Hunting for threats with Intercept X and the Windows Event Collector

We’ve all had a moment of being so caught up in the excitement of threat hunting that we’ve run down a rabbit hole and had to back out. Using tools that present the right data in the right context makes us more efficient, more effective hunters, and it helps us to avoid rabbit holes (and to retrace our steps if we run down them anyway).

Like lots of threat hunters, the Sophos Security Team uses a variety of data streams to help deliver that context. We get data from Sophos products, of course, and we use streams from sources like Sysmon and the Windows Event Forwarding and Collecting framework to enrich it.

In particular, we’re fans of the data we get from Intercept X. It helps us to build a comprehensive threat picture, to make sense of our data, and to respond effectively and proportionately to alerts.

It not only helps us perform root cause analysis on alerts, it saves us valuable time by providing a platform from which to pivot into other datasets, to create correlation searches, and to visualise those searches in dashboards.

Gathering data

By default, Intercept X writes exploit prevention alerts to the Windows application log with an Event ID of 911:

If your SIEM (Security Information and Event Management) system is already ingesting Windows endpoint events, adding Intercept X alerts to a WEC (Windows Event Collector)-initiated subscription is a straightforward task. I recommended you enable process command line auditing too.

Events are forwarded to the WEC, which can pass them to an SIEM/analytics tool of your choice. (Microsoft has a comprehensive set of articles covering the initial setup of event forwarding and collection.)

The messages in the 911 events also contain useful information that can be extracted to field value pairs, to further enrich your SIEM’s threat hunting data.

Our tools also consume event and alert data from Sophos Central. If you’re not already pulling this data into your SIEM system, you can read about how to do it on the Sophos Community pages.

Further contextual data is obtained using an unsupported method from Sophos Central, which provides us with information such as last IP, last logged on user, last activity and last successful update etc.

Fitting it all together

The event data obtained from Sophos Central shows us alerts for things like ROP (Return-Oriented Programming), HeapSpray and DEP (Data Execution Prevention) exploits. (If you want to know more about these kind of exploit detections, the whitepaper Exploits Explained: Comprehensive Exploit Prevention has some great explanations.)

Using exploit detections as a foundation search, and correlating the 911 events from Intercept X, gives us a compelling set of data to begin threat hunting.

Digging deeper, we can use an event’s timestamp to narrow our search and investigate what was happening on a machine around the time of a detection, by looking at the processes that appeared before and after it.

This can assist in identifying suspicious looking PE files. In turn, this allows us to pivot and start searching the rest of the estate for the same files; to use the information to search in other data sets in the SIEM system; or to look for spurious command line entries.

It can also help us to pivot on other variables on the affected machine, such as: what accounts have logged on, what sites have been visited, what did the network traffic look like, were any PUAs (Potentially Unwanted Applications) blocked, and were there any other detections?

An example

In this example you can see an ROP exploit detection in Chrome.

Using the detection’s timestamp, I looked at a 20 minute window – 10 minutes either side of the event – and searched for Event ID 4688 to understand what new processes were created, who ran them and what process created them. This will also reveal if there’s anything suspicious I can pivot on, and dig deeper into.

In this instance, the detection is revealed as a false positive, my digging stops and the rabbit hole is dodged. By reducing the amount of information to triage, I can see clearly that there were no malicious triggers. In this instance I was able to determine that the user clicked a link in an email in Outlook, that it took them to a legitimate website running on the local network, and that the only processes running were from known good locations.

By collating appropriate, useful information into our SIEM system, we ensure we have the tools and data to triage quickly, allowing us to pinpoint what’s important and where we should (and shouldn’t) focus our efforts.

Without this, we’d almost certainly have found ourselves having tea with the Mad Hatter again!