AsukaStealer (Observerstealer.Gen)

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.


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.

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

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

Yes, quite a Solomon’s decision. I don’t mind, so be it.