What Happens During a Ransomware Attack?
The timeline of a ransomware incident and what your response plan should cover.
A ransomware attack typically unfolds in six phases: the attacker gains initial access, dwells quietly in your network, moves laterally to gain control, steals sensitive data, detonates encryption across servers and endpoints, and finally presents a ransom note — often with a threat to leak the stolen data. The visible chaos at the end is usually the shortest phase of the entire incident.
Understanding that timeline matters because almost every decision you make during an incident — when to isolate, who to call, whether recovery takes days or weeks — depends on which phase you're actually in. This walkthrough covers what happens operationally at each stage: what your IT team sees, what breaks, and where you still have room to act.
Days–weeks
Typical dwell time between initial access and detonation, per industry incident reporting
Hours
How fast encryption spreads once the attacker pulls the trigger — often overnight or on a weekend
Days–weeks
Realistic full recovery window, even with good backups and a rehearsed plan
Phase 1: Initial access
Every ransomware incident starts with a foothold. The most common entry points are depressingly ordinary: a phishing email that captures credentials or drops a loader, an exposed remote desktop or VPN gateway with weak authentication, an unpatched vulnerability on an internet-facing system, or credentials bought from an access broker who compromised you months earlier.
Operationally, this phase is nearly invisible. There's no alarm bell — just a successful login that looks legitimate, or a small payload running under a user's context. This is why patching internet-facing vulnerabilities quickly and enforcing MFA on every remote access path matter so much: they close the doors attackers actually use.
What IT might see, if looking closely: a login from an unusual location or impossible travel pattern, a new service or scheduled task on one machine, or endpoint detection flagging a script interpreter doing something odd. Mature endpoint tooling catches a meaningful share of intrusions here — our comparison of EDR, MDR and traditional antivirus explains which layer watches for what.
Phase 2: Dwell time
After the initial foothold, professional ransomware operators don't rush. They establish persistence — additional accounts, remote access tools, scheduled tasks — so losing one foothold doesn't evict them. They map the domain, enumerate shares, identify backup infrastructure, and locate the systems that would hurt most to lose: file servers, line-of-business applications, domain controllers, hypervisors.
Industry incident reports commonly describe dwell times ranging from days to several weeks, and the trend in recent reporting has been toward shorter dwell times as defenders improve — but even a weekend of quiet access is enough for an operator to map a 50-person network completely. During this phase, your environment still works normally. Users notice nothing. The only signals live in authentication logs, EDR telemetry, and network traffic — which is why detection capability, not just prevention, determines how bad the eventual incident gets.
Phase 3: Lateral movement and privilege escalation
The attacker's goal here is domain dominance. Using harvested credentials, pass-the-hash techniques, or abuse of legitimate admin tools, they move from the initial machine to servers and domain controllers. A telling characteristic of modern ransomware operations is how much of this uses your own tooling — PowerShell, PsExec, remote desktop, your RMM platform — which makes malicious activity blend into normal administration.
What IT sees at this stage, if anyone is watching: service accounts logging into machines they never touch, admin tools executing at odd hours, new domain admin accounts appearing, or group policy objects being modified. Flat networks make this phase fast; segmented networks with tiered admin credentials slow it down and create more chances to catch it.
Critically, this is when attackers locate and neutralize your defenses: disabling endpoint agents where they have sufficient privileges, deleting volume shadow copies, and — most importantly — finding your backups. Whether your backups survive the incident is usually decided here, before a single file is encrypted. The design principles in endpoint backup versus server backup cover how isolation and immutability change this outcome.
Phase 4: Data exfiltration
Modern ransomware is almost always double extortion: steal first, encrypt second. Attackers identify valuable data — financial records, HR files, customer data, contracts, email archives — and quietly copy it out to cloud storage or attacker-controlled infrastructure. Exfiltration of hundreds of gigabytes can take days and often blends into normal outbound traffic.
What IT might see: unusually large outbound transfers, especially to consumer cloud storage or unfamiliar destinations, or archive utilities compressing directories on servers. This phase has a permanent consequence: even if you restore everything from backup and never pay, the stolen data is already gone. The encryption is, in a sense, the second threat — the first one already happened.
Phase 5: Detonation — encryption across the network
Detonation is usually scheduled for maximum disruption: late Friday night, a holiday weekend, the start of your busiest season. The attacker pushes the encryptor to as many systems as possible at once — often via group policy, PsExec, or your own management tooling — and within hours, file servers fill with encrypted files, databases won't mount, hypervisors lose their virtual machines, and endpoints reboot into ransom notes.
What breaks, roughly in the order you'll notice: shared drives become inaccessible, applications fail because their databases or files are encrypted, authentication can degrade if domain controllers are hit, and phone calls start coming in from users who can't work. If your backup infrastructure was reachable with domain credentials, you may discover in this same hour that your backups were encrypted or deleted too.
Phase 6: The ransom note and extortion
The note itself is a business document: a demand amount, a Tor link to a negotiation portal, a deadline, and proof that your data was stolen — sometimes with a sample posted to a leak site. Threats escalate on a schedule: publish the data, contact your customers, or alert regulators and the press.
This is the moment the incident stops being an IT problem and becomes a company-level crisis. Legal counsel needs to assess notification obligations. Your cyber insurer needs to be engaged — most policies require it before any negotiation, and many provide breach coaches and negotiators. Leadership owns the pay-or-don't-pay decision. Everything after this point runs on the incident response plan you either have or don't.
The attack timeline at a glance
| Phase | Typical duration | What you observe | Your leverage |
|---|---|---|---|
| Initial access | Minutes | Almost nothing — a plausible login | Prevention: MFA, patching, email filtering |
| Dwell time | Days to weeks | Subtle log and EDR anomalies | Detection: monitoring, alerting, hunting |
| Lateral movement | Hours to days | Odd admin activity, new accounts | Containment: segmentation, tiered admin |
| Exfiltration | Days | Large outbound transfers | Egress filtering, DLP alerts |
| Detonation | Hours | Everything breaks at once | Response: isolate, activate the plan |
| Extortion | Days to weeks | Ransom note, leak threats | Leadership, counsel, insurer decisions |
The first 60 minutes after discovery
What you do in the first hour shapes the next several weeks. The priorities, in order:
Isolate, don't power off. Disconnect affected systems from the network — unplug cables, disable switch ports, isolate VLANs. Leave machines running where possible: volatile memory holds evidence, and some encryptors resume on reboot. For a fast-moving encryption event, it is better to take a segment offline than to lose the whole network.
Protect identity. Disable compromised accounts and force password resets for privileged accounts. Assume domain admin credentials are exposed until proven otherwise — this constrains how you rebuild later.
Activate the call tree. Notify leadership, your IT team or MSP, legal counsel, and your cyber insurer — in that rough order, and through out-of-band channels. Don't use company email or chat to coordinate; assume the attacker can read them.
Preserve evidence. Capture the ransom note, log which systems are affected and when they were discovered, and image key systems before rebuilding. Your insurer, counsel, and any forensics firm will need this — and regulators may too.
Verify your backups before touching them. Confirm backups exist, are isolated from the compromised environment, and predate the intrusion. Do not connect backup infrastructure to a network you haven't cleaned.
The pay-or-don't-pay decision
There is no universally right answer, and anyone who gives you one without knowing your situation is guessing. What can be said defensibly:
- Payment does not guarantee a working decryptor, and decryption with an attacker-supplied tool is often slow and imperfect — organizations that pay frequently still face a long rebuild.
- Payment does not guarantee deletion of stolen data. Leak-site postings after payment are well documented in incident reporting.
- Depending on the attacker's identity, payment can create sanctions exposure. In the U.S., OFAC has advised that facilitating ransom payments to sanctioned entities may violate regulations — one more reason counsel and your insurer must be in the room.
- Many cyber insurance policies cover negotiation and payment under specific conditions, but require the insurer's involvement before you engage the attacker at all.
Frame it correctly: this is a business continuity and legal risk decision made by leadership with professional advice — not an IT decision, and not one to improvise at 3 a.m. Deciding your organization's default posture in advance, as part of your incident response plan, is far easier than debating it mid-crisis.
Recovery realities
Recovery is slower than anyone expects the first time. A realistic sequence: confirm the attacker is out (eradication), rebuild identity infrastructure from a known-clean state, restore systems in priority order from verified backups, then validate data integrity and bring business functions back online. For a small company with good, tested backups, core operations returning within several days to two weeks is a reasonable expectation. Without usable backups, or with a compromised Active Directory, full recovery measured in weeks is common in incident reporting.
The variables that dominate recovery time are unglamorous: whether backups were isolated and recent, whether you know your rebuild order, whether clean installation media and credentials exist offline, and whether anyone has ever actually performed a test restore. Recovery speed is purchased in advance, not during the incident.
This is also where the broader program matters. Companies that fare best treat response as one layer of a complete posture — the priorities in our cybersecurity checklist for a 50-person company map directly onto the phases above.
"The ransom note is not the beginning of the incident — it's the attacker telling you the incident is almost over. Every phase before it was a chance to detect, contain, or recover cheaply."
Key takeaway: invest in detection and tested recovery, because by the time encryption starts, your remaining options are all expensive.
What your response plan must cover
Walking the timeline above backward gives you the requirements for a response plan. At minimum, it needs: a declaration threshold (who decides this is an incident, and when), isolation procedures for your specific network, a call tree with current after-hours contacts for leadership, IT, MSP, counsel and insurer, evidence preservation steps, a backup verification and restore procedure that's been tested, a communication plan for staff and customers, and a predefined leadership posture on ransom payment.
Our step-by-step guide on how to build an incident response plan turns each of those requirements into a concrete, maintainable document — including the one-page version a small team can actually keep current. You can also baseline your overall readiness with our security score calculator.
Frequently asked questions
How long does a ransomware attack take from start to finish?
The visible part — encryption and the ransom note — often completes in hours. The invisible part is longer: industry incident reports commonly describe attackers spending days to weeks inside a network between initial access and detonation, stealing data and positioning for maximum impact. Total recovery, including restore, rebuild and business normalization, frequently runs from several days to several weeks.
Should we ever pay the ransom?
There is no universally right answer, and the decision belongs to leadership with legal counsel and your cyber insurer involved. Payment does not guarantee a working decryptor or deletion of stolen data, it may create sanctions exposure depending on the attacker's identity, and it marks you as willing to pay. Many organizations that pay still face weeks of recovery. Treat it as a last-resort business decision, not an IT decision.
Will our backups survive a ransomware attack?
Only if they are isolated or immutable. Modern ransomware operators actively hunt for backup servers, network shares and cloud backup consoles before detonating, specifically to destroy your recovery options. Backups that are offline, air-gapped, or written to immutable storage with separate credentials usually survive. Backups mounted on the network with domain credentials usually do not.
What should we do in the first hour after discovering ransomware?
Isolate affected systems from the network without powering them off, disable compromised accounts, and activate your incident response plan's call tree — leadership, IT or your MSP, legal counsel, and your cyber insurer. Preserve evidence rather than wiping machines, and communicate out-of-band because email and chat may be compromised or monitored.
Want to know how your environment would hold up?
SmashByte Security assesses ransomware readiness across detection, containment and recovery — and helps you build the response plan before you need it.
Request Security Assessment
