Using the Call stack to debug programs

In large pieces of malware it is difficult, when under time pressure to fully reverse it. So, many times you just put a breakpoint on the imported functions like say send() for outbound TCP connections. Then you run the malware.

What happens now, is that the BP will be hit when the malware tries to send traffic. And that's fine. But where was it called from? As in, which function actually made the call to send()? This is important because it'll help you go back and then find out how the payload was constructed, how the C&C was decided... and many other things.

There's 2 ways to do this. One, you can identify all the references made to the send() call by the binary, and set breakpoints on all of them. Then when one gets hit you can inspect it further. This is the most obvious way to do it.

The other way is to first, as usual set a breakpoint on the function you want to trace. Here I just choose SetUnhandledExceptionFilter() as that's the first function I can see :). The address immediately after that is 0100251D - make a note of that.

Then, instead of searching through the 123 references to the call and trying to guess which one is useful, look at where the function is returning to when the  breakpoint is hit. This can be found on the Olly call stack. Many times you have to step through a lot of system function code, but eventually, it will return to user code. I tend to use the Ctrl+F9 while in system code, and keep watching the call stack for when the address changes to one where the code is running from.

Then I visit that address, set a breakpoint and hit F9 again. This time I will break inside the exact place where the call was made from. Note the address? :)


Then we go to that address and set a breakpoint and run...and we'll break in the exact place where the call was made.

Debugging child processes - Olly 2.01h

A lot of malware creates new processes and injects the actual malicious code into the memory of that process and then runs it from there. Meaning..you could start debugging malware.exe...but then find out that it has called CreateProcess() and created a new child process boo.exe. Then it called VirtualAlloc() and allocated memory into some part of boo.exe.

The point being... malware.exe has nothing and you now need to debug boo.exe. There's a few different ways I have tried, all to varying degrees of success.

- Get PID of the Child process from Process Explorer. Then go to Olly and Attach to process.
- Set Olly as JIT debugger. Windows Task Manager. Right click - Debug
- Set Olly as JIT debugger. Set the entry point of the process to CC (a breakpoint) and run the process.
- Try and attach Immunity to the process while debugging the parent in Olly.

But none of that, for multiple reasons worked at all... or worked very sporadically. That sucked.

Luckily OllyDbg 2.01h has this new (well for me ;)) option to debug child processes created by Olly. Meaning, if I'm debugging malware.exe and it creates a new process..and you have this option checked, it'll automatically open a new window and load boo.exe into it :). Perfect.

You can find this option in Olly 2.01 (latest version) in Options - Events. Tick the box that says 'Debug child processes' and save yourself a lot of pain :).

View PE header - Olly 2.01

Many times we want to view the PE header to study certain fields. Its easy enough to do this with a million PE editors out there. You could even do it programatically - I use the pefile module in Python to do it. There's almost certainly others. But the point is... that I love Olly :). How can we do it in Olly?

Well, in Olly 1.10 you could go to the PE header location in the Dump section, right click and select Special - PE header. And this would perfectly parse the PE header and display it in the Dump. Or just go to View - Memory Map, right click and select Dumo.

But Olly 2.01 doesn't have this. The option seems to have changed. I had trouble finding it but finally managed. There is no Special -> PE header menu but a 'Decode as structure' menu.  Here are steps on how to view the PE header in Olly 2.01:

• View - Memory Map. Locate PE header for the exe. Get the address from here.
• Go to the Dump section of Olly. Ctrl+G - enter address.
• So you can right click on the start of the PE header (MZ)  - Decode as structure and in the Drop down box there select IMAGE_DOS_HEADER. Now you see just 1 section decoded.
• Scroll down a bit till you come to the PE header. Right click on the PE header (anywhere...but make sure its inside the PE header, not the DOS header - Decode as structure - IMAGE_FILE_HEADER.

And so on.. use all the different IMAGE_ structures to decode the entire header. Its a bit of a pain really, and I preferred the old way :( or maybe just use another tool - just not Olly 2.01 for this. Its good for other structures though..probably, as you might have guessed.

Extracting PE files from memory

Was recently trying to debug some malware that someone gave me. The malware was extracting itself into memory and working from there. It is possible to debug the malware from memory itself but its a bit painful, since we have to debug the entire memory each time, let the memory get populated with the malicious code and then try and understand what the code is doing. This is a waste of time - and if we can avoid it, we should.

As it turns out, its possible to dump contents from memory. This is specially useful if its a PE file that's unpacked into memory. Coz.. you could dump it and reverse it separately without all that running of the original malware that unpacked it.

I always knew this was possible but for many reasons (a laziness to learn being foremost ;)) I never did it. This time, I was determined to figure out how to do it. Turns out it is fairly straightforward. All credit for me learning this goes to this blog - http://www.joestewart.org/morphine-dll/

That blog should be self explanatory really, but here were my steps.

• Load process in Olly and debug it as usual.
• Once the process has loaded in memory, locate it in the Dump section of Olly.
• Right click inside the dump. Backup - Save data to file to an EXE file on disk.
• Launch a PE Editor (I use LordPE). Locate the last section. Add the RawSize and RawOffset. Record the number.
• Open the hex editor and go to this number (offset) inside. Delete all content after this number. Usually this is all zeros.
  Now go to the start of the file. Delete all content inside the file upto the start of the header (4D 5A). Save the file.
• Open the file in Olly...and there you go.. a normal EXE file.

I tried some plugins like OllyDumpEx but they did not work for me. They probably are fine - just that I mostly made a mistake while using it. I will try some nice plugins soon and update this post when I am done.

Hope this post helps someone easily unpack malware from memory manually. Its fairly easy and you do not need a plugin to do this :)

Volatility - Extracting malware signatures from memory

There's a million tutorials online on Volatility and how to use it. This post will teach you nothing new. It is just my own way of learning the tool. All I'm going to do here is to go through each and every plugin which is listed very well here and very well explained here and make my own notes. If you're starting off with Volatility don't read this post - go read the official documentation.

The purpose quite simply is to just help me remember the tons of plugins that Volatility has, so I can use it while performing malware analysis of all those dangerous pieces of malware.

I'll use the memory images of Shylock downloaded from here to practise running Volatility's plug-ins against. This image can be downloaded from here. The images that I got from the Volatility Git repository (git clone) didn't work for some reason.

- The -f  (image name) and --profile (what OS the image was extracted from) switches are used in almost every command.

- Imageinfo suggests profiles while kdbgscan definitely identifies the best profile to use. Sometimes though kdbgscan also identifies multiple processes. In such cases look at the number of processes that it identified and proceed accordingly.

- pslist gives you a list of processes in the memory. psscan does the same but includes hidden processes which are there maybe, coz of rootkits. pstree does the same but gives you a nice view like Process Explorer does on disk.

- dlllist is a nice plugin that gives you the DLLs loaded by a process. Its best to identify the PID of the process you are after using the previous plugins and then use the -p switch with this plugin. dlldump is the next logical step, you find a DLL and try and dump it. Again, makes sense to focus on a specific process.

- handles, while super-verbose is a nice way to quickly see what all stuff a process is referring. Use the -p and the -t here to filter output. Its very similar to the Sysinternals handles utility.

- cmdscan lists out all the commands an attacker typed and consoles goes one step further by listing the exact output that the attacker saw when she typed it.

- connections lists out all the connections that were active when the image was captured. connscan is cooler in that it also identifies connections that were terminated.

- sockets lists all the listening sockets as well. sockscan does the same thing but in a different way. netscan does the same thing but for different platforms.

- hivelist searches for registry hives in memory. You can actually print out entire registry subtrees using printkey with the -K option which searches all the hives in hivelist's output above and returns the keys with its values if found. hivedump is super-verbose and recursively prints all the keys found.

- hashdump gets stored credentials from memory of all the local OS accounts. You could grab hashes from here and then crack those offline.

There's plenty more and I'll keep adding to this list as I play with them over the next few days. :)

Writing ClamAV signatures

Obviously while learning about malware analysis it is not enough only to know how to reverse malware. I should know how to protect against them as well. So I wanted to learn how to write signatures really well - it could be useful. So I will learn how to do so using the following:

• ClamAV
• Yara
• Suricata
• Snort

This post... I'll start with ClamAV. Here are my rough notes. The aim is to be able to refer to them over time. They are not the most polished blogs ever nor do I intend to make them appear to be that way :)

Here goes.

----
Stop updater daemon: sudo /etc/init.d/clamav-freshclam stop
Update now: freshclam
Update but run as a daemon: freshclam -d
Stop clamd daemon: sudo /etc/init.d/clamav-daemon stop/start. Don't try and start it from the CLI

Send clamd commands using socat:

  - socat - /var/run/clamav/clamd.ctl. Then type command. If started in TCP mode though, you can normally telnet to a port.

  - The connection to the socket times out though fairly quickly by default, so I'd have the command copied to clipboard :)

  - List of all commands available in the clamav documentation on page 17

Scan files: clamscan /tmp/virus_test
Scan files using clamdscan: clamdscan - < /tmp/virus_test

Use libclamav to scan files from inside other software. Can be used with C programs only.

Info about a database file: sigtool --info

Creating signatures:

- Make sure that you unpack the binary before doing this, else it's not very useful.

Hash based signatures:

sigtool --md5 test.exe > test.hdb
clamscan -d test.hdb test.exe
The moment a single byte changes, this signature will fail

Extract sections from PE file and create a signature for each section:

Use my hash_sections script to do this. Another option is to save all sections and use sigtool --mdb

Remember sections with a zero size will cause clamscan to break so don't add those

Also remember that this method is best used AFTER you have done all your analysis and want to detect a packer.. so here you don't necessarily have
to unpack the binary before writing a signature

Similar files but minor difference in certain bytes

This means that it is the same malware but hash based signature or section-hash based signatures will not work. For example:
md5sum 03*
  ae831fcf5591dc0079ebfe4654f23f52 031.exe
  b20a1db0a01f7a6f14f503a6fcdd6c0f 03.exe

Here's a sig where the {4} are the only bytes that change. Save these manually into a file with an ndb extension:

TestSig:1:*:8DBEEB7FF7FF57{4}10909090909090
TestSig:1:EP+6:8DBEEB7FF7FF57{4}10909090909090 [EP is entry point, and this can drastically reduce false positives]

Same logic but with much more powerful signatures. These must be stored in ldb files:

The difference here is that everything is separated by ; characters. All the patterns are right at the end. The penultimate block is the one that decides how this pattern is actually applied, the previous block decides which files the signatures is applied to. The first block is just a name..can be anything.

LogicalTestSig;Target:1;(0&1);8DBEEB7FF7FF57{4}10909090909090;88074701DB

Whitelist files

Same name as the database in which the detection signatures exist. So if all signatures are in daily.cld

The whitelisting file should be by the name daily.fp and have this line (hash : size : random name) in the same dir as daily.cld

5523530941c409b349ef40fa9415247e:51204:Whitelist signatures

This is despite a BAD signature being there in the daily.cld... it'll just IGNORE the bad one

Whitelist specific signatures

Same name as the database in which the detection signatures exist. So if all signatures are in daily.cld

The whitelisting file should be by the name daily.ign and have this line (goodDBname : line number : Actual signature name) in the same dir as daily.cld

daily.cld:1237270:Win.Trojan.Agent-807822

This is despite a BAD signature being there in the daily.cld... it'll just IGNORE the bad one

Some nice References:

http://infosec4breakfast.blogspot.com/2013/06/fun-with-clamav.html
Alain Zidouemba webinar pdf- http://www.clamav.net/doc/webinars/Webinar-Alain-2009-03-04.pdf
Clam AV documentation- https://github.com/vrtadmin/clamav-devel/raw/master/docs/signatures.pdf

The sample files, scripts and its signatures can be found in my Git repository - https://github.com/arvinddoraiswamy/lemal