Google Apps Script impersonation creates stealthy GCP persistence

At a glance

What this is: Exaforce details how Google Apps Script project impersonation can conceal hidden GCP resources, persistent service accounts and compute abuse inside an organisation.

Why it matters: IAM and cloud security teams need to treat project identity, billing state and service-account behaviour as governance signals, not just visibility problems, because malicious infrastructure can mimic legitimate automation.

Context

Google Apps Script is a low-code automation layer, but in GCP it also creates a distinct project footprint that defenders often misread. The security gap is that project naming, folder placement and console visibility do not reliably tell you whether a resource is legitimate or hostile, especially when the attacker controls project creation and IAM.

This matters for identity and cloud governance because the abuse path is built around service accounts, project ownership and resource manager permissions. Once a hidden project exists, it can host compute, persist through a service account, or sit outside normal operator attention unless teams look at billing, enabled services and creation logs together.

Key questions

Q: What fails when a GCP project can impersonate Apps Script naming patterns?

A: The failure is inventory and trust, not only detection. If project IDs, folder placement and console visibility are treated as reliable proof of legitimacy, an attacker can hide a project, attach resources or create persistent identities, and operate before the mismatch is noticed.

Q: Why do hidden cloud projects become a persistence risk for service accounts?

A: Because the attacker does not need to keep the entry point alive if the service account remains. A service account can outlast the initial project abuse, carry privilege into later activity and be harder to remove when ownership, scope and purpose are unclear.

Q: What are the signs that a lookalike Apps Script project is being abused?

A: Look for unusual billing links, unexpected compute enablement, suspicious principalEmail values in folder-scoped logs and service-account activity inside projects that should be quiet. A single signal is weak, but the combination often shows impersonation rather than normal automation.

Q: How should organisations block malicious Apps Script project impersonation?

A: They should combine project-creation restrictions, approved-use exceptions and continuous review of project metadata, billing and service usage. Blocking the ID pattern alone is too blunt if Apps Script is legitimately used, but allowing it without governance leaves a hiding place for persistence.

Technical breakdown

Why Apps Script project impersonation works in GCP

Apps Script projects in Google Cloud are not magical objects. They are normal GCP projects created under a specific naming and folder pattern, which means an attacker who can create projects can imitate that pattern closely enough to confuse manual review. The problem is structural: visibility differs depending on where the project lives, and console views do not always show the same inventory as gcloud or Resource Manager. That creates an identity and inventory gap at the control plane, not just a detection gap.

Practical implication: inventory GCP projects from the control plane and not only from the console.

How hidden projects become persistence and abuse platforms

Once a deceptive project exists, it can host paid resources such as compute or free-tier resources such as service accounts. That matters because persistence does not require a large footprint if the attacker can keep a privileged identity alive inside a project that looks routine. Service accounts are especially useful here because they can outlast the initial intrusion, carry privilege, and operate even when some services are disabled. In practice, the persistence mechanism is identity-based, while the camouflage is project-based.

Practical implication: treat service-account creation in suspicious projects as a persistence event, not a routine admin action.

What makes detection hard in apps-script lookalike projects

Detection is complicated by the fact that billing, enabled APIs and principal email patterns can each be manipulated or partially hidden. A fake Apps Script project may need billing for compute, but a persistent service account does not. Attackers can also disable unused services or re-enable them only when needed, which makes static checks brittle. In other words, one signal is rarely enough. Defenders need correlated evidence across billing state, resource inventory, API usage and audit logs to distinguish normal automation from impersonation.

Practical implication: correlate billing, API enablement and audit logs before concluding a project is legitimate.

Threat narrative

Attacker objective: The attacker wants a concealed, reusable foothold in GCP that can host resources or privileged identities without drawing normal administrator attention.

1. Entry occurs when an attacker gains the ability to create or modify GCP projects inside the target organisation and chooses a sys-prefixed lookalike to imitate Google Apps Script.
2. Credential and identity abuse follow when the attacker creates or reuses a service account in the hidden project and assigns it privilege that can survive after the initial access path closes.
3. Impact comes when the hidden project is used for cryptomining, privileged persistence or other covert activity that blends into normal cloud administration.
4. The attack objective is to establish durable, low-visibility control inside GCP while avoiding detection by project-name and console-based review.

Breaches seen in the wild

• Kubeflow cryptomining attacks 2020: Exposed Kubeflow dashboards and a notebook's mounted Kubernetes service account let attackers run cryptominers on tens of ML clusters.
• Dropbox Sign breach 2024: A compromised back-end service account gave attackers Dropbox Sign customer data, including API keys, OAuth tokens and MFA information.

Read and download The State of NHI & AI Agent Breach Report 2026, covering 200+ breaches impacting Non-Human Identities including AI Agents.

NHI Mgmt Group analysis

Project impersonation is now an identity-control problem, not just a naming problem. The article shows that a lookalike project can slip past console review because the real control boundary is the project creation and IAM path, not the visible label. That means cloud governance teams must treat project identity as part of the security model, not as metadata. The practitioner conclusion is simple: review how project creation is authorised and observed, not just how projects are listed.

Stealthy persistence in cloud environments increasingly rides on non-human identities. The hidden project itself is the camouflage, but the durable foothold is the service account living inside it. That is a classic NHI governance issue because the account can outlast the entry point, retain privileges and be harder to offboard if ownership is unclear. Practitioners should treat service-account lifecycle and project lifecycle as a single control surface.

Hidden compute plus hidden identity creates a detection blind spot that policy alone will not close. Billing state, enabled APIs and audit logs each reveal part of the story, but attackers can shape all three to look ordinary. Cloud identity sprawl: that is the real failure mode here, where projects, identities and permissions multiply faster than teams can reconcile them. The field implication is that cloud security programmes need joined-up inventory, not isolated alerts.

Organisation policies can block the lookalike pattern, but only if teams understand the normal pattern well enough to constrain it. The article’s suggested sys-[0-9]{26} denial is a control design example, not a complete answer. If an organisation actually relies on Apps Script, the policy must be paired with a clear exception model and stronger monitoring around approved automation. The practitioner conclusion is that prevention without governance will either miss abuse or block legitimate work.

Exaforce’s detections point to a broader shift in cloud defence toward behavioural context over static signatures. The article’s value is not the vendor reference itself, but the lesson that unusual API use, unexpected policy bindings and session-level event correlation are more reliable than visual inspection alone. For identity teams, that is a reminder that NHI monitoring has to include cloud resource context. The practitioner conclusion is to align detections with project behaviour, not just project appearance.

From our research library:

• Only 5.7% of organisations have full visibility into their service accounts, according to the Ultimate Guide to NHIs.
• Read next: Service Account Security Guide

What this signals

Cloud identity sprawl: the danger is not just that attackers create a hidden project, but that they can attach a durable non-human identity to it and make later cleanup ambiguous. When project lifecycle and service-account lifecycle are managed separately, the attacker gets room to persist. The control question is whether your governance model can tie a project, its billing state and its NHI ownership back to a single accountable record.

Defenders should stop assuming that console visibility is a trustworthy proxy for legitimacy in GCP. The operational signal is stronger when you combine audit logs, billing relationships and service enablement with a normal baseline for automation. That approach is more resilient than treating naming conventions as evidence of benign use.

For practitioners

• Establish project-creation guardrails Restrict who can create projects in sensitive GCP organisations and review whether sys-style lookalike IDs are even necessary in your environment.
• Monitor service-account creation in new projects Alert when a newly created project contains a service account, especially if the project appears to mimic Apps Script naming or folder placement.
• Correlate billing with resource intent Flag hidden or low-visibility projects that unexpectedly link to a billing account or spin up compute resources inconsistent with legitimate Apps Script usage.
• Validate audit logs from the apps-script folder Review principalEmail, project creation events and folder-scoped logs to separate Google-managed Apps Script activity from attacker-created impersonations.
• Use organisation policy to block impersonation patterns Apply a custom constraint that denies project IDs matching sys-[0-9]{26} unless Apps Script is explicitly approved and operationally necessary.

Key takeaways

• Google Apps Script project impersonation is a cloud governance failure that lets attackers hide resources and identities inside apparently legitimate GCP structures.
• The key risk is persistence through non-human identities, especially service accounts that can survive longer than the initial project abuse.
• Blocking lookalike project IDs and correlating billing, logs and service usage are the controls that most directly limit this attack path.

Key terms

• Application Impersonation: Application impersonation occurs when an attacker uses an application credential to act as that application in authentication flows. In identity systems, this is dangerous because the attacker inherits the trust relationships attached to the application, which can extend to cloud services, data stores, and internal tools.
• Service-account persistence: The use of a cloud service account, often with keys or privileged bindings, as a long-lived foothold after initial access. Because the identity is non-human and can be embedded inside project infrastructure, it may remain active long after user-session indicators disappear.
• Control Plane Visibility: A governance pattern where the operational record for a system becomes the place where teams verify, diagnose, and account for access behaviour. For MCP, it means analytics must expose enough context to support both reliability work and identity governance.
• Billing-linked Abuse: Billing-linked abuse is the use of an organisation's payment relationship as a signal or enabler for malicious cloud activity. Attackers may attach paid resources to a project to run compute-heavy workloads, then try to hide behind normal billing relationships to delay detection and response.

Deepen your knowledge

NHI Mgmt Group covers identity security, NHI governance, and agentic AI through independent research, practitioner guides, and the NHI Foundation Level course, the industry's only accredited NHI security programme. It is designed for teams that need to govern service accounts, workload identity, and identity lifecycle risk across modern environments.