Tuesday, September 24, 2013

Links - Malware Edition

Bromium Labs posted some pretty interesting information regarding another Zeus variant; the information in this post is very useful.  For example, the phishing attack(s) reportedly targeted folks in the publishing industry.

What I found most interesting is that the variant, with all of its new capabilities, still uses the Run key for persistence.

Looking at other artifacts that can be used to detect malware on systems, see this Zeus write up from SecureWorks...one of the listed capabilities is that it can modify the hosts file on the system.  MS KB 172218 illustrates why this is important...but it's also something that can be checked with a very quick query.

Speaking of write ups, I really enjoyed reading this one from System Forensics, for a couple of reasons:

First, the author documents the setup so that you can not only see what they're doing, but so that the analysis can be replicated.

Second, the author uses the tools available to document the malware being analyzed.  For example, they use PEView to determine information about the sample, including the fact that it's compiled for 32-bit systems.  This is pretty significant information, particularly when it comes to where one (DF analyst, first responder) will look for artifacts.  Fortunately, the system on which the malware was run is also 32-bit, so analysis will be pretty straightforward.  It does seem very interesting to me that most malware analysts/RE folks appear to use 32-bit Windows XP when they conduct dynamic analysis.

Again, we see that this variant uses the Run key (in this case, in the user context) for persistence.

Finally, they performed Prefetch file analysis to gather some more information regarding what the malware actually does on a system.

A couple of thoughts about the analysis:
Had the author run the malware and then copied off the MFT, they might have recovered the batch files as they're very likely resident files.  Even if the files had been marked as not in use (i.e., deleted), had they responded quickly enough, they might have been able to retrieve the MFT before those records were overwritten.

The author states in the article, "The stolen data is sent via the C&C using the HTTP protocol."; I tend to believe that it can be valuable to know how this is done.  For example, if the WinInet API is used, there may be a set of artifacts available that can assist analysts in gaining some information regarding the malware.

Corey released his Tr3Secure data collection script.  Open the batch file up in Notepad to see what it does...Corey put a lot of work into the script, and apparently got some great input from others in the community - see what happens when you share what you're doing, and someone else actually takes the time to look at it, and comment on it?  Stuff just gets better.

If you're grabbing memory during IR, you might want to take a look at SketchyMoose's Total Recall script.  Corey's script gives you the capability to dump memory, and SketchyMoose's script can help make analysis a bit easier, as well.

Adam has posted another in a series (four total, thus far) of blogs regarding persistence mechanisms.  There is some pretty interesting stuff so far, and I was recently looking at a couple of his posts, in particular #3 in the series.  I tried out some of the things he described under the App Paths section of the post, and I couldn't get them to work.  For example, I tried typing "pbrush" and "pbrush.exe" at the command prompt, and just go the familiar, "'pbrush' is not recognized as an internal or external command, operable program or batch file."  I also added calc.exe as a key name, and for the default value, added the full path to Notepad.exe (in the system32 folder) and tried launching calc.exe...each time, the Calculator would launch.  I have, however, seen the AppCertDlls key reportedly used for persistence in malware write ups, which is why I wrote the RegRipper plugin to retrieve that information.

Update: Per an exchange that I had with Adam via Twitter (good gawd, Twitter is a horrible way to try to either explain things, or get folks to elaborate on something...people, don't use it for that...), apparently, the App Paths "thing" that Adam pointed out only works if you try to run the command via the Run box ("through the shell"), and doesn't work if you try to run it from the command prompt.

1 comment:

Adam said...

Hey Harlan,


As per our Twitter discussion. I updated the post with an example .REG file one can use for testing and a clarification how this works (it doesn't run from command line as it has to go through Shell)


Thanks for verification of my research - hope more people check the facts as you do!