ET MALWARE Specter Insight Beacon CnC Checkin; sid: 2061025

Rule Signatures
1

Hello, ET team,

found some SpecterInsight traffic, where sid 2061025 does not fire.

The rule:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET MALWARE Specter Insight Beacon CnC Checkin"; flow:established,to_server; http.method; content:"GET"; http.uri; bsize:63<>65; content:"/threads/"; startswith; pcre:"/^[a-f0-9]{32}/R"; content:"/messages|3f|filter|3d|"; within:17; pcre:"/^\d{5,7}$/R"; http.user_agent; bsize:16; content:"Evernote Windows"; fast_pattern; reference:url,practicalsecurityanalytics.com/specterinsight/; reference:md5,612e27b5df944f1591bfc5d1bc17a153; classtype:trojan-activity; sid:2061025; 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 2025_03_24, deployment Perimeter, malware_family Specter_Insight, performance_impact Low, confidence High, signature_severity Major, tag C2_Framework, updated_at 2025_03_24, mitre_tactic_id TA0010, mitre_tactic_name Exfiltration, mitre_technique_id T1567, mitre_technique_name Exfiltration_Over_Web_Service;)

The reference sample can produce a URL of 63 chars, like this /threads/2891fbd9d931434dbdb60ba0dcebc2e0/messages?filter=62255. Therefore, due to bsize:63<>65, no alert is triggered.

GET /threads/2891fbd9d931434dbdb60ba0dcebc2e0/messages?filter=62255 HTTP/1.1
User-Agent: Evernote Windows
Host: 142.93.198.235
Accept-Encoding: gzip

Also, there is a sample MD5: 0f1bab742523821d833701f82a328c2b with the Mozilla user-agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36

GET /threads/1bff4fec79014222a9c7e465b0b4e02a/messages?filter=14089 HTTP/1.1
User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/79.0.3945.130 Safari/537.36
Host: www.identity-shield.org
Accept-Encoding: gzip
1 Like
2

Hey @emankekin - Thanks for sharing the new samples! I’ll take a look at this today and let you know what happens. Depending on performance impact we may write a new signature to cover the gaps.

Thanks!
Isaac

3

emankekin,

My name is Tony, I’ll be taking over for Isaac. I made this rule so I’m kinda responsible for the mix-up.

First things first, the bsize mistake has been fixed by using bsize:62<>66. I made a mistake in believing that the bsize keyword was inclusive for its numeric ranges. Supposedly snorts urilen buffer is inclusive, but I also modified the Snort rule as well (e.g. urilen:62<>66

Next up, the second sample you mentioned. I’ve created some DNS and TLS SNI rules for the domain *.identity-shield.org that should be going out today.

Finally I created a sort of more generic rule that focuses on the URI pattern that the first and second sample have in common and I created a new rule for a URI pattern I observed in one of the samples reaching out to www.identity-shield.org. Those should be going out today as well.

Thanks,

Tony

2 Likes