Ransomware is often described as an encryption event. This illustration follows a different shape, where recovery options are removed first and the encryption is only the visible part that follows.
Composite case study: based on patterns observed across incident response engagements; details are blended and illustrative.
The situation
A backup administrator opens the console for a routine check and finds that several jobs and repositories have been deleted. Nobody on the team made the change. The audit trail shows a login from a host that does not normally touch the backup system, using a shared administrator account. That account also carries domain-level privilege, which is a common setup and a common weakness.
No encryption has been seen yet. That detail matters. Backup deletion often happens before encryption starts and can mark the end of the quiet phase, so the organization may still have room to act.
What the investigator saw
The security lead does not wait for a finished timeline. On the strength of what is already known, the responders act at once:
- Isolate the backup infrastructure from the rest of the network.
- Disable the shared administrator login and revoke its active sessions.
- Reset domain-level credentials and sessions, because the shared login carried domain privilege.
Evidence capture runs in parallel with that work, not ahead of it. Console audit logs, authentication logs and endpoint telemetry are exported and preserved while containment proceeds.
With those steps underway, the investigator starts reconstructing what happened. The signals are the ones this pattern commonly produces: backup console logins from unexpected accounts or hosts, deletion of jobs and restore points in the audit trail, shadow copy deletion commands and recovery-setting changes in endpoint telemetry, and backup agents that were stopped or removed.
How it was confirmed
The investigator lines up the backup audit trail against authentication events. Who touched the backup system, and when, often reveals the privilege level the operator already held. In this illustration the answer points to broad administrative reach, which supports the decision to treat identity as suspect and not just the backup server.
Then comes the question of what survived. The responders check for offline copies, immutable copies, cloud-side copies and snapshots on separate storage. Here an offline copy exists, but it is months old. It is genuinely valuable, because it is out of the operator’s reach. It is also incomplete, so recent data will need to come from other sources.
What it cost
The cost is mostly time and trust. Rebuilding from a stale copy means rework, and recent changes have to be recovered from other places or recreated by hand. Confidence in the backup program takes a hit too. The team has to ask which restore points predate the intrusion and which cannot be relied on, and that uncertainty slows decisions.
Containment
Containment, as described above, starts as soon as the problem is understood, and it continues while the investigation develops. The backup credentials are rotated and stored separately from everyday administrator accounts. The offline copy is validated on a clean network, away from the affected environment.
In this illustration, the organization’s first wrong move is the urge to restore before cleaning identity. Bringing systems back into a domain whose administrator credentials may still be trusted can hand access back to whoever held it. The better order is identity first, then core services, then data. Restoring quickly feels productive, but it tends to work only when the foundation underneath is clean.
Lessons
A backup that the compromised administrator can reach may not protect you against ransomware. Copies should be immutable, credentials should be separate, and restores should be tested before they are needed.
Common organizational mistakes in this pattern include:
- Using domain admin credentials on the backup server.
- Skipping a test of a full restore.
- Leaving the backup network reachable from user networks.
Checklist for your next incident
1. Isolate the backup infrastructure from the network.
2. Disable the shared administrator login and revoke active sessions.
3. Reset domain-level credentials and sessions, since the shared login may hold domain privilege.
4. Rotate backup credentials and keep them separate from everyday accounts.
5. Capture evidence in parallel: backup audit trail, authentication logs, endpoint telemetry.
6. Look for shadow copy deletion, recovery-setting changes and stopped backup agents.
7. Identify what survived: offline, immutable, cloud-side, or separate snapshots.
8. Validate surviving restore points on a clean network.
9. Clean identity before restoring, then rebuild core services, then data.
10. Schedule a full restore test once the dust settles.
Message us to talk through your backup recovery plan.
See how we help with incident response and security services.
Discover more from Core-Infosec
Subscribe to get the latest posts sent to your email.
