You are browsing the archive for Forensic Analysis.

The not so boring land of Borland executables, part 2

December 18, 2014 in Forensic Analysis, Malware Analysis

In the part 1 we explored the case of the resource timestamps that may come handy while building a timeline, or at least when you are trying to figure out when a specific Borland executable was compiled (I use ‘Borland’ here, but we know it means all the possible variations of Borland-esque compilers/products we can think of: Delphi, Borland C++, Code Gear, Embarcadero) .

The other interesting fact you may come across is the family of Borland files that are compiled with an old version of Borland C++. They have 2 very interesting and peculiar properties:

  • They have 2 exports: __GetExceptDLLinfo ___CPPdebugHook
  • They also include an original name of the executable

The first one makes it easy to recognize them.

The second one, while it may not be the most forensically interesting information it may still give you some clues for further research. It may come handy if the exported name is unique enough as it may allow e.g. to search for samples from the very same family (e.g. on Google, VirusTotal, Malwr)

For example, running the good-old pedump.exe over the file with a hash 3E19EF9C9A217D242787A896CC4A5B03 gives us the following:

exports table:

  Name:            winmgmtc.exe
  Characteristics: 00000000
  TimeDateStamp:   00000000 -> Thu Jan 01 08:00:00 1970
  Version:         0.00
  Ordinal base:    00000001
  # of functions:  00000002
  # of Names:      00000002

  Entry Pt  Ordn  Name
  00001059     1  __GetExceptDLLinfo
  0000C128     2  ___CPPdebugHook

The Export Directory is populated with the name of the original .exe and followed by 2 exports.

And yes, many online AV checkers/sandboxes do not show this information.

So, 2 things to remember now:

  • If it is an older Delphi file, check its resource section’s compilation timestamp
  • If it is Borland C++, check the export directory

Beyond good ol’ Run key, Part 19

December 4, 2014 in Anti-Forensics, Autostart (Persistence), Compromise Detection, Forensic Analysis, Malware Analysis

In my last post I mentioned Sysinternals. While combining the info for that post I came across a few things that gave me enough material to write a #19 in the series.

And it’s based on bugs in Sysinternals’ tools. Bugs that can be spotted easily. Today I’ll explain how you can utilize these bugs to create new persistent mechanisms.

Say, you like Process Explorer.

Nowadays 64-bit systems are very popular so running procexp.exe on a 64-bit system ends up with a procexp.exe dropping its 64-bit version into a %TEMP% folder and launching it.

procexp

Now, what you can do is f.ex. copy your notepad.exe to %TEMP% and name it procexp64.exe. Then you need to set up 2 access rights for everyone:

  • One that forbids deleting %temp%\procexp64.exe (on the file itself)
  • One that forbids deleting subfolders and files inside %TEMP% (on the %TEMP% folder); this is btw. one of the WTFs of NTFS system where prohibiting deletion of the files needs to be extended to its parent folder; there must be some reasons for that, but it is not something you can learn about from a cryptic Security Properties tab

From now on, launching procexp.exe on a 64-bit system will always launch notepad.exe. A nice man-in-the-middle attack especially if the malicious notepad.exe actually does spawn the legitimate procexp64.exe and hides its presence somehow from the Process Explorer GUI.

Of course blocking %TEMP% from deletion is a silly idea, but:

  • it is an example only
  • it actually works
  • there are many other ways to prevent deletion of the procexp64.exe by procexp.exe (on exit), or at least ensure the malicious procexp64.exe is restored after it is being deleted

Another bug I spotted was the way vmmap.exe craves for dbghelp.dll.

VMMAP is not a very popular program and I bet not too many people use it daily, but the way it works requires a special attention; it’s an example of a difference between programming for your own use vs. programming for ‘public’. As a non-professional programmer who writes buggy programs every day I am actually quite surprised by it. Yes, it’s that buggy.

Let me elaborate.

VMMAP has a very peculiar way for searching for dbghelp.dll:

First, it searches for the entry in the Registry:

  • HKCU\Software\Sysinternals\VMMap\DbgHelpPath32 = <path to dbghelp.dll>
  • #persistence #1
    • By modifying HKCU\Software\Sysinternals\VMMap\DbgHelpPath32 to point to a malicious DLL we can ensure that DLL is loaded every time VMMAP is launched

If it is not found, VMMAP goes ballistic (#persistence #2..N).

It calls a LoadLibraryW with a NULL which is a (sort of) result of retrieving data from a non-existing HKCU\Software\Sysinternals\VMMap\DbgHelpPath32 value.

This is when things get crazy. The craving goes totally addictive.

NULL is a Pandora’s box (Or’ Pandor’s since the author is a male) open for LoadLibraryW.

It means it will walk through every directory listed in the PATH environment variable and will attempt to load a library called ‘.dll’ from every single directory on that list.

Yes, ‘.dll’ is a valid library name i.e. a NULL with a ‘.dll’ extension.

So, you can place a DLL called “.dll” in any location that is covered by a PATH environment variable and you will have it launched by VMMAP anytime it starts.

You probably want to hear that this is the end of the story.

Not quite so.

There are still a few places to look at:

  • C:\Program Files\Debugging Tools for Windows (x86)\dbghelp.dll
  • C:\Program Files\Debugging Tools for Windows\dbghelp.dll
  • C:\Debuggers\dbghelp.dll

Dropping a dbghelp.dll in the …

yawnz…

you know the drill :)