Detection evasion in CLR and tips on how to detect such attacks

[harlan4096]

SOC method for finding abnormal CLR activities and new techniques capable of running any code on a remote host

In terms of costs, the age-old battle that pits attacker versus defender has become very one sided in recent years. Almost all modern attacks (and ethical offensive exercises) use Mimikatz, SharpHound, SeatBelt, Rubeus, GhostPack and other toolsets available to the community. This so-called githubification is driving attackers’ costs down and reshaping the focus from malware development to the evasion of security mechanisms. What’s the point of creating a tool that can be detected by EPP solutions when you can gain more by simply reusing existing tools and learning how to perform attacks with them? It places the onus – and costs – on the defender who suddenly needs new expertise, tools and processes.

Fileless and malwareless attacks, heavy usage of the LOLBAS list, runtime encryption, downloaders, packers, as well as old, repurposed and completely new techniques to evade a variety of security tools and controls – all these are actively used by attackers. No one is surprised by Mimikatz being embedded in InstallUtil.exe. In our article we will describe an evasion technique that can be employed to hide offensive activities in the memory, namely, how to delete indicators from memory. We will then provide you with some tools and methods that may be useful for detecting this technique. We’ll review applications running in or using the CLR (Common Language Runtime) environment, such as PowerShell, numerous LOLBAS tools, and multiple C# utilities.
If you’re already familiar with CLR, you can go straight to Detection evasion in CLR.

CLR basics

When you compile a source code written in C# the compiler doesn’t give you a ready-to-run PE file, but an assembly. This is primarily a set of statements (CIL code) for the runtime environment to generate native code (which in its turn will be executed) during the execution of this assembly. The process of creating native code from the assembly at runtime is called JIT compilation.

The assembly resulting from the compilation of an application will contain the following data:

• Metainformation on classes, interfaces, types, methods and fields in the assembly. These data are needed for CLR to handle the written code: load it, reference it, run one code from another, and pass input and output data. The process of reading and applying this data is called reflection.
  
• The code itself, defined in modules. It just can’t be launched without being processed in CLR.
  
• Assembly Manifest containing data on security, versions, dependencies and the assembly elements. The manifest defines what is needed to execute code. For instance, if your code needs https://github.com/JamesNK/Newtonsoft.Json to be launched, it will be defined in the manifest.
  
• All types of files and data, which can be included in the assembly itself or stored as separate files.
  

Loading and execution of assemblies is a complicated process – let’s take a closer look at how it works.

Process startup

The ETW CLR Runtime Provider (GUID e13c0d23-ccbc-4e12-931b-d9cc2eee27e4) gives a good indication of a process startup with managed code.
...

Continue Reading