The Sality botnet
(Publication) Google search: [1]
| The Sality botnet | |
|---|---|
| Botnet | Maazben, Storm, Pandex, Rustock |
| Malware | Sality |
| Botnet/malware group | |
| Exploit kits | |
| Services | |
| Feature | |
| Distribution vector | |
| Target | |
| Origin | |
| Campaign | |
| Operation/Working group | |
| Vulnerability | |
| CCProtocol | P2P |
| Date | 2010 / 14 May 2010 |
| Editor/Conference | Symantec |
| Link | http://www.symantec.com/connect/blogs/sality-botnet (Archive copy) |
| Author | Nicolas Falliere |
| Type | |
Abstract
“ As discussed in a previous blog entry, Sality-infected computers become part of a peer-to-peer (P2P) botnet. This botnet is used by peers to exchange lists of URLs pointing to malicious software, which Sality will decrypt, download and install.
Though the peer-to-peer protocol used by Sality is custom, we can reverse-engineer the malware binary to determine the P2P packet format, as well as protocol rules and features. Traffic analysis can be used to facilitate or guide a white box approach. Eventually, writing a working P2P client and/or server can be used to validate the analysis.
I decided to create a rogue P2P client that would join the Sality botnet and crawl it, in order to estimate its size.
Let’s do a quick reminder of what the P2P protocol offers:
A peer can ask another peer for its list of URLs. A peer can send its list of URLs to another peer. A peer can ask another peer to send the coordinates (IP, port) of a third-party peer.
Bibtex
@misc{Falliere2010BFR896,
editor = {Symantec},
author = {Nicolas Falliere},
title = {The Sality botnet},
date = {14},
month = May,
year = {2010},
howpublished = {\url{http://www.symantec.com/connect/blogs/sality-botnet}},
}