October 9, 2019 · phishing payload-delivery

Deceptive Phishing for Payload Delivery and Access (Part 1)

During the last engagement, I faced a situation where the currently existed phishing tools were not enough; therefore, I started to code my own. Initially, I had a few requirements. I wanted the phishing tool to:

  1. Send attachments in emails.
  2. Encrypt the attachment with a password
  3. Send that password in the email to a bunch of users.

The primary purpose was to generate and send unique malicious emails per recipient to bypass mass searching by threat hunters and discover every victim.

At that time, I could manage it by coding a python script to take a single .docx payload, generate random password and password protect the .docx file with the random password. Then create email content from a template and send the attachment with its password to each victim.

Finally, I could easily bypass the incoming email monitoring systems such as sandbox as the word files were password encrypted. This resulted in getting a couple of shells and I was kind of happy with it.

Thinking beyond the possibilities

I like the armed document, such as .docx files that upon execution, the remote template will be fetched and loaded.

The whole idea that we can send statically non-malicious .docx files and then that file will load the malicious template from a remote system is brilliant and it technically opens many possibilities.

At this time, I was trying to figure out a way to use the .docx file to do some initial enumeration on the victim machine and then load the remote template, but this idea didn't work as doing any enumeration on the victim requires the user to enable the macro.

And finally, after days of research and looking into a Doc, Docx and Docm file structures and reading other's posts. I got an idea.

Furthor Analysis

There are few things needs to be mentioned.

  1. You can inject arbitrary images into any office documents. e.g.      .docx files. by opening the file, office application will request the image from the URI. it can be on remote server! it can be over HTTP/HTTPS or SMB.Loading images through SMB might also leak the netntlm hash as well.
  2. If there is any local/remote template associated with the .docx file, it will fetch and load that template right after opening the file.
  3. If the remote template includes macro, the office will show the typical "Enable Macro" yellow bar.By knowing all the above, we can actually create a .docx file. Add a transparent 1px*1px image to it,      then send it to the victim, once the victim opens it, the HTTP headers will be leaked.

Docx with Embedded Image Pointing to Remote Server

The below is an example of office requesting for an embedded image hosted on the remote server.

Analysis of HTTP Headers:

  1. Once victim request for the remote image, the User-Agent header clearly identified what application that hitting the webserver.
  2. X-Forwarded-For and Via Headers shows the internal proxy server that the victim is using.
  3. User Agent parsed to Outlook 14 on Windows 7, more details are shown below:

Docx with Remote Template

Now lets have a look at the request HTTP headers of word file that with a remote template.

Analysis of HTTP Headers:

  1. User-Agent is the same as the request for embedded image.
  2. There is a 1-second time gap between HTTP request for image vs. HTTP request for template.

Docx with Remote Template + Malicious Macro

To make it work, For the POC, I used the below VBScript to download and execute a payload from attacker server using COM Object and WMI.

Opened the file and double clicked on the "Enable Content", and the following request logged in the webserver.

Now lets analyze the HTTP Request:

  1. User-Agent parsed to Internet Explorer 11 on Windows 7.
  2. Request is through proxy same as all other http requests.
  3. There is about 20 seconds gap between the requests for embedded      image/template and the macro stager.

The reason of 20 seconds gap is it usually takes a minimum 20 seconds for a human actor from the time of opening the file until clicking the "Enable Content" button.

The keynote here would be, Virustotal, online sandboxes, target organization on-premise sandboxes or analyst's hunting machine usually have disabled macro warning so all the macros will be executed once the document is opened.

Leveraging on the HTTP Request Variables

So far, few useful variables identified to figure out who and from what location the payload has been executed.Below is the list of all of them:

Now let's dig into details of each variable. :)

Source IP

By tracking the source IP the following can be identified:

User-Agent

By parsing the User-Agent the following can be identified:

"Via" HTTP Header

Usually, it will leak the internal proxy server FQDN.

"X-Forwarded-For" HTTP Header

Usually, if there is a proxy server, this header will be used to keep track of the original source of packet. in operations, this header can be used for different purposes.

Time Between Each Request

It can be used to know if target system has macro warning enabled or not.

How? Let's say, we have a Docx file, we added embedded image with remote URL, then we have a remote template with malicious macro, and that malicious macro will download something from attacker machine. Here is each request:

  1. Request for embedded image from the server.
  2. Request for template from the server
  3. Upon macro execution, the macro will generate a request to download a payload

The analysis is, if #2 and #3 happens right after each other, means the macro warning is disabled. which usually will not happen for a typical employee in an organization.

Closing part one...

In this part, I just wanted to share some analysis regarding armed documents. I hope the idea behind triggered some thoughts in the reader.In part two, I will be introducing the phishing toolkit that I have written to automate all the process.

  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket