03-29-2020 10:30 PM
Hello
Who could tell me how to be sure whether this IPS event (MALWARE-CNC User-Agent known malicious user-agent string AutoIt ) is false positive. I get this notification very often.
Device : firepower
Timestamp : 2020-03-30 10:18:53
Protocol : tcp
Alert Message : MALWARE-CNC User-Agent known malicious user-agent string AutoIt (1:18347:10)
Session : x.x.x.x:49644 -> 209.95.55.249:80
[*] 0 more events originated from this Source IP
Solved! Go to Solution.
03-30-2020 12:53 AM
Well we have a saying "the packets don't lie".
Your packet view that you provided clearly shows the user string so it's definitely not a false positive.
If I am ever in doubt, I use that method to prove (usually to a customer) why Firepower (or more accurately the Talos security intelligence researchers who develop the rules) considers the rule as a true positive.
03-29-2020 11:40 PM - edited 03-29-2020 11:41 PM
If you are getting an Intrusion Event, you can drill down in FMC under Analysis > Intrusions > Events and go into the Packets workflow. There you can see the actual packets and verify if the user-agent string specified in the Snort rule is present.
Here's the reference for that rule:
https://snort.org/rule_docs/1-18347
...and the associated Snort rule:
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS (msg:"MALWARE-CNC User-Agent known malicious user-agent string AutoIt"; flow:to_server,established; content:"User-Agent|3A| AutoIt|0D 0A|"; fast_pattern:only; http_header:; metadata:impact_flag red, service http; reference:url,snort.org/rule_docs/1-18347; classtype:trojan-activity; sid:18347; rev:10; gid:1; )
That rule is disabled by default in a Balanced Security and Connectivity IPS ruleset.
03-30-2020 12:14 AM
Thank you Marvin for you info. I checked the packet in firewall and observed that the string in the packet is same with Snor rule. so this means that it is not false positive right? I should use the method you taught me when i need to be sure whether the event is false positive or not, right? If user string in the packet is same with Snort rule, it means it is 100 persent true positive
this is packet firewall captured, and snort rule
alert tcp $HOME_NET any -> $EXTERNAL_NET $HTTP_PORTS
(msg:"MALWARE-CNC User-Agent known malicious user-agent string AutoIt";
flow:to_server,established; content:"User-Agent|3A| AutoIt|0D 0A|";
fast_pattern:only; http_header; metadata:impact_flag red, service http; reference:url,snort.org/rule_docs/1-18347; classtype:trojan-activity; sid:18347; rev:10; gid:1; )
..u.L=.M..0.......E...(.@.......S@._7....P....$.2.P.......GET /drupal/sites/default/files/WebFM/admin/files/Spreadsheet_Compare/Version.ini HTTP/1.1 User-Agent: AutoIt Host: thefoolonthehill.net Cache-Control: no-cache
03-30-2020 12:53 AM
Well we have a saying "the packets don't lie".
Your packet view that you provided clearly shows the user string so it's definitely not a false positive.
If I am ever in doubt, I use that method to prove (usually to a customer) why Firepower (or more accurately the Talos security intelligence researchers who develop the rules) considers the rule as a true positive.
03-30-2020 01:04 AM
Let me summarize our discussion. every time i get IPS event, first i must look at Packet's User-agent string and if it is same with snort rule it means it is definitely true positive. If i am right, please confirm. thanks so much
03-31-2020 04:28 AM
No, you don't need to check every time because Firepower has a VERY low false positive rate. I only check the packets if there is doubt or question from the customer that the event may not be a true positive.
03-31-2020 05:26 AM
Hello Marvin
i get same notification every day. what i shoud do with that notification? i asked the user to run antivirus maybe some agent would be found and deleted but we fail to find out what cause the event being triggered. do you think blocking that ip address would solve the problem?
03-31-2020 10:39 AM
Since the Firepower is identifying it as an intrusion event it should already be blocking the destination IP address.
To ascertain what might be causing it on the endpoint can be a bit more difficult. If whatever endpoint protection is not already catching it, a deeper investigation may be required. I would typically use something like SysInternals tcpview utility in Windows to determine what process (if it's not the browser) is making the connections to the address shown in the event.
Discover and save your favorite ideas. Come back to expert answers, step-by-step guides, recent topics, and more.
New here? Get started with these tips. How to use Community New member guide