By: Daniel Bresler, CyOps Team Leader

.NET binary abuse is not overly sophisticated, nor is it a new method of attack, but it is a frequently overlooked one that security teams should understand. Further, these types of attacks continue to be prevalent: this class of malware is readily available on the dark web, and responsible for threats such as SynAck ransomware. Most security professionals are aware that the .NET layer on Windows is not secure enough. They also know that NET runtime compilations can be manipulated to evade common detection methods, where attackers take advantage of .NET utilities/binaries to carry out malicious infections. Because .NET is installed in Windows and comes with a package of developer tools which can be abused, every machine is vulnerable to abuse.

Let’s take a look at how this can happen.

Most malware payloads are delivered by malware helpers such as downloaders and droppers (also known as launchers or loaders). Today, the most common “weak links” in which malware infiltrates the organization and achieves av evasion include:

  • Phishing or spam emails
  • Malicious office documents weaponized with malicious macros (executing embedded Visual Basic code once the victim enables macros on the document) and with DDE functionality (Dynamic Data Exchange) or embedded exploits that extract or download the actual malware and execute it on the machine, while also ensuring persistence, in case the machine is rebooted or the user logs off.

 

How Attacks Are Carried Out

The attacks can be carried out in the following manners:
Malicious Microsoft Office documents can include embedded C# code which is then compiled into a new malware downloader.

Delivery via document:
Flow Chart of dot NET binary attack delivery via document

This is done by invoking the C# command line compiler without the need for Visual C# studio to be installed on the machine.

Sometimes, executables will compile the malware and place it where it is not easily detectable.

Delivery via executable:
Flow Chart of dot NET binary attack delivery via executable

Another way of manipulating .NET binary is when malware runs malicious code inside legitimate .NET processes, such as MSBuild.exe and RegAsm.exe.

This technique is a classic method to bypass antivirus detection, to utilize application whitelisting bypass, and to potentially evade certain EDR solutions. Traffic originating from these compromised processes bypasses application whitelisting controls (i.e. AppLocker, which is a Windows application whitelisting control that is host-based and helps determine which applications can perform certain operations on the host) and personal firewalls.

These types of infections can be also referred to as “Living Off the Land Binary” attacks (or simply LOLBins). This is because the attacker leverages existing application binaries to conduct their malicious intentions and run malicious code via these applications. Compromising .NET binaries is just one way out of many to launch such an attack.

Some Use Cases

Use Case #1

Here is an example of an infection that was recently detected by Cynet (Cynet360 – Threat Report – Imminent RAT abused by malware). In this instance, a malware dropper (compiled from C#), uses the C# command line compiler to generate a new executable. From the code, it extracts an obfuscated image holding encrypted code from its resources section (.rsrc). The technique of holding any type of code or message inside an image is called Steganography. After the encrypted code is extracted and decrypted from the image, it is compiled into a new executable that is then injected into the virtual memory address space of RegAsm.exe process.

Use Case #2

Another interesting Cynet use case is an infection that leverages the MSBuild.exe process.

mimikatz 221 detection and alert by cynet360

It does this by injecting malicious code to its memory to maintain Command and Control (C&C or C2) communications between a Remote Access Trojan and its remote operator (Cynet360 – Threat report – NanoCore RAT).

The Cost to Organizations

These types of attacks are very efficient at bypassing security controls to conduct malicious activities on a host. As opposed to the usual damage counts, successful attempts at av bypass such as these have a more insidious cost. Once the persistent code has reached the point of executing its malicious code in the context of a .NET legit binary, it can be remotely operated, exfiltrating data to a remote C&C server, stealing user credentials, fingerprinting the infected machine and downloading additional malware. This is only a method of delivering malware and running malicious code. Of course, there are many forms of malicious code and many different intentions behind them.

Are You at Risk?

Any Windows OS endpoint with .NET assemblies installed on it is in a point of potential infection. Organizations can minimize this risk by enacting appropriate security. Common methods of delivery include phishing campaigns, malvertising, malspam, and the delivery of additional malware by already existing infections.

The Methods Behind .NET Binary Abuse

Malware can use the C# command line compiler to compile and execute additional threats entirely from memory. Also, malicious code can be executed in the context of .NET binaries (RegAsm.exe) to evade application whitelisting and anti-malware protection. Once on the endpoint, host-based security controls are bypassed because no executable is written to disk and the malicious code lives inside a legitimate Windows file\process.

Mitigation or Response?

There are no preliminary actions that can mitigate this type of attack, but real-time monitoring will detect malicious use of .NET binary manipulation. Detecting memory patterns or heuristic memory detection are best practices against this type of attack vector. It is also important to calculate all the infection stages.

The compilation of malicious C# code or the manipulation of .NET binaries can be prevented from the beginning, if malicious commands originating from VB macros code are blocked at runtime (or if the csc.exe is invoked from a malware executable). In most cases, PowerShell will be invoked from a weaponized document to download additional malware from the internet and execute it from an allocated memory buffer without touching disk (“file-less”). If it is a dropper, shell commands will be used to invoke the C# command line compiler.

Detection

Monitoring runtime commands from all processes on the machine is best practice, since LOLbin attacks are very trendy among malware and attackers.