# Hancitor ## Initial Triage *** SHA256 Hash - `8ff43b6ddf6243bd5ee073f9987920fa223809f589d151d7e438fd8cc08ce292` File Type - `Dll` #### Initial Triage Using Cutter -

* The Dll is written in C and has four library imports - * kernel32.dll * user32.dll * gdi32.dll * mpr.dll * The low number of library imports suggests that this file is most definitely packed. But before performing any unpacking, we need to confirm if this file is malicious or not. We can do this using Virus Total. * The virus total result comes out as positive. So this Dll is definitely malicious and by the looks of it, seems to come from Hancitor family.

* Now that we know that this DLL is malicious, we can start static analysis on it. This can be done using `FLOSS.exe`.

* Some interesting strings from the string dump are - {% code overflow="wrap" %} ``` extern "C" short unsigned volatile std::nullptr_t std::nullptr_t // The above basically confirms that the DLL was written in C and contains volatile constants Sunday Monday Tuesday Wednesday Thursday Friday Saturday January February August September October November December MM/dd/yy dddd, MMMM dd, yyyy HH:mm:ss // These suggest that the malware performs some check on the day, Month and time of execution. AreFileApisANSI CompareStringEx EnumSystemLocalesEx FlsAlloc FlsFree FlsGetValue FlsSetValue GetActiveWindow GetCurrentPackageId GetDateFormatEx GetEnabledXStateFeatures GetFileInformationByHandleEx GetLastActivePopup GetLocaleInfoEx GetProcessWindowStation GetSystemTimePreciseAsFileTime GetTimeFormatEx GetUserDefaultLocaleName GetUserObjectInformationW GetXStateFeaturesMask InitializeCriticalSectionEx IsValidLocaleName LCMapStringEx LCIDToLocaleName LocaleNameToLCID LocateXStateFeature MessageBoxA MessageBoxW RoInitialize RoUninitialize SetThreadStackGuarantee //These are the WinAPIs used in the malware. ``` {% endcode %} ## Unpacking *** * Let's look at the malware in PE-Bear now to get some more information.

* We can see that the malware only has 4 imports in the Import Address Table (IAT) and the imports aren't related to networking or cryptography. So, the DLL is most likely packed. Below are the exported functions of the DLL.

* Using **pestudio** tool, we can see that there is a difference between the raw-size and the virtual size of the `.data` section of the DLL. So this confirms our suspicion that the DLL malware is packed.

* Now that we know that the DLL is a packed malware, we can use **x32DBG** to unpack it and analyze the contents underneath. * The malware has five exported functions and without further static analysis, it's difficult to know what they do. Thus we can go one by one to figure out what they do. Let's start with the first one - "Callrun". * When the execution is stopped at the start of execution (INT3 OPCODE), set up breakpoints (ctrl + G to search the function up and after it comes up, click on the small dot on the left of the assembly instruction) on * VirtualAlloc * VirtualProtect * ResumeThread * WriteProcessMemory

* These are some classical WinAPIs that are used in unpacking process. Now run the program (F9) until it hits the first breakpoint (VirtualAlloc). Now `Right click on the EAX register and follow it in Dump 1`. You can see the memory contents of the adress being pointed to by EAX.

* As you can see, the memory dump starts with a magic byte "MZ" which denotes that it is a Windows PE program. But this isn't what we need right now. Now Click on Execute till Return (CTRL+F9) to see what the VirtualAlloc function allocates. To see what the function returns, repeat the same process of `right-clicking on the EAX register -> Follow in Dump`. This memory dump will soon get filled when the next VirtualAlloc function runs (run the program until it hits the breakpoint at the VirtualAlloc function again).

At the Return Point of First VirtualAlloc

* This memory data is still gibberish to us. So we need to repeat the same process again and again while visualizing the return data in different dumps to make sense of this gibberish data. > If the malware is unpacking very slowly, you can Singleshot the memory dumps. In order to do that, go to the dump that is going to be written on by the next VirtualAlloc function call, select the first four hex bytes, `right click → Breakpoint → Memory, Write → Singleshot`**.** This helps in cases where malware takes a long time to write on that region

That address gets written on by the third calling of the VirtualAlloc function

Which gets overwritten by the time VirtualProtect is called

* In this specific strain of Hancitor, it took three VirtualAlloc calls to fully place the unpacked malware in memory. It can vary depending on the strain of Hancitor. In the above picture, at the start of Dump 3, we can see the ASCII characters "**M8Z**". Just like the magic bytes of Windows PEs, "**M8Z**" is the magic byte of **PLib Compression.** We can dump this whole region by `right-clicking on the bytes and choosing "Follow in Memory Map"`.

* On the gray highlighted base address, `right-click -> Dump Memory to File` to save the memory region of the unpacked malware. Keep the debugger open for now. Open the saved file in **XVI Editor**. This is essential to fix the IAT of the dumped malware. Now in XVI editor, search for the text string - "DOS".

* Once you found it, look for the PE magic bytes "MZ" 2-3 lines above. Click on the byte just before it and go to `Edit → Delete to cursor`. This will align the packed malware's PE headers.

* Save the hex data to disk and open it in Pe-Bear to see the imports. We can now see all the imports of the malware.

* By the looks of it, the malware potentially uses "WININET.dll" for some kind of network communication. To know which kind of network communication, we need to further analyze the malware in a disassembler. I will be using Binary Ninja and Ghidra for the task. You can close the debugger for now. ## Static Analysis ***

* We can start analyzing the malware by looking at the exported functions. You can see the exported functions of the dll below as seen in Ghidra.

* There are 2 exported functions - * entry * MVELLJHNDSVBJLD (I renamed it to **MAL\_MAIN** later) * The **entry** (or the **DllEntryPoint**) function supposedly only returns the value 1 and exits. So it's not useful for us.

The other function - MAL\_MAIN seems interesting though. It supposedly compares a data variable "MainCompareWithValue0" with the value "0x0". If they are not equal, then the function returns. Else, it calls "FirstFunctionCalledFromMain" and sets the variable to "1". > All function and variable names are renamed for brevity. The full reverse source code is available [here](https://github.com/Swayampadhy/Hancitor).

* The "FirstFunctionCalledFromMain" function does the following - * Create a GUID for the victim * Initialize C2 communication and send victim information to C2 * Download and inject shellcode as - * Remote injection * Self Injection * Launching Shellcode * Download file to temp directory

#### Creating A GUID For The Victim * In order to distinguish the victim computer from others, Hancitor creates a unique GUID (Global Unique Identifier) for the machine. This is done by concatenating various unique values from the victim system. * First Hancitor uses `GetAdapterAddresses` winapi to get the MAC (Media Access Control) addresses of all the network adapters on the pc. Then it XORs all the addresses together to get a final 48-bit value.

* After this, Hancitor extracts the machine volume serial number using `GetVolumeInformationA` and XORs it with the above final MAC value.

* Next, this malware also gets the machine information by calling `GetComputerNameA` . Hancitor also finds the username of the logged-in user by searching for the PID of "explorer.exe", extracting the user SID (Security Identifier) from the process token using `OpenProcessToken` and `GetTokenInformation`, and looking that SID up through `LookupAccountSidA` winapi.

* Finally the machine info is formatted as - ``` Machine_name @ Domain_Name \ User_name ``` * In order to get the public-facing IPV4 address of the victim machine, Hancitor requests a GET request to `hxxp://api[.]ipify[.]org`**.** In case it's unable to get a response, Hancitor uses `0.0.0.0` as the IPV4 address.

* This GET request function is also later used to download shellcode from the C2. * The domain shares and NETBIOS names are extracted using `DsEnumerateDomainTrustsA` Winapi.

* Finally before sending the values back to the C2, Hancitor encrypts them using RC4 and formats them as below - {% code overflow="wrap" %} ``` GUID=&BUILD=&INFO=&EXT=&IP=&TYPE=1&WIN=.(x64) GUID=&BUILD=&INFO=&EXT=&IP=&TYPE=1&WIN=.(x32) ``` {% endcode %}

#### Initialize C2 communication and send victim information to C2 * After the victim data is completed and encrypted, the malware runs an infinite loop to communicate with the C2 server. To send information to the server, Hancitor uses POST HTTP requests. The code is the same as that of downloading the shellcode.

* As the C2 servers are long down, we can't do a PCAP analysis of the communications but looking at the code, the C2 sends a BASE64 string to hancitor. Hancitor checks the first 4 bytes of the response to verify if the response is from the C2 server.

* After the check, the result is decoded using Base64 and accepted. The C2 response contains a CLI argument which is tokenized (using a custom implementation of strtok C++ function) and checked to determine which type of payload execution method is to be used.

* Here are the possible commands given to Hancitor - * `b` - Download and remote injection of shellcode * `e` - Download and self injection of shellcode * `l` - Download shellcode and use Svchost to launch it * `r` - Download Shellcode in temp folder and execute it * `n` - Do Nothing

#### Download And Remote Injection Of Shellcode * Hancitor downloads the file from the URL in the response and performs remote reflective PE injection to execute it.

* The malware first parses the response using pipes as delimiters and downloads the file contents. After receiving them, Hancitor validates the UNC path and goes forward with the payload processing. After processing, it checks the magic byte of the processed payload to check if it is a "MZ" (Windows PE) or not.

* In order to process the payload, the malware decrypts it using a XOR cipher with its first 8 bytes as the key. Next, it calls **RtlDecompressBuffer** to perform LZ decompression to decompress the final executable.

* Next up, it performs reflective PE injection by injecting the downloaded payload into a `svchost.exe` process.

* How the reflective injection works is, first a suspended `svchost.exe` process is created for the payload to be injected in. That is done by getting the SystemRoot variable (C drive) using `GetEnvironmentVariableA` winapi, adding "\System32\svchost.exe" to it and creating it is suspended mode using `CreateProcessA`.

* Next, Hancitor uses `VirtualAllocEx` to create a buffer in target memory for the injection. The Payload is copied to a heap buffer created using HeapAlloc and mapped to it through relocating it's PE base. Finally `WriteProcessMemory` is used to write the payload from the heap to **svchost’s** allocated memory.

* Now that the payload is set to the suspended "svchost.exe" process, Hancitor sets up the injected thread’s context by setting the image base address from PEB (through the context’s **EBX** register) to the injected base address and the thread’s entry point (through the context’s **EAX** register) to the injected entry point. Finally the payload is launched by calling `ResumeThread`.

#### Download and self injection of shellcode * When given the `e` command, Hancitor downloads a file from the URL in the response and injects it into its own process.

* After payload download, the malware checks if the download payload is a Windows PE or not. After that, it calls `VirtualAlloc` to allocate a buffer and loads the payload there.

* Now, the malware set's up the IAT for the reflective self injection. This is done by extracting all imported DLL names and calling `GetModuleHandleA` or `LoadLibraryA` to retrieve the DLL’s base. For each imported DLL, the malware manually iterates through its own Import Address Table (IAT) to retrieve the name of each imported function. It calls `GetProcAddress` to get the address of the imported function and updates it in its IAT.

* Lastly, the malware creates a new thread using `CreateThread` and launches the payload in it. #### Download shellcode and use Svchost to launch it * Hancitor downloads the shellcode from the URL in the C2 response and runs it either locally or in svchost.

* This function takes in a parameter to determine whether the shellcode is injected locally or in svchost. The process of injecting to svchost is same as earlier and the shellcode is launched using `CreateRemoteThread` winapi. * Injecting locally works the same as before - memory is allocated using `VirtualAlloc`, shellcode is copied into this buffer and finally executed using `CreateThread`. #### Download Shellcode in temp folder and execute it * Lastly, when `r` is given, Hancitor downloads a file from the URL specified in the response, drops it in the Windows Temp folder, and launches it.

* Hancitor gets the temp folder location using the `GetTempPathA` winapi and `GetTempFileNameA` to generate a temporary file’s name in that path with the prefix of “BN”. * Then it calls `CreateFileA` and `WriteFile` to write the downloaded content to the temporary file.

* After that, the malware checks the `Characteristics` flag in the file header to determine if the payload is a PE or a DLL. If the file is an executable, it's launched by calling `CreateProcessA` with the file’s path as the command line to be executed. * If the file is a DLL, the malware launches it by calling `CreateProcessA` with a formatted `rundll32.exe` command as the command line. * The analysis of Hancitor is now complete. The yara detection rules for this malware are below. ## YARA Rule *** {% code overflow="wrap" %} ```json rule Hancitor_General { meta: description = "Hancitor detection general rule" author = "Swayam Tejas Padhy" date = "2025-10-12" malware_family = "Hancitor" malware_type = "Trojan" severity = "high" strings: // User-Agent string $ua_string = "Mozilla/5.0 (Windows NT 6.1; Win64; x64; Trident/7.0; rv:11.0) like Gecko" ascii // Content-Type header $content_type = "Content-Type: application/x-www-form-urlencoded" ascii // IP service $ipify_url = "http://api.ipify.org" ascii nocase // Beacon parameters $beacon_guid = "GUID=%I64u" ascii $beacon_build = "&BUILD=" ascii $beacon_info = "&INFO=" ascii $beacon_ext = "&EXT=" ascii $beacon_ip = "&IP=" ascii $beacon_type = "&TYPE=1" ascii $beacon_win_x64 = "&WIN=%d.%d(x64)" ascii $beacon_win_x32 = "&WIN=%d.%d(x32)" ascii // Command validation $cmd_valid = "ncdrleb" ascii // Rundll32 execution $rundll_pattern = "Rundll32.exe %s, start" ascii // System path construction $svchost_path = "\\System32\\svchost.exe" ascii // Compression marker $compression_marker = { 80 A8 15 54 } // XOR deobfuscation $xor_key = { 7A } // Base64 $base64_alphabet = "ABCDEFGHIJKLMNOPQRSTUVWXYZabcdefghijklmnopqrstuvwxyz0123456789+/" ascii // Windows API imports $api_1 = "GetAdaptersAddresses" ascii $api_2 = "DsEnumerateDomainTrustsA" ascii $api_3 = "K32GetProcessImageFileNameA" ascii $api_4 = "RtlDecompressBuffer" ascii $api_5 = "CryptDeriveKey" ascii // Process creation $create_suspended = { 00 00 00 04 } // CREATE_SUSPENDED flag // Pipe delimiter $pipe_delim_check = { 7C 00 } // pipe character check // Stack strings $explorer_exe = "explorer.exe" ascii $temp_prefix = "tmp" ascii wide // Registry and mutexs $systemroot = "SystemRoot" ascii // Thread context manipulation $context_integer = { 00 00 01 00 } // CONTEXT_INTEGER // RC4 algorithm $rc4_algid = { 01 68 00 00 } // CALG_RC4 = 0x6801 // SHA1 algorithm $sha1_algid = { 03 80 00 00 } // CALG_SHA1 = 0x8003 // LZNT1 compression $lznt1_format = { 02 00 } // Compression format 2 // HTTPS $sec_flag_ignore_ca = { 00 00 01 00 } // SECURITY_FLAG_IGNORE_UNKNOWN_CA // VirtualAlloc $page_exec_readwrite = { 40 00 00 00 } // PAGE_EXECUTE_READWRITE // Dynamic resolution $getprocaddr = "GetProcAddress" ascii $loadlibrary = "LoadLibraryA" ascii // HTTP methods $http_get = "GET" ascii fullword $http_post = "POST" ascii fullword // WinINet flags $internet_open_type = { 01 00 00 00 } // INTERNET_OPEN_TYPE_PRECONFIG condition: uint16(0) == 0x5A4D and // MZ header filesize < 5MB and ( // Core C2 communication ( $ua_string and $content_type and ($beacon_guid or $beacon_build) and 2 of ($beacon_*) ) or // Fingerprinting ( $ipify_url and $api_1 and ($explorer_exe or $systemroot) ) or // Payload execution ( $rundll_pattern and $svchost_path and $create_suspended and $page_exec_readwrite ) or // Cryptographic operations ( $base64_alphabet and $xor_key and ($rc4_algid or $sha1_algid) and $api_5 ) or // Combination ( 3 of ($api_*) and $compression_marker and $cmd_valid and 2 of ($http_*) ) or // Decompression and obfuscation ( $api_4 and $lznt1_format and $compression_marker and $base64_alphabet ) ) and // API imports ( 3 of ($api_*) or ( $getprocaddr and $loadlibrary and 2 of ($beacon_*) ) ) } rule Hancitor_Definitive { meta: description = "Patterns which are definitively Hancitor" author = "Swayam Tejas Padhy" reference = "Hancitor beacon" date = "2025-10-12" severity = "critical" strings: $beacon_format_1 = "GUID=%I64u&BUILD=%s&INFO=%s&EXT=%s&IP=%s&TYPE=1&WIN=%d.%d(x64)" ascii $beacon_format_2 = "GUID=%I64u&BUILD=%s&INFO=%s&EXT=%s&IP=%s&TYPE=1&WIN=%d.%d(x32)" ascii $ipify = "http://api.ipify.org" ascii $ua = "Mozilla/5.0 (Windows NT 6.1; Win64; x64; Trident/7.0; rv:11.0) like Gecko" ascii $content_type = "Content-Type: application/x-www-form-urlencoded" ascii $commands = "ncdrleb" ascii condition: uint16(0) == 0x5A4D and filesize < 3MB and ( ($beacon_format_1 or $beacon_format_2) and $ipify and $ua and $content_type and $commands ) } rule Hancitor_Payload_Execution { meta: description = "Hancitor payload execution" author = "Swayam Tejas Padhy" reference = "Hancitor reflective injection analysis" date = "2025-10-12" severity = "high" strings: $svchost = "\\System32\\svchost.exe" ascii $rundll = "Rundll32.exe %s, start" ascii $compression = { 80 A8 15 54 } $proc_api_1 = "CreateProcessA" ascii $proc_api_2 = "WriteProcessMemory" ascii $proc_api_3 = "VirtualAllocEx" ascii $proc_api_4 = "CreateRemoteThread" ascii $proc_api_5 = "GetThreadContext" ascii $proc_api_6 = "SetThreadContext" ascii $temp_prefix = "tmp" ascii condition: uint16(0) == 0x5A4D and filesize < 3MB and $svchost and ( ($rundll and $temp_prefix and $compression) or (4 of ($proc_api_*) and $compression) ) } ``` {% endcode %} ***