What are crypters?

Crypters ("криптер" in Russian) are software programs that encrypt, obfuscate, and manipulate malware so it can bypass security detection while keeping its malicious functionality fully intact. A crypter takes a known malicious payload, such as an infostealer, remote access trojan (RAT), or ransomware. It wraps it in a layer that looks harmless to antivirus and other scanners, then decrypts and runs the original malware at execution time. The crypter itself isn't malicious code; it's a tool. But its purpose in the wrong hands is to disguise malware and enable its delivery, which is why crypters are a foundational component of the modern cybercrime supply chain. The ultimate goal is FUD status, short for Fully UnDetectable: the packaged malware evades every security vendor.

Key takeaways

A crypter hides malware, it isn't the malware: it wraps an existing payload in encryption and obfuscation so scanners see something benign.
The stub is the heart of a crypter: this component decrypts the payload at runtime and loads it into memory.
FUD is the goal: Fully UnDetectable status means no security engine flags the packaged file, and it's always temporary.
Scantime vs runtime: scantime crypters evade static, on-disk scanning; runtime crypters must also defeat in-memory defenses like EDR and AMSI.
Crypters are a business: sold as crypter-as-a-service on underground forums, they let non-experts make any malware evasive through a simple interface.

What does a crypter do?

A crypter's job is deception. Modern security products detect known malware through signatures (patterns matching known-bad code) and, increasingly, behavioral analysis. A crypter defeats that first line by transforming the malicious file so its signature no longer matches anything in the antivirus database, while ensuring the original code still runs exactly as intended once it reaches the targeted system.

It typically does this by encrypting or obfuscating the payload and modifying the program to decrypt itself during execution. Better crypters add extra layers: fake icons and metadata that make the file look like a legitimate application, and evasion techniques that slow down or block analysis. Because the crypter is a completely independent module, threat actors can use the same one to protect any malware they want to deliver. That's also why identifying the crypter alone doesn't reveal which malware family is hidden inside.

How crypters work: The stub

A crypter typically encrypts or obfuscates a binary and modifies it to decrypt itself at runtime. The component responsible for decrypting the main payload is called the stub ("стаб" in Russian). When the packaged file is executed, the stub runs first, decrypts the real malware into memory, then launches it, often using techniques such as RunPE or dynamic forking, where a legitimate process is started in a suspended state and its memory is overwritten with the malicious payload.

The stub is both the crypter's engine and its weakness. Because it's a static, reusable component, once security vendors fingerprint a particular stub, any malware packaged with it is quickly detected and the crypter becomes useless. This is the defining economic fact of the crypter world: to stay effective, stubs must be changed and updated constantly. Sekoia's Threat Detection & Research (TDR) team distinguishes three stub types:

Public (shared) stubs are widely available and shared among many users. Free or cheap, but detected quickly because they're so common.
Private stubs are unique to one user or a small group and updated regularly, often daily, to stay ahead of antivirus signatures. More expensive, but they keep the malware FUD for longer.
Melt stubs are designed to be self-destructive, removing traces of the dropper after execution.

Types of crypters

Scantime vs runtime crypters

A scantime crypter keeps the payload encrypted on disk so it bypasses traditional, static antivirus scanning; the file only becomes readable when it's executed. A runtime crypter goes further: it must also evade defenses that inspect what happens in memory during execution, such as host intrusion detection systems, Windows AMSI, and endpoint detection and response (EDR). Runtime crypters are more complex, often injecting code into running processes or rewriting code during execution to stay hidden from behavioral monitoring.

Static, polymorphic, and metamorphic crypters

A static crypter uses a fixed, pre-defined stub that stays the same across every payload it packages. Simple and cheap, but once that stub's signature is known, everything it produces is caught. A polymorphic crypter generates a unique stub for every build, changing keys, inserting junk code, altering control flow, and randomizing API call sequences, so no two outputs share a signature. That defeats hash- and signature-based detection. Metamorphic crypters go further still by rewriting their own logic. The more dynamic the crypter, the longer it retains FUD status against static analysis, though behavioral detection can still expose poorly implemented mutation.

Crypter vs packer vs protector vs loader

These terms overlap and are often used interchangeably, but they describe different tools with different primary goals.

Tool	Primary goal	Notes
Crypter	Encrypt/obfuscate malware to evade detection	Focused on antivirus evasion; decrypts payload at runtime via a stub
Packer	Compress a file (runtime packer / self-extracting)	Originally for size reduction; unpacks itself in memory. Not inherently malicious (e.g. `UPX`)
Protector	Prevent tampering and reverse engineering	Combines packing and encryption, sometimes code virtualization; used in gaming anti-piracy and in ransomware
Loader	Fetch and execute a payload (often remotely)	First stage of an attack; may set persistence and pull the final malware

The clean mental model: a crypter is the lock and disguise on the payload, a packer is the compressed shipping box, a protector is the anti-tamper vault, and a loader is the delivery vehicle. In practice, threat actors combine them, and a single tool may blur all four categories.

Legitimate use vs malicious use

The technology is dual-use, and it's worth being precise about the distinction. The underlying techniques (encryption, obfuscation, anti-tamper protection) have legitimate applications: software vendors use packers and protectors to guard intellectual property, license checks, and anti-piracy modules. What crosses the line is intent and context. A crypter marketed on a dark web forum with the explicit promise of making malware Fully UnDetectable is a cybercrime tool, not a software-protection product.

Complicating detection, many legitimate protectors and malicious crypters exhibit similar behaviors, such as allocating executable memory or unpacking at runtime. That's a genuine source of false positives, and part of why crypter detection is genuinely hard.

The crypter-as-a-service ecosystem

Crypter development has grown into a mature underground market. The crypter-as-a-service (CaaS) model has flourished alongside the broader commoditization of cybercrime: customers buy access to a crypter and receive updates as soon as it's detected, so they never need deep technical skills of their own. Crypter-related services have been sold since at least 2011 on Russian-speaking cybercrime forums, and today appear across marketplaces such as HackForums, Cracked, XSS, BreachForums, CryptBB, and Exploit, usually through accounts branded specifically for the purpose.

Providers typically support Windows executables and sell tiered access, with private stubs commanding higher prices for longer FUD longevity. Because the final payload is chosen by each customer, the same crypter shows up across completely unrelated malware families and campaigns, which is exactly what makes clustering crypter activity so difficult for defenders. A telling detail: crypter authors often instruct buyers not to upload samples to VirusTotal, because public exposure accelerates detection and shortens the tool's useful life.

How to detect crypters

Since a crypter's whole purpose is to defeat signatures, detection has to look beyond static patterns. Effective approaches combine several signals:

Behavioral analysis: watch for suspicious runtime behavior, such as a process allocating executable memory and decrypting content into it, self-injection, or delayed execution.
Memory scanning: inspect what's actually running in memory after the stub decrypts the payload, since the real malware is only revealed at runtime.
Entropy and heuristic analysis: high entropy in a file's sections is a classic sign of encryption or packing and triggers heuristic alerts.
Stub fingerprinting and reputation: reused public stubs are flagged quickly through hash correlation once a signature exists.
EDR, XDR, and sandboxing: detonating a suspicious file in a sandbox and correlating behavior across telemetry catches what static scanning misses.

Expert insight: Detect the behavior and map the ecosystem

A crypter is engineered to win the static-detection game, so chasing it with signatures alone is a losing strategy. The entire CaaS economy exists precisely to stay one step ahead of signature databases, refreshing stubs daily. Sekoia's TDR team has documented this in detail in its crypter threat landscape report. Two things actually work.

First, behavioral in-memory detection. However well the payload is disguised on disk, the stub must eventually decrypt and run the real malware, and that runtime behavior (memory allocation, injection, the payload's own actions) is detectable. Second, intelligence on the ecosystem itself: knowing which crypters are active, which stubs are circulating, and which threat groups favor them.

That's where Sekoia's approach fits the problem. Because a crypter can wrap any payload, identifying the crypter alone gives defenders little. The value is in correlating runtime behavior with fresh intelligence about the crypter ecosystem. Sekoia Defend applies roughly 1,000 detection rules mapped to MITRE ATT&CK, targeting the process-injection, memory, and execution behaviors that a stub produces when it unpacks, rather than relying on a static signature for the disguise. Those detections are enriched by Sekoia Intelligence, where the TDR team actively tracks the CaaS market, its stubs, its forums, and the malware families it delivers. Every new indicator is retro-hunted across historical events through the platform's 300-plus integrations. For European organizations, it comes with a data-sovereignty posture that US generalists rarely match.

You won't out-signature a crypter. Detect the behavior it can't hide, and back it with intelligence on the ecosystem that produces it.

‍

Frequently asked questions

What is a crypter?

A crypter is a software program that encrypts and obfuscates a piece of malware so it evades security detection while keeping its malicious functionality intact. It wraps a payload such as a RAT, infostealer, or ransomware in a layer that looks benign to antivirus, then decrypts and runs the original malware at execution time via a component called the stub.

What is the difference between a crypter and a cryptor?

There's no meaningful difference; "crypter" and "cryptor" are two spellings of the same concept: a tool that encrypts or obfuscates malware to avoid detection. Some sources also use "packer," "protector," and "loader" loosely as synonyms, though those describe technically distinct tools with different primary goals.

What does FUD mean in the context of crypters?

FUD stands for Fully UnDetectable. It describes a crypter, or the malware it packages, that evades every security vendor's detection. FUD is the ultimate goal for malware authors, but it's always temporary: once security products fingerprint the crypter's stub, the packaged malware is detected and the crypter must be updated to regain FUD status.

What is a stub in a crypter?

The stub is the part of a crypter-modified program that decrypts the hidden payload at runtime and loads it into memory. It's the crypter's core component and its main weakness: because the stub is static and reusable, once antivirus vendors fingerprint it, any malware packaged with that stub is quickly detected, which is why stubs are updated constantly.

What is the difference between a scantime and a runtime crypter?

A scantime crypter keeps the payload encrypted on disk to bypass static, on-disk antivirus scanning; the payload is only exposed when executed. A runtime crypter must additionally evade in-memory defenses such as host IDS, Windows AMSI, and EDR, so it's more complex, often using process injection or code rewriting during execution.