# GCleaner Sig Submission
**URL:** https://community.emergingthreats.net/t/gcleaner-sig-submission/290
**Category:** Rule Signatures
**Created:** [January 30, 2023, 8:48pm UTC](https://community.emergingthreats.net/t/gcleaner-sig-submission/290 "2023-01-30T20:48:56Z")
**Posts on this page:** 2
**Page:** 1
### Author:  [@cosmicgumbo](https://community.emergingthreats.net/u/cosmicgumbo)
#### Post date: [January 30, 2023, 8:48pm UTC](https://community.emergingthreats.net/t/gcleaner-sig-submission/290/1 "2023-01-30T20:48:56Z")
>
Some of these might be overkill but let me know if you need anything from it. I think some of it is useful but I put more in than might be needed to grab as much as possible from the PCAP.
I am also interested in any documentation that might be helpful for me to start doing the Snort conversions myself so it’s not something all of you have to do for my sigs.
Thanks!
---
### Author:  [@trobinson667](https://community.emergingthreats.net/u/trobinson667)
#### Post date: [January 31, 2023, 6:37pm UTC](https://community.emergingthreats.net/t/gcleaner-sig-submission/290/2 "2023-01-31T18:37:38Z")
Hey there fella,
Thanks once again for a fantastic set of rule submissions. I’ve taken a look at your rules and I’ve made some modifications, and have some feedback to offer, but first, the changes I’ve made:
```auto
alert http $HOME_NET any -> $EXTERNAL_NET any msg:"ET MALWARE GCleaner CnC Checkin M1"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"|2f|default|2f|stuk|2e|php"; fast_pattern; bsize:17; http.header_names; content:"|0d 0a|Accept|0d 0a|Accept|2d|Language|0d 0a|Accept|2d|Charset|0d 0a|Accept|2d|Encoding|0d 0a|User|2d|Agent|0d 0a|Host|0d 0a|Connection|0d 0a|Cache|2d|Control|0d 0a 0d 0a|"; http.user_agent; content:"OK"; bsize:2; reference:url,tria.ge/230130-trm29acf8w; classtype:trojan-activity; sid:1; rev:1;)
alert http $HOME_NET any -> $EXTERNAL_NET any msg:"ET MALWARE GCleaner Payload Retrieval Attempt"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"|2f|default|2f|puk|2e|php"; fast_pattern; bsize:16; http.header_names; content:"|0d 0a|Accept|0d 0a|Accept|2d|Language|0d 0a|Accept|2d|Charset|0d 0a|Accept|2d|Encoding|0d 0a|User|2d|Agent|0d 0a|Host|0d 0a|Connection|0d 0a|Cache|2d|Control|0d 0a 0d 0a|"; http.user_agent; content:"OK"; bsize:2; reference:url,tria.ge/230130-trm29acf8w; classtype:trojan-activity; sid:2; rev:1;)
alert http $EXTERNAL_NET any -> $HOME_NET any msg:"ET MALWARE Potential GCleaner Payload Retrieval Response"; flow:established,to_client; http.response_line; content:"HTTP|2f|1|2e|1|20|200|20|OK"; bsize:15; http.header_names; content:"|0d 0a|Cache-Control|0d 0a|Content|2d|Disposition|0d 0a|Content-Transfer-Encoding|0d 0a|Content-Length|0d 0a|Keep-Alive|0d 0a|Connection|0d 0a|Content-Type|0d 0a 0d 0a|"; fast_pattern; reference:url,tria.ge/230130-trm29acf8w; classtype:trojan-activity; sid:3; rev:1;)
alert http $HOME_NET any -> $EXTERNAL_NET any msg:"ET MALWARE GCleaner CnC Checkin M2"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"|2f|dll|2e|php"; bsize:8; fast_pattern; http.header_names; content:"Accept|0d 0a|Accept-Language|0d 0a|Accept-Charset|0d 0a|Accept-Encoding|0d 0a|User-Agent|0d 0a|Host|0d 0a|Connection|0d 0a|Cache-Control|0d 0a|"; http.user_agent; content:"B"; bsize:1; reference:url,tria.ge/230130-trm29acf8w; classtype:trojan-activity; sid:4; rev:1;)
alert http $HOME_NET any -> $EXTERNAL_NET any msg:"ET MALWARE Potential GCleaner CnC Checkin"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"|2f|advertisting|2f|plus|2e|php|3f|s|3d|NOSUB|26|str|3d|mixtwo|26|substr|3d|mixinte"; fast_pattern; bsize:56; http.header_names; content:"|0d 0a|Accept|0d 0a|Accept|2d|Language|0d 0a|Accept|2d|Charset|0d 0a|Accept|2d|Encoding|0d 0a|User|2d|Agent|0d 0a|Host|0d 0a|Connection|0d 0a|Cache|2d|Control|0d 0a 0d 0a|"; http.user_agent; content:"OK"; bsize:2; reference:url,tria.ge/230130-trm29acf8w; classtype:trojan-activity; sid:5; rev:1;)
```
So most of the changes I’ve made to the rules above are mainly cosmetic and I guess are what you’d call ET syntax/style:
- With the `flow` keyword, we typically either use `to_server` or `to_client`
- With the `reference` metadata keyword, we usually remove the `http|https://` portion of a reference URL
- We typically use the `ET MALWARE` category for general malware as opposed to `ET Trojan`
- Renamed sid 1 and 4 to CnC Checkin M1 and M2 (respectively)
- Renamed sid 2 to Payload retrieval attempt
With the minor stuff out of the way, lets get into some more details:
- Unfortunately, I don’t think we’ll be able to make very good use of sid number 3. If at all possible, we like to make sure a rule has a good candidate for `fast_pattern` matching, and this rule really doesn’t have a good candidate – For suricata 4 and 5, we can use the `http.header_names`/`http_header_names` buffer to make a fast\_pattern for this rule, but for Snort 2.9.x, this is going to end up being a PCRE, and you can’t make fast\_pattern matches out of PCRE on snort.
- Additionally, while this combination of header names from the server seemed to test okay among our quality assurance pcaps, I don’t know that it’ll be a particularly unique set of HTTP headers in the real-world. I suspect it has the potential to be false-positive prone.
- However, the good news is that we have a very similar rule in the ETPRO ruleset that triggers on the return traffic, using a different method – we chose to focus on the `filename` field of the `Content-Disposition` header in the server’s response. Today, we will be moving this rule to the ETOPEN ruleset.
- That brings me to sid number 5: While I definitely saw the URI pattern in the Virustotal IP addresses/pivots, this URI pattern was not observed in the sandbox run. Some of the IP addresses had comments in which users seemed to have observed the IP addresses having been used as Vidar stealer C2 addresses as well, so for the time being, I decided change the message to `Potential` CnC Checkin.
- For all of the submissions here, I did a bunch of QA and performance testing. I found in my testing that for suricata 5, that the rules performed better when I used the `http.method` and `http.uri` buffers, instead of `http.request_line` However, its hard for me to say whether or not this resulted in better rule performance, or if it was…
- For sids 1, 2, and 5, I noticed the user-agent of `OK` was used as the `fast_pattern` match. This resulted in a couple of checks in my QA analysis, so I decided to experiment with setting the `fast_pattern` match to the `http.uri` string instead for sids 1, 2, 4, and 5. This removed checks/alerts in our QA datasets for all of the rules except for sid 3, and I noticed in performance testing that between moving the fast\_pattern, and using the `http.method` and `http.uri` buffers, I got some natty perf gainz.
I will be submitting sids 1,2,4, and 5 to the ETOPEN ruleset, and be changing sid 2852925 from ETPRO to ETOPEN (instead of using sid number 3).
So that’s my feedback, and why I made the changes I’ve made. Once again, thank you very much for sharing your research, and I hope to collaborate with you in the future.
Cheers,
Tony