Community Threats & Threat Intelligence Feeds used by Rapid 7

InsightIDR Alerts
1

Hi!

In our InsightIDR + InsightConnect environment, we use threat intelligence workflows that collect new IOCs like IPs, hashes, phishing websites from different OSINT databases into one of our Community Threats in order to generate alerts. Sometimes I’m not very sure if we actually need to do that or if Rapid 7 uses similar threat intelligence feeds in the background. Does anyone have an idea, which built-in intel feeds InsightIDR uses to detect for example a suspicious C2 IP address or to trigger the Spear-Phishing Alert?

My second question is about alerts that came up several times now in our InsightIDR environment caused by one of our community threats: We received an alert about outbound firewall connectivity to a malicious IP address from our community threat. The destination IP was truly malicious but the source IP in the firewall log was our proxy server. After checking the proxy logs and some research, we noticed that the suspicious destination IP resolved to several legitimate Domains and the user accessed one of these legitimate domains so it was a false positive. I’m wondering if this behavior is unique to our environment or if other customers had the same issue. What could be a good way to create an exception for this?

2

Hi Ge72,

Rapid7’s internal use of Community Threats was superceded with the introduction of the ABA detection Engine, which allowed for feeds to be directly incorporated from multiple sources across multiple regions and, more importantly, curated and vetted by our internal detection experts. So, your supposition is correct - many of the IOCs that are in community threats are already being ingested and automatically applied to all customers via ABA, and the ones that are not are likely to have been excised due to being false positives or excessively noisy. Additionally, just in the last month we have added hundreds of new ABA rules powered by the IntSights/Threat Command threat library and will continue to do so going forward.
To pre-empt a follow on question - whilst we don’t currently display the full lists of IOCs (domains, hashes and so on) that are being used in the ABA rules this is very high up on our roadmap both to improve transparency and to potentially reduce the duplication of effort that might be occurring with customers use of the Community Threat feature.

So, for example, referring to C2 - this rule Network Flow - Destination Address in Cobalt Strike C2 List
has the logic
from( entry_type = "flow" ) where( direction = "OUTBOUND" AND NOT ( destination_port IN ["137", "139", "135", "445", "0"] ) AND SUBQUERY("Cobalt Strike C2 List") AND SUBQUERY("Cobalt Strike C2 Ports List") )

which refers to 2 internal feeds (the subqueries) which are automatically imported from a variety of sources, tested and verified against troves of data to identify false positives and then automatically pushed out to all customers. What we are intending to do is to allow customers to drill into those Subqueries to see the underlying datasets and, potentially, re-use them in their own Custom Detection Rules.

To your second question, unfortunately exceptions are not available with Community Threats and are not planned to be implemented in its current form. However, when the above comes to fruition you would be able to craft an exception that specifically excluded the legitimate domains from the alert.

Whilst I am by no means an expert and every customer has different needs and complexities, I know that our internal MDR SOC teams have their threat intel feed needs satisfied via the built in ABA alerts and no longer use Community Threats at all. However, I also understand that, as customers do not have the visibility into the content used, the reassurance provided by Community Threats is a value all to itself.

This turned into a bit of an epic so I will stop, but please feel free to ask more questions if you have any :+1:

4 Likes