For the final blog post in our series on lessons learned from 2016 security assessments, we’ll discuss a high-risk issue our penetration testers and consultants often come across: filtering malicious emails. In our assessments, sending phishing emails with malicious payloads or links is the most common method we use to get initial access to a network. Email is one of the few vectors that gives us direct access to end users. Overall, there is a much higher chance a single user will unwittingly click on a malicious link or open a harmful attachment than fall for other methods we use to try to compromise them. However, this is predicated on those malicious emails successfully making it to the end user’s inbox.
Many security teams believe their email filtering appliances are the first line of defense, and the user is the last line of defense when it comes to stopping phishing. In our experience, security teams end up relying on end users to be the “catch-all” for malicious emails, instead of attempting to make it more difficult for a malicious email to make it to a user in the first place.
Baseline Protection: Scans and Sandboxing
Most commercial grade email appliances offer some basic scanning or sandboxing to make sure emails are “safe enough” to be delivered to end users. However, skilled attackers are always prodding and testing to find ways to bypass these security measures and get malicious payloads, or links to malicious payloads, past them. As a first step, a well-trained security team should know the capabilities and gaps of its mail server defenses. By examining your organization’s own defensive capabilities, you can identify and fix weak spots. This means knowing what steps your mail appliance is taking to analyze emails, and how it decides to deliver them to end users or not.
One cause of malicious payloads ending up in users’ inboxes stems from a sandboxing device failing to classify the payload as malicious. Specifically, devices run the payloads in a “safe” environment to see what they do (i.e., call out to domains, attempt to download files, attempt to inject code into other processes). The classification process is usually when security professionals have the least visibility into how their appliance is working. This is an area you should look at closely when evaluating your network defenses. In our experience, sandboxes will run a minimal number of tests to determine if the attachment is considered malicious.
Evading Mail Server Defenses
Given enough time, we can typically find ways around these tests and trick the sandbox into categorizing our payload as benign. For example, some sandboxes may only run a payload for a short period of time, so they can be bypassed by simply adding a “sleep” statement into the beginning of our code.
One of our preferred methods – and of threat actors – is delivering malicious payloads to an end-user by attaching a malicious MS Office document with an embedded Object-Link Embedded (OLE) payload. The “OLE” payload has become a very common phishing technique. While some email appliances detect the presence of the OLE objects, and can inspect them to see if they’re malicious, not all are blocked at the mail appliance and are thus delivered to end users.
The end user experience of opening the attached MS Office document might look something like this:
The embedded file at the bottom is disguised to look like a .docx file, but is actually a batch file that will run code of our choosing when the employee double-clicks the icon. Frequently, the script or object is surrounded by textthat encourages the user to click or interact with it.
Although the malicious Word document with an embedded OLE object works for our assessments, it requires several clicks from the user before the payload is executed. Another option we have is sending the user an email containing a link to an HTLM Application (.hta file). We configure the HTA file to execute malicious vbscript code. If the user clicks on our link using either Chrome or Firefox, this file will be downloaded and the user must manually open it to run our payload. However, if the user opens our link using Internet Explorer, which many organizations still use, the user will be immediately prompted to open the file. If the file is clicked, the user will be presented with a warning about executing code from the HTA file.
We find that many users click past this warning, which grants us control of their workstation in the user context of whoever clicked the link. Many commercial and open source penetration testing tools are now incorporating HTA creation as part of their attack flow such as Metasploit and Powershell Empire.
Summary and Recommendations
Our pen testers have been using both approaches for the past few years, and we’re just starting to see some organizations detecting or blocking these payloads from being delivered to users. The situations in which the payload makes it through is always a result of the defensive security stack failing to prevent the blocking of the email and its payload.
A good approach to defending such attacks is to have insight into how your security department filters and scans for malicious emails and potential vulnerabilities. If you’re using a third-party solution for email filtering, make every effort to have some level of recourse with your vendor to submit suspected malware samples for manual review when needed. And as always, be sure your users are trained to recognize, report, and not open any suspicious emails nor click on any links or attachments within them, even if they appear to come from a legitimate source.
This concludes our blog series, and we hope you’ve found it informative and thought-provoking. Catch up on the first five blogs in our series, and learn more about our penetration testing services and penetration service teams.