{"id":168594,"date":"2023-05-09T10:50:12","date_gmt":"2023-05-09T17:50:12","guid":{"rendered":"https:\/\/www.mcafee.com\/blogs\/?p=168594"},"modified":"2023-07-11T11:07:02","modified_gmt":"2023-07-11T18:07:02","slug":"guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader","status":"publish","type":"post","link":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/","title":{"rendered":"GULoader Campaigns: A Deep Dive Analysis of a highly evasive Shellcode based loader"},"content":{"rendered":"

Authored by: Anandeshwar<\/span> Unnikrishnan<\/span><\/p>\n

Stage <\/span>1:<\/span> GULoader<\/span> Shellcode Deployment<\/span><\/span>\u00a0<\/span><\/h2>\n

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.<\/span>\u00a0<\/span><\/p>\n

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.<\/span><\/p>\n

\"\"<\/span><\/p>\n

 <\/p>\n

The NSIS script<\/span>,<\/span> which is a file found in the archive<\/span>, <\/span>has a file extension <\/span>\u201c<\/span>.<\/span>nsi<\/span>\u201d<\/span> as shown in the image above. The deployment <\/span>strategy employed by the threat actor can be <\/span>studied by analyzing the NSIS script commands provided in the script file.<\/span> The image shown below is an oversimplified view of the whole shellcode staging process<\/span>.<\/span><\/span>\u00a0<\/span><\/span><\/p>\n

\"\"<\/span><\/p>\n

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

\"\"<\/span><\/p>\n

 <\/p>\n

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

The system.dll <\/span>is responsible for<\/span> allocating<\/span> memory for the shellcode and <\/span>its execution.<\/span> The following <\/span>image shows <\/span>how the <\/span>NSIS <\/span>script calls functions in plugin <\/span>libraries.<\/span><\/span><\/p>\n

\"\"<\/span><\/p>\n

 <\/p>\n

The system.dll has<\/span> the<\/span> following exports as shown <\/span>the in<\/span> the image below. The <\/span>function named <\/span>\u201cCall\u201d <\/span>is being used to deploy the shellcode on victim\u2019s system<\/span>.<\/span><\/span>\u00a0<\/span><\/span><\/p>\n

\"\"<\/span><\/p>\n

    \n
  • The Call function exported by system.dll resolves following functions dynamically and execute them to deploy the shellcode.<\/span>\u00a0<\/span><\/li>\n
  • CreateFile \u2013 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.<\/span>\u00a0<\/span><\/li>\n
  • VirtualAlloc \u2013 To hold the shellcode in the RWX memory.<\/span>\u00a0<\/span><\/li>\n
  • SetFilePointer \u2013 To seek the exact position of the shellcode in the dumped file.<\/span>\u00a0<\/span><\/li>\n
  • ReadFile \u2013 To read the shellcode.\u00a0<\/span>\u00a0<\/span><\/li>\n
  • EnumResourceTypesA \u2013 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.\u00a0\u00a0<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

    Vectored Exception Handling in <\/span>GULoader<\/span><\/span>\u00a0<\/span><\/strong><\/h2>\n

    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:<\/span>\u00a0<\/span><\/p>\n

      \n
    • Hooking<\/span>\u00a0<\/span><\/li>\n
    • Covert code execution and anti-analysis<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

      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.\u00a0<\/span>\u00a0<\/span><\/p>\n

        \n
      • 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.<\/span>\u00a0<\/span><\/li>\n
      • VEH is abused by malware, either to manipulate the control flow or covertly execute user functions.<\/span>\u00a0<\/span><\/li>\n
      • Windows provides AddVectoredExceptionHandler Win32 API to add custom exception handlers. The function signature is shown below.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

        \"\"<\/p>\n

        The Handler routine <\/span>is<\/span> of the<\/span> type PVECTORED_EXCEPTION_HANDLER. <\/span>Further checking the <\/span>documentation,<\/span> we can see the handler function takes <\/span>a pointer to _E<\/span>XCEPTION<\/span>_POINTERS type<\/span> as its input<\/span> as shown in the image below.<\/span><\/span>\u00a0<\/span><\/p>\n

        \"\"<\/p>\n

         <\/p>\n

        The <\/span>_<\/span>EXCEPTION<\/span>_POINTERS type holds two important <\/span>structures<\/span><\/span>;<\/span><\/span><\/span> PEXCEPTION_RECORD and PCONTEXT<\/span>. PEXCEPTION_RECORD <\/span>contains<\/span> all the information related t<\/span>o <\/span>exception<\/span> raised by the system like exception code <\/span>etc.<\/span> and <\/span>PCONTEXT structure hold<\/span>s<\/span> CPU register<\/span> (like RIP\/EIP<\/span>, debug registers <\/span>etc.<\/span>)<\/span> values or state of the thread <\/span>captured when exception occurred.<\/span><\/span>\u00a0<\/span><\/p>\n

        \"\"<\/p>\n

         <\/p>\n

          \n
        • 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.\u00a0<\/span>\u00a0 \u00a0<\/span><\/li>\n
        • 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.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

          Vectored Handler in GULoader<\/span>\u00a0<\/span><\/p>\n

            \n
          • GULoader registers a vectored exception handler via RtlAddVectoredExceptionHandler native routine.\u00a0 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.\u00a0<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

            \"\"<\/p>\n

             <\/p>\n

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

              \"\"\u00a0<\/span><\/p>\n

               <\/p>\n

              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:<\/span><\/p>\n

                \n
              • The GULoader reads the ContextRecord and retrieves EIP value of the thread.<\/span>\u00a0<\/span><\/li>\n
              • \u00a0Increments the current EIP by 2 and reads the one byte from there.<\/span>\u00a0<\/span><\/li>\n
              • 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.<\/span>\u00a0<\/span><\/li>\n
              • The XOR\u2019ed value is then added to the EIP fetched from the ContextRecord.<\/span>\u00a0<\/span><\/li>\n
              • Finally, the modified EIP value from prior step is saved in the ContextRecord and returns the control back to the system(dispatcher).<\/span>\u00a0<\/span><\/li>\n
              • The malware has the same logic for the access violation exception.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

                \"\"<\/p>\n

                \u00a0<\/span><\/p>\n

                  \n
                • 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.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

                  \"\"<\/p>\n

                   <\/p>\n

                  EIP Calculation Logic Summary<\/span>\u00a0<\/span><\/p>\n\n\n\n\n
                  Trigger via interrupt instruction (INT3)<\/span>\u00a0<\/span><\/td>\neip=((ReadByte(eip+1)^0x1A)+eip)<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                  Trigger via Single Stepping(PUSHFD\/POPFD)<\/span>\u00a0<\/span><\/td>\neip=((ReadByte(eip+2)^0x1A)+eip)<\/span>\u00a0<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

                  *The value 0x1A changes with samples<\/span>\u00a0<\/span><\/p>\n

                  Detecting Abnormal Execution Flow via VEH<\/span>\u00a0<\/span><\/p>\n

                    \n
                  • 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.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

                    Below image shows this the carefully laid out code to detect analysis.<\/span>\u00a0<\/span><\/p>\n

                    \"\"<\/p>\n

                     <\/p>\n

                    The Egg hunting: VEH Assisted Runtime Padding<\/span>\u00a0<\/span><\/h2>\n

                    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.\u00a0<\/span>\u00a0<\/span><\/p>\n

                      \n
                    • The egg value in the analyzed sample is 0xAE74B61.\u00a0<\/span>\u00a0<\/span><\/li>\n
                    • It initiates a search for this value in its own data segment of the shellcode.<\/span>\u00a0<\/span><\/li>\n
                    • Don\u2019t 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.<\/span>\u00a0<\/span><\/li>\n
                    • 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.<\/span>\u00a0<\/span><\/li>\n
                    • If the check fails, the search continues. The process of retrieving the location of the egg is shown in the image below.\u00a0<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

                      \"\"<\/p>\n

                        \n
                      • 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.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

                        \u00a0<\/span>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.<\/span>\u00a0<\/span><\/p>\n

                         <\/p>\n

                        \"\"<\/p>\n

                        \"\"<\/p>\n

                        Stage 2: Environment Check and Code Injection\u00a0<\/span>\u00a0<\/span><\/h2>\n

                        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.\u00a0<\/span>\u00a0<\/span><\/p>\n

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

                          Anti-dump Protection<\/span>\u00a0<\/span><\/h3>\n

                          Whenever GULoader invokes a Win32 api, the call is sandwiched between two XOR loops as shown in the image below.\u00a0 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.<\/span>\u00a0<\/span><\/p>\n

                          \"\"<\/p>\n

                           <\/p>\n

                          String Decoding\u00a0<\/span><\/b>\u00a0<\/span><\/h3>\n

                          This section covers the process undertaken by the GUloader to decode the strings at the runtime.<\/span>\u00a0<\/span><\/p>\n

                            \n
                          • The NtAllocateVirtualMemory is called to allocate a buffer to hold the encoded bytes.<\/span>\u00a0<\/span><\/li>\n
                          • 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.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

                            \"\"<\/p>\n

                             <\/p>\n

                            The first byte\/word is reserved to hold the size of the <\/span>encoded bytes. Below shows a 12 byte long encoded data being <\/span>written to memory.<\/span><\/span>\u00a0<\/span><\/p>\n

                            \"\"<\/p>\n

                            Later, the first <\/span>word<\/span> gets replaced by the first <\/span>word<\/span> of the actual encoded data<\/span>.<\/span> Below image shows the buffer after replacing the first word.<\/span><\/span>\u00a0<\/span><\/p>\n

                            \"\"<\/p>\n

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

                            \"\"<\/p>\n

                             <\/p>\n

                            The result of the XOR operation is written to same memory buffer that holds the encoded data. <\/span>A final<\/span> view of the memory buffer with decoded data is shown below.<\/span><\/span>\u00a0<\/span><\/p>\n

                            \"\"<\/p>\n

                            The image shows the <\/span>decoding<\/span> the string \u201cpsapi.dll<\/span>\u201d,<\/span> later this <\/span>string<\/span> is used in fetching the address<\/span>es<\/span> of <\/span>various functions <\/span>to employ <\/span>anti-<\/span>analysis<\/span>.<\/span>\u00a0<\/span><\/span>\u00a0<\/span><\/p>\n

                             <\/p>\n

                            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.\u00a0<\/span>\u00a0<\/span><\/p>\n

                            The variation of hollowing technique employed by the GULoader doesn\u2019t replace the file contents, but instead injects the same shellcode and maps the memory in the suspended process. Interestingly<\/span>,<\/span> GULoader employs an additional technique if the hollowing attempt fails. More details are covered in the following section.\u00a0<\/span>\u00a0<\/span><\/p>\n

                            Listed below Win32 native APIs are dynamically resolved at runtime to perform the code injection.<\/span>\u00a0<\/span><\/p>\n

                              \n
                            • NtCreateSection<\/span>\u00a0<\/span><\/li>\n
                            • ZwMapViewOfSection<\/span>\u00a0<\/span><\/li>\n
                            • NtWriteVirtualMemory<\/span>\u00a0<\/span><\/li>\n
                            • ZwGetContetThread<\/span>\u00a0<\/span><\/li>\n
                            • NtSetContextThread<\/span>\u00a0<\/span><\/li>\n
                            • NtResumeThread<\/span> \u00a0\u00a0<\/span><\/li>\n<\/ul>\n

                              Overview of Code Injection<\/span>\u00a0<\/span><\/h3>\n
                                \n
                              • Initially image \u201c%windir%\\Microsoft.NET\\Framework\\version on 32-bit systems\\<version>\\CasPol.exe\u201d is spawned in suspended mode via CreateProcessInternalW native API.<\/span>\u00a0<\/span><\/li>\n
                              • The Gu loader retrieves a handle to the file <\/span>\u201cC:\\Windows\\SysWOW64\\iertutil.dll\u201d<\/span><\/i> which is used in section creation. The section object created via <\/span>NtCreateSection<\/span><\/i> will be backed by iertutil.dll.\u00a0<\/span>\u00a0<\/span><\/li>\n
                              • This behavior is mainly to avoid suspicion, a section object which is not backed by any file may draw unwanted attention from security systems.\u00a0<\/span>\u00a0<\/span><\/li>\n
                              • 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.<\/span>\u00a0<\/span><\/li>\n
                              • C0000018 (STATUS_CONFLICTING_ADDRESS)<\/span>\u00a0<\/span><\/li>\n
                              • C0000220 (STATUS_MAPPED_ALIGNMENT)<\/span>\u00a0<\/span><\/li>\n
                              • 40000003 (STATUS_IMAGE_NOT_AT_BASE).<\/span>\u00a0<\/span><\/li>\n
                              • If the mapping is unsuccessful and status code returned by ZwMapViewOfSection matches with any of the code mentioned above, it has a backup plan.<\/span>\u00a0<\/span><\/li>\n
                              • 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.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

                                \"\"<\/p>\n

                                After <\/span>memory allocation<\/span>, <\/span>it <\/span>writes itself<\/span> into remote process <\/span>via <\/span>NtWriteVirtualMemory<\/span> as discussed above<\/span>.<\/span> GULoader<\/span> shellcode<\/span>s<\/span> taken from the <\/span>field <\/span>are bigger in <\/span>size<\/span>,<\/span>\u00a0<\/span> samples<\/span> taken for this analysis are all greater than 20 mb<\/span>. In <\/span>samples analyzed<\/span>, the <\/span>buffer size <\/span>allocated<\/span> to hold the shellcode is 2<\/span>950000 bytes.<\/span> The below image shows the <\/span>GuLoader<\/span> shellcode in the memory<\/span>.<\/span><\/span>\u00a0<\/span><\/p>\n

                                \"\"<\/p>\n

                                 <\/p>\n

                                Misleading Entry point<\/span> \u00a0<\/span><\/h3>\n
                                  \n
                                • 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.<\/span>\u00a0<\/span><\/li>\n
                                • 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.\u00a0 The base address of the executing shellcode (stage 2) is subtracted from the virtual address [ebp+4] to obtain RVA.\u00a0<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

                                  \"\"<\/p>\n

                                   <\/p>\n

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

                                   <\/p>\n

                                  \"\"<\/p>\n

                                  Finally,<\/span> by calling <\/span>ZwSetContextThread<\/span>, the <\/span>change<\/span>s<\/span> made to the CONTEXT structure <\/span>is<\/span> committed <\/span>in the target thread of CasPol<\/span>.exe process.<\/span> The thread is resumed by calling <\/span>NtResumeThread<\/span>.<\/span> The CasPol.exe resumes executi<\/span>on <\/span>and <\/span>performs stage <\/span>3<\/span> of the infection chain.<\/span><\/span>\u00a0<\/span><\/p>\n

                                  Stage 3: Payload Deployment\u00a0<\/span><\/b>\u00a0<\/span><\/h2>\n

                                  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.<\/span>\u00a0<\/span><\/p>\n

                                  \"\"<\/p>\n

                                  Later the addresses of following functions are resolved dynamically by loading wininet.dll:<\/span>\u00a0<\/span><\/p>\n

                                    \n
                                  • InternetOpenA<\/span>\u00a0<\/span><\/li>\n<\/ul>\n
                                      \n
                                    • InternetSetOptionA<\/span>\u00a0<\/span><\/li>\n
                                    • InternetOpenUrlA<\/span>\u00a0<\/span><\/li>\n
                                    • InternetReadFile<\/span>\u00a0<\/span><\/li>\n
                                    • InternetCloseHandle.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

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

                                      \"\"<\/p>\n

                                       <\/p>\n

                                      The <\/span>cdn<\/span> server is well protected, it only <\/span>serve<\/span>s to<\/span> clients with proper headers <\/span>and <\/span>cookies. If <\/span>these<\/span> are not present in the HTTP request, the following message is shown to the user.<\/span><\/span>\u00a0<\/span> <\/span><\/p>\n

                                      \"\"<\/p>\n

                                      Final Payload<\/span><\/b>\u00a0<\/span><\/h2>\n

                                      Quasi Key Generation<\/span>\u00a0<\/span><\/h3>\n

                                      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:<\/span>\u00a0<\/span><\/p>\n

                                        \n
                                      • The 40<\/span>th<\/span> and 41<\/span>st<\/span> bytes (word)<\/span> are retrived from the download buffer in the memory.<\/span>\u00a0<\/span><\/li>\n
                                      • The above word is XORed with the first word of the encoded embeded key along and a counter value.<\/span>\u00a0<\/span><\/li>\n
                                      • The process is repeated untill the the word taken from the downloaded data fully decodes and have a value of 0x4D5A \u201cMZ\u201d.<\/span>\u00a0<\/span><\/li>\n
                                      • The value present in the counter when the 4D5A gets decoded is taken as the quasi key. This key is shown as \u201ckey-1\u201d in the image below. In the analysed sample the value of this key is \u201c0x5448\u201d<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

                                        \"\"<\/p>\n

                                        Decoding Actual Key<\/span>\u00a0<\/span><\/h3>\n

                                        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.<\/span>\u00a0<\/span><\/p>\n

                                          \n
                                        • Each word in the embeded key is XORed with quasi key key-1.<\/span>\u00a0<\/span><\/li>\n
                                        • When the interation counter exceeds the size value of 371 bytes, it stops and proceeds to decode the downloaded payload with this new key.<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

                                          \"\"<\/p>\n

                                          The <\/span>decoded 371 bytes of <\/span>embeded<\/span> key is shown below in the image below.<\/span><\/span>\u00a0<\/span><\/p>\n

                                          \"\"<\/p>\n

                                          Decoding File<\/span>\u00a0<\/span><\/h3>\n

                                          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.<\/span>\u00a0<\/span><\/p>\n

                                          \"\"<\/p>\n

                                          The final decoded PE file <\/span>residing<\/span> in the memory is shown in the image below:<\/span><\/span>\u00a0<\/span><\/p>\n

                                          \"\"<\/span><\/p>\n

                                          Finally, the loader loads the PE file by allocating the memory with RWX permission in the stage3 process, based on analyzing multiple samples it<\/span>\u2019<\/span>s either the same process in stage 2 as the child process<\/span>,<\/span> 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:<\/span>\u00a0<\/span><\/p>\n

                                            \n
                                          • Vidar (Stealer)<\/span>\u00a0<\/span><\/li>\n
                                          • Raccoon (Stealer)<\/span>\u00a0<\/span><\/li>\n
                                          • Remcos RAT<\/span>\u00a0<\/span><\/li>\n<\/ul>\n

                                            Below image shows the injected memory regions in stage3 process caspol.exe in this report.<\/span>\u00a0<\/span><\/p>\n

                                            \"\"<\/p>\n

                                            Conclusion\u00a0<\/span>\u00a0<\/span><\/h2>\n

                                            The role played by malware loaders popularly known as \u201ccrypters\u201d 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<\/span>,<\/span> 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.<\/span>\u00a0<\/span><\/p>\n

                                            \u00a0<\/span><\/p>\n

                                            Following table summarizes all the dynamically resolved Win32 APIs\u00a0<\/span>\u00a0<\/span><\/h2>\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n\n
                                            Win32 API<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            RtlAddVectoredExceptionHandler<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            NtAllocateVirtualMemory<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            DbgUIRemoteBreakIn<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            LdrLoadDll<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            DbgBreakPoint<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            EnumWindows<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            Nt\/ZwSetInformationThread<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            EnumDeviceDrivers<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            GetDeviceDriverBaseNameA<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            MsiEnumProductsA<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            MsiGetProductInfoA<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            TerminateProcess<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            ExitProcess<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            NtSetContextThread<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            NtWriteVirtualMemory<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            NtCreateSection<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            NtMapViewOfSection<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            NtOpenFile<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            NtSetInformationProcess<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            NtClose<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            NtResumeThread<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            NtProtectVirtualMemory<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            CreateProcessInternal<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            GetLongPathNameW<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            Sleep<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            NtCreateThreadEx<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            WaitForSingleObject<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            TerminateThread<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            CreateFileW<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            WriteFile<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            CloseHandle<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            GetFileSize<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            ReadFile<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            ShellExecuteW<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            SHCreateDirectoryExW<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            RegCreateKeyExA<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            RegSetValueExA<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            OpenSCManagerA<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            EnumServiceStatusA<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            CloseServiceHandle<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            NtQueryInformationProcess<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            InternetOpenA<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            InternetSetOptionA<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            InternetOpenUrlA<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            InternetReadFile<\/span>\u00a0<\/span><\/td>\n<\/tr>\n
                                            InternetCloseHandle<\/span>\u00a0<\/span><\/td>\n<\/tr>\n<\/tbody>\n<\/table>\n

                                             <\/p>\n

                                            IOC<\/span>\u00a0<\/span><\/h2>\n

                                            889fddcb57ed66c63b0b16f2be2dbd7ec0252031cad3b15dfea5411ac245ef56<\/span>\u00a0<\/span><\/p>\n

                                            59b71cb2c5a14186a5069d7935ebe28486f49b7961bddac0a818a021373a44a3<\/span>\u00a0<\/span><\/p>\n

                                            4d9cdd7526f05343fda35aca3e0e6939abed8a037a0a871ce9ccd0e69a3741f2<\/span>\u00a0<\/span><\/p>\n

                                            c8006013fc6a90d635f394c91637eae12706f58897a6489d40e663f46996c664<\/span>\u00a0<\/span><\/p>\n

                                            c69e558e5526feeb00ab90efe764fb0b93b3a09692659d1a57c652da81f1d123<\/span>\u00a0<\/span><\/p>\n

                                            45156ac4b40b7537f4e003d9f925746b848a939b2362753f6edbcc794ea8b36a<\/span>\u00a0<\/span><\/p>\n

                                            e68ce815ac0211303d2c38ccbb5ccead144909d295230df4b7a419dfdea12782<\/span>\u00a0<\/span><\/p>\n

                                            b24b36641fef3acbf3b643967d408b10bf8abfe1fe1f99d704a9a19f1dfc77e8<\/span>\u00a0<\/span><\/p>\n

                                            569aa6697083993d9c387426b827414a7ed225a3dd2e1e3eba1b49667573fdcb<\/span>\u00a0<\/span><\/p>\n

                                            60de2308ebfeadadc3e401300172013be27af5b7d816c49696bb3dedc208c54e<\/span>\u00a0<\/span><\/p>\n

                                            23458977440cccb8ac7d0d05c238d087d90f5bf1c42157fb3a161d41b741c39d<\/span>\u00a0<\/span><\/p>\n","protected":false},"excerpt":{"rendered":"

                                            Authored by: Anandeshwar Unnikrishnan Stage 1: GULoader Shellcode Deployment\u00a0 In recent GULoader campaigns, we are seeing a rise in NSIS-based…<\/p>\n","protected":false},"author":695,"featured_media":169435,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[442],"tags":[],"coauthors":[4136],"class_list":["post-168594","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-mcafee-labs"],"acf":[],"yoast_head":"\nGULoader Campaigns: A Deep Dive Analysis of a highly evasive Shellcode based loader | McAfee Blog<\/title>\n<meta name=\"description\" content=\"Authored by: Anandeshwar Unnikrishnan Stage 1: GULoader Shellcode Deployment\u00a0 In recent GULoader campaigns, we are seeing a rise in NSIS-based installers\" \/>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<meta property=\"og:locale\" content=\"en_US\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"GULoader Campaigns: A Deep Dive Analysis of a highly evasive Shellcode based loader | McAfee Blog\" \/>\n<meta property=\"og:description\" content=\"Authored by: Anandeshwar Unnikrishnan Stage 1: GULoader Shellcode Deployment\u00a0 In recent GULoader campaigns, we are seeing a rise in NSIS-based installers\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/\" \/>\n<meta property=\"og:site_name\" content=\"McAfee Blog\" \/>\n<meta property=\"article:publisher\" content=\"https:\/\/www.facebook.com\/McAfee\/\" \/>\n<meta property=\"article:author\" content=\"https:\/\/www.facebook.com\/McAfee\/\" \/>\n<meta property=\"article:published_time\" content=\"2023-05-09T17:50:12+00:00\" \/>\n<meta property=\"article:modified_time\" content=\"2023-07-11T18:07:02+00:00\" \/>\n<meta property=\"og:image\" content=\"https:\/\/www.mcafee.com\/blogs\/wp-content\/uploads\/2023\/05\/300x200_Blog_GULoader.png\" \/>\n\t<meta property=\"og:image:width\" content=\"300\" \/>\n\t<meta property=\"og:image:height\" content=\"200\" \/>\n\t<meta property=\"og:image:type\" content=\"image\/png\" \/>\n<meta name=\"author\" content=\"McAfee Labs\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:creator\" content=\"@McAfee_Labs\" \/>\n<meta name=\"twitter:site\" content=\"@McAfee\" \/>\n<meta name=\"twitter:label1\" content=\"Written by\" \/>\n\t<meta name=\"twitter:data1\" content=\"McAfee Labs\" \/>\n\t<meta name=\"twitter:label2\" content=\"Est. reading time\" \/>\n\t<meta name=\"twitter:data2\" content=\"20 minutes\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\/\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/#article\",\"isPartOf\":{\"@id\":\"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/\"},\"author\":{\"name\":\"McAfee Labs\",\"@id\":\"https:\/\/www.mcafee.com\/blogs\/#\/schema\/person\/86f325fa6532a017d06d6b49a2f3b1ad\"},\"headline\":\"GULoader Campaigns: A Deep Dive Analysis of a highly evasive Shellcode based loader\",\"datePublished\":\"2023-05-09T17:50:12+00:00\",\"dateModified\":\"2023-07-11T18:07:02+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/\"},\"wordCount\":4099,\"publisher\":{\"@id\":\"https:\/\/www.mcafee.com\/blogs\/#organization\"},\"image\":{\"@id\":\"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.mcafee.com\/blogs\/wp-content\/uploads\/2023\/05\/300x200_Blog_GULoader.png\",\"articleSection\":[\"McAfee Labs\"],\"inLanguage\":\"en-US\"},{\"@type\":\"WebPage\",\"@id\":\"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/\",\"url\":\"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/\",\"name\":\"GULoader Campaigns: A Deep Dive Analysis of a highly evasive Shellcode based loader | McAfee Blog\",\"isPartOf\":{\"@id\":\"https:\/\/www.mcafee.com\/blogs\/#website\"},\"primaryImageOfPage\":{\"@id\":\"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/#primaryimage\"},\"image\":{\"@id\":\"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/#primaryimage\"},\"thumbnailUrl\":\"https:\/\/www.mcafee.com\/blogs\/wp-content\/uploads\/2023\/05\/300x200_Blog_GULoader.png\",\"datePublished\":\"2023-05-09T17:50:12+00:00\",\"dateModified\":\"2023-07-11T18:07:02+00:00\",\"description\":\"Authored by: Anandeshwar Unnikrishnan Stage 1: GULoader Shellcode Deployment\u00a0 In recent GULoader campaigns, we are seeing a rise in NSIS-based installers\",\"breadcrumb\":{\"@id\":\"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/#breadcrumb\"},\"inLanguage\":\"en-US\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/\"]}]},{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/#primaryimage\",\"url\":\"https:\/\/www.mcafee.com\/blogs\/wp-content\/uploads\/2023\/05\/300x200_Blog_GULoader.png\",\"contentUrl\":\"https:\/\/www.mcafee.com\/blogs\/wp-content\/uploads\/2023\/05\/300x200_Blog_GULoader.png\",\"width\":300,\"height\":200},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"Blog\",\"item\":\"https:\/\/www.mcafee.com\/blogs\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"Other Blogs\",\"item\":\"https:\/\/www.mcafee.com\/blogs\/other-blogs\/\"},{\"@type\":\"ListItem\",\"position\":3,\"name\":\"McAfee Labs\",\"item\":\"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/\"},{\"@type\":\"ListItem\",\"position\":4,\"name\":\"GULoader Campaigns: A Deep Dive Analysis of a highly evasive Shellcode based loader\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\/\/www.mcafee.com\/blogs\/#website\",\"url\":\"https:\/\/www.mcafee.com\/blogs\/\",\"name\":\"McAfee Blog\",\"description\":\"Internet Security News\",\"publisher\":{\"@id\":\"https:\/\/www.mcafee.com\/blogs\/#organization\"},\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\/\/www.mcafee.com\/blogs\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"en-US\"},{\"@type\":\"Organization\",\"@id\":\"https:\/\/www.mcafee.com\/blogs\/#organization\",\"name\":\"McAfee\",\"url\":\"https:\/\/www.mcafee.com\/blogs\/\",\"logo\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.mcafee.com\/blogs\/#\/schema\/logo\/image\/\",\"url\":\"https:\/\/www.mcafee.com\/blogs\/wp-content\/uploads\/2023\/02\/mcafee-logo.png\",\"contentUrl\":\"https:\/\/www.mcafee.com\/blogs\/wp-content\/uploads\/2023\/02\/mcafee-logo.png\",\"width\":1286,\"height\":336,\"caption\":\"McAfee\"},\"image\":{\"@id\":\"https:\/\/www.mcafee.com\/blogs\/#\/schema\/logo\/image\/\"},\"sameAs\":[\"https:\/\/www.facebook.com\/McAfee\/\",\"https:\/\/x.com\/McAfee\",\"https:\/\/www.linkedin.com\/company\/mcafee\/\",\"https:\/\/www.youtube.com\/McAfee\"]},{\"@type\":\"Person\",\"@id\":\"https:\/\/www.mcafee.com\/blogs\/#\/schema\/person\/86f325fa6532a017d06d6b49a2f3b1ad\",\"name\":\"McAfee Labs\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"en-US\",\"@id\":\"https:\/\/www.mcafee.com\/blogs\/#\/schema\/person\/image\/af947d76ffbef8521094b476cf8050c3\",\"url\":\"https:\/\/www.mcafee.com\/blogs\/wp-content\/uploads\/2017\/07\/Social-Media-PF-Logo-Pic-300x300-2-96x96.jpg\",\"contentUrl\":\"https:\/\/www.mcafee.com\/blogs\/wp-content\/uploads\/2017\/07\/Social-Media-PF-Logo-Pic-300x300-2-96x96.jpg\",\"caption\":\"McAfee Labs\"},\"description\":\"McAfee Labs is one of the leading sources for threat research, threat intelligence, and cybersecurity thought leadership. See our blog posts below for more information.\",\"sameAs\":[\"https:\/\/www.linkedin.com\/company\/mcafee\/\",\"https:\/\/www.facebook.com\/McAfee\/\",\"https:\/\/x.com\/McAfee_Labs\"],\"url\":\"https:\/\/www.mcafee.com\/blogs\/author\/mcafee-labs\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"GULoader Campaigns: A Deep Dive Analysis of a highly evasive Shellcode based loader | McAfee Blog","description":"Authored by: Anandeshwar Unnikrishnan Stage 1: GULoader Shellcode Deployment\u00a0 In recent GULoader campaigns, we are seeing a rise in NSIS-based installers","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"og_locale":"en_US","og_type":"article","og_title":"GULoader Campaigns: A Deep Dive Analysis of a highly evasive Shellcode based loader | McAfee Blog","og_description":"Authored by: Anandeshwar Unnikrishnan Stage 1: GULoader Shellcode Deployment\u00a0 In recent GULoader campaigns, we are seeing a rise in NSIS-based installers","og_url":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/","og_site_name":"McAfee Blog","article_publisher":"https:\/\/www.facebook.com\/McAfee\/","article_author":"https:\/\/www.facebook.com\/McAfee\/","article_published_time":"2023-05-09T17:50:12+00:00","article_modified_time":"2023-07-11T18:07:02+00:00","og_image":[{"width":300,"height":200,"url":"https:\/\/www.mcafee.com\/blogs\/wp-content\/uploads\/2023\/05\/300x200_Blog_GULoader.png","type":"image\/png"}],"author":"McAfee Labs","twitter_card":"summary_large_image","twitter_creator":"@McAfee_Labs","twitter_site":"@McAfee","twitter_misc":{"Written by":"McAfee Labs","Est. reading time":"20 minutes"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/#article","isPartOf":{"@id":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/"},"author":{"name":"McAfee Labs","@id":"https:\/\/www.mcafee.com\/blogs\/#\/schema\/person\/86f325fa6532a017d06d6b49a2f3b1ad"},"headline":"GULoader Campaigns: A Deep Dive Analysis of a highly evasive Shellcode based loader","datePublished":"2023-05-09T17:50:12+00:00","dateModified":"2023-07-11T18:07:02+00:00","mainEntityOfPage":{"@id":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/"},"wordCount":4099,"publisher":{"@id":"https:\/\/www.mcafee.com\/blogs\/#organization"},"image":{"@id":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/#primaryimage"},"thumbnailUrl":"https:\/\/www.mcafee.com\/blogs\/wp-content\/uploads\/2023\/05\/300x200_Blog_GULoader.png","articleSection":["McAfee Labs"],"inLanguage":"en-US"},{"@type":"WebPage","@id":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/","url":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/","name":"GULoader Campaigns: A Deep Dive Analysis of a highly evasive Shellcode based loader | McAfee Blog","isPartOf":{"@id":"https:\/\/www.mcafee.com\/blogs\/#website"},"primaryImageOfPage":{"@id":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/#primaryimage"},"image":{"@id":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/#primaryimage"},"thumbnailUrl":"https:\/\/www.mcafee.com\/blogs\/wp-content\/uploads\/2023\/05\/300x200_Blog_GULoader.png","datePublished":"2023-05-09T17:50:12+00:00","dateModified":"2023-07-11T18:07:02+00:00","description":"Authored by: Anandeshwar Unnikrishnan Stage 1: GULoader Shellcode Deployment\u00a0 In recent GULoader campaigns, we are seeing a rise in NSIS-based installers","breadcrumb":{"@id":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/#breadcrumb"},"inLanguage":"en-US","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/"]}]},{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/#primaryimage","url":"https:\/\/www.mcafee.com\/blogs\/wp-content\/uploads\/2023\/05\/300x200_Blog_GULoader.png","contentUrl":"https:\/\/www.mcafee.com\/blogs\/wp-content\/uploads\/2023\/05\/300x200_Blog_GULoader.png","width":300,"height":200},{"@type":"BreadcrumbList","@id":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/guloader-campaigns-a-deep-dive-analysis-of-a-highly-evasive-shellcode-based-loader\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"Blog","item":"https:\/\/www.mcafee.com\/blogs\/"},{"@type":"ListItem","position":2,"name":"Other Blogs","item":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/"},{"@type":"ListItem","position":3,"name":"McAfee Labs","item":"https:\/\/www.mcafee.com\/blogs\/other-blogs\/mcafee-labs\/"},{"@type":"ListItem","position":4,"name":"GULoader Campaigns: A Deep Dive Analysis of a highly evasive Shellcode based loader"}]},{"@type":"WebSite","@id":"https:\/\/www.mcafee.com\/blogs\/#website","url":"https:\/\/www.mcafee.com\/blogs\/","name":"McAfee Blog","description":"Internet Security News","publisher":{"@id":"https:\/\/www.mcafee.com\/blogs\/#organization"},"potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/www.mcafee.com\/blogs\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"en-US"},{"@type":"Organization","@id":"https:\/\/www.mcafee.com\/blogs\/#organization","name":"McAfee","url":"https:\/\/www.mcafee.com\/blogs\/","logo":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.mcafee.com\/blogs\/#\/schema\/logo\/image\/","url":"https:\/\/www.mcafee.com\/blogs\/wp-content\/uploads\/2023\/02\/mcafee-logo.png","contentUrl":"https:\/\/www.mcafee.com\/blogs\/wp-content\/uploads\/2023\/02\/mcafee-logo.png","width":1286,"height":336,"caption":"McAfee"},"image":{"@id":"https:\/\/www.mcafee.com\/blogs\/#\/schema\/logo\/image\/"},"sameAs":["https:\/\/www.facebook.com\/McAfee\/","https:\/\/x.com\/McAfee","https:\/\/www.linkedin.com\/company\/mcafee\/","https:\/\/www.youtube.com\/McAfee"]},{"@type":"Person","@id":"https:\/\/www.mcafee.com\/blogs\/#\/schema\/person\/86f325fa6532a017d06d6b49a2f3b1ad","name":"McAfee Labs","image":{"@type":"ImageObject","inLanguage":"en-US","@id":"https:\/\/www.mcafee.com\/blogs\/#\/schema\/person\/image\/af947d76ffbef8521094b476cf8050c3","url":"https:\/\/www.mcafee.com\/blogs\/wp-content\/uploads\/2017\/07\/Social-Media-PF-Logo-Pic-300x300-2-96x96.jpg","contentUrl":"https:\/\/www.mcafee.com\/blogs\/wp-content\/uploads\/2017\/07\/Social-Media-PF-Logo-Pic-300x300-2-96x96.jpg","caption":"McAfee Labs"},"description":"McAfee Labs is one of the leading sources for threat research, threat intelligence, and cybersecurity thought leadership. See our blog posts below for more information.","sameAs":["https:\/\/www.linkedin.com\/company\/mcafee\/","https:\/\/www.facebook.com\/McAfee\/","https:\/\/x.com\/McAfee_Labs"],"url":"https:\/\/www.mcafee.com\/blogs\/author\/mcafee-labs\/"}]}},"_links":{"self":[{"href":"https:\/\/www.mcafee.com\/blogs\/wp-json\/wp\/v2\/posts\/168594","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www.mcafee.com\/blogs\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www.mcafee.com\/blogs\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www.mcafee.com\/blogs\/wp-json\/wp\/v2\/users\/695"}],"replies":[{"embeddable":true,"href":"https:\/\/www.mcafee.com\/blogs\/wp-json\/wp\/v2\/comments?post=168594"}],"version-history":[{"count":5,"href":"https:\/\/www.mcafee.com\/blogs\/wp-json\/wp\/v2\/posts\/168594\/revisions"}],"predecessor-version":[{"id":171475,"href":"https:\/\/www.mcafee.com\/blogs\/wp-json\/wp\/v2\/posts\/168594\/revisions\/171475"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/www.mcafee.com\/blogs\/wp-json\/wp\/v2\/media\/169435"}],"wp:attachment":[{"href":"https:\/\/www.mcafee.com\/blogs\/wp-json\/wp\/v2\/media?parent=168594"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www.mcafee.com\/blogs\/wp-json\/wp\/v2\/categories?post=168594"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www.mcafee.com\/blogs\/wp-json\/wp\/v2\/tags?post=168594"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www.mcafee.com\/blogs\/wp-json\/wp\/v2\/coauthors?post=168594"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}