{
	"id": "79eac668-3e76-482c-ab48-e9fc30e4b119",
	"created_at": "2026-04-06T00:16:11.25358Z",
	"updated_at": "2026-04-10T13:11:20.393732Z",
	"deleted_at": null,
	"sha1_hash": "c57c89f6a7240153bb2bef0f9c0f70aef8d4623a",
	"title": "Gh0stBins, Chinese RAT: Malware Analysis, Protocol Description, RDP Stream Recovery",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 114748,
	"plain_text": "Gh0stBins, Chinese RAT: Malware Analysis, Protocol Description, RDP\r\nStream Recovery\r\nBy Electron, Jane and kinoshi\r\nPublished: 2023-06-22 · Archived: 2026-04-05 23:05:22 UTC\r\n[10:48] Ivan Skladchikov Electron is a malware analyst at ANY.RUN \r\nElectron\r\nI'm a malware analyst. I love CTF, reversing, and pwn. Off-screen, I enjoy the simplicity of biking, walking, and hiking.\r\nANY.RUN writer and network traffic analyst\r\nJane\r\nI'm ANY.RUN ambassador and a real network traffic numismatist. I also love penguins and tortoises. My motto is to do\r\ngood and throw it into the sea.\r\nANY.RUN writer\r\nkinoshi\r\nI'm a dedicated programmer and malware analyst. I derive immense joy from the art of coding and have a deep passion for\r\nboth low-level and system-level programming. I thoroughly enjoy delving into the intricacies of software and exploring how\r\nit operates at a fundamental level. My expertise extends to solving crackme challenges and participating in online CTF\r\ncompetitions, where I tackle complex tasks to enhance my skills.\r\nIt’s not every day that you come across a DLL so new that even VirusTotal draws a blank. But it’s even rarer when this\r\nsample turns out to be a sophisticated RAT from China. \r\nBut this is exactly what happened in our recent case. We discovered what may be a previously unseen version of the\r\nGh0stBins RAT — an obscure malware family originating from the Middle Kingdom and sparsely studied in the field.\r\nNaturally, we had to analyze it. \r\nThe Chinese malware scene has recently undergone something of an industrial revolution, making modern Chinese malware\r\na serious threat. In this article, we’ll dive deep into this new Gh0stBins variant — and show you how to detect it with\r\nSuricata and YARA rules as well as recover leaked data using a Python script.  \r\nLet’s get started. \r\nHow we Discovered this Gh0stBins Sample \r\nAt ANY.RUN, our team is always monitoring network activity of public samples, constantly on the lookout for signs of\r\nsuspicious actions. We classify them into three main categories: backdoors, stealers, and loaders. \r\nToday’s case started when we detected loader-type activity. This detection was achieved through a two-fold approach. First,\r\nusing a unique rule specifically designed for xored files of PE EXE or DLL format. Second, by analyzing certain statistical\r\nfeatures of the encrypted file — notably the autocorrelation function, a concept that will be discussed more comprehensively\r\nin the section on network rules. \r\nAs we continued our analysis, we discovered a significant similarity in the structure of packets from the system-installed\r\nbackdoor to the structure of Gh0stRat packets. You’ll find these similar packets highlighted with the same color in the\r\nattached screenshots, and we’ll be discussing these similarities in greater detail in the following sections. \r\nGh0stRAT: https://app.any.run/tasks/f50156b5-c387-40a1-8eca-8f913babca06/ \r\nGh0stBins: https://app.any.run/tasks/3b14ef62-5d21-48bb-a5e4-5b3fed402fb7/ \r\nhttps://any.run/cybersecurity-blog/gh0stbins-chinese-rat-malware-analysis/\r\nPage 1 of 9\n\nOur sample’s packets are suspiciously similar to Gh0stRat’s \r\nStage 1: Loader Analysis \r\nThe initial loader consists of two files: \r\nthe legitimate application ‘net-service.exe’ (part of VMware Workstation), which has a valid digital signature from\r\n“VMware, Inc” \r\nthe malicious DLL ‘shfolder.dll’ \r\nProcess tree of the loader\r\nProcess tree of the loader \r\nAt the time of writing this article, the malicious DLL has only received 3 detections on VirusTotal. \r\n3 detections on VirusTotal\r\n3 detections on VirusTotal\r\nFirstly, the main process with PID 3508 restarts itself from the same location. Secondly, it creates its own copy in the same\r\ndirectory with the name “vmnet.exe” and starts itself again.  \r\nAdditionally, we discovered that two processes made HTTP requests to http://49[.]235.129.40/update/. This indicates that\r\nthe loader may be attempting to download or update a payload: \r\nSuspicious HTTP requests\r\nSuspicious HTTP requests \r\nThe malicious library is loaded into all three processes using Search Order Hijacking technique (T1574.001) which was\r\ndocumented in the old CVE-2019-5526. \r\nIt is interesting that “shfolder.dll” has an artifact – a PDB path with Chinese characters translated as “over start”:\r\nE:\\MyProjects\\过启动\\FakeDll\\Release\\shfolder.pdb\r\nSo far, a malicious code starts its execution at the initialization routine where static objects or libraries need to be initialized\r\nbefore the program execution: \r\nStatic objects and libraries are initialized before the program executes\r\nStatic objects and libraries are initialized before the program executes \r\nThe initialization routine of the loader unpacks two payloads that are encrypted with a XOR key ‘12345678AABBCCDD’: \r\nshellcode is used to load an executable PE file; \r\nthe malicious executable (not found on a VirusTotal). \r\nThe following image shows the decrypted PE file with the help of CyberChef: \r\nDecrypted PE file in CyberChef\r\nDecrypted PE file in CyberChef \r\nThe shellcode will be written to the main module’s Entry Point using ‘WriteProcessMemory’ function, ensuring that when\r\nwe reach that point, it will be executed, and the decrypted PE file will be mapped to memory: \r\nDecrypted PE file \r\nDecrypted PE file \r\nThe decrypted PE file creates a mutex, which is likely associated with the date of a sample compiled ‘2023.01.18.18.45’: \r\nA mutex created by the decrypted PE file\r\nA mutex created by the decrypted PE file \r\nIt is worth noting that the date is written in the Chinese date format, using the pattern “yyyy年mm月dd日.” This\r\nobservation could potentially indicate that the attacker has Chinese origins or is associated with China in some way. \r\nhttps://any.run/cybersecurity-blog/gh0stbins-chinese-rat-malware-analysis/\r\nPage 2 of 9\n\nThe primary objective of the decrypted PE file, which is relatively small in size (around 7KB), is to download and execute a\r\npayload from a remote server. To achieve this task, it utilizes WinAPI functions such as ‘connect’, ‘WriteFile’, and\r\n‘ReadFile’ to create a GET request. The structure of the GET request can be observed in the accompanying picture: \r\nRaw GET request structure\r\nRaw GET request structure  \r\nAt the time of writing the article, the remote server was still active. However, instead of returning the expected payload, it\r\ndisplayed a directory listing. Consequently, when the loader attempted to download the payload, it encountered an\r\nunexpected response, leading to a crash. The loader was originally designed to download a PE executable, and the directory\r\nlisting caused an error in its execution. \r\nThe remote server displayed a directory at the time of writing, which led to loader crashing\r\nThe remote server displayed a directory at the time of writing, which led to loader crashing \r\nIn case when the payload was successfully downloaded, it needed to be decrypted using the XOR key\r\n‘12345678AABBCCDD’.  \r\nTo proceed with our analysis, we manually downloaded the payload and decrypted it.  \r\nYou can examine the operational payload at this link. \r\nNow, let us move on to the next stage. \r\nStage 2: RAT Analysis \r\nThe downloaded payload is a DLL with one exported function ‘shellcode_entry’: \r\nThe downloaded payload is a DLL\r\nThe downloaded payload is a DLL \r\nThe DLL is a modular Remote Access Trojan (RAT) written in C++, and it is not currently present on VirusTotal (VT). The\r\ndownloaded DLL is also a kernel module that serves as a connector for all the other components of the RAT. \r\nThe main execution flow of the RAT can be described roughly as follows: \r\nmain execution flow of the RAT\r\nThe RAT is an IOCP and asynchronous client, which has a complex multithreaded structure, primarily based on the events.\r\nHowever, the detailed description of this structure is beyond the scope of this article. Instead, we will focus on discussing\r\nthe exchange protocol in detail and highlight a few aspects of the RAT below. \r\nIt is interesting that the RAT contains forgotten debug logs, which can prove helpful for debugging purposes: \r\nForgotten debug logs we found in the RAT\r\nForgotten debug logs we found in the RAT \r\nFurthermore, the RAT includes RTTI (Run-Time Type Information) information and class descriptions. This tells us that the\r\nmain class of the current module is likely named ‘CKernel’: \r\nRTTI information and class descriptions suggest that the main class of the current module is named\r\n“CKernel”\r\nRTTI information and class descriptions suggest that the main class of the current module is named\r\n“CKernel” \r\nLet us now turn to discuss the exchange protocol. \r\nStage 3. Traffic Analysis \r\nWe’re going to analyze traffic based on this task. To perform a thorough analysis of the traffic, we recommend either\r\ndownloading the PCAP (Packet Capture) file or following the network stream in the static discovery window available on\r\nANY.RUN. \r\nInitial Request: Module Registration \r\nAfter establishing the connection, it is observed that the first outgoing packet always consists of 4 bytes, which describes the\r\nmodule connecting to the Command and Control (C2) server. In this particular case, the kernel module is identified by its\r\nshort alias “KNEL”: \r\nThe kernel module identified as “KNEL”\r\nThe kernel module identified as “KNEL” \r\nhttps://any.run/cybersecurity-blog/gh0stbins-chinese-rat-malware-analysis/\r\nPage 3 of 9\n\nOur hunting team has also discovered an RDP module, identified by the alias ‘RDTP’. Furthermore, through the process of\r\nreverse engineering the code, we can deduce the existence of additional modules. We can speculate about their intended\r\npurposes based on their names: \r\nName Alias Module description\r\nkernel  KNEL  The heart of the RAT, a connector for all other modules \r\nchat  unknown  Enables communication and interaction with the RAT operator or other users. \r\nfilemgr  unknown  Manages files and directories on the compromised system \r\nrd  RDTP  Remote Desktop: Allows remote access and control of the target system's desktop. \r\ncamera  unknown  Controls and accesses the target system's camera for capturing images or videos. \r\nmicrophone  unknown  Controls and accesses the target system's microphone for recording audio. \r\nfiledownloader  unknown  Downloads files from the internet onto the compromised system \r\nkblog  unknown  Logs and records keystrokes on the target system \r\nsocksproxy  unknown \r\nSets up a SOCKS proxy server on the compromised system, allowing network traffic to\r\nbe routed through it \r\ncmd  unknown \r\nExecutes  commands on the target system, providing remote control and administration\r\ncapabilities \r\nInitial Response: Registration Confirmed \r\nThe server responds to the received ‘module registration’ packet with the following ‘registration confirmed’ packet: \r\n0  1  2  3  4  5  6  7  8  9  a  b  c  d  e  f \r\n0\r\nheader\r\nmagic bytes  packet size decompressed size packet type\r\n1 p_type payload\r\nThe packet has the following fields: \r\nmagic bytes: always contains the value “BINS” for all subsequent communications. \r\npacket size: the size of the packet excluding the header.\r\ndecompressed size: is used only when the payload is compressed, and it represents the size of the decompressed\r\ndata.\r\npacket type: type of the packet, which can have 2 values: 0x0 denotes a data packet and 0xABCDEF indicates that\r\nthe packet is a “heartbeat”.\r\np_type: can have 2 types of values: 0x9C78: payload is compressed with ‘zlib’ using fixed Huffman coding and any\r\nrepresents a command to process. \r\npayload: compressed or raw data. \r\nBelow, you can see an example of the “registration confirmed” packet: \r\nThe registration confirmed packet example\r\nThe registration confirmed packet example \r\nThe decompressed command from the payload in the above picture can be viewed in CyberChef: \r\nDecompressed command from the picture above \r\nSo that the server asks the client to send information about the host. \r\nhttps://any.run/cybersecurity-blog/gh0stbins-chinese-rat-malware-analysis/\r\nPage 4 of 9\n\nClient Identity \r\nIn response to the command received from the server, the client starts collecting information about the victim.\r\nThey do it in the following order:\r\n1. Get IP address using WinAPI “getsockname” \r\n2. Get computer name \r\n3. Get user name \r\n4. Get the Windows version using the WinAPI function “GetNativeSystemInfo” to obtain bitness and information from\r\nthe registry key: \r\nHKLM\\SOFTWARE\\Microsoft\\Windows NT\\CurrentVersion\\Product \r\n5. Create a registry key “HKEY_CURRENT_USER\\SOFTWARE\\HHClient” \r\n if it didn’t exist before. It also updates the date of the RAT installation by setting a string value ‘InstallDate’ to the\r\ncurrent date: \r\n \r\nThe RAT sets a string value ‘InstallDate’ to the current date to update the time of its installation\r\nThe RAT sets a string value ‘InstallDate’ to the current date to update the time of its installation \r\n6. Get information about the processor from ‘HKLM\\HARDWARE\\DESCRIPTION\\System\\CentralProcessor\\0’ and\r\nusing GetSystemInfo API \r\n7. Get information about drives via GetLogicalDrives and GetDiskFreeSpaceExW \r\n8. Get memory size using GlobalMemoryStatusEx API \r\n9. Check if the C2 is available by sending a echo-request (PING) packet to the attacker server \r\n10. Check if a victim has a camera by enumerating available devices \r\n11. Check if an attacker’s comment of the victim exists in the key “HHClient” \r\nAfter collecting all the information, the RAT prepends it with a 2-byte prefix ‘0xEE01’, indicating that it is a client identity\r\nresponse, compresses it with “zlib” and sends it to the C2: \r\nExfiltrating data to C2\r\nExfiltrating data to C2 \r\nHeartBeat \r\nEvery 60 seconds the RAT sends the heartbeat packet (packet type is equal to 0xABCDEF) to the server to ensure the\r\nconnection is still active. The server has to respond with the same packet type and zero payload len immediately: \r\nThe heart beat packet is sent every 60 seconds\r\nThe heart beat packet is sent every 60 seconds \r\nModules Downloading and Executing \r\nWhen the attacker decides to execute a command on the victim host, they send a packet similar to the ‘registration\r\nconfirmed’ packet, but with a different command ID. The command ID is always 2 bytes in length. Depending on the packet\r\ntype, the command ID can either be compressed or located in the position of the ‘zlib’ header. \r\nBelow is a list of all the available command IDs: \r\n# \r\nCmd ID\r\nreq \r\nCmd ID\r\nresp \r\nDescription \r\n1  0x4552  0xEE01  Send victim info \r\n2  0xDD01  0xEA05  Prepare for loading ‘cmd’ module \r\n3  0xDD02  0xEA05  Prepare for loading “chat’ module \r\n4  0xDD03  0xEA05  Prepare for loading “file manager” module \r\n5  0xDD04  0xEA05  Prepare for loading “RDP” module \r\n6  0xDD05  0xEA05  Prepare for loading “camera” module \r\nhttps://any.run/cybersecurity-blog/gh0stbins-chinese-rat-malware-analysis/\r\nPage 5 of 9\n\n# \r\nCmd ID\r\nreq \r\nCmd ID\r\nresp \r\nDescription \r\n7  0xDD06  0xEA05  Prepare for loading “microphone” module \r\n8  0xDD07  0xEA05  Prepare for loading “file uploader” module \r\n9  0xDD08  -  Exit \r\n10  0xDD09  0xEA05  Prepare for loading ‘keyboard log’ module \r\n11  0xDD0A  0xEA08  Create a LNK file in the startup menu with name of “VMware NAT Service” \r\n12  0xDD0B  0xEA08 \r\nAdd itself to autorun via\r\n“HKCU\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run” with name\r\n“VMware NAT Service” \r\n13  0xDD0C  0xEA05  Prepare for loading ‘socks proxy’ module \r\n14  0xDD0D  -  Is not developed, has a comment “OnUtilsOpenWebPage” \r\n15  0xEA04  -  Restart itself \r\n16  0xEA07  0xFA00  Prepare memory for the payload \r\n17  0xEE02  -  Reboot system \r\n18  0xEE03  -  Force system shutdown \r\n19  0xEE04  0xEE05  Save comment about the victim host to the registry \r\n20  0xFA01    A part of the payload is received \r\nIn the analyzed task, the attacker sends a command 0xDD04 to upload the “RDP” module. In response, the client sends a\r\nconfirmation of readiness to accept the payload with the bytes ‘rd’ at the end — the type of module to be loaded: \r\nThe command that uploads the “RDP” module\r\nThe command that uploads the “RDP” module \r\nThe server, in turn, sends basic information about the expected payload: \r\ncommand 0xEA07 \r\ntotal size \r\nresulting hash value obtained by simply summing up all the bytes included in the payload after the final assembly \r\n‘rd’ confirmation \r\nBasin information is then sent by the server in return\r\nBasin information is then sent by the server in return \r\nThe client allocates memory for the payload and confirms its acceptance by sending the following packet: \r\nThe client responds with this packet to confirm acceptance\r\nThe client responds with this packet to confirm acceptance \r\nThis packet includes: \r\nconfirmation command 0xFA00 \r\nexpecting payload size \r\nexpecting payload hash \r\nthe number of the received part \r\nthe maximum size of the expecting part \r\n“rd” confirmation \r\nIt is also worth noting that the above packet will be sent to the server as confirmation of receiving every part with the only\r\ndifference in the number of the received part. \r\nStarting from this moment, the server will send the result payload part by part with a size that was agreed upon with the\r\nclient. Each subsequent packet will have a structure similar to the following: \r\nA part of the payload is sent\r\nA part of the payload is sent \r\nThis data packet includes: \r\nhttps://any.run/cybersecurity-blog/gh0stbins-chinese-rat-malware-analysis/\r\nPage 6 of 9\n\ncommand 0xFA01 \r\nexpecting payload size \r\nthe size of the current part\r\npayload \r\n4 bytes hash at the end of each packet calculated only for the current payload’s part; the hashing algorithm used will\r\nbe the same as described earlier \r\nWhen the transaction is complete, the server may send a 0xDD08 command to exit from the kernel module, as was the case\r\nin our task. \r\nAt this moment, the downloaded RDP module is mapped to the memory and executed, which can be observed through the\r\nnewly created connection: \r\nA new connection indicates that the downloaded RDP is executed\r\nA new connection indicates that the downloaded RDP is executed  \r\nTo simplify the task of constructing the resulting payload, we have written a Python script that is already available in our\r\nGitHub repository. You can download the PCAP file and save the raw TCP stream 0 to a separate file. Then, you can apply\r\nour script, which will rebuild the payload from the captured traffic dump. As a result, you will obtain a new DLL containing\r\nthe malicious RDP module. \r\nOr, you could download a constructed payload with the simple DLL loader for your own analysis. \r\nStage 4. RDP module: basic description and protocol \r\nThe RDP module, the same as the ‘kernel’ module, is a DLL compiled against static CRT and OpenCL libraries. It includes\r\nan exported function called “ModuleEntry”. This function takes the host and port as input arguments: \r\nExported function named “ModuleEntry”\r\nThe exported function named “ModuleEntry” \r\nThe structure of the RDP module is similar to the “kernel” module, as it is also based on asynchronous events. It has its own\r\ncommands and includes forgotten logging functions, which can be observed if we execute the module from the console: \r\nA logging function was likely forgotten\r\nA logging function was likely forgotten \r\nIt is worth mentioning that the RDP module also possesses a debug filename artifact, displaying the same developer’s\r\ndirectory as the “kernel” module: \r\nDebug filename artifact of the RDP module\r\nDebug filename artifact of the RDP module \r\nThe traffic structure of the RDP module is like the kernel’s, except for the initial registration packet, which contains the\r\nkeyword “RDTP”: \r\nThe traffic structure of the RDP module\r\nThe traffic structure of the RDP module \r\nOne interesting aspect to note is that the RDP module will not function properly if it is started by an external loader, as it\r\nlacks the call to the “WSAStartup” routine. This absence of initialization will result in a failure, leading to the module’s exit.\r\nThis could be a clever trick to protect the module from dynamic analysis, as well as a programmer mistake. \r\nWe won’t spend our time analyzing the internal workings of the RDP. Instead, let’s move on to a more interesting task:\r\nrecovering a video stream. \r\nStage 5. RDP Module – Recovering a Video Stream and Leaked Data \r\nDuring our analysis, we wonder if it is possible to restore the video stream received by the attacker to gain insights into the\r\nleaked data. The answer is yes — we can do it. \r\nTo begin with, we discovered that the RDP protocol contains a NALU header with information about the upcoming video\r\nstream. In particular, we observed that the stream is encoded using the H.264 codec: \r\nThe video stream is encoded with the H.264 codec\r\nThe video stream is encoded with the H.264 codec  \r\nSecondly, we have developed a Python script, available in our GitHub repository, which is capable of extracting the\r\nencapsulated video stream from the RAT traffic. The script concatenates the extracted data and saves it as a separate file. \r\nFinally, we used a MPEG decoder to create an mp4 file: \r\nhttps://any.run/cybersecurity-blog/gh0stbins-chinese-rat-malware-analysis/\r\nPage 7 of 9\n\nAn MPEG decoder creates an mp4 file\r\nMPEG decoder creates an mp4 file \r\nAs a result, we have the full video stream captured by the attacker, but upside down! Just compare the screen to the analyzed\r\ntask: \r\nThe recovered video stream is unfortunately saved upside down\r\nWe did it! But the recovered video stream is unfortunately saved upside down \r\nThus we may conclude that the stream is not encrypted at all which, for example, might help you to write a Suricata\r\nsignature. \r\nStage 6. Fake RAT Server \r\nIn order to simplify the process of the protocol analysis and only for educational purposes we wrote a simple fake server for\r\nthe RAT, which can only accept the client, send a registration packet, and a heartbeat. This script is available on our GitHub\r\npage.  \r\nWe’ve spun up a fake RAT server strickly for educational purposes\r\nWe’ve spun up a fake RAT server strictly for educational purposes \r\nStage 7. Suricata Signature \r\nWe’ve developed 4 Suricata rules for detecting Gh0stBINS in network traffic. You can find them in our GitHub\r\nrepository. \r\nAs an example, let’s look at the key points of the Gh0stBins rule (sid: 8000054). \r\nSuricata keyword  Description \r\nflow: established, to_client; \r\nDefines the direction of data packet transmission — from the remote\r\nPC to the client \r\ndsize: 24;   The size of the payload of the transmitted packet is 24 bytes \r\ncontent: \"BINS\";depth:  4;  Magic constant — beginning of the data packet \r\ncontent: \"|789c 0300 0000 0001|\"; distance: 12;\r\nwithin: 8; \r\nPayload of the Gh0stBins protocol, which is an empty zlib archive \r\nStage 8. YARA Rules \r\nWe’ve developed multiple YARA rules for detecting Gh0stBINS in memory and files. You can familiarize yourself with\r\nthem in detail in our GitHub repository. \r\nThese YARA rules are designed to detect: \r\n1. Malicious DLL, used for CVE-2019-5526 \r\n2. Core and RDP modules \r\n3. Decryptor and loader shellcode \r\nConclusion \r\nWe hope that you’ve learned something new from today’s analysis. Gh0stBins is indeed an unusual sample. Despite its\r\nchallenges, analyzing it was highly rewarding and may provide insights into the strategies used by adversaries from China. \r\nDon’t forget, that we’ve written a Python script that can construct the payload from captured traffic dump for further\r\nanalysis. We encourage you to download and try it. The script is available on our GitHub. \r\nInterested in more malware deep dives? Read how we deobfuscated GuLoader, or how we examined the encryption and\r\ndecryption of PrivateLoader. \r\nAppendix 1: IOCs \r\nAnalyzed files: \r\nName  payload_decrypted.bin net-service.exe 7f426b327c878f799c74bb4b8a532cb3.exe shfolder.dll \r\nMD5  4FEB48DDEB3F2BD55B2AF31BD77EAB2E D9B422F37FCAF61BD80E12CC03E84816 7F426B327C878F799C74BB4B8A532CB3 d\r\nhttps://any.run/cybersecurity-blog/gh0stbins-chinese-rat-malware-analysis/\r\nPage 8 of 9\n\nName  payload_decrypted.bin net-service.exe 7f426b327c878f799c74bb4b8a532cb3.exe shfolder.dll \r\nSHA1  20B5B6C2F24C2FDB9778BDFF5BC5976997C7E2AD 1D9D212620F342AE0D5440A067F4DE3AE12877F9 0315CC83C6D781DB16E\r\nSHA256  16F3191FF882670F1288E1836CF4683C7A74863AD0BFFE153FE4A668995A714B 4395003E0D81C685BE47C80DFF9DACCC2F0A3\r\nConnections (IP) \r\n“118[.]107.7.166”  \r\n“193[.]134.208.217” \r\n“49[.]235.129.40” \r\nHTTP Request \r\nhttp://118[.]107[.]7[.]166/foxx/64.bin \r\nhttp://49[.]235.129.40/update/\r\nAppendix 2: MITRE MATRIX \r\nTactics   Techniques   Description \r\nTA0007:  Software\r\ndiscovery    \r\nT1082:  System Information  Discovery   Collects system data  \r\nTA0011:  Command and\r\nControl  \r\nT1071.001:  Application Layer\r\n  Protocol  \r\nSending collected data   to the control\r\nserver  \r\n   T1105 Ingress Tool Transfer   Requests binary from the Internet  \r\n  T1572 – Protocol Tunneling  GhostBins protocol uses RDP \r\nTA0005: Defense\r\nEvasion  \r\nT1027 – Obfuscated Files or Information  \r\nAttempt to make an executable or file\r\ndifficult to discover or analyze by\r\nencrypting XOR  \r\n \r\nT1140 – Deobfuscate/Decode Files or\r\nInformation \r\nDecrypts unpack file with XOR key \r\nTA0005: Defense\r\nEvasion \r\nT1574.001 – Hijack Execution Flow:\r\nDLL Search Order Hijacking \r\nCVE-2019-5526 \r\nelectron\r\nElectron\r\nLeading malware analyst\r\nI'm a malware analyst. I love CTF, reversing, and pwn. Off-screen, I enjoy the simplicity of biking, walking, and hiking.\r\njane\r\nJane\r\nLeading network traffic analysis expert at ANY.RUN\r\nI'm ANY.RUN ambassador and a real network traffic numismatist. I also love penguins and tortoises. My motto is to do\r\ngood and throw it into the sea.\r\nkinoshi\r\nkinoshi\r\nMalware analyst at ANY.RUN\r\nI'm a dedicated programmer and malware analyst. I derive immense joy from the art of coding and have a deep passion for\r\nboth low-level and system-level programming. I thoroughly enjoy delving into the intricacies of software and exploring how\r\nit operates at a fundamental level. My expertise extends to solving crackme challenges and participating in online CTF\r\ncompetitions, where I tackle complex tasks to enhance my skills.\r\nSource: https://any.run/cybersecurity-blog/gh0stbins-chinese-rat-malware-analysis/\r\nhttps://any.run/cybersecurity-blog/gh0stbins-chinese-rat-malware-analysis/\r\nPage 9 of 9\n\nAnalyzed files: Name payload_decrypted.bin net-service.exe 7f426b327c878f799c74bb4b8a532cb3.exe shfolder.dll  \nMD5 4FEB48DDEB3F2BD55B2AF31BD77EAB2E D9B422F37FCAF61BD80E12CC03E84816 7F426B327C878F799C74BB4B8A532CB3 d\n Page 8 of 9",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://any.run/cybersecurity-blog/gh0stbins-chinese-rat-malware-analysis/"
	],
	"report_names": [
		"gh0stbins-chinese-rat-malware-analysis"
	],
	"threat_actors": [],
	"ts_created_at": 1775434571,
	"ts_updated_at": 1775826680,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/c57c89f6a7240153bb2bef0f9c0f70aef8d4623a.pdf",
		"text": "https://archive.orkl.eu/c57c89f6a7240153bb2bef0f9c0f70aef8d4623a.txt",
		"img": "https://archive.orkl.eu/c57c89f6a7240153bb2bef0f9c0f70aef8d4623a.jpg"
	}
}