Microsoft acknowledged a new Zero Day vulnerability on Microsoft Windows Task Scheduler. Currently there is no workaround. That's why we show you how to reduce the risk.
On August 27, a new Zero Day vulnerability on Microsoft Windows Task Scheduler has been publicly revealed. Acknowledged by Microsoft, this local escalation vulnerability has currently no known workaround. However, because a PoC* has been released, it could be used by malicious hackers. Keep reading and you will discover how to reduce the risk!
Let's start with a bit of explanation! The Microsoft Windows Task Scheduler uses an internal interface called ALPC (Advanced Local Procedure Call) in 64-bit systems (Windows 10 & Server 2016), which does not check permissions when performing its actions. To be more accurate, this is the API function called "SchRpcSetSecurity". Because of this behavior, anybody can call it and set file permissions on anything locally, even a guest user!
How it is exploited?
The exploit misuses the "SchRpcSetSecurity" API to alter permissions and allow a hard link to be created. Once done, it calls a print job using the XPS Printer to call the hijack DLL as SYSTEM thanks to the Spooler process.
How to detect it?
The first step is to enable file system auditing by creating a specific GPO. Within the GPO, browse to "Computer Configuration\Windows Settings\Security Settings\Advanced Audit Policy Configuration\Audit Policies" and define the following Audit Policy setting:
- Object Access: File System — Success
In addition, you have to configure, in the same GPO, a scheduled task to launch a specific script** to turn on file system auditing on the Tasks folder. If an exploit is detected, a security event called 4664 will be generated because a hardlink has been created in the Tasks folder.
This vulnerability can only be exploited locally, but it remains necessary to ensure that your local computer is well protected! Don't forget to lock your screen, don't write your credentials down and disable guest users are a few quick wins that can be configured if not already done, to reduce the risk.
There is currently no patch deployed by Microsoft regarding this vulnerability. However, you should keep following new security updates released by Microsoft and check regularly our website for more information. Remember to follow a strict and planned patch management process in order to avoid new issues in your production environment.
**Script:$computer = gc env:computername
$path = “C:\windows\system32\tasks”
$user = “everyone”
$path = $path.replace(“\”, “\\”)
$SD = ([WMIClass] “Win32_SecurityDescriptor”).CreateInstance()
$ace = ([WMIClass] “Win32_ace”).CreateInstance()
$Trustee = ([WMIClass] “Win32_Trustee”).CreateInstance()
$SID = (new-object security.principal.ntaccount $user).translate([security.principal.securityidentifier])[byte] $SIDArray = ,0 * $SID.BinaryLength$SID.GetBinaryForm($SIDArray,0)
$Trustee.Name = $user
$Trustee.SID = $SIDArray
$ace.AccessMask = [System.Security.AccessControl.FileSystemRights]”Modify”
$ace.AceFlags = “0x67”
$ace.AceType = 2
$ace.Trustee = $trustee
$SD.SACL = $ace
$wPrivilege = gwmi Win32_LogicalFileSecuritySetting -computername $computer -filter “path=’$path’”