A Good Day To Go Phishing

We’ve all received a pesky phishing email that ends up in our inbox. Your response to the email ends up being the deciding factor if it’s successful for a hacker. But how does it end up in our inbox and what all went into receiving a phishing email? This blog post will go into a high-level overview of some of the hurdles an attacker must overcome to send a successful phishing email.

The Target

There are usually two circumstances that victims fall into to become a target for a hackers next phishing campaign.


Each time you hear on the news that an organization has gotten breached there is usually some form of data that was obtained by the hacker. This usually includes usernames/email addresses and password. Once an attacker obtains an email address it gets lumped together with many other breached lists of email address creating a massive list of email address that the hacker might use on their next phishing campaign.


Most individuals are not on a hacker’s radar by choice but there are few things that might make you into a prime target:

  • You receive emails that have email attachments on a daily basis
  • You currently have access to privileged accounts within your organization
  • You are newly hired to the organization within (90 Days)
  • You are an IT administrator for your organizations
  • You have general administrative access to any key systems in your organization
  • You deal with the transfer and movement of money within the organization
  • You work with “sensitive information” or data within your organization
  • You work for a third-party company that interfaces with the hackers main target company

This is just a few that come to mind but there are multiple reasons and connections to becoming a prime target for a hacker.


Unless a hacker has already infiltrated someone’s cloud infrastructure, or they are “borrowing” someone else’s computer. They will temporarily create their phishing infrastructure using whichever cloud provider they prefer this usually consists of one of the following:

  • AWS
  • GCP
  • Microsoft Azure
  • Linode
  • Digital Ocean

An attacker will use either one single phishing/payload server to send out their email and host a payload or break their infrastructure into two separate servers one server to send emails and another to host their payloads.

Attack Type

After choosing a cloud provider they will now have to make a choice what is the main goal or what are they trying to obtain. There are usually a few different goals for a hacker to choose from:

  • Phish for user credentials (username/email address & password)
  • Phish for session cookies (Usually obtained through man-in-the-middle tactics)
  • Phish to obtain a foothold (Trick a user into installing or running malicious software)

Once an objective is found the hacker will usually stand up a minimum of two server. One server to send the phishing emails and the second server to receive clicks and host a payload.

What is a payload?

Based on the type of objective for the phishing campaign there could be the following:

  • Phish for user credentials (username/email address & password):
    • Usually, a fake website that has a login portal
  • Phish for session cookies (Usually obtained through man-in-the-middle tactics):
    • A fake website that has a login portal
  • Phish to obtain a foothold (Trick a user into installing or running malicious software):
    • Usually there is a link to a malicious application to download. They can include some of the following files:
      • exe
      • zip
      • docm (macro attack)
      • pdf
      • hsa
      • iso

This is just a short list but there are many other file types that can be sent with embedded malicious software.

Email Template

Next a hacker will need to create their own email message. This is what will make or break a phish. One of the easiest methods is to grab an existing html email template from the Internet and alter it to suit your specific needs.

After a quick google search, you should be able to find an existing template. Next the attacker must think about how to convince their victim into clicking on the email. Attackers usually focus on exploiting the following emotions:

  • Fear: This is a primary emotion leveraged by cybercriminals. They may send messages that create a sense of panic or urgency, such as threats of account closure or legal action if immediate action is not taken.
  • Curiosity: Phishing attempts may pique a target’s curiosity by promising exclusive access to content or sensational information if they click on a link
  • Urgency: By creating a false sense of urgency, attackers can push individuals to act quickly, bypassing their usual caution and skepticism.
  • Desire: Offers that seem too good to be true, such as job offers, prizes, or other opportunities, can exploit a person’s desires and lead them to engage with phishing content.

These tactics play on the innate psychological responses that can override rational thought and lead to hasty decisions. Once your email message has been crafted its on to bypassing the spam filter.

Spam Filter

After the email message is prepped and the payload is set, the last piece of the puzzle is bypassing the dreaded “control”. So, what is a control? With most things there is usually an application set into place in front of the email service which works in the background to protect users from malicious emails. This spam filter’s main purpose is to verify and validate if an email is legitimate or spam.

Simple enough right, but how do we bypass it?

First key is to understand what is standard for emails. How does a control verify the legitimacy of your email domain? There are three main email authentication methods:

  • Sender Policy Framework (SPF)
  • DomainKeys Identified Mail (DKIM)
  • Domain-based Message Authentication Reporting and Conformance (DMARC)

Sender Policy Framework (SPF)

SPF is an email authentication method designed to detect forged sender addresses during the delivery of the email. It works by specifying which IP addresses are allowed to send emails on behalf of a particular domain. When an email is received, the recipient's mail server can check the SPF record of the sender's domain to verify if the email is being sent from an authorized source.

Configuring SPF: To configure SPF for your domain, you need to create a DNS TXT record containing a list of authorized IP addresses or hostnames that are allowed to send emails on behalf of your domain. This record should be added to your domain's DNS settings.

Example SPF record:

v=spf1 ip4: include:_spf.example.com -all

In this example, emails from IP addresses within the range and those authorized by the SPF record of _spf.example.com are considered valid.

DomainKeys Identified Mail (DKIM)

DKIM is another email authentication method that allows the sender to digitally sign an email using a private key. The recipient's mail server can then verify the signature by using the public key, ensuring that the email has not been tampered with during transit and that it originated from the claimed sender.

Configuring DKIM: To configure DKIM, you need to generate a public-private key pair. The private key is used to sign outgoing emails, while the public key is published in your domain's DNS settings as a DKIM record. The recipient's mail server can then use this public key to verify the signature of incoming emails.

Domain-based Message Authentication Reporting and Conformance (DMARC)

DMARC builds on top of SPF and DKIM to provide additional protection against email spoofing and phishing attacks. It allows domain owners to specify how they want email messages that fail SPF and DKIM checks to be handled. DMARC also provides reporting mechanisms to help domain owners monitor and improve their email authentication practices.

Configuring DMARC: To configure DMARC, you need to publish a DMARC policy in your domain's DNS settings. This policy specifies how you want emails that fail SPF and DKIM checks to be handled, whether to quarantine or reject them, and where to send aggregate and forensic reports.

Example DMARC record:

v=DMARC1; p=quarantine; rua=mailto:dmarc@example.com; ruf=mailto:dmarc@example.com; fo=1

In this example, the DMARC policy instructs receiving mail servers to quarantine emails that fail authentication checks, and to send aggregate and forensic reports to dmarc@example.com.

Once SPF, DKIM, and DMARC, have been configured for the email server this will significantly increases the validity of your phishing emails.


After all the configuration has been completed, it is now time to send the email. The target has been set, the infrastructure has been configured. Even if the email gets into the user’s inbox(You've go mail!), will they open up the email? Will they click on the link? Will they try to login? Will they download and run your malicious program? Or will it end up being just another day phishing?

Securing Tomorrow,

A thing showing CTA