Anatomy of a Ransomware Attack: From Phish to Ransom Note

Forget the hoodie. Ransomware is a business.

The lone-wolf-in-a-basement image is cosplay. Modern ransomware runs like a SaaS company, because economically it is one.

Initial access brokers specialise in getting footholds and sell them on forums for a few hundred dollars a pop. Ransomware-as-a-Service groups build the malware, the negotiation portal, and the affiliate dashboard. Affiliates — the people who actually breach you — execute campaigns and take a 20–30% cut. Negotiators haggle with victims on a quarterly target. There are help-desks. There are SLAs.

I mention this because the defensive implication is brutal: you're not up against one attacker. You're up against a role-separated industry whose incentives rival legitimate software companies, and whose supply chain means any one specialist failure just gets outsourced to another specialist.

So let's walk the kill chain. One attack, five phases, and the detection that should page on-call at each step.

---

Phase 1 — Initial access: the email is not a Nigerian prince

It almost always starts with email. Not the cartoon spam of 2005. Targeted spearphishing that references real internal projects, real colleague names, real document naming conventions, all scraped from LinkedIn, GitHub, and whichever recent breach dump has your employees' inboxes in it.

The three lures I see over and over:

• An invoice or purchase order as a macro-enabled Office doc
• A DocuSign or SharePoint "you have a shared file" notification pointing to a credential harvester
• An IT help-desk impersonation asking the user to re-enroll their MFA

When one lands, the user runs a loader — historically QakBot, Emotet, IcedID, and their grandchildren — which beacons a C2 and pulls down the next stage.

What actually helps here:

• Email gateway with sandboxed attachment detonation. No detonation, no defence.
• Group Policy that disables Office macros entirely, or allows only macros signed by an internal CA. This one setting kills a huge slice of initial access.
• Phishing-resistant MFA. Passkeys or FIDO2. TOTP is better than nothing; it is also routinely harvested by modern phishing kits. If your MFA can be typed into a fake login page, it isn't phishing-resistant.

---

Phase 2 — Execution and persistence: the first thing they do is survive

Once the loader runs, a post-exploitation framework drops (Cobalt Strike and its endless forks are still the default). Priority number one is surviving a reboot and a log-off.

The persistence mechanisms I see routinely:

• Scheduled tasks pointing at a fileless payload stashed in the registry (schtasks /create …)
• Classic registry run keys under HKCU\Software\Microsoft\Windows\CurrentVersion\Run
• DLL hijacking from a writable directory that's on the system PATH
• WMI event subscriptions — harder to see, persistent across log rotation

While persistence is being set up, the attacker is already busy:

1. Enumerating local admin groups
2. Dumping credentials from LSASS (Mimikatz, or the quieter comsvcs.dll MiniDump trick)
3. Looking for EDR agent processes and idling if sandbox indicators show up

What actually helps:

• EDR with explicit memory-protection rules around LSASS access. LSASS dumping is loud if you're listening.
• Credential Guard on every workstation.
• Ship scheduled-task and run-key events to the SIEM — and alert on new ones from unexpected parents.
• Parent-child process detection. WINWORD.EXE → cmd.exe → powershell.exe is almost never legitimate. Write the rule.

---

Phase 3 — Lateral movement: one foothold becomes the whole domain

Now the attacker pivots. The targets are the ones that matter: domain controllers, backup servers, file servers, the cloud management console if they can reach it. The crown jewels, not the crown jewel-makers.

The techniques are boring and effective:

• Pass-the-Hash / Pass-the-Ticket with whatever credentials they scraped out of LSASS
• Remote service creation via PsExec or sc.exe
• SMB lateral movement to any host with an open share
• Living off the land — RDP, WinRM, WMIC, PowerShell. No malware signatures. Just admin tools being used admin-ly, by the wrong admin.

And if they land on a domain controller and get access to the KRBTGT account? Game over. Forged Kerberos tickets for any user, any service, indefinitely. That's the Golden Ticket, and it ends the engagement before you know it started.

What actually helps:

• A tiered AD model. Workstation credentials cannot authenticate to servers. Server credentials cannot authenticate to DCs. If your helpdesk account can log into your domain controller, you have no tiering.
• SMB signing enforced everywhere.
• UEBA rules for impossible-travel logons, off-hours admin auth, and the first time a given workstation account authenticates to a given server.
• Privileged Access Workstations for domain admin work. No email. No browsing. Just admin.

---

Phase 4 — Data exfiltration: encryption isn't the threat anymore, exposure is

Somewhere around 2019, every serious ransomware crew figured out that just encrypting files wasn't enough leverage — backups existed, and sometimes people had tested them. So they added a second extortion: exfiltrate first, encrypt second, threaten to publish. Now even a perfect backup restore doesn't save you from the data leak.

The exfiltration toolkit is embarrassingly mundane:

• MEGASync, rclone, or WinSCP pushing to attacker-controlled cloud storage
• DNS tunnelling for slow, low-volume exfil that slides under DLP thresholds
• HTTPS to legitimate-looking CDNs (domain fronting until the CDNs catch up)

They take whatever is regulated or reputationally ruinous: customer PII, financial records, source code, email archives, HR data. The negotiation lever is the same either way.

What actually helps:

• DLP on outbound traffic with an allow-list of sanctioned cloud destinations. Large transfers to anything off the list should not silently succeed.
• DNS filtering plus logging, with rules for DGA domains and DNS-tunnelling signatures.
• A CASB that watches sanctioned cloud storage for weird upload volume — attackers love using the infra you already blessed.

---

Phase 5 — Impact: the part you see, and the part that's already too late

The final stage is the loud one. The binary:

1. Kills backup agents, VSS writers, and database services to free file handles
2. Nukes shadow copies: vssadmin delete shadows /all /quiet
3. Encrypts target file types using a hybrid AES + RSA scheme
4. Drops the ransom note in every directory it can reach

Modern ransomware uses intermittent encryption — encrypting every other 16 bytes, say — so it finishes the whole file share in minutes instead of hours, while still rendering files useless without the key. Speed is the point.

And the classic backup trap: if the backup agent uses domain credentials, the attacker already has those credentials. If the backup server is joined to the domain, it gets encrypted along with everything else. Your backup strategy was a plan to defeat hardware failure, not a targeted adversary. Those are different problems.

What actually helps:

• Immutable backups. Object-lock / WORM cloud buckets, or genuinely air-gapped tapes, or offline copies an attacker with domain admin still cannot reach.
• Backup credentials that live outside the domain. Break-glass accounts, separate identity provider, hardware keys.
• Restore drills. Not a wiki page describing how you'd restore — an actual, timed, reviewed restore. If you've never restored, you don't have backups. You have hope.

---

Where the kill chain gets loud

Phase	Highest-signal detection
Initial Access	Office macro → child process; credential entry on a non-SSO domain
Persistence	New scheduled task or run key from an unexpected parent process
Lateral Movement	LSASS read access; anomalous remote logons; unusual admin tool use
Exfiltration	High-volume upload to consumer cloud storage; DNS-tunnelling patterns
Pre-encryption	VSS shadow-copy deletion; backup-agent termination; share enumeration at scale

The single highest-value detection in the whole kill chain is VSS deletion. By the time vssadmin delete shadows fires, you have maybe seconds to isolate hosts before encryption finishes on the file share. That rule should page on-call with no debouncing, no "investigate tomorrow." Immediate.

---

If you're reading this during an actual incident

• Isolate, don't power off. Pull hosts from the network. Leave them running. Volatile memory may contain the encryption key, and you will want that memory later.
• Preserve evidence. Memory dump and disk image before any remediation. The attacker has already compromised the environment; your job now is to preserve the forensic picture, not tidy it up.
• Rotate every credential the attacker touched. Assume compromise is transitive. Service accounts, scheduled task credentials, stored browser creds — all of it.
• Don't pay without legal and law enforcement in the room. Paying certain groups can be an OFAC sanctions violation. Call law enforcement first. Let them and counsel lead.
• Restore from verified-good backups. Verify integrity before the outage, not during.

Ransomware isn't a technology problem with a technology solution. It's people, process, and technology, and the only posture that matters is the one you built before the attacker arrived. Everything else is just expensive regret.