SYSMON LOGS WEF - Supported ?


SYSMON LOGS WEF - Supported ?

anthony.dolce@paradigmcorp.com

It was a permissions problem.   It was fixed with the following string which gave explicit permission to the Sysmon log.

 wevtutil slMicrosoft-Windows-Sysmon/Operational/ca:O:BAG:SYDSadA;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x1;;;BO)(A;;0x1;;;SO)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)



RandyFranklinSmith

It was a permissions problem.   It was fixed with the following string which gave explicit permission to the Sysmon log.

 wevtutil slMicrosoft-Windows-Sysmon/Operational/ca:O:BAG:SYDSadA;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x1;;;BO)(A;;0x1;;;SO)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)



Wow that's interesting.  That doesn't happen on my test system which is Windows 10 with Sysmon 6.03.  I think that could also be done via group policy.  We'll try to get a KB article written up on this for posterity.  Thank you very much for sharing the solution.  Do you have Network Service as a member of Event Log Readers local group, I wonder.

anthony.dolce@paradigmcorp.com

RandyFranklinSmith - 6/16/2017
It was a permissions problem.   It was fixed with the following string which gave explicit permission to the Sysmon log.

 wevtutil slMicrosoft-Windows-Sysmon/Operational/ca:O:BAG:SYDSadA;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x1;;;BO)(A;;0x1;;;SO)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)



Wow that's interesting.  That doesn't happen on my test system which is Windows 10 with Sysmon 6.03.  I think that could also be done via group policy.  We'll try to get a KB article written up on this for posterity.  Thank you very much for sharing the solution.  Do you have Network Service as a member of Event Log Readers local group, I wonder.

Network Service is part of the Event Log Readers group.   I did not setup SysMon so it might be somewhere in how it was installed.   What I can tell you is that it is not a unique problem because while researching on the open internet there were a few posts where this happened and the first thing to check was the Event Log Readers group but nobody knew how to grant the explicit permission until now.

RandyFranklinSmith

I would love to know what the original permissions where because on my test system my sysmon log perms are: O:BAG:SYDSadA;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x1;;;BO)(A;;0x1;;;SO)(A;;0x1;;;S-1-5-32-573)
S-1-5-32-573 = EventLogReaders
This is Windows 10 with sysmon 6.01 and I didn't change them so that should be the defaults.
So if Network Service is a member of Event Log Readers it shouldn't be necessary to add the S-1-5-20 which is for Network Service.
In your case one of the 3 things must be true:
  • Your default permissions on the sysmon log were different than mine (hard to believe)
  • Someone changed your default permissions (unlikely)
  • Network Service is actually not a member of Event Log Readers on that computer
  • That computers has not been rebooted or klist purged since adding Network Service to Event Log Readers
It would be nice if you had another system you could check the sysmon perms on by running "wevtutil gl Microsoft-Windows-Sysmon/Operational"

I'm harping on this because I'm hoping we don't have to have customers configure sysmon log permissions normally.  There isn't a group policy option for it like there is for the Security Log permissions.  My assumption is that default permissions on sysmon and other logs give Event Log Readers access and it's a matter of making sure that Network Service is a member of that group and that systems either get bounced or klist purged to make sure it takes affect.

https://support.logbinder.com/Supercharger/50136/9-How-To-Purge-Kerberos-Ticket-via-Group-Policy-using-Klist?Keywords=klist



anthony.dolce@paradigmcorp.com

RandyFranklinSmith - 6/19/2017
I would love to know what the original permissions where because on my test system my sysmon log perms are: O:BAG:SYDSadA;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x1;;;BO)(A;;0x1;;;SO)(A;;0x1;;;S-1-5-32-573)
S-1-5-32-573 = EventLogReaders
This is Windows 10 with sysmon 6.01 and I didn't change them so that should be the defaults.
So if Network Service is a member of Event Log Readers it shouldn't be necessary to add the S-1-5-20 which is for Network Service.
  • Your default permissions on the sysmon log were different than mine (hard to believe)
  • Someone changed your default permissions (unlikely)
  • Network Service is actually not a member of Event Log Readers on that computer
  • That computers has not been rebooted or klist purged since adding Network Service to Event Log Readers
It would be nice if you had another system you could check the sysmon perms on by running "wevtutil gl Microsoft-Windows-Sysmon/Operational"

I'm harping on this because I'm hoping we don't have to have customers configure sysmon log permissions normally.  There isn't a group policy option for it like there is for the Security Log permissions.  My assumption is that default permissions on sysmon and other logs give Event Log Readers access and it's a matter of making sure that Network Service is a member of that group and that systems either get bounced or klist purged to make sure it takes affect.

https://support.logbinder.com/Supercharger/50136/9-How-To-Purge-Kerberos-Ticket-via-Group-Policy-using-Klist?Keywords=klist


 will do.  Since it is only installed and working on my personal laptop at this point I can get the settings and output from the next ones we attempt later in the week.


A

RandyFranklinSmith - 6/19/2017
I would love to know what the original permissions where because on my test system my sysmon log perms are: O:BAG:SYDSadA;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x1;;;BO)(A;;0x1;;;SO)(A;;0x1;;;S-1-5-32-573)
S-1-5-32-573 = EventLogReaders
This is Windows 10 with sysmon 6.01 and I didn't change them so that should be the defaults.
So if Network Service is a member of Event Log Readers it shouldn't be necessary to add the S-1-5-20 which is for Network Service.
  • Your default permissions on the sysmon log were different than mine (hard to believe)
  • Someone changed your default permissions (unlikely)
  • Network Service is actually not a member of Event Log Readers on that computer
  • That computers has not been rebooted or klist purged since adding Network Service to Event Log Readers
It would be nice if you had another system you could check the sysmon perms on by running "wevtutil gl Microsoft-Windows-Sysmon/Operational"

I'm harping on this because I'm hoping we don't have to have customers configure sysmon log permissions normally.  There isn't a group policy option for it like there is for the Security Log permissions.  My assumption is that default permissions on sysmon and other logs give Event Log Readers access and it's a matter of making sure that Network Service is a member of that group and that systems either get bounced or klist purged to make sure it takes affect.

https://support.logbinder.com/Supercharger/50136/9-How-To-Purge-Kerberos-Ticket-via-Group-Policy-using-Klist?Keywords=klist



I was also having problems forwarding sysmon logs (error code 5004). The output of wevtutil gl for Microsoft-Windows-Sysmon/Operational was the same as Randy's test machine.
I then edited the permissions with the command above from Microsoft which basically added the SID of the network service and that fixed the problem. My workstation is Windows 7 with Sysmon 7.03. This was already configured for Event Forwarding but just for security logs (for which permissions of the Network Service are set via GPO).




enrique.gonzales

RandyFranklinSmith - 6/19/2017
I would love to know what the original permissions where because on my test system my sysmon log perms are: O:BAG:SYDSadA;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x1;;;BO)(A;;0x1;;;SO)(A;;0x1;;;S-1-5-32-573)
S-1-5-32-573 = EventLogReaders
This is Windows 10 with sysmon 6.01 and I didn't change them so that should be the defaults.
So if Network Service is a member of Event Log Readers it shouldn't be necessary to add the S-1-5-20 which is for Network Service.
  • Your default permissions on the sysmon log were different than mine (hard to believe)
  • Someone changed your default permissions (unlikely)
  • Network Service is actually not a member of Event Log Readers on that computer
  • That computers has not been rebooted or klist purged since adding Network Service to Event Log Readers
It would be nice if you had another system you could check the sysmon perms on by running "wevtutil gl Microsoft-Windows-Sysmon/Operational"

I'm harping on this because I'm hoping we don't have to have customers configure sysmon log permissions normally.  There isn't a group policy option for it like there is for the Security Log permissions.  My assumption is that default permissions on sysmon and other logs give Event Log Readers access and it's a matter of making sure that Network Service is a member of that group and that systems either get bounced or klist purged to make sure it takes affect.

https://support.logbinder.com/Supercharger/50136/9-How-To-Purge-Kerberos-Ticket-via-Group-Policy-using-Klist?Keywords=klist



I have installed sysmon 7.03 and I faced this same issue. I managed to install sysmon with GP and added the command to change the permissions to the batch file, but I'm not sure why it takes long time for the events to show up in the collector. I have applications events that are being collected from all my workstations and they show up really quick in the collector but sysmons events always are behind like 30-40 mins... I used the default refresh time=900. Im not sure if this might be the issue here, also I'm filtering the sysmon events to only forward when I open an application, could this be the issue here?  here is the xpath filter that I'm using:

<QueryList>
<Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
  <Select Path="Microsoft-Windows-Sysmon/Operational">*[System[(EventID=1)]]</Select>
  <Suppress Path="Microsoft-Windows-Sysmon/Operational"> *[EventData[Data[@Name='CurrentDirectory'] = 'C:\Windows\CCM\']] or *[EventData[(Data[@Name='LogonId'] = '0x3e7' or Data[@Name='LogonId'] = '0x3e4' or Data[@Name='LogonId'] = '0x3e5')]] or *[EventData[Data[@Name='ParentImage'] = 'C:\Windows\System32\svchost.exe']]
</Suppress>
</Query>
</QueryList>

I used the Custom view in my workstation to test and it works... but I'm new to xpath or xml, and I'm not sure if this filter is configure correctly. 

bjvista

enrique.gonzales - 6/26/2018
RandyFranklinSmith - 6/19/2017
I would love to know what the original permissions where because on my test system my sysmon log perms are: O:BAG:SYDSadA;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x1;;;BO)(A;;0x1;;;SO)(A;;0x1;;;S-1-5-32-573)
  • Your default permissions on the sysmon log were different than mine (hard to believe)
  • Someone changed your default permissions (unlikely)
  • Network Service is actually not a member of Event Log Readers on that computer
  • That computers has not been rebooted or klist purged since adding Network Service to Event Log Readers
It would be nice if you had another system you could check the sysmon perms on by running "wevtutil gl Microsoft-Windows-Sysmon/Operational"

I'm harping on this because I'm hoping we don't have to have customers configure sysmon log permissions normally.  There isn't a group policy option for it like there is for the Security Log permissions.  My assumption is that default permissions on sysmon and other logs give Event Log Readers access and it's a matter of making sure that Network Service is a member of that group and that systems either get bounced or klist purged to make sure it takes affect.

https://support.logbinder.com/Supercharger/50136/9-How-To-Purge-Kerberos-Ticket-via-Group-Policy-using-Klist?Keywords=klist



I have installed sysmon 7.03 and I faced this same issue. I managed to install sysmon with GP and added the command to change the permissions to the batch file, but I'm not sure why it takes long time for the events to show up in the collector. I have applications events that are being collected from all my workstations and they show up really quick in the collector but sysmons events always are behind like 30-40 mins... I used the default refresh time=900. Im not sure if this might be the issue here, also I'm filtering the sysmon events to only forward when I open an application, could this be the issue here?  here is the xpath filter that I'm using:

<QueryList>
<Query Id="0" Path="Microsoft-Windows-Sysmon/Operational">
  <Select Path="Microsoft-Windows-Sysmon/Operational">*[System[(EventID=1)]]</Select>
  <Suppress Path="Microsoft-Windows-Sysmon/Operational"> *[EventData[Data[@Name='CurrentDirectory'] = 'C:\Windows\CCM\']] or *[EventData[(Data[@Name='LogonId'] = '0x3e7' or Data[@Name='LogonId'] = '0x3e4' or Data[@Name='LogonId'] = '0x3e5')]] or *[EventData[Data[@Name='ParentImage'] = 'C:\Windows\System32\svchost.exe']]
</Suppress>
</Query>
</QueryList>

I used the Custom view in my workstation to test and it works... but I'm new to xpath or xml, and I'm not sure if this filter is configure correctly. 

Please note that the above commands need to be run in a Command Prompt with Admin rights, not PowerShell.  And the string is:

wevtutil sl Microsoft-Windows-Sysmon/Operational /ca:O:BAG:SYDSadA;;0xf0007;;;SY)(A;;0x7;;;BA)(A;;0x1;;;BO)(A;;0x1;;;SO)(A;;0x1;;;S-1-5-32-573)(A;;0x1;;;S-1-5-20)

There is a space between sl and "Microsoft" and a space after Operational.  And the little smiley face shouldn't be there.  It should be S, Y, D, then a colon and then an open parenthesis then A.
Edited
9 Months Ago by bjvista
GO


Similar Topics


Reading This Topic


Login
Existing Account
Email Address:


Password:


Select a Forum....








LOGbinder Forum


Search