Hello, I saw a new bot and decided to write a rule


alert http any any -> any any (msg: "ET MALWARE [ANY.RUN] ZharkBOT HTTP GET Request";flow: established, to_server; http.method; content: "GET"; http.uri; content: "?id="; pcre: "/^[a-f0-9]{32}&/R"; content: "us="; within: 3content: "&mn="; distance: 0; content: "&os="; distance: 0; content: "&bld="; distance: 0; http.header_names;  content:!"Referer|0d 0a|";  reference: md5,1636b0de8dccc7605335f2289b883abc;  reference: url,app.any.run/tasks/dbf5e817-75fe-4d88-98a2-3573edf6febc; reference: url,community.emergingthreats.net/t/zharkbot/; metadata: attack_target Client_Endpoint, deployment Perimeter, former_category MALWARE, signature_severity Major, malware_family ZharkBOT,  created_at 2024_01_22; classtype: trojan-activity; sid: 1; rev: 1;)

Best regards

1 Like

Hi Jane,

As always, We appreciate your submissions. I’ve taken the liberty of making a couple of minor changes, that I think will be beneficial:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET MALWARE [ANY.RUN] ZharkBOT HTTP CnC Checkin"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"?id="; pcre:"/^[a-f0-9]{32}&/R"; content:"us="; content:"mn="; content:"os=Windows"; fast_pattern; content:"bld="; http.header_names; content:!"Referer|0d 0a|"; reference:md5,1636b0de8dccc7605335f2289b883abc; reference:url,app.any.run/tasks/dbf5e817-75fe-4d88-98a2-3573edf6febc; reference:url,community.emergingthreats.net/t/zharkbot/; metadata:attack_target Client_Endpoint, deployment Perimeter, former_category MALWARE, signature_severity Major, malware_family ZharkBOT, created_at 2024_01_22; classtype:trojan-activity; sid:1; rev:1;)

So the first thing I did was remove the distance:0; after each of the parameters. Its possible that the bad guys will just change what orders the parameters are in, or in some cases, applications can just do that arbitrarily sometimes. And of course, that would mean a rule in which we are rigidly looking for the parameters in a particular order will fail. I looked in our sandbox, and there’s no evidence for them changing their parameter order (yet), but who knows what might happen when they discover that we know about them. I also removed the ampersand (&) from some of those content matches, because again, if the parameter order in the URI changes, then that would mean a false negative. I know that these changes will mean that the rule probably won’t perform quite as well, but it enables some degree of flexibility in our ability to detect slight changes in Check-in format.

The other minor thing I did was change the “os=” content match into os=Windows, because for starters, this is Windows malware, and they they capture the OS version currently, the first word will always be “Windows”, so os=Windows makes more sense, and we can set that as a fast_pattern for the rule.

Once again, we are always thank for your help, and the help from our community to make ETOPEN better, and this rule will be added to tonight’s rule release.

Good luck and happy hunting,



Thanks Tony, sorry for my inadvertence :pray: All your comments are right on point, I probably would have done the same myself. And you correctly noted about Windows, and the ampersand is not needed if there is no distance.
↳ ❝ [ Thank you! ] ¡! ❞

.・::・゚’✫ Jane ✫’゚・::・˙