The average ransomware breakout time — the window between initial compromise and domain-wide impact — has dropped to 29 minutes according to CrowdStrike's 2024 threat intelligence data. The average recovery cost following a successful ransomware incident sits at $2.73 million. Yet most organizations measure their ransomware resilience by pointing to their EDR deployment and their backup solution. Neither of those things, in isolation, tells you whether you can actually survive an attack.
At Cyber Security Pentesting Inc., we run simulated ransomware operations that stress-test the entire kill chain: the initial access vector, the lateral movement phase, the credential harvesting, the data staging, and — critically — the backup infrastructure that organizations believe will save them. What we find consistently challenges the confidence level organizations have in their defensive posture.
The 29-Minute Breakout Timeline
To understand why ransomware resilience testing matters, it helps to walk through what a realistic engagement timeline actually looks like. The 29-minute breakout figure is not an outlier — it is the median for eCrime actors operating at operational tempo. Here is how those minutes get used.
Minutes 0–3: Initial Access
Initial access in our engagements typically arrives via one of three vectors: a phishing payload that bypasses email filtering, a valid credential set obtained through prior OSINT or credential stuffing, or an internet-exposed service with a known or zero-day vulnerability. By the time the first callback reaches our team server, the clock is running.
Minutes 3–8: Situational Awareness and Local Credential Harvesting
The implant begins automated discovery — enumerating the local system, identifying domain membership, profiling the user's role and group memberships, and scanning for credential material. In environments without LSASS protection controls, we have extracted valid domain credentials within four minutes of initial execution.
# Illustrative discovery sequence — legitimate OS binaries only
whoami /all
net localgroup administrators
systeminfo
ipconfig /all
net view /domain
nltest /dclist:DOMAINEvery command in that sequence uses a built-in Windows binary. Nothing external is dropped to disk. No process injection has occurred yet. Behavioural EDRs that rely exclusively on file-based IOCs have seen nothing alertable at this stage.
Minutes 8–15: Lateral Movement
With valid credentials in hand, lateral movement begins. The target is always the highest-value system reachable with current privileges — backup servers, domain controllers, file servers, and any host with a service account running as a domain admin. In the engagements we run, we reach at least one domain controller in this window in the majority of cases.
Minutes 15–22: Privilege Escalation and Persistence
Domain administrator privileges are pursued through Kerberoasting, AS-REP roasting, or ACL abuse depending on what the environment presents. Persistence mechanisms are established on at least three separate systems using different techniques so that remediation of one does not terminate the operation.
Minutes 22–29: Data Staging and Encryption Deployment
Data of value — financial records, customer data, intellectual property — is identified and staged for exfiltration. In a real ransomware operation, this data becomes the leverage for a second extortion demand even if backups are restored successfully. Encryption is then deployed from the domain controller outward to maximize impact before detection and containment can occur.
Living-off-the-Land Techniques That Bypass EDR
Living-off-the-land (LOTL) techniques abuse legitimate operating system tools and trusted binaries to carry out attack objectives. Because these tools are inherently trusted and used constantly in normal operations, detection requires behavioural context rather than file-based signatures. Many EDR configurations are not tuned to provide that context.
PowerShell AMSI Bypass
The Antimalware Scan Interface (AMSI) is Microsoft's mechanism for exposing script content to security products before execution. Every major threat actor has invested in AMSI bypass techniques because PowerShell remains one of the most capable and universally available post-exploitation platforms in a Windows environment.
The bypass approaches we test against in engagements do not involve writing files to disk or spawning new processes. They operate entirely in memory within the existing PowerShell session. We do not publish specific bypass code — the purpose of testing is to determine whether your AMSI implementation and EDR detect the bypass attempt, not to contribute to the attacker's toolkit.
What we consistently find: AMSI bypass attempts succeed in environments where PowerShell Constrained Language Mode is not enforced and where the EDR's AMSI integration has not been specifically tuned. The default EDR configuration is frequently insufficient.
WMI Lateral Movement
Windows Management Instrumentation (WMI) provides remote process execution capabilities that are legitimately used by IT operations tools, monitoring agents, and remote administration workflows. Threat actors use the same interfaces to execute code on remote systems without creating a new service or dropping an executable.
# WMI remote process creation — uses only built-in OS functionality
# wmic /node:TARGET /user:DOMAIN\user /password:pass process call create "cmd.exe /c [command]"
# Or via PowerShell: Invoke-WmiMethod -ComputerName TARGET -Class Win32_Process -Name CreateWMI lateral movement generates Event ID 4688 (process creation) on the target host but does so under the context of WMI provider host (WmiPrvSE.exe), a signed Microsoft binary. Without properly configured parent-child process relationship monitoring, this lateral movement is invisible to most SIEM configurations we test.
Scheduled Task Persistence
Scheduled tasks are among the most persistent persistence mechanisms available to an attacker because they survive reboots, survive user logoffs, and are difficult to enumerate comprehensively on a large estate. We establish scheduled task persistence using the built-in schtasks.exe utility, targeting system-level task names that blend with legitimate Windows maintenance tasks.
# Scheduled task creation using native OS binary
# schtasks /create /tn "Microsoft\Windows\[LegitimateTaskName]" /tr "[payload]" /sc onlogon /ru SYSTEM /fThe detection gap here is specifically the /f flag — force creation — which overwrites existing tasks without generating a unique event distinguishable from a normal task update. Combined with a task name chosen to match a legitimate Microsoft task category, this persistence mechanism has gone undetected for the duration of engagements in the majority of environments we test.
LOLBins Abuse
Living-off-the-land binaries — signed Microsoft executables that can be abused for offensive purposes — are catalogued extensively at lolbas-project.github.io. During ransomware simulations we regularly abuse certutil.exe for file download and decode operations, mshta.exe for script execution, regsvr32.exe for proxy execution, and rundll32.exe for in-memory payload execution.
The common thread is signed, trusted binaries executing unsigned, untrusted content. Detection requires monitoring the arguments passed to these binaries, not just their presence on a system. That level of argument-level telemetry is not universally configured, even in environments with enterprise-grade EDR.
EDR Evasion in Practice
Modern EDR solutions are sophisticated. They monitor process creation, file system activity, network connections, registry modifications, and increasingly, memory regions. To test whether your EDR is actually detecting a realistic threat actor, we employ techniques that match the capabilities of mid-to-high tier ransomware operators. We are explicit that we test detection capability — we do not publish or provide evasion tooling.
Direct Syscalls
Most EDR hooks operate at the userland API layer — specifically, they patch functions in ntdll.dll to intercept calls before they reach the kernel. Direct syscall techniques bypass these hooks entirely by invoking the Windows kernel directly using syscall instruction sequences, without going through the hooked API functions.
What we test: whether your EDR has kernel-level monitoring capabilities that detect the anomalous call pattern. ETW (Event Tracing for Windows) kernel provider monitoring and kernel-mode drivers are the defensive controls that matter here. Userland-only EDR architectures have a structural gap against this technique.
Unhooking Userland Hooks
A related evasion approach involves restoring the original, unhooked versions of ntdll.dll functions by mapping a fresh copy of the DLL from disk and overwriting the hooked memory regions. This is detectable by EDRs that monitor for unexpected modifications to loaded DLL memory regions — but it requires that specific detection capability to be active and tuned.
In assessments, we document which evasion techniques triggered alerts, which generated telemetry that was not acted upon, and which generated no telemetry at all. The distinction between "logged but not alerted" and "not logged at all" is significant for remediation prioritization.
In-Memory Execution
Fileless execution — running payloads entirely in memory without writing to disk — is now table stakes for any competent threat actor. The defensive dependency on file scanning as a primary detection mechanism is a well-understood gap. We test in-memory execution paths through process hollowing, process doppelganging, and injection into legitimate host processes.
The detection signal for in-memory execution is not file presence — it is anomalous memory regions in trusted processes, unexpected outbound network connections from those processes, and unusual API call sequences. EDRs that rely on file scanning as a primary layer provide significantly weaker coverage against this technique class.
Reflective DLL Injection
Reflective DLL injection loads a DLL from a memory buffer rather than from disk, bypassing the normal Windows loader and avoiding the creation of a standard loaded module entry that security tools can enumerate. This technique is commonly used to load implants into remote processes in a way that does not appear in the standard module list.
Why Your Backups Won't Save You
This is where engagements produce the most operationally significant findings. When clients tell us their ransomware recovery plan rests on their backup solution, we immediately ask four questions: where are the backup credentials stored, are the backup systems on a separate network segment, when did you last test a full restore, and do you have immutable or offline backup copies? The answers are rarely reassuring.
Backup Credentials Stored in Active Directory
The most common finding is that the backup agent service account credentials — including credentials for the backup management console — are stored in Active Directory or accessible via the domain. Once we have domain administrator access, we can enumerate these credentials directly from AD attributes, from LSASS memory on the backup server, or from the backup agent configuration files.
In one engagement, we found the backup solution's administrative credentials stored in a GPO preference item — a configuration method Microsoft deprecated precisely because credentials stored this way are recoverable by any domain user. With those credentials, we could connect to the backup management console, enumerate all backup jobs, and delete them. A real ransomware actor would do exactly this before triggering encryption.
Backup Systems on the Same Network Segment
Backup servers that sit on the same flat network as production systems are reachable by a ransomware operator who has achieved lateral movement. We regularly find backup servers in the same VLAN as file servers, with no firewall rules restricting which hosts can initiate connections to the backup infrastructure.
In this configuration, the backup server is just another target. We treat it as a priority target specifically because organizations rely on it for recovery. A ransomware operator targeting your backups before deploying encryption can double your recovery time minimum — and in several cases we have documented, complete restoration was impossible because no offline copy existed.
Untested Restoration Procedures
Having backups and being able to restore from them are two different things. We have encountered organizations that had not performed a full restore test in over two years. Backup jobs were completing without errors — but the backup catalog had been corrupted by a storage system issue six months prior, and the restores would fail.
In another case, the organization's backup solution had been upgraded but the restoration documentation had not been updated. The procedures referenced menu paths that no longer existed in the new version. Under incident response conditions, with every hour of downtime costing revenue, discovering that your runbook is out of date is a compounding disaster.
No Offline or Immutable Backups
Online backups — backups that are network-accessible at the time of an attack — can be deleted or encrypted by a ransomware actor who has achieved the necessary privilege level. Immutable backup solutions, where backup data cannot be modified or deleted within a defined retention window, provide meaningful protection against this. Offline backups — air-gapped copies on tape or disconnected media — provide the strongest protection.
The gap we find most frequently is not that organizations are completely unaware of immutable or offline backup requirements. It is that the implementation is incomplete. A common scenario: cloud backup with object lock enabled, but the retention window is seven days. A patient ransomware actor who established persistence three weeks ago and began slow-encrypting files has already rotated beyond that window before the attack becomes visible.
Purple Team Approach to Ransomware Testing
A fully blind red team operation — where the blue team has no foreknowledge of the engagement — produces a realistic worst-case scenario assessment. But for organizations whose primary goal is to improve detection and response capability, a purple team approach delivers more actionable output per day of engagement time.
How We Structure Purple Team Ransomware Exercises
In a purple team ransomware exercise, the red team and blue team operate collaboratively. The red team executes each technique from the ransomware kill chain while the blue team monitors their tooling in real time. After each technique execution, both teams review what was detected, what was missed, and what the alert quality looked like.
This approach allows us to iterate through detection gaps in a single engagement rather than over multiple assessment cycles. If a technique is not detected, the blue team can immediately work with their EDR vendor or SIEM configuration to create a detection while the red team's execution context is still fresh.
Measuring MTTD and MTTR
Mean Time to Detect (MTTD) and Mean Time to Respond (MTTR) are the two metrics that determine whether a ransomware operation can be contained before domain-wide impact. We measure both during the exercise and compare them against the 29-minute breakout benchmark.
If your MTTD for lateral movement is 45 minutes, a realistic ransomware actor has already achieved their objectives before your first alert fires. That gap — the delta between the attacker's operational tempo and your detection capability — is what ransomware resilience testing is designed to quantify.
Detection Engineering Feedback Loops
Each technique that bypasses detection during the exercise becomes a detection engineering task for the blue team. We provide the specific telemetry that should have been present — the Event IDs, the process relationships, the network indicators — so that new detection rules can be written and validated before the engagement closes.
This means an organization exits the engagement with not just a list of gaps, but a partially closed gap list validated by the same team that identified them. The feedback loop between offensive technique execution and defensive rule creation is the core value of the purple team format.
Defensive Guidance
Based on our ransomware resilience testing across multiple sectors and organization sizes, the following controls produce the most significant reduction in ransomware impact when properly implemented:
- Enforce PowerShell Constrained Language Mode via AppLocker or Windows Defender Application Control (WDAC). This does not prevent PowerShell use — it restricts what classes and methods are accessible, breaking a significant proportion of post-exploitation tooling.
- Enable Credential Guard on all Windows 10/11 and Server 2019+ systems. Credential Guard isolates LSASS in a virtualization-based security boundary, preventing memory-based credential extraction without kernel-level compromise.
- Audit and restrict replication privileges in Active Directory. Any account that is not a domain controller and holds DS-Replication-Get-Changes-All is a DCSync risk. We find these accounts in every environment that has been running Active Directory for more than five years.
- Segment your backup infrastructure with dedicated firewall rules. Only backup agents should be able to initiate connections to backup servers. No production host should be able to reach the backup management console directly.
- Store backup credentials in a privileged access workstation (PAW) or secrets vault that is not domain-joined and not reachable from the production network.
- Implement immutable backup retention with a minimum 30-day window and test restoration procedures quarterly. The test should be a full, end-to-end restore to a isolated environment — not a file-level restore of a single document.
- Maintain at least one offline backup copy that is physically or logically disconnected from the network. Tape, removable drives kept off-site, or cloud providers with operator-isolated storage all satisfy this requirement depending on your RTO/RPO targets.
- Enable Windows Event Logging for process creation with command-line auditing (Event ID 4688 with full command-line capture). Without this, the argument-level visibility needed to detect LOLBin abuse simply does not exist.
- Enable Sysmon with a community-maintained configuration baseline such as the SwiftOnSecurity or Olaf Hartong configurations. The additional telemetry Sysmon provides — particularly for process injection, driver loads, and WMI activity — is not available from native Windows logging alone.
- Run tabletop exercises that specifically test your incident response playbook against a ransomware scenario. Identify who has authority to isolate a domain controller, who has the backup console credentials, and what the communication plan is before you are doing it under pressure.
Frequently Asked Questions
How is ransomware resilience testing different from a standard red team assessment?
A standard red team engagement tests your overall detection and response capability across a broad range of attack scenarios. Ransomware resilience testing is scoped specifically to the ransomware kill chain — with explicit focus on lateral movement speed, EDR evasion techniques used by ransomware operators, and backup system integrity. We also specifically assess whether your recovery capability is viable, which standard red team engagements typically do not cover.
Will you actually encrypt anything during the test?
No. We simulate the encryption deployment phase by demonstrating the capability to reach target systems and execute code with the required privileges. We do not encrypt client data under any circumstances. In some engagements we deploy a benign "canary" file write operation to confirm that encryption would succeed if deployed, but all activity is fully reversible and scoped in the rules of engagement.
Do we need to tell our staff the test is happening?
For a purple team exercise, the SOC and blue team are informed — that is the format. For a blind red team engagement, the decision about staff awareness is made by senior leadership and documented in the rules of engagement before the engagement begins. We have experience with both formats and can advise on which is appropriate for your current maturity level.
How long does a ransomware resilience assessment take?
A focused ransomware resilience assessment typically runs five to ten business days depending on scope. This includes the active testing phase, the backup infrastructure assessment, and the reporting and debrief cycle. Purple team exercises are typically structured as a series of half-day or full-day sessions over two to three weeks to allow time for detection engineering between sessions.