ESET Research reported finding Cereal, a previously undocumented modular .NET toolset, in government Microsoft Exchange environments in Kazakhstan and Romania. ESET attributed the toolset to Turla with high confidence, citing a component previously linked publicly to the group and similarities to earlier Turla malware. The disclosure was published on November 10, 2026; ESET dates its Kazakhstan detection to November 28, 2025, and says the Romanian organization was compromised from December 23, 2025 onward. ESET’s technical analysis describes two distinct roles: selecting email for collection and using the compromised server to receive operator requests.
What ESET reported about Cereal and Turla
ESET reported two affected government organizations, one in Kazakhstan and one in Romania. It also observed increased activity in the Kazakhstan case on January 15, 2026, and in the Romanian case on January 20, 2026. These reports concern those two organizations; they do not establish a broader pattern across Exchange servers.
Cereal is a collection of components that load and run .NET code. ESET says many execute in memory and arrive in encrypted containers. CerealLoader loads an assembly from an encrypted disk file; CerealRunner runs embedded payloads and commands in memory and returns their output. CerealSprinter loads other components but does not run commands or return their output.
How Cereal used Exchange
CerealBox handled email filtering within Exchange’s transport pipeline. ESET says it was injected into the EdgeTransport.exe process, where it wrapped existing transport-agent handlers in memory instead of registering a new agent. Its selection rules required an attachment ending in .doc, .docx, or .pdf, plus a match against configured sender, recipient, subject, or attachment-name criteria. Ignore lists could exclude messages that otherwise matched.
In the Romanian case, ESET says the configuration included institutional addresses associated with NATO and the European Union, including nato.int and europa.eu. That identifies targets in the configuration, not the contents of specific messages.
CerealBox’s filters describe which messages it could stage, not a tally of email successfully taken.
ESET describes two additional implementation details: CerealBox stopped processing messages 70 days after its first run, and it emptied its staging dictionary and generated a new filename when the combined values exceeded 5 MB. Those thresholds describe the tool’s reported behavior, not the amount of email successfully exfiltrated.
CerealNeuron served a different purpose. It passively waited for valid incoming requests on configured Exchange-like HTTPS paths and could execute supplied assemblies. ESET observed no external command-and-control infrastructure and could not identify the operators’ ingress IP addresses. The five observed path prefixes, all on port 443, were /owa/sdds/, /autodiscover/microsoft.exchange.proxyservice/, /autodiscover/integrated/api/, /autodiscover/proxyservice/, and /microsoft-server-activesync/integrated/api/. A request to one of these paths alone does not establish malicious activity.
ESET also observed CerealHermit, a CerealNeuron variant without network functions that reads encrypted command files from disk. In some intrusions, the two backdoors were deployed together. Despite the name, ESET treats CerealNeuron as a distinct family from the earlier Neuron malware, describing functional similarities rather than a new version of Neuron.
What ESET reported about access and collected email
ESET says it could not determine how the operators first gained access. Because the Exchange servers were internet-accessible, exploiting a vulnerability was considered possible, but ESET did not identify it as the confirmed entry method.
The technical account describes how CerealBox selected and staged messages; it does not identify the contents of particular emails or quantify successfully exfiltrated mail. ESET’s published account likewise reports the two government cases without establishing additional victims.
