Anubis Ransomware Targets Global Victims with Wiper Functionality

This blog provides a detailed technical analysis of Anubis ransomware, an emerging RaaS threat known for combining data encryption with an optional file-wiping feature that permanently destroys victim data. 

By mapping its behavior to the MITRE ATT&CK Enterprise framework, we explore the full attack chain, from initial access via spear-phishing to the use of ECIES-based encryption and file-wiping mechanisms that amplify impact.

We also examine how Anubis leverages privilege checks, defense evasion, and service termination to maximize impact while minimizing detection. Security professionals can use this analysis to understand its inner workings and improve defenses against similar dual-impact ransomware campaigns.

Anubis Ransomware: Overview and Key Findings

Anubis is a Ransomware-as-a-Service (RaaS) operation first observed in December 2024, evolving from a prototype known as “Sphinx.” Its operators established presence on cybercrime forums under aliases like “superSonic,” promoting customizable affiliate programs [1]. 

Unlike typical RaaS models, Anubis supports additional monetization via access sales and data extortion. It gained traction in 2025 by combining encryption with an optional file-wiping feature that permanently destroys data. 

Anubis has targeted organizations across sectors, healthcare, engineering, construction, in Australia, Canada, Peru, and the U.S., suggesting opportunistic targeting based on access availability rather than industry-specific motivations.

Anubis Ransomware Sample Analyzed from VirusTotal

As Picus Security, we analyzed the following ransomware sample to feed our threat library.

Figure 1. Anubis Ransomware Sample

Technical Overview of Anubis Ransomware: MITRE ATT&CK Framework

Here is the technical overview of Anubis ransomware mapped to the MITRE ATT&CK Enterprise framework.

Initial Access: Spearphishing Attachment (T1566.001)

Anubis ransomware starts with spear-phishing emails containing malicious links or attachments. These emails are crafted to look like they come from trusted sources, tricking users into launching the malware. Once opened, the payload gives attackers a foothold in the system, enabling them to continue the attack. 

Phishing is critical to Anubis’s success, as it bypasses technical defenses by targeting human error.

Execution: Command and Scripting Interpreter (T1059)

Anubis leverages command and scripting interpreters with configurable parameters to streamline execution and tailor attacks to each environment. These options control key behaviors such as:

• /KEY= – sets the encryption key
• /elevated – attempts to escalate privileges
• /PATH= – defines specific directories to encrypt
• /PFAD= – excludes certain directories from encryption
• /WIPEMODE – enables file destruction mode

This design supports automation, rapid deployment, and greater adaptability. The inclusion of a wiper mode adds pressure by threatening irreversible data loss, making the ransomware particularly coercive and impactful.

Defense Evasion: Valid Accounts (T1078)

Anubis uses a smart privilege check to decide how it should proceed, based on whether it's running with administrator rights. This helps it evade detection and adapt execution in both standard and privileged environments, a common trait of mature malware.

Privilege Check Initiated

The malware runs the following call to determine access level:

The result of this check is stored in the al register.

If Admin Rights Are Found

Anubis continues execution and prepares a system-level escalation:

On screen, this would appear like:

At this point, it may relaunch with SYSTEM-level access or enable features that require full privileges.

If Admin Rights Are Not Found

It shows a fallback prompt and still offers to proceed:

Terminal output might look like:

This indicates a graceful fallback, Anubis doesn’t stop running but instead offers the chance to restart itself with the /elevated flag later, or just run with limited capabilities.

Privilege Escalation: Access Token Manipulation (T1134.002)

To determine whether it can proceed with elevated operations, Anubis performs a system-level permission check rather than directly requesting or exploiting admin rights. It does so by attempting to open a handle to the raw disk device \\.\PHYSICALDRIVE0, which represents the primary physical drive on Windows systems.

Accessing this path is considered a privileged operation because it enables low-level read/write access to disk sectors, functionality restricted to administrative users. In the function checkAdmin(), this is achieved with:

The function returns a boolean indicating whether this file handle could be opened. If successful (return auVar1._8_8_ == 0;), the ransomware infers that it has administrative privileges.

This method avoids noisy API calls like IsUserAnAdmin() or UAC prompts, making it stealthier and harder to detect security logs. Once confirmed, Anubis can create a new process using a cloned security token with elevated privileges, often via native Windows API calls like CreateProcessWithTokenW. 

This is the essence of T1134.002i impersonating a higher-privileged token to spawn a process that inherits broader access rights.

By combining this access-check logic with conditional behavior (as seen in previous figures), Anubis can dynamically escalate or fallback, depending on the current user's privilege level, making the attack more robust across different environments.

Discovery: File and Directory Discovery (T1083)

Before encryption begins, Anubis performs a directory scan to identify which file paths are eligible for processing. This is a common step in ransomware operations to maximize impact while avoiding system instability or detection.

However, to maintain system operability and prevent drawing immediate attention, Anubis includes a hardcoded exclusion list,  directories that are intentionally skipped to avoid corrupting essential OS components or triggering recovery mechanisms.

Skipped directories include:

These exclusions suggest two things:

1. Anubis avoids encrypting core system directories to prevent blue screens or boot failures.
2. It filters out developer and toolchain folders (.nuget, .gradle, .vscode) to reduce the chance of alerting developers or IT staff too early.

This discovery stage ensures that Anubis can target valuable user and business data while avoiding operational disruption that might prevent ransom payment. It reflects a controlled and goal-oriented design typical of mature ransomware campaigns.

Impact

ATT&CK T1490: Inhibit System Recovery

Anubis attempts to prevent file restoration by deleting Volume Shadow Copies, which are typically used by Windows for backup and recovery. It executes the following command:

This silently removes all shadow copies without user prompts or error messages, disabling one of the last lines of defense for restoring encrypted files.

ATT&CK T1489: Service Stop

To ensure encryption and wiping activities proceed without interference, Anubis stops or disables selected system services and processes. This may include:

• Backup agents
• Security software
• Database services
• Application servers

Below, you will find the full list of terminated processes and services by Anubis Ransomware.

Processes Terminated by Anubis Ransomware

Services Disabled or Stopped by Anubis

ATT&CK T1486: Data Encrypted for Impact

Anubis encrypts victim data using the Elliptic Curve Integrated Encryption Scheme (ECIES), a hybrid cryptosystem that uses public key cryptography to securely transmit a symmetric encryption key. 

The encryption implementation in Anubis relies on a Go-based ECIES library (github.com/ecies/go), which is directly visible through embedded function symbols such as:

These functions allow the malware to:

• Generate a new asymmetric keypair per session or victim
• Parse stored or hardcoded public keys (from hex or byte format)
• Encrypt session keys (e.g., AES keys) using ECIES before writing them to the encrypted file or ransom note

Code-Level Encryption Flow

In the disassembled code block:

The malware prepares the encryption call by assigning values to intermediate registers. The arguments likely represent:

• a1, a2: plaintext data or key material
• a4: a pointer to a structure holding encryption state or target buffer
• *((_DWORD *)&a4 + 2): a field within the structure, possibly encoding key length, flags, or buffer offsets

The github_com_ecies_go_Encrypt call handles ECIES-based wrapping of a symmetric key. If encryption fails (if (a4)), the flow enters an error-reporting block:

Here, it dereferences the buffer structure (a4 + 8) to extract an error message or failed data state, and logs it using fmt_Errorf. This level of failure handling suggests runtime resilience, where encryption failure on one file does not crash the entire execution.

Visual Indicators and System Branding

Anubis also embeds branding assets in the system to visually mark compromise. 

The function main.extractEmbeddedAssets() contains the following logic:

This extracts an ICO and JPG from the malware’s packed resources and writes them into C:\ProgramData. These files are used to:

• Replace icons for encrypted files (via shell extension or file association changes)

• Attempt wallpaper replacement to reinforce victim awareness

Wallpaper change is initiated via this command:

This modifies the registry key responsible for system wallpaper. However, if the image file isn’t present (e.g., failed extraction), this attempt silently fails, revealed in logs and telemetry during sandbox analysis.

File Extension and Ransom Strategy

Encrypted files are renamed to include the .anubis extension, which is not just cosmetic, it prevents accidental opening and clearly flags encryption success. 

A ransom note titled RESTORE FILES.html is dropped into affected directories, usually next to encrypted files like:

The ransom note includes contact instructions and threatens public exposure of stolen data if payment is not made, forming the double extortion model. The note is likely linked with a TOR-hosted panel or communication portal, though the ID may be statically or dynamically generated.

Summary of Technical Characteristics

How Picus Helps Defend Against Anubis Ransomware Attacks?

The Picus Security Validation Platform helps by safely simulating Anubis Ransomware’s techniques, such as file encryption using ECIES, shadow copy deletion, service and process termination, and stealthy privilege escalation, using its continuously updated Threat Library. These simulations uncover blind spots across EDRs, NGFWs, and SIEMs before attackers can exploit them.

The Picus Threat Library includes the Anubis Ransomware threat, emulating and simulating real-world tactics, techniques, and procedures (TTPs) to support continuous security control validation, helping organizations measure readiness, reduce exposure, and strengthen defenses against sophisticated threats.

Reference

[1] The Hacker News, “Anubis Ransomware Encrypts and Wipes Files, Making Recovery Impossible Even After Payment,” The Hacker News, Jun. 16, 2025. Available: https://thehackernews.com/2025/06/anubis-ransomware-encrypts-and-wipes.html. [Accessed: Jun. 20, 2025]