Sysmon.exe

[Jennifer Leos]

Iam working on a query to highlight devices within the environment that do not sysmon.exe running on them. There are several hundreds of devices in the environment and all of these should have sysmon.exe running as it's been widely deployed. The purpose of my query is to identify devices that do not have sysmon.exe running.

I get other processes that are not "Sysmon.exe or Sysmon64.exe" which is not what I want. I want to identify devices which do not have the Sysmon.exe or Sysmon64.exe process running. All suggestions are welcome.

@rahuljindal-MVP Thanks for your response and suggestion. Modifying the query as suggested below shows. Any suggestions on which kql commands I can use to make the comparisons against all enrolled devices? I am quite new to KQL so learning as much as I can.

I am attempting to use the "TA-Sysmon-deploy" Splunkbase app to deploy and maintain Sysmon on our endpoints. I've noticed that the script which checks for sysmon then installs it does run correctly. It always results in a "sysmon not found" situation and re-installs it. This is expected activity if the script does not see sysmon running or it detects is out of date. Nonetheless, the script completes each time by installing sysmon again and again, even thought the host has the proper version of sysmon installed and running.

The peculiar thing here is that it works correctly if I run the batch script manually from an Admin (as system) command prompt but not when run by the Splunk Universal Forwarder. I've added an Echo statement so I can the check script variables just before they go into the deployment IF statements. Theyare correct when manually run but are not when executed by Splunk.

- SETLOCAL and ENDLOCAL: removes any outside the script variable influences

- Enclosed the version check FOR statement in an IF EXIST clause, the script seemed to error out if sysmon.exe did not exist)

- added variable output "echo" statements so I can see the variable in the logs just before the IF statements.

that is correct. Both, config and installation must be there..

about script and your environment, you can test it first on your windows station, when you confirm that work in both case (deploy and update), you can test it from splunk..

It sound like a GPO or system management utility is copying version 13.31 from somewhere. Check to see if any GPO has startup script or Group Policy Preference that is copy sysmon.exe from a network share.

LinkedIn and 3rd parties use essential and non-essential cookies to provide, secure, analyze and improve our Services, and to show you relevant ads (including professional and job ads) on and off LinkedIn. Learn more in our Cookie Policy.

I'm thrilled to mention that @markrussinovich and @mxatone have released Sysmon v6. When I first discussed Sysmon v2 two years ago it offered users seven event types. Oh, how it's grown in the last two years, now with 19 events, plus an error event. From Mark's RSA presentation we see the current listing with the three new v6 events highlighted.

"This release of Sysmon, a background monitor that records activity to the event log for use in security incident detection and forensics, introduces an option that displays event schema, adds an event for Sysmon configuration changes, interprets and displays registry paths in their common format, and adds named pipe create and connection events."

I strongly suggest you deploy using these recommendations. A great way to get started is to use a Sysmon configuration template. Again, as Mark discussed at RSA, consider @SwiftOnSecurity's sysmon-config-export.xml via Github. While there are a number of templates on Github, this one has "virtually every line commented and sections are marked with explanations, so it should also function as a tutorial for Sysmon and a guide to critical monitoring areas in Windows systems." Running Sysmon with it is as easy as: sysmon.exe -accepteula -i sysmonconfig-export.xml

As a quick example of Sysmon capabilities and why you should always run it everywhere, consider the following driver installation scenario. While this is a non-malicious scenario that DFIR practitioners will appreciate, rather than the miscreants, the detection behavior resembles that which would result from kernel-based malware. I fired up WinPMEM, the kernel mode driver for gaining access to physical memory included with Rekall, as follows:

ETW is a heavy area for analysis that we use when identifying indicators of compromise. With the recent release of Sysmon v10, and Event ID 22 and DNS monitoring, Sysmon now allows for the ability to identify every process that executes a DNS query. DNS in general is a sore subject for defenders as the log volume often becomes substantially large when ingesting data into the SIEM and probably one of the highest areas of visibility that threat hunters first look at.

When you download ( -us/sysinternals/downloads/sysmon) from the Microsoft site and install on a Windows machine, there are a few things to note. First is that by default Sysmon will log *everything*. You might not want that and the sheer number of logs you receive will be substantially larger from a verbosity perspective. We recommend leveraging your own custom configuration and there are two really great starting points for configs that have some amazing analysis/rules:

Configuration files allow you to be very specific and granular about what is logged. For example, a common technique for exploitation utilizes leveraging living off the land techniques ( -project.github.io/) which are legitimate Windows binaries (referred to as Living off the Land Binaries and Scripts, LOLBAS) that allow for additional functionality and code execution. One common method for detecting these LOLBAS is through identifying when a process is created and especially with network communications.

Most endpoint detection and response (EDR) tools look for common indicators within the command like for example a combination of regsvr32, a /i, and *http* within the command line option. While this may be useful for common detections, if an attacker obfuscates this code in anyway, it circumvents the detections commonly presented by endpoint tools.

Most operating systems to-date are now running Sysmon64.exe which is platform specific to server core without 32-bit. If we open up a administrative level command prompt and run Sysmon64.exe, we can see the configuration flags (note you can run sysmon.exe as well on 64-bit platforms with 32-bit compatibility):

The most important pieces here are that we can use -c to update an already existing installation of Sysmon or specify a new configuration to be installed. We can also uninstall with -d, and -i for installation of Sysmon.

We can see from the Event ID 1, that regsvr32.exe was run from the system32 directory, most importantly we can see the CommandLine parameter that was used which contained our indicators of /i and downloading from a remote site. We can also see that the ParentImage (parent process) was cmd.exe (highly suspicious). Some other useful fields are User (user logged int hat executed), hashes (used if renaming), and ParentCommandLine.

In this case we will look for regsvr32.exe with network connections initiated. In a normal corporate network, this would be an unusual behavior. Our recommendation is to leverage more network connection detections and baseline usual behavior and monitor for deviations of those patterns for better detection.

In the example above we can see some good indicators, first the Image (regsvr32), the User, SourceIP, DestinationIP. This is a great view of what happened and where regsvr32.exe communicated to. In this example though we lost some valuable information such as CommandLine which could be very valuable. In regsvr32.exe as an example (and good for other LOLBAS), it might be valuable to log on all process creations that you create under network connection, but alarm only on network connection and ability to retrieve process creation alarms for further analysis.

This is only one example and there are many more examples that can be used with Sysmon. There are new indicators coming out all of the time and what is fantastic about Sysmon is the ability to make changes to just the configuration file and then update the configuration without a need for a reboot. In enterprises, packaging up Sysmon and leveraging either your SIEM, an EDR (such as Binary Defense Vision which can ingest Sysmon logs), or Windows Event Forwarding allows you to retrieve these logs enterprise wide.

From the screenshot above, we can see the Image that was loaded which was regsvr32.exe and the queryname and domain of the address. This is a specific example where we have a specific LOLBAS calling out to a domain name which could be a great detection for us. As mentioned above our recommendation is to leverage all DNS queries in a central location to perform better threat hunting exercises.

3a8082e126