Hunting for Executable Code in Windows Environments

Published: 2016-02-18. Last Updated: 2016-02-19 08:59:45 UTC
by Xavier Mertens (Version: 1)

Executable code can take different forms in a Microsoft Windows operating system: it can be an executable (a PE - "Portable Executable" - file), a shared library (DLL) or a driver. The ability to execute code on a system is the attackers' ultimate goal. Everyday, they are trying to find new ways to deliver malicious code available to a system to compromize it. This can be via a vulnerability in a software, an OLE document with an embedded VBA macro, a malicious JavaScript code in a web page. That’s why it is mandatory to control and know which applications are executed on a system. When a computer is compromised, there are two ways to find malicious code: the first one is a "reactive" way by using forensics tools like Volatility. The first step is to make a dump of the infected computer memory and then to analyze it. The following example will list the processes found in memory:

$ vol.py -f memory.dump --profile=Win7SP1x86 psxview
Offset(P)  Name                    PID pslist psscan thrdproc pspcdid csrss
---------- -------------------- ------ ------ ------ -------- ------- -----
0x06541da0 svchost.exe            1140 True   True   False    True    True
0x06531b10 wuauclt.exe            1040 True   True   False    True    True
0x065e44d8 svchost.exe             952 True   True   False    True    True
...
...

But there is another way which is more proactive: to capture executable code "live" when the system is executing it. To achieve this, I'm using a nice tool called PE Capture. There are two versions of this tool, a completely free version that is a "graphical" tool with a classic GUI. The second one is running as a Windows service (to be completely transparent for the user) called PE Capture Service. This one is free for personal use but a license is required for deployments in corporate environments. The tool provides two interesting features:

As its name suggests, It captures PE files (executables, DLL, drivers) loaded in the system and saves a copy of the file in a specific directory (the file name is the MD5 hash)
It logs the executables names, MD5 hashes and the execution timestamp in a flat file.

The installation is pretty straight forward: download the archive, extract the files in a folder, select your architecture (x86 or x64), move the directory in the C:\PECaptureSvc (this can be changed via the configuration file) and launch install.bat. That’s it! The service will start automatically at each reboot. By default, captured executables are saved in:

C:\PECaptureSvc\Intercepted\[hostname]\[dd-mm-yyyy]\

The daily log file is:

C:\PECaptureSvc\Logs\[hostname]\[dd-mm-yyyy].log

Here is a log entry sample:

18/02/2016 20:45:33
C:\totalcmd\TOTALCMD64.EXE
80F48C1F435FE040D33665030F719132

Note that an exclusion database is available (to prevent most common executable code to be logged every day). You can define regular expressions. Executable files matching them won't be logged/captured. Example:

C:\MySafeTools\*.exe
*:\CorporateTool.exe

You can also disable one of the two main features. By example: to log and not save the extracted code (keep in mind that the "Intercepted" directory size might grow very quickly on busy systems!)

To be more practical, here is an example of a system infected by the newly Locky ransomware. The sample used is facture037017.doc (63c2551118c5006f6ffe6773dadbff75) received via a phishing email.

Let's double-click on the file, Microsoft Word is started:

18/02/2016 20:46:20
C:\Program Files\Common Files\Microsoft Shared\OFFICE12\MSOXEV.DLL
2403A9F058DFDD337CE9A67AE1ECAD63

18/02/2016 21:03:46
C:\Program Files (x86)\WinRAR\RarExt64.dll
C2CE5E4DF7B3766A7A59A6634F29ABB1

18/02/2016 21:05:29
C:\Program Files (x86)\Microsoft Office\Office12\WINWORD.EXE
4E7782C13D82BAA36059745280135A84

18/02/2016 21:05:35
C:\Program Files (x86)\Microsoft Office\Office12\WWLIB.DLL
C102BEDBE15445AA2938EBF0D5B281E0

18/02/2016 21:05:38
C:\Program Files (x86)\Microsoft Office\Office12\OART.DLL
7F2C8065F1079D04BD8BC2B19750A596

18/02/2016 21:05:42
C:\Program Files (x86)\Common Files\microsoft shared\OFFICE12\MSO.DLL
E7AAFC1A321ED0E3EF44B1ED8CF09FA2

18/02/2016 21:05:42
C:\Program Files (x86)\Microsoft Office\Office12\1033\WWINTL.DLL
BEF1EAD605CF791FDBB48ADD71075509

18/02/2016 21:05:42
C:\Program Files (x86)\Common Files\microsoft shared\OFFICE12\MSPTLS.DLL
34B820CE0B0A26CFAF78F6E57709FFB7

18/02/2016 21:05:44
C:\Program Files (x86)\Common Files\microsoft shared\OFFICE12\MSORES.DLL
C7D010BD8BCEF2EB3FCA8F7CD3C08D9F

18/02/2016 21:05:46
C:\Program Files (x86)\Common Files\microsoft shared\OFFICE12\1033\MSOINTL.DLL
4C5D603A632023BFDB8EDD4436882ABF

18/02/2016 21:05:47
C:\Program Files (x86)\Common Files\microsoft shared\OFFICE11\msxml5.dll
FC5CB6727354B634CD8AD3EFB4B8F83D

18/02/2016 21:05:47
C:\Windows\System32\spool\drivers\x64\3\PSCRIPT5.DLL
211A1CFF92CF7F70EB61606ABB729615

18/02/2016 21:05:47
C:\Windows\System32\spool\drivers\x64\3\PS5UI.DLL
9699DB0085C06D5E1D03089D88CA13B9

18/02/2016 21:05:47
C:\Program Files (x86)\Common Files\microsoft shared\OFFICE12\RICHED20.DLL
1A8B4857F2CAAED89E16B1ED1F24930D

The malicious document contains a VBA macro, VB6 and .Net material is now loaded:

18/02/2016 21:05:48
C:\PROGRA~2\COMMON~1\MICROS~1\VBA\VBA6\VBE6.DLL
563482363CD86013E8EF29575D790D22

18/02/2016 21:05:48
C:\Program Files (x86)\Microsoft Office\Office12\msproof6.dll
DA79517783552B80229705D9720B8E8D

18/02/2016 21:05:48
C:\Windows\winsxs\x86_microsoft.vc80.crt_1fc8b3b9a1e18e3b_8.0.50727.6195_none_d09154e044272b9a\msvcp80.dll
0B3595A4FF0B36D68E5FC67FD7D70FDC

18/02/2016 21:05:49
C:\Program Files (x86)\Common Files\microsoft shared\PROOF\MSLID.DLL
CB0C98DD5C3108F71BAA938B1ECD8B04

18/02/2016 21:05:49
C:\PROGRA~2\MICROS~3\Office12\OUTLFLTR.DLL
87BA0576429722DF5B92FD43F55FAD77

18/02/2016 21:05:49
C:\PROGRA~2\COMMON~1\MICROS~1\VBA\VBA6\1033\VBE6INTL.DLL
B64D8A3F75C4AB72242910D9F4BBEB75

18/02/2016 21:05:49
C:\Windows\SysWOW64\SCP32.DLL
F0283069C1B8E0A65A97F08186BFC9B2

18/02/2016 21:05:49
C:\Windows\SysWOW64\FM20.DLL
7D5AD5FAF64BF8AA1EB55B81A3AB830D

18/02/2016 21:05:49
C:\Windows\SysWOW64\FM20ENU.DLL
F2CE3C8E63F770DB3E59D503CE4CC311

18/02/2016 21:07:40
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\WMINet_Utils.dll
FDA2FEC6B42787EE1ED4EFD39359770B

And finally, here is our malicious payload is downloaded and executed by the VBA macro:

18/02/2016 21:08:58
C:\Users\xavier\AppData\Local\Temp\vcgfdrDYa.exe
A9188E2204532498472F2E837C3D4A97

This is indeed our Locky malware as reported by VirusTotal: A9188E2204532498472F2E837C3D4A97.

Of course, the log file contains useful information that can be reused by other tools. I’m loading the PECaptureSvc events within my Splunk. The file has a clean format so it’s easy to create a new SourceType in your props.conf:

[pecapturesvc]
DATETIME_CONFIG =
NO_BINARY_CHECK = true
category = Operating System
description = PECaptureSVC Log File
pulldown_type = true

Field extraction is helpful. I’m only extracting those two fields: “filename” and “md5” to get interesting activity reports like this one:

A few months ago, in a previous diary, I explained how to generate a list of hashes from a “clean” system using the Microsoft tool FCIV. You can now combine the two processes and detect automatically PE code that is not standard into your organization. Create a Splunk lookup table with your “known” (good) hashes and compare them on the fly. The same hashes can also be submitted to VirusTotal and, if you dump them, PE files can be further analyzed with your favorite tools.

Another good point is the fact that PE Capture isn't a common tool (yet). I'm not aware of any malware checking for the presence of "PECaptureSvc.exe" like they usually do for anti-virus or debugging processes.

Happy hunting!

Xavier Mertens
ISC Handler - Freelance Security Consultant
PGP Key

Keywords: executable forensics malware microsoft pe windows

6 comment(s)

Comments

You can also use Sysmon (from sysinternals) to do this. It's completely free and also offers some other features. It also runs as a service. It doesn't have the possibility to make a copy of the executable or DLL however.
It logs to the Windows event log, so it can be directly integrated in Splunk as well.

Thanks for sharing this. Indeed, my goal was to capture the executable for further analysis (we need fresh meat ;-)

If you're dumping to a shared folder in an enterprise environment, this could get kind of busy. <understatement> Does it check for an already existing file named with the current hash, or does it just overwrite every time?
Thanks
John

As files are saved in daily directories, you can have multiple copies of the same file if it's launched on a daily basis.
Files are saved with the following timestamps:

- Created: <timestamp when started on the system>
- Modified: <original timestamp when the file was created>
- Accessed: <timestamp when started on the system>

But files are captured once a day (based on my findings - not documented)

I am curious, aside from having a hash of the file, how is this any different than the Audit Process Creation under the Advanced Audit Policies baked into Windows NTv6 and beyond?

Enabling this setting produces EventCode 4688 in the Security logs every time a new process is created, which also produces the PID and Token Elevation Type, as well as more useful information in 2012 server such as the command line arguments that may have been passed to the executable.

As sais Lode, there are other tools to collect this kind of information. AppLocker can also be used in "logging only" mode (I wrote a blog post a long time ago about this - https://blog.rootshell.be/2014/02/10/tracking-processesmalwares-using-ossec/).
From a forensics point of view, having the executable captured and saved was the key point for me in this case.

Internet Storm Center

Hunting for Executable Code in Windows Environments

Comments

Anonymous

Feb 19th 2016
8 years ago

Anonymous

Feb 19th 2016
8 years ago

Anonymous

Feb 19th 2016
8 years ago

Anonymous

Feb 19th 2016
8 years ago

Anonymous

Feb 19th 2016
8 years ago

Anonymous

Feb 19th 2016
8 years ago

Hunting for Executable Code in Windows Environments

Comments

Anonymous

Feb 19th 20168 years ago

Anonymous

Feb 19th 20168 years ago

Anonymous

Feb 19th 20168 years ago

Anonymous

Feb 19th 20168 years ago

Anonymous

Feb 19th 20168 years ago

Anonymous

Feb 19th 20168 years ago

Feb 19th 2016
8 years ago

Feb 19th 2016
8 years ago

Feb 19th 2016
8 years ago

Feb 19th 2016
8 years ago

Feb 19th 2016
8 years ago

Feb 19th 2016
8 years ago