Strange behaviour of Security Analytics

[Anonymous]

Hi All,

I was just building an rule related to failed logon followed by successful logon for the same i just use an integrated window system by attempting failed logon and then successful logon.

But when i was investigating the events i saw a very strange behaviour of Security analytics. there was some event was in audit failure category but in ec.outcome it was showing successful and in last event.cat.name is  "user.activity.successful.logins" as the part of investigation i move to log view and found log is related to failure event, i thought it could be an parser issue.

So, i select other event for the audit failure and found its parsed correctly so its not a parser issue because a incorrect parser cant parsed one event correctly and other one incorrectly.

one failure event is parsed as correctly while other event is showing event type = audit failure but ec.outcome = success

please refer screenshots for the same.

is there anyone who can justify this behaviour of SA or SA is trusty for monitoring?

if i create a report with ec.outcome then this event will come in successful login or if i create a report using event type = audit failure then event will come in failure event.

plz Suggest what should i do to get a proper report from SA, i cant check every event in investigation.

[RSAAdmin]

Hi Rajveer,

Thank you for stating the problem in detail.

This could be a parser related issue. The screenshot of the two events with their metas that you have displayed are matched by two separate content definitions in the winevent_nic parser.

For example, if you see the first event which has event.type = "Audit Failure" but ec.outcome = "Success", it has msg.id = "Security_4776_Microsoft-Windows-Security-Auditing". It indicates that this event is matched by the message definition in /etc/netwitness/ng/envision/etc/devices/winevent_nic/v20_winevent_nicmsg.xml that has id1="Security_4776_Microsoft-Windows-Security-Auditing". This message definition defines ec_outcome = "Success"

But if you see the second event which has event.type = "Audit Failure" but ec.outcome = "Failure", it has msg.id = "Security_4625_Microsoft-Windows-Security-Auditing". This event is matched by the message definition in the same XML that has id1="Security_4625_Microsoft-Windows-Security-Auditing". It defines ec_outcome = "Failure".

So the question now is: Why does the first event match a message definition that defines ec_outcome = "Success" instead of one that defines ec_outcome = "Failure"?

To dig deeper into this, I'll need the complete event from the first screenshot in text format. You can provide it to by clicking the 'Export Logs' button (visible in your screenshot). When it asks you to select export format, specify "Text". Then go to Profile > Jobs, download the exported log, copy the entire log from it and paste it as a comment here. This will help me to have the exact event (byte for byte) that I can feed to my Log Decoder and troubleshoot the issue.

Thanks,

Susam

[RSAAdmin]

Hi Rajveer,

I was able to find the root cause of this issue by copying the event in text format from your screenshot and feeding it to my Log Decoder. The problematic event is:

%NICWIN-4-Security_4776_Microsoft-Windows-Security-Auditing: Security,rn=3028054 cid=4244 eid=628,Wed Nov 19 23:18:19 2014,4776,Microsoft-Windows-Security-Auditing,,Audit Failure,MACHINE.infosec.com,Credential Validation,,The computer attempted to validate the credentials for an account. Authentication Package: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Logon Account: Administrator Source Workstation: G4-PC Error Code: 0xc000006a

This event is supposed to match the message definition in /etc/netwitness/ng/envision/etc/devices/winevent_nic/v20_winevent_nicmsg.xml that has id1="Security_4776_Microsoft-Windows-Security-Auditing:02". However, it doesn't because, the above event from Windows contains "Error Code: 0xc000006a" in the end, whereas the message definition for id1="Security_4776_Microsoft-Windows-Security-Auditing:02" in the XML attempts to match "Error Code: 0xc000006A". The difference in case, i.e. "6a" vs. "6A", causes the issue.

This looks like an issue in the parser. I'll let our engineers who work on the parser know about this issue.

Until this issue is fixed, I believe, you'll have to stick with event.type = "Audit Failure" for your reports. The event.type meta is extracted directly from the event and therefore would be correct for all types of Windows events.

I hope this answers your question.

Thanks,

Susam

[Anonymous]

Hi Susam,

Thank you so much for detailed explanation of root causes of this issue. I appreciate your efforts.

Thanks again

Rajveer