This rule probably is missing the noalert as per the references in the rule. Right now, I’m seeing it fire a bunch of times on my networks.
alert tcp $HOME_NET any -> $EXTERNAL_NET 443 (msg:"ET TROJAN Win32/BugSleep CnC Checkin"; flow:established,to_server; xbits:set,ET.BugSleep.C2,track ip_dst,expire 60; content:"|fd fd fd|"; offset:1; depth:3; fast_pattern; content:"|2c|"; within:255; reference:url,blog.talosintelligence.com/writing-a-bugsleep-c2-server/; reference:url,blog.sekoia.io/muddywater-replaces-atera-by-custom-muddyrot-implant-in-a-recent-campaign/; reference:url,research.checkpoint.com/2024/new-bugsleep-backdoor-deployed-in-recent-muddywater-campaigns/; classtype:trojan-activity; sid:2057160; rev:1; metadata:affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, affected_product Windows_11, attack_target Client_and_Server, tls_state plaintext, created_at 2024_10_30, deployment Perimeter, deployment Internal, malware_family Win32_BugSleep, performance_impact Low, confidence High, signature_severity Major, updated_at 2024_10_30; target:src_ip;)
Note the rule 2057161 is the command rule which looks for the flow bit set with this one.
Greetings,
I was the one responsible for bringing this rule to the ET ruleset. We have a test battery of pcaps for what is mostly “normal” network traffic that we test our rules against before adding them to the ET ruleset, and I had tested both rules (the Beacon and Command rules) against our test battery and I figured things looked well enough to where the noalert; wouldn’t be necessary.
But as it sometimes turns out to be, our testing captures that emulate real-world traffic, and actual real-world traffic aren’t always accurate. So, my apologies for the excessive alerts. I’ve added a noalert tag to the xbit in the beacon rule. That change should be going live in tonight’s rule release.
Thanks for reporting this problem, and as always, if there are any continued problems after pulling down tonight’s rule release, please let us know so that we may fix them.
Thanks,
Tony Robinson
@trobinson667 No worries. Thanks for the quick reply and fix.
Just so nobody here is caught offguard, we ran across a consistency problem with xbits:noalert that resulted in it not work consistenly between versions of Suricata.
Fortunately, setting flowbits:noalert allowed us to stop the rule from alerting, but still allows the xbit to be set. So, expect the problematic rule to be fixed with a flowbits:noalert; as opposed to xbits:noalert; for the time being until we can investigate this inconsistency further.
2 Likes