Exchange 2016 Unauthenticated Email Vulnerabilities (2023–2025)

CVEs Enabling Unauthenticated or Spoofed Email Sending

Case Studies and Incident Reports

  • ProxyShell & ProxyNotShell Exploits (2021–2022): Earlier exploit chains like ProxyShell (2021) demonstrated the danger of Exchange transport flaws. ProxyShell combined three bugs (CVE-2021-34473, 34523, 31207) to achieve pre-auth remote code execution (RCE) on Exchange 2016 (PST, Want a Shell? ProxyShell Exploiting Microsoft Exchange Servers | Google Cloud Blog) (PST, Want a Shell? ProxyShell Exploiting Microsoft Exchange Servers | Google Cloud Blog). Attackers worldwide (e.g. UNC2980 in a university attack) used this to compromise servers and then sent malicious emails from those servers (PST, Want a Shell? ProxyShell Exploiting Microsoft Exchange Servers | Google Cloud Blog) (PST, Want a Shell? ProxyShell Exploiting Microsoft Exchange Servers | Google Cloud Blog). In 2022, ProxyNotShell (CVE-2022-41040/41082) – an SSRF plus RCE – was similarly used to hijack Exchange 2016 servers. Once RCE was gained via these exploits, attackers often installed web shells or ran Exchange Management shells to send spam/phishing emails directly from the Exchange server, effectively bypassing normal authentication (since the server itself was sending the mail). These incidents underscored that even fully patched Exchange environments needed continuous monitoring, as exploit code often leveraged the Exchange transport pipeline to propagate malicious emails internally.
  • NTLM Relay Attacks by APT Groups (2023): In 2023, threat actors (including nation-state groups) targeted Exchange’s authentication weaknesses. For example, APT28 (a Russian state-linked group) was observed exploiting NTLM relay vulnerabilities like CVE-2024-21410 to steal Exchange authentication tokens and impersonate users (CVE-2024-21410 Archive - Greenbone). This allowed them to read confidential emails and even send messages as high-privilege users, all without valid credentials. CISA reported that CVE-2024-21410 was under active attack (added to the KEV catalog) (CVE-2024-21410 Archive - Greenbone), meaning multiple incidents where on-prem Exchange servers were breached. In these cases, Exchange servers became launch pads for further phishing or data theft – attackers authenticating as the Exchange server itself and then interacting with mailboxes or sending outbound mail as if it were legitimate system activity.
  • Exchange Server as a Spam Relay (Real Incidents): There have been reports of Exchange 2016 servers suddenly sending outbound spam or phish without any user account being obviously compromised. In one Spiceworks forum case, an admin found their Exchange sending emails to all users from what looked like internal accounts. The message headers showed an X-ClientProxiedBy line with the Exchange server’s own name/IP “To” itself (127.0.0.1) – indicating the message was injected locally on the server (Email account compromised and keeps getting flooded - Collaboration). This kind of artifact is a red flag: it suggests the SMTP pipeline was triggered internally (possibly by malware or a web shell on the server) rather than by a user logging in via Outlook. Microsoft’s incident guidance notes that once attackers gain Exchange SYSTEM access, they can directly submit emails into transport using PowerShell or pickup directories, leading to outbound messages that bypass normal auth logging. Such messages often show only the Exchange server (localhost) in Received headers. (For example, Exchange’s own health probe emails originate from 127.0.0.1 as seen in headers (Undeliverable Inbound proxy probe message troubleshoot - Microsoft Q&A) – an attacker can abuse similar internal channels to send mail.)

Behavioral Notes: Proxied Traffic & Header Indicators

  • Headers Showing Localhost (127.0.0.1): When Exchange’s Frontend Transport proxies SMTP connections to the backend, it can stamp headers like Received: from <source> (127.0.0.1) by <server> or add an X-ClientProxiedBy header. For instance, Exchange health monitoring will generate an InboundProxyProbe message from 127.0.0.1, with headers such as “Received: from InboundProxyProbe (127.0.0.1) by ExchangeServer (127.0.0.1)” (Undeliverable Inbound proxy probe message troubleshoot - Microsoft Q&A). In a healthy scenario, these originate from HealthMailbox accounts and are benign. However, if you find outbound emails with similar headers (localhost as the sending host) that are not from a health mailbox, it may indicate that the email was injected internally. In other words, the Exchange server itself (or a process on it) acted as the client. This is typical in exploits where the attacker runs code on the server – the malicious email is submitted locally, so no external IP shows up.
  • X-ClientProxiedBy Header: This header explicitly notes an Exchange Frontend server proxying an SMTP session to a Mailbox server. In single-server environments it might show the same server twice (proxy to itself). For example: “X-ClientProxiedBy: ExchServer.LOCAL (192.168.10.13) To ExchServer.LOCAL (192.168.10.13)” (Email account compromised and keeps getting flooded - Collaboration). In Office 365, admins sometimes use this header to spot spoofing or strange routing (o365 Journal Spoofing -- X-ClientProxiedBy header can be used for). In on-prem Exchange 2016, seeing your server’s name/IP in both the proxy “By” and “To” fields for an outbound message could mean the message didn’t come from an authenticated client at all – it was accepted by the frontend from an internal source. When investigating suspicious emails, lack of an authenticated sender and presence of localhost in headers are strong signs of an email sent via a backend process rather than a user login. This aligns with vulnerabilities that allow transport-level abuse: e.g. an NTLM relay attack might make the Exchange server trust the connection as internal, resulting in a proxied-by-localhost header and the email getting sent out without an auth event.
  • No User Authentication in Logs: Environments hit by these vulnerabilities often find that outbound malicious emails do not correspond to any user’s SMTP login in the logs. That’s because exploits like token replay or EWS-based attacks leverage service contexts. For instance, CVE-2023-38181’s NTLM relay could make Exchange accept a message as if it were coming from the Exchange server itself (Exchange believes it’s just routing internal system traffic) (Zero Day Initiative — The August 2023 Security Update Review). Similarly, after an attacker gains SYSTEM-level access (via RCE), they can call Exchange’s send-mail APIs or drop emails into the pickup folder, which bypasses authentication. The result is outbound mail that Exchange delivers (often successfully) but doesn’t attribute to any mailbox login – the only trace is in message tracking or headers showing the server as the source. Administrators should look for anomalies like messages with X-MS-Exchange-Organization-AuthAs: Internal despite not being sent by a known application account, or unexpected X-ClientProxiedBy entries, as these often accompany spoofed or unauthenticated deliveries from compromised Exchange servers.

References

Edit
Raw PDF PNG
Report
Pub: 18 Apr 2025 14:52 UTC
Views: 55
new·what·how·langs·contacts