offensive security
Detecting Sysmon on the Victim Host
Exploring ways to detect Sysmon presence on the victim system
Processes
Note: process name can be changed during installation
Services
1
Get-CimInstance win32_service -Filter "Description = 'System Monitor service'"
2
# or
3
Get-Service | where-object {$_.DisplayName -like "*sysm*"}
Copied!
Note: display names and descriptions can be changed
Windows Events
1
reg query HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\WINEVT\Channels\Microsoft-Windows-Sysmon/Operational
Copied!
Filters
Note how even though you can change the sysmon service and driver names, the sysmon altitude is always the same -
385201
Sysmon Tools + Accepted Eula
Sysmon -c
Once symon executable is found, the config file can be checked like so:
1
sysmon -c
Copied!
Config File on the Disk
If you are lucky enough, you may be able to find the config file itself on the disk by using native windows utility findstr:
Get-SysmonConfiguration
A powershell tool by @mattifestation that extracts sysmon rules from the registry:
As an example, looking a bit deeper into the
ProcessCreate rules:We can see the rules almost as they were presented in the sysmon configuration XML file:
A snippet from the actual sysmonconfig-export.xml file:
Bypassing Sysmon
Since Get-SysmonConfiguration gives you the ability to see the rules sysmon is monitoring on, you can play around those.
Another way to bypass the sysmon altogether is explored here:
References
Operating Offensively Against Sysmon
Shell is Only the Beginning
PSSysmonTools/SysmonRuleParser.ps1 at master · mattifestation/PSSysmonTools
GitHub
Allocated filter altitudes - Windows drivers
docsmsft
GitHub - GhostPack/Seatbelt: Seatbelt is a C# project that performs a number of security oriented host-survey "safety checks" relevant from both offensive and defensive security perspectives.
GitHub
​