{
	"id": "65c2bdd9-27bf-455b-b194-6c7792382de3",
	"created_at": "2026-04-06T00:19:08.265101Z",
	"updated_at": "2026-04-10T03:30:37.630899Z",
	"deleted_at": null,
	"sha1_hash": "b6fd8a2292611991eade47bb11001d05b7087630",
	"title": "Technical Analysis of Bumblebee Malware Loader",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1795949,
	"plain_text": "Technical Analysis of Bumblebee Malware Loader\r\nBy No items found.\r\nPublished: 2025-08-21 · Archived: 2026-04-05 12:56:30 UTC\r\nMalware loaders are essentially remote access trojans (RATs) that establish communication between the attacker\r\nand the compromised system. Loaders typically represent the first stage of a compromise. Their primary goal is to\r\ndownload and execute additional payloads, from the attacker-controlled server, on the compromised system\r\nwithout detection.\r\nResearchers at ProofPoint have discovered a new malware loader called Bumblebee. The malware loader is named\r\nafter a unique user agent string used for C2 communication. It has been observed that adversaries have started\r\nusing Bumblebee to deploy malware such as CobaltStrike beacons and Meterpreter shells. Threat group TA578\r\nhas also been using Bumblebee the loader in their campaigns.\r\nThis article explores and decodes Bumblebee malware loader’s:\r\nTechnical features\r\nLogic flow\r\nExploitation process\r\nNetwork maintenance\r\nUnique features\r\nCampaign Delivery\r\nAdversaries push ISO files through compromised email (reply) chains, known as thread hijacked emails, to deploy\r\nthe Bumblebee loader. ISO files contain a byte-to-byte copy of low-level data stored on a disk. The malicious ISO\r\nfiles are delivered through Google Cloud links or password protected zip folders.\r\nISO file retrieved from Google Cloud (“storage.googleapis.com”)\r\nISO file retrieved from password protected zip files\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 1 of 41\n\nThe ISO files contain a hidden DLL with random names and an LNK file. DLL (Dynamic Link Library) is a\r\nlibrary that contains codes and data which can be used by more than one program at a time. LNK is a filename\r\nextension in Microsoft Windows for shortcuts to local files.\r\nThe LNK file often contains a direct link to an executable file or metadata about the executable file, without the\r\nneed to trace the program’s full path. LNK files are an attractive alternative to opening a file, and thus an effective\r\nway for threat actors to create script-based attacks. The target location for the LNK files is set to run rundll32.exe,\r\nwhich will call an exported function in the associated DLL. If the “show hidden items” option is not enabled on\r\nthe victim’s system, DLLs may not be visible to the user.\r\nBumblebee Loader Analysis\r\nThe analyzed sample (f98898df74fb2b2fad3a2ea2907086397b36ae496ef3f4454bf6b7125fc103b8) is a DLL file\r\nwith exported functions.\r\nExported functions in the sample DLL file\r\nBoth the exported functions, IternalJob and SetPath, execute the function sub_180004AA0.\r\n \r\nInternalJob executing the function sub_180004AA0 SetPath executing the function sub_180004AA0\r\nEntropy of the DLL\r\nThe entropy of a file measures the randomness of the data in the file. Entropy can be used to determine whether\r\nthere is hidden data or suspicious scripts in the file. The scale of entropy is from 0 (not random) to 8 (totally\r\nrandom). High entropy values indicate that there is encrypted data stored in the file, while lower values indicate\r\nthe decryption and storage of payload in different sections during runtime.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 2 of 41\n\nEntropy of the Malware Sample\r\nThe peak is spread across the data segments of the DLL file. It is highly possible that this peak was caused by the\r\npresence of packed data in the data segments of the sample DLL. This indicates that the malware, at some point in\r\nruntime, will fetch the data from the data segment and unpack it for later use.\r\nUnpacking and Deploying Payload (Function sub_180004AA0)\r\nThe exported function sub_180004AA0 is a critical component in unpacking and deploying the main payload on\r\nthe target system.\r\nExported Function sub_180004AA0\r\nThe function sub_180003490 serves as the unpacker for the main payload.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 3 of 41\n\nFunction sub_180003490\r\nFunction sub_180003490\r\nFunction sub_180003490 contains 2 functions of interest:\r\nsub_1800021D0: This function routine is responsible for allocating heap memory.\r\nFunction sub_1800021D0\r\nsub_1800029BC: This function writes the embedded data, in the data segment of the DLL sample, into the newly\r\nallocated heap memory. The packed payload is fetched from the data segment and written into allocated heap\r\nmemory. The code segment highlighted in the image below is responsible for transferring the data.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 4 of 41\n\nFunction sub_1800029BC\r\nFunction sub_1800029BC\r\nAssembly code representation of function sub_1800029BC\r\nThe assembly code highlighted yellow transfers the embedded data (packed payload) from the data\r\nsegment of DLL to an intermediate CL register.\r\nThe assembly code highlighted red transfers the data from CL to the allocated heap. During runtime, the\r\nheap memory continues to get filled with the packed payload embedded within the DLL samples.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 5 of 41\n\nHeap memory during run time\r\nFunction sub_180002FF4\r\nAfter dumping the packed payload in the allocated memory, the control goes back to sub_180004AA0 and\r\nfunction sub_180002FF4 is executed.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 6 of 41\n\nFunction sub_180002FF4\r\nFunction sub_180002FF4 performs the following operations:\r\nAllocates new heap memory.\r\nTransfers previously dumped packed payload into newly allocated memory.\r\nDeallocates previously allocated memory.\r\nAfter the control returns to sub_180004AA0 function sub_180004180 is executed.\r\nFunction sub_180004180\r\nFunction sub_180004180\r\nThree functions encapsulated in Function sub_180004180\r\nFunction sub_180004180 has 3 functions:\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 7 of 41\n\nsub_180001670: This function is responsible for allocating multiple heap memories to the malware. The\r\nmalware later dumps the unpacked MZ file into one of the allocated memories.\r\nsub_180003CE4: This function is responsible for unpacking previously dumped packed payload in the\r\nprocess heap and dumps it into one of the memories allocated by sub_180001670.\r\nsub_180001A84: This function is responsible for deallocating memory.\r\nUnpacked MZ artifact in the memory\r\nHook Implementation\r\nHooking refers to a range of techniques used to modify the behavior of an operating system, software, or software\r\ncomponent, by intercepting the function calls, events, or communication between software components. The code\r\nwhich handles such intercepted function calls, events, or communication is called a hook.\r\nRight after the Bumblebee loader unpacks the main payload in the memory, it hooks a few interesting functions\r\nexported by ntdll.dll (a file containing NT kernel functions, susceptible to cyberattacks) through an in-line\r\nhooking technique. The in-line hooks play a significant role in the execution of the final payload. The trigger\r\nmechanism, for the deployment of the payload, shows the creativity of the malware developer. Function\r\nsub_180001000 is responsible for implementing the in-line hooks.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 8 of 41\n\nFunction sub_180001000\r\nFunction sub_180001000 initially saves the addresses of 3 detour functions used for hooking. The detour\r\nfunctions are responsible for hijacking control flow in hooked Windows functions. After storing the addresses,\r\nsub_1800025EC is executed to resolve the addresses of the target API (Application Programming Interface)\r\nfunctions for hooking.\r\nDetour functions in sub_180001000 function\r\nsub_1800025EC loads ntdll.dll in the address space of the loader process using function LoadLibraryA. Following\r\nthe loading of the ntdll, function GetProcAddress is used to resolve the addresses of functions:\r\nNtOpenFile\r\nNtCreateSection\r\nNtMapViewOfSection\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 9 of 41\n\nLoadLibraryA and GetProcAddress functions\r\nAfter obtaining the addresses to memory pages of the detour functions for hooking, the loader uses function\r\nVirtualProtect to change the memory permissions of the target pages. After changing the permissions, the loader\r\nwrites the in-line hooks in sub_180002978. Then VirtualProtect is called again to restore the page permissions.\r\nVirtualProtect and sub_180002978 functions\r\nThe data passed to VirtualProtect at runtime is shown in the image below. The call to VirtualProtect changes the\r\nntdll.NtOpenFile page permission to 0x40 (PAGE_EXECUTE_READWRITE).\r\nData passed/call to VirtualProtect function\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 10 of 41\n\nAfter changing the page permissions of ntdll.NtOpenFile, the loader modifies the initial sequence of bytes in the\r\nNtOpenFile API by executing function sub_180002978.\r\nsub_180002978 function modifying the NtOpenFile API\r\nIn-line hooking involves the following steps:\r\nntdll.NtOpenFile before (hooking) execution of sub_180002978 function\r\nAfter sub_180002978 is executed, a call to NtOpenFile makes the malware code jump to location\r\n1800023D4 (detour). This is how malicious in-line hooks change the execution flow of APIs.\r\nCall to NtOpenFile making the malware jump to 1800023D4\r\nAfter writing the hook, VirtualProtect is used again to restore the page permission of ntdll.NtOpenFile to\r\n0x20 (PAGE_EXECUTE_READ).\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 11 of 41\n\nVirtualProtect function used to restore page permission of ntdll.NtOpenFile\r\nThe process of changing memory permission and writing in-line hooks is repeated in a do-while loop, for\r\nthe rest of the target functions, NtCreateSection and NtMapViewOfSection.\r\nDo-while loop repeating the permission and hooks process for other target functions\r\nSummary of Hooked Functions\r\nAfter successful hooking, whenever target functions are called in the address space of the loader process, the\r\ncontrol flow is transferred to the in-line the respective hook addresses:\r\nTarget Function In-line Hook (Detours)\r\nntdll.NtOpenFile 1800023D4\r\nntdll.NtCreateSection 1800041EC\r\nntdll.NtMapViewOfSection 180001D4C\r\nLoading gdiplus.dll is Unique to Bumblebee\r\nThe final function executed by the loader is sub_1800013A0. The malware uses the function LoadLibraryW to\r\nload the DLL module. It then uses the function GetProcAddress to obtain the address of a specific function\r\nexported by the library loaded.\r\nThis plays a crucial step in deployment of the main payload on the victim system. Unlike TTPs (Tactics,\r\nTechniques, and Procedures) of common malware loaders, this is where the Bumblebee loader gets creative.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 12 of 41\n\nFunction sub_1800013A0 with LoadLibraryW and GetProcAddress functions\r\nThe module gdiplus.dll is loaded into the process memory address space. Gdiplus.dll is an important module,\r\ncontaining libraries that support the GDI Window Manager, in the Microsoft Windows OS.\r\nRuntime execution of function sub_1800013A0\r\nThe module gdiplus.dll is executed in the last function of the malware loader. This is the first instance in which the\r\nunpacked MZ payload is used directly by the loader. Hence, the loading of this module appears suspicious. Also,\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 13 of 41\n\nan unusual base address (0x1d54fd0000) is assigned to the loaded gdiplus.dll module.\r\nUnusual base address assigned to gdiplus.dll\r\nBy further examining the suspicious memory, it was found that the address is a mapped page with RWX\r\npermission in the loader address space. This is a classic use case of hollowing where the module content is\r\nreplaced with unpacked malicious artifacts.\r\nAddress as a mapped page with RWX permission\r\nBut in our analysis so far we have not come across any code that does the hollowing. Then how did the malware\r\nchange the contents of the gdiplus.dll? Interestingly this is where the malware developer decided to get creative!\r\nThe hooking seen earlier is responsible for hollowing the loaded module with the unpacked payload. More details\r\nabout the same are covered in the following section.\r\nInvestigating the Hooks and the Trigger\r\nAs seen in the previous section, the malware hooks 3 specific APIs:\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 14 of 41\n\nNtOpenFile\r\nNtCreateSection\r\nNtMapViewOfSection\r\nThe API selection is not random. The internal working of loading any DLL via LoadLibrary API uses the 3\r\nfunctions mentioned above. Hooking these functions gives the malware the flexibility to deploy the unpacked\r\npayload covertly. This feature makes it difficult for researchers to hunt the main payload.\r\nThe detour function at 0x180001D4C is used to hook function NtMapViewOfSection, which lays the groundwork\r\nfor hollowing the loaded module (in this case, gdiplus.dll) with the unpacked Bumblebee binary. The detour\r\nfunction is capable of the following actions:\r\nSection object creation via NtCreateSection API\r\nMapping of the view of gdiplus.dll to loader address space via NtMapViewOfSection\r\nWriting the unpacked payload into the mapped view of gdiplus.dll\r\nDeallocating heap memory that holds unpacked payload from earlier steps\r\nThe implementation of the detour function at 0x180001D4C, shows the use of a pointer to the NtCreateSection\r\nAPI, for creating a section object to be used later in mapping the gdiplus.dll module.\r\nPointer to NtCreateSection API\r\nAfter creating a section object, the detour function calls NtMapViewOfSection, via a pointer. Now the view for the\r\nsection is created by the system. The function sub_180002E74 is responsible for filling the mapped view with an\r\nunpacked payload.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 15 of 41\n\nPointer to NtMapViewOfSection along with sub_180002E74 function\r\nThe address of the mapped view, returned by NtMapViewOfSection pointer in the loader process, which is\r\n0x1D54F5D0000, is the same address seen while examining the process modules.\r\nAddress of the mapped view returned by NtMapViewOfSection\r\nUnusual base address assigned to “gdiplus.dll” as seen earlier\r\nThe mapped view starts from 0x1D54F5D0000. The loader dumps the unpacked payload here, hollowing\r\ngdiplus.dll. Hence, the final Bumblebee payload stays hidden inside the loaded module gdiplus.dll.\r\nRight after mapping the view, the detour function executes sub_180002E74 to initiate the writing of the unpacked\r\nbinary.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 16 of 41\n\nFunction sub_180002E74 responsible for filling the mapped view with the final payload\r\nThe hooks get activated as soon as the loader loads the gdiplus.dll module via LoadLibraryW API. Then the\r\npayload is covertly loaded into the gdiplus.dll module. The final payload is a DLL, hence the loader has to\r\nexplicitly call an exported function to trigger the execution.\r\nIn this case, the loader obtains the address of exported function SetPath via function GetProcAddress. The control\r\nis then transferred to the final payload by the final call to SetPath, by providing the loader program name as\r\nargument.\r\nLoader obtains the address of exported function “SetPath” via GetProcAddress\r\nThe image below shows the function SetPath exported by the unpacked Bumblebee payload.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 17 of 41\n\nSetPath Function\r\nBumblebee Main Payload Analysis\r\nThe core malicious component of the bumblebee is executed in the memory, when the hollowed gdiplus.dll is\r\nloaded via the LoadLibrary API. When the module is loaded into memory, the function DllMain creates a new\r\nthread and executes sub_180008EC0 routine.\r\nThe DllMain function of the bumblebee payload\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 18 of 41\n\nsub_180008EC0 routine is quite a large function that is responsible for all the malicious activities performed by\r\nBumblebee on the compromised system.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 19 of 41\n\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 20 of 41\n\nFunction sub_180008EC0 logic flow\r\nAnti VM Checks\r\nThe first activity performed by sub_180008EC0 is to check for a virtual machine (VM) environment. If the\r\nfunction returns True, then Bumblebee shuts itself down by executing the ExitProcess function.\r\nsub_18003DA0 performs VM check\r\nThe VM checking routine is. Rigorous. It employs various techniques to ensure that the malware is not running in\r\na sandbox environment used by security researchers. Some of the interesting features are:\r\nIterating through running processes via functions CreateToolHelp32Snapshot, Process32FirstW, and\r\nProcess32NextW.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 21 of 41\n\nMalware functions which help in iterating through running processes\r\nEach running process is compared to a list of program names.\r\nRunning process being compared to the list of program names\r\nThe malware also checks for specific usernames used in sandboxed environments to confirm the absence of\r\na VM.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 22 of 41\n\nMalware checking for specific usernames\r\nThe VM check routine also enumerates active system services running via the OpenSCManagerW API.\r\nThe names of common services used by VM softwares are stored in an array.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 23 of 41\n\nEnumerating active system services running via OpenSCManagerW\r\nIt also scans the system directory for common drivers and library files used by VM applications.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 24 of 41\n\nSystem check for common drivers and library files used by popular VM applications\r\nThe routine also checks for named pipes to identify the presence of VM.\r\nChecking for named pipes\r\nThese are a few examples of techniques employed by the malware to identify analysis environments. It also has\r\nother functionalities built such as the use of WMI and registry functionalities to identify hardware information to\r\ncheck for the presence of VM environments installed on the target system.\r\nEvent Creation\r\nAfter VM checks, if it is secure to continue, the malware creates an event. The event ID is 3C29FEA2-6FE8-\r\n4BF9-B98A-0E3442115F67. This is used for thread synchronization.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 25 of 41\n\nThe event created by the malware\r\nPersistence\r\nThe malware uses wsript.exe as a persistence vector to run the malware each time the user logs into the system.\r\nThe VB instruction is written into a .vbs file. This is performed when the C2 sends the “ins” command as a task to\r\nexecute on the system.\r\nWsript.exe\r\nVB instruction written into a .vbs file\r\nToken Manipulation\r\nThe malware performs token manipulation to escalate its privilege on the target system by granting the malware\r\nprocess a SeDebugPrivilege. With this privilege the malware can perform arbitrary read/write operations.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 26 of 41\n\nMalware is given the “SeDebugPrivilege”\r\nThe malware is capable of performing code injections to deploy malicious code in running processes using\r\nvarious APIs. The malware dynamically retrieves the addresses of the APIs needed for the code injection. The core\r\nbumblebee payload comes with embedded files which areinjected into the running process to further attack the\r\nvictim.\r\nList of APIs used to perform code injections\r\nCode Injection Via NtQueueApcThread\r\nWhen the malware receives the command along with a DLL buffer, which gets injected, the malware starts\r\nscanning for a list of processes on the system. One of the executables in the list is randomly chosen to inject the\r\nmalicious DLL.\r\nMalware looking for the list of processes on the system\r\nList of executables\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 27 of 41\n\nFollowing the code injection, the malware:\r\nCreates a process from the previously selected executable image via COM (Component Object Model), in\r\nwhich access to an object’s data is received through interfaces, in a suspended state.\r\nEnumerates through the running process via the CreateToolhelp32Snapshot API to find the newly spawned\r\nprocess created in the previous step.\r\nWhen the process is found, the malware manipulates the token and acquires the SeDebugPrivilege token to\r\nperform further memory manipulation.\r\nIf token manipulation is successful, the malware injects a shellcode into the process to make it go to sleep.\r\nMalware creating a process and injecting shellcode into it\r\nFunction sub_180037A80 is responsible for performing the shellcode injection into the spawned process in the\r\nsuspended state.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 28 of 41\n\nFunction sub_180037A80\r\nAfter injecting the shellcode into the process, the malware resumes the process. It then executes function\r\nsub_18003A9BC to finally inject malicious DLL by creating multiple memory sections and views.\r\nExecuting sub_18003A9BC function to inject malicious DLL\r\nThe DLL code is executed via the NtQueueApcThread API, which is dynamically resolved during the execution.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 29 of 41\n\nDLL code executed via NtQueueApcThread API\r\nC2 Network\r\nCommand and Control Infrastructure, also known as C2 or C\u0026C, is a collection of tools and techniques used to\r\nmaintain contact with a compromised system of devices after the initial access has been gained. The IP address of\r\nthe C2 can be retrieved from the payload code as shown below.\r\nRetrieving the IP address of C2\r\nThe C2 periodically sends out tasks to the agent to be executed on the system. The malware extensively uses WMI\r\n(Windows Management Infrastructure) to collect basic victim information like domain name and user name, and\r\nsends the compromised information to the C2. The C2 distinguishes active agents based on the client ID assigned\r\nto each one.\r\nData transferred in C2 communication\r\nInterestingly, the user agent string used by the malware for communication is “bumblebee”.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 30 of 41\n\nOutbound Traffic\r\nData transferred out of the compromised system\r\nClient Parameters\r\nclient-id\r\ngroup_name\r\nsys_version\r\nUser name\r\nclient_version\r\nInbound Traffic\r\nCommands received by the compromised system\r\nClient Parameters\r\nresponse_status\r\ntasks\r\nCommands Supported\r\nThe task field in the C2 response will contain one of the following commands:\r\nCommand Description\r\ndex Downloads executable\r\nsdl Kill Loader\r\nins Persistence\r\ndij DLL inject\r\nA Tale of Bundled DLLs and Hooks\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 31 of 41\n\nThe core payload comes with two DLLs embedded in the binary. The purpose and function of both the DLLs are\r\nthe same, but one is 32 bit and the other is 64 bit. These are used to perform further hooking and control flow\r\nmanipulations.\r\nDLL Signatures (SHA256)\r\n32 bit: B9534DDEA8B672CF2E4F4ABD373F5730C7A28FE2DD5D56E009F6E5819E9E9615\r\n64 bit: 1333CC4210483E7597B26042B8FF7972FD17C23488A06AD393325FE2E098671B\r\nIn this section we will look into the inner workings of embedded 32 bit DLL. The module looks for a specific set\r\nof functions in ntdll.dll, kernel32.dll, kernelbase.dll, and advapi32.dll to later remove any hooks present in the\r\ncode. This will also remove any EDR/AV (Endpoint Detection and Response/ Antivirus) implemented hooks used\r\nfor monitoring.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 32 of 41\n\nFunctions in ntdll.dll checked for existing hooks\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 33 of 41\n\nFunctions in kernel32.dll checked for existing hooks\r\nIn kernelbase32.dll following functions are checked for any already existing hooks:\r\nFunctions in kernelbase32.dll checked for existing hooks\r\nFunctions in advapi32.dll checked for existing hooks\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 34 of 41\n\nThe Unhooking Mechanism\r\nThe unhooking process involves the following steps:\r\nThe module retrieves handles to target DLLs via the GetModuleHandleW API. The handle returned by the\r\nAPI is for the DLL loaded in the memory by the malware process, i.e. the process responsible for executing\r\nthe bumble loader, which is rundll32.exe.\r\nThen the malware constructs the absolute path for target DLLs via the LetSystemDirectoryA API, to access\r\nthe system32 directory, where all system DLLs are located.\r\nA pointer to NtProtectVirtualMemory is computed following the DLL path generation.\r\nFunction sub_10005B90 is called to do the unhooking. Parameters passed to the function are:\r\nFirst Arg: Absolute path to target DLL\r\nSecond Arg: Handle to already loaded target DLL\r\nThird Arg: Offset to array holding target functions exported by the target DLL\r\nFourth Arg: Null\r\nFifth Arg: Pointer to NtProtectVirtualMemory\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 35 of 41\n\nSteps for Unhooking Mechanism\r\nFunction sub_10005B90 performs the following operations:\r\nMaps fresh copy of the target DLL from the hard disk to address space of the malware process via\r\nfunctions CreateFileA, CreateFileMappingA, and MapViewOfFile.\r\nCalls function sub_10005D40 to perform unhooking. The following data is passed to the function:\r\nFirst Arg: Mapped Address of fresh copy of DLL\r\nSecond Arg: Same as sub_10005B90\r\nThird Arg: Same as sub_10005B90\r\nFourth Arg: Same as sub_10005B90\r\nFifth Arg: Same as sub_10005B90\r\nAfter unhooking, the mapped view is released via the UnMapViewOfFile API.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 36 of 41\n\nOperations performed by function sub_10005B90\r\nThe logic used for unhooking is straightforward. The malware compares the target function in the loaded module\r\nin memory against the function defined in the mapped module via MapViewOfFile. If both the codes don’t match,\r\nthe content from the mapped module is written to the loaded module, to restore the state to that of the mapped\r\nversion from the hard disk.\r\nThe malware goes through the exports of the loaded DLL and performs a string match against the set of function\r\nnames stored as an array in a loop. The sub_10005930 is responsible for string matching.\r\nString match against the set of function names\r\nWhen the function name in the array of the malware matches the exported function from the loaded module, the\r\nflag is set to [v8] and breaks from the loop. This occurs in the following steps:\r\nThe malware stores the addresses of functions from both modules(loaded and mapped).\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 37 of 41\n\nThen the loaded and mapped function codes are checked for hooks, by identifying dissimilarities in the\r\ncode. If the loaded code is the same as the mapped one, it breaks from the loop and continues to iterate\r\nthrough the remaining functions.\r\nMalware matches the exported function\r\nIf the loaded code is not the as same as the mapped code, then the following operations are performed by the\r\nmalware for unhooking:\r\nVirtualQueryEx API is called to retrieve the base address of the page containing the target function.\r\nThen NtProtectVirtualMemory API is used for changing permissions of the page containing the function\r\ncode (READ_WRITE_EXECUTE).\r\nVirtualQuery is used again to check for permission; whether the page is writable or not.\r\nFunction sub_10005890 is called to restore the loaded module with the contents of the mapped module.\r\nNow the functions in the mapped and loaded modules are in the same state.\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 38 of 41\n\nMalware does not match the exported function\r\nAfter clearing all the hooks in the selected functions, the malware installs hooks.\r\nFunctions RaiseFailFastException from kernel32.dll and api-ms-win-core-errorhandling-l1-1-2.dll are hooked.\r\nThen the detour function sub_100057F0 hijacks the control flow when the above functions are called by the\r\nsystem after hooking is done by the malware.\r\nInstalling hooks\r\nFunction sub_100057F0 simply returns the call.\r\nFunction sub_100057F0\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 39 of 41\n\nThe embedded DLL has a hooking strategy similar to that of the Bumblebee loader. Various functions used by the\r\nsystem, while loading a DLL module, are hooked and wups.dll is loaded to trigger the chain.\r\nHooking of the functions used while loading DLL and loading of wups.dll\r\nTarget API Detour Function\r\nZwMapViewOfSection sub_10004C50\r\nZwOpenSection sub_10004FF0\r\nZwCreateSection sub_10004BC0\r\nZwOpenFile sub_10004F20\r\nCode Upgrades In The Wild\r\nAfter analyzing many samples in the wild we observed code modifications in the loader.\r\nProminent code modifications done in Bumblebee loader ever since its discovery\r\nThe extreme left sample in the image above is the one we have covered in this report. As we can see from the\r\nlogic flow of the loader, the malware developer has modified the loader code in the other two samples. All the\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 40 of 41\n\nsamples observed in the wild are 64 bit DLL modules with an exported function that has a randomly generated\r\nstring as the function name. This can be justified by the fact that code plays a major role in whether the malware is\r\ndetected by security products. To circumvent this hurdle, malware developers make changes to the code and the\r\nmalware design.\r\nNewer loader samples in the wild contain various payloads, such as cobaltStrike beacons and Meterpreter shells,\r\nunlike the custom bumblebee payload seen in the first generation.\r\nIndicators of Compromise (IoCs)\r\nBinary\r\nf98898df74fb2b2fad3a2ea2907086397b36ae496ef3f4454bf6b7125fc103b8\r\nIPv4\r\n45.147.229.23:443\r\nSource: https://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nhttps://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/\r\nPage 41 of 41",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://cloudsek.com/technical-analysis-of-bumblebee-malware-loader/"
	],
	"report_names": [
		"technical-analysis-of-bumblebee-malware-loader"
	],
	"threat_actors": [
		{
			"id": "62585174-b1f8-47b1-9165-19b594160b01",
			"created_at": "2023-01-06T13:46:39.369991Z",
			"updated_at": "2026-04-10T02:00:03.304964Z",
			"deleted_at": null,
			"main_name": "TA578",
			"aliases": [],
			"source_name": "MISPGALAXY:TA578",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "52eb5fb6-706b-49c0-9ba5-43bea03940d0",
			"created_at": "2024-11-01T02:00:52.694476Z",
			"updated_at": "2026-04-10T02:00:05.410572Z",
			"deleted_at": null,
			"main_name": "TA578",
			"aliases": [
				"TA578"
			],
			"source_name": "MITRE:TA578",
			"tools": [
				"Latrodectus",
				"IcedID"
			],
			"source_id": "MITRE",
			"reports": null
		}
	],
	"ts_created_at": 1775434748,
	"ts_updated_at": 1775791837,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/b6fd8a2292611991eade47bb11001d05b7087630.pdf",
		"text": "https://archive.orkl.eu/b6fd8a2292611991eade47bb11001d05b7087630.txt",
		"img": "https://archive.orkl.eu/b6fd8a2292611991eade47bb11001d05b7087630.jpg"
	}
}