# GCP - IAM Post Exploitation

{{#include ../../../banners/hacktricks-training.md}}

## IAM <a href="#service-account-impersonation" id="service-account-impersonation"></a>

You can find further information about IAM in:

{{#ref}}
../gcp-services/gcp-iam-and-org-policies-enum.md
{{#endref}}

### Granting access to management console <a href="#granting-access-to-management-console" id="granting-access-to-management-console"></a>

Access to the [GCP management console](https://console.cloud.google.com) is **provided to user accounts, not service accounts**. 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, it does **not have to be a member of the target organization**.

To **grant** the primitive role of **Owner** to a generic "@gmail.com" account, though, you'll need to **use the web console**. `gcloud` will error out if you try to grant it a permission above Editor.

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

```bash
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.

This is the **highest level you can assign using the gcloud tool**.

### 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. In the hands of an attacker, this makes it possible to remove legitimate access mechanisms in order to cause a denial of service.

To carry out such an attack, it is possible, for example, to delete roles using:
```bash
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, which in the hands of an attacker could be used to disrupt operations, cause denial of service, or hinder incident response by preventing the use of legitimate credentials.

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

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

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

```bash
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. In the hands of an attacker, this can be used to reverse defensive actions (recover removed access), re-establish deleted compromise vectors to maintain persistence, or evade remediation efforts, complicating incident containment.

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

{{#include ../../../banners/hacktricks-training.md}}



