Domain Controller Ransomware Deployment & Threat Attribution
| Report ID | SIR-2026-06-23-05 | Classification | Simulated / Training Environment |
| Analyst | F. Nanos | Date of Report | 2026-06-23 |
| Severity | Critical | Status | Closed (Attributed) |
| Affected Asset | 1x domain controller | ||
1. Executive Summary
A ransomware deployment against a domain controller was reconstructed from a metadata-only forensic image containing NTFS system artifacts only, with no user files, registry hives, or event logs present in the acquisition. The investigation traced delivery of the ransomware payload via a public file-sharing service, a rename-then-execute evasion pattern consistent with prior stages of this incident, and file encryption across the host. Threat-actor attribution was resolved not through extension or ransom-note-format pattern matching, both of which produced plausible but incorrect candidates, but through direct submission of ransom note content to a public malware sandbox, which linked to a confirmed leak-site listing.
2. Scope & Methodology
The forensic acquisition provided for this investigation was deliberately scoped to NTFS metadata only ($MFT, $LogFile, $UsnJrnl, and related system structures), with no live system, registry, or event-log access available. This constrains the investigation to file-system artifact analysis exclusively: current file state from the Master File Table, and historical file operations (creates, renames, deletions) from the change journal, which together allow reconstruction of activity even when the underlying file content itself is unavailable.
# Image access (metadata-only .ad1 image)
# FTK Imager -> Add Evidence Item -> Image File -> export relevant artifacts
# MFT parsing
MFTECmd.exe -f "<path>\$MFT" --csv "<out>" --csvf mft_parsed.csv
# Change journal / transaction log parsing
LogFileParser64.exe /LogFileFile:"<path>" /MftCsvFile:"<mft_parsed.csv>" /OutputPath:"<out>"
# Artifact search
Select-String -Path mft_parsed.csv -Pattern "README"
Select-String -Path mft_parsed.csv -Pattern "<extension>"3. Technical Findings
3.1 Delivery
An alternate data stream associated with the initial payload archive recorded referrer and host URLs pointing to a public file-hosting service, recovering the exact external download source directly from filesystem metadata without requiring browser history or network capture data.
3.2 Evasion via Rename-Then-Execute
The original dropper, delivered under a short, generic filename, was subsequently found duplicated under a second name in a path designed to mimic legitimate IT deployment tooling. Both files shared an identical file size, and file-record timestamps placed the renamed binary's execution seconds before the first ransom note was written, establishing it as the binary that performed encryption. This masquerading pattern is consistent with prior stages of the wider incident.
3.3 Impact
A consistent ransom-note filename and file-encryption extension were identified replicated across dozens of directories throughout the host, including system and recycle-bin locations, consistent with standard ransomware behavior of maximizing note visibility to the victim.
3.4 Threat Attribution
Initial attribution attempts based on encryption-extension and ransom-note-naming-convention pattern matching against public ransomware family databases produced multiple superficially plausible candidates, none of which were confirmed correct. Attribution was ultimately resolved by submitting the literal ransom note text to a public malware analysis sandbox, which had already indexed a matching sample and linked to a confirmed dark-web leak-site listing, directly identifying the responsible group.
4. Indicators of Compromise
| Type | Indicator | Context |
|---|---|---|
| Delivery host | [redacted, public file-sharing service] | Payload archive source |
| Dropper filename | [redacted, generic short name] | Initial payload |
| Renamed binary | [redacted, disguised as IT agent tool] | Encryption executable |
| Encryption extension | [redacted] | Appended to encrypted files |
| Attributed group | [confirmed via sandbox/leak-site cross-reference] | Threat actor |
5. MITRE ATT&CK Mapping
| Technique ID | Technique | Tactic |
|---|---|---|
| T1105 | Ingress Tool Transfer | Command and Control |
| T1036.005 | Masquerading | Defense Evasion |
| T1486 | Data Encrypted for Impact | Impact |
| T1657 | Financial Theft | Impact |
| T1593 | Search Open Websites/Domains | Reconnaissance (analyst-side, attribution) |
6. Recommendations
- Block or closely monitor outbound access to public file-sharing services from privileged infrastructure such as domain controllers.
- Alert on newly created executables in paths mimicking legitimate IT/agent tooling naming conventions, particularly when file size matches a recently observed dropper.
- Ensure forensic-readiness tooling captures change-journal ($UsnJrnl) data by default, since it recovers rename and deletion events that current-state artifacts alone cannot reveal.
- Incorporate ransom-note-text sandbox submission as a standard first step in ransomware attribution workflows, rather than relying solely on extension or filename pattern matching.
7. Investigator's Notes
Threat-actor attribution was the primary point of difficulty in this investigation. Extension and ransom-note-naming-convention pattern matching against public ransomware family databases surfaced multiple structurally similar, contemporaneously active candidates, none of which proved correct on verification. Resolution required abandoning pattern matching in favor of direct evidence: submitting the literal ransom note text to a public sandbox service that had already indexed a matching sample. This is now treated as a standing lesson: when extension/filename conventions produce several plausible-but-unconfirmed candidates, that is the signal to pivot to literal-text sandbox lookup rather than continuing to guess among similarly styled families.