Cereal Malware: Detect Email Theft Inside Microsoft Exchange

Cereal malware can read a sensitive email before it leaves a Microsoft Exchange server, copy it, and let the legitimate message continue as if nothing happened. ESET disclosed the previously undocumented Turla toolset on November 10, 2026, after finding it inside government Exchange environments in Kazakhstan and Romania.

The risk is larger than one espionage campaign. Cereal hides in legitimate processes, executes much of its code in memory, and uses the victim's own server as a command hub. If you defend on-premises Exchange, a quiet mail flow and a clean outbound-domain list are no longer enough to establish trust.

Key Takeaway: Treat the Exchange server as a possible collection platform, not merely a delivery system. Hunt for process, file, and web-request anomalies together.

What Cereal malware does inside Exchange

ESET Research published its technical analysis on November 10, making this a fresh public disclosure even though the observed compromises began in late 2025. Researchers found the toolset at a government organization in Kazakhstan on November 28, 2025, then identified a Romanian government victim compromised on December 23.

At the Romanian organization, CerealBox was configured to select messages involving NATO and European Union addresses. It could filter email by sender, recipient, subject, attachment name, and document type, including DOC, DOCX, and PDF attachments.

The original email still traveled through the normal delivery pipeline. That matters because users did not need to click a link, open an attachment, or notice an account takeover. The collection happened on infrastructure that administrators already trusted to see every message.

ESET attributes the campaign with high confidence to Turla, a Russia-aligned espionage group also known as Snake, Secret Blizzard, and Waterbug. The attribution provides context, but your operational decision should rest on evidence from your own hosts. The initial access route remains undisclosed, and public reporting does not establish that every Exchange server faces the same targeting.

Common Mistake: Searching only mailboxes and user sign-ins. Cereal's important activity occurs in server processes, Windows loading paths, and Exchange transport handling.

Why this Exchange implant is difficult to spot

Cereal is not one large executable with a fixed command set. It is a modular family whose components load encrypted payloads, inject code, receive task-specific programs, collect messages, and return results.

The architecture creates four detection problems:

1. Limited disk evidence: Most components arrive in encrypted containers and execute in memory.
2. Trusted process abuse: Malicious code runs inside legitimate Windows and Exchange processes.
3. No separate command domain: The compromised Exchange server becomes the operator-accessible command point.
4. Normal service paths: Incoming requests can resemble Outlook Web Access, Autodiscover, or ActiveSync traffic.

CerealNeuron, the passive network backdoor, waits for specially constructed encrypted requests. ESET observed traffic using paths such as /owa/sdds/, /autodiscover/proxyservice/, and /Microsoft-Server-ActiveSync/Integrated/Api/. Invalid requests receive a normal-looking Exchange error response, while valid encrypted requests deliver code for execution.

That design weakens common network assumptions. There may be no regular beacon, newly registered domain, or attacker-hosted command server to block. An allowed HTTPS connection to a familiar Exchange path can carry the operator's task.

CerealHermit provides a second route by reading encrypted command files from disk instead of listening for web traffic. Meanwhile, CerealRunner packages individual .NET programs for specific jobs, such as querying Active Directory, extracting LSA secrets, listing snapshots, retrieving messages, or reading and deleting files.

Key Stat: ESET documented eight named Cereal components supporting loading, injection, passive access, command execution, and email collection.

Cereal malware indicators defenders should hunt

A single indicator can be renamed, deleted, or shared with legitimate software. Build a behavioral hunt that connects unexpected files, unusual module loading, Exchange process injection, suspicious requests, and staged encrypted data.

Inspect Windows loading paths and caches

ESET observed CerealLoader placed as ncobjapi.dll or wbemcomn.dll under C:\Windows\System32\wbem\. The malware could forward legitimate calls so the affected Windows service continued operating normally.

Researchers also found malicious files in the .NET native image cache, including a file named Microsoft.Exchange.Search.Mdb.ni.dll. Compare these locations against known-good servers with the same Windows, .NET, and Exchange patch levels. File presence alone is not enough, so validate signatures, hashes, creation times, owners, access controls, and load events.

Examine Exchange process behavior

CerealBox injects into EdgeTransport.exe and wraps handlers already used by existing transport agents. It does not need to register a new transport agent that an administrator might notice in configuration.

Look for:

• unexpected DLL or assembly loads by Exchange services
• memory regions with executable code not backed by an approved module
• anomalous child processes or access to LSASS-related material
• encrypted archives or staged message data near Exchange service paths
• changes in the .NET native image cache without a matching maintenance event
• unusual access by Exchange processes to directory, snapshot, or credential resources

The Cisco Secure Email Gateway vulnerability response guide makes the same broader point: email infrastructure needs host-level hunting after a serious compromise, not just a patch confirmation.

Correlate unusual inbound web requests

Review reverse-proxy, load-balancer, firewall, IIS, and endpoint telemetry for the paths reported by ESET. Baseline method, content length, status code, source pattern, TLS characteristics, and request timing rather than blocking a path solely because its name appears in reporting.

Attackers may change paths, and legitimate Exchange functions can generate similar traffic. The stronger signal is a suspicious request followed by new code in an Exchange process, file access, directory queries, or encrypted output.

BleepingComputer's November 10 report summarizes the observed execution chain and links to ESET's extended indicator set. Import those indicators into your tooling, but preserve a separate behavior-based query for variants that do not match published hashes.

Pro Tip: Capture volatile memory before restarting a suspected server. A fast reboot can remove the best evidence of an implant designed to execute in memory.

How to contain a suspected Cereal compromise

Do not treat this as a malware-cleaning ticket. A compromised Exchange server can expose email, credentials, directory data, internal systems, and every trust relationship the host can reach.

1. Isolate while preserving business options

Remove the suspected server from external reach and restrict lateral traffic using controls outside the host. If email continuity is critical, route mail through a known-good alternate path rather than keeping the suspect server online for convenience.

Preserve memory, relevant virtual disks, Windows event logs, IIS logs, Exchange logs, EDR telemetry, load-balancer records, and identity-provider events. Record system time and collection methods so investigators can align evidence accurately.

2. Scope the intrusion beyond Exchange

Cereal commands can query Active Directory and extract locally stored secrets. Review privileged sign-ins, service accounts, remote management, scheduled tasks, WMI activity, and administrative changes from the earliest plausible compromise date.

Use the containment principles in Hexon's helpdesk server blast-radius guide: identify what the server could reach, which credentials it held, and which downstream systems trusted it. The product is different, but the dependency-mapping problem is the same.

3. Rotate credentials and invalidate access

Rotate credentials exposed to the host, prioritizing privileged, service, backup, monitoring, and deployment accounts. Replace certificates or secrets if evidence shows they were accessible, and invalidate active sessions where the identity platform permits it.

Password changes alone do not remove existing access. Hexon's session revocation guide explains why tokens, sessions, application passwords, and delegated grants need their own response steps.

4. Rebuild from known-good media

An implant that abuses DLL search paths, .NET caches, process injection, and encrypted loaders is a poor candidate for selective cleanup. Rebuild affected servers from trusted installation media, apply current security updates, restore only validated configuration and data, then monitor the replacement closely.

Do not reconnect the rebuilt host until identity, directory, management, and adjacent server evidence has been reviewed. Otherwise, persistence elsewhere can simply reinfect the clean system.

Key Takeaway: Containment ends when the trust boundary is restored, not when the suspicious DLL disappears.

How to harden on-premises Exchange after the hunt

The current disclosure does not identify the initial access vector, so no single patch can be presented as a complete Cereal fix. Reduce the number of ways an attacker can reach, control, and persist on the server.

Start with these actions:

• keep supported Exchange and Windows builds fully patched
• place external publishing behind a hardened reverse proxy or application-aware gateway
• restrict management interfaces to dedicated administration networks
• remove interactive web exposure that the organization does not require
• separate Exchange administration from daily user accounts
• block unnecessary outbound traffic and lateral protocols
• forward logs to storage the Exchange server cannot modify
• baseline service binaries, loaded modules, transport behavior, and .NET cache contents
• alert on credential access and directory discovery by mail-service processes
• test recovery from a clean build rather than assuming backups are trustworthy

Retention is also part of blast-radius control. If the server can access years of messages, one implant can turn old correspondence into current intelligence. Apply defensible mailbox and archive retention based on legal and business needs, using the approach in Hexon's legacy data breach risk guide.

Finally, rehearse the decision to take Exchange offline. Define who can authorize isolation, where mail will queue or reroute, how investigators will preserve volatile evidence, and how leadership will communicate with affected partners.

What security leaders should do this week

First, confirm whether the organization runs on-premises or hybrid Exchange and identify every internet-facing route to it. Cloud-only Microsoft 365 tenants should not mislabel themselves as affected by an on-premises implant, but hybrid connectors and legacy servers still deserve inventory review.

Second, assign a focused hunt across endpoint, identity, network, and email teams. The core question is not "Did our scanner find Cereal?" It is "Can we prove that only approved code handles mail and that no suspicious request caused hidden execution?"

Third, prepare a clean-rebuild and credential-rotation path before an alert forces the decision. Identify replacement capacity, trusted configuration sources, log-retention gaps, and the accounts whose compromise would widen the incident.

Fourth, brief leadership accurately. ESET found two government victims and a highly selective espionage operation. That supports urgent investigation for exposed Exchange environments, but it does not support claiming a global mass-exploitation event or a known vulnerability when the entry method is still unknown.

Cereal malware is important because it turns the normal strength of an email server into a surveillance advantage. Exchange already sees every message, already runs complex trusted code, and already exposes web services to the outside. Defenders must therefore validate the server itself, correlate weak signals across layers, and restore trust through evidence rather than uptime alone.