GULoader Campaigns: A Deep Dive Analysis of a highly evasive Shellcode based loader | McAfee Blog

Authored by: Anandeshwar Unnikrishnan

Stage 1: GULoader Shellcode Deployment 

In recent GULoader campaigns, we are seeing a rise in NSIS-based installers delivered via E-mail as malspam that use plugin libraries to execute the GU shellcode on the victim system. The NSIS scriptable installer is a highly efficient software packaging utility. The installer behavior is dictated by an NSIS script and users can extend the functionality of the packager by adding custom libraries (dll) known as NSIS plugins. Since its inception, adversaries have abused the utility to deliver malware. 

NSIS stands for Nullsoft Scriptable Installer. NSIS installer files are self-contained archives enabling malware authors to include malicious assets along with junk data. The junk data is used as Anti-AV / AV Evasion technique. The image below shows the structure of an NSIS GULoader staging executable archive.

 

The NSIS script, which is a file found in the archive, has a file extension “.nsi” as shown in the image above. The deployment strategy employed by the threat actor can be studied by analyzing the NSIS script commands provided in the script file. The image shown below is an oversimplified view of the whole shellcode staging process. 

The file that holds the encoded GULoader shellcode is dropped on to victim’s disc based on the script configuration along with other data. Junk is appended at the beginning of the encoded shellcode. The encoding style varies from sample to sample. But in all most all the cases, it’s a simple XOR encoding. As mentioned before, the shellcode is appended to junk data, because of this, an offset is used to retrieve encoded GULoader shellcode. In the image, the FileSeek NSIS command is used to do proper offsetting. Some samples have unprotected GULoader shellcode appended to junk data. 

 

A plugin used by the NSIS installer is nothing but a DLL which gets loaded by the installer program at runtime and invokes functions exported by the library.  Two DLL files are dropped in user’s TEMP directory, in all analyzed samples one DLL has a consistent name of system.dll and name of the other one varies.   

The system.dll is responsible for allocating memory for the shellcode and its execution. The following image shows how the NSIS script calls functions in plugin libraries.

 

The system.dll has the following exports as shown the in the image below. The function named “Call” is being used to deploy the shellcode on victim’s system. 

• The Call function exported by system.dll resolves following functions dynamically and execute them to deploy the shellcode. 
• CreateFile – To read the shellcode dumped on to disk by the installer. As part of installer set up, all the files seen in the installer archive earlier are dumped on to disk in new directory created in C: drive. 
• VirtualAlloc – To hold the shellcode in the RWX memory. 
• SetFilePointer – To seek the exact position of the shellcode in the dumped file. 
• ReadFile – To read the shellcode.  
• EnumResourceTypesA – Execution via callback mechanism. The second parameter is of the type ENUMRESTYPEPROCA which is simply a pointer to a callback routine. The address where the shellcode is allocated in the memory is passed as the second argument to this API leading to execution of the shellcode. Callback functions parameters are good resources for indirect execution of the code.   

Vectored Exception Handling in GULoader 

The implementation of the exception handling by the Operating System provides an opportunity for the adversary to take over execution flow. The Vectored Exception Handling on Windows provides the user with ability to register custom exception handler, which is simply a code logic that gets executed at the event of an exception. The interesting thing about handling exceptions is that the way in which the system resumes its normal execution flow of the program after the event of exception. Adversaries exploit this mechanism and take ownership of the execution flow. Malware can divert the flow to the code which is under its control when the exception occurs. Normally it is employed by the malware to achieve following goals: 

• Hooking 
• Covert code execution and anti-analysis 

The GuLoader employs the VEH mainly for obfuscating the execution flow and to slow down the analysis. This section will cover the internals of Vectored exception handling on Windows and investigates how GUloader is abusing the VEH mechanism to thwart any analysis efforts.  

• The Vectored Exception Handling (VEH) is an extension of Structured Exception Handling (SEH) with which we can add a vectored exception handler which will be called despite of our position in a call frame, simply put VEH is not frame-based. 
• VEH is abused by malware, either to manipulate the control flow or covertly execute user functions. 
• Windows provides AddVectoredExceptionHandler Win32 API to add custom exception handlers. The function signature is shown below. 

The Handler routine is of the type PVECTORED_EXCEPTION_HANDLER. Further checking the documentation, we can see the handler function takes a pointer to _EXCEPTION_POINTERS type as its input as shown in the image below. 

 

The _EXCEPTION_POINTERS type holds two important structures; PEXCEPTION_RECORD and PCONTEXT. PEXCEPTION_RECORD contains all the information related to exception raised by the system like exception code etc. and PCONTEXT structure holds CPU register (like RIP/EIP, debug registers etc.) values or state of the thread captured when exception occurred. 

 

• This means the exception handler can access both ExceptionRecord and ContextRecord. Here from within the handler one can tamper with the data stored in the ContextRecord, thus manipulating EIP/RIP to control the execution flow when user application resumes from exception handling.    
• There is one interesting thing about exception handling, the execution to the application is given back via NtContinue native routine. Exception dispatch routines call the handler and when handler returns to dispatcher, it passes the ContextRecord to the NtContinue and execution is resumed from the EIP/RIP in the record. On a side note, this is an oversimplified explanation of the whole exception handling process. 

Vectored Handler in GULoader 

• GULoader registers a vectored exception handler via RtlAddVectoredExceptionHandler native routine.  The below image shows the control flow of the handler code. Interestingly most of the code blocks present here are junk added to thwart the analysis efforts.  

 

• The GULoader’s handler implementation is as follows (disregarding the junk code). 
• Reads ExceptionInfo passed to the handler by the system. 
• Reads the ExceptionCode from ExceptionRecord structure. 
• Checks the value of ExceptionCode field against the computed exception codes for STATUS_ACCESS_VIOLATION, STATUS_BREAKPOINT and STATUS_SINGLESTEP. 
• Based on the exception code, malware takes a branch and executes code that modifies the EIP. 

 

 

The GULoader sets the trap flag to trigger single stepping intentionally to detect analysis. The handler code gets executed as discussed before, a block of code is executed based on the exception code. If the exception is single stepping, status code is 0x80000004, following actions take place:

• The GULoader reads the ContextRecord and retrieves EIP value of the thread. 
•  Increments the current EIP by 2 and reads the one byte from there. 
• Performs an XOR on the one-byte data fetched from step before and a static value. The static value changes with samples. In our sample value is 0x1A. 
• The XOR’ed value is then added to the EIP fetched from the ContextRecord. 
• Finally, the modified EIP value from prior step is saved in the ContextRecord and returns the control back to the system(dispatcher). 
• The malware has the same logic for the access violation exception. 

 

• When the shellcode is executed without debugger, INT3 instruction invokes the vectored exception handler routine, with an exception of EXCEPTION_BREAKPOINT, handler computes EIP by incrementing the EIP by 1 and fetching the data from incremented location. Later XORing the fetched data with a constant in our case 0x1A. The result is added to current EIP value. The logic implemented for handling INT3 exceptions also scan the program code for 0xCC instructions put by the researchers. If 0xCC are found that are placed by researchers then EIP is not calculated properly. 

 

EIP Calculation Logic Summary 

Trigger via interrupt instruction (INT3)	eip=((ReadByte(eip+1)^0x1A)+eip)
Trigger via Single Stepping(PUSHFD/POPFD)	eip=((ReadByte(eip+2)^0x1A)+eip)

*The value 0x1A changes with samples 

Detecting Abnormal Execution Flow via VEH 

• The shellcode is structured in such a way that the malware can detect abnormal execution flow by the order in which exception occurred at runtime. The pushfd/popfd instructions are followed by the code that when executed throws STATUS_ACCESS_VIOLATION. When program is executed normally, the execution will not reach the code that follows the pushfd/popfd instruction block, thus raising only STATUS_SINGLESTEP. When accidently stepped over the pushfd/popfd block in debugger, the STATUS_SINGLESTEP is not thrown at the debugger as it suppreses this because the debugger is already single stepping through the code, this is detected by the handler logic when we encounter code that follows the pushfd/popfd instruction block wich throws a STATUS_ACCESS_VIOLATION. Now it runs into a nested exception situation (the access violation followed by suppressed single stepping exception via trap). Because of this, whenever an access violation occurs, the handler routine checks for nested exception information in _EXCEPTION_POINTERS structure as discussed in the beginning. 

Below image shows this the carefully laid out code to detect analysis. 

 

The Egg hunting: VEH Assisted Runtime Padding 

One interesting feature seen in GULoader shellcode in the wild is runtime padding. Runtime padding is an evasive behavior to beat automated scanners and other security checks employed at runtime. It delays the malicious activities performed by the malware on the target system.  

• The egg value in the analyzed sample is 0xAE74B61.  
• It initiates a search for this value in its own data segment of the shellcode. 
• Don’t forget the fact that this is implemented via VEH handler. This search itself adds 0.3 million of VEH iteration on top of regular VEH control manipulation employed in the code. 
• The loader ends this search when it retrieves the address location of the egg value. To make sure the value is not being manipulated by any means by the researcher, it performs two additional checks to validate the egg location. 
• If the check fails, the search continues. The process of retrieving the location of the egg is shown in the image below.  

• As mentioned above, the validity of the egg location is checked by retrieving byte values from two offsets: one is 4 bytes away from the egg location and the value is 0xB8. The other is at 9 bytes from the egg location and the value is 0xC3. This check needs to be passed for the loader to proceed to the next stage of infection. Core malware activities are performed after this runtime padding loop. 

 The following images show the egg location validity checks performed by GULoader. The values 0xB8 and 0xC3 are checked by using proper offsets from the egg location. 

 

Stage 2: Environment Check and Code Injection  

In the second stage of the infection chain, the GULoader performs anti-analysis and code injection. Major anti-analysis vectors are listed below. After making sure that shellcode is not running in a sandbox, it proceeds to conduct code injection into a newly spawned process where stage 3 is initiated to download and deploy actual payload. This payload can be either commodity stealer or RAT.  

Anti-analysis Techniques  

• Employs runtime padding as discussed before. 
• Scans whole process memory for analysis tool specific strings 
• Uses DJB2 hashing for string checks and dynamic API address resolution. 
• Strings are decoded at runtime 
• Checks if qemu is installed on the system by checking the installation path: 
• C:\Program Files\qqa\qqa.exe 
• Patches the following APIs: 
• DbgUIRemoteBreakIn 
• The function’s prologue is patched with ExitProcess call 
• LdrLoadDll 
• The initial bytes are patched with instruction “mov edi edi” 
• DbgBreakPoint 
• Patches with instruction nop 
• Clears hooks placed in ntdll.dll by security products or researcher for the analysis. 
• Window Enumeration via EnumWindows 
• Hides the shellcode thread from the debugger via ZwSetInformationThread by passing 0x11 (ThreadHideFromDebugger) 
• Device driver enumeration via EnumDeviceDrivers andGetDeviceDriverBaseNameA 
• Installed software enumeration via MsiEnumProductsA and MsiGetProductInfoA 
• System service enumeration via OpenSCManagerA and EnumServiceStatusA 
• Checks use of debugging ports by passing ProcessDebugPort (0x7) class to NtQueryInformationProcess 
• Use of CPUID and RDTSC instructions to detect virtual environments and instrumentation. 

Anti-dump Protection 

Whenever GULoader invokes a Win32 api, the call is sandwiched between two XOR loops as shown in the image below.  The loop prior to the call encoded the active shellcode region where the call is taking place to prevent the memory from getting dumped by the security products based on event monitoring or api calls. Following the call, the shellcode region is decoded again back to normal and resumes execution. The XOR key used is a word present in the shellcode itself. 

 

String Decoding  

This section covers the process undertaken by the GUloader to decode the strings at the runtime. 

• The NtAllocateVirtualMemory is called to allocate a buffer to hold the encoded bytes. 
• The encoded bytes are computed by performing various arithmetic and logical operations on static values embedded as operands of assembly instructions. Below image shows the recovery of encoded bytes via various mathematical and logical operations. The EAX points to memory buffer, where computed encoded values get stored. 

 

The first byte/word is reserved to hold the size of the encoded bytes. Below shows a 12 byte long encoded data being written to memory. 

Later, the first word gets replaced by the first word of the actual encoded data. Below image shows the buffer after replacing the first word. 

The encoded data is fully recovered now, and malware proceeds to decode it. For decoding the simple XOR is employed, and key is present in the shellcode. The assembly routine that does the decoding is shown in the image below. Each byte in the buffer is XORed with the key. 

 

The result of the XOR operation is written to same memory buffer that holds the encoded data. A final view of the memory buffer with decoded data is shown below. 

The image shows the decoding the string “psapi.dll”, later this string is used in fetching the addresses of various functions to employ anti-analysis.  

 

The stage 2 culminates in code injection, to be specific GULoader employs a variation of the process hollowing technique, where a benign process is spawned in a suspended state by the malware stager process and proceeds to overwrite the original content present in the suspended process with malicious content, later the state of the thread in the suspended process is changed by modifying processor register values like EIP and finally the process resumes its execution. By controlling EIP, malware can now direct the control flow in the spawned process to a desired code location. After a successful hollowing, the malware code will be running under the cover of a legit application.  

The variation of hollowing technique employed by the GULoader doesn’t replace the file contents, but instead injects the same shellcode and maps the memory in the suspended process. Interestingly, GULoader employs an additional technique if the hollowing attempt fails. More details are covered in the following section.  

Listed below Win32 native APIs are dynamically resolved at runtime to perform the code injection. 

• NtCreateSection 
• ZwMapViewOfSection 
• NtWriteVirtualMemory 
• ZwGetContetThread 
• NtSetContextThread 
• NtResumeThread   

Overview of Code Injection 

• Initially image “%windir%Microsoft.NETFrameworkversion on 32-bit systems<version>CasPol.exe” is spawned in suspended mode via CreateProcessInternalW native API. 
• The Gu loader retrieves a handle to the file “C:WindowsSysWOW64iertutil.dll” which is used in section creation. The section object created via NtCreateSection will be backed by iertutil.dll.  
• This behavior is mainly to avoid suspicion, a section object which is not backed by any file may draw unwanted attention from security systems.  
• The next phase in the code injection is the mapping of the view created on the section backed by the iertutil.dll into the spawned CasPol.exe process. Once the view is successfully mapped to the process, malware can inject the shellcode in the mapped memory and resume the process thus initiating stage 3. The native api ZwMapViewOfSection is used to perform this task. Following the execution of the above API, the malware checks the result of the function call against the below listed error statuses. 
• C0000018 (STATUS_CONFLICTING_ADDRESS) 
• C0000220 (STATUS_MAPPED_ALIGNMENT) 
• 40000003 (STATUS_IMAGE_NOT_AT_BASE). 
• If the mapping is unsuccessful and status code returned by ZwMapViewOfSection matches with any of the code mentioned above, it has a backup plan. 
• The GuLoader calls NtAllocateVirtualMemory by directly calling the system call stub which is normally found in ntdll.dll library to bypass EDR/AV hooks. The memory is allocated in the remote CasPol.exe process with an RWX memory protection. Following image shows the direct use of NtAllocateVirtualMemory system call. 

After memory allocation, it writes itself into remote process via NtWriteVirtualMemory as discussed above. GULoader shellcodes taken from the field are bigger in size,  samples taken for this analysis are all greater than 20 mb. In samples analyzed, the buffer size allocated to hold the shellcode is 2950000 bytes. The below image shows the GuLoader shellcode in the memory. 

 

Misleading Entry point  

• The GULoader is highly evasive in nature, if abnormal execution flow is detected with help of employed anti-analysis vectors, the EIP and EBX fields of thread context structure (of CasPol.exe process) will be overwritten with a decoy address, which is required for the stage 3 of malware execution. The location ebp+4 is used to hold the entry point despite of the fact whether program is being debugged or not. 
• The Gu loader uses ZwGetContextThread and NtSetContextThread routines to accomplish modification of the thread state. The CONTEXT structure is retrieved via ZwGetContextThread, the value [ebp+14C] is used as the entry point address. The current EIP value held in the EIP field in the context structure of the thread will be changed to a recalculated address based on value at ebp+4. Below image shows the RVA calculation.  The base address of the executing shellcode (stage 2) is subtracted from the virtual address [ebp+4] to obtain RVA.  

 

The RVA is added to the base address of the newly allocated memory in the CasPol.exe process to obtain new VA which can be used in the remote process. The new VA is written into EIP and EBX field in the thread context structure of the CasPol.exe process retrieved via ZwGetContextThread. Below image shows the modified context structure and value of EIP.  

 

Finally, by calling ZwSetContextThread, the changes made to the CONTEXT structure is committed in the target thread of CasPol.exe process. The thread is resumed by calling NtResumeThread. The CasPol.exe resumes execution and performs stage 3 of the infection chain. 

Stage 3: Payload Deployment  

The GULoader shellcode resumes execution from within a new host process, in this report, analyzed samples inject the shellcode either into the same process spawned as a child process or caspol.exe. Stage3 performs all the anti-analysis once again to make sure this stage is not being analyzed. After all checks, GUloader proceeds to perform stage3 activities by decoding the encoded C2 string in the memory as shown in the image below. The decoding method is the same as discussed before. 

Later the addresses of following functions are resolved dynamically by loading wininet.dll: 

• InternetSetOptionA 
• InternetOpenUrlA 
• InternetReadFile 
• InternetCloseHandle. 

The below image shows the response from the content delivery network (cdn) server where the final payload is stored. In this analysis, a payload of size 0x2E640 bytes is sent to the loader. Interestingly, the first 40 bytes are ignored by the loader. The actual payload starts from the offset 40 which is highlighted in the image. 

 

The cdn server is well protected, it only serves to clients with proper headers and cookies. If these are not present in the HTTP request, the following message is shown to the user. 

Final Payload 

Quasi Key Generation 

The first step in decoding the the downloaded final payload by the GUloader is generating a quasi key which will be later used in decoding the actual key embeded in the GULoader shellcode. The encoded embeded key size is 371 bytes in analysed sample. The process of quasi key generation is as follows: 

• The 40th and 41st bytes (word) are retrived from the download buffer in the memory. 
• The above word is XORed with the first word of the encoded embeded key along and a counter value. 
• The process is repeated untill the the word taken from the downloaded data fully decodes and have a value of 0x4D5A “MZ”. 
• The value present in the counter when the 4D5A gets decoded is taken as the quasi key. This key is shown as “key-1” in the image below. In the analysed sample the value of this key is “0x5448” 

Decoding Actual Key 

The embedded key in the GULoader shellcode is of the size 371 bytes as discussed before. The quasi key is used to decode the embeded key as shown in the image below. 

• Each word in the embeded key is XORed with quasi key key-1. 
• When the interation counter exceeds the size value of 371 bytes, it stops and proceeds to decode the downloaded payload with this new key. 

The decoded 371 bytes of embeded key is shown below in the image below. 

Decoding File 

A byte level decoding happens after embeded key is decoded in the memory. Each byte of the downloaded data is XORed with the key to obtain the actual data, which is a PE file. The decoded data is overwritten to the same buffer used to download the decoded data. 

The final decoded PE file residing in the memory is shown in the image below: 

Finally, the loader loads the PE file by allocating the memory with RWX permission in the stage3 process, based on analyzing multiple samples it’s either the same process in stage 2 as the child process, or casPol.exe. The loading involved code relocation and IAT correction as expected in such a scenario. The final payload resumes execution from within the hollowed stage3 process. Below malware families are usually seen deployed by the GULoader: 

• Vidar (Stealer) 
• Raccoon (Stealer) 
• Remcos RAT 

Below image shows the injected memory regions in stage3 process caspol.exe in this report. 

Conclusion  

The role played by malware loaders popularly known as “crypters” is significant in the deployment of Remote Administration Tools and stealer malwares that target consumer data. The exfiltrated Personal Identifiable Information (PII) extracted from the compromised endpoints are largely collected and funneled to various underground data selling marketplaces. This also impacts businesses as various critical information used for authentication purposes are getting leaked from the personal systems of the user leading to initial access on the company networks. The GuLoader is heavily used in mass malware campaigns to infect the users with popular stealer malware like Raccoon, Vidar, and Redline. Commodity RATs like Remcos are also seen delivered in such campaign activities. On the bright side, it is not difficult to fingerprint malware specimens used in the mass campaigns because of the volume its volume and relevance, detection rules and systems can be built around this very fact. 

 

Following table summarizes all the dynamically resolved Win32 APIs  

Win32 API

RtlAddVectoredExceptionHandler

NtAllocateVirtualMemory

DbgUIRemoteBreakIn

LdrLoadDll

DbgBreakPoint

EnumWindows

Nt/ZwSetInformationThread

EnumDeviceDrivers

GetDeviceDriverBaseNameA

MsiEnumProductsA

MsiGetProductInfoA

TerminateProcess

ExitProcess

NtSetContextThread

NtWriteVirtualMemory

NtCreateSection

NtMapViewOfSection

NtOpenFile

NtSetInformationProcess

NtClose

NtResumeThread

NtProtectVirtualMemory

CreateProcessInternal

GetLongPathNameW

Sleep

NtCreateThreadEx

WaitForSingleObject

TerminateThread

CreateFileW

WriteFile

CloseHandle

GetFileSize

ReadFile

ShellExecuteW

SHCreateDirectoryExW

RegCreateKeyExA

RegSetValueExA

OpenSCManagerA

EnumServiceStatusA

CloseServiceHandle

NtQueryInformationProcess

InternetOpenA

InternetSetOptionA

InternetOpenUrlA

InternetReadFile

InternetCloseHandle

 

IOC 

889fddcb57ed66c63b0b16f2be2dbd7ec0252031cad3b15dfea5411ac245ef56 

59b71cb2c5a14186a5069d7935ebe28486f49b7961bddac0a818a021373a44a3 

4d9cdd7526f05343fda35aca3e0e6939abed8a037a0a871ce9ccd0e69a3741f2 

c8006013fc6a90d635f394c91637eae12706f58897a6489d40e663f46996c664 

c69e558e5526feeb00ab90efe764fb0b93b3a09692659d1a57c652da81f1d123 

45156ac4b40b7537f4e003d9f925746b848a939b2362753f6edbcc794ea8b36a 

e68ce815ac0211303d2c38ccbb5ccead144909d295230df4b7a419dfdea12782 

b24b36641fef3acbf3b643967d408b10bf8abfe1fe1f99d704a9a19f1dfc77e8 

569aa6697083993d9c387426b827414a7ed225a3dd2e1e3eba1b49667573fdcb 

60de2308ebfeadadc3e401300172013be27af5b7d816c49696bb3dedc208c54e 

23458977440cccb8ac7d0d05c238d087d90f5bf1c42157fb3a161d41b741c39d