Socially engineered emails containing malicious attachments and embedded links are routinely used in targeted cyber intrusions against organisations. This document has been developed to provide mitigation strategies for the security risks posed by these malicious emails.
Not every mitigation strategy within this document will be suitable for all organisations. Organisations should consider their unique business requirements and risk environment when deciding which mitigation strategies to implement. Furthermore, before any mitigation strategy is implemented, comprehensive testing should be undertaken to minimise any unintended disruptions to the organisation’s business.
The mitigation strategies, and implementation considerations, are summarised in Appendix A.
This document uses the terms ‘block’ and ‘quarantine’. In the context of this document, ‘block’ refers to preventing an email reaching the user and being removed from the mail server while ‘quarantine’ refers to preventing an email from reaching the user but safely storing it so it can be accessed if required.
Attachments are a significant security risk associated with emails. Effective attachment filtering reduces the likelihood of malicious content reaching a user’s workstation. Mitigation strategies associated with attachment filtering are discussed below.
Converting attachments to another format is a highly effective method of removing malicious content or rendering it ineffective, for example, by converting Microsoft Office documents to PDF documents. To decrease the impact to users, but at the expense of an increased security risk, original emails and attachments can be quarantined with a release facility available in case the originals are required for editing purposes.
File typing inspects the content of a file to determine its file type rather than relying on its extension. Only file types that have a legitimate business purpose and an acceptable risk profile for organisations should be allowed. As file extensions can be changed, a mismatch between a file’s type and its stated extension should be treated as suspicious and quarantined.
Content within password protected archives can’t be trusted since email content filters can’t decrypt and inspect their contents. Any protected archive or otherwise encrypted attachments should be blocked until such time that they can be deemed safe. Unidentifiable content is less of a security risk if only allowing attachments based on file typing. Where organisations have corporately approved encrypted email communications, such as S/MIME or PGP, these can be allowed to prevent disruption to legitimate business.
Active content, such as macros in Microsoft Office files and JavaScript, should be removed from within attachments before being delivered to users. This should include embedded content such as an executable placed inside a Microsoft Word document, embedded Flash content placed inside a Microsoft Excel spreadsheet and link (LNK) files that call executable content, which should include executable content on the end user’s computer such as mshta.exe and rundll32.exe. Organisations should also consider cases where active content creates a high level of suspicion due to limited legitimate use; in these cases the attachment should be blocked.
Active content removal products should scan attachments for undesirable active content based on keywords or heuristics, and rewrite those elements rendering them inert. Complete and comprehensive sanitisation of an attachment is a difficult process.
An increase in the use of macros in Microsoft Office files being used as a malware delivery vector has been observed. These macros are written in the Visual Basic for Applications (VBA) programming language, a feature built into Microsoft Office applications. Macros are commonly used for task automation; however, adversaries are also using macros to perform a variety of malicious activities including the download and execution of malware on the host computer.
Organisations should configure Microsoft Office to disable all macros by default and only run macros vetted as trustworthy and placed in ‘trusted locations’ which typical low-privileged users can’t write to.
Archive files can be used to bypass poorly configured email content filters. By placing a malicious file in an archive file and sending it to the target, the archive file might bypass content filtering checks. To mitigate this, the contents of archive files should be subjected to the same level of inspection as un-archived attachments. The archive files should be decompressed and the files within inspected. A directory listing of the files inside an archive file is not always an accurate representation of the files actually in the archive file since file attributes, such as file name, could be stored in two places for each file.
Archived content should be inspected in a controlled manner to avoid exploits associated with archive files, such as directory traversal and denial of service via recursion. For example, a text file which is 1GB in size and consists only of spaces, could compress to 1MB but consume significant computing resources when it is processed by an email content filter. As another example, a zip file containing 16 zip files, each of which contain 16 zip files, each of which contain 16 zip files etc. to a depth of 5, could cause an email content filter to process over one million files. To mitigate this, quotas and timeout values can be used on CPUs, memory and disks so that decompression is blocked or failed if it takes longer than the specified time or uses excessive computing resources.
Archive files decompress starting from the end of the file, stopping when all the files have been extracted. As a result of this an archive file can be appended to the end of a legitimate image file and still be a valid archive from which files can be extracted. In this case, depending on the file type checking, the file could pass file type checks as an image. This behaviour can be exploited by adversaries to avoid controlled inspection of archive files. To mitigate this, organisations should attempt to decompress all attachments, with all decompressed files submitted to the security controls for attachments and the original attachment blocked if any decompressed files fail.
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, by renaming readme.exe to readme.doc. Only file extensions with a legitimate business purpose should be allowed.
Blocking attachments based on file typing is less proactive and thorough than allowing attachments based on file typing or file extension, and the overhead of maintaining a list of all known bad file types is far greater than maintaining a list of all known good file types.
Attachments should be scanned using vendor supported antivirus software with up-to-date signatures, reputation ratings and other heuristic detection capabilities. To maximise the chance of detecting malicious content, antivirus software from a different vendor to that used for user workstations should be used.
Blocking attachments based on file extension is less proactive and thorough than allowing attachments based on file typing or file extension. Blocking 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, by renaming readme.exe to readme.doc.