Clean restore point after ransomware: Why not every backup is trustworthy
The recent cyberattack on the Berlin state administration serves as a prime example of how long an attacker can remain undetected in a network before an incident is even noticed. According to current information, the perpetrators gained access to the systems of two Senate departments as early as August 7th, but the affected areas were not discovered and isolated until August 14th. The incident was also discovered rather by chance, as the central IT service provider, ITDZ Berlin, noticed unusual network activity that was not actually within its remit ( Born's IT and Windows Blog ). On September 1st, the Berlin Senate Department officially confirmed that passwords in plaintext had also been compromised in the attack, stored in ordinary Office files belonging to various specialized applications ( heise online ). Since then, approximately 12.000 systems in the state network have been continuously scanned to prevent further compromises.
This scenario – an attacker who remains undetected for days or weeks before damage becomes visible – poses a question for companies and authorities that is often neglected in the public debate about ransomware: If the exact time of the initial compromise can only be reconstructed retrospectively, which backup version is still trustworthy?
Table of Contents
Cyberattack on Berlin: One week of undetected access before discovery
The Berlin case highlights the problem in several ways. First, there was a gap of about a week between the actual intrusion and the isolation of the affected systems – time in which attackers typically not only gain access but also collect further credentials, expand privileges, and establish a foothold in neighboring systems. Second, the incident was not discovered through targeted monitoring by the affected administrations themselves, but rather incidentally by an external service provider. Third, the need to systematically scan 12.000 systems retrospectively demonstrates that even after the immediate response, the authorities could not be certain how far the compromise had actually spread. Governing Mayor Kai Wegner publicly declared that the state of Berlin would not be blackmailed ( Tagesspiegel ) – however, the actual technical challenge of determining when the systems could be considered trustworthy again remains unaffected.
Why a technically successful restore does not guarantee a clean restore point
Traditional backup concepts focus on Recovery Time Objective (RTO) and Recovery Point Objective (RPO) – that is, how quickly and with how much data loss a recovery can be performed. Whether a restore process functions reliably from a technical standpoint is a separate, important question that is addressed through regular recovery testing . However, the present case raises a separate, preliminary question: Even if a restore process functions flawlessly from a technical standpoint, this says nothing about whether the chosen recovery point itself is still uncompromised.
In the Berlin case, this gap can be clearly traced: Seven days lie between August 7, the earliest possible access date according to current knowledge, and August 14, when the affected administrations were isolated. Any backup created during this period would have been unremarkable according to classic RPO logic – a restore to August 10 or 12 would have appeared at first glance to be an obvious, current choice. In reality, however, such a restore would very likely have reinstated the same, already ongoing compromise.
The Berlin case provides a concrete example: The affected applications stored password lists in plain text in ordinary Office files. Such files are routinely backed up by standard backup jobs without their security-critical content being specifically assessed. If these files were already read during the seven-day compromise, a restore from that period would formally be "before encryption"—but the affected access data would still already be in the hands of the attackers, regardless of the chosen restore point.
Risk of Re-Infection: What a False Recovery Point Means for Businesses
For affected organizations, this translates into a significant increase in workload after an incident. Instead of simply restoring the most recent available backup, a forensic investigation must first determine when the compromise actually occurred – a process that can take days or even weeks and delays the actual restart. If, instead, a supposedly secure backup is used prematurely, there is a risk of re-infection: the system may be running again, but the attacker still has access or can re-enter the system using restored but compromised credentials.
This uncertainty also increases the pressure on communication and reporting processes. As long as it is unclear which systems and which time period are actually affected, the extent of a potential data breach can only be estimated provisionally – with corresponding consequences for the GDPR assessment and for internal and external communication.
Five requirements for a recovery strategy that ensures clean restore points
This problem gives rise to several requirements for a robust recovery strategy:
Maintain multiple restore points over an extended period. Those who only keep the last one or two backups may not have a clean restore point to fall back on in the event of a prolonged, undetected compromise.
Actively check restore points before restoring. Instead of blindly reverting to the most recent state, a restore candidate should be examined in an isolated environment for anomalies such as unexpected processes, changed configurations, or embedded malware before being deployed to the production environment.
Regular recovery testing is a prerequisite, not a replacement. Whether a restore process functions technically should be continuously verified through structured recovery testing. However, this testing does not answer the question of whether the tested recovery point itself is free from compromise – both checks are necessary, but different.
Reassess login credentials and permissions during every recovery process. Since login credentials may have been altered or intercepted during an undetected compromise, a recovery should always include resetting critical login information instead of simply reusing existing credentials.
Expand RTO and RPO planning to include an uncertainty scenario. Contingency plans should not only cover the case of a known outage time, but also the scenario of an unclear compromise duration that must be determined retrospectively – with correspondingly longer, but realistic timeframes for full recovery.
Expert view: Recoverable is not synonymous with clean
According to Reinhard Quickstern, a certified Business Continuity Manager at Cristie Data, the central misconception in many disaster recovery plans is equating recoverability with cleanliness. A backup that can be restored flawlessly from a technical standpoint is therefore not necessarily free of traces of a previous attack. In practice, this confusion leads to systems being quickly restored after an incident, while the underlying threat persists undetected.
This becomes particularly critical when – as in the Berlin case – the discovery of an attack occurs more or less by chance and not through targeted, continuous monitoring of one's own backup and production environment. The longer the actual duration of the compromise remains unclear afterward, the larger the circle of potentially affected backup versions becomes – and the more important a systematic, not purely time-based, review of the available recovery points becomes.
Recommendations for action: How companies determine a safe recovery point
The above-mentioned requirements cannot all be implemented simultaneously. A phased approach is advisable, starting with an inventory and gradually transitioning into processes and governance:
Immediately implementable (inventory):
1. Check how many recovery points are currently maintained and over what period – is the depth sufficient to cover even a compromise that went undetected for several weeks?
2. Clarify which specialist procedures or applications store security-critical content such as access data in ordinary file formats instead of in designated, better-protected systems – the Berlin case shows that exactly such files are easily overlooked during restoration.
Short term (process definition):
3. Establish a clearly defined procedure for the forensic brief review of a recovery point, including responsibilities and maximum time duration, so that this step does not have to be improvised in an emergency.
4. Integrate the process for resetting access credentials and certificates as a fixed component of every major recovery in the incident response runbook.
Medium term (infrastructure and monitoring):
5. Include the backup infrastructure itself in security monitoring – not just the production systems. Unusual access to backup storage is an independent warning signal that is currently missing in many concepts.
Governance (define in advance, do not decide in a crisis):
6. Define decision-making processes for who, in an emergency, weighs the options between several possible recovery points and on what basis – so that this decision does not have to be made under time pressure and without clear responsibility.
Conclusion: Restore points must be checked, not just stored.
The cyberattack on the Berlin state administration demonstrates that considerable time can elapse between an attacker's actual intrusion and their detection – with direct consequences for choosing a trustworthy backup recovery point. A modern recovery strategy can no longer rely on the most recent available backup automatically being the most secure. Instead, robust cyber resilience practices require multiple recovery points, systematic testing of these points before restoration, and regularly tested, automated recovery processes that actually work in a crisis.
Frequently asked questions about backup restore points after ransomware attacks
Why isn't the last backup automatically safe after a ransomware attack?
If an attacker had access to a network for an extended period before the incident was discovered, backups from that time may already contain compromised elements such as altered credentials or manipulated configurations. A simple restore could result in the attacker retaining access even after the system has been restored.
What does Recovery Point Objective (RPO) mean in the context of cyberattacks?
RPO describes the maximum tolerable data loss and thus indirectly how far back in time a recovery point can be. In the case of cyberattacks with an unclear duration of the compromise, RPO planning must be supplemented by the question of whether the chosen point in time is actually before the start of the compromise.
How long do attackers typically remain undetected in a network?
The actual duration varies considerably depending on the type of attack, the detection technology used, and the organization. The Berlin case exemplifies a gap of approximately one week between initial access and the isolation of the affected systems; in other cases, the timeframe can be significantly longer.
What is a clean recovery point?
A clean restore point is a backup state that demonstrably predates any compromise and contains no manipulated configurations, credentials, or embedded malware. It is typically determined through forensic examination and automated scans in isolated test environments.
Are regular backups alone sufficient protection against ransomware?
Regular backups are a necessary but not sufficient condition. Without verifying the integrity and cleanliness of the restore points, there is a risk that even backed-up data may already contain compromised elements.
Should all login credentials be changed after a system restore?
Yes, this is considered best practice, as login credentials may have been intercepted or altered during an undetected compromise. Resetting critical login credentials during recovery reduces the risk of further compromise using previously known credentials.
Act now – we are your partner for cyber resilience and recovery
Cristie Data supports you with years of expertise in backup, recovery, and cyber resilience – so that in an emergency, you can rely not only on data recovery but also on the integrity of your recovery points. Contact us – a phone call or email is all it takes.
