maltrail: False positive `dr49lng3n1n2s.cloudfront.net` in the Blacklist

dr49lng3n1n2s.cloudfront.net is in the Blacklist https://raw.githubusercontent.com/stamparm/aux/master/maltrail-malware-domains.txt mentioned here: https://github.com/stamparm/maltrail#blacklist

Blocking dr49lng3n1n2s.cloudfront.net actually makes aws.amazon.com & aws.amazon.com.cdn.amazon.com blocked, looks false positive?

aws.amazon.com.cdn.amazon.com	canonical name = dr49lng3n1n2s.cloudfront.net.
aws.amazon.com	canonical name = tp.8e49140c2-frontier.amazon.com.
tp.8e49140c2-frontier.amazon.com	canonical name = dr49lng3n1n2s.cloudfront.net

Take a look at misc/whitelist.txt and I found cloudfront.net there: https://github.com/stamparm/maltrail/blob/master/misc/whitelist.txt#L52

Anything that I can do to help? Thanks!

About this issue

  • Original URL
  • State: closed
  • Created 2 years ago
  • Comments: 15 (10 by maintainers)

Most upvoted comments

@PeterDaveHello there will be no over-engineering here. there is no silver bullet for false-positives. if you take number of commits/domains, i would say that the frequency of FPs in Maltrail is quite low.

nonetheless, from now on we’ll have some automated checks to prevent similar occurrences

I got an idea that may be able to help mitigate this situation: to cross reference AlienVault OTX and SecurityTrails, but not so sure it’ll really be helpful here, because that may also add some additional loading to modify the process.

The reason why to suggest it is that I did two checks before opening this issue, and these checks seemed verified my guess, giving me the confidence that this could be a false positive.

  1. From the info on AlienVault OTX, this domain seems to be popular, the certificate info also looks good, and has been whitelisted already in the past (from passive DNS records):

https://otx.alienvault.com/indicator/domain/dr49lng3n1n2s.cloudfront.net

image

image

  1. From SecurityTrails we can see that two domains are in the record to point to dr49lng3n1n2s.cloudfront.net, that’s tp.8e49140c2-frontier.amazon.com & aws.amazon.com.cdn.amazon.com, and aws.amazon.com points to tp.8e49140c2-frontier.amazon.com, so this domain seems to be very important(I know it may depend on if you’re using AWS) and looks like an FP:

https://securitytrails.com/domain/tp.8e49140c2-frontier.amazon.com/dns https://securitytrails.com/domain/dr49lng3n1n2s.cloudfront.net/dns

image

Both of AlienVault OTX and SecurityTrails has their API, could have some automatic test/integration if that’ll help, though I’m not familiar with it, just want to share the process to verify my thoughts of the FP before opening the issue 😄

@PeterDaveHello

It’s interesting that the domain was added for about two months: 79cc94a

And I didn’t find out the relationship between the CloudFront domain with the references added 😅

Relashionship: image

May I also ask if making the entire CloudFront domain whitelisted sounds reasonable to you? Just wondering how to prevent the same false positive again

No way: https://twitter.com/drb_ra/status/1490697536591613952

This all doesn’t cancel my thankyou-words for pointing FP out.

well, whitelisting the whole domain would be problematic because some malicious/malware programs use “cloud” fronting to hide the real C&C (e.g. https://bigb0ss.medium.com/redteam-c2-redirector-cloud-fronting-setup-aws-e7ed561a3a6c)

1