Security Alert
Jonathan Crowe
Sep 2018

Windows Task Scheduler ALPC Zero-Day Exploited in the Wild: What You Need to Know

Double-kill-zero-day-exploit-650840-edited

Last week, a security researcher published details of a Windows zero-day vulnerability on Twitter and included a link to working proof-of-concept (PoC) code on GitHub. Two days later, it was spotted being exploited in the wild.

Key Details

  • What's happening?

    Two days following the sudden disclosure of a previously unknown vulnerability in Windows operating systems, researchers have already spotted attackers exploiting it in targeted attack campaigns. The vulnerability, which can allow attackers to gain elevated (SYSTEM) privileges, was announced by security researcher SandboxEscaper on Monday, August 27 via a tweet that linked to proof-of-concept (PoC) exploit code on GitHub.

  • What's the flaw all about?

    It's a local privilege escalation vulnerability in the Windows Task Scheduler's Advanced Local Procedure Call (ALPC) interface. Exploiting the flaw allows a local unprivileged user to change the permissions of any file on the system and modify it, including system files that are executed by privileged processes. For example, SandboxEscaper's PoC specifically overwrites a printing-related DLL to make it launch notepad.exe, then triggers the Print Spooler service (spoolsv.exe) to load the DLL. As a result, notepad.exe is spawned as SYSTEM.

  • How is the exploit being used in attacks?

    According to researchers at ESET, an attack group called PowerPool has modified the exploit PoC to gain write access to GoogleUpdate.exe, the legitimate updater for Google applications which is regularly run under admin privileges. By replacing the updater with a malicious executable, the attackers ensure it will be launched with the updater's elevated privileges the next time the updater is called.

  • How are the attacks being delivered?

    The only way for attackers to utilize this exploit is by gaining initial access and code execution on a vulnerable system first. To do that, ESET reports the PowerPool group appears to be launching small-scale malspam campaigns that are being sent to carefully targeted recipients (for now). While there are no details on what the emails look like, the group has been known to use Symbolic Link (.slk) file attachments to distribute their malware in the past. 

  • What systems are vulnerable?

    Initially thought to be confined to Windows 10 and Windows Server 2016 64-bit systems, CERT vulnerability analyst Will Dormann later confirmed all supported Windows versions are vulnerable, including Windows 7, 8, and 10; Windows Server 2008, 2012, and 2016; and 32-bit systems, as well.

  • Is a patch available?

    UPDATE: Yes. Microsoft has addressed the flaw (now identified as CVE-2018-8440) as part of its September Patch Tuesday updates. Prior to the official patch, the company 0patch had issued a "micropatch" that addresses the issue for Windows 10, Windows 7, Windows 2008, and Windows Server 2016 systems.

  • What else can I do to protect my organization?

    One option presented by Karsten Nilsen and James Forshaw  is to set access control lists (ACLs) on the C:\Windows\Tasks directory to prevent authenticated users from writing to the directory. Others have tested and confirmed that prevents the exploit code from working without interfering with existing scheduled tasks or the creation of new scheduled tasks. That said, the mitigation hasn't been approved by Microsoft and could potentially have unexpected consequences. In addition, Kevin Beaumont provides guidance on creating rules to detect exploitation of the vulnerability here. Finally, having a strong endpoint security solution in place can prevent attacks from gaining the initial access and code execution they need to use this exploit.

  • Barkly customers: You are protected from these campaigns in the wild

    We can confirm Barkly offers protection against the PowerPool attacks by blocking the payload files as well as attempts to abuse .slk files to gain initial access and code execution.

Barkly blocks the PowerPool attack campaigns being distributed in the wild
Find out how

Windows zero-day vulnerabilities are always big news, but the latest flaw has generated even more attention due to the way it was disclosed. On Monday, August 27, Researcher SandboxEscaper published details about the vulnerability in a tweet and provided a link to exploit proof-of-concept (PoC) code uploaded to GitHub (later reposted by researcher Kevin Beaumont).     

SandboxExplorer-ALPC-0day-tweetShortly thereafter, other analysts and researchers began confirming that the exploit did in fact work. 

CERT vulnerability analyst Will Dormann then decided to take testing several major steps forward, ultimately confirming that, with slight modifications, the PoC exploit could also be run on all other supported versions of Windows, including 32-bit Windows 10 systems, Windows 7, and Windows Server 2012 systems. 

The vulnerability

  • Type: Local privilege escalation (requires attackers gain access and code execution first)
  • Vulnerable systems: All supported versions of Windows

At a high level, the flaw is a local privilege escalation vulnerability in Windows Task Scheduler's Advanced Local Procedure Call (ALPC) interface. More specifically, the problem is with Task Scheduler's SchRpcSetSecurity function, which is supposed to make sure any instructions it receives are carried out in the context of the user feeding it those instructions (a mechanism called impersonation). Unfortunately, it doesn't do that. Instead, Task Scheduler uses its own permissions to carry out the instructions, even if the user is a low-privileged user. The reason that can be trouble is that Task Scheduler runs in the context of the LocalSystem account, which is highly privileged. 

The result: By calling Task Scheduler's SchRpcSetSecurity function, unprivileged users can change the permissions of any file on the system, and then modify or replace it as they please. 

The exploit PoC

To demonstrate this vulnerability SandboxEscaper developed a PoC that first overwrites a printing-related DLL that should be protected from modification, and replaces it with a DLL that launches notepad.exe. Next, it triggers the Print Spooler service (spoolsv.exe) to load the DLL. As a result, notepad.exe is spawned as SYSTEM.

As the 0patch team explains in its write-up

What the PoC does to demonstrate the issue is:

  1. create an UpdateTask.job file in folder %SystemRoot%\Tasks where any user is allowed to create files (this is needed in the process of creating a new scheduled task, and non-admin users are allowed to do that); however, this file is not an ordinary file but rather a hard link pointing to a system file PrintConfig.dll. (which non-system user can't modify or replace);
  2. call Task Scheduler's SchRpcSetSecurity method to change permissions on UpdateTask.job such that everyone will be able to modify it; this actually changes permissions of the linked-to PrintConfig.dll file, which thus becomes user-modifiable;
  3. replace PrintConfig.dll with a "malicious" DLL that simply launched Notepad;
  4. trigger the Print Spooler service to load and execute the modified PrintConfig.dll using its own Local System identity.

The primary problem is step #2, which is made possible because a) calling SchRpcSetSecurity allows any user to change permissions on any file; and b) Task Scheduler is willing to perform SchRpcSetSecurity on a hard link. 

Note: There is a risk of getting hung up on the PoC and not appreciating the full breadth of this vulnerability. As SandboxEscaper commented, the PoC represents just one of many options for abuse. To drive the point home, Will Dormann provided another example of exploiting the vulnerability to overwrite acpi.sys.

UPDATE: Exploit adapted and used by attackers in the wild

Unfortunately, attackers have wasted no time putting this exploit to use. According to researchers at ESET, an attack group they're referring to as PowerPool was spotted incorporating the exploit into attack campaigns as early as two days following the initial disclosure. 

Rather than simply use the PoC code, the attackers adapted it to change the permissions of GoogleUpdate.exe, the legitimate updater for Google applications which is regularly run under administrative privileges by a Microsoft Windows scheduled task. Once the updater has been made writable, the attack replaces it with a malicious payload executable. The next time the updater is called the payload gets executed in its place, under the same elevated privileges of the updater. 

The payload appears to be a backdoor that collects basic reconnaissance of the now-compromised machine and establishes a connection with the attacker's C&C server. Should the machine be considered interesting enough to warrant further activity, the attackers will use the backdoor to download additional payload files, including the following tools designed to enable lateral movement:

  • PowerDump: A Metasploit module that can retrieve usernames and hashes from the Security Account Manager (SAM).
  • PowerSploit: A post-exploitation framework in PowerShell, à la Metasploit.
  • SMBExec: A PowerShell tool to perform pass-the-hash SMB connections.
  • Quarks PwDump: A Windows executable that can retrieve Windows credentials.
  • FireMaster: A Windows executable that can retrieve stored passwords from Outlook, web browsers, etc.

In addition, the backdoor supports the following basic commands from attackers:

  • Execute a command
  • Kill a process
  • Upload a file
  • Download a file
  • List a folder

So far, the attacks PowerPool is launching appear to be distributed via small-scale and carefully targeted malspam campaigns. While we don't have information on what the emails in these campaigns look like, ESET points out that the group has used Symbolic Link (.slk) file attachments to distribute their malware in the past. 

Attackers can abuse .slk files in much the same way as Excel Web Query (.iqy) files, which have been experimented with heavily over the summer, especially in widespread Necurs spam campaigns. While .slk abuse is far less common, it remains equally dangerous. Because they're a legitimate (and extremely simple) file format, email and antivirus filters don't stand much chance of blocking them on their own. To protect your organization, here's what you should do:

  • Adjust firewall / email filtering settings to block .slk files
  • If your organization doesn't require active use of .slk files, consider forcing them to open via NotePad:
    1. Open the Group Policy Management Console 
    2. Create a new Group Policy and name it something like "Block SLK Execution"
    3. Apply the policy to the appropriate OUs and security groups, or apply to the entire domain. Next, right-click on the policy and click Edit
    4. Navigate to User Configuration/Preferences/Control Panel Settings/Folder Options
    5. Right-click in the blank area and click on Open With
    6. In the box that pops up, choose Update for the Action, enter slk for the file extension, make sure Set as default is checked, then lastly for the Associated Program field type in %windir%\System32\notepad.exe

Barkly customers: You're protected. Barkly blocks attempts to abuse .slk files as well as the PowerPool backdoor payloads. 

Barkly-blocks-slk-malware

Barkly blocking a malicious .slk file used in a previous PowerPool campaign

Mitigations

UPDATE (9/11/18): Microsoft has addressed the flaw (now identified as CVE-2018-8440) as part of its September Patch Tuesday updates. 

As such, the best mitigation is to patch. 

For posterity's sake, we're preserving the suggestions below, which had been provided prior to the patch being available:

1) Consider setting ACLs on the C:\Windows\Tasks directory

Setting access control lists (ACLs) on the C:\Windows\Tasks directory to prevent authenticated users from writing to the directory has been confirmed to prevent the exploit code from working. It also reportedly does not interfere with existing scheduled tasks or prevent users from creating new scheduled tasks. That said, this mitigation has not been approved by Microsoft and could have unexpected consequences. Admins should be careful implementing these changes and make sure to test them first to ensure they don't cause issues in their environments. 

As the CERT vulnerability note for this flaw explains, to apply this mitigation, run the following commands in an elevated-privilege prompt,:

icacls c:\windows\tasks /remove:g "Authenticated Users"
icacls c:\windows\tasks /deny system:(OI)(CI)(WD,WDAC)

Note: When a patch is made available for this vulnerability, these changes should be undone. This can be done by executing the following commands:

icacls c:\windows\tasks /remove:d system
icacls c:\windows\tasks /grant:r "Authenticated Users":(RX,WD)


2) Apply 0patch's "micropatch"

The team at 0patch has released a "micropatch" addressing the vulnerability for 64-bit Windows 7, Windows 10, Windows 2008, and Windows Server 2016 systems. In order to apply the micropatch you have to install 0patch and create a free account. 


3) Deploy detection rules

Researcher Kevin Beaumont walks through implementing rules to detect exploitation of this vulnerability on his blog. In addition to using Microsoft Sysmon to look for spoolsv.exe spawning abnormal processes (to spot use of the PoC exploit, specifically), Beaumont suggests auditing the Tasks directory for Event 4664 (an attempt to create a hard link). He also provides a PowerShell script that can be pushed out via Group Policy.  

4) Make sure you're using endpoint security you're confident in

In order to leverage this local privilege escalation exploit attackers first need to bypass your organization's defenses to gain initial access and code execution on a vulnerable machine. This is where antivirus (AV) programs are supposed to come into play, but as we've routinely seen, simple tricks like the use of legitimate file types such as .slk and .iqy files is often enough to evade AV detection. 

Barkly blocks malicious payloads as well as the latest tricks attackers attempt to use in order to retrieve them. In this case, we can confirm Barkly blocks the backdoor payloads the PowerPool campaigns are attempting to distribute, and should the campaigns try to utilize .slk, .iqy, or other commonly abused file types as downloaders, Barkly blocks those, too.   

Want to see Barkly in action for yourself? Sign up to test it out.

Additional reading


Subscribe to the blog for updates on this threat

We'll continue following this vulnerability closely. Sign up to receive updates so when there's news regarding a patch or further attempts to exploit this vulnerability in the wild you'll be the first to know. 

Jonathan Crowe

Jonathan Crowe

Jonathan covers the latest threats and cybersecurity trends from a practical perspective.

lock-white.png

Stay up-to-date on the latest threats

Join a group of 7,000 IT and security pros who get clear, actionable takes on malware and infosec news.

Subscribe

Comments

Stay informed!

Get the latest security news, tips, and trends straight to your inbox.

Stay informed!

Get the latest security news, tips, and trends straight to your inbox.