{
	"id": "6d3e511e-e0b8-422a-a612-5c3fa4a237b3",
	"created_at": "2026-04-06T00:17:54.755591Z",
	"updated_at": "2026-04-10T03:21:38.31866Z",
	"deleted_at": null,
	"sha1_hash": "52106b037b243e58673a4a7fc0abe3018b6f5c6a",
	"title": "Cloud-Based Malware Delivery: The Evolution of GuLoader - Check Point Research",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 105012,
	"plain_text": "Cloud-Based Malware Delivery: The Evolution of GuLoader - Check\r\nPoint Research\r\nBy alexeybu\r\nPublished: 2023-05-22 · Archived: 2026-04-05 16:15:35 UTC\r\nKey takeaways\r\nGuLoader is a prominent shellcode-based downloader that has been used in a large number of attacks to deliver a\r\nwide range of the “most wanted” malware.\r\nGuLoader has been active for more than three years and is still undergoing further development. The latest version\r\nintegrates new anti-analysis techniques, which results in it being significantly challenging to analyze. New GuLoader\r\nsamples receive zero detections on VirusTotal, ensuring its malicious payloads also remain undetected.\r\nGuLoader’s payload is fully encrypted, including PE headers. This allows threat actors to store payloads using well-known public cloud services, bypass antivirus protections, and keep payloads available for download for a long\r\nperiod of time.\r\nEarlier versions of GuLoader were implemented as VB6 applications containing encrypted shellcode. Currently, the\r\nmost common versions are based on the VBScript and the NSIS installer. The VBScript variant stores the shellcode\r\non a remote server.\r\nIntroduction\r\nAntivirus products are constantly evolving to become more sophisticated and better equipped to handle complex threats. As\r\na result, malware developers strive to create new threats that can bypass the defenses of antivirus products. “Packing” and\r\n“crypting” services are specifically designed to resist analysis. GuLoader is one of the most prominent services\r\ncybercriminals use to evade antivirus detection.\r\nFigure 1 – The number of attacks using GuLoader in the past 6 months.\r\nFigure 1 – The number of attacks using GuLoader in the past 6 months.\r\nIn addition to code encryption, GuLoader utilizes many other techniques including anti-debugging and sandbox evasion\r\ntechniques. A distinguishing feature of GuLoader is that the encrypted payload is uploaded to a remote server. The would-be\r\nattacker gets a highly protected shellcode-based loader that downloads the payload from a remote server, and decrypts and\r\nruns it in memory without dropping the decrypted data to the hard drive.\r\nDespite Google’s efforts to block GuLoader’s encrypted malicious payloads, GuLoader still downloads payloads from\r\nGoogle Drive in most cases. The following chart shows the statistics of the different hosting services used by GuLoader over\r\nthe past month.\r\nFigure 2 – Different hosting services used by\r\nGuLoader between March – April 2023.\r\nFigure 2 – Different hosting services used by GuLoader between March – April 2023.\r\nWe see evidence that GuLoader is currently being used to distribute the following malware:\r\nhttps://research.checkpoint.com/2023/cloud-based-malware-delivery-the-evolution-of-guloader/\r\nPage 1 of 12\n\nFormbook\r\nXLoader\r\nRemcos\r\n404Keylogger\r\nLokibot\r\nAgentTesla\r\nNanoCore\r\nNetWire\r\nEarly GuLoader samples managed to avoid detection by antivirus products, but later different security solutions became\r\ncapable of detecting this malware.  However, in parallel with the ongoing development of antivirus software by\r\ncybersecurity vendors, the GuLoader developers also continued improving their product. In the absence of previous research\r\nfindings and understanding of the anti-analysis mechanisms employed in GuLoader, analyzing the code of the new version\r\nwould be exceedingly challenging.  You will discover the reasons for this below in our report.\r\nTechnical details\r\nThe earlier versions of GuLoader were implemented as VB6 applications containing encrypted shellcode. The shellcode\r\nperformed the main functions of loading the encrypted payload, decrypting it and launching it from memory.\r\nCurrently, the most common versions are based on the VBScript and the NSIS installer (Nullsoft Scriptable Install System).\r\nVBScript variant\r\nIn the earlier version described at the end of 2022, the shellcode was stored inside the VBScript.\r\nA distinctive feature of the new version is that the encrypted shellcode is hosted on a cloud service (usually Google Drive).\r\nVBScript itself contains only a small obfuscated PowerShell script and a lot of junk code. This allows GuLoader samples to\r\nmaintain a very low detection rate.\r\nHere is an example of an infection chain that uses the VBS variant of GuLoader:\r\nFigure 3 – Infection chain that uses VBS variant\r\nof GuLoader.\r\nFigure 3 – Infection chain that uses VBS variant of GuLoader.\r\nLet’s consider a sample with SHA256 5fcfdf0e241a0347f9ff9caa897649e7fe8f25757b39c61afddbe288202696d5. At the\r\ntime of uploading to VirusTotal (VT) on March 3, 2023, it had 0 detections:\r\nFigure 4 – Zero detections of GuLoader sample in\r\nVT.\r\nFigure 4 – Zero detections of GuLoader sample in VT.\r\nTwo days after it was uploaded, only 17 out of 59 vendors flagged this sample as malicious.\r\nhttps://research.checkpoint.com/2023/cloud-based-malware-delivery-the-evolution-of-guloader/\r\nPage 2 of 12\n\nWe should note that at the time of writing this article, it has been 3 weeks since the specified sample was uploaded to VT,\r\nand the URLs for both downloading the GuLoader shellcode and for downloading the malicious payload (Remcos) were still\r\nactive:\r\nDescription MD5 URL\r\nShellcode 141da1d174041a32cc6a234d80d0b850\r\nhxxps://drive.google.com/uc?\r\nexport=download\u0026id=1BZ2BJVzqOMDwarpjiTzKEiwa42W1Dj9q\r\nPayload bcea24378a2134429ca82164827f1c25\r\nhxxps://drive.google.com/uc?\r\nexport=download\u0026id=1soTWv6y3rkBBbmMcBMOwovCqXxU4U\r\nLet’s take a look inside the GuLoader VBScript. It contains a lot of pseudo-random comments and some useless commands.\r\nAfter cleaning it up a bit, the code we got looks like this:\r\nFigure 5 – Cleaned GuLoader VBScirpt.\r\nFigure 5 – Cleaned GuLoader VBScirpt.\r\nThe purpose of this code is to call the PowerShell interpreter and pass it the code of the script collected in the “pa0” variable\r\nas a parameter.\r\nIf we look at the contents of the “pa0” variable after adding the omissions and hyphens, we get the following script:\r\nFigure 6 – GuLoader obfuscated PowerShell\r\nscript.\r\nFigure 6 – GuLoader obfuscated PowerShell script.\r\nWe see that this new script contains the function “Gothites9“, which implements cutting the passed string starting from the\r\nsecond character with a step of 3. Therefore, the result for the command “$Tjene0 = Gothites9 ‘ OIUlEDiXSa ‘;” is “IEX\r\n”.\r\nThe string $Parrotb is converted in the same way. Starting from position 2, taking every third character from this string\r\ngives us a string that is another PowerShell script:\r\nFigure 7 – GuLoader PowerShell script after\r\nremoving the first layer of obfuscation.\r\nFigure 7 – GuLoader PowerShell script after removing the first layer of obfuscation.\r\nhttps://research.checkpoint.com/2023/cloud-based-malware-delivery-the-evolution-of-guloader/\r\nPage 3 of 12\n\nThis script is called either by using the IEX command (if the OS is 32-bit) or passed as a parameter to the PowerShell\r\ninterpreter called from the SysWOW64 folder (if the OS is 64-bit). This is because the GuLoader shellcode must run in a 32-\r\nbit process.\r\nWe can already see that the script code contains the URL pointing to Google Drive.\r\nHowever, the resulting script is still heavily obfuscated. The script starts with a function that is used to decode strings:\r\nFigure 8 – Encoded strings in the GuLoader\r\nPowerShell script.\r\nFigure 8 – Encoded strings in the GuLoader PowerShell script.\r\nIt is interesting that all lines in the nested script are stored in encoded form, except for the line with the URL.\r\nAfter deobfuscating the script, we got the following code:\r\nFigure 9 – Deobfuscated GuLoader PowerShell\r\nscript.\r\nFigure 9 – Deobfuscated GuLoader PowerShell script.\r\nNow we can see that the script allocates 2 memory areas, downloads the data from the link to Google Drive, and saves it to a\r\ntemporary file “%APPDATA%\\Umig.For”. Next, the contents of the downloaded file are decoded using BASE64. The\r\nfirst 654 bytes of the decoded data are placed in the first memory area (“$Gamme2483” in the example), and the rest in the\r\nsecond (“$Nulstille” in the example). The first 654 bytes contain an obfuscated shellcode which is intended to decrypt the\r\nsecond copied area containing the main part of the shellcode in encrypted form.\r\nControl is transferred to the decryptor by using the CallWindowsProc callback function, which also receives the address of\r\nthe encrypted shellcode and the address of the NtProtectVirtualMemory function as arguments.\r\nNSIS-installer based variant\r\nUnlike the VBS variant, samples based on the NSIS contain the GuLoader shellcode, albeit in encrypted form. This allows\r\nyou to run the sample in a sandbox and see the behavior of GuLoader even if the sandbox is not connected to the Internet.\r\nStatic analysis of NSIS script and encrypted shellcode is also possible.\r\nSuch samples now receive a consistent number of detections by antivirus products at the time of the first upload to\r\nVirusTotal.\r\nFigure 10 – Detection rate of NSIS-installer-based\r\nGuLoader variant.\r\nhttps://research.checkpoint.com/2023/cloud-based-malware-delivery-the-evolution-of-guloader/\r\nPage 4 of 12\n\nFigure 10 – Detection rate of NSIS-installer-based GuLoader variant.\r\nWe will not describe this variant in detail, as it was already analyzed in the article GuLoader: The NSIS Vantage Point.\r\nGuLoader shellcode\r\nThe same version of the shellcode is used in both the NSIS and VBS variants. As in previous GuLoader versions, the\r\nshellcode implements a large number of anti-analysis techniques:\r\nSandbox evasion techniques including:\r\nScanning memory for VM-related strings.\r\nChecking if the hypervisor bit is enabled, using CPUID instruction\r\n(https://evasions.checkpoint.com/techniques/cpu.html#check-if-being-run-in-Hypervisor-via-cpuid).\r\nMeasuring time, using RDTSC in combination with CPUID\r\n(https://evasions.checkpoint.com/techniques/timing.html#rdtsc).\r\nSearching for QEMU related files: C:\\Program Files\\Qemu-ga\\qemu-ga.exe and C:\\Program Files\\qga\\qga.exe.\r\nCounting the number of Windows, using the EnumWindows API function\r\n(https://evasions.checkpoint.com/techniques/ui-artifacts.html#check-number-of-top-level-windows).\r\nChecking if there are any VM-related drivers present, using the EnumDeviceDrivers API function.\r\nEnumerating installed software, using the MsiEnumProductsA and MsiGetProductInfoA.\r\nAnti-debugging techniques:\r\nHooking the functions DbgBreakPoint (https://anti-debug.checkpoint.com/techniques/process-memory.html#patch_ntdll_dbgbreakpoint) and DbgUiRemoveBreakIn (https://anti-debug.checkpoint.com/techniques/process-memory.html#patch_ntdll_dbguiremotebreakin) to prevent the debugger\r\nfrom attaching.\r\nHiding the main thread from the debugger calling the NtSetInformationThread function with the\r\nThreadHideFromDebugger (https://anti-debug.checkpoint.com/techniques/interactive.html#ntsetinformationthread)\r\nThreadInformationClass value.\r\nKnowing the techniques used by the GuLoader shellcode, it is quite easy to bypass them by using a debugger in the process\r\nof dynamic analysis. However, in the new version, we encountered a technique that makes both debugging and static\r\nanalysis extremely difficult.\r\nA new anti-analysis technique\r\nStarting from the end of 2022, the GuLoader shellcode uses a new anti-analysis technique, which consists of breaking the\r\nnormal flow of code execution by deliberately throwing a large number of exceptions and handling them in a vector\r\nexception handler that transfers control to a dynamically calculated address.\r\nTo throw exceptions, the code uses the int3 instruction. It was possible to implement a script to automatically replace int3\r\ninstructions with jump instructions to the correct address:\r\nFigure 11 – Replacement of the int3 instruction\r\nwith the jmp instruction.\r\nFigure 11 – Replacement of the int3 instruction with the jmp instruction.\r\nhttps://research.checkpoint.com/2023/cloud-based-malware-delivery-the-evolution-of-guloader/\r\nPage 5 of 12\n\nThis technique was first described in the article Malware Analysis: GuLoader Dissection Reveals New Anti-Analysis\r\nTechniques and Code Injection Redundancy. However, in the new version this technique has been improved. The shellcode\r\nstarted using three different patterns to throw exceptions and break the normal flow of code execution.\r\nAccessing an invalid memory address to cause access violation.\r\nThis pattern is quite straightforward. First, as a result of mathematical operations, one of the registers is set to zero value.\r\nThe shellcode then attempts to write data to the memory addressed by this register:\r\nFigure 12 – Accessing invalid memory address to\r\nraise the access violation exception.\r\nFigure 12 – Accessing invalid memory address to raise the access violation exception.\r\nThis causes the access violation exception (0xC0000005). The exception is handled in GuLoader by the registered VEH\r\nwhich calculates the new address to continue the shellcode execution. The numbers used and the mathematical operations\r\nthat lead to the calculation of the zero value are always different.\r\nSetting the Trap Flag to raise the single-step exception.\r\nGuLoader uses the following combination of instructions to set TF in the EFALGS register:\r\nFigure 13 – Setting a Trap Flag to raise the single-step exception.\r\nFigure 13 – Setting a Trap Flag to raise the single-step exception.\r\nAt first glance, it is unclear what happens in this piece of code. However, if we calculate the valued in the register EDI, we\r\nget the value 0x100. The combination of the next few instructions is intended to push the EFLAGS and set the TF (Trap\r\nFlag) bit to “1”. The modified value from the stack is then set back to the EFLAGS register.\r\nWhen the Trap flag is set in the EFLAGS register but no debugger is attached, the processor  generates a single-step\r\nexception (0x80000004) after the execution of the next instruction. In GuLoader, the registered VEH is called in this case.\r\nHowever, if the debugger is attached, the GuLoader’s VEH is not called and execution follows the wrong path.\r\nThe code chunks in the GuLoader shellcode are always different; various combinations of registers can be used. As in the\r\ncase of invalid memory address, the numbers used and the mathematical operations that lead to the calculation of the value\r\n0x100 to set TF in the EFLAGS register are always different.\r\nUsing int3 to raise the breakpoint exception.\r\nUsing int3 as instruction as an anti-analysis technique was already implemented in the previous version of GuLoader.\r\nHowever, it is still used in various parts of the GuLoader shellcode. When the CPU encounters the int3 instruction in the\r\nabsence of a debugger, it generates a breakpoint exception (0x80000003) and the registered VEH is called. However, if a\r\ndebugger is attached, the control is transferred to the debugger’s interrupt handler which typically pauses the program’s\r\nexecution.\r\nhttps://research.checkpoint.com/2023/cloud-based-malware-delivery-the-evolution-of-guloader/\r\nPage 6 of 12\n\nThe int3 instruction is usually followed by random bytes that break the normal execution of the shellcode:\r\nFigure 14 – Using int3 to raise the breakpoint\r\nexception.\r\nFigure 14 – Using int3 to raise the breakpoint exception.\r\nAs a result, we cannot determine the correct execution path without analyzing the code of the GuLoader VEH.\r\nException handler\r\nTo calculate a new jump address in the case of one of the 3 specified exceptions, and direct the program to a new execution\r\npath, GuLoader registers a vector exception handler (VEH) using the RtlAddVectoredExceptionHandler function.\r\nTo see how the jump address is calculated, let’s look at the VEH code.\r\nLike other parts of the code, VEH code is obfuscated. It contains junk instructions, and important values are calculated\r\ndynamically using XOR operations:\r\nFigure 15 – Obfuscated VEH code.\r\nFigure 15 – Obfuscated VEH code.\r\nHowever, after the decompilation in IDA this code looks very simple:\r\nFigure 16 – Decompiled VEH code.\r\nFigure 16 – Decompiled VEH code.\r\nAs you can see, VEH actions are slightly different depending on the exception code. In the case of exceptions 0x80000004\r\n(EXCEPTION_SIGNLE_STEP) and 0xC0000005 (EXCEPTION_ACCESS_VIOLATION), it gets the value of the byte\r\nat offset 2 from the instruction where the exception occurred and XORs that byte with some constant value (0x8B in the\r\nexample). In the case of exception 0x80000003 (EXCEPTION_BREAKPOINT), the byte at offset 1 is taken and also\r\nXORs with the constant. It should be noted that the specified constant is different in all samples. The resulting value is then\r\nadded to the EIP value in the exception context. Therefore, when exiting the exception handler, control is transferred to the\r\nnew address.\r\nIn all cases, the exception handler also checks the status of the debug registers:\r\nhttps://research.checkpoint.com/2023/cloud-based-malware-delivery-the-evolution-of-guloader/\r\nPage 7 of 12\n\nFigure 17 – Checking debug registers in VEH.\r\nFigure 17 – Checking debug registers in VEH.\r\nIf any hardware breakpoints are set, the exception handler refers to the zero address instead of the ContextRecord address.\r\nThis eventually causes the application to crash.\r\nIn the case of EXCEPTION_BREAKPOINT, the exception handler also looks for software breakpoints in the address\r\nspace between the old EIP and the calculated new EIP values.\r\nDespite the huge variety of code combinations that can be used to trigger the execution of the exception handler, they all\r\nfollow 3 patterns, and we can implement a regular expression to find most of them. However, we expect that the GuLoader\r\ndevelopers may change the patterns in new versions.\r\nTo patch one instruction on which an exception is raised and replace it with a jump to a correct address in x32dbg, you can\r\nuse the following script (you must replace 0x8B with a constant value from the sample you analyze):\r\nmov $const, 0x8B cmp 1:[eip], 0xCC je exception_breakpoint mov $x, 1:[eip + 2] xor $x, $const jmp patch\r\nexception_breakpoint: mov $x, 1:[eip + 1] xor $x, $const patch: sub $x, 2 1:[eip+1] = $x 1:[eip] = 0xEB\r\nmov $const, 0x8B\r\ncmp 1:[eip], 0xCC\r\nje exception_breakpoint\r\nmov $x, 1:[eip + 2]\r\nxor $x, $const\r\njmp patch\r\nexception_breakpoint:\r\nmov $x, 1:[eip + 1]\r\nxor $x, $const\r\npatch:\r\nsub $x, 2\r\n1:[eip+1] = $x\r\n1:[eip] = 0xEB\r\nURL decryption\r\nAll the strings, including the URL for downloading the final payload, are encrypted and stored in a specific form in the\r\nshellcode:\r\n; eax is set to the address of the allocated memory\r\n8B 44 24 04 mov eax, [esp+target_enc_str_buffer]\r\n; first 4 bytes of the buffer contain the length of the encrypted string\r\n; the bytes are calculated using xor, add, and sub operations:\r\nC7 00 75 9B D5 11 mov dword ptr [eax], 11D59B75h\r\nhttps://research.checkpoint.com/2023/cloud-based-malware-delivery-the-evolution-of-guloader/\r\nPage 8 of 12\n\n81 30 0E 84 7B 49 xor dword ptr [eax], 497B840Eh\r\n81 28 1C 8B 75 41 sub dword ptr [eax], 41758B1Ch\r\n81 00 B3 6B C7 E8 add dword ptr [eax], 0E8C76BB3h ; 12 00 00 00\r\n05 97 47 CD 01 add eax, 1CD4797h\r\n2D 93 47 CD 01 sub eax, 1CD4793h ; eax = eax + 4\r\n; calculate next 4 bytes of the encrypted string\r\nC7 00 B9 FD D8 E0 mov dword ptr [eax], 0E0D8FDB9h\r\n81 30 06 79 13 36 xor dword ptr [eax], 36137906h\r\n81 30 AD 51 65 B7 xor dword ptr [eax], 0B76551ADh\r\n81 30 81 FA 9D 8C xor dword ptr [eax], 8C9DFA81h ; 12 00 00 00 93 2F 33 ED\r\n; eax is set to the address of the allocated memory 8B 44 24 04 mov eax, [esp+target_enc_str_buffer] ; first 4 bytes of the\r\nbuffer contain the length of the encrypted string ; the bytes are calculated using xor, add, and sub operations: C7 00 75 9B\r\nD5 11 mov dword ptr [eax], 11D59B75h 81 30 0E 84 7B 49 xor dword ptr [eax], 497B840Eh 81 28 1C 8B 75 41 sub dword\r\nptr [eax], 41758B1Ch 81 00 B3 6B C7 E8 add dword ptr [eax], 0E8C76BB3h ; 12 00 00 00 ; ... ; increment eax by 4 05 97\r\n47 CD 01 add eax, 1CD4797h 2D 93 47 CD 01 sub eax, 1CD4793h ; eax = eax + 4 ; ... ; calculate next 4 bytes of the\r\nencrypted string C7 00 B9 FD D8 E0 mov dword ptr [eax], 0E0D8FDB9h 81 30 06 79 13 36 xor dword ptr [eax],\r\n36137906h 81 30 AD 51 65 B7 xor dword ptr [eax], 0B76551ADh 81 30 81 FA 9D 8C xor dword ptr [eax], 8C9DFA81h ;\r\n12 00 00 00 93 2F 33 ED ; ...\r\n; eax is set to the address of the allocated memory\r\n8B 44 24 04 mov eax, [esp+target_enc_str_buffer]\r\n; first 4 bytes of the buffer contain the length of the encrypted string\r\n; the bytes are calculated using xor, add, and sub operations:\r\nC7 00 75 9B D5 11 mov dword ptr [eax], 11D59B75h\r\n81 30 0E 84 7B 49 xor dword ptr [eax], 497B840Eh\r\n81 28 1C 8B 75 41 sub dword ptr [eax], 41758B1Ch\r\n81 00 B3 6B C7 E8 add dword ptr [eax], 0E8C76BB3h ; 12 00 00 00\r\n; ...\r\n; increment eax by 4\r\n05 97 47 CD 01 add eax, 1CD4797h\r\n2D 93 47 CD 01 sub eax, 1CD4793h ; eax = eax + 4\r\n; ...\r\n; calculate next 4 bytes of the encrypted string\r\nC7 00 B9 FD D8 E0 mov dword ptr [eax], 0E0D8FDB9h\r\n81 30 06 79 13 36 xor dword ptr [eax], 36137906h\r\n81 30 AD 51 65 B7 xor dword ptr [eax], 0B76551ADh\r\n81 30 81 FA 9D 8C xor dword ptr [eax], 8C9DFA81h ; 12 00 00 00 93 2F 33 ED\r\n; ...\r\nFor the example above, we deobfuscated the code, clearing it of junk instructions and jumps. In reality, the code contains a\r\nlarge number of garbage and invalid instructions. To help understand the obfuscation complexity, this is part of the original\r\ncode corresponding to the previous example:\r\nhttps://research.checkpoint.com/2023/cloud-based-malware-delivery-the-evolution-of-guloader/\r\nPage 9 of 12\n\nFigure 18 – Composing encrypted strings in the\r\nheavily obfuscated GuLoader shellcode.\r\nFigure 18 – Composing encrypted strings in the heavily obfuscated GuLoader shellcode.\r\nUnlike strings, the decryption key is stored as a regular sequence of bytes following the decryption function:\r\nFigure 19 – Strings decryption XOR key.\r\nFigure 19 – Strings decryption XOR key.\r\nThis key is usually not very long, with a maximum of 64 bytes.\r\nThe strings are decrypted using an XOR operation with the decryption key. After decrypting the strings, we can find a string\r\nthat looks like a URL, but without a schema:\r\nvgtirek34.138.169.8/wp-content/themes/seotheme/CbwPtnKqeAYGeixiNB73.inf\r\nIt’s obvious that the GuLoader authors realized the way the research community managed to decrypt URLs in the previous\r\nversions of the shellcode using the strings “http://” or “https://” in the known-plaintext attack to detect the first bytes of the\r\ndecryption key. Therefore, in the new version, they replaced the URL scheme with random bytes.\r\nIf the 5th byte of the decrypted URL-string is equal to “s”, GuLoader replaces the first 8 bytes with “https://”. Otherwise, it\r\nreplaces the first 7 bytes with “http://”.\r\nHere are examples of more URL-strings extracted from different samples:\r\nOriginal string Schema\r\nMatesIndgimiere.nl/XgSUmroHlWk92.bin https://\r\nKlshsShadrive.google.com/uc?\r\nexport=download\u0026id=1OSjh65P9X1Tx4cIemJXvrIa3Lt7pUc5C\r\nhttps://\r\nAppesNondrive.google.com/uc?\r\nexport=download\u0026id=1BMRiKvpSFYvKsNn6ilsl9DD3vFcz338C\r\nhttps://\r\nReseSyn45.88.66.147/kZDkFdCKTkJdSpwPQkKt70.bin http://\r\nPayload decryption\r\nThe payload decryption key is also stored in the same way as the encrypted strings but the key is not encrypted. The key\r\nlength is usually in the range of 800-900 bytes.\r\nhttps://research.checkpoint.com/2023/cloud-based-malware-delivery-the-evolution-of-guloader/\r\nPage 10 of 12\n\nFor example, in a sample with MD5 40b9ca22013d02303d49d8f922ac2739, the length of the key is 844 bytes. However,\r\nanother length is used for the decryption routine, and is stored in the obfuscated form:\r\nFigure 20 – Key length used for decrypting the\r\npayload differs from the length stored with the key.\r\nFigure 20 – Key length used for decrypting the payload differs from the length stored with the key.\r\nGuLoader used a different size, rather than the size stored with the key, to deceive automated analysis. If we don’t take this\r\ninto account, we can only decrypt the first 843 bytes of the downloaded payload, and the rest of the data will be broken.\r\nThe payload decryption algorithm itself has not changed in comparison to the previous GuLoader versions. The first 64\r\nbytes of the downloaded data are skipped. Then, to get the final key, GuLoader assumes that the first 2 bytes of the\r\ndecrypted payload should be “MZ” and calculates the 2-bytes XOR key (rand_key). The payload decryption key is then\r\nXOR-ed with the calculated 2-bytes value:\r\nFigure 21 – Calculating the final key used for\r\ndecrypting the payload.\r\nFigure 21 – Calculating the final key used for decrypting the payload.\r\nThe resulting key is finally used to decrypt the payload.\r\nConclusion\r\nSeveral years after its introduction, the threat posed by GuLoader continues to grow. This is primarily due to the fact that the\r\nGuLoader developers are continually working to improve their product. The advanced defense evasion of GuLoader made it\r\na favored tool among threat actors for delivering malware.\r\nGuLoader counteracts antivirus products using a variety of sandbox evasion techniques, code obfuscation, and multiple\r\nlayers of encryption. The GuLoader developers continually improve the anti-analysis and anti-debugging techniques. This\r\nyear we also saw the use of a new trick: moving the encrypted shellcode to the cloud, and using a VBScript to download the\r\nshellcode. As a result, victims receive a VBScript file, which is less suspicious than an .exe file and is less likely to trigger\r\nalerts.\r\nThe use of encryption and storing payloads in a raw binary format without any headers and separate from the loader makes\r\nthem totally invisible to antiviruses. This allows threat actors to use Google Drive to store malicious payloads and bypass its\r\nantivirus protection. In some cases download links to GuLoader malicious payloads stored in Google Drive remain active\r\nfor very long periods of time.\r\nAppendix: Indicators of Compromise\r\nDescription MD5 ITW URL\r\nhttps://research.checkpoint.com/2023/cloud-based-malware-delivery-the-evolution-of-guloader/\r\nPage 11 of 12\n\nGuLoader\r\nVBScript\r\n9623c946671c6ec7a30b7c45125d5d48  \r\nGuLoader\r\nshellcode\r\n(base64)\r\n141da1d174041a32cc6a234d80d0b850\r\nhttps://drive.google.com/uc?\r\nexport=download\u0026id=1BZ2BJVzqOMDwarpjiTzKEiwa42W1Dj9q\r\nEncrypted\r\nRemcos\r\npayload\r\nbcea24378a2134429ca82164827f1c25\r\nhttps://drive.google.com/uc?\r\nexport=download\u0026id=1soTWv6y3rkBBbmMcBMOwovCqXxU4U\r\nDecrypted\r\nRemcos\r\npayload\r\nd5335a1ec161a8430e564bc66c16f894\r\nhttps://drive.google.com/uc?\r\nexport=download\u0026id=1soTWv6y3rkBBbmMcBMOwovCqXxU4U\r\nGuLoader\r\nNSIS\r\n40b9ca22013d02303d49d8f922ac2739  \r\nGuLoader\r\nencrypted\r\nshellcode\r\n(NSIS)\r\nc6e068ce04fb4959e2e6daaebac8d893  \r\nDecrypted\r\nFormbook\r\npayload\r\n66274853e6f35e3fef0645a6587cb892\r\nhttp://34.138.169.8/wp-content/themes/seotheme/CbwPtnKqeAYGeixiNB73.inf\r\nCheck Point Threat Emulation provides protection against this threat:\r\nDropper.Win.CloudEyE.*\r\nSource: https://research.checkpoint.com/2023/cloud-based-malware-delivery-the-evolution-of-guloader/\r\nhttps://research.checkpoint.com/2023/cloud-based-malware-delivery-the-evolution-of-guloader/\r\nPage 12 of 12",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://research.checkpoint.com/2023/cloud-based-malware-delivery-the-evolution-of-guloader/"
	],
	"report_names": [
		"cloud-based-malware-delivery-the-evolution-of-guloader"
	],
	"threat_actors": [],
	"ts_created_at": 1775434674,
	"ts_updated_at": 1775791298,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/52106b037b243e58673a4a7fc0abe3018b6f5c6a.pdf",
		"text": "https://archive.orkl.eu/52106b037b243e58673a4a7fc0abe3018b6f5c6a.txt",
		"img": "https://archive.orkl.eu/52106b037b243e58673a4a7fc0abe3018b6f5c6a.jpg"
	}
}