(anti)Forensics – DiabloHorn

Notes on ZFS / Solaris forensics

A while ago I wrote a script to perform what I called poor man’s forensics. The script was meant as a way to utilize the native operating system to extract some minimal data from exotic filesystems to be able to create a timeline and identify possible abnormalities. As a reminder to myself here are some additional raw notes, commands and resources on performing (forensic || incident response || compromise assessments) investigations on ZFS / Solaris environments. I encountered ZFS / Solaris during some of the FoxCert investigations I participated in.

These raw notes are by no means complete and you must definitely not follow these blindly and always ensure you are working on a copy of a copy of a copy of the real evidence.

Continue reading “Notes on ZFS / Solaris forensics”

Corruption & Security

This time it’s actually an afternoon thought. So let’s say you will be traveling from one country to another and you have stored your truecrypt container on a remote site. There is a chance someone might steel it and try to brute force it. Usually if you are paranoid enough a brute force on a truecrypt container is well…useless. Because you are THAT paranoid you actually also want to make sure that a brute force on your container really is futile. So how about corrupting the container in a controlled way? Check out the file format specifications: http://www.truecrypt.org/docs/?s=volume-format-specification.

A good option would be to change the 4bytes of the encrypted TRUE string to some random bytes. Make sure u have a backup of the original bytes(preferably memorized). This should prevent the successful decryption of the container even if someone has the correct password.

It’s security by obscurity but hey…you can never have enough layers of security. Another interesting idea is to modify the truecrypt source/binary on your hard disk to use the string FOUR instead of TRUE for the whole decryption verification. So unless they also steel your modified version of the truecrypt binary they will not be able to open it.

Just to make sure…the above ideas are only an ADDITIONAL security layer and it CAN be broken if detected by an adversary. I just thought it would be fun to have an additional layer of security on my truecrypt containers.

Workable Deniability

So you have just finished installing the hidden operating system offered by TrueCrypt. You are however stuck with the following problem…you need frequent access to the hidden operating system…which means that you won’t be using the decoy system that much. According to the guidelines offered by TrueCrypt this means that your plausible deniability is a little bit less plausible. How about fixing this? What if you could “work” at the same time in both operating systems?

So there I was thinking I could write a blog posting with screenshots and a extended howto. Unfortunatly I am not able to perform the idea on my computer and I got no spare computer left. So I’m just going to put it out there and maybe someone feels like implementing it and letting me know how well it works.

The whole thing is rather simple, it actually fits in a sentence:

Run your decoy OS inside your hidden OS with the help of virtualization techniques.

Like stated before the claim is simple. It’s a shame I got no spare computer around atm to test it out. In theorie it should work fine. Only thing that worries me is the possible evidence that a virtualization application might leave on the booted decoy system, I’m thinking there is none…but I haven’t been able to test this.

So just to be clear this is NOT an idea to go against the TrueCrypt Security Precautions, it’s just another method to be able to spend more time in a hidden operating system without having to worry that it could be compromised because of forensics on your decoy os. This way all the timestamps and the temp files will be kept up to date in your decoy os while you are working in your hidden os.

To take it one step further…you could even write a few scripts to startup your email, mark them as read at varieng intervals and surf around on the web. If they ask you why you have script to automate things inside your decoy os, you can just answer with a simple answer: I’m lazy.

If I get a spare computer anytime soon I’ll be sure to let you know how this method works out.

Scriptable Anti Live Forensics – POC

In short this + python support. I’ve finally decided to build alpha POC code for the idea I already blogged about. Some of you might wonder why I choose to support python, seeing that I previously wrote about it and I hate/loved it. Well because afaik it’s the easiest language to embed inside C. Oh and the reason why I added support for a scripting language is because some things are just so much easier when done in a scripting language. So let’s see the actual code(make sure u read my previous blog post else the next stuff might sound like total gibberish).

Continue reading “Scriptable Anti Live Forensics – POC”

anti-live-forensic toolkit

Well I’ve been developing this for a while now and still haven’t finished, mainly because I’ve got little time to spare for coding. Previously I wrote about using somekind of ping to see if your computer is still connected to the net. The solution is fun but it will not prevent forensic analysis of your computer. I have expanded upon that previous post and started to write a toolkit which could be used if we assume the following:

You want to prevent live-forensic analyses of your computer at all costs. You don’t care about normal forensic analysis because your harddisk is encrypted and you have used a real long password and a keyfile.

So with that in mind I started to construct something which frustrates live forensics and at the same time is easy to expand. If you are concerned about normal forensic analysis you can always turn to some of the current anti-forensics projects like the one at metasploit.

Continue reading “anti-live-forensic toolkit”

JavaScript deobfuscation a little start

So I’ve been trying to get more information about the funky world of JavaScript deobfuscation. It’s really fascinating what kind of protective measures and obfuscation JavaScript can reach. So whith what kind of stuff have i been playing around?

SpiderMonkey FTW!

No really, it’s easy, it’s proven and it works. Installing is really easy…lotsa documentation also. The best part of it was that…spidermonkey does not have default support for things like document.write(); After googling I found out about 2 ways to achieve it. The first method involved changing the C files and recompiling and such…the other method was so much easier. Have a look:

part1 for a nice introduction

part2 with the solution to add document.write(); support.

For the ones interested here is the method where you need to recompile spidermonkey and such.

There are a lot more of interesting deobfuscation tools out there to play with though.

Ultimate deobfuscator

malzilla

So this has been my little introduction to javascript deobfuscation I will certainly keep playing it’s fun, I never thought javascript could be used for so much evil but fun things.

Reversing, grasping the big picture

So no reversing section but still a reversing post. My personal opinion is that reversing is part of a forensic research in some way or an other…you could state that reversing is like a very specific forensic investigator. Most people asociate reversing with copyright infringements and bypassing security measures to access forbidden goodies(game cheats for example). Reversing can also be used for legal purposes just to name a few:

perform a blackbox audit on an executable
perform a investigation on a piece of malware
help develop a quick patch until the official one is released
learn and understand compiler optimization

I love reversing, I also hate reversing. Yet I keep practicing it and trying to learn. Why ? Because it really is a beautifull way to learn new things and to relax(this depends on the person reversing of course).

Continue reading “Reversing, grasping the big picture”

IDE Sniffing || Detect WDE/FDE

Maybe “IDE Sniffing” is a bit misleading…but I was not sure how to call it otherwise. So this is the problem context: You need to know if a harddisk is encrypted but you are not allowed to disconnect or move the computer. You have no access to the computer, like no login,no firewire to exploit and no vulnerable services running. Let’s also assume that this computer is using normal IDE ( I know it’s a bit outdated) disks. How on earth are we going to find out?

Continue reading “IDE Sniffing || Detect WDE/FDE”

FDE / WDE spiced up

So you got your harddisks encrypted and feel totally secure? Think again.

Investigators have got some nifty devices which are capable of moving your pc without disconnecting it. Effectively bypassing FDE/WDE encryption if you are not used to lock your computer. Although locking doesn’t seem to be the answer nowadays with all those firewire hacks. So what’s left to do?

First of all disable firewire and make sure you always lock your pc. In the strange case that you do not lock your pc I made some easy yet (this hasn’t been tested in a real life situation) effective code to frustrate the investigator. This is just some quick POC (forgive me the messy code) I wrote. In a lab environment this works, so don’t blaim me if this doesn’t work in a real life situation.

Continue reading “FDE / WDE spiced up”