Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    Snort Rule 1:2044746 ET Trojan SOMNIRECORD

    Scheduled Pinned Locked Moved IDS/IPS
    14 Posts 6 Posters 1.4k Views
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • J
      joshs922
      last edited by joshs922

      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?

      P 1 Reply Last reply Reply Quote 2
      • P
        phodge @joshs922
        last edited by

        @joshs922 Same issue here with this Snort entry. PiHole was querying 1.1.1.1 both times when Snort logged rule 2044746.

        J 2 Replies Last reply Reply Quote 0
        • bmeeksB
          bmeeks
          last edited by bmeeks

          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.

          1 Reply Last reply Reply Quote 1
          • J
            joshs922 @phodge
            last edited by

            @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.

            1 Reply Last reply Reply Quote 0
            • J
              joshs922 @phodge
              last edited by

              @phodge Just sharing this breaking information on this that I found. Looks like some rule changes are being pushed through tonight.

              P 1 Reply Last reply Reply Quote 3
              • P
                phodge @joshs922
                last edited by

                @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.

                J 1 Reply Last reply Reply Quote 0
                • J
                  jimmychoosshoes @phodge
                  last edited by jimmychoosshoes

                  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.

                  D J 2 Replies Last reply Reply Quote 0
                  • D
                    DBMandrake @jimmychoosshoes
                    last edited by DBMandrake

                    @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.

                    J J 2 Replies Last reply Reply Quote 0
                    • J
                      jimmychoosshoes @DBMandrake
                      last edited by

                      @dbmandrake We have not had any alerts today so all appears to be good.

                      D 1 Reply Last reply Reply Quote 0
                      • J
                        joshs922 @jimmychoosshoes
                        last edited by

                        @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.

                        NogBadTheBadN 1 Reply Last reply Reply Quote 0
                        • NogBadTheBadN
                          NogBadTheBad @joshs922
                          last edited by

                          @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.

                          Andy

                          1 x Netgate SG-4860 - 3 x Linksys LGS308P - 1 x Aruba InstantOn AP22

                          1 Reply Last reply Reply Quote 1
                          • D
                            DBMandrake @jimmychoosshoes
                            last edited by

                            @jimmychoosshoes Seems OK now here as well.

                            J 1 Reply Last reply Reply Quote 0
                            • J
                              joshs922 @DBMandrake
                              last edited by

                              @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?

                              1 Reply Last reply Reply Quote 0
                              • J
                                joshs922 @DBMandrake
                                last edited by

                                @dbmandrake @jimmychoosshoes @phodge

                                049f1f8c-728f-452f-a423-d415de931fd0-image.png

                                Found the actual contact attempt in the pihole logs .. the wife's Macbook Air. Hmm, time to exorcise that laptop.

                                1 Reply Last reply Reply Quote 0
                                • First post
                                  Last post
                                Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.