The theory of building large p2p botnets
#1
The theory of building large p2p botnets

Credits: pest
Issue: 2013
Source: Inception E-Zine


P2p botnet sounds truly grandiose. Many people think that only pros are capable of creating such a botnet. The truth is, the most important thing you need is to understand the theory of p2p, which is unbelievably simple.

The main objective is to connect IP bots and pass commands from bot to bot.

Architectures:

1. Temporary node exchange (ip of bots).
Every bot has a table stored (routing table) with the following structure:

Code [Expanded]:

struct NODE{
uint32 ip;
uint16 port;
uint32 time;
};

where 'ip' stands for the bot IP, 'time' is the time the bot was added, 'port' is the port.

Let the table be limited to the size of 255 elements NODE [255]; It means that the bot will have the maxim of 255 neighbors. The table contains unique IPs and is arranged by time. This can be done with the help of the qsort function.

Code:
8.5.1.2 - 10:55:10 01.09.2013
1.5.1.2 - 10:53:10 01.09.2013
1.1.1.2 - 10:53:01 01.09.2013
1.1.1.2 - 06:33:10 01.09.2013
....

The bot "looks at" the table, extracts elements subsequently and sends messages with requests for a new list. The bot receiving this kind of message responds with current IPs (from the top of the table). It does not send all 255 IPs though, rather than a few, for example, 10 elements NODE[10]; The bot that initialized the request for a new IP list gets these NODE[10] and checks if they are on its list. If they are, it updates the time. If they aren't, it adds the new ones. If the table is full (with 255 elements), it updates the 'oldest' element.

That way, a constant exchange of IPs is supported. Only current IPs are added to the table. As time for transferring IPs between bots, it's best to use delta time_delta=now()-time, where now() is current time (to avoid certain attacks related to transferring the "excessive" time value).

The entire network represents one large segment that has time as its coordinates, so the entire network approaches current time.
We can distinguish ZAccess as a real example of such a network. It uses the same p2p network architecture as described above.

2. Exchange of nodes by distance (distributed hash tablets DHT)
Every bot has a routing table:
Code:
struct NODE{
uint8 nid[16]; //ID of node (bot)
uint32 ip; //IP
uint16 port; //port
uint32 time; //time
};

The number of elements is limited by NODE[255]. When installed, every bot generates an ID and remembers it, it's a nid, for example, 0x00000000000000000000000000000004.
When exchanging nodes, the bot adds to the routing table only nids close to it. Only then it's guided by the time.

For example, there is a list:
Code:
0x00000000000000000000000000000000
0x00000000000000000000000000000001
0x00000000000000000000000000000002
0x00000000000000000000000000000003
0x00000000000000000000000000000005
0x00000000000000000000000000000006
0x00000000000000000000000000000007
0x00000000000000000000000000000008

The following will be the closest to 0x00000000000000000000000000000004:
Code:
0x00000000000000000000000000000003 (4-3) = 1
0x00000000000000000000000000000005 (5-4) = 1
0x00000000000000000000000000000002 (4-2) = 2
0x00000000000000000000000000000006 (6-4) = 2

etc

To work with close nids, their ranges have to be somehow calculated to be put into order later. For that, a bit-to-bit (byte-to-byte) XOR operation is used. Let's see what happens if we XOR the list by 0x00000000000000000000000000000004:
Code:
(0x00000000000000000000000000000000^0x00000000000000000000000000000004)=0x00000000000000000000000000000004
(0x00000000000000000000000000000001^0x00000000000000000000000000000004)=0x00000000000000000000000000000005
(0x00000000000000000000000000000002^0x00000000000000000000000000000004)=0x00000000000000000000000000000006
(0x00000000000000000000000000000003^0x00000000000000000000000000000004)=0x00000000000000000000000000000007
(0x00000000000000000000000000000004^0x00000000000000000000000000000004)=0x00000000000000000000000000000000
(0x00000000000000000000000000000005^0x00000000000000000000000000000004)=0x00000000000000000000000000000001
(0x00000000000000000000000000000006^0x00000000000000000000000000000004)=0x00000000000000000000000000000002
(0x00000000000000000000000000000007^0x00000000000000000000000000000004)=0x00000000000000000000000000000003
(0x00000000000000000000000000000008^0x00000000000000000000000000000004)=0x0000000000000000000000000000000С

Arrange by result:
Code:
(0x00000000000000000000000000000004^0x00000000000000000000000000000004)=0x00000000000000000000000000000000
(0x00000000000000000000000000000005^0x00000000000000000000000000000004)=0x00000000000000000000000000000001
(0x00000000000000000000000000000006^0x00000000000000000000000000000004)=0x00000000000000000000000000000002
(0x00000000000000000000000000000007^0x00000000000000000000000000000004)=0x00000000000000000000000000000003
(0x00000000000000000000000000000000^0x00000000000000000000000000000004)=0x00000000000000000000000000000004
(0x00000000000000000000000000000001^0x00000000000000000000000000000004)=0x00000000000000000000000000000005
(0x00000000000000000000000000000002^0x00000000000000000000000000000004)=0x00000000000000000000000000000006
(0x00000000000000000000000000000003^0x00000000000000000000000000000004)=0x00000000000000000000000000000007
(0x00000000000000000000000000000008^0x00000000000000000000000000000004)=0x0000000000000000000000000000000С

You can arrange with the help of qsort function because the number of elements in our tables is not too large. However, if you are planning to use large routing tables, you should use the binary tree.

That way, every bot accumulates nids that are the closest to it, breaking the network into a multitude of segments whose number equals the number of bots.

The Zeus GameOver (P2P) network is a real example of how it works.
You can perform a nid search in such a network. If you associate, say, a file with a nid, you can also perform a search for a specific file. Let's say md5 h1 is calculated from the file (just the 16 bytes for our example). In the routing table, a nid close to h1 is searched for (or several ones, because not all nodes may be online) and a request to the list of close nids with h1 request is made. A remote node received this request and searches its list for nids close to h1, sending them back. After a few of such requests, if the distance decreases, nid^h1 can exceed a certain value. You can consider the file found and execute a request to download the file from the node. This is how files are searched for in KAD networks.

Files in p2p network:
The types of files reviewed above connect bots between themselves, although this happens in different ways. This means that bots can send messages to their "neighbors". Files can be such messages. If you upload a file to one bot, it can pass it to its neighbors, and they will pass it on to their neighbors etc. until the file is disseminated across the network.

That file can also be a bot update, another bot, a configuration file. Remember to such your files with an e-signature (private key), and the bot will check it with its public key upon receipt. Then your bot will know you were the one that signed it. Otherwise, your botnet will be hijacked very soon…

Tunnels (proxy):
You may have noticed from the information above that this kind of network does not have a command center, while it would be good to have one, to gather statistics on bots, form grabber data, web injects etc. This command center should also be concealed behind the nodes.

To implement this idea, you can enable every bot to tunnel traffic.
  1. The botmaster selects from the list of bots those that will be tunneling traffic;
  2. the botmaster connects to them and sends a packet signed with its e-signature containing IPcc:PORTcc of its CC, that way tuning the bot into a tunnel;
  3. a configuration is created in which the botmaster signs IPproxy:PORTproxy (the bot it turned into a tunnel) with its e-signature;
  4. the configuration is sent throughout the network the standard way, just like a usual file.
The bots start going to the tunnel that sends packets to CC.

[Image: IknO03y.png]

Usually, the UDP protocol is used to exchange IP lists, while TCP is used to download/upload files, for TCP tunnels.

Good luck with bot-building.
Reply
#2
Thanks for sharing, this is awesome and I would like to start writing this as a programming exercise even though I will probably never need it anyways.
But I have some questions: This requires opening ports, how is that supposed to be done? Most devices hide behind a router with a firewall that will not forward inbound connections unless configured otherwise and UDP hole punching would require a dedicated P2P server, which would kind of defeat the whole purpose of P2P botnets in the first place.
Assuming there is a workaround for this and I really start building such a system, how would I test this without dozens of VMs? Is there anything that would run a little lighter? I think of something like a network simulation that only runs single applications on the virtual network nodes, instead of an OS plus these applications. Anything that will run on consumer hardware and wouldn't require me to buy a server to run many VMs would be fine I guess.
Reply
#3
(01-24-2021, 10:21 AM)chios Wrote: Thanks for sharing, this is awesome and I would like to start writing this as a programming exercise even though I will probably never need it anyways.
But I have some questions: This requires opening ports, how is that supposed to be done? Most devices hide behind a router with a firewall that will not forward inbound connections unless configured otherwise and UDP hole punching would require a dedicated P2P server, which would kind of defeat the whole purpose of P2P botnets in the first place.
Assuming there is a workaround for this and I really start building such a system, how would I test this without dozens of VMs? Is there anything that would run a little lighter? I think of something like a network simulation that only runs single applications on the virtual network nodes, instead of an OS plus these applications. Anything that will run on consumer hardware and wouldn't require me to buy a server to run many VMs would be fine I guess.

You can run a docker cluster which is relatively light on resources as a stand-in for VMs in order to get the most bang for your buck. Resources wise. Also, ICMP is good protocol for Malware communications look into Samy Kamkar's `pwnat` for an example of using ICMP to defeat NAT. HTTPS, would be good as well as the data has a good chance of passing for regular web traffic that way.
Reply
#4
(01-26-2021, 10:31 AM)Vector Wrote: You can run a docker cluster which is relatively light on resources as a stand-in for VMs in order to get the most bang for your buck. Resources wise.
Damn, this is pretty obvious, I don't know how I didn't come up with that myself. Thank you Vector.
(01-26-2021, 10:31 AM)Vector Wrote: Also, ICMP is good protocol for Malware communications look into Samy Kamkar's `pwnat` for an example of using ICMP to defeat NAT.
Thanks, the man page was a super interesting read and if I find the time I will try looking into the whitepaper. But according to this StackOverflow answer from 2016 pwnat doesn't work with modern standards any longer. I can also see how this sort of traffic could be filtered easily if a somewhat advanced firewall is installed in the system. But it is a very interesting concept nevertheless and I wonder if there are other projects like this.
(01-26-2021, 10:31 AM)Vector Wrote: HTTPS, would be good as well as the data has a good chance of passing for regular web traffic that way.
But that would require some sort of hole punching or c2c server again to work, right? I can't see how https alone can help with establishing p2p connections without being able to open ports.
Reply
#5
I am not quite sure what you mean by 'hole punching'. The mechanism by which P2P communication takes place is through tunneling from one host to another, you can tunnel all kinds of protocols. Insider's post only speaks to the networking infrastructure of a P2P botnet. Now a complete malware will have a lot of other components on top of what has been discussed so far. Including ways to establish tunnels. Obviously each bot will need to be bound to an interface on target, but if you take utilities such as stunnel, ptunnel and proxyconnect into account, and code a bot that has the same capabilities as those linux utilities, you are basically already half-way there.

Like was stated in the OP as well, having some sort of C2 could actually be desirable, not to mention you can configure different nodes to do different things. Some may serve as proxy servers, others will be specifically for tunneling.

How you go about deploying and spreading your malware, will factor into the tunneling capabilities as well. It would be mostly dependent on the TTPs you know and have access to which could of course include an exploit that takes advantage of a vulnerability in the utilities i mentioned themselves.

Also to clarify. The reference to the `pwnat` utility was more for illustrative purposes and meant as a reference point. I actually have a Reverse ICMP Shell targeting Windows in development over at our Github Organization.
Reply
#6
(01-26-2021, 06:43 PM)Vector Wrote: I am not quite sure what you mean by 'hole punching'.
https://en.wikipedia.org/wiki/Hole_punch...etworking)
(01-26-2021, 06:43 PM)Vector Wrote: The mechanism by which P2P communication takes place is through tunneling from one host to another, you can tunnel all kinds of protocols. Insider's post only speaks to the networking infrastructure of a P2P botnet. Now a complete malware will have a lot of other components on top of what has been discussed so far. Including ways to establish tunnels.
Yes, perhaps my question was a little beyond the scope of this thread, but this problem was the first thing that came to my mind when reading the OP.
(01-26-2021, 06:43 PM)Vector Wrote: Like was stated in the OP as well, having some sort of C2 could actually be desirable, not to mention you can configure different nodes to do different things. Some may serve as proxy servers, others will be specifically for tunneling.
Sure, but the C2 server described in the OP would appear and act like a node in many ways, as you said. But a typical server that would be used for setting up P2P connections for clients behind a NAT need to be just like your typical C2 server: with a static IP that needs to be hardcoded somewhere in your code. That's at least if no other method of getting the connection between the peers, such as pwnat, is possible.
(01-26-2021, 06:43 PM)Vector Wrote: How you go about deploying and spreading your malware, will factor into the tunneling capabilities as well. It would be mostly dependent on the TTPs you know and have access to which could of course include an exploit that takes advantage of a vulnerability in the utilities i mentioned themselves.

Also to clarify. The reference to the `pwnat` utility was more for illustrative purposes and meant as a reference point. I actually have a Reverse ICMP Shell targeting Windows in development over at our Github Organization.
I still have very limited knowledge of networking and even less knowledge of windows, so I guess it would be pointless for me to look at the source of this. But this thread and especially your replies have led me to looking various stuff up and learning some new things in the process, so thanks a lot for that. Perhaps I should read a book on networking, is there anything that goes through networking basics and possibly also some implementations in C?
Reply
#7
(01-27-2021, 10:38 AM)chios Wrote: Perhaps I should read a book on networking, is there anything that goes through networking basics and possibly also some implementations in C?

https://beej.us/guide/bgnet/
But I personally used https://www.packtpub.com/product/hands-o...1789349863 recently to brush up and it was pretty good.
Reply
#8
(01-27-2021, 05:50 PM)poppopret Wrote:
(01-27-2021, 10:38 AM)chios Wrote: Perhaps I should read a book on networking, is there anything that goes through networking basics and possibly also some implementations in C?

https://beej.us/guide/bgnet/
But I personally used https://www.packtpub.com/product/hands-o...1789349863 recently to brush up and it was pretty good.
Thank you! Especially the Beej's guide looks perfect to get me started, it is not too long but covers many topics. Maybe I will skim through Hands-On Network Programming with C afterwards, the table of contents lets me assume that it covers more examples of protocol implementations.
Reply
#9
(01-28-2021, 10:27 AM)chios Wrote:
(01-27-2021, 05:50 PM)poppopret Wrote:
(01-27-2021, 10:38 AM)chios Wrote: Perhaps I should read a book on networking, is there anything that goes through networking basics and possibly also some implementations in C?

https://beej.us/guide/bgnet/
But I personally used https://www.packtpub.com/product/hands-o...1789349863 recently to brush up and it was pretty good.
Thank you! Especially the Beej's guide looks perfect to get me started, it is not too long but covers many topics. Maybe I will skim through Hands-On Network Programming with C afterwards, the table of contents lets me assume that it covers more examples of protocol implementations.

I wanted to mention that if you would like to have a look at the source code of my Reverse ICMP Shell, send me a PM and i will send you the source code. If you think it'd be helpful, i wouldn't mind sharing.
Reply


Possibly Related Threads…
Thread Author Replies Views Last Post
  Future of Botnets 2021? Majin-Buu 5 7,800 01-06-2021, 05:12 PM
Last Post: poppopret