The Black Friday That Broke a City's Rail System
"You Hacked, ALL Data Encrypted. Contact For Key (cryptom27@yandex.com) ID:681, Enter."
Handwritten "Out of Service" signs go up on ticket machines. Fare gates swing open. Nearly 2,000 of 8,000 SFMTA computers are locked. Bus drivers get their routes on paper. And for one long weekend, 700,000 daily riders on the busiest transit network west of the Mississippi ride entirely for free — not as a holiday gift, but because a ransomware strain called Mamba has just held an entire municipality hostage.
This is the story of the SFMTA ransomware attack of November 2016 — one of the most public ransomware incidents ever recorded against critical infrastructure. It's also, remarkably, a story with a happy ending: the transit agency refused to pay a single Bitcoin, restored its own systems, and the attacker himself was hacked by a security researcher within days. This tutorial breaks down exactly what happened, how the malware worked, and every defensive lesson that came out of it.
The Muni attack was a preview of every major ransomware incident since — Colonial Pipeline (2021), the Irish HSE health service (2021), London Transport (2024). The exact techniques used against SFMTA — legitimate open-source tools weaponised, unpatched public-facing servers, no network segmentation — remain the top three attack vectors on critical infrastructure a decade later. Understanding SFMTA is understanding the modern threat.
Ransomware 101 — The Business Model Behind the Attack
Before dissecting the SFMTA case, understand the weapon. Ransomware is not a virus in the classical sense — it is a business model that happens to run on malware. The economics are simple: encrypt files the victim cannot afford to lose, demand payment in a currency that cannot be traced, and disappear.
The FBI has, at times, quietly acknowledged that when good backups do not exist, paying is the only path to recovery — even though official guidance discourages it. This is why backups are not an IT nicety — they are the single most important cybersecurity control. SFMTA survived precisely because they had them.
Meet the Weapon — Mamba / HDDCryptor
The malware family behind the SFMTA attack goes by two names: HDDCryptor and Mamba. It first appeared in early 2016 and was publicly documented by Trend Micro that September — just two months before Muni was hit. What made it dangerous was not novel cryptography but its audacious reuse of legitimate tools.
That is Mamba. It does not ship with custom encryption code. It bundles DiskCryptor, a legitimate open-source full-disk encryption tool that thousands of privacy-conscious users install voluntarily. The attacker weaponises the tool, encrypts the victim's disk with a key only he knows, then walks away.
Why this matters: antivirus software has a hard time flagging DiskCryptor as malicious, because in most contexts it isn't.
Mamba's Signature Behaviours
Mamba pioneered a technique now dominant in ransomware: living off the land. Instead of custom malware that antivirus engines can fingerprint, the attackers use tools that are already trusted or ship with Windows — PsExec, DiskCryptor, certutil, PowerShell. The malware is essentially a script that orchestrates legitimate binaries. Every major ransomware family since — Ryuk, Conti, LockBit — uses variations of this playbook.
Attack Timeline — Hour by Hour
Deconstructing the Attack Chain
Every ransomware breach follows a recognisable path — reconnaissance, entry, escalation, lateral movement, impact. Mapping SFMTA onto the standard MITRE ATT&CK chain shows exactly where a defender could have broken the attack at seven different points.
| Phase | What The Attacker Did | Where SFMTA Could Have Stopped It |
|---|---|---|
| Reconnaissance | Scanned the internet for exposed Windows servers and unpatched Oracle WebLogic instances. | Asset inventory + attack surface management. You cannot defend what you don't know is exposed. |
| Initial Access | Exploited a public-facing Windows 2000 / Oracle WebLogic server, or delivered via a torrent to an admin. | Patch management + no admin browsing on production networks. |
| Execution | Dropped DiskCryptor + scheduled task to run the encryption binary. | Application allow-listing would have blocked the unsigned installer. |
| Privilege Escalation | Used the compromised server's already-elevated context; no exploit needed. | Principle of least privilege. Public servers should not have domain admin rights. |
| Lateral Movement | PsExec across a flat internal network to ~2,000 hosts. | Network segmentation. VLANs. Deny-by-default east-west traffic. |
| Defence Evasion | Used legitimate signed tools (DiskCryptor, PsExec) that antivirus won't flag. | EDR (Endpoint Detection & Response) that flags behaviour, not signatures. |
| Impact | Encrypted MBR + full disks on 2,000 machines. Threatened data leak. | Offline immutable backups. This is what saved SFMTA. Full stop. |
The Two Entry-Point Theories
Nearly a decade later, the exact initial entry vector is still debated. Two credible theories exist, and understanding both is instructive because they map onto the two most common ransomware entry points to this day.
| Element | Detail |
|---|---|
| Target | Oracle WebLogic |
| Flaw type | Java deserialization |
| Age of bug | Publicly known, patched |
| Skill needed | Low — public exploit |
| Detection? | Only with WAF / IDS |
| Fix | Apply Oracle patch |
| Element | Detail |
|---|---|
| Target | Admin's workstation |
| Flaw type | Human — pirated software |
| Age of bug | N/A — social |
| Skill needed | Low — seed torrent |
| Detection? | Nearly impossible |
| Fix | Policy + user training |
Whether it was the unpatched server or the pirated software, both scenarios share one root cause: a single point of failure was allowed to talk to 2,000 other machines. The initial infection would have been contained to one host if SFMTA had segmented its network. This is the enduring lesson of Muni — it was not the entry vector that made this disaster, it was the flat network.
The Ransom Note — What The Attacker Actually Sent
Journalists at the San Francisco Examiner and security researcher Brian Krebs later obtained copies of the direct communication between the attacker and SFMTA. The note itself is a case study in ransomware psychology — technical bravado mixed with broken English, designed to convince the victim that resistance is futile.
# Message sent from cryptom27@yandex.com to Sean Cunningham,
# SFMTA infrastructure manager, evening of Friday, Nov 25, 2016.
# Signed: "Andy Saolis"
FROM: cryptom27@yandex.com
TO: scunningham@sfmta.com
SUBJ: Hacked
All Your Computer's/Server's in MUNI-RAILWAY Domain
Encrypted By AES 2048Bit!
We have 2000 Decryption Key !
Send 100 BTC to My Bitcoin Wallet ,
then We Send you Decryption key For Your All Server's HDD!!
# Later follow-up message, after SFMTA went public:
Company don't pay attention to Your safety!
They give your money and everyday rich more!
But they don't pay for IT security and using very old systems!
SFMTA network was Very Open and 2000 Server/PC infected by software!Broken English is common in ransom notes not because criminals cannot write, but because it obscures attribution. It could be a non-native speaker; it could be a native speaker faking one; it could be machine translation. Attributing this attack to any nation or specific person is exactly what the attacker wants you not to be able to do.
What SFMTA Did Right — The Defensive Playbook
For all the criticism of SFMTA's security posture (and there is plenty), the agency's response was textbook. It is genuinely worth studying as a positive case, because most public sector organisations hit by ransomware have handled it far worse.
The Twist — The Hacker Gets Hacked
Inside were months of ransomware negotiations with dozens of other victims. Bitcoin wallets. Server credentials. A second email address (w889901665@yandex.com) tied to earlier campaigns. And crucially: proof that the SFMTA attack was not targeted — Muni was simply one of thousands of internet-facing servers the attacker had opportunistically compromised.
Krebs published the story on November 29, four days after the attack began.
| What Was Exposed | Detail Recovered From The Attacker's Mailbox |
|---|---|
| Other victims | At least a dozen organisations, including a US manufacturing firm that had paid 63 BTC (~$45,000) on Nov 20 — five days before Muni. |
| Total earnings | Krebs' source estimated at least $140,000 in Bitcoin extorted over the preceding months. |
| Attack methodology | Non-targeted. The attacker mass-scanned the internet for exposed servers, exploited them opportunistically. |
| Attacker's location | Investigative clues pointed to Iran — the attacker was tied to open-source projects and forum activity by an Iranian developer. |
| Infrastructure | Plain-text credentials for hosting providers used in the attack were sitting in the mailbox. |
The attacker used weak security questions on his own Yandex account — the exact same mistake his victims made. This is not coincidence. Ransomware operators are not necessarily elite hackers. They are operators of a business model, using tooling built by more skilled developers. Weak opsec cuts both ways.
The Financial and Operational Impact
Compared to modern ransomware losses running into the hundreds of millions, SFMTA got off remarkably light. But the incident still caused meaningful damage — most of it invisible to the public.
SFMTA's operational technology (train signalling, safety systems) was never touched, but for 72 hours the public watched a major American city transit agency locked out of its own computers by a foreign ransomware operator. That image — followed by copycat attacks on Fort Worth transit, Philadelphia's SEPTA, and Martha's Vineyard's Steamship Authority — reshaped US infrastructure cyber policy for the next decade.
Practical Example — Detecting Mamba-Style Behaviour
A modern SOC (Security Operations Centre) would spot Mamba's behavioural fingerprints before disk encryption completes. The malware's use of legitimate tools is a defence and a tell — DiskCryptor is not commonly installed on typical corporate workstations, so its appearance is itself an indicator of compromise.
Indicators of Compromise (IoCs) for Mamba / HDDCryptor
# === File System Indicators ===
FOLDER: C:\DC22\ # DiskCryptor install path
FOLDER: C:\xampp\http\ # Staging directory
FILE: myConf.txt # Encryption config (key + reboot delay)
FILE: dcapi.dll # Modified DiskCryptor API module
FILE: dcinst.exe # DiskCryptor installer
# === Windows Service Indicators ===
SERVICE: DefragmentService # Malicious service name
RUN AS: LocalSystem # Executes as SYSTEM
# === Network Indicators (2016 campaign) ===
EMAIL: cryptom27@yandex.com # Ransom contact (SFMTA)
EMAIL: w889901665@yandex.com # Earlier campaigns
EMAIL: cryptom2016@yandex.com # Hosting provider comms
# === Behavioural Indicators (higher fidelity) ===
EVENT: PsExec.exe execution against >5 hosts in <5 minutes
EVENT: Scheduled task creation with SYSTEM context on multiple hosts
EVENT: New Windows service registered pointing to unsigned binary
EVENT: Any process writing to sector 0 of \\.\PhysicalDrive0
EVENT: Unexpected reboot within 5 minutes of scheduled task creationYARA Rule — Detecting the DiskCryptor Abuse Pattern
// A minimal YARA rule that flags binaries bundled with DiskCryptor components.
// Real production rules go deeper into imphash and PE anomalies.
rule HDDCryptor_Mamba_Indicators
{
meta:
author = "SOC analyst"
description = "Detects HDDCryptor / Mamba DiskCryptor abuse"
reference = "SFMTA incident, November 2016"
strings:
$dc1 = "C:\\DC22\\" ascii wide
$dc2 = "dcapi.dll" ascii wide
$dc3 = "dcinst.exe" ascii wide
$svc = "DefragmentService" ascii wide
$cfg = "myConf.txt" ascii wide
$note = "You Hacked, ALL Data Encrypted" ascii wide
condition:
2 of ($dc*) or $svc or $cfg or $note
}Any process on a corporate endpoint touching the Master Boot Record is a P1 incident. There is no legitimate business reason for user-space software to write to \\.\PhysicalDrive0 sector 0. Modern EDR tooling (CrowdStrike, SentinelOne, Microsoft Defender for Endpoint) alerts on this by default — but you must have it deployed before the attack.
Defence Configuration — What SFMTA Should Have Had
This section walks through the specific configuration changes that would have prevented, contained, or drastically limited the SFMTA attack. Each maps to a concrete control any defender can implement today.
1. Disable PsExec Lateral Movement
# PowerShell / Group Policy: block PsExec on workstations that don't need it.
# SMB port 445 is Mamba's spread mechanism; deny east-west by default.
# Windows Firewall rule — block inbound SMB from workstation ranges:
New-NetFirewallRule -DisplayName "Block-SMB-East-West" `
-Direction Inbound -Protocol TCP -LocalPort 445 `
-RemoteAddress "10.0.0.0/8" -Action Block
# Registry: prevent PsExec-style admin$ pipe abuse from non-domain-controllers:
Set-ItemProperty -Path "HKLM:\SYSTEM\CurrentControlSet\Services\LanmanServer\Parameters" `
-Name "AutoShareWks" -Value 02. Enable Application Allow-Listing (WDAC)
# Windows Defender Application Control policy fragment.
# Only signed, approved binaries may execute. DiskCryptor is not on the list.
<SiPolicy>
<Rules>
<Rule>
<Option>Enabled:Unsigned System Integrity Policy</Option>
</Rule>
<Rule>
<Option>Required:Enforce Store Applications</Option>
</Rule>
</Rules>
<!-- Only allow binaries signed by Microsoft or the org's cert. -->
</SiPolicy>3. Network Segmentation — VLAN by Function
# Conceptual segmentation. SFMTA had one flat network. Should have looked like:
VLAN 10 — Ticketing kiosks # public-facing, isolated
VLAN 20 — Station terminals # staff, restricted access
VLAN 30 — Corporate workstations # email, office work
VLAN 40 — Domain controllers # heavily restricted
VLAN 50 — Operational Technology # signalling, train control — air-gapped
VLAN 99 — Management # jump hosts only, MFA required
# Deny-by-default east-west traffic between all VLANs.
# Explicit allow rules for necessary flows only, logged at both ends.4. The 3-2-1 Backup Rule (What Saved SFMTA)
Similar Cases — The Muni Playbook Repeated
SFMTA was neither the first nor the last public infrastructure ransomware victim. Studying the sequence reveals a pattern: every case shares two or more of the same root causes SFMTA had.
| Year | Victim | Ransomware | Paid? | Root Cause Shared With SFMTA |
|---|---|---|---|---|
| Feb 2016 | Hollywood Presbyterian Hospital, LA | Locky | Yes — $17,000 | Flat network, weak email filtering |
| Apr 2016 | Lansing Board of Water & Light, MI | Unnamed | Yes — $25,000 | No offline backups |
| Nov 2016 | SFMTA / Muni, San Francisco | Mamba / HDDCryptor | No — refused | Unpatched WebLogic + flat network |
| May 2017 | UK NHS + 200,000 machines globally | WannaCry | Mostly no | Unpatched SMBv1 (EternalBlue) |
| Mar 2018 | City of Atlanta | SamSam | No — refused | Weak RDP credentials, no MFA |
| May 2021 | Colonial Pipeline, USA | DarkSide | Yes — $4.4M (part recovered) | Compromised VPN account, no MFA |
| May 2021 | Irish Health Service (HSE) | Conti | No — refused | Phishing entry + flat network |
| Jun 2021 | New York MTA | Unattributed (China-linked) | — | Unpatched Pulse Secure VPN |
A decade of attacks and the top three root causes remain: unpatched internet-facing services, flat internal networks, and weak or missing multi-factor authentication. If you fix only three things after reading this tutorial, fix those three.
Newspaper & Reference Coverage of the Attack
The SFMTA case is unusually well-documented because it was so publicly visible. Below is a curated list of the primary sources — useful for anyone building on this case study for academic work or professional briefings.
| Publication | Date | Contribution |
|---|---|---|
| San Francisco Examiner | Nov 26, 2016 | First reporter on the ground. Photographed the "Out of Service" signs. Broke the direct-quote email correspondence with the attacker. |
| Forbes (Thomas Brewster) | Nov 28, 2016 | Documented the ransom amount (100 BTC ≈ $70,000) and got the attacker's follow-up interview quotes. |
| CBC News | Nov 28, 2016 | Muni spokesperson Paul Rose on record: "The SFMTA has never considered paying the ransom." |
| BBC News | Nov 28, 2016 | Confirmed no impact to transit service, safety systems, or customer information. |
| MIT Technology Review | Nov 28, 2016 | Contextualised alongside the Hollywood Presbyterian Hospital ransomware case earlier that year. |
| Krebs on Security | Nov 29, 2016 | The pivotal report. Brian Krebs revealed the attacker's inbox had itself been hacked, exposing prior victims and total earnings of at least $140,000. |
| Trend Micro Research | Dec 2016 | Technical analysis of HDDCryptor / Mamba — DiskCryptor abuse, MBR overwrite, PsExec spread. |
| SecurityWeek (Ionut Arghire) | Dec 6, 2016 | Documented Fortinet's Oracle WebLogic entry-point theory. |
| Kaspersky Lab (SecureList) | 2017 | Long-term tracking of Mamba operators as they resurfaced in Brazil and Saudi Arabia. |
| FBI FLASH Alert MI-000148-MW | Mar 2021 | Federal Bureau of Investigation IOC bulletin on Mamba — five years after the SFMTA hit, the family was still active. |
Golden Rules — The SFMTA Lessons in Seven Lines
The San Francisco Muni attack ended well — no data lost, no ransom paid, no passengers stranded, and the attacker publicly embarrassed within a week. It is one of the very few ransomware cases with a genuinely positive ending. That outcome was not luck. It was the product of good backups, a refusal to negotiate, and a willingness to be transparent. Every organisation defending critical infrastructure should aspire to the SFMTA response — while learning from the mistakes that got them into the crisis in the first place.