HomeMalware Analysis
AsukaStealer: The Next Chapter in ObserverStealer’s Story
HomeMalware Analysis
AsukaStealer: The Next Chapter in ObserverStealer’s Story

The following research was conducted by Anna Pham, also known as RussianPanda, a Senior Threat Intelligence researcher and a guest author for the ANY.RUN Blog. For more of her expert insights, follow her on Twitter/X. Now, let’s get started with the analysis.

On May 19, 2023, an individual known by the pseudonym ‘breakcore’ announced that AsukaStealer was available for sale at $80 a month. Developed in C++, AsukaStealer includes capabilities to deploy additional payloads on infected computers, configure FileGrabber settings, and facilitate log delivery via Telegram, among other features.

Figure 1: AsukaStealer sell announcement 

It’s worth mentioning that breakcore used the pseudonym ObserverStealer before and was selling ObserverStealer on hacking forums until July 2023.

Figure 2: Username history on the hacking forum 

ObserverStealer failed to gain popularity among cybercriminals and received predominantly negative reviews. 

Figure 3: Technical discussion thread on ObserverStealer (source: XSS forum) 
Figure 4: WhiteSnake’s comment on ObserverStealer 

In this write-up, we will dive into the analysis of AsukaStealer (MD5: 32583272b5b5bd95e770661438b41daf) to determine if it’s the rebrand of ObserverStealer.

Follow along with the analysis in the ANY.RUN sandbox 

Sign up for free

AsukaStealer Technical Analysis 

As mentioned before, AsukaStealer is written in C++ with a file size of approximately 440KB for the payload that hasn’t been encrypted.  

When submitting the sample to ANY.RUN, we immediately see the attribution to ObserverStealer, as shown in the image below. That hints that the code or traffic for ObserverStealer is potentially similar to AsukaStealer.  

Figure 5: Attribution tag 

The noticeable things in the binary are the base64-encoded and hexadecimal values. AsukaStealer implements XOR encryption for C2 addresses. In our case, “1d6f6623f5e8555c446dc496567bd86e” is the key, and “WRBCFgwZHQZIAVcWAwMbUQEOBVRTBA==” is the encrypted C2 address. It’s worth noting that AsukaStealer uses one C2 address to receive the logs unless the clients configure their custom proxy, which is also an option. For each stealer build generated, the base64-encoded and the hexadecimal values change.   

Figure 6: Embedded Base64-encoded and hexadecimal values 
Figure 7: Decrypted string (Source: CyberChef) 

AsukaStealer uses GetCurrentHwProfileA function to obtain information about the hardware profile of the machine. The obtained HWID value is then appended to the logs file “SystemInfo.txt” and sent out to the C2 server as the first POST request.  

Figure 8: Obtaining HWID/GUID value 
Figure 9: Obtaining the HWID/GUID value (Behavior activities from ANY.RUN analysis) 
Figure 10: Process details from ANY.RUN analysis 

To gather extra system information, the stealer accesses the registry value at SOFTWARE\Microsoft\Windows NT\CurrentVersion\ProductName to retrieve the operating system’s product name. Additionally, the UserDefaultLangID function determines the current user’s language preferences. The architecture of the system is identified using the GetNativeSystemInfo function, which yields the “SYSTEM_INFO” structure. This structure includes the critical member wProcessorArchitecture. When wProcessorArchitecture indicates a value of 9, it signifies that the system operates on a 64-bit architecture (either AMD or Intel). Any other value suggests the system is based on a 32-bit architecture. Furthermore, the language identifier is adeptly acquired through the GetUserDefaultLangID API, ensuring a precise understanding of the user’s language setting. Next, the username is obtained via the GetUserNameW function, and detailed display information is retrieved from EnumDisplayDevicesW. 

Figure 11: Gathering system information 

The gathered system information is then parsed accordingly to the fields:  

  • username 
  • timezone 
  • cpu 
  • os 
  • display_size 
  • ram 
  • arch 
  • locale 
  • apps 
  • devices 
Figure 12: Parsing system information 

The stealer probes the registry path SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall, zeroing in on the DisplayName registry value. It compiles a list of installed applications from this data and subsequently adds this information to the SystemInfo.txt file. 

Figure 13: Accessing the registry key to get installed application products 

The system information and list of installed applications are then sent over to C2, which we will go through later in this article. 

AsukeStealer scans for active processes like Telegram.exe, Steam Desktop Authenticator.exe, and steam.exe. It initiates this process by invoking CreateToolhelp32Snapshot to capture a snapshot of all running processes, subsequently iterating through each process in the snapshot with Process32FirstW. 

Figure 14: Iterating through specific running processes 

If it finds any of the running processes, it searches for the following (based on the configuration fetched from the C2 server): 

For Steam Desktop Authenticator, it searches for any files within the /files/ directory, indicated by the .* regex, which matches any character (except for line terminators) zero or more times. 


  • Steam Desktop Authenticator.exe: 
  • Folder/Pattern: /maFiles/ 
  • Regex Pattern: .* 

For Telegram.exe, within the /tdata/ directory, it looks for: 

  • Files that are exactly 16 or 17 characters long at the end of the string (likely unique identifiers or encrypted file names). 
  • Specific filenames or patterns including usertag, prefix, key_datas, settingss (with an optional file extension), countries, devversion, configs, and maps. 


  • Telegram.exe 
  • Folder/Pattern: /tdata/ 
  • Regex Pattern: (.{16,17}$)|usertag|prefix|key_datas|settingss(\.(\w+))?|countries|devversion|configs|maps 

For steam.exe, it searches globally (indicated by /) for: 

  • Files starting with ssfn followed by any number of digits (associated with Steam user authentication files). 
  • Specific Steam configuration and data files: loginusers.vdf, libraryfolders.vdf, DialogConfig.vdf, and config.vdf. 


  • steam.exe 
  • Folder/Pattern: / 
  • Regex Pattern: ssfn([0-9]+)|loginusers\.vdf|libraryfolders\.vdf|DialogConfig\.vdf|config\.vdf 

After that, it assigns the tag “PG”, presumably meaning “Process Grabber,” to the X-Config header; the identified process and the corresponding path to the file from the configuration are appended to the X-Info header and split with a pipe that is sent to the C2.server, for example:  

  • X-Info: Steam Desktop Authenticator.exe|<path_to_ maFiles> 

The function below captures the infected machine’s screenshot using API functions such as GetDC, CreateCompatibleDC, GetDeviceCaps, CreateCompatibleBitmap, etc. The value “{557CF406-1A04-11D3-9A73-0000F81EF32E}” is the encoder that is used to save the image; in our case, it’s PNG.   

Figure 15: Function responsible for taking the screenshot 

The following files are gathered and sent over to C2: 

  • cookies.sqlite – stores the cookies. 
  • logins.json – stores the passwords. 
  • cert9.db – stores the security certificate settings. 
  • key4.db – stores the master password. 

The files gathered are essential for decrypting Firefox browser data. For each file collected, a new UUID is generated using the UuidCreate function. These UUIDs are then attached to the traffic data for each file sent to the C2 server for subsequent password decryption. It is also worth noting that the UuidCreate function is utilized for other data exfiltrated from the host, including crypto wallets, the Grabber module, Steam, Telegram, and more. 

Figure 16: Gathering Firefox sensitive files for password decryption 
Figure 17: Using UUIDCreate to create a new UUID 
Figure 18: Generated UUIDs used for communication with C2 server 

The regex pattern “\”encrypted_key\”:\”(.+?)\”” is used to retrieve either the encrypted key or the encrypted master password from the Google Chrome Local State file. This pattern specifically targets a JSON field named “encrypted_key” to extract its value. The “(.+?)” segment is a non-greedy capturing group designed to match and capture the shortest sequence of one or more characters that fulfill the pattern. 

Figure 19: Regex pattern to look for the encrypted key 
Figure 20: The stealer reading Local State file (ANY.RUN) 

The extracted key is then Base64-decoded and decrypted via CryptUnprotectData function.  

Figure 21: Base64-decoding function 

Get a personalized demo of ANY.RUN for your team
See how it can help your organization 

Schedule a demo

C2 Communication 

Upon initial infection, the machine retrieves the X-Session ID from the server using URLOpenBlockingStreamW API that is responsible for creating a blocking type stream object from a URL and retrieving the data from the Internet using the GET request format “<C2_IP>/s?id=X-ID”, where X-ID stands for the log ID, assuming that’s how the logs are correlated with the infected instance. The X-Session ID will be used for further communication with the C2 server. The stealer configuration is also retrieved from the C2 using the mentioned API following the GET request format “<C2_IP >/?id=X-ID”

Figure 22: Retrieving stealer’s configuration from C2 server 
Figure 23: Retrieving X-Session ID from the server C2 

Interestingly enough, the configuration file and the X-Session ID can be found under C:\Users\<username>\AppData\Local\Microsoft\Windows\Temporary Internet Files\Content.IE5\, where Windows stores cached internet files. 

Figure 24: Configuration and X-Session ID found in cached internet files 

Next, the infected machine sends out the POST request with HWID information with “HWID” appended to the X-Config custom header. If the server responds with “ok”, the infected machine will further send more exfiltrated logs.

Figure 25: Sending HWID to C2 server 

After receiving the “ok” response from the server, the infected machine sends out gathered system information mentioned previously with “SYS” appended to the X-Config header.  

Figure 26: The infected host sending out collected system information 

Further, the host proceeds with sending out the captured screenshot with “SCR” appended to X-Config header. 

Figure 27: Sending out the screenshot to the C2 server 

Starting with Chrome 80, Google Chrome encrypts cookies and passwords using AES-256 encryption in GCM mode, with the encryption key (state key) stored in the Local State file. This state key is further secured using the Data Protection API (DPAPI). To decrypt cookies or passwords, the encrypted state key is first decrypted with the master key managed by DPAPI. Once the state key is decrypted, it is used to decrypt cookies or passwords. While Chrome, similar to Firefox, decrypts cookies and passwords on the server, the decryption of the master key occurs on the infected machine. The master key is then transmitted to the server, labeled as “Google_KEY” in the X-Config header. 

Figure 28: Sending the decrypted Google Chrome master key to the C2 server 

After the master key is transmitted and an “ok” response is received, the Login Data from Google Chrome is sent using “Google_LGP” as the X-Config header. 

Figure 29: Sending out Login Data of Google Chrome to the C2 server 

The Cookies file is sent using “Google_COK” for the X-Config header. 

Figure 30: Sending out Google Chrome Cookies to the C2 server 

The Web Data file of Google Chrome is sent using “Google_WBT” for the X-Config header. 

Figure 31: Sending out Google Chrome Web Data to the C2 server 

For Edge, similar strings will be applied: _KEY for the master key, _LGP for Login Data, _COK for Cookies, and _WBT for Web Data. For Firefox, the strings are _FLGP (for cert9.db and key4.db files) and _FCOK (for the cookies.sqlite file). 

ObserverStealer vs AsukaStealer 

The codes of ObserverStealer and AsukaStealer are quite similar. Both stealers retrieve their configurations in the same manner. However, unlike ObserverStealer, AsukaStealer does not parse cookie parameters on the infected host, such as expiry, isSecure, and isHttpOnly. 

ObserverStealer downloads DLL dependencies, such as nss3.dll, from a server to decrypt and parse cookies and login data, utilizing functions like PK11_Authenticate, PK11_GetInternalKeySlot, and PK11_FreeSlot. AsukaStealer, on the other hand, forgoes the downloading of these dependencies and directly decrypts the data on the server. This approach reduces its digital footprint and helps in evading detection.

Figure 32: Using APIs from nss3.dll to decrypt browser data 


Figure 33: ObserverStealer retrieving the dependencies from the C2 server 

ObserverStealer parses AutoFill data directly on the host, whereas AsukaStealer is likely to perform this parsing on the server. 

Figure 34: ObserverStealer parsing credit card AutoFill data 

Looking at the network traffic for ObserverStealer, we can confirm that the data is being decrypted on the infected host instead of the server.

Figure 35: Decrypted cookies sent to C2 server (ObserverStealer network traffic) 
Figure 36: Decrypted browser password sent to C2 server (ObserverStealer network traffic) 

ObserverSteater employs XOR encryption for the C2 as well. But the key is not generated randomly and is rather hardcoded.

Figure 37: Hardcoded XOR key 


AsukaStealer shares fundamental similarities with its predecessor, ObserverStealer, including C2 communication and XOR encryption. However, AsukaStealer sets itself apart by eliminating the requirement for external DLL dependencies for data parsing and decryption, preferring server-side operations to improve stealth and minimize its digital footprint. The motivation behind the rebranding of ObserverStealer is believed to be the negative feedback from users, as well as the malware developers’ intent to enhance the stealer based on previous critiques, albeit under a new name.


ANY.RUN is a cloud-based malware analysis platform designed to support the work of security teams. It boasts a user base of 400,000 professionals who utilize the platform for threat analysis on Windows and Linux cloud virtual machines.

Benefits of ANY.RUN

  • Instant detection: ANY.RUN can detect malware and identify various malware families using YARA and Suricata rules within approximately 40 seconds of file upload.
  • Hands-on analysis: In contrast to many automated tools, ANY.RUN offers interactive capabilities, allowing users to engage directly with the virtual machine through their browser. This feature helps prevent zero-day exploits and advanced malware that can bypass signature-based detection.
  • Affordable: ANY.RUN’s cloud-based nature makes it a budget-friendly solution for businesses, eliminating the need for setup or maintenance efforts from the DevOps team.
  • Ideal for training: ANY.RUN’s user-friendly interface enables even junior SOC analysts to quickly learn how to analyze malware and extract indicators of compromise (IOCs).

See how ANY.RUN can contribute to your organization’s security. Get a demo of the service for your team.

Schedule a demo

Appendix 1: IOCs 

AsukaStealer sample: https://app.any.run/tasks/8b1ee45a-87de-4fc5-a755-84546a974a44/ 

SHA256: 0E5470A33FD87B813ECF72370F9E1F491515C12F41C8EA3C7BBC169AC56ACDA5 

ObserverStealer sample: https://app.any.run/tasks/e8a05e7f-9fd4-4b4c-9fdb-791ef29f382e/ 

SHA256 (unpacked sample): 476171DD2EB7F118D3E0AFF32B7264D261BA4C2D9FA6C14CCFF6D8D99B383DB4 

Unpacked sample: https://www.unpac.me/results/20720ac8-1f14-4c62-926a-e9990d5677e3#/ 


You can access the configuration for AsukaStealer on the GitHub page


I have created a YARA rule to detect AsukaStealer. You can access it on the GitHub page

Anna Pham
Senior Threat Intelligence researcher | + posts

Senior Threat Intelligence researcher by day and malware enthusiast by night.
Anna's LinkedIn.

Anna Pham
Senior Threat Intelligence researcher
Senior Threat Intelligence researcher by day and malware enthusiast by night.
Anna's LinkedIn.

What do you think about this post?

7 answers

  • Awful
  • Average
  • Great

No votes so far! Be the first to rate this post.