{
  "family": "eziriznetreactor",
  "sample_count": 5,
  "category": "ransomware",
  "description": "HackTool:MSIL/Eziriznetreactor (often detected as a generic Suspicious or PUA file) refers to the malicious abuse of the legitimate **Eziriz .NET Reactor** software. .NET Reactor is a powerful, commercial code obfuscator and licensing system designed to protect intellectual property in C# and VB.NET applications. However, because it provides exceptional anti-decompilation, string encryption, and control flow obfuscation, it is heavily favored and weaponized by malware authors to hide their malicious .NET payloads (like Agent Tesla, Formbook, or custom RATs) from antivirus engines and reverse engineers.<br><br><b>Understanding .NET Reactor Abuse</b><br>To an end-user, executing a file packed with .NET Reactor looks perfectly normal. For a malware analyst, encountering a malicious payload wrapped in .NET Reactor is incredibly frustrating. The tool is highly effective at scrambling the Microsoft Intermediate Language (MSIL) code, turning readable C# into spaghetti code, hiding API calls, and encrypting embedded resources. EDR systems frequently flag files protected by it heuristically simply because so much malware utilizes it.<br><br><b>Execution and Evasion Mechanics</b><br>The malware author writes their malicious C# code (`T1204.002`). Before distribution, they run the compiled `.exe` through the Eziriz .NET Reactor software. The software packs the binary (`T1027.002`), encrypts all strings (`T1027`), and adds 'Anti-Tampering' and 'Anti-Debugger' modules (`T1622`). When the victim runs the packed file, the .NET Reactor stub executes first, decrypts the original malicious code directly into memory, and executes it without dropping the clear-text payload to disk. Because the on-disk file is heavily obfuscated and uniquely packed, static signature-based detection is rendered almost entirely ineffective.<br><br><b>Indicators of Compromise & Impact</b><br>The impact depends entirely on the hidden payload (which could be anything from a simple credential stealer to ransomware). Host-based IoCs include EDR alerts for 'Suspicious Packed Executable' or the identification of specific .NET Reactor metadata or stub signatures within the binary (e.g., specific randomly generated namespace structures or references to `SecureTeam.Attributes`). Analysts must use advanced .NET deobfuscators (like de4dot) or dynamic debugging (dnSpy) to attempt to unpack the binary in memory to reveal the true payload.",
  "cta": "Published by the SystemHelpdesk team.",
  "aliases": [],
  "enrichment_level": "expert-seo",
  "faq": [],
  "faq_count": 0,
  "mitre_attack": [
    "T1027.002",
    "T1129",
    "T1204.002",
    "T1622"
  ],
  "cisa_advisory": null,
  "last_updated": "2026-06-09",
  "mitre_attack_detail": [
    {
      "id": "T1027.002",
      "name": "Obfuscated Files or Information: Software Packing (.NET Reactor)",
      "tactic": "Defense Evasion"
    },
    {
      "id": "T1622",
      "name": "Debugger Evasion (Anti-debugging techniques injected by the packer)",
      "tactic": "Defense Evasion"
    },
    {
      "id": "T1129",
      "name": "Shared Modules (Loading .NET assemblies dynamically)",
      "tactic": "Execution"
    },
    {
      "id": "T1204.002",
      "name": "User Execution: Malicious File",
      "tactic": "Execution"
    }
  ],
  "containment_steps": [
    "Isolate the endpoint to prevent the hidden, injected secondary payload from communicating with its C2 server or exfiltrating data.",
    "Submit the obfuscated binary to a sophisticated malware sandbox (like Joe Sandbox or ANY.RUN) to observe its behavioral IoCs, as static analysis will fail.",
    "Use specialized memory forensics tools to dump the memory of the running process to extract the final, unencrypted payload after the .NET Reactor stub has decrypted it.",
    "Block the sender IP and domain from the initial phishing email that delivered the packed executable."
  ],
  "what_to_avoid": [
    "Do not assume a file is safe just because static AV engines report it clean; commercial packers like .NET Reactor are designed specifically to bypass static analysis.",
    "Avoid attempting to manually reverse engineer heavily obfuscated .NET Reactor files without automated deobfuscation tools, as the control flow flattening will waste massive amounts of time."
  ],
  "target_industries": [
    "Global / Opportunistic"
  ],
  "motivation": "Opportunistic",
  "threat_actors": [
    "Unknown / Cybercriminal"
  ],
  "target_geographies": [
    "Global"
  ]
}