The file “bbransom.doc” is provided and, once opened, greets you with a picture of Jareth the Goblin King. We’re prompted with the familiar “Security Warning” that Macros are disabled so let’s start analysis there.

Looking at the underlying VBA for ThisDocument doesn’t reveal much.

It checks whether a variable is set to “goblinkingbb” and then launches a function; however, this function does not appear in the Project list so it’s safe to assume it’s hidden somehow.

Looking in the Object Explorer, we can see a Class “UjRtRQl” with two members, the initial function we saw in the VBA and another, unknown to us at the moment.

I scratched my head for a while trying to figure out where this code was hidden before relying on outside tools. The details of the trick can be read about here but effectively, VBA loads all of the streams in the OLE folder but only displays the ones under a specific folder in the Microsoft Visual Basic editor. Using Didier Stevens oledump.py shows the streams and shows the hidden file in stream 9.

Looking at the code, we can see the two functions. The first one is a small XOR algorithm using the “goblinkingbb” variable seen previously and, looking a little further below, arrays of integers.

Macintosh HD:Users:jwhite:Desktop:Screen Shot 2017-04-28 at 5.05.44
PM.png Towards the end of the second function is a CreateObject function call followed by a “Run”. This is likely a Wscript.Shell function running a command, so I’m going to pivot over to dynamic analysis and see what happens when we run it.

Opening the document we’re prompted with this MsgBox, which can be seen above in the macro text, so it also confirms that the first function is converting ASCII strings.

Allowing the macro to run, a PowerShell process is created under Word.exe and then closes after a few seconds.

A quick look at the strings found in memory for this child-process show what command was run, which appears to just launch a PowerShell script; presumably the script is built from the VBA macro and written to disk.

By the time I checked for the file it had been deleted so I ran it again and copied it before it deleted itself. Looking under the hood, it’s another obfuscated script.

Stepping through the first part, the bytes from the base64 decoded string “DwImSAI1CgMYSQQ+GhoO” are XOR’d with the bytes from the string “For great justice”, which produce the string “ImTheGoblinKing”. This value is used as the password (highlighted variable in green) in the generation of the Key/IV for Rijndael.

Reading the code further, it appears to search for files with the extension “.urbb” and “.toby” and reads the first 2048 bytes, encrypts it, then writes it back to the file with a new extension of “.bbmine”.

A little further down and the now SOP ransomware “help” file code is present.

This file gets written if any file gets encrypted so I created a text file containing “Magic Dance” lyrics and saved it with the extension “.toby”. Running the PowerShell script again creates the expected HTML file.

Looking at the PowerShell script again, “CLIENT ID” is randomly generated, whereas “Campaign ID” and “Version Key” are static values base-64 encoded within the script.

Since “For great justice” was used as the initial XOR key to build the password for the crypto-algorithm, it made logical sense to attempt to XOR the “Campaign ID” by this key.


> import base64
>
> a =
> base64.b64decode("Fi48W1UTAwMSQVkQRk1aVAB/DUQRVxQBBxdGCBcSEFtUB3RXEEJXFFxRTERbQhdHWgVcdgpKQ18TAVRDEwtNFkRfVwM7")
>
> b = "For great justice"
>
> c = ""
>
> for i in range(0,len(a)):
>
> ... c += chr(ord(a[i]) ^ ord(b[i % len(b)]))
>
> ...
>
> c
>
> 'PAN{2afbfa3e5937e9b610fdfcfbbad27b28bb0f908d17d33f90e8c8ad573a8e064f}'

The challenge answer is “PAN{2afbfa3e5937e9b610fdfcfbbad27b28bb0f908d17d33f90e8c8ad573a8e064f}”.