VB2014 paper: Hiding the network behind the network. Botnet proxy business model


Alexandru Maximciuc

Bitdefender, Romania

Razvan Benchea

Bitdefender, Romania

Cristina Vatamanu

Bitdefender, Romania
Editor: Martijn Grooten


Since hiding a C&C means that a botnet will remain running for longer, specialized hosting services that are able to hide a server behind many proxies have appeared. In their VB2014 paper, Alexandru Maximciuc, Cristina Vatamanu and Razvan Benchea describe a proxy network with two types of redirection: one on the HTTP standard port (protecting the C&C servers) and the other on the UDP standard port (protecting a dedicated server that handles the DNS resolution for domains generated by Domain Generation Algorithms or chosen at will).


Over the years, botnet creators have implemented various methods for protecting their networks and especially their command and control (C&C) servers. Since hiding the C&C server usually means that a botnet will remain active for longer, there exist specialized hosting services that are able to hide a server behind many proxies.

During one of our investigations, we discovered a network of this type, which at the time of writing this paper has 10 ‘clients’ (i.e. 10 servers distributing different malware families). This proxy network has two types of redirection: one on the HTTP standard port (protecting the C&C servers) and the other on the UDP standard port (protecting a dedicated server that handles the DNS resolution for domains generated by Domain Generation Algorithms or chosen at will).

This infrastructure is designed in such a way as to allow critical changes to be made in the shortest time possible, so any abuse report regarding the proxy nodes is handled immediately. The so called ‘cleaning’ is done by making some minor changes to the configuration of the proxy nodes. This is usually achieved by changing the proxies between clients. Therefore the financial loss caused by interruption of the malware distribution, is minimized.

In this paper, we will describe the architecture of this network and the changes made during the time we have been monitoring it. We will also present some examples of malware families that make use of it.

General infrastructure

This network model has at least two levels of proxies protecting the real C&C servers. Currently, it has 10 ‘clients’, serving different types of malware to unsuspecting users. Each client has its own set of machines, responsible for handling the UDP traffic. They act as name servers for that specific client and its corresponding HTTP traffic. The infrastructure is designed in such a way as to hide the real C&C servers and to easily be able to apply changes, when needed.

Figure 1 shows the components of the infrastructure.

Network’s general infrastructure.

Figure 1. Network’s general infrastructure.

Proxy level 1

Proxy level 1 is responsible for redirecting the UDP traffic (on port 53) and the HTTP traffic (on port 80). Figure 2 shows the way in which redirection works, using the ‘client 4’ as an example. A user, infected with a piece of malware spread by client 4, tries to connect to a domain, dX. The machines used in the first level of the proxy are set as authoritative name servers for these domains. So, any DNS resolution request for the dX domain arrives here. All the traffic received on port 53 is redirected to a central DNS server. The port used for this redirection is BASE_PORT + client_id, where BASE_PORT is a high number. This approach enables the central DNS server to differentiate between the clients. This server responds with four active IPs, randomly chosen from the list of IP addresses allocated to the current client. The victim’s computer chooses one of these IP addresses (IP 4n in Figure 2) and sends an HTTP request to the machine corresponding to it. This machine will redirect the request on a machine from the second level proxy, usually on port 80.

DNS and HTTP redirections (BP=BASE_PORT).

Figure 2. DNS and HTTP redirections (BP=BASE_PORT).

At the time of writing this paper, this network has 10 clients. When we discovered the network, it had one inactive client and eight active clients, called ‘ozerside’, ‘special’, ‘owner’, ‘nobody_xxx’, ‘owl’, ‘eclipse’, ‘curl’ and ‘victor’ (see Table 1). Around 23 November 2013, the ninth client was activated under the name ‘Lee(iq)’ (see Table 2), and on 20 February 2014 the 10th client was added, without a name (see Table 3).

UIDHTTP botsDNS botsHTTPPortCommentActionDNS statUsed bots
12 (3 up)2 (3 up)ip_server_180ozerside[Edit][Show]26075
22 (1 up)2 (2 up)ip_server_218230special[Edit][Show]28586
32 (2 up)2 (2 up)ip_server_380owner[Edit][Show]25907
42 (2 up)2 (2 up)ip_server_480nobody_xxx[Edit][Show]7502
52 (2 up)2 (2 up)ip_server_580owl[Edit][Show]13917
62 (2 up)2 (2 up)ip_server_680eclipse[Edit][Show]3866
72 (3 up)2 (2 up)ip_server_780curl[Edit][Show]1136
82 (1 up)2 (1 up)ip_server_880victor[Edit][Show]3778
90 (0 up)0 (0 up) [Edit][Show]4646

Table 1. ‘Clients’ list when we discovered the network.

UIDHTTP botsDNS botsHTTPPortCommentActionDNS statUsed bots
12 (3 up)2 (3 up)ip_server_180ozerside[Edit][Show]26075
22 (1 up)2 (2 up)ip_server_218230special[Edit][Show]28586
32 (2 up)2 (2 up)ip_server_380owner[Edit][Show]25907
42 (2 up)2 (2 up)ip_server_480nobody_xxx[Edit][Show]7502
50 (0 up)0 (0 up)ip_server_580owl[Edit][Show]13917
62 (2 up)2 (2 up)ip_server_680eclipse[Edit][Show]3866
72 (3 up)2 (2 up)ip_server_780Curl[Edit][Show]1136
82 (1 up)2 (1 up)ip_server_880victor[Edit][Show]3778
92 (2 up)2 (2 up)ip_server_92224Lee(iq)[Edit][Show]4646

Table 2. ‘Clients’ list late November 2013.

UIDHTTP botsDNS botsHTTPPortCommentActionDNS statUsed bots
12 (3 up)2 (3 up)ip_server_180ozerside[Edit][Show]3
100 (0 up)0 (0 up) [Edit][Show]0
22 (1 up)2 (2 up)ip_server_218230special[Edit][Show]5
32 (2 up)2 (2 up)ip_server_3806504650[Edit][Show]10
40 (0 up)0 (0 up)[Edit][Show]0
52 (2 up)2 (2 up)ip_server_580owl[Edit][Show]1
60 (0 up)0 (0 up)ip_server_680dokben, 777[Edit][Show]0
72 (3 up)2 (2 up)ip_server_780rxtitans[Edit][Show]1
82 (1 up)2 (1 up)ip_server_880victor[Edit][Show]1
90 (0 up)0 (0 up) [Edit][Show]0

Table 3. ‘Clients’ list late February 2014.

Table 1, Table 2 and Table 3 illustrate information displayed by the ‘users.php’script located on the central DNS server.

We noticed that some changes had also been made to other clients: client 4 is now called ‘demien (otkaz)’ and is no longer active; clients 6 and 7 changed their names to ‘dokben, 777’ and ‘rxtitans’, respectively.

With the help of some local authorities we managed to analyse some data. An encrypted binary file (ELF) named ‘map’ gave us an insight into the network. The decryption uses the waterfall technique: 13 areas are decrypted, and each decryption depends on the previous one through an index table.

The last area is a bash script that has two main functionalities:

  1. Self-update

  2. Update for service.xml, the service responsible for traffic redirection.

The self-update procedure is very simple. The updated binary file is downloaded via a request to http://IP_MAP_UPDATE/update. Integrity checks are performed using MD5 hashes. The MD5 hash for the binary file is also retrieved from the same link. The bash script checks the data consistency (that is, whether the computed MD5 for the freshly downloaded file is the same as the retrieved one). The next step is to find out whether an update is necessary. If the MD5 for the downloaded binary file differs from the MD5 for the existing binary file, then the old version is replaced with the new one and the process is restarted.

The second functionality is very similar. Through a request to http://IP_DNS_SERVER/<file1>?ip=<currentMachineIP>, an xml file is downloaded and saved, temporarily, as ‘service.xml’. The file contains rules for UDP and HTTP forwarding, as can be seen in Figure 3. The IP used for this update is the IP for the central DNS server. The xml file is parsed, the extracted ‘tunnelling’ rules are applied in the system, and the services affected by those rules (nginx and 3proxy) are restarted.

The structure of the service.xml file is illustrated in Figure 3.

Service.xml file (BP=BASE_PORT).

Figure 3. Service.xml file (BP=BASE_PORT).

We noticed that every UDP request is redirected to the central DNS server. The UDP traffic is forwarded to the port BASE_PORT + client_id and, in this way, the DNS server can identify which client sent the request.

The DNS server will respond with a list of IPs corresponding to the identified client, a list of four IPs, not necessarily unique and not necessarily the same for different queries (as mentioned previously, a random list of active IPs). The infected computer will choose one of the IP addresses and send an HTTP request that will be redirected by the level 1 proxy to the IP specified in service.xml for the HTTP protocol. Usually, the value for ‘to_port’ is 80, but it can vary (for example, ‘client 2’ was assigned an HTTP port with value 18230), as we can see from the clients management interface illustrated in Figure 4. The HTTP traffic is actually redirected to an IP from the second proxy layer.

Traffic tunnelling (BP=BASE_PORT).

Figure 4. Traffic tunnelling (BP=BASE_PORT).

Central DNS server

The DNS server has three main roles: it resolves DNS queries, as discussed in the ‘Proxy Level 1’ section; it serves updates for service.xml; and it represents the management interface for all the clients.

During our investigation we have been monitoring the ‘map’ file updates for proxy level 1 machines, and we have observed the DNS server being moved from one machine to another. With the help of the local authorities, we managed to gather information about the old server. A collection of PHP scripts was analysed, most of which were related to a management interface.

These files were divided in three main categories: admin, checker and system, as can be seen in Figure 5.

Directory tree from central DNS server.

Figure 5. Directory tree from central DNS server.


Most of the PHP scripts from the admin section have the role of managing the system by implementing the CRUD operations (create, read, update and delete) for all the entities used. The most important PHP scripts are ‘domain.php’, ‘user.php’ and ‘index.php’.

The ‘index.php’ script (Table4) handles the data for the servers corresponding to the proxy level 1 machines. It allows the deleting, editing and displaying of different information regarding the servers corresponding to the infected bots, such as their IP addresses, the country where they are located, the period of time elapsed since their last valid response, clients they are assigned to, etc. Table 5shows a snapshot of the information displayed.

DelDelete IP from servers.
EditEdit IP from servers.
<without parameters>Prints the number of online bots and the number of active HTTP and DNS servers. For each IP it shows: country, IP, HTTP, DNS, speed, ping, loss, UpTime, LastCheck, Other, UID, actions.

Table 4. Parameters for the index.php script.

CountryIPHTTPDNSSpeedPingLossUpTimeLastCheckUID Action
UkraineIP1offoff00021 days 21 hours 7 mins 54 secs 2013-11-22 14:50:476[Delete][Edit]
RussiaIP2onon26493018 days 34 mins 20 secs 2013-11-22 14:52:057[Delete][Edit]

Table 5. Information about servers from the first level of proxy.

The ‘users.php’ script is used to add, edit or show information regarding the clients from the network. The parameters are described in Table 6. Each client has a corresponding file (‘users/%uid%’, where uid is the client id). These files contain the client’s name, the IP for the second-level proxy server that handles the HTTP traffic for that client, the port for the HTTP communication, and so on. This script uses and saves information in these files and in the MySQL database in the ‘servers’ table.

edit<sent>Parameters: HTTP (no. of HTTP bots), DNS (no. of DNS bots), IP, port and comment, received through POST, are saved in users/%uid% (where %uid% is the client ID received through GET) and showed on the web page.
editGets the previously mentioned parameters for the received %uid%, shows them on the web page, and allows their actualization.
add<sent>Parameters: HTTP (HTTP bots), DNS (DNS bots), IP, port and comment, received through POST, are saved in users/%uid% and showed on the web page.
addDisplays, on the web page, a form that allows the saving of information for the new client.
dns-statDisplays, on the web page, statistics for a certain client for the current day and month.
<without parameters>Shows on the web page information for all the clients.

Table 6. Parameters for the users.php script.

The ‘domain.php’ script is used to manage the data regarding the assigned domains (Table 7). It allows the deleting, adding and displaying of information about them. The registration of a domain is done automatically through the cnobin.com service. Table 8 shows the information displayed on the web page by domains.php.

DelDeletes the domain.
add<sent>If the ‘sent’ parameter is used, it will register domains through cnobin.com and insert the data (domain, uid, type, ns1, ns2, ns3, ns4) into the database (domains table).
addDisplays a form that allows data to be submitted as domain, uid, ns1, ns2, ns3, ns4.
<without parameters>Displays information about all the domains registered in the database (domain table).

Table 7. Parameters for the domains.php script.

Domain80 portHoldingUIDTypeNSAction
domain_1OnOn22ns1: ip_1 ns2: ip_1 ns3: ip_1 ns4: ip_1 [Del]
domain_2OnOn22ns1: ip_2 ns2: ip_2 ns3: ip_2 ns4: ip_2 [Del]
domain_3OnOn22ns1: ip_3 ns2: ip_3 ns3: ip_3 ns4: ip_3 [Del]

Table 8. Information about the registered domains.


These scripts are responsible for checking some of the characteristics of the servers from the proxy level 1 network, such as the state (on/off) and the speed (Table 9). These characteristics are updated in the ‘servers’ table in the MySQL database. For example, ‘checker.php’ checks whether the bots are responding in a specific way. If yes, they are ‘on’; otherwise they are ‘off’.

Column (servers)Setting conditions
http[on/off] if a certain request answers with a message containing %http_test_msg%, then it sets the column to on, otherwise it is set to off.
dns[on/off] if a certain request answers with a message containing %dns_test_ip%, then the column is set to on, otherwise it is set to off.
http_goodIf http is [on], and the values for ping and speed are within a certain range (ping and speed are computed with Net/Ping.php), then the column is set to [on], otherwise it is set to [off].
dns_goodIf dns is [on], and the values for ping and speed are within a certain range (ping and speed are computed with Net/Ping.php), then the column is set to [on], otherwise it is set to [off].

Table 9. Parameters for the checker.php script.


Here, we found scripts for RC4 encryption and decryption, config files, and scripts that delete from the database the servers that have an ‘expired’ LastCall (where the time elapsed since the last valid response is greater than a certain timeout).

We also found the template file for the service.xml update (Figure 6).

Template for the service.xml file.

Figure 6. Template for the service.xml file.

Abuse reports

This complex network architecture proves to be very effective in the case of abuse reports. We submitted two types of abuse report, and on each occasion the network recovered very quickly.

The first type of abuse report was related to the servers from the first proxy level. This issue can be resolved only by switching between users’ IP lists. This change is made in the central DNS server, in the ‘servers’ table of the MySQL database. An update for the service.xml file is also provided to the affected machines in order for them to change IP addresses for the HTTP redirection (Figure 7).

Solution for recovering from abuse reports.

Figure 7. Solution for recovering from abuse reports.

The second type of abuse report is related to the IPs corresponding to the second level of proxies. The events we observed in this case did not last more than 24h, so the downtime for the malware is very small. Usually, after the abuse is reported, the machine is stopped (it doesn’t respond as it should), but after approximately three to four hours, a new IP appears in the system and, in less than 24 hours, the malware is back in business. The changes needed consist of modifying some data from the central DNS server and a service.xml file update. On the central DNS server, in the client’s corresponding file (‘users/%uid%’), the old IP is replaced with the new one. Also, all the clients from the first-level proxy, that redirected the HTTP traffic to the affected IP, will receive a new service.xml file, updated with the new IP.


Malware families served by these clients include CryptoLocker, Citadel, FakeAVs, Casino, and various scams.


This network is very dynamic – IP addresses are moved from one user to another, new IP addresses are added, and old IP addresses are removed. The charts shown in Figure 8 and Figure 9 illustrate the IP changes that occurred on the first proxy level during the period in which we were monitoring the network.

Number of IPs added weekly.

Figure 8. Number of IPs added weekly.

Number of IPs removed weekly.

Figure 9. Number of IPs removed weekly.

A map for the proxy level 1 IP addresses in November 2013 is illustrated in Figure 10. There were four serves in the Ukraine, 12 in Russia, and five in Kazakhstan.

Servers added in November 2013.

Figure 10. Servers added in November 2013.

In January 2014, they extended their business to the United States (Figure 11). In February 2014, they added a server in Germany (Figure 12). In May 2014, a new server appeared in the Netherlands (Figure 13).

Servers added in January 2014.

Figure 11. Servers added in January 2014.

Servers added in February 2014.

Figure 12. Servers added in February 2014.

Servers added in May 2014.

Figure 13. Servers added in May 2014.

(Click here for a larger view of Figure 13.)

A map illustrating all the IPs which passed through the system during our investigation is shown in Figure 14.

Servers map from November 2013 to May 2014.

Figure 14. Servers map from November 2013 to May 2014.

(Click here for a larger view of Figure 14.)


This network has proven to be well thought out and maintained. The structure hides the real C&C servers very well and has the ability to recover from abuse reports in less than 24 hours. It has a great dynamic, adding new servers and removing old ones almost every day. It also seems to be very well known among malware creators, who use if for distributing various types of malware.

We are currently continuing our investigation in order to find all the nodes of the network with the aim of taking them down.



Latest articles:

Nexus Android banking botnet – compromising C&C panels and dissecting mobile AppInjects

Aditya Sood & Rohit Bansal provide details of a security vulnerability in the Nexus Android botnet C&C panel that was exploited to compromise the C&C panel in order to gather threat intelligence, and present a model of mobile AppInjects.

Cryptojacking on the fly: TeamTNT using NVIDIA drivers to mine cryptocurrency

TeamTNT is known for attacking insecure and vulnerable Kubernetes deployments in order to infiltrate organizations’ dedicated environments and transform them into attack launchpads. In this article Aditya Sood presents a new module introduced by…

Collector-stealer: a Russian origin credential and information extractor

Collector-stealer, a piece of malware of Russian origin, is heavily used on the Internet to exfiltrate sensitive data from end-user systems and store it in its C&C panels. In this article, researchers Aditya K Sood and Rohit Chaturvedi present a 360…

Fighting Fire with Fire

In 1989, Joe Wells encountered his first virus: Jerusalem. He disassembled the virus, and from that moment onward, was intrigued by the properties of these small pieces of self-replicating code. Joe Wells was an expert on computer viruses, was partly…

Run your malicious VBA macros anywhere!

Kurt Natvig wanted to understand whether it’s possible to recompile VBA macros to another language, which could then easily be ‘run’ on any gateway, thus revealing a sample’s true nature in a safe manner. In this article he explains how he recompiled…

Bulletin Archive

We have placed cookies on your device in order to improve the functionality of this site, as outlined in our cookies policy. However, you may delete and block all cookies from this site and your use of the site will be unaffected. By continuing to browse this site, you are agreeing to Virus Bulletin's use of data as outlined in our privacy policy.