OMFW & OSDFC recap

This has been ported over to my GitHub site and is not longer being maintained here. For any issues, comments or updates head here.

General Notes

I attended both the Open Memory Forensics Workshop (OMFW) and the Open Source Digital Forensics Conference (OSDFC) for the first time last year and just like I said last year - they're both set as recurring events on my calendar now.  I was told that my tweets and recap post of last years activities was helpful to those who couldn't attend so I figured I'd write up something again since I took notes anyway.  I really like that both conferences have ~30-40 minute talks so you're not stuck listening to anyone ramble about anything and you also get the benefit of getting more presentations.  If you haven't been able to make either of these yet or are still debating if you should attend - go for it.  They're both 1 day (well, if you just go to the presentations) each and I have yet to be let down with the overall quality of presentations and better yet, the networking that you're able to do at them.

Best Quotes of the Cons

• "They can tunnel faster than you can image" - @williballenthin
• "Brian Carrier just virtually twerked the audience"- @bbaskin
• "What one man can invent,  another man can discover" - Sherlock Holmes (on someone's t-shirt)

Disclaimer - I didn't make it to every talk at OSDFC so if I don't have notes on it, sorry.  Also - these are notes that I jotted down so if something is wrong or there are slides uploaded for ones I didn't link please contact me so I can update the post.

OMFW

The first thing I want to say about this conference was how glad I was that it was at the same venue as OSDFC this year - this makes it really convenient for those attending both so hopefully it stays that way next year {nudge @volatility}.

The State of Volatility

Presenter : AAron Walters
Notes : Went over where Volatility currently stands, major updates/changes and what's on their roadmap.
Highlights :

• The Volatility Foundation has officially become a 501(c)(3)
• Version 2.3.1 of Volatility is officially released and includes full Mac support, Android/ARM support, new address spaces and new/updated plugins.
• AAron also touched on a new plugin he created, dumpfiles, which is extremely useful as it reconstructs files from the Windows cache manager and share section objects. 

Stabilizing Volatility

Presenter : Mike Auty
Notes : Went over a lot of the questions that need to be addressed/answered moving forward with the framework and discussed some of the code layout/structure that needs to be modified
Highlights :

• Version 2.4 of Volatility is pretty much done already but the real focus is version 3 of Volatility.
• The big thing I took away here is that it will be written in Python v3... so I guess it's time to start writing in it too :/

Mastering Truecrypt and Windows 8/Server 2012 Memory Forensics

Presenter : MHL
Notes : MHL talked on the research he's recently done regarding Truecrypt and the support that Volatility now has in order to help recover Truecrypt keys in memory.  His slides go into more detail about the structure of Truecrypt'ed data and where to look for it etc. so hopefully those will pop-up online as there was some good information on them.
Highlights :

• The older versions aren't currently supported but that doesn't indicate that it can't, just that most people are probably using the newer versions of it anyway so why waste time on it?
• Did I mention Volatility can analyze Windows 8 and Server 2012 dumps?  The true beauty of open source showed here... just after new releases came to the market there were Volatility profiles to analyze them.  This is pure awesomeness because it means you don't have to wait for a vendor to implement it into a new release of the tool you're using... you can go home and analyze it today!
• Two new plugins were mentioned, and are said to be committed in v2.4, Truecryptpassprase and Truecryptsummary

All Your Social Media are Belong to Volatility

Presenter : Jeff Bryner
Notes : Gave a presentation about the recent plugins he contributed to Volatility regarding extracting social media artifacts within memory.  Jeff's only scraped the begining of this and hopefully he or someone else can also take a look at the other social media sites he hasn't yet gotten around too - except MySpace... no one uses that anymore, honestly.
Highlights :

• The first thing about his presentation that caught my eyes was his slide deck.  After digging a little into his source code I saw it was all being done with reveal.js - cool thing to bookmark and also gives you the ability to say "my slides are online right now" so people don't have to bug you about where to find them.
• After watching Jeff demo his plugins some discussions started to spark.  When you visit these social media pages you get a huge JSON file returned and why you may not realize it - there're some real gems in there.  You have the possibility of determining who a users friends are, what they 'like'/'favorite', what they've viewed etc.  This can be significant if you need to say they've communicated with someone or viewed something they're denying.

"All the things you think only exist in movies and sci-fi books" 

...OK, I made up the title because I don't remember what it was... but I think this one is fitting anyway

Presenter : George M. Garner Jr.
Notes : This talk wasn't listed on the schedule but this made up title is right on point.  George seems to either have a presentation that is extremely technical and will make you feel dumb on several occasions or he'll talk about things that some think only happen in the movies... the latter in this instance. Most of his content was just speaking so unfortunately I don't think having his slides would be of more use.
Highlights :

• scary, fun, exciting
• George went into detail about engagements he's been on where there was malware in the BIOS and optical drives.... and of course the recent buzz around 'airgapped' malware wasn't left out.  The only difference... this wasn't fabricated in a Hollywood studio.  This got me thinking, as I'm sure many other in attendance and reading this... how the hell do you even detect these types of things?  I know for sure I'm not looking for this type of malware in my routine investigations but I guess if there's some suspicion then this type of deeper analysis could be started.

Memory, Volatility and the Threat Intel life Cycle

Presenters : Steven Adair and Sean Koessel
Notes : While this was probably the least technical presentation of the conference, it still added value.  I enjoy hearing about what others have faced while in this field, what worked, what didn't work etc.
Highlights :

• While I'm sure some of those reading this post already do similar things within their analysis process, I figured it would still be worth mentioning a good tactic they covered - making YARA signatures for all archive utilities, Microsoft tools (e.g. - net, copy, xcopy, ftp, psexec, sticky keys etc.).  Useful for many things but in this talk they mentioned leveraging these rules with yarascan to run across memory dumps.
• They also discussed some of the things they've encountered during engagements and some of the things they've needed to recommend to customers.  I feel these are worth pointing out here because I may or may not also come across a lot of these too often and feel they need to be changed as well : 2 factor authentication, flat networks, ability to change all passwords and ability to perform DNS sink-holing.

Dalvik Memory Analysis and a Call to ARMs

Presenter : Joe Sylve
Notes : Joe touched on some of the work he's been doing to add ARM support to Volatility, went over the tool 'Dalvik Inspector' and put out a call for people who are interested in this space to help out as there's still a lot to be tackled/uncovered.
Highlights :

• The tool referenced above may or may not sound familiar to you... but in case it doesn't or you forgot where you hear it from, check out the related blog post for it. The tool looks pretty slick and the auto creation of Volatility plugins will surely help others during their Android investigations.  I didn't hear an exact date on its release but it's supposed to be soon so be on the look out!

Bringing Mac Memory Forensics to the Mainstream

Presenter : Andrew Case
Notes : One of the big things with the latest Volatility release was the Mac support.  Some of the Mac support/plugins have been around for a bit but if you look now you'll see the number of plugins specifically for Mac is over 30!
Highlights :

• There are some Mac profiles are in a .zip file on the wiki - don't copy them all to the Volatility directory or upon execution it will load each of them and slow things down.  Only copy the one that's applicable.
• launchd shouldn't be a child process
• lsmod may show ones with a size of 0 and aren't found on disk - doesn't mean it's malware
• slide 4 on Mac userland rootkits shows how to detect them with plugins (these slides would help, nudge @attrc).
• 10.9.x of Mac compresses free pages so running strings over a dump won't show anything

Memoirs of a Hidsight Hero: Detecting Rootkits in OS X

Presenter : Gem Gurkok
Notes : Don't try and write a book about Mac rootkits or Gem will make it his hobby to disprove your data before you get to publish it
Highlights :

• There was some really good information here on showing how to detect every new method some authors were saying couldn't be detected but I think the slides would be of better explanation.  

Every Step You Take: Profiling the System

Presenter : Jamie Levy
Notes : I always tend to find the stuff Jamie talks on to be the most relevant to my daily operations.  Last year she talked on MBR/MFT stuff and this year she showed off some plugins related to profiling/intelligence.
Highlights :

• Jamie touched on a plugin she created a little bit ago, CybOX, which checks for threat indicators in memory samples
• There was also mention of profiling memory dumps.  I can't specifically recall if there was a plugin called 'profiler' but never the less, it was sweet.  Think about generating profiles of memory dumps so you can detect either good stuff or malicious stuff.  In one way of thinking, you can create your golden profile - a baseline of a clean system so you can diff that against another memory dump and see what's different. This can help detect new software, processes etc.  Another thought is creating a memory dump while the system is infected and then using some of those artifacts to later determine if they exist in another memory dump.  This is something that can scale and I'm really excited to start playing with it.

Honorable Mention

• ethscan - This plugin was a runner up in Volatility's plugin contest but it's definitely something I can start to leverage on engagements right away.  I'm not sure how the author's blog post managed to slip under the cracks but it's linked above so give it a look.  I like the fact that it will work for any OS' memory dump and can utilize dpkt to save the network traffic to a PCAP file.

OSDFC

First... I'm glad the official conference page had a Twitter hashtag to use this year but I still ran into the same issue as last year - people using a variety of hashtags... stick to the default! One of the first observations this year was that it appeared the attendance was double that of last year.  Additionally, I noticed there were a lot of younger attendees this year so it's great to see them getting involved and starting to network.  On the disappointing side - I did feel like I was seeing a noticeable amount of people doing the same things as others have already done.  I know it's useful from a learning perspective to do things yourself but why spend so much time re-doing something that's already out there to use?

Forensics Visualizations with Open Source Tools

Presenter : Simson Garfinkel
Notes : Simson has spoken at every OSDFC, he hates pie graphs and likes PDFs
Highlights :

• No seriously, doesn't like pie graphs... and when he rotated them around it kind of made sense.  When you rotate the pie chart the focus of what you're trying to show changes.  He referenced another presentation, Save the Pies for Desert, that's worth a read.
• Simson brought up an interesting point that some graphing tools (graphviz etc.) will produce different graphs when run more than once.  This happens when there's randomized algorithms being used and the seed keeps changing when producing the graphs.  Not good when need things to be repeatable by others.
• Have you every visualized network traffic?  It can certainly be helpful... what about creating some stats/reports?  Sometimes looking at graphs instead of lines within Wireshark can help show things you might have otherwise missed.  A quick, high-level overview can be generated with 'netviz' (slide 46).  It's currently within tcpflow and creates some histogram for you.
• He made some valid points for PDFs having a high resolution that could be zoomed in on and also they have the ability to be text searchable

Autopsy 3: Extensible Desktop Forensics

Presenter : Brian Carrier
Notes : Brian twerked it
Highlights :

• Brian had a great transition in his slides to incorporate a Miley Cyrus picture (related quote later in this post)
• The keyword searches within Autopsy refresh every 5 mins by default
• The searches for specific locations (e.g. - user's folders) are prioritized so their results show first.  (can this be modified??)
• The video triage module does periodic screenshots of the video so you don't have to sit there and watch the entire thing to see if it changes at any point
• The text gisting module helps translate text into English
• Future things - will use SQLite for hash DB, carve using Scalpel and will have Mac and *nix installers

"Challenge Results" - Autopsy Module Contest

Notes : I was surprised there were only two submissions to this contest and just as surprised that both of them were more on the complex side of things.  Someone could have just created a module to periodically show a cat picture and won some dinero.  Of the two submissions, one was a remote submission and only had a video to show if off.  It looked useful, but just didn't cut it - Willi B took the gold.
Highlights :

• Willi B - Registry Module; wrote an entire library in Java
• someone else - Fuzzy Hash Module

A Tool for Answering the Question: What Changed on Disk?

Presenter : Stuart Maclean
Notes : Tool to do some diffing (waiting for github for code)
Highlights :

• Armour - shell program to compare TSK bodyfile's
• slide 15 - cmd's
• slide 19 - cuckoo report
• Not just used for VM diffing, slide 21 - can do psychical machine disk diffing w/ external drive and *nix live cd

Bulk_Extract Like a Boss

Presenter : Jon Stewart
Notes : Lightgrep FTW
Highlights :

• Unicode shout out to U+1F4A9 (you know you want to look this up now)
• With lightgrep incorporated into bulk_extractor, if you disable the normal 'find' disabled (-x find) you'll have blazingly fast searches - slide 11
• Bulk_extractor contains recursive scanners to extract files then scan them (defaults to recurse 7 times to make sure don't fall into zip bombs)
• There's a couple of new scanners - xor and hiberfil
• "useful options" - slide 8
• paper in last years DFWRS on its unicode support
• Lightgrep is incorporated into the Windows installer and the source can be downloaded and installed yourself for other flavors

Making Molehills Out of Mountains: Data Reduction Using Sleuth Kit Tools

Presenter : Tobin Craig
Notes : The speaker saw a gap and tackled it but I do think some of it is repetitive to what's already out there.
Highlights :

• Built to work on DEFT v8
• Created a bash script that leverages TSK
• limitations: limited to FAT/NTFS partitions and relies on file extentions to determine file types

Doing More with Less: Triaging Compromised Systems with Constrained Resources

Presenter : Willi Ballenthin
Notes : Willi showed that you don't always need to have the entire disk in order to answer the key questions to your investigation.  He also let us into his analysis process and a peek into all of the sweet things he's written.
Highlights :

• 'pareto principle' - get 20% of artifacts to answer 80% of the questions
• The key data to grab is generally the $MFT, Registry files and Event Logs (others, depending in your questions to ask could be memory, Internet history etc.)
• These key files compress extremely well and are generally result in being under 100MB 

INDXParse

• list_mft.py - creates timeline and can also pull resident INDX records
• MFTView.py - pulls resident data if it's there in the 'Data' ta and tells what sectors to pull from disk to get contents of it if not ;  right pane shows Unicode/ASCII strings so can see refinements of what was previously there
• get_file_info.py - CLI that's scriptable and creates a mini timeline

python-registry

• reg_view.py - R/O GUI registry viewer
• findkey.py - search keys/values/paths etc. to feed it keywords to search for
• timeline.py - create timeline from key modification time stamps
• forensicating.py - some functions I put together to show how to utilize this library for forensics (got a sweet shout out for it, w00t w00t... now your turn)
• full documentation can be found : here.

python-evtx

• Lfle.py - carve for records
• Willi also mentioned a GUI Event Log Viewer which has the ability to index records for easier searching and puts the event IDs in categories/sub-categories that are sortable.  This is something I had talked to a few about over the years and I'm really glad to see someone finally doing it, thanks Willi!  This currently isn't publicly released yet but be on the lookout.
• full documentation can be found : here.

Computer Forensic Triage using Manta Ray

Presenter : Doug Koster & Kevin Murphy
Notes : "Automated Triage" - looks to be the same thing as Tapeworm was.  There looks like there still needs some things to be ironed out/finished.  In my investigations I don't need to run every tool every time and that's kind of what I feel this does... maybe useful for others but doesn't fit into my process flow.
Highlights :

• Going to be in SIFT v3.0 but for the time being it's at mantarayforensics.com

Honorable Mention

• Noriben - Brian Baskin gave a quick demo of his latest version ; useful for quick analysis
• SIFTER - "the Google of digital forensics"... I unfortunately didn't make it to this talk but I heard it was great so I'm putting it here as it's something I want to look into and feel others might want to as well.
• MassScan - This was described as an internal VirusTotal tool.  Unfortunately the display on the projectors wasn't working properly so it wasn't easy to follow along but I'm eager to see the code and what it can really do. (anyone have a link?)

Don't Get Locked Out

This has been ported over to my GitHub site and is not longer being maintained here. For any issues, comments or updates head here.

Scenario

The system had Full Disk Encryption (FDE) via McAfee SafeBoot and I had recently changed my Windows password but apparently fat fingered it from what I thought I had changed it to which left me unable to authenticate to Windows.  The OS and SafeBoot were working properly and I had valid credentials to login to the SafeBoot file system (SBFS)...this is because it used separate credentials from my Windows credentials.

Considerations

Even though I could authenticate to SafeBoot and decrypt the OS, I wasn’t able to boot off of anything else (Kon-boot, Ophcrack etc.) after authenticating to SafebBoot or prior to entering the SafeBoot environment.

Since my Windows passphrase was over 18 characters (don’t ask me why) a dictionary attack wasn’t on the list of possible solutions.  While rainbow tables were next on my list, LM was turned off and the key space for my passphrase would have been too big to tackle.  There was the option to try and unlock it via FireWire (Inception) but since this was a Windows 7 x64 with SP1 and 8 GB of memory it was unlikely to work in its release at that time.

Trials

In order to recover/troubleshoot SafeBoot you can use the WinTech CD.  Once you boot your system from the WinTech CD the first thing that you must do is open up WinTech (start > Programs > SafeBoot WinTech) and enter the daily access code.  

After successfully authorizing yourself the next step is to authenticate to SafeBoot.  This can be done three different ways:

Since I had valid credentials for this particular SafeBoot group I chose the first option - to "Authenticate From SBFS".  If all goes well you’ll see authorized and authenticated in the bottom of the program.

You now have the ability to mount your decrypted file system and browse it with an explorer within the BartPE environment or from cmd.  My first thought was to copy off the SAM and SECURITY files but again, lack of LM hashes and my long passphrase were telling me nope, try another way.

As such, I decided to try the old Sticky Keys trick.  For those of you who are unaware of what I mean, Sticky Keys is an accessibility feature within Windows meant to allow a user to be able to hold down two or more keys at a time when they would otherwise be unable to.  This feature is enabled by default on Windows installations and is therefore highly reliable as another option.  To make sure this was a possible solution I hit the ‘Shift’ key five times once I was at the Windows login screen.  If your settings haven’t been altered and Sticky Keys is enabled you’ll be presented with:

By switching the Sticky Keys application with a command prompt on the system you can take advantage of this feature and reset a local user’s password or create a new local user.  Usually, this trick would be carried out by either booting the system from a Windows installation disk and utilizing the recovery console or by mounting the file system within a live Linux instance.  The issue that came up again is that neither of them would have sufficed since the OS file system would still be encrypted.

Resolution

Once I was authorized and authenticated to the SBFS I opened cmd within WinTech and did the following:

1. Created a copy of the Sticky Keys application:
   > copy c:\Windows\system32\sethc.exe c:\Windows\system32\sethc.bak
   1 file(s) copied.
2. Tried to replace the Sticky Keys application with a copy of the command prompt:
   > copy /y c:\Windows\system32\cmd.exe c:\Windows\system32\sethc.exe
   Access is denied.
   0 file(s) copied.
   
   The first time around I received an "Access Denied" error in this step, as depicted above.  This is something I hadn't run into before because every time I had previously performed this trick I was working on a Windows XP system - but this time it was a Windows 7 system.  After some troubleshooting I realized this error was due to enhanced protections on the System32 files that Windows 7 has over Windows XP...so the ownership/permissions on this file need to be modified.
3. Within SafeTech, Start > Programs > File Management > MS Explorer.
• Right click on sethc.exe > Properties > Security > Advanced
• Change the current owner (TrustedInstaller) to Administrators (in my case)
• Change the permissions of who you changed ownership to (Administrators in this example) to "full control"
4. I attempted to replace the Sticky Keys application again with a copy of command prompt:
   > copy /y c:\Windows\system32\cmd.exe c:\Windows\system32\sethc.exe
   1 file(s) copied.
   
   Victory!
5. Then, after a system restart I pressed the Shift key 5x at the Windows login.  If all went well then the command prompt should now pop up and allow us to add a new user or reset an existing users password:








At which point I could just do the first of those two, reset my Windows password:
> net user <username> <new password>

While not a super exciting post, it was something that I had to think about for a sec. and hopefully these little notes will help someone else out there if they ever run into the same situation.

NoMoreXOR

This has been ported over to my GitHub site and is not longer being maintained here. For any issues, comments or updates head here.

Update 04/09/2013 - NoMoreXOR is now included in REMnux as of version 4.

Have you ever been faced with a file that was XOR'ed with a 256 byte key? While it may not be the most common length for an XOR key, it's still something that has popped up enough over the last few months to make it on my to-do list.  If you take a look at first the two links mentioned above you'll see they both include some in-house tool(s) which do some magic and provide you with the XOR key.  Even though they both state that at some point their tools will be released, that doesn't help me now.

Most of the tools I came across can handle single byte - four byte XOR keys no problem (xortool, xortools, XORBruteForcer, xorsearch etc.) but other than that I didn't notice any that would handle (or actually work) with a large XOR key besides for (okteta, converter and cryptam_unxor).

I noticed Cryptam's online document analysis tool had the ability to do this as well so I sent them a few questions on their process and received a quick, informative response which pointed me to a post on their site.  Within the post/email they said that they don't perform any bruteforcing on the XOR key but rather perform cryptanalysis and then brute force the ROL1-7 (if present).  As shown in the dispersion graphs they provide, they appear to essentially be looking for high frequencies of repetitive data then using whatever appears the most to test as the key(s).

So how do you know if the file is XOR'ed with a 256 byte key in the first place?  Well... you could always try to reverse it but you may also be lucky enough to have some YARA rules which have some pre-calculated rules to help aid in this situation.  A good start would be to look at MACB's xotrools (previously linked) and also consider what it is you might want to look for (i.e. - "This program cannot be run") and XOR it with some permutations.

Manual process

If we open that file within a hex editor and go to the offset flagged (0x25C8) we'll see what is supposedly "This program cannot be run" = 26 bytes :

If we take that original file and covert it to hex we'll essentially just get a big hex blob:

...but that hex blob helps to try and guess the XOR key:

From my initial tests, the XOR key has always been in the top returned results, but even if you're having some difficulties for whatever reason you can always modify the code to fit your needs - gotta love that.

So if we now try to unxor the original file with the first guessed XOR key (remember XOR is symmetric) hopefully we'll get the original content that was XOR'ed:

After the original file was unxored and scanned with YARA we see that it was flagged for having an embedded EXE within it (this rule can be found within MACB's capabilities.yara file) so it looks like it worked.

Now while all this hex may look like a bunch of garbage at times, the human eye is very good at recognizing patterns - and when you look more and more at things like this you'll start to recognize them.  Do you recall the YARA hit that triggered? It stated that the XOR key was incremented.  What this means is that each byte is being XOR'ed with the next byte in an incremental fashion until it wraps back around to the beginning.  That may be confusing the grasp at first so lets visualize it by breaking down the previously found 256 byte XOR key in its' respective order:

868788898a8b8c8d8e8f
909192939495969798999
a9b9c9d9e9f
a0a1a2a3a4a5a6a7a8a9
aaabacadaeaf
b0b1b2b3b4b5b6b7b8b9
babbbcbdbebf
c0c1c2c3c4c5c6c7c8c9
cacbcccdcecf
d0d1d2d3d4d5d6d7d8d9
dadbdcdddedfe
0e1e2e3e4e5e6e7e8e9
eaebecedeeef
f0f1f2f3f4f5f6f7f8f9
fafbfcfdfeff
000102030405060708090
a0b0c0d0e0f
10111213141516171819
1a1b1c1d1e1f
20212223242526272829
2a2b2c2d2e2f
30313233343536373839
3a3b3c3d3e3f
40414243444546474849
4a4b4c4d4e4f
50515253545556575859
5a5b5c5d5e5f
60616263646566676869
6a6b6c6d6e6f
70717273747576777879
7a7b7c7d7e7f
808182838485

As you see, it started with 86 and looped all the way around till it reached 85 - you should also notice the patterns on each line.  This is just an example of incremental/decremental XOR (not as commonly observed in my testing but useful to be aware of) but it's useful to know because it's quite easy to spot if you look at the original file in a hex editor again:

... and that's a pattern that was observed repeating ~56 times.

Automated process

So now we can kind of put together a process flow of what we want to do:

1. Convert the original, XOR'ed file to hex
2. Conduct some slight frequency analysis of the newly created hex file and look for the most common characters as well as the most commonly observed hex chunks.  
1. The first part may help in determining if there's an embedded PE file (usually a lot of \x00's) or possibly help deduce if certain bytes should be skipped.  
2. The latter essentially reads 512 bytes at a time, stores it and continues till the end of the file.  Once complete it does some simple checking to try and weave out meaningless possible keys then presents the top five most observed 512 bytes or characters in this sense  (i.e. - 512 characters = 1 possible 256 byte key(s))
3. For each possible XOR key guessed from the previous step, XOR (the entire file for right now) the original file, save it to a new file and scan it with YARA.  
1. I chose to perform YARA scans here to help determine the likelihood that the key used was correct - you may choose to implement something else such as just a check for an embedded PE file etc.  If there are YARA hits then I stop attempting the other possible XOR keys (if any other were still to be processed) and assume the previous XOR key was the correct one.

* If you stick with the YARA scanning, it will continue to process all of the possible key(s) it outlined as the top, in terms of frequency, so your YARA rules should include something that might be present in the original XOR'ed file.  If not, you might already have the correct XOR key but aren't aware.  Embedded exe's are a good start to look for since they're common - but remember if we XOR the entire file at once instead of a specific section that you might find the embedded content but that doesn't mean the original file will be readable afterwards (i.e - won't be a Word document anymore since it was XOR'ed) 

Let's try out that process flow in a more automated way (on a new file):

As you can see, it worked like a charm :)

As always, I'm sure there's a better way to code some of the stuff I did but hey, it works for me at the moment.  There's a to-do list of things that I want to further implement into this tool, some of which is already included in other tools.  I've been asked before how this tools will work with smaller XOR keys and that's up to you to test and tell me - I created this in order to tackle the problem solely of the 256 byte key files I was observing so I'd recommend using one of the earlier mentioned tools for that situation, at least for the time being.

Example To-do's:

• ROL(1-7)/ROT(1-25) - either brute forcing or via YARA scans
• Add ability to skip \x00 & other chosen bytes (ref)
• more is outlined within the file....

Download

NoMoreXOR can be found on my github

dbmgr reloaded

This has been ported over to my GitHub site and is not longer being maintained here. For any issues, comments or updates head here.

I recently had a discussion with another coworker regarding scenarios where you can try and determine if something malicious is or was on a system based on mutexes.  For those unfamiliar with what a mutex/mutant is, a definition:

"Stands for Mutual Exclusion Object, a programming object that may be created by malware to signify that it is currently running in the computer. This can be used as an infection 'marker' in order to prevent multiple instances of the malware from running in the infected computer, thus possibly arousing suspicion."

Mutexes are referred to as mutants when they're in the Windows kernel but for the purpose of this post I'm going to only refer to mutexes even when mutant might be the correct technical term (deal with it).  So in theory, and in practice, by enumerating mutexes on a system and then comparing them to a list of mutexes known to be used by malware you would have good reason to believe something malicious is/was on the system - or at least a starting point of something to dig into if you're in the 'needle in a haystack' situation.  During our conversation I remembered a script from the Malware Analysts Cookbook which scraped ThreatExpert reports and populated a DB (Note : This script requires the 'avsubmit.py' file from the MACB as well since it takes the ThreatExpert class from it).  After taking another look at the script, I figured it would be less time consuming to modify it to fit my needs instead of starting from scratch.  This idea can be implemented across other online sandboxes as well but in this instance I'm just going to touch on ThreatExpert.

I grabbed the latest copy of the 'dbmgr.py' script but when I went to verify it was functioning properly prior to making any modifications I ran into a tiny hiccup.  As a result of a simple grammatical error within this version of the script, the processing would come to a halt and not complete ... I submitted a quick bugfix and within ~2 mins MHL acknowledged the issue, commented and fixed it.  I know it was a small fix but man, what service!

Now that there was a working copy up I took a look at the params/args which ThreatExpert made available and noticed I could use the 'find' parameter in addition to the 'page' parameter (which the script already included) and supply it with whatever I wanted to search for within the archived reports.

The addition of  'sl=1' is credited to another post MHL pointed out a little while ago where another user noted this would filter ThreatExperts results to only show 'known bad' ... after all, for the purposes most of us will be using this for, we don't really want to have 'good' results.  When you query ThreatExpert you receive ~20 results per page and ~200 pages max from what I've seen.  The other post mentioned above included a quick external bash script to loop the dbmgr.py script and supply it with a new value to grab different pages for bulk results.  To make things easier, I added another def to the script so you have the ability loop through multiple result pages and I also put in a simple check to stop processing results if there's no more left (i.e. - if you tell it to search 5 pages but only 3 are returned, instead of trying to process the last two it checks for the 'No further results to process' text which ThreatExpert produces and exists).

Example search terms which might be of interest:

• mutex
• would  produce results which have a greater chance of containing mutexes since that's a required word within the report based on what we're querying.
• exploit.java || exploit.swf
• either of these would produce results which involve either 'exploit.java' or 'exploit.swf' in their A/V name
• wpbt0.dll
• could be used to look at reports involving a commonly associated BHEK file

There were also a few other cosmetic changes that you'll notice in the patch but those are mainly to display things a certain way I wanted to see them - but I also came across an instance where there was some funky encoding on a file name it was trying to insert which caused it to fail so I added a little sanity check there as well.

So what's the point of this all and why do you care?  One of the reasons which I mentioned above was to populate a DB with known malicious mutexes (without wasting time grabbing a bunch of other reports that aren't relevant to your needs).  

This becomes even more handy when you're analyzing a memory image and want to do a cross-reference with volatility's 'mutantscan' command.  In fact, if you read the blurb under that commands reference you'll notice the volatility folks actually mentioned a similar PoC they tested so it's good to see others thinking the same way.  Other ways of interest could be to populate a DB and start to put together some stats regarding which registry keys are commonly associated with malware, which registry values, common file names, common file locations targeted, IP addresses contacted via the malware etc.. there's a wealth of data mining that can be done and the great thing is (1) it can be automated and (2) you don't have to have the samples or waste the time processing them in your own sandbox as you can just leverage this free resource.

If you want to play around with the patch I put out, head over to my github and follow the instructions for patching the original version.

:: Note - during recent testing I noticed I wasn't getting results but I believe this might be due to something on ThreatExpert's side, or I'm just being throttled... either way, it works but just be aware in case you aren't getting results every time (even with the original script) ::

SWF-ing away

This has been ported over to my GitHub site and is not longer being maintained here. For any issues, comments or updates head here.

:: Disclaimer - the intent of this post is for educational and research purposes only.  Don't be lame and use it to steal copyrighted material ::

There's been quite a bit of chatter lately with the recent discovery of the latest IE 0-day.  While reading through one of the other researchers posts I decided to take a deeper look into some of the files being used in these reported attacks.  The issue that some might be experiencing while trying to analyze the related flash files, as did I, is that they're encrypted with doSWF and therefore take a little more effort in order to get down to what we care about.  A quick search about how to go about decrypting this particular type of encryption led me two good articles (one | two).  

With the addition of another user posting a decompiled version of the ActionScript within the file I was looking at I decided to give a quick look into this referenced script and modify its 'decrypt' function to correspond with the information provided.  I thought it would be an easy task but later turned out to result in errors - Java is something I don't care to debug... The thought of having a script to aid in the future automation of decrypting such files would be helpful and might be re-visited but there's also a learning aspect to doing it manually.  With that being said I opted to go about it in a different approach (attaching OllyDbg to IE and dumping the SWF from memory) which would be repeatable in future analysis efforts even if the type of encryption used was different - which makes it more reliable/flexible in my eyes.  There will be some overlap here to previously linked posts but instead of just saying what was done I feel it's useful for others to see how to do it.

So after wiping off the dust from OllyDbg I was able to get the end results I was seeking from my analysis by performing the steps outlined below.  Note that while some of the steps and content below are specific to the file I set out to analyze, other steps can be applied to help analyze other situations you might encounter.

1. This initial step can be bypassed depending on what your analyzing and goals are but for this particular situation I started off by commenting out the part of the initial landing page which was responsible for initializing the variables and just left the part in which loaded the SWF file:


2. Open up IE (this could be another browser, again depending on what your analyzing)
3. Open OllyDbg and attach the IE process (File > Attach).  If you have more than one instance of IE open, make sure you are attaching to the right one!
4. Open exploit.htm in IE which will load the SWF file
5. Locate the SWF loaded within IE's memory.  Go back to OllyDbg:
   View > Memory Map > right click > Search (Ctrl + B)
   The search criteria will be dependent on what you're looking to locate, and be mindful of little endian.  In this case I decided to search for "doSWF" which would be displayed here as "64 6F 53 57 46" in HEX.
   
   
   
    
There may be multiple hits of the text you are searching for - each of which will pop up in its own 'Dump' window.  Take a look at the context of where the found text is located and continue (CTRL + L) until you get one that looks like it's right.


6. Once you come across what looks to be your decrypted SWF file, within its Dump window; right click > Copy > Select All .  Now you might disagree with this approach and say why copy everything out instead of just what you're after but I'd rather copy it all out and worry about carving the exact SWF file later rather than manually calculating the correct SWF length and carving it out from OllyDbg (more on that latter).
   
   Once it's all highlighted; right click > Binary > Binary Copy
   
   
   
   
   Open a hex editor (HxD in this example) and paste the copied information we took from OllyDbg into a new HEX file; Edit > Paste write (CTRL + B )
   
   You can scroll down to see the 'goodies' which also help in showing it's not encrypted anymore since these are strings we were unable to previously see:
   
   • File header (46 57 53 | FWS)
   • iFrame reference and 'call' statement to blob
   
   
   (image was widened to show it all, not all hex columns are shown as a result)
7. Since I copied everything over you can obviously see there's other junk there which we don't care about and will prohibit us from solely having the sought after SWF file.  As mentioned earlier, this can be solved by either manually carving it out based on Adobe's SWF specifications [PDF]:
   
   
   •   first 3 bytes = header
   •   next 1 byte = version(8 bit #, not ascii representation)
   •   next 4 bytes = total length including header (varies if compressed)
   
   
   • 46 57 53 = FWS
   • 09  = version 9
   • BD 18 00 00 = 18BD (little endianed HEX or 6333 (decimal)
 (you can see these corresponding values to the carved SWF in an image below)

...or have a tool help you out.  While it's useful to know the specifications of what you're analyzing, having a tool to help you limit the chance of you creating an error is always nice so I opted use Alexs' kick-ass tool xxxswf to do the thinking and lifting for me.
   


No matter how you go about it, once you've successfully carved it out you should now have just the unencrypted SWF you can continue your analysis:





8. Open up the unencrypted SWF with your tool of choice for analysis.  If you're using Adobe's SWF Investigator then copy out the disassembled text by; SWF Dissasembler tab > click 'open with text editor'.
   
   Once you have the dissasembled code, scroll down until you see the blob being passed into the ByteArray and copy out what's inbetween the quotes:
   
   
   
   
   
   
9. Take that copied out data and paste into a hex editor.  Since we see some 'eval' occurring and this blob being a variable in the ByteArray I'm going to say this looks be the shellcode so let's go ahead and pass this extracted code within a shellcode analyzer for ease (scDbg/libemu in this example).  When initially analyzed it detects that the data is XOR'ed with the key '0xE2' :
   
   
   
   In the output of the first run through libemu we noticed there was an error so by adding the '-d' switch and running through it we get the following:

10. Well that's helpful - now we don't have to question if it is and/or search for the key since it's already provided to us.  This allows us to move on to reversing the XOR with a capable program (xor.exe in this example):




A quick test of determining what the actual file is (shown in the second command above) after being reversed shows it's just 'data'.  Hm, it doesn't appear to be what I'd expect as a result of the shellcode or did something fail when performing the XOR?  If we view the strings of this data we see it displays a link to a file which could indicate a 2nd stage download:

You can continue your analysis as needed from here but for the purpose of this post hopefully this showed you a thing or two that you either previously weren't aware of or was causing a road block in your analysis efforts.  As always, there are many ways to accomplish the task at hand and if you have a more efficient way to accomplish what I've touched by all means pass it along.

Customizing cuckoo to fit your needs

This has been ported over to my GitHub site and is not longer being maintained here. For any issues, comments or updates head here.

With the talk of the .4 release of cuckoo to be publicly released shortly I figured I should get this post out as some of the things I talk about here are said to be addressed and included in that release.  If you don't want to wait for that release or something I touch on here isn't included in that release then hopefully the information below will be of use to you. In full disclosure, I'm not a python guru so if you see something that could have been done an easier way or something turns out not to be working for you please let me know...I found out the hard way python is strict on spacing.  Throughout my testing it all seemed to work fine for me but there may be some scenario I didn't test or think of.

(patches available on my github)

General Notes

The installation notes are pretty straightforward to get you up and running and after you successfully do it the first time, any subsequent installation process should be even faster for you.  There are a couple of notes worth mentioning though:

• The first user you create during your Ubuntu installation is an admin user.  This is important to remember if you want your cuckoo user to be a limited user.
• When you add the cuckoo user to its group, you need to log out and log back in for it to take affect.
• To ensure there are no permission issues, you should do the virtualbox setup as the cuckoo user instead of another admin/root account.
• If during your analysis the VM isn't able to be restored or you need to kill cuckoo.py then you need to run virtualbox after and take the vm our of 'saved' mode by discarding it.
• If you are installing 3rd party applications (and you should be if you want to test exploitation), make sure you're properly pointed to them within their appropriate analyzer file "/path/to/cuckoo/setup/packages"
• There's a default list of hashes for common programs that are automatically discarded in the dropped files section so be aware of them "/path/to/cuckoo/shares/setup/conf/analyzer.conf"

Patching

Instead of re-posting all of the files in the cuckoo repo I decided the easiest way to go about releasing these patches/modifications was to utilize the diff & patch commands in *nix. To create the patches:

diff -u 'original' 'new' > 'file.patch'

and once the patches are downloaded from my github, all you need to do is run:

patch '/path/to/original/cuckoo/file' < 'file.patch'

Customization

Web Reports/Portal

At first I couldn't understand why I was able to continuously reanalyze a sample but when I thought about it , it made sense.  Since cuckoo gives you the ability to analyze a file in multiple VM’s, it has to be processed more than once (duh)…maybe a better approach would be to only have that sample be analyzed once by the same VM.

In the main web portal page you are presented with a single search box to search for a files MD5 hash. For convenience and as a time saver I hyper-linked the files MD5 hash in the general information section as well as the dropped files section so you can quickly see if/when it was analyzed previously instead of having to copy and paste it in the main search box every time.

I didn’t want to clutter up the general information section of the report with all of the scans and lookups I was adding to the report so I created two other sections for the report (signatures & lookups).

Signatures

Within the signatures section I added the following ClamAV (2 versions) and YARA.  If you have other scan engines you wish to run against your files then the same type of method could be re-used.  With all three of these features you need to configure the location to their corresponding signatures within "/path/to/cuckoo/processing/file.py".

ClamAV

(besides for above noted change, you also need to edit the path to your clamscan)
I’m a fan of ClamAV and the numerous ways it can be leveraged just make it ideal to have included in my automated processes.  If you’ve read the Malware Analysts Cookbook  (MACB) you might recall that there’s some really handy code made available and one of which shows how to do exactly what I wanted to do – scan the files with ClamAV and show the results.  I don’t like to re-do what someone else has done if it works how I need it to so I made one or two modifications and plugged it in as necessary.

Custom ClamAV

Using the traditional signatures database from ClamAV is good but it can also be worthwhile to create some of your own signatures (remember how logical signatures can be a big help) so I also added a section where you can point it to your custom ClamAV database so it can pickup on other signatures you’ve personally written/acquired.

YARA

On the cuckoo mailing list I came across another user who said he had patches for implementing YARA into cuckoo.  If you’ve read any of my past posts or follow me on twitter you’ll know that I’m a fan of YARA’s capabilities and as such contacted him to see what he had wrote.  The patches themselves were very straightforward and since they worked I didn’t see a need to change them.  He provided me a link to them on his personal GDrive so if you only want to implement that feature into cuckoo then you can use his files, however, the files I’m releasing have that already implemented so no need to do double the work otherwise.  When/if more than one YARA rule is matched, they'll be comma separated within brackets.  The additional files needed besides for for the ones in my github that you'll need to download and install are:

• http://yara-project.googlecode.com/files/yara-1.6.tar.gz
• http://yara-project.googlecode.com/files/yara-python-1.6.tar.gz

Lookups

The looksups section only contains two actual lookups at the moment but also contains what I refer to as ‘future linkage’.  I didn't add the lookups section to the dropped files section because I plan on analyzing them automatically with the modifications mentioned earlier and that would just be too repetitive and a waste of a time.  As far as actual lookups I put in Cymru and VirusTotal for right now so if there’s Internet they will pull the last time the sample was scanned/seen with their services and the A/V detection rate (note - I'm only querying for the hashes, I don’t like submitting for a few reasons).

Team Cymru 

Team Cymru offers a couple of very useful services and one of which I use during investigations is their Malware Hash Registry (MHR). MHR will take the hash(es) you supply it and tells you if it’s a known bad file, the last time they've seen it and an approximate percentage for A/V detection. MACB also had a recipe for adding this to a script so once again I just modified as necessary and inserted to fit cuckoo.

VirusTotal

There are a few scripts online to utilize VirusTotals API and submit/query their site but I decided to use this script.  You can use any method you'd like but if you use the patches I provided just install that script and supply your API key in "/path/to/cuckoo/processing/file.py".  I didn’t want to overly insert code into the existing cuckoo files so I opted to build this file and then import it from within cuckoo.  Essentially I take the files hash and try to get a report of it and if it exists just pull last scan date and detection rate.  While it can be useful to see what the A/V's detected it as, I didn't want to waste time making a collapsable table including all of this information if the new release of cuckoo will already do this.  If it doesn't, then I'll re-visit it.

If the sample doesn't have any VT detection or exist then I have it just state that and if there’s no current Internet connection then state an error.  The latter is very important because I’ve seen others trying to stuff this capability into their code but they fail to address the scenario when there’s no Internet connectivity and therefore their report will fail to be created because they don’t handle the error created.  I wrote it so it would be generic in catching an error because I don’t want my report to fail because of this so if there’s no Internet connection or another error (note that this will also suppress the error that your API key may be wrong!) and the rest of the report is fine to generate then it can still generate.  The same hold true for the snippet for the Cymru check.

Internet connection and results found :

No Internet connection :

Internet connection and no results found :

Future Linkage

I thought it was useful to pre-link the samples to common online sites people use for additional reference/analysis (malwr, shadowserver and threatexpert).  Instead of slowing up the analysis by trying to pull down all of these reports if they exists then parse them I decided it was just easier to create a link for them based on the samples hash that way even if the sample hasn’t been analyzed on any of these sites at the time of my analysis, I could go back to them at a later time and check if a report exists since then.  Just another way to save some time and make life easier.

Dropped Files

Cuckoo will take any dropped files during the analysis of the sample and copy them back over to the host machine under the structure "/path/to/cuckoo/analysis/<#>/files".  By default those files are just left in that subfolder and not analyzed (they will have basic information such as file type and hash in the report though) but I felt it didn't make sense to just leave them in that sub-directory (at least for my goals) so I added the following opted to change "/path/to/cuckoo/processing/data.py" so it would take those files and move it to my samples directory (/opt/samples):

 shutil.move(cur_path,'/opt/samples')

This samples folder is the folder that I'm going to monitoring for new/created files and automatically process them to be analyzed as mentioned later via the watcher.rb script.  Once I did that I noticed another side affect... if there was a queue in the samples directory and the files being moved from the dropped files folder to the samples folder were the same then it would crap out.  I thought the move command would overwrite it but it didn't.  I figured this could be fixed by either copying instead or what I chose to do, check if it exists and if so just delete it from the dropped files folder since it was going to be processed anyway:

        check = os.path.join('/opt/samples/', cur_file)
        if os.path.exists(check):
            os.remove(cur_path)
        else:
            shutil.copy(cur_path,'/opt/samples')
            os.remove(cur_path)

        return dropped

This may not be something that everyone feels they want to do since one obvious consequent I could think of was that since every file is being moved out of the dropped files directory, any special configuration file etc. that you might be interested in won't be there (unless you do file type identification and only move files which can even be processed or if a file can't be processed, move it out of the samples directory to another folder to store dropped files that couldn't get processed i.e. - html files, js etc.).  Another reason might be because it may end up being a continual loop.  Some malware will go out and download another copy of itself etc. and as such by continuing to automatically analyze them will just cause a loop.  This will vary of course by sample, if the Internet is connected and what you want out of your analysis.  Other than that, your analysis task numbers might rise quickly but that shouldn't be on concern because you aren't going to have a sequential set since there's going to be times when a file can't be processes.

Samples Directory Watcher

Melissa wrote a post a little bit ago on integrating cuckoo with NTR and in that post she touched upon the usefulness of having a script running to automatically realize that a new file was created or moved to a certain directory and then take action on that file.  I thought it was nifty and since it was already built into Ruby, I wasn't going to try and hack something else together and see how it held up.   I've read that INotify can be a memory hog so that's something that should be paid attention to although I haven't had any noticeable issues thus far.  If you read the original post you'll soon realize there's some typos... Melissa pointed one out but there are a couple others that might make you frustrated when troubleshooting and to make things easier, I took care of them already.  To get this directory watcher up and running do the following:

sudo apt-get install ruby rubygems 
sudo gem install rb-inotify  

Update 07-18-12 : ... had the wrong command for installing rb-inotify

Download the modified watcher.rb script (on my github too) and edit it to point to the directory you want to watch and the script you want it to execute upon an action/event occurring.  Instead of having an interim script here you can just pass the new sample to "/path/to/cuckoo/submit.py" but I realized I needed an interim script because the sample might be password protected or in a format that cuckoo wouldn't take (i.e. an archive file).

That's the basic customization you need to do for this script, however, you can change it as you see fit.  Initially when I was talking to some Ruby gurus they said that using the IO.popen method was overhaul for what I wanted to do since all I'm essentially doing is passing along a string (new file created/moved) to another file to process.  For testing purposes, I changed it to use exec instead... which worked, but would kill the watcher script after each event.... and that basically killed the purpose of me even having it running so I opted to keep the original method. Once you have all of the pre-reqs installed and the script modified to your needs just open another tab in your shell and let it fly (you don't need the '&' at the end but I like to get my terminal back):

ruby watcher.rb

Archive Parser

If you’re like me then you might have some emails which contain malware samples as attachments or download/get sent password protected archives with possible malware.  If you hand cuckoo an archive or email file (pst etc.) then nothing will happen as it doesn't have a default module to handle them.  As far as the email situation goes, the sheer thought of individually saving each sample one by one doesn’t sound like fun so figured within the interim script I'm calling from the watcher script that there would be a check for a Microsoft Outlook data file and if so, run pffexport against the file.  The thought process is to basically just recursively extract everything out of the the email messages and attempt to process them with cuckoo (if you install libpff, remember to sudo ldconfig after you install it).


To address the archives/pw protected archives issue I try to identify it as an archive file and if so, try to unzip it both with and without a password.  I wasn’t aware that if you supply a wrong password to unzip a file with 7zip that it will still unzip the archive if it turns out that there isn’t even a password protecting the archive (thanks Pär).  I also have a little array set up which contains some of the common password schemes used to password protected malware archives that way I could also add to it in the future (sort of like a dictionary).  

 Additional Software

Depending on the installation you're performing and what additional features you're going to be installing there might be some additional software required which could include:

• YARA
• sudo apt-get install libpcre3 libpcre3-dev 
• python
• sudo apt-get install python python2.7-dev python-magic python-dpkt python-mako
• ssdeep
• http://sourceforge.net/projects/ssdeep/files/ssdeep-2.8/ssdeep-2.8.tar.gz/download
• svn checkout http://pyssdeep.googlecode.com/svn/trunk/ pyssdeep
• g++
• sudo apt-get install g++
• subversion
• sudo apt-get install subversion
• 7zip
• sudo apt-get install p7zip

To-do/Wish List

• The cuckoo DB that's created "/path/to/cuckoo/db/cuckoo.db" only stores a limited amount of information within it.  Even though information regarding a files SHA1/256 hash, ssdeep hash, mutexes, IP/domains etc. are included in the samples report, they aren't stored in the DB.  This helps keep the DB to a limited size but doesn't help if I want to search my repository of analyzed samples for all samples which called a particular IP/host etc.  I didn't want to start changing big chunks of the code to implement this at this point because updates may kill it etc... so I think the better solution will be to only change the snippet which says which fields to create in the DB and to store other selected fields into that DB after analysis.  Another solution can be used to query that DB as it's a common task many of us do anyway.
• The file identification process for determine what type of file the sample is and if it should be processed is pretty basic at this point.  It does the job but at times could use a boost.  A similar thing noticed is if there's certain characters in the samples file name then it won't get processed.  This looks like it could be a one or two line fix with something like Python's string.printable .
• After talking with one of my friends about cuckoo he noted that he's observed not all of the dropped files from the sample being analyzed were being copied back over to the host after the analysis.  This is no bueno... and while I haven't verified this at this time, a simple solution looks to be installing CaptureBAT on the Windows VM and using something (xcopy or robocopy) to copy all of the files caught by CaptureBAT back over to the host after analysis.
• I'm debating to add a switch so I can choose for the analysis to either run wild on the Internet or feed it something like INetSim for simulation.  There are pros and cons to each scenario and maybe a better solution is to use something like Tor ... but I'm up in the air.  As a side note, installing INetSim can be a pain and I'm spoiled as I'm used to it already being installed so other options to look at could be something like HoneyD. 
• I'd like to modify some of the existing analyzers to run additional programs against a sample and report on their results (i.e. hachoir-subfile, pdfextract etc.)

Is that an infection or a false positive?

This has been ported over to my GitHub site and is not longer being maintained here. For any issues, comments or updates head here.

Have you been in a situation where there's a file being flagged by A/V and you don't really agree? (...is that rhetorical?)  I was in a situation where I was noticing files being flagged as a generic variant of ZeuS and while at first you can't necessarily disregard the alert -no matter your feelings on the A/V- you can do a little digging and try to determine what's actually going on.  This  is not something you are or should do for every infection you come across, but rather a more practical use is to understand why certain files may be mis-classified when they are in fact benign.

The particular A/V vendor that was reporting the alerts was classifying them as 'W32/Zbot.gen.*' ... the 'gen.b' was most noticeable.  I grabbed one of the files in question and started to poke around.  Some of the usual first steps led no where - internal hash lookups, external hash look-ups (cymru, VT etc.), pescanner had a generic YARA hit for banker based on a string which looked all too common, dynamic analysis didn't show anything... so I started to extend some of my initial steps:

I extracted the PE sections with 7zip so I could do sectional MD5 hashing and see if I could get any leads by comparing those to other known bad sectional hashes :

$ 7z x <file>.exe -osections

The above syntax will extract the contents of each of the PE sections, in a tree structure (note that these will most likely be hidden since they start with "." so make sure you list all) :

Now that the PE sections are dumped I opted to use ClamAv for creating the sectional based MD5's.  ClamAV gives you this ability by using the following syntax:

$ sigtool --mdb <file>

The format that gets created for these signatures is:

PESectionSize:MD5:MalwareName

 If you do it right, you should see similar output to this:

57344:fceb22b4c5be5a981e6b7bd1e47dca63:.data
45:8e5a1b84a87bcd2eed7b3ab698a72123:files.txt
77824:34aeb441429d8f6184d0f6ba5d34cddd:.rdata
479232:68c0e32b605b7ccead4ad9520d5a5acc:.text

Welp... no luck on that front either -  but since I didn't have all my samples to cross-check them against, it was more of a long shot anyway.  Now what sparked curiosity is that ClamAV was also raising alerts on this particular file with the name "Trojan.Murofet".  That name is interchanged with Zbot depending on which vendor you're using so it was still leaning towards the same kind of classification for this file.  Hey, if two A/V's are flagging it for pretty much the same thing isn't that more credibility?

I've been incorporating ClamAV and it's misc. tools more into my process because it's free, maintained, cross-platform, I'm able to create my own signatures and I can even view/edit theirs.  Think about how great the latter of that statement is... If I don't like how something's being detected, I can change it myself.  If I want to catch something from my personal collection I can create my own signature and here's the greatest part - I can see what was being used in order to classify a detection.  Most of the bigger A/V companies hold that little gem to themselves and thus make this type of analysis difficult.

Using ClamAV's sigtool I decompressed its main signature datababase :

$ sigtool -u /path/to/main.cvd

The second part of the above image shows me searching for the detection it was classifying it as (Murofet).  You'll notice that there's more than one entry in this case and that they're both a bit different.  The first hit, Trojan.Murofet, is a sectional hash signature taking on the following format:

69632:7e82be33bfa6b241bf081909d40e265c:Trojan.Murofet

Explained:
PESectionSize:MD5:MalwareName

The second hit, W32.Murofet, is a regular signature taking on the following format:

W32.Murofet:1:EP+0:e850000000e9????????73686c776170692e646c6c0061647661706933322e646c6c0075726c6d6f6e2e646c6c00536f6674776172655c4d6963726f736f667400746d7000687474703a2f2f002f666f72756d2f005589e583ec0453e8ea0100008945fc

Explained:
MalwareName:TargetType:Offset:HexSignature[:MinFL:[MaxFL]]


The second hit is of more interest in this case if we take a look at what it's really saying...

For any 32/64 bit EXE, if at the entrypoint you see "èPéshlwapi.dlladvapi32.dllurlmon.dllSoftware\Microsofttmphttp:///forum/U‰åƒì Sèê ‰Eü" then flag it as W32.Murofet.

The HEX string showed in the hit can be decoded from HEX to ASCII which will reveal the string displayed above between the quotes.  The use of double question marks inbetween is a wildcard stating "match any byte"


Since I now know what the signature within ClamAV was triggering on I wanted to take a look at the EXE's entry point and see if those strings were in fact there.  Even though this could have still been done within REMNux, I flipped over to a Windows analysis box and opened the file in CFF Explorer to get a different view of things.  From within the 'Sectional Headers' I could see the entrypoint (bottom right):

Geared with that value I opened a hex editor, HxD in this example, and pointed it to go to that offset :

and wouldn't ya know it ... I was presented with "shlwapi.dll , advapi32.dll,  urlmon.dll, Software\Microsoft, tmp, http://, forum" .  So does the presence of these strings make the file malicious or do they simply help in trying to determine its characteristics/capabilities from a static analysis perspective?  If you've ever analyzed a ZeuS sample you'd notice that what was uncovered here doesn't quite line up with the normal data encountered, however, what about ZeuS-Licat?  Trend Micro has a great write up [PDF] here.  What it appears is that there was a version of ZeuS somewhere else which dropped Licat and what we saw at the files entry point was newly added malicious code - now  appended to this once legitimate file (file infector characteristic).

Even if you can't dig into the signature responsible on the other A/V you shouldn't call it quits.  If you can find another tool (such as ClamAV) which is classifying it in a similar way then there's a good chance that it's following some of the uncovered signatures logic within ClamAV and you have an idea of how/if it was being mis-classified. Even if you look at a file and a large majority of it looks legitimate -and- even may still run as it once did (in this example the malicious code would execute at the entry point and then jump back to the files original entry point so it could run as it normally did) try and look for anomalies and if possible cross reference the file in question with another version of the original file to find discrepancies.

More information on ClamAV signatures.