A new attack method bypasses both Microsoft 365 default security (EOP) and advanced security (ATP). At the time of writing, Microsoft 365 is still vulnerable and the attack is still being used extensively against Microsoft 365 customers.

This week, Avanan’s Security Analysts detected a significant increase in the usage of .slk files in attacks against Microsoft 365 customers. In this attack, hackers send an email with an .slk file attachment that contains a malicious macro (MSI exec script) to download and install a remote access trojan.

It is a very sophisticated attack with several obfuscation methods specifically designed to bypass Microsoft 365. More details below.

Gmail customers are safe from this attack - Google blocks it on incoming email and makes it impossible to send them as an attachment from a Gmail account.

What should I do?

If you are an Avanan customer and in Protect (Inline) mode, this attack is blocked and users will not see them in their inbox. If you are in Monitor Mode, we recommend that you move to Protect (Inline) mode.

Alternatively, we recommend you configure your Office 365 account to reject files of this type. SLK files are relatively rare, so unless you have a legacy reason to allow them, we recommend excluding the SLK extension as a static mail-flow rule, at least until Microsoft fixes this gap.

Microsoft’s recommendations are much more complicated, but are another alternative to protect the desktop.

About the SLK File Attack

SLK files are rare. If you have received one in your inbox, chances are you are being targeted by the most recent Remote Access Trojan malware that has been ‘upgraded’ to bypass Advanced Threat Protection. The attack method itself has been extensively documented, so I’ll only explain it briefly. The focus will be on how such a well-understood attack bypassed Office 365 filters, including ATP.

The attack specifically targets Microsoft 365 accounts and until recently, was isolated to a small number of organizations. This has changed.

Emails are Targeted and Manually Created

The attack emails are highly customized, using information and language that could only have been found and written manually. The messages seem to come from a partner or customer using a topic that is highly specific to the organization and the individual. For example, an email to a manufacturer will discuss parts specifications, an email to a tech firm ask for changes to a large electronics order while an email to a government department will discuss legal concerns. The subjects, contents and even the attached files are customized with the target’s name and organization. No two are alike. What they have in common is that the messages are realistic and compelling enough to convince a user to click on the attached SLK file.

What is a SLK file?

A so-called “Symbolic Link” (SLK) file is Microsoft’s human-readable, text-based spreadsheet format that saw its last update when Dallas went off the air in 1986. At a time when XLS files were proprietary, SLK was an open-format alternative before XLSX was introduced in 2007. To the end-user, a SLK file looks like an Excel document. For the attacker, it is an easy way to bypass Microsoft 365 security, even for accounts protected with Advanced Threat Protection.

David Williams of V&C Inc.slk

What does this attack do?

This week’s version of the SYLK attack includes an SLK file with an obfuscated macro to run a command on a Windows machine:

This runs Windows Installer (msiexec) in quiet mode to install whatever MSI package they decide to host on their site. In this campaign, it is a hacked version of the off-the-shelf NetSupport remote control application, granting the attacker full control over the desktop.

Windows Grants More Trust to SLK Files than XLSX Files

Because Windows “Protected View” does not apply to SLK files downloaded from the Internet or from email, Excel does not open them in read-only mode.

When opening an SLK file, the end-user does not see this message:

Targeted Methodology to bypass Advanced Threat Protection

The first versions of the SLK attack method were seen in 2018 and were eventually blocked by Microsoft Advanced Threat Protection (ATP). This new campaign, however, includes a number of obfuscation techniques specifically designed to bypass ATP.

• The attack was sent from hundreds of free hotmail accounts
• The macro script includes ‘^’ characters to confuse ATP filters.
• The URL was split in two so that ATP would not read it as a web link,
• The hosting server became active after the email was sent so it seemed benign if sandboxed by ATP,
• The hosting server only responded to “Windows Installer” user agents, ignoring other queries.

These methods are ATP-specific. Gmail blocks these files and, in fact, makes it impossible to send from a Gmail account.

The attackers took advantage of a series of blind spots in the Microsoft email infrastructure.

The attack was sent from thousands of hotmail accounts.

All of the emails were sent from disposable email addresses of the format “randomwords1982@hotmail.com”, each sending just a handful or messages at a time.

An important benefit of hotmail to many attackers is that the same security filters are being used end to end. If the attacker is able to attach and send a file, it is likely that it will make it through the entire Microsoft security infrastructure. Should one of the accounts get flagged, Microsoft will disable it, informing the attacker that his messages are getting caught downstream.

While most of the well-known anonymous email sending engines deserve their poor spam and phishing reputations, Hotmail users benefit from Microsoft’s own reputation. Since the service was merged with its own Outlook application, Microsoft seems to grant them a higher level of trust than external senders.

The macro script includes escape characters to confuse ATP filters

The attackers take advantage of the fact that ATP filters do not interpret text in the same way as the Windows command line. ATP would normally be able to identify the powerful and potentially malicious msiexec command but the attackers inserted command-line escape characters ‘^’ to obfuscate the script.

becomes

When read by Advanced Threat Protection filters, the msiexec command becomes unreadable and the tell-tale ‘http://’ is obscured.

When read by the desktop command line, the escape characters ‘disappear’, running as if they were never there. This is just a command-line version of the Zero-Font methodologies that have plagued ATP for years.

The URL was split into two macros so that ATP would not read it as a link

ATP does not need to see the ‘http://’ to recognize a web link, and would normally catch any text of the format ‘malicious-site.com’. In order to hide the link, the attackers split it into two separate commands.

The first macro command creates a batch file with the first half of the URL.

The second macro command adds the remainder of the URL and then runs the batch file.

Within seconds, the malicious SLK file has run two simple commands to create a malicious install script and begin installing whatever software the attackers decide to host.

The hosting server was armed after the message was sent

We don’t believe ATP is testing these files within their sandbox environment, relying on static filters, but we have found that other vendors have also failed to catch this attack, even when the code is executed in a virtual environment.

There is no special code or intelligence within the script to detect if it is running within emulation. Instead the attackers do not enable the malicious web server until shortly after the email is sent. Because it cannot reach the server, the script fails, installing nothing.

In addition to enabling the URL only after delivery, the server would become inactive a few hours later, rejecting further queries. This seems to be a way to avoid action from their provider as "the reported content is no longer available at the links associated with" the attack by the time a manual take-down notice is requested. 

The coordinated timing of the hosting servers with the sending of the emails suggests a more sophisticated campaign. When combined with the high-profile nature of the targeted organizations, suggests an APT group or state actor.

The hosting server only responded to requests from “Windows Installer” agents

In addition to their on-then-off-again timing the hosting servers utilized another common technique to avoid analysis, rejecting all queries except for those with User Agent: Windows Installer. This ensured that it only responded to the malicious script and would avoid detection by URL analysis tools.

Why Wasn’t it Caught?

Each of the obfuscation advanced malware methodologies were designed for bypassing a specific layer of the Microsoft 365 security control infrastructure. While we understand how each was used in turn, we are still confused as to how ATP fails to detect this technique in emulation. Creating a batch file and calling the msiexec application is considered malicious, even if it fails to run. We must assume, then, that none of these files are being tested by the sandbox layer. Unfortunately, because each file is unique, no two attachments have the same MD5 hash, requiring each file to be given additional scrutiny.

Learn how to block attacks like this from hitting your inbox.