Cereal: How the Turla Group Steals Mail from Government Exchange Servers

On November 10, 2026, researchers at the Slovak company ESET published an analysis of a new cyber-espionage toolkit they named Cereal. It's used by Turla (also known as Snake and Secret Blizzard) — one of the oldest and most sophisticated state-espionage actors, active since at least 2004. Per ESET and Western intelligence, Turla is part of Russia's Federal Security Service (FSB).

Cereal's main feature is how it works. The toolkit is designed to run directly on the Microsoft Exchange servers of compromised organizations: it receives commands, executes them in memory, maps the victim's infrastructure, and selectively steals emails. Notably, researchers found no external command-and-control (C&C) server — the attackers turned the victim's own server into the control point.

What Cereal is and who's behind it

ESET first encountered Cereal on November 28, 2025 on the Exchange server of a government organization in Kazakhstan. At first it looked like a set of scattered suspicious components, but reconstructing the attack chain revealed a previously undocumented toolkit: a collection of modular .NET programs built to work specifically on Exchange servers.

A month later, after tuning detections, the same toolkit was found in Romania — on a government institution's server compromised December 23, 2025. There, the mail-theft module was configured to collect messages addressed to NATO and European Union institutions.

The name "Cereal" wasn't chosen at random: the toolkit heavily uses serialization — a technique for packing data and code for transport. Hence all components carry the Cereal- prefix.

Attribution to Turla rests on two facts: simultaneous use of another component publicly linked to the group, and conceptual similarity to an older Turla malware. ESET's confidence is high.

Architecture: a modular set of .NET components

Cereal isn't one monolithic backdoor but a chain of specialized components built around several principles: keep the payload encrypted, run code in memory, reuse the compromised server, and deliver commands as separate .NET assemblies.

The toolkit's main components:

• CerealLoader — loads and runs a .NET assembly from an encrypted file on disk. It's the only component written to disk in a recognizable .NET form; the rest are delivered in encrypted containers and run from memory.
• CerealRunner — contains other encrypted programs, unpacks and runs them in memory, returning the result over the same channel. Effectively an "envelope" for command delivery.
• CerealSprinter — a Runner analog that only loads other components.
• CerealNeuron — a passive backdoor with no built-in commands, able to run CerealRunner assemblies received via network requests. Named after the older Neuron malware the UK's NCSC attributed to Turla back in 2017.
• CerealHermit — a Neuron variant without network functions: it reads encrypted commands from files on disk.
• CerealIron — an injector that runs .NET assemblies from processes that aren't .NET.
• CerealBox — the mail-collection module injected into the Exchange transport service.
• CerealMoth — a simple component that takes an assembly and a method name, loads and runs it.

The victim as infrastructure: C&C without external servers

The most notable part of the campaign is what ESET did not find: an external control server. Most backdoors periodically reach out to operators, leaving traces — domains, IP addresses, hosting providers, sync patterns. CerealNeuron does none of that.

Instead of outbound connections, it passively waits for inbound requests on paths that mimic normal Exchange traffic:

• https://*:443/owa/sdds/
• https://*:443/AUTODISCOVER/PROXYSERVICE/
• https://*:443/MICROSOFT-SERVER-ACTIVESYNC/INTEGRATED/API/

To a firewall or analyst, these requests blend with legitimate Outlook Web Access, Autodiscover, and ActiveSync traffic. If a request is correctly encrypted and passes several integrity checks, CerealNeuron decrypts it, treats the content as a command, and executes it. If the request is invalid — the client is redirected to a plausible Exchange error page.

The consequences are substantial:

• There's no external infrastructure to detect, block, or "take down."
• Network tracking is extremely limited: researchers couldn't establish the operators' IP addresses — they could connect directly, through anonymization services, or from other compromised hosts.
• Malicious traffic coexists with legitimate Exchange web services — exactly the traffic defenders are least inclined to block.

The backup channel is CerealHermit — the networkless version that reads encrypted command files from disk. In some intrusions both backdoors were deployed together, giving operators two independent control paths.

Commands as one-off programs

Instead of one big backdoor with every possible command, Turla operators deliver each command as a separate small .NET program. The execution core is CerealRunner: it carries encrypted .NET programs along with arguments, unpacks them, runs them in memory, and returns the result.

ESET found dozens of structurally similar CerealRunner binaries differing only in a small code fragment for the specific task. Among the commands:

• extracting mailboxes or individual messages via Exchange Web Services;
• Active Directory queries about computers, users, groups, and DNS records;
• WMI queries — for example, listing processes or active TCP connections;
• extracting LSA secrets (credentials Windows stores locally);
• listing volume shadow copies (snapshots);
• listing, reading, and deleting files — often the mail dumps exfiltrated by CerealBox.

The sheer number of near-identical binaries compiled for specific tasks points to an internal framework that automates command compilation and packing. Combined with the modular architecture, this suggests a mature, well-designed platform rather than a chaotic set of scripts.

CerealBox: intercepting mail from inside Exchange

The most innovative component is CerealBox, the mail-collection module. Turla had attacked Exchange before, including by abusing transport agents — a legitimate Exchange feature letting developers hook into the mail flow (e.g., for spam filtering). But a registered transport agent leaves visible traces in Exchange configuration.

CerealBox acts more cunningly. Instead of registering, it injects directly into the EdgeTransport.exe process — the Exchange process that handles mail flow. Once inside, CerealBox accesses Exchange's internal structures, finds already-loaded transport agents, and wraps their handlers with malicious code. The wrapper first runs CerealBox's own logic, then hands control to the original code. Mail keeps flowing normally, and no new agent appears in Exchange configuration.

With visibility into the mail flow, CerealBox selects interesting messages. A message is collected if it has a .doc, .docx, or .pdf attachment and matches at least one of the encoded lists — sender addresses, recipient addresses, subject substrings, or attachment names — while not falling into ignore lists. Selected messages are compressed, encrypted, and stored as files on disk, which operators later exfiltrate via ordinary CerealNeuron commands.

Injection into the Exchange transport service and intercepting the mail flow from inside is a technique previously undocumented for any malware family. It requires deep understanding of Exchange's mail-pipeline internals.

.NET tricks: how the malicious code hides from analysts

Normally .NET programs run through the Common Language Runtime (CLR), which converts instructions to machine code just before execution — a process visible to standard analysis tools. Cereal systematically works outside these standard paths.

CerealLoader is the only component written to disk unencrypted. In a .NET decompiler its entry point does almost nothing, and a breakpoint on the malicious method never fires. In reality, CerealLoader executes low-level machine code before the .NET runtime begins running ordinary instructions: it abuses a rare .NET spec feature — Vtable Fixups — to build a hidden bridge from native code back into a .NET method that appears to be called by nobody. An analyst looking only at the .NET side sees code that "does nothing" — while the payload has already run.

Other tricks include DLL hijacking — notably a malicious wbemcomn.dll in the WMI folder that forwards legitimate calls so the host keeps working — and placing files in the .NET native image cache under names like Microsoft.Exchange.Search.Mdb.ni.dll so the runtime loads them instead of genuine Exchange libraries.

How Turla initially penetrated victim networks, ESET doesn't disclose. However, Turla's known initial-access methods include spear-phishing, watering holes, and provider-level man-in-the-middle attacks.

Who's targeted and why it concerns Ukraine

The geography of confirmed victims matches Turla's long-standing targeting profile. Per ESET telemetry, about 70% of countries Turla attacked since 2022 are former Soviet republics or European states once closely tied to the USSR.

The Romanian case is telling: CerealBox was configured to collect mail linked to NATO and EU addresses. That focus matches Russia's long-standing intelligence priorities. It may also be tied to regional tension: since early 2025 Romania recorded Russian drones falling near or on its territory, prompting calls for a NATO mission in the Black Sea region. The Kazakh case also has political context: from January 2026 Kazakhstan began deporting some Russian exiles and regime critics.

For Ukraine this is a direct signal. Turla has worked for decades against government and diplomatic targets in the post-Soviet space and Europe, and the "make the victim's server your own infrastructure" technique makes attacks harder to detect. Government bodies and companies using on-premises or hybrid Exchange should treat this threat as relevant to them.

How to detect Cereal and protect the Exchange server

Direct signs of Cereal compromise are few — it deliberately leaves minimal traces. But there are practical steps that raise detection odds and complicate the attack:

1. Update Exchange and Windows. Most Exchange attacks start from known vulnerabilities. Timely cumulative updates (CU) and Microsoft security patches close the easiest entry paths.
2. Monitor anomalies in EdgeTransport.exe. Injection into the mail-transport process can be spotted via EDR/memory- and process-behavior-monitoring tools — watch for suspicious DLL loads and unusual assemblies executing from non-standard paths.
3. Check for transport agents and configuration changes. Although CerealBox doesn't register new agents, other components may leave traces; regular Exchange configuration audits help find third-party changes.
4. Watch for "empty" .NET assemblies. Non-standard entry points (Vtable Fixups, unmanaged entry points) are a sign of obfuscation. Analyze suspicious files in the native image cache, especially names masquerading as Exchange libraries.
5. Use ESET's IoCs. Turla/Cereal indicators of compromise are published in ESET's GitHub repository (eset/malware-ioc, turla branch) — add them to SIEM/EDR.
6. Check whether your mail appeared in known leaks via our breach-check tool — this helps assess the risk of reused compromised credentials.

Conclusion

Cereal is a carefully constructed long-term cyber-espionage tool. It leaves almost nothing on disk, avoids detectable and blockable external infrastructure, and hides inside legitimate Exchange processes. Its use of unmanaged entry points, Vtable Fixups, abuse of the native image cache, and injection into the Exchange transport pipeline demonstrates a level of .NET effort unusual even among sophisticated APT actors.

The main conclusion for defenders is simple: for Turla, an Exchange server isn't just a mail server — it's a long-term data-collection point, an internal execution node, and an environment for hiding sophisticated code. Those responsible for government and corporate infrastructure security should treat their Exchange as a potential state-level target — and build defense accordingly.