{
	"id": "af6ff8be-fd63-4a68-8283-17c478e9a32c",
	"created_at": "2026-04-06T01:31:58.02816Z",
	"updated_at": "2026-04-10T03:20:06.56699Z",
	"deleted_at": null,
	"sha1_hash": "ea4a33e9a7fc4b0ca11643acca0a91ae5c14e7af",
	"title": "BUGHATCH Malware Analysis",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 5256783,
	"plain_text": "BUGHATCH Malware Analysis\r\nBy Salim Bitam\r\nPublished: 2022-09-09 · Archived: 2026-04-06 00:08:10 UTC\r\nKey takeaways\r\nElastic Security Labs is releasing a BUGHATCH malware analysis report from a recent campaign\r\nThis report covers detailed code analysis, network communication protocols, command handling, and\r\nobserved TTPs\r\nFrom this research we produced a YARA rule to detect the BUGHATCH downloader\r\nPreamble\r\nBUGHATCH is an implant of a custom C2 deployed during the CUBA ransomware campaigns we observed in\r\nFebruary of 2022, this tool was most likely built by the threat actor themselves as it was not used previously.\r\nBUGHATCH is capable of downloading and executing commands and arbitrary code, it gives the operator the\r\nfreedom to execute payloads with different techniques like reflection, shellcode execution, system command\r\nexecution, and so on. The samples we have seen were not obfuscated and were deployed using a custom\r\nobfuscated in-memory dropper written in PowerShell and referred to as TERMITE by Mandiant.\r\nIn this document, we will go through the execution flow of BUGHATCH highlighting its functionalities and code\r\nexecution techniques, a YARA rule and the MITRE ATT\u0026CK mapping can be found in the appendix.\r\nIn this analysis we will describe the following:\r\nToken adjustment\r\nInformation collection\r\nThreading and thread synchronization\r\nNetwork communication protocol\r\nCommand handling\r\nFor information on the CUBA ransomware campaign and associated malware analysis, check out our\r\nblog posts detailing this:\r\nCUBA Ransomware Campaign\r\nCUBA Malware Analysis\r\nStatic analysis\r\n| | | | ------------ | ---------------------------------------------------------------- | --- | | SHA256 |\r\nF1325F8A55164E904A4B183186F44F815693A008A9445D2606215A232658C3CF | | File Size | 35840 bytes | |\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 1 of 28\n\nFile Type: | Win32 executable | | Signed? | No | | Packer? | No | | Compiler | Visual Studio 2017 - 15.5.0 preview 2 |\r\n| Compile Time | Sun Feb 06 21:05:18 2022 | UTC | | Entropy | 6.109 |\r\nSections\r\nName VirtualAddress\r\nVirtual\r\nSize\r\nRaw\r\nSize\r\nEntropy MD5\r\n.text 0x1000 0x6000 0x5400 5.933 A6E30CCF838569781703C943F18DC3F5\r\n.rdata 0x7000 0x3000 0x2A00 6.217 9D9AD1251943ECACE81644A7AC320B3C\r\n.data 0xA000 0x1000 0x400 1.163 B983B8EB258220628BE2A88CA44286B4\r\n.reloc 0xB000 0x424 0x600 5.235 39324A58D79FC5B8910CBD9AFBF1A6CB\r\nCode analysis\r\nBUGHATCH is an in-memory implant loaded by an obfuscated PowerShell script that decodes and executes an\r\nembedded shellcode blob in its allocated memory space using common Windows APIs ( VirtualAlloc ,\r\nCreateThread, WaitForSingleObject ).\r\nThe PowerShell loader uses inline C# to load APIs needed for shellcode injection as seen in the following\r\npseudocode.\r\nPseudocode PowerShell inline C#\r\nThe PowerShell script is obfuscated with random functions and variable names and contains the shellcode in a\r\nreverse-Base64 format.\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 2 of 28\n\nPseudocode embedded shellcode in Base64 format\r\nThe script first decodes the reverse-Base64 encoded data, then allocates a memory region with VirtualAlloc\r\nbefore copying the shellcode into it. Finally, the script executes the shellcode by creating a new thread with the\r\nCreateThread API.\r\nPseudocode PowerShell creates a new thread to execute the shellcode\r\nThe shellcode downloads another shellcode blob and the encrypted PE implant from the C2 server, this second\r\nshellcode decrypts and reflectively loads the PE malware.\r\nThis section dives deeper into the BUGHATCH execution flow, threading and encryption implementation,\r\ncommunication protocol with C2, and finally supported commands and payload execution techniques\r\nimplemented.\r\nThe following is a diagram summarizing the execution flow of the implant:\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 3 of 28\n\nExecution flow diagram of BUGHATCH\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 4 of 28\n\nPseudocode of the main function\r\nToken adjustment\r\nThe implant starts by elevating permissions using the SeDebugPrivilege method, enabling the malware to access\r\nand read the memory of other processes. It leverages common Windows APIs to achieve this as shown in the\r\npseudocode below:\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 5 of 28\n\nInformation collection\r\nThe malware collects host-based information used to fingerprint the infected system, this information will be\r\nstored in a custom structure that will be 2-byte XOR encrypted and sent to the C2 server in an HTTP POST\r\nrequest.\r\nThe following lists the collected information:\r\nCurrent value of the performance counter\r\nNetwork information\r\nSystem information\r\nToken information\r\nDomain and Username of the current process\r\nCurrent process path\r\nCurrent value of the performance counter\r\nUsing the QueryPerformanceCounter API, it collects the amount of time since the system was last booted. This\r\nvalue will be used to compute the 2-byte XOR encryption key to encrypt communications between the implant\r\nand the C2 server, a detailed analysis of the encryption implementation will follow.\r\nPseudocode QueryPerformanceCounter function\r\nNetwork information\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 6 of 28\n\nIt collects the addresses of network interfaces connected to the infected machine by using the GetIpAddrTable\r\nWindows API.\r\nPseudocode collecting interface addresses\r\nSystem information\r\nBUGHATCH collects key system information which includes:\r\nWindows major release, minor release, and build number\r\nProcessor architecture (either 32-bit or 64-bit)\r\nComputer name\r\nPseudocode collecting system information\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 7 of 28\n\nToken information\r\nThe agent proceeds to collect the current process token group membership, it invokes the\r\nAllocateAndInitializeSid API followed by the CheckTokenMembership API, concatenating the SDDL SID\r\nstrings for every group the process token is part of. While not unique to BUGHATCH, this is detected by Elastic's\r\nEnumeration of Privileged Local Groups Membership detection rule.\r\nPseudocode collecting token group membership information\r\nDomain and username of the current process\r\nThe malware opens a handle to the current process with OpenProcessToken and gets the structure that contains\r\nthe user account of the token with GetTokenInformation. It then retrieves the username and domain of the user\r\naccount with the LookupAccountSidW API and concatenates the 2 strings in the following format:\r\nDOMAIN\\USERNAME.\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 8 of 28\n\nCurrent process path\r\nFinally, it collects the current process path with GetModuleFileNameW. The malware then encrypts the entire\r\npopulated structure with a simple 2-byte XOR algorithm, this encryption implementation is detailed later in the\r\nreport.\r\nThreading and thread synchronization\r\nThe implant is multithreaded; it uses two different linked lists, one is filled with the commands received from the\r\nC2 server and the other is filled with the output of the commands executed.\r\nIt spawns 5 worker threads, each handling a command received from the C2 server by accessing the appropriate\r\nlinked list using the CriticalSection object. The main process’ thread also retrieves the command's output from\r\nthe second linked list using the CriticalSection object for synchronization purposes, to avoid any race conditions.\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 9 of 28\n\nPseudocode of the thread creation function\r\nNetwork communication protocol\r\nIn this section we will detail:\r\nBase communication protocol\r\nEncryption implementation\r\nThe implant we analyzed uses HTTP(S) for communications. On top of the SSL encryption of the protocol, the\r\nmalware and C2 encrypt the data with a 2-byte XOR key computed by the malware for each new session. The\r\nvalues to compute the 2-byte XOR key are prepended at the beginning of the base protocol packet which the\r\nserver extracts to decrypt/encrypt commands.\r\nWhen launched, the malware will first send an HTTP POST request to the C2 server containing all the collected\r\ninformation extracted from the victim’s machine, the C2 then responds with the operator’s command if available,\r\nor else the agent sleeps for 60 seconds. After executing the command and only if the output of the executed\r\ncommand is available, the malware will send a POST request containing both the collected information and the\r\ncommand’s output, otherwise, it sends the collected information and waits for new commands.\r\nExample of an implant HTTP POST request to an emulated C2 server\r\nBase communication protocol\r\nThe author(s) of BUGHATCH implemented a custom network protocol, the following is the syntax that the agent\r\nand server use for their communication:\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 10 of 28\n\nBUGHATCH agent and server communications\r\nXOR key values: The values to compute the 2-byte XOR encryption key used to encrypt the rest of the\r\ndata\r\nSeparator: A static value ( 0x389D3AB7 ) that separates Msg chunks, example: the server can send\r\ndifferent instructions in the same HTTP request separated by the Separator\r\nChunk length: Is the length of the Msg , Separator and Chunk length\r\nMsg: Is the message to be sent, the message differs from the agent to the server.\r\nWe will dive deeper into the encapsulation of the Msg for both the agent and the server.\r\nPseudocode extracting commands according to the separator value\r\nEncryption implementation\r\nThe malware uses 2-byte XOR encryption when communicating with the C\u0026C server; a 2-byte XOR key is\r\ngenerated and computed by the implant for every session with the C2 server.\r\nThe agent uses two DWORD values returned by QueryPerformanceCounter API as stated earlier, it then\r\ncomputes a 2-byte XOR key by XOR-encoding the DWORD values and then multiplying and adding hardcoded\r\nvalues. The following is a Python pseudocode of how the KEY is computed:\r\ntmp = (PerformanceCount[0] ^ PerformanceCount[1]) \u0026 0xFFFFFFFF\r\nXorKey = (0x343FD * tmp + 0x269EC3)\u0026 0xFFFFFFFF\r\nXorKey = p16(XorKey \u003e\u003e 16).ljust(2, b'\\x00')\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 11 of 28\n\nPseudocode of the encryption implementation\r\nCommand handling\r\nIn this section, we will dive deeper into the functionalities implemented in the agent and their respective Msg\r\nstructure that will be encapsulated in the base communication protocol structure as mentioned previously.\r\nOnce the working threads are started, the main thread will continue beaconing to the C2 server to retrieve\r\ncommands. The main loop is made up of the following:\r\nSend POST request\r\nDecrypt the received command and add it to the linked list\r\nSleep for 60 seconds\r\nA working thread will first execute the RemoveEntryRecvLinkedList function that accesses and retrieves the\r\ndata sent by the C2 server from the linked list.\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 12 of 28\n\nPseudocode retrieves data sent by the C2\r\nThe thread will then de-encapsulate the data received from the C2 and extract the Msg(Command). The malware\r\nimplements different functionalities according to a command flag, the table below illustrates the functionalities of\r\neach command:\r\nCommand FLAG Description\r\n1 Group functions related to code and command execution\r\n2 Group functions related to utilities like impersonation and migration\r\n3 Process injection of a PE file in a suspended child process\r\nCommand 1\r\nThis command gives access to functionalities related to payload execution, from DLL to PE executable to\r\nPowerShell and cmd scripts.\r\nSome of the sub-commands use pipes to redirect the standard input/output of the child process, which enables the\r\nattacker to execute payloads and retrieve its output, for example, PowerShell or Mimikatz, etc…\r\nThe following is the list of sub commands:\r\nSub\r\nCommand\r\nFlag\r\nFunction Name Functionality description\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 13 of 28\n\n2 ReflectivelyExecutePERemote\r\nReflectively loads PE files in a child process and redirects\r\nits standard input output, the output will be sent to the\r\noperator C2 server\r\n3 DropPEDiskExecute\r\nDrops a PE file to disk and executes it, the execution\r\noutput is then sent to the operator’s C2 server\r\n4 SelfShellcodeExecute Executes a shellcode in the same process\r\n5 RemoteShellcodeExecute\r\nExecutes a shellcode in a suspended spawned child\r\nprocess\r\n6 ExecuteCmd Executes a CMD script/command\r\n7 ExecutePowershell Executes a Powershell script/command\r\n9 ReflectivelyLoadDllRemote\r\nExecutes a DLL reflectively in a remote process using\r\nCreateRemoteThread API\r\nThe following is the structure that is used by the above commands:\r\nstruct ExecutePayloadCommandStruct\r\n{\r\n DWORD commandFlag;\r\n DWORD field_0;\r\n DWORD subCommandFlag_1;\r\n DWORD readPipeTimeOut_2;\r\n DWORD payloadSize_3;\r\n DWORD commandLineArgumentSize_4;\r\n DWORD STDINDataSize_5;\r\n CHAR payload_cmdline_stdin[n];\r\n};\r\ncommandFlag: Indicates the command\r\nsubCommandFlag: Indicates the subcommand\r\nreadPipeTimeOut: Indicates the timeout for reading the output of child processes from a pipe\r\npayloadSize: Indicates the payload size\r\ncommandLineArgumentSize: Indicates length of the command line arguments when executing the\r\npayload, example a PE binary\r\nSTDINDataSize: Indicates the length of the standard input data that will be sent to the child process\r\nPayload_cmdline_stdin: Can contain the payload PE file for example, its command line arguments and\r\nthe standard input data that will be forwarded to the child process, the malware knows the beginning and\r\nend of each of these using their respective length.\r\nReflectivelyExecutePERemote\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 14 of 28\n\nThe agent reflectively loads PE binaries in the memory space of a created process in a suspended state (either\r\ncmd.exe or svchost.exe ). The agent leverages anonymous (unnamed) pipes within Windows to redirect the\r\ncreated child process's standard input and output handles. It first creates an anonymous pipe that will be used to\r\nretrieve the output of the created process, then the pipe handles are specified in the STARTUPINFO structure of\r\nthe child process.\r\nPseudocode for anonymous pipe creation\r\nAfter creating the suspended process, the malware allocates a large memory block to write shellcode and a XOR\r\nencrypted PE file.\r\nThe shellcode will 2-byte XOR decrypt and load the embedded PE similar to ( Command 3 ). This command can\r\nload 64bit and 32bit binaries, each architecture has its own shellcode PE loader, after injecting the shellcode it will\r\npoint the instruction pointer of the child process’s thread to the shellcode and resume the thread.\r\nPseudocode of Reflective Loading PE into child processes\r\nThe following is an example of a packet captured from our custom emulated C2 server, we can see the structure\r\ndiscussed earlier on the left side and the packet bytes on the right side, for each command implemented in the\r\nmalware, a packet example will be given.\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 15 of 28\n\nExample of a ReflectivelyExecutePERemote command received from an emulated C2\r\nDropPEDiskExecute\r\nWith this subcommand, the operator can drop a PE file on disk and execute it. The agent has 3 different\r\nimplementations depending on the PE file type, GUI Application, CUI (Console Application), or a DLL.\r\nFor CUI binaries, the malware first generates a random path in the temporary folder and writes the PE file to it\r\nusing CreateFileA and WriteFile API.\r\nPseudocode writing payload to disk\r\nIt then creates a process of the dropped binary file as a child process by redirecting its standard input and output\r\nhandles; after execution of the payload the output is sent to the operator’s C2 server.\r\nFor GUI PE binaries, the agent simply writes it to disk and executes it directly with CreateProcessA API.\r\nAnd lastly, for DLL PE files, the malware first writes the DLL to a randomly generated path in the temporary\r\nfolder, then uses c:\\windows\\system32\\rundll32.exe or c:\\windows\\syswow64\\rundll32.exe (depending on the\r\narchitecture of the DLL) to run either an exported function specified by the operator or the function start if no\r\nexport functions were specified.\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 16 of 28\n\nPseudocode running the payload dropped by DropPEDiskExecute function\r\nExample of a SelfShellcodeExecute command received from an emulated C2\r\nSelfShellcodeExecute\r\nThis subcommand tasks the agent to execute shellcode in its own memory space by allocating a memory region\r\nusing VirtualAlloc API and then copying the shellcode to it, the shellcode is executed by creating a thread using\r\nCreateThread API.\r\nPseudocode of SelfShellcodeExecute command\r\nExample of a SelfShellcodeExecute command received from an emulated C2\r\nRemoteShellcodeExecute\r\nThis sub-command can be used to execute a 32-bit or a 64-bit position independent shellcode in another process\r\nmemory space.\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 17 of 28\n\nSimilarly to the SpawnAgent subcommand, the malware creates a suspended svchost.exe process with\r\nCreateProcessA API, allocates a memory region for the shellcode sent by the C2 server with VirtualAllocEx ,\r\nand writes to it with WriteProcessMemory , it then sets the suspended thread instruction pointer to point to the\r\ninjected shellcode with SetThreadContext and finally it will resume the thread with ResumeThread to execute\r\nthe payload.\r\nPseudocode writes shellcode to remote process\r\nPseudocode set EIP of child process using SetThreadContext\r\nExample of a RemoteShellcodeExecute command received from an emulated C2\r\nExecuteCmd and ExecutePowershell\r\nAn operator can execute PowerShell scripts or CMD scripts in the infected machine, the malware can either write\r\nthe script to a file in the temporary folder with a randomly generated name as follow: TEMP\u003cdigits\u003e.PS1 for\r\nPowerShell or TEMP\u003cdigits\u003e.CMD for a Command shell. The malware then passes parameters to it if specified by\r\nthe malicious actor and executes it, the malware uses named pipes to retrieve the output of the PowerShell\r\nprocess.\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 18 of 28\n\nPseudocode of ExecuteCmd command\r\nExample of an ExecutePowershell command received from an emulated C2\r\nReflectivelyLoadDllRemote\r\nExecute reflectively a 32-bit or 64-bit DLL in a process created in a suspended state, the following summarizes the\r\nexecution flow:\r\nCheck if the PE file is a 32 or 64-bit DLL\r\nCreate a suspended svchost.exe process\r\nAllocate memory for the DLL and the parameter for the DLL if specified by the C2 command with the\r\nVirtualAllocEx API\r\nWrite to the remotely allocated memory withthe WriteProcessMemory API the DLL and the parameter if\r\nspecified\r\nCreate a remote thread to execute the injected DLL with the CreateRemoteThread API\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 19 of 28\n\nPseudocode of a ReflectivelyLoadDllRemote command\r\nExample of a ReflectivelyLoadDllRemote command received from an emulated C2\r\nCommand 2\r\nThe command 2 has multiple sub functionalities as shown in the command table above, according to a\r\nsubCommandFlag the malware can do 6 different operations as follows:\r\nSub Command Flag Function Name Functionality description\r\n1 ExitProcess Exit process\r\n2 SelfDeleteExitProcess Self delete and exit process\r\n3 SpawnAgent64 Spawn 64-bit agent\r\n4 SpawnAgent32 Spawn 32-bit agent\r\n0x1001 ImpersonateToken Impersonate explorer\r\n0x1002 MigrateC2 Change C2 config\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 20 of 28\n\nThe following is the structure that is used by the above commands:\r\nstruct ImpersonateReplicateStruct\r\n{\r\n int subCommandFlag;\r\n int impersonateExplorerToken;\r\n char padding[16];\r\n __int16 isParameterSet;\r\n WCHAR w_parameters[n];\r\n};\r\nExitProcess\r\nCalls the ExitProcess(0) API to terminate.\r\nExample of an ExitProcess command received from an emulated C2\r\nSelfDeleteExitProcess\r\nThe agent gets the PATH of the current process with GetModuleFileNameA and then executes the following\r\ncommand to self-delete: cmd.exe /c del FILEPATH \\\u003e\\\u003e NUL using CreateProcessA then simply exit the\r\nprocess with ExitProcess(0).\r\nExample of a SelfDeleteExitProcess command received from an emulated C2\r\nSpawnAgent64 and SpawnAgent32\r\nWhen subcommands 3 or 4 are specified, the malware will spawn another agent on the same machine depending\r\non the subcommand sent by the C2, as shown in the table above.\r\nThe malware first retrieves the C2 IP address embedded in it, it will then do an HTTP GET request to download a\r\npacked agent in shellcode format, in the sample we analyzed /Agent32.bin URI is for the 32-bit agent, and\r\n/Agent64.bin is for 64-bit the agent.\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 21 of 28\n\nPseudocode spawning another agent\r\nThe malware then creates a suspended svchost.exe process with CreateProcessA API, writes the agent shellcode\r\nto the process, sets its instruction pointer to point to the injected shellcode with SetThreadContext , and finally it\r\nwill resume the thread with ResumeThread to execute the injected payload.\r\nExample of a SpawnAgent32 command received from an emulated C2\r\nImpersonateToken\r\nThis subcommand is specific to process tokens; an attacker can either impersonate the explorer.exe token or\r\ncreate a token from credentials (Domain\\Username, Password) sent by the C2 to spawn another instance of the\r\ncurrent process.\r\nPseudocode ImpersonateToken command\r\nIt will first check if the current process is a local system account or local service account or network service\r\naccount by testing whether the given process token is a member of the group with the specified RID (\r\nSECURITY_LOCAL_SYSTEM_RID , SECURITY_LOCAL_SERVICE_RID ,\r\nSECURITY_NETWORK_SERVICE_RID ) respectively.\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 22 of 28\n\nPseudocode check token group membership\r\nThen depending if the operator specified credentials or not, the malware will first call LogonUserW with the\r\nDomain\\User and password to create a token then it will spawn another instance of the current process with this\r\ntoken.\r\nPseudocode LogonUserW to create a token\r\nIf not, the implant will impersonate the explore.exe process by duplicating its token with DuplicateTokenEx and\r\nthen spawn the current process with the duplicated token if no credentials are specified.\r\nExample of an ImpersonateToken command received from an emulated C2\r\nMigrateC2\r\nThe operator can migrate the implant to another C2 server by specifying the subcommand 0x1001 with the IP\r\naddress of the new C2.\r\nPseudocode migrating the implant\r\nExample of a MigrateC2 command received from an emulated C2\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 23 of 28\n\nCommand 3\r\nWhen command 3 is received the malware will reflectively load a PE file embedded as payload in the C\u0026C\r\nrequest in another process's memory space, the following is an overview of the execution:\r\nDetermine the type and architecture of the PE file\r\nCreate a suspended process\r\nAllocate a large memory in the suspended process\r\nWrite a shellcode in the allocated memory that will locate, decrypt and reflectively load the PE file\r\n2-byte XOR encrypt the PE file and append it after the shellcode\r\nSet the EIP context of the suspended process to execute the shellcode\r\nThe shellcode will then reflectively load the PE file\r\nPseudocode for Command 3's main logic\r\nThe agent first parses the PE file received from the C2 server to determine the type and architecture of the PE file.\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 24 of 28\n\nPseudocode determines the PE file architecture\r\nAnd according to this information, a Windows signed executable will be chosen to inject into.\r\nIf the PE file is CUI (Console User Interface), the malware will choose cmd.exe , however, if it is GUI (Graphical\r\nUser Interface) or a DLL PE file it will choose svchost.exe.\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 25 of 28\n\nOptions for malware to inject into\r\nThe malware will then create a suspended process with CreateProcessA API (either cmd.exe or svchost.exe ) and\r\nallocate a large amount of memory with VirtualAllocEx in the created process, it will then copy a position\r\nindependent shellcode stored in the .rdata section to the newly allocated memory that is responsible for locating\r\naccording to a specific tag the appended PE file, decrypt it and reflectively load it in memory.\r\nThen it appends after the shellcode a 12 bytes structure composed of a tag, the size of the PE file, and a 2-byte\r\nXOR key.\r\nIt will then 2-byte XOR encrypt the PE file and append it after the structure, the following is an overview of the\r\nwritten data to the allocated memory:\r\nSHELLCODE TAG PE SIZE 2-byte XOR KEY 2-byte XOR encrypted PE file\r\nPseudocode write shellcode and PE to child process\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 26 of 28\n\nThe agent will then set the thread context with SetThreadContext and point the instruction pointer of the\r\nsuspended process to the shellcode then it will simply resume the execution with ResumeThread.\r\nThe shellcode will first locate the 2-byte XOR encrypted PE file according to the tag value ( 0x80706050 ), it will\r\nthen 2-byte XOR decrypt it and load it reflectively on the same process memory.\r\nObserved adversary tactics and techniques\r\nElastic uses the MITRE ATT\u0026CK framework to document common tactics, techniques, and procedures that\r\nadvanced persistent threats use against enterprise networks.\r\nTactics\r\nTactics represent the why of a technique or sub-technique. It is the adversary’s tactical goal: the reason for\r\nperforming an action.\r\nExecution\r\nCollection\r\nCommand and Control\r\nExfiltration\r\nTechniques / sub techniques\r\nTechniques and Sub techniques represent how an adversary achieves a tactical goal by performing an action.\r\nCommand and Scripting Interpreter: Windows Command Shell\r\nEncrypted Channel: Asymmetric Cryptography\r\nEncrypted Channel: Symmetric Cryptography\r\nExfiltration Over C2 Channel\r\nAutomated Collection\r\nNative API\r\nDetections\r\nDetection rules\r\nThe following detection rule was observed during the analysis of the BUGHATCH sample. This rule is not\r\nexclusive to BUGHATCH activity.\r\nEnumeration of Privileged Local Groups Membership\r\nYARA rule\r\nElastic Security has created a YARA rule to identify this activity.\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 27 of 28\n\nrule Windows_Trojan_BUGHATCH {\r\n meta:\r\n author = “Elastic Security”\r\n creation_date = \"2022-05-09\"\r\n last_modified = \"2022-06-09\"\r\n license = “Elastic License v2”\r\n os = \"Windows\"\r\n arch = \"x86\"\r\n category_type = \"Trojan\"\r\n family = \"BUGHATCH\"\r\n threat_name = \"Windows.Trojan.BUGHATCH\"\r\n reference_sample = \"b495456a2239f3ba48e43ef295d6c00066473d6a7991051e1705a48746e8051f\"\r\n strings:\r\n $a1 = { 8B 45 ?? 33 D2 B9 A7 00 00 00 F7 F1 85 D2 75 ?? B8 01 00 00 00 EB 33 C0 }\r\n $a2 = { 8B 45 ?? 0F B7 48 04 81 F9 64 86 00 00 75 3B 8B 55 ?? 0F B7 42 16 25 00 20 00 00 ?? ?? B8 06 00 00 0\r\n $a3 = { 69 4D 10 FD 43 03 00 81 C1 C3 9E 26 00 89 4D 10 8B 55 FC 8B 45 F8 0F B7 0C 50 8B 55 10 C1 EA 10 81 E\r\n $c1 = \"-windowstyle hidden -executionpolicy bypass -file\"\r\n $c2 = \"C:\\\\Windows\\\\SysWOW64\\\\WindowsPowerShell\\\\v1.0\\\\powershell.exe\"\r\n $c3 = \"ReflectiveLoader\"\r\n $c4 = \"\\\\Sysnative\\\\\"\r\n $c5 = \"TEMP%u.CMD\"\r\n $c6 = \"TEMP%u.PS1\"\r\n $c7 = \"\\\\TEMP%d.%s\"\r\n $c8 = \"NtSetContextThread\"\r\n $c9 = \"NtResumeThread\"\r\n condition:\r\n any of ($a*) or 6 of ($c*)\r\n}\r\nSource: https://www.elastic.co/security-labs/bughatch-malware-analysis\r\nhttps://www.elastic.co/security-labs/bughatch-malware-analysis\r\nPage 28 of 28\n\ncomputes a 2-byte values. The following XOR key by XOR-encoding is a Python pseudocode the of how DWORD values the KEY is and then multiplying computed: and adding hardcoded\ntmp = (PerformanceCount[0] ^ PerformanceCount[1])  \u0026 0xFFFFFFFF\nXorKey = (0x343FD * tmp + 0x269EC3)\u0026 0xFFFFFFFF \nXorKey = p16(XorKey \u003e\u003e 16).ljust(2, b'\\x00') \n   Page 11 of 28",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"references": [
		"https://www.elastic.co/security-labs/bughatch-malware-analysis"
	],
	"report_names": [
		"bughatch-malware-analysis"
	],
	"threat_actors": [],
	"ts_created_at": 1775439118,
	"ts_updated_at": 1775791206,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/ea4a33e9a7fc4b0ca11643acca0a91ae5c14e7af.pdf",
		"text": "https://archive.orkl.eu/ea4a33e9a7fc4b0ca11643acca0a91ae5c14e7af.txt",
		"img": "https://archive.orkl.eu/ea4a33e9a7fc4b0ca11643acca0a91ae5c14e7af.jpg"
	}
}