Investigating a real incident with the Amcache: walkthrough

The host is CORP-FS-04, a Windows Server 2019 file server. Backup operations died at 02:14 UTC last Tuesday. The on-call admin found two file shares full of .[recovery-id]@onionmail.org.locked extensions and a ransom note in every directory. EDR was deployed two weeks ago and had not yet been configured to alert on encryption behaviour. Live response started at 09:00 UTC, four hours after detection.

This is fictional, but it is built out of pieces from real cases. The point is not the ransom narrative; the point is what the Amcache contributed, where it earned its keep, and where I had to be honest about what it did not prove.

What was collected#

KAPE triage, run from a network share, dumped the standard targets into \\evidence\corp-fs-04\:

Amcache.hve, Amcache.hve.LOG1, Amcache.hve.LOG2
The Prefetch folder
All Windows event logs, including Microsoft-Windows-Sysmon%4Operational.evtx (Sysmon was deployed three months ago, lucky us)
$MFT, $LogFile, $UsnJrnl:$J from the USN journal
The Software, System, Security, and Default user hives from the registry
VSS snapshots from before the encryption window

The Amcache hive was the first artifact I opened, because the question on the table was "what tool encrypted the files", and the Amcache is the cheapest place to look for executables that may have been deleted post-encryption.

First pass: parse and filter#

AmcacheParser:

AmcacheParser.exe -f Amcache.hve --csv .\parsed\ --mp -i

UnassociatedFileEntries.csv had 14,802 rows. AssociatedFileEntries.csv had 6,991 more. Twenty-one thousand rows is too many to eyeball.

Filter rules I applied in the order I always apply them:

Drop everything under c:\windows\winsxs\, c:\windows\servicing\, c:\program files\microsoft\. That is OS noise.
Drop entries with IsOsComponent = True. More OS noise.
Keep entries where LowerCaseLongPath is in \users\, \programdata\, \windows\temp\, \perflogs\, or anywhere with \appdata\ in the path.
Keep entries where Publisher is empty or Unknown. Signed software with a real publisher is rarely the first lead.
Sort by KeyLastWrite descending.

That left 47 rows. Manageable.

The three entries that stood out#

Three rows in the filtered set were anomalous.

KeyLastWrite: 2025-05-20 01:47:33 UTC
LowerCaseLongPath: c:\programdata\health-mon\svchealth.exe
OriginalFileName: rundll32.exe
FileId: 00007a3f5b9c8e2d4a6f1b3c5e7d9f1a2b4c6e8d
Publisher: (empty)
LinkDate: 2015-08-14 03:22:11
BinaryType: pe64_file
Size: 487424

KeyLastWrite: 2025-05-20 01:47:34 UTC
LowerCaseLongPath: c:\programdata\health-mon\nx.exe
OriginalFileName: nx.exe
FileId: 0000d4e2c8a7f3b1e5d9c2a4f6e8b1d3c5a7f9e2
Publisher: (empty)
LinkDate: 2024-11-03 09:14:22
BinaryType: pe64_file
Size: 2,148,352

KeyLastWrite: 2025-05-20 01:51:12 UTC
LowerCaseLongPath: c:\windows\temp\enc.exe
OriginalFileName: enc.exe
FileId: 0000a1b2c3d4e5f6789012345678901234567890
Publisher: (empty)
LinkDate: 1970-01-01 00:00:00
BinaryType: pe64_file
Size: 3,891,200

A few things to note before going further.

OriginalFileName: rundll32.exe on a file at c:\programdata\health-mon\svchealth.exe is the kind of detail the Amcache exists to surface. The attacker named the file to look like a monitoring tool, but the PE version resource still says rundll32.exe, which means somebody packaged a custom binary using a Microsoft binary's version resource as a starting point. That is interesting on its own.

LinkDate: 1970-01-01 on the third entry is a giveaway. Whoever built enc.exe either did not care, or deliberately zeroed the timestamp. Both are flags.

The three KeyLastWrite values are within four minutes of each other. Either the Compatibility Appraiser ran once during that window and noticed all three files in a single scan, or they were created very close in time and an Appraiser run picked them up together. Either way: the three are related.

The SHA-1 pivot#

I stripped the 0000 prefix from each FileId and queried VirusTotal:

7a3f5b9c8e2d4a6f1b3c5e7d9f1a2b4c6e8d (svchealth.exe): 41 / 73 detections. Tagged as RemoteUtilities by multiple vendors. This is not malware in the strict sense; it is a commercial remote administration tool that ransomware affiliates routinely abuse for hands-on-keyboard access. The hash matched a known build.
d4e2c8a7f3b1e5d9c2a4f6e8b1d3c5a7f9e2 (nx.exe): 0 / 73. Unknown. No prior submission.
a1b2c3d4e5f6789012345678901234567890 (enc.exe): 64 / 73 detections. Multiple vendors tagged as Ransom:Win64/Ryuk family variants. Hash matched a recent submission from a sandbox in Eastern Europe, three days before the incident.

So: one commercial RAT, one unknown binary worth detonating, one known ransomware payload. That tells me what was probably on this host. It does not tell me anything was executed yet.

Corroborating execution#

The Amcache says these files existed. It does not say they ran. I have to go elsewhere for that.

Prefetch first. Parsed with PECmd.exe:

SVCHEALTH.EXE-A1B2C3D4.pf: present, last run 2025-05-20 01:48:02 UTC, run count 7. Definitely executed. Multiple times.
NX.EXE-E5F6789A.pf: present, last run 2025-05-20 01:55:18 UTC, run count 1. Executed once.
ENC.EXE-12345678.pf: not present.

The third file is missing from Prefetch. Two reasons that could happen on a server: Prefetch is sometimes disabled on Windows Server SKUs by default (it is on this one, I checked the EnablePrefetcher registry value, set to 0), or the file ran for less than the Prefetch threshold (unlikely for a ransomware encryptor on a file server). Server SKU explains it cleanly.

So Prefetch corroborates execution for two of three. For the third, I need Sysmon.

Sysmon (EventID 1 ProcessCreate) confirmed:

c:\programdata\health-mon\svchealth.exe: spawned multiple times, parent services.exe (installed as a service) and later cmd.exe. First seen 2025-05-20 01:46:51.
c:\programdata\health-mon\nx.exe: spawned 2025-05-20 01:55:14, parent svchealth.exe, command line included -scan 10.0.0.0/24. This is the lateral movement / reconnaissance step.
c:\windows\temp\enc.exe: spawned at 2025-05-20 02:13:47, parent svchealth.exe, command line enc.exe -p \\corp-fs-04\fileshare. That is the encryptor invocation. Matches the 02:14 incident timestamp on the backup failure.

Now I have execution for all three, plus the parent-child chain, plus the command lines. Sysmon was the artifact that closed this.

What the Amcache actually contributed#

Worth being honest about, because every artifact has a job and overclaiming dilutes the report.

The Amcache contributed:

The initial list. Without the Amcache filter pass, I would have been swimming in 21,000 entries with no obvious starting point. The user-writable-path filter narrowed to 47, the three suspect entries jumped out.
The hashes. Sysmon does include process hashes in modern configurations, but this Sysmon was older and the hash field was empty for enc.exe. The Amcache FileId gave me the SHA-1 I sent to VirusTotal, which is what unlocked the threat-intel pivot.
The hash for enc.exe after it was deleted. The encryptor was deleted from C:\Windows\Temp\ after the encryption finished (the USN journal showed the file create at 02:13:47 and the delete at 02:14:22). By 09:00 UTC when collection started, the binary was gone. The Amcache row, with its SHA-1, was still there. This is the artifact's killer feature in action.
The version-resource tell. OriginalFileName: rundll32.exe on svchealth.exe is the kind of detail that does not appear in EDR telemetry and does not appear in Prefetch. The Amcache surfaced it.

The Amcache did not contribute:

Execution evidence. Prefetch and Sysmon gave that.
The command lines. Sysmon.
The parent-child chain. Sysmon.
The lateral movement target list. Sysmon command line plus the Security log 4624/4625 events from neighbouring hosts.
The point of entry. Still under investigation as of the report; suspected RDP brute force based on Security 4625 frequency on the public-facing host that pivoted into CORP-FS-04.

If all I had was the Amcache, the report would say "three suspicious binaries were present on the host". That is not enough. With Prefetch, USN, MFT, Sysmon and the Security log, it becomes "the threat actor deployed a commercial RAT for persistence, ran network reconnaissance, and executed a known Ryuk-family encryptor against the file share at 02:13:47 UTC". The Amcache was load-bearing for the SHA-1 attribution; everything else carried the execution narrative.

The report-ready sentence#

The single sentence I built from this work, which is what executive readers actually consume:

"At 02:13:47 UTC on 20 May 2025, the threat actor executed a Ryuk-family ransomware binary (SHA-1 a1b2c3d4..., recovered from the Amcache despite post-encryption deletion of the file) against the \\corp-fs-04\fileshare UNC path, preceded by deployment of a commercial remote-access tool (RemoteUtilities, SHA-1 7a3f5b9c...) running as svchealth.exe under C:\ProgramData\health-mon\ for ~27 minutes prior."

That sentence is defensible. Every hash, path, time and tool name in it is sourced from at least two artifacts. The Amcache contributes the hashes that survive deletion; Sysmon contributes the execution and command lines; Prefetch contributes corroboration for two of three binaries; the USN journal contributes the deletion timestamp.

That is what the Amcache is for. Not a smoking gun. A reliable, deletion-resistant hash index that lets you pivot when the rest of the evidence has been actively destroyed.