Today I received a very nice spam e-mail that caught my attention.

It basically is an e-mail with a link in it pointing to a malicious document.
But it did not catch my attention because of its content but because of the domains it contained.

The e-mail sender address is no-reply@hmrcmailgov.uk and the link inside the body is payert-gov.uk.

A quick whois request shows the reason:

hmrcmailgov.uk domain lookup results from whois.nic.uk server:

Domain name: hmrcmailgov.uk
Registrar: GoDaddy.com, LLP. [Tag = GODADDY]
URL: http://uk.godaddy.com
Relevant dates:
Registered on: 26-Jun-2018
Expiry date: 26-Jun-2019
Last updated: 26-Jun-2018

payert-gov.uk domain lookup results from whois.nic.uk server:

Domain name: payert-gov.uk
Registrar: GoDaddy.com, LLP. [Tag = GODADDY]
URL: http://uk.godaddy.com
Relevant dates:
Registered on: 26-Jun-2018
Expiry date: 26-Jun-2019
Last updated: 26-Jun-2018

As you can see both domains were registered today.

My next step was to visit the suspicious URL given inside the e-mail body. As it turned out the website wanted only to be visited by internet explorers which to me was already an indicator that it might be the IE exploit which was recently publicly disclosed. CVE-2018-8174

After switching to IE I was able to grab the script.vbs file. This file should be executed and then download a nice payload.
My goal at this point is to retrieve the playload URL’s to block any access to it.

One possible solution is to execute the file inside a malware analysis sandbox, which should work pretty fine. I didn’t want to do this as in my current environment this takes quite some time. So I had to find a quicker solution.

As the script.vbs code looked very similar to the exploit prototype code which is available on github, I compared the two files with each other. The only difference could be found inside an unicode encoded section. This means the payload URL’s must be somewhere in there.

With a little help from the CyberChef and a few tries a even was able to recover the actual payload URL’s.

Well this basically is the whole magic and is probably a little bit faster than using the malware sandbox everytime.

So that you don’t have to gather together all the ingredients for the recipe, I added the recipe as json. Now you can just load the recipe and paste the following json:

1
2
3
4
5
6
7
8
[
  { "op": "Unescape Unicode Characters",
    "args": ["%u"] },
  { "op": "Encode text",
    "args": ["UTF16 (1201)"] },
  { "op": "Swap endianness",
    "args": ["Raw", 2, true] }
]

pro memoria..

• Sometimes and for certain use-cases, there is a quicker solution than using dynamic malware analysis, but the way to get there must be found
• CyberChef is an amazing tool to do various en- and decodings