← Case studies
Disk forensics2 min readCTF, sample disk imageSample

Ransomware timeline rebuilt from NTFS artifacts

A super-timeline from the MFT, USN journal and event logs shows how the attacker got in and when encryption started.

KAPEMFTECmdPlasoChainsawT1078 Valid AccountsT1490 Inhibit System RecoveryT1486 Data Encrypted for Impact

Scenario

A file server had its documents renamed with a new extension and a ransom note in every folder. I received a disk image taken after the incident. The goals were to find the first sign of the attacker, the moment encryption started, and anything that could still be recovered.

Question to answer

Which account was used to get in, and how long did the attacker stay before encrypting?

Evidence and tools

  • fileserver.E01, forensic image of the system volume
  • KAPE to collect the key artifacts from the mounted image
  • MFTECmd to parse $MFT and the USN journal ($J)
  • Chainsaw to hunt Windows event logs with Sigma rules
  • Plaso to merge everything into one timeline

Analysis

Collect and parse

bash
# collect triage artifacts from the mounted image (drive letter F:)
$ kape.exe --tsource F: --tdest D:\case\target --target !SANS_Triage

# parse the MFT and the USN journal
$ MFTECmd.exe -f D:\case\target\F\$MFT --csv D:\case\out --csvf mft.csv
$ MFTECmd.exe -f D:\case\target\F\$Extend\$J --csv D:\case\out --csvf usn.csv

Event logs

Chainsaw flagged a burst of failed logons (event 4625) followed by a successful RDP logon (4624, logon type 10) from one external address. The account belonged to a former contractor.

bash
$ chainsaw hunt D:\case\target\F\Windows\System32\winevt\logs -s sigma/ --mapping mappings/sigma-event-logs-all.yml

File system activity

The USN journal shows thousands of rename operations within a few minutes, all from one process. A little earlier, the shadow copies were deleted.

bash
# the command seen in process creation logs just before encryption
vssadmin delete shadows /all /quiet

Timeline

  1. Day 1, 02:11Password guessingRepeated failed logons against several accounts.
  2. Day 1, 02:19Access gainedSuccessful RDP logon with the contractor account.
  3. Day 1, 02:34Tools droppedNew executables written under a temp folder.
  4. Day 2, 01:58Recovery blockedShadow copies deleted.
  5. Day 2, 02:03Encryption startsMass renames begin in the USN journal.

Findings and IOCs

Type Value Note
Account contractor.old Valid account that should have been disabled
IP 198.51.100[.]23 Source of the RDP logon (sample value)
File readme_restore.txt Ransom note dropped in each folder
Command vssadmin delete shadows /all /quiet Run before encryption

Conclusion and recommendations

The attacker used a valid but forgotten account over RDP, stayed about a day, removed recovery options and then encrypted the server.

  • Disable unused accounts and review access every quarter
  • Do not expose RDP to the internet; require a VPN and multi-factor authentication
  • Alert on shadow copy deletion
  • Keep offline backups and test restoring them

What I would do differently

I would ask for network logs from the firewall earlier. They would have shown the first connection from the external address without waiting for the event logs.

More case studies

See all →
Credential theft from a Windows workstation memory imageA 4 GB memory capture, one suspicious process, and a path from initial execution to lateral movement. Memory forensics Ransomware timeline rebuilt from NTFS artifactsA super-timeline from the MFT, USN journal and event logs shows how the attacker got in and when encryption started. Disk forensics Ransomware timeline rebuilt from NTFS artifactsA super-timeline from the MFT, USN journal and event logs shows how the attacker got in and when encryption started. Disk forensics