Tips for an Information Security Analyst/Pentester Career - Ep. 99 - Lessons Learned in Evasive Spear Phishing

I recently completed the second evasive spear phishing gig in a short amount of time, so I had to up my game and learn a lot of new stuff very fast.

I missed the mark with the first gig, but on the second assessment my emails slipped through the client's defenses, even though I still feel I could've done a better job.

This post will be about what I learned from this experience and what steps are needed for a successful assessment, without revealing any details about specific clients and projects. I'm also going to live demo a very cool tool I used to deliver my campaign, so stick around for that (check the embedded video for more details).

I will briefly define some basic concepts before diving into what I did and talking about what steps are needed to get better at this. 

SPEAR PHISHING VS ENTERPRISE PHISHING

The distinction is important and not only semantic.

Spear phishing is a very targeted type of phishing that involves a small group of the client's employees (usually 20 to 50), often times having the same role (e.g. HR employees, executives). As such, it uses personalized information and tends to define attack scenarios very specific to the target user group.

Enterprise phishing targets the whole user base of a specific organization (normally 100 to 500 users or more, depending on the specific organization's size) with more generalized attack scenarios, that can be relevant to all employees. The goal is to trick recipients into revealing sensitive information or clicking malicious links, but it lacks the tailored approach of spear phishing. In other words, spear phishing is a targeted attack, while enterprise phishing tends to be more of a shot in the dark.

EVASIVE SPEAR PHISHING VS. NON-EVASIVE SPEAR PHISHING

Spear phishing campaigns can be evasive or non-evasive.

Evasive spear phishing assessments resemble much more closely real-world adversaries' techniques, so their goal is to assess whether carefully crafted emails can slip though the client's email defenses without need for the client to whitelist the phishing domain. They're conducted with non-attributable infrastructure, so the phishing server(s) must be configured in a way that the target users can't determine who owns the attacking infrastructure. The focus here is on assessing how much a very targeted attack, conducted with carefully crafted messages, is likely to slip through the email perimeter defenses and deceive the target employees. For these reasons, evasive spear phishing attacks must be stealthy and credible. They can sometimes also be part of a red teaming assessment.

Non-evasive spear phishing campaign are more focused on employees' awareness, so whitelisting the phishing domain is no big deal in this case. What matters here is to assess the user base's response to targeted attacks. 

FIRST STEPS 

• Kickoff call with the client: you need to ask two fundamental questions:

1. Do I have to define a list of targets or will you provide one?
2. Do you want for me to provide potential attack scenarios or do you have some specific scenarios in mind?
   

The answers to these questions define the level of effort expected from you. Though OSINT is always needed, if the client can provide at least one of the above elements, that can save a lot of time and stress, as these engagements don't normally last very long.

• OSINT stage: is paramount for the campaign's success and the sooner it's started the better. Ideally, one should begin doing this at least two weeks before the engagement kickoff date, but it's not always possible. We need to know all we can about the target organization to make our message look more credible: company logos, corporate culture, preferred fonts, email signatures, mergers, recent news, technology stack, social media presence, potential targets for impersonation, etc. The final email must look and feel to the reader as it might come from within the target organization, so they're more inclined to click the link.
• PREPPING INFRASTRUCTURE: I'll delve deeper with the related settings in the video demo, however the basic steps are as follows:
• Have an aged domain at hand, ideally purchased over 90 days earlier than the start of the engagement and never used in prior phishing engagements, to host the phishing server. Domains that are newer than 90 days can more likely  get flagged as suspicious and blocked by email defense mechanisms.
• Create an AWS EC2 instance to host your phishing server: in your security settings, edit inbound rules by restricting SSH access to your public IP and opening TCP and UDP ports 53, 80, 443 and 8443 to everyone (select Anywhere-IPv4).
  
• Properly categorize the domain: make sure the phishing domain is included in a category rated as low risk, such as Blog, business, computing, etc. This is important because organizations block domains that are either unclassified or ranked as malicious, which efficiently thwarts potential attacks (ever happened to try visiting a page only to receive a message such as "this page is unavailable due to policy restrictions"?). Without a proper domain categorization, all the hard work going through the target organization's defenses could be totally useless. For this reason, after uploading real contents to your website, submit its URL to databases such as this one. Go ahead with your efforts only after your domain receives the correct categorization from multiple databases. Below is an example of an email received for a successful categorization request.
  
  
   
• Use credible servers: in a real-world assessment, I'd use something like an Office365 account to send the emails from my "clean" domain, and they will most likely go through. However, in my demo I'm going to use a Gmail account cause it can be set up more quickly.
  
• Install and configure phishing software: For non-evasive gigs, the set up used to send phishing email includes GoPhish, in combination with a sending service such as Mailgun. For evasive gigs, though, the set up must be different. In fact, Mailgun IPs are often blacklisted because a lot of people use them for spamming purposes. I was very successful adding an aged domain to Office365 and creating a custom user to send emails from such domain. For evasive gigs, a very common tool is Evilginx, a reverse proxy allowing to clone a page belonging to the target organization and use it to steal user credentials, including MFA tokens. I'm not gonna delve with Evilginx here, even because some peculiarities with the client's network environment led me to prefer another tool, called SquarePhish, that I'm going to demo. 
• Personalize and improve email template: Before kicking off the campaign, it's paramount to work on the email template, to make sure it looks credible enough to convince a user to unconditionally click the link. That requires a lot of OSINT and hard work, other than attention to details.  An error here could compromise the final outcome of the campaign. You can assess how likely your email template can go undetected by using tools like Mail Tester or Spamcheck. The higher the score the better the email template.

DEMO 

The tool I'm going to demo, SquarePhish, uses a technique combining the OAuth Device code authentication flow and QR codes. The victim receives an email containing a QR code that they should scan with their phone to renew their (allegedly) expired Microsoft Authenticator MFA token. After that, they receive another email with a device code to be entered at the related Microsoft login page. At that point, the phishing server will gather the user credentials submitted and save them to a file. Check the video for more details.

Wrap-up

Here's what I learned from this experience:

• Evasive spear phishing is hard. Deploying the infrastructure the proper way is time consuming and challenging, so prepare ahead of time and don't rush through things. A small mistake could get your domain burned and the engagement go sideways before even getting started. Put the needed effort into getting as best results as possible.
• Don't waste precious time insisting on solutions that are clearly not working and have back up solutions handy. 
  
• Ask the client for clarifications as soon as needed.
• Be as thorough as possible with your OSINT and leave no stone unturned. This can be challenging when juggling multiple projects.
  

My last campaign was a nightmare but I ended up learning a lot from it. When I started seeing hits on my phishing server, I almost couldn't believe it and I felt very proud. I feel I could've done better with the email template but multiple setbacks caused me to almost run out of time.

FINAL LESSONS LEARNED 

• PREPAREDNESS: get started as soon as possible to account for technical issues, setbacks or client's slow response times.
• CREDIBILITY: Be creative and try to put yourself in the target employees' shoes. Were you to receive such an email, would you click the link or would you recognize potential red flags? The answer to this question can guide you to the best solution for the specific assessment. Don't forget spear phishing is based on social interactions, so some understanding of human psychology and social dynamics can go a long way.  As a result, it's a much more challenging task than a simple pentest, because it's about technical and social engineering knowledge at the same time.

I feel I've become a more well-rounded consultant after learning from my mistakes and being able to deliver regardless. This is surely another stepping stone towards red teaming, that shows how hard it is to get good at that.

I expect hardships but I also believe nothing is 100% impossible, and that's how I learned the (few) things I know.