Listen to this Post
Introduction
In late 2025, a Chinese-linked threat group known as FamousSparrow launched a multi‑wave cyber‑espionage campaign against an Azerbaijani oil and gas company, gaining initial access by exploiting two well‑known Microsoft Exchange vulnerability chains: ProxyNotShell and ProxyShell. The attackers re‑compromised the same vulnerable server three times over two months, deploying custom backdoors such as Deed RAT and Terndoor, evading detection with advanced DLL sideloading, and finally moving laterally to domain controllers via RDP and SMB. This incident underscores a harsh reality: unpatched Exchange servers are not just a risk – they are an open invitation for persistent, state‑backed intruders.
Learning Objectives
- Understand how ProxyShell and ProxyNotShell chains bypass Exchange authentication and enable remote code execution with SYSTEM privileges.
- Recognise the evasive techniques – two‑stage DLL sideloading, custom encryption, and security‑vendor spoofing – that APTs use to maintain long‑term access.
- Master the hands‑on steps to detect, mitigate, and remediate these vulnerabilities in your own environment, including specific commands and detection rules.
You Should Know
- Understanding ProxyShell and ProxyNotShell – Two Critical Attack Chains
The attack leveraged two distinct vulnerability chains: ProxyShell (CVE‑2021‑34473, CVE‑2021‑34523, CVE‑2021‑31207) and ProxyNotShell (CVE‑2022‑41040, CVE‑2022‑41082). Both chains allow an unauthenticated attacker to execute arbitrary code on a vulnerable Exchange server.
Step‑by‑step guide explaining what this does and how to use it (for defensive understanding):
– ProxyShell works by first sending a specially crafted request to the `/autodiscover/autodiscover.json` endpoint, exploiting a path confusion bug (CVE‑2021‑34473) to gain NT AUTHORITY\SYSTEM access to any backend URL. The attacker then uses the `X‑Rps‑CAT` parameter to impersonate an Exchange admin (CVE‑2021‑34523) and finally exports a mailbox to a malicious `.aspx` webshell (CVE‑2021‑31207).
– ProxyNotShell uses a server‑side request forgery (CVE‑2022‑41040) to reach the PowerShell backend, then exploits a deserialisation flaw (CVE‑2022‑41082) to achieve remote code execution.
Quick verification commands (run on the Exchange server):
Check Exchange build numbers against known vulnerable versions (Get-Command ExSetup.exe).FileVersionInfo.ProductVersion Compare with: Exchange 2019 CU12 < 15.2.1118.20 (vulnerable)
See also: Full version table at Microsoft Exchange build numbers.
NOTE: All Exchange versions before November 8, 2022 are vulnerable to these chains.
- Detecting ProxyShell and ProxyNotShell Exploitation in Your Environment
The first sign of compromise is often the deployment of a webshell. In the FamousSparrow incident, the IIS worker process (w3wp.exe) wrote a malicious `.aspx` file into a publicly accessible Exchange directory. Network monitoring also revealed suspicious POST requests to `/autodiscover/autodiscover.json` with `X‑Rps‑CAT` parameters – clear indicators of ProxyShell/ProxyNotShell reconnaissance and exploitation.
Step‑by‑step detection:
- Search for webshell creation in IIS directories (e.g.,
\HttpProxy\owa\auth\,\inetpub\wwwroot\aspnet_client\). Use the following Splunk query as a starting point:index= sourcetype="WinEventLog:" (file_path="\HttpProxy\owa\auth\" OR file_path="\inetpub\wwwroot\aspnet_client\") file_name=".aspx" | stats count by dest, user, file_path
2. Monitor HTTP logs for unusual POST requests:
grep -i "POST /autodiscover/autodiscover.json" /var/log/nginx/access.log grep -i "X-Rps-CAT" /var/log/httpd/access.log
Security teams should also look for “suspicious POST requests … that may indicate attempts to enumerate LegacyDN attributes as part of initial reconnaissance” and “requests containing X‑Rps‑CAT parameters” which indicate attempts to impersonate Exchange users.
3. Correlate outbound HTTPS traffic to known malicious C2 domains such as `sentinelonepro.com` (used to spoof SentinelOne) and virusblocker.it.com. A simple PowerShell one‑liner to test for such connections (in a lab only):
Invoke-WebRequest -Uri "https://sentinelonepro.com/heartbeat" -UseBasicParsing -Headers @{"User-Agent"="DeedRAT/1.0"} -TimeoutSec 10
- Hardening Microsoft Exchange – Patch, Segment, and Restrict
Patching is the only complete defence. However, many organisations delay updates. The FamousSparrow attackers exploited this precisely: they returned repeatedly to the same unpatched Exchange server because the victim failed to close the original entry point.
Step‑by‑step mitigation:
1. Apply the official security updates immediately:
- For ProxyShell: CVE‑2021‑34473, CVE‑2021‑34523, CVE‑2021‑31207.
- For ProxyNotShell: CVE‑2022‑41040, CVE‑2022‑41082.
- Use PowerShell to enforce extended protection and disable vulnerable authentication methods:
Enable Extended Protection for authentication Set-ExchangeServer -Identity "Exchange01" -ExtendedProtectionTokenChecking Allow Disable basic authentication globally Get-CASMailbox -ResultSize Unlimited | Set-CASMailbox -BasicAuthEnabled $false
- Restrict RDP and SMB – the attackers moved laterally using a domain admin account and Impacket tools. Enforce network segmentation:
On Linux: restrict SMB access to only authorised subnets iptables -A INPUT -p tcp --dport 445 -s 10.0.0.0/8 -j ACCEPT iptables -A INPUT -p tcp --dport 445 -j DROP
-
Analysing the Malware Arsenal: Deed RAT, Terndoor, and Mofu Loader
The campaign deployed three distinct backdoors across three waves:
– Deed RAT (also Snappybee) – delivered via DLL sideloading using the legitimate LogMeIn Hamachi binary, allowing it to inherit the trust of a signed process. It uses RC4/AES‑CBC encryption and LZNT1/Deflate compression.
– Terndoor – a backdoor previously seen against South American telecoms, loaded via a driver‑based chain.
– Mofu Loader – a shellcode loader attributed to the GroundPeony cluster.
Step‑by‑step technical deep dive (for reverse engineers):
- The DLL sideloading is two‑stage: the malicious library overrides two exported functions, requiring the host application to complete its full startup sequence before activating the payload. This defeats sandboxes that only examine partial code execution.
- To identify such activity, search for `LogMeIn Hamachi` services or drivers started from user‑writable paths:
Get-Service | Where-Object {$_.DisplayName -like "LogMeIn"} | Select-Object Name, Status, StartType Check for unexpected service binary paths wmic service where "name like '%Hamachi%'" get pathname - The C2 domain `sentinelonepro.com` was used to blend into environments where SentinelOne agents are deployed, making outbound HTTPS traffic appear legitimate.
- Incident Response Playbook – Reclaiming the Compromised Exchange Server
The attackers’ persistence (three waves over two months) demonstrates that simple remediation is not enough. You must assume the intruder will return as long as the original vulnerability remains.
Step‑by‑step recovery:
- Isolate the compromised Exchange server from the network.
2. Collect forensic artefacts:
- IIS logs for `/autodiscover/autodiscover.json` POST requests.
- Sysmon Event ID 11 for `.aspx` file creations in IIS directories.
- Process creation events for `w3wp.exe` writing to web‑accessible paths.
3. Remove all webshells:
Find all .aspx files modified in the last 30 days in IIS directories
Get-ChildItem -Path "C:\inetpub\wwwroot" -Recurse -Include ".aspx" | Where-Object {$_.LastWriteTime -gt (Get-Date).AddDays(-30)}
4. Hunt for persistence – check for scheduled tasks, services, and startup entries:
schtasks /query /fo LIST /v | findstr /i "Hamachi Deed RAT"
5. Once clean, patch immediately and rotate all credentials that the domain admin account may have touched.
What Undercode Say
- Key Takeaway 1: Unpatched vulnerabilities don’t just grant access – they give attackers a reusable master key. The FamousSparrow group returned three times through the same Exchange flaw, proving that a single unpatched server can become a persistent beachhead.
- Key Takeaway 2: Trusted binaries are the new attack vector. By using legitimate, signed software (LogMeIn Hamachi) to load malicious DLLs, the attackers bypassed many security tools. Defenders must monitor not just for malware, but for abnormal behaviour from trusted processes – such as a VPN service writing to unusual paths or spawning unexpected child processes.
Prediction
The energy sector will become a prime testing ground for APT groups, leveraging vulnerabilities in widely used enterprise software. We will see more “two‑stage” evasions – techniques that gate malicious payloads behind legitimate application logic – as a standard method to bypass sandboxes and EDR. Organisations that do not adopt continuous, automated patch management and behaviour‑based monitoring for trusted processes will remain at high risk. The lesson from FamousSparrow is clear: an unpatched server is not a vulnerability; it is a welcome mat for state‑sponsored spies.
▶️ Related Video (80% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Varshu25 Microsoft – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
