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.

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

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

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

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.  

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.   

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.  

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. 

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

• username 
• timezone 
• cpu 
• os 
• display_size 
• ram 
• arch 
• locale 
• apps 
• devices 

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. 

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. 

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. 

Configuration: 

• 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. 

Configuration: 

• 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. 

Configuration: 

• 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.   

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. 

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. 

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

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”. 

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. 

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.

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.  

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

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. 

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. 

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

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

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.

 

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

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

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

Summary 

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.

About ANY.RUN

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#/ 

Configuration 

You can access the configuration for AsukaStealer on the GitHub page. 

YARA 

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