Ransomware Simulation

Simulated Persistence and Encryption Controlled Threat Response Exercise. Three of those words are the whole proposition: it is simulated, it is controlled, and it is an exercise. The persistence and encryption are the parts your organisation experiences and your tooling has to catch; the control and the reversibility are what make it something you can run on a working Tuesday. We describe it as a controlled threat producing a real response.

No. Not at any tier, and there is no encryption capability in the agent to enable. Files are renamed with a .spc_sim extension and nothing else about them changes — same bytes, same location. Each path is written to a manifest on disk before that rename happens and streamed to our control plane as the run proceeds, so the record of what to put back exists before anything is touched. The ransom note is a piece of theatre that talks about AES-256; the software behind it does not implement it.

There are four independent ways to stop it, and three of them restore your files. We can kill it from the dashboard; your lead can type the kill code at an affected terminal; or, if the machine cannot reach us at all, dropping a file named SPECTRE_KILL containing the kill code into the agent's directory triggers the same restoration. Ending the process in Task Manager stops it without restoring, and the manifest is then used to put things back. Restoration takes seconds, and if the agent is ever re-run on a machine with an unfinished manifest it restores rather than starting again.

That is the single best outcome available and it is a finding we will happily write up. If your controls block the binary before it does anything, you have paid for proof that the money you spent on endpoint protection works. We record it as blocked, note what stopped it, and the report says so. What clients tend to discover is more nuanced: something detects it, and nobody acts on the alert for forty minutes.

No, and we are careful about this. A ransomware simulation is not a penetration test and is not delivered under our CREST accreditation — it is a threat simulation exercise that measures detection and response. It complements penetration testing rather than replacing it: a test tells you where an attacker could get in, a simulation tells you what happens once something is already running inside.

No. The agent is deployed by hand to hosts named in the rules of engagement and has no self-propagation. It only touches the paths in the agreed scope, honours a maximum file count, and is inert without a valid engagement-scoped token. Where you authorise network enumeration it looks at what is reachable and reports it, but looking is all it does.

It is designed to be alarming, because an experience nobody takes seriously teaches nothing — but it is bounded. You choose the tier, and Canary involves your staff not at all. Your lead holds a kill code that stops everything within seconds, and we brief them to use it the moment anyone becomes distressed rather than waiting to see. Debriefing people quickly afterwards matters, and the reporting is aggregated and blame-free by design, exactly as it is for our phishing work.

The simulation targets Windows endpoints, which is where the ransomware risk overwhelmingly sits. The on-screen elements — wallpaper takeover, notes and overlay — are Windows-specific, so a Windows estate is what a Standard or Full Impact engagement needs.