Registry Parser
← All articles

Registry forensics in a ransomware investigation

8 min read

A user calls the help desk: files renamed with a .locked extension, a README_RESTORE.txt in every folder, and the desktop replaced with a black background and a Bitcoin address. By the time you image the host, the operator is long gone and the EDR agent was killed an hour before encryption. You have the disk. The question your incident lead actually wants answered is not "what does the ransom note say" — it is "how did it get in, what ran, how did it stay, what did it turn off, and when". The registry answers four of those five with high confidence, and it does so from artifacts that survive even when the logs were cleared and the malware deleted itself.

This is a practitioner's map of ransomware registry forensics: which ransomware artifacts live in the hives, what each one proves, and the order to work them. It is a workflow post, not a tutorial on each artifact — the deep-dives are linked, and you should read them once. Here we synthesize them into a case. For the broader scenario catalog this post sits under, see the registry forensics in investigations pillar.

The artifacts that matter

Ransomware intrusions follow a recognizable arc — initial access, execution, persistence, defense evasion, then mass encryption. The registry has a witness for most of those stages, scattered across three hives. Group them by the question they answer.

Execution — what ran, and was it present

  • Shimcache (AppCompatCache), in SYSTEM: proves a binary existed at a path on disk, with its file modification time. Presence is the signal; the entry is not proof of execution and the timestamp is the file's $STANDARD_INFORMATION mtime, not a run time. Order-of-entry on Win10+ is no longer reliable. Treat it as "this svhost.exe in C:\PerfLogs\ was on the box".
  • Amcache, in Amcache.hve: the strongest single registry execution-and-presence artifact. Full path, SHA-1 of the file, compile time, and first-seen time. The hash is the lever — it survives renaming and lets you pivot straight to threat-intel and to the dropper across hosts.
  • BAM/DAM, in SYSTEM: Background Activity Moderator records the last execution time per executable, per user SID. This is the closest thing the registry has to a "this ran, here, at this time, as this user" statement. Short retention, so it skews toward the recent — which in a ransomware case is exactly the encryptor.

Correlate the three: Shimcache and Amcache for "the binary was here", BAM for "it ran, as this user, at this time". When all three name the same path, you have your execution evidence.

Persistence — how it stayed

  • Run keys and IFEO, in SOFTWARE and NTUSER.DAT: the classic autostart values, plus Image File Execution Options debugger hijacks. Fast to triage, frequently used, and the key's LastWrite time brackets when persistence was planted.
  • Services, in SYSTEM: a malicious service is a favorite for both persistence and SYSTEM-level execution. Look for services with binaries in non-standard paths, a recent LastWrite, Start=2 (auto), and missing or junk Description values.
  • Scheduled tasks (TaskCache), in SOFTWARE: TaskCache maps task GUIDs to actions and stores creation and last-run times. Ransomware operators love scheduled tasks for staging the encryptor across a fleet via GPO or PsExec. Cross-check against the on-disk XML in C:\Windows\System32\Tasks.

Defense evasion — what it turned off

This is where ransomware intrusions are loud in the registry, because disabling protection requires writing to it. The full technique breakdown is in the Impair Defenses (T1562.001) post; the registry tells:

  • Defender neutered, in SOFTWARE: DisableAntiSpyware, DisableRealtimeMonitoring, and — the operator's signature — exclusion paths and extensions under Windows Defender\Exclusions. An exclusion for C:\ or for the encryptor's working directory, written minutes before encryption, is intent on a plate.
  • Event logging crippled, in SOFTWARE: channels disabled under the WINEVT Channels keys, or audit policy gutted. The registry shows the configuration change; the gap in the logs shows the effect.
  • Recovery sabotaged: VSS and boot-recovery tampering often lands as service-disable writes in SYSTEM alongside the vssadmin/bcdedit execution traces.

A cluster of these writes, tightly grouped in time, is itself a finding — it is the pre-encryption staging window.

The ransom-note tell — wallpaper

In NTUSER.DAT, Control Panel\Desktop\Wallpaper and the Active Setup wallpaper policy point at the ransom-note image the operator dropped, with a LastWrite time that approximates the moment of detonation. It is a small artifact that often pins the encryption timestamp better than anything else.

A working order

Load the hives and work them in the order that builds the timeline outward from the encryption event.

  1. Anchor the detonation. Start with the NTUSER.DAT wallpaper write and the Defender-exclusion LastWrite in SOFTWARE. These bracket the encryption window. Now you know roughly when.
  2. Find the encryptor. Pull BAM/DAM for executions in that window, per SID. The unfamiliar path that ran as the affected user, minutes before the wallpaper changed, is your prime suspect.
  3. Confirm presence and get the hash. Take that path to Amcache for the SHA-1 and first-seen time, and to Shimcache to confirm it was on disk. The hash goes into your IOC list and pivots you to every other host.
  4. Walk back the staging. The defense-evasion writes (Defender, event log, recovery) cluster just before execution. Their LastWrite times give you the hands-on-keyboard window. This is usually where the operator was actively working.
  5. Map persistence. Run keys, services, and TaskCache tell you what would have survived a reboot and how lateral staging happened. A service or scheduled task pointing at the same binary closes the loop between persistence and execution.
  6. Reach back to initial access and dwell. Persistence LastWrite times that predate the encryption window by days or weeks reveal dwell time. If the earliest malicious Run-key write is two weeks old, this was not a smash-and-grab.

Worked across the three hives, this turns "ransomware hit on Tuesday" into a sequenced narrative: planted on the 3rd, defenses disabled at 02:11, encryptor ran as DOMAIN\svc-backup at 02:14, wallpaper changed at 02:31.

Gotchas

  • Timestamps need a timezone. FILETIMEs in the hive are UTC. Key LastWrite times are UTC. Your timeline tooling may render local. State your timezone in case notes or you will misalign the registry against EDR and log evidence by hours.
  • The registry shows configuration, not the live effect. A DisableRealtimeMonitoring=1 value tells you protection was set to off; it does not tell you it was off at every moment, and it does not tell you what was missed. You need the Defender operational logs and the gap they show to prove effect. Same for event-log disables — the registry is the cause, the missing log is the proof.
  • Shimcache is not execution. Repeat it until it sticks. Presence and a file mtime. BAM and Amcache carry the execution weight.
  • BAM retention is short. If the host ran for a while post-encryption, the encryptor may have aged out of BAM. Pull from VSS snapshots and from every affected host — the encryptor that aged out on one box is fresh on the one imaged first.
  • Replay the transaction logs. A hive captured from a live or hibernated system may have pending writes in .LOG1/.LOG2. Drop them alongside the hive or you may miss the most recent — and most relevant — Defender or wallpaper write.
  • Attribution stops at the SID. BAM and NTUSER artifacts attribute to a user account. If the operator ran the encryptor under a compromised service account, the artifact correctly names that account — which is the account, not the human.

Work the case in your browser

Drop the SYSTEM, SOFTWARE, NTUSER.DAT, and Amcache.hve from the imaged host into Registry Parser. Nothing uploads — the hives are parsed client-side and discarded when you close the tab, which matters when those hives carry case-sensitive material. The artifact plugins surface Shimcache, Amcache, BAM, services, Run keys, and TaskCache without you hand-walking the key paths.

Build the timeline by sorting the cross-artifact view on timestamp: the wallpaper write, the Defender exclusion, the BAM execution, and the Amcache first-seen line up into the staging-to-detonation sequence above. The Findings panel flags the high-signal patterns automatically — Defender exclusions written immediately before an unfamiliar execution, services with binaries in temp paths, disabled log channels — so you triage the cluster instead of grepping for it. Export the findings with the original SHA-256 of each hive for your case notes and IOC list.

Related