# 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:

rule MALDOC_LNK {
strings:
\$BirthObjectId = {C2 CC 13 98 18 B9 E2 41 82 40 54 A8 AD E2 0A 9A}
\$MACAddress = {00 0C 29 5A 39 04}
condition:
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:

Conclusion

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.

rtfdump.py 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 oledump.py: 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.

Detection

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 {
strings:
\$header = "{\\rtf1"
\$objdata = "objdata 0105000002000000" nocase
\$urlmoniker = "E0C9EA79F9BACE118C8200AA004BA90B" nocase
\$http = "68007400740070003a002f002f00" nocase
condition:
\$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!

# CSCBE Challenge Write-up – Sufbo

The Sufbo challenge was tackled during the Cyber Security Challenge qualifiers and proved to be very difficult to solve. This write-up gives you a possible way of solving it!

Credits

All challenges of the Cyber Security Challenge are created by security professionals from many different organisations. The Sufbo challenge in particular was created by Adriaan Dens, one of our distinguished challenge contributors, from Proximus. Adriaan & Proximus have contributed multiple challenges over the years and they tend to be pretty hard to solve ;).

The challenge

And you thought Assembly was hard to read? Try this!

The solution

The challenge consists out of a heavily obfuscated piece of perl code. We can start by cleaning up the code which improves the readability by a small bit:

print"Flag: ";
chomp(\$_=&lt;&gt;);
\$[=0;
die if y///c!=32;
chomp(@_=&lt;DATA&gt;);
\$/=join'',map{chr(ord\$_^\$=)}split//,pack"H*",shift(@_).shift(@_);

while(\$,=substr\$_,8*\$-,8) {
(\$@,\$*,\$#,\$x,\$y,\$z,\$!,\$.,\$,) = (unpack("N*",\$/.\$,),0,2**31*(sqrt(5)-1),(1&lt;&lt;32)-1);
map {
\$!+=\$.;
\$!&amp;=\$,;
\$y+=(((((\$z&lt;&lt;4)&amp;\$,)+\$@)&amp;\$,)^((\$z+\$!)&amp;\$,)^(((\$z&gt;&gt;5)+\$*)&amp;\$,));
\$y&amp;=\$,;
\$z+=(((((\$y&lt;&lt;4)&amp;\$,)+\$#)&amp;\$,)^((\$y+\$!)&amp;\$,)^(((\$y&gt;&gt;5)+\$x)&amp;\$,));
\$z&amp;=\$,;
\$"=pack("N*",\$y,\$z);
\$/=\$"x2
}0..31;
die if\$"ne pack"H*",\$_[\$-];
\$-++;
}
print "OK\n"

__DATA__
6c594e50630d4f63
7d515d4655525b1d
7872575285c742da
15c670798094a00b
54f08c6b937ed1f2
6810afed7372cd76

This code might still not mean a lot to the average non-perl-speaking-person. Let’s take a look at the same code, but with some inline comments:

print"Flag: "; # Prints "Flag: " to STDIN
chomp(\$_=&lt;&gt;); # Reads in the input into the variable \$_
\$[=0; # Changes the starting index of an array to 0 (It's a useless command actually)
die if y///c!=32; # y///c is a Perl golfing idiom that is similar to length(\$_), so the length of your input has to be a string of length 32.
chomp(@_=&lt;DATA&gt;); # Store the data below (under __DATA__) in the array @_
\$/=join'',map{chr(ord\$_^\$=)}split//,pack"H*",shift(@_).shift(@_); # Shift the first two elements of @_, "unhexify" the strings, split them per character, XOR with \$= (default value is 60), and join the characters back in the variable \$/.
#
while(\$,=substr\$_,8*\$-,8) { # While there are 8 characters left in the input do:
(\$@,\$*,\$#,\$x,\$y,\$z,\$!,\$.,\$,) = (unpack("N*",\$/.\$,),0,2**31*(sqrt(5)-1),(1&lt;&lt;32)-1); # Convert the variable \$/ (unknown) and \$, (our input) to unsigned numbers, assign 0 to \$!, assign 2**31*(sqrt(5)-1) to \$/ and assign (1&lt;&lt;32)-1 to \$,.
map { # Use map to loop 32 times (see below)
\$!+=\$.; # Add \$. to \$!
\$!&amp;=\$,; # Bitwise AND \$! with \$,
\$y+=(((((\$z&lt;&lt;4)&amp;\$,)+\$@)&amp;\$,)^((\$z+\$!)&amp;\$,)^(((\$z&gt;&gt;5)+\$*)&amp;\$,)); # Some bitwise operations added to \$y
\$y&amp;=\$,; # Bitwise AND \$y with \$,
\$z+=(((((\$y&lt;&lt;4)&amp;\$,)+\$#)&amp;\$,)^((\$y+\$!)&amp;\$,)^(((\$y&gt;&gt;5)+\$x)&amp;\$,)); # Some bitwise operations added to \$z
\$z&amp;=\$,; # Bitwise AND \$z with \$,
\$"=pack("N*",\$y,\$z); # Convert the unsigned numbers back to string representation
\$/=\$"x2 # Set \$/ to two times \$"
}0..31; # Use map to loop 32 times
die if\$"ne pack"H*",\$_[\$-]; # Die if \$" is not equal to the "unhexified" element (\$- contains the index) in @_
\$-++; # Increase the variable \$-
} #
print "OK\n" # Printed if you have the key
#
__DATA__ # Starting the DATA block (kinda like a here document)
6c594e50630d4f63 # This part was used for \$/ in line 6.
7d515d4655525b1d # This part was used for \$/ in line 6.
7872575285c742da # This part was used to compare with the input on line 20
15c670798094a00b # This part was used to compare with the input on line 20
54f08c6b937ed1f2 # This part was used to compare with the input on line 20
6810afed7372cd76 # This part was used to compare with the input on line 20

So now we more or less know what each line does but we still miss context on a higher level (what it is doing). As always in reverse engineering, you try to find some “known parts” which allow you to understand the code a lot faster. These parts are usually strings, metadata, fixed numbers or familiar code blocks.

In our case, we have 2 fixed numbers: $2**31*(sqrt(5)-1)$ and $(1<<32)-1$. In this representation they don’t mean much but if we convert them to hex numbers we get 0x9e3779b9 and 0xffffffff respectively.

Let’s see if our old friend Google knows more about this.

Hmm, interesting! Seems like we’ve got a Perl implementation of Tiny Encryption Algorithm (TEA) on our hands here!

More specifically, the while loop block in the code is the actual TEA implementation, which decrypts the second half of the __DATA__ section using the first half as the key.

Retrieving the key can be done using the following perl one-liner:

perl -E 'say join"",map{chr(ord\$_^\$=)}split//,pack"H*","6c594e50630d4f637d515d4655525b1d"

Which yields us “Perl_1s_Amazing!” as the key.

So now we have they key and the data to be decrypted. Let’s be lazy and copy the reference code listed on the wikipedia page we found earlier.

#include&lt;stdint.h&gt;
#include&lt;stdio.h&gt;

void decrypt (uint32_t* v, uint32_t* k) {
uint32_t v0=v[0], v1=v[1], sum=0xC6EF3720, i; /* set up */
uint32_t delta=0x9e3779b9; /* a key schedule constant */
uint32_t k0=k[0], k1=k[1], k2=k[2], k3=k[3]; /* cache key */
for (i=0; i&lt;32; i++) { /* basic cycle start */
v1 -= ((v0&lt;&lt;4) + k2) ^ (v0 + sum) ^ ((v0&gt;&gt;5) + k3);
v0 -= ((v1&lt;&lt;4) + k0) ^ (v1 + sum) ^ ((v1&gt;&gt;5) + k1);
sum -= delta;
} /* end cycle */
v[0]=v0; v[1]=v1;
printf("%x%x", v0, v1);
}

void main() {
/* Our cipher chunks, found in the __DATA__ block of the Perl code */
uint32_t c0[] = { 0x78725752, 0x85c742da };
uint32_t c1[] = { 0x15c67079, 0x8094a00b };
uint32_t c2[] = { 0x54f08c6b, 0x937ed1f2 };
uint32_t c3[] = { 0x6810afed, 0x7372cd76 };

/* The used keys for encrypting */
uint32_t k[] = { 0x5065726c, 0x5f31735f, 0x416d617a, 0x696e6721 }; /* Original key: Perl_1s_Amazing! */
uint32_t k0[] = { 0x78725752, 0x85c742da, 0x78725752, 0x85c742da }; /* c0 . c0 */
uint32_t k1[] = { 0x15c67079, 0x8094a00b, 0x15c67079, 0x8094a00b }; /* c1 . c1 */
uint32_t k2[] = { 0x54f08c6b, 0x937ed1f2, 0x54f08c6b, 0x937ed1f2 }; /* c2 . c2 */

/* Decrypting the chunks */
decrypt(c0,k);
decrypt(c1,k0);
decrypt(c2,k1);
decrypt(c3,k2);
}
\$ gcc --std=c99 solution.c
\$ ./a.out
43534342457b5065726c31735772317465306e6365526534646e33766552727d
\$ ./a.out | perl -nle 'print pack("H*", \$_)'
&gt;&gt;&gt; CSCBE{Perl1sWr1te0nceRe4dn3veRr}

There we go! CSCBE{Perl1sWr1te0nceRe4dn3veRr} was the flag.

# 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: http://forensicswiki.org/wiki/LNK.

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: http://computerforensics.parsonage.co.uk/downloads/TheMeaningofLIFE.pdf