What Is Ransomware and How Does a Ransomware Attack Actually Work?

Ransomware is a malicious attack that makes data or systems unavailable and demands payment to restore access. Modern ransomware incidents can go further: attackers may steal information before encryption and use the threat of disclosure as additional leverage. NIST’s current ransomware guidance explicitly recognises both encryption and data theft as parts of the risk organisations need to manage.

That means ransomware is better understood as an incident process, not simply as a program that suddenly scrambles files. An attacker may first gain access, establish a foothold, discover valuable systems, obtain broader privileges, move through the environment, steal data, interfere with recovery options and only then trigger encryption or another disruptive action.

For an individual or organisation facing a suspected attack, the immediate priorities are not to negotiate with a ransom note or start deleting evidence. Isolate affected systems where it is safe to do so, activate the incident-response process, preserve evidence, determine the scope, protect unaffected systems and assess recovery from known-good backups. If the incident affects an organisation, involve the appropriate security, IT, legal, management and reporting functions rather than treating it as an ordinary computer fault.

If you first need the broader distinction between ransomware and other malicious software, see What Is Malware?. This article focuses specifically on how a ransomware incident develops and why defensive layers matter at different stages.

Ransomware is an attack outcome, not one fixed infection path

It is tempting to imagine ransomware as a single sequence: someone opens a bad attachment, a program encrypts the laptop, and a ransom message appears. That can happen, but it is too narrow a model for defending a real environment.

The initial access method can vary. An attacker might exploit a vulnerable internet-facing service, abuse valid credentials, use social engineering, or rely on another malicious component already present in the environment. After access, the attacker may attempt to understand the network and locate accounts, servers, storage, backups and business-critical data.

The eventual impact can also vary. Encryption is common, but extortion can involve stolen information as well. NIST IR 8374 Revision 1, published in June 2026 for Cybersecurity Framework 2.0, describes ransomware as an attack in which data is encrypted and payment is demanded, while noting that attackers may also steal information and demand payment to prevent disclosure.

So the useful security question is not only, “How do we stop the ransomware executable?” It is also, “Which opportunities in the attack path can we remove, detect or contain before the organisation reaches a crisis?”

The diagram deliberately separates the stages because different controls interrupt different parts of the incident. Strong authentication may reduce credential-based entry. Timely patching can reduce exposure to known exploitable weaknesses. Network segmentation can make lateral movement harder. Logging and monitoring can reveal abnormal behaviour. Protected backups reduce dependence on an attacker’s promise of recovery.

Stage 1: the attacker needs a way in

Ransomware does not bypass the basic reality of cybersecurity: an attacker needs some path to execute malicious actions or obtain useful access.

Common defensive priorities therefore begin well before encryption. NIST’s ransomware profile maps ransomware risk management across the CSF 2.0 functions Govern, Identify, Protect, Detect, Respond and Recover. This is important because it rejects the idea that one endpoint product can carry the entire defence.

For internet-facing systems, organisations need an accurate asset inventory and a disciplined vulnerability-management process. For identity-based access, multi-factor authentication, strong account lifecycle controls and least privilege reduce what stolen or guessed credentials can achieve. For email and user-driven delivery, filtering helps, but user awareness and application controls still matter because no filter is perfect.

The practical lesson is simple: preventing ransomware starts with reducing ordinary routes into the environment.

Stage 2: a foothold becomes a larger security problem

Initial access is not necessarily the same as immediate encryption. An attacker who controls one account or endpoint may try to turn limited access into something more valuable.

That can involve discovering hosts and services, identifying privileged accounts, looking for shared storage, or finding systems that are important to operations. If the environment is flat and one account has broad permissions, a small compromise can become a much larger incident.

This is where least privilege and segmentation become more than compliance language. Suppose an employee workstation can directly reach sensitive administrative services and the user’s account has unnecessary access to shared data. A compromise of that workstation gives the attacker a much more useful starting position than the same compromise inside a segmented environment with constrained permissions.

Good architecture assumes that some preventive controls will eventually fail. It asks what happens after the first failure.

Stage 3: attackers may target recovery and visibility

An organisation with reliable backups has a stronger recovery position, so attackers have an incentive to make recovery harder. Defenders should therefore avoid treating backup storage as merely another convenient network share.

NIST’s ransomware guidance emphasises contingency planning and recovery capabilities. The important property is not simply that a backup job reports success. A useful ransomware recovery capability needs backups that are protected from the same compromise, monitored, retained appropriately and tested through restoration.

A backup that cannot be restored is not a recovery plan. A backup whose administrative credentials are exposed through the same identity path as production is also weaker than it appears.

Logging deserves similar attention. During an incident, responders need enough trustworthy evidence to reconstruct what happened: which accounts were used, which systems communicated, what changed, when suspicious activity began and whether data may have left the environment. Centralised or otherwise protected logs can remain useful even if an endpoint is damaged.

Stage 4: data theft can create a second form of pressure

Encryption attacks availability: people cannot use the files or systems they need. Data theft attacks confidentiality. When both occur, restoring from backup may solve only one part of the incident.

Imagine an organisation that restores every encrypted server successfully. Operationally, that is excellent. But if sensitive customer information was copied before encryption, the organisation still has a breach investigation, potential notification obligations and a confidentiality problem. Recovery does not erase exfiltration.

This is why responders need to investigate the incident rather than assuming that restored files mean the event is over.

Stage 5: encryption and extortion create the visible crisis

Encryption is often the moment when the incident becomes obvious. Files become inaccessible, services fail, unusual extensions may appear, or a ransom message is displayed.

At this point, hurried actions can make investigation and recovery harder. Turning off every system without coordination, wiping machines immediately, or deleting suspicious files can destroy useful evidence. On the other hand, leaving active malicious systems connected can allow damage to continue.

The correct containment decision depends on the environment and incident. That is why organisations need a rehearsed response plan before the emergency. NIST SP 800-61 Revision 3, listed by NIST alongside its ransomware resources, treats incident response as part of broader cybersecurity risk management rather than an improvised technical exercise.

What should you do if ransomware is suspected?

For an organisation, use the established incident-response process and obtain qualified assistance where necessary. For a personal device, the exact steps depend on whether other devices, cloud accounts or shared storage may also be affected. A sensible high-level sequence is:

1. Contain carefully. Disconnect affected endpoints from networks when appropriate and safe, while avoiding actions that unnecessarily destroy evidence.
2. Escalate. Notify the responsible security or IT team immediately in an organisation. Do not quietly attempt a private fix on a managed device.
3. Preserve evidence. Record what is visible and preserve relevant logs and system information according to the response process.
4. Establish scope. Determine which identities, endpoints, servers, storage locations and cloud services may be affected.
5. Protect what remains. Address compromised credentials and exposed access paths from trusted systems, and prevent unaffected assets from being reached through the same route.
6. Eradicate and recover. Rebuild or restore from known-good sources according to a validated recovery plan rather than assuming a decrypted machine is trustworthy.
7. Report and investigate. Follow applicable organisational, legal, regulatory, insurance and law-enforcement reporting requirements.

CISA’s ransomware guidance likewise centres preparation, prevention, response and recovery rather than a single malware-removal step.

Should a victim pay the ransom?

There is no technical guarantee that payment will restore a trustworthy environment or prevent stolen information from being misused. A decryption mechanism, even if provided, does not answer how the attacker entered, what else changed, whether credentials were stolen, whether persistence remains, or whether copied data was retained.

Payment decisions can also involve legal, regulatory, sanctions, insurance and law-enforcement considerations that vary by jurisdiction and circumstances. They should not be reduced to a simple technical calculation or handled casually by an individual administrator.

From a security-engineering perspective, the better goal is to build enough resilience that the organisation is not relying on an attacker’s cooperation as its recovery strategy.

The controls that matter at each stage

The table below maps practical controls to the problem they are intended to reduce. It is a defensive model based on the lifecycle reasoning in current NIST ransomware guidance, not a claim that every incident follows identical steps.

No row is a magic solution. The strength comes from overlapping controls. If phishing resistance fails, strong identity controls may still help. If one endpoint is compromised, segmentation may contain it. If encryption succeeds, protected backups may preserve recovery. If restoration succeeds but data was stolen, logs and investigation still matter.

Why backups need to be tested, not merely created

“We have backups” sounds reassuring until someone asks three harder questions: Can they be reached by the same compromised administrators? How old is the last clean recovery point? How long does a real restore take?

A mature recovery process answers those questions through testing. Organisations should know which systems must return first, what dependencies those systems have, who is authorised to initiate recovery and how integrity will be checked before restored services return to production.

This is also why recovery planning belongs in business resilience, not only in the storage team’s task list. A technically successful restore that takes longer than the organisation can tolerate is still a serious operational problem.

Common ransomware misconceptions

“Antivirus will stop ransomware.” Endpoint protection is valuable, but ransomware risk spans identity, vulnerabilities, network architecture, data protection, monitoring, response and recovery. One product cannot compensate for weak controls everywhere else.

“If backups work, there is no breach.” Backups address availability and recovery. They do not prove that confidential information was not stolen.

“Encryption is the beginning of the attack.” It may be the first visible symptom, but an attacker can have performed substantial activity beforehand.

“A ransom note tells us exactly what happened.” A note is an attacker’s message, not forensic evidence of the complete scope or truth of the incident.

“Restoring files finishes the incident.” Recovery must be paired with root-cause investigation, credential remediation, validation and lessons learned, otherwise the original access path may remain.

A practical readiness check

A small organisation does not need an enormous security programme to ask useful questions. Start with the controls that reduce both ransomware risk and many other cyber risks:

• Do we know which internet-facing systems and critical assets we operate?
• Are high-risk vulnerabilities and unsupported systems handled promptly?
• Is MFA required for important remote, cloud and administrative access?
• Are privileged accounts separated and limited?
• Can one compromised workstation directly reach too much of the environment?
• Are important logs available somewhere an attacker on one endpoint cannot simply erase?
• Are backups protected from production compromise, and have we actually restored from them?
• Do staff know whom to contact immediately when something suspicious happens?
• Has the organisation practised a ransomware or destructive-incident scenario?

These questions align naturally with NIST CSF 2.0’s broader Govern, Identify, Protect, Detect, Respond and Recover model. Ransomware readiness is strongest when it improves the organisation’s general security architecture rather than creating a separate collection of emergency-only tools.

Ransomware defence is really resilience engineering

The visible ransomware payload receives attention because encryption is dramatic. The deeper lesson is less dramatic but more useful: ransomware exploits ordinary weaknesses in access, identity, architecture, monitoring and recovery, then combines them into operational leverage.

A resilient environment therefore does not depend on predicting the exact ransomware family that may appear next. It reduces entry paths, limits privileges, contains movement, protects important data, preserves evidence, maintains independent recovery options and rehearses what to do when prevention fails.

That approach also strengthens security against many incidents that never display a ransom note.

For more foundational context, read What Is Malware?, Cybersecurity vs Information Security, and Cybersecurity in Sri Lanka.

Sources and further reading

• NIST IR 8374 Revision 1: Ransomware Risk Management, Cybersecurity Framework 2.0 Community Profile, final June 2026.
• NIST Ransomware Protection and Response publications, including NIST SP 800-61 Revision 3 and data-integrity guidance.
• NIST Cybersecurity Framework 2.0, for the Govern, Identify, Protect, Detect, Respond and Recover risk-management functions.
• CISA and MS-ISAC Ransomware Guide, defensive guidance for prevention, response and recovery.