Hi @rakesh.shrestha Sorry you are experiencing this. Unfortunately you have come to the incorrect community. This forum is for specific questions and topics related to Google Security Operations.
Here’s what I found online for you.
In "Hijacked Resource" cases, the UI is often locked to prevent the attacker from doing further damage, but programmatic access via the Cloud SDK (gcloud) sometimes remains partially functional for administrative cleanup.
Programmatic Revocation via CLI
If your local credentials still have administrative permissions, you can bypass the Console UI entirely using the gcloud CLI.
To List and Delete API Keys:
First, ensure you are authenticated and pointing to the correct project: gcloud config set project [PROJECT_ID]
To list all keys: gcloud services api-keys list
To delete a specific key: gcloud services api-keys delete [KEY_ID]
To Disable Service Account Keys:
If a Service Account was compromised, you should disable its keys rather than just deleting them, to preserve audit trails while stopping the "leak." gcloud iam service-accounts keys disable [KEY_ID] --iam-account=[SA_NAME]@[PROJECT_ID].iam.gserviceaccount.com
Log Retrieval & Investigation
Since the UI redirect is blocking Cloud Logging, you can attempt to pull logs to your local machine to find the "abusive" IP addresses or actions.
To export recent Activity Logs: gcloud logging read "resource.type=project AND severity>=INFO" --limit=50 --format="table(timestamp, protoPayload.methodName, protoPayload.callerIp)"
To check for unauthorized instances (common in hijacking for mining): gcloud compute instances list
If you see resources you didn't create, delete them immediately via CLI: gcloud compute instances delete [INSTANCE_NAME] --zone=[ZONE]
The "Proof of Remediation" Strategy
When the Trust & Safety team reviews your appeal, they aren't just looking for a "fixed" project; they are looking for evidence of a changed security posture.
Since you are blocked from the UI, your appeal should include a Log of Actions Taken via CLI.
What to include in your reply to the appeal email:
-
Command Output: Paste the output showing that keys have been deleted or disabled (mask sensitive IDs).
-
The "Clean" Declaration: Explicitly state: "I have performed remediation via gcloud CLI because the Console UI is inaccessible due to the redirect loop."
-
Specific Identification: Identify the source of the leak (e.g., "Found unauthorized Compute Engine usage in region us-east1").
Breaking the Redirect Loop (Last Resort)
Sometimes, the redirect is cached or triggered by a specific entry URL. Try the following to see if you can "sneak" into a sub-page:
-
Direct Policy Link: Try navigating directly to https://console.cloud.google.com/iam-admin/quotas. Sometimes quota pages aren't as strictly redirected and allow you to see where the "abuse" (high usage) is happening.
-
Incognito Mode: Ensure a stale "Suspended" cookie isn't forcing the redirect even if the status has partially changed.
Why you haven't heard back:
Trust & Safety queues are currently prioritized by the severity of the hijack. If the "abusive activity" (like outbound DDoS or crypto-mining) is still technically running because the keys weren't deleted, the appeal will likely be postponed. Prioritize the CLI deletions first, then send a follow-up email to your appeal confirmation stating that all compromised vectors have been closed.
