Windows 10 ALPC Task Scheduler EoP — osquery and PolyLogyx to the rescue

Recently got to know of a new Windows 10 (and pretty much all other versions too) vulnerability described in detail here. In simplest terms, the vulnerability allows an application to by-pass the NTFS ACLs and allows an application to be able to write onto files that it was otherwise not allowed to.

Now, if you are not worried about it, you really should be. For one, this is not yet patched and the PoC code is already out. But the bigger reason being its simplicity and potential severity post exploit. The attacker can write onto scheduled tasks (as in this PoC); write on to a binary installed as a windows service; or use any of the myriad techniques available to gain persistence and auto execution.

Now a race is about to begin where every endpoint vendor would participate in, to show how their technology can either prevent, or notify, when the vulnerability gets weaponized. Given that we are in the final stages of our release, code named Captain Nemo, we thought let’s see where Captain Nemo stood the test on this vulnerability.

Captain Nemo derives its power from the osquery agent and our extension to it named Nautilius (well, what else?). For the uninitiated, osquery is this beautiful tool that can make querying the properties of an endpoint as simple as querying a SQL table. For the doubly uninitiated, PolyLogyx extension to osquery on Windows turbo charges its form factor and data breadth by adding a real-time activity capture engine to it. Not only that, the extension also captures the context around the activity like the time, the process, the target object (file, registry, network) and the user account that owned the activity. The real time activity data captured by PolyLogyx extension is regularly synced using the scheduled query mechanism of osquery on the following tables:

win_file_events; win_process_events; win_socket_events; win_http_events; win_dns_events; win_pefile_events; win_epp_table

To ensure our server is not choked by the volume of event data, we have also built a capability to apply filter to these events. And thanks to the filter set from swiftonsecurity, created for sysmon, we ported something similar on our agent.

So we begin by priming our fleet manager with the information that a process triggered by low integrity user might try to break its confines and write onto a file that it might not have access to. To be watchful for such activity, lets see what users exist and with what privileges:

Thanks to the osquery ‘users’ table, in an instant we can find out what users exist on the target endpoint called ‘poly-win10’ and with what privileges. We see there is a non-admin user called ‘visitor’.

So now the endpoint is streaming interesting data events on which we can apply some alerting conditions, e.g. in case a non-admin or high privileged user ends up modifying something that it did not have rights to. Simple and sensible enough.

Now let’s run the exploit PoC test code on our endpoing. The way the PoC code works is it would need a goat process to inject the exploit DLL, which would then overwrite another DLL under Window scheduled tasks, to be triggered a print job when spooled. So we create a goat ‘notepad’ process and the state of the endpoint looks like:

A notepad process with pid 7120 being created under the user poly-win10\visitor. And then from the non-admin (we can’t get admin, we are a ‘visitor’, right?), we attempt to inject a DLL into our goat process. The event of process creation (pid 7120 & notepad) is also captured on our server.

Alright, so the world is looking a good place, and the exploit is triggered on the endpoint.

So we see a new instance of notepad with PID 1316 is being created by spoolsv.exe (this could have been any process e.g. a malware but since this is a PoC, the exploit write chose to trigger a benign process like notepad.exe) running under ‘System’ account. So what triggered from a non-admin guest account, now has ‘System’ privileges. To see how it did that, lets look at the alert we received:

A-ha. By our constant monitoring on file (or PE File) activity, we see that the notepad process with PID 7120 has now overwritten a file inside C:\Windows\System32\DriverStore\FileRepository\…\PrintConfig.dll and post the write the MD5 hash of the new file is printed. Since all the real time activities of the endpoint are being captured, and exported as an osquery table, we can also query for the files dropped by the process PID 7120 by means of a simple SQL query.

(Pardon the poor graphic appearance where the progress bar overlapped the SQL query. We are still somewhat under construction)

The MD5 hash has a pre-poulated URL to VirusTotal, and that shows as:

Phew. Oh boy.

Well, don’t worry. It was a PoC exploit, not a real malware. The ‘signature driven’ AV industry is quick to catch on to it (although only 13?? That was disappointing..huh)

Anyways, so now we come to the end of this graphicy-verbosy blog, which was intended to show about the new exploit, the detection methods, and, er, a bit of self promotion, maybe. Leave a comment if this was of any use or interest to you. You can leave a comment, even if not. Doesn’t really cost a bit. Just a bit of typing.

God bless.