The Russian state-backed threat group Turla (also tracked as Secret Blizzard, Snake, Uroburos, and Venomous Bear) has been observed deploying a new malware toolset called Cereal to intercept emails directly on Microsoft Exchange servers operated by government organizations. This is not speculative capability development — it is an active espionage operation against on-premises Exchange infrastructure, and it should be treated as an urgent detection priority for any organization running Exchange on-prem, particularly government, defense, diplomatic, and critical infrastructure entities.
The targeting of Exchange servers for email interception is a mature and effective technique: rather than compromising individual endpoints and collecting mailboxes one host at a time, the adversary sits at the chokepoint where every message flows. If your organization operates Exchange servers that are internet-facing or handle sensitive communications, you need to assume you are in-scope for this class of operation and hunt accordingly.
Technical Analysis: How Cereal Operates on Exchange Servers
Threat Actor Profile
Turla is one of the longest-running and most sophisticated cyber-espionage groups in the world, attributed to Russia's FSB. The group has historically targeted ministries of foreign affairs, defense organizations, and diplomatic entities across Europe, Central Asia, and the Middle East. Turla's hallmark is stealth — the group routinely lives inside victim networks for years, uses custom malware with small footprints, and prefers server-side persistence that avoids noisy endpoint activity.
The Cereal Toolset
Cereal is a malicious toolset deployed on compromised Microsoft Exchange servers with a singular purpose: intercepting email traffic as it transits the server. Rather than dumping mailboxes in bulk (which generates obvious exfiltration signals), Cereal operates inline with the mail flow, allowing Turla to selectively collect messages of interest — likely filtered by sender, recipient, subject keywords, or attachment types — matching classic signals-intelligence collection methodology.
Key characteristics defenders should internalize:
- Server-side implant: The malware lives on the Exchange server itself, likely integrating with IIS worker processes (w3wp.exe) servicing Exchange Web Services (EWS/OWA) or hooking into the Exchange transport pipeline (MSExchangeTransport.exe / EdgeTransport.exe).
- Targeted collection: Interception logic implies selective filtering, meaning traditional mailbox audit logging and bulk-export detections will not fire.
- Stealth-first design: Consistent with Turla tradecraft, expect signed or legitimate-looking binaries, timestomping, log tampering, and C2 infrastructure designed to blend with legitimate traffic.
- Initial access vector: Turla frequently obtains access to Exchange servers via exploitation of known Exchange vulnerabilities or by piggybacking on access already established by other actors (a documented Turla behavior — they have historically hijacked other groups' infrastructure and implants).
Why Exchange Servers Are High-Value Targets
An adversary on your Exchange server has:
- Full visibility into organizational communications — including internal-only mail that never touches a gateway.
- Access to credentials — Exchange servers process authentication constantly, and memory scraping or NTLM relay from an Exchange host is a well-worn privilege escalation path.
- A trusted pivot point — Exchange servers are whitelisted, highly connected, and rarely subjected to the same EDR scrutiny as workstations.
Exploitation Status
This is confirmed active exploitation by a nation-state actor against government targets. There is no CVE associated with Cereal itself — it is post-compromise tooling. The lesson for defenders is that Cereal lands on servers that were already compromised through some other vector. That means two things:
- If you find Cereal, you have a deeper intrusion to unravel — the implant is a symptom, not the disease.
- Your Exchange attack surface management (patching, restricting internet exposure, hardening IIS) is your first line of defense, because Turla cannot deploy Cereal on a server it cannot reach.
Detection & Response
The detections below focus on the observable behaviors inherent to an Exchange email-interception implant: IIS worker processes exhibiting anomalous behavior, transport pipeline tampering, suspicious module loads, and outbound connections from Exchange processes that have no business talking to the internet.
Sigma Rules
---
title: Exchange IIS Worker Process Spawning Suspicious Child Processes
id: 9c4a2f18-3e71-4b5a-9d82-7f1c6a3e4b05
status: experimental
description: Detects w3wp.exe (Exchange app pool context) spawning command shells, scripting engines, or other unusual child processes consistent with webshell or implant activity on Exchange servers.
references:
- https://attack.mitre.org/techniques/T1059/
- https://attack.mitre.org/techniques/T1505/003/
- https://www.bleepingcomputer.com/news/security/turla-hackers-use-new-ceral-malware-to-spy-on-govt-exchange-servers/
author: Security Arsenal
date: 2026/02/10
tags:
- attack.persistence
- attack.t1505.003
- attack.execution
- attack.t1059
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith: '\w3wp.exe'
selection_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\powershell_ise.exe'
- '\pwsh.exe'
- '\cscript.exe'
- '\wscript.exe'
- '\mshta.exe'
- '\rundll32.exe'
- '\regsvr32.exe'
- '\net.exe'
- '\net1.exe'
- '\whoami.exe'
- '\certutil.exe'
filter_apppool:
ParentCommandLine|contains: 'MSExchangeOWAAppPool'
condition: selection_parent and selection_child and not filter_apppool
falsepositives:
- Legitimate Exchange diagnostics (rare; investigate every hit)
- Known Exchange cumulative update installation windows
level: high
---
title: Exchange Transport Process Making Unusual Outbound Network Connections
id: 2b7e5c91-8d43-4f6a-a1c9-5e3d8b2f7a14
status: experimental
description: Detects Exchange transport or IIS worker processes initiating network connections to non-standard ports or unusual destinations, consistent with an email-interception implant exfiltrating collected messages.
references:
- https://attack.mitre.org/techniques/T1071/
- https://attack.mitre.org/techniques/T1114/
author: Security Arsenal
date: 2026/02/10
tags:
- attack.collection
- attack.t1114
- attack.exfiltration
- attack.t1071
logsource:
category: network_connection
product: windows
detection:
selection_image:
Image|endswith:
- '\EdgeTransport.exe'
- '\MSExchangeTransport.exe'
- '\w3wp.exe'
selection_ports:
DestinationPort:
- 4444
- 8443
- 8081
- 9001
- 53
filter_dns:
Image|endswith: '\EdgeTransport.exe'
DestinationPort: 53
condition: selection_image and selection_ports and not filter_dns
falsepositives:
- Hybrid Exchange configurations using alternate TLS ports
- Legitimate smart-host relay configurations (baseline and whitelist)
level: high
---
title: Suspicious Module or DLL Drop in Exchange Installation Paths
id: 6f1a3d84-2c95-4b7e-8a41-9d5c2e7f3b68
status: experimental
description: Detects creation of executable content (DLL/EXE) in Exchange FrontEnd, ClientAccess, or TransportRoles directories, consistent with implant deployment alongside legitimate Exchange components.
references:
- https://attack.mitre.org/techniques/T1036/
- https://attack.mitre.org/techniques/T1505/003/
author: Security Arsenal
date: 2026/02/10
tags:
- attack.persistence
- attack.defense_evasion
- attack.t1036
logsource:
category: file_event
product: windows
detection:
selection_path:
TargetFilename|contains:
- '\Microsoft\Exchange Server\V15\FrontEnd\'
- '\Microsoft\Exchange Server\V15\ClientAccess\'
- '\Microsoft\Exchange Server\V15\TransportRoles\'
selection_ext:
TargetFilename|endswith:
- '.dll'
- '.exe'
- '.aspx'
- '.ashx'
- '.asmx'
filter_updates:
Image|endswith:
- '\setup.exe'
- '\msiexec.exe'
- '\TrustedInstaller.exe'
condition: selection_path and selection_ext and not filter_updates
falsepositives:
- Exchange CU/SU installation (correlate with patch windows; file_event Image attribution may be limited)
level: critical
Analyst note: Rule one is deliberately conditioned to exclude the OWA app pool in the default state — many legitimate Exchange management actions spawn from there, and an unfiltered version of this rule will be disabled within a week. Baseline your environment, then tighten. Rule three is the highest-fidelity signal: nothing should be writing new binaries or scriptable web content into Exchange install paths outside a documented update window.
KQL — Microsoft Sentinel / Defender for Endpoint
This hunt looks for the intersection of anomalous process execution and network behavior on Exchange servers over a 14-day window. Run it against servers identified by naming convention or device group — tune the DeviceName filter to your environment.
// Hunt: anomalous child processes + outbound connections from Exchange server processes
let Lookback = 14d;
let ExchangeServers = DeviceInfo
| where DeviceName has_any ("exch", "mbx", "cas")
| distinct DeviceName;
let SuspiciousChildren = DeviceProcessEvents
| where TimeGenerated > ago(Lookback)
| where DeviceName in (ExchangeServers)
| where InitiatingProcessFileName in~ ("w3wp.exe", "EdgeTransport.exe", "MSExchangeTransport.exe")
| where FileName in~ ("cmd.exe", "powershell.exe", "pwsh.exe", "mshta.exe", "cscript.exe",
"wscript.exe", "rundll32.exe", "regsvr32.exe", "certutil.exe",
"net.exe", "whoami.exe", "nltest.exe", "adfind.exe", "rclone.exe", "7z.exe")
| project TimeGenerated, DeviceName, InitiatingProcessFileName, InitiatingProcessCommandLine,
FileName, ProcessCommandLine, AccountName, SHA256, ReportId;
SuspiciousChildren
| join kind=leftouter (
DeviceNetworkEvents
| where TimeGenerated > ago(Lookback)
| where DeviceName in (ExchangeServers)
| where InitiatingProcessFileName in~ ("w3wp.exe", "EdgeTransport.exe")
| where RemotePort !in (25, 80, 443, 587, 465, 993, 995, 143)
| where RemoteIPType == "Public"
| summarize NetHits = count(), Ports = make_set(RemotePort), Destinations = make_set(RemoteIP)
by DeviceName, InitiatingProcessFileName
) on DeviceName
| project TimeGenerated, DeviceName, ParentProc = InitiatingProcessFileName, ChildProc = FileName,
ProcessCommandLine, AccountName, SHA256, NetHits, Ports, Destinations
| order by TimeGenerated desc
Also run this second query specifically for file drops in Exchange paths, which is the highest-fidelity artifact of implant staging:
// Hunt: new executable/script content written into Exchange installation directories
DeviceFileEvents
| where TimeGenerated > ago(30d)
| where FolderPath has_any ("Exchange Server\\V15\\FrontEnd", "Exchange Server\\V15\\ClientAccess",
"Exchange Server\\V15\\TransportRoles")
| where FolderPath endswith_any (".dll", ".exe", ".aspx", ".ashx", ".asmx", ".config")
| where ActionType in ("FileCreated", "FileModified", "FileRenamed")
| project TimeGenerated, DeviceName, ActionType, FolderPath, FileName, SHA256,
InitiatingProcessFileName, InitiatingProcessCommandLine
| order by TimeGenerated desc
Velociraptor VQL — Endpoint Forensic Hunt
Use this artifact to sweep Exchange servers for suspicious loaded modules, recently modified binaries in Exchange paths, and anomalous network connections from Exchange processes in a single collection.
-- Hunt for Turla-style Exchange implant indicators:
-- unsigned/recent DLLs in Exchange paths, odd connections from Exchange processes,
-- and suspicious child processes of w3wp/EdgeTransport.
LET exchange_paths = 'C:/Program Files/Microsoft/Exchange Server/**'
SELECT * FROM {
-- Recently created/modified executable content in Exchange install tree (last 45 days)
SELECT 'FileArtifact' AS Finding, FullPath, Size, Mtime, Ctime,
'' AS Detail
FROM glob(globs=exchange_paths)
WHERE (FullPath =~ '(?i)\.(dll|exe|aspx|ashx|asmx)$')
AND Mtime > (now() - 3888000)
} UNION {
-- Exchange-related processes and their command lines
SELECT 'ProcessArtifact' AS Finding, Exe AS FullPath, Pid AS Size,
CreateTime AS Mtime, CreateTime AS Ctime,
CommandLine AS Detail
FROM pslist()
WHERE Name =~ '(?i)(w3wp|edgetransport|msexchangetransport)'
} UNION {
-- Network connections owned by Exchange processes to non-mail ports
SELECT 'NetworkArtifact' AS Finding, Name AS FullPath, Pid AS Size,
Laddr AS Mtime, Raddr AS Ctime,
format(format='Status=%v Family=%v', args=[Status, Family]) AS Detail
FROM netstat()
WHERE Name =~ '(?i)(w3wp|edgetransport|msexchangetransport)'
AND Status =~ 'ESTABLISHED'
}
PowerShell — Exchange Server Integrity Verification and Hardening Script
Run this on each Exchange server as SYSTEM. It verifies patch level against current Cumulative/Security Updates, checks for unsigned or recently modified binaries in Exchange paths, inventories suspicious child-process lineage via audit logs, confirms AMSI is enabled for Exchange, and validates that IIS module load behavior hasn't been tampered with. It is read-only — it will not change your production state, but it will tell you whether you have a problem.
# Turla Cereal - Exchange Server Integrity & Hardening Verification
# Run elevated on each Exchange server. Output: C:\IR\ExchangeIntegrity_<hostname>_<date>.txt
$outDir = 'C:\IR'
New-Item -ItemType Directory -Path $outDir -Force | Out-Null
$report = Join-Path $outDir ("ExchangeIntegrity_{0}_{1:yyyyMMdd}.txt" -f $env:COMPUTERNAME, (Get-Date))
"=== Exchange Integrity Check :: $env:COMPUTERNAME :: $(Get-Date -Format o) ===" | Out-File $report
# 1. Exchange version & build - verify you are on a supported CU with current SUs
"`n[1] Exchange Build" | Out-File $report -Append
$exReg = Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\ExchangeServer\v15\Setup' -ErrorAction SilentlyContinue
"ProductName: $($exReg.ProductName) Version: $($exReg.MsiProductMajor).$($exReg.MsiProductMinor) Build: $($exReg.MsiBuildMajor).$($exReg.MsiBuildMinor)" | Out-File $report -Append
# Cross-reference build against Microsoft's Exchange Server build numbers and release dates page.
# If your SU build is older than the most recent quarterly SU, you are exposed.
# 2. Recently modified executable content in Exchange install paths (last 45 days)
"`n[2] Executable content modified in Exchange paths (last 45 days)" | Out-File $report -Append
$cutoff = (Get-Date).AddDays(-45)
$exPaths = @(
"$env:ExchangeInstallPath\FrontEnd",
"$env:ExchangeInstallPath\ClientAccess",
"$env:ExchangeInstallPath\TransportRoles"
)
foreach ($p in $exPaths) {
if (Test-Path $p) {
Get-ChildItem $p -Recurse -Include *.dll,*.exe,*.aspx,*.ashx,*.asmx -ErrorAction SilentlyContinue |
Where-Object { $_.LastWriteTime -gt $cutoff } |
ForEach-Object {
$sig = Get-AuthenticodeSignature $_.FullName
"{0} | {1} | SigStatus={2} | Signer={3}" -f $_.LastWriteTime, $_.FullName, $sig.Status, $sig.SignerCertificate.Subject |
Out-File $report -Append
}
}
}
# 3. Unsigned DLLs anywhere in the Exchange tree (implants frequently masquerade as components)
"`n[3] Unsigned or invalidly signed binaries in Exchange tree (sample scan)" | Out-File $report -Append
Get-ChildItem "$env:ExchangeInstallPath" -Recurse -Include *.dll,*.exe -ErrorAction SilentlyContinue |
ForEach-Object {
$s = Get-AuthenticodeSignature $_.FullName
if ($s.Status -ne 'Valid') { "{0} | {1}" -f $s.Status, $_.FullName }
} | Out-File $report -Append
# 4. Suspicious child processes of Exchange parents (requires process creation auditing / Sysmon)
"`n[4] Suspicious child processes of w3wp/EdgeTransport (last 30 days)" | Out-File $report -Append
$parents = 'w3wp.exe','EdgeTransport.exe','MSExchangeTransport.exe'
$badKids = 'cmd.exe','powershell.exe','pwsh.exe','mshta.exe','cscript.exe','wscript.exe','rundll32.exe','certutil.exe'
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688; StartTime=(Get-Date).AddDays(-30)} -ErrorAction SilentlyContinue |
Where-Object { $_.Message -match (($parents -join '|')) -and $_.Message -match (($badKids -join '|')) } |
Select-Object -First 50 TimeCreated, Message | Out-File $report -Append
# 5. AMSI / Windows Defender state - Exchange supports AMSI integration; ensure it is active
"`n[5] Defender / AMSI posture" | Out-File $report -Append
Get-MpComputerStatus | Select-Object AMServiceEnabled, AntispywareEnabled, RealTimeProtectionEnabled, BehaviorMonitorEnabled, IoavProtectionEnabled |
Format-List | Out-File $report -Append
# 6. IIS global modules - look for unexpected native modules (common implant persistence on IIS)
"`n[6] IIS global modules" | Out-File $report -Append
if (Test-Path "$env:SystemRoot\System32\inetsrv\config\applicationHost.config") {
Select-String -Path "$env:SystemRoot\System32\inetsrv\config\applicationHost.config" -Pattern '<add name=' |
ForEach-Object { $_.Line.Trim() } | Out-File $report -Append
}
"`n=== Review complete. Any unsigned binaries, unexpected modules, or child-process hits warrant full IR escalation. ===" | Out-File $report -Append
Write-Host "Report written to $report"
Remediation
Immediate Actions (Next 24–72 Hours)
- Hunt before you assume you're clean. Deploy the Sigma rules and run the KQL hunts above across all Exchange servers. Turla's access predates the tooling — if you find Cereal-class artifacts, initiate a full incident response engagement; you are dealing with an established intrusion, not a single malware drop.
- Patch Exchange to the latest supported Cumulative Update and Security Update. Verify your build against Microsoft's official "Exchange Server build numbers and release dates" page (https://learn.microsoft.com/en-us/exchange/new-features/build-numbers-and-release-dates). Unsupported builds — anything more than one CU behind, or missing the most recent quarterly SU — are precisely the soft targets groups like Turla exploit for initial access.
- Reduce internet exposure. If OWA/EWS does not need to be internet-facing, it should not be. Place Exchange behind a VPN or a properly authenticated reverse proxy (e.g., with pre-authentication). Audit firewall rules for direct internet reachability of ports 443/80/587 to Exchange hosts.
- Enable and verify AMSI integration for Exchange and ensure Defender for Endpoint (or equivalent EDR with AMSI telemetry) is deployed and in block mode on Exchange servers. Too many environments exclude Exchange from EDR "for performance reasons" — that is exactly the blind spot this campaign exploits.
Hardening (Next 30 Days)
- Deploy Sysmon with a process-lineage config on all Exchange servers (SwiftOnSecurity or a tuned equivalent), including module-load logging for w3wp.exe and EdgeTransport.exe. Without this telemetry, the detections above are blind.
- Run Microsoft's Exchange Health Checker and the Exchange Emergency Mitigation (EM) service. Verify EM is enabled and actually pulling mitigations (check
%ProgramFiles%\Microsoft\Exchange Server\V15\Bin\EEMS\for activity logs). - Audit IIS global modules and Exchange virtual directories for unauthorized additions. Compare applicationHost.config and web.config files against a known-good baseline from a clean build or vendor reference.
- Restrict outbound egress from Exchange servers. Exchange needs SMTP (25/587), DNS (53), and update endpoints. It does not need arbitrary outbound 443 to the open internet. Egress filtering on Exchange servers is one of the single most effective controls against implants like Cereal exfiltrating collected mail.
- Enable mailbox auditing and transport agent logging, and alert on registration of new transport agents (
Get-TransportAgentdiffed against baseline — Turla-class actors have historically abused the Exchange transport pipeline for interception).
If You Find Evidence of Compromise
- Do not simply remove the implant. Turla maintains multiple persistence mechanisms and has demonstrated the ability to re-establish access rapidly.
- Preserve forensic evidence first: memory capture of the Exchange server, IIS logs (including historical — check retention), Security event logs, and a full disk image before remediation.
- Assume credential theft: any account that authenticated to the Exchange environment during the dwell window should be treated as compromised, particularly privileged accounts.
- Rebuild, don't clean. For confirmed nation-state implants on Exchange, the defensible path is a clean rebuild of the server on fully patched media, migration of mailboxes, and rotation of all credentials with access to the system.
- Report. Government and critical infrastructure organizations should engage CISA (report@cisa.gov) and national CERT channels; confirmed Turla activity has intelligence value beyond your own network.
The Bigger Picture
Cereal is a reminder that for espionage-motivated actors, the email server is the prize, not the stepping stone. Defenders who treat Exchange as "just infrastructure" — excluded from EDR, missing Sysmon, months behind on CUs, wide-open egress — are handing actors like Turla exactly the operating environment they need. The technical debt on Exchange servers is, functionally, an espionage subsidy. Close the telemetry gaps, tighten egress, patch on schedule, and hunt on the assumption that quiet does not mean clean.
Related Resources
Security Arsenal Red Team Services AlertMonitor Platform Book a SOC Assessment pen-testing Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.