Notifications
Clear all
Topic starter
02/08/2026 11:40 am
TL;DR: Attackers can impersonate Google Apps Script project patterns in GCP to hide resources, persistence, and service accounts inside a target organisation, according to Exaforce's research. The governance gap is not detection alone, but the assumption that project naming and visibility reliably distinguish legitimate automation from malicious infrastructure.
NHIMG editorial — based on content published by Exaforce: Ghost in the Script, impersonating Google App Script projects for stealthy persistence
By the numbers:
- 72% of organisations have experienced or suspect they have experienced a breach of non-human identities , 46% confirmed, 26% suspected.
Questions worth separating out
Q: What breaks when cloud project identity can be impersonated?
A: When project identity can be copied, defenders lose confidence that naming, folder placement, or console visibility reflects legitimacy.
Q: Why do non-human identities complicate sovereign cloud governance?
A: Because NHIs are created quickly, often get broad access, and are easier to overlook than human accounts.
Q: How can security teams know if hidden cloud projects are being abused?
A: Look for mismatches between expected project behaviour and observed state: unusual billing linkage, unexpected API enablement, projects created by non-Google principals, and service accounts inside low-visibility folders.
Practitioner guidance
- Restrict lookalike project creation paths Block creation and update of GCP projects whose IDs match sys-[0-9]{26} when Apps Script is not an approved workload pattern.
- Baseline legitimate Apps Script behaviour Record which Apps Script projects should exist, who creates them, which APIs they normally use, and whether they should ever be linked to billing.
- Treat service-account creation as persistence Monitor for service account creation, key generation, and privileged role binding inside low-visibility projects, especially where the project name resembles managed automation.
What's in the full article
Exaforce's full blog covers the operational detail this post intentionally leaves for the source:
- Step-by-step examples of how Apps Script impersonation is created inside GCP folders and why console views miss it.
- Detection logic for billing attachment, enabled APIs, and folder-level logs that can distinguish real from fake Apps Script projects.
- The custom organisation policy pattern used to deny sys-[0-9]{26} project creation when Apps Script is not required.
- Concrete Exaforce detection examples showing how principalEmail, service usage, and resource graphs are triaged.
👉 Read Exaforce's analysis of Google Apps Script impersonation and stealthy persistence →
Google Apps Script impersonation in GCP: what defenders are missing?
Explore further
02/08/2026 12:52 pm
Cloud project impersonation is a governance problem, not only a detection problem. The article shows that malicious resources can inherit the visual form of legitimate automation while remaining functionally separate from normal operator expectations. That means the control gap sits in lifecycle governance, naming trust, and folder-level visibility as much as in telemetry. In practice, cloud teams need to assume that metadata can be forged and build review paths that verify origin, not just appearance.
A question worth separating out:
Q: What should organisations do when Apps Script is not in use?
A: They should block the project creation pattern entirely and reduce the chance of project-name mimicry. If there is no business need for Apps Script, deny sys-style project IDs, monitor for exceptions, and review whether any existing automation depends on that surface before enforcing the policy.
👉 Read our full editorial: Google Apps Script impersonation creates stealthy GCP persistence
