Our Approach To Ransomware Threat Modeling
In offensive security, we spend a great deal of time proving that individual weaknesses can be exploited. We compromise accounts, extract credentials, move between systems, and test whether controls withstand realistic attacker behaviour.
But one question matters more than any individual finding:
That is the question ransomware threat modeling is designed to answer.
What Is Threat Modeling?
Threat modeling is a structured way to understand how an attacker could compromise an organization, which systems matter most, what controls stand in the way, and what the business consequences could be.
It does not try to predict one exact future incident. Instead, it develops a set of plausible attack scenarios based on the organization’s architecture and operating processes, relevant threat intelligence, actual attacker techniques, existing controls, and the potential impact if those controls fail.
For ransomware, this means looking beyond malware and encryption. The model should explain how an attacker could move from initial access to privilege escalation, lateral movement, data theft, ransomware deployment, operational disruption, or recovery impairment.
The value is in seeing the whole attack path, not merely its individual pieces.
The Attack Path Tells the Real Story
After years of penetration testing, red teaming, control assessments, and threat-modeling work, I have found that major compromises rarely depend on one extraordinary vulnerability.
More often, attackers combine several weaknesses that appear manageable when examined separately:
A Help Desk process that relies heavily on trust.
Phishable multifactor authentication.
A compromised remote laptop.
Reused local administrator passwords.
Credentials stored in a script or file share.
An internal system missing a security update.
An administrative platform with broad operational reach.
Individually, each weakness may produce a separate finding. Together, they may form a credible ransomware path:
An attacker compromises a remote user through an MFA phishing portal and gain initial access through the VPN afterward.
Once initial access is obtained, the attacker finds an unprotected file share with a script containing credentials for a high-privilege service account. The attacker then uses the account to move laterally, exfiltrate data (used for double extortion) and additional credentials from compromised hosts. Once domain domination is complete, the attacker uses deployment systems such as SCCM to deploy an EDR killer to disable endpoints defenses just before deploying the ransomware.
That story is much more useful than a list of technical observations. It explains why an apparently modest weakness matters, how controls depend on one another, and where the organization has opportunities to interrupt the attack.
Start With the Outcome and Work Backward
A useful ransomware model begins with the outcome the organization wants to prevent.
What could allow an attacker to deploy ransomware broadly? Which systems could cause the greatest operational disruption? What would allow sensitive data to be stolen for extortion? What could prevent systems from being restored?
The answers often point toward systems such as identity and privileged-access platforms, software deployment systems, remote support tools, network management platforms, source-code and build pipelines, hypervisors, backup infrastructure, and systems capable of executing commands or distributing files across many locations.
These systems are attractive because the organization already trusts them.
A software deployment platform is allowed to execute scripts. A network management platform is allowed to change connectivity. A privileged-access system is designed to provide administrative sessions. A build pipeline produces software that endpoints are expected to trust.
From an offensive perspective, this creates a powerful question:
In many environments, abusing a trusted management or deployment system is more effective than attacking thousands of endpoints individually.
Combine Threat Intelligence With Internal Knowledge
Threat intelligence keeps the model connected to reality.
Ransomware operators regularly use techniques such as Help Desk impersonation, phishing, adversary-in-the-middle attacks, token theft, remote access software, credential dumping, vulnerability exploitation, and backup destruction.
But a list of attacker techniques is not yet a threat model. Each technique must be translated into questions about the organization:
Could an attacker persuade the Help Desk to reset a user’s access?
Could a stolen session token be replayed?
Can unmanaged devices access sensitive services?
Could a compromised laptop provide internal access through the VPN?
Are administrator passwords reused?
Could authentication be relayed to a sensitive service?
Are credentials stored in scripts or shared folders?
Which systems can deploy software or execute commands at scale?
Could recovery images or backups be modified after privileged access is obtained?
Threat intelligence tells us what attackers do. The people operating the environment tell us how those techniques could work here.
Both are essential.
The Security Team Cannot Do This Alone
Some of the most important attack paths are discovered through conversations, not scanners.
A support technician may explain that an alternate remote-access tool is used when the VPN is unavailable. A developer may describe how software packages are built and approved. A network administrator may reveal that a central server can run scripts against remote locations. A recovery specialist may identify a dependency on a particular identity service or image repository.
These details are often absent from formal architecture diagrams.
This is why threat modeling must be iterative and collaborative. Security brings knowledge of attackers, attack chains, and control weaknesses. System owners bring knowledge of how the environment actually operates.
When the process is handled well, it also builds trust. The objective is not to find someone to blame. It is to understand how legitimate processes could be abused and how different teams can reduce that risk together.
The first version of the model will not be perfect. It may contain incorrect assumptions, missing systems, or overstated paths. That is expected.
Every workshop, technical review, and control validation should make it more accurate.
The Model Remains a Hypothesis Until It Is Tested
Documentation tells us how a control is intended to work. Interviews tell us how people believe it works.
Offensive security tells us whether the attacker can get around it.
Testing does not require deploying ransomware or disrupting production. Individual links in the chain can be evaluated safely:
Can the Help Desk be socially engineered?
Can an unmanaged device access sensitive systems?
Can tokens or browser sessions be replayed?
Can credentials be extracted and reused?
Can NTLM authentication be relayed?
Can a privileged-access workflow be bypassed or misused?
Can a deployment package be modified without detection?
Can commands be executed through a trusted management platform?
Can backups, snapshots, or recovery images be deleted or altered?
Do detections activate early enough to interrupt the path?
The threat model guides offensive testing toward the scenarios with the greatest business relevance. The test results then improve the model.
Sometimes the controls prove stronger than expected. Sometimes a trusted assumption fails immediately. Both outcomes are valuable because they replace theory with evidence.
Prioritize Controls That Break Multiple Attack Paths
One of the strongest benefits of ransomware threat modeling is better remediation prioritization.
The most valuable action is not always the fix associated with the highest-scoring individual finding. It may be the action that interrupts the greatest number of credible attack paths.
For example, phishing-resistant MFA can reduce several identity-compromise scenarios. Managed-device enforcement can reduce remote-device and token-theft risks. LAPS can interrupt multiple lateral-movement paths. Hardened administrative access can protect several critical platforms. Immutable recovery assets can reduce the impact of many successful compromises.
The question changes from:
Which finding is the most severe?
To:
Which improvement removes the most realistic paths to ransomware impact?
That is a much more useful conversation for both security teams and leadership.
Treat the Model as a Living Offensive Security Asset
A ransomware threat model should not become a static diagram buried in a report.
It can guide penetration tests, red-team exercises, control assessments, detection engineering, incident-response playbooks, tabletop exercises, recovery testing, and security architecture decisions.
The process should become a recurring cycle:
Model the attack path. Validate it with stakeholders. Test the assumptions. Improve the controls. Update the model. Test again.
The real outcome is not the diagram itself. It is the shared understanding that develops around it.
Security teams understand which systems matter most. Operational teams see how legitimate capabilities could be abused. Offensive testers know which assumptions are worth challenging. Leadership understands how several modest weaknesses can combine into a major business event.
Ransomware does not begin when files are encrypted.
Encryption is usually the final visible step in a much longer intrusion.
Threat modeling helps us understand that intrusion while there are still multiple opportunities to stop it.