- IDA Pro
- Cerbero Profiler 2.5
- Lab01-03.exe SHA256:7983a582939924c70e3da2da80fd3352ebc90de7b8c4c427d484ff4f050f0aec
Analyze the file Lab01-03.exe.
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.
The strings doesn’t tell/show much either. Most likely this binary is packed.
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.
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.
- Decrypt the real executable contents
- Repair the Import tables
- 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.
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.
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.
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.
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.
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.
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).
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.
- Select the currently debugged process (top drop down list)
- Change OEP (bottom left) to 1090
- Click on IAT AutoSearch and finally click on Get Imports
- 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
There we are good to go. Click on Fix Dump to save a copy of the unpacked executable.
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
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 );
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.
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.
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.
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.
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.
*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.
0x37188 + 0x2c = 0x371b4 == Navigate function call. With these we now know what offset equates to which function call! =)
Some interesting functions are:
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.