In September 2019, MITRE evaluated Microsoft Threat Protection (MTP) and other endpoint security solutions. The ATT&CK evaluation lasted for three days, with a professional red team from MITRE emulating many advanced attack behaviors used by the nation-state threat group known as YTTRIUM (APT29). After releasing the results of the evaluation, MITRE published the emulation methodology, including all of the attack scripts, tools, and code.
During the evaluation, the Microsoft Threat Protection team noted an interesting behavior related to one of the steps in the APT29 attack chain: Step 19 was supposed to perform stealthy deletion of files using the SDELETE tool reflectively loaded in memory. However, we observed that the step repeatedly caused process crashes during the execution of red team operations.
Crashes are unexpected surprises that could be a true gem for defenders for being a major indicator of an imminent attack, ruining the party for red teams and real attackers alike. Inspired by the transparency of MITRE publishing all the payloads and tools used in the attack simulation, in this blog post, we’ll describe the mystery that is Step 19, share our root cause analysis of the Step 19 attack script, and tell a story about how blue teams, once in a while, share important learnings for red teams and their tools.
The APT29 emulation involved 20 steps consisting of attacker techniques from the MITRE ATT&CK matrix related to the APT29 group. These steps were executed in the course of two days (plus an extra day reserved as a buffer), 10 steps per day. Since these steps spanned the entire attack chain, each step logically flowed from the previous one.
Step 19 was part of the attack chain executed on the second day. It emulated the attacker’s goal of deleting artifacts from the machine at the end of the breach using the SDELETE tool, which was loaded via PowerShell through a reflective loader mechanism, without ever touching disk.
Figure 1. Step 19 of the MITRE evaluation
This was done by dropping and running a script file called wipe.ps1, in a process that included:
It’s important to note that the wipe.ps1 payload was based on and inspired by the famous “Invoke-ReflectivePEInjection” script from Joseph Bialek (@JosephBialek) and Matt Graeber (@mattifestation), which is also affected by the same issue that we discovered in our investigation and root cause analysis.
Figure 2. Microsoft Threat Protection detection of the reflective loader with relevant cmdlets
Figure 3. Entire script fetched using advanced hunting (truncated for brevity)
Microsoft Threat Protection automatically detected the execution of the reflective loader via PowerShell; however, during the execution of this attack, the telemetry provided by the product also captured the launch of WerFault.exe process (the Windows Error Reporting process) forked from PowerShell.exe, which was a sign of a crashing process.
Having noticed the repeated process crashing behavior, we decided to investigate further to understand what was happening in Step 19, and we observed the following:
| Test | Result |
| Execution in MITRE test environment #1 (primary) with MTP | wipe.ps1 generated crash |
| Execution in MITRE test environment #2 (backup) with MTP | wipe.ps1 generated crash |
| Execution in MITRE private environment without MTP | wipe.ps1 executed with no crashes |
| Onboarding MTP to MITRE private environment | wipe.ps1 generated crash |
Indeed, it looked as if MTP was the cause of the wipe.ps1 script crashing. However, we validated that this shouldn’t be the case. Therefore, we performed an extensive analysis independent of the MITRE test, with the hope of finding the root cause of this behavior and sharing with MITRE, red teams, and other researchers.
Debugging the script wipe.ps1, we noticed an unexpected crash in the GetCommandLineW API, which was quite odd.
Figure 4. Call stack analysis for crash
Since the crash happens at kernelbase!GetCommandLineW, we examined its code before reflective loading:
Figure 5. GetCommandLineW code before patching
Note that the code consists of:
We then examined the code at the moment of the crash:
Figure 6. GetCommandLineW code at the crash
Note that there’s no RET instruction, so INT 3 (debug-breakpoint) was executed, causing the crash during the test (since no debugger is attached). Noting the byte encoding of the instructions and comparing them at a normal state and in the moment of the crash, we noticed a one-byte difference: the second byte changed from 8B to B8, causing a complete modification of the interpreted instruction! 8B is the opcode for a relative addressing move, while B8 is an immediate value move. The first byte 48 is a REX.W prefix, making the instruction refer to 64-bit operands.
Clearly, something strange was happening in the attack script wipe.ps1, so we decided to perform an extensive, line-by-line analysis of the attack script internals.
As mentioned, the reflective loader used in the MITRE evaluation was inspired by Invoke-ReflectivePEInjection from PowerSploit, so analysis was relatively easier, vis-à-vis reverse engineering a new reflective loader.
A reflective loader is a tool for loading executable code into a process address space without invoking the operating system API, allowing attackers to avoid security products’ instrumentation of APIs such as LoadLibrary WinAPI that loads a DLL. Since .exe files are compiled with relocation tables (due to address space layout randomization (ASLR) support), many reflective loaders support loading of .exe files as well as DLLs.
When reflectively loading an .exe file, special care must be taken, as processes tend to rely on certain memory structures to be uniquely reserved to them. This is especially true for structures like the Process Environment Block (PEB), which contains important information about the current running process without transitioning into kernel mode. The reflective loader used by MITRE indeed takes special care of certain APIs that obtain information from the PEB; it does so by inline hooking.
Specifically, the reflective loader hooks the function GetCommandLineW that we saw earlier. Unless it does so, the reflected .exe code (sdelete.exe in this case) would fetch the original command line (the one for PowerShell.exe in this case) instead of the intended command line. Here’s a step-by-step analysis of the hooking:
When performed correctly and fully, this should work well. However, our debugging showed only one-byte change (from 8B to B8) and no RET instruction. This meant that either StructureToPtr had some bug, or that patching was done partially. Assuming the latter, we concluded that the crash happens during the patching itself, after placing the MOV instruction but before encoding the new address, i.e. right after invoking Write-BytesToMemory.
Debugging further, we discovered that the crash indeed happens after the first Write-BytesToMemory cmdlet. The call stack analysis showed that the call originates from PowerShell itself (or more precisely, from the CLR which is invoked by PowerShell), which is odd. This means that some code in PowerShell somehow tries to fetch the current process command line immediately after the cmdlet is executed.
We discovered that the code responsible for fetching the command line is the code that generates Event Tracing for Windows (ETW) for cmdlets. The Microsoft-Windows-PowerShell event provider exposes event IDs that log cmdlets, such as event 7937. Here’s an example of such an event:
Figure 7. Cmdlet tracing with ETW
Note the captured information, such as the cmdlet name, cmdlet type, and the process command line. The ETW writer for cmdlets is invoked after the cmdlet has finished running and has logged all the information. The command line itself is fetched by the ETW writer by invoking GetCommandLineW.
This means that an the ETW writer invoked for the first Write-BytesToMemory would invoke GetCommandLineW, but since only the first two bytes were patched, then GetCommandLineW is “half-patched”, eventually executing INT 3 and causing a crash.
While this explains the crash, it doesn’t explain why there was no crash when Microsoft Threat Protection was not present. The solution for this is simple: if there are no ETW listeners to the event, the ETW writer is never invoked, and therefore never tries to fetch the command line. Indeed, Microsoft Threat Protection listens to many ETW providers, including the Microsoft-Windows-PowerShell ETW.
To summarize, here is a flow diagram showing how this scenario runs:
Figure 8. Flow chart for the first Write-BytesToMemory cmdlet run
This conclusively proves that if any ETW listener registers to this ETW event (and not just Microsoft Threat Protection), the PowerSploit reflective loader implementation will crash. We reproduced this behavior without Microsoft Threat Protection and reported it to the MITRE red team to decide the course of action with Step 19.
PowerSploit is a known and widely used infrastructure for red teams. It’s used extensively and its codebase is regularly checked and updated. Even such a well-established project may contain unexpected bugs, some of which could only occur under special conditions such as specific environment changes like the one we described here.
Data we gathered using the advanced hunting capability in MTP further establishes this strong correlation: in real-world environments, 66% of the Invoke-ReflectivePEInjection invocations end up crashing their hosting PowerShell instance. This is a statistically significant proof of this bug in PowerSploit.
Figure 9. Advanced hunting query for correlating PowerShell crashes and Cmdlet invocation
The TL;DR advice for red teams is this: if you use “Invoke-ReflectivePEInjection” script during your regular penetration testing, be aware of an unexpected surprise in certain circumstances that may lead to immediate detection.
We thank MITRE for leading a transparent and collaborative evaluation process that encourages partnership and threat intelligence sharing. To learn how Microsoft Threat Protection did in the evaluation, read: Microsoft Threat Protection leads in real-world detection in MITRE ATT&CK evaluation.
Jonathan Bar Or
Microsoft Threat Protection Research Team
Questions, concerns, or insights on this story? Join discussions at the Microsoft Threat Protection and Microsoft Defender ATP tech communities.
Read all Microsoft security intelligence blog posts.
Follow us on Twitter @MsftSecIntel.
Microsoft, in collaboration with OpenAI, is publishing research on emerging threats in the age of AI, focusing on identified activity associated with known threat actors Forest Blizzard, Emerald Sleet, Crimson Sandstorm, and others. The observed activity includes prompt-injections, attempted misuse of large language models (LLM), and fraud.
At Microsoft, we’ve been working on the challenges and opportunities of AI for years. Today we’re sharing some recent developments so that the community can be better informed and better equipped for a new world of AI exploration.
Microsoft security researchers investigate an attack where the threat actor, tracked DEV-0139, used chat groups to target specific cryptocurrency investment companies and run a backdoor within their network.
Microsoft Defender Experts for Hunting, our newest managed threat hunting service, delivered top-class results during the inaugural MITRE Engenuity ATT&CK® Evaluations for Managed Services. Defender Experts for Hunting provided a seamless, comprehensive, and rapid response to the simulated attack using expert-led threat hunting and an industry-leading platform—Microsoft 365 Defender.
