How a Ransomware Attack Actually Unfolds

Ransomware is often imagined as a single catastrophic event: files encrypt, a note appears. In reality encryption is the final act of an operation that has been running for some time. Understanding the preceding stages matters, because almost all of the practical defensive opportunity sits before the encryption ever begins.

Stage one: initial access

Entry is usually unglamorous. The dominant routes are phishing, exploitation of an internet-facing service that has not been patched, valid credentials purchased or reused from earlier breaches, and remote access services exposed without strong authentication.

Increasingly, the group that breaks in is not the group that deploys the ransomware. Access brokers specialise in obtaining and selling footholds, which means the gap between compromise and encryption can be substantial — and represents time defenders can use.

Stage two: establishing and expanding

• Persistence — scheduled tasks, services, or legitimate remote-management tools installed so access survives a reboot or password change.
• Discovery — mapping the domain, file shares, backup infrastructure and which accounts hold privilege. Much of this uses built-in administrative tooling, which is why it blends in.
• Credential access — harvesting credentials from memory, from files, or by abusing weak service-account configuration.
• Privilege escalation — moving toward domain or infrastructure administrator rights, which is what makes mass deployment possible.
• Lateral movement — spreading using legitimate remote administration protocols, frequently indistinguishable from IT work without context.
• Defence evasion — disabling security tooling, clearing logs, and adding exclusions to endpoint protection.

Stage three: backups and exfiltration

Two things happen before encryption that determine how bad the outcome is.

First, backups are located and destroyed or encrypted. An organisation that can restore quickly has far less reason to pay, so attackers deliberately target backup infrastructure — which is why backup deletion is one of the highest-value alerts a defender can configure.

Second, data is exfiltrated. Double extortion has become standard: even a clean restore does not remove the threat of publication. This means "we have good backups" is a necessary but no longer sufficient answer, and it changes the regulatory picture, because exfiltration is a data breach regardless of whether encryption succeeded.

Stage four: deployment and extortion

Deployment is usually rapid and timed for maximum disruption — a weekend, a public holiday, or the early hours. Having obtained administrative control, the attacker pushes the payload broadly using the same distribution mechanisms your IT team uses.

The extortion that follows typically combines encryption, threatened publication of stolen data, and sometimes direct pressure on customers, partners or regulators. Whether to pay is a business and legal decision with no clean answer; what is clear is that payment does not guarantee usable decryption, does not remove the exfiltrated copy, and may carry legal implications depending on jurisdiction and who the recipient is.

Where defence actually works

1. Remove the common entry points: patch internet-facing services promptly, require phishing-resistant MFA on all remote access, and eliminate exposed remote desktop services.
2. Detect the middle stages, which is where the longest dwell time sits. Alert on credential dumping, mass discovery activity, security tooling being disabled, and unusual use of administrative protocols.
3. Protect backups as a priority target: keep offline or immutable copies, restrict who can delete them, and alert loudly on deletion attempts.
4. Segment the network so that domain-wide administrative reach is not the default state.
5. Monitor for large outbound transfers, since exfiltration precedes encryption and is frequently the last chance to act.
6. Test restoration under realistic conditions. An untested backup is an assumption, and recovery time is what determines business impact.
7. Rehearse the incident response plan, including the decisions — legal, regulatory and communications — that are made badly under pressure if not decided in advance.

Related from TechBiz Security

• Incident response
• SOC services
• Digital forensics

Sources & further reading

• CISA — StopRansomware
• CISA — #StopRansomware Guide
• MITRE ATT&CK
• NIST SP 800-61 — Computer Security Incident Handling Guide

Frequently asked questions