Blog Qualification: ultra amateur. I’d never done anything like this before, so there may be a number of things overlooked or just plain wrong, but it was a ton of fun.
For this piece, I attempted to analyze a real malware sample recently submitted to minotauranalysis.com.
Minotaur Sample ID: 141369
Submitted: 4/6/2012 10:39:22 PM
File: http://atlnovodv.beepworld.it/files/imagen.jpg(active as of 4/8/12 3:19 PM)
The malicious file uses the “.jpg” extension, but running a “file” command on it reveals that it is an executable:
kyle@labuntu1010_1_64b:/share/noexec$ file imagem.jpg
imagem.jpg:PE32 executable for MS Windows(GUI) Intel 80386 32bit
The file must be downloaded by an end user and opened. Because it is not a valid image file, browsers cannot display it, and directing a browser to a location hosting the “image” may result in it being downloaded by default. Most likely, social engineering would be used to get victims to open the file.
To monitor the actions taken by the malicious file, I used the autoruns, process explorer, and process monitor tools from the sysinternals suite, the registry auditing tool regshot, and wireshark (“Malware Analysis Part 1”, 2011). Before executing the sample, I took a snapshot of the registry with regshot, collected auto-run information with autoruns, and monitored Wireshark to establish a traffic baseline (the victim host did not have any external network connectivity during the initial execution). Instead of double clicking on the file as a typical user might, I ran it from the Windows command line in conjunction with a command to output the system time, so that I would know exactly when the file was run, down to the 100thof a second, as shown below:
Note, “imajen.jpg” (shown throughout the analysis) and “imagem.jpg” (original file name) are identical files; the name difference is the result of a typing error while moving the file between systems.
Upon execution, no image viewing application loaded, as would happen when opening a normal .jpg file. The imajem.jpg process remained running until the system was shut down, as shown by process explorer and task manager. The process monitor capture shows approximately two dozen buffer overflows resulting from actions taken by the imajem.jpg process within one second of its execution:
A comparison of the baseline capture of autorun information with a capture done after executing the malicious file shows a new entry called “GBPVS”, as highlighted by the autoruns utility:
The most useful information came from the report generated by regshot after comparing captures of the registry from before and after the infection. The malware made a plethora of changes to the system in order to mask its presence.
Several XML event viewer settings files were created that, as best as I can determine, make various event viewer fields invisible or sets them to desired values. For example, regshot reported that “C:\Users\All Users\Microsoft\Event Viewer” was added to the system.
“C:\Users\All Users\Microsoft\Event Viewer\Settings.xml” contains:
<ViewerConfig>
<Preview Visible=”“>26</Preview>
<DirectChannelsVisible>0</DirectChannelsVisible>
</ViewerConfig>
About a dozen filers with similar content were created in various locations. In addition, many registry values were created to disable logging. A portion of the regshot report shows the following:
—————————————————————————————-
Values added:393
—————————————————————————————-
HKLM\SOFTWARE\Microsoft\Tracing\Explorer_RASAPI32\EnableFileTracing: 0x00000000 HKLM\SOFTWARE\Microsoft\Tracing\Explorer_RASAPI32\EnableConsoleTracing: 0x00000000
HKLM\SOFTWARE\Microsoft\Tracing\Explorer_RASAPI32\FileTracingMask: 0xFFFF0000 HKLM\SOFTWARE\Microsoft\Tracing\Explorer_RASAPI32\ConsoleTracingMask: 0xFFFF0000 HKLM\SOFTWARE\Microsoft\Tracing\Explorer_RASAPI32\MaxFileSize: 0x00100000 HKLM\SOFTWARE\Microsoft\Tracing\Explorer_RASAPI32\FileDirectory: “%windir%\tracing” HKLM\SOFTWARE\Microsoft\Tracing\Explorer_RASMANCS\EnableFileTracing: 0x00000000 HKLM\SOFTWARE\Microsoft\Tracing\Explorer_RASMANCS\EnableConsoleTracing: 0x00000000 HKLM\SOFTWARE\Microsoft\Tracing\Explorer_RASMANCS\FileTracingMask: 0xFFFF0000 HKLM\SOFTWARE\Microsoft\Tracing\Explorer_RASMANCS\ConsoleTracingMask: 0xFFFF0000 HKLM\SOFTWARE\Microsoft\Tracing\Explorer_RASMANCS\MaxFileSize: 0x00100000 HKLM\SOFTWARE\Microsoft\Tracing\Explorer_RASMANCS\FileDirectory: “%windir%\tracing”
HKLM\SOFTWARE\Microsoft\Tracing\imajem_RASAPI32\EnableFileTracing: 0x00000000 HKLM\SOFTWARE\Microsoft\Tracing\imajem_RASAPI32\EnableConsoleTracing: 0x00000000
HKLM\SOFTWARE\Microsoft\Tracing\imajem_RASAPI32\FileTracingMask: 0xFFFF0000 HKLM\SOFTWARE\Microsoft\Tracing\imajem_RASAPI32\ConsoleTracingMask: 0xFFFF0000
Setting EnableFileTracing and EnableConsoleTracing to “0” disables all logging (Allen, Hunter, & Dinerman, 2006) for both the explorer process and the malicious imajem process, which was confirmed by the lack of interesting entries in the Windows event viewer.
As noted above, the victim host had no network connectivity besides a loopback and an auto-configuration 169.X.X.X address throughout the test so far. The Wireshark capture showed no attempts to access network resources by any application. This was somewhat disappointing, so I set up a BackTrack machine on the same virtual network as the victim, and set the victim’s default gateway to its IP. I ran Wireshark on both the victim and the BackTrack VM. Instantly upon having a valid IP and gateway, the Windows system began attempting to resolve several unfamiliar domain names. The figure below shows the capture, filtered for relevant information (“Display Filter Reference: Domain Name Service”, 2012):
As shown, the malware attempted connections to three domains:
- lucapaciollo.sites.uol.com.br
- silverioguedes.sites.uol.com.br
- auto2012.beepworld.it
The two sub-domains of sites.uol.com.br resolve to sets of addresses in the 200.147.33.16-21 range; addresses that LACNIC identifies as belonging to Universo Online S.A., a Brazillian ISP. The beepworld.it sub-domain resolves to 85.25.91.168, an IP under RIPE belonging to the free website hosting service beepworld. All IP addresses are listed on malwaredomainlist.com and numerous other blacklists.
[ At this point, I tried to use dnsmasq to allow the above domains to resolve to the BT5 box in order to see what protocol the malware tries to talk over, but it failed to work. Next go round, I will play with fakenet for this purpose: http://practicalmalwareanalysis.com/fakenet/ ]
My conclusion is that this malicious file is similar to most in that it backdoors the victim machine, hides its activities from the user, and could be used for any manner of covert monitoring, but is most likely used to steal banking credentials (reverences to Trojan.PWS.Banker exist on Minotaur’s site and when performing searches on the IPs as described above). I saw this sample integrate itself very deeply into the victim system, and would reimage an infected machine, rather than attempt to disinfect it.
To detect this infection, HIDS could watch for the specific registry changes captured by regshot, which are likely common to lots of malware, as well as monitor for the GBPVS autorun that was added. NIDS should monitor for connections to the attacker’s domains and, depending on the nature of the organization, it may be possible to drop all traffic from the LAN to the 200.147.33.0/24 net space, much of which has been blacklisted by malc0de and others.
References
Allen, R., Hunter, L. E., & Dinerman, B. J. (2006).Windows Server 2003 Networking Recipes: A Problem Solution Approach. (pp. 167,168). Apress. Retrieved from http://books.google.com
Display Filter Reference: Domain Name Service. (2012, April 8).Wireshark. Retrieved from http://www.wireshark.org/docs/dfref/d/dns.html
Malware Domain List. (n.d.). Retrieved April 8, 2012, from http://www.malwaredomainlist.com/mdl.php
Malware Analysis Part 1. (2011, May 1).eLearnSecurity. Retrieved April 8, 2012, from http://www.youtube.com/watch?v=fqf5LfPwmm4
