Gone Phishin’ — An Attacker’s Perspective & Solutions
Intro
You can teach a man how to phish, but.. you can’t make him phish-proof? Aside from the headings in this blog I’ll try to avoid the fish puns to save your forehead from all of the potential for face palms. Why am I creating this blog? I’m hoping to shed some light on some Security 101 Best Practices for techies and non-techies alike from the viewpoint of an attacker. It’s not quite Security Awareness Month (October), so consider this an appetizer.
Spear-phishing is something we have great success with during our Social Engineering engagements at Pondurance. Sure, there are a lot of tools out there which regularly tests employees to see who’s had enough coffee in the morning, but manual, targeted attacks can take things to the next level. I’ve seen IT administrators who are proponents of phishing training, CEO’s, and just about anyone else you can imagine in various positions throughout organizations fall victim to our shenanigans.
In fact, phishing is so successful in the wild that according to a recent report from Cofense, 91% of all cyber attacks today originate from a phishing campaign. This checks out in my mind as a quick sanity check, because if I know I’m on an engagement as a red teamer and phishing is in scope, I’m confident we’re going to find a way into the organization. Alternatively, we have to hope there’s an external misconfiguration of a device, bad code in an application, or a vulnerability in the form of a patching deficiency somewhere on the perimeter of the environment to which the chances of success aren’t nearly as high today.
It should be no surprise then that since most incidents start as phishing, the human factor or human error is the weakest link and often targeted first. It’s easier to exploit a person than it is a device nowadays, and security awareness training isn’t as effective as it should be. So, that being said, let’s take a look at what a targeted spear-phishing campaign looks like through the eyes of the attacker and the solutions in place to help prevent you from getting hooked! Ugh, I did it again.. sorry!
Scoping Out a Watering Hole (I mentioned these previously!)
Well, I mentioned this is a spear-phishing exercise and not your uncle’s “Nigerian Prince” scheme, so we’re going to have to do our research if we want people to actually open the email. Time to put your black hat on. If you don’t already know the person you’re targeting but your client wants you to go after an organization, you’ll have to find some email addresses. Some clients will provide a list of personnel with their email addresses, roles, and other relevant information.. which is great! But we don’t have that luxury in this scenario. What can we do? OSINT.. it?
1) Company’s Profile Page
Well gosh, thanks company website, for providing me with information that Curtis Brazzell is a Managing Security Consultant at Pondurance and his email is curtis.brazzell@pondurance.com! That’s a start! (By the way, if I haven’t said it yet, now’s a good time to mention you shouldn’t try any of this at home..)
2) Social Media
Great! This time I not only have his work email, but I have his personal email as well! You get the idea at this point as this could continue with Googling the victim’s name and finding other resources manually. OR, you could use some tools to automate a lot of this for you.
3) Recon Tools
Maltego
Social Engineering Toolkit (SET), LinkedInt, Discover, Maltego, theHarvester, Recon-ng, and MailSniper are just a few of my team’s preferred tools available during this phase of intelligence gathering, often referred to as the Reconnaissance phase. In fact, using a tool like MailSniper against a large organization can be easier than phishing, since you’re bound to get at least some valid accounts just by password spraying the employees with bad passwords like “Winter2018”. If you’re reading this saying, “HEY! That’s my password!”.. you might want to change it.
In my experience, the last thing you want to do is cast a wide net (not even trying, sorry!) when going after the organization when you have time on your side and the goal is to stay undetected for some time. There are circumstances when an attacker may want to blast out the same generic email to everyone in the company, but that’s likely going to tip at least one person off and everyone will be on high alert. Also, your domains could be blacklisted internally or externally, etc. A less tailored email is going to have less of a chance of successfully luring 😔 the recipient into opening the message. Furthermore, all it takes is one person to give up mailbox credentials if you have access to Office 365, OWA, or another externally accessible email service, and you can log in as that person to start internally phishing other targets from the legitimate domain! We’ll do that in this scenario later.
One thing I’ve realized is that context is everything when phishing. Say I successfully phish my target, then what’s going to be my next step? Is my goal to deliver a RAT, steal credentials, or record analytics for security awareness training? If it’s to deliver malware, consider what your payload is going to look like. Are you planning to deliver a document with an embedded payload? Are you attempting to send a link to an executable? What role does the “Recipient” you’re targeting have in the organization? Now consider who your “Sender” is going to be mimicking, or sending on behalf of. Would a non-IT person be asking someone to install an executable if that isn’t normal behavior? We want this to look believable!
For this scenario, assuming we did some recon and we discovered the IT Department’s email distribution is “helpdesk@pondurance.com”, let’s craft a campaign that’s believable and target a single individual.
Baiting the Hook
Right on, we decided on a campaign! Let’s pretend we’re the Help Desk and we’re emailing a manager who might have VPN access to the organization. After all, we did our recon and determined there’s a Cisco VPN available on an IP address within the External IP range of the organization. If we get credentials via phishing, we might be able to get onto the internal network! We also have learned that the Cisco AnyConnect client has a field for a “Second Password”, which we know is some sort of 2FA token. We’ll have to build support into our portal to capture the token as well or we won’t get very far, and it needs to be in near-real time since those typically expire within 30 seconds or so. To complicate things further, most 2FA services expire the token after the next use.
So since we’ve decided to steal credentials, we need to figure out how that’s going to play out. Let’s clone a web service login portal on our own site and make it look like it’s theirs! We’ll set it up to log any credentials and tokens entered and then send them on their way to the real site. We’ll also have to buy a domain that looks similar to the organization’s we’re targeting so the user isn’t instantly suspicious, and we’ll also want to get an email address created on that same domain. Let’s get started!
There are also techniques known as bitswapping, homoglyph, punycode, etc, which can be leveraged based on your preference. Tools also exist to help you come up with a similar domain if you’re not feeling creative. It’s also important to note that techniques like punycode only work on browers like FireFox and Opera, so you need to know what client your target is using. One of the more advanced tactics we try to leverage on my team at Pondurance during the information discovery phase, is to see if there are any application security vulnerabilities on the company’s web servers that may allow us to use their domain for phishing. These include Cross Site Scripting (XSS), Open Redirects, or Unrestricted File Uploads with Indirect Object References. However, let’s continue with the current scenario at hand.
Next, let’s obtain a web server. I like the AWS Micro Ubuntu instances because they’re quick, inexpensive, and simple to spin up and terminate when you’re not using them. Also, if your domain or IP get blacklisted it’s simple enough to obtain a new Elastic IP and be back in the game.
Now that we have a web server with a domain set up, let’s get a free TLS certificate. Most people have been trained in Security Awareness sessions to look for the green “Secure” lock in the browser. This does not mean the site is safe, it simply means data is encrypted in transit from the client to the server and back again. Leveraging a free service called LetsEncrypt, you can easily add that lovely “https” to the front of your domain. Using encryption is almost a requirement nowadays if you’re phishing, as Google Chrome and other popular browsers all warn the user when logging in to a form submitted to over plain text, which would tip them off in our case.
All that’s left to do now is to prepare the fake web content so it looks like the real thing. There are tools out there that will clone a static site easily (HTTrack, SET, etc), but often times there’s dynamic content (CSS/JS) that just doesn’t look quite right. I always find it easier to just “File ➜ Save Page As ➜ Webpage, Complete” directly in my browser and manually edit the HTML locally until it looks right. At this point a trick we like to do on our team is to add a BeEF hook into the landing page, possibly in an iframe for persistence. This will allow us to hook our victim’s browser and collect analytics for our deliverable.
Usually now you’d have to build another page to receive the request, build a back end database to store the credentials, integrate some alerting mechanism, and add some logic to redirect the victim to another page. Because this takes time to do and everyone’s skill set is different, I created an API for my team to handle all of this. I came up with a really unique name for it too. I call it.. wait for it, Phishing-API!
Basically, edit the HTML of your fake page to include the parameters required for the API and you’re all set to start phishing! You can also set up Slack notifications (or modify for IFTTT) and a Redirect link to send the user to once you’ve captured the credentials. I like to send the user back to the legitimate site again so they think the first round “just didn’t take”. Since we’re capturing a 2FA token and we need time to use it before the customer, let’s redirect them somewhere where they don’t need to use it. It needs to be somewhere that won’t raise too many alarms, like the homepage so they think it’s a glitch. I like to set up my Slack channel to notify my mobile device anytime there’s a post to that channel, so I can act quickly if I did capture someone.
Lastly, if you’re looking for something better than my API, check out Evilginx or CredSniper. These are wonderful tools and are much more feature rich than my simple program. I like Evilginx because it sets up a transparent proxy between the client and the server, making the request go through the proxy so you capture the session token. This means you don’t have to redirect the customer like you do with my API. It takes a little more to set up, but can be worth it if you’re looking to really fly under the radar. Let’s see our fake portal!
Casting the Line
It’s finally time for us to compose an email to our first victim! Let’s go after that goofy Curtis Brazzell guy.. the manager with the VPN access. Once we have our “HelpDesk@pondurnace.com” email account set up we’re ready to start drafting up a believable request. Remember, we’re betting on the fact that Curtis won’t notice the similar domain and won’t question the request from the Help Desk. Some email clients (like Outlook in Office 365) will let you know if your recipient is Out of Office. Microsoft is being kind to the attackers so we don’t have to wonder if they fell for it or if they’re simply out on a two week vacation.
In order to help get a more timely response, I find it’s helpful to put some kind of urgency in the request. Also, to make it a tad more believable, you’ll probably want to consider adding a valid looking email signature to the outgoing emails, especially if they’re used to seeing one. It’s that extra mile that makes the difference between a phishing scam and spear-phishing. Since these aren’t always publicly available, I love emailing the “Contact Us” or “Apply Here” sections of the targeted site to see if I can get a response with a signature in it. Lastly, if targeting more than one person, send separate emails and address the person by name so they’re not all just CC’d or BCC’d on the same line.
Since we’re phishing for credentials by sending victims to our fake landing page, we’ll want to use a hyperlink and mask it in a way so it’s not obvious to the recipient. I’ve noticed that email spam filters do a good job nowadays with catching a hyperlink where the text of the hyperlink looks a link but doesn’t match. For example, it’s better to use a hyperlink to the fake landing page that has the hyperlink text “Secure Login Portal” or something instead of “http://...notfake". See below:
Reeling ‘er In
This is the fun part! It’s where you sit back in the boat and wait for the catch. In my case, make a PB&J while I wait for my Android device to go off.
Once a phish is caught, it’s time to click the link in that slack message and re-use those credentials!
We have a username, password, and a token! Meanwhile, Curtis is staring at the homepage assuming his credentials worked since he doesn’t see a reason to believe they weren’t valid. Meanwhile, I’m cleaning the peanut butter off of my shirt while I frantically enter our new credentials into Pondurance’s VPN portal.
At this point it’s safe to say the domain is compromised and Curtis likely has no idea what happened. As a penetration tester, you can take it from here by exploiting internal assets, moving laterally, and scooping up additional credentials along the way. Another option may be to use Curtis’ credentials to log into his inbox and get someone else in the organization to open a RAT that gives us access to a workstation. Also, if you have someone’s account already a lot of times you can use a tool like MailSniper to easily enumerate all email addresses in the Global Address List. I like to leverage the search functionality MailSniper offers in order to find sensitive words like “password” in the inbox, so you don’t have to snoop through people’s messages. This is another reason why it’s never a good idea to email sensitive information, like passwords, credit cards, or PII.
Because users can be suspicious of phishing campaigns, we’ve found it best to log into the user’s inbox as soon as possible and keep the session open as long as we can. Office 365 apparently doesn’t invalidate the session even if the user gets suspicious and changes their AD passwords, so this can be a good way to keep persistence throughout the engagement.
Don’t Be a Phish
Okay, so reading this you probably have a few good ideas on how you can avoid being duped like our boy Curtis. We can’t rely on products out there to stop all of the spam that comes in, especially when it’s targeted, so we have to do our due diligence ourselves. Tools help, but they really should be considered the last line of defense against Social Engineering.
I couldn’t possibly cover everything to look out for when spotting a phishing email and besides, this blog isn’t meant to be a comprehensive security awareness guide. Wired did a story recently on Resisting Phishing Attacks With Three Golden Rules, which is worth a read.
When I have doubts about an email because it’s outside of the norm, I’ll sometimes call/text/slack the sender and ask if they really sent it. Try to always verify the sender of an email and hover over hyperlinks to make sure they are from the correct domain. When in doubt of a link, run it through an online analyzer like urlquery.net. Lastly, be suspicious of any attachments, especially those that are executables or contain executable content (like PDFs or Office docs with macros, OLEs, etc). Now that you know some basic things to look out for, what can be done to protect your accounts if your passwords are stolen?
Enable Multi-factor Authentication
¹It’s generally a good idea to enable Multi-factor Authentication (MFA) whenever it’s available to you, both as an individual and as an organization. A password is something you know, but a second form of authentication can be something you have which helps to validate you are who you say you are. A lot can be said on this topic and I won’t plan to cover everything, but I’ll go through the basics at a high level so you can be aware of the pitfalls of some 2FA implementations.
Two Factor Authentication (2FA) Tokens
You’ve probably all seen some form of these at some point, probably when your bank texts you a pin code and asks you supply that along with your password. There are several different kinds of 2FA, including biometrics, badge readers, etc. Here are a few common ones:
- RSA Keys
These are hardware devices, typically with an LCD screen, that provide a numeric pin that rotates every 30 seconds or so. These, like any 2FA, are better than a password alone but it wouldn’t be too difficult to capture this in a phishing exercise, as we did in our scenario above. All we have to do is trick the user into entering this for us and acting on it before the time expires. Push notifications through our API allow us to respond quickly enough for this attack to work.
- SMS Messages
This is no longer considered good practice, and I see this going away soon. SMS messages can and have been intercepted in the wild using SIM card swapping, spoofed cellular networks, and social engineering attacks against victim’s wireless carriers. Also, SMS isn’t tied to a specific device necessarily.
- Software / Application Tokens
Popular application based 2FA solutions include Google Authenticator and DUO, to name a couple. While these are better than SMS, they can still be intercepted by an attacker and used before it can be leveraged by the victim. In our example, DUO was used and was not set to expire over time, but instead invalidated upon use or when manually refreshed. This just allowed the attacker even more time to respond.
- Mobile Push Notification
In my opinion, this is the most secure of these 2FA options listed so far. These are also super convenient for the user. You may have noticed Google now prefers this over Google Authentication for G Suite, so now you simply get a push notification asking a “Yes” or “No” to confirm you’re really trying to sign in to your account. It’s also worth mentioning that some software products like DUO optionally allow you to use “push” instead of a token, which makes it less-phishable.
Universal Two Factor Authentication (U2FA)
- Security Devices
These, in my opinion, are the best. Are they fool proof? No. If you haven’t figured it out by now, nothing should claim it’s “Hack Proof” or “Unphishable”. However, it’s one of the strongest options available today. These are physical hardware devices, typically in the form of USB, using the USB connection itself, NFC, or Bluetooth to help provide that second “what you have” factor of authentication. A popular example of this is the Yubikey, of which I’m a proud owner. Now that this open standard is taking off, many websites offer support for these physical security tokens and don’t need to ask you for it every time you log in, only when you’re using a new device or your session expires. It’s hard to phish what you can’t get control of, but that didn’t stop a couple of researchers from leveraging a flaw in Google Chrome’s WebUSB to access the Yubikey Neo and obtain authorization remotely. Unfortunately for me, that’s the one I use so I had to disable WebUSB for now in my browser to mitigate the risk.
Brian Krebs recently released an article claiming that Google hasn’t had any of it’s 85,000+ employees successfully phished since requiring all employees to use U2FA since early 2017. That says something!
To take things even further with a hardware device like Yubikey, Microsoft recently announced that Azure Active Directory and even non-AD Microsoft Accounts can use Yubikey for Windows Hello on Windows in place of a password (or along with it) to sign onto the operating system. Neat! Also, with the new open WebAuthN standard coming out, it’ll make it easier for web sites to start supporting hardware based authentication, so expect to see even more of this in the near future.
Report any Incidents or Suspicions
I think the best approach is to do what you can to prevent falling victim, but assume that you’ll fall for something at some point. Even the best of us can fall for a scam when we least suspect it. After all, we’re each checking potentially hundreds of emails a day and it’s easy to let your guard down.
You learn a lot about people after gathering access to their inboxes and like all of us, people tend to be a little humiliated when they find they’ve been tricked. Often times after being suspicious of an email they fell victim to, it’s not reported. That, or it gets reported but it isn’t disclosed that the person went through with the request.
The important thing is that everyone has a “Neighborhood Watch” mentality. If the first person suspects something is wrong and reports it, then it could potentially save many others from falling for the same scheme. The IT Department can quickly sinkhole DNS records, block IP addresses in the firewall, and disallow URLs in the web content filter to help mitigate the attack. If your credentials or computer are compromised, it’s better to report right away than silently wait for them to be used for something else without your knowledge. If you do give up your credentials, hopefully you’re not reusing that password anywhere else. If so, consider changing those right away and look into getting a password vault protected with MFA. 😜
If you plan to start adding MFA to all of your accounts, good for you! I’d argue that the most important place to start is with your email or, if using SSO, those accounts as well (Facebook, Google, etc). The reason I say this is because I can’t tell you the number of times I’ve gotten into an inbox and could simply perform a “forgot my password” to gain access to an external site, even if it’s secured with MFA itself! Often times you can disable MFA or re-enroll it (as I’ve done on pentests before) to the attacker’s device so long as you have access to the victim’s inbox.
I hope you enjoyed this blog and leave today a little more armed against these types of attacks, for yourself and your organization alike. Remember, if you smell something phishy.. it might be a phish!
- Curtis Brazzell
