Driver’s Ed for Criminals: How Ransomware Learns to Run Over Your Defenses

December 2, 2025

Synopsis

The analysis shows that a ransomware operator is using a custom packer (TangleCrypt) and an EDR-killer toolchain (STONESTOP with the ABYSSWORKER driver) to disable endpoint defenses, terminate security processes, and sometimes delete files prior to deploying ransomware, placing Windows endpoints and servers at significant risk of encryption, data loss, and operational downtime. Strategically, this information pushes organizations to strengthen driver-governance, update risk registers, and allocate resources toward improved monitoring and hardening; operationally, it highlights the need for better telemetry, tighter EDR self-protection, and clearer escalation paths when security tools fail; tactically, it requires responders to look for specific behavioral sequences such as new driver loads followed by rapid EDR-process termination. The scenario elevates overall risk posture because moderate control strength and high threat capability increase the likelihood of meaningful harm once the actor reaches this stage of the intrusion. Financial resilience is affected by the credible potential for recovery costs, service disruption, and secondary losses, reinforcing the need for stronger preventive controls, better detection of driver-based evasion, and more consistent investment in incident-response readiness.

Evaluated Source, Context, and Claim

Artifact Title

TangleCrypt: a sophisticated but buggy malware packer

https://labs.withsecure.com/publications/tanglecrypt

Source Type

Vendor research blog post (WithSecure Labs)

Publication Date: 27 November 2025

Credibility Assessment

WithSecure is an established security vendor with a long track record of publishing detailed, technically verifiable research, and this article provides concrete artifacts, behaviors, and references to other public analyses. Overall, it is a high-credibility technical source suitable for use in defensive intelligence and detection engineering.

General Claim

The OSINT reports that threat actors deploying Qilin ransomware are using a previously undocumented Windows malware packer, TangleCrypt, to hide and launch the STONESTOP EDR-killer with the ABYSSWORKER driver, using multi-layered encoding and flexible injection techniques but with implementation flaws that can cause crashes and reduce reliability.

Narrative Reconstruction

The OSINT describes a ransomware operator that, in an early-September 2025 incident, used a custom malware packer dubbed TangleCrypt to conceal and execute STONESTOP, an EDR-killer that registers and abuses the ABYSSWORKER kernel driver to terminate security products and sometimes recursively delete files in predefined directories before or alongside Qilin ransomware deployment. TangleCrypt itself is a payload-agnostic Windows PE packer that stores the encrypted payload in PE resources and protects it through layered base64, LZ78 compression, and XOR encryption, then dynamically decrypts and launches it either in the same process or in a spawned child process based on a configuration string embedded in the payload. The primary assets at risk are Windows endpoints and servers running Microsoft Defender and other EDR/AV tools, whose processes are explicitly targeted by STONESTOP, with the operational goal of disabling endpoint defenses to enable subsequent data exfiltration and file encryption typical of hands-on ransomware operations. Although TangleCrypt includes basic anti-analysis techniques such as string encryption, dynamic import resolution, and minor anti-debugging behavior, the analysis highlights flaws in its loader implementation and API re-implementations that can lead to crashes in certain execution contexts, illustrating that while the tool increases evasion capability for attackers, its imperfections can also serve as a detection opportunity for defenders.

Risk Scenario

Risk Scenario

A threat actor conducting hands-on ransomware operations deploys a custom loader that conceals and launches defense-evasion tooling to disable endpoint protections before executing file-encrypting malware. The loader uses layered obfuscation and configurable execution methods to hide malicious components, while the payload seeks elevated privileges, loads system-level elements, and repeatedly terminates security processes to create a temporary security blind spot. This places Windows endpoints and servers at risk by clearing the path for ransomware deployment and data theft. Although the loader is designed for stealth, its inconsistent implementation can cause unstable behavior, creating both detection opportunities and operational uncertainty for the attacker.

Threat

An organized ransomware operator observed deploying Qilin ransomware and leveraging an EDR-killer toolchain (STONESTOP plus ABYSSWORKER) packaged with the custom TangleCrypt loader.

Method

The threat actor deploys executables packed with TangleCrypt, which decrypts and launches a STONESTOP payload from PE resources using layered base64, LZ78 compression, and XOR; STONESTOP then registers and loads the ABYSSWORKER kernel driver, enumerates targeted process names, repeatedly terminates matching EDR/AV processes, and in some variants recursively deletes files in specified directories, all to clear defenses and hinder response ahead of or during ransomware activity.

Asset

Windows endpoints and servers in the victim environment, particularly those running Microsoft Defender and other endpoint security products that are listed as targets within STONESTOP’s configuration, along with business and security data residing in directories that may be subject to driver-driven deletion.

Impact

If successful, the attack can leave the environment temporarily without effective endpoint defenses while ransomware is executed, leading to encryption and potential loss of data, operational downtime while systems are restored, increased incident-response and forensic costs, and possible downstream obligations related to data loss or service disruption depending on what systems and data are affected.

Evidentiary Basis for Synopsis and Recommendations

Supporting observations from the analysis help clarify how the threat landscape, control environment, and organizational behaviors interact to shape overall risk exposure. These insights provide the foundation for identifying where controls perform well, where gaps or weaknesses create unnecessary vulnerability, and how attacker methods intersect with real-world operational conditions. Building on these findings, the recommendations that follow focus on strengthening resilience, improving decision-making, and guiding readers toward practical steps that enhance both security posture and risk-informed governance.

FAIR Breakdown

Threat Event Frequency (TEF)

Because the information focuses on a specific incident and a very small set of samples, TEF must be inferred from the broader pattern of ransomware campaigns that use EDR-killer tooling and custom packers rather than from hard counts. For a typical mid-sized organization running Windows endpoints, a reasonable speculative TEF for “hands-on ransomware with custom-packed EDR killer” is low-to-moderate, on the order of 2–3 meaningful attempts per year, recognizing that only a subset of total ransomware activity will use this particular style of loader and driver-based defense evasion.

Contact Frequency (CF)

The information shows a highly targeted, post-compromise tool (packer + EDR killer) used inside an already-breached environment, not an internet-wide scanning or phishing campaign, so CF is best interpreted as how often a given organization is pushed far enough down the ransomware kill chain that such tooling is deployed. For a typical enterprise in a commonly targeted vertical (general enterprise, services, manufacturing), it is reasonable to speculate moderate CF driven by automated scanning and opportunistic initial access activity, but only a small fraction of those broader contacts escalate to the stage where a custom packer and kernel-level EDR killer are deployed on hosts.

Probably of Action (PoA)

The use of a purpose-built packer, a kernel-level driver, and an EDR-killer payload indicates a highly motivated, financially driven threat actor that invests in bypassing endpoint defenses rather than relying solely on commodity encryptors. Once an actor has obtained sufficient access to deploy this toolchain, PoA is high: they have already committed resources, and the packer’s design suggests clear intent to proceed to ransomware execution and data destruction or encryption whenever feasible.

Threat Capability (TCap)

TCap is high, as the campaign demonstrates the ability to develop and maintain a custom packer, integrate it with an EDR-killer plus kernel driver, and operate it in a live ransomware intrusion.

Exploit sophistication: The information does not detail initial access exploits, but the defensive-evasion phase uses privilege escalation, driver registration, and systematic termination of security processes, indicating moderate-to-high sophistication in post-compromise operations even if initial vulnerability exploitation is not directly described.

Bypass ability: The EDR killer systematically kills AV/EDR processes and can delete files in specified directories, while the packer hides payloads with layered encoding, compression, and encryption and dynamically resolves imports; combined, this gives moderate-to-high capability to bypass standard endpoint defenses, tempered by the absence of advanced anti-analysis features and the presence of implementation bugs.

Tooling maturity: The packer design (payload-agnostic, configurable injection mode, layered protection) and the existence of multiple in-the-wild payloads suggest a maturing toolchain, though loader flaws and crashes imply incomplete QA and somewhat uneven development discipline; overall tooling maturity can be rated moderate.

Campaign success rate: The information documents at least one successful ransomware incident where the toolchain was deployed and additional samples found in the wild, but the small sample size prevents precise measurement; a reasonable speculative assessment is moderate success when the tool is actually deployed on endpoints, with failures introduced by crashes and environmental differences.

Attack path sophistication: The observed kill chain (ransomware intrusion, deployment of custom-packed EDR killer, driver loading, repeated termination of defenses, potential file deletion, and eventual ransomware execution) reflects a high degree of operational sophistication in post-compromise defense evasion and staging.

Cost to run attack: Development of a custom packer and integration with kernel-level components is non-trivial, but once built, per-attack costs are relatively low, involving infrastructure, operator time, and ongoing maintenance; for a financially motivated group this style of operation is clearly feasible and economically justified.

Control Strength (CS)

Across typical enterprises with mainstream EDR, kernel-driver blocklists, and monitoring, control strength against this specific toolchain is mixed: some environments will block malicious or vulnerable drivers and detect anomalous process-kill behavior, while others rely heavily on the very EDR processes being targeted. Overall CS can be considered moderate, with substantial variance depending on whether driver-blocking, application control, and robust telemetry are in place and tuned.

Resistive Strength (RS)

Effectiveness of preventive/detective controls:

• RS improves when organizations:

  • Enforce kernel driver blocklists (including known bad and vulnerable drivers)

  • Harden device-guard / application control policies for drivers and low-level components

  • Monitor and alert on security-process termination events

  • Monitor for unusual or repeated driver load and registration activity

• RS is reduced when:

  • Payloads concealed in PE resources are not inspected or behaviorally monitored

  • EDR/AV process-kill patterns are not explicitly detected and alerted

  • Driver behavior is not correlated with subsequent ransomware or destructive activity

• Net effect: many environments end up with only low-to-moderate RS against a custom packer plus EDR-killer toolchain unless they specifically monitor driver behavior and process-kill patterns.

Control Failure Rate

Control failure rate is moderate-to-high when organizations:

• Rely almost exclusively on endpoint agents as the primary detection and prevention layer

• Do not enforce strict driver policies or allow unsigned/unvetted drivers

• Lack runtime monitoring for mass security-process termination or repeated driver registration

• Typical gaps include:

  • Incomplete adoption or maintenance of vulnerable-driver blocklists

  • Limited or no alerting when EDR/AV processes are terminated repeatedly or unexpectedly

  • Weak correlation between suspicious driver activity and downstream ransomware indicators

• Net effect: these gaps significantly increase the likelihood that the described toolchain will bypass controls once it is deployed on compromised hosts.

Susceptibility

Given high threat capability and generally moderate control strength, overall susceptibility for a typical mid-sized enterprise to be harmed once the actor has reached the stage of deploying this toolchain is estimated around 40–60 percent, reflecting the fact that many environments will have partial but not comprehensive defenses for this specific pattern.

Exploitability: Estimated at roughly 60–70 percent at the “post-compromise deployment” stage, since the EDR killer targets known process names and leverages a driver to force terminations; crashes and bugs reduce reliability but not the fundamental exploitability of an unprepared endpoint estate.

Attack surface: Approximately 50–70 percent of Windows endpoints and servers in many organizations may be exposed if they run one of the targeted EDR/AV products and lack strict driver or application control policies, making them viable targets once the actor has foothold and lateral access.

Exposure conditions: During an active ransomware intrusion where the actor has administrative access on multiple hosts, exposure rises substantially; in that context, it is reasonable to estimate 60–75 percent of relevant systems could be exposed to this toolchain if not specifically hardened against driver-based EDR-killer behavior.

Patch status: Patch status on OS and applications has limited direct mitigating effect, because the described tooling focuses on driver registration and process termination rather than exploit-based initial access; at best, strong patching indirectly reduces how often an actor reaches this stage, but once they do, patching may only reduce risk by a modest amount (for example, 10–20 percent) unless it includes specific mitigations such as updated driver blocklists.

Numerical Frequencies and Magnitudes

All values relating to actual dollar amounts are for example/speculative purposes only. Organizations would need to take into account their own asset values, control strength, telemetry, etc., and adjust numbers accordingly.

Loss Event Frequency (LEF)

1/year (estimated)

• Justification: Assuming a speculative TEF of 2.5 relevant ransomware intrusions per year where the actor could deploy such a toolchain and a vulnerability (probability of harm per contact) of about 0.4, the resulting LEF is roughly 1 successful loss event per year for a typical mid-sized organization that is a viable ransomware target.

Vulnerability (probability of harm per contact): .4

• Justification: Given high threat capability but only moderate control strength and some adversary-side instability, it is reasonable to estimate that about 40 percent of cases where this toolchain is deployed on hosts lead to successful disabling of defenses and meaningful harm (encryption or destructive impact) before detection and response.

Secondary Loss Event Frequency

0.5/year (estimated)

• Justification: Not every primary ransomware or destructive event driven by this toolchain will generate significant secondary losses (such as regulatory, legal, or customer-impact costs), but where critical or sensitive systems are affected, secondary consequences are plausible; assuming roughly half of primary events have material secondary effects yields an SLEF of about 0.5 per year.

Loss Magnitude

Estimated range:

• Min: $50,000

• Most Likely: $400,000

• Maximum: $2,000,000

Justification:

• The minimum value reflects localized impact on a small number of systems, containment, IR labor, and restoration from backups. The most likely value assumes disruption to key business services, broader endpoint recovery, overtime for IT and security teams, and some productivity loss. The maximum represents scenarios where core business systems are encrypted, downtime extends into days, and recovery requires extensive rebuilds and third-party IR support, but still short of existential or multi-region catastrophic loss.

Secondary Loss Magnitude (SLM)

Estimated range:

• Min: $100,000

• Most Likely: $600,000

• Maximum: $3,000,000

Justification:

• Secondary losses may include contractual penalties, incident notification costs, regulatory or legal expenses, reputational remediation, and customer churn if business-critical or sensitive systems are impacted. The upper bound accounts for significant regulatory scrutiny or major customer impact for a mid-sized organization, while recognizing that very large enterprises or highly regulated entities could see higher exposures that should be modeled with their own data.

  
  

Mapping, Controls, and Modeling

MITRE ATT&CK Mapping

Resource Development

T1587.001 – Develop Capabilities: Malware

Reference: “a detailed technical analysis of TangleCrypt, a previously undocumented packer for Windows malware… first packed with VMProtect, and subsequently with a custom executable packer that we are tracking as TangleCrypt” and “a malware packer known as HeartCrypt and well documented by Palo Alto… we concluded that we were dealing here with a completely different malware packer.”

Execution

T1055 – Process Injection

Reference: “‘b1.exe’ starts a child process of itself in suspended state, writes the decrypted content to the child process memory and finally resumes its main thread… via the Win32 API functions CreateProcessW, WriteProcessMemory and ResumeThread in KERNEL32.DLL.”

Defensive Evasion

T1027 – Obfuscated/Encrypted File or Information

Reference: “The payload is stored inside the PE Resources via multiple layers of base64 encoding, LZ78 compression and XOR encryption… The '.rdata' section is full of 0x8D7-size areas which are 0x00 bytes but all encrypted with the same XOR key, resulting in the same byte pattern and thus having a low entropy.”

T1027.007 – Obfuscated/Encrypted File or Information: Dynamic API Resolution

Reference: “To hinder analysis and detection, it uses a few common techniques like string encryption and dynamic import resolving… TangleCrypt uses the string encryption feature also to decrypt strings of Windows DLL names and API function names, which are then used to dynamically resolve their virtual address.”

T1036 – Masquerading

Reference: “‘fehmr.sys’ – an x64 kernel driver, packed with VMProtect, and masquerading as a CrowdStrike Falcon Sensor driver.”

T1140 – Deobfuscate/Decode Files or Information

Reference: “This is a base64 encoded string, which the loader decodes… It turns out that this is an LZ78 compressed buffer, and the loader calls a function to decompress it… The loader uses the number sequence… as a XOR key to decrypt this buffer. And this is finally the original executable.”

T1562.001 – Impair Defenses: Disable or Modify Tools

Reference: “Such tool forcefully terminates the installed security products on the device… The executable contains a list of executable names and uses the driver to terminate all running processes matching an item in this list… all found executables target Microsoft Defender and usually one or two other EDR/AV vendors.”

T1622 – Debugger Evasion

Reference: “the loader calls two Win32 API functions LocalHandle and GlobalSize with the first and only argument set to NULL… This triggers an Access Violation exception… we rather suspect that the authors included this trick as a countermeasure against code tracers – for example used in some automated sandboxes – since an exception might confuse them.”

Impact

T1485 – Data Destruction

Reference: “Some STONESTOP versions also have a hard-coded list of directories. All files in these directories will be recursively deleted by the driver.”

T1486 – Data Encrypted for Impact

Reference: “before conducting malicious operations like data exfiltration and file encryption in ransomware attacks… the threat actor deployed Qilin ransomware on the victim’s systems.”

NIST 800-53 Affected Controls

SI-3 — Malicious Code Protection

Use of a custom packer (TangleCrypt) to conceal malware payloads and deployment of an EDR killer prior to ransomware operations directly threaten the effectiveness of malicious-code protection controls that are meant to detect and block such code.

Reference: “a previously undocumented packer for Windows malware… their payloads were both identified as an EDR killer known as STONESTOP… used in a recent ransomware attack… before conducting malicious operations like data exfiltration and file encryption in ransomware attacks.”

SI-4 — System Monitoring

STONESTOP’s repeated termination of security processes and continuous background operation, along with abnormal driver registration and process injection behavior, are activities that robust monitoring should detect but which this toolchain is designed to evade.

Reference: “The executable contains a list of executable names and uses the driver to terminate all running processes matching an item in this list… The executable keeps running in the background. The termination of any running ‘unwanted’ process is repeated every second… the loader starts a child process of itself in suspended state, writes the decrypted content to the child process memory and finally resumes its main thread.”

SI-7 — Software, Firmware, and Information Integrity

The use of a malicious kernel driver that masquerades as a legitimate security product undermines integrity controls intended to prevent unauthorized or altered code from running in privileged contexts.

Reference: “‘fehmr.sys – an x64 kernel driver, packed with VMProtect, and masquerading as a CrowdStrike Falcon Sensor driver… We identified the kernel driver being ABYSSWORKER… a malicious driver specifically created for this purpose.”

CM-6 — Configuration Settings

Reliance on vulnerable or malicious drivers (BYOVD and custom drivers) to disable defenses highlights weaknesses in platform and driver configuration policies, such as insufficient enforcement of driver blocklists and secure configuration baselines.

Reference: “either by exploiting a vulnerable driver (BYOVD), or via a malicious driver specifically created for this purpose… most ABYSSWORKER samples that we found elsewhere… packed with VMProtect,” indicating repeated use of driver-based techniques against standard configurations.

CM-7 — Least Functionality

Allowing unnecessary or broadly-permissive driver loading and execution of unsigned or unvetted packed binaries increases system functionality beyond what is required, creating the conditions for TangleCrypt-packed EDR killers to operate.

Reference: “Just like most malware packers, TangleCrypt’s main objective is to hide the actual payload and make it look like a benign file… a malicious driver specifically created for this purpose… the executable assumes that the SYS file is present in the same directory. Then it tries to load and initialize the driver,” illustrating over-permissive support for arbitrary drivers and packed executables.

Monitoring, Hunting, Response, and Reversing

Monitoring

Monitoring should prioritize endpoint and OS telemetry that can surface driver registration, process injection, and repeated security-process termination, supplemented by network, identity, and DNS data to confirm host- and account-level impact. Endpoint and kernel telemetry (driver loads, service changes, process creation, process termination, and registry modifications) must be collected at sufficiently granular log levels to capture ABYSSWORKER driver registration, repeated termination of EDR/AV processes, and long-running background executables matching STONESTOP-like behavior; in many environments this requires raising log levels for driver events, process-termination events, and security-product health/status logs. Key indicators include executables packed with uncommon PE-resource structures, processes that immediately register or load a new driver and then begin terminating security products every second, and variants that recursively delete files in fixed directories, all of which should drive high-severity alerts when correlated. Monitoring gaps exposed by this threat include weak visibility into kernel driver loading, limited inspection of PE resources, and the absence of specific detections for mass security-process termination, so correlation logic should tie together “new or masquerading driver load + targeted EDR/AV process kills + background persistence of the same executable,” with thresholds tuned to treat repeated kills of security processes as a critical event even on a single host. Dashboards and metrics should be updated to track trends in driver-block events, security-process restarts or unexpected exits, and counts of hosts exhibiting these behaviors, with validation performed through controlled simulations (e.g., test drivers, benign process-termination tests) and replay of captured artifacts where available to ensure alerts fire as intended without overwhelming operators.

Hunting

Hunting hypotheses should assume that a capable ransomware actor has already obtained elevated access and is using a custom loader and EDR-killer driver to clear endpoint defenses prior to encryption, focusing on “hosts where security processes repeatedly die after a driver load” and “binaries with unusual PE-resource-based payload storage.” Telemetry sources should include EDR logs, Windows event logs for driver and service activity, Sysmon or equivalent for process and module events, AV/EDR health logs, and any available PE metadata from file-scanning systems, optionally augmented by network telemetry to spot suspicious outbound activity from hosts where security tools have gone dark. Detection logic for hunts can center on sequences such as new or unusual kernel driver registration followed shortly by termination of multiple security processes, executables whose behavior includes repeated process-kill loops, or PE files with sparse sections and a small number of resource entries inconsistent with normal software. Noise-to-signal management will require whitelisting legitimate drivers and maintenance operations that stop security processes under change windows, refining hunts around drivers that masquerade as security products and around patterns of process termination that repeat every second or over extended periods, so that analysts can zero in on true EDR-killer behavior tied to custom-packed payloads.

Response

Response should assume the need for detailed host-level evidence, including Windows security and system logs, EDR telemetry, driver installation and load events, process creation and termination logs, and file-system activity on directories that may have been targeted for deletion, alongside collected copies of suspicious executables and driver binaries. Expected artifacts include one or more packed executables with unusual PE-resource layouts, a malicious or repurposed kernel driver masquerading as a legitimate security component, and logs showing repeated termination of security processes and possible recursive deletion of files in specific directories, which together support reconstruction of the sequence from loader execution to driver registration, EDR-kill behavior, and any subsequent ransomware or destructive actions. Anti-forensic behavior here manifests primarily as disabling or removing the very security tools that would normally collect evidence, so reconstructing events will depend on surviving logs from before termination, upstream log-forwarding infrastructure, and any residual forensic artifacts on disk and in memory. DFIR outputs—such as the time window between defense impairment and encryption, the number and type of systems affected, and the extent of file deletion—should be fed into FAIR loss estimates to refine Loss Event Frequency and Loss Magnitude for future modeling. Likely containment will involve isolating affected hosts, blocking the malicious driver and associated binaries via hashes and driver policies, restoring security tools, and searching for similar artifacts across the estate. Priority artifacts include the packed executables, the malicious driver, and full event/EDR traces around their execution, and telemetry requirements extend to driver-block events, security-process status, and backup/restore logs. IR gaps often include limited historical driver telemetry and insufficient logging of process-termination patterns, so validation strategies should include post-incident tuning, replay of captured samples in a lab, and simulated driver/EDR-kill scenarios to ensure future incidents are detected earlier.

Reverse Engineering

Reverse engineering should focus on understanding TangleCrypt’s loader behavior—how it reads encrypted payloads from PE resources, applies layered base64, LZ78, and XOR decoding, and then chooses between in-process and child-process execution based on embedded configuration strings—so that reusable unpacking methods and structural signatures can be derived. Analysts should document evasion techniques including string encryption, dynamic import resolution, unoptimized and deliberately noisy control flow, and the small anti-debugging trick that deliberately triggers benign access violations, noting that these are relatively weak and sometimes buggy compared to more advanced packers. Persistence appears to rely mainly on STONESTOP running in the background and repeatedly killing security processes, so reverse engineering should also characterize that loop, the driver-registration logic, and the optional recursive file-deletion behavior rather than inferring additional persistence that is not evidenced. Indicators to extract include distinctive resource-section patterns, decoding routines, numeric key formats, driver names and metadata used to masquerade as security software, and the list of targeted process names and directories. Recommended dynamic and static hooks include breakpoints around resource-access functions, decompression and decryption routines, driver-registration calls, and process-termination APIs, plus broader malware-reversing practices such as building YARA and behavioral rules from unpacked samples and comparing variants over time to track changes in configuration strings, targets, and reliability.

CTI

From a CTI perspective, PIRs should be tuned to determine whether this style of EDR-killer toolchain and custom packer is appearing in the organization’s sector, geography, or among its partners, how often similar ransomware operations recur, which TTPs (driver-based defense evasion, packer design, process-kill loops, file deletion) are consistent across incidents, and which assets (Windows servers, administrative endpoints, specific EDR products) are repeatedly targeted. SIR work should identify missing IOCs such as hashes of TangleCrypt-packed samples and associated drivers, any infrastructure used for command and control or payload distribution, gaps in attribution confidence around the actor behind this tooling, and the specific logs and telemetry needed from internal sources to confirm or refute potential sightings of this behavior. Collection recommendations include sustained monitoring of vendor blogs, threat reports, malware sandboxes, and repositories for new TangleCrypt/STONESTOP/ABYSSWORKER variants, mining internal telemetry for recurring patterns of EDR/AV termination and driver anomalies, engaging with sector ISACs/ISAOs to compare observations, and, where appropriate, watching dark web or leak sites for ransomware campaigns that mention or exhibit similar defense-evasion behavior. Mapping work should cluster related samples and infrastructure into coherent campaigns, map observed TTPs to ATT&CK techniques already identified (e.g., driver-based defense impairment, process injection, obfuscation), compare those patterns with historical ransomware incidents, and assign confidence levels to relationships between tooling, operators, and sectors. CTI should continuously update emerging-pattern assessments—such as shifts in targeted security products, changes in packer reliability, or new execution modes—and use those to validate or refute existing hypotheses about the actor’s priorities and maturity, feeding refined threat, frequency, and capability assessments back into FAIR models, monitoring priorities, and governance discussions.

GRC and Testing

Governance

Governance updates should ensure policies explicitly address driver-governance requirements, packed-binary restrictions, and post-compromise defense-evasion risks highlighted by TangleCrypt and the ABYSSWORKER/STONESTOP toolchain. Oversight functions should require regular review of driver blocklists, EDR-process protection configurations, and code-execution policies for executables with unusual PE-resource structures. RA, PM, and PL family documents should be updated to incorporate governance for kernel-level components, validation of software integrity prior to execution, and expectations for endpoint telemetry retention when security controls are disabled. The risk register should add or update entries for driver-based defense impairment, custom packer usage, and mass EDR-process termination, noting their contribution to ransomware loss magnitude. Board and executive reporting should summarize the organization’s exposure to driver-loading risks, gaps in visibility into security-process termination, and the expected financial impact modeled in FAIR, ensuring leadership understands required investment in monitoring, hardening, and policy enforcement.

Audit and Offensive Security Testing

Audit and testing activities should validate whether driver-control policies, EDR self-protection configurations, and monitoring rules are functioning as defined, with particular emphasis on gaps where ABYSSWORKER-style drivers or TangleCrypt-packed binaries could bypass controls. Evidence gaps—such as limited telemetry for driver loads, missing logs for repeated security-process termination, or insufficient retention of pre-crash events—should be documented and prioritized for remediation. Auditors should confirm that relevant SI-, CM-, and AC-family controls are implemented as written and enforceable. Red-team and purple-team exercises should include simulation of driver loading, process-kill loops, and execution of PE-resource-packed binaries to validate detection and containment pathways. Pen-testing scope should include attempts to load unsigned or masquerading drivers and reproduce the EDR-kill behavior to determine whether controls trigger appropriately. Control validation should ensure that logs are generated, alerts fire at the correct thresholds, and compensating controls (e.g., allowlists, blocklists, EDR hardening) perform reliably across representative systems.

Awareness Training

Training should reinforce user awareness of behaviors that enable ransomware operators to advance far enough into the intrusion to deploy tools like STONESTOP, focusing on human failure modes such as approving unverified admin prompts, running unknown executables, or bypassing security warnings. Role-specific adjustments should target administrators—who are most likely to encounter driver-loading prompts or execute binaries manually—as well as finance, operations, and customer-facing staff who may be manipulated into actions that provide early footholds. Employees should be taught to recognize behavioral indicators such as unexpected UAC prompts, repeated crashes of security tools, or files disappearing from key directories, and to escalate these immediately. Phishing simulations should incorporate more realistic pre-ransomware patterns rather than simple credential-harvesting lures. Communication guidelines should emphasize verifying software-install requests, scrutinizing system-level prompts, and reporting suspicious activity in booking, account-management, or customer-data workflows. Reinforcement cycles should measure reporting rates, correct-response rates, and changes in susceptibility over time to ensure training effectively reduces the likelihood that human actions enable later-stage defense-evasion tooling.

Indicators of Compromise

0b4295bcd7bf850fea2b1bc09f652da028af33d625b11781ac875c603a52e5a8

0e7930481e53e4fc79a6aa9d1b037b4127d66a3138b8a1a03f1fc50ddec9f0a6

0eaa413dc13bc846258e5b4670142bea20e567065b7f4bbc135fe62d93878160

147dee11a406a86dd9b42982c091e8acbaca13614edb75f447cbaffb23017a90

15cd13e0cad20394ec1405748e4bd50e3f27313c6274aee098c4eb0ede970b4c

2073d94af0aa560c11e3399d2b83a720ee373a46ccf835486e57c37e3d1d9a25

28fa1789fff41060e35496507d518a032c2a6142712843eb98ff63f6ec99997a

2936f5f3ff24f5bb42eace4ad2d64989b19dc6cd75d8f4ee83496ee6bdf169f6

43cd3f8675e25816619f77b047ea5205b6491137c5b77cce058533a07bdc9f98

4686bf07db10376fb4c8ce3b729c4ab60d89b454fc57feb39f9607cb43a081d9

48e6e071b70566bc9fabbbff995946076b410f5459356b65051ae10e04fe512f

49ed990459486e569cd1428b045baff1e61b86cdeef84a75384b5f7f46bd678e

5baf5445c4b22c645ff6d509a744e0b6c96fe5c5ea84ed471421af890cfd8533

5c8f53bd9eb13ac07ca5190ed0946c9feb5c73627bf5c0c9e79b28626310ad90

5e423483165666976997e17b9834b9f6bd0da6c4b0da23f45584203f7c08fe4c

77e089dfeb1d114d4171e461e0c4f36b895ed8ef5ee23e8b243bdf491837b5b6

9dd36887e84ec25414fee984e22e42b1a76e893f1d476d689d89719ffe8077ff

aae2e7f4feb75a61c98a727a9da9c3eba213e9e43aa7c9e81e2b3c2f6439b908

b8c1f3d24f0282c84ed599147462d4031df43cd4fceef38afcee4b3fc8f16e7b

d2939cd18c9072488767520be081fef71d560896c6293b6633cab099fcd238ae

ddf23db6881e42e65440c26a208c9175ad705c708f0a5d8426a2636bad79777c

df6cb5199c272c491b3a7ac44df6c4c279d23f7c09daed758c831b26732a4851

e6309fdb03313dd1b62467684a49692de5c27bbc3c17e65e2010cfbf686a4bf3

f11930cb70556941b6e3c8530956f1381a4cdbd1e3fe8e9f363487a73b45a9c0

f1c37f93d000134b4bfe439add26f3c146958dd87b230123d58790fedce6336a

f51397bb18e166c933fe090320ec23397fed73b68157ce86406db9f07847d355

fb3fc93dc627c7dfd8d95c1d66c2cb66caac92783b6d6eb33ac5b91647871ae6

0142346650907fe3b7ef7313be6863b15413b17b1ee900efa77f9b7c923718cf

05f8f514d1367aca856564af5443a75f47d22a30ce63f0b024a41e6b9553a527

06eccd102c9105957773b32538943531d9c39d0a504ceb3b9b155e97e3b0b134

1e42c8cb410a7ed653cfe62bbd8cf191f31a47337fe1ffcc35232d03f2da05ef

3fbe5a1ed857a6736e061a6850706f9e8a7e881f024bff044df1c34795b89bf4

6a2a0f9c56ee9bf7b62e1d4e1929d13046cd78a93d8c607fe4728cc5b1e8d050

927e3aef03a8355d236230cace376b3023480a40c5ac08453c07dab343dd1f11

a2e49aaa95f50438153ca6e55c909229df3a006b324622cc32477479de0afb6b

efb642ad3fab4a2e6cb4de829b60e04dd0d9ae7c2b4cf544de28c38f978b4136

73b6e7cdd10c373a633367fd3bde791278e7900b342a21e2bad2b8e5cfc33746