A View on Current Malware Behaviors

1. A View on Current Malware Behaviors Ulrich Bayer, Imam Habibi, Davide Balzarotti, Engin Kirda, and Christopher Kruegel Slides by Eric Smith

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

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

4. Anubis runs binaries in an unmodified Windows environment (Qemu), which leads to good emulation accuracy. • It doesn’t 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

5. Samples • Samples are sent to it by a number of outside sources: • Public web interface • Security organizations • Anti-malware companies

6. Total Data Set • Study done over 2 years • February 7th 2007 – December 31st2008 • 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

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

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.

9. Packers • 40.64% of the analyzed PE files are packed according to SigBuster (a signature-based scanner for packers).

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

11. Observed Malicious Behavior

12. Samples vs. Clusters • Because of polymorphism the results are skewed, so the results are separated into Samples and Clusters • Sample’s 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 allapleworm

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

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

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.

16. The modifications to existing files are less interesting. • The majority of this activity is dueto 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

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 don’t change the CLSIDs of their components, these IDs can be used to detect the presence of some malware families.

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).

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.

20. Network Activity

21. Network Protocols

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.

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).

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).

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.

26. Botnet Activity • 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.

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

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)

30. IRC bots are analyzed in more detail • 13% of the timethe 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.

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.

32. Sandbox Detection • Sandboxes aren’t perfect • Malware makers don’t 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

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 it’s susceptible to the same detection methods as Qemu

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

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

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 sample’s “not much activity”

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.