Sponsored

GCP - IAM Post Exploitation

IAM

You can find further information about IAM in:

GCP - IAM, Principals & Org Policies Enum

Granting access to management console

Access to the GCP management console is provided to user accounts, not service accounts: service accounts cannot be used for browser-based sign-in. To log in to the web interface, you can grant access to a Google account that you control. This can be a generic "@gmail.com" account, and it does not have to be a member of the target organization.[1][2][3]

To grant the primitive role of Owner to a generic "@gmail.com" account, though, you'll need to use the web console. For this external-user workflow, gcloud cannot grant a role above the primitive Editor role; the documented Owner exception must be handled in the console.[3]

You can use the following command to grant a user the primitive role of Editor to your existing project:[4]

gcloud projects add-iam-policy-binding [PROJECT] --member user:[EMAIL] --role roles/editor

If you succeeded here, try accessing the web interface and exploring from there.

For this external-user workflow, Editor is the highest primitive role you can assign using the gcloud tool; Owner is the console-only exception.[3][4]

Delete IAM components iam.*.delete

The iam.*.delete permissions (e.g., iam.roles.delete, iam.serviceAccountApiKeyBindings.delete, iam.serviceAccountKeys.delete, etc.) allow an identity to delete critical IAM components such as custom roles, API key bindings, service account keys, and the service accounts themselves. Deleting a service account removes workload access, while deleting a key permanently prevents that key from authenticating; an attacker could therefore remove legitimate access mechanisms and cause a denial of service.[5][7][10]

To carry out such an attack, it is possible, for example, to delete roles using:[6]

gcloud iam roles delete <ROLE_ID> --project=<PROJECT_ID>

iam.serviceAccountKeys.disable || iam.serviceAccounts.disable

The iam.serviceAccountKeys.disable and iam.serviceAccounts.disable permissions allow disabling active service account keys or service accounts. Disabling a key prevents authentication with that key but does not revoke short-lived credentials already issued; disabling the service account causes credential generation and API requests using it to fail. In the hands of an attacker, these operations could disrupt operations, cause denial of service, or hinder incident response by preventing the use of legitimate credentials.[5][8][9]

To disable a Service Account, you can use the following command:[9]

gcloud iam service-accounts disable <SA_EMAIL> --project=<PROJECT_ID>

To disable the keys of a Service Account, you can use the following command:[8]

gcloud iam service-accounts keys disable <KEY_ID> --iam-account=<SA_EMAIL>

iam.*.undelete

The iam.*.undelete permissions allow restoring previously deleted elements such as API key bindings, custom roles, or service accounts. Google documents iam.roles.undelete, iam.serviceAccountApiKeyBindings.undelete, and iam.serviceAccounts.undelete as distinct permissions; in the hands of an attacker, these can reverse defensive actions (recover removed access), re-establish deleted compromise vectors to maintain persistence, or evade remediation efforts, complicating incident containment.[5][10][11]

The service-account command restores a deleted account by its unique ID:[12]

gcloud iam service-accounts undelete "${SA_ID}" --project="${PROJECT}"

References

[!TIP] Learn & practice AWS Hacking:HackTricks Training AWS Red Team Expert (ARTE)
Learn & practice GCP Hacking: HackTricks Training GCP Red Team Expert (GRTE)
Learn & practice Az Hacking: HackTricks Training Azure Red Team Expert (AzRTE)
Browse the full HackTricks Training catalog.

Support HackTricks
Sponsored