​Both failure and experimentation have been instrumental in developing my offensive tradecraft skills. While not a red teamer by trade (I am an intelligence tool builder), being able to recreate tradecraft has always been important, validating the signals being generated from the automation that I build. One facet of our cyber intelligence, or counter cyber intelligence (CCI) to be more specific, are the detailed mappings of social structures within the commoditized exploit tool ecosystem. These data structures have the ability to anticipate which exploit tools and tradecraft may be combined with another, possibly being disparate at a surface glance but connected within our dataset by way of social, developer or technical relationships. It is these possible tradecraft combinations that then fuel our experimentation to ground-truth how the signals would behave if combined together. This writeup has been fueled by just such a scenario as we explore building a dropper that can bypass UAC (User Account Control) and persist through WMI, turned into shellcode and injected into a remote process. Testing was conducted on a Windows 10 box and with MDE (Microsoft Defender for Endpoint) installed, BlockMode and Automated Investigations enabled. While the attack was fully executed, MDE automated investigations caught up with us and eventually killed our fun. This is the story.
 
Lately, we have been zeroing in on a part of the kill chain that transpires right after an initial access event (like malicious macro downloads payload) has taken place and then finishing right before lateral movement. It is within this scope that we will operate for this writeup and build a dropper that will automate all aspects of the attack. Three months ago, many of our signals related to UAC bypass ran FUD (fully undetected) when tested on endpoints protected by MDE. As of late, Microsoft has stepped up their detection game and getting a FUD UAC bypass on an MDE protected endpoint, is difficult. In an attempt to combat this newfound blue team’s strength, we decided to build our exploitation logic so that it could be turned into shellcode via donut.exe (“Generates position-independent shellcode that loads .NET Assemblies, PE files, and other Windows payloads from memory”) and injected into various processes. Ultimately, the injected offensive logic is able to download additional payloads, bypass UAC, install WMI persistence and callback to Covenant C2 as NT AUTHORITY\SYSTEM. 

​

​Slippery.exe:
Slippery.exe’s primary purpose is to be turned into shellcode and injected into WmiPrvSE.exe, via process hollowing. It’s exploit logic is that of a dropper / UAC Bypass which executes an attack chain, culminating in SYSTEM level persistence. Let’s walk through some of its code.

​Slippery.exe Functionality:
Slippery.exe establishes HTTPS connections with ngrok and leverages the curl.exe binary found preinstalled in Windows 10, to download its payloads.

1. Using the command "ngrok http file:///C:\Users\user\Downloads" exposes an attacker's local file system (housing payloads to be downloaded) and makes payloads accessible from the public internet.
2. The https address that is created for the ngrok tunnel is then put into the C# code as a process start argument for curl.exe.
3. The process curl.exe is created with “process.StartInfo.WindowStyle = ProcessWindowStyle.Hidden” to specify not to create a window with the starting of the process.

File Drops:
Slippery.exe has two defined download paths where it will drop files to disk:

1. C:\Users\Public
2. C:\Windows\System32\spool\drivers\color

Slippery.exe itself is executed within C:\Users\Public\Downloads, additionally downloading the file ClipEvent.ps1 to the same directory and then dropping files fontdrvx64.exe and wscRGB.ps1 to a user writeable folder contained within C:\Windows\System32\spool\drivers\color\. The files fontdrvx64.exe and wscRGB.ps1 are the persistence payloads that are called by a WMI event subscription, which we will describe below. The thinking here was that if our UAC bypass was flagged (but not blocked from executing), MDE would articulate all associated processes, files and corresponding locations, triggering a human investigation of the affected items. In order to try and deceive the investigators and keep the persistent C2 channel active, Slippery.exe tries to break that clear investigation linkage by downloading the initial stages to the first path, downloading the persistence payloads to the second path and then attempting to obfuscate their execution relationship which will also be discussed below. Choosing the user writable subfolder within system32 was a good hiding spot before, but is now detected by MDE and in our case, initiated an automated investigation that inevitably led to the automation discovering and neutralizing the persistence payloads. The irony wasn’t lost on us that in actuality, it was this automated investigation that got us burned. Afterwards, I was thinking to keep all payloads together in Public\Downloads and then during WMI persistence execution (as SYSTEM), moving the WMI payloads into the protected folder to not raise the same alert. 

​The UAC Bypass:
Leveraging the native binary fodhelper.exe, Slippery.exe will bypass UAC by exploiting odd behaviors found within fodhelper.exe. This native binary is an "auto-elevated" binary and will look for additional process creation arguments, should certain registry keys exist. If those keys are created, fodhelper.exe will execute the command value which is contained within one of those keys (high-integrity context), thereby bypassing UAC. We wrote some very basic C# code to exploit this vulnerability which was based on trending vectors, articulated within our CCI dataset. The bypass code achieves the following:
​

1. Create subkey: CurrentUser\Software\Classes\ms-settings\Shell\Open\command
2. Set Value DelegateExecute: ""(blank)
3. Set Value (Default) "": C:\Users\Public\Downloads\ClipEvent.ps1
4. Start process fodhelper.exe with hidden window

Persistence & Hiding Execution Relationships:
So, this method was really about dismantling the forensic relationship between the initial execution and the persistence mechanism because we knew the UAC bypass method would get flagged. In the end, we were caught on the decision to write to a protected folder as an unprivileged user, coupled with the UAC bypass that indeed was flagged. None the less, we feel this strategy applied slightly differently could be highly effective and run FUD. The exploit logic for persistence will be discussed in two parts; the initial part that registers the persistence and then the second part which details what the persistence does.
 
Persistence Logic (ClipEvent.ps1):
To gain persistence on this endpoint ClipEvent.ps1 opted for an old favorite and that was a WMI event subscription. One difference here is that we decided not to use mofcomp.exe to register an event subscription as that vector is detected by MDE, now. Instead, we crafted a PowerShell approach which did the following:
​

1. Create an Event Filter for ProcessStartTrace on process rdpclip.exe
2. Create a CommandLineEventConsumer which would launch a PowerShell Script
3. Create FilterToConsumerBinding

​Persistence Payload Logic (wscRGB.ps1):
wscRGB.ps1 is a tiny script that is meant to start the process injector (fontdrvx64.exe) which injects Covenant C2 implant shellcode as NT AUTHORITY\SYSTEM. Its secondary function is to delete the initial files that were dropped to Public\Downloads.

​Execution Relationship Obfuscation:
Our idea was to download the first process injector (containing the UAC bypass) and the first ps1 script (responsible for WMI persistence) into Public\Downloads and the second injector (Covenant implant) and ps1 script (WMI payload for the CommandLineEventConsumer) into a user writable folder, within system32. The rationale was that if our UAC bypass was alerted on, investigators would have a harder time connecting the dots between it and the resulting process injection, stemming from a sub folder in system32 with no clear execution linkage. We broke up the execution relationship by not passing execution directly from the process responsible for bypassing UAC (Slippery.exe’s logic injected into WmiPrvSE.exe) and registering WMI persistence. Instead, Slippery.exe would initially kill process rdpclip.exe (in case it was already active) and then at the end of its logic, start rdpclip.exe which would then trigger the WMI permanent event subscription, therby firing the second injector connecting back to the C2 as SYSTEM. Remember, part of the WMI payload’s logic (wscRGB.ps1) was to delete ClipEvent.ps1 (registers the WMI event subscription) which would clearly articulate the directory of the WMI payload to be executed by the “CommandLineEventConsumer.” That being said, defenders could still see the resulting WMI payload location by inspecting tools such as ScriptBlock Logging or the AMSI content output in MDE (shown below). Additionally, due to the fact we got lit up for dropping a file to a protected folder which was user writeable, the automation was able to see the injected process (Dropper/UAC bypass) WmiPrvSE.exe now connected with the WMI payloads in system32 we were trying to obfuscate (also shown below).

Process Injector (Process Hollowing (fontdrvx64.exe & SM.exe))
For the injector we used a modified version of a payload discussed at Defcon 27, “Writing custom backdoor payloads with C#,” which can be found below. Both fontdrvx64.exe and SM.exe were identical injectors, except for the shellcode that they injected. SM.exe was responsible for injecting the initial dropper/UAC bypass and fontdrvx64.exe was the persistent injector hidden within “C:\Windows\System32\spool\drivers\color\, responsible for injecting the Covenant implant.”

(defcon27_csharp_workshop/2.cs at master · mvelazc0/defcon27_csharp_workshop · GitHub)

​Conclusions:
In this round of experimental testing, MDE really ate our lunch for us but we learned quite a bit. Some key takeaways are as follows:
 

1. C:\Windows\System32\spool\drivers\color\ is not a safe zone anymore
2. Accessing that protected folder after WMI execution (as SYSTEM) may have neutralized that alert
3. The creation of registry key: CurrentUser\Software\Classes\ms-settings\Shell\Open\command is heavily monitored by MDE and a great detection point for this specific UAC bypass
4. Use more reflection rather than on-disk payloads :)
5. As always, keep experimenting and have fun!

​*Why Regular Antivirus is not Enough: A Roll-Your-Own UAC Bypass vs Regular AV & MDE* Building a UAC bypass in C# that leverages fodhelper.exe and right off the bat, it bypasses regular AV. When executed against MDE, the bypass gets about two seconds of life. MDE detects on the behavior associated with changing the registry values which are needed for this bypass. It goes to show you why just regular AV isn’t enough these days. Some neat things coming up to try with this bypass, with the intent to get it to run FUD against the MDE. We jumped off these codes found below:
 
UAC bypass 1:
https://gist.github.com/netbiosX/a114f8822eb20b115e33db55deee6692
 
UAC bypass 2: https://github.com/0xyg3n/UAC_Exploit
 
#infosec #cybersecurity #informationsecurity #threatintelligence #networksecurity #sec #security #tools #offensivesecurity #pentesting #redteam #blueteam

*C# Dropper: Attack Chain Fully Executed + Detailed Blue Perspective of the Attack Timeline (MDE BlockMode Auto Investigations)* We got the dropper almost there with only one detection on the UAC bypass which MDE wrongly classified as blocked. This itself was a bit of a battle as MDE completely blocks the stock UAC bypass from executing. The incident starts with the dropper assessing the executing process’s SID and escalating if not Administrator, dropping files to disk via ngrok (https), injecting shellcode for the first C2 callback in high integrity and then installing WMI persistence with ProcessStartTrace on WinStore.app.exe, which injects shellcode and calls back to the C2 as SYSTEM, every time the Windows store is launched. We modified and utilized the commoditized tooling found below (unmodified versions).
 
0xyg3n/UAC_Exploit: https://github.com/0xyg3n/UAC_Exploit
 
EDRGoesBrrr: https://github.com/NVISOsecurity/brown-bags/tree/main/DInvoke%20to%20defeat%20EDRs/DemoDInvokeLoader
 
donut: https://github.com/TheWover/donut
 
Covenant: https://github.com/cobbr/Covenant
 
#infosec #cybersecurity #informationsecurity #threatintelligence #networksecurity #sec #security #tools #offensivesecurity #pentesting #redteam #blueteam

*C# Dropper, D/Invoke Direct System Calls + Shellcode Injection* Round 2 with an edited version of Jean-Francois Maes’s code (EDRGoesBrrr) which utilizes the direct system call functionality. This functionality can be very broadly defined as retrieving a syscall number for a Windows function (located on disk from within ntdll.dll) and then placing that corresponding syscall number on the eax register and entering the kernel directly. By not having to use the Windows function located within ntdll.dll, it is possible to bypass EDR hooks that may be present in that corresponding function – you go underneath the EDR’s hooks in ntdll.dll. This was then added to the dropper I am working on which tested FUD against MDE (BlockMode and Automated Investigations enabled).
 
EDRGoesBrrr-source:https://github.com/NVISOsecurity/brown-bags/blob/main/DInvoke%20to%20defeat%20EDRs/DemoDInvokeLoader
 

*C# Dropper, D/Invoke Manual Mapping(ntdll.dll) + Shellcode Injection* After a really good talk by Jean-Francois Maes, I wanted to try his code’s functionality (EDRGoesBrrr) with a dropper that I’m working on. The dropper opens an HTTPS tunnel with ngrok, downloads an edited version of his injector which leverages D/Invoke to manually map ntdll.dll (avoiding any hooks) and then injects a Covenant implant into RDP clipboard monitor. I did use the NuGet package for D/Invoke which didn’t seem to cause any problems. No alerts in MDE but there was an informational warning in the timeline regarding the parent PID spoofing. Testing was done on MDE (BlockMode + Automated Investigation).
 
 
Talk (EDR Mechanics / Evasion Techniques): Defeating EDR's using D/Invoke - YouTube

 
EDRGoesBrrr(source):brown-bags/DInvoke to defeat EDRs/DemoDInvokeLoader at main · NVISOsecurity/brown-bags · GitHub
​

*Cyber Mongol’s Adversary Tradecraft Simulator (Faza Agent): Check Privs, Elevate to High, Impair Telemetry, DLL Inject C2 Implant (High), Persist WMI(SYSTEM)* The Faza Agent utilizes Cyber Mongol’s Counter Cyber Intelligence (CCI) to pull in real, on-trend, commoditized tradecraft that tests advanced defenses. Faza will be available as an integration for Microsoft for Endpoint’s Evaluation Lab and additionally, a standalone offering.

We are still working on the mechanics of the agent and fully expected that we’d get busted by the EDR, flagging on the UAC bypass we are using. Faza’s current functionality is to check the integrity level of the process, bypass UAC, inject Covenant grunt for 1st C2 channel, disable MDE telemetry, add persistence with a WMI event subscription and then connect back to the C2 as SYSTEM, when the event subscription is triggered (starting Win store process).

 Currently, Faza is in its infancy but I thought it would be interesting to share as we build it out.

​
#infosec #cybersecurity #informationsecurity #threatintelligence #networksecurity #sec #security #tools #offensivesecurity #pentesting #redteam #blueteam

​*Step 2 - Custom FUD Dropper in C#: Privilege Escalation Logic Added* Continuing the build on the dropper that can pull in commoditized tooling that our engine sees signals on, I wrote the logic that would assess the current SID and determine if the process was in medium or high integrity. If in medium, the logic branches off and downloads a UAC bypass (commoditized tooling) before it injects a Covenant grunt, resulting in a high integrity context. The dropper ran good against standard Defender AV (undetected) but was burned against MDE EDR (medium integrity injection still worked), which was to be expected. I still have some OpSec work to do on the dropper’s UAC bypass before it is ready to tackle the big dog (MDE EDR) and run FUD.
 

 
#infosec #cybersecurity #informationsecurity #threatintelligence #networksecurity #sec #security #tools #offensivesecurity #pentesting #redteam #blueteam

*Custom FUD Dropper in C#: RED/BLUE Perspectives*I wrote a custom dropper in C# that reaches back to adversary infrastructure via ngrok, downloads a DLL injector, looks for and(or) starts rdpclip.exe and then injects a Covenant C2 implant into that process. The dropper ran completely undetected and even passed two cloud delivered security scans (“Your administrator requires a security scan”). Testing was conducted against the MDE stack (AV/EDR (BlockMode AutoRemediation)).
 
 
#infosec #cybersecurity #informationsecurity #threatintelligence #networksecurity #sec #security #tools #offensivesecurity #pentesting #redteam #blueteam