Let Me In

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

A few months ago I was doing some research regarding various ways incident responders could unlock both a live and dead system for an article I was publishing in Digital Forensics Magazine entitled "Let Me In". If you're not a subscriber to that magazine the article essentially listed some tools (Kon-Boot, Ophcrack ,Back Track, Inception etc.) and reasons for needing to perform such tasks (EFS, FDE, need to use the proprietary software on the system to open data etc.). While it was supposed to be in an earlier issue, it got pushed back to Issue 11 - May of 2012.

There was a good amount of content I had to trim out of that article so I decided I would write up a post to further elaborate about one of the sections – unlocking a live system. When I say ‘unlock’ I am simply referring to bypassing the authentication on the Operating System (OS) level and since Windows it is still the most dominant platform on the market it will serve as the main OS discussed. So why not just follow traditional methods and image the disk to perform forensics offline? There may come a time when you are presented with a locked system and are unable to shut it down because the volatile data is imperative to your investigation, it has Full Disk Encryption (FDE) or maybe it is a critical server. Whatever the reason may be, I asked the question - "What would you do?"

Considerations

Most modern techniques for unlocking a live system rely on the IEEE 1394, or FireWire interface. FireWire is a serial bus interface which allows for fast data transfer. The reason it is able to achieve this and why we care about it for Incident Response is because FireWire provides the ability to read/write directly to a systems memory through Direct Memory Access (DMA). By doing so, we are able to bypass the systems Central Processing Unit (CPU) and OS to circumvent any restrictions which would otherwise prohibit such ability. Before just jumping into trying these techniques you should test and validate your trials to ensure you are aware of the benefits, artifacts created and possible limitations. Some of the considerations that came to my mind were:

1. Will you have physical access to the system?
2. Does the target system have Full Disk Encryption (FDE)?
3. Is there a FireWire port on the target system? If not can you insert an expansion slot (PCIe, ExpressCards etc.) as an alternative for a missing FireWire port? Will that FireWire port suffice?
4. Whether or not the 1394 stack is disabled on the target system
5. What OS and patch level does the target system has?
6. How much Random Access Memory (RAM) does the target system has?
7. Did the FireWire driver install successfully on the target system?
8. Is this forensically sound and will it hold up as acceptable/repeatable if questioned in court? Let’s remember that if we choose to unlock the system we are actively writing back to the target system, which could mean we write outside of the memory we want or cause the system to blue screen.

Unlocking a live system with Inception

While the concept of using FireWire to bypass the Windows Lock Screen has been discussed and presented since 2004, most notably Winlockpwn by Adam Boileau which used raw1394, there wasn't a whole lot of development or maintenance of such methods. During my research into this area I came across a tool called "Fire Through the Wire Autopwn" or FTWAutopwn which provided a more stable and reliable means than previous tools, such as Winlockpwn. This was because it incorporated a new open source library called libforensic1394, which uses the new Juju FireWire stack and allows you to present a Serial Bus Protocol 2 (SBP-2) unit directory with original FireWire bus information from your machine to the target system. As previously stated, my article got pushed back an issue and as luck would have it the author of FTWautopwn changed the tool to "Inception" which is the same project just renamed and updated since my initial testings’.

* If you're interested in this topic I suggest reading this paper by Freddie Witherden.

Inception is actively maintained, which means its author is constantly adding new features, bug fixes, and more reliable unlocking techniques. I exchanged a few emails with the tools author back when I was testing the original FTWAutopwn and provided some feedback such as - when there's multiple signatures/offsets for a target, if the correct combo unlocks the system then quit and don't continue to try other combos. After going back to this tools site recently it appears new signatures and methods have been incorporated and a couple of the things I brought up have been addressed so it's nice to see the active maintenance.

This tool works great for Windows XP SP0-3 and Windows 7 x86 SP0-1, however, it may be a hit or miss if you are trying it on Windows x64 systems based on my testing a few months ago - but again, you might have more luck these days. The main reason you might fail at unlocking is because the method it uses relies on the signature it is patching to be at a specific offset and on 64 bit systems the offset address is less stable and more likely to change. If the signatures and offsets within the configuration file are not working for your scenario and you have some disassembly knowledge, you can load the specific msv1_0.dll version into a disassembler and determine the signature/offset combination that you need to add to Inception. Instead of re-posting how to do this, check out here and here.

In Windows, the Dynamic Link Library (DLL) msv1_0.dll is the Microsoft Authentication Package, which is responsible for validating a users' password. Within this DLL is a function called 'MsvpPasswordValidate' which is responsible for performing a comparison between an entered password and the correct password. Inception patches this comparison to say that the correct password was entered regardless of what or if anything was entered at all. Since this is all done in memory, the patching is not persistent and restarting the system will restore to its normal authentication (that's if all goes well of course).

Once you have your system properly configured and DMA access to your target system, choose which target you want to unlock and if you are successful you will see a screen similar to (screenie is from FTWAutopwn):

Dumping the memory of a live system

Besides for being able to unlock a live system on the fly, the libforensic1394 library also provides a means for dumping the memory of a live system. If you take a look at the authors’ paper[PDF] he provided some additional insight of how to do this. The only additional requirement missing is a little knowledge of python. While doing my research I came across another paper[PDF] where a researcher was testing Mac OS Lion memory acquisition using FireWire. While he also utilized the libforensic1394 library he additionally included a PoC python script to dump the memory of a live system. This was another bit of information I passed along to @breaknenter and looks like the updated tool incorporated this feature as well (score).

Start-up script

Instead of remembering what commands need to be entered, what files need to be downloaded and what packages are required I wrote a simple setup script for BackTrack to automate the process. Additionally, it was written to be used with a non-persistent system (Live CD/USB) as well as a system with a persistent configuration. In my opinion, creating a USB with persistent storage works the best but if you are going to run this type of script on a non-persistent system, Internet access is required unless the files/packages required are downloaded prior and stored on some other removable media that would then have to be configured in the script as well. Since the tool has changed and the new version has its own setup script I'm not sure if it’s worth changing my start-up script :( ... I don't believe Inception checks for the all the required files (libforensic1394 etc.) and if you're using Inception on a distro like BackTrack I don't think it will set the environment accordingly so if I see a need I'll make some modifications accordingly.

Deobfuscating JavaScript with Malzilla

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 was asked a question a little while ago from a fellow forensicator about deobfuscating some JS that he came across.  The JS didn't take long to reverse but I suspect there are others out there that would benefit from a quick post regarding another way to go about this task.  While there's jsunpack, js-beautify etc. I chose to run it through Malzilla for this example.

The structure of the JS was noticeably familiar and turns out to be related to an exploit pack; which is a common source of where a lot of the JS you might come across in the DFIR field results from these days.  These types of kits make it point-and-click easy to not only distribute malware but also make it uber-easy to obfuscate the code on their pages.

The first thing to do is copy out what’s in between the ‘<script>’ tags and place it in the top box of the ‘Decoder’ Tab within Malzilla - we don't need the other <html> tags etc., we only need the goods.  Next step is to get rid of what we don’t necessarily need at this point (shown commented out with ‘//’).  This will vary depending on what you're analyzing and may take a bit more knowledge to realize but just remember what your goals are - there will be junk thrown into the mix and since all I care about at this point is to see what gets produced (URL etc.) the top part didn't look relevant for helping me get my question answered :

At this point you have a few options (1) replace the eval() (2) run it through debugging to verify it's working (3) run the script.  Everything looks good enough to work so let's just go ahead and choose to run the script:

Note that even though the bottom text displays “Script can’t be compiled” (seen above) … the eval results were still produced.  To see the results, click on ‘Show eval() results’ then double click on each of the results (one in this instance) and the results will be displayed in the lower pane – this time showing the produced iframe :

There's generally always more than one way to get the results you require so hopefully this will help some of you next time.

YARA + Volatility ... the beginning

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

YARA - the sleeping giant.  There's been mention of it over the last few years but as far as adoption - I think it's still lacking in the tool set of many analysts. I personally like to leverage YARA on its own, within pescanner and most definitely within volatility's malfind.  I've recently encountered two obstacles (1) Converting ClamAV to YARA signatures and (2) How to process multiple YARA rule files.  If you take a look at page 26 of YARA's v1.6 User's Manual you'll see it outlines an option to include multiple rule files from within a single file (thanks Par).  In other words, if you use the standard syntax for calling YARA from the cli "yara /path/to/rules.yara <file>" you can't specify multiple rule files (without some foo of course).  Another prime example is within MHL's pescanner where you define the location of your rules file at the bottom, but again, a single rules file:

The above image shows the configuration within pescanner where you define the path to your YARA rules.  This particular example is taken from REMnux and is already filled out, generally it's left blank for your own configuration.

The use of the 'include' feature is one way of circumventing such a restriction because by placing this with the path to your other rule files to the top of the main rules file you're invoking, YARA will automatically process those additional rule files as well.  Here's an example of what I mean:

Simple and straightforward.  Just pop that syntax into the top of your main rule file and you're good to go.

So.. cool right?  Sort of... maybe useful if you have certain rule files you want to use for certain things, like pescanner, but I have a lot of files :/ . If you don't have many rule files then sure... but what if you have a bunch of different ones and foresee yourself continuing to split up or create new ones?  Having to constantly update the main rule file with an "include /path/to/new/rules.yara" every time just sounds like too much upkeep.  Say what..you don't see yourself having that many rule files for it to be a concern you say? ... Well what if, for example, you convert the ClamAV signatures to YARA rules?

The Malware Analysts Cookbook provides such a means with clamav_to_yara.py.  At the time of writing this there is an open issue with this script but there are a couple modified versions which work a bit better - still produce some errors, but not nearly as many.  There are a few tutorials out there on how to convert ClamAV signatures to YARA rules and it looks pretty straight forward, but I found some things have either changed or people just left out details.  If you have a fresh install of ClamAV you need to make sure you unpack its signature file before you can use the conversion script on it.  This can be done using ClamAV's sigtool:

$ sigtool -u /var/lib/clamav/main.cvd

which when complete will leave present you with the following:

Once you have the .ndb file you can proceed to converting as follows:

$ python clamav_to_yara.py -f main.ndb -o clamav.yara

Based on what I've encountered I believe depending on what version of the ClamAV signature DB you have and which version of the clamav_to_yara.py script you have, you may or may not get some signatures which YARA won't process.  I happened to get the problem child this time around and if get errors relating to invalid jumps etc. you can just remove those rules as needed since the errors are nice enough to tell you which lines it doesn't like.

The resulting file was ~18 MB of newly generated YARA rules based off the ClamAV signatures.. fwe.. that's a lot.  I tried multiple ways/attempts to get YARA to use this rule file but failed every time.  My assumption was that it's just too big to process in a timely manner like all of the other (smaller) rule files.  But I had a thought... so I started to split this big ol' file into smaller chunks and wanted to see at about what size would be ideal.  Finally at ~512K it seemed to be pretty fast and effective.  To split the file in an easy fashion you can use some form of the 'split' command... i.e :

$ split -d -b 512k clamav.yara

* if you split based on size like I did here you need to realize that it's going to cut the top/bottom signatures into pieces because you're only taking size into consideration and not splitting based on the signatures' structure. This can be easily fixed by going through each one and re-assembling just those two rules but if you don't do this, it's going to scream about the broken rules.

If you did the math, now you can see where I'm going.  This little workaround produced (33) YARA rule files and no, I don't want to add them all statically in case something changes.  When I'm doing some Volatility automation I usually define the path to my YARA rules in the beginning, i.e. :

YARA_Rules="/path/to/capabilities.yara"

but because of what we've just found out, a simple workaround to use instead is:

YARA_Rules=(`find /path/to/rules/ -type f -iname *.yara -exec ls {} \;`);

What this essentially does (in Bash) is point to the location where you keep all of your YARA rules and then it will list them all so that you don't have list them one-by-one... you can then parse them in an array:

for rule in "${YARA_Rules[@]}"; do 

and then pass them to the normal volatility syntax from within your volatility automation script, i.e:

YARA_Rules=(`find /path/to/rules/ -type f -iname *.yara -exec ls {} \;`);  

for rule in "${YARA_Rules[@]}"; do

   vol.py -f <mem.raw> --profile=<profile> malfind -Y $rule -D /path/to/dump/directory >> log

done 

Hopefully my troubles and workarounds will help someone else out there.. as always, ping me for feedback, tips etc.