{ "id": "433ce83b-c948-4dea-9aa6-12c29e1be173", "created_at": "2026-04-06T00:14:00.865081Z", "updated_at": "2026-04-10T03:23:51.609621Z", "deleted_at": null, "sha1_hash": "df858a4dee0e6411d67fa6cc0add1455a7522239", "title": "Who’s Behind Your Proxy? Uncovering Bunitu’s Secrets", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 809552, "plain_text": "Who’s Behind Your Proxy? Uncovering Bunitu’s Secrets\r\nBy Malwarebytes Labs\r\nPublished: 2015-08-04 · Archived: 2026-04-05 23:17:48 UTC\r\nDisclaimer\r\nThe following research is the result of a collaboration with ad-fraud fighting firm Sentrant. Analysts from both the\r\nSentrant and Malwarebytes teams have been working on the Bunitu malware and we decided to combine our\r\nefforts to provide a more complete study.\r\nExecutive summary\r\nIn our previous analysis we showed how the Bunitu Trojan was distributed via the Neutrino exploit kit in various\r\nmalvertising campaigns. After spending more time analyzing the proxy, we realized that the requests we were\r\nreceiving were not related to ad-fraud activity (as we initially suspected) but instead appeared to be for some sort\r\nof VPN service.\r\nWe believe that the operators of the Bunitu botnet are selling access to infected proxy bots as a way to monetize\r\ntheir botnet. People using certain VPN service providers to protect their privacy are completely unaware that the\r\nbackend uses a criminal infrastructure of infected computers worldwide.\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/08/whos-behind-your-proxy-uncovering-bunitus-secrets/\r\nPage 1 of 10\n\nNumber of Bunitu infections in July based on telemetry data from Malwarebytes Anti-Malware.\r\nNot only that, but all traffic is also unencrypted – ironic for a VPN service – and could be intercepted via a Man-In-The-Middle attack. Malicious actions such as data theft or traffic redirection could therefore easily be\r\nperformed.\r\nDuring our research we noticed that a VPN service called VIP72 was heavily involved with the Bunitu botnet and\r\nits proxies. VIP72 appears to be a top choice for cybercriminals, as referenced on many underground forums.\r\nA recent report from FireEye on Nigerian scammers also mentions VIP72.\r\nIn this article we will review the proxy mechanism and expose the underlying infrastructure used by the Bunitu\r\nbotnet. We are also sharing indicators of compromise so that end users are able to clean up their computers and no\r\nlonger help to provide free exit nodes for dubious VPN services.\r\nTechnical details\r\nExperiments performed\r\nIn order to confirm our hypothesis regarding the Bunitu proxies we developed our own Bunitu “honeypot”. We\r\nreverse engineered the Bunitu command and control (C2) protocol and developed a script that mimicked the proxy\r\nregistration request.\r\nWe then used the script to register our honeypot to the Bunitu C2 and recorded the URLs of all the requests that\r\nwere subsequently sent to our honeypot. A copy of the honeypot registration script can be found on our GitHub\r\nhere: bunitu_tests.\r\nFindings\r\nAlmost immediately after registering our honeypot we realized that many of the requests we were receiving came\r\nfrom a VPN service known as VIP72.\r\nSince the clients were already connected through a proxy it seemed strange that they would be visiting a second\r\nproxy, so we decided to investigate further. We also shut down the honeypot as we did not want to accidentally\r\nintercept legitimate requests from people who were unaware that they were using a botnet as a proxy.\r\nWe registered an account and logged into VIP72 and were surprised to see our honeypot proxy listed as one of\r\ntheir available exit IP address. Of course this in of itself is not proof that VPIP72 is knowingly using Bunitu botnet\r\nproxies.\r\nIt could be the case that they were scanning the Internet for open proxies (proxies that are listening on the Internet\r\nwithout requiring authentication) and using them to route traffic. However, we noticed a bug in the proxy\r\nregistration system. The IP address that the proxy is initially registered from will be maintained in the VIP72\r\ndatabase as the “HOST” and associated with the proxy, even if the proxy moves to a new IP address.\r\nTo prove that VIP72 is using Bunitu proxies as their exit points, we registered a Bunitu proxy from one IP\r\n(Honeypot #1) then moved it to another IP (Honeypot #2) and registered it again using the same bot ID.\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/08/whos-behind-your-proxy-uncovering-bunitus-secrets/\r\nPage 2 of 10\n\nAs you can see in the VIP72 proxy list, the IP for Honeypot #1 is still listed as the proxy “HOST” with the new IP\r\nfor Honeypot #2 listed  as the current IP.\r\nIf VIP72 was simply scanning the Internet for open proxies it is possible that they would have identified both our\r\nproxies (old and new IP) at different times. However, without having access to the Bunitu C2 server and bot ID\r\nthere is no way that they could have associated those IPs to the same proxy as shown in the screenshot above.\r\nThis is proof that the operators of VIP72 also have direct access to the Bunitu botnet server and use Bunitu\r\ninfected hosts as proxies for their service.\r\nDistributors\r\nOur experiment lead us to the conclusion that distributors are different based on the geolocation of Bunitu infected\r\nmachines.\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/08/whos-behind-your-proxy-uncovering-bunitus-secrets/\r\nPage 3 of 10\n\nIn the US. and Canada, the VPN provider is VIP72, but in Central and Eastern Europe characteristics of the traffic\r\nare entirely different and suggest another VPN provider which we have not been able to pinpoint yet.\r\nOur hypothesis is that the botnet is operated by a middleman who resells a pool of bots to various providers. Then,\r\nthe bots are assigned to particular VPN networks according to their geolocation.\r\nProxy analysis\r\nTwo types of proxies are created on an infected machine:\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/08/whos-behind-your-proxy-uncovering-bunitus-secrets/\r\nPage 4 of 10\n\n1. Standard, by opening ports and passing traffic through them which works if the machine has a public IP\r\naddress.\r\n2. Tunneled, by connecting to C\u0026C #2 and receiving commands through and passing the results back which\r\nworks even if the infected machine has no public IP address.\r\nViewing connections by tcpview, we can see:\r\nFirst 2 connections belong to standard proxies – HTTP and SOCKS (listening at 2 randomly chosen\r\nports).\r\nSecond connection belongs to C\u0026C#2 (in this case: 95.211.15.37) at remote port 53 (tunnel).\r\nConnection initialization process:\r\nAs we mentioned in the previous post about Bunitu, during installation of the Trojan, a unique ID is generated and\r\nstored in the registry: This is an important value sent to the C\u0026Cs and used to identify the particular bot (bot ID).\r\nIt occurs in each and every packet exchanged between the bot and C\u0026C, often in its truncated version containing\r\nonly the first 4 byes, i.e.: fb 1b 70 67 for the above case.\r\nIn short, presence of the relevant key in the packet can be used as proof that the packet belongs to the Bunitu\r\nprotocol.\r\nStandard proxy registration (packet sent to C\u0026C#1):\r\nDetails:\r\n00 01 01 00 00 01 00 00 00 00 00 00 = header (hard coded) 67 ab = socks proxy port (little endian\r\nTunneling proxy registration (packet sent to C\u0026C#2):\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/08/whos-behind-your-proxy-uncovering-bunitus-secrets/\r\nPage 5 of 10\n\nDetails:\r\n0e 00 = Length of the message (little endian) -\u003e 0x00e0 -\u003e 14 fb 1b 70 67 d6 6f c0 9d = bot ID, trunc\r\nCommunication models: standard proxy vs tunnel:\r\nC\u0026C#1 is used to register standard proxies when the clients have a public IP address.\r\nTo keep the connection with C\u0026C#1, the client periodically sends the above registration packet. Due to the fact\r\nthat the infected machine has a public IP, the role of the C\u0026C is simple: To make sure that the bot is ready to\r\nreceive commands.\r\nTo emulate the bot’s behavior, we have implemented the following script: cnc1_test.py. The server is just used to\r\nreceive data from the client, and does not send any special response back and that’s why it is not possible to verify\r\nwhether the given host is a Bunitu C\u0026C#1.\r\nC\u0026C#2 (tunnel) is used when the clients don’t have a public IP\r\nCommunication with the tunnel and keeping the connection alive is more complex, as it involves a custom\r\nprotocol. In this case, the server plays an active and important role: Its responses can be used to test whether a\r\nparticular host is a Bunitu C\u0026C#2. For such a verification, we have created following script: cnc2_test.py\r\nAfter receiving the registration packet, C\u0026C#2 tests the bot by asking it to execute a DNS query:\r\n1. C\u0026C#2 (IP: 95.211.178.145) sends a command to test the connection by querying google.com\r\n2. The bot executes the request by making the DNS query and then testing the connection with the queried\r\nIP 216.58.209.70 that belongs to google.com\r\n3. The bot reports success (or failure) to C\u0026C#2 (IP: 95.211.178.145)\r\n4. C\u0026C#2 confirms receiving the report\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/08/whos-behind-your-proxy-uncovering-bunitus-secrets/\r\nPage 6 of 10\n\nPackets exchanged between C\u0026C#2 (blue) and bot (red) during this test:\r\nEvery packet exchanged between C\u0026C#2 and a bot is prompted by a DWORD containing the length of the data\r\nthat follows it (little endian). After that, there is the bot ID (truncated to first 4 bytes).\r\nThe 6-th DWORD (marked red) packet can have the following meanings:\r\n01 00 00 01: “test the given domain”\r\n01 00 02 01: “bot reporting: domain tested”\r\n04 00 02 00: “report accepted”\r\nThe 8-th DWORD (marked purple) is the socket number via which the bot performed a request (to google)\r\nThe 9-th DWORD (marked yellow) is a unique value generated by the C\u0026C#2\r\nThe bot tests the connection with google, and then builds the response for the C\u0026C#2 (based on the request and\r\nchanging the appropriate fields):\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/08/whos-behind-your-proxy-uncovering-bunitus-secrets/\r\nPage 7 of 10\n\nTunneling communication process for the client\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/08/whos-behind-your-proxy-uncovering-bunitus-secrets/\r\nPage 8 of 10\n\nREQUEST (C\u0026C#2 to bot) The tunneled C\u0026C receives the requests from the connected clients. It wraps them in\r\nthe internal protocol and sends them to an infected machine.\r\n1. C\u0026C#2 (IP: 95.211.178.145) gives an order to make a particular request (demanded by the proxy user)\r\n2. The bot performs the request\r\nRESPONSE (bot to C\u0026C#2) The infected machine carries out the requested operations and its IP address is\r\nvisible from the outside. After fetching the results, it packs them in the internal protocol and sends them back to\r\nthe C\u0026C (tunnel).\r\n1. The bot gets the response from the appropriate server\r\n2. The bot passes the response to C\u0026C#2 (IP: 95.211.178.145), wrapped in the internal protocol and then\r\nC\u0026C#2 passes it to the proxy user\r\nDuring the communication process, C\u0026C#2 may request the bot to connect to additional IPs.\r\nHere is a command from C\u0026C#2 instructing the bot to connect to a new IP and setup the tunnel SOCKS proxy:\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/08/whos-behind-your-proxy-uncovering-bunitus-secrets/\r\nPage 9 of 10\n\nDetails:\r\n15 00 00 00 - message size 33 - command for “connect to new IP” 42 c7 e5 fb - new IP address (little\r\nConclusion\r\nBunitu shows us how versatile malware can be, especially when compromised systems are tied together towards\r\nthe same goal. While we have analyzed its main components, there is still much more that is unknown about this\r\nthreat and in particular the extent of its reach or the list of VPN providers using it.\r\nWe hope that this research will help others to identify Bunitu related infections and eventually reduce the size of\r\nthe botnet. We also invite security firms and law enforcement to get in touch with us via the contacts provided\r\nbelow so we can share with them additional intelligence.\r\nAnalyzed samples:\r\nOriginal sample (installer) md5=542f7b96990de6cd3b04b599c25ebe57 ; payload (ynfucvu.dll)\r\nmd5=1bf287bf6cbe4d405983d1431c468de7\r\nOriginal sample (installer) md5=ac4e05a013705fd268e02a97c15d6f79 ; payload (lyhbyjo.dll)\r\nmd5=b71832a8326b598208f49bf13e5b961f\r\nWe would like to thank the following contributors to this report:\r\nSentrant: Sergei Frankoff\r\nMalwarebytes: hasherezade\r\nSource: https://blog.malwarebytes.com/threat-analysis/2015/08/whos-behind-your-proxy-uncovering-bunitus-secrets/\r\nhttps://blog.malwarebytes.com/threat-analysis/2015/08/whos-behind-your-proxy-uncovering-bunitus-secrets/\r\nPage 10 of 10", "extraction_quality": 1, "language": "EN", "sources": [ "Malpedia" ], "references": [ "https://blog.malwarebytes.com/threat-analysis/2015/08/whos-behind-your-proxy-uncovering-bunitus-secrets/" ], "report_names": [ "whos-behind-your-proxy-uncovering-bunitus-secrets" ], "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 } ], "ts_created_at": 1775434440, "ts_updated_at": 1775791431, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/df858a4dee0e6411d67fa6cc0add1455a7522239.pdf", "text": "https://archive.orkl.eu/df858a4dee0e6411d67fa6cc0add1455a7522239.txt", "img": "https://archive.orkl.eu/df858a4dee0e6411d67fa6cc0add1455a7522239.jpg" } }