AsukaStealer (Observerstealer.Gen)

Rule Signatures
1

Hi, yesterday @RussianPanda9xx wrote an article about the AsukaStealer: The Next Chapter in ObserverStealer's Story - ANY.RUN's Cybersecurity Blog. She describes the differences between the AsukaStealer and the original variant - ObserverStealer.
There is one noteworthy point: Asuka does not decrypt browser data as the Observer did previously. This reduces the visibility of loading additional modules; all decryption occurs on the server.

image
image1113Ɨ1000 137 KB

The raw data sent as a result has a different content type, previously it was text/plain is now multipart/form-data . And as a consequence of the need for decryption on the server side, another parameter was added - the key (Google_KEY|Firefox_KEY|Edge_KEY).
I made rules for the packets inspection because I couldnā€™t reach the required HTTP transaction with the Suricata HTTP parser (http.header).
But I had to cheat a little so as not to check the packets of all protocols and set a condition for the presence of HTTP in the connection (alert http) and look for the content in TCP packets.
image
image706Ɨ1043 130 KB

Rules:
Exfiltrates SQLite Browsers Data

alert http any any -> any any (msg: "ET MALWARE [ANY.RUN] AsukaStealer Exfiltrates SQLite Browsers Data";
flow: established, to_server;
content: "POST";
startswith;
content: "Content-Type: multipart|2f|form-data|3b| boundary="; distance: 0;
content: "X-Session|3a| "; within: 350;
content: "X-Info|3a|"; within: 45;
content: "X-Config|3a| "; within: 350;
pcre: "/^(Google_COK|Firefox_COK|Edge_COK)\r/R";
content: "X-ID|3a| "; within: 22;
threshold:type limit, seconds 120, count 1, track by_src;classtype: credential-theft;
reference:md5,ae5537f1a506140ee101ffdf4605fdcc;
reference:url,app.any.run/tasks/7a36fb55-3738-4f40-b760-b443689c9edd;
reference:url,community.emergingthreats.net/t/asukastealer-observerstealer-gen;
metadata: malware_family asukastealer, created_at 2024_03_19;
sid: 1; rev: 1;)

Sends MasterKey to Decrypt Browsers Data

alert http any any -> any any (msg: "ET MALWARE [ANY.RUN] AsukaStealer Sends MasterKey to Decrypt Browsers Data";
flow: established, to_server;
content: "POST";
startswith;
content: "Content-Type: text|2f|plain"; distance: 0;
content: "X-Session|3a| "; within: 350;
content: "X-Info|3a|"; within: 45;
content: "X-Config|3a| "; within: 350;
pcre: "/^(Google_KEY|Firefox_KEY|Edge_KEY)\r/R";
content: "X-ID|3a| "; within: 22;
threshold:type limit, seconds 120, count 1, track by_src;classtype: credential-theft;
reference:md5,ae5537f1a506140ee101ffdf4605fdcc;
reference:url,app.any.run/tasks/7a36fb55-3738-4f40-b760-b443689c9edd;
reference:url,community.emergingthreats.net/t/asukastealer-observerstealer-gen;
metadata: malware_family asukastealer, created_at 2024_03_19;
sid: 2; rev: 1;)

Have a nice day!
š–¤£š–„§š–”¼ā€ā‹†.ą³ƒąæ”*:ļ½„.
Jane

1 Like
2

Hey Jane,

Just wanna let you know that we saw your post here. Iā€™ve made a judgement call to focus on escalating the problem you experienced regarding the HTTP sticky buffers not operating correctly, resulting in a rule that could not use HTTP buffers, but COULD use the HTTP protocol specification in the rule header.

I took a snippet of the traffic from the original pcap, and used the tool flowsynth to create a smaller pcap that would trigger both YOUR rule, and the rule I put together that I based off of your original rule:

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"ET MALWARE [ANY.RUN] AsukaStealer SQLite Browser Data Exfiltration Attempt"; flow:established,to_server; http.method; content:"POST"; http.content_type; content:"multipart|2f|form-data|3b 20|boundary|3d|"; http.header; content:"X-Config|3a 20|"; fast_pattern; pcre:"/^(?:Google\x5f|Edge\x5f|Steam\x5f|Firefox\x5fF)/R"; content:"COK|0d 0a|"; within:20; http.header_names; content:"|0d 0a|X-Session|0d 0a|"; content:"|0d 0a|X-Info|0d 0a|"; content:"|0d 0a|X-Config|0d 0a|"; reference:md5,ae5537f1a506140ee101ffdf4605fdcc; reference:url,app.any.run/tasks/7a36fb55-3738-4f40-b760-b443689c9edd; reference:url,community.emergingthreats.net/t/asukastealer-observerstealer-gen; classtype:trojan-activity; sid:1; rev:1;)

In that instance, the rules both triggered just fine on that pcap. The next thing I wanted to check was whether or not I might have been hitting the http client inspection memory cap or something. so I increased it to 100mb, and still experienced the same problem you experienced.

So here is where we are so far:

  • It appears we do have some coverage for Asuka Stealer through the Observer Stealer rules that youā€™ve submitted in the past, and that our analysts created as well. So, weā€™re not entirely ā€œblindā€ to this threat.
  • Iā€™ve submitted a bug to OISF, and again, weā€™re escalating it to get eyes on it, because I donā€™t think this should be happening.
  • Iā€™m holding off on submitting these rules just yet, because the sticky buffers will make them perform much better. If there isnā€™t a response or a fix in a reasonable timeframe, weā€™ll submit the rules you have provided to enhance the coverage against asuka stealer in the meantime until we can get to the root of this issue.
2 Likes
3

Yes, quite a Solomonā€™s decision. I donā€™t mind, so be it.