Audit Viewer: Malware Rating Index Undocumented Features and Caveats
Written by Peter Silberman
Hopefully everyone has had a few weeks to recover from the M-Trends kickoff party in St. Louis and everyone has also had a chance to read the M-Trends report! I hope everyone enjoyed the talk I gave at DOD Cyber Crime Conference. I certainly had fun giving it, sorry to those that got hit with the squishy balls. I wanted to take a second to address some caveats and undocumented features of MRI that couldn’t be discussed in the talk.
A caveat within MRI I that I want to talk about is Process Path Verification. This rule set is very powerful but there are two ways to define to paths. Neither is documented because currently there is no documentation on MRI.. The first method of specifying a process path is to specify an absolute path such as this:
calc.exe:\windows\system32
MRI interprets this as the only valid path for calc.exe is \windows\system32\calc.exe. However, if I wrote the rule like:
calc.exe:\windows\system32\
MRI would interpret this as calc.exe can be run from any sub directory as long it’s a sub directory within \windows\system32\*
The reason this is important is it gives you flexibility in writing definitions. If I don’t want to specify the exact location of iexplore.exe I can say it needs to be launched from \program files\. This may prove to be too loose, and I may change this behavior going forward. For now you have the flexibility to specify absolute paths or sub paths.
The next “undocumented” tidbit that I want to discuss is within two behaviors. These behaviors actually have the ability to use regex when trying to match up their values. I did not build the regex option into the UI so it has to be manually added to the AuditViewerConfig.xml. The two XML lists that can take regex expressions are IgnoreFilesList, and ProcessSuspiciousHandleList. The regex elements are, IgnoreFileRegex, and HandleRegex. An example IgnoreFileRegex looks like:
<IgnoreFileRegex>mshist.*\\index.dat</IgnoreFileRegex>
This rule specifies that any file matching this regular expression should be ignored when doing process scoring. You can get creative just be careful.
An example HandleRegex looks like:
<HandleRegex>*:.*-7$:mutant:known conficker mutant</HandleRegex>
It breaks down like this:
Process: Regular Expressions : handle type: description
It breaks down like this:
Process: Regular Expressions : handle type: description
This allows you to get more out of your suspicious handles definitions.
Finally, I’d like to take a second to reiterate something I stated at DC3. The “Verify Digital Signatures” option in Memoryze and Audit Viewer wizard can ONLY be run when doing live memory. It is not possible to enable it when doing dead memory analysis. Which means the address scoring is not possible on dead memory, behavioral analysis still works on dead memory. If you are going to acquire memory, please run live analysis jobs as well as acquisition. This way you get the most information possible off the machine. The second thing I wanted to reiterate is that verify digital signatures is great, it really helps potentially speed up an analyst’s job. However, we are only verifying the digital signatures exist and are valid on disk. We are not verifying the module in memory hasn’t been modified. If a userland rootkit exists (again shame on the authors) then we won’t report that. It’s important to remember this. Verifying modules in memory short of doing rootkit detection is not a trivial task. The windows loader is a beast, a behemoth it does a lot to make verification in memory to disk is very hard (not impossible). Thanks again for all the interest in M-Trends, Audit Viewer and Memoryze. As always feedback is always appreciated.
Tags: Audit Viewer, DC3, DOD Cyber Crime Conference, M-Trends, Malware Rating Index, Memoryze, MRI, MTrends
Highlighter v1.1.1 Released
Written by Jed Mitten
MANDIANT is proud to announce a new version of Highlighter (version 1.1.1). There are big changes between our previous release and this one, so grab it while it’s hot! The biggest enhancements are bolded in the change log below. Download the new version at http://www.mandiant.com/software/highlighter.htm.
Don’t forget that we’re relying on the user community to suggest improvements. Check out http://forums.mandiant.com and head to the Highlighter section to give us your input. Feedback, feature requests, bugs, and use-cases are all very welcome.
Change Log (since v1.0.1):
- Fix: Tabs were mistakenly removed by input sanitization. This has been corrected.
- Fix: The highlight hit count was incorrect – an additional hit per line was mistakenly being added. This has been corrected.
- Fix: The events over time histogram was not properly displaying highlights. This has been corrected.
- Fix: If text was selected in the textbox, and the user clicked on the highlight button, the selection would not be highlighted. This has been corrected.
- Enhancement: The graphic overview now draws much faster.
- New Feature: The textbox is now a 100% custom control. It is virtualized, and supports a wider range of visual display effects. When words are highlighted, the actual word on each line will be surrounded by a colored translucent bubble with a slightly darkened border. The textbox selection and scrolling behavior is now more like a traditional Windows textbox.
- New Feature: Highlighter will now open MUCH larger files. NOTE: Highlighter now keeps a file open while you are working with it.
- New Feature: Highlighter will now accept a list of terms, one on a line, as input to automatically highlight or remove lines. Look under the right click menu, Highlight -> Import Simple List and under Line Operations -> Remove Using Simple List.
- Enhancement: Files will now open somewhat more quickly due to optimization of calculating the MD5 sum of the file.
- Enhancement: The events over time histogram has sharper numbers on the X and Y axis.
- Fix: The events over time histogram scale now properly adjusts when when switching from linear to log mode.
- Fix: A number of State issues were resolved.
- Fix: Various other minor bugs.
- New Feature: Highlighter support opening a document from a Mandiant Intelligent Response (MIR) controller. Look for the new option from the File -> Open menu.
- New Feature: Highlighter will add a Windows Explorer shell extension by default.
- Fix: A number of State issues were resolved, including improper handling of when a selection included a comma.
- Fix: A race condition existed in the implementation of retrieving lines from the current file.
- Fix: Not all hotkeys were actually implemented in code.
- Fix: Highlight counts in the status bar were incorrect sometimes.
- Fix: Sometimes you could not scroll to the bottom of a file using the scrollbar.
- Fix: Events over time histogram had a very sparse appearance.
- Fix: After opening a file, you could not use hotkeys like CTRL-O to open files, nor could you do things like ALT-F4 or any other key sequence with modifiers.
- Fix: The remove feature would not remove lines with selections that contained a TAB.
- Fix: Various other minor bugs.
Tags: highlighter, log analysis, product, software, visualization
Mandiant Highlighter featured on CyberSpeak podcast
Written by Jed Mitten
Jason Luttgens and I were interviewed by Bret Padres and Ovie Carroll over at the CyberSpeak podcast regarding our log analysis tool, Highlighter. Take some time to listen — the interview begins at 18m 10s, though I recommend listening to the whole show because those guys are fun and their content relevant.
Tags: forensics, free, highlighter, incident response, log analysis, software
Memoryze is the 2008 Toolsmith Tool Of the Year
Written by Michael J. Graven
Russ McRee recently wrote that Memoryze is the 2008 Toolsmith Tool of the Year, and how it helped him find the full name of a malware author. He also wrote up a great description of using Memoryze to chase down a password stealing trojan in the February 2009 issue of the ISSA Journal.
One of the interesting things about Russ’s approach in both cases is his use of the strings option. It turned up some great investigative information. However, strings generates a lot of data, and in a large environment that could be a bit of a challenge (imagine running Memoryze on, say, 20,000 systems.) But on the third hand, what if one of those strings in memory is truly your best indicator of compromise?
The key to solving that problem – large-scale searching for very specific information – is prefiltering the results (and indexing them). Using an XPath expression to match only your desired indicator-of-evil lets the investigator focus on just the relevant data. It also lets you scale up the search to very large numbers of systems.
We’ve built our Intelligent Response product for exactly that need, including features from Memoryze as well as other IR tools. If you’d like to hear more about it, or see a demo, drop me a line.
Tags: holisticinfosec.org, Intelligent Response, ISSA Journal, Memoryze, Russ McRee, Toolsmith
Mandiant Highlighter v1.0
Written by Jason Luttgens
I was poring over some Windows event logs about a year ago, looking for a security breach. We had good intel that a breach occurred on this system, just not exactly what or when. I was getting ridiculously frustrated by the number of non-relevant entries I had to mentally process and thought “there has to be a better way!”
So I searched the Internet and asked colleagues in search of an application that would allow me to quickly remove lines from a text file. I wanted to be able to scroll through the file, and as I identified text that was irrelevant, remove lines from the display that contained that text. Sounds simple enough, right? But after searching for about a week, it seemed that no one knew of such a tool. Many suggested using a series of “grep -v” commands under Linux or with the Win32 Unix tools. Even though I am an avid command line user and a fan of using grep and Linux, that solution was a bit too clunky and not the sort of streamlined workflow I was looking for. A week more frustrated, I couldn’t find any app like the one I was searching for, so I decided I would have to make it myself.
Over two days I wrote a very basic C# application using Microsoft Visual Studio Express. The application had a single function – load a text file into a textbox, let me select text, and remove all lines with that text from being displayed. The original file was never modified, but they weren’t shown to me.
I used my new tool on a selection of the Windows event logs and immediately saw the benefit; with some files, this technique of removing lines quickly eliminated about 80-90% of the events. This let me focus closely on the remaining events, which allowed me to find evil and solve crime faster than ever!
After a little use I realized that thought it would be cool if I not only removed lines, but also found where certain strings occurred throughout a file. I started with the idea of statistical analysis on the file – generate information about each word that indicated frequency, distribution, etc. The problem with that is that I couldn’t come up with any good way to represent the results. After explaining the idea to my Mandiant colleague, Lindsey Lack, he simply said “I’m a graphical person. Why don’t you make a visual representation of the file and display information graphically?”. GENIUS!
Our idea was to depict the file as a graphic on which we could highlight areas on the graphic that corresponded to a key word or phrase. The depiction would immediately give you a sense for frequency and distribution. So with help from one of Mandiant’s Intelligent Response developers, Matt Frazier, we created a C# control that displays the file as a graphic. The graphic represents a sort of super zoomed-out version of the file. Lines from the original file are displayed as graphics lines (no text) on the screen. The lines displayed are proportional to the line lengths in the file. So you have a graphic on the screen next to the text box that proportionally represents the entire file. So, back to the Windows event logs.

See the line numbers jump in the text window. Hidden lines are indicated in the overview with grey lines.
I opened the log and selected a username in question identified through the previous analysis I did. I right-clicked and selected the new function – “Highlight”. The graphic lit up with small red lines (highlights), indicating each exact location that username appeared in the file. I immediately noticed something odd – the red highlights appeared in a fairly regular pattern, except around a certain spot, where there were a number of red highlights that just appeared out-of-place in comparison to the rest. We made the graphic clickable, so I clicked in that area and the textbox advanced to that portion of the file. The log entries that came up were very late at night – a time when this user should not have been accessing this system. Further investigation revealed the user’s account was compromised, malware was installed, and a number of other things happened that day.

The lines highlighted in the salmon color in the text box correspond with the yellow highlights in the overview window.
Evil found. Crimes being solved.
http://www.mandiant.com/software/highlighter.htm
http://mandiant.invisionzone.com/index.php?showforum=15
Tags: forensics, graphics, highlighter, log review, software, tools
Snort My Memory – Blackhat DC 09
Written by Peter Silberman
For those of you who have not checked the speaker lineup for Blackhat DC, I will be there giving a presentation entitled “Snort My Memory.” This talk will address some research that has been going on internally here at MANDIANT for the past couple of months. The research is focused on how to identify common malware samples in memory using Memoryze and the Audit Viewer. The specific idea behind this presentation is to take existing Snort signatures and apply them to strings in memory. The theory being that Snort uses strings to identify malware going over the network. These malware samples create network traffic using “strings” these “strings” must be in memory prior to going out over the wire. So why not just use Snort on the network? Well, when searching an entire enterprise for malware, you need to know every host that is infected and not just the ones that are communicating. Also, the attacker’s communications may be encrypted using SSL or other techniques, which makes network detection harder. With a little luck, the protocol strings such as commands for the botnet are hanging around statically unencrypted in memory, and we can detect them.
This research led me to write two new components. The first component is MindSniffer. This tool takes a Snort rule file and generates either Xpath filters for Memoryze to use or plugins for the Audit Viewer.
python mindsniffer.py
Written by Peter Silberman (peter.silberman@mandiant.com)
USAGE: mindsnort.py
<-r|–rules RULE FILE> snort rule file to parse
<-x|–xpath> generate xpath signatures
<-p|–py> generate py files for use in AuditViewer
[-o|--output] specify output directory
The second component written is a plugin framework/manager for the Audit Viewer. This new component allows users to apply Snort “signatures” to Audit Viewer results (strings must be turned on during the process audit).
The presentation will cover the above research, what was learned, and how Memoryze accesses/parses physical memory and associates strings to processes. As always there will be live demonstrations of Snort signatures working in memory. You can see the official abstract https://www.blackhat.com/html/bh-dc-09/bh-dc-09-speakers.html#Silberman
I hope to see you guys there in February. Feel free to e-mail me if you have questions or want to see the demo from Hack In The Box Malaysia ‘08 (http://conference.hitb.org/hitbsecconf2008kl/).
As final note and shameless plug, stay tuned for some major updates to the Audit Viewer in the coming month or so.
Tags: Audit Viewer, blackhat, blackhat dc, memory, mindsniffer, snort

