800+ IT
News
als RSS Feed abonnieren📚 Exploring Peer to Peer Botnets
💡 Newskategorie: Video
🔗 Quelle: malwaretech.com
Peer to Peer and Everything In between
Back in October I'd gotten bored of the endless stream of cryptolockers and PoS trojan, so decided to look at something old school, that something was Kelihos. Since then, I've come to realize that P2P botnet monitoring brings together two of my favorite areas of security: Reverse Engineering and Programming. As a fun little side project, I decided to begin work on a P2P botnet monitoring system which would show details such as the size of the botnet and geographical distribution of nodes (It's still a work in progress but you can find it here.).
How does it work?
In a peer to peer botnet, bots which can receive incoming connections act as servers (called supernodes) and those that can't just perform tasks from the botmaster (known as workers). The supernodes connect to other supernodes and pass messages between themselves to keep the network in sync and workers then connect to multiple supernodes to retrieve commands. In order for the workers to keep an up to date list of supernodes, the each supernode respond to a peer request command with a list of IPs for other supernodes it knows about (this list varies in size depends on botnets; for example Kelihos sends 500 IPs whist ZeroAccess2+ only sends 16). Workers will download peer lists from multiple supernodes and store them locally to ensure they can maintain connectivity with the botnet, even with a constantly changing landscape of supernodes.
Mapping Supernodes
First we need the IP of one or more online supernodes, then we can write a program to connect to each supernode and send a peer request, then connect to all the IPs returned, repeating the process recursively. In the case of newer ZeroAccess nodes, the supernodes internally store a large list of supernode IPs, but only return 16 online IPs as a response to each peer request: this means that in a single crawl we will likely only find a small cluster of recently contacted supernodes, not every online node.
To ensure the entire network is discovered, we should start the crawler off with multiple supernode IPs and store all IPs found into a database, then each time we restart the crawler we seed it with the list of IPs found during the previous crawler; repeating this process for a couple of hours ensure all online nodes are found.
If you're like me and you're wondering what a botnet map looks like when visualized, then look no further. Here is some data taken from a single crawl of the ZeroAccess 3 botnet and visualized using d3.
 |
| ZeroAccess 3 Full Map (Online and offline supernodes). |
 |
| ZeroAccess 3 Full Map (Same as above but with more link elasticity). |
 |
| ZeroAccess 3 (Online supernodes only). |
Mapping Workers
This is a little bit more tricky as worker IPs are not exposed to the botnet in any way; however, they do still need to connect to multiple supernodes to retrieve peer lists and commands. In order to map all workers, we'd need to set up multiple supernodes across the botnet which log incoming connections (obviously every worker doesn't connect to every supernode at the same time, so it's important that our supernodes have a stronger presence in the botnet).
Depending on the botnet bots use various different methods to decide which nodes to contact, this could be: age, online time, latency, or trust. In the case of ZeroAccess 2, it's age. ZA2 workers keep an internal list of supernode IP addresses which they connect to in order from newest to oldest; so, in order to gain a well established presence on the botnet it would be best to have a server with multiple IPs and add new ones frequent, making sure to notify as many other supernodes as possible of our new IP addresses (we can use the comprehensive list of supernode IPs obtained from the crawler for that!).
What's the purpose?
In my case the botnet tracker has no real purpose other than being a fun project, but in the threat intelligence world it could provide valuable intelligence. If we know the IP addresses of all the workers on the botnet, we can proactively work against any malicious actions they might take: for instance, if the botnet was a spam botnet, we could have have all the IP addresses flagged for spam before they even send a single email. We could also use the data to automatically notify businesses if IPs in their address space show up on the botnet, allowing them to be deal with breaches before they cause any harm.
Conclusion
This post is just a small insight into my current project and as it progresses I will likely post more data and data visualizations. If you've got any suggestions, leave a comment or DM me on twitter (@MalwareTechBlog).
If you're interested to read more about ZeroAccess3, check out this collaboration I did with the guys at Kryptos Logic: ZeroAccess 3 Analysis.
If you're interested to read more about ZeroAccess3, check out this collaboration I did with the guys at Kryptos Logic: ZeroAccess 3 Analysis.