AoTR 3: The Abandoned Farmhouse

Scenario

This Sherlock demonstrates an encrypted root partition with an associated hibernation swap. The swap can be pattern-matched to reveal the AES encryption key, granting access to the filesystem. Further examination of the filesystem reveals corruption, necessitating manual file recovery through selective matching in order to extract the relevant data.

Executive Summary

The image was an encrypted Linux laptop with a LUKS2 root partition and a hibernation swap partition. The swap held a copy of RAM from the moment of hibernation, including the expanded AES key schedule of the unlocked volume, so scanning it for key-schedule patterns recovered the master key without a passphrase. With the volume decrypted, the filesystem turned out to be damaged and the share directory had been deleted, so Samba logs and configuration fragments were read directly and the planning documents were carved out by file signature. The documents describe a staged theft operation: a modified drone, a code word to start it, a fixed execution time and the city where the crew would wait.

Artifacts

• Disk image: hibernal.E01 → ewfinfo for acquisition metadata, ewfmount to expose the raw disk
• Partitions: the raw disk split with dd into the LUKS2 root (p5.img) and the swap (swap.img)

Note: Work on dd copies of the partitions, not on the mounted image.

Discovery

The E01 container stores the case number in its acquisition metadata, so ewfinfo answers it without mounting anything.

ewfinfo hibernal.E01

Mount the E01 with ewfmount, dd the partitions out of the raw disk and run luksDump on the encrypted one. The header prints the version directly.

cryptsetup luksDump work/p5.img

Credential Access

The swap partition is a hibernation image, so it contains the kernel’s memory, including the expanded AES-256 key schedule that dm-crypt keeps resident. No aeskeyfind was available, so I wrote a small C scanner that tests every byte offset of swap.img for a consistent AES-256 key schedule. The scan has to step by single bytes: an aligned 8-byte step missed the key. One pair at offset 1209041602 (plus 466) turned up three times in the image. An XTS master key is two 32-byte keys, and the pair came out with the tweak and data halves swapped, so the master key is the second half followed by the first. Decrypting p5.img with that order produced a valid LVM volume, which confirms it.

cryptsetup open --master-key-file mk.bin work/p5.img hibernal

python3 -I xts_decrypt.py p5.img root.img  # AES-XTS, key = second || first of the scanned pair

Gotcha: The key schedule pair is not in the order dm-crypt expects. If decryption yields noise, swap the two 32-byte halves before concluding the key is wrong.

Lateral Movement

Inside the decrypted LVM volume, dd the root logical volume out (physical extents start at 1 MiB) and list it with debugfs. /var/log/samba holds one log.<client> file per connecting host, and the last client’s file is named after its address. A string search of the swap for 10.129.234. also finds the same client in a socket string (ipv4:...:49844), which corroborates the file name. This was matched on the Samba log name plus the swap string rather than an explicit “last connection” timestamp, so it is the most reasoned of the answers.

debugfs -R 'ls /var/log/samba' lvroot.img

strings -a swap.img | grep -E '10\.129\.234\.[0-9]+'

The filesystem is corrupted. Searching the raw volume for path = lines finds a share definition fragment pointing at /home/driver_bud/share, and the bracketed name above it is the share.

strings lvroot.img | grep -B3 'path = /home/driver_bud'

Collection

The share directory had been deleted and the filesystem was corrupted, so the files had to be recovered by signature. Scan lvroot.img for PDF magic at 4096-byte alignment and dd out each hit. pdftotext -layout on the carved “Operation Winter Blackout” PDF gives a total estimated value line.

python3 -I carve.py lvroot.img work/carved/

pdftotext -layout work/carved/*.pdf - | grep -i 'total estimated value'

Tip: The answer wants digits only, so drop the currency symbol and thousands separators from the document’s figure.

The technical specification section of the same PDF names the airframe and marks it as modified for the operation.

pdftotext -layout work/carved/*.pdf - | grep -i matrice

Gotcha: The document writes the full model with an RTK suffix, but the accepted answer stops at the model number, with the DJI prefix kept.

The emergency protocols PDF lists code words; the one designated to start the attack is the answer.

pdftotext -layout work/carved/*.pdf - | grep -i -A2 'code word'

The same emergency protocols document gives the scheduled execution time, to the second.

pdftotext -layout work/carved/*.pdf - | grep -E '[0-9]{2}:[0-9]{2}:[0-9]{2}'

The planning PDF states where the core crew is positioned on New Year’s Eve.

pdftotext -layout work/carved/*.pdf - | grep -i -B1 -A2 'core crew'

Attack Summary

Phase	Action
Planning	Operation documents (value of targets, modified drone, code word, execution time, crew city) written and stored in a Samba share
Collection	Share served from /home/driver_bud/share to SMB clients
Cleanup	Share files deleted from the filesystem
Exposure	Host hibernated, leaving the key schedule in swap

IOCs

Type	Value
Case number	K-122/2025
Last SMB client	10.129.234[.]0
SMB share	GOSPODSKI (/home/driver_bud/share)
Image	hibernal.E01

MITRE ATT&CK

Technique	ID	Description
OS Credential Dumping	T1003	Master key recovered from key material left in the hibernation image (analyst technique)
Remote Services: SMB/Windows Admin Shares	T1021.002	Documents served and accessed over a Samba share
Data from Network Shared Drive	T1039	Planning documents held on the share
Data from Local System	T1005	Heist documents stored on the laptop
Indicator Removal: File Deletion	T1070.004	Share contents deleted, forcing signature carving

Defender Takeaways

Hibernation swap defeats full-disk encryption. A hibernation image writes RAM, including the live AES key schedule, to an unencrypted or weakly protected swap. Encrypt swap with a key that is not recoverable from the same disk, or disable hibernation on encrypted laptops.

Samba logs outlive deleted shares. The per-client files in /var/log/samba still named the connecting host after the share contents were gone. Ship them off the host so a deletion cannot erase the access history.

Deleting files is not removing them. The planning PDFs survived in unallocated space and were carved by signature. Wipe or encrypt sensitive shares at the file level, and treat damaged filesystems as recoverable, not lost.

Keep sensitive operational documents off shared folders. The code word, time and location sat together in a handful of PDFs on a share. Splitting such material and restricting access limits what a single image reveals.

Conclusion

Full-disk encryption protected nothing once the machine had hibernated: the key schedule sat in swap, and the deleted planning documents came out of the decrypted volume by signature carving. The disk gave up the whole operation without a single password.