Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sysmon 14.14 - Anti-Tamper Controls? #167

Open
bobby-mack opened this issue Feb 27, 2023 · 3 comments
Open

Sysmon 14.14 - Anti-Tamper Controls? #167

bobby-mack opened this issue Feb 27, 2023 · 3 comments

Comments

@bobby-mack
Copy link

Following an upgrade from Sysmon version 13.33 to 14.14 (latest) with the "default" pre-generated configuration (balanced config / most used) -- we ran into serious network complications with Windows servers (2016/2019), that essentially rendered them inoperable until a server reboot (i.e. no connections could be made... the servers were actively refusing any inbound connections). I don't really know if the Sysmon config itself would play a part here or not, but I was of the understanding that a restart was not required to commit changes to Sysmon and a simple service recycle would suffice there. Perhaps this is some kind of bug in the upgrade jump or something with the service itself, but I would like some clarification if others can speak to this. Looking for any feedback!

@bobby-mack
Copy link
Author

bobby-mack commented Feb 27, 2023

Just a quick follow-up to my original inquiry on this -- it's not just network connections that are affected; it's every process that grinds to a screeching halt. I believe I've narrowed down the culprit to force-killing the Sysmon64 service as part of my update script, prior to actually passing the -c param and specifying my new config. Attempting to force-kill the process like this:

PowerShell -Command "Get-Process Sysmon64 | Stop-Process -Force"

...results in the command seemingly hanging forever, with some very nasty side effects. In particular, the entire system hangs on any kind of existing or new commands, which ultimately winds up requiring a force reboot by holding down the power button on a physical device, or doing a soft reset of a VM.

It's still a mystery to me why this behavior all of a sudden changed in 14.14; is due to some kind of anti-tampering mechanism or kill switch baked into the service design? Just a theory based on being able to reproduce this myself.

I had noticed a couple registry detections for Sysmon included in the "default" config here, but that shouldn't influence my ability or inability to start/stop services. I feel like I'm missing something here.

<TargetObject name="technique_id=T1562.001,technique_name=Disable or Modify Tools" condition="contains">SYSTEM\CurrentControlSet\services\SysmonDrv</TargetObject> <TargetObject name="technique_id=T1562.001,technique_name=Disable or Modify Tools" condition="contains">SYSTEM\CurrentControlSet\services\Sysmon</TargetObject>

@bobby-mack bobby-mack changed the title Sysmon Upgrade 13.33 > 14.14 = Major Network Problems Sysmon 14.14 - Anti-Tamper Controls? Feb 27, 2023
@technion
Copy link

technion commented Apr 26, 2023

Just adding that I've been using the sysmonconfig-mde-augment.xml version with sysmon 14.16 and struggled for a few days to find the cause of similar issues, with servers becoming unusable in this way. Servers tend to be fine if left online, but if I try to reboot (which attempts to stop this service) nothing will stop properly and you end up power cycling the VM.

@technion
Copy link

technion commented May 1, 2023

@bobby-mack After hours and hours of supplying logs to Microsoft, I suddenly can't replicate this. There hasn't been a Windows update or new version of Sysmon, and I'm wondering if an automated Defender update fixed something.

Would you be able to check updates and let us know your experience?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants