by OBJECTIVES COVERED
Given a scenario, analyze data as part of security monitoring activities.
Email remains one of the primary vectors for intrusion and data exfiltration attacks. As an analyst, you should be able to validate that email systems are configured to be as secure as possible and be able to analyze email internet headers and message contents for Indicators of Compromise (IoCs).
EMAIL PHISHING AND IMPERSONATION IOCS
Spam and phishing campaigns are social engineering attacks that use email as the delivery vector. For these campaigns to succeed, the attacker must trick the target into thinking that the message derives from a genuine source. Many phishing attempts are quite easy to spot, but some can be very convincing and difficult for spam filters to block and for users to reject. A campaign targeting a specific individual (spear phishing) might use the results of hours of research against the target. You should be alert to the tactics used by phishers and to the clues that can be used to identify a message from a spoofed or compromised source.
** The term pretexting is often used for an attack that invokes some sort of fictitious scenario made realistic through the use of legitimate details, such as knowing the target’s account number or line manager’s name. **
Impersonation
One email vulnerability is for an attacker to hijack a user’s email account, either through compromising a computer or mobile device, or by hacking a cloud service. This is referred to as business email compromise (BEC). BEC allows the attacker to impersonate the user and attempt further compromises. For example, an employee receives an email from their manager’s account that asks them to share confidential information. The message is uncharacteristic of the manager as it is typed poorly and rife with spelling and grammatical errors. On the surface, this may seem like a standard phishing attempt, but the fact that it appears to be sent by the real account may imply something more. Although email sources can be spoofed, you check the Exchange Server and verify that the very same email message was sent from the manager’s account to the recipient employee. Now the threat is more serious as it appears that the manager’s account has been hijacked and is being used for malicious purposes.
An attacker can also perform an impersonation attack by spoofing a valid sender’s email address or domain. Management in your organization will likely be targeted frequently by attackers looking to steal high-level credentials. Many types of spoofing attempts can be detected by close examination of the Internet headers attached to a message.
Forwarding
Phishing emails will often be formatted to appear to have come as part of a reply or forward chain. When this tactic is used in bulk phishing attempts, it is unlikely to be convincing. As part of a spear phishing campaign where the adversary has access to genuine emails, it may prove more of a threat. Analysis of the Internet headers should resolve the true sender.
EMAIL MESSAGE INTERNET HEADER ANALYSIS
An email’s Internet header contains address information for the recipient and sender, plus details of the servers handling transmission of the message between them, using the fields set out in the Simple Mail Transfer Protocol (SMTP). When an email is created, the mail user agent (MUA) creates an initial header and forwards the message to a mail delivery agent (MDA). The MDA should perform checks that the sender is authorized to issue messages from the domain. Assuming the email isn’t being delivered locally at the same domain, the MDA adds or amends its own header and then transmits the message to a message transfer agent (MTA). The MTA routes the message to the recipient, using DNS to locate the recipient’s MTA, with the message passing via one or more additional MTAs, such as SMTP servers operated by ISPs or mail security gateways. Each MTA adds information to the header.
One structural feature of email headers that is continually exploited is the fact that there are three “sender” address fields:
- Display from—The sender’s email address. This is the field displayed by an email client as the “From” field. It is submitted using a From: header in the message body and officially designated RFC5322.From. This field can be populated by both a “friendly” name string and the email address in angle brackets. Some email clients suppress the display of the email address part. This is bad practice as it makes it hard for the user to identify the source of the message. Frequently, adversaries will enter a trustworthy domain string in the first part, hoping that the mail client will display that rather than the actual address. Compare:
Friendly Guy<friendlyguy@isp.foo>
…with:
friendlyguy@isp.foo<friendlyguy@xyz.foo>
- Envelope from—A return address for use if the email is rejected by the recipient MTA. The value of this field is submitted using the MAIL FROM SMTP command and is officially designated as RFC5321.MailFrom. This field is normally hidden by the mail client. It can take various labels, including return-path.
- Received from/by—A list of the MTAs that processed the email. Each MTA identifies itself and the server that sent it the message. If an adversary is spoofing a domain, the true origin of the message is likely to be revealed by examining this list of servers. A server identifies itself using the HELO/EHLO string when starting a session with another SMTP server.
Headers aren’t exposed to the user by most email applications, which is why they’re usually not a factor in an average user’s judgment. You can view and copy headers from a mail client via a message properties/options/source command. MTAs can add a lot of information in each received header, such as the results of spam checking. If you use a plain text editor to view the header, it can be difficult to identify where each part begins and ends. Fortunately, there are plenty of tools available to parse headers and display them in a more structured format. One example is the Message Analyzer tool, available as part of the Microsoft Remote Connectivity Analyzer (testconnectivity.microsoft.com). This will lay out the hops that the message took more clearly and break out the headers added by each MTA. You can also implement software that inspects headers and triggers an alert if the headers match known malicious values.
The following example shows the headers from a spam message. Some of the fields have been removed and some of the original identifying information redacted and replaced with placeholders:
Received: from protection2.outlook.com (2603:10a6:208:ac::18) by exchangelabs.com with HTTPS ; Tue, 24 Dec 2019 19:30:08 +0000
Received: from protection1.outlook.com (10.152.16.53) by protection2.outlook.com (10.152.17.88) with Microsoft SMTP Server ; Tue, 24 Dec 2019 19:30:08 +0000
Authentication-Results: spf=none (sender IP is w.x.y.z) smtp.mailfrom=spam.foo; hotmail.com; dkim=none (message not signed) header.d=none;hotmail.com; dmarc=none action=none header.from=spam.foo;
Received-SPF: None (protection.outlook.com: spam.foo does not designate permitted sender hosts)These fields show the receipt of the email by the recipient’s mail gateway, which performs analysis on it. The sender’s domain is identified as spam.foo.
Received: from openrelay.foo (w.x.y.z) by protection1.outlook.com (10.152.16.89) with Microsoft SMTP Server ; Tue, 24 Dec 2019 19:30:06 +0000This field shows the SMTP server that originated the message. It comes from a different domain than spam.foo. The openrelay.foo domain and IP address is on many mail blacklists.
Subject: Your account is blocked by the administrator
Content-Transfer-Encoding: 7bit
Content-Type: text/html; charset="UTF-8"; format=flowed; delsp=yes
Date: Wed, 25 Dec 2019 06:30:07 +0000
MIME-Version: 1.0
From: Gmail Accounts <spammer@spam.foo>
To: recipient@hotmail.com
Return-Path: spammer@spam.fooThe from and return-path fields list the same sender address, but note the attempt to disguise the nature of the sender by impersonating a Gmail account administrator.
X-MS-Exchange-Organization-Expiration StartTime: 24 Dec 2019 19:30:07.8963 (UTC)
X-MS-Office365-Filtering-Correlation-Id: ca0b527c-0b59-4085-cfc2-08d788a7af58
X-Sender-IP: w.x.y.z
X-SID-PRA: SPAMMER@SPAM.FOO
X-Microsoft-Antispam: BCL:8;
X-MS-Exchange-Organization-SCL: 6The X- headers indicate custom headers that are controlled by the SMTP server administrator. They are often used for message authentication and spam analysis, in this case by Microsoft (docs.microsoft.com/en-us/microsoft-365/security/office-365-security/anti-spam-message-headers).
EMAIL MALICIOUS CONTENT ANALYSIS
While spoofing and impersonation techniques are used to convince a victim to act on a message, the attacker must also craft some sort of payload to complete the exploit. The body of an email uses Multipurpose Internet Mail Extensions (MIME) to support different formats, such as HTML and rich text format (RTF), plus the inclusion of files. Binary data is translated to Base64 encoded ASCII text characters (lifewire.com/base64-encoding-overview-1166412).
Malicious Payload
A malicious payload is some sort of code implemented within the message body. There are two main types of malicious payload:
- Exploit—The message data contains scripts or objects that target some vulnerability in the mail client, such as incorrectly processing RTF or HTML-based messages, image files, or S/MIME digital signatures. In some cases, these may be activated via the email client’s preview feature. It is important to keep email client applications up to date with the latest patches.
- Attachment—The message contains a file attachment in the hope that the user will execute or open it. The nature of the attachment might be disguised by formatting tricks such as using a double file extension (of the form file.pdf.exe).
Embedded Links
As users are slightly less likely to open suspicious attachments these days, another popular vector is to embed a link to a malicious site within the email body. As with email sender addresses, a link can be composed of a friendly string plus the URL. Most mail applications should display the full URL of the link rather than just the friendly string, which can assist the user in diagnosing whether to trust it or not. However, the best advice is never to use links from email messages. Even if the user trusts the communication, they should still locate the site referred to manually via the browser.
It is also possible to construct links that will perform an exploit against some local vulnerability in the email client application or the underlying OS (fireeye.com/blog/threat-research/2019/12/breaking-the-rules-tough-outlook-for-home-page-attacks.html).
Email Signature Block
A missing or poorly formatted email signature block is an indicator for a phishing message. Conversely, spear phishing might have obtained samples of a company’s signature block and constructed a convincing facsimile. This might be used to embed malicious links and incorrect or hacked contact details.
EMAIL SERVER SECURITY
Some types of spoofing attacks can be mitigated by configuring authentication for email server systems. Essentially, these work by publishing records on a DNS server that identify messaging servers authorized to send email for the domain.
Sender Policy Framework (SPF)
Sender Policy Framework (SPF) uses a DNS record published by an organization hosting email service. The SPF record—there must be only one per domain—identifies the hosts authorized to send email from that domain. The authorized mail servers can be identified by IP address, CIDR address blocks, or by hostnames. An SPF can also indicate what to do with mail from servers not on the list, such as rejecting them (-all), flagging them (~all), or accepting them (+all). For example, the following record restricts authorized hosts to those identified in MX records in the host domain and the securemailprovider.foo domain:
TXT @ "v=spf1 mx include:_spf.securemailprovider.foo -all"The receiving server can be configured to perform SPF-checking. To do this, it uses the domain identified in the envelope return header field (return-path) to look up the SPF record, and then processes the email according to whatever local rules have been configured.
DomainKeys Identified Mail (DKIM)
DomainKeys Identified Mail (DKIM) provides a cryptographic authentication mechanism. This can replace or supplement SPF. To configure DKIM, the organization uploads a public key as a TXT record in the DNS server. When outgoing email is processed, the domain MTA calculates a hash value on selected message headers and signs the hash using its private key. The hash value is added to the message as a DKIM signature, along with the sequence of headers used as inputs for the hash, the hash algorithm, and the selector record, to allow the receiving server to locate the correct DKIM DNS record.
The receiving MTA looks up the DKIM DNS record, obtains the public key, and uses it to decrypt each hash. It calculates its own header hash and compares the two. If they match, the message origin has been authenticated.
Optionally, the MTA can also calculate a message body hash. This provides an integrity check mechanism to show that the message contents have not changed in transit.
Domain-Based Message Authentication, Reporting, and Conformance (DMARC)
The Domain-Based Message Authentication, Reporting, and Conformance (DMARC) framework ensures that SPF and DKIM are being utilized effectively. A DMARC policy is published as a DNS record. It specifies an alignment mechanism to verify that the domain identified in the rule header from field matches the domain in the envelope from field (return-path) in an SPF check and/or the domain component in a DKIM signature. DMARC can use either SPF or DKIM or both. DMARC specifies a more robust policy mechanism for senders to specify how DMARC authentication failures should be treated (flag, quarantine, or reject), plus mechanisms for recipients to report DMARC authentication failures to the sender. Recipients can submit an aggregate report of failure statistics and a forensic report of specific message failures.
Cousin Domains
SPF, DKIM, and DMARC do not solve the problem of cousin or look-alike domains. These are domain names or domain name parts that closely resemble an organization’s real domain. Phishers will also exploit the fact that many organizations use hosted email services, especially for business tasks like marketing and customer service and support ticketing. When official emails arrive from domains such as support@realcompany.serviceprovider.foo, it makes it much easier for a phisher to succeed with an impersonation attack using an email address such as support@reelcompany.serviceprovider.foo or support@realcompany.srviceprovider.foo.
SMTP LOG ANALYSIS
When investigating suspected email abuse, you will also frequently need to inspect SMTP logs. SMTP logs are typically formatted in request/response fashion: the local SMTP server sends a request to the remote SMTP server to open a port for communications. The remote SMTP server responds and, if successful, the local server begins forwarding the client’s message. The logs at this point typically record the time of request/response, the address of the recipient, and the size of the message.
Another component of an SMTP log entry is the status code. Status codes indicate a remote server’s acceptance or rejection of a request or message. For example, the remote server may send code 220 after a request, indicating that the server is ready. After the local server provides the message information, the remote server responds with code 250 to indicate that the message itself is accepted.
Likewise, you can use SMTP logs to collect errors in transmissions that may indicate insecure email activity. Code 421 in a remote server’s response indicates that the service is not available, and codes 450, 451, and 452 each indicate different issues with sending the actual message. Repeated failure entries like these could be the sign of a DoS condition on either the remote or local SMTP server.
In the following example, the server hosting 515support.com receives a message from the server at smtp.openmail.foo with the IP address 192.168.2.192. Note that this server is relaying a message for a sender in the domain bitminer.foo. Using a mail security gateway would help to filter these kinds of phishing attempts before they reach users’ inboxes.
** For a full list of SMTP reply codes, navigate to serversmtp.com/smtp-error. **
EMAIL MESSAGE SECURITY AND DIGITAL SIGNATURES
Server security and email authentication architecture go a long way toward preventing the compromise of email accounts and the spoofing of email, but there is still a need for message authentication and confidentiality in many scenarios. One means of doing this is called Secure/Multipurpose Internet Mail Extensions (S/MIME). S/MIME can be used to add a digital signature to a message and optionally to encrypt the message contents.
To use S/MIME, the user is issued a digital certificate containing his or her public key, signed by a certificate authority (CA) to establish its validity. The public key is a pair with a private key. The private key part must be kept secret by the user. To establish the exchange of secure emails, both users must be using S/MIME and exchange certificates. In this example, Alice is the sender of a message and Bob is the intended recipient.
- Alice sends Bob her digital certificate, containing her public key and validated digital ID (distinguished subject name and email address). She signs this message using her private key.
- Bob uses the public key in the certificate to decode her signature and the signature of the CA (or chain of CAs) validating her digital certificate and digital ID and decides that he can trust Alice and her email address.
- He responds with his digital certificate and public key and Alice, following the same process, decides to trust Bob. Both Alice and Bob now have one another’s certificates in their trusted certificate stores.
- When Alice wants to send Bob a confidential message, she makes a hash of the message and signs the hash using her private key. She then encrypts the message, hash, and her public key using Bob’s public key and sends a message to Bob with this data as an S/MIME attachment.
- Bob receives the message and decrypts the attachment using his private key. He validates the signature and the integrity of the message by decrypting it with Alice’s public key and comparing her hash value with one he makes himself.
The mail client will indicate a valid digital signature with an icon and an untrusted signature with a cross or similar motif. A signature may be untrusted because the sender’s certificate and root certificate have not been added to the mail client’s trusted certificate store. A certificate may be rejected because it has not been issued for the purpose of digital signing. If the sender certificate is present, the email may have been tampered with in transit.
Front of Flashcard 1 of 3
Which framework assures the most comprehensive spoofing mitigation for email services?
Back of Flashcard 1 of 3
The Domain-based Message Authentication, Reporting, and Conformance (DMARC) framework ensures that Sender Policy Framework (SPF) and Domain Keys Identified Mail (DKIM) are being utilized effectively. It also provides a reporting mechanism.
Front of Flashcard 2 of 3
On what type of server(s) are spoofing mitigation records for common frameworks published?
Back of Flashcard 2 of 3
Records for Sender Policy Framework (SPF), Domain Keys Identified Mail (DKIM), and Domain-based Message Authentication, Reporting, and Conformance (DMARC) are all published to DNS servers.
Front of Flashcard 3 of 3
Is any other type of server other than SMTP required to implement S/MIME?
Back of Flashcard 3 of 3
Secure/Multipurpose Internet Mail Extensions (S/MIME) requires that the user is issued with a digital certificate containing his or her public key, signed by a certificate authority (CA) server.