Skip to main content
Security

Russian “Cereal” Malware Targets Government Servers

ESET has documented a Russian espionage toolset that hides inside Microsoft Exchange and needs no outside command server. Here is what happened, how it works and how to defend against it.

A Russian espionage group has been reading government email from inside the mail servers themselves. On November 10, 2026, security firm ESET published research on a previously undocumented toolset called Cereal, found on Microsoft Exchange servers at government bodies in Kazakhstan and Romania. ESET attributes it to Turla with high confidence (Help Net Security).

What makes Cereal unusual is that it needs no outside command server. The compromised Exchange server becomes the attacker's control point, and commands arrive disguised as normal webmail traffic. In Romania, the malware was configured to pick out email to and from NATO and EU addresses.

No U.S. victims have been reported. The technique still matters to any organization that runs its own Exchange server, because it hides in places that routine security checks do not look.

What happened

ESET found Cereal in late 2025 and published its findings a year later. The timeline below comes from Help Net Security and BleepingComputer.

DateEvent
Nov 28, 2025ESET first finds Cereal at a Kazakh government body
Dec 23, 2025A Romanian government organization is compromised
Jan 15, 2026Activity at the Kazakh victim spikes
Nov 10, 2026ESET publishes its research on the Cereal toolset

ESET found the Romanian victim only after it tuned its detections, which shows how well the toolset avoided earlier checks. In Romania, the malware's collection filter targeted messages sent to or from NATO and EU addresses. The Record reports that ESET could not tell how much information was actually stolen.

Several basics are still unknown. Researchers have not said how the attackers first got into either network, and ESET could not identify the IP addresses the operators connected from. The coverage we reviewed includes no comment from the Romanian or Kazakh governments, NATO, the EU or Microsoft.

Who is behind it

ESET attributes Cereal to Turla, also tracked as Snake, Secret Blizzard, Venomous Bear, Waterbug and Uroburos. The evidence is indirect: a component already publicly tied to Turla ran alongside Cereal, and the new code resembles older Turla malware (Security Affairs). ESET rates its confidence as high, but the findings come from one vendor, and the coverage we reviewed shows no independent confirmation.

Turla is widely assessed to be part of Russia's FSB. U.S. and allied agencies say it operates from a known unit within FSB Center 16, and they described its long-running Snake implant as the most sophisticated espionage tool that unit uses in a 2023 joint advisory (CISA, NSA).

The group is old and patient. ESET's earlier research says Turla has been active since at least 2004 and is known for breaching the U.S. Department of Defense in 2008 and the Swiss defense company RUAG in 2014. ESET also reports that about 70% of the countries Turla has targeted since 2022 were former Soviet republics or European countries with historical ties to Moscow, which fits a Kazakh and Romanian target set.

How Cereal works

Cereal is a modular .NET toolset. The name refers to serialization, the technique of packaging data and code for transport that the tools rely on heavily (ITdaily). The Hacker News lists eight components:

ComponentRole
CerealRunnerDrops the other parts and runs the operator's command programs in memory
CerealLoaderLoads a .NET assembly from an encrypted file on disk and starts CerealSprinter
CerealSprinterDecrypts and runs CerealNeuron, CerealHermit and CerealBox
CerealIronLets non-.NET processes load and run .NET assemblies
CerealMothLoads an assembly and runs a named method
CerealNeuronPassive backdoor that waits for commands on the Exchange server
CerealHermitBackdoor variant with no network code; reads encrypted command files from disk as a fallback
CerealBoxEmail harvester that injects into the Exchange transport service

The command channel. CerealNeuron never calls out. Operators send requests to the victim's internet-facing Exchange server, disguised as Outlook Web Access, Autodiscover and ActiveSync traffic, using paths such as /owa/sdds/ and /autodiscover/proxyservice/. Requests that are properly encrypted and pass integrity checks are executed. Everything else gets a normal-looking Exchange error page (Help Net Security).

The email theft. CerealBox injects into EdgeTransport.exe, the Exchange mail transport process, and wraps the handlers of transport agents that are already loaded. It registers no new agent, so nothing new appears in the Exchange configuration. It selects messages with .doc, .docx or .pdf attachments that match hardcoded senders, recipients, subjects or file names, then compresses, encrypts and stages them on disk for later pickup. Mail keeps flowing normally. ESET says this approach had not been documented in any malware family before (BleepingComputer).

The hiding. The first loader runs native code before the .NET runtime starts, so an analyst sees .NET code that appears to do nothing. In one chain it posed as ncobjapi.dll in the Windows management folder (System32\wbem), which the WMI service loads automatically. Copies also sat in the .NET native image cache under names resembling Exchange components, so Exchange loaded the malicious file first. Operators could then pull mailboxes, query Active Directory, extract stored Windows credentials, and read or delete files.

Who is at risk

The confirmed victims are two government bodies, and no U.S. organization has been named. But the method does not depend on a specific victim. It depends on an Exchange server that the attacker can reach from the internet and compromise by some route.

That route is the open question. Turla is known for spear-phishing, watering-hole attacks and ISP-level adversary-in-the-middle attacks, though the reporting does not tie any of them to this campaign (The Hacker News). Without a known entry point, no single patch closes the door.

Three groups should pay attention:

  • Organizations running on-premises or hybrid Exchange, especially older versions.
  • Private firms that trade email with governments or alliances. Turla has also targeted private businesses (Security Affairs), and a partner's mailbox holds the same correspondence.
  • Companies that moved to Microsoft 365 but left an old Exchange server running. U.S. and allied agencies advise decommissioning end-of-life on-premises and hybrid servers once the move is complete (The Hacker News).

How it could be prevented

No source says how Cereal got in, so no one can promise a specific control would have stopped it. What follows is the standard Exchange hardening that cuts the odds of any compromise, plus the checks that can catch this one.

  1. Patch, and retire what is unsupported. The joint guidance from the NSA, CISA, Australia's ACSC and Canada's Cyber Centre warns that delayed patching compounds risk over time and advises decommissioning leftover end-of-life servers once the move to Microsoft 365 is done (ASD's ACSC).
  2. Harden authentication. Turn on Extended Protection, configure TLS consistently, use Kerberos instead of NTLM, require modern authentication with multi-factor, and disable basic authentication once users have moved (The Hacker News). Extended Protection is on by default for new Exchange 2019 CU14 installs, but older servers need it enabled by hand (Kaspersky).
  3. Limit administrative access. The same guidance tells administrators to restrict who can manage Exchange (ITPro).
  4. Shrink the exposure. Publish only the Exchange services users actually need, and remove old servers left over from a migration.
  5. Check integrity, not just traffic. Cereal makes no outside connection, so watching outbound traffic alone misses it (CyberInsider). Look for unfamiliar DLLs in System32\wbem and the .NET native image cache, and review requests to the three Exchange-looking paths. A clean list of transport agents does not rule out compromise, because CerealBox registers none (Security Affairs). ESET keeps indicators of compromise in the Turla folder of its malware-ioc repository on GitHub (BleepingComputer).

How we approach and mitigate threats like this

We treat a threat like Cereal as an infrastructure problem first. The malware lives on one server, but what it can reach depends on how the network around that server is built. Our work on a case like this follows five steps.

  1. Find every Exchange server. We inventory what you run, including forgotten hybrid or migration leftovers, and record version, patch level and whether it faces the internet.
  2. Close the known gaps. We bring servers to supported versions and apply the hardening steps above: patching, Extended Protection, modern authentication, restricted admin access.
  3. Limit what a compromised server can touch. We place Exchange in its own network zone with tight rules in and out (the next section covers this in detail).
  4. Verify, don't assume. We check the places Cereal hides, such as the DLLs, the native image cache and requests to the Exchange-looking paths, and we do not rely on the transport agent list alone.
  5. Plan for a bad day. If a server is suspected, we treat it as untrusted: isolate it, preserve evidence, rebuild it rather than clean it, and reset the credentials it could have exposed, since Cereal's tooling can pull stored Windows credentials.

We do not resell Fortinet or Cisco Meraki hardware, so you can buy from any reseller. We design, install, configure and manage the result.

Our specialty: network segmentation and firewall policy

Cereal's command channel hides in traffic that looks like normal webmail, so a firewall cannot simply block it. What a well-built network can do is limit what the server can reach once it is compromised, and make odd behavior easier to see. Segmentation and firewall policy design on Fortinet and Cisco platforms is the part of this threat where our network engineering work applies most directly.

For an Exchange server, the policy we would build looks like this:

TrafficPolicyWhy it helps
Internet to ExchangeOnly the services in use, ideally through a reverse proxy or web application firewallShrinks what an attacker can send and gives you a place to log unusual requests
Exchange to internetDeny by default, then allow only the mail delivery and update destinations it needsLimits second-stage downloads and data theft
Exchange to internal networkOnly the ports it needs to reach Active Directory and mail partnersSlows lateral movement after credential theft
AdministrationOnly from a management network or jump hostKeeps a stolen workstation login from managing the server

On FortiGate and Cisco firewalls we build these as explicit zone policies. On Cisco and Meraki switching we enforce the VLAN separation and access lists behind them.

This has limits. If the published webmail paths are needed, an attacker's request to them still gets through. But Cereal's modules query Active Directory and pull stored credentials, and that is the step segmentation and restricted administration are meant to blunt. A mail server that suddenly opens a connection it has never made is also a signal worth alerting on.

Key takeaway

Cereal shows that a mail server can be both the victim and the attacker's control point, with no outside infrastructure to block. If you run Exchange yourself, find every server, bring them to supported versions, harden authentication, and put the server in a tightly controlled network zone. Then check the server itself for unfamiliar files, because a clean transport agent list and quiet outbound traffic are not proof of a clean server.

If you run Exchange yourself and want a second set of eyes on how it is exposed, call us at 866-252-1860. For the wider picture on keeping attackers out, read our ransomware guide.

Sources

Sources checked November 10, 2026. Technical details come from the coverage above, which reports ESET's findings. We did not review ESET's full technical report.

Keep Reading

More from our blog

Talk to an Engineer about Exchange security

Tell us what mail servers you run today and we'll tell you where they are exposed.

Call your local office

Each service area has its own direct line. Your call goes straight to the team that covers your neighborhood.

NEW YORK
212-920-9466
Financial District, Midtown, SoHo
NEW YORK
917-268-4940
LIC, Astoria, Flushing
NEW YORK
917-268-4940
DUMBO, Williamsburg, Park Slope
NEW YORK
516-717-0404
Nassau & Suffolk counties
NEW JERSEY
201-374-0092
Bergen, Hudson, Essex

Certified Partners & Technology Stack

Cisco HP, Hewlett-Packard Microsoft