Snort Rule 1:2044746 ET Trojan SOMNIRECORD
-
@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.
