ESET says Turla's Cereal toolset hijacks Exchange agents at two governments; entry route not stated
ESET Research says Turla's Cereal toolset ran inside Microsoft Exchange at two governments, hijacking existing transport agents and listening on lookalike web paths with no outside server. ESET could not find the entry route, and the attribution is its own.
By Parminder Kumar Sharma · LinkedIn · · 19 min read
ESET detected Cereal on 28 November 2025 and published 347 days later, without an entry route
On 10 November 2026 ESET Research published a blog post and a white paper on a toolset it names Cereal, which it attributes to the Russia-aligned group Turla. The white paper says ESET "detected a previously undocumented set of malicious tools" being used against a governmental organisation in Kazakhstan on 28 November 2025. That is 347 days before publication (derived: 28 November 2025 to 10 November 2026). ESET found the same toolset at a governmental organisation in Romania, compromised from 23 December 2025 onwards by the white paper's account, which is 25 days after the Kazakh date (derived). Both are Microsoft Exchange servers. ESET names neither agency.
The 347 days is not how long Cereal was in use, and ESET does not claim it is. The white paper says "it remains unclear when this toolset was first used". Its earliest CerealLoader sample was uploaded to VirusTotal from Kazakhstan on 11 May 2022, 1,644 days before publication (derived), and ESET ties no intrusion to that sample. Nor do the dates establish how the intruders got in: "We were unable to determine the initial access method." They do not establish what was taken, how many other organisations are affected, or whether anyone outside ESET has checked the attribution.
ESET's selling interest, stated once: the blog post closes with "ESET Research offers private APT intelligence reports and data feeds." This site treats ESET as it treats any vendor: every claim below is ESET's unless marked otherwise. Both ESET pages were read in full from about 10:45 UTC on Tuesday 10 November 2026. BleepingComputer and Help Net Security (both dated 10 November 2026 by their page data) were read only to see what outsiders add. They add nothing that checks ESET's findings. ESET's GitHub indicator page was not read, because that host's robots.txt disallows the path; the white paper's own indicator table is used instead.
What ESET describes, component by component
ESET calls the family Cereal because, it says, "the tools rely heavily on serialization". The white paper lists eight components. Only one, CerealLoader, is written to disk as a recognisable .NET file; ESET says everything else is delivered in encrypted containers, unpacked at runtime and run from memory. The table gives ESET's own description of each and the gap it leaves.
The eight Cereal components as the ESET white paper describes them, read 10 November 2026; the last column is this site's note on what the paper does not say
| Component | What ESET says it does | What ESET does not say |
|---|---|---|
| CerealLoader | loads and runs a .NET assembly from an encrypted file on disk | How its files reached the server. |
| CerealRunner | contains other encrypted binaries that are loaded and executed | Who builds the thousands of samples ESET analysed. |
| CerealSprinter | is used only to load and run other components | Anything it ran beyond the backdoors and CerealBox. |
| CerealNeuron | a passive backdoor with no built-in commands | The operators' IP addresses. |
| CerealHermit | a variant of CerealNeuron with no network functionalities | How its command files are placed on the server. |
| CerealIron | an injector that allows operators to load and run .NET assemblies from non .NET processes | Which process it was pointed at: a process ID was used, not a name. |
| CerealBox | processes, filters, and collects interesting email messages by being injected into Microsoft Exchange's transport service | What it collected. |
| CerealMoth | a simple component that receives an assembly and a method name as arguments | Nothing further. |
ESET does not say which components were found at which victim. The white paper says "In both cases, the attackers focused on Exchange servers", and that in the Romanian case CerealBox was configured to flag NATO and EU mail. It says one victim ran a CerealNeuron version with a different configuration format and does not say which. ESET's own figure of the components, reproduced below, shows how they relate.
A backdoor that never calls out
Most backdoors beacon to an operator's server, which leaves domains and addresses for defenders to block. ESET says Cereal does not. "One of the most interesting aspects of this toolset is what we did not find: external command and control (C&C) infrastructure." CerealNeuron instead runs on the compromised Exchange server and waits. ESET lists five URI prefixes it was configured to answer, among them the path ending /owa/sdds/ and paths under Autodiscover and ActiveSync (exact strings in Technical details). A request to one of those paths is processed only if it is properly encrypted and passes integrity checks. The white paper says: "If the data format is invalid, or decryption fails, CerealNeuron redirects the response" to a configured URL, and that "We observed redirections to error pages, which would be the expected behavior in uncompromised servers."
That gives ESET three limits on what it could see. "No external network infrastructure was discovered during our investigation." "We were unable to identify the ingress IP addresses used to interact with CerealNeuron." And CerealNeuron is "the only component that communicates with hosts outside the compromised network". ESET's reading is that the victim's own Exchange server is the operator-accessible control point. That is ESET's characterisation of a design; it is not a finding about who connected, from where, or how often.
Commands are not built in. Each arrives as a separate small .NET program inside a CerealRunner binary. The white paper lists the commands it observed: reading a mailbox or single message through Exchange Web Services, querying Active Directory over LDAP, running WMI queries, extracting LSA Secrets from the registry, listing volume snapshots, and listing, reading and deleting files. It adds: "In most cases the operators specified files with email messages filtered by the CerealBox component." So ESET did observe commands aimed at the files CerealBox staged. It prints no count and no content for them.
CerealHermit is the fallback. ESET says it is the CerealNeuron code with the network parts emptied: "It reads assemblies from a file, runs them, and writes outputs to a file". Defaults in the printed configuration are two minutes between reads while active and 60 minutes in passive mode. In most cases ESET saw the two deployed together and says they do not appear to interact. ESET does not say how Hermit's command files get onto the server or how the results leave; BleepingComputer makes the same observation, in its words "ESET didn't explain how attackers place Hermit's command files on the server or retrieve the execution results."
CerealBox: what a defender can look at, and what ESET says is there
Exchange transport agents are a legitimate hook into the mail flow, used for jobs such as spam filtering. ESET says Turla has used them before: "Turla has already implemented its own transport agents in the past in its LightNeuron malware." The 2019 LightNeuron work, summarised in the 2026 white paper, had commands arriving by email, hidden in specially crafted PDF or JPG attachments. The blog states the catch with registered agents: "Installed transport agents, however, leave visible traces in Exchange's configuration."
CerealBox avoids that trace. In ESET's words: "CerealBox doesn't add a new agent; it hijacks existing ones in memory". The white paper describes how. CerealBox, run inside the transport process, finds the table of agent factories, "Find all factories of type RoutingAgentFactory and replace them with a custom factory", and the custom factory builds the expected agent through the original factory and wraps its handlers. The wrapper runs CerealBox's logic first, then the original agent. The blog adds "No new agent appears anywhere in Exchange's configuration." ESET calls injection into the transport service "a novel technique, not previously documented for any malware family".
Where a defender might look, per the ESET blog post and white paper read 10 November 2026; the last column is what ESET does not say
| Place to look | What ESET says is there | What ESET does not say |
|---|---|---|
| Registered transport agents in Exchange's configuration | No new agent appears. CerealBox wraps existing routing agent factories in memory. | Any way to tell a wrapped factory from a normal one. |
| Mail flow | Email continues to flow normally; the original message goes on its way. | Any delay, log entry or other sign of the extra processing. |
| Outbound network traffic | No external command infrastructure observed; CerealNeuron is passive. | Whether any outbound traffic exists at all beyond replies to inbound requests. |
| Web requests to the server | Five lookalike URI prefixes; invalid requests are redirected to an error page. | What a malicious request or response looks like in a log. |
| Disk | CerealLoader is the one recognisable .NET file. CerealBox stages mail in compressed, encrypted files and operators later read and delete them. | File names or paths of the staging files. |
| Memory of the transport process | CerealBox is injected there; ESET says EdgeTransport.exe was likely the target. | How to inspect it, or which process ID was used. |
On ESET's description, CerealBox keeps a message only if it has a .doc, .docx or .pdf attachment and matches at least one hardcoded list: sender, recipient, subject text or attachment name, without matching the ignore lists. Kept messages go into a dictionary that is serialised, compressed, encrypted and written to a file; the white paper says the dictionary is emptied and a new file name used when the values exceed 5 MB. "CerealBox stops processing messages 70 days after its first run." The lists are hardcoded, so "the operators must compile and deliver new binaries to update them".
One discrepancy between ESET's own pages. The blog says CerealBox is "injected directly into EdgeTransport.exe". The white paper is more careful about the evidence: "We don't know which processes were targeted, as the operators used a PID instead of a service name, but analysis of the injected payload suggests EdgeTransport.exe was likely injected." This site reports the transport process as ESET's assessment, not an observed fact.
A clean agent list is not a clean mail path
The friendly label here is an inventory. A review of registered transport agents is a common control for Exchange, and on ESET's account it would show nothing for CerealBox, because the code is not registered; it replaces factories for agents that are. The same applies to the redirect: a probe that sends a bad request to a Cereal path gets what ESET calls the expected behaviour of an uncompromised server. A clean list and a normal error page each report that nothing unusual was found, which is true of the thing they check and says nothing about the thing ESET describes. That is this site's inference from ESET's description, not a statement in the white paper.
The attribution rests on one shared component
ESET's attribution is firm in wording: "We attribute the activities described in this white paper to the Turla group with high confidence." The basis, in its words: "The main reason is the concurrent use of a malicious component publicly attributed to Turla." That component is a bootstrapper that ESET says is publicly attributed to Turla and that a Palo Alto Networks article describes. The version ESET saw has a compilation date of 3 October 2025 against 5 November 2019 in older binaries, and ESET says its "core functionality remains the same".
The second strand is weaker by ESET's own account. CerealNeuron is functionally similar to Neuron, a malware family the UK's National Cyber Security Centre attributed to Turla in 2017, but "we assess that CerealNeuron is a different malware family, rather than a new version of Neuron". The white paper also notes that the NCSC's 2019 report said Turla had obtained tools and access associated with Iran-aligned actors, which it says may complicate Neuron's lineage. The blog calls the link to older Turla malware "conceptual similarities". The white paper's executive summary adds that the attribution rests on the toolset's co-occurrence with known Turla malware. ESET describes similarities of design and function, not shared code, apart from the bootstrapper.
The attribution as ESET states it, read 10 November 2026, and what ESET does not state
| Question | What ESET states | What ESET does not state |
|---|---|---|
| Who | Turla, high confidence. The blog says Turla is widely assessed to be part of Russia's Federal Security Service; the white paper says it is thought to be part of it. | Any government attribution, or any outside party that has confirmed ESET's assessment. |
| On what basis | A bootstrapper publicly attributed to Turla used at the same time, plus similarity of design to older Turla malware. | Operator IP addresses or infrastructure, which ESET did not find. |
| How strong | High confidence, ESET's own scale. | The scale's definition, or a second analysis of the same samples. |
| Who else | A different Romanian governmental case exists in ESET's Turla telemetry, in a sentence about target countries. | Whether that case involves Cereal. ESET counts two Cereal victims. |
What the NATO and EU filter does and does not show
In the Romanian case, ESET says CerealBox "was configured to identify email messages sent to, or received from, NATO and European Union (EU) institutional addresses", specifically nato.int and europa.eu addresses, and that the list of pre-targeted addresses also held a small number of individuals who appear connected to government work involving those institutions. ESET does not publish the lists: "As they contain victim-identifying content, we can't divulge the lists we've seen". It does not describe the Kazakh configuration.
A configuration is an intention, not a harvest. It shows what the code was set to keep. ESET observed commands that read staged files, but it prints no count of messages kept and no content. On ESET's described rule, mail without a .doc, .docx or .pdf attachment would not be kept at all. ESET adds geopolitical context, tensions in Romania since early 2025 and deportations from Kazakhstan since January 2026, and then hedges: "While we cannot confirm the operators' exact intelligence requirements". Activity at the Kazakh victim rose on 15 January 2026 and at the Romanian one on 20 January 2026, per the white paper; ESET suggests the Kazakh timing may follow a holiday period.
What ESET states, and what it does not
Cereal as stated by ESET on 10 November 2026, and what none of the pages read states
| Item | Stated | Not stated |
|---|---|---|
| Initial access | Unable to determine; ESET says it is possible the internet-accessible servers were breached by exploiting a vulnerability. | Any vulnerability, CVE identifier or credential route. No CVE appears in any page read. |
| Operator infrastructure | No external infrastructure discovered; ingress IPs not identified. | Whether operators connected directly, through anonymisation services or from other compromised hosts. |
| Number of victims | Two national governmental organisations, one Kazakh, one Romanian. | Other victims. ESET says it is unclear when the toolset was first used. |
| What was taken | Commands that read and delete staged mail files were delivered. | How many messages, from whom, to whom, or whether any left the network. |
| Independent check | ESET's own high confidence assessment. | Any outside party, including any government, confirming it. |
| NATO and EU filter | CerealBox was configured to flag mail to or from nato.int and europa.eu addresses at the Romanian victim. | Whether the operators read that mail, or which mail the Kazakh configuration targeted. |
| Exchange build and patch level | Nothing. | The victims' Exchange versions, update state or hardening. |
| Microsoft | Nothing in any page read. | Any Microsoft statement or guidance. This builder did not search Microsoft's own pages, so this is absence in ESET and the two news pages only. |
Where the sources differ
Differences between ESET's two pages and the two news reports, all dated 10 November 2026 by their own page data, left unresolved
| Topic | ESET blog | ESET white paper | News reports |
|---|---|---|---|
| Kazakh date | On 28 November 2025 ESET found the toolset. | Detected on 28 November 2025; compromised since at least that day. | Help Net Security: ESET found it on 28 November 2025. BleepingComputer: documented late 2025. |
| Romanian date | Compromised on 23 December 2025. | Compromised from 23 December 2025 onwards; more active from 20 January 2026. | Both repeat 23 December 2025. |
| The injected process | Injected directly into EdgeTransport.exe. | EdgeTransport.exe was likely injected; the process ID was used, not a name. | Both state EdgeTransport.exe flatly. |
| Agent configuration | No new agent appears anywhere in Exchange's configuration. | CerealBox does not add a new agent; it hijacks existing ones in memory. | BleepingComputer: no new agent registered. Help Net Security: no new agent appears. |
| Turla's identity | Widely assessed to be part of the FSB. | Thought to be part of the FSB. | BleepingComputer adds the names Secret Blizzard and Waterbug, which neither ESET page uses. |
| Number of samples | Numerous CerealRunner binaries across the two intrusions. | Thousands of CerealRunner samples, a handful of CerealSprinter. | Not given. |
None of these changes the picture, but they show where the loudest wording runs ahead of the evidence. The Kazakh date is a detection and a compromise date at once only because the white paper says both; the process name is an assessment in one ESET page and a fact in the other.
What to do, in order
Take this with you
This site's suggestions, in order
- Check every Exchange server's files against the SHA-1 values and file names in Technical details (ESET's indicators). A hash match is strong; a miss is not clearance, because the operators compile new binaries per task.
- Compare the registered transport agents with what is actually loaded in the transport process, EdgeTransport.exe, and treat any code there that no registered agent explains as suspect. ESET prints no method for this, so it needs a memory capable tool.
- Look in the System32 wbem folder for the two DLL names ESET printed, and in the .NET native image cache for .ni files that were copied in rather than generated. ESET says the cached files were manually copied.
- Review web logs for requests to the five URI prefixes in Technical details, and for any listener on the Exchange server's ports that is not the expected web stack. ESET says the traffic blends in, so look for odd request sizes and responses, not for the path alone.
- Treat Exchange servers as crown jewels: limit who can reach their admin interfaces, monitor them separately, and keep them on supported builds. ESET suspects a vulnerability on an internet facing server but names none.
- Restrict outbound traffic from Exchange anyway, but know its limit here: ESET says Cereal makes no outbound beacons and answers on the inbound connection, so egress rules would not have caught this channel.
- If a hit is found, capture the transport process memory before restarting anything, since most Cereal components never touch disk, then rotate credentials the server held. ESET saw commands that extract LSA Secrets.
Technical details
Everything below is printed in the ESET white paper or blog post, read from about 10:45 UTC on Tuesday 10 November 2026, and copied exactly. ESET publishes detection names and an indicator list; this site has not verified them. The white paper lists only file indicators (SHA-1 values), no IP address and no domain, because ESET found no external infrastructure. Hashes are not network indicators: they identify a specific file, not a connection. No code from the white paper is reproduced. The CerealNeuron prefixes carry a wildcard host, so they are patterns on the victim's own server and are not defanged.
The five URI prefixes. These are the paths CerealNeuron listens on, on the compromised Exchange server. A defender searches web logs and listener registrations for them. Legitimate Exchange traffic uses nearby paths, so a match is a lead, not a verdict.
https://*:443/owa/sdds/
HTTPS://*:443/AUTODISCOVER/MICROSOFT.EXCHANGE.PROXYSERVICE/
HTTPS://*:443/AUTODISCOVER/INTEGRATED/API/
HTTPS://*:443/AUTODISCOVER/PROXYSERVICE/
HTTPS://*:443/MICROSOFT-SERVER-ACTIVESYNC/INTEGRATED/API/
Where the loader was placed. CerealLoader was written into Windows system folders and the .NET native image cache so that legitimate processes load it. A defender checks these locations and compares any file there with the hashes below. In one sample ESET says the malicious code runs only if the parent process is the Exchange search service, named in the second block below.
C:\Windows\System32\wbem\ncobjapi.dll
C:\Windows\system32\wbem\wbemcomn.dll
C:\Windows\system32\wbemcomn.dll
C:\Windows\assembly\NativeImages_v4.0.30319_64\Microsoft.E083ac9c1#\00d687fb4e6fa2a01653da0edc88b666\Microsoft.Exchange.Search.Mdb.ni.dll
Microsoft.Exchange.Search.Service
What CerealBox hooks. These are the names ESET says CerealBox loads and walks to reach the transport agents. A defender cannot search for them as files; they are objects inside the transport process, useful to a responder who is inspecting that process.
%ExchangeInstallPath%\Bin\Microsoft.Exchange.Transport.dll
%ExchangeInstallPath%\Public\Microsoft.Exchange.Data.Common.dll
mexRuntime
factoryTable
RoutingAgentFactory
EdgeTransport.exe
Configuration keys. ESET prints the names of the keys CerealNeuron and CerealHermit use, and two values. The MD5 key is the hash of a hardcoded integer and ESET saw it in two CerealNeuron binaries and in CerealBox, so it is a possible file or memory marker; ESET does not call it an indicator.
C\ExecutionTimeout
C\Autostart
T\Uris
T\RedirectUris
S\MaxEmptySessions
S\ActiveTimeout
S\PassiveTimeout
T\Path
B38C96AE6643D2AB5C0BFE823D9C9017
https://<redacted_server>/owa/auth/errorFE.aspx
File indicators. The white paper's table, in its order: SHA-1, file name, ESET detection name and role. Where ESET prints N/A there is no file name. A defender loads the SHA-1 values into an endpoint search. Eighteen entries. This site has not verified them.
4A3C263977417FB6977B0E598C9E3BC5924F390C Microsoft.Exchange.Data.Transport.ni.dll MSIL/Agent.YCC CerealLoader
7742C6B0AAF114335CEF7EBAB11290CB18A0B8B3 version.dll MSIL/Agent.YCC CerealLoader
AFE448DD95494CD14438F04F0C5F6B384664A3B7 version.dll MSIL/Agent.YCC CerealLoader
4A65040646E354303F067D47AA1C953D467F65CB Microsoft.Search.Platform.dll MSIL/Agent.YCA CerealLoader
D1E17520A2435EDCDCC47F582381416FBDF75F94 Microsoft.Ceres.dll MSIL/Agent.YCA CerealLoader
7AB784D0049890D9844AEE7F214BA173E3CC23BE wbemcomn.dll MSIL/Agent.YCA CerealLoader
5D80118B1EE974936322475F740AB3AEFF70B8F3 EdgeTransport.ni.exe MSIL/Agent.YCC CerealLoader
D51C58C2E95D4561848E0A5A8B9FB33C847C50A4 iph.dat MSIL/Agent.YCA CerealLoader
5B94FE76EC4FEB0B5CB6EA3BCA4C48D2FE22597B ncobjapi.dll MSIL/Agent.YCA CerealLoader
1408A8F62B09A5AD0DFF279B2878D8F59F70A330 Microsoft.Exchange.Search.Mdb.ni.dll MSIL/Agent.YCC CerealLoader
3D1A534CE0D0C293F62ECE556CBC6D0728213104 Microsoft.Exchange.EdgeSyncSvc.ni.exe MSIL/Agent.YCC CerealLoader
AD85FBF2CC879D4325BCE1E6FB5F12AB59E3D387 N/A MSIL/Agent.YBZ CerealRunner
3EA03188DBA8898D97E965732C1D6A68C5437EDC N/A MSIL/Agent.YBZ CerealSprinter
3FBA18AF966DEACF7AE09E4D4238952DD90A6D6F N/A MSIL/Agent.YBZ CerealHermit
EB9BA1DA5363F5D04E2F98673595FCE93F39A78E N/A MSIL/Agent.YBZ CerealIron
0B4E4A1CE7FEE91BFC62B2A2EC572C325642BB60 N/A MSIL/Agent.YBZ CerealMoth
A4E477CE257F2C635401EF554E05506C080967C0 N/A Win32/Agent.AIOQ Bootstrapper DLL (x86)
A5BE8706032A0798FD63214A9F22EFA6309355F5 N/A Win32/Agent.AIOQ Bootstrapper DLL (x64)
The question ESET leaves open
ESET found a toolset whose control channel is the victim's own web server, whose mail hook leaves no new agent in the configuration, and whose entry route it could not identify. Two of the controls defenders lean on, a list of registered agents and a watch on outbound traffic, are the two ESET says it sidesteps. ESET's assessment is that Turla did it, with high confidence, on the strength of one shared bootstrapper. So which control, run by whom outside ESET, would tell a government mail administrator today that the server is working for someone else, and who checks the attribution that ESET alone has made?
Key facts
Sources
- PrimaryExchange for breakfast: Turla's Cereal tricks are not for kids, blog post dated 10 November 2026. Read in full: the toolset, the two victims, the attributionESET Research (WeLiveSecurity)accessed 2026-11-10
- PrimaryWhite paper, Exchange for breakfast: Turla's Cereal tricks are not for kids, dated 10 November 2026, 36 pages. Read in full: components, configuration, CerealBox hooking steps, file indicatorsESET Researchaccessed 2026-11-10
- Reported byTurla hackers use new Cereal malware to spy on govt Exchange servers, dated 10 November 2026 by its page data. Used only to see what outsiders add; ESET sells threat intelligenceBleepingComputeraccessed 2026-11-10
- Reported byTurla's Cereal malware turns victims' Exchange servers into spy hubs, dated 10 November 2026 by its page data. Used only to see what outsiders addHelp Net Securityaccessed 2026-11-10
