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.
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:
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:
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.
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:
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:
This is just a short list but there are many other file types that can be sent with embedded malicious software.
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:
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.
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:
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:192.0.2.0/24 include:_spf.example.com -all
In this example, emails from IP addresses within the range 192.0.2.0/24 and those authorized by the SPF record of _spf.example.com are considered valid.
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.
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?