Filtering out M365 Defender Standard discovery noise

[GrassfedMeatSticks]

Hi everyone,

Is there a good way to filter out specific, known-false positive detections?

I had posted earlier about some benign SNMP traffic on Issue #227 and am now seeing detections on ports 22, 80, and 161 from Microsoft 365 Defender's recommended Standard Discovery configuration.

Standard discovery (recommended): This mode allows endpoints to actively find devices in your network to enrich collected data and discover more devices - helping you build a reliable and coherent device inventory. In addition to devices that were observed using the passive method, standard mode also leverages common discovery protocols that use multicast queries in the network to find even more devices. Standard mode uses smart, active probing to discover additional information about observed devices to enrich existing device information. When Standard mode is enabled, minimal, and negligible network activity generated by the discovery sensor might be observed by network monitoring tools in your organization.
You can change and customize your discovery settings, for more information, see Configure device discovery.

I reviewed #169 and wasn't sure if there was something like a REQUESTS.ignorelist like the "ip.ignorelist": ["192.168.1.1", "192.168.123.45"], in the referenced issue or if there would be a better way to filter out these M365 standard discovery requests.

Here's a sample M365 standard discovery detection

New Events
Event 1: {"dst_host": "<canary LAN IP>", "dst_port": 22, "local_time": "2023-03-17 13:09:12.039393", "local_time_adjusted": "2023-03-17 08:09:12.039445", "logdata": {"SESSION": "10"}, "logtype": 4000, "node_id": "opencanary-1", "src_host": "<standard discovery host LAN IP>", "src_port": 55684, "utc_time": "2023-03-17 13:09:12.039431"}

Event 2: {"dst_host": "0.0.0.0", "dst_port": 161, "local_time": "2023-03-17 13:09:20.844402", "local_time_adjusted": "2023-03-17 08:09:20.844462", "logdata": {"COMMUNITY_STRING": "public", "REQUESTS": ["1.3.6.1.2.1.1.1.0", "1.3.6.1.2.1.1.2.0", "1.3.6.1.2.1.1.4.0", "1.3.6.1.2.1.1.5.0", "1.3.6.1.2.1.1.6.0", "1.3.6.1.2.1.25.3.2.1.3.1"]}, "logtype": 13001, "node_id": "opencanary-1", "src_host": "<standard discovery host LAN IP>", "src_port": 59819, "utc_time": "2023-03-17 13:09:20.844446"}

Event 3: {"dst_host": "0.0.0.0", "dst_port": 161, "local_time": "2023-03-17 13:09:21.854738", "local_time_adjusted": "2023-03-17 08:09:21.854787", "logdata": {"COMMUNITY_STRING": "public", "REQUESTS": ["1.3.6.1.2.1.1.1.0", "1.3.6.1.2.1.1.2.0", "1.3.6.1.2.1.1.4.0", "1.3.6.1.2.1.1.5.0", "1.3.6.1.2.1.1.6.0", "1.3.6.1.2.1.25.3.2.1.3.1"]}, "logtype": 13001, "node_id": "opencanary-1", "src_host": "<standard discovery host LAN IP>", "src_port": 59819, "utc_time": "2023-03-17 13:09:21.854772"}

Event 4: {"dst_host": "<canary LAN IP>", "dst_port": 80, "local_time": "2023-03-17 13:09:33.541597", "local_time_adjusted": "2023-03-17 08:09:33.541640", "logdata": {"HOSTNAME": "<canary LAN IP>", "PATH": "/index.html", "SKIN": "basicLogin", "USERAGENT": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/64.0.3282.140 Safari/537.36 Edge/17.17134"}, "logtype": 3000, "node_id": "opencanary-1", "src_host": "<standard discovery host LAN IP>", "src_port": 55706, "utc_time": "2023-03-17 13:09:33.541627"}

I wonder how the commercial version of the Canary handles these?

[jayjb]

Hi @GrassfedMeatSticks,

Thanks for getting in touch with us about this issue. Its an interesting problem and one that we haven't yet engineered for. If you have some ideas, and would like to add to the project, I'd be happy to work with you to add this feature.

On the commercial side, we have many different filters (called annotations) which recognise particular attributes of an alert. It then allows us to confidently say that this alert is created from MSFT defender or other scanners or AV.

[frosit]

This seems like a problem we might run into as well soon as we're currently working to deploy that. Just informing I'm open to collaborate. If no solution is at hand, good chance I will create one but have to wait for it to be rolled out before I can replicate the problem.

[GrassfedMeatSticks]

Hi @jayjb and @frosit ,

Apologies for the delay.

I don't really have any ideas, but I did contact the commercial side of the house. Their response was thoughtful and perhaps helpful for this project (see below).

The TLDR of their responses is that we should consider excluding the honeypot IPs from M365 Defender and disabling the SNMP filter on the OpenCanary.

I haven't had time to tinker with our OpenCanarys (OpenCanaries?) but I will report back on this thread when I do.

Summary of exchange with Canary support:

Me: I've been playing with your open source OpenCanary project and was curious how the paid version of Canary handles Microsoft Defender Endpoint Standard Discovery?

The paid for version of Canary will generally require a much higher bar of “badness” before firing off an alert. For instance, if the Canary has a file share (SMB) and a web server (HTTP) configured, alerts will only be sent when a file is accessed or an attempt is made to login to the web server. So you won't easily get false positive alerts.
The SaaS console, which is also included in the paid version, has various features for handling activity from known systems including “Annotations”.
This works by detecting patterns in the initial and subsequent alerts generated by systems/applications (e.g.MSFT Defender) when they interact with a Canary.MSFT Defender appears to make a SIP & HTTP proxy request before firing off a port scan against the target. This activity would send alerts to the management console. The console will flag and suppress the alert as coming from Defender if the alert pattern is encountered. You can opt to ignore similar alerts in the future as well.
Another method to deal with Defender triggering alerts on your Canaries is to apply the recommendation from Microsoft, that is to add devices (such as honeypots) to an exclusion list. You can add the IP of your OpenCanary instance to this list as well. In general, OpenCanary and the paid products are pretty different products.

Me: What about other miscellaneous SNMP false positives?

Early on we did have SNMP as one of the services available on the Canary devices. We have since removed it from the paid for version because it was too noisy (as you have found out - there are a lot of SNMP probes on most networks!). We take this approach with all Canary services, if the signal is low, we remove it.
The OpenCanary gets triggered every time an endpoint pings the canary on ports 22, 80, and 161 and these are all false positives.
Although these might seem to be “false positives” OpenCanary is doing its job here (I.e. it is letting you know when it is being touched). We recommend adding its IP address to the exclusion list (as mentioned above).

[jayjb]

Hey @GrassfedMeatSticks,

I was reading over this issue again. I don't think that Opencanary is going to cater for this kind of ignore specificity any time soon. I would recommend adding the MSFT host doing the scans to your ip ignorelist as a fix for now.