2021-08-18 09:00 AM
Hi Experts,
We are using netwitness version 11.5.2.
In the course of our investigation and working to build use case in Netwitness for Cisco Sourcefire, i notice that the signature id was generate occasionally from the log events.
We noticed that the result from the meta “Signature ID” is not constant, some of the value of signature id from the logs are not parse into this meta.
For example , the following 2 signature from sourcefire
the signature is was 21546 and 32609 and it should be parse in netwitness as the following meta : sig.id
The log format is the same for all the log events, but somehow, not all signature id are parse into the meta.
Even for the same signature, one of them will be parse in, some will not.
Is there any way to resolve it ? or anyone have the issue with with us ?
Thank you.
2021-08-18 12:02 PM - edited 2021-08-18 12:02 PM
@Randolph Can you share some of the log samples - both ones that do parse correctly and others that don't?
2021-08-18 10:40 PM
able to parse with sig.id
Aug 19 01:25:21 SG1-03-IPS-TTT SFNTDROPSG: Correlation Event: Not Dropped Events/Not Dropped Event - Logging at Thu Aug 19 01:25:21 2021 UTC: [1:21546:4] "MALWARE-CNC Possible host infection - excessive DNS queries for .cn" [Impact: Currently Not Vulnerable] From "SGSG03-AA-IPS04" at Thu Aug 19 01:25:20 2021 UTC [Classification: A Network Trojan was Detected] [Priority: 1] {udp} 000.000.000.00:1179 (unknown)->8.8.8.8:53 (united states)
unable to parse sig.id
Aug 18 21:35:46 SG1-03-IPS-TTT SFNTDROPSG: Correlation Event: Not Dropped Events/Not Dropped Event - Logging at Wed Aug 18 21:35:46 2021 UTC: [1:41374:3] "MALWARE-CNC Win.Trojan.NetWiredRC variant registration message" [Impact: Vulnerable] From "SGSG03-GGT-IPS01" at Wed Aug 18 21:35:46 2021 UTC [Classification: A Network Trojan was Detected] [Priority: 1] {tcp} 00.00.000.00:34100 (unknown)->00.000.00.000:27035 (unknown)
2021-08-18 10:47 PM
above with Sig.id
above without Sig.id
2021-08-19 04:14 PM - edited 2021-08-19 04:15 PM
The reason for the different parsing result is actually due to that sig.id value. The snort parser attempts to use the value in the sig.id field as the msg.id - if there is a defined msg.id matching that value, then it uses that specific msg.id to parse the log, but if there is not a defined msg.id matching that value then the parser uses the generic "Snort_AlertLog" msg.id.
'21546' being used as the msg.id:
'41374' without a matching msg.id:
A couple options you have to get '41374' parsed into the sig.id metakey:
2021-08-19 10:33 PM
Hi @JoshRandall ,
Thank you for the finding, we have quite a number of signatures that are not able to parse correctly.
There are thousands of signatures from Cisco Sourcefire, does it mean that for every signature that come in, we will need to add a custom parse?
2021-08-20 12:14 PM
If the logs that do not have the sig.id parsed are all being handled by msg.id "Snort_AlertLog" then you'd only need to add/modify that. But if those events are being handled by other msg.ids then you'd likely want/need to modify those others, as well.