Malicious Keylogger Campaign Hits 65 Microsoft Exchange Servers Worldwide
In a chilling reminder of the dangers lurking in outdated systems, security firm Positive Technologies has uncovered a stealthy campaign targeting publicly exposed Microsoft Exchange servers in 26 countries—65 confirmed victims—where malicious JavaScript keyloggers are being injected into Outlook Web Access (OWA) login pages.
The Attack Unveiled: JavaScript Keyloggers on OWA
According to the analysis:
- The JavaScript code scrapes credentials from the login form
- It either:
- Saves them to a local file accessible externally
- Sends them immediately via XHR to an attacker-controlled endpoint
These keyloggers are sophisticated:
- Local exfiltration: The data is stored on the server—no network traffic flags security tools.
- Direct exfiltration: The data is streamed out via XHR to attacker infrastructure, including malicious Telegram bots or even DNS tunnels.
“Malicious JavaScript code reads and processes the data from the authentication form, then sends it via an XHR request to a specific page on the compromised Exchange Server,” write researchers Klimentiy Galkin and Maxim Suslov.
Source: The Hacker News Article
Why 65 Servers — and Counting?
This is not a one-off:
- The campaign is an evolution of attacks first observed in May 2024, initially targeting government agencies, banks, IT firms, and educational institutions in Africa and the Middle East.
- It leverages known exploits—notably the dreaded ProxyShell and ProxyLogon vulnerabilities:
- CVE‑2021‑26855, ‑26857, ‑26858, ‑27065 (ProxyLogon)
- CVE‑2021‑31206, ‑31207, ‑34473, ‑34523 (ProxyShell)
- Plus older CVEs like CVE‑2014‑4078 and CVE‑2020‑0796.
Exchange servers have long been a magnet for attackers due to their role in identity and email. These vulnerabilities, years old yet unpatched, leave doors wide open.
The Threat Actor’s Playbook
- Scan for internet-exposed OWA endpoints.
- Exploit publicized CVEs to gain code execution on the server.
- Modify the
login.aspxor similar file to inject malicious JavaScript. - Harvest credentials silently. In some cases, attackers also collect cookies, user agents, and timestamps.
- Persist without detection, given zero outbound traffic in the local exfiltration variant.
Mirroring techniques seen in past Exchange campaigns (e.g. Hafnium, ProxyLogon in 2021), this method remains disturbingly effective.
Microsoft’s Response: Patch, Detect, Protect
🔧 1. Immediate Patching & Mitigation
Microsoft continuously releases security updates for Exchange Server. In May 2025 alone, they patched 71 CVEs, including five critical flaws. The Microsoft Security Response Center (MSRC) strongly urges administrators to:
👉 Check Microsoft’s Security Update Guide
- Install updates without delay.
- Follow Microsoft’s patching guidance for your Exchange version.
🔍 2. Detection Tools & Forensic Cleanup
Microsoft’s Exchange Team provides:
- A Detection Tool for Web Shells
- An On-Premises Mitigation Tool (PowerShell script) to scan and remove malicious scripts/web shells from affected servers
These tools are essential for not just patching—but entirely cleaning—compromised systems.
📘 3. Defense-in-Depth
Layered security can disrupt this attack chain:
- Network segmentation: OWA shouldn’t be reachable by credentials stored locally.
- Web Application Firewalls (WAFs): Watch for suspicious POST/XHR behavior on login endpoints.
- HTTP anomaly detection: Look for patterns matching malicious XHR calls.
Code Example: Detecting Malicious XHR in OWA
Below is a PowerShell snippet that searches Exchange web directories for suspicious XHR injection patterns:
# Iterate over installed Exchange web directories
$owaDirs = "C:\inetpub\wwwroot\owa",
"C:\inetpub\wwwroot\ecp"
$pattern = '<script.*?XMLHttpRequest.*?send\('
foreach ($dir in $owaDirs) {
Get-ChildItem -Path $dir -Recurse -Include *.aspx,*.js |
ForEach-Object {
if (Select-String -Path $_.FullName -Pattern $pattern -Quiet) {
Write-Host "⚠️ Malicious script detected in $($_.FullName)"
}
}
}
What this does:
- Scans script and ASPX files in OWA/ECP folders
- Flags any references to
XMLHttpRequestorsend(— common in keylogger payloads
Next steps:
- If flagged, examine and compare the scripts to clean/repair them using backups or sanitized versions.
Stay Ahead: Hardening Steps
| Step | Action |
|---|---|
| 1. Patch Today | Install all patches from MSRC: https://msrc.microsoft.com |
| 2. Scan & Clean | Use PowerShell tools & forensic scripts to remove injected code |
| 3. Monitor Logs | Enable logging for OWA endpoints and WAF alerts |
| 4. Network Hygiene | Restrict access to OWA to trusted IPs/MFA |
| 5. Plan Recovery | Implement regular backups and incident response drills |
| 6. Review Architecture | Consider moving on‑prem Exchange to Exchange Online (cloud‑hosted with SaaS‑level patch automation and protection) |
The Human Stakes Behind the Code
When a user's password is stolen, it’s not abstract—it’s their career email, university account, or the local council's correspondence. Each vulnerable server can be the key to wider identity theft, espionage, fraud, or ransomware.
Quiet campaigns like this are dangerous precisely because they fly under the radar: no spikes in outbound traffic, no obvious malware, just keystrokes flowing into silent scripts. As one researcher aptly noted, this attack is “undetectable for long periods”—until the damage shows up downstream.
In Closing: Code, Courage, and Collective Action
This is more than a patching issue—it’s a people and process issue. When systems are left exposed, they become weaponized against real humans. Here’s how we all can act:
- Systems administrators, prioritize patching and cleanups today.
- Organizations, reassess reliance on on‑prem infrastructure; consider secure SaaS alternatives.
- Security teams, layer defenses, monitor with intention, and simulate incidents.
- Everyone, stay informed—share this post with your peers, and encourage proactive checks.
🌱 If you’re responsible for Exchange systems, take 30 minutes today:
Use [Optimize365.io](https://optimize365.io) to assist you in automating your assessment and remediation processes
Only then can we close another chapter in this long-running exchange of harm and hope.
We can’t fix what we don’t patch—start the cleanup now.