Lookup/extract value from key in CDB List, and place it event.

[InfoSec]

In the following important (sanitized) event, Windows correctly reports the member Security ID, but the account name is a dash (in red below):

2018 Jul 07 00:11:46 WinEvtLog: Security: AUDIT_SUCCESS(4732): Microsoft-Windows-Security-Auditing: (no user): no domain: Sanitized: A member was added to a security-enabled local group.    Subject:   Security ID:  S-1-5-18   Account Name:  SANITIZED$   Account Domain:  SANITIZED   Logon ID:  0x3E7    Member:   Security ID:  S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx   Account Name:  -    Group:   Security ID:  S-1-5-32-544   Group Name:  Administrators   Group Domain:  Builtin    Additional Information:   Privileges:  -

In Wazuh, Is there a way to:

 i) Extract the member account name from a CDB list consisting of Security_ID:Account_Name; and

ii) Replace the '-' in member account name by the resolved account name from the Security_ID:Account_Name CDB list?

This substitution could be performed post-Wazuh in a LogStash mutation, but I would rather see the correction of the shortsightedness of Windows addressed close to the source - i.e. in Wazuh if possible.

[alfonso.r...@wazuh.com]

Hello InfoSec,

Sometimes it can happen that our way of obtaining the log events of windows is not correct and produces failures, therefore the first thing we should check is if in the windows event viewer we can visualize the field "Account Name". 

If the name of the account appears, it seems that we are getting the event in the wrong way. On the other hand, if it does not appear or appears with the character "-" the event is obtained correctly but does not show any account name. 

In the latter case, I am sorry to say that at the moment in Wazuh we are unable to obtain the name from CBD list account, but we are working on it:  https://github.com/wazuh/wazuh/issues/905

At the moment the best way to save the problem is still to use LogStash. 

Thank you very much for everything, we are waiting for your response to check the result of the display using the Windows event viewer. Do not hesitate to ask any questions you may have. 

Kind regards,

Alfonso Ruiz-Bravo 

[InfoSec]

Here's a copy of the 4732 event from Windows event viewer, which includes both the event and the xml representation.

Wazuh agent seems to be picking up the normal event rather than the xml for this event. They do not match, and Wazuh picks up the less correct one.

Discrepancies:

- Normal event has SID in the name field, and name is a dash

- Wazuh event has SID in the name field, and name is a dash

- XML has correct SID, but name is a dash.

Log Name:      Security
Source:        Microsoft-Windows-Security-Auditing
Date:          2018-07-11 15:01:53
Event ID:      4732
Task Category: Security Group Management
Level:         Information
Keywords:      Audit Success
User:          N/A
Computer:      Sanitized
Description:

A member was added to a security-enabled local group.


Subject:

 Security ID: SYSTEM
 Account Name: SANITIZED$
 Account Domain: SANITIZED
 Logon ID: 0x3E7


Member:
 Security ID: SANITIZED\Sanitized <-- Problem: domain\account name instead of Security ID.
 Account Name: - <-- Problem: Security ID is left as a dash instead of domain\account.


Group:
 Security ID: BUILTIN\Administrators

 Group Name: Administrators
 Group Domain: Builtin


Additional Information:
 Privileges: -

Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Microsoft-Windows-Security-Auditing" Guid="{54849625-5478-4994-A5BA-3E3B0328C30D}" />
    <EventID>4732</EventID>
    <Version>0</Version>
    <Level>0</Level>
    <Task>13826</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8020000000000000</Keywords>
    <TimeCreated SystemTime="2018-07-11T12:01:53.553606400Z" />
    <EventRecordID>15610588</EventRecordID>
    <Correlation ActivityID="{2FECC6D7-18CE-0007-FBC6-EC2FCE18D401}" />
    <Execution ProcessID="1008" ThreadID="28228" />
    <Channel>Security</Channel>
    <Computer>Sanitized</Computer>
    <Security />
  </System>
  <EventData>
    <Data Name="MemberName">-</Data> <-- Problem: - instead of Domain\Account.
    <Data Name="MemberSid">S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx</Data> <-- This is OK, but is NOT picked up correctly by Wazuh.
    <Data Name="TargetUserName">Administrators</Data>
    <Data Name="TargetDomainName">Builtin</Data>
    <Data Name="TargetSid">S-1-5-32-544</Data>
    <Data Name="SubjectUserSid">S-1-5-18</Data>
    <Data Name="SubjectUserName">SANITIZED$</Data>
    <Data Name="SubjectDomainName">SANITIZED</Data>
    <Data Name="SubjectLogonId">0x3e7</Data>
    <Data Name="PrivilegeList">-</Data>
  </EventData>
</Event>

[alfonso.r...@wazuh.com]

Hello InfoSec,

We have been checking how we got the data through Logcollector. Apparently, we get the data from the xml and it looks like you may have a problem with the windows event. As we can see, the fields in the event viewer are there, but they appear with dash and that is how Wazuh collects them. 

What Microsoft Windows operating system is causing the problem?

Thank you very much for your attention.

Kind regards,

Alfonso Ruiz-Bravo

On Saturday, July 7, 2018 at 8:54:52 AM UTC+2, InfoSec wrote:

[InfoSec]

Operating System is Windows 10 Enterprise 1803.

The agent is configured to pick the security log as eventchannel. Why is it picking the Windows event rather than the XML?

[alfonso.r...@wazuh.com]

Hello InfoSec,

Eventchannel does not collect events from the xml, it recovers them in the standard format of the event. Eventchannel reads events using: https://docs.microsoft.com/en-us/windows/desktop/api/winbase/nf-winbase-readeventloga

We have done some research, it is possible that the content of the account name is a dash because the event is related to local groups? or because security principals are used, such as LOCAL SERVICE or ANONYMOUS LOGON?

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/event.aspx?eventID=4732

Thank you very much for your attention.

Kind regards,

Alfonso Ruiz-Bravo

On Saturday, July 7, 2018 at 8:54:52 AM UTC+2, InfoSec wrote: