AURA stealer

Rule Signatures
1

I am very sceptical about everything that is detected as Lumma Stealer since September 2025, when the administration of Lumma decided to vanish. Since that moment, everything related to Lumma should be thougth twice or even 3 times before associating to them.

An example is AURA stealer, with a C2 communication very similar to Lumma, which is causing sever mislabeling. Example of AURA stealer from today:
Analysis U1t-KMSpico.rar (MD5: 2FC8158F220185E6F5B980E899F2CD55) Malicious activity - Interactive analysis ANY.RUN

This stealer is gaining reputation increasingly over these months also provoked by disruptions of other malware families. Please take a look

Is it possible to add detection to AURA stealer labeling correctly and separately from Lumma?

2 Likes
2

Thanks @g0njxa ! @ishaughnessy was taking a look at this today - the downloaded RAR from any.run is itself encrypted - he’ll be in touch.

3

@ishaughnessy @rgonzalez oh yeah im very sorry i didn’t post the password

RAR password is windows

1 Like
4

hey @g0njxa - Thanks for bringing this to our attention! This week I’ve been talking to some of the researchers who handle our Lumma automation and config extraction to get some insight into how these are handled.

After reviewing a few samples we found the config extracted will sometimes contain at least one domain which is definitely Lumma which results in the classification, but this may be residual from the actor not cleaning up the config completely before new campaigns. This said, we only reviewed a limited number of samples so it’s not a complete view.

We will keep an eye out and update our automation process to handle Aura going forward based on telemetry we see. I was curious and found that the trend of Lumma (DNS) sigs being released drops off significantly between July and October which correlates with what you’ve seen.

JSON-preview
JSON-preview2250×1049 153 KB

Here are a few signatures I got in yesterday with traffic from your sample + a few pivots

ET MALWARE Aura Stealer CnC Exfil (POST) - 2065858
ET MALWARE Aura Stealer CnC Response (false) - 2065862
ET MALWARE Aura Stealer CnC Response (true) - 2065861
ET MALWARE Aura Stealer Conf Checkin (POST) - 2065859
ET MALWARE Aura Stealer Victim Checkin (GET) - 2065860
ET MALWARE Observed Aura Stealer Domain (magicupdate .cfd in TLS SNI) - 2065865
ET MALWARE Observed Aura Stealer Domain (mscloud .cfd in TLS SNI) - 2065856
ET MALWARE Observed Aura Stealer Domain (searchagent .cfd in TLS SNI) - 2065857
ET MALWARE Observed DNS Query to Aura Stealer Domain (magicupdate .cfd) - 2065864
ET MALWARE Observed DNS Query to Aura Stealer Domain (mscloud .cfd) - 2065854
ET MALWARE Observed DNS Query to Aura Stealer Domain (searchagent .cfd) - 2065855
1 Like
5

I just stumbled across this, very cool you got an interview :fire::fire::fire:

https://g0njxa.medium.com/approaching-stealers-devs-a-brief-interview-with-aura-9b513369e117

1 Like
6

This is wonderful, thanks to you for all the amazing work!

1 Like
7

Hi, guys

We’ve found some anyrun tasks that produce alert on sid 2065860

image
image952×898 16.9 KB

HTTP request to RMM tool server, you can see alerts:

ET INFO Observed RMM Domain (gotoresolve .com in TLS SNI)

ET INFO Observed DNS Query to RMM Domain (gotoresolve .com)

Alert for ET MALWARE Aura Stealer Victim Checkin (GET) sid: 2065860 we found in our tool during retroscan public PCAPs

Best regards,
Evgeny Bechkalo, AVLab Positive Technologies

1 Like
8

Thanks for notifying us, 2065860 shouldn’t be alerting on logmein traffic so I’ll get this updated today.

The other two signatures are working as designed. They’re set as INFO and shouldn’t affect the verdict of whether or not something is malicious.

Thanks!
Isaac

1 Like