The Architects of Evasion: a Crypters Threat Landscape

Crypters—tools that encrypt, obfuscate, or otherwise modify malware—are widely used to help threat actors evade detection and deliver final payloads, offered as open-source projects, private builds, or subscription-based Crypter-as-a-Service. The report details crypter types (scantime vs runtime), stub variants, polymorphism and the Crypter-as-a-Service workflow, showing how these services support large-scale, persistent malware distribution. #AttackerCrypter #VenomRAT

Keypoints

  • Crypters are programs that encrypt/obfuscate malware to bypass detection and are used to deliver RATs, infostealers and ransomware.
  • Two main anti-detection categories exist: scantime crypters (obfuscate on disk) and runtime crypters (decrypt/load in memory to evade execution-time detection).
  • Stubs perform runtime decryption; they can be public, private (regularly updated), or melt (self-deleting), and determine FUD longevity.
  • Polymorphic crypters change their stub/signature (e.g., shuffling code, inserting garbage) to resist signature-based detection.
  • Crypter-as-a-Service (CaaS) is a growing subscription model where users upload payloads, configure evasion settings, receive modified binaries, and test detections.
  • Crypter marketplaces and integrations (forums, Telegram, Sellix) enable wide distribution and partnerships with MaaS operators, increasing accessibility for less-skilled actors.

MITRE Techniques

  • [T1027] Obfuscated Files or Information – Crypters “are software programs capable of encrypting, obfuscating, and manipulating malware to bypass detection mechanisms” (used to hide payloads and alter binaries).
  • [T1055] Process Injection – Runtime crypters load decrypted portions into memory as separate processes to execute before detection: “loading decrypted portions into memory as separate processes.”
  • [T1036] Masquerading – Crypters and payloads “masquerade as legitimate software” via legitimate API/System call patterns (e.g., Kernel32, WS_32) to blend with normal processes.
  • [T1497] Virtualization/Sandbox Evasion – Crypters conceal “techniques to detect the environment or to detect debugging processes” in API calls to prevent full execution under analysis.
  • [T1566] Phishing – Modified payloads are distributed through social-engineering vectors such as “phishing or spam campaigns” to deliver the crypter-obfuscated malware to victims.

Indicators of Compromise

  • [Domain] crypter services and recommendations – crypter[.]guru, cryptor[.]biz (mentioned as recommended crypter services)
  • [Malware/Tool names] observed using crypters – VenomRAT, Bumblebee, and 6 more (e.g., Conti/Trickbot successors, Cuba, WastedLocker, Vidar, RedLine, MetaStealer)
  • [Crypter names/offerings] advertised on forums – AttackerCrypter, TrueCrypt, AnonCrypter, Royal Flush (examples of crypters cited in marketplace posts)
  • [Forums/Marketplaces] where CaaS is advertised – HackForums, XSS, and others (platforms used to sell/advertise crypter subscriptions)

The technical core: crypters transform a malicious binary so that detection engines fail to recognise it while preserving functionality. Scantime crypters modify files on disk and rely on decryption before execution, making them effective against static scanners but vulnerable during runtime; runtime crypters instead decrypt and map payload fragments directly into memory or spawn separate processes so the payload runs before defenders can react. The component that performs decryption at runtime—the stub—can be shared (public), unique and frequently updated (private), or self-deleting (melt), and its design (static vs polymorphic) largely determines how long a crypter remains FUD.

Common obfuscation techniques include custom encryption, binary rewriting (instruction rearrangement, code shuffling), junk/gap insertion (appending garbage bytes or null padding to inflate PE size), API call patterns to mimic legitimate libraries (e.g., Kernel32, WS_32), and anti-analysis checks that detect sandboxes or debuggers. Runtime approaches often load only decrypted portions into memory or inject into processes to avoid disk-based detection, and some services provide configuration options to target specific antivirus engines or enable anti-analysis features.

Crypter-as-a-Service operationally follows a repeatable pipeline: users create accounts or interact via bots, upload payloads (or use APIs), select obfuscation/runtime settings, receive the modified binary, and test it against scanners—often via offline or private tools—to iterate until detection rates are acceptable. Providers maintain regular stub updates, monitoring, and feedback loops to preserve evasion effectiveness; they may also expose APIs or Telegram integrations for automation and delivery notifications, enabling large-scale, persistent distribution campaigns by affiliates or MaaS partners.

Read more: https://blog.sekoia.io/the-architects-of-evasion-a-crypters-threat-landscape/