Deciding whether to rebuild or restore after ransomware

Work the table by marking every row you can observe in your own environment. The rows are not weighted equally and they do not average out. A single row in the lower half forces the outcome in its right-hand column no matter how many rows above it look reassuring, because those rows describe exposure of credential material or destruction of the record, and neither is undone by cleaning a disk.

The absence of findings does not license cleaning. Most of these conditions are observable only if you had the telemetry to observe them, so an environment with ninety days of endpoint detection data and one with a fortnight of firewall logs are answering different questions when they both report nothing found. Where you cannot test a row, treat it as unknown and let the unknown push the decision toward rebuild for that tier. Write down which rows you could not test, because that list is the honest scope of the recovery and somebody will ask for it later.

When a writable domain controller is compromised, or its database is copied out, every secret the domain holds goes with it. That is broader than the password hashes. It includes the key material that Kerberos authentication chains up to, and resetting every user password in the directory does nothing about it. This is the row in the table above that gets underestimated most often, because the visible damage may be one encrypted file server while the actual exposure is the whole authentication system.

The krbtgt account is the specific problem. Its key signs and encrypts every ticket-granting ticket in the domain, so an attacker holding it can mint tickets for any principal. Microsoft's Active Directory forest recovery guidance is unambiguous about the remedy: reset the krbtgt password twice, waiting ten hours between the two resets. Ten hours is the default maximum lifetime for both user and service tickets, so the wait lets tickets issued under the old key expire on their own instead of breaking mid-session, and where a domain is configured with a longer lifetime the wait has to exceed that configured value. Two resets are needed because the password history for that account holds two passwords, so a single reset leaves the previous key in history and forged tickets built on it keep validating. Running both resets back to back with no wait produces an authentication and replication outage of your own making, which is how a recovery generates its own second incident. Budget for the disruption either way, because every ticket-granting ticket already issued stops being accepted and the dependable way to return a machine to service is a reboot.

Group managed service accounts need separate handling. Their passwords derive from the Key Distribution Service root key, so an attacker who read that root key object, together with an account's security identifier and its managed password identifier, can compute those service account passwords offline and keep computing them. Rolling the accounts changes nothing while the root key stays the same. Microsoft documents the recovery: create a new root key, get every group managed service account onto it by letting the passwords roll or by recreating the accounts outright, then delete the old root key object once they have all moved. A new root key is not usable in production for about ten hours after creation, so this belongs in the plan from the first day of the recovery.

The same reasoning covers the domain controller computer account and the trust passwords on each side of every domain trust, both of which the forest recovery procedure resets when the recovery is driven by a security breach. If the identity plane is in scope, rebuilding the file server is not the job. The identity plane sets the sequence for everything else, and until it is rebuilt or fully rotated, nothing you reconnect to it is trustworthy no matter how carefully that system was rebuilt.

Credential rotation has a dependency problem. Every rotation is performed using access that may itself be compromised, and several of the rotations will lock out the people performing them. Before anything else, establish a clean administrative path: a freshly built device that has never touched the compromised environment, a cloud-only break-glass account with phishing-resistant multi-factor authentication enrolled on it, credentials held offline, and an alert that fires whenever that account signs in. Everything below is performed from there.

The ordering rule is to rotate the things that issue trust before the things that consume it, so the key material behind Kerberos goes before the service accounts that authenticate with it, and federation certificates go before the applications that trust them. Reverse that order and you rotate downstream credentials the attacker re-harvests using the upstream access you left in place, which buys a long night of work and no change in position.

The second rule is that a reset and a session revocation are one operation. A password change does not retire an existing session, and in most estates what the attacker holds is a live session, which no password change touches. The table sets out the order. The fourth column is the part worth arguing about internally, because that is where an item gets quietly missed.

Refresh tokens and browser session cookies are the first surprise. In Microsoft Entra ID, invalidating them is an action separate from the reset: Revoke sessions on the user in the admin centre, or revokeSignInSessions through the Graph API, which stamps a validity date on the account and forces every application to obtain new tokens. Two details change how you use it. A few minutes can pass before the revocation takes effect, so a revocation issued in the same breath as a reset has to be verified afterwards. And it does not revoke sign-in sessions for external users, because those users authenticate in their home tenant, which makes every guest holding access to your data a separate piece of work.

Access tokens already issued are the second gap. A standard access token has a default lifetime in the region of an hour, so an attacker holding a live one keeps that access for the remainder of its life after the reset lands. Where both the client and the resource support continuous access evaluation, token lifetimes extend to as much as twenty-eight hours, and in exchange revocation on critical events such as a password change happens close to real time, though propagation can still take up to about fifteen minutes. The instruction is the same in both cases. Reset, revoke sessions, then read the sign-in logs for that account and watch what the attacker's client does next.

Application identity is the gap that most often survives an entire recovery. A consent grant made months ago, a service principal carrying directory permissions, a client secret uploaded to an application registration: none of these are touched by resetting human passwords, and none appear in the account lists most teams work from. Enumerate every application with permissions over mail, files or the directory, rotate its secrets and certificates, and remove anything nobody present can explain.

Rebuilt systems should not be returned to the network they were compromised on. Build a new segment with new addressing and its own controls, and let systems enter it only once they have been rebuilt or verified. Nothing crosses from the old environment except data that has been through a defined check, and the old environment stays isolated and powered down instead of decommissioned, because you are going to want it later. Reconnection then becomes a sequence of gates, each carrying a criterion written before the stage starts, so the decision to proceed is measured against something agreed while everyone was calm.

The monitoring goes in before the traffic does. Endpoint detection is installed and reporting on a host before that host receives an address. Egress filtering denies by default, with an allow-list you build deliberately, because an allow-list generated from the first day of live traffic encodes whatever the attacker is still doing. Name resolution is logged in full, and sign-in alerting runs on the rebuilt identity plane with a specific alert on the break-glass accounts. Without that visibility there is no record of why each system was let back in, and an insurer reviewing the claim will ask for exactly that record.

Rebuilding destroys the evidence. Wiping and reimaging is the correct remediation for a compromised host, and it is also the most common way an Australian business loses the ability to answer questions it will be asked for the next two years. The fix is unglamorous. Image before you wipe, and hold the images on media the rebuild cannot reach.

The people who will ask are known in advance. A cyber policy commonly requires the insurer's agreement to the forensic provider and a forensic account of what happened before a claim is settled, so decisions taken in week one shape what eventually gets paid. The Notifiable Data Breaches scheme under the Privacy Act 1988 requires you to assess a suspected eligible data breach expeditiously and in any event within thirty days, and you cannot assess what you deleted on day three. Cybercrime is reported through ReportCyber, run by the Australian Signals Directorate's Australian Cyber Security Centre, and critical infrastructure entities carry separate reporting duties under the Security of Critical Infrastructure Act. A civil claim years later is decided on records, and the records will be whatever you kept in the first fortnight.

Capture full disk images of the first host you can attribute to the attacker and of every host where credential access is suspected. Take volatile memory where the machine is still running and the decision is made early enough to matter. Export the logs that age out fastest, usually identity sign-in logs, endpoint telemetry, firewall and proxy records and mailbox audit data, because retention windows will quietly delete the period you care about while the recovery is still running. Keep the ransom note and every communication with the operator. Keep a contemporaneous action log of what was changed, by whom and at what time, which is separately useful when you need to show that a given change was yours and not theirs.

Settle the engagement structure on day one. A forensic report commissioned directly by the business is ordinarily discoverable. A report commissioned by external counsel for the dominant purpose of providing legal advice may attract legal professional privilege, and Australian courts have examined those arrangements closely enough that the outcome turns on how the engagement genuinely operated and not on what the cover page says. That is a decision for your lawyer, and it has to be made before the first forensic invoice is raised.

The end of an incident is a decision, and it should be made against criteria written down before the recovery started. Left undefined, it gets made by exhaustion, usually by whoever is least willing to keep saying no to the operations manager.

Give every criterion a named owner and a written confirmation. A recovery of any size is worked by internal staff, a managed service provider, a forensic firm and at least one software vendor at once, and each assumes somebody else covered the item that turns out to be missed. These are the criteria worth agreeing in advance.

The second incident follows a consistent shape. The environment is restored, the business resumes trading, and within a few weeks the same operator returns, often with better knowledge of the estate than they had the first time. The review almost always finds the same cause. The entry vector was never actually closed, or it was closed on the systems that were rebuilt and left open on one that was not.

There is one question to put to every system before it reconnects, and it is not whether the scan came back clean. Ask how you know this specific path is closed, and what you would expect to see if it were not. An answer that amounts to the tools being quiet is the same answer the organisation had the week before the first encryption. The paths below are the ones that keep turning up, and they are short enough to work through as a checklist.

Black Shard runs incident response and breach remediation for Australian businesses, and the decision described here is the one we make jointly with a client and put in writing. That record covers the conditions observed, the recovery position they support, what was rotated and in what order, what evidence was preserved before anything was destroyed, and the criteria met at each reconnection gate. It exists because the insurer, the regulator, the board and possibly a court will each read a version of that account later, and reconstructing it from memory months afterwards is how a defensible recovery turns into an indefensible one.

The work that follows sits across the rest of what we do. Rebuilding an identity plane is Entra ID and Azure security work. Proving the entry vector is closed is penetration testing, and a repeat vulnerability scan does not answer it. Watching a reconnected estate for the return of an operator is attack surface monitoring. Holding the standard steady while the business pushes to be back up is the part a vCISO carries. Our approach and trust pages set out how an engagement runs, and the breach page is the direct path if you are working an incident now.