Yes, we can definitely go forward with this submission.
Thank you for the URI paths in the previous posts. The request for URI paths was motivated to improve the second PCRE performance, where possible. The second PCRE ``pcre:"/\.(?:wsf|py|js|jse|vbs|vbe|bat|cmd|ps1|hta|url)(?=$|[?#&])/i"; will match if
- there exists a http.uri buffer
- the http.uri buffer contains an extension content match, anywhere
- the http.uri buffer may end after the extension content match OR may end in ?#&
We can improve performance by using more content and anchors. Let’s match on content:“.”, and then use this content match as an anchor for the extension matching >> content:“.”; pcre:”/^(?:wsf|py|js|jse|vbs|vbe|bat|cmd|ps1|hta|url)(?:$|[?#&])/Ri”. More about PCRE modifiers in this post, Handling False Positive Reports as A Rule Writer! Special Guests: PCREs, Dalton, Dalton’s Flowsynth
And so, I’ll release 4 rules for each domain with the updated PCRE e.g.
alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET HUNTING Suspicious File Hosted via Cloudflare Services (* .r2 .dev)"; flow:established,to_server; http.host; content:".r2.dev"; endswith; http.uri; content:"."; pcre:"/^(?:wsf|py|js|jse|vbs|vbe|bat|cmd|ps1|hta|url)(?:$|[?#&])/Ri"; reference:url,cofense.com/blog/how-cloudflare-services-are-abused-for-credential-theft-and-malware-distribution; reference:url,developers.cloudflare.com/cloudflare-one/networks/connectors/cloudflare-tunnel/do-more-with-tunnels/trycloudflare/; classtype:trojan-activity; sid:4; rev:1;)
BTW, I do note we could continue improving the PCRE if we assumed the URI terminated at the extension match. I haven’t noticed any URI examples with fragments, Search - urlscan.io . However, that wasn’t the intention of your rules, so I didn’t add that modification!
Cheers! I’ll update this post when the production SIDs are out and give you thanks in our Daily Release post.