Chihuahua Stealer Malware Targets Browser and Wallet Data

Chihuahua Infostealer is a multi-stage .NET-based malware discovered in April 2025. It targets browser credentials and crypto wallet data, using obfuscated PowerShell scripts delivered via trusted platforms like Google Drive. Stolen data is encrypted and exfiltrated over HTTPS, with local traces wiped to evade detection.

In this blog, we break down Chihuahua’s infection chain, delivery methods, evasion tactics, and data theft techniques. We also map its behavior to MITRE ATT&CK and share key indicators of compromise (IOCs) and defensive strategies to help security teams detect and respond effectively.

Threat Actor Origin and Key Characteristics

Origin of the Chihuahua Infostealer Developers

As of this writing, no specific threat actor or group has been conclusively attributed to Chihuahua Infostealer. However, there are hints that could suggest its origins. 

For example, the malware’s developer embedded lines of transliterated Russian rap lyrics in the code, printed to the console during execution [1]. This quirk serves no functional purpose but may act as a cultural or personal signature. It could indicate the author has a Russian background or influence, although this is not definitive evidence of attribution.

Key Characteristics of Chihuahua Infostelar Malware 

Unlike older “smash-and-grab” stealers, Chihuahua adopts a more refined approach designed to evade detection and maintain persistence on infected systems. It reflects a broader trend toward stealthier, more feature-rich infostealers. With multi-stage loaders, cloud-hosted delivery, native API-based encryption, and meticulous cleanup routines, Chihuahua exemplifies the evolution of infostealer design toward resilience and long-term stealth.

Delivery Methods and Download Stages of Chihuahua Infostelar 

Chihuahua Infostealer typically begins with social engineering that tricks victims into executing a malicious PowerShell script. 

Figure 1. A Redditor got tricked into running a malicious PowerShell script

In the first observed case, a user was lured into opening a seemingly legitimate Google Drive document, which led to the execution of an obfuscated script embedded within. This tactic takes advantage of the trust placed in cloud services like Google Drive and OneDrive, helping attackers evade filters and deliver payloads undetected.

Once triggered, the script launches a multi-stage infection chain. Victims are often convinced to run the script under the guise of needing it to access content. Delivery methods vary from phishing emails and impersonated IT messages to links shared through collaboration platforms.

While Google Drive was confirmed in this case, infostealers commonly spread through other channels, including malvertising and trojanized downloads. Trusted platforms like GitHub are also exploited. We, for instance, documented Lumma Infostealer campaigns that used fake GitHub repositories disguised as legitimate projects, an increasingly popular method for evading detection via cloud-hosted infrastructure.

The stages for delivering the main payload of Chihuahua Infostealer are as follows.

Stage 1: Initial Launch with a PowerShell Blob

The attack begins when the victim executes a malicious PowerShell loader delivered through an initial lure, such as a document hosted on Google Drive or OneDrive. This first-stage script is typically short and designed to act as a launcher for the next phase of the attack.

One observed sample uses a compact PowerShell one-liner that decodes a Base64-encoded payload and executes it directly in memory. This approach avoids writing files to disk and helps evade detection. The decoded command resembles the following (see Figure 1):

• Verb RunAs: Indicates elevated execution (run as administrator).
• -windowstyle hidden: Hides the PowerShell window.
• -nologo -noprofile: Prevents logo display and bypasses loading user profiles.
• executionpolicy bypass: Overrides policy restrictions to allow script execution.
• iex (...): Uses Invoke-Expression to run the decoded Base64 string in memory.
• FromBase64String(...): Encoded payload that gets decoded and executed.

Stage 2 – Scheduled Job and Marker-Based Payload Execution

Once decoded, the second-stage PowerShell script rebuilds a heavily obfuscated payload that’s encoded in hexadecimal format. It strips out custom separators (such as the ~ character), translates the hex values into ASCII text, and reconstructs the third-stage code directly in memory. This dynamic reconstruction technique helps the malware bypass static detection mechanisms and analysis in sandboxed environments.

The script then creates a scheduled job named f90g30g82 that runs every minute. This job continuously checks the user's Recent folder for files ending with .normaldaki, which serve as infection markers.

If such files exist, the script queries a primary C2 server at:

If the response contains a trigger keyword (e.g., "Comm"), the embedded payload is extracted, Base64-decoded, and executed via Invoke-Expression. If the server is unreachable, the script falls back to a second domain:

Actual Code: Scheduled Job & Marker-Based Execution

Stage 3 – Fallback and Final Payload Execution

The final stage enhances persistence and delivers the core stealer component.

After setting the scheduled job to run every minute, the script initiates a request to download a .NET assembly from:

This assembly is expected to contain compiled malicious code (likely as a Base64 string). Immediately afterward, the script uses a OneDrive-hosted URL to retrieve another Base64-encoded payload. This second payload carries the Chihuahua Stealer itself, which is decoded and executed directly in memory using .NET reflection.

Here’s how the execution works:

1. Fetch the encoded payload via Invoke-RestMethod.

2. Decode the payload using [System.Convert]::FromBase64String().

3. Load the decoded bytes as a .NET assembly using [System.Reflection.Assembly]::Load(...).

4. Use reflection to locate and invoke the Main method in the Program class.

5. Clean up by clearing the console, wiping clipboard contents, and exiting PowerShell.

This method of in-memory execution ensures nothing is written to disk, making detection extremely difficult for traditional antivirus or endpoint monitoring tools.

Actual Code: Assembly Loading & Execution

Operational Insight

By combining in-memory .NET execution with cloud-hosted payloads and persistent scheduled jobs, this stage finalizes Chihuahua Infostealer's deployment with stealth and resiliency. The use of trusted services (e.g., OneDrive) adds further difficulty for defenders attempting to block outbound communication or trace malicious artifacts.

Technical Breakdown of Chihuahua InfoStealer Malware

Initial Execution and Author Fingerprint

The malware's execution begins in a somewhat unconventional manner. Upon launch, the Main() function calls a method named DedMaxim(), which iteratively prints a sequence of transliterated Russian rap lyrics to the console:

The PoraMoveStaff array contains references to specific street-culture lines like “Edu iz Voronezha v Samaru v ‘Mak’ na Polevoj,” which don’t serve any operational purpose. Instead, they appear to function as a form of digital signature or cultural imprint: possibly a nod to the malware author’s background or musical influences. 

These non-functional flourishes mirror behavior seen in other themed malware that embed pop culture references or memes.

Host Fingerprinting and Unique ID Generation

Following its introductory theatrics, the stealer transitions to its core operations. One of the initial steps involves establishing a unique identifier for the infected machine. 

This is accomplished via the Prazdnik() method, which performs hardware fingerprinting by querying the device's disk serial number and machine name using WMI:

This string is passed through two custom obfuscation or hashing methods—ST52() and BTH()—to generate a normalized machine ID. This identifier is then used for naming the staging folder and stolen data archive, enabling consistent labeling across infections while obscuring the actual machine details.

Browser Data Harvesting

Chihuahua’s data collection process begins with a sweep of browser profile directories. The malware defines an array of known browser paths under the variable SinBinoklya, which includes directories for:

• Chrome
• Chromium
• Brave
• Opera (including GX variant)
• Microsoft Edge
• Slimjet
• MapleStudio's ChromePlus
• Iridium

The %PRIKUPILIXULI% token is dynamically replaced at runtime with the current user's %USERPROFILE% path, allowing the malware to adapt its lookup across different Windows environments.

After path resolution, the script checks which directories exist on the victim’s system to identify installed browsers. Valid directories are then parsed to extract sensitive content, including saved passwords, cookies, autofill data, session storage, and browsing history.

Crypto Wallet Targeting

In addition to browser data, the malware is designed to exfiltrate data from browser-based cryptocurrency wallets. It does so by matching known extension IDs against directories found within each browser profile. The extensions targeted include:

These entries consist of obfuscated Chrome extension folder names paired with their wallet identities. When a match is found, the malware attempts to extract associated wallet files or session tokens.

Persistence and Multi-Stage Delivery

Chihuahua establishes persistence using Windows scheduled tasks. The job it creates, named f90g30g82, is configured to run every minute and monitors the user’s Recent folder for .normaldaki files, which act as infection beacons.

If such a marker is found, the script contacts the primary C2 server at cdn.findfakesnake[.]xyz to fetch and execute a new Base64-encoded payload. If that server fails, it switches to a secondary endpoint at cat-watches-site[.]xyz.

Eventually, it retrieves the final stealer payload from flowers.hold-me-finger[.]xyz as a .NET assembly. This is loaded directly into memory and executed via reflection:

To further minimize detection, the script clears the terminal using clear-host, erases clipboard contents, and exits cleanly.

Summary of the Technical Analysis of Chihuahua Stealer 

Chihuahua Stealer combines theatrics, modular payload delivery, and stealthy in-memory execution to achieve data theft at scale. From its unique use of Russian rap lyrics to its targeted scraping of browser profiles and wallet extensions, this .NET-based malware demonstrates both technical fluency and personality. Its use of scheduled tasks for persistence, fallback C2 infrastructure, and dynamic payload reconstruction highlights its resilience and intent to remain undetected.

How Does Picus Help Defend Against the Chihuahua Stealer Attacks?

To defend against threats like Chihuahua Stealer, which rely on techniques such as PowerShell execution, scheduled task abuse, and in-memory payload delivery, it’s essential to validate whether your existing security controls can detect and prevent these behaviors. Instead of relying solely on static configurations or assumptions, continuously testing your defenses in real-world conditions is critical.

Picus Security enables this through automated, threat-informed validation. Leveraging a comprehensive and frequently updated threat library, the Picus Platform simulates techniques used by malware like Chihuahua, such as encoded PowerShell loaders and scheduled job persistence, in a safe and controlled manner. These automated simulations help verify the effectiveness of EDRs, NGFWs, and SIEMs, and identify blind spots before attackers can exploit them.

We strongly suggest simulating ransomware groups to test the effectiveness of your security controls against their attacks using the Picus Security Validation Platform.  

The Picus Threat Library includes the following Chihuahua Stealer threat, replicating TTPs observed in the wild.

MITRE ATT&CK Mapping of Observed TTPs

Chihuahua Infostealer’s tactics, techniques, and procedures (TTPs) can be mapped to the MITRE ATT&CK framework, illustrating the steps it takes across the kill chain. 

Below is a mapping of key observed behaviors to ATT&CK technique IDs, along with context from the malware’s operation:

Initial Access – T1566.002 (Spearphishing Link): The infection begins with a user clicking a malicious link (e.g. to a Google Drive or OneDrive document) and being tricked into running a script. This social engineering via a cloud file link is effectively a form of spearphishing using a link to deliver malware.

Execution – T1204.002 (User Execution: Malicious File) and T1059.001 (Command and Scripting Interpreter: PowerShell): Chihuahua relies on user execution of a file or script – the victim is convinced to run an embedded PowerShell command from the document. The payload is executed through PowerShell with an obfuscated command (-EncodedCommand/iex) to launch the malicious script in memory.

Persistence – T1053.005 (Scheduled Task/Job): The malware establishes persistence by creating a scheduled task (PowerShell scheduled job) that repeatedly triggers its payload without user interaction. The task, identified by a benign-looking name, ensures the malware continues running even after reboots or if the initial process ends.

Defense Evasion – T1027 (Obfuscated Files or Information): Extensive use of obfuscation is employed at multiple stages. The PowerShell loader is Base64-encoded and the second stage is hidden in a hex string, thwarting straightforward detection by scanners. By only decoding at runtime, the malware avoids having easily detectable malicious code on disk.

Defense Evasion – T1218 (System Binary Proxy Execution / Trusted Utility): The use of legitimate interpreter (powershell.exe) and system tools (schtasks, WMI, etc.) to execute malicious code is an example of “binary proxy execution.” In this case, PowerShell and Windows Scheduler do the work for the malware, making it harder to distinguish from normal admin activity.

Discovery – T1082 (System Information Discovery): Chihuahua gathers host information such as the computer name and disk serial number via WMI calls, likely to fingerprint the system. This is part of its internal ID generation and could also be used by attackers to assess the value of the target (for instance, identifying corporate machines vs. home PCs).

Discovery – T1083 (File and Directory Discovery): The malware searches for specific directories related to web browser profiles and extensions on the file system. By checking these locations, it discovers which browsers and wallet apps are present on the system before proceeding to theft.

Credential Access – T1555.003 (Steal Web Browser Credentials): The stealer targets multiple web browsers to steal stored credentials, cookies, and other sensitive data like autofill info and session tokens. This falls under stealing credentials from web browsers, a common technique for info-stealer malware.

Credential Access/Collection – Crypto Wallet Theft: (Related to T1555 for credential access or T1114 for files). Chihuahua specifically looks for files associated with cryptocurrency wallet browser extensions and steals those wallet data files. This technique doesn’t have a dedicated ATT&CK ID but is an extension of credentials and data theft, focusing on private keys/seed phrases in wallet storage.

Collection – T1560 (Archive Collected Data): The malware archives the collected data into a single file (*.chihuahua) before exfiltration. Compressing files is a way to gather everything and possibly reduce the size of data sent, as well as avoid sending a bunch of separate files.

Defense Evasion – T1027.001 (Encrypted or Obfuscated Data): Prior to exfiltration, Chihuahua encrypts the archive of stolen data using AES encryption. This ensures that even if the data is intercepted or scanned, it appears as random, unrecognizable bytes, bypassing content inspection systems.

Command and Control – T1071.001 (Application Layer Protocol: Web): For C2 communications and data exfil, Chihuahua uses standard web protocols (HTTP/HTTPS). The Stage 2 and Stage 3 communications are web requests to attacker domains (over HTTPS), which is an example of using HTTP/S as a C2 channel.

Command and Control – T1573.002 (Encrypted Channel: TLS/SSL): All network traffic for Chihuahua (payload retrieval and exfiltration) is encrypted via TLS (HTTPS). This encrypted channel hides the content of the C2 traffic from detection or content filtering.

Exfiltration – T1041 (Exfiltration Over C2 Channel): The stolen, encrypted data is exfiltrated to a remote server controlled by the attackers using the same channel as the C2 (HTTPS POST requests to their domain). Rather than using a separate method, the malware piggybacks the exfiltration on its existing C2 web communication.

Cleanup – T1070.004 (Indicator Removal on Host: File Deletion): After executing its mission, Chihuahua deletes the temporary files and archives it created, as well as any marker files or evidence of its payload on disk. This cleanup of artifacts is meant to erase traces that could be used to detect or investigate the malware’s presence.

Each of these mappings corresponds to an observed behavior from Chihuahua Infostealer. 

The malware’s use of standard tools and multi-step obfuscation shows a clear attempt to align with known adversarial techniques that are effective at evading defenses, which is why mapping them to MITRE ATT&CK is useful for defenders. By understanding these technique IDs, security teams can verify if they have detections in place for each relevant step (for example, alerts for suspicious PowerShell usage (T1059.001) or creation of new scheduled tasks (T1053.005), etc.).

Indicators of Compromise (IOCs)

Security teams can use the following IOCs and patterns associated with Chihuahua Infostealer to help identify infections or attempted attacks. (Note: Always consider context around an indicator; many can be changed by the attackers. Domains and hashes may not be static across campaigns.)

Malicious Domains (C2/Delivery): Several unique domains have been tied to Chihuahua’s operations. These were used for hosting payloads or C2 communications. They include:

• flowers[.]hold-me-finger[.]xyz – (e.g. hxxps://flowers[.]hold-me-finger[.]xyz/index2.php)
• cat-watches-site[.]xyz
• cdn.findfakesnake[.]xyz

These domains are not legitimate business domains and seeing any network traffic to them (especially from a user workstation) is highly suspicious. They should be blocked and monitored. The use of “.xyz” TLD, random words, and phrases like “findfakesnake” or “hold-me-finger” are strong signals of malicious infrastructure.

File Hashes (malware samples):

• PowerShell Loader Script 
  • SHA-256: afa819c9427731d716d4516f2943555f24ef13207f75134986ae0b67a0471b84
• Chihuahua Stealer .NET Payload
  • SHA-256: c9bc4fdc899e4d82da9dd1f7a08b57ac62fc104f93f2597615b626725e12cae8

These hashes correspond to specific samples analyzed in reports. Security teams can use them to hunt in file logs or virus total, but note that the malware author could release updated versions with different hashes. 

AV vendors have assigned detection names like Trojan-Downloader.Agent for the script and Trojan-Stealer.Chihuahua for the final payload, so updating your AV signatures is important.

File/System Artifacts:

• Unusual archive files with the extension “.chihuahua” – presence of any file ending in .chihuahua (especially in temp or user directories) is a likely sign of this malware or copycat, as this is not a common file type.

• A scheduled task or scheduled job named “f90g30g82” (or similarly random strings) running a PowerShell command. In the known case, this exact name was used, but future variants might use different random names. Any unknown scheduled task executing PowerShell, particularly one that runs very frequently (e.g. every minute) and calls out to the internet, should be investigated.

• Files with “.normaldaki” in their name or as an extension, appearing in user directories. The malware used this extension for marker files to signal an active infection. Legitimate software is highly unlikely to create .normaldaki files. If found (especially in the user’s “Recent Files” folder), it’s a red flag that a Chihuahua loader script ran on that system.

• Base64-encoded PowerShell commands or scripts in logs. Specifically, a command line invoking powershell.exe with a long encoded command (often starting with -EncodedCommand followed by a long base64 string) could be an IOC. Chihuahua’s initial stage does exactly this. While not unique to this malware, it is commonly malicious and should be reviewed.

Network Indicators: Aside from the domains above, watch for unusual patterns such as a client system making HTTP POST requests with large encrypted payloads (which could be the exfiltrated data) to unfamiliar domains, or any connection attempts to domains containing strange phrases like those listed. Also, monitor for connections to cloud storage URLs (Google Drive, OneDrive) immediately followed by PowerShell activity, as this sequence may indicate the initial payload fetch.

By monitoring these IOCs, defenders can potentially catch Chihuahua infections in early stages. 

References

[1] G DATA Security Lab, “Chihuahua Stealer: A new Breed of Infostealer,” May 2025, Available: https://www.gdatasoftware.com/blog/2025/05/38199-chihuahua-infostealer.