Suricata

consider the following rule which was written to detect a "password" being sent via a POST request.

However, the source article is not clear if the parameter is sent via a URI parameter or within the request body. One could assume, but that's always a dangerous game to play. As such, it was written as an unbuffered content match.

alert http any any -> $HOME_NET any (msg:"ET MALWARE Win32/frebniis IIS Backdoor Trigger Attempt M2"; flow:established,to_server; content:"7ux4398!"; fast_pattern; http.method; content:"POST"; http.uri; content:"/default.aspx"; reference:url,symantec-enterprise-blogs.security.com/blogs/threat-intelligence/frebniis-malware-iis; classtype:trojan-activity; sid:2044232; rev:1; metadata:attack_target Web_Server, created_at 2023_02_16, deployment Perimeter, deployment Internal, deployment SSLDecrypt, former_category MALWARE, performance_impact Low, confidence High, signature_severity Major, updated_at 2023_06_08;)

There are many such rules within the ruleset contain the following "logic" of using an unbuffered content match to match either http.uri or http.request_body.

I'm not 100% sure how this would work given fast_pattern limitations, but something like the below rule would be kinda cool.

alert http any any -> $HOME_NET any (msg:"ET MALWARE Win32/frebniis IIS Backdoor Trigger Attempt M2"; flow:established,to_server; http.uri || http.request_body; content:"7ux4398!"; fast_pattern; http.method; content:"POST"; http.uri; content:"/default.aspx"; [snip]

The current "workaround" is to write two different rules, which works fine in most cases.

I suppose this could be extended to other buffers as well.