Shared Infrastructure Nightmare: Dual APT Access in Balochistan Police Breach
Just caught the latest report regarding the Balochistan Police portal compromise. The timeline alone (Feb 2024 to April 2026) is terrifying, but the fact that researchers suspect both China- and India-aligned groups were weaponizing the same servers simultaneously is a new level of messy.
It sounds like they didn't just exfiltrate data; they maintained persistence on servers hosting web apps for sensitive police and citizen records. This screams "poor segmentation" and likely unpatched vulnerabilities allowing for web shell deployment. If you're supporting public sector entities, you know how common these legacy portals are.
For those hunting this specific behavior in your logs, look for anomalous process trees originating from your web server processes that shouldn't be there:
DeviceProcessEvents
| where Timestamp > ago(90d)
| where FolderPath endswith "\w3wp.exe" or FolderPath endswith "\httpd.exe"
| where ProcessCommandLine contains "whoami" or ProcessCommandLine contains "net user"
| project DeviceName, ProcessCommandLine, InitiatingProcessFileName, AccountName
Also, run a quick checksum on your web roots to spot recently modified ASPX or PHP files that might have slipped past the AV:
Get-ChildItem -Path "C:\inetpub\wwwroot" -Recurse -Include *.aspx, *.ashx, *.php |
Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-30) } |
Select-Object FullName, LastWriteTime, Length
What are your thoughts on the operational security here? Are we seeing "spy vs. spy" where one group is hijacking the other's C2 channel, or is the access just so wide open that they are ignoring each other?
Great query, but I'd recommend expanding that KQL hunt to include PowerShell encoded commands. In these state-sponsored campaigns, we often see w3wp.exe spawning powershell.exe with base64 encoded payloads rather than simple whoami checks. The obfuscation level is usually higher than skiddie tools.
Having worked with municipal gov, the downtime issue is real. They won't patch the portal because the 'system is critical.' If you can't patch, you need aggressive virtual patching on the WAF to block the upload attempts used to drop these web shells in the first place.
It's highly likely they were stepping on each other's toes. I analyzed a similar incident last year where Threat Actor A left a simple web shell, and Threat Actor B replaced the index page to install a more persistent backdoor, effectively overwriting the first group's access.
It’s wild that two APTs were cohabitating; they were likely overwriting each other's web shells constantly. Since patching wasn't an option, aggressive file monitoring is the only safety net. Check for recently modified files in the web directory that could be new persistence mechanisms dropped by either group:
Get-ChildItem "C:\inetpub\wwwroot" -Recurse | Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-7) }
Agreed on the WAF, but if containment is the goal, strict egress filtering is just as critical. These APTs need to exfil; blocking non-standard ports and whitelisting destinations can stifle that even if they maintain access.
I’d recommend hunting for long-lived connections in your netflow data. For example, looking for established connections on the web server:
netstat -ano | findstr ESTABLISHED | findstr ":443"
Look for IPs with high byte counts that don't match your known backup destinations.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access