News

Tools
Autopsy v3 is in beta...check it out here.  There are lots of screenshots, so if you're looking for a free, open source alternative to commercial analysis frameworks, take a look.  Also, consider DFF, another useful framework (discussed in DFwOST) to help get you started in analysis, or to use side-by-side with your other tools in order to validate what you're seeing.  If you're in Chantilly, VA, during the first week of Oct, be sure to sign up for OSDFC; it looks like Brian's going to be talking about Autopsy there.

Speaking of open source tools, Volatility has really taken off, with the establishment of the Volatility Labs blog, as well as month of Volatility Plugins (MoVP).  In the month of September alone, there have been half a dozen or so posts.  I really like how the descriptions of the plugins are laid out, as each provides several sections, including the Effects on Forensics, a description of what the plugin helps reveal.  What I really like about this is that too often, in our age of "social"  media, too many times, simply linking to something, or clicking "Like" or "Favorite" or retweeting something means that we miss out on the valuable insight that could easily be provided.  Good on the folks from Volatility for contributing to the growth of the community in more ways than simply providing a tool to make memory collection and analysis achievable, for a variety of platforms..  To see more of what these folks bring to the table, be sure to check out the Open Memory Forensics Workshop prior to OSDFC, albeit a short distance from the OSDFC venue; OMFW is a half-day conference on 2 Oct, in Chantilly, VA, with presentations by some of the big names (and big heads!!) in memory forensics.

If you're not sure about using Volatility for analysis, check out the SemperSecurus post regarding using Volatility to analyze the Cridex malware.  In the post, Andre refers to a number of the useful Volatility commands for extracting information from a memory dump.

If you're using Volatility, or want to, be sure to check out MemGator, for memory sample automated extraction and HTML reporting.  According the write-up, MemGator is also capable of extracting TrueCrypt keys.  If you do have access to a memory dump from a supported OS, this is a great tool to run through that dump through initial processing, before you move on to more targeted analysis.

Blogosphere
Christian Buia has an interesting EMC blog post where he discusses threat actor's lateral movement within an infrastructure via the Task Scheduler.

The latest rendition of the jobparse.pl Perl code that I wrote, which Christian mentions in the post, can be found here, and Jamie's Python tool is discussed here.

Christian's blog post is very valuable to the community, as there have been a number of times (such as at the DC3 conference last January) where presenters have stated that "..lateral movement was used...", but don't go beyond that; I heard several attendees lament this fact, because without knowing what this "looks like", how would they find it within their infrastructure.  Christian gives an example of what this can "look like" within the infrastructure.  Some things you might find via host-based analysis would be indications of the use of at.exe on the primary node (Prefetch file, etc.), and artifacts of a Scheduled Task having been run on the secondary node (Windows Event Log entries, Scheduled Task logs, etc.).  Now, this is not the only means of lateral movement that can be used; there is also psexec and it's variants, as well.

Sploited has some updates to TLN tools, which is pretty cool.  So far, three tools have been posted on the Google Code site for the project.  I haven't tried these tools yet, but I am looking for an opportunity to do so soon.  This is a great example of how someone in our industry sees a need and decides to step up and fill it...too many times, I think that many of us are hesitant to do so much as express a need...I'm not saying sit down and learn to program, I'm saying simply express a need..."...it would be useful to have X."  After all, most of the folks in the community, from the Volatility crew to the person who writes a DOS batch file to tie RegRipper rip.exe commands together all start that way.

Windows 8 is more than on it's way out...check out Claus's Windows 8 Linkage post to see some of the new stuff available.

Threat Intel
I found this very interesting Trend Micro write-up on the Tinba banking trojan, said to be the "smallest", as it reportedly weighs in at 20KB.  Write-ups like these can often provide a great deal of threat intelligence, but they can also sometimes fall a bit short with respect the amount of intelligence that can be derived from them and used within your own infrastructure.  I don't think that this is necessarily an intentional omission; rather, I think that in most cases, it's due to the perspective of the organization (in this case, an AV vendor), as well as the analyst(s) performing the actual analysis (malware RE folks).  What I mean by that is that if you're a reverse engineer who's really good at using a debugger and analyzing memory, your analysis is going to be slanted in that direction.  Very often what I try to do is read between the lines and see what isn't said, and what host-based artifacts should be there that aren't discussed, so that the information provided can be used as part of a root cause analysis.

A couple of things I found interesting within the write-up:

This malware apparently uses the user's Run key for persistence.  Many sites, including Microsoft themselves, have stated this persistence mechanism allows the malware to remain persistent following a system boot...however, it is more correct to say that it allows the malware to start automatically the next time the user logs in to the system.  Yes, the malware will run after a reboot, but only after that user logs in again.

Note: the write-up states that the malware creates a Registry "key" for itself; this is incorrect - it creates a Registry value beneath the Run key.  This may not be a huge distinction to many, but when it comes to things like incorporating Registry data into timeline analysis, it will make a significant difference.  Registry keys include embedded time stamps within their structure, referred to as the key "LastWrite" time; Registry values do not have this element in their structure.

I did not find any mention within the write-up as to which platform was used to analyze the malware; we can assume, based on a couple of the screen captures, that it was likely Windows XP, but there's no indication as to whether the platform is 32- or 64-bit.  This is important to consider, because if the malware is 32-bit and infects a 64-bit system, the location of the persistence mechanism will be slightly different.

The malware also apparently modifies another Registry value that controls Internet Explorer; specifically, within the "HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\Zones\3" key, the value "1609" is modified to 0.  There is other malware out there that makes similar modifications, and MS is kind enough to provide a KB article that describes what the various values beneath these keys refer to. 

Something else that the malware does is modify the user.js Firefox file within the user's profile; as there doesn't seem to be any indication of time stamp manipulation, this should show up as an "M..." entry for that file in your timeline.  The modification that the malware makes apparently disables anti-phishing warnings in Firefox.

While there is some discussion of the malware communications mechanism, it mostly centers on the fact that comms are encrypted.  Earlier in the write-up, the report states that the malware primarily uses 4 DLLs, one of which is ws2_32.dll.  This may provide it's off-system communications capabilities, and for host-based analysts, it can tell us something else.  For example, if this is the only DLL utilized for off-system communications, and others such as wininet.dll are not used, then this would tell us that we should not expect to see artifacts of the communications in the user's index.dat file, and we should probably consider spelunking into the pagefile for artifacts of communications.