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

src/pentesting-cloud/aws-security/aws-post-exploitation/aws-ec2-ebs-ssm-and-vpc-post-exploitation/README.md

@@ -23,7 +23,7 @@ aws-malicious-vpc-mirror.md
 
 ### Laufende Instanz kopieren
 
-Instanzen enthalten normalerweise eine Art von sensiblen Informationen. Es gibt verschiedene Möglichkeiten, um Zugang zu erhalten (siehe [EC2 Privilegieneskalationstricks](../../aws-privilege-escalation/aws-ec2-privesc.md)). Eine andere Möglichkeit, um zu überprüfen, was sie enthält, besteht darin, **ein AMI zu erstellen und eine neue Instanz (sogar in Ihrem eigenen Konto) daraus zu starten**:
+Instanzen enthalten normalerweise eine Art von sensiblen Informationen. Es gibt verschiedene Möglichkeiten, um Zugang zu erhalten (siehe [EC2 Privilegieneskalationstricks](../../aws-privilege-escalation/aws-ec2-privesc.md)). Eine andere Möglichkeit, um zu überprüfen, was sie enthält, besteht darin, **eine AMI zu erstellen und eine neue Instanz (sogar in Ihrem eigenen Konto) daraus zu starten**:
 ```shell
 # List instances
 aws ec2 describe-images
@@ -47,7 +47,7 @@ aws ec2 modify-instance-attribute --instance-id "i-0546910a0c18725a1" --groups "
 aws ec2 stop-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1
 aws ec2 terminate-instances --instance-id "i-0546910a0c18725a1" --region eu-west-1
 ```
-### EBS Snapshot-Dump
+### EBS Snapshot dump
 
 **Snapshots sind Backups von Volumes**, die normalerweise **sensible Informationen** enthalten, daher sollte deren Überprüfung diese Informationen offenbaren.\
 Wenn Sie ein **Volume ohne Snapshot** finden, könnten Sie: **Einen Snapshot erstellen** und die folgenden Aktionen durchführen oder es einfach **in einer Instanz** innerhalb des Kontos **einbinden**:
@@ -56,9 +56,9 @@ Wenn Sie ein **Volume ohne Snapshot** finden, könnten Sie: **Einen Snapshot ers
 aws-ebs-snapshot-dump.md
 {{#endref}}
 
-### Datenexfiltration
+### Data Exfiltration
 
-#### DNS-Exfiltration
+#### DNS Exfiltration
 
 Selbst wenn Sie eine EC2 so absichern, dass kein Verkehr nach außen gelangen kann, kann sie dennoch **über DNS exfiltrieren**.
 
@@ -68,11 +68,11 @@ Selbst wenn Sie eine EC2 so absichern, dass kein Verkehr nach außen gelangen ka
 
 `aws ec2 modify-vpc-attribute --no-enable-dns-support --vpc-id <vpc-id>`
 
-#### Exfiltration über API-Aufrufe
+#### Exfiltration via API calls
 
 Ein Angreifer könnte API-Endpunkte eines von ihm kontrollierten Kontos aufrufen. Cloudtrail wird diese Aufrufe protokollieren und der Angreifer wird in der Lage sein, die exfiltrierten Daten in den Cloudtrail-Logs zu sehen.
 
-### Offene Sicherheitsgruppe
+### Open Security Group
 
 Sie könnten weiteren Zugriff auf Netzwerkdienste erhalten, indem Sie Ports wie folgt öffnen:
 ```bash
@@ -81,7 +81,7 @@ aws ec2 authorize-security-group-ingress --group-id <sg-id> --protocol tcp --por
 ```
 ### Privesc zu ECS
 
-Es ist möglich, eine EC2-Instanz auszuführen und sie zu registrieren, um ECS-Instanzen auszuführen, und dann die Daten der ECS-Instanzen zu stehlen.
+Es ist möglich, eine EC2-Instanz zu starten und sie zu registrieren, um ECS-Instanzen auszuführen, und dann die Daten der ECS-Instanzen zu stehlen.
 
 Für [**weitere Informationen siehe hier**](../../aws-privilege-escalation/aws-ec2-privesc.md#privesc-to-ecs).
 
@@ -180,7 +180,7 @@ aws ec2 modify-snapshot-attribute --snapshot-id <snapshot_ID> --create-volume-pe
 
 Ein Proof of Concept ähnlich der Ransomware-Demonstration, die in den S3-Post-Exploitation-Notizen gezeigt wurde. KMS sollte in RMS umbenannt werden, da es so einfach ist, verschiedene AWS-Dienste damit zu verschlüsseln.
 
-Zuerst aus einem 'Angreifer'-AWS-Konto, erstellen Sie einen kundenverwalteten Schlüssel in KMS. Für dieses Beispiel lassen wir AWS die Schlüsseldaten für mich verwalten, aber in einem realistischen Szenario würde ein böswilliger Akteur die Schlüsseldaten außerhalb der Kontrolle von AWS behalten. Ändern Sie die Schlüsselrichtlinie, um es jedem AWS-Konto-Principal zu ermöglichen, den Schlüssel zu verwenden. Für diese Schlüsselrichtlinie war der Name des Kontos 'AttackSim' und die Richtlinienregel, die den gesamten Zugriff erlaubt, heißt 'Outside Encryption'.
+Zuerst aus einem 'Angreifer'-AWS-Konto, erstellen Sie einen kundenverwalteten Schlüssel in KMS. Für dieses Beispiel lassen wir AWS die Schlüsseldaten für mich verwalten, aber in einem realistischen Szenario würde ein böswilliger Akteur die Schlüsseldaten außerhalb der Kontrolle von AWS behalten. Ändern Sie die Schlüsselrichtlinie, um es jedem AWS-Konto-Principal zu ermöglichen, den Schlüssel zu verwenden. Für diese Schlüsselrichtlinie war der Name des Kontos 'AttackSim' und die Richtlinienregel, die allen Zugriff erlaubt, heißt 'Outside Encryption'.
 ```
 {
 "Version": "2012-10-17",
@@ -272,7 +272,7 @@ Zuerst aus einem 'Angreifer'-AWS-Konto, erstellen Sie einen kundenverwalteten Sc
 ]
 }
 ```
-Die Schlüsselrichtlinienregel benötigt die folgenden Berechtigungen, um die Möglichkeit zu ermöglichen, ein EBS-Volume zu verschlüsseln:
+Die Schlüsselrichtlinienregel muss Folgendes aktiviert haben, um die Möglichkeit zu ermöglichen, ein EBS-Volume zu verschlüsseln:
 
 - `kms:CreateGrant`
 - `kms:Decrypt`

src/pentesting-cloud/gcp-security/gcp-privilege-escalation/gcp-cloudbuild-privesc.md

@@ -12,12 +12,12 @@ Für weitere Informationen zu Cloud Build siehe:
 
 ### `cloudbuild.builds.create`, `iam.serviceAccounts.actAs`
 
-Mit dieser Berechtigung können Sie **einen Cloud-Build einreichen**. Die Cloudbuild-Maschine hat standardmäßig ein **Token des Cloudbuild-Servicekontos** in ihrem Dateisystem: `<PROJECT_NUMBER>@cloudbuild.gserviceaccount.com`. Sie können jedoch **jedes Servicekonto im Projekt** in der Cloudbuild-Konfiguration angeben.\
-Daher können Sie die Maschine einfach dazu bringen, das Token an Ihren Server zu exfiltrieren oder **eine Reverse-Shell darin zu erhalten und sich das Token zu besorgen** (die Datei, die das Token enthält, könnte sich ändern).
+Mit dieser Berechtigung kannst du **einen Cloud Build einreichen**. Die Cloudbuild-Maschine wird standardmäßig in ihrem Dateisystem ein **Token des Cloudbuild-Servicekontos** haben: `<PROJECT_NUMBER>@cloudbuild.gserviceaccount.com`. Du kannst jedoch **jedes Servicekonto innerhalb des Projekts** in der Cloudbuild-Konfiguration angeben.\
+Daher kannst du die Maschine einfach dazu bringen, das Token an deinen Server zu exfiltrieren oder **einen Reverse-Shell innerhalb davon zu erhalten und dir das Token zu besorgen** (die Datei, die das Token enthält, könnte sich ändern).
 
 #### Direkte Ausnutzung über gcloud CLI
 
-1- Erstellen Sie `cloudbuild.yaml` und ändern Sie es mit Ihren Listener-Daten.
+1- Erstelle `cloudbuild.yaml` und modifiziere es mit deinen Listener-Daten.
 ```yaml
 steps:
 - name: bash