Thisis not at all what the error in German says. It first says that the service cannot be started because it is not responding to the start request. At the end it says that the file cannot be found and that access was denied.
I suspect that this is because you did not install Sysmon from an Administrator prompt. The last error message in your original output indicates that access is denied, and since you are able to do it correctly via a scheduled task (which may execute everything elevated), this is probably the issue.
Sysmon is a background driver and service, so your task is not running in the background and neither does it have to. Simply executing the command line installed the service. If you delete the task and reboot then everything should still work.
I wanted to add that creating a script to capture the events you are looking for is easy if you integrate grep by using WSL2, cygwin windows server 2022 (its own set of security related issues), or even creating grep64.exe yourself if you know how.
I am 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.
Internal : Hi Metrics / Windows peeps what am I missing can metricbeat -> system > processes not detect sysmon process. I have metricbeat set to collect all processess ... I see them Alll ... but I don't see Sysmon ... it is running... It is a special processs of something that can not be detected?
I wanted to understand how Sysmon detects various activities on the Windows endpoints and generates the event logs, so I created a tool SysmonSimulator which is written in C and uses Win32 APIs for simulating attack techniques and provides instructions to generate the Sysmon event logs. It can be used by threat detection teams to test the EDR detections and correlation rules. The source code is available on Github and anyone can modify to test it as per their requirements.
The first one SysmonDrv.sys is the driver loaded by Sysmon which registers the kernel notification callbacks. Sysmon sets multiple callbacks on kernel objects in addition to using telemetry APIs and ETW and sets up as a Minifilter driver on all volumes on a system which allows it to see all the file system operations and actions taken by APIs before they are processed by the file system. The driver is loaded by a service at system startup which runs Sysmon64.exe on system boot and keeps requesting the driver to get state of events generated. Below diagram shows the architecture of Sysmon:
SysmonSimulator requires an event ID from the above parameters list (for example: -eid 1) and the related Windows API function will be called to simulate the attack and Sysmon event log will be generated which can be viewed in the Windows Event Viewer.
To detect process creation events, Sysmon uses PsSetCreateProcessNotifyRoutine callback routine to monitor the process creation activities performed by APIs like CreateProcess(), CreateProcessAsUser(), CreateProcessWithToken(), CreateProcessWithLogon() and so on.
To detect file creation time change events, Sysmon uses the FltRegisterFilter which is used to register a minifilter to detect the activities when any process tries to change the creation time of a file using the windows API function SetFileTime.
In the Sysmon EventID 3, all the TCP and UDP network connections are logged and each network connection is linked to a process through the ProcessId and ProcessGUID fields which is really useful for the correlation. Some important fields are included like the source and destination host names, IP addresses and port numbers.
Note: Usually, event ID 3 generates a large volume of logs, so the sysmon XML configuration file should be properly tuned by creating necessary filters for specific processes and ports.
In Event ID 5, Sysmon logs the process termination event when a process terminates. It provides the UtcTime, ProcessGuid and ProcessId of the process. For threat detection teams, this event ID is useful to co-relate with process start and shutdown events, if a process may have been terminated by an adversary and also to measure the lifespan of a process by comparing the process termination time with the process creation time to test SIEM behavioural rules.
To detect process termination events, Sysmon uses the same PsSetCreateProcessNotifyRoutine event registration mechanism and looks for any process termination API like ExitThread(), ExitProcess(), TerminateProcess() and their relevant NTAPIs. To verify which NT API is called when a particular Win32 API to exit the process is called, I tried these different API functions to terminate the process and in the end, ZwTerminateProcess() gets called and kernel terminates the process and all of its threads, and a process termination event gets logged in Event Viewer.
In the Sysmon EventID 6 (driver loaded), the information about a driver being loaded on the system is provided. This event would be helpful in identifying driver based threats such installation of malicious or vulnerable drivers, more importantly the signed ones because they provide a stealthy way to conduct malicious activity. There are various incidents of such activity where a driver is loaded on a system to perform malicious activities, for example- XMRIG coinminer driver (WinRing0x64.sys) which comes in an open source project that is commonly abused by adversaries to infect and mine bitcoin. Threat actors often use kernel drivers to install rootkits or to run the tools that require to run at Kernel level. So as defenders, we should always keep an eye on the drivers in our environment.
When the event ID 7 from SysmonSimulator is executed, it calls the LoadLibraryA function to Load the crypt32.dll module into the address space of the SysmonSimulator.exe. This is how the event looks like:
To detect image loading events, Sysmon uses the same PsSetLoadImageNotifyRoutine event registration mechanism, which registers a callback for this all image loading activities performed by different API functions such as ImageLoad(), NtMapViewOfSection(), LoadLibrary() and so on.
In the Sysmon event ID 8 (CreateRemoteThread), a log is generated when a process creates a thread in another process by using the CreateRemoteThread function. This technique is used by malware to inject code and hide in other processes. The event indicates the source and target process. It gives information on the code that will be run in the new thread: StartAddress, StartModule and StartFunction.
In these type of events, the StartAddress field shows the address of the target process where the new thread starts. We can use Process Hacker to see what is there in that address. It can be seen that a new thread is created into the remote process starting at the address of our MessageBox shellcode that was loaded by SysmonSimulator into the allocated virtual memory space of the target process.
To detect CreateRemoteThreat events, Sysmon uses the PsSetCreateThreadNotifyRoutine event registration mechanism, which registers a callback when a new thread is created and when such a thread is deleted.
Sysmon Event ID 9 (RawAccessRead) is logged when a process performs read operations on the drive using the \.\ syntax. This technique is often used by malware for data exfiltration of files that are locked for reading, as well as to avoid file access auditing tools. Threat actors use this technique to copy important files such as NTDS.dit and SAM Registry hives from the host to do credential harvesting.
Note: Normally, no legitimate process should be performing this kind of activity. It is mostly performed by softwares like the backup tools or drive imaging tools in a normal environment.
To detect RawAccessRead events, Sysmon uses the FltRegisterFilter which is used to register a minifilter to detect the activities when any process tries to read a drive using the \.\ denotation using APIs such as NtCreateFile(), CreateFile(), ObpLookupObjectName() and so on.
Sysmon Event ID 10 (ProcessAccess) is logged when a process tries to open another local process object by using OpenProcess function. This is a type of operation that is often performed to read and write in the address space of the target process. This event can help in enabling the detection of malicious tools that read the memory contents of processes like lsass.exe (Local Security Authority) in order to steal credentials.
If a target process is opened with higher permissions, it is possible to perform operation like reading the data from target process memory, patching its memory, process hollowing, creations of threads in the target process like we did in Event ID 8 (CreateRemoteThread) that are commonly performed by adversaries.
In this event, the most important field is CallTrace which can be used by threat detection teams to create different use cases. The calltrace provides the DLL and the relative virtual address of the functions in the call stack right before the OpenProcess call which would be really helpful to find which functions are called to performed specific actions.
Now, I will dump the LSASS memory by calling MiniDumpWriteDump() from a custom program dumplsass.exe. Once the function is called, an event log is generated which matches the above condition as seen in the below screenshot:
That was an example of using the Calltrace field to detect Credential dumping performed using MiniDumpWriteDump(). Similarly, other use cases can be created by leveraging information from the calltrace.
3a8082e126