[This is a little phishing exercise that I went through a while back. Since I’ve got a blog now, I figured I might as well share it.]
Why ADHD and not something else?
There was a time, well over a year ago, when I thought about running an internal phishing campaign on my coworkers to see how many of them are falling for the temptations of links and attachments coupled with a promise of something that appeals to them. Back then, I had a quick look at the Simple Phishing Toolkit (sptoolkit). Sptoolkit looked promising, but I was sidetracked and never got back to exploring the functionality or testing it out. More recently, when I got back on the phishing bandwagon, I had a look at the Social Engineering Toolkit (SET). SET is a great tool, but when it comes to phishing my coworkers, SET does a little more than what I was looking for. I didn’t actually want to send a malicious payload. Plus, there’s a good chance that some of our defensive measures would get in the way of the out-of-the-box payloads included in SET. I just wanted simple reporting on random link clicking and attachment opening.
Back in early 2014, I was at a SANS conference in Orlando, and I was taking 504 with John Strand, and he spent some time talking about the tools included in the Active Defense Harbinger Distribution (ADHD). One of the tools included in ADHD is a Web Bug Server for tracking when a document is opened. No macros or trickery required. Just a .doc file with some embedded HTML that calls home to a webserver. Cool…there’s my pre-built solution for tracking people opening up random attachments.
What about reporting for just hyperlinks and not attachment opening? As it turns out, you can very easily use the Web Bug Server for tracking those too. When a Web Bug document is opened, the embedded HTML calls home to:
The URL query string is set to type=css or type=img depending on what part of the embedded HTML inside the Web Bug Doc is calling back to the Web Bug Server. That’s the out-of-the-box functionality provided when ADHD is installed. You can modify the URL so that the “type=xxx” has a different string of characters to indicate that your phishing target has clicked on a link. A unique “type=xxx” will indicate what the user did to connect back to your Web Bug Server. I used a few different custom urls when I built my phishing links, and you’ll see them in the screenshots below.
Here’s my quick and easy setup for phishing my coworkers.
Email.vbs is a simple VB Script for sending an email with an attachment. I’m sure there are many ways to do this, but this is what I used:
Correlating each hit on the Web Bug Server with a specific employee
Each employee was assigned an ID number between 1 and n, where n is the total number of employees.
I created n number of emailn.vbs and Vacation2014n.doc. In each emailn.vbs and Vacation2014n.doc, the urls for each link were modified to have id=n. In each emailn.vbs, the objMessage.To line was modified so that the email was sent to the employee assigned that ID number, and the objMessage.AddAttachment line was modified so that the correct Vacation2014n.doc was attached.
That gives me a relatively solid way of knowing which employee opened the attachment and/or clicked the link. There is certainly the possibility that one employee forwarded their email to a second employee and that the hits on the Web Bug Server for each ID number were not necessarily hits from the employee that was originally assigned that ID. If you wanted more solid proof, you could correlate the IP that each Web Bug Server hit came from with the user logged in to that computer at the time the hit happened. For now, my low-tech, quick and easy method is fine for my needs.
It’s worth noting that the original intention (at least, my understanding of the original intention) for the id=n field is to identify which document was calling back to the ADHD server. Remember that my use of ADHD for a phishing campaign is slightly outside of the intended purpose when the distro and tools were built.
Multiple URLs to provide more accurate data
While you were looking at the screenshots above, you may have noticed that there are several different URLs used in the body of the email, and in the Web Bug document. Let’s take a quick look at each of them. I’ll start with the 4 that are used in the Vacation2014.doc.
This is the first URL we see:
<LINK REL=”stylesheet” HREF=”hxxp://10.5.0.85/web-bug-server/index.php?id=141&type=css”> generated automatically by ADHD when the Web Bug Doc is created. The IP address (10.5.0.85) is the address of my ADHD server. “id=141” is used to correlate that hit on the Web Bug Server with employee number 141 (an ID number that we assigned earlier). “type=css” indicates that the embedded HTML in the Web Bug Doc called back to the Web Bug Server looking for a stylesheet.
Here is the second URL in the Vacation2014.doc:
<a href=”hxxp://10.5.0.85/web-bug-server/index.php?id=141&type=url”>Click here</a>
This time, the URL is displays as a link in an attempt to get the recipient to click on it. I’m using “type=url” to indicate that it was a plaintext URL that’s easily readable by a human (if they take the time to view the URL before just clicking the “click here!” text.
Here’s the third URL in the document:
In this URL, some of the characters have been encoded to make them less-easily readable by the human recipient. It’s worth mentioning that the same encoding techniques are used in other scenarios to evade IDS/IPS signatures, but I just wanted to do something to make the actual destination less clear to the person viewing it. “type=enc” is used to indicate that the encoded URL was used. When I tried to click this link in Microsoft Word 2010, it didn’t work. I assume that Word simply won’t open encoded URLs. For that reason, the document instructs the user “try copy and pasting this into your web browser’s address bar…”.
Finally the last URL in the document is this:
<IMG SRC=”hxxp://10.5.0.85/web-bug-server/index.php?id=141&type=img” width=”1″ height=”1″>
Like the first URL, this one was also automatically generated when the Web Bug Doc was created in ADHD. “type=img” indicates that the request to the Web Bug Server came from the embedded image source tag.
In the email message body, there is only 1 URL. It’s at the very end of the message, and it’s proceeded by a note: “If that doesn’t work, try going here for help:”
This URL has also been encoded, and the “type=hlp” indicates to me that the message recipient couldn’t find what they were looking for at all of the other places, and they have fallen for the last and final link to get help. It’s worth noting that Outlook 2010 (like Word mentioned above) also will not link directly to this encoded URL. The recipient probably would have needed to copy and paste the link. I have not tested with any other mail clients.
Here’s the bait
When you start casting your phishing bait, here’s what the recipients will receive.
Yes, this all looks incredibly suspicious, and it has tell-tale signs of a phish. It may need to look much more professional to be successful, but part of my intention was to see how many people fell for a relatively obvious scam.
Reviewing the catch from the latest phishing expedition
When the Web Bug Doc calls back to the server, or the recipient clicks one of the other links, the Web Bug Server on ADHD creates an entry in a database. Below is an example of Employee ID Number 141 being very curious.
Unfortunately, I can’t share the full results of my phishing campaign. However, I can say that the percentage of employees that were tricked enough to have at least 1 check-in on the ADHD server was not insignificant, and there was representation from nearly every business unit.
Use better bait to catch more phish!
A few ideas for improving the success rate…
1 – If you control DNS for your network, poison it. Don’t get crazy and poison the record for a popular website. Instead, make a bogus entry for something that doesn’t exist. I redacted the Sender address that I used in the screenshots that were shown earlier, but I used a “believable” domain name that was in the format Continent–Country-Trips.com. I say it’s believable because I was trying to entice my recipients with pictures from vacation. For a number of reasons, I double-checked ahead of time to make sure that the domain I was spoofing wasn’t actually registered to anyone. If you can make a bogus DNS entry, then you don’t need to rely on URLs that included an IP address
2 – If you have the time, money, and energy, then go ahead and register a Domain name and stand up a website that makes it look like a legitimate business. This accomplishes the same improvements that are provided by creating a bogus DNS record.
3 – Make the email look more professional. I won’t go into details here…I’m sure everyone has a wealth of emails in their inbox that they can reference for ones that look more legitimate and believable than others.
4 – Use (or build) a better tool. Like I mentioned before, ADHD wasn’t built for phishing – I just took advantage of one of its tools to throw together a quick and dirty phishing test.
5 – Appeal to your recipient’s desires. I stuck with a relatively benign email trying to get someone to view vacation photos that don’t exist. The more you know about your target, and the more freedom to have to execute, the better you can socially engineer a “click” out of them. If you can run recon on a set of employees and craft a phish that appeals to their interests, then your success rate may increase.
6 – Automate, Automate, Automate. Consider writing a program or script that will automagically modify the email and word templates to have the correct recipient address, ID #, etc.