Incorrect Windows Security 4728 Parsing

[DanielStephens]

There appears to be a problem with the stock windows log parser, particularly with security message 4728. Netwitness query to find these logs is:
msg.id = 'security_4728_microsoft-windows-security-auditing' 

We use this log to monitor for users added to AD groups that have admin privileges. The problem we have been encountering is that the usernames are not parsed correctly. The current user adding the new user is parsed as user.dst, the new user is not parsed at all, and the CN, OU, and DC fields are crammed into user.src. Here is an example.

In the above log, the user making the change is in highlighted in yellow; the user being added is on blue. 

In the meta of this log, you can see the user making the change still appears (as the destination, rather than source user) and the user being added is nowhere to be found. 

Why this matters is for two reasons:

1. Every time we get an alert, we have to navigate to the raw log to figure out the user who was added.

2. We have the AD groups we are monitoring in a list on the reporting engine and they are updated once users are approved to have privileged access. But without meta being generated for the user being added, there is no way to tune out the false positives of approved users being added. 

My questions are:
Does RSA have plans to fix this parser?
What is the level of effort to write a custom windows parser and replace the RSA one? Is that overkill?

[MarcoDemonte]

Hello Daniel,

in our environment (10.6.1) all windows 4728 events are parsed correctly.

I don't believe that the issue you are pointing out is related with the stock parser, I am sorry.

I attach an example of the event 4728 as it arrives in our environment. It is sligthly different.

%NICWIN-4-Security_4728_Microsoft-Windows-Security-Auditing: Security,rn=32695297 cid=1516 eid=476,Mon Nov 14 19:12:35 2016,4728,Microsoft-Windows-Security-Auditing,,Audit Success,MYSERVER.mydomain.local,Security Group Management,,A member was added to a security-enabled global group. Subject: Security ID: S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxxx Account Name: ACCOUNT_DOING_CHANGE Account Domain: MYDOMAIN Logon ID: 0x2A896AD0 Member: Security ID: S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx Account Name: CN=ACCOUNT_MODIFIED,CN=XXXXX,DC=MYDOMAIN,DC=local Group: Security ID: S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxx Group Name: NAME_OF_THE_GROUP Group Domain: MYDOMAIN Additional Information: Privileges: -

PS:

Keep in mind that the user.src is populated in most of the events related to changes, and it is populated with the user that changes (example: password change, user enable/disable, add/remove from groups....)

The user.dst meta is populated with the user that do the change, in these cases.

I hope it could help

Best regards (and sorry for my bad English)

[Anonymous]

Daniel,

I suspect this might have something to do with transient meta.  If you are not familiar, transient meta is something that may be parsed, but not registered as meta and is only something available for that session.  Then, it is discarded.

When I look at the winevent_nic log parser (/etc/netwitness/ng/envision/etc/devices/winevent_nic/v20_winevent_nicmsg.xml) for Security 4728, I see the following:

<MESSAGE
level="6"
parse="1"
parsedefvalue="1"
tableid="85"
id1="Security_4728_Microsoft-Windows-Security-Auditing"
id2="Security_4728_Microsoft-Windows-Security-Auditing"
eventcategory="1402010301"
summary="NIC_B_WINDOWS;sumtype=11;|NIC_B_WINDOWS;key=event_computer;sumtype=12;|NIC_B_WINDOWS;key=event_type;sumtype=13;|NIC_B_WINDOWS;key=category;sumtype=14;|NIC_B_CATEGORIES;sumtype=denied_in;|NIC_B_CATEGORIES;subkey=event_log;sumtype=connection;"
content="&lt;@ec_theme:UserGroup&gt;&lt;@ec_subject:Group&gt;&lt;@ec_activity:Modify&gt;&lt;@ec_outcome:Success&gt;&lt;@:*SYSVAL($MSGID,$ID1)&gt;&lt;@msg:*PARMVAL($MSG)&gt;&lt;@event_log:*HDR(msgIdPart1)&gt;&lt;@event_time:*EVNTTIME($HDR,'%B %F %H:%U:%O %W',Hdatetime)&gt;&lt;@id:*HDR(msgIdPart2)&gt;&lt;@event_source:Microsoft-Windows-Security-Auditing&gt;&lt;@event_type:*HDR(Hevent_type)&gt;&lt;@event_user:*HDR(Hevent_user)&gt;&lt;@event_computer:*HDR(Hevent_computer)&gt;&lt;@category:*HDR(Hcategory)&gt;&lt;@fld61:*PARMVAL(username)&gt;&lt;event_description&gt; Subject: Security ID: &lt;sid&gt; Account Name: &lt;username&gt; Account Domain: &lt;domain&gt; Logon ID: &lt;sessionid&gt; Member: Security ID: &lt;c_sid&gt; Account Name: &lt;c_username&gt; Group: Security ID: &lt;groupid&gt; Group Name: &lt;group&gt; Group Domain: &lt;remote_domain&gt; Additional Information: Privileges: &lt;privilege&gt;" />

The ID being created appears to be placed into a variable called 'c_sid'.

When I look at the table-map.xml (/etc/netwitness/ng/envision/etc/table-map.xml), which maps the log parser variables to Netwitness meta keys, I see what I suspected:

<mapping envisionName="bytes" nwName="bytes" flags="None" format="UInt64" nullTokens="(null)|-"/>
<mapping envisionName="c_domain" nwName="sdomain" flags="Transient" envisionDisplayName="C_Domain|ClientDomain"/>
<mapping envisionName="sdomain" nwName="sdomain" flags="Transient"/>
<mapping envisionName="c_username" nwName="user.src" flags="None" envisionDisplayName="ClientUserName" nullTokens="none|-"/>
<mapping envisionName="c_sid" nwName="user.sid.src" flags="Transient"/>
<mapping envisionName="calling_from" nwName="phone" flags="Transient"/>
<mapping envisionName="calling_to" nwName="phone" flags="Transient"/>

What I typically do next is to update or create a custom table map.  The filename would be /etc/netwitness/ng/envision/table-map-custom.xml. 

You could simply copy the table-map.xml and make it   table-map-custom.xml.  Then, change the    flags="Transient"   to   flags="None"   like so:

<mapping envisionName="c_sid" nwName="user.sid.src" flags="None"/>

Once completed, simply restart the log decoder service.

That SHOULD start writing that meta into the 'user.sid.src' meta key for you.  If that is something you would also like to index, simply add that meta key to the concentrator's index-concentrator-custom.xml.

HOWEVER...

Your logs are showing the domain/user.  If that is what you want, then you should be good.  If you want the username by itself, 'evsxm8' in this case, we may need to introduce a Lua normalization parser and pull out just the username.

Let me know your thoughts on this.

Chris