How Ransomware Works —
And What Developers Can Do to Stop It

The Ransomware Kill Chain

Modern ransomware attacks don't work the way movies portray — no dramatic hacking sequences, no superhuman speed. They're methodical, and they follow a predictable kill chain:

1. Initial access: Phishing email, exploitation of an unpatched vulnerability, compromised credentials via credential stuffing, or exposed RDP/VPN
2. Persistence: Malware establishes a persistent foothold — scheduled tasks, registry run keys, installed services
3. Privilege escalation: Attacker exploits local vulnerabilities or misconfigurations to gain admin or SYSTEM privileges
4. Lateral movement: Using compromised credentials or network vulnerabilities to spread to other systems
5. Data exfiltration: Sensitive data copied to attacker-controlled storage (used as double extortion leverage)
6. Ransomware deployment: Encryption payloads deployed to all accessible systems simultaneously
7. Ransom demand: Victim's screens display ransom note with payment instructions

Steps 1-5 typically happen over days or weeks. Step 6 happens in hours. By the time the encryption is visible, the attacker has been in the network for a long time.

Software Vulnerabilities as Primary Entry Points

The initial access step is where developers have the most influence. Ransomware operators regularly exploit:

• Unpatched web application vulnerabilities: SQL injection, RCE through deserialization, file upload vulnerabilities. Log4Shell was used in ransomware attacks within 48 hours of disclosure.
• Exposed management interfaces: Admin panels, database consoles, and development tools with no authentication or weak credentials exposed to the internet
• VPN and remote access vulnerabilities: Unpatched Pulse Secure, Fortinet, Citrix, and other VPN appliances have been the entry point for numerous major ransomware campaigns
• Credential theft via phishing leading to application login: Stolen credentials for web applications that then give access to internal systems

Double Extortion: Encryption Plus Data Leak Threats

Before 2019, ransomware was primarily about encryption — pay to get your files back. Since then, the dominant model has shifted to double extortion: attackers exfiltrate sensitive data before encrypting, then threaten to publish it on leak sites if the ransom isn't paid.

This changes the calculus dramatically:

• Good backups used to mean ransomware wasn't catastrophic. Now attackers threaten data publication even if you restore from backup.
• Healthcare, legal, and financial organisations face regulatory consequences for data publication even if they recover operationally.
• Customer trust damage from data publication can exceed the operational disruption of the ransomware itself.

Some groups have moved to "triple extortion" — threatening customers directly, DDoSing your infrastructure during the negotiation, and notifying your regulators.

Supply Chain Ransomware: NotPetya

NotPetya (2017) is the most damaging supply chain attack in history. Attackers compromised the update mechanism of M.E.Doc, a Ukrainian accounting software used by businesses operating in Ukraine. The malware spread through the update, then used EternalBlue and credential theft to propagate through corporate networks globally.

The damage estimate: $10 billion, affecting Maersk (shipping), FedEx (TNT), Merck (pharma), Mondelez, and hundreds more. Companies that had no connection to Ukraine were affected because their global networks included a single Ukrainian subsidiary.

The Developer's Role in Prevention

Developers aren't the last line of defence against ransomware — but they're often the first. The vulnerabilities that ransomware operators exploit are code and configuration issues that developers create and fix.

• Patch dependencies promptly: SCA scanning plus a process for expedited patching of critical CVEs. Log4Shell was exploited within 48 hours. Teams that had SCA alerts and a fast patch process were protected.
• No unauthenticated admin interfaces: Development tools (phpMyAdmin, Kibana, Jupyter) should never be publicly exposed. This is the most common "quick compromise" vector we see.
• No hardcoded credentials: Compromised credentials from leaked source code are sold and used for initial access. Every hardcoded credential is a potential ransomware entry point.
• Input validation: Prevent RCE vulnerabilities that give attackers a foothold in your applications
• Least privilege: Even if an attacker gains access to your application, they shouldn't be able to reach the entire internal network from it

Backup Strategies That Actually Survive Ransomware

Ransomware operators know backup strategies. They specifically target backup systems before deploying encryption. An effective backup strategy must account for this:

• Offline backups: At least one copy that is physically disconnected from the network — or in a separate, isolated cloud account. Ransomware can't encrypt what it can't reach.
• Immutable backups: Write-once storage (AWS S3 Object Lock, Azure Immutable Storage) prevents ransomware from encrypting or deleting backup objects even with valid credentials
• Regular restore testing: Backups you've never tested restoring are unreliable. Schedule quarterly restore drills.
• Separate credential management: Backup credentials should not be accessible from production systems. If production is compromised, the backup system shouldn't be automatically accessible.

Detection: What to Look For

Ransomware is often detectable before the encryption phase if you're monitoring for the right signals:

• Unusual volume of file reads — lateral movement and data exfiltration phase
• Large outbound data transfers — exfiltration before encryption
• Shadow copy deletion commands (vssadmin delete shadows) — attackers destroy backups before encrypting
• Unusual service creation or scheduled tasks — persistence mechanisms
• Credential access tool signatures (Mimikatz, etc.) — privilege escalation phase

Incident Response Playbook

1. Isolate affected systems immediately — disconnect from network to stop lateral spread. Yes, this means downtime. It limits the blast radius.
2. Activate incident response team — engage incident response retainer if you have one. If not, CISA provides free ransomware guidance.
3. Identify patient zero — which system was first compromised? This identifies the entry point to close.
4. Preserve forensic evidence — before rebuilding, image affected systems for forensic analysis. You'll need this for the post-incident report and insurance claim.
5. Notify stakeholders — legal, PR, regulatory bodies as appropriate. Early notification is almost always better than delayed notification.
6. Restore from clean backups — into an isolated, clean environment. Don't restore into the same infected network.
7. Close the entry point — the patched vulnerability, revoked credentials, or fixed misconfiguration that gave initial access.

The Math: Why Paying Rarely Works

The FBI and CISA officially advise against paying ransoms. The practical arguments against:

• No guarantee of decryption: About 20-30% of organisations that pay do not receive working decryption keys. They pay and still lose their data.
• Marks you as a payer: Paying signals you're willing to pay. Threat actors share target lists. Being a payer increases your risk of future attacks from the same or different groups.
• Legal risk: Paying ransoms to sanctioned entities (some ransomware groups are on OFAC sanction lists) can expose companies to regulatory penalties.
• Data published anyway: Even after paying, data sometimes gets published — by a different faction of the same group, or because the stolen data was already sold.