Rendering of access rights codes in Windows audit logs

267 views
Skip to first unread message

Kevin Branch

unread,
Jun 13, 2016, 6:57:35 PM6/13/16
to ossec-list
I've noticed that while the Windows Event Viewer shows fairly human readable information in audit records, like this audit log section:

	Access Reasons:		READ_CONTROL:	Granted by	D:(A;ID;0x1200a9;;;BU)
				SYNCHRONIZE:	Granted by	D:(A;ID;0x1200a9;;;BU)
				ReadData (or ListDirectory):	Granted by	D:(A;ID;0x1200a9;;;BU)
				ReadEA:	Granted by	D:(A;ID;0x1200a9;;;BU)
				ReadAttributes:	Granted by	D:(A;ID;0x1200a9;;;BU)

that the underlying XML of the same Windows log entry is full of %% codes in place of human readable terms, like this:

 <Data Name="AccessReason">%%1538:	%%1801	D:(A;ID;0x1200a9;;;BU)
				%%1541:	%%1801	D:(A;ID;0x1200a9;;;BU)
				%%4416:	%%1801	D:(A;ID;0x1200a9;;;BU)
				%%4419:	%%1801	D:(A;ID;0x1200a9;;;BU)
				%%4423:	%%1801	D:(A;ID;0x1200a9;;;BU)
				</Data>

Would it be plausible to have the OSSEC Windows agent render this content using the same facility that the Windows Event Viewer does, before sending the event along to the OSSEC server?  

I use OSSEC agents to convey Windows logs back to my OSSEC server for analysis and stashing into my ELK system.  While I will probably do textual search and replace on the ELK side to resolve this issue for now, it strikes me there would be broader benefit to the OSSEC Windows community if the OSSEC agent itself were to render "Access List" and "Access Reason" elements of Windows audit log records in the same way that the Windows Event Viewer does.

Thanks for listening,
Kevin

dan (ddp)

unread,
Jun 15, 2016, 7:27:18 AM6/15/16
to ossec...@googlegroups.com
On Mon, Jun 13, 2016 at 6:57 PM, Kevin Branch
<ke...@branchnetconsulting.com> wrote:
> I've noticed that while the Windows Event Viewer shows fairly human readable
> information in audit records, like this audit log section:
>
> Access Reasons: READ_CONTROL: Granted by D:(A;ID;0x1200a9;;;BU)
> SYNCHRONIZE: Granted by D:(A;ID;0x1200a9;;;BU)
> ReadData (or ListDirectory): Granted by D:(A;ID;0x1200a9;;;BU)
> ReadEA: Granted by D:(A;ID;0x1200a9;;;BU)
> ReadAttributes: Granted by D:(A;ID;0x1200a9;;;BU)
>
>
> that the underlying XML of the same Windows log entry is full of %% codes in
> place of human readable terms, like this:
>
> <Data Name="AccessReason">%%1538: %%1801 D:(A;ID;0x1200a9;;;BU)
> %%1541: %%1801 D:(A;ID;0x1200a9;;;BU)
> %%4416: %%1801 D:(A;ID;0x1200a9;;;BU)
> %%4419: %%1801 D:(A;ID;0x1200a9;;;BU)
> %%4423: %%1801 D:(A;ID;0x1200a9;;;BU)
> </Data>
>
>
> Would it be plausible to have the OSSEC Windows agent render this content
> using the same facility that the Windows Event Viewer does, before sending
> the event along to the OSSEC server?
>

Would this require the agent to decode the information first?
Do you have a link to the facility you're talking about?

>
> I use OSSEC agents to convey Windows logs back to my OSSEC server for
> analysis and stashing into my ELK system. While I will probably do textual
> search and replace on the ELK side to resolve this issue for now, it strikes
> me there would be broader benefit to the OSSEC Windows community if the
> OSSEC agent itself were to render "Access List" and "Access Reason" elements
> of Windows audit log records in the same way that the Windows Event Viewer
> does.
>
>
> Thanks for listening,
>
> Kevin
>
> --
>
> ---
> You received this message because you are subscribed to the Google Groups
> "ossec-list" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to ossec-list+...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

Kevin Branch

unread,
Jun 15, 2016, 9:24:24 AM6/15/16
to ossec...@googlegroups.com
I think it would be ideal for the agent to decode the %% access rights codes and then send the logs along looking like the Windows event viewer would display them.  Not only would the stored logs be much easier to meaningfully review, but also building OSSEC rules to fire on specific audit events would be easier as the names of access rights rather than the codes could be keyed on.

I would like to think there was a Window API call for getting the access rights name that corresponds to a given %% code, but I have very little insight at this level, not having Windows development experience.  If a suitable API call cannot be found, it does appear that the number of codes is small enough that it could be hard coded into the agent, assuming the codes are consistent across Windows versions.  For example, there are about 15 access rights names associated with file audit events according to:


I have been tasked by a client to set up Logstash translation of %% access rights codes to names in Windows audit logs events.  Once I have a table of codes to names worked out, would you all be interested in potentially incorporating it into the OSSEC agent?  I'd be happy to share it.   

Kevin




You received this message because you are subscribed to a topic in the Google Groups "ossec-list" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/ossec-list/Jb2mhBrf_FQ/unsubscribe.
To unsubscribe from this group and all its topics, send an email to ossec-list+...@googlegroups.com.

dan (ddp)

unread,
Jun 16, 2016, 9:38:46 AM6/16/16
to ossec...@googlegroups.com
On Wed, Jun 15, 2016 at 9:24 AM, Kevin Branch
<ke...@branchnetconsulting.com> wrote:
> I think it would be ideal for the agent to decode the %% access rights codes
> and then send the logs along looking like the Windows event viewer would
> display them. Not only would the stored logs be much easier to meaningfully
> review, but also building OSSEC rules to fire on specific audit events would
> be easier as the names of access rights rather than the codes could be keyed
> on.
>
> I would like to think there was a Window API call for getting the access
> rights name that corresponds to a given %% code, but I have very little
> insight at this level, not having Windows development experience. If a
> suitable API call cannot be found, it does appear that the number of codes
> is small enough that it could be hard coded into the agent, assuming the
> codes are consistent across Windows versions. For example, there are about
> 15 access rights names associated with file audit events according to:
>
>
> https://msdn.microsoft.com/en-us/library/windows/desktop/aa364399(v=vs.85).aspx
>
>
> I have been tasked by a client to set up Logstash translation of %% access
> rights codes to names in Windows audit logs events. Once I have a table of
> codes to names worked out, would you all be interested in potentially
> incorporating it into the OSSEC agent? I'd be happy to share it.
>

We can definitely take a look at it, but if it requires the agent to
decode the message before passing it to the manager, I wouldn't have
high hopes for the added functionality.
Reply all
Reply to author
Forward
0 new messages