​*Great Cobalt Strike Resource* While writing backend code to build and analyze more complex social structures between exploit tools and their authors, we came across a tradecraft cluster with significant Cobalt Strike depth. White paper coming soon that details all the special things our tech does.
 
The center of the cluster is a great resource, find below:
 
 
Awesome-CobaltStrike: https://github.com/zer0yu/Awesome-CobaltStrike
 
 
#infosec #cybersecurity #informationsecurity #threatintelligence #networksecurity #sec #security #tools #offensivesecurity #pentesting #redteam #blueteam
 

The engine found shellcode injection techniques that are extremely simple and unquestionably effective. I think I am in love….

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

Dump Lsass with SharpMiniDump NTFS transactions + UAC bypass + Exfil .dmp file to Dropbox. Overall, MDE BlockMode did a good job articulating this vector in the device timeline. Utilizing SharpMiniDump NTFS transactions (a fork of b4rtik/SharpMiniDump) to avoid writing the dump file to disk and exfiltrating it out to an awaiting Dropbox, made a big difference in avoiding being blocked from executing. The UAC bypass (Medium.exe) executes enough to drop into high-integrity and fire SharpMiniDump (SMD.exe). It took forever to upload the .dmp file to Dropbox - which eventually lost out to my patience (killed process before .dmp file finished). With some work, this may be a good vector.

Lsass Dumper: https://lnkd.in/eD3m2gu

UAC Bypass: https://lnkd.in/dwXdNiE


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

Migrator.exe -->CreateProcess CMD.exe<--Fibs.exe<-- InjectShellcode-->C2 Callback
 
Sensors picked up a new PEx64 injector that maps an .exe into the memory space of a legitimate process. We had some problems getting it working with our shellcode injector which injects a Covenant C2 Grunt into itself but managed to get it working with the system binary cmd.exe. While providing better OpSec when compared to spawning a random process with a sketchy location path, a better legitimate process can be found (cmd made network connection to xxx.xxx.x.x – not great). No Detections on the MDE stack (BlockMode Auto-Remediation Group). We will share the resources we used for this attack after some upcoming client work.
 
PE-Injection Info (MITER): https://attack.mitre.org/techniques/T1055/002/
 
#cyberthreatintelligence #infosec #cybersecurity #informationsecurity #threatintelligence #networksecurity #sec #security #tools #offensivesecurity #pentesting #redteam #blueteam 

Intro
Deriving intelligence from sensors that register human momentum within the security ecosystem serves us well, granting insight into how adversaries may, or currently are attacking IT systems. It allows us to triage signals we feel are impactful and pose a real chance of slipping through the cracks of advanced security stacks, gaining execution. Operator tradecraft intelligence is also quite useful as it articulates what opensource exploit systems are in vogue and may be combined for greater effect. Advanced adversaries are rapidly embracing opensource software and for good reason. Opensource software provides much more anonymity when compared to custom malware development, the lead-time between offensive campaigns is reduced, innovation is greatly expanded, and the flying of false flag operations is possible. Nevertheless, this is not the scope of todays blog, utilizing trending UAC bypasses and combining them with an APT favorite (WMI) to gain persistence, is. Let’s dig in.
 
In the upcoming testing, we assume some type of initial access which results in the download and execution of our maliciousness. Our testing will then pick up at that point, deciding on proper evasion for the execution (actually gaining execution) and elevating privileges to persist on the endpoint after a reboot. In the blue team’s corner, we have Microsoft’s Defender for Endpoint (MDE) which is available for those customers using E/3 – E/5 licensing for Windows 10. We have configured the EDR in BlockMode and have enabled automated remediation for the machine group containing the endpoints. The overall attack architecture is as follows:
 
Attack 1:
Muffin.exe(UAC bypass) -> GetMoving.cmd(Elevated) -> mofcomp.exe(persistence) -> WmiPrvSe.exe -> Fibres2.exe(NT SYSTEM) -> Covenant C2(C&C)
 
Attack 2:
MeFirst(UAC bypass) -> WMIpers.cmd(Elevated) -> EventSubWMI.ps1(persistence) -> WmiPrvSe.exe -> script.ps1 -> Fibres.exe(NT SYSTEM) -> Covenant C2(C&C)

Executing Shellcode via Process Fibers
So, first thing we needed to do is figure out what we would execute after achieving a high integrity context – thank you trending UAC bypasses. One of the most common categories of behaviors our passive sensing technologies ingest are T1055 - Process Injections. Process injections are a great form of defense evasion as they (in a very broad sense), overtake a portion of a process’s memory and then inject their malicious intent into that process’s memory space. There are many different flavors of process injection, each with their own benefits and operational security considerations. Lately, our team has been utilizing trending process hollowing techniques (creating a process in a suspended state -> injecting shellcode -> resuming suspended process and executing shellcode) to achieve our goals but the MDE stack has caught on to these shenanigans. Our team turned to one of our newer intelligence capabilities (The Hunter Module) which utilizes Cyber Mongol’s advanced signatures to go out and find relevant operator tactics on the open internet. In this case, we put together signatures made up of API calls, text features, system binaries and associated privileges, to find shellcode injectors which utilize process fibers to execute shellcode within a process. Rooting through the treasure trove of returned data, we indeed found suitable candidates that would covertly inject shellcode into the memory space of a process.

GetMoving.cmd​
Ok, now that that is sorted, let’s start at the beginning of “Attack 1”…executing the initial UAC bypass (Muffin.exe) that will pass on its own elevated token, to the rest of our attack chain. This UAC bypass utilizes the Microsoft signed binary ComputerDefaulst.exe which possesses an AutoElevate attribute, set to true. The bypass creates a process which inherits the high integrity context of its parent process, in our case Muffin.exe spawns GetMoving.cmd (which orchestrates the rest of our attack) and passes on its associated privileges. Something to note, the user account must be part of the local administrators group for this bypass to work. Luckily, this user configuration can be quite prevalent, in our experience.  
 
GetMoving.cmd has three purposes.

1. To set PowerShell “Set-ExecutionPolicy Unrestricted”
2. Utilize elevated PowerShell to execute mofcomp.exe and register a WMI permanent event subscription (StickAround.mof) for persistence in SYSTEM context
3. Lastly, utilize elevated CMD to execute Fibres2.exe and inject itself with Covenant C2 implant shellcode, in high integrity (initial C&C channel).

​
We also added some basic OpSec by changing PoC code that requires pop-up Windows / User input and added code to relevant cpp console applications, “ShowWindow(GetConsoleWindow(), SW_HIDE);” hiding console windows. We left the console window open for GetMoving.cmd so that we could have a look at our .mof file being ingested. Lastly, we simulated a victim harmlessly opening up the Windows Store. 

WMI Persistence
​Now would be a great time to chat about the WMI persistence portion of the attack – Event Triggered Execution: Windows Management Instrumentation Event Subscription (T1546.003) . During our testing this week we tried two different UAC bypass techniques that have been trending, both producing similar results. They each produced alerts in MDE of varying degrees, but none were blocked from executing. Similarly, we employed two different ways of achieving WMI persistence through subscription, with only one of these techniques alerted on (mofcomp.exe). Without getting too deeply into the weeds here (deep dive), our intention was to register WMI persistence that would connect back to our Covenant C2 channel, every time the Windows Store application was launched. Of notable mention, WmiPrvSe.exe is the parent process for WMI subscription execution and this results in an integrity level of NT SYSTEM, for the resulting subscription’s action (fiber injection Covenant C2 Implant). Good score!
​
The noisier of the two tactics we employed to register WMI event subscriptions was to use mofcomp.exe. this Windows binary parses a .mof file (StickAround.mof) and creates a WMI permanent event subscription based on the file.
​

1. StickAround.mof created a trace event (Query = "SELECT * FROM Win32_ProcessStartTrace WHERE ProcessName=\"WinStore.App.exe\"") that looks for the Windows Store application being launched.
2. It then registers a “CommandLineConsumer” that directly executes our fiber injector (Fibres2.exe), which injects itself with shellcode that calls back to our Covenant C2 channel (CommandLineTemplate = "cmd /C C:\\Users\\Public\\Fibres2.exe").
3. Lastly, a binding between the event and consumer is created.

The much quieter way of registering a WMI event subscription (contrasted against the MDE stack) was to utilize PowerShell’s native ability to interact with WMI directly. Here, we used the attack architecture depicted above in “Attack 2” which possesses a few key differences when compared to "Attack 1."

1. Utilize a PowerShell script (instead of mofcomp.exe) to register a WMI event subscription (same event as Attack 1).
2. The event consumer, “commandLineConsumer” would fire another PowerShell script (script.ps1) that would then execute the fiber injection (fibres.exe), every time the Windows Store application was launched.
3. None of the basic OpSec modifications were taken that were described above.

This method was highly effective and was not blocked or flagged by the security stack. The only alert that was generated could actually have been misleading to an incident responder, alerting that the UAC bypass was fully remediated and blocked from executing (this UAC alert happened in both attack scenarios). A busy SOC analyst may have triaged this alert as “investigate later,” depending on their current priorities – afterall, they would have thought the compromise was rectified by the automation. 

​Both “Attack 1” and “Attack 2” resulted in an initial C&C channel in high integrity and a persistent channel with SYSTEM level integrity. None of these attacks were blocked from completing but “Attack 1” certainly generated more alerts that would get the operation burned. 

After completing a week of testing (UAC bypasses + fiber shellcode injection), we put together a few signatures for the Hunter module that would find more shellcode injectors, utilizing process fibers (they are extremely effective). The data we ingested was awesome, with a few great intel finds that we plan to analyze in the coming days.
 

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

Our last bit of UAC bypass tactics research ends off with combining the use of trusted directories using trailing spaces "c:\windows \system32\" and a shellcode injector utilizing process fibers, inevitably resulting in a C2 channel with high integrity. What’s interesting about these trending UAC bypasses our CTI engine has been articulating is that MS doesn’t seem to consider them a security boundary. Users that are running with local admin privs (which happens quite a bit) is a big win for an adversary if combined with other evasion tradecraft such as process injection, which we show here. This tactic has a fairly easy detection which is to hunt for any directories with trailing spaces. None the less, it is an effective way to execute malicious code with high integrity, as shown by executing a Covenant implant.
 
Bypass: shubham0d/UAC-bypass-using-dll-injection: A small project to bypass UAC in windows 10/8/7 using dll injection technique (github.com)
 
Blog: Hijacking DLLs in Windows (wietzebeukema.nl)
 
 
#cyberthreatintelligence #infosec #cybersecurity #informationsecurity #threatintelligence #networksecurity #sec #security #tools #offensivesecurity #pentesting #redteam #blueteam
 

​“Recorded Future expects further adoption of open source tools that have recently gained popularity, specifically Covenant, Octopus C2, Sliver, and Mythic." We have strung together some trending, open source tradecraft, utilizing a UAC bypass that has had significant human momentum behind it, showing the potential for serious compromise, with very little modification to the open source tool systems.
 
1. Modify UAC bypass to execute WMIPers.cmd with High integrity
 
2. WMIPers.cmd runs command “PowerShell Set-ExecutionPolicy Unrestricted” to change the execution policy
 
3. WMIPers.cmd executes EventSubWMI.ps1 (High Integrity required) to create a WMI permanent event subscription (SYSTEM). The subscription executes a script when the Windows Store app is opened, firing binary Fibre.exe (a shellcode injector utilizing process fibers to execute)
 
4. WMIPers.cmd also executes Fibre.exe to establish an initial C2 channel in High Integrity
 
5.The Windows Store app is opened, creating a second channel back to the C2 in SYSTEM context
 
*Better OpSec needed (cleanup, windows, etc) for real engagement*
 
#cyberthreatintelligence #infosec #cybersecurity #informationsecurity #threatintelligence #networksecurity #sec #security #tools #offensivesecurity #pentesting #redteam #blueteam

Sensors ingested a new UAC bypass that leverages the AutoElevate attribute for Microsoft signed binary, ComputerDefaults.exe. We tested the bypass against Microsoft for Endpoint in BlockMode which was ineffective. More worrisome, the EDR showed that the threat had been “Blocked” which was inaccurate, as we were even able to execute the exact same binary (UAC bypass) multiple times, that remained on disk. This goes to show, technology still can’t take the place of trained humans required for post-investigation response.  
 
UAC Bypass: 0xyg3n/UAC_Exploit: Escalate as Administrator bypassing the UAC affecting administrator accounts only. (github.com)

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

Intro​
After reading an incredibly eye-opening report entitled, “Russia: EMP Threat” [1]  which dives into the post-soviet, contemporary doctrine of non-contact warfare (“the combined use of cyber viruses and hacking, physical attacks, non-nuclear EMP weapons, and ultimately nuclear HEMP attack against electric grids and critical infrastructures”), we decided to see if we could develop some signatures for the Hunter module that would find and track Russian criminal forums on the clear-net, looking for trending tradecraft. The Federation’s intelligence apparatus is well known to employ elite cyber criminals periodically for government initiatives and this is what sparked our curiosity. Could we develop custom signatures for our automation that would enumerate these key points of interest? What would we find? Ultimately, the answer was yes, we can use our proprietary signatures and automation to articulate trends in these criminal circles. Below, we will discuss some of these interesting findings from this preliminary research as well as lay some broader context behind the initial motivation for this endeavor. 

Full disclosure – we have not had prior training as military analysts, but our team has been observing the technical capabilities of Russian cyber actors, for some time now. Moreover, observing Russian cyber aggressions against places like the Ukraine, resulting in real-world consequences like the annexation of the Crimean Peninsula also intensified our interests. The Ukraine has long been a testing ground for the Russian Federation’s cyber weapons [2], or as they call it, Information Warfare. While many of these recent intrusions into the IT systems of the West have been viewed solely as espionage, there are others that believe there is a far more sinister motivation behind these operations.

“Intrusions look less like isolated cases of theft and hacking and more like probing U.S. defenses and gauging Washington’s reactions—perhaps in preparation for an all-out cyber offensive that would include physical sabotage, radio frequency weapons, and ultimately nuclear HEMP attack [3].”

This was the primary motivation to begin down this path; to see if we could use our open-source capabilities and shed some light on this Russian information warfare onslaught.
 
Lastly, we leave the readers with supporting technical documentation in hopes to spur further discussion and analysis. 


Russian Information Warfare
​Russia views the cyber domain considerably different from the west, both from defensive and offensive perspectives. The federation sees the freedoms and connectivity that the internet brings as dangerous, potentially sewing dissention and democratic views within the regime. Understanding the mindset of the state, which is said to be a mindset of “worst case scenario,” provides a valuable lens for interpreting how the power structure would view adjacent events such as the toppling of governments in Georgia’s rose revolution, Ukraine’s orange revolution, and Kyrgyzstan’s tulip revolution [4], in association with the free-speech nature and connectivity of the  internet.

Russia also sees cyberspace as a powerful vehicle to enhance offensive military and political objectives and have become proficient masters of this domain. The Russian ministry of Defense (MoD) plans to create a cyber deterrent akin to the devastation that thermal nuclear weapons would have on an adversary’s civilization. The MoD has an annual budget of ~250M for its cyber activities and invests this capital into initiatives like malware development to target all aspects of Western critical infrastructure (banking, power, defense, aviation, etc…) [5]. This defense budget seems to be well spent as Russian cyber operators have a reputation that precedes them across the globe.  ​

Hunting Tradecraft with a Russian Flavor
 For our preliminary experiment, we wanted to see if we could take existing Cyber Mongol signatures and augment them slightly to find content hosted on Russian Criminal forums. There has long been lines drawn between Russian criminal groups and state sponsored operators such as APT 28, so we thought this might be a good place to start.
 
Using Cyber Mongol hunt signatures for direct system calls, Cobalt Strike binary object files (BOFs), process hollowing and process doppleganging, we hit the clear-net to see what we could turn up. All four signatures succeeded at turning up tradecraft being shared on Russian criminal sites. While our initial research had nowhere near the depth to find innovative APT tactics not yet articulated within the security community, it did prove without a doubt that advanced content which our cyber intelligence engine tracks within the security community is definitely being mirrored on criminally frequented platforms. One of these such platforms (www[.]xss[.]is) had continuous hits with all four of the signatures mentioned above. It also housed other tradecraft that our sensors aren’t tuned to ingest, such as software to create fake passports, carding tactics and other criminal aspects of the Russian underground. 

Conclusions 
While our findings were preliminary and quite raw, we were able to test a completely new application of our existing intelligence stack, with only minor tweaks to the signatures. Seeing on-trend content which our intelligence engine is currently tracking within the security community, being shared and discussed on Russian criminal forums has strengthened our existing stance that the cyber security ecosystem maintains influence over adversary tradecraft adoption. Moreover, knowing that groups like APT 28 have strong links to platforms such as this gives us new ideas on how to better harness and augment our open-source intelligence capabilities. Stay tuned for even bigger and better things to come.

Supporting Documentation

1. Russia: EMP Threat
​2. 2018 CEPA Report Chaos as a Strategy
​3. ​The Russian Military in Contemporary Perspective
4. ​Analysis of the Cyber Attack on the Ukrainian Power Grid

I want to briefly explain the cycle we use for the Hunter module to ingest offensive tradecraft. Step(1): Signatures are distilled by extracting features from already ingested tradecraft that the engine deems relevant.  Features include text processing features, API calls and system binaries. Step(2): These features are refined and given to the Hunter module which searches for matching signatures, across a vast amount of social platforms. Step(3): When like tradecraft is found, it is distilled in the same fashion and the cycle repeats. Example tradecraft in this post can be found below and emphasizes our last post regarding an ongoing, widespread adoption of direct syscall use.
 
Dumpert2000:
gitjdm/dumper2020: Yet another LSASS dumper (github.com)
 
Syscalls & Cobalt Strike:
Implementing Syscalls In The Cobaltstrike Artifact Kit – bs – no bs (br-sn.github.io)
 
#cyberthreatintelligence #infosec #cybersecurity #informationsecurity #threatintelligence #networksecurity #sec #security #tools #offensivesecurity #pentesting #redteam #blueteam

​On average, AV/EDR is doing a good job at catching this type of injection. In this video, we first hollowed with OpenThread, SuspendThread, VirtualAllocEx, WriteProcessMemory, and ResumeThread which was swiftly dealt wit by Defender for Endpoint. However, our automation distilled another prevalent API signature for hollowing that was used later in the video and ran undetected. Our automation creates these signatures by looking over millions of lines of malicious code and graphing relationships between files, functions, processes, libraries and social contexts. A detailed look at these process hollowing techniques and a look at the signature we distilled to find advanced Cobalt Strike tradecraft, will be published in our first-ever Cyber Mongol CTI report.  Get a hold of us to find out more. 

​A dirty UAC bypass is just enough time to register a WMI permanent event subscription (which needs to be registered with Admin privs), executing a binary that injects into nslookup.exe, every time the Microsoft Store app process is started. The injection results in a persistent, SYSTEM level implant phoning home to a Covenant C2 listener, provided the artifacts on disk aren’t discovered. There are other vectors available a little more OpSec friendly 😊. MS for Endpoint flags the UAC bypass as malicious (doesn’t stop it) but doesn’t see the WMI event subscription, therefore does not indicate a persistent SYSTEM level shell is present. The device timeline does register the script that is fired by the WMI event subscription and the binary that hollows the process nslookup.exe – but neither are flagged. Checking for WMI event subscriptions is a good way to find nastiness with the following commands:
 
EventFilters: Get-WMIObject -Namespace root\Subscription -Class __EventFilter
 
EventConsumers: Get-WMIObject -Namespace root\Subscription -Class CommandLineEventConsumer
 
Bindings: Get-WMIObject -Namespace root\Subscription -Class __FilterToConsumerBinding

Intro​
Anticipating an adversary’s intentions, behaviors, or movements is nothing new. Generals from ancient times have prioritized this aspect of warfare and for good reason, "If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. [1]" Open-source Intelligence (OSINT) is the cornerstone of what we (Cyber Mongol) do. Specifically, the development of automation to locate, contextualize, classify and articulate emerging adversary behaviors is what we specialize in. Analyzing the triaged signals produced by our technology can allow analysts to make educated predictions on how adversaries may attack their IT assets. In this mini case study, we are going to use our technology to look at the tradecraft (behavior) profiles of Iranian threat actors (APT 39, APT 33, Chafer & OilRig) and make predictions on how those profiles may migrate (change) due to advances in defensive technologies.  

Heavy Community Chatter
One aspect of our sensor’s technology is its ability to listen to what is being talked about within the security community, then distill the content (blog posts, exploits, tradecraft, social exchanges) being shared. It was through this functionality that we have seen heavy chatter regarding Iranian threat groups, and the campaigns they have undertaken. Specifically, we are seeing substantial signaling surrounding the Fox Kitten campaign [2], the continued exploitation of external remote services [3], Chafer’s activities [4] and CISA’s warning of continued webshell usage by Iranian APTs [5]. 

Building a Current Tradecraft Profile
Using the references stated above, and some resources from MITRE ATT&CK [6], [7], [8], we put together a behavior profile for Iranian threat actors based on current knowledge. We distilled key areas (specific to our in-house needs) of this current profile, so that we could perform predictive analysis that may indicate how these operators may change their offensive behaviors in the near future. Some bullets (behaviors/software used) at a high level of the profile are as follows:
 
-phishing techniques
-external remote services leveraging 1-day exploits (Citrix, BIG-IP, Pulse Secure, etc..)
-webshells
-Juicy Potato
-Mimikatz and variants
-LaZagna
-Procdump
-Brute forcing of internally mapped assets
-stolen legitimate credentials (OWA)
-Invoke-TheHash (PowerShell pass-the-hash)
-PowerShell commands accessing remote computers via WMI and SMB protocols
-CrackMapExec (Impacket, LOLBAS)
-Keylogger
-Screen capture
-clipboard data
-ports 80, 443 & 22
-Ngrok
-PowerShell Empire
 
How Do We Predict
Predictions are made utilizing our technology and by employing two internally developed, predictive analysis techniques. The first technique focusses on graph analysis and the second makes assumptions based on current trends in offensive operator tactics and the current behavior profile of the adversary being observed. Below, in-house priority board for the hottest publicly available exploits, which are tracked by our CTI engine, over a 6-month period.

Social Reach and Graph Theory
Our research has concluded for some time now, that advanced adversaries look to the security community for ways in which to advance or migrate their tradecraft. Furthermore, the social reach and the relational structure of development clusters within the security community, can directly influence adversary adoption. We see this theory in play as we analyze APT 39, APT 33, Chafer & OilRig’s preferences for offensive tooling. In the graph depicted below, we can see the threat actors’ most favored tools (Indicated above and by green boxes in the graph) are tightly grouped amongst a smaller sub-cluster within the broader security community. We can definitely see adversary adoption within this sub-community is strong and can make the extrapolation that adoption may continue just as strongly. If that is the case, we can look to see what tools are closely connected to the groups preferred tooling and then look to see which of those connected tools are natural evolutions of the group’s tradecraft. ​

Insecure Deserialization
Connected within the subcommunity to CVE-2019-19781 (Remote Code Execution on Citrix ADC Netscaler) which is heavily exploited by Iranian operators [10], there is a sub-cluster connection to CVE-2020-0688 which exploits OWA by way of insecure deserialization. Given the group’s predisposition to attacking externally facing resources and OWA [11], we felt this may be a great introduction (if not already utilized) into insecure deserialization tradecraft. Furthermore, this small sub-cluster houses the two most popular (by sensor hits) tool systems for insecure deserialization, ysoserial [12] and ysoserial.net [13].

C# and other .NET Vectors for C2 and Post Exploitation
With the group’s tendency to PowerShell tooling like Empire, Invoke-TheHash and PowerSploit, we predict that these threat actors will migrate further into .NET, utilizing ports of tools they already know, and others that may be new but socially connected to tools they know and trust. SILENTRINITY [14] is connected to multiple tool systems the group leverages and combines disparate post exploitation tradecraft that the group employs, under one cohesive feature set – this C2 really seems like it was tailormade to match Iranian threat actor behaviors! For instance, one feature that matches Iranian behavior profiling is the framework’s ability to leverage WMI to execute remote commands and substitute credentials with stolen password hashes. Moreover, leveraging an open-source tool system provides operators with a level of anonymity, not otherwise attainable with custom tooling.

Credential Access
As modern endpoint defenses constrict malicious activity, dumping LSASS via Procdump, which is indicative of Iranian operators, is not an option without being flagged. Lsassy [15], a tool which leverages this method can be seen in the subcommunity and is also connected via functionality to CrackMapExec (another Iranian APT favorite). Even trying to dump LSASS as SYSTEM, leveraging comsvcs.dll will burn your operation to the ground. We see two potential migrations available for Iranian threat operators, in order to continue to dump credentials utilizing similar tradecraft. The first migration could use evasion techniques that are quite popular within the community, currently. API unhooking techniques, signed driver exploitations (kernel memory space), shellcode execution via fibers and direct system calls all are effective right now at evading endpoint defenses and may even facilitate the use of mimikatz directly (example unhooking). The other option is to use a tool like SharpMiniDump [16] which has built-in evasion techniques such as those mentioned above and utilizes the MiniDumpWriteDump API. We see this as a very probable migration for Iranian threat actors looking to dump LSASS as it is already present in some of the mimikatz permutations [17] utilized, just not articulated in threat reports that we’ve seen. 

Privilege Escalation with the Potato
Iranian APT groups leverage juicy potato [18] for privilege escalations, more specifically to escalate Windows service accounts to SYSTEM through impersonation. For this migration we look at a trending tool meant to do a very similar task, PrintSpoofer [19].
 
 
Webshells
CISA’s warning of continued webshells being leveraged by Iranian APTs is accompanied by growing signals across the board we see regarding webshells. There is a marked increase in webshell activity on the sensors [20] and we don’t see any type of migration deviation happening from this behavior. Webshells are here to stay.
 
 
1.https://en.wikipedia.org/wiki/The_Art_of_War#:~:text=The%20Art%20of%20War%20is%20an%20ancient%20Chinese,how%20it%20applies%20to%20military%20strategy%20and%20tactics.
2. https://www.clearskysec.com/wp-content/uploads/2020/02/ClearSky-Fox-Kitten-Campaign.pdf
3. https://securityaffairs.co/wordpress/106898/apt/iranian-hackers-f5-big-ip-flaw.html
4. https://www.bitdefender.com/files/News/CaseStudies/study/332/Bitdefender-Whitepaper-Chafer-creat4491-en-EN-interactive.pdf
5. https://us-cert.cisa.gov/ncas/analysis-reports/ar20-259a
6. https://attack.mitre.org/groups/G0064/
7. https://attack.mitre.org/groups/G0049/
8. https://attack.mitre.org/groups/G0087/
9. https://github.com/kgretzky/evilginx2
10. https://us-cert.cisa.gov/ncas/alerts/aa20-259a
11.https://www.fireeye.com/blog/threat-research/2019/01/apt39-iranian-cyber-espionage-group-focused-on-personal-information.html
12. https://github.com/frohoff/ysoserial
13. https://github.com/pwntester/ysoserial.net
14. https://github.com/byt3bl33d3r/SILENTTRINITY
15. https://github.com/Hackndo/lsassy
16. https://github.com/b4rtik/SharpMiniDump
17. https://github.com/GhostPack/SafetyKatz
18. https://github.com/ohpe/juicy-potato
19. https://github.com/itm4n/PrintSpoofer
20. https://github.com/tennc/webshell

Intro
In this first scenario, we will create a very noisy attack chain based on our trending threat intelligence and see which parts ATP’s new Block feature will detect, block and(or) auto-remediate.  The endpoint under test has been added to the automated investigations group and ATP’s EDR block mode has been enabled.
 
“When endpoint detection and response (EDR) in block mode is enabled, Microsoft Defender ATP leverages behavioral blocking and containment capabilities by blocking malicious artifacts or behaviors that are observed through post-breach protection. EDR in block mode works behind the scenes to remediate malicious artifacts that are detected post-breach [1].” - docs.microsoft.com​

Method: Noisy 
1. We drop a malicious CMD to disk which invokes PowerShell (Invoke-WebRequest) to download a vulnerable driver (RTCore64.sys), PPLKiller and a shellcode injector that utilizes direct system calls to establish a channel with Covenant C2 (SYSTEM level integrity). The Micro-Star MSI Afterburner driver [2] is a signed Microsoft driver which can be exploited to allow arbitrary read/write access of kernel memory [3]. While this CMD script is not practical from a red team perspective (needs a UAC bypass / lots of things dropped to disk, visible console windows), it does generate some dangerous and noisy behaviors that will test ATP’s ability to detect and respond in an automated fashion. ​

​2. Next, we see in the Device Timeline that ATP registers the driver (RTCore64.sys) being loaded and the PPLKiller process being created. 

​3. APT does issue a warning for a suspicious file being dropped to disk (PPLKiller.exe) and for a process privilege escalation. These events set off an automated investigations response but that does not result in the blockage of the malicious activity. 

​4. Next we execute our shellcode injector within the SYSTEM level shell, utilizing direct system calls to gain code execution. The device timeline did not register this injection but it did see S2.exe (the injector) make a network connection to the C2 channel - no warning or no remediations. 

​5. So far, we have raised two alarms (suspicious file drop and process PE), set off an automated investigation, but our behaviors have not been blocked and we are free to begin post-exploitation activities. For this part of the attack chain we are going to get extremely noisy, we are going to run the Mimikatz module that comes standard with Covenant C2

​6. The use of Mimikatz did trigger the third and final alarm.  At this point our actions are not blocked, we have executed code on the endpoint, dumped password hashes from LSASS and the automated investigation response is still assessing our behaviors.

​7. The final conclusion of the automated response was that our activity, while suspect, was not found to be malicious. While any human hunt team would have surely had enough IOA’s to leap into full response mode, the point was to test ATP’s new feature's ability to BLOCK and REMIDIATE malicious behaviors, missed by the first stage antivirus. This was a fail.

Method: Stealth Mode
Now, we are going to attack the same setup but actually try and remain undetected. The CMD script still isn’t of professional quality as it needs UAC bypass, shows visible console windows, but we are just trying to replicate the above behavior (Download -> Execute -> Dump LSASS) without tripping any defenses. Again, the endpoint under test has been added to the automated investigations group and ATP’s EDR block mode has been enabled.
 
1. We recompiled the shellcode injector code, making minor changes to change its signature. Instead of Mimikatz to dump hashes, we will use b4rtik's SharpMiniDump [4], altering the code slightly to avoid detection.

2. The script starts by using Invoke-WebRequest (just like above) to download the LSASS dumper (g.exe) and the C2 shellcode injector (StealthFighter.exe), dropping them to disk. Defender’s device timeline registers the events but provides zero detections. 

​3. The device timeline articulates the PowerShell command “Start-Process” with the corresponding process creation, but still no detections. 

​4. Next, we can see g.exe open a handle to LSASS in order to dump the password hashes – no detections. 

​Finally, we have generated a .dmp file (happy.dmp) and are able to ingest it into an offline copy of Mimikatz to extract the credential material. – No Detections 😊 Fail X2

1. https://docs.microsoft.com/en-us/windows/security/threat-protection/microsoft-defender-atp/edr-in-block-mode
2. http://download-eu2.guru3d.com/afterburner/[Guru3D.com]-MSIAfterburnerSetup462Beta2.zip
3. https://br-sn.github.io/Removing-Kernel-Callbacks-Using-Signed-Drivers/
4. https://github.com/b4rtik/SharpMiniDump
​

Intro
Simplicity can be powerful when operating in the murky world of the digitally complex. I know the sinking feeling of waging war against state-of-the-art endpoint defenses, only to get crushed at your most hopeful. You have probably spent days wrapping your head around concepts like API unhooking, found and edited PoC code to mount an attack, then only to be crushed by the swift response of multi-tiered machine learning. Well, todays story is different! Today, I will tell you of a battle won with clever simplicity, waged against the multi-headed beast Windows Defender ATP and all its machine learning minions. This battle was not won by replacing jump points in EDR occupied memory space, it was won by probing for weakness and making calculated strikes against the ML models.

 
“So in war, the way is to avoid what is strong, and strike at what is weak.” ― Sun Tzu, The Art of War

 
Multilayer ML
Defender ATP (like other EDRs) employs a multi-tier approach to threat protection. It has hooks and sensors within the operating system, vast amounts of compute power and elaborate machine learning models that are continually classifying known good, from known bad. Yet, standing in opposition to this almost unsurmountable defense, there is a chink in the armor that is revealed to the astute observer. Like many complex systems, their complexity is both the root of their power and also their Achilles heel. Defender uses machine learning models in conjunction with static and dynamic analysis methods to classify bad things from good things. But how does it make these decisions? Well, that I’m sure is a very closely guarded secret by Microsoft, but we can make educated assumption’s by utilizing trial and error and interpreting the results. Machine learning models can be trained by using something called features. In this case, a feature could be an API call made in a malicious context, different offensive behaviors exhibited, or really any other indicator Microsoft feels is relevant. After the model is exposed to thousands, or even hundreds of thousands of features, it is ready to make predictions based on the features it has seen. Now, there are models that produce black and white answers (this file is good / bad) and others that provide an estimation. For this reason (to avoid many false positives), a threshold has to be established before Defender will block the file in question. The threshold Microsoft employs is a confidence score of 90% or greater that the thing in question, is malicious. It is in this area of complex decision making that we can manipulate the features being observed in combination and reduce the model’s confidence score to under 90%. If we do that, our malicious activity will not get blocked by endpoint defenses and we can proceed to inflict havoc as we see fit.
 
“In order to avoid false positives, cloud protection service is configured by default to require at least 90% probability to block the malware [1]”

“For the fastest classifiers in our layered stack, the features may include static attributes of the file combined with events (for example, API calls or behaviors) seen while the scanning engine emulates the file using dynamic translation. [1]”

Where the Hooks At?
I decided to revisit some process hollowing code in C# which now is getting consistently busted by Defender ATP. My intentions were to employ a much more complex attack vector which included switching out some of the API calls and utilizing unhooking techniques that we are seeing trend right now. Before jumping into all that, I started to review some of the circumstances surrounding the immediate quarantine of my injector. I knew that the standard API calls I was using for process hollowing would surely be raising some alarms (SuspendThread, NtUnmapViewOfSection, VirtualAllocEx, CreateRemoteThread, WriteProcessMemory). Looking back at the EDR history I saw definite evidence of that – a detection on NtAllocateVirtualMemory API call which is VirtualAllocEx’s lower-level cousin. After reading the article in which I took the above excerpts, I wondered if the combination of certain processes being created in conjunction with certain other API calls (like VirtualAllocEx) were what was pushing the model to a 90% confidence score. I decided to start to play with process selection and leave the current API calls intact – for now. 

So Many Process Injections
While rifling through the system32 folder for processes to create in a suspended state, I soon made the discovery that selecting specific processes was enough to reduce the model’s confidence and let me inject with immunity. I actually got ridiculous with this; injecting 30 different processes with the exact same API calls…including VirtualAllocEx! The realization was clear, as long as I chose processes that the model must not have seen features for, I wouldn’t need to edit the C# injector code at all. Defenders ML model must put a high degree of emphasis on certain processes that are created in conjunction with certain API calls. As long as I avoided the processes it squawked on, I would run undetected – simple and clean. I decided to run through almost the entire system32 folder just to document my findings, as about half of the processes I tried did trip defenses. In the end, I had 30 different processes I could safely inject into, all with varying degrees of Opsec from human hunt teams. There were some other considerations I had alongside of Opsec.
 
1. Could I spawn a process without any arguments needed?
2. Will the process close immediately after executing?
3. Is there a visible window a user can see and(or) close?
4. What background processes could I use?
5. Should this process be connecting to the internet?
 
Below, a video of my 30 processes running in all their glory as Covenant C2 Grunts. 

​1.https://www.microsoft.com/security/blog/2017/12/11/detonating-a-bad-rabbit-windows-defender-antivirus-and-layered-machine-learning-defenses/

Intro

​​While it is bold to claim your company possesses predictive cyber intelligence technologies, we (Cyber Mongol) can positively say that our technology regularly provides early warning signals for damaging cyber events. TALK IS CHEAP – that’s why we like to back up our dialogue with facts, posting signals and analysis publicly as we see it. This story encompasses the F5 Networks BIG-IP vulnerability (CVE-2020-5902), Cyber Mongol’s signals and early warning issued to the community, CISA (Cybersecurity & Infrastructure Security Agency) issuing its own warning and culminating this week with an FBI Private Industry Notification (PIN), confirming that advanced operator tactics are now including this vector.
 
This story of exploitation begins like any other, a vulnerability is discovered (June 30th, 2020) which could potentially lead to exploitation; in this case full RCE (remote code execution) – a CVSS score of 10! Cyber Mongol doesn’t tune its instrumentation to listen for events indicating that a bug has been found. Instead, our sensors are tuned to identify when PoC (Proof of concept) exploit code becomes publicly available. Yes, exploits could exist far before and brokered in private deals, but it’s when an exploit such as this becomes freely available and integrated into exploit frameworks, that we see exploitation at mass-scale. Our CTI engine (PANDEMIC) started ingesting publicly available exploit code (June 4th / June 5th), the same time CISA (Cybersecurity & Infrastructure Security Agency) started initiating their own investigations [1]. 

CISA Investigations: Released on July 24

"On July 4, open-source reporting indicated a proof-of-concept code was available and threat actors were exploiting the vulnerability by attempting to steal credentials. On July 5, security researchers posted exploits that would allow threat actors to exfiltrate data or execute commands on vulnerable devices. The risk posed by the vulnerability is critical." - CISA

​"As early as July 6, 2020, CISA has seen broad scanning activity for the presence of this vulnerability across federal departments and agencies—this activity is currently occurring as of the publication of this Alert" - CISA

​Cyber Mongol: Sensor Ingestion Table

Cyber Mongol Public Statement & Resources: Released on July 9

Conclusion

The CISA investigations [1] into the BIG-IP exploitation wouldn’t become publicly available until July 24th, 15 days after Cyber Mongol released a public warning and an extensive resource containing links to more than 28 publicly available exploits and scanners [2]. Observing and reacting to Cyber Mongol produced signals would have given organizations an 18-day jump in preparation, assessing risks and patching vulnerable equipment. Moreover, on July 15th our sensors saw that CVE-2020-5902 became assimilated into the exploit framework Cobalt strike within the Chinese security community, indicating preparation for mass-scale exploitation. 

​1. https://us-cert.cisa.gov/ncas/alerts/aa20-206a
2. https://www.cybermongol.ca/signal-sets.html

Intro​

If we think of the exploit frameworks Empire and Impacket as celestial bodies, they could be viewed as binary stars that are locked in a cosmic dance, bound by their gravitational attractions. If we change our perception of graph relationships and think of the edges as gravity, we can start to see the influential nature that certain nodes in the graph possess over others. Interesting parallels start to emerge when comparing a threat landscape and a cosmic universe. There are patterns of tradecraft collections bound together by relationships, born of central and influential nodes. This starts to sound a lot like how stars birth planetary systems, born of the same cosmic materials and orbiting because of the star’s influence - gravity. Just like humans map the stars and the systems they belong to, our team maps offensive tradecraft and the collectives they are related to. 

We could essentially think of the graph itself as a universe, containing many other influential star systems. These star systems give birth to planetary bodies that share a relationship to the stars that created them. It is in this context we look at our graphs, examining the relationships, proximities and the evolutions of offensive tradecraft. Just as objects in space suddenly or more predictably get caught by the forces of other galactic objects, we are able to observe changes in relationships and tradecraft patterns, within our graphs. Lastly, just as trained astronomers are able to make predictions by studying the heavens, we are able to start to predict migrations in tradecraft by studying our data.
 
 
Let’s look at a practical example of the observations we are making. Circle back to the binary star example of Empire and Impacket as these can be viewed as the center of the .NET tradecraft system. Both of these frameworks are connected to many highly skilled, offensive .NET tradecraft developers. We will take a spin around this system to see how influential exploit frameworks give rise to emerging offensive tradecraft. Below, you will find images of our tradecraft universe that have been labeled with the corresponding articulations.


A Closer Look at the .NET System
 
Empire: "Empire is a post-exploitation framework that includes a pure-PowerShell2.0 Windows agent, and a pure Python 2.6/2.7 Linux/OS X agent. It is the merge of the previous PowerShell Empire and Python EmPyre projects. The framework offers cryptologically-secure communications and a flexible architecture. On the PowerShell side, Empire implements the ability to run PowerShell agents without needing powershell.exe, rapidly deployable post-exploitation modules ranging from key loggers to Mimikatz, and adaptable communications to evade network detection, all wrapped up in a usability-focused framework. PowerShell Empire premiered at BSidesLV in 2015 and Python EmPyre premeiered at HackMiami 2016."

Repo: https://github.com/EmpireProject/Empire

Impacket: "Impacket is a collection of Python classes for working with network protocols. Impacket is focused on providing low-level programmatic access to the packets and for some protocols (e.g. SMB1-3 and MSRPC) the protocol implementation itself. Packets can be constructed from scratch, as well as parsed from raw data, and the object oriented API makes it simple to work with deep hierarchies of protocols. The library provides a set of tools as examples of what can be done within the context of this library."
 
Repo: https://github.com/SecureAuthCorp/impacket

SILENTTRINITY: "SILENTTRINITY is modern, asynchronous, multiplayer & multiserver C2/post-exploitation framework powered by Python 3 and .NETs DLR. It's the culmination of an extensive amount of research into using embedded third-party .NET scripting languages to dynamically call .NET API's, a technique the author coined as BYOI (Bring Your Own Interpreter). The aim of this tool and the BYOI concept is to shift the paradigm back to PowerShell style like attacks (as it offers much more flexibility over traditional C# tradecraft) only without using PowerShell in anyway."
 
Repo: https://github.com/byt3bl33d3r/SILENTTRINITY

Covenant: "Covenant is a .NET command and control framework that aims to highlight the attack surface of .NET, make the use of offensive .NET tradecraft easier, and serve as a collaborative command and control platform for red teamers. Covenant is an ASP.NET Core, cross-platform application that includes a web-based interface that allows for multi-user collaboration."
 
Repo: https://github.com/cobbr/Covenant

Seatbelt: "Seatbelt is a C# project that performs a number of security oriented host-survey "safety checks" relevant from both offensive and defensive security perspectives."
 
Repo: https://github.com/GhostPack/Seatbelt

Sharp WMI: "SharpWMI is a C# implementation of various WMI functionality. This includes local/remote WMI queries, remote WMI process creation through win32_process, and remote execution of arbitrary VBS through WMI event subscriptions. Alternate credentials are also supported for remote methods."
 
Repo: https://github.com/GhostPack/SharpWMI

SharpSploit: "SharpSploit is a .NET post-exploitation library written in C# that aims to highlight the attack surface of .NET and make the use of offensive .NET easier for red teamers. SharpSploit is named, in part, as a homage to the PowerSploit project, a personal favorite of mine! While SharpSploit does port over some functionality from PowerSploit, my intention is not at all to create a direct port of PowerSploit. SharpSploit will be it's own project, albeit with similar goals to PowerSploit."
 
Repo: https://github.com/cobbr/SharpSploit

SharpC2: ".NET Command & Control Framework"
 
Repo: https://github.com/SharpC2/SharpC2

Intro​
As we push towards realizing the Cyber Mongol vision of teaming advanced automation with human defenders, it’s exciting to see pieces of our technology come to life from concept. Our most recent concept that went under the lightning rod and brought to life like Mary Shelley’s Frankenstein, was automated adversary behavior tagging. Essentially, any emerging tradecraft that hits our sensors and passes triage, will be automatically defined and categorized by the offensive behavior it represents – example process injection. While it seems common practice in the industry today to elude to the fact that your solution only uses the most advanced neural networks and ML models, that can be incredibly misleading as rule-based Regex is still a major component for effective detections. I’m not saying we don’t use ML within our pipeline, I’m just saying it works synergistically with the other logic to produce results. This blog post is a product of creating a small subset of Regex rule-based logic to detect process injection and I thought it might be helpful to share with the community.  
 
We have been conducting extensive research in process injection, their variations and security solution API hook evasion over the last month. While none of these techniques are new, we are seeing an increased interest within the security community in regard to these vectors, based on our ingested signals. Additionally, these signals represent ways to execute malicious code on endpoints and evade AV/EDR solutions, emphasizing their significance in relation to the cyber Kill Chain. Process Injections, their variants and API hook evasion techniques like direct SYSTEM calls are heavily used by advanced actors such as nation states, criminal syndicates and hacktivists. I wanted to share a high-level overview of a few process injection variants and the common API calls they make. This post is not meant to be a deep technical dive into the internal workings of process injection, but to possibly aid in the comprehension of the technique to the unfamiliar, and enumerate some of the functions (common and uncommon) that we see being utilized for this tradecraft. Knowing which API calls are in vogue and may represent malicious activity, can definitely strengthen a threat hunting initiative.  


Process Injection
So, what is a process injection? Process injections attempt to run arbitrary code in the memory space of targeted processes, executing malicious code that can evade endpoint protections. At the most basic level (and most well-known), a process injection works by getting access to a target process with the OpenProcess function, allocating memory within the process with VirtualAllocEx, writing malicious code to the allocated memory space with WriteProcessMemory, and then finally executing the malicious code with CreateRemoteThread. Alternatively, instead of opening an already existing process, an operator may choose to spawn a new process and inject malicious code into that process’s memory space with the CreateProcess function. These API’s are well known to be heavily exploited by injection techniques, and as such, security venders monitor (or hook) these functions so that they can inspect the code being executed. These security hooks (or inspections) happen in what’s called Userland (code that runs outside of the OS kernel) and can be bypassed with various techniques [1], [2]. Additionally, there are different variations of process injection – Process Hollowing and Process Doppelganging are two variation examples. 

Process Hollowing
Process Hollowing substitutes the memory space of a remote process with operator-controlled memory. This is achieved by creating a process in a suspended state with CreateProcess(CREATE_SUSPENDED), deallocating (hollowing) the suspended process’s memory space with NtUnmapViewOfSection, allocating memory for malicious use with VirtualAllocEx, write the malicious PE (portable executable) sections (data, text, etc…) to the newly allocated memory addresses with WriteProcessMemory, point the EAX register to the correct position in the text section by using SetThreadContext and finally, execution is achieved once the process is re-started with ResumeThread. This technique’s goal is to hide the execution of malicious code within a benign process. 


Process Doppelganging
Process Doppelganging looks to achieve execution of malicious code in the context of a legitimate process, use none of the suspicious API calls used in Process Hollowing (NtUnmapViewOfSection, VirtualProtectEx, SetThreadContext), to have the antivirus only scan clean files and to remain hidden from advanced forensic tools. A Doppelganger has 4 steps which are needed to successfully execute this type of injection. It needs to overwrite a legitimate executable with a malicious one (Transact), it needs to load a malicious executable (load), it needs to roll back to the original executable (rollback), and it needs to bring the Doppelganger to life (animate). The Transact step uses multiple Transactional NTFS functions to accomplish its goal. The CreateTransaction function will create an initial transaction, the CreateFileTransacted function is used to open a clean file (example svchost.exe) within the transaction and lastly, the clean file meant to evade endpoint protections will be overwritten with malicious code using the WriteFile function. Anything trying to inspect the file will not see the changes that have been made as they have occurred within the transaction, and the inspection is taking place outside of that transaction’s context. Additionally, after the rollback phase (which completes the NTFS transaction), the file will be reverted to its original clean state. The load phase will create a section object (a buffer of sorts) from the transacted file (svchost.exe) that points to a malicious executable with NtCreateSection. The Rollback step simply rolls back the changes made to the file system with RollbackTransaction but leaves the malicious section object that is pointing to the evil executable, intact. In the final step, the technique needs to create a process from this malicious section with NtCreateProcessEx(Process,..Section) which looks legitimate but runs malicious code inside of it, create a thread to the process using NtCreateThreadEx , create process parameters, copy parameters to the newly created process’s address space and start the Doppelganger’s execution using NtResumeThread. 


Conclusion
Even if endpoint protections are bypassed with some of the techniques mentioned above, it still may be possible to enumerate suspicious API usage if you know what you are looking for – example ProcMon [3]. Some EDR vendors also offer advanced hunting queries that may also be used to assist in locating malicious API calls.  

Follow-on Resources:
1. https://rastamouse.me/blog/process-injection-dinvoke/
2. https://www.solomonsklash.io/syscalls-for-shellcode-injection.html
3. https://docs.microsoft.com/en-us/sysinternals/downloads/procmon

Intro
At Cyber Mongol, we are in the business of forecasting and articulating trends in emerging adversary behaviors. One important aspect of behavior forecasting is ground-truthing some of the emerging signals we see being articulated by our CTI engine. Over the last year, it has become increasingly more difficult to execute and evade on a Windows 10 endpoint, with off-the-shelf tooling. Being able to pull-off sophisticated operator tactics, with little to no modification to the underlying tradecraft, is important to our research because it signals to the likelihood an enterprise may encounter this vector. An effective technique to skirt modern defenses and achieve execution with just the knowledge of what tool systems to string together is quite advantageous for adversaries. Unsophisticated adversaries will utilize this knowledge for the obvious reason of reducing the associated skill barrier with an otherwise advanced technique that may not be otherwise accessible. Sophisticated adversaries may also utilize this same knowledge to mimic unsophisticated adversaries and make attribution more difficult. In this research, we string together tools that have been signaled by our CTI engine to get a Covenant C2 grunt (implant) to execute on a Win10E 1909 endpoint and bypass standard defenses in the Enterprise stack. 

​
​The Tools: Covenant C2
Covenant C2 is a .NET command and control framework that aims to highlight the attack surface of .NET, make the use of offensive .NET tradecraft easier, and serve as a collaborative command and control platform for red teamers [1]. This opensource project is connected to one of the most influential development clusters associated with offensive .NET tradecraft. The efficacy of emerging tool systems can also be judged by other tool systems connected to the same development cluster. In this case, this tool walks among gods with the likes of Empire [2], Bloodhound [3] and Impacket [4] associated to the cluster

The Tools: donut​
Donut creates position-independent shellcode that loads .NET assemblies. This is a massive topic domain in itself and a great place to start, is to read the Wover’s blog post [5] which is a primer on the tool and .NET tradecraft. For this discussion, it will suffice just to know this tool enables us to take Covenant’s binary launcher(.exe) and create shellcode that will inject into a suspended process’s memory and gain execution while evading defenses. This is actually quite important tradecraft when operating with Covenant C2 as the framework does not possess the ability to generate shellcode natively, which is needed for more advanced attacks like process injection.


​The Tools: defcon27 Talk
Our sensors picked up chatter mid 2019 regarding a talk at defcon entitled “Writing custom backdoor payloads with C# [6]”. The resources surrounding this talk (lab guide and source code) are incredibly great to learn these advanced techniques from. They also make it fairly easy for an operator possessing an intermediate skillset to implement sophisticated tactics – provided they know how to slightly modify the vector articulated in the talk.


Technique: Process Hollowing (T1093)
Process hollowing occurs when a process is created in a suspended state then its memory is unmapped and replaced with malicious code. Similar to process Injection, execution of the malicious code is masked under a legitimate process and may evade defenses and detection analysis [7]. Examples of advanced adversaries and tool systems that utilize process hollowing are Gorgon Group [8], Cobalt Strike [9] and Smoke Loader [10].​

Stringing It All Together
As stated above, the whole point of this exercise is to get a Covenant Grunt executed on a Windows 10 endpoint, without tripping defenses. It would stand to reason that the first step would then be to setup a Covenant C2 infrastructure as per your needs.

1. Once you have an infrastructure in place, generate a Covenant binary launcher and save the executable that is produced “GruntStager.exe”.
2. Next you will need to install donut. Create C# shellcode from the Covenant launcher(.exe) with the following options: setting architecture to x64 (-a 2), selecting C# for output (-f 7) and saving to a blank file called “GruntStager.bin”. The command to do this is: <command> donut.exe -a 2 -f 7 C:\Users\Administrator\Downloads\GruntStager.exe -o C:\Tools\GruntStager.bin</command>
3. Within the defcon27_csharp_workshop, navigate to the C# script contained in lab7, entitled 2.cs [11]. Here, we will need to edit the process to be manipulated (line 63) which we will set to “notepad.exe” and replace the byte array after “=” with the newly generated byte array thanks to donut, contained within “GruntStager.bin”.
4. Now let’s rename and compile that C# code using CSC.exe with this command: <command>c:\Windows\Microsoft.NET\Framework\v4.0.30319\csc.exe phallow.cs</command>
5. Deliver and execute the newly compiled binary to the target machine, evading Windows 10 standard enterprise security features.