Why is Email Analysis needed
Phishing emails persist as one of the primary attack vectors targeting organizations. The Mitre ATT&CK framework https://attack.mitre.org/ categorizes phishing under both Initial Access and reconnaissance techniques. Among the main methods attackers employ to breach organizations, phishing remains the most prevalent:
Phishing
Web application exploits
External remote services (e.g., RDP)
Supply Chain
Attackers continuously adapt and enhance their phishing campaigns. Today, there even exists a concept known as Phishing-as-a-Service (PaaS), enabling hackers to establish sophisticated phishing campaigns for a fee. PaaS is introducing increasingly sophisticated phishing techniques to a wider audience of hackers.
Email Analysis Overview
Email (Phishing) analysis within an example SOC.
Emails enter the organization through the organization's email gateway also known as the Mail Transfer Agent (MTA). More commonly today a cloud email service gateway like O365. Most email gateways possess robust capabilities to block spam and some phishing emails.
In cases where an end-user identifies an email as suspicious (it's important to encourage users to report suspicious emails rather than opening them), your organization should provide a portal or an easy method for users to report such emails as suspicious. These reports can then trigger deeper automated analysis and/or be forwarded to the SOC for awareness and in-depth analysis.
The email analysis process may encompass:
Examination of email message headers
Examination of email content analysis (url links, etc)
Examination of email attachments (e.g., Excel, PDF, etc.) if they are present in the email
Other (sending domain history, email traffic patterns, etc)
Manual versus Automated Email Analysis
Manual methods of email analysis can prove time-consuming. To enhance efficiency, SOCs should automate this process, and robust email gateways should possess the capability to automatically conduct certain analyses to determine an email's verdict (e.g., spam or phishing). This article highlights some of the manual steps involved in email header analysis, in order to provide cybersecurity professionals with a deeper understanding of the email headers.
Email Header Analysis
The email headers are a part of each email, and contain metadata related to the email. Key email header fields include:
Sender
Receiver
Route
Timestamp
In most email clients you can select the dots in the corner of the email software to view the email headers.
Next, choose "View Sources" or "View Headers." If the option is "View Source," it will display the entire email, encompassing the email headers. While it may initially appear as a jumble of random words and characters, this information contains important details about the email.
While some individuals can easily interpret email headers from experience, the majority tend to copy and paste the email header into an email message header analyzer for examination. One of the widely used and freely available email header analyzers on the Internet is called "mxtoolbox." https://mxtoolbox.com/
Email header analyzers serve a dual purpose, being employed not only for cybersecurity analysis but also by email administrators to resolve email delivery and delay issues. In the initial section of the MX Toolbox output, you will find information regarding the sequence of email server hops that processed the email. These email servers are commonly referred to as Mail Transfer Agents (MTAs). The email header should show all the MTAs the email traversed.
Understanding "Sender Policy Framework" (SPF)
The standard email flow adheres to a straightforward process. In a simplified overview of this process, a user utilizes their preferred email client (e.g., Outlook) to compose an email. This email is subsequently dispatched from their email provider's server (MTA) to the intended destination email server.
Because internet routing operates based on IP addresses, the first task for the sending email server (MTA) is to ascertain the IP address of the mail server designated for the email recipient. This is achieved through a specific DNS query to retrieve the IP address of the email server associated with a receiving organization, for instance, an email going to joe@examplecompany.com would look up examplecompany.com. This process is known as a DNS "MX lookup" (MX being an abbreviation for "Mail eXchange").
In brief, the sending MTA forwards the email to the IP address obtained from the MX lookup. This sending MTA, depicted as "Blue Guy's Email Server" in the diagram below, also operates from its own distinct IP address for sending purposes.
At this juncture, everything should be good in the email world; however, unscrupulous individuals often seek to send both malicious emails and spam to specific, targeted companies.
As emails contain sender domains and IP addresses, security tools began to identify and block common IP addresses and URLs associated with spam and malware. Email service providers also initiated the development of reputation-based algorithms. For instance, an email server sending a high volume of emails per hour could be flagged as a potential source of spam. Additionally, newly established email sending domains are initially treated with more scrutiny until they establish a track record of legitimacy over time.
These threat/spam actors then had to devise additional tactics to complete their nefarious hacking goals. Step #1 of getting Phishing and spam emails through email filters and clicked is making them look legitimate. Some strategies for making emails look legitimate include:
Impersonating the sender's information for a legitimate domain.
Hacking into a legitimate sender's email account or email server.
Of these two methods, impersonating the sender's email information is easier to execute.
Thankfully, detecting email impersonations is a more manageable task. To counter the threat of email impersonations, email providers devised unique protection mechanisms. The first of these is SPF, which stands for "Sender Policy Framework." What SPF does is allow senders to include a special TXT record in DNS that outlines the authorized IP addresses responsible for sending emails on behalf of their particular domain. As a result, when a mail server receives an email from that domain, it can conduct a query for the sender's SPF record to cross-reference it with the sending IP address identified in the actual email received from that domain. The SPF check in the received email passes if the IP address of the sending domain's email server matches what's specified in the sending domain's SPF record. Conversely, if there's no match, the SPF check fails.
While SPF is highly effective, there are certain corner cases it doesn't cover. One such instance occurs when emails are forwarded through a mail server.
For more detailed information on SPF, you can refer to this link: https://learn.microsoft.com/en-us/microsoft-365/security/office-365-security/email-authentication-anti-spoofing?view=o365-worldwide
Understanding "DomainKeys Identified Mail" (DKIM)
Where SPF verifies that the sending IP is authorized, DKIM, on the other hand, validates whether the sending server is authorized to send emails. DKIM operates through Public/Private Key cryptography.
DKIM plays a crucial role in ensuring that the sender is authorized to dispatch messages from their domain and that the message remains unaltered in transit. However, it's important to note that DKIM primarily reduces the likelihood of spammers utilizing forged or stolen email addresses.
Nothing prevents hackers/spammers from purchasing a legitimate domain and generating valid SPF and DKIM records for them. However, hackers frequently attempt to impersonate reputable organizations to obtain user credentials, such as the inundation of emails we all see requesting password resets for banks, Google accounts, email services, and more.
Understanding "Domain-based message Authentication Reporting and Conformance" (DMARC)
Lastly there is DMARC, which stands for "Domain-based Message Authentication, Reporting, and Conformance." Organization's setup a DMARC entry for their domain to instruct receivers of emails from their domain (legitimate or spoofed) on what to do if SPF and/or DKIM checks fail when the receiver checks them.
Automated Email Analysis
Asa SOC analyst you want to have a thorough understanding of email header analysis but because it is time consuming your operation should have email analysis as automated as possible.
A main reason why you need to analyze more than just email headers
Hackers often employ a common tactic: compromising the credentials of legitimate users and reputable companies. This is particularly concerning because when an email originates from a genuine company, it tends to bypass automated spam filters and security checks, such as SPF, DKIM, and DMARC.
This underscores the importance of conducting thorough email body and attachment analysis, as well as providing comprehensive user training to thwart email phishing attempts effectively.
Another technique hackers employ involves configuring email auto-forwarding rules on the compromised email accounts. By doing so, they gain control over the communication flow directed toward phishing victims. The result of this email box auto-forwarding manipulation is, the legitimate owner of the email account does not realize that their email account has been compromised.
References
Greta simulation for explaining SPF, DKIM and DMARC https://www.learndmarc.com/
email message trace https://learn.microsoft.com/en-us/exchange/monitoring/trace-an-email-message/message-trace-modern-eac
コメント