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. Kevin On Wed, Jun 15, 2016 at 7:25 AM, dan (ddp) <[email protected]> wrote: > On Mon, Jun 13, 2016 at 6:57 PM, Kevin Branch > <[email protected]> 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 [email protected]. > > For more options, visit https://groups.google.com/d/optout. > > -- > > --- > 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 > [email protected]. > For more options, visit https://groups.google.com/d/optout. > -- --- 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 [email protected]. For more options, visit https://groups.google.com/d/optout.
