Snort Rule 1:2044746 ET Trojan SOMNIRECORD
-
I'm having DNS requests to OpenDNS (208.67.220.220 and .222) from my pihole blocked by Snort this morning with rule 2044746 "ET Trojan SOMNIRECORD Backdoor DATA Command in DNS Query". The rule is unknown/unsearchable online so I can't figure out if this is a false positive or what. Anyone else having this issue?
-
@joshs922 Same issue here with this Snort entry. PiHole was querying 1.1.1.1 both times when Snort logged rule 2044746.
-
See my post here: https://forum.netgate.com/topic/178975/trying-to-get-snort-to-block-local-client-if-they-have-a-trojan/4.
When a rule suddenly starts triggering for lots of folks on seemingly innocuous traffic, that usually means the author/maintainer of the rule made a "bad change" and the rule is generating false positives.
Remember that you probably have configured your rules to auto-update at least weekly if not nightly. Any given update can pull down both new and edited rules, and something that was working fine yesterday can be broken today if a rule creator/maintainer makes a human error and then publishes it in their latest rules update package.
-
@phodge said in Snort Rule 1:2044746 ET Trojan SOMNIRECORD:
Same issue here with this Snort entry. PiHole was querying 1.1.1.1 both times when Snort logged rule 2044746.
Interesting. That would be consistent behavior for "somnirecord" - apparently that's how it works/masquerades... it uses DNS requests to avoid detection. I'm still hesitant to block the rule as it does seem to be triggered by/coming from requests made by only one specific host on my LAN.
-
@phodge Just sharing this breaking information on this that I found. Looks like some rule changes are being pushed through tonight.
-
@joshs922 Good to know. Had a few more entries triggered by queries to 1.1.1.2 and 8.8.8.8. Will make sure the rules are updated tomorrow.
-
I traced one of our guests who were triggering this alert. They have a macbook air, currently it is believed that only windows variants exists so this is a false positive for us.
https://www.elastic.co/security-labs/not-sleeping-anymore-somnirecords-wakeup-call
https://siliconangle.com/2023/03/20/asian-attack-group-deploys-new-forms-malware-target-companies/
obviously the maintainer has now posted that a fix for the "ET MALWARE SOMNIRECORD Backdoor DATA" trigger is incoming. We never saw probe or cmd alerts.
-
@jimmychoosshoes Seeing lots of false positives for this rule here too. From a variety of different devices - Macbook Air's iPad's etc. Since there are only Windows variants of the malware and it was coming from so many non windows devices (over 30 devices on a network of 800 or so) I figured it was a false positive, especially after looking at the rule definition which looks overly broad to me.
-
@dbmandrake We have not had any alerts today so all appears to be good.
-
@jimmychoosshoes said in Snort Rule 1:2044746 ET Trojan SOMNIRECORD:
I traced one of our guests who were triggering this alert. They have a macbook air,
Yep. That's what was triggering the alerts here. The wife's MacBook Air.
-
@joshs922 said in Snort Rule 1:2044746 ET Trojan SOMNIRECORD:
traced one of our guests who were triggering this alert. They have a macbook air,
My Panasonic TV did it a few times yesterday.
-
@jimmychoosshoes Seems OK now here as well.
-
@dbmandrake @jimmychoosshoes @phodge
New one appeared today - Snort blocked a DNS request from pihole with rule number 2044844, "ET TROJAN SocGholish Domain in DNS Lookup (unit4 .majesticpg .com)"
Could this be another false positive? Seems fairly specific like a host was trying to phone home. Anyone else seeing anything like this?
-
@dbmandrake @jimmychoosshoes @phodge
Found the actual contact attempt in the pihole logs .. the wife's Macbook Air. Hmm, time to exorcise that laptop.
