8base and Phobos: why reimaging one host will not save you

8base is an active ransomware group that runs a Phobos-based encryptor delivered through a SmokeLoader loader. It is not fast-and-loud. Its signature is stickiness and quiet. Heavy persistence, heavy defense evasion, and double extortion. If you respond to it the way you would respond to a single infected laptop, you will think you are clean while the encryptor re-arms behind you.

How it works

The intrusion starts with a packed, obfuscated SmokeLoader stage that beacons out and pulls the Phobos payload. Packing defeats static signatures, so the first stage often looks like an unremarkable process. From the beachhead the actor harvests credentials and escalates through access-token impersonation (T1134.001) into a Domain Admin context, moving off the original host.

Then the tradecraft that defines 8base begins. On each host it can reach, it plants more than one way back in: a registry Run-key autostart, one or more scheduled tasks (T1053.005), and a Startup-folder copy, all pointing at the same payload. It disables endpoint tools it can reach (T1562.001), clears Windows event logs to hide its tracks, and deletes Volume Shadow Copies (T1490) so local recovery is gone before anything is encrypted. Only then does it stage the Phobos encryptor (T1486) to a distribution share and queue it through the persistence it already planted. Data is typically stolen before encryption, which is how the group runs double extortion: pay to decrypt, and pay again so we do not leak what we took.

Why reimaging one host fails

The intuitive response to a ransomware precursor is to grab the noisy host, wipe it, and restore it from its most recent snapshot. Against 8base that fails twice over.

First, the persistence is redundant by design. Removing the Run key on the beachhead leaves the scheduled tasks and the Startup-folder copy intact, and they live on other hosts too. One leftover foothold re-detonates the payload after you believe you have contained it. The redundancy is the whole point. It is built to survive partial cleanup.

Second, the snapshot you want to restore from is already gone. Phobos deletes Volume Shadow Copies early in the sequence, before it stages the encryptor. So the local recovery point your reimage plan depended on does not exist by the time you reach for it. You cannot restore from a shadow copy that was deleted an hour ago.

The correct mental model is that the incident is the domain, not the one host, and the recovery source is not local.

How to detect

No single mechanism gives 8base away, because admins create scheduled tasks and drop startup items every day, and packers exist in benign software. The tell is the correlation. Watch for Volume Shadow Copy deletion (vssadmin or wmic) and event-log clearing (Event ID 1102) happening alongside a Run-key write, a Startup-folder copy, and scheduled tasks that all reference the same binary, from a host that recently beaconed. Inhibiting recovery before any file is encrypted is the pre-detonation signature. Domain Admin logons originating from a recently beaconing host sharpen it further.

Contain, eradicate every foothold, recover from offline backups

Containment here is completeness, not just speed. Isolate every host the Domain Admin context touched, not only the loud one. Cut the DA foothold: disable and reset the account and rotate krbtgt twice with replication. Re-enable or reinstall the endpoint protection the actor disabled so it can catch a re-detonation attempt.

Eradication means enumerating persistence across three classes on every touched host: Run-key autostarts, Startup-folder copies, and scheduled tasks. Treat a host as clean only when nothing autostarts the payload anymore. Miss one and the encryptor comes back.

Recovery cannot use local snapshots, because the shadow copies were deleted. Restore only from offline or immutable backups the actor could not reach. This is exactly why offline and immutable backups are not optional against a group that inhibits local recovery as standard practice.

Then frame the impact honestly. Averting encryption is a real win, but Domain Admin was compromised and data was likely staged and stolen before encryption. Under double extortion the leak risk persists even if not a single file was locked. Notification obligations follow the scoped data exposure and the credential compromise, not whether the files were encrypted or whether you paid.

Practice it

We built the 8base identity-to-domain intrusion as a scenario in GraphLattice Range so responders can rehearse the decision that matters: the moment you are tempted to reimage one host and move on, and the reasons that fails against redundant persistence and deleted shadow copies. The reps are cheaper than learning it during the real thing.