Cereal Malware: How Turla Turned Exchange Into a Spy Hub
On a compromised government Exchange server, the most interesting email is the one nobody sees leave. ESET researchers have documented a previously unknown malware toolset, named Cereal, that sat inside the Exchange servers of government organisations in Kazakhstan and Romania, intercepted selected messages before they were delivered, and turned the victims' own mail infrastructure into the attackers' command centre. The Cereal malware campaign is one of the more sophisticated intrusions documented this year, and its most impressive feature is an absence.
The attribution carries weight and should be stated precisely. ESET attributes Cereal malware with high confidence to Turla, a Russia-aligned espionage group assessed by Western authorities to be part of Russia's Federal Security Service, active since at least 2004. The researchers found the toolset on a Kazakh government server on 28 November 2025, and after tuning detections, on a Romanian government organisation compromised on 23 December 2025. The Romanian deployment was configured to collect emails sent to or received from NATO and EU institutional addresses.
What makes the Cereal malware story notable is not just who was hit. It is how the toolset works, how little of it can be seen, and what it says about where espionage tradecraft is heading.
What the Cereal malware components do
ESET's researchers reconstruct the toolset as a chain of specialised components rather than a single backdoor. Encrypted payloads sit on disk. .NET assemblies hide inside other .NET assemblies. Legitimate Windows processes load DLLs that do not belong to them. Exchange services execute code that was never meant to run there.
The named components form a family, each with a specific job.
- CerealLoader loads and runs a .NET assembly from an encrypted file, and it is the only component written to disk as a recognisable .NET file.
- CerealRunner carries other encrypted binaries inside itself, unpacks them at runtime and executes them in memory, delivering commands and components.
- CerealSprinter does the same, used only to load and run other components.
- CerealNeuron is a passive backdoor with no built-in commands, executing assemblies received in network requests, a nod to Neuron, a malware family the United Kingdom's National Cyber Security Centre attributed to Turla in 2017.
- CerealHermit is CerealNeuron without the network parts, reading encrypted command files from disk instead.
- CerealIron injects .NET assemblies into processes that are not .NET.
- CerealBox is the email collection module injected into Exchange's transport service.
- CerealMoth loads an assembly and runs a named method.
The naming is a pun on the toolset's heavy use of .NET serialization, the technique for packaging data and code for transport. The technical report is available in ESET's white paper, and the coverage was picked up by Recorded Future News and Infosecurity Magazine.
The design principle: the victim's server is the infrastructure
The most remarkable aspect of the Cereal malware campaign is what ESET did not find. There is no attacker-controlled command and control server anywhere in the picture.
Most backdoors contact their operators on a schedule, and that behaviour is what burns them. Domains, IP addresses, hosting providers and timing patterns are how defenders find, block and take down command infrastructure. CerealNeuron does the opposite. It runs on the compromised Exchange server and passively waits for incoming web requests on paths that look like ordinary Exchange traffic, among them paths resembling Outlook Web Access, Autodiscover and ActiveSync.
If a request on one of those paths is properly encrypted and passes several integrity checks, CerealNeuron decrypts it, treats the contents as a command, and runs it. If a request looks wrong, the backdoor redirects the client to a legitimate-looking Exchange error page. To a firewall or an analyst reviewing traffic, the Cereal malware command channel is indistinguishable from the mail server doing its job.
The consequences stack up. There is no dedicated infrastructure to discover, block or take down, because the victim's own internet-facing server is the operator-accessible control point. ESET was unable to identify the ingress IP addresses the operators used, whether they connected directly, through anonymisation services, or from other compromised hosts. And the malicious traffic coexists with legitimate Exchange web services, the traffic defenders are least likely to block.
For defenders, that design defeats an entire category of detection. Network monitoring, threat intelligence feeds and sinkholes all assume the malware talks to infrastructure the defenders can eventually find. Cereal malware never makes that assumption necessary for its operators, because every byte of command traffic arrives as a HTTPS request to a server the victim already runs and already trusts.
ESET notes that abusing a compromised server as an operational hub is rare, used by only a handful of APT groups, and that Turla has used variations before. The toolset also includes a fallback: in some intrusions both backdoors ran together, giving operators two independent paths to their goals.
CerealBox: hooking the mail flow from inside
The component with the most novel technique is CerealBox, the email collection module, and its approach contrasts with Turla's own older playbook.
Turla had previously targeted Exchange through transport agents, a legitimate feature that lets developers hook into email flow for tasks like spam filtering. Installed transport agents leave visible traces in Exchange's configuration, which is a detection opportunity. Cereal malware takes a stealthier path. It is delivered through an intricate chain of nested components and injected directly into EdgeTransport.exe, the Exchange process that handles email flow.
Once inside, CerealBox accesses Exchange's internal structures, finds the transport agents already loaded, and wraps their handlers with malicious code. The wrappers run CerealBox's logic first, then hand control back to the original code. Email continues to flow normally, and no new agent appears anywhere in Exchange's configuration. ESET calls this a novel technique, not previously documented for any malware family, requiring deep understanding of Exchange's mail pipeline internals.
Having visibility into mail flow, CerealBox selects messages of interest. A message qualifies if it carries a document or PDF attachment and matches at least one hardcoded list of sender addresses, recipient addresses, subject substrings or attachment names, while avoiding ignore lists. Interesting messages are compressed, encrypted and staged in files on disk. Operators later exfiltrate and delete them through ordinary backdoor commands.
The collection rules are where the intelligence requirements become visible. Someone decided which senders, which subjects and which attachment types mattered, and encoded those decisions into the Cereal malware build delivered to each victim. That is closer to how an intelligence officer writes collection requirements than how a malware author writes features, and it explains why the two deployments differ in configuration despite sharing a codebase.
The operational discipline extends to cleanup. Staged files are deleted after exfiltration, which denies investigators the clearest evidence of what was taken. The victims know their servers were compromised. They may never know exactly which messages left the building.
Commands as disposable programs in the Cereal malware toolset
Rather than one large backdoor containing every command, the operators deliver each command as its own small compiled .NET program.
CerealRunner is the execution core. It carries other encrypted programs inside itself, unpacks its payloads, runs them in memory, and returns output through the same pipeline so CerealNeuron can encrypt and send it back. ESET detected numerous near-identical CerealRunner binaries across the two intrusions, each differing only in the small piece of code implementing a specific task. The Cereal malware architecture treats every command as a one-off program rather than a menu inside the implant, which limits what a captured sample reveals about the rest of the toolset.
The command list reads like a systematic intelligence collection plan: retrieving mailboxes or specific messages through Exchange Web Services, querying Active Directory for computers, users, groups and DNS records, running WMI queries to list processes or active connections, extracting LSA Secrets, which are credentials Windows stores locally, listing volume snapshots, and listing, reading and deleting files, often the staged email dumps CerealBox produced.
The volume of near-identical binaries strongly suggests an internal framework that automates compilation and packaging of commands. Combined with modular, interchangeable components, the impression is of a mature, engineered platform rather than a loose collection of scripts. Cereal malware, in other words, is not the work of an operator improvising with off-the-shelf tools.
The .NET tradecraft that hides Cereal malware
What separates Cereal malware from most recent APT cases is how deeply it exploits the inner workings of .NET, the framework that powers a large part of Windows and Exchange itself.
Three techniques stand out. CerealLoader executes low-level native code before the .NET runtime runs its normal instructions, abusing a rarely used feature of the .NET specification called Vtable Fixups to build a hidden bridge into a method no other part of the program appears to call. An analyst inspecting only the .NET side sees code that appears to do nothing, because by that point the real payload has already run.
Because CerealLoader can bootstrap from native code, it can be dropped where legitimate non-.NET Windows processes will load it. In one chain it posed as ncobjapi.dll in the WMI system folder, where the Windows Management Instrumentation service loaded it automatically. In another it impersonated wbemcomn.dll. The malicious DLL forwards legitimate calls, so the affected process keeps working normally, and nothing about the file prompts a second look from tools that trust Microsoft's own component names. That is the signature of Cereal malware: legitimate shapes, malicious centres.
And the operators placed malicious CerealLoader files in .NET's native image cache, the folder of precompiled common libraries that the runtime prefers to load. When Exchange asked for a library, it got the malicious version, which contains no real replacement code, so .NET falls back to the genuine library for functionality, but not before the attackers' code has executed. In one sample, the malicious code only activated when the parent process was Exchange's search service. A Cereal malware component that never runs outside Exchange is a component that file-system scans on ordinary workstations will never see.
Each technique is documented in little-known parts of the .NET specification. What is unusual is seeing them combined deliberately in one toolset, aimed at hiding inside Exchange. Most Cereal malware components are visible only in memory, and the few on-disk artefacts are either encrypted or dressed as legitimate Windows libraries.
Attribution, and why these victims fit
ESET attributes the campaign to Turla with high confidence, based on the concurrent use of another component publicly linked to Turla and conceptual similarities to older Turla malware. Turla, also known as Snake, Secret Blizzard and Venomous Bear, has targeted governments, diplomatic missions and defence organisations across Europe, Central Asia and the Middle East for two decades, and the Cereal malware toolset is consistent with that history of patient, engineered operations. ESET's telemetry shows roughly 70 percent of countries targeted by Turla since 2022 have been former Soviet republics or European countries once closely aligned with the Soviet Union.
The two confirmed victims fit that geography and, more pointedly, the intelligence priorities the collection rules encode. The Romanian component collected messages involving NATO and EU institutional addresses. ESET notes the regional context: Romania has reported repeated incidents involving Russian drones near or within its territory since early 2025, prompting calls for a NATO mission in the Black Sea region. The Kazakh compromise occurred as Kazakhstan reportedly began deporting some Russian exiles and regime critics. ESET is careful here, noting that researchers could not determine whether the operators were seeking information about dissidents, but the fit is evident.
ESET also documents a human detail that says something about the operators. Activity in Kazakhstan surged on 15 January 2026, the day after the Old New Year, an informal holiday still observed in Russia and some neighbouring countries. Malware does not celebrate holidays, but the people operating it evidently do.
What remains unknown is as important as what is known. ESET could not determine how the attackers initially gained access to the servers, or how much information they obtained. No exploitation of the Cereal malware beyond the two organisations has been reported, and detection was tuned before the campaign spread further, as far as public reporting shows.
What defenders should take from it
Three lessons generalise beyond these two victims.
First, perimeter assumptions about mail servers are outdated. An Exchange server is not just a mail relay; in this campaign it was a collection point, an execution hub and the control channel itself. Mail infrastructure belongs in the same threat model as domain controllers, and the Cereal malware campaign is the proof of concept.
Second, absence of suspicious outbound traffic is not evidence of absence. A passive backdoor that waits for incoming requests produces no beacon to flag, so detection has to come from the host: unexpected DLLs in system folders, processes whose .NET modules do not match their purpose, and mail flow handlers that exist in memory but not in configuration. Cereal malware was caught because ESET tuned detections after the first find, not because any network sensor screamed.
Third, the configuration is not the ground truth. CerealBox hijacked transport agents that were already installed and left no configuration trace. Defenders who verify Exchange security by reviewing installed agents and settings should treat runtime behaviour, loaded modules and process-level instrumentation as the authoritative view. ESET has published indicators of compromise in its GitHub repository and white paper, and organisations running Exchange should check them, because the Cereal malware indicators are public now.
Why Exchange keeps attracting state attackers
There is a reason a two-decade-old espionage group keeps investing in Exchange tradecraft, and it is not habit.
Exchange servers sit at the intersection of everything an intelligence service wants. They hold the organisation's correspondence, they touch every internal directory through mail flow, they are reachable from the internet, and they are administered by teams whose primary metric is that mail keeps flowing. A compromise of the mail server is a compromise of the institution's memory, and the Cereal malware campaign shows what that means in practice.
Cereal malware shows how far that logic can be pushed. The same server that stores the messages also stages them, relays the commands, and fronts the collection operation. No additional infrastructure means no additional exposure, and every defence the victim has invested in, uptime, encryption, legitimate certificates, works in the attacker's favour once the server is compromised.
The other lesson is about modularity as an investment. Cereal malware's components are interchangeable, its commands are disposable programs, and its framework automates delivery. That architecture means a new collection requirement does not require a new implant, just a newly compiled assembly pushed through the existing pipeline. The marginal cost of the next intelligence task is close to zero, which is why long-term intrusions of this kind persist for months before anyone notices.
For context on how this bulletin lands in a broader season of infrastructure security failures, the Linux kernel SMB flaws left unpatched for months, unauthenticated code execution surfaced in a popular AI tool, and SAP's November bulletin shipped four CVSS 10.0 flaws in the components that face the internet. Mail and collaboration servers are the terrain where state-level attackers and mundane vulnerabilities meet, and the defensive bar keeps rising. The Cereal malware campaign is what the advanced end of that terrain looks like.
Questions readers are asking
Who is behind the Cereal malware?
ESET attributes it with high confidence to Turla, a Russia-aligned espionage group widely assessed to be part of Russia's FSB and active since at least 2004. The attribution rests on a concurrently deployed component publicly linked to Turla and conceptual similarities to older Turla malware. No government has made an independent attribution, and the group itself has never commented.
Which organisations were compromised?
Two are confirmed: a governmental organisation in Kazakhstan, found on 28 November 2025, and one in Romania, compromised on 23 December 2025. The Romanian deployment was configured to collect emails involving NATO and EU addresses. ESET has not named the organisations, and no additional victims have been publicly reported.
How did the attackers get in?
Unknown. ESET could not determine the initial access method or the volume of information obtained. The research documents what ran after access, not how access was gained.
Is my Exchange server at risk?
The Cereal malware was found in two government environments, and there is no public evidence of broader targeting. That said, the techniques depend on long-standing Exchange and .NET behaviours rather than a specific vulnerability, so the practical defences are runtime monitoring, checking the published indicators, and treating Exchange servers as high-value assets rather than commodity mail relays. Any organisation that matches Turla's target profile should treat this as directly relevant, and any organisation that does not should still note the techniques, because they do not depend on being a government.
The bottom line
The Cereal malware toolset is a carefully built instrument for slow, long-term espionage, and its most impressive feature is an absence: no attacker infrastructure anywhere in the picture, because the victim's own Exchange server did that job.