{ "id": "731e8695-df7d-48ca-a2d2-7bc81ccc3637", "created_at": "2026-04-06T00:10:37.784684Z", "updated_at": "2026-04-10T13:11:27.267445Z", "deleted_at": null, "sha1_hash": "d502758c777e31ab3f84352ba57f65e289ad4383", "title": "How To Guide | Dissecting the new shellcode-based variant of GuLoader (CloudEyE) | Spamhaus Technology", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 811231, "plain_text": "How To Guide | Dissecting the new shellcode-based variant of\r\nGuLoader (CloudEyE) | Spamhaus Technology\r\nArchived: 2026-04-05 20:40:55 UTC\r\nWhat is GuLoader?\r\nGuLoader, or as it is also known, CloudEye, is a small VB5/6 downloader malware. Typically, it downloads\r\nRemote Access Tools (RATs) and Stealers, such as Agent Tesla, Arkei/Vidar, Formbook, Lokibot, Netwire, and\r\nRemcos, often (but not always), from Google Drive.\r\nWhat’s so special about GuLoader?\r\nGuLoader is notorious for its anti-virtual machine (anti-VM) tactics, i.e., thwarting any attempts for researchers to\r\nanalyze it. In fact, it was so successful at evading analysis that, at one point, not even one of the most famous\r\nonline sandboxes could detonate the malware successfully.\r\nUtilizing a packer to swerve detection\r\nGuLoader utilizes the Nullsoft Scriptable Install System (NSIS) packer to compress and encrypt its payload. The\r\nNSIS packer is a free, open-source tool commonly used to create Windows installers. However, it can also pack\r\nother types of files, such as executables. It is GuLoader’s use of the NSIS packer that makes it harder for antivirus\r\nprograms to detect and remove the malware.\r\nWhen GuLoader packs its payload, it first compresses the file using the NSIS packer, then encrypts the\r\ncompressed file with a custom encryption algorithm. The encrypted file is then embedded into the GuLoader\r\nexecutable. When GuLoader is run, it decrypts and unpacks the payload, then executes it.\r\nGuLoader employs a multitude of “anti” strategies\r\nWe all know that virtualization is a common way to improve infrastructure efficiency and reduce costs across the\r\nIT industry. However, attackers can abuse it to evade detection and launch attacks. Here are some of the ways\r\nGuLoader evades detection:\r\n1. Checking for common VM tools: GuLoader checks for the presence of common VM tools such as\r\nVMware, VirtualBox, and QEMU. If any of these tools are detected, GuLoader will not execute.\r\n2. Checking for debuggers: GuLoader checks for the presence of debuggers such as OllyDbg and WinDbg.\r\nIf a debugger is detected, GuLoader will not execute.\r\n3. Checking for sandboxes: GuLoader checks for the presence of sandboxes such as Cuckoo Sandbox and\r\nAnubis. If a sandbox is detected, GuLoader will not execute.\r\nWe’ve covered the basic overview; now brace yourselves as we get down and dirty looking under the hood of\r\nGuLoader.\r\nhttps://www.spamhaus.com/resource-center/dissecting-the-new-shellcode-based-variant-of-guloader-cloudeye/\r\nPage 1 of 9\n\nHow does Guloader resolve an API?\r\nGuLoader uses a hashed technique to resolve an API call; it’s a modified version of djb2 – see the example below:\r\nBinary code obfuscation techniques\r\nGuLoader uses these to make code more difficult to understand and reverse engineer. They work by making the\r\ncode appear random or meaningless, making it harder for humans to understand what it does.\r\nOne of the most common obfuscation techniques is “opaque predicates“, which are Boolean expressions that\r\nalways return true or false values. However, the value is not known beforehand, making it difficult to understand\r\nwhat it does. Opaque predicates are often used with other obfuscation techniques, such as code permutation, to\r\nmake the code even more difficult to understand.\r\nhttps://www.spamhaus.com/resource-center/dissecting-the-new-shellcode-based-variant-of-guloader-cloudeye/\r\nPage 2 of 9\n\nGuLoader uses vectored exceptional handler to change code flow\r\nOne interesting feature of GuLoader is how it manages to change the code flow during runtime. This is done using\r\nvectored exceptional handler (VEH), a software exception handling mechanism. A VEH can be used to intercept\r\nand handle exceptions generated by the operating system or running programs.\r\nThe operating system or program will generate an exception code when an exception occurs. The VEH then looks\r\nup the address of the exception handler associated with that exception code and calls it. GuLoader uses VEH to\r\nmodify the extended instruction pointer (EIP) at an exception to point to the next legitimate instruction. Here’s the\r\nVEH setup:\r\nhttps://www.spamhaus.com/resource-center/dissecting-the-new-shellcode-based-variant-of-guloader-cloudeye/\r\nPage 3 of 9\n\nInitially, as the exception happens, _CONTEXTRECORD structure is checked for the presence of hardware\r\nregisters, i.e., the x86 debug registers:\r\nThe EIP, where the exception happened, is compared against byte 0xcc, i.e., the software break point. This is a\r\nnecessary condition for the exception to proceed and to generate the next EIP.\r\nThe EIP is calculated relative to the place where the exception occurred:\r\nhttps://www.spamhaus.com/resource-center/dissecting-the-new-shellcode-based-variant-of-guloader-cloudeye/\r\nPage 4 of 9\n\nThe byte after the exception EIP is XORed with 0xcb, and the result is added to the current EIP to get the next\r\nlocation for execution. The instruction in between the exception EIP and the calculated EIP is filled with junk\r\ninstructions to confuse the disassembler, as illustrated below:\r\nHow to automate the extraction of indicators of compromise (IOCs) from GuLoader\r\nThe manual dissection of GuLoader payloads becomes a cumbersome and tedious process due to the presence of\r\nall the various hardcore anti-VM, anti-analysis, and anti-debug mechanisms. Therefore, it is imperative to\r\nhttps://www.spamhaus.com/resource-center/dissecting-the-new-shellcode-based-variant-of-guloader-cloudeye/\r\nPage 5 of 9\n\nautomate this extraction. To make the process successful, we must first automate the dumping and then write a\r\nscript to extract the parameters necessary to get the URL out of GuLoader.\r\nBut GuLoader presents us with a big hurdle, i.e., the anti-dumping protection. This is a technique used to prevent\r\nreverse engineering and analysis of the code. It works by encrypting or obfuscating the code, making it\r\nexceptionally difficult to read and understand.\r\nGuLoader encrypts the main binary code at any point in the calling of any system API, which invariably makes\r\nthe dumped code useless. The following two images depict “XORing the code before the call” and “deXORing\r\nafter the API call”, respectively.\r\n \r\nA weakness you can exploit is the initial API call made by GuLoader, which is not wrapped in the subroutine that\r\ndoes all the aforementioned “anti “checks.\r\nTo exploit this weakness, you can set up a DLL hook after OEP is reached, as shown in the code below:\r\nhttps://www.spamhaus.com/resource-center/dissecting-the-new-shellcode-based-variant-of-guloader-cloudeye/\r\nPage 6 of 9\n\nOnce the dump is successful, we have to locate the key. This process is reasonably straightforward, as GuLoader\r\nencrypts the botnet command and controller (C\u0026C) with the same subroutine as the strings. Here’s the string\r\ndecoding subroutine:\r\nhttps://www.spamhaus.com/resource-center/dissecting-the-new-shellcode-based-variant-of-guloader-cloudeye/\r\nPage 7 of 9\n\nThe interesting pattern to observe is how the parameters are supplied to the subroutine; being a subroutine with\r\n__stdcall calling conventions, the stack is cleaned by the called function, but only three parameters are pushed\r\nonto the stack.\r\nTracking back, we can observe that the key parameter is pushed using a direct call opcode. That’s precisely the\r\nlocation of the XOR key to be used.\r\nOnce you have extracted the key, you can easily brute force for the presence of URLs in the memory dump using\r\nthe following code:\r\nThe output will be:\r\npython Gu2Extract.py MemDump\r\nhttps://www.spamhaus.com/resource-center/dissecting-the-new-shellcode-based-variant-of-guloader-cloudeye/\r\nPage 8 of 9\n\nGuLoader c2 = b’http://192.3.245.147/2022.bin\r\nEasy as that 😊!\r\nAs is evident from what we’ve discussed, GuLoader is challenging to detect and remove and can pose a severe\r\nthreat to both individual users and organizations. There are several ways to protect against GuLoader, most of\r\nthem are IT basics – but sadly, the basics often get missed:\r\nKeep your software up to date\r\nUsing a reliable antivirus solution\r\nTrain users to be careful when opening email attachments.\r\nFurther malware information\r\nTo see what malware families our researchers are currently observing in our botnet command and controller\r\n(C\u0026C) report, visit our Botnet Quarterly Update.\r\nAuthor: Raashid Bhat, Malware Reverse Engineer, Spamhaus. Active 2017 - 2023.\r\nSource: https://www.spamhaus.com/resource-center/dissecting-the-new-shellcode-based-variant-of-guloader-cloudeye/\r\nhttps://www.spamhaus.com/resource-center/dissecting-the-new-shellcode-based-variant-of-guloader-cloudeye/\r\nPage 9 of 9\n\n https://www.spamhaus.com/resource-center/dissecting-the-new-shellcode-based-variant-of-guloader-cloudeye/ \nOnce the dump is successful, we have to locate the key. This process is reasonably straightforward, as GuLoader\nencrypts the botnet command and controller (C\u0026C) with the same subroutine as the strings. Here’s the string\ndecoding subroutine: \n Page 7 of 9", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "origins": [ "web" ], "references": [ "https://www.spamhaus.com/resource-center/dissecting-the-new-shellcode-based-variant-of-guloader-cloudeye/" ], "report_names": [ "dissecting-the-new-shellcode-based-variant-of-guloader-cloudeye" ], "threat_actors": [], "ts_created_at": 1775434237, "ts_updated_at": 1775826687, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/d502758c777e31ab3f84352ba57f65e289ad4383.pdf", "text": "https://archive.orkl.eu/d502758c777e31ab3f84352ba57f65e289ad4383.txt", "img": "https://archive.orkl.eu/d502758c777e31ab3f84352ba57f65e289ad4383.jpg" } }