Malicious Email Mitigation Strategy Guide

CYBER SECURITY OPERATIONS CENTRE Malicious Email Mitigation Strategy Guide Introduction (UPDATED) SEPTEMBER 2012 1. Socially engineered emails containing malicious attachments and embedded links are commonly used in targeted cyber intrusions against Australian government networks. This document provides guidance on mitigating these malicious emails using DSD s Strategies to Mitigate Targeted Cyber Intrusions. 2. This document is intended for use by Information Technology Security Advisors and email system administrators. It should be read in conjunction with the advice on email security and content filtering contained in the Australian Government Information Security Manual (ISM). 3. The mitigations in this document are ranked within categories in order of the overall security effectiveness of the mitigation, from most to least effective. Further information on these mitigation strategies can be found at Attachment A. Email attachment filtering 4. Attachments are a significant security risk associated with emails. Effective email attachment filtering and restrictions reduce the likelihood of malicious content entering the network. The key security considerations associated with email attachment filtering are discussed below. Convert attachments to another file type 5. Converting a document to another format is a highly effective method of removing malicious content or rendering it ineffective. For example, Microsoft Office documents are converted to PDF and delivered to the user. A release facility should be available for selected blocked emails in case the original is required for editing purposes. Allowing attachments based on file typing (Whitelisting) 6. File typing inspects the content of the file to determine the file type rather than relying on the extension as an indicator. File extensions can be changed and therefore a mismatch between a file s type and its stated extension should be treated as suspicious and blocked. DSD recommends whitelisting file types with a legitimate business purpose. Whitelisting is more proactive and thorough than blacklisting as it ensures only specified files can be received, while all others are blocked. Page 1 of 6

Block password protected archives, unidentifiable or encrypted attachments 7. Content within a protected archive cannot be inspected since the email filter cannot decrypt the archive. Any protected archive or otherwise encrypted attachment should be blocked until such time as it can be deemed safe to allow through to the user. Unidentifiable content is less of a threat if effective file typing and whitelisting of email attachments is used. Sanitise attachments to remove active or potentially harmful content 8. Active content, such as macros and JavaScript, should be removed from within the document before being delivered to the user in the same way that active content should be removed from the email body. Active content removal can be completed by products such as Exchange Defend PDF which will detect a PDF document, scan the document for undesirable active content based on keywords, and rewrite those elements in the document rendering them inert. Complete and comprehensive sanitisation of an attachment is a difficult process. For this reason, the preferred solution is file conversion. Controlled inspection of archive files 9. Archived files can be used to bypass email filters, for example, if an adversary crafts a malicious PDF and places it in an archive file and sends the archive file to the target. The contents of an archive file should be subjected to the same level of inspection as un archived email attachments. Archived content should be inspected in a controlled manner to avoid archive file associated exploits, such as directory traversals and denial of service via archive directory recursion. Scan attachments using antivirus software 10. Attachments should be scanned using CLASSIFICATION up to date signatures, reputation ratings and other heuristic detection capabilities. To maximise coverage, use a product provided by a different vendor than the desktop antivirus product. Ensure that the anti virus software is up to date. Block attachments based on file typing (Blacklisting) 11. Blacklisting attachments based on file typing is far less proactive and thorough than whitelisting attachment types, and the overhead of maintaining a list of all known bad file types is far greater. Allow attachments based on extension (Whitelisting) 12. Allowing attachments based on file extension is less robust than file typing as the extension can be trivially changed to disguise the true nature of the file (for example, renaming readme.exe to readme.doc). Only file extensions with a legitimate business purpose should be whitelisted. Block attachments based on extension (Blacklisting) 13. Blacklisting attachments based on their extension is less proactive and thorough than whitelisting. Blocking based on file extension is less robust than file typing as the extension can be trivially changed to disguise the true nature of the file (for example renaming readme.exe to readme.doc). Page 2 of 6

Email body filtering 14. Email content filtering performed on the body of an email helps provide a defence in depth approach to email filtering. The possible attack surface presented by the body of an email is less than email attachments; however, it can be used for malicious communications. The key security considerations associated with filtering the body of an email are discussed below. Replace active (live) web addresses in an email s body with non active versions 15. An active web address allows the user to click directly on the hyperlink and be taken to a specified website. Active web addresses can appear to be safe but can actually direct the user to an unintended location. Hovering over the address will reveal the actual location, as shown here: 16. Active web addresses should be replaced with the actual location of the link, otherwise they should be replaced with text so that the user must copy and paste the link into their browser. Enforce protective markings on the email body or subject line 17. Protective markings should be enforced to ensure that the content being sent and received in an email is appropriately classified to traverse the network. Enforcement of protective markings on emails helps to minimise the number of data spills and the exfiltration of data from the network via email. Decode and inspect encoded content in an email s body 18. Encoded content can be used to hide malicious or command and control communications originating from the network or intended for the network. For example a command to an implant can be encoded and inserted into the email s body. A content filter should inspect the email body for encoded content after decoding the email body according to the MIME Content Transfer Encoding header. If encoded content is detected the email should be blocked. Remove active content from an email s body 19. Emails with active content such as VBScript or JavaScript pose a threat if the email client is capable of running the active content. Email bodies containing active content should be sanitised to minimise the risk, however, the risk posed by active content is minimal because only a small number of email clients have the option to execute active content. Page 3 of 6

Domain authentication 20. Being able to verify the authenticity and integrity of an email can stop an agency from receiving some forms of malicious emails. The key controls for authenticating the domain of an email are discussed below. Block email on SenderID/SPF hard fail 21. Checking the SenderID will verify the email as originating from the domain it claims to originate from. Checking the SenderID allows an agency to block the email if the checks fail. An SPF hard fail occurs when an email is received which has been verified as not originating from the domain it claims to originate from. SPF hard fails should be blocked and investigated. An SPF hard fail can indicate a phishing attempt, especially if the failed message is spoofed to appear to come from a legitimate domain. Block email on DKIM fail 22. DomainKeys Identified Mail (DKIM) is a method of verifying the sender s domain of an email using the signatures provided by the sending domain. When an email fails DKIM verification, the email should be blocked and investigated. This should also be logged and potentially reported to the organisation that the email was claiming to originate from. Block email on SenderID/SPF soft fail 23. Checking the SenderID will verify the email as originating from the domain it claims to originate from. Checking the SenderID allows an agency to block the email if the checks fail. An SPF soft fail occurs when an SPF enabled domain cannot guarantee that the email was sent from an authorised server of that domain. When an SPF soft fail is encountered, the email should be blocked with the option of being able to retrieve it if it is a legitimate email. Flag email on SenderID/SPF soft fail 24. As above, except instead of blocking the email, the email should be marked before being sent to the user to allow the user to make a decision as to whether they will accept (trust) the message or not. For example, the subject line of the email could be modified to highlight and identify to the user that the email did not pass the SPF checks. Incorporate spam blacklists 25. Known spam email senders and addresses can be blocked without the email being examined. Additional email filter functionality 26. The focus of this document is security controls to reduce the risk of compromise of the network or the information it holds. However, the following functionality will make an email content filter, or management of it, more effective. Page 4 of 6

a. Logging and auditing. Logging of actions and events from the email filter should be implemented, and these logs should be audited. Effective logging and auditing will help in the event of a current or past security incident. b. Minimal overhead for an administrator to release blocked content. This will allow an administrator to easily release content for a user when that content has been blocked. The administrator needs to be able to see why the email was blocked to determine if the email or content should be allowed through to the user. c. User self release of email (based on blocked reason). This will allow the user who has had an email blocked the ability to request to have the email released without needing to go through the administrator. This option should only be available for selected blocked emails based on the control triggered. All email self releases should be logged for auditing purposes. Further information 27. The Australian Government Information Security Manual (ISM) assists in the protection of official government information that is processed, stored or communicated by Australian Government Systems, and is available at: http://www.dsd.gov.au/infosec/ism/index.htm. 28. Strategies to Mitigate Targeted Cyber Intrusions and other DSD products are available on DSD s public website and OnSecure, and complement the advice in the ISM. These products can be found at: http://www.dsd.gov.au/publications/index.htm. 29. For further information on email protective markings, please refer to the Email Protective Marking Standard for the Australian Government produced by the Australian Government Information Management Office: http://www.finance.gov.au/e government/security andauthentication /authentication identity.html. 30. For further information on Sender Policy Framework, please refer to Mitigating Spoofed Emails Sender Policy Framework Explained which can be found at: http://www.dsd.gov.au/publications/csocprotect/spoof_email_sender_policy_framework.html Contact details Australian government customers with questions regarding this advice should contact the DSD Advice and Assistance Line on 1300 CYBER1 (1300 292 371) or dsd.assist@defence.gov.au. Australian businesses or other private sector organisations seeking further information should contact CERT Australia at info@cert.gov.au or by calling 1300 172 499. Page 5 of 6

Attachment A: Summary of email mitigation strategies Attachment Filtering Mitigation Strategy Overall Security Effectiveness User Resistance Upfront Cost (Staff, Equipment, Technical Complexity) Maintenance Cost (Mainly Staff) Designed to Prevent or Detect an Intrusion Helps Mitigate Intrusion Stage 1: Code Execution Helps Mitigate Intrusion Stage 2: Network Propagation Convert attachments to another file type Excellent Medium* Medium Medium* Prevent Yes No No Allow attachments based on file typing (Whitelisting) Excellent Medium Medium Low Prevent Possible No Yes^ Block password protected archives, unidentifiable or encrypted attachments Excellent Medium Medium Low Prevent Yes No Yes Sanitise attachments to remove active or potentially harmful content Excellent Medium* High Medium* Prevent Yes No No Controlled inspection of archived files Good Low Medium Low Both Yes No Yes Scan attachments using antivirus software Good Low Low Low Both Yes No No Block attachments based on file typing (Blacklisting) Average Low Low Medium Prevent Yes No Yes^ Allow attachments based on extension (Whitelisting) Minimal Medium Low Low Prevent Possible No Yes^ Block attachments based on extension (Blacklisting) Minimal Low Low Medium Prevent Yes No Yes^ Email Body Filtering Replace active (live) web addresses within an email s body with non active versions Good Low Medium Low Prevent Yes No No Enforce protective markings on the email body or subject line Minimal Low High Low Detect No No Yes Remove active content from an email s body (e.g. JavaScript, VBScript) Minimal Low Medium Low Prevent Yes No No Domain Authentication Block an email on SenderID/SPF hard fail Excellent Low Low Low Prevent Possible No No Block email on DKIM fail Excellent Low Low Low Prevent Possible No No Block email on SenderID/SPF soft fail Good Medium Low Low Prevent Possible No No Flag email on SenderID/SPF soft fail Average Low Low Low Prevent Possible No No Incorporate spam blacklists Average Low Low Low Both# Possible No No Mitigations are ranked in categories based on the overall security effectiveness. *Potentially lower if document release is easy. #If the mitigation is applied to both incoming and outgoing emails, then this is Both otherwise, just Prevent. ^Provided the attacker is attempting to exfiltrate a file type that is blocked. Helps Mitigate Intrusion Stage 3: Data Exfiltration Page 6 of 6