Skip to content

Conversation

@mon0pixel
Copy link

The current method of installing Sysmon and WinlogBeat are opening up security holes due to an insecure ACL that is carried over when the .zip files are extracted. Specific concerns lay around the WinlogBeat folder permissions as any low priv user on the system is able to replace the service binary which the service will attempt to execute as SYSTEM allowing privilege escalation.
image
A potential attacker could also just disable the service causing reduced visibility to the host.
Sysmon is less of a concern as when it installs it copies the binaries to C:\Windows\System32 but should still be secured.
It looks like attempts to prevent this were in place in lines 177-180 but as you can see from the screenshot this was not working.

When the .zip file was being copied over to the C:\Program Files directory it was carrying a ACL rule allowing modify access to the folder for the NT AUTHORITY\Authenticated Users group. By doing it this way the only ACLs placed on the C:\Program Files\Sysmon directory will be the ones inherited by C:\Program Files.
When the .zip file was being copied over to the C:\Program Files directory it was carrying a ACL rule allowing modify access to the folder for the NT AUTHORITY\Authenticated Users group. By doing it this way the only ACLs placed on the C:\Program Files\winlogbeat* directory will be the ones inherited by C:\Program Files.
@mon0pixel
Copy link
Author

The more I look at this the less I think its caused by the .zip file but rather the directory the file is extracted in. Still an issue though.

@william-stearns william-stearns added the bug Existing functionality is broken, incorrect, or not behaving as intended label May 12, 2023
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

bug Existing functionality is broken, incorrect, or not behaving as intended

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants