Ransomware Resilience Testing: EDR Evasion, LOTL Techniques, and Why Your Backups Won't Save You

The average eCrime breakout time, the window between initial compromise and lateral movement onto a second system, dropped to 29 minutes for 2025 activity according to CrowdStrike's 2026 Global Threat Report, down from 48 minutes the year before, with the fastest observed breakout at 27 seconds. Excluding any ransom, the average cost to recover from a ransomware attack was $2.73 million (Sophos, The State of Ransomware 2024). 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. This guide is about offensive validation, proving whether your controls detect and stop an operator. If you need the defensive counterpart, what to actually do when ransomware is suspected or confirmed, see our ransomware response and defence guide and its incident-response playbook.

The 29-Minute Breakout Timeline

Two things are worth separating carefully. CrowdStrike's 29-minute figure measures one specific thing: the average breakout time, from initial compromise to the first lateral movement onto a second system. It does not mean an operator reaches domain-wide encryption in 29 minutes; full ransomware deployment typically unfolds over hours to days after breakout. The illustrative sequence below is a compressed exercise scenario we use to show how the early minutes get spent and where detection has to fire, not a claim that every stage completes inside the breakout window. What the 29-minute average does establish is that if your detection and response are measured in hours, the attacker has already broken out before you begin.

Minutes 0-3: Initial Access

Initial access typically arrives via one of three vectors, consistent with the patterns CISA documents for ransomware actors: 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. Where LSASS protection controls are absent, credential material can be harvested from memory in minutes, giving the operator valid credentials to reuse before most detection pipelines have alerted.

# Illustrative discovery sequence — legitimate OS binaries only
whoami /all
net localgroup administrators
systeminfo
ipconfig /all
net view /domain
nltest /dclist:DOMAIN

Every 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 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. Reaching at least one domain controller in this window is a realistic objective for a capable operator, and interrupting it before that happens is exactly what a resilience test measures.

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.

After Breakout: Data Staging and Encryption Deployment

In the later phase of a real intrusion, typically hours to days after breakout rather than within the same 29 minutes, data of value, financial records, customer data, intellectual property, is identified and staged for exfiltration. That stolen data becomes the leverage for a second extortion demand even if backups are restored successfully. Encryption is then pushed out through whatever mass-deployment path the operator controls: RMM tooling, software-deployment systems, hypervisor management, Group Policy, scripts, service creation, or admin shares. A domain controller is a common but not required launch point, and detection should not assume any single origin.

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.

These are overlapping, independent controls, not a single switch. Constrained Language Mode (enforced through application control), AMSI inspection, script-block logging, and behavioural EDR each cover different gaps; the absence of one does not by itself guarantee a bypass succeeds, and none substitutes for the others. Environments that rely on a default EDR configuration without tuning these layers together leave the widest gap.

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 Create

WMI lateral movement spawns processes under the WMI provider host (WmiPrvSE.exe), a signed Microsoft binary. Event ID 4688 (process creation) is only recorded if process-creation auditing is explicitly enabled, and richer signal exists in the WMI-Activity operational log, authentication events, and EDR process telemetry. It is not inherently invisible, but without process-creation auditing, parent-child relationship monitoring, and command-line capture correlated together, WMI execution frequently goes unnoticed.

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 /f

The /f flag forces creation and suppresses the interactive confirmation prompt when a task already exists; it does not by itself suppress task telemetry. Task creation and modification are recorded as Event IDs 4698 and 4702 when the relevant auditing is enabled, alongside Task Scheduler operational events, and the task XML, action, command line, account context, and parent process remain detectable. The real gap is when those controls are not configured: combined with a task name chosen to mimic a legitimate Microsoft task, the persistence can survive undetected unless you correlate schtasks.exe execution, 4698/4702, the Task Scheduler operational log, and suspicious parent processes.

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

A frequent and high-impact weakness is that backup service-account credentials, including credentials for the backup management console, are stored in or reachable from Active Directory. Once an operator holds domain administrator access, those credentials can be enumerated directly from AD attributes, from LSASS memory on the backup server, or from 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. Backup infrastructure placed in the same VLAN as file servers, with no firewall rules restricting which hosts can initiate connections to it, remains a common and dangerous configuration.

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 who reaches your backups before deploying encryption removes your fastest recovery path, and where no isolated or offline copy exists, restoration can become impossible. Sophos found that where attackers attempted to compromise backups, they succeeded 57% of the time (The State of Ransomware 2024).

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

The controls below consistently produce the most significant reduction in ransomware impact when properly implemented, and they map directly to the initial-access, credential-access, and backup-targeting behaviours documented by CISA and CrowdStrike:

• 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.
• Deploy Credential Guard across Windows 10/11 and Server 2019+ systems after compatibility testing (phased rollout, not a blanket flip). It isolates derived secrets, cached domain credentials, NTLM hashes, and Kerberos TGTs in a virtualization-based security boundary, which blocks common LSASS memory-dumping. It does not protect every credential artefact and does not stop Kerberoasting, DCSync, or abuse of credentials while in use, so pair it with the other controls here.
• Audit and restrict directory replication privileges in Active Directory. DCSync abuses replication rights as a set, primarily Replicating Directory Changes and Replicating Directory Changes All, so audit the effective rights held by any non-domain-controller principal, including rights inherited through group membership and ACLs. These over-privileged rights accumulate over years of delegation and are a common finding in long-established environments.
• Segment your backup infrastructure with explicitly documented, least-privilege firewall rules based on your backup architecture (some designs are server-initiated or use proxies and management APIs, so a blanket "agents only" rule can break protection). Restrict management-console and control-plane access to dedicated administrative paths, and ensure no general production host can reach the backup control plane directly.
• Keep backup control-plane credentials in an isolated secrets/PAM system that is not domain-joined and not reachable from the production network, and access the backup control plane only from a hardened privileged access workstation (a PAW is an administration endpoint, not a secrets store). Define emergency credential escrow and recovery separately.
• Implement immutable backup retention and test restoration regularly. Set the retention window to exceed your credible compromise-discovery time (a 30-day window and quarterly full restores are common starting baselines that should be validated against your own RPO/RTO, change rate, and regulatory requirements), keep multiple restore points, and make the test a full, end-to-end restore to an 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.