Gurcu stealer report outbound

Rule Signatures
1

Hi, I found that we do not detect some requests to send a report with metadata from the Gurcu stealer.
Here I propose a rule for such activity.

alert http any any -> any any (msg: "ET MALWARE [ANY.RUN] Gurcu Stealer Reporting Request (Outbound)";
flow: established, to_server;
http.method; content: "PUT";
http.uri; content: "@"; content: "_report.wsr"; endswith; 
http.host; pcre: "/^(?:(?:\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])\.){3}(?:\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])/R";
http.header_names; content: "Host|0d 0a|Content-Length|0d 0a|Expect|0d 0a|";
http.header_names; content:!"Referer|0d 0a|";
http.header_names; content:!"User-Agent|0d 0a|";
http.request_body; content: "WSR$"; depth: 4;
reference: url, https://app.any.run/tasks/0b0e6ff6-afa1-4645-811a-f1f8bd54952f/;
reference: md5, aeccba3e22db4978ae4e754ce940568c;classtype: credential-theft;
sid:1; rev:1;
metadata: affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, created_at 2023_05_24, deployment Perimeter, former_category MALWARE, performance_impact Low, signature_severity Major, malware_family Gurcu, updated_at 2023_05_24;)

https://www.joesandbox.com/analysis/865363/0/html

Have a good day! Regards Jane.

3 Likes
2

Hey Jane,

Great to see you over here. Thank you for submitting this rule. I made a couple of small changes in order to cast a slightly wider net, while maintaining rule fidelity:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET MALWARE [ANY.RUN] WhiteSnake Stealer Reporting Request (Outbound)"; flow:established,to_server; http.method; content: "PUT"; http.uri; content: "|40|"; content: "_report.wsr"; fast_pattern; endswith; http.header_names; content:"|0d 0a|Host|0d 0a|Content-Length|0d 0a|Expect|0d 0a|"; content:!"|0d 0a|Referer|0d 0a|"; content:!"|0d 0a|User-Agent|0d 0a|"; http.request_body; content:"WSR$"; depth: 4; reference:url,app.any.run/tasks/0b0e6ff6-afa1-4645-811a-f1f8bd54952f/; reference:md5,aeccba3e22db4978ae4e754ce940568c; classtype:credential-theft; sid:1; rev:1;)

  • I made a slight change to the content match for the "@", to look for the hex equivalent ("|40|"). Either way works, but its just a stylistic choice.
  • I chose to remove http.host; pcre: "/^(?:(?:\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])\.){3}(?:\d|[1-9]\d|1\d\d|2[0-4]\d|25[0-5])/R";. This is a PCRE for a dotted quad IP address. Just in the event that actors start using domain names in addition to IPv4 addresses, we want to cast a slightly wider net to catch that as well.
  • made the _report.wsr at the end of the http URI the fast_pattern for the rule.
  • http.header_names only needs to be called once for both positive content matches, as well as negations, since its a sticky buffer.
  • Based on conversation with my peers, Gurcu Stealer also has the name ‘WhiteSnake stealer’. Additionally, using google to search for whitesnake stealer produces more results, and is a bit more likely to be helpful to other researchers attempting to find write-ups on this stealer. For the sake of simplicity, I changed the title to: ET MALWARE [ANY.RUN] WhiteSnake Stealer Reporting Request (Outbound), and for the malware family tag I will add both Gurcu and WhiteSnake as its tags.
  • As a final aside, one of my peers wrote up a rule for the telegram checkin already. In addition to this rule with the proposed changes I’ve made, the other rule will be available tonight after our daily rule release.
  • Minor syntactical hiccups that our QA system didn’t care for (no spaces between reference: and reference data, no protocol identifier in url reference data (e.g. no http:// or https://) no space after the msg: tag, etc.

Once again, thank you for your contribution!

2 Likes
3

Thanks for the response _/_ It would be nice for me to know this in order to write rules in the future.

1 Like
4

Thanks @Jane0sint and @trobinson667 - in release these SIDs are:

  • 2045868 - ET MALWARE [ANY.RUN] WhiteSnake Stealer Reporting Request (Outbound) (malware.rules)
  • 2045869 - ET MALWARE WhiteSnake Stealer Telegram Checkin (malware.rules)
5

May I ask you to correct existing rules?
ET MALWARE Gurcu Stealer Sending Data to Telegram (POST) sid:2044309;
ET MALWARE Gurcu Stealer Response (Inbound) sid:2044338;

6

There is also a small question, is it worth adding an extended metadata like this?

metadata: affected_product Windows_XP_Vista_7_8_10_Server_32_64_Bit, attack_target Client_Endpoint, created_at 2023_05_24, deployment Perimeter, former_category MALWARE, performance_impact Low, signature_severity Major, malware_family Gurcu, updated_at 2023_05_24;)

7

Hello again Jane,

And thanks for the suggestion. We agree that consistency is important. We’ll be changing the names for these rule triggers in tonight’s rule release, and adding tag data for both Gurcu and WhiteSnake.

Now, in regards to your other question: You don’t have to supply metadata with the rule if you don’t want to. All of the metadata tags you see are added by our QA in a semi-automated manner. We select some of the tags manually, but the system handles others on our behalf.

Having them filled out makes it super easy for us to just select the metadata options, but in the same vein, some metadata options are pretty obvious (e.g. deployment Perimeter for CnC Checkins, or setting deployment SSLDecrypt, Perimeter for C2 traffic that will likely feature encryption – like telegram check-in).

If a malicious executable is Windows only, we usually default to Windows_XP_Vista_7_8_10_Server_32_64_Bit as the affected_product

Stuff like that. Once again, thank you for your assistance and feedback. Good luck, and happy hunting.

3 Likes
8

Thanks for giving us more insight into how the signatures are curated, @trobinson667! This is good context for us consumers as we tune our rule sets.