Anubis Malware/Ransomware

Anubis ransomware refers to a family of ransomware and cyber-extortion malware that has appeared in multiple, unrelated forms over time. The name “Anubis” has been reused by different threat actors, so it’s important to distinguish which Anubis is being discussed.
“Anubis” is a reused malware name, not a single lineage. Variants are not cryptographically or operationally related.


Variant A — Anubis Wiper (Fake Ransomware)

Era: ~2018–2019
Severity: Destructive / non-recoverable

Behavior

  • Encrypts files using AES/RSA
  • Encryption key is deleted immediately
  • Ransom note is fraudulent
  • Even attacker cannot decrypt

Technical characteristics

  • No C2 key escrow
  • One-time encryption key generated in memory
  • Key overwritten or discarded
  • Often masquerades as cracked software loaders

Impact

  • Permanent data loss
  • No decryption possible
  • Restore only from backups or shadow copies (rare)

Variant B — Anubis “Real” Ransomware (Commodity / RaaS-style)

Era: 2020–2022
Severity: High

Behavior

  • Standard ransomware workflow
  • File encryption
  • Ransom note with TOR payment portal
  • Some variants support key recovery if paid

Encryption

  • AES-256 for files
  • RSA-2048 or ECC for key wrapping
  • Keys sent to attacker infrastructure

Extortion

  • Usually single extortion
  • Some samples show double-extortion scaffolding, inconsistently implemented

Variant C — Anubis with Data Wiping Fallback

Era: ~2021
Severity: Critical

Behavior

  • Encrypts files
  • If sandbox/debug detected → wipes data
  • If payment deadline missed → triggers wipe

Purpose

  • Anti-analysis
  • Pressure victim to pay quickly
  • Hybrid ransomware/wiper

Variant D — Android Anubis (NOT ransomware)

Clarification only

  • Banking trojan
  • Credential theft
  • Overlay attacks
  • No file encryption

2. Common Indicators of Compromise (IOCs)

File System IOCs

Common encrypted extensions

.anubis
.locked
.crypted
.encrypted
.bin

Ransom note filenames

README.txt
README.html
RECOVER_FILES.txt
HOW_TO_DECRYPT.txt
ANUBIS_NOTE.txt

Dropped files

%AppData%\Roaming\<random>\
%ProgramData%\<random>\
%Temp%\<random>.exe

Process & Execution IOCs

  • Unsigned executables running from:
    • %Temp%
    • %AppData%
  • High file I/O + CPU usage spike
  • vssadmin delete shadows /all /quiet
  • wmic shadowcopy delete
  • bcdedit /set {default} recoveryenabled no

Registry IOCs

Persistence commonly via:

HKCU\Software\Microsoft\Windows\CurrentVersion\Run
HKLM\Software\Microsoft\Windows\CurrentVersion\Run

Defense evasion:

DisableTaskMgr
DisableRegistryTools
DisableAntiSpyware

Network IOCs

  • TOR traffic (9050 / 9150)
  • DNS to newly registered domains
  • HTTPS POSTs with:
    • Host fingerprint
    • OS version
    • Encryption status
  • Some variants are offline-only (wiper risk)

3. Infection Vectors (Observed)

VectorLikelihood
Phishing attachments (ZIP, ISO, LNK)Very High
Cracked software / keygensVery High
RDP brute-forceMedium
Trojan loaders (SmokeLoader, etc.)High
Drive-by downloadLow

4. Incident Response (IR) — Step-by-Step

Phase 1 — Containment (IMMEDIATE)

  • Isolate infected hosts
  • Disable:
    • SMB shares
    • VPN access
    • RDP
  • Block TOR traffic at firewall
  • Snapshot memory if encryption ongoing

Phase 2 — Identification

  • Collect:
    • Ransom note
    • Encrypted sample files
    • Hash of malware binary
  • Determine:
    • Is encryption symmetric + escrowed?
    • Is key stored locally? (rare but critical)
    • Evidence of key destruction?

Phase 3 — Eradication

  • Remove malware binary
  • Kill persistence mechanisms
  • Reset:
    • All credentials used on infected machine
  • Reimage systems (preferred over cleaning)

Phase 4 — Recovery

  • Restore from offline backups only
  • Verify backups are ransomware-free
  • Do NOT restore until:
    • All hosts scanned
    • Lateral movement ruled out

Phase 5 — Lessons Learned

  • Patch initial entry vector
  • Disable macros by default
  • Implement:
    • Application allowlisting
    • EDR with ransomware rollback
    • Network segmentation

5. Decryption Reality Check

VariantDecryption Possible
Anubis WiperNo
Real Anubis RansomwareSometimes
Wiper-Fallback VariantNo
Android AnubisN/A

⚠️ Never assume decryption is possible until cryptographic analysis confirms escrowed keys.


6. When to Escalate

Escalate immediately if:

  • Multiple hosts affected
  • Domain controller touched
  • Evidence of data exfiltration
  • Healthcare / critical infrastructure involved

Report to:

  • Internal SOC / DFIR
  • National CERT
  • Law enforcement (especially for data breach obligations)

In short, Anubis is dangerous not because it is sophisticated, but because it is deceptive. It looks like ransomware, talks like ransomware, and demands money like ransomware — yet in many cases it behaves like a wiper. Treating it casually or assuming decryption is possible is one of the most costly mistakes an organization can make.