Snare XDR and Sysmon

Threat detection software has evolved significantly in recent years. Malware detection and prevention software began incorporating endpoint detection and response (EDR) in a change of tactics in response to more comprehensive, dangerous, and self-masking malware variants. The market has adopted a few different flavours of Detect/Response mechanisms – EDR, Network Detection and Response (NDR), Threat Detection and Response (TDR), and now the industry has settled more on Extended Detection and Response (XDR).

The terms have meant different things to different customers and vendors, but the overall goal is to detect and react to threats and unauthorised user activity across networks, servers and endpoints, clouds, and applications. XDR applies analytics and automation to detect, analyse, and hunt for threats in order to remediate or respond to identified threats.

By collecting forensic and log data from a diverse range of system components, correlated data can be scanned to identify patterns across event sources and provide context to a threat or attack chain. Events and activities that would not have been detected or addressed prior to XDR tools and concepts being implemented will be more obvious, allowing security teams to focus on, respond to, and mitigate/eliminate identified threat. This has the benefit of reducing further impact, and dropping the severity, scope, and longevity of the attack.

How Snare helps with XDR

The Snare suite has a comprehensive capability to collect log data from almost any source. Snare agents run on most common platforms such as Windows, Linux variations, MacOS, Solaris, Microsoft SQL Server, and can collect relevant forensic log activity from a wide range of systems and applications. The Snare agents collect and send log data to a Snare Central server and can send or reflect data to a range of other SIEM and analytics tools. The collected logs provide visibility into a range of security-sensitive activities, including:

  • Administrative Activity – What actions were undertaken by administrative users? Did they add/remove users, change permissions, change system policies, run privileged commands, etc.?
  • Login/Logoff Activity – Who logged on, was it within business hours or out of hours, what systems were impacted? Was it local or remote via a VPN or remote connection to the host? What was the source? Was there lateral user movement between systems? Are users trying to gain privileged access to systems? Are there indications of brute force logins occurring on the network to attempt to guess a password?
  • Command Activity – What applications or shell commands were run, were any executed at a higher privilege level? Where were these commands run, on what systems?
  • Data Access – What data was accessed, by who? What did they read, change, or delete? Was data copied or exfiltrated to other systems or out over the internet? Was a file or payload or backdoor loaded by malicious actors for later use?

There are various capabilities that help facilitate the analysis of these activities:

  • Collect logs from as many sources as possible – all servers, desktops, network devices, everything that can send a syslog. All devices should have some form of logging or monitoring in place.
  • Use FIM, FAM, RIM and RAM to track and monitor all key files and system configuration. Know who and when files were changing and what tools they used.
  • Use Database Activity Monitoring (DAM) to track key activity on SQL databases. Know if admin accounts are being abused and validate that key data has not been tampered with.
  • Having evidence to show if the attack vectors came in via email, USB, a web link download, a software update are all important to knowing how they got in.

To take a deeper dive into how Snare can help with XDR, download our technical white paper.

Background on the Print Spooler Vulnerability

The recent threat posted by Microsoft for a print spooler vulnerability is subject to exploitation from tools such as Mimikatz, a tool that can steal user credentials and potentially facilitates lateral movement of an attacker in the network.

PrintNightmare directly affects the native Windows service named “Print Spooler” that is enabled by default on Windows machines. The purpose of Print Spooler is to manage printers and printer servers.

  • SANS has published a recent article here.
  • CISA have also noted the issue here.

This covers the remote code exploitation of systems from the vulnerability. As of the 2nd of July, Microsoft has not fully patched the problem and still rates it as critical. Microsoft has published some workarounds to allow customers to potentially avoid the issue by reducing services/capabilities.

The process of exploiting the vulnerability will generate several print spooler events (event ID 316) in the PrintService-Operational custom windows event log.

How Snare Can Help

The Snare Enterprise Windows agents will collect any custom Windows event logs, that have been enabled by the administrator out of the box. The generation of PrintService custom logs can easily be enabled from either the Windows event viewer or from the group policy setting, at which time they will be picked up by the Snare agent and forwarded to your collection target system.

Open the Windows Event Viewer application then navigate to the Application and Service Logs → Microsoft → Windows → Then scroll down to PrintService and expand to see the Operational log then right click to enable.

An example as follows:

Mimikatz PrintNightmare_Example

Once enabled, logs will appear in this log and the Snare Agent will collect and send the logs to the Snare Central or your other target SIEM system.

In Snare Central, a specific report can be created for these events and a real-time alert can be triggered when one or more target events appear over a designated timeframe.

Create a new report using the menu using the “Add new objective” button in a report container of choice.

Change the log type to MS Windows Event Log – Adhoc query

An example of a report is provided below.

The source type has been configured with the name of the custom event log, the eventid has been set to 316 and the number of days set to 1 in order to limit the report to the most recent data. This can be adjusted to search for more days as needed:

Mimikatz Print Spooler Vulnerability

To display the events that meet these requirements, adjust the tabular reporting to show the following fields.

Mimikatz Print Spooler Field

Adjust the number of rows and pages to suit the number of rows being generated, keep in mind the larger the output the longer the report may take to generate.

For real time alerting based on a threshold of 2 events in 5 seconds you can set the criteria as follows:

Mimikatz Print Spooler Print Nightmare Snare Report

Select “Set” to save the report. Now set the schedule to provide the email address for the alerts to go to.

This will use the SMTP gateway as set in the configuration Wizard.

PrintNightmare Snare Detection

Once active, if any “316” eventIDs in the PrintService event log are received, a real-time alert will be generated.


Need help from Snare’s Team?

Contact our team if you have questions about the PrintNightmare incident or how to set up Snare to manage or audit printer server logs.