Malware News Mustang Panda Uses Zoho WorkDrive as Command Channel in Indian Government Attacks

[Captain Awesome]

Content source

https://thehackernews.com/2026/06/mustang-panda-uses-zoho-workdrive-as.html?m=1

The China-aligned espionage group Mustang Panda is running two campaigns against the Indian government and hydropower targets, deploying new malware and turning a legitimate cloud service into its command channel.

Acronis Threat Research Unit found active compromises inside Indian government networks, including machines used by senior administrative staff, and worked with CERT-In on notification and cleanup.

The malware abuses Zoho WorkDrive, a cloud storage platform common in India's government sector, to pass commands and exfiltrate data. That is the whole idea: the traffic looks like ordinary cloud activity, so it hides inside the network it is stealing from.

The Zoho security and operational teams are fully aware of this threat and have actively intervened to shut down the malicious accounts.

 

[Bot]

The Zoho security and operational teams are fully aware of this threat and have actively intervened to shut down the malicious accounts.

Abusing a legitimate cloud service (like Zoho WorkDrive) as a command-and-control channel usually does not mean “Zoho was hacked” or that there is an inherent platform vulnerability—it often means the attacker created or took over accounts and then used normal API/file activity to blend in with expected traffic.

What the quoted detail implies (practically)

• Network defenses that rely mainly on “block suspicious domains” can fail, because the traffic goes to a well-known, allowed SaaS provider.
• Detection often has to shift to identity signals (account behavior, OAuth/app usage, MFA events) and endpoint telemetry (new processes, persistence, suspicious file access), not just perimeter logs.
• If attackers used stolen credentials, shutting down malicious accounts helps, but it does not automatically remove the original access path (phishing, token theft, compromised endpoint, etc.).

About the statement “Zoho teams are fully aware and shut down malicious accounts”
I can’t verify that claim from the excerpt alone. It’s plausible and consistent with how SaaS providers respond (they can disable abusive tenants/accounts), but the most reliable confirmation would be an official Zoho advisory/support communication or a report from the researching vendor that explicitly documents Zoho’s takedown actions.

Defensive steps that typically matter most in this scenario

• Identity hardening: enforce MFA (prefer phishing-resistant where possible), review conditional access, disable legacy authentication, and rotate credentials where compromise is suspected.
• Token/OAuth hygiene: review third-party app consent/OAuth grants and revoke suspicious refresh tokens/sessions.
• SaaS auditing: enable and retain detailed WorkDrive/Zoho audit logs; alert on unusual downloads, mass file access, new device/location anomalies, and creation of strange shares/public links.
• Endpoint containment: isolate and forensically triage affected machines; check for persistence mechanisms and credential theft artifacts; reimage if integrity is uncertain.
• Data access control: least-privilege on repositories, reduce standing access for senior staff machines, and segment sensitive shares so a single endpoint doesn’t expose broad datasets.
• Detection engineering: build detections around behavior (rare user agents, unusual API call patterns, abnormal upload/download volumes) rather than simply blocking the domain.

If this is being discussed for organizational defense, the safest next step is to rely on the published IOCs/TTPs from the reporting vendor and internal log review, and treat “account takedown” as only one part of remediation—not the conclusion.