How to Solve the Blindspots of Event-Driven Detection

A while back, I discussed how memory could be used as an ultimate form of the log as long as the analysis workflow and process is smooth.

This blog post will start by explaining the blind spots created by event-driven detection solutions such as Endpoint Detection & Response (EDR), and how this can be balanced by using Comae DumpIt + Stardust as part of an incident response & compromise assessment strategy.

The Driverless Event-Driven Detection Truck

This blog post has been motivated by two recent events:

Microsoft Kernel Sensors

Starting from version 1809 (October 2018), additional ETW events (kernel sensors) have been added to the kernel to trace new events including User APC code injection initiated by the kernel. This technique has gained notoriety in the public eye when WannaCry repackaged NSA’s DOUBLEPULSAR leaked by TheShadowBrokers.

BlackHat USA 2005 — Barnaby Jack releases a paper explaining a User APC code injection method. (KeInsertQueueApc)
January 2006 — Uninformed Vol 3 on Thread APC by bugcheck & skape.
2013(???) — CIA Vault 7: From Kernel to User Mode: APC Injection.
April 2013 — According to documents leaked by TheShadowBrokers, DOUBLEPULSAR (which leverages User APC code injection) targeted a SWIFT Service Bureau in the Middle East.
April 2017 — TheShadowBrokers releases offensive tools including Windows exploits/tools: DOUBLEPULSAR, ETERNALBLUE etc.
21, April 2017 — Analysis of DOUBLEPULSAR by zerosum0x0
May 2017 — Comae Stardust adds detection for DOUBLEPULSAR.
May 2017 — WannaCry happens and uses ETERNALBLUE + DOUBLEPULSAR
October 2018 — Microsoft adds ETW-based kernel sensors including one to log APC queues (EtwTiLogQueueApcThread)
January 2019 — Huawei releases a patch for a “vulnerability” in Huawei PCManager Product (CVE-2019–5241) that was discovered through the new APC ETW sensor and reported by Microsoft.
Timeline: APC Injection Method Lifespan

As you can see, the lifespan of a technique can be rather long before it gets detected in real time. Even though there are more and more efforts on the detection side from vendors, you can still expect this delay to be significant in the future for new techniques.

Endpoint visibility becomes a problem when the implementation of detection techniques by defenders is measured in years. Also, it’s important to note that detection techniques are never perfect — someone will always come up with a way to bypass them as it happened a few months after this new sensor got added.

Detection is not and will never be perfect, this is why response needs to be done in a smarter way and go beyond “RegEx parsing”. And ETW sensors are definitely a good step in the right direction.



EXTRAPULSAR is a proof of concept released by zerosum0x0 in April 2019. This technique is very interesting as it is currently undetected by any EDRs or current kernel sensors just like DOUBLEPULSAR used to be for many years until “WannaCry happened” to be significant enough as a problem to be monitored.

The proof-of-concept smbdoor.sys driver is a silent remote backdoor that does not bind new sockets or perform function modification hooking. Instead it abuses undocumented APIs in srvnet.sys to register itself as a valid SMB handler. It then listens on the already-bound ports 139/445 for special packets in which to execute secondary shellcode. In several ways, it has similarities with DoublePulsar and DarkPulsar, as well as ToxicSerpent

This raises interesting questions about the current state of detection in security. Detection in EDR works well nowadays for techniques it already knows, logic you’ll say. But what about techniques that we aren’t aware of?

EXTRAPULSAR is a beautiful example of such techniques. It leverages an unexported table in srvnet.sys driver which makes it very difficult for endpoint detection to have visibility on, and performs communication over SMB without having to bind new sockets. This technique is currently undetected by EDRs.

Last year, I discussed the idea of rethinking logging for critical assets by using memory as an additional input source for logs to fill the gap created by log files or event generated detection as they may miss events that are outside their scope.

In this scenario, periodically generating strategic memory images generated by DumpIt at different points in time can be leveraged if they are archived for future analysis once a new suspicious technique emerges in the public eye such as EXTRAPULSAR.

This allows enabling “retro-hunting” in a much more powerful manner and makes memory archives as a data source for “time machine investigation” feature of Comae Stardust to detect for silent attackers.

As an illustrative example, it is very easy on Comae Stardust platform to re-extract metadata from an archived memory image generated by DumpIt (1), or just simply rerun detection playbooks (2) against the extracted metadata.

As we add detection playbooks, we can easily increase memory visibility and post-mortem detection techniques that are not covered by EDRs such as EXTRAPULSAR.

Below is an example of report (click here for live report) output generated by Comae Stardust against such blind spots created by event-driven detection.

Comae Stardust on SrvNetDeviceExtension malicious entries.


Real-time endpoint detection leaves obvious blindspots once a method is unknown, however, this can be balanced by archiving memory images generated by DumpIt.

Those archived images can later be analyzed (or re-analyzed) once additional detection playbooks are added to Comae Stardust (or once the input threat intelligence feeds updated) as we have seen in the above scenario with EXTRAPULSAR.

This provides your organization more endpoint visibility if you do not want to wait years for sensors to be added by endpoint detection vendors —while attackers may be acting out of the scope of those solutions.

Click here, to see the analysis report generated by the platform after detecting EXTRAPULSAR’s silent SMB backdoor.

If you have any comments or questions, do not hesitate to reach out over email ([email protected]).

How to Solve the Blindspots of Event-Driven Detection was originally published in Comae Technologies on Medium, where people are continuing the conversation by highlighting and responding to this story.

Article Link: