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)
ISC Stormcast For Thursday, February 18th 2016

Angler exploit kit generated by "admedia" gates

Published: 2016-02-18
Last Updated: 2016-02-18 00:44:29 UTC
by Brad Duncan (Version: 1)
5 comment(s)


On 2016-02-01, the Sucuri blog reported a spike in compromised WordPress sites generating hidden iframes with malicious URLs [1].  By 2016-02-02, I started seeing exploit kit (EK) traffic related to this campaign [2].  Sucuri noted that "admedia" was a common string used in malicious URLs generated by these iframes.  Because of that, some people (including me) use the term "admedia" when referring to traffic generated by this campaign.  These "admedia" URLs act as a gate between the compromised website and the EK server.  EK traffic associated with this campaign has generally sent TeslaCrypt ransomware.  However, characteristics of this campaign have evolved since Sucuri's original blog post.

  • Since 2016-02-11, I've usually seen the term "megaadvertize" used in these gate URLs instead of "admedia" [3, 4, 5].
  • Although we first saw Nuclear EK from this campaign, during the past week or so, these admedia gates have led to Angler EK.
  • In the past 24 hours, I saw a Joomla site generate an admedia gate, so this campaign is no longer limited to WordPress sites.

Other sites like the Malwarebytes blog have also documented this campaign [6].  Sites like Malwarebytes and DeepEnd Research have also documented most of these recent changes [7, 8].  Let's look at a recent Angler EK infection related to this "admedia" campaign.  In today's example, the chain of events starts with a compromised Joomla site.

Shown above:  HTML from the compromised site that kicked off this chain of events.

Today's infection

On Wednesday 2016-02-17 at approximately 18:14 UTC, I got a full chain of events.  The chain started with a compromised website that generated an admedia gate.  The gate led to Angler EK.  Finally, Angler EK delivered TeslaCrypt, and we saw some callback traffic from the malware.

  • - - admedia gate
  • - - Angler EK
  • - - TeslaCrypt callback traffic

Shown above:  A pcap of the infection traffic filtered in Wireshark.

Shown above:  Some of the events generated by reading the pcap in Snort using the Talos subscription ruleset.

Shown above:  Some of the events generated in Sguil by using tcpreplay in Security Onion with Suricata and the EmergingThreats Pro ruleset.

Shown above:  The infected Windows desktop after Angler EK delivered TeslaCrypt.


How did the compromised website generate the admedia gate?  It was caused by injected script.  As the Sucuri blog already reported, each .js file returned by the compromised site had malicious script appended to it.  In a case on 2016-02-15, I also saw the same type of script included in an HTML page from the compromised website [5]; however, today's traffic only shows injected script in the .js files.

Shown above:  Example of malicious script appended to .js files sent by the compromised web server (1 of 3).

Shown above:  Example of malicious script appended to .js files sent by the compromised web server (2 of 3).

Shown above:  Example of malicious script appended to .js files sent by the compromised web server (3 of 3).

Each example of injected script has a long string of hexadecimal code.  Translate that string from hex to ASCII, and you'll find a URL for the admedia gate.

Shown above:  The ASCII translation of that long hex string.  The admedia gate is highlighted in yellow.

In the traffic, an HTTP GET request to the admedia gate is followed by an HTTP POST.  The HTTP POST returns more obfuscated script.  That script generates a URL for an Angler EK landing page.  How can we check this?  Notice the "eval" function highlighted in the image below of HTML text returned by the admedia gate.

Shown above:  HTML and javascript returned by the admedia gate.

Take that HTML text and put it in a text editor.  Change the "eval" to "alert" and save that text to a separate HTML file.

Shown above:  Changing the "eval" to "alert" and saving the text in a separate HTML file.

Open your newly-saved HTML file in a browser, and you should see the Angler EK landing page URL appear in a pop-up alert.

Shown above:  The Angler EK landing page URL in a pop-up alert.

Below are images of the Angler EK traffic from today's infection.

Shown above:  HTTP request for the Angler EK landing page.

Shown above:  HTTP request for the Angler EK Flash exploit.

Shown above:  HTTP request for the Angler EK malware payload.

Final words

So far, I've only seen TeslaCrypt from this admedia campaign.  In fact, I've seen a whole lot of TeslaCrypt lately, with little other ransomware from EK traffic.  For example, I last saw CryptoWall on 2016-02-05 [9].  Since then, I haven't noticed any CryptoWall.

However, my field of view is currently limited, and there's plenty of information on other types of ransomware that's been making the rounds lately [10, 11, and 12 to name a few].

Have you seen any admedia Angler EK or similar activity?  If so let us know in the comments section below.

Traffic and malware for this ISC diary can be found here.

Brad Duncan
Security Researcher at Rackspace
Blog: - Twitter: @malware_traffic



5 comment(s)


Diary Archives