Getting Into It
When I was a SOC Analysis, understanding how to analyze phishing emails actually came up quite often in interviews I was in. For example, the job I actually took when I first become a SOC Analyst at my first security gig, I vividly remember the interviewer giving me a scenario in which I walked him through what I would look at were interpreting a phishing email. This wasn’t hands on but was more so a test to see if I knew enough off the top of my head. This was the only technical question I actually got thrown my way if I remember correctly so this definitely save my a$$. And for good reason, given it was an entry level, first line of defense role, I was manning the phishing email analysis so I’m assuming that’s why that hit me with that question. It’s a fundamental skill that you will definitely want to in most Security Analysis entry roles and depending on the size of the shop you are interviewing; it would not surprise me if these details across System Administrators as well to make up for lack of team size.
I’m going to start off this guide starting with the least technical ways to spot out a phishing email and we will work through more and more “advanced” or more technical aspects of an email that can help you determine if that email is a phishing attempt or not. Often times either the system will automatically “quarantine” emails or block them actually hitting the mailbox until the email is approved after analysis, or users will have a built in “submit for review” of some sort of button if they want the security team to take a deeper look into an email before interacting with the email in question.
What to Look for First (Least Technical)
These are the checks I usually do as my first spot check. You’d be surprised at how many emails you can tell almost immediately are phishing attempts. This may seem obvious, but they genuinely can come in pretty handy and often times the first spot check you do will end up revealing whether it is a phishing attempt or not.
Prepping for an upcoming interview? Don’t forget to save this to review 30+ Security Analyst specific interview questions and answers
Look at the actual email address:
The first step is to always actually look at the sender’s email address right at the top of the email. Often attackers will look for a quick win by sending 1000s of email will a clearly faked email hoping someone will blindly click. For example, MicrosoftSupport@Gmail.Com asking for a password reset. As we all know, no emails will come in from Microsoft that have a gmail attached domain, phishing. A good amount of these attempts will come from a random gmail account that hope you don’t look at the @gmail or other mail domain you typically see with personal emails.
It’s another always that straight forward though. For example attackers can actually purchase similar domains to make it a bit easier to fool a non-trained eye. For example, the IT at your company could be “ITSupport@yourcompany.com”, and an attacker can can purchase a very similar “ITSupport@yourcompany-support.com”. Although this is a non-technical starting point do not overlook it!
Generic Verbiage / Introductions:
As attackers are often firing these emails at 1000s of emails at once, they don’t have time to sit there and curate a personal introduction for every one of their potential targets. A tell I usually look for is a generic email introduction such as “Dear Valued Customer” or “Dear Customer” as opposed to a “Dear [Specific User’s Name] email. At the very least, this should at least give you a heads up that this email is some sort of spam / coming from sort of bulk distribution list on the backend.
Spelling / Grammar:
I’m not too sure why this is common, but it could be that often attackers can be coming from overseas therefore their first language may not be the one you are currently operating in. A good tell you look out for is the way emails are structured that have for language errors that may stand out.
For example, it could be as simple as “Your password have expired” as opposed to “Your Has Password Expired”.
Request of Personal Details:
The goal of an attacker with a phishing email is often very straightforward. Get the information they want and get out. Any email you come across that is requesting for personal details / information to any extent is a red flag. Just for examples to look out for that may be seem obvious such as “Please reply with your password” or “To move forward please confirm your SSN to move forward with your request”.
Urgency / Threatening Tone:
As mentioned, the goal of an attacker is to get a quick click or a quick reply to their email with the information they want. Keep a keen eye out for emails that start off with “Answer Immediately Or Your Account Will Be Closed”, or of that nature. This is a tactic to hope you don’t spend the extra 10 seconds to realize it is a phishing attempt.
For example, there has been many cases in the wild where attackers will pose as legitimate vendors to a company and send an email such as “Send Banking Information or the deal is going to fall through!” towards a lower-level employee. The goal again here is to prey on a lower-level employee to quickly reply with the needed information for the transaction so it doesn’t fall through on their terms.
Diving Deeper — More Technical Analysis for SOC Analysts
As you can imagine, there will not always be a scenario where the first spot check is good enough. This is where learning more ways to interpret emails at a deeper level will be the next course of action.
Make sure you to scroll to the bottom of this article as I will go into much more detail about email headers and email authentication protocols such as SPF, DKIM and DMARC.
Analyzing Email Headers (This will be more in-depth in the final part):
The email header itself can hold very helpful information to give you more details about an emails actually origin and the path it took to that user’s mailbox. 99% of the time, the security platform will be able to extract the headers for you instead of having to manually do it yourself which saves a ton of time. But if not, you can use often extract the raw data from email itself and then further analyze it through by searching for certain parts of email using “Ctrl-F” for keywords that are helpful. For example, to touch upon it briefly as I will go into more detail at the end of this article, you can look at the “From” and “Return-Path” match up or if a suspicious email is configured to receive any emails that reply to it.
URL Inpsection:
Under the assumption an email contains a URL, you can further get an idea if you still are unsure if it is malicious in nature by analyzing the URLs deeply. Just make sure not to click on them (lol). For example, you likely will have some sort of security system / URL inspection tool that will let you paste a URL that will check it against reputational sites to see if it has any hits for being malicious. This works as well since often times attackers will using ways of masquerading the underlining URL to be labeled as something is not so at first it may look legit, until it’s clicked. Make sure these are tested in a secure environment but often times, at least from my experience these URL scanners if you amy are built right into the email security platform themselves. A URL that comes back as having malicious hits from a database should immediately signal it is an attempted phishing attempt.
Attachments:
The process goes the same for URL’s. Often times security platforms will provide analysis for attachments as well that are inspected further to see if they are embedded with anything malicious. For example, a common attack is embedding a macro inside of an office document that under the hood is really communicating with a command and control server in the background. But from the user’s perspective, it would just look like a normal word / excel document for example. (Microsoft I believe has pushed a setting that blocks all Macro’s’ by default now but just for example's sake). For example, VirusTotal files can be submitted that would check the file hash for any other reports of suspicious reports in the wild.
Utilizing Threat Intelligence:
Information that an email has that can be checked against reputational databases does not just stop at URLs and attachments (think file hashes), but for general email information as well. For example, the X-Originating IP, most times should show where the email original was generated. If this IP is flagged for being on some sort of threat intelligence database, then that means this IP has been flagged somewhere else for belonging malicious / suspicious behavior.
Onto the Nitty Gritty Stuff (More Intricate Concepts):
Email Authentication Protocols (SPF, DKIM and DMARC):
The goal of these protocols is to combat email spoofing and tampering while it is transversing the internet. These mechanisms allow for us to check that emails were actually sent on the behalf of the email domain / sender they are saying they are from.
SPF — Send Policy Framework:
SPF works by preventing email spoofing. In the simplest terms I can think of, SPF will allow us to confirm if a mail server is actually authorized to be sending emails on the behalf of the domain. For example, if spoof my email address to somehow say @Microsoft.com , but the SPF check confirms that the mail server I am sending my email from (definitely not from Microsoft’s), then the SPF check will show a fail. Essentially, if the mail server an email was sent from, is not listed on a specific domains “allow list”, this would flag as a SPF fail. The allow list in this example would be a list of IP addresses of mail servers that are registered for a specific domain (likely a specific companies).
Breaking It Down:
For this to work, owners of a domain will actually configure a list that shows IP addresses / mail servers there domain is legitimately registered with. This takes place that domains DNS record. Therefore, when email on the internet is sent out on the internet claiming it is coming from a specific domain, this can be legitimately fact checked with the SPF record. This would then in theory thwart any attempts of an attacker sending an email to appear as if it came from a legitimate domain, as their IP would not match any of the companies registered IP / Mail servers. To clear up any further confusion as I know that is a lot, here is an example of what an SPF record check would actually look like in a header.
In this example, you received an email from someone of the email address of Bob@fakecompany.com
Received-SPF: pass (server: domain of fakecompany.com designates 1.2.3.4 as permitted sender)
This information in the header, is telling us that since the email came from a @fakecompany.com domain, that they checked what mail server / IP address the email came from, and it is legitimately registered with @fakecompany.com’s domain in their SPF record located in their DNS record. It goes without saying but if it said fail, this could indicate an attacker was attempting to pretend they were sending an email from fakecompany.com’s domain.
DKIM — Domain Keys Indentified Email
While SPF mainly dealt with the confirmation of the source of the email, DKIM is focused on ensuring the integrity of an email as it transversed the internet. Basically, it ensures the actual content in an email had not been modified or tampered with during it’s journey to your end user’s mailbox.
Essentially when an email is sent out the mail server it originated from has also generated a specific signature associated with it, which consists of the email itself and content within it, but a private key as well. When the email is eventually received, the mailsever of the receipient would then validate the email was not tampered with by that companies domains DNS record containing the associated public key. This communication allows for the validation of the original DKIM signature to ensure it had not been changed throughout it’s transit as any modification would have altered the emails contents and not match the unique signature originally generated.
For example in email header, you can control-f to pinpoint it but you will see somwhere saying “dkim=pass” or fail respectively dependent on the results. Often time this is located near “Authentication Results” but I usually will just ctrl-f for the dkim keyword if the security platform already does not present this to me.
Again before we move onto DMARC, it should be clarified again that DKIM is not checking the legitimacy of the sender itself, but is instead just focused on if the content of the email itself was altered or not since it had originally been sent out. SPF is focused on ensuring the original sender IP / Mail server is legitimately registered with the domain.
DMARC (Domain-Based Message Authentication, Reporting and Conformance)
DMARC is a bit different but actually relies on SPF / DKIM. DKIM instead of being a protocol is actually a configurable policy that also lives within a domains DNS record. It is configured by domain owners to actually tell receiving mail servers what to do if they receive email from their domain that fail SPF / DKIM checks. It essentially an instruction for a receiving mail server should react if an email sent from their domain failed these checks. For example, it can be configured to tell a receiving mail server to reject, quarantine, spam or let the email go through if it is received. For example, say fakecompany.com has both the SPF and DKIM configured properly in their DNS record. They are 100% certain that it would pass both checks so they set their DMARC policy to tell receiving servers that if our emails don’t pass these checks, do not let them through cause that means someone if spoofing us.
It serves basically two purposes. It maintains email integrity from their domain as it lets recepients know that they have their SPF / DKIM set up correctly so if it receives any email failing it, to reject it as a safety measure. The other aspect is also for building intelligence as well. For example, if they then receive reports that another company is receiving emails appearing to be their domain but failing the SPF/DKIM checks, they can A) double check they have configured their DNS records correctly and B) do further research to try and figure out who is attempting to spoof their domain.
Looking an email header for SPF/DKIM/DMARC:
Authentication-Results: mx.fake.com; spf=pass (fake.com: domain of user@fake.com designates 1.2.3.4 as permitted sender) smtp.mail=user@fake.com; dkim=pass header.i=@fake.com; dmarc=pass (p=NONE sp=NONE dis=NONE) header.from=fake.com
SPF/DKIM/DMARC TDLR:
SPF = Confirms the email came from a legitmately authorized server for the domain associated with it
DKIM = ensures the email has not be altered throughout it’s journey over the internet
DMARC = let’s recipients of mail from your domain know what to do if they receive an email from your domain failing the SPF / DKIM checks both for reputational purposes and potentially misconfiguration issues
I know that was a lot, but it’s pretty important to understand. For starters, you will need to understand how to interpret these when analyzing emails and you very well one day could be tasked with configuring these records, or better yet you could get slammed with this question in an interview.
Deeper Look into Header Analysis:
Email headers are pretty much often what you will end up looking into when you are looking very deeply into an email for further analysis. Headers contain information that can be very helpful in deteriming more details of an email you have are lookiing into. For example, the route the email took over the internet, or where it originated from, can be pulled out from the raw data living inside an email header.
Often times your email security systems will slap this right in front of you, all extracted already, but if you are at home you can get a good feel for emails on whichever client you use. For example, just look up how to get headers from email gmail. But off the top of my most clients have it shown as something of “Original Email” or “Message Details” if I am not mistaken.
Email Header Helpful Components:
From and Return-Path:
This what the email address is displayed as an absolutely can be spoofed. I wouldn’t use this as my source of truth to green light an email but a quick check you can do is to look at the “From” address and compare it with the “Return-Path” address in the email header. If these two don’t align, that is a red flag. Especially if ther return-path is absolutely something suspicious. For example, an attacker could spoof their email is anything and have the return-path route to their personal email address. Therefore if someone fell for their email, the reply would hit their personal inbox instead of the one they are spoofing in the displayed address to the user.
Received:
Received is actually pretty helpful and basically just shows where the email traveled through during its journey to your mailbox. You can trace this the hops or mail server IP it traversed to get the original IP address. This could then be checked against IP reputation databases for malicious reports or even confirmed on tools such as WhoIs to see if that IP is legitimately registered with the company they may be posing as. Keep in mind, this should usually be covered in the SPF check as mentioned earlier as it should theoretically confirm an IP was registered with a domain, but I always double check.
X-Originating-IP or Originating-IP:
The nomenclature could potentially differ, but I’ll usually hit the email header with a CTRL-F for “IP” to look for that original IP address. Sometimes this is not actually presented in an email header, which is where I would look at the received fields, if applicable to get an idea of where it originated from but if you do have the X-Originating IP, it is pretty valuable to do further research on the potentially supsicious sender.
SPF/DKIM/DMARC (Refer to previous paragraph)
Fake Email Header Example:
This was pretty hard to format with medium to be honest but I bolded the parts that we will break down to hopefully make it a bit more readable.
Received: from mailserver.suspicious-sender.com (123.456.78.90) by yourmailserver.com (192.168.1.1) with SMTP;
Tue, 8 Aug 2023 08:00:00 +0000
From: “Your Bank” <support@yourbank.com>
Return-Path: <bounce@suspicious-sender.com>
X-Originating-IP: [987.654.32.1]
Received-SPF: fail (yourmailserver.com: domain of yourbank.com does not designate 123.456.78.90 as permitted sender)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=suspicious-sender.com;
Message-ID: <1234567890@suspicious-sender.com>
Subject: Account Alert!
Breaking It Down:
From / Return-Path Addresses:
First — we notice the From Address and The Return-Path address are not the same. The From Address, which is displayed to the user is as “support@yourbank.com” does not match the email replies will be sent to which is found at Return-Path “suspicious-sender.com”. The From Address can always be spoofed and pretty easily but the return-path address will show whom is actually sending the email. In this case, this is definitely being spoofed.
IP Address / Mail Servers:
Now let’s look at the IP addresses / mail servers involved here. Let’s take a look at the Recieved header to take a look at the path this email took to get to us. We notice that the email was originally sent from the mail server called mailserver-suspicious.com with IP address of 123.456.78.90
Next let’s take a look at the X-Originating IP field. It may raise a flag that this IP address does not match that of the original mail servers IP address, but that can be pretty common. The originating IP address sometimes can be what was captured from the actual device that had been sent. Either way, it worth looking into as you check both IP addresses against reputational databases.
SPF / DKIM results:
SPF is pretty clear here. It failed the SPF check. This is telling us that the mailserver that had originally sent us the email, is NOT authorized by the @yourbank.com domain that is is claiming it sent from. This is an immediate red flag of a spoofing attempt.
DKIM Signature:
This may not catch your eye at first but there is another red flag in the DKIM signature. Notice the DKIM signature is actually associated with the suspicious-sender.com domain. You can tell by looking closer at the DKIM part of the header and notice it says d = suspicious-sender.com (where d is the domain) as opposed to ‘YourBank.Com’ which the email is pretending to be have sent from!
Wrapping Up:
That was a lot but I really do reccomend getting this nailed down in your head. Not only will like this likely be a common task when you are first starting off in a blue team position but it has a pretty high chance of being an interview question as well, speaking from personal experience.
There are plenty of platforms out there to get hands on experience with to further get your muscle memory going but understanding it first will make that process much more smoother.
Hope this helps and good luck!
as a disclaimer, the Amazon product linked above I receive a small commission if it is purchased using that link at no additional cost to you (:
