Link to Rule
|
name = "Machine Learning Detected a DNS Request Predicted to be a DGA Domain" |
Rule Tuning Type
False Positives - Reducing benign events mistakenly identified as threats.
Description
Title: [Tuning] Update DGA ML Rule to exclude Microsoft Telemetry and FP Domains
Rule Name: Machine Learning Detected DNS Request Predicted to be a DGA domain
Description
The current logic for DGA detection frequently triggers on legitimate Microsoft telemetry and "Flighting/Front Door" (FP) domains. These domains utilize high-entropy strings for load balancing and performance measurement, which consistently triggers a high malicious_prediction score from the DGA ML model.
Furthermore, many DNS log sources (such as Packetbeat or certain firewall integrations) may not consistently populate dns.question.registered_domain, making current exceptions based on that field ineffective in some environments.
Suggested Changes
Update the rule's exception logic or documentation to include a broader set of known-good Microsoft high-entropy domains using dns.question.name to ensure coverage across varied ECS implementations.
Also suggestion to use ESQL instead of KQL for wildcard matching dns.question.name using RLIKE.
Now I have made exceptions to the rule, but since these Microsoft telemetry domains are known, it would be nice to have them included in the rule:
destination.portIS 53
AND dns.question.name MATCHES *.fp.measure.office.com
When I search for events with ml_is_dga.malicious_prediction=1 using the following ESQL query, the returned documents do not always contain dns.question.registered_domain field, only the dns.question.name....so question is that does the current query with only exception for avsvmcloud.com actually work?
FROM logs-*
| WHERE ml_is_dga.malicious_prediction == 1
Current KQL rule:
ml_is_dga.malicious_prediction:1 and not ( dns.question.registered_domain:avsvmcloud.com
Not sure if the wildcard matching can be done with KQL in any good way?
Suggested improvement with ESQL rule:
(This contains domains from our environment that have triggered the DGA rule. Needs to be reviewed and cleaned for wider deployment)
FROM *:logs-endpoint.events.*, *:logs-network_traffic.*
| WHERE ml_is_dga.malicious_prediction == 1
AND NOT ( dns.question.name RLIKE ".*windows.net" OR
dns.question.name RLIKE ".*mshome.net" OR
dns.question.name RLIKE ".*fp.measure.office.com" OR
dns.question.name RLIKE ".*res.office365.com" OR
dns.question.name RLIKE ".*omni.microsoft.com" OR
dns.question.name RLIKE ".*api.powerplatform.com" OR
dns.question.name RLIKE ".*googlesyndication.com" OR
dns.question.name RLIKE ".*cloudfront.net" OR
dns.question.name RLIKE ".*cloudflare.net" OR
dns.question.name RLIKE ".*cdn.forter.com" OR
dns.question.name RLIKE ".*_msdcs.*" OR
dns.question.name RLIKE "cdn.jsdelivr.net" OR
dns.question.name RLIKE "cdn.indexww.com" OR
dns.question.name RLIKE "cdn.brcdn.com" OR
dns.question.name RLIKE ".*apicdn.sanity.io" OR
dns.question.name RLIKE ".*sentry.io" OR
dns.question.name RLIKE ".*avsvmcloud.com" )
| KEEP @timestamp, dns.question.name, agent.name, host.name, user.name
Example Data
No response
Link to Rule
detection-rules/rules/integrations/dga/command_and_control_ml_dns_request_predicted_to_be_a_dga_domain.toml
Line 17 in 4201fe6
Rule Tuning Type
False Positives - Reducing benign events mistakenly identified as threats.
Description
Title: [Tuning] Update DGA ML Rule to exclude Microsoft Telemetry and FP Domains
Rule Name: Machine Learning Detected DNS Request Predicted to be a DGA domain
Description
The current logic for DGA detection frequently triggers on legitimate Microsoft telemetry and "Flighting/Front Door" (FP) domains. These domains utilize high-entropy strings for load balancing and performance measurement, which consistently triggers a high malicious_prediction score from the DGA ML model.
Furthermore, many DNS log sources (such as Packetbeat or certain firewall integrations) may not consistently populate dns.question.registered_domain, making current exceptions based on that field ineffective in some environments.
Suggested Changes
Update the rule's exception logic or documentation to include a broader set of known-good Microsoft high-entropy domains using dns.question.name to ensure coverage across varied ECS implementations.
Also suggestion to use ESQL instead of KQL for wildcard matching dns.question.name using RLIKE.
Now I have made exceptions to the rule, but since these Microsoft telemetry domains are known, it would be nice to have them included in the rule:
When I search for events with ml_is_dga.malicious_prediction=1 using the following ESQL query, the returned documents do not always contain
dns.question.registered_domainfield, only the dns.question.name....so question is that does the current query with only exception for avsvmcloud.com actually work?Current KQL rule:
Not sure if the wildcard matching can be done with KQL in any good way?
Suggested improvement with ESQL rule:
(This contains domains from our environment that have triggered the DGA rule. Needs to be reviewed and cleaned for wider deployment)
Example Data
No response