Event Information
-
What it is:
resourcemanager.organizations.setIamPolicyis an Admin API call that replaces the IAM policy on an entire GCP organization resource (not incremental). It’s typically invoked viagcloud organizations set-iam-policy, REST API, or through tools that manage org-level IAM. -
Security / GCPIAM impact: This event means someone or something has rewritten the org-level IAM policy, potentially adding/removing org-wide roles and members. It can:
- Grant or revoke powerful roles (e.g.,
roles/owner,roles/resourcemanager.organizationAdmin) across all projects/folders. - Introduce risky principals (e.g.,
allUsers, external domains), affecting least-privilege and segregation-of-duties.
- Grant or revoke powerful roles (e.g.,
-
Compliance / practical actions:
- Treat as high-sensitivity; log, alert, and review every occurrence for SOX/PCI-DSS/ISO 27001 evidence.
- Compare before/after IAM policies (use Cloud Logging and version control) to detect privilege escalation or policy drift.
- Restrict who can call this API (via
resourcemanager.organizations.setIamPolicypermission) to a small break-glass/admin group and enforce approvals via change management.
Examples
-
Organization-level privilege escalation
- An attacker sets an overly permissive policy (e.g.,
roles/ownerorroles/resourcemanager.organizationAdmin) for their account or a compromised service account at the organization level, gaining full control over all projects and folders. - Violates least-privilege and separation-of-duties expectations in ISO 27001, SOC 2, and CIS GCP benchmarks.
- An attacker sets an overly permissive policy (e.g.,
-
Bypassing security & compliance controls
setIamPolicyis used to remove or weaken bindings forroles/orgPolicyPolicyAdmin,roles/securityAdmin, orroles/loggingAdmin, preventing security teams from enforcing org policies, SCC findings, and centralized logging.- Can break controls required by PCI DSS and HIPAA around centralized monitoring, auditability, and configuration hardening.
-
Persistence and data exfiltration path
- A malicious actor adds a broad group (e.g.,
allAuthenticatedUsersor an external domain group) to roles likeroles/resourcemanager.projectCreatoror high-privilege custom roles at org level, enabling creation of shadow projects or access paths for data exfiltration. - Conflicts with identity governance and access control requirements in NIST 800-53 (AC-2, AC-6) and CIS GCP controls.
- A malicious actor adds a broad group (e.g.,
Remediation
Using Console
-
Containment & investigation (Org-level escalation)
- In GCP Console, go to IAM & Admin → IAM, set the Scope selector (top bar) to your Organization.
- Sort by Role and look for any principals with Owner,
roles/resourcemanager.organizationAdmin, or other highly privileged custom roles. - For each suspicious principal:
- Click the pencil icon → Remove high-privilege roles → Save.
- If the account is compromised (user/service account): in IAM & Admin → Service Accounts or Admin Console (for users), disable it and rotate all related keys/secrets.
- In IAM & Admin → Audit Logs and Cloud Logging, filter on
protoPayload.methodName="SetIamPolicy"andresource.type="organization"to identify when/where the escalation occurred; preserve logs for compliance (ISO 27001 A.12, SOC 2 CC7, CIS GCP).
-
Restore and harden security/compliance controls (securityAdmin/orgPolicy/logging)
- In IAM & Admin → IAM (scope: Organization), verify correct bindings for:
roles/orgPolicyPolicyAdmin(or tightly scoped policy admin)roles/securityAdmin(or SCC/security team roles)roles/loggingAdmin/roles/loggingConfigWriter(for centralized logs)
- Re-add legitimate security/compliance groups (e.g.,
secops@,compliance@) to these roles at Org level: Grant access → Add principal → Select role → Save; ensure no unapproved principals retain these roles. - In Organization policies (IAM & Admin → Organization policies), review and re-enable critical policies (e.g., domain restriction, disable service account key creation); validate logging sinks in Logging → Log Router still send all ADMIN_READ / DATA_ACCESS logs to central SIEM for PCI DSS/HIPAA auditability.
- In IAM & Admin → IAM (scope: Organization), verify correct bindings for:
-
Remove persistence paths & enforce least privilege (projectCreator/shadow projects)
- In IAM & Admin → IAM (scope: Organization), search for principals such as
allUsers,allAuthenticatedUsers, external domains, or broad groups on:roles/resourcemanager.projectCreator- Any high-privilege custom roles or roles that can create projects/folders/service accounts.
- For any broad or external principals: Edit principal → Remove these roles at org level → Save; replace with tightly scoped internal groups as needed (per NIST 800-53 AC-2/AC-6, CIS GCP).
- In IAM & Admin → Folders and Manage Resources, list projects/folders recently created; for suspicious “shadow” projects, remove IAM bindings, disable APIs, and, if confirmed malicious, shut them down (select project → Shut down) after exporting required logs/evidence.
- In IAM & Admin → IAM (scope: Organization), search for principals such as
Using CLI
-
Immediate containment & rollback of org-level IAM escalation
- Identify and revoke unauthorized org-level bindings (including
roles/owner,roles/resourcemanager.organizationAdmin, broad groups) and re‑apply baseline access: - Enumerate and clean up shadow access paths (project creators, custom roles, external groups):
- Identify and revoke unauthorized org-level bindings (including
-
Restore and lock down security/compliance control roles (Security Admin, Org Policy, Logging)
- Re‑grant required roles only to tightly controlled security groups, and verify no weakened bindings:
- Enforce constraints to prevent future org‑level privilege escalation and bypass of security controls (aligns with ISO 27001, SOC 2, PCI DSS, HIPAA, NIST 800‑53, CIS GCP):
- Re‑grant required roles only to tightly controlled security groups, and verify no weakened bindings:
-
Detection, monitoring, and long‑term hardening
- Review Cloud Audit Logs for
SetIamPolicyon the organization and security‑sensitive roles, and enable high‑severity alerts: - Implement continuous controls to meet CIS GCP, NIST AC‑2/AC‑6:
- Require approval workflows and break‑glass processes for org‑level roles (via IAM Conditions, Cloud Functions / Cloud Workflows + security ticketing).
- Regularly export and baseline‑compare org IAM and org policies with CI/CD or compliance tooling to detect unauthorized changes.
- Review Cloud Audit Logs for
Using Python
-
Identify and contain org-level IAM abuse
-
Enumerate and review all org-level bindings, focusing on
roles/owner,roles/resourcemanager.organizationAdmin,roles/resourcemanager.projectCreator, custom high-privilege roles, and security roles (roles/orgPolicyPolicyAdmin,roles/securityAdmin,roles/loggingAdmin), then immediately remove or narrow any non-approved principals and rotate credentials for compromised accounts. -
Example Python (Cloud Resource Manager v1) to list and then clean risky bindings (ensure
ORGANIZATION_IDandALLOWED_PRINCIPALSreflect your policies and approval list):
-
Enumerate and review all org-level bindings, focusing on
-
Reinstate security/compliance guardrails and monitoring
-
Re-add or validate bindings so that only dedicated security/compliance groups hold
roles/orgPolicyPolicyAdmin,roles/securityAdmin,roles/loggingAdmin, androles/accessContextManager.policyAdmin, and ensure audit logs (Admin, Data Access, Policy Denied) are enabled org-wide; configure log sinks locked to a security project to meet PCI DSS / HIPAA centralized logging. -
Example: Python to ensure security teams have required roles (idempotent “ensure-binding” pattern):
-
Re-add or validate bindings so that only dedicated security/compliance groups hold
-
Prevent persistence / re-escalation and align with least-privilege controls
-
Remove broad identities like
allAuthenticatedUsers, external domains, or unapproved groups from org-level high-privilege roles and especially fromroles/resourcemanager.projectCreator; replace them with tightly controlled groups, enable Org Policy constraints (constraints/iam.allowedPolicyMemberDomains,constraints/iam.disableServiceAccountKeyCreation,constraints/compute.disableSerialPortAccess), and require approvals for org-level IAM changes (change management to align with ISO 27001, SOC 2, NIST 800-53 AC-2/AC-6). -
Example: Python snippet to specifically harden
roles/resourcemanager.projectCreatorand strip public/external members to reduce “shadow project” risk:
-
Remove broad identities like

