{
	"id": "0995c720-4138-425c-8caf-c26c974bc1cc",
	"created_at": "2026-04-06T00:19:00.691559Z",
	"updated_at": "2026-04-10T13:12:39.366868Z",
	"deleted_at": null,
	"sha1_hash": "f1c9a10c46eaa6caa0007637bc25b0d31a54c074",
	"title": "ProxyBox: Socks5Systemz Lives On",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 6699264,
	"plain_text": "ProxyBox: Socks5Systemz Lives On\r\nBy Synthient Research\r\nPublished: 2026-03-30 · Archived: 2026-04-05 21:27:06 UTC\r\nExecutive Summary\r\nSynthient’s Research Team continuously tracks Black Hat proxy services due to the significant risks they pose to\r\nclients in the financial sector. Recently, a service known as “ProxyBox” stood out after online discussions revealed\r\nits overwhelming popularity among threat actors for carding, credential stuffing, and identity theft. This report\r\nbuilds upon earlier research by the BitSights Research Team, detailing the evolution of this threat from its origins\r\nas \"Socks5Systemz.\" Originally sold on underground hacking forums since 2013, the Socks5Systemz malware\r\nsaw widespread commercial use under the banner of PROXY[.]AM. Following that platform's shutdown, the\r\nservice rebranded as ProxyBox and continued to provide clients with access to 32,000 to 35,0000 daily active IPs\r\n(DAI).\r\nTo build this massive network of residential IPs, ProxyBox acquires initial access by tricking users into\r\ndownloading infected files from cracked software sites. Synthient has observed a growing trend of proxy\r\nproviders exploiting these consumer-focused piracy vectors to rapidly expand their infrastructure.\r\nBecause this consumer-driven threat poses a unique risk to enterprise environments, organizations must adopt\r\nproactive countermeasures. On a human level, users should be strictly warned against downloading unverified,\r\nthird-party software. On a technical level, organizations should block the malware's tier 1 and tier 2 relay servers,\r\ncutting off proxying and rendering the infection ineffective. Furthermore, enforcing strict network policies to\r\nblock commonly abused proxy protocols is highly recommended to mitigate this ongoing risk.\r\nBackground\r\nAccording to research published by the BitSight TRACE team, Socks5Systemz originated in early 2013 when a\r\nthreat actor operating under the alias \"BaTHNK\" initiated a sales thread on the Russian-speaking XSS forum.\r\nhttps://synthient.com/blog/proxybox-socks5systemz-lives-on\r\nPage 1 of 17\n\nFig 01. Socks5Systemz Sales thread on XSS. (PROXY[.]AM Powered by Socks5Systemz Botnet)\r\nFor approximately ten years, the malware operated primarily as a SOCKS5 proxy module integrated into\r\nestablished malware families, including Andromeda, Smokeloader, and Trickbot.\r\nIn September 2023, BitSight observed a shift in deployment tactics, with Socks5Systemz distributed as a\r\nstandalone final payload via loaders such as Privateloader and Amadey. By late January 2024, the botnet's initial\r\niteration had reached a daily average of approximately 250,000 infected devices globally. In December 2023, the\r\noperators lost control of the V1 infrastructure, leading to the sinkholing of the malware in early 2024.\r\nFollowing the 2024 infrastructure disruption and sinkholing events, the PROXY.AM service rebranded to\r\nProxyBox. The rebranded service continues to operate the Socks5Systemz botnet at a reduced capacity.\r\nhttps://synthient.com/blog/proxybox-socks5systemz-lives-on\r\nPage 2 of 17\n\nFig 02. ProxyBox landing page and pricing model.\r\nIn an attempt to regain their once previous numbers the ProxyBox operators are observed utilizing pay per install\r\n(PPI) sites which distribute the malware through cracked software sites as seen below with vsttorentz[.]net.\r\nhttps://synthient.com/blog/proxybox-socks5systemz-lives-on\r\nPage 3 of 17\n\nFig 03. Backdoored piracy sites such as vsttorentz[.]net pushing Socks5Systemz.\r\nThese sites utilize NSIS installers which will dynamically install a series of applications. At the time of\r\npublication the NSIS installer is no longer observed installing Socks5Systemz, with it now observed installing\r\nother Proxy SDKs and adware.\r\nMicroleaves (Shifter[.]io)\r\nOpera GX\r\nDotGo / iRocket\r\nSearchCandy\r\nInternet Download Manager\r\nFig 04. Pay-Per-Install infection chain with multiple applications being installed.\r\nAnalysis\r\nThe ProxyBox/Socks5Systemz infection chain relies on a multi-stage loading process designed to evade basic\r\ndynamic analysis and disguise itself as benign software. The following sections break down the initial loader's\r\nself-overwriting techniques, the second-stage resource extraction, and the final payload's C2 behavior.\r\nInitial Loader\r\nFig 05. Initial payload in explorer\r\nThis initial payload is a 32-bit binary that is approximately 2.5 MB in size. It’s compiled as a GUI application and\r\nimports GUI-related functions from GDI32.dll, but never displays any activity to the end user. The module\r\nincludes a writable executable section. It also uses timestamp stomping, showing that it was compiled in 2011,\r\nwhich is false.\r\nhttps://synthient.com/blog/proxybox-socks5systemz-lives-on\r\nPage 4 of 17\n\nFig 06. Initial payload PE file header\r\nFig 07. Initial payload PE sections\r\nThe only purpose of the first payload is to overwrite itself with another loader. This loader shares decompression\r\nand encryption functions with the loader that it overwrites, suggesting both payloads were created by the same\r\nauthor.. Chunks of the encrypted payload are embedded within the .text section and can be non-contiguous;\r\nthis makes static extraction difficult or impossible. However, you can extract the parameters to the loader stub\r\nfunction and dump the section of memory containing the encrypted payload. Manual decryption and payload\r\ndumping are possible, as demonstrated in this article.\r\nhttps://synthient.com/blog/proxybox-socks5systemz-lives-on\r\nPage 5 of 17\n\nFig 08. Control graph of gamebackupmanager\r\ngamebackupmanager[.]exe will write a loader function onto the stack. The loader function accepts a single\r\nargument, a 74-byte struct containing information required to overwrite the current main module. This approach\r\nhas some advantages for the malware author, first of all, because if you overwrite an image loaded by the system\r\nloader, the memory your payload resides in will be marked as image-allocated rather than private. A second\r\nadvantage is that it complicates debugging. If a researcher sets a breakpoint in the second payload after it is\r\nmapped into memory, restarting the debugger will wipe that breakpoint out. This happens because the first loader\r\ndynamically overwrites itself with the second stage during each run. Resulting in a loss of control and or a\r\nfrustrating experience.\r\nhttps://synthient.com/blog/proxybox-socks5systemz-lives-on\r\nPage 6 of 17\n\nhttps://synthient.com/blog/proxybox-socks5systemz-lives-on\r\nPage 7 of 17\n\nhttps://synthient.com/blog/proxybox-socks5systemz-lives-on\r\nPage 8 of 17\n\nFig 09. Initial payload calling loader function on stack\r\nFig 10. Memory map of initial payload showing EIP in stack\r\nLoader argument struct layout in memory:\r\n0x0 = module to overwrite, the loader function will jump to the module it overwrites instead of returning. Neither\r\nthe initial payload nor the payload its loading contain relocation information. This simplifies the loading process.\r\n0x4 = address of GetProcAddress\r\n0x8 - 0x24 = pointers to chunks of the encrypted module. The loader function will add 0x800 to these pointers\r\ninstead of using them as raw.\r\n0x28 = pointer to a struct containing a key and data size used for decryption.\r\n0x6C = kernel32.dll module\r\n0x70 = compression function pointer, decryption of the module chunks is done inline within the function, but calls\r\nout of the function for decompression.\r\nhttps://synthient.com/blog/proxybox-socks5systemz-lives-on\r\nPage 9 of 17\n\nFig 11. Loader function parameter layout in memory\r\nAddress of key and data size:\r\nFig 12. Pointer in structure to key and size structure.\r\nFig 13. Pointer and key structure in x32dbg\r\nEncryption key:\r\nFig 14. Highlighting encryption key in hex editor\r\nSize:\r\nFig 15. Highlighting size of payload in hex editor\r\nOnce the loader stub decrypts the second stage module, it resolves the necessary imports and overwrites the\r\noriginal main module. Because both stages are stripped of relocation data and mapped to the same base address,\r\nhttps://synthient.com/blog/proxybox-socks5systemz-lives-on\r\nPage 10 of 17\n\nno memory relocations occur. Finally, instead of returning from the function, the loader stub executes the payload\r\nby jumping directly to the second stage's entry point. The second stage then starts execution as it would normally\r\nbe mapped into memory by the system.\r\nSocks5Systemz Second Stage\r\nThe second loader is approximately 500KB in size. The majority of this bulk comes from an encrypted DLL\r\nstored within its resource section. Besides housing this payload, the loader's actual functionality is minimal and\r\ncompletely unobfuscated.\r\nFig 16. Second stage loader in explorer.\r\nA Socks5Systemz module stored in the loader's resource section makes static extraction easy. The compression\r\nalgorithms used in the initial payload to load the current module are also used within the module itself to protect\r\nthe payload while it’s stored in the resource section.\r\nFig 17. Encrypted Resource in second loader\r\nThe first operation the loader will perform in the main function is to register a service control handle. If it is\r\nsuccessful, it will start a new thread to load the socks5systemz.dll into memory and wait indefinitely for that\r\nthread to complete. If an error is encountered at any point in this function, the function will return to winmain,\r\nwhere its status is not checked, and execution continues. The advantage of this design decision is that it allows the\r\nmodule to function both as a service and as a regular PE/EXE.\r\nNext, the function will check for the presence of two possible command-line flags. If the uninstall flag is\r\nspecified, a test file will be created, and the process will exit; this may be unimplemented functionality. If the\r\ninstall flag is specified, persistence will first be attempted by registering a service; if this fails due to insufficient\r\npermissions or for any other reason, a run key will be created. Otherwise, if no flags are specified, the packed\r\nDLL will be memory-loaded into the current process without any further operations.\r\nhttps://synthient.com/blog/proxybox-socks5systemz-lives-on\r\nPage 11 of 17\n\nPseudo code of the main function in the second stage loader:\r\nBefore unpacking, the loader will sleep in a loop to delay execution, both before and in the middle of the memory\r\nloading process.\r\nTo unpack the DLL, the loader will first call standard APIs used to retrieve data from resource sections,\r\nFindResourceA, SizeOfResource, LoadResource, and LockResource. To decrypt the resource, it extracts a 32-byte\r\nkey from the end of the resource, though only the first 16 bytes are used in the algorithm. The first 4 bytes of the\r\ndecrypted context will be the uncompressed data size, used when passing the decrypted data to the decompress\r\nfunction. Once the module's bytes are returned, the DLL will be mapped into memory using a single allocation\r\nwith read and execute permissions. The memory loader will fix relocations and zero the PE headers before\r\ntransferring control to the DLL entry point.\r\nPseudo code of the unpacking function in the second stage loader:\r\nSocks5Systemz Final Payload\r\nThe final payload of Socks5Systemz is around 600KB unpacked, and it has a realistic timestamp.\r\nFig 18. Socks5systemz PE file header\r\nThe DLL heavily relies on junk code and control-flow obfuscation, making static analysis challenging. Instead,\r\ndynamic analysis was used to understand the main routine of the final unpacked sample.\r\nC2 Loop Behavior\r\nThe module will attempt to reach out to its C2 3 times before moving onto the next C2. Once it reaches the end of\r\nthe list it loops back around to the beginning of the list. For the first iteration of the list it attempts to use HTTPS\r\nbefore falling back to HTTP. Once it reaches the end of the C2 list while attempting to use HTTP, it loops back\r\naround to the beginning of the C2 list and attempts to use HTTPS again and the cycle keeps repeating until a\r\nsuccessful connection is made.\r\nhttps://synthient.com/blog/proxybox-socks5systemz-lives-on\r\nPage 12 of 17\n\nhttps://synthient.com/blog/proxybox-socks5systemz-lives-on\r\nPage 13 of 17\n\nFig 19. Socks5systemz C2 command loop\r\nC2 Communication\r\nSocks5Systemz uses the useragent Mozilla/5.0 (Windows; U; MSIE 9.0; Windows NT 9.0; en-US) is used for\r\nauthentication to the C2 server.\r\nThe C2 url is in the format http(s)://ip/ai/?key=\u003cencrypted parameters\u003e for example:\r\nExample of unencrypted parameters for initial connection:\r\nExample of unencrypted parameters for a command response, in this case a response from the C2 requesting that\r\nthe bot connect to a relay:\r\nThe module will use InternetOpenA to set a header and get a handle to an HINTERNET object. It will then call\r\nSetInternetOptionA three times, setting the INTERNET_OPTION_CONNECT_TIMEOUT ,\r\nINTERNET_OPTION_CONTROL_SEND_TIMEOUT , and INTERNET_OPTION_CONTROL_RECEIVE_TIMEOUT options to 5\r\nseconds each. To make a request to a specific URL, use the InternetOpenUrlA function. If any type of error\r\noccurs, it either tries or goes to the next address, depending on the iteration. If a favorable response is received, it\r\nwill use the InternetReadFile function to read an encrypted reply. The response will then be decrypted, and\r\nexecution will be directed toward the appropriate command handler.\r\nEncryption Routine\r\nBoth requests and responses are RC4 encrypted using the same RC4 encryption key. Of hi_few5i6ab\u00267#d3 .\r\nActual keys can vary between samples but the use of a 16 byte key is consistent across a variety of samples.\r\nResponse:\r\nFig 20. Decrypting response in cyberchef\r\nRequest:\r\nhttps://synthient.com/blog/proxybox-socks5systemz-lives-on\r\nPage 14 of 17\n\nFig 21. Decrypting request in cyberchef\r\nThe URL parameters to make C2 requests are not unique between executions and between requests. Because of\r\nthis it is possible to intercept a single request and then make a script to mimic the request and continuously request\r\ncommands.\r\nC2 Commands\r\nThe response from the C2 will be matched against the following commands and then be redirected to its command\r\nhandler:\r\nProxyBox and its Victims\r\nSince the PROXY[.]AM sinkholing led by BitSight, the operators have pivoted to using ProxyBox[.]io to sell\r\naccess to the malware. Synthient’s Research Team observes around 32,000 to 35,000 daily active IPs for the\r\noperation (DAI), with a significant portion in Russia, Brazil, and India.\r\nhttps://synthient.com/blog/proxybox-socks5systemz-lives-on\r\nPage 15 of 17\n\nFig 22. ProxyBox ip distribution\r\nDue to the overlap in IP addresses, Synthient’s Research Team alleges, with moderate confidence, that the\r\noperators are likely offering the traffic for sale to larger providers.\r\nMitigation Strategies\r\nOrganizational \u0026 Network Mitigations\r\nBlock malicious infrastructure: Block the provided Tier 1 and Tier 2 IP addresses to prevent the malware\r\nfrom receiving commands or proxying.\r\nRestrict proxy protocols: Enforce strict corporate network policies that block unauthorized or commonly\r\nabused proxy protocols to prevent the malware from routing traffic.\r\nMonitor C2 communication signatures: Flag or block outbound web traffic utilizing the specific User-Agent string Mozilla/5.0 (Windows; U; MSIE 9.0; Windows NT 9.0; en-US) used by the malware for C2\r\nauthentication.\r\nIdentify C2 polling behavior: Use network rules to identify the malware's distinct C2 loop, which\r\nincludes 5-second timeout polling, fallback mechanisms between HTTPS and HTTP, and RC4-encrypted\r\npayload patterns.\r\nVictims\r\nEnforce least privilege: Remove local administrator rights from standard users to prevent the malware's\r\ninitial loader from successfully registering its persistent service control handle.\r\nDon’t install untrusted Software: Avoid the installation of software from shady cracked software\r\nwebsites.\r\nhttps://synthient.com/blog/proxybox-socks5systemz-lives-on\r\nPage 16 of 17\n\nIndicators of Compromise\r\nA full list of indicators of compromise can be found on the Synthient Github.\r\nFuture Outlook\r\nProxyBox, as the successor to Socks5Systemz, highlights the ongoing evolution of proxy-based malware services\r\nin the cybercrime ecosystem. Its persistent presence, despite takedowns and rebranding, highlights the adaptability\r\nof threat actors and the challenges organizations face in securing their environments.\r\nAddressing this ongoing threat requires a multi-layered defense strategy. Organizations should deploy technical\r\ncontrols such as blocking relay IP addresses linked to proxy botnets, enforcing restrictions on unauthorized proxy\r\nprotocols, and actively monitoring for command-and-control polling behaviors that indicate compromise. In\r\nparallel, user awareness training should highlight the risks posed by third-party and pirated software, which are\r\ncommon vectors for initial infection.\r\nSource: https://synthient.com/blog/proxybox-socks5systemz-lives-on\r\nhttps://synthient.com/blog/proxybox-socks5systemz-lives-on\r\nPage 17 of 17",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://synthient.com/blog/proxybox-socks5systemz-lives-on"
	],
	"report_names": [
		"proxybox-socks5systemz-lives-on"
	],
	"threat_actors": [],
	"ts_created_at": 1775434740,
	"ts_updated_at": 1775826759,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/f1c9a10c46eaa6caa0007637bc25b0d31a54c074.pdf",
		"text": "https://archive.orkl.eu/f1c9a10c46eaa6caa0007637bc25b0d31a54c074.txt",
		"img": "https://archive.orkl.eu/f1c9a10c46eaa6caa0007637bc25b0d31a54c074.jpg"
	}
}