Play Console MCP Privileged API Sweep
This rule flags a single automation session that uses the Google Play Developer API to touch multiple sensitive areas at once — account permissions, pricing/refunds, or resource deletion — within a ten-minute window. Normal release pipelines stay narrow; this pattern is broad and crosses unrelated business domains, which is the signal being reported.
How the attack works
A process (and its child processes in the same session) makes a high-impact write through the androidpublisher API — granting account access, changing prices or refunds, or deleting a Play resource. The rule then checks whether that same session also touched other unrelated domains, such as release publishing, store listings, or earnings data, inside a short ten-minute window. If the writes span three or more of these domains, or if a large burst of writes occurs, it's reported as a sweep. The rule does not attempt to explain how the session got its access — there's no visibility into credential theft or injection in this data — it only reports the abuse pattern once broad privileged use is already happening.
Netzilo detection
Netzilo reports this behaviour when it is observed.
- Signature ID
- 7f3c1e2a-9b64-4d18-8c5f-2a71d0e4b93c
- Severity
- Medium
Why it matters
An attacker (or compromised automation) holding a privileged API session could pull account grants, alter pricing or refunds, and touch app assets or delete resources in one short burst — actions that could lead to unauthorized payouts, account takeover of developer permissions, or destructive changes to a published app, before anyone notices the session was misused.
What you can do
- →Restrict which service accounts or CI credentials can call androidpublisher endpoints for account/user grants and monetization together — separate those permissions from release/publishing automation where possible.
- →Review any session that mixes access-control changes (user grants) with pricing, refunds, or deletions in the same short window; confirm it matches a known onboarding or admin script.
- →Set short-lived, scoped tokens for release pipelines so a single compromised token cannot reach both release and monetization/account domains.
- →Log and periodically audit Play Developer API usage by session/process to catch unexpected breadth in tool use, even if each individual write looks legitimate.
Known benign look-alikes
- Full CI/CD release rollout (fastlane supply, Gradle Play Publisher) that creates an edit, uploads a bundle, updates a track, updates listings and commits — this stays inside release/store-assets and does NOT hit the access-control or monetization anchor, so it is not reported unless it also mutates prices or user grants.
- Scheduled monetization jobs that update in-app product prices or subscription base plans while a staged rollout is running in the same session — anchor plus one other domain; reported only if a third domain or a 12-write burst is also present.
- Play Console user onboarding/offboarding scripts that add or remove developer account grants and then pull a report in the same run — this is the intended access-control anchor firing on a legitimate admin action.
- Bulk cleanup jobs that DELETE stale internal app sharing artifacts, expansion files or obsolete in-app products (three or more DELETEs trips the burst branch).
- Monthly earnings/financial export jobs reading the pubsite_prod_rev_* bucket that happen to run during a release window under the same shell session.