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)
6 comment(s)

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:
$ -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:
The daily log file is:
Here is a log entry sample:
18/02/2016 20:45:33
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:
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

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

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

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

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

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

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

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

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

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

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

18/02/2016 21:05:47

18/02/2016 21:05:47

18/02/2016 21:05:47
C:\Program Files (x86)\Common Files\microsoft shared\OFFICE12\RICHED20.DLL
The malicious document contains a VBA macro, VB6 and .Net material is now loaded:
18/02/2016 21:05:48

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

18/02/2016 21:05:48

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

18/02/2016 21:05:49

18/02/2016 21:05:49

18/02/2016 21:05:49

18/02/2016 21:05:49

18/02/2016 21:05:49

18/02/2016 21:07:40
And finally, here is our malicious payload is downloaded and executed by the VBA macro:
18/02/2016 21:08:58
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:
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
6 comment(s)


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?
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 -
From a forensics point of view, having the executable captured and saved was the key point for me in this case.

Diary Archives