Ulrich Bayer, Imam Habibi, Davide Balzarotti, Engin Kirda, and
Christopher Kruegel Slides by Eric Smith
Slide 2
Overview Study on the trends and evolution of malicious
programs What are people designing malware to do? Examine the
effects of code polymorphism and malware statistics
Slide 3
Anubis Dynamic malware analysis platform Basically Big Brother
meets a sandbox Monitors and records: Windows API calls System
services Network traffic Data flows Generates comprehensive reports
about any binaries under analysis
Slide 4
Anubis runs binaries in an unmodified Windows environment
(Qemu), which leads to good emulation accuracy. It doesnt modify
the program that it executes (such as through API call hooking or
breakpoints), making it more difficult to detect by malicious code.
Each sample is run until all processes are terminated or a timeout
of four minutes expires. Can be a limiting factor of the
program
Slide 5
Samples Samples are sent to it by a number of outside sources:
Public web interface Security organizations Anti-malware
companies
Slide 6
Total Data Set Study done over 2 years February 7 th 2007
December 31 st 2008 Total of 1,167,542 submissions With 901,294
unique samples (based on their MD5 hashes) 50,000 samples analyzed
on average per month Samples only analyzed once If a sample is
encountered again it will return the existing analysis report
without doing another analysis
Slide 7
The number of submitted samples indicate how widespread a
malware sample is 73% of samples submitted by 1 source are
identified by 2 out of 5 anti-virus software 81% of the submissions
submitted by at least 3 sources are identified by anti-virus
software. 91% of samples that are submitted by 10 or more sources
are identified by anti-virus software
Slide 8
Around 14% of submitted samples are not valid Windows PE
executables With an online public malware analysis service people
can send all sorts of data, not only malware Some users might have
submitted applications (i.e. Word or Internet Explorer) just to see
how the system reacts.
Slide 9
Packers 40.64% of the analyzed PE files are packed according to
SigBuster (a signature-based scanner for packers).
Slide 10
Four types of submitters: Large: more then 1000 submitted
samples, by far the largest contributor of samples Medium: 100 to
1000 submitted samples. 75% of submitted samples from this group
were malicious, the highest rate of the 4 categories Small: 10 to
10o submitted samples Single: 1 to 10 submitted samples. 50% of the
submitted samples from this group were malicious, the lowest rate
of the 4 categories
Slide 11
Observed Malicious Behavior
Slide 12
Samples vs. Clusters Because of polymorphism the results are
skewed, so the results are separated into Samples and Clusters
Samples with very similar behavior are grouped into clusters Tight
threshold on the cluster process, so there is a very large amount
of different clusters For example, 4.49% of all samples create the
file C:\WINDOWS\system32\urdvxc.exe This is only true for 0.54% of
all clusters. This file is created by the well-known polymorphic
allaple worm
Slide 13
File System Activity 70.8% of all binaries lead a change on the
file system (a file is created or modified) Mainly two types of
created files Executable files, 37.2% of all samples create one or
more of these Non-executables, 63.8% of all samples create one or
more of these
Slide 14
Created Executables Typically the malware copies or moves its
binary to a different known location. This binary is often a new
polymorphic variant. Created where? Windows directory: 63% User
directory (Documents and Settings): 15.1%, executables created here
are likely developed to run successfully with the permissions of a
normal user
Slide 15
Created Non-executables Normally temporary files, DLLs, or
batch scripts. Many of the temporary files are from Internet
Explorer These files are created when Internet Explorer (or, more
precisely, functions exported by iertutil.dll) are used to download
content from the Internet This is frequently used by malware to
load additional components. 21.3% of all samples created at least
one of these files. Most of the DLLs are places in the Windows
system folder. Created where? Window directory: 53% User folder:
61.3% Note that the numbers exceed 100% as a sample can create
multiple files in different locations.
Slide 16
The modifications to existing files are less interesting. The
majority of this activity is due to Windows recording events in the
system audit file system32\config\SysEvent.Evt A few malware
programs infected utilities in the system folder or well-known
programs (like Internet Explorer or the Windows media player).
Deletions were also tracked Most deletions were temporary files
created by the malicious code Very few samples deleted the records
of its activity from log data 0.26% of all the samples delete *log
files 0.0018% of all the samples delete *evt files
Slide 17
Registry Activity A large number of samples (62.7%) create
registry entries. For 37.7% of those samples, the registry entries
are related to control settings for the network adapter. 22.7% of
the samples create a registry key that is related to the unique
identifiers (CLSIDs) of COM objects that are registered with
Windows. These entries are benign, but since some malware programs
dont change the CLSIDs of their components, these IDs can be used
to detect the presence of some malware families.
Slide 18
Two malicious registry actions were found 1.59% of malware
programs create an entry under the key
SystemCertificates\TrustedPublisher\Certificates. Here, the malware
installs its own certificate as trusted. 1.01 % of malware programs
created the Windows\CurrentVersion\Policies\System key, which
prevents users from invoking the task manager. Modified registry
actions The most common malicious behavior was the disabling of the
Windows firewall, 33.7% of all samples, or almost half of those
that modify Windows registries, perform this action. 8.97% of the
binaries tamper with the Windows security settings (i.e. the
MSWindows\Security key).
Slide 19
An important set of registry keys is related to the programs
that are automatically launched at startup. These allows the
malware to survive a reboot. 35.8% of all samples modify registry
keys to get launched at startup.
Slide 20
Network Activity
Slide 21
Network Protocols
Slide 22
The important of Samples vs. Clusters is important here When
the first graph is observed, one would think that there is an
increase in the number of samples using HTTP protocol. After the
samples are clustered, its obvious HTTP protocol use has remained
more or less constant. So the belief that there is an increase in
HTTP usage is not justified, and is probably caused by an increase
in the number of polymorphic samples. However, the graph in Figure
5 supports the assumption that IRC is becoming less popular.
Slide 23
47.3% of the samples that show network activity also query the
DNS server to resolve a domain name. These queries were successful
most of the time. However, for 9.2% of the cases, no result was
returned. 19% of the samples that we observed engaged in scanning
activity. These scans were mostly initiated by worms that scan
specific Windows ports (e.g., 139, 445) or ports related to
backdoors (e.g., 9988 Trojan Dropper Agent).
Slide 24
8.9% of the samples connected to a remote site to download
another executable. Figure 6 shows the file sizes of these second
stage malware programs, compared with the size of the executable
samples submitted to Anubis. As expected, the second stage
executables are normally smaller More then 70% of the samples that
downloaded an executable downloaded more than one. One sample was
observed downloading the same file 178 times (the download was
corrupted each time, so the sample immediately attempted to
download it again).
Slide 25
GUI Windows A surprising fraction of samples 33.26% display a
GUI window. Closer analysis reveals that only 2.2% of these are due
to program crashes. The largest fraction (4.47%) is due to GUI
windows that come without the usual window title and contain no
window text. The majority of GUI windows are simple message boxes,
often pretending to convey an error of some kind. An error message
draws less attention than a file that does not react at all when
being double clicked. 1.7% of the samples show a fabricated message
box that claims that a required DLL was not found. However, if this
error message was authentic, it would be created on behalf of the
csrss.exe process.
Slide 26
Analyzed the network traffic dumps that Anubis has recorded
Interested in detecting three bot families: IRC HTTP P2P
Implemented detectors for ICR, HTTP and the P2P protocols:
BitTorrent, DirectConnect, EDonkey, EmuleExtension, FastTrack,
Gnutella, and Overnet. Botnet Activity
Slide 27
To track bots Anubis defines traffic profiles that capture
expected, bot-like behaviors Based on the observation that bots
usually perform DDoS attacks, send out spam e-mails, or download
malicious executables If it sees signs of any suspicious activities
in a report it considers this sample a bot candidate. Such
activities could be: address scans, port scans, DNS MX queries, a
high number of SMTP connections, etc. Uses some heuristics to
detect known malicious bot conversations The bot analysis is used
to create a blacklist of identified command and control servers
This blacklist is constantly updated and is also used to identify
and verify new bot samples
Slide 28
Identified 36,500 samples (5.8%) as being bots 30,059 IRC bots
4,722 HTTP bots 1,719 P2P bots All P2P bots detected were
variations of the Storm worm. Out of the identified samples, 97.5%
were later correctly recognized by at least two anti-virus software
programs as malware. Often the anti-virus programs misclassified
the sample (i.e. flagging a storm worm variation as an HTTP
Trojan)
Slide 29
Slide 30
IRC bots are analyzed in more detail 13% of the time the
channel topic is base64-encoded. During the time in which the
samples were executed in Anubis, over 13,000 real commands that the
bot master sent to malware were collected. In 88% of the cases, the
commands were instructing the client to download some file (get and
download commands). Some other interesting commands that were
observed were ipscan, login, keylog, scan, msn, and visit.
Slide 31
Also analyzed was how many samples tried to disguise their
activities by using standard protocols on non- standard ports. For
the HTTP bots, 99.5% of the samples connected to the ports 80 and
8080. Only 62 samples were using non-standard ports. IRC bots, 92%
of the samples were connecting to an IRC server running on a
non-standard port. The ports 80 and 1863 (i.e., Microsoft
Messenger) are very common alternatives, often used to bypass
firewalls.
Slide 32
Sandbox Detection Sandboxes arent perfect Malware makers dont
want you to know what they are doing Some malware programs attempt
to detect a sandbox If found most malware programs just shut off
Two types of detection methods Instruction Level detection API
Level detection
Slide 33
Instruction level detection Attempts to tell the difference
between a real CPU and an emulated CPU by using CPU instructions
Currently, no good way of detecting these kind of detection
attempts API-level detection Queries the environment by calling one
or several (Windows) API functions. Anubis uses Qemu for its full
system emulation So its susceptible to the same detection methods
as Qemu
Slide 34
Several Anubis-specific detections have been published on the
Internet. They work by comparing the return value of a Windows API
function such as GetComputerName to a hard- coded value that is
known to identify Anubis
Slide 35
Only 0.03% of the samples (99 distinct malware programs)
contain a known Anubis check. Under the assumption that a sample
that detects Anubis (or a sandbox) does not perform much activity,
we can also provide an upper bound for the samples that do sandbox
detection. A behavioral report contains not much activity when it
contains less than 150 features. The average profile has 1,465
features. 12.45 % of the executable samples (13.57 % of the
clusters) show not much activity. Not all of these samples really
contain anti-sandbox routines
Slide 36
Problems with Anubis There are multiple reasons why Anubis
might not be able to produce a good report. GUI programs that
require user input (such as installers) cannot be analyzed Anubis
only analyzes for 4 minutes Some programs require non-existing
components at runtime At least 0.51% of the reports with not much
activity can be attributed to samples that are protected with a
packer that is known to be incorrectly emulated in Qemu Bugs in
Anubis and Qemu are also possible, and are likely explanations for
some samples not much activity
Slide 37
Conclusion Although much research has been conducted on many
aspects of malicious code, little has been reported in literature
on the (host-based) activity of malicious programs once they have
infected a machine. Understanding common malware behaviors is
important to enable the development of effective malware
countermeasures and mitigation techniques.