Google Apps Script impersonation creates stealthy GCP persistence

At a glance

What this is: This is an analysis of how Google Apps Script project impersonation can be abused to hide GCP resources, service accounts, and persistence mechanisms.

Why it matters: It matters because IAM and cloud security teams need to treat project identity, service-account ownership, and billing state as governance signals, not just administrative details, when hunting 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.

👉 Read Exaforce's analysis of Google Apps Script impersonation and stealthy persistence

Context

Google Apps Script is a legitimate automation feature, but in cloud terms it also creates a hidden identity and project-management surface that defenders may not inspect consistently. In this case, the primary risk is not code execution in the abstract, but the ability to make a malicious GCP project look like a benign Apps Script project and use that appearance to persist unnoticed. The primary keyword here is Google Apps Script impersonation, and it matters because naming and visibility controls become part of access governance.

For IAM and cloud security teams, this is a reminder that non-human identity governance extends beyond secrets and service accounts into project lifecycle, billing linkage, and policy enforcement. If an attacker can create a project, hide it from normal console views, and attach privileged identities or resources, the control gap is partly organisational: the environment is trusting metadata that can be imitated. That is a common cloud governance blind spot, not an edge case.

Key questions

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. Attackers can hide resources, create service accounts, and maintain persistence inside projects that look managed. The result is slower detection, harder cleanup, and a higher chance that privileged activity is mistaken for legitimate automation.

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. In sovereign cloud, that creates a gap between jurisdictional intent and operational reality. Service accounts, tokens, and AI agents can outlive their purpose unless lifecycle controls are explicit and enforced.

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. A project that exists but does not fit the organisation’s approved automation pattern deserves investigation, even if the workload itself looks benign.

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.

Technical breakdown

How Apps Script projects map to hidden GCP resources

Google Apps Script projects are backed by normal GCP projects, but their lifecycle and presentation differ from standard organisation projects. In the article’s example, the created project gets a sys- prefix and can reside in a folder structure that is not obvious in console views. That matters because visibility is not the same as existence. A project can be present in Cloud Resource Manager and still remain practically invisible to operators who rely on the console alone. The abuse path is simple: create or mimic the project shape, place resources inside it, and use that surface for persistence or compute.

Practical implication: inventory project creation paths and enumerate hidden folders with Cloud Resource Manager, not just console views.

Why project impersonation helps persistence and cryptomining

The impersonation technique works because defenders often trust the project’s external appearance more than its actual policy state. Once an attacker controls a lookalike project, they can attach billing, enable services, create compute, and add service accounts or keys for return access. The key idea is that persistence in cloud environments often sits in the management plane rather than the workload itself. A hidden project can host both paid resources, such as large instances, and cheaper persistence artefacts, such as service accounts, making cleanup harder and detection noisier.

Practical implication: treat project metadata, billing linkage, and service-account creation as persistence indicators in cloud detection logic.

How detection breaks when attackers blend into normal admin activity

The article shows several detection pivots, including billing account attachment, enabled APIs, and folder-level logs. Each one helps only if defenders understand what legitimate Apps Script projects normally look like. That is the core lesson: behavioural baselining must be tied to the identity and lifecycle of cloud artefacts, not just to resource activity. If a project is expected to be service-light, billing-free, and created by a Google-managed principal, then a user-created lookalike with enabled compute is a strong anomaly. If those baselines are missing, attackers can disable or re-enable services to reduce the signal.

Practical implication: baseline legitimate Apps Script characteristics and alert on deviations in principal, service state, and billing behaviour.

Threat narrative

Attacker objective: The attacker wants a hidden foothold in the cloud organisation that survives ordinary review and supports either monetisation or future access.

1. Entry occurs when an attacker creates or impersonates a project with a sys- style identifier inside a target Google Cloud organisation.
2. Credential and access abuse follows when the attacker uses project permissions, billing linkage, or service-account creation to establish control and persistence.
3. Impact occurs when the hidden project is used to host cryptomining, maintain privileged access, or evade cleanup by blending into trusted automation patterns.

NHI Mgmt Group analysis

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.

Non-human identity control extends into the cloud control plane. This is an NHI issue because service accounts, project-scoped permissions, and API enablement are the mechanisms that let the impostor persist. The article reinforces a pattern NHIMG sees repeatedly: the identity layer is often trusted after the project layer has already been compromised. The practical conclusion is that service-account governance, project creation policy, and privileged API monitoring must be managed together.

Hidden-project persistence is a specific failure mode of trust-by-default cloud administration. The nameable concept here is project-identity mimicry: when an attacker copies the observable shape of a legitimate automation project to suppress scrutiny. That concept matters because many cloud controls still key off whether a project looks normal, rather than whether it was created, managed, and authorised through an expected path. Practitioners should stop assuming naming conventions provide assurance.

Cloud attack surface reduction depends on policy constraints, not just better triage. The article’s deny-policy example is a useful reminder that prevention works best when the risky creation pattern is restricted up front. Where an organisation does not use Apps Script, allowing sys-[0-9]{26} style project creation expands the attack surface without business value. The broader lesson for identity and cloud governance teams is to remove entire classes of impersonation paths where they are not required.

Visibility into NHI behaviour must include resource lineage and ownership context. Service accounts are not dangerous only when they are over-privileged; they are also dangerous when they are attached to artefacts that defenders do not recognise as owned infrastructure. That is why hidden project abuse is a useful case study for NHI governance. It shows that lineage, provenance, and control ownership are as important as the credential itself.

What this signals

Project-identity mimicry is the operational lesson from this research: attackers increasingly abuse the management plane’s trust in naming, placement, and ownership signals. That shifts the defender’s job from simple anomaly hunting to provenance checking, where a hidden project is suspicious because of how it came into existence, not only because of what it runs.

For IAM and cloud security teams, the practical change is to treat project creation, billing attachment, and service-account binding as part of identity governance. External baselines such as the NIST Cybersecurity Framework 2.0 help structure this work, but the decisive control remains whether the organisation can prove a project is expected, owned, and lifecycle-managed. In other words, hidden infrastructure is a governance failure before it becomes a detection event.

For practitioners

• 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. Use organisation policy so the restriction is enforced before a hidden project can be populated with resources.
• 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. Alert on deviations in principalEmail, enabled services, and project location.
• 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. Review these events as potential persistence, not routine administration.
• Correlate billing, API, and log signals Join billingAccountName, billingEnabled, Resource Manager folder events, and API enablement state to determine whether a project is legitimate or an impersonation. This reduces false assumptions based on console visibility alone.

Key takeaways

• Google Apps Script impersonation turns cloud project naming and placement into a persistence risk, because attackers can hide normal-looking resources inside a trusted GCP structure.
• The article shows that billing linkage, API enablement, and service-account creation are not admin trivia, they are practical indicators of hidden-project abuse and long-lived access.
• Where Apps Script is unnecessary, blocking sys-style project creation and tightening project lifecycle governance reduces the attack surface more effectively than relying on console visibility alone.

Key terms

• Google Apps Script impersonation: A tactic in which an attacker creates or shapes a GCP project to resemble a legitimate Apps Script project. The goal is to exploit trust in Google-managed automation patterns so the project, its resources, and its identities draw less scrutiny than normal infrastructure.
• Project-identity mimicry: The practice of copying the visible form of a legitimate cloud project so it appears routine to operators and automated checks. In identity governance terms, it is a provenance problem, because the object may look valid while having an unauthorised origin and intent.
• Stealthy persistence: A persistence method designed to survive ordinary review by blending into expected administrative or platform behaviour. In cloud environments, it often relies on hidden projects, service accounts, or policy artefacts that remain available even after the initial compromise is noticed.
• 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.

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.

👉 Exaforce's full post covers the attack path, detection signals, and preventive policy pattern in detail.

Deepen your knowledge

NHI Foundation Level course, the industry's only accredited NHI security programme, covers NHI governance, machine identity security, and secrets management in a way that supports practitioners responsible for cloud and identity control decisions. It helps security teams translate identity principles into lifecycle and access governance across modern environments.