How Windows 11 24H2 Disrupts Malware Self-Deletion & How Cybersecurity Teams Respond

The ongoing race between cybersecurity defenders and threat actors is defined as much by shifting technical frontiers as by ingenuity and adaptation. Nowhere is this dynamic more vividly demonstrated than in the persistent evolution of malware evasion techniques and the operating system updates designed to thwart them. Windows 11’s 24H2 update, released as part of a wave of refinements and enhanced security features, has unexpectedly disrupted one of the malware community’s most relied-upon self-deletion techniques—the Lloyd Labs method. Long favored by adversaries for its effectiveness in erasing digital footprints, this method now faces an existential challenge on Microsoft's newest operating system. But as the dust settles, the rapid collaboration within the cybersecurity community has yielded a workaround nearly as swift as the disruption itself, underscoring the relentless push and pull of this technical arms race.

The Lloyd Labs Self-Delete Technique: A Digital Vanishing Act​

For years, the Lloyd Labs self-delete technique has been a critical tool in the toolkit of malware authors and, on occasion, legitimate security researchers seeking to test containment strategies. Its genius lies in its ability to remove all traces of malware from a compromised system immediately after execution, right down to the file’s presence on disk. Such complete erasure significantly hampers forensic analysis, complicating both live incident response and post-mortem investigations.

Anatomy of the Technique​

The traditional Lloyd Labs self-delete method unfolds through a meticulously orchestrated seven-step process exploiting nuances in the NTFS filesystem's file handle and access permissions mechanics:

• Opening the File with DELETE Access: This establishes the groundwork by allowing manipulation at the filesystem level.
• Renaming the Primary Data Stream: The malware changes the file’s principal identifier.
• Closing the Handle: This step commits the rename, freeing system resources.
• Reopening the File: Reacquiring a handle allows further manipulation.
• Setting the Deletion Disposition: The file is marked for deletion.
• Deleting and Closing Handles: With all handles closed, NTFS processes the delete request, and the file vanishes from the system.

Under Windows 10, Windows 11 23H2, and all earlier versions, this sequence enabled a process to delete even its own executable while running—a capability often blocked by operating systems to prevent both legitimate and malicious use cases.

Windows 11 24H2: The Disruption​

With the arrival of the Windows 11 24H2 update, security researchers and malware authors alike noticed something odd: self-deleting malware suddenly failed to erase itself completely. What initially appeared to be sporadic failures quickly crystallized into a pattern as researchers performed proof-of-concept tests against the new OS.

What Changed Under the Hood?​

A collective of investigators, notably from threat intelligence and reverse engineering circles such as TKYN, dug deeper. Through kernel debugging and reverse engineering—leveraging tools like Ghidra and WinDbg—they compared the new NTFS.sys driver with its predecessor. Central to their findings was the altered behavior of the NtfsSetDispositionInfo function, which handles file deletion requests at the driver level.
Specifically, attempts to carry out the SetDispositionInformationFile system call on memory-mapped files (a core step in the Lloyd Labs method) would now trigger the error code 0xF216D. Further analysis revealed that instead of deleting the file outright, NTFS as of 24H2 moves the original file contents into an alternate data stream, leaving the file "appearing" empty but persisting on the disk.
This approach, likely intended to bolster system stability and address race conditions or bugs related to file deletion, inadvertently undermined one of the principal malware evasion strategies.

Key Technical Findings​

• Error Code 0xF216D: Returned during deletion attempts on memory-mapped files, indicating a fundamental change in allowable operations.
• Alternate Data Stream Persistence: Files slated for deletion retain their content in a hidden stream, defeating “true” file erasure.
• Enhanced Security Checks: The NTFS.sys driver in 24H2 introduced robust checks during file disposition, shifting from previous deletion logic.

These changes were verified through side-by-side kernel tracing, bytecode analysis, and direct empirical testing, lending high confidence to the technical claims made by researchers and published in reputable cybersecurity trade sources.

Why It Matters: Beyond Malware​

While the intended disruption targeted shadowy actors, the affected technique is not exclusively the province of malware authors. Security teams and administrative tools sometimes legitimately leverage self-delete functions for software cleanup, sensitive data lifecycle management, and containment or incident simulation. The side-effect of Microsoft’s changes, therefore, reaches into the broader world of endpoint management—a reminder that the battlefield between attack and defense is sometimes crowded with bystanders.

The Community’s Response: Engineering a Workaround​

Faced with the new limitations, cybersecurity researchers responded rapidly. Detailed analysis and community collaboration pinpointed a workaround rooted in Windows’ growing support for POSIX (Portable Operating System Interface) semantics—a nod to cross-platform compatibility and enterprise-grade security.

The New Playbook: FILE_DISPOSITION_POSIX_SEMANTICS​

The successful workaround leverages two flags in the updated file deletion logic:

• FILE_DISPOSITION_DELETE: The standard flag for marking files for deletion.
• FILE_DISPOSITION_POSIX_SEMANTICS: Newly significant in 24H2, it instructs NTFS to adopt UNIX-like file removal logic.

By deploying these flags in combination with the FileDispositionInformationEx structure—rather than the now-insufficient FileDispositionInfo parameter—and invoking the NtSetInformationFile routine, security tools (and malware) can once again achieve comprehensive self-deletion, even under 24H2.
Here’s a simplified illustration:

FILE_DISPOSITION_INFORMATION_EX info = {0};
info.Flags = FILE_DISPOSITION_DELETE | FILE_DISPOSITION_POSIX_SEMANTICS;
NtSetInformationFile(FileHandle, &statusBlock, &info, sizeof(info), FileDispositionInformationEx);

The approach has been corroborated by independent sources and stands up in tests against patched 24H2 environments, restoring full self-delete functionality without leaving residual alternate data streams or forensic crumbs.

Critical Implications​

• Security Vendors: Needed quick adaptation to ensure their exploit simulation tools and endpoint protection suites could still self-destruct cleanly for testing and containment scenarios.
• Malware Authors: Rapidly updated codebases, as evidenced by emerging samples exploiting the new deletion technique.
• Incident Responders: Must now account for both pre- and post-24H2 deletion traces, incorporating the presence of alternate data streams as a new investigative avenue.

Microsoft’s Balancing Act: Security vs. Usability​

Microsoft’s changes to the NTFS driver in 24H2 likely stemmed from legitimate efforts to make file handling more robust, prevent system crashes, and close potential loopholes that could be weaponized in low-level attacks. Good engineering sometimes has to weigh the risk (malware using self-deletion) against the reward (preventing accidental or premature deletion of files in use, which could cause system instability).
Yet, as this episode demonstrates, any change to core file system behavior inevitably ripples outwards, affecting both adversarial and legitimate use cases. Microsoft has so far not issued an official statement on the exact rationale behind the NTFS change—this lack of clarity leaves some room for speculation about intent and downstream implications.

The Cat-and-Mouse Game in Focus​

This rapid cycle of “patch and adapt” reflects the broader reality of cybersecurity on modern operating systems:

• Attackers constantly probe under-the-hood changes to repurpose or bypass new protections.
• Defenders have to test their tools and adjust methodologies after every significant OS update.
• Vendors must communicate clearly with users when breaking changes have far-reaching effects—ideally ahead of time.

The Lloyd Labs self-delete disruption and the community’s subsequent adaptation serve as a microcosm of this constant technical duel. Ironically, the attempted improvement in system security produced both a temporary defense and, by revealing the effectiveness of POSIX-based file deletion on NTFS, a new avenue for both legitimate and malicious actors.

Forensic Impact: New Artifacts, New Analysis Paths​

With 24H2’s NTFS change came an unintentional side effect: forensic investigators now gain a new type of evidence. When self-delete attempts fail using the old method, residual data gets tucked away in alternate data streams—a less familiar but still recoverable part of the NTFS file structure. Awareness of this artifact can aid post-compromise analysis, making previously impossible recoveries feasible for a short window until the newer evasion techniques become dominant.
Incident response teams should enhance their detection and recovery scripts to scan for these “orphaned” alternate data streams, which may harbor both malicious payloads and clues about attacker methodology.

The Road Ahead: Continuous Adaptation Required​

This episode underscores several enduring truths for organizations managing Windows environments:

• Continuous Validation: Security and administrative tools must be regularly tested against the latest OS builds to avoid unanticipated failures.
• Universal Target: Operating systems are under constant pressure to balance security improvements against the risk of breaking established (often undocumented) behaviors.
• Rapid Coordination: The cybersecurity community’s rapid response—dissecting, publicizing, and neutralizing the impact of deep technical changes—remains vital to resilience.

Recommendations for Organizations​

• Inventory Self-Deleting Tools: Identify and test any tooling (legitimate or otherwise) that depends on NTFS self-deletion, updating techniques as necessary for 24H2 compliance.
• Monitor Alternate Data Streams: Integrate this check into your endpoint security stack.
• Stay Informed: Monitor Windows release notes, threat intelligence feeds, and kernel-level technical bulletins for changes affecting security tools and incident response plans.
• Engage in Proactive Testing: Include simulated malware and red-team scenarios on up-to-date test environments to expose any stealthy persistence mechanisms.

Conclusion: In Search of Lasting Security​

The temporary obsolescence—and rapid resurrection—of the Lloyd Labs self-delete technique in Windows 11 24H2 both highlights and challenges the assumption that technological progress alone will yield improved security. In reality, advances in operating system robustness and anti-malware postures are perpetually offset—if not outpaced—by the determination and sophistication of adversaries.
The ultimate lesson? Every system update is a double-edged sword demanding vigilance, agility, and, above all, a commitment to understanding the ever-evolving dance between offense and defense. As long as operating systems continue to evolve and new adversarial techniques emerge, the frontline of cybersecurity will remain as dynamic and contested as ever, with each new Windows release sure to produce both newfound strengths and unforeseen risks.

---

Source: CybersecurityNews Windows 11 24H2 Disrupts Self-Delete Technique Used for Malware Evasion