Malware Analysis Tutorial 33: Evaluation of Automated Malware Analysis System I (Anubis)

Learning Goals:

1. Practice Binary Patching
2. Understand Design Principles of Automated Malware Analysis Systems
3. Hands-on Experiences with Anubis Malware Analysis System

Applicable to:

1. Operating System Security

1. Introduction

As we have examined the entire Max++/ZeroAccess binary code, it is now a great time to evaluate a number of automated malware analysis systems based on our knowledge. This tutorial reports our experiences with Anubis (formerly known as TTAnalyze), an automated malware analysis system. A webportal is provided by Anubis designers to submit Windows binary executables (http://anubis.iseclab.org/).

Anubis uses API hook to monitor the system calls placed by a malware (and the processes started by the malware). Equipped with a data structure parser, it is able to extract rich semantic information from the function parameters of system calls (such as registry values and file names). This allows the system to provide a detailed report of malware behaviors.

2. Run Benign Software on Anubis
To verify the functionality and validity of Anubis, we first submitted int2d.exe (used in our malware analysis tutorial 4) to Anubis. int2d.exe is a very simple executable that calls printf() to print two simple strings. As this is the first time that this binary executable is submitted to Anubis, it takes Anubis about 7.5 minutes to generate the report. Figure 1 presents the details of the report.

Figure 1. Anubis Analysis on int2d.exe

 As shown in Figure 1, int2d.exe is identified as a benign file. It does not generate any suspicious file, registry, or network activities.

3. First Submission of Max++.exe
We then proceed with the submission of Max++.exe. This time, it only takes Anubis 10 seconds to generate the report, because it pulls out the report from its repository based on the md5 checksum of the binary executable file. (i.e., Even if we change the file name, it's still the same report). As shown in Figure 2, the first time the binary of Max++ submitted to Anubis is November 2010.

Figure 2. Cached Report of Max++

Figure 3 shows the summary of Max++. It is reported that Max++ has suspicious file, registry, and process creation activities. Specifically, Max++ spawned two processes: dwwin.exe and drwtsn32.exe. This is interesting: because we have not observed such activities during our analysis.It is known that dwwin.exe and dwtsn32.exe are files related to Dr. Watson (a part of the microsoft error report/diagnosis/debugging utility). However, it is unknown in this case if these two files are already there on the Anubis system, or they are fake files downloaded by Max++. We need to drill down deeper into the report.

Figure 3. Summary of Max++

Anubis then reports the detailed activities performed by Max++ and the processes spawned by it. We now briefly examine each:

Runtime DLL Activities: As shown in Figure 4, Anubis successfully discovered that lz32.dll is loaded at run time, however, no further information about the hijack and reloading of DLL contents.

Figure 4. Run-time DLL Activities

Registry Activities: only read values are reported, no write-values.

File Activities. Figure 5 shows the file activities reported by Anubis (note the highlighted area). This is quite different from our own manual analysis. First of all, Anubis did not notice that the file and device drivers are modified by Max++ and thus all operations on the hidden drive (and corresponding file mapping activities) are not discovered by Anubis. Secondly, the reported activities (such as creation of a temporary file and modification of PIPE\lsarpc [used for Local Security Authority]) were not noted in our analysis. We suspect that these activities were made by the drwtsn32.exe.

Figure 5. File Activities

Process Activities. Figure 6 shows the process activities. Again, this is completely different from our manual analysis. Note that Max++ has foreign memory regions written (see highlighted area in Figure 6). Our best guess is that this is similar to the injection of remote thread of an existing process (smss.exe) in our analysis (see Tutorial 15). Because the process is randomly picked, it is possible that the drwtsn.exe is chosen at run time. However, the intended behavior, i.e., to remove the max++_download_2010.exe is not reported by Anubis.

Figure 6. Process Activities

Structured Exceptions. Figure 7 shows Anubis report on the SEH activities. Anubis has  captured one of many Max++'s SEH activities, however, did not perform in-depth analysis of the exception handler after the exception is triggered. For example, the one in Tutorial 11 is not reported.

Figure 7. Structured Exceptions.

Conclusion: it is unclear to us at this moment: if the Dr. Watson service is hijacked by Max++, or it's simply launched because Max++ crashed, as Anubis report also includes a screenshot of the Dr. Watson service screenshot (see Figure 8). To clarify this issue, we have to enforce Anubis to have a new run of Max++ (instead of retrieving the reports based on its MD5 checksum).

Figure 8. Dr. Watson Screenshot

4. Second Trial. Anubis Report on Modified Max++
To enforce the execution of Max++ on Anubis, we have to change the binary executable slighly, so that the Max++ executable does not have the same MD5 (which is already stored in Anubis). Follow the instructions below to modify Max++:

Figure 9. Modify Max++ Binary Executable

(1) Pick one instruction that will never be executed (e.g., the one at 0x00413BD7 in Figure 9).
(2) Right click in code pane -> Assemble -> NOP.
(3) Right click -> Copy to Executable ->All Modified -> Copy All ->  click "close" button on the right top of the dialog and then select "save".

Then upload the modified Max++ to Anubis. It will now take over 8 minutes to generate the report. Interestingly, the report is exactly the same. This seems to confirm that Max++ did not complete in Anubis, and it was stopped early by the drwtson32.exe.