FamousSparrow Resurfaces: Multi-Wave Exchange Intrusions in Critical Infrastructure
Just caught the Bitdefender report regarding the persistent targeting of an Azerbaijani oil and gas firm. It looks like FamousSparrow (UAT-9244) is back at it, leveraging a "multi-wave" intrusion strategy between late Dec 2025 and Feb 2026.
What stands out isn't just the geopolitical targeting of the energy sector, but the sheer persistence. They weren't content with a single foothold; they kept coming back through Microsoft Exchange. Given FamousSparrow's history with ProxyShell-like vulnerabilities, it's highly likely they are exploiting unpatched deserialization flaws or relying on legacy web shells.
If you're still running on-prem Exchange, specifically for OWA or ECP, you need to audit your IIS logs immediately. Look for anomalies in the autodiscover or ecp directories.
Here is a quick PowerShell snippet to hunt for recently modified ASPX files in the web root—a common sign of web shell persistence:
$Path = "C:\inetpub\wwwroot"
$Date = (Get-Date).AddDays(-30)
Get-ChildItem -Path $Path -Recurse -Filter "*.aspx" |
Where-Object { $_.LastWriteTime -gt $Date -and $_.Length -lt 10kb } |
Select-Object FullName, LastWriteTime, Length
Also, monitor for suspicious PowerShell child processes spawned by w3wp.exe.
Is anyone else seeing a resurgence of classic Exchange TTPs lately, or is the community finally moving off on-prem fast enough to avoid these?
We saw similar behavior in a honeypot last week. The initial access was via a legacy ProxyNotion attempt, but they immediately dropped a custom web shell named healthcheck.aspx. The key indicator we found was the User-Agent string sticking to "Mozilla/5.0 (compatible; MSIE 9.0; Windows NT 6.1; Trident/5.0)"—very old school. If you're using Sentinel, try this KQL query to catch the initial spray:
SecurityEvent
| where EventID == 4625
| where AccountType == "User"
| where Account contains "HealthMailbox"
| summarize count() by IpAddress, Account
As an MSP, this is my nightmare fuel. We have a few clients clinging to on-prem Exchange because of specific legacy apps. We've actually started restricting ECP access via VPN only and enforcing MFA, which seems to have stopped the automated scanners. It’s not a silver bullet, but it stops the initial wave from the internet. Has anyone had success with Microsoft's Exchange Mitigations tool in reducing the attack surface effectively?
I recall analyzing FamousSparrow samples a while back. They love using the Set-User cmdlet via the ECP backend to grant themselves permissions once they have a foothold. If you suspect compromise, don't just look at file changes; audit the Exchange Admin Audit logs for any suspicious permission escalations.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access