Forum libero

Analysis of a Botnet Takeover
Brett Stone-Gross, Marco Cova, Lorenzo Cavallaro, Bob Gilbert, Martin Szydlowski,
Richard Kemmerer, Christopher Kruegel, and Giovanni Vigna
Department of Computer Science, University of California, Santa Barbara

tutto ambientato nel 2009, consiglio di leggere tutto il pdf perchè è proprio interessante.
www.cs.ucsb.edu/~seclab/projects/torpig/torpig.pdf

A particularly sophisticated and insidi-
ous type of bot is Torpig, a malware program that is designed to
harvest sensitive information (such as bank account and credit card
data) from its victims. In this paper, we report on our efforts to take
control of the Torpig botnet and study its operations for a period of
ten days. During this time, we observed more than 180 thousand
infections and recorded almost 70 GB of data that the bots col-
lected. While botnets have been “hijacked” and studied previously,
the Torpig botnet exhibits certain properties that make the analysis
of the data particularly interesting. First, it is possible (with rea-
sonable accuracy) to identify unique bot infections and relate that
number to the more than 1.2 million IP addresses that contacted our
command and control server. Second, the Torpig botnet is large,
targets a variety of applications, and gathers a rich and diverse set
of data from the infected victims. This data provides a new un-
derstanding of the type and amount of personal information that is
stolen by botnets.
A more active approach to study botnets is via infiltration. That
is, using an actual malware sample or a client simulating a bot,
researchers join a botnet to perform analysis from the inside. To
achieve this, honeypots, honey clients, or spam traps are used to
obtain a copy of a malware sample. The sample is then executed in
a controlled environment, which makes it possible to observe the
traffic that is exchanged between the bot and its command and con-
trol (C&C) server(s).

To overcome the limitations of passive measurements and infil-
tration – in particular in the case of centralized IRC and HTTP
botnets – one can attempt to hijack the entire botnet, typically by
taking control of the C&C channel. One way to achieve this is
to directly seize the physical machines that host the C&C infras-
tructure [8]. Of course, this is only an option for law enforcement
agencies. Alternatively, one can tamper with the domain name ser-
vice (DNS), as bots typically resolve domain names to connect to
their command and control infrastructure. Therefore, by collab-
orating with domain registrars (or other entities such as dynamic
DNS providers), it is possible to change the mapping of a botnet
domain to point to a machine controlled by the defender [6]. Fi-
nally, several recent botnets, including Torpig, use the concept of
domain flux. With domain flux, each bot periodically (and inde-
pendently) generates a list of domains that it contacts. The bot
then proceeds to contact them one after another. The first host that
sends a reply that identifies it as a valid C&C server is considered
genuine, until the next period of domain generation is started. By
reverse engineering the domain generation algorithm, it is possible
to pre-register domains that bots will contact at some future point,
thus denying access to the botmaster and redirecting bot requests
to a server under one’s own control. This provides a unique view
on the entire infected host population and the information that is
collected by the botmasters.

Torpig has certain properties that make our analysis particularly in-
teresting.
First, Torpig bots transmit identifiers that permit us to distinguish
between individual infections. This is different from other botnets
such as Conficker. The presence of unique identifiers allows us to
perform a precise estimate of the botnet size. Moreover, we can
account for DHCP churn and NAT effects, which are well-known
problems when computing botnet sizes. In addition, we compare
our results to IP-based techniques that are commonly used to esti-
mate botnet populations.
Second, Torpig is a data harvesting bot that targets a wide vari-
ety of applications and extracts a wealth of information from the
infected victims. Together with the large size of the botnet (we
observed more than 180 thousand infections), we have access to
a rich data set that sheds light on the quantity and nature of the
data that cyber-criminals can harvest, the financial profits that they
can make, and the threats to the security and privacy of bot vic-
tims.

So far, Torpig has been distributed to its victims as part of Meb-
root. Mebroot is a rootkit that takes control of a machine by replac-
ing the system’s Master Boot Record (MBR). This allows Mebroot
to be executed at boot time, before the operating system is loaded,
and to remain undetected by most anti-virus tools. More details
on Mebroot can be found in [9, 12, 25]. In this paper, we will focus
on Torpig, introducing Mebroot only when necessary to understand
Torpig’s behavior. In particular, hereinafter, we present the life cy-
cle of Torpig and the organization of the Torpig botnet, as we ob-
served it during the course of our analysis. We will use Figure 1 as
a reference.
Victims are infected through drive-by-download attacks [33]. In
these attacks, web pages on legitimate but vulnerable web sites (1)
are modified with the inclusion of HTML tags that cause the vic-
tim’s browser to request JavaScript code (2) from a web site (the
drive-by-download server in the figure) under control of the attack-
ers (3). This JavaScript code launches a number of exploits against
the browser or some of its components, such as ActiveX controls
and plugins. If any exploit is successful, an executable is down-
loaded from the drive-by-download server to the victim machine,
and it is executed (4).
The downloaded executable acts as an installer for Mebroot. The
installer injects a DLL into the file manager process (explor-
er.exe), and execution continues in the file manager’s context.
This makes all subsequent actions appear as if they were performed
by a legitimate system process. The installer then loads a kernel
driver that wraps the original disk driver (disk.sys). At this
point, the installer has raw disk access on the infected machine.
The installer can then overwrite the MBR of the machine with Me-
broot. After a few minutes, the machine automatically reboots, and
Mebroot is loaded from the MBR.

--> continua