The SafeBreach Labs team is committed to conducting original research to uncover new threats and ensure our Hacker’s Playbook provides the most comprehensive collection of attacks. As part of my recent research, I uncovered multiple zero-day vulnerabilities that I was able to use to turn endpoint detection and response (EDR) and antivirus (AV) tools into next-generation wipers with the potential to impact hundreds of millions of endpoints all around the world. 

This wiper runs with the permissions of an unprivileged user yet has the ability to wipe almost any file on a system, including system files, and make a computer completely unbootable. It does all that without implementing code that touches the target files, making it fully undetectable. I first presented this research in a presentation at BlackHat Europe today. This is a summary of the presentation. 

In this research report, I will provide a high-level overview of current-day wipers, including how they work and what they are used for. I will then explain my research process and how I discovered multiple zero-day vulnerabilities that enabled me to create a powerful next-generation wiper. Finally, I will discuss how SafeBreach is sharing this information with the security community and what organizations can do to protect themselves. 

How Current-Day Wipers Work

To understand the details of this next-generation wiper, it’s important first to understand exactly what wipers are and how they work. As defined on Wikipedia, “a wiper is a class of malware intended to erase (wipe, hence the name) the hard drive of the computer it infects, maliciously deleting data and programs.” Wipers have become a go-to tool for advanced persistent threat (APT) groups as they conduct cyber warfare and are increasingly used as an offensive act to support physical warfare. A very good example is the current war between Russia and Ukraine—both sides have been attacked by wipers. Iran, Israel, and Saudi Arabia have also been targeted by wiper attacks in recent years. 

When you hear the word wiper, you probably think about the concept of deletion. But there is actually a crucial difference between the two. In Windows, when a certain process calls the DeleteFile() API function, this function asks the kernel to delete a certain file. The kernel then goes to the master file table (MFT), and marks a certain entry as free. This entry is just a pointer to the actual file content. The actual file content is not really being deleted—it stays on the disk. That is the difference between a deletion and a wipe. When something is wiped, it means that the actual content is being completely erased and is not restorable. 

But there is a way to achieve a wipe using a deletion. According to the Microsoft Developer Network (MSDN), “When files are deleted from a New Technology File System (NTFS) volume, their MFT entries are marked as free and may be reused.” That means a newly created file can use the same free MFT entry. Writing to a file that was given an MFT entry that was previously used by a deleted file allows a user to overwrite the actual content of the deleted file. When I researched how famous current-day wipers overcome the gap between a deletion and a wipe, I saw that many do not delete files but instead overwrite them. In this way, they can ensure they are changing the actual content of the file and, as a result, really erasing it.

Well-known wipers like Shamoon, CaddyWiper, DoubleZero, IsaacWiper, KillDisk, and Meteor use this technique—they basically open their target files and overwrite them to ensure they are replacing the original contents of the file. However, this technique requires high privileges. For example, if the wiper wants to delete certain files from an administrator user folder, it needs to have the privileges to the files in those folders. That is true for system files as well. Thus, these wipers will generally run with administrator privileges. 

Another technique that current-day wipers use is the drive-destruction technique. With this technique, the wiper opens the drive as a device and starts writing directly to it. As a result, it can overwrite the boot-sequence structures that belong to the NTFS and file contents. Well-known wipers using this technique include IsaacWiper, KillDisk, Petya wiper variant, SQLShred, StoneDrill, WhisperGate, and DriveSlayer. But again, this option also requires administrator privileges, because an unprivileged user should not be able to ruin everything on the hard drive completely.

An important item to note here is that each of these wiper techniques and any other wiper technique that I researched for that matter,are obviously initiated by the process of the wiper itself. That means EDRs or anyone else attempting to analyze what has happened after an event like this takes place can easily use data collected from process monitoring to see that conspicuous API calls have been used to open files and then write to them, clearly identifying them as wiper techniques. 

Creating A Next-Generation Wiper

I began my research with two what-if scenarios I wanted to test: 

• What if there was a next-generation wiper that didn’t use these obvious API calls to wipe files? 
• What if this next-generation wiper could also wipe these files as an unprivileged user? 

This idea made me think about Aikido, a martial art that specializes in using the power of an opponent against them. EDRs have a very special superpower: the ability to delete any file on a system, no matter the privileges required to delete it. They have this ability because any file on the system could potentially be malicious, so they must be able to take action if necessary. Using the mindset of Aikido, I set out to see if I could use that power against EDRs to delete a target file as an unprivileged wiper. 

Triggering a Deletion

At this point, it is helpful to understand when EDRs choose to delete or quarantine files. This, of course, depends on the configuration. But I did see a common default configuration that enables EDRs to automatically delete or quarantine files they identify as malicious. Some do this when files are open, and they detect them as malicious. Other EDRs do this once files are closed after they are written to. And still, other EDRs take action in both scenarios. But most EDRs do offer an option for a scan, whether it’s a custom scan of a custom path on the file system or just a general system scan. 

An important takeaway here is that even as an unprivileged user, I do have a certain amount of control over the EDR—I can create a malicious file and, as a result, trigger a file deletion. So, I just needed to figure out how to trigger that deletion for the wrong file. 

The first idea I had was to write some malicious content to an innocent file, and then wait for the EDR to delete that. But there are two problems with this method. The first is that many important files a wiper may want to wipe require write permissions that the wiper does not have. The second problem is that this process is very similar to the file-overwrite technique from the perspective of the needed API calls. So I gave up on that idea. 

The second idea I had was to somehow point the EDR toward a different path to delete while convincing it that it is deleting the original, intended path. These vulnerabilities are usually achieved using links. The category of link vulnerability—CWE 59—is very famous in the cybersecurity industry. Microsoft even realized that they needed to give a special user right, which they called the “create symbolic links” user right, to enable users to create symbolic links (symlinks) because they are commonly used in a vast amount of privilege escalation vulnerabilities. This user right is only given by default to administrators, and other users must be given it manually by an administrator.

Junction points are another type of link that can be created on NTFS. I began to think about the difference between junction points and symlinks. If we look at a local directory symlink and a junction point, there is no difference from a high-level perspective. However, unlike a symlink, a junction point can be created by an unprivileged user. I quickly realized that I might be able to use a junction point link, but I still needed to find the right window of opportunity. 

Finding the Window of Opportunity

There are two main events when an EDR deletes a malicious file. First, the EDR identifies a file as malicious and then it deletes the file. If I could do something between these two events, using a junction, I might be able to point the EDR towards a different path. These are called time-of-check to time-of-use (TOCTOU) vulnerabilities.

To understand how to point an EDR toward a specific point during this window of opportunity, let’s look at this example. Let’s say that as an unprivileged user, I want to delete a .sys file, which is a driver contained inside the directory C:\Windows\System32\drivers. Of course, as an unprivileged user, I cannot delete that file. But I can create a special path that is very, very similar to the path that I want to delete, with one main difference: most of the path is contained inside a directory that is under my control as an unprivileged user. In this case, it would be C:\temp\Windows\System32\drivers, and I created the .sys file at this location. 

If I triggered a privileged program to attempt to delete that specially crafted path but, just before the deletion happened, I deleted everything from inside the temp directory and switched the temp directory to be a junction towards the C:\ drive, then the same path that the EDR or the privileged program tried to delete would actually lead to the original .sys file. 

And that is exactly what I tried to do. I created a Mimikatz file in the specially crafted path above, then immediately after the creation, deleted the temp directory with the Mimikatz file inside and instead created a junction that pointed toward the C:\ drive. 

I hoped the EDR or the AV would delete my target file, but that didn’t work. During this process, I observed two main behaviors. The first was that some EDRs have very good control over the file system right after the creation of the Mimikatz file on it. I was not able to delete the Mimikatz file and the temp directory that contained that file, and so I was not able to make a different directory junction towards the C:\ drive. The other behavior I saw was that the EDR or AV realized that the threat no longer existed after I deleted it, so there was no longer a need to delete that file. At that point, I understood I needed to expand my window of opportunity between these two main events.

Forcing a Reboot

My next idea was to try to catch the handle of the malicious file that I was creating in an effort to force a reboot. This was based on the knowledge that when we open a file in Windows or create a file in Windows, it asks us to identify the file-sharing mode to determine if other processes can modify or delete the file. So, I did not give any permission for that when I created the malicious Mimikatz file, kept the handle to it open, and waited to see what happened. The EDRs and AVs began to alert me that a reboot was needed in order to fully remediate the threat.

I again observed two different behaviors. The first was that some EDRs and AVs used the default Windows API to postpone a deletion until after the next reboot. SentinelOne, for example, handled the situation this way. The other method that I observed was that some EDRs or AVs just kept a list of the paths to delete somewhere and then after the reboot, they deleted them. But if we take a look at the default Windows API for postponing a deletion to after the next reboot, it is done using the MoveFileEx function with the flag MOVEFILE_DELAY_UNTIL_REBOOT. 

This flag requires administrator privileges because once the function receives this flag, it goes to the registry value called PendingFileRenameOperations and adds an entry, which is the path to delete after the reboot. But what’s surprising about this default Windows feature is that once it reboots, Windows starts deleting all the paths and blindly follows junctions. Some other self implementations of EDRs and AVs do that too. As a result, I was able to create one complete process that allowed me to delete almost any file that I wanted on the system as an unprivileged user. 

Summary of Steps to Trigger the Privileged Delete Vulnerability 

If we look at this in the context of the earlier example, the complete process would look like this: 

1. Create a special path with the malicious file at C:\temp\Windows\System32\drivers\ndis.sys
2. Hold its handle and force the EDR or AV to postpone the deletion until after the next reboot
3. Delete the C:\temp directory
4. Create a junction C:\temp → C:\
5. Reboot

This process achieved the what-ifs I set out to test at the beginning of my research: 

• What if there was a next-generation wiper that didn’t use these obvious API calls to wipe files? Using this process, I was able to delete files without using the obvious API calls that the latest wipers are using. 
• What if this next-generation wiper could also wipe these files as an unprivileged user? Using this process, I was able to wipe important files as an unprivileged user without the appropriate permissions. 

Bypassing the Controlled Folder Access Ransomware Protection Feature

This exploit is also effective for  a ransomware protection feature in Windows called the Controlled Folder Access. This feature prevents untreated processes from modifying or deleting any files contained inside one of the folders listed in the Protected Folders list. However, since an EDR or AV is the most trusted entity on a system, this feature does not prevent them from deleting these files.

Product Testing & Vendor Response

Overall, I tested 11 different security products against this exploit and found six of them to be vulnerable—that’s more than 50%.

Disclaimer regarding the Microsoft Defender and Microsoft Defender for Endpoint products: I was not able to achieve arbitrary file deletion, but rather arbitrary directory deletion. But wipers do not care about deleting a few extra files on the way, so that was not a major issue for my wiper. 

We responsibly reported these vulnerabilities to the affected vendors between July and August of 2022. We then worked closely with them over the next four months on the creation of a fix prior to this publication. The following CVEs have been issued by three of the vendors: 

• Microsoft: CVE-2022-37971
• TrendMicro: CVE-2022-45797
• Avast & AVG: CVE-2022-4173

Microsoft issued one CVE for both of its vulnerable products, because both Defender and Defender for Endpoint use the same engine for deletion. TrendMicro also issued one CVE for their products. Gen, which is the vendor of the Avast and AVG AVs, also issued one CVE because both products use the same code. 

Three of the vendors also released new versions of their software or patches to address this vulnerability: 

• Microsoft Malware Protection Engine: 1.1.19700.2
• TrendMicro Apex One: Hotfix 23573 & Patch_b11136
• Avast & AVG Antivirus: 22.10

We encourage all organizations to ensure they are using the latest software versions and/or have applied the appropriate patches to ensure protection against this vulnerability. 

Overview of the Aikido Wiper Tool

The Aikido iperTool is implemented with exploits for the vulnerabilities found in SentinelOne’s EDR, Microsoft Defender, and Microsoft Defender for Endpoint. The exploits for these products were the most consistent and easiest to implement in a wiper, which is why I chose them.

General Qualities of the Aikido Wiper:

Fully Undetectable

The wiper executes its malicious actions using the most trusted entity on the system—the EDR or AV. EDRs and AVs do not prevent themselves from deleting files.

NOTE: In order to minimize the action of creating a malicious file, the wiper creates an EICAR file instead of a real malicious file. This file is deleted by EDRs and AVs and, at the same time, is not really malicious.

Makes the System Unbootable

The wiper is able to delete system files like drivers and, as a result, can prevent the operating system from being able to boot.

Wipes Important Data

The wiper is able to delete all the content of an administrator user directory. That is just an example of the importance of the data that the wiper is able to delete.

NOTE: In order to escalate the file deletion to a wipe, the wiper runs when the computer reboots and fills up the disk to no space with random bytes a few times. Doing that ensures that any data from deleted files that was left on the disk is overwritten and wiped.

Runs as an Unprivileged User

The wiper has all the qualities listed above and still runs as an unprivileged user.

Deletes the Quarantine Directory

The wiper can manipulate an EDR or AV to delete the quarantine directory too. If the target files are quarantined, they can still be deleted.

Conclusion  

SafeBreach is passionate about improving security on a global level. By openly sharing information about this discovery, our goal is to raise a warning flag about the existence of these zero-day vulnerabilities and the ability to exploit them to create an undetectable, next-generation wiper with the devastating potential to manipulate many existing EDR and AV solutions. 

While we have done our best to test the EDR and AV products we had access to, it is not feasible for us to test every product on the market. By making this information available to the larger security community, we hope to minimize the ability of malicious actors to exploit these vulnerabilities and provide EDR and AV vendors with the knowledge they need to take immediate action on their own. 

We believe it is critical for all EDR and AV vendors to proactively test their products against this type of vulnerability and, if necessary, develop a remediation plan to ensure they are protected. We would also strongly encourage individual organizations that currently utilize EDR and AV products to consult with their vendors about these vulnerabilities and immediately install any software updates or patches they provide.

As cyber criminals continue to evolve their tactics, organizations must understand that: 

• A wiper is much more dangerous if it uses a trusted entity on the system—in this case, an EDR or AV—to complete its malicious actions by proxy. 
• Having security controls does not mean an organization is secure. 
• Security controls can be a preferred target for attackers because of their high privileges and very high level of trust. 

Credits & References

I would like to thank Shmuel Cohen, a fellow security researcher on the SafeBreach Labs research team, for his assistance with testing my exploits against different EDR and AV products.