Mustang Panda Leveraging Zoho WorkDrive for C2 in Indian Sector Attacks
Just saw the report from Acronis TRU regarding Mustang Panda's recent campaign against the Indian government and hydropower sectors. The shift towards using Zoho WorkDrive as a command channel is a significant evolution in their TTPs. It creates a nightmare for detection, as the traffic to a legitimate cloud provider often bypasses standard egress filtering.
The report mentions active compromises on senior admin staff machines. Given Mustang Panda's history, we are likely looking at spear-phishing initial access vectors followed by custom loader deployment. While IOCs are still emerging, we should be hunting for unusual process chains originating from Office suites.
Here is a basic KQL query to start hunting for suspicious parent-child process relationships that often accompany these document-based lures:
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("winword.exe", "excel.exe", "powerpnt.exe")
| where FileName in~ ("powershell.exe", "cmd.exe", "mshta.exe", "wscript.exe")
| project Timestamp, DeviceName, AccountName, InitiatingProcessCommandLine, ProcessCommandLine
| order by Timestamp desc
The bigger issue is the cloud C2 aspect. Without deep packet inspection or a CASB, this traffic looks like normal user activity. How is everyone handling "trusted" cloud service abuse in their environments? Are you blocklisting specific API endpoints or relying on behavioral anomalies?
We've seen similar tactics with APT29 abusing various cloud storage providers. The key is really focusing on the User-Agent and the volume of data transferred. Legitimate WorkDrive clients have specific UA strings. If you see a generic Python-requests or PowerShell UA hitting Zoho, block it immediately. We also started tracking the 'Time-On-Site' for these connections; C2 beacons often have much more regular heartbeat intervals than human file syncs.
This is exactly why we implemented strict OAuth token monitoring. If a workstation account that shouldn't have access to WorkDrive starts generating authentication tokens, it triggers an alert. Also, check for the presence of zoho in specific environment variables or hardcoded paths in suspicious PowerShell scripts. Threat actors often get lazy with where they stage their config tools.
From a red team perspective, abusing these services is incredibly effective because blue teams are terrified of blocking productivity tools. If you can't block the domain, try to limit the scope via your proxy. For example, only allow the Zoho WorkDrive subnets/IPs and block the rest of their ecosystem if not needed. It reduces the attack surface slightly.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access