Recovery Begins Before Persistence Is Eliminated

The pressure to resume operations triggers restoration before initial access, persistence mechanisms and the scope of compromise have been sufficiently understood and addressed.

Backups are available, executives want to restart and visible systems have been cleaned. This combination gives an impression of progress. Yet compromised identities, active sessions, keys, scheduled tasks, forgotten devices, remote access or cloud changes may still allow the attacker to return.

Recovery reconnects clean systems to an environment that may not be. It offers new targets, sometimes restores vulnerable configurations, and tips off the attacker that the organization is rebuilding.

The result can be a second compromise, a second exfiltration or a new encryption event, often more costly than the first because backups, teams and decision-makers’ trust have already been worn down.

"The EDR isn’t seeing anything anymore" is not a criterion for authorizing recovery. It’s one observation among several.

• Ask what objective evidence must exist before a system can be restored or reconnected.
• Check whether the criteria cover initial access, persistence, identities, sessions, network, admin consoles and unknown assets.
• Examine who holds recovery authority and whether that person receives a clear picture of residual risk.
• Look in the plans for a real separation between containment, eradication and recovery.
• Check whether operational pressure can bypass the criteria without formal risk acceptance.

• Define exit criteria for containment and eradication before setting technical restoration criteria.
• Require joint authorization from operational leaders and incident response to reconnect critical services.
• Prepare recovery waves: identity and administration, core services, priority applications, then the rest of the environment.
• Plan for an isolated restoration environment where systems can be validated before reconnection.
• Document dependencies, enhanced monitoring controls and a rollback mechanism.
• Test the plan with a scenario where the first restoration must be paused because of a new indicator.

• Suspend non-essential restorations until the main return paths have been assessed.
• Establish written criteria, even simple ones, for each wave: secrets rotated, persistence hunted, log sources active, critical assets validated and approval obtained.
• Restore into an isolated segment, with enhanced monitoring and strictly necessary communications.
• Rotate identities and secrets from clean infrastructure before reusing them.
• If recovery must begin despite uncertainty, have the residual risk explicitly accepted and documented; monitor as if re-intrusion is expected.