Forum libero

After the initial update, Mebroot contacts its C&C
server periodically, in two-hour intervals, to report its current con-
figuration (i.e., the type and version number of the currently in-
stalled modules) and to potentially receive updates. All commu-
nication with the C&C server occurs via HTTP requests and re-
sponses and is encrypted using a sophisticated, custom encryption
algorithm [9]. Currently, no publicly available tool exists to cir-
cumvent this encryption scheme.
During our monitoring, the C&C server distributed three mod-
ules, which comprise the Torpig malware. Mebroot injects these
modules (i.e., DLLs) into a number of applications. These appli-
cations include the Service Control Manager (services.exe),
the file manager, and 29 other popular applications, such as web
browsers (e.g., Microsoft Internet Explorer, Firefox, Opera), FTP
clients (CuteFTP, LeechFTP), email clients (e.g., Thunderbird, Out-
look, Eudora), instant messengers (e.g., Skype, ICQ), and system
programs (e.g., the command line interpreter cmd.exe). After
the injection, Torpig can inspect all the data handled by these pro-
grams and identify and store interesting pieces of information, such
as credentials for online accounts and stored passwords.
Periodically (every twenty minutes, during the time we moni-
tored the botnet), Torpig contacts the Torpig C&C server to upload
the data stolen since the previous reporting time (6).
This com-
munication with the server is also over HTTP and is protected by
a simple obfuscation mechanism, based on XORing the clear text
with an 8-byte key and base64 encoding. This scheme was broken
by security researchers at the end of 2008, and tools are available
to automate the decryption [20]. The C&C server can reply to a
bot in one of several ways. The server can simply acknowledge the
data. We call this reply an okn response, from the string contained
in the server’s reply. In addition, the C&C server can send a con-
figuration file to the bot (we call this reply an okc response). The
configuration file is obfuscated using a simple XOR-11 encoding.
It specifies how often the bot should contact the C&C server, a set
of hard-coded servers to be used as backup, and a set of parameters
to perform “man-in-the-browser” phishing attacks [14].
Torpig uses phishing attacks to actively elicit additional, sensi-
tive information from its victims, which, otherwise, may not be ob-
served during the passive monitoring it normally performs. These
attacks occur in two steps. First, whenever the infected machine
visits one of the domains specified in the configuration file (typi-
cally, a banking web site), Torpig issues a request to an injection
server. The server’s response specifies a page on the target domain
where the attack should be triggered (we call this page the trigger page, and it is typically set to the login page of a site), a URL on
the injection server that contains the phishing content (the injection
URL), and a number of parameters that are used to fine tune the
attack (e.g., whether the attack is active and the maximum number
of times it can be launched). The second step occurs when the user
visits the trigger page. At that time, Torpig requests the injection
URL from the injection server and injects the returned content into
the user’s browser (7). This content typically consists of an HTML
form that asks the user for sensitive information, for example, credit
card numbers and social security numbers.
These phishing attacks are very difficult to detect, even for at-
tentive users. In fact, the injected content carefully reproduces
the style and look-and-feel of the target web site. Furthermore,
the injection mechanism defies all phishing indicators included in
modern browsers. For example, the SSL configuration appears
correct, and so does the URL displayed in the address bar.


A fundamental aspect of any botnet is that of coordination; i.e.,
how the bots identify and communicate with their C&C servers.
Traditionally, C&C hosts have been located by their bots using their
IP address, DNS name, or their node ID in peer-to-peer overlays.
In the recent past, botnet authors have identified several ways to
make these schemes more flexible and robust against take-down
actions, e.g., by using IP fast-flux techniques [17]. With fast-flux,
the bots would query a certain domain that is mapped onto a set of
IP addresses, which change frequently. This makes it more difficult
to take down or block a specific C&C server. However, fast-flux
uses only a single domain name, which constitutes a single point of
failure.
Torpig solves this issue by using a different technique for locat-
ing its C&C servers, which we refer to as domain flux. With domain
flux, each bot uses a domain generation algorithm (DGA) to com-
pute a list of domain names. This list is computed independently
by each bot and is regenerated periodically. Then, the bot attempts
to contact the hosts in the domain list in order until one succeeds,
i.e., the domain resolves to an IP address and the corresponding
server provides a response that is valid in the botnet’s protocol. If a
domain is blocked (for example, the registrar suspends it to comply
with a take-down request), the bot simply rolls over to the following
domain in the list. Domain flux is also used to contact the Mebroot
C&C servers and the drive-by-download servers. Domain flux is
increasingly popular among botnet authors. In fact, similar mech-
anisms were used before by the Kraken/Bobax [1] and the Srizbi
bots [46], and, more recently, by the Conficker worm [32].
In Torpig, the DGA is seeded with the current date and a numer-
ical parameter. The algorithm first computes a “weekly” domain
name, say dw, which depends on the current week and year, but is
independent of the current day (i.e., remains constant for the en-
tire week). Using the generated domain name dw, a bot appends
a number of TLDs: in order, dw.com, dw.net, and dw.biz. It then
resolves each domain and attempts to connect to its C&C server. If
all three connections fail, Torpig computes a “daily” domain, say
dd, which in addition depends on the current day (i.e., a new do-
main dd is generated each day). Again, dd.com is tried first, with
fallbacks to dd.net and dd.biz. If these domains also fail, Torpig at-
tempts to contact the domains hardcoded in its configuration file
(e.g., rikora.com, pinakola.com, and flippibi.com).
Listing 1 shows the pseudo-code of the routines used to generate
the daily domains dd. The DGA used in Torpig is completely deter-
ministic; i.e., once the current date is determined, all bots generate
the same list of domains, in the same order.