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.