PRACTICAL MALWARE ANALYSIS: BASIC STATIC TECHNIQUES (LAB 1-03)

Tools Used:

  1. IDA Pro
  2. PEID
  3. Cerbero Profiler 2.5
  4. OllyDbg
  5. ImpRec

Samples:

  1. Lab01-03.exe  SHA256:7983a582939924c70e3da2da80fd3352ebc90de7b8c4c427d484ff4f050f0aec

Lab 1-3
Analyze the file Lab01-03.exe.
Questions
1. Upload the Lab01-03.exe file to http://www.VirusTotal.com/. Does it match
any existing antivirus definitions?

As of 22nd Jan 2016 there were 43/54 anti virus detection ratio for Lab01-03.exe.

View Lab01-03.exe Report here

2. Are there any indications that this file is packed or obfuscated? If so,
what are these indicators? If the file is packed, unpack it if possible.

Virus total and PEID both detect that this binary is packed using FSG.

In IDA Pro we can observe that there is only 2 functions in the import table which is too few for a proper executable.

lab01-03imports
Import Table

The strings doesn’t tell/show much either. Most likely this binary is packed.

lab01-03strings
Strings

Cerbero Profiler shows that the section headers has no name, a virtual size header of 3000 and a raw size of 0. This is a signature of FSG packer.

lab01-03sections
Sections

Lets try to unpack this packed executable. I cant see a tail jump (via IDA Pro’s graph view) in this case. So I decided to break on GetProcAddress in OllyDbg. Reason for doing so is that I want to find the real OEP and dump the debugged process from there. A packed executable involves 3 steps to unpack.

  1. Decrypt the real executable contents
  2. Repair the Import tables
  3. Jmp to the real OEP in the decrypted contents

So by breaking @ the GetProcAddress I would be jumping straight to step 2. Stepping through a little bit more I should reach the real OEP. Before going further, note that there is an easier solution out there that involves the use of plugins in OllyDbg to find the real OEP… but i prefer to manually find it so as to have a better understanding how assembly code flows.

lab0103_breakpoint
breakpoint @GetProcAddress

Click on the run button and you will eventually break at the above breakpoint. Stepover till you hit RETN 8. You will be returned back to the user code.

lab0103_stepover
Break @ GetProcAddress
lab0103_usercode
GetProcAddress return to user code

I would now remove the previous breakpoint @ GetProcAddress and place my breakpoint at 0x004050E9. This would give me a better picture of the user code process flow. You may find the above address statically via IDA Pro also. Now click on run. The program should stop at the point before calling into GetProcAddress. Now observe the stack.

lab0103_stack
stack

We can see that the program is trying to rebuild the address for CoCreateInstance. Step through and analyse how the program repairs the Import table. Note that after the repair is done the packer most likely will jump to the real OEP.

lab0103_jmp

After stepping over several iterations, you will realize that the opcode as highlighted above has yet to take the jump. The address is also quite different from the above jump opcodes. The above jumps are all pointing to 0x405??? but this is pointing to 0x401090. While highlighting the above opcode, press enter to jump to the immediate constant address.

lab0103_oep
OEP found

This looks like a typical function call’s prologue. Most likely this is the original OEP. How did we miss this function back in IDA Pro? Most likely these codes are generated dynamically (decryption etc). Let’s investigate shall we? Right click on address 0x401090 and set a hardware breakpoint (R/W) there. Then restart the debug.

lab0103_unpacking
breakpoint @0x401090

If we look at the opcode at 0x405022, a mov instruction is executed to move a byte from ESI to EDI. EDI is currently pointing at 0x401091. If we look at the memory address at 0x401090, we would see that 0x55 is written on it. The rest of the address space after it is still empty. This is the part where the packer is unpacking the real code for us in memory. Continue stepping through and you will see the entire code unpack before your eyes. To dump out the unpack process into a physical file, i set a software breakpoint at address 0x401090 (after the decryption) and let my program runs till it hit this address. Now dump the debugged process via the OllyDumpEx Plugin (You would need to install this plugin).

lab0103_dump
OllyDumpEx

Change the PE’s Entry point to 1090 (we found the OEP at 0x401090; minus off the image base of 0x400000). Click on dump and we are nearly there… If you try to execute the dumped exe… the program will crash. This is because the IAT has yet to be fixed. The current imports is the old imports (LoadLibraryA and GetProcAddress) and we have just lose our code on rebuilding the IAT (packers code) since we set the OEP to the decrypted function.

To repair the imports table, launch ImpRec tool.

lab0103_imprec
ImpRec
  1. Select the currently debugged process (top drop down list)
  2. Change OEP (bottom left) to 1090
  3. Click on IAT AutoSearch and finally click on Get Imports
  4. You should see the imported functions populate.

Now we have one issue… there is a imported FThunk with a validity status set to NO. Expand the tree and we see thate @rva 204C ImpRec thinks that CoCreateInstance belongs to combase.dll. This is wrong… it should be ole32.dll

lab0103_CoCreateInstance
Resolving imports

There we are good to go. Click on Fix Dump to save a copy of the unpacked executable.

lab0103_unpack
Good to go

3. Do any imports hint at this program’s functionality? If so, which imports
are they and what do they tell you?

The packed executable contains LoadLibraryA and GetProcAddress function. This is a good tell tale sign than the executable is packed and it is using the functions to rebuild the IAT.

The unpacked executable contains the following imports

lab0103_imports
imports

The only interesting function here is CoCreateInstance. According to MSDN, CoCreateInstance creates a single uninitialized object of the class associated with a specified CLSID. The following is the syntax for CoCreateInstance.


HRESULT CoCreateInstance( _In_  REFCLSID  rclsid,
_In_  LPUNKNOWN pUnkOuter,
_In_  DWORD     dwClsContext,
_In_  REFIID    riid,
_Out_ LPVOID    *ppv );

lab0103_cocreate

rclsid: 00022DF01-0000-0000-C000-000000000046

In ollydbg breaking before the call to CoCreateInstance we can see that the rclsid is targeted to “00022DF01-0000-0000-C000-000000000046”. In Registry this value refers to Internet Explorer.

lab0103_CLSID

Internet Explorer

Stepping further down in ollydbg we can see a function call being made with an offset of 2C. Note that EDX is a pointer to ppv from CoCreateInstance.

ieproxy

Question is what is this offset? If we step over this function call, Internet Explorer will pop up with the malicious site loaded. Let’s look at the executable modules in ollydbg.

lab0103_executablemodule
ieproxy loaded at address 0x56EF0000

We now know that the program is attempting to call a function in ieproxy.dll at address 0x56F2d340. If we deduct the image base of the dll the offset is 0x56F2d340 – 0x56EF0000 = 0x3D340. Loading c:\windows\System32\ieproxy.dll in IDA Pro and finding the instructions at offset 0x3D340… we can conclude that the Navigate function is being called which explains why internet explorer pops up after this call.

lab0103_navigate
Navigate Function Call in ieproxy.dll

But where is ppv pointer pointing to? we know that we derive to Navigate function via [EDX+2C] in olly dbg. So EDX contains the pointer to ppv.

lab0103_EDX
EDX

*ppv = 0x56F27188

doing our math again by deducting the image base of ieproxy.dll we derived the offset of 0x56F27188 – 0x56EF0000 = 0x37188.

In IDA Pro we can see that this address is a table pointing to different functions.

lab0103_37188
vftable of CWebBrowserHandler_Interface

0x37188 + 0x2c = 0x371b4 == Navigate function call. With these we now know what offset equates to which function call! =)
Some interesting functions are:

Offset function
1C GoBack
20 GoForward
24 GoHome
28 GoSearch
2C Navigate
30 Refresh
34 Refresh2
38 Stop
CC put_fullscreen
D0 Navigate2
D8 ExecWB

So by calling navigate function, the malware will popup internet explorer and navigates to the url: http://www.malwareanalysisbook.com/ad.html

To inexperience malware analyst, this function call can be easily ignored since it doesn’t look malicious in the first place and it depends on the CLSID used… so do watch out for it the next time =).

4. What host- or network-based indicators could be used to identify this
malware on infected machines?

The only network based indicator I could find is the url http://www.malwareanalysisbook.com/ad.html. You may filter/sniff network traffic to detect if any terminals are infected with this malware.

Advertisements
PRACTICAL MALWARE ANALYSIS: BASIC STATIC TECHNIQUES (LAB 1-03)

One thought on “PRACTICAL MALWARE ANALYSIS: BASIC STATIC TECHNIQUES (LAB 1-03)

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s