topic Re: Suspected false positives in FMC in Network Security

Suspected false positives in FMC

AFlack20 — Sat, 13 Feb 2021 01:50:15 GMT

This morning when I logged into our FMC I had several new IOC's on my context explorer, all of which were related to CnC connection attempts. After getting into the analysis and using the talos lookup tool on the IP address associated with these events, they're all looking fairly benign. Most were to IP's that according to talos belong to amazon cloud-front with a neutral reputation the remaining were cloudflare connections with same neutral reputation.

The IP's are as follows: 54.230.125.230 54.230.125.6 99.84.199.157 54.230.125.123 99.84.199.145 54.230.125.68 172.67.190.148

Assuming that these IP's aren't malicious CnC servers, as indicated by talos tool, why are they showing up as that in my FMC? I can see that these events are showing up under the security intelligence category of URL CnC. I don't know where the URL CnC is drawing from to determine what is "Bad" and to blacklist, but I would assume it would be talos? Lastly how would I edit this policy? If I go into Policies -> Access Control -> My Policy -> Security Intelligence, and under Blacklist is URL CnC, but I don't see any means in which to edit URL CnC there?

I would be appreciative if the Cisco team could advise as to what the best practice would be for adjusting the URL CnC blacklist, and whether I should just whitelist the IP addresses that were indicated above.

Thanks!

Re: Suspected false positives in FMC

Marvin Rhoads — Sat, 13 Feb 2021 06:09:49 GMT

The listing of what's included in both IP and URL security intelligence categories comes from the Cisco Security Intelligence feeds (TALOS-provided) which you can see under Objects > Security Intelligence. By default they are updated by FMC every 2 hours in the background and then pushed out to be immediately available on your managed devices.

If you want to whitelist addresses that would otherwise be indicated as malicious, you can do so from the same object management page. Generally you create a text file with the objects and upload it to FMC. You can also right click on the address in the events listing and choose "Whitelist now".

It might be worth opening a TAC case to understand why these particular addresses were identified as being associated with CnC events. They appear benign to me as well based on checking the TALOS site (and Threatgrid and Shodan) via SecureX / Cisco Threat Response.

Re: Suspected false positives in FMC

Marius Gunnerud — Sat, 13 Feb 2021 19:59:52 GMT

You can go to https://talosintelligence.com/ and lookup the websites you have questions about and you will see the reputation they are being assigned.

I had a similar issue after upgrading from 6.4.x to 6.6.1.x. I contacted TAC regarding this and they said that they can not do anything about this blocked site as this might jeopardise the integrity of the automated calculations and that the only way to allow this is to either add specific ACP rules for the sites or whitelist them.

So, that will be the basic reply you will get from TAC if you try to contact them.

Re: Suspected false positives in FMC

AFlack20 — Tue, 16 Feb 2021 01:06:40 GMT

Thanks Marvin and Marius. When navigating to the objects -> security intelligence -> url lists & feeds, I don't see any feeds. Could that possibly be because we don't have a license for URL filtering?

We're running 6.6.1 as well so perhaps these IP's being flagged could just be a bug with 6.6.1?

Re: Suspected false positives in FMC

Marius Gunnerud — Tue, 16 Feb 2021 07:37:14 GMT

Security intelligence is included in the Threat license. It is not a bug, but more likely that the Talos automated systems do not yet have enough information on the sites to provide a different reputation. As mentioned above, the only way to allow this traffic immediately is to whitelist it. Otherwise you will need to wait for the Talos system to reassess the webiste reputation.s

Re: Suspected false positives in FMC

keithcclark71 — Tue, 29 Jun 2021 14:00:29 GMT

Old thread but I thought i'd touch base on also as I am going down the same road. If we look at packet that for me is related to snort signature MALWARE-CNC DNS Fast Flux attempt (1:57756:2). I believe the rule is flagging as an Intrusion event due to the returned small TTL value of the record as shown below. I think load balancers out there when left at default settings have very low TTL for domain names associated with them or admins purposely setting to such a low value as to avoid some stale record cache to constantly keep the DNS servers updating.

wd-prod-ss.trafficmanager.net: type A, class IN
Name: wd-prod-ss.trafficmanager.net
Type: A (Host address)
Class: IN (0x0001)
wd-prod-ss.trafficmanager.net: type CNAME, class IN, cname wd-prod-ss-us-west-2-fe.westus.cloudapp.azure.com
Name: wd-prod-ss.trafficmanager.net
Type: CNAME (Canonical name for an alias)
Class: IN (0x0001)
Time to live: 4 minutes, 22 seconds
Data length: 51
Primaryname: wd-prod-ss-us-west-2-fe.westus.cloudapp.azure.com
wd-prod-ss-us-west-2-fe.westus.cloudapp.azure.com: type A, class IN, addr 104.42.196.205
Name: wd-prod-ss-us-west-2-fe.westus.cloudapp.azure.com
Type: A (Host address)
Class: IN (0x0001)
Time to live: 5 seconds
Data length: 4
Addr: 104.42.196.205
<Root>: type OPT
Name: <Root>
Type: OPT (EDNS0 option)
UDP payload size: 4096
Higher bits in extended RCODE: 0x0
EDNS0 version: 0
Z: 0x8000
Bit 0 (DO bit): 1 (Accepts DNSSEC security RRs)
Bits 1-15: 0x0 (reserved)
Data length: 0