Wednesday, February 29, 2012

my past weeks have been quite intensive and busy, unfortunately next weeks seem to follow the same pattern... I am going to travel between conferences and meetings since early April, this could have some influence in my posting frequency. Said that, today I'd like to share a pretty nice tool pointed me out from a student of mine called mimikatz . This windows specific tool helps penetration testers in different ways, specifically it helps pen testers in finding clear text passwords of users logged on windows users and injecting libraries into processes. The author seems to be a french guy who posted examples and test-cases in french language. I am not a native french speaker so I am not going to describe every mimikatz feature (since I could merely understand the one I am going to describe), but rather I am going to describe the ones I believe to be more interesting for pen testers.

mimikatz::inject. This is the inject functionality implemented in mimikats framework. The inject parameter takes the PID and the library to inject as input parameters. The following example is injecting the kelloworld.dll into the process having PID 3256 which happens to be Microsoft Word processor.

This actually makes me reflecting on windows memory management. Since there is no the need of having plaintext passwords in LSASS, indeed it uses hashes and not plain text passwords, it means that the plain text passwords are stuck on the memory in the original input holding variable. This makes me thinking that no memory cleaners are used in windows logon. I am not sure 100%, I could be wrong but if you follows my brainstorming it could be easily this way, which actually is a quite important mistake which allows programs to read logon passwords from memory (as actually is working in this way! ).

The following example shows how to use the hashes functionality to dump SAM hashes:

You will find this interesting tool here (it happens to be a french site, but google translator does its job very well). Finally I like and I do suggest to have in your own swiss-knife this interesting tool specially if you need to inject your own DLL into specific PID getting PID's rights. Have a nice hunting !

Wednesday, February 15, 2012

Reverse engineering executables is always a very challenging procedure especially if the analyzed executable has been packed or encrypted. I've been talking a lot about packers and unpackers (take a look to these posts here) but the technique I am going to show you is totally new respect to those already described. As you might know the most difficult procedure of reversing a packed (or encrypted) executable is to find out the original entry point (OE). Again, there are tons of ways to figure out if an executable is packed or not (aka PEiD) but there is no a universal known way to unpack it. The following image shows PEiD in action.

PEID finds out that the executable has been packed with Aspack v2.12. Nowadays you might find specific unpackers (unpackers designed for a specific packing procedure) but there is no way to have an ultimate universal unpacker. Here you can find many of those packers. YES, I know, there are universal unpackers too, but those unpackers are signature based, meaning that they are not able to unpack "new" packing procedure (algorithms), they must include the signature of every used algorithms. The following pictures shows one of my favorite Unpackers: Faster Universal Unpacker from RCE.

A group of the New Mexico Tech designed a visualization tool based on Entropy (system calls, oriented graphs and so on) called VERA (read more here, here and here). By using this tool you are able to distinguish between packers / encryptors STUB and unpacked / decrypted code by simply analyzing the execution of the executable. The following image shows the notepad.exe (yes the one in WinXP) traced by PIN and visualized by VERA. I traced notepad.exe by fixing 2 minutes of execution here the result:

The blue label represents the Start address (which in this particular case corresponds to OE), yellow color means normal entropy, numbers in labels (you probably cannot see them because the image is too small) are the called addresses. The following image shows the same executable packet by using UPX.

As you may see the are sections (calls to addresses) that have high entropy (meaning be packed or encrypted) represented with RED labels. This alerts us about the presence of a packer / encryptor. Where the is a continuously low entropy labels (purple) we can find the OE. This because the encryptor / packer STUB finished its job and unpacked / decrypted the executable code giving to the OE the control flow. The following image shows notepad.exe packed by BroExePacker.

In this case BroExePacker introduces a two levels of compression STUBs, you can easily distinguish them by looking at the red labels that are present in two points during the execution. This shows a typical two stage decompression. A first STUB decompress the function that decompress the real function who will decompress the original byte code (RED -PURPLE-RED-PURPLE). The OE is placed after the second RED labels. The following image shows the same executable (notepad.exe) compressed by the same BroExePacker but by using a different algorithm.

Again, we can easily discover that this executable has been packed, this time with one level STUB. The OE could be in a couple of positions. Experience will help a lot in finding the OE, but this Visualization tool considerably decrease the complexity of such operation. VERA could be integrated to IDA pro by installing an IDA Pro plugin making IDA Pro communicating to VERA through sockets. This integration makes a lot easier the interaction between the tracer (IDA Pro) and the visualization tool VERA. I am not going to cover in this post how to integrate VERA with IDA, but I am rather cover how to use VERA and PIN in a very quick way. Once you download and install VERA from its website , you will get the visualization tool (VERA) and a small installation of PIN. PIN is the tracer, the one who will produce the .trace file by executing the analyzed executable, the .trace file who will get VERA to elaborate its diagram. The following picture shows hot to run PIN with VERA template.

PIN is now running and tracing the analyzed executable. Let it running for a while (the time you decide) and then close the executable in a normal way (File -> Close, or whatever). Now opera VERA and click on Open. Select the file produced by PIN. Now VERA asks you about the original file and ask where to put its own graph file. The following image shows this process

Once you done with that, VERA will take a while and finally it will show you a graphic traced path. You will find more details on VERA and PIN manual.

Summing up, I wanted to describe a new way to figure out if a executable has been packed or encrypted, and a new way to discover the Original Entry Point of the packed/encrypted executable. My experience in this field let me say that this is a great way to proceed and to learn about packers/encrypters.

Monday, February 13, 2012

This morning I came across an interesting article from HexBlog titled: VirusTotal Plugin for IDA Pro. I took a look to the date, and actually it's not really new, but I believe it is still very actual. What a nice idea having the possibility to monitor your binary directly from VirusTotal ! If you are a malware writer this will increase your productively a lot, in fact you might test your binary on most of the known antivirus engines and if it is catch, dynamically you are able to modify it and resubmit it to antivirus engines for a second round of test. An of course you could follow on this way as many time as you like.

Tuesday, February 7, 2012

Antivirus terminators are specific malware able to terminate antivirus engines without the consciousness of the users in order to install themselves in the target system. This post is about specific techniques to terminate Antivirus. Let describe what kind of terminator techniques could be used by common malware.

One of the most used technique, during the past years is the so called: "DebugActiveProcess". Its names comes from the Windows API used to achieve its goal. DebugActiveProcessAPI allows a generic process to attach itself to another process as a debugger. Debugging a process often means to control it. Since no controller has been implemented on Antivirus engine once an external process becomes its debugger it will crash immediately. Goal reached: Antivirus has been terminated!

Another way to terminate an Antivirus is through the Windows API ZwUnmapViewOfSecion. This API unloads the described .dll. For example a process could unload important Antivirus .dll such as ntdll.dll. Once the Antivirus engine invokes a function wrapped on unloaded .dll it will crash. Goal reached: Antivirus has been terminated!

Another great trick is by getting the handle of an Antivirus engine. Let assume the Antivirus terminator call the Windows API OpenProcesspassing to the function the Antivirus process Identification. Now Antivirus terminator can use APIs such as: NtTerminateProcess or ZwTerminateProcess to terminate the Antivirus engine at kernel level. Goal reached: Antivirus has been terminated!

Different techniques come from graphic user interfaces. Antivirus terminator can use the Windows API FindWindowto select the window to terminate. Through this API the terminator looks in the opened windows set for the exact window matching with the name of the Antivirus engine (such as: antivir, kaspersky, avguard, etc.. etc..). Once the terminator found the right window it terminates the Antivirus engine by sending messages such as WM_CLOSE or WM_QUIT through the respective SendMessage or PostMessage API. Goal reached: Antivirus has been terminated!

Another "graphic" way to terminate an Antivirus engine is by exploiting the function SendInput. Manipulating this API the terminator could stimulate mouse events clicking on the "close button". Through FindWindow API the terminator finds the desired icon, through SendInput it opens up the the desired window and finally it clicks on the close ("x") icon. Goal reached: Antivirus has been terminated!

Antivirus terminators could modify registry so that a NULL debugger is attached once the Antivirus engine starts its execution. For example by using ZwOpenKey and ZwSetValueKey the terminator could open a registry key and modify it to the desired value. Goal reached: Antivirus has been terminated!

Nonetheless the terminator could simply use the API TerminateThread to terminate some threads of an Antivirus engine. Again, Goal reached: Antivirus has been terminated!

These techniques are only some of the used techniques from malware writers, but they are still very used and effective.