mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2025-12-30 22:50:43 -08:00
Translated ['src/banners/hacktricks-training.md', 'src/pentesting-ci-cd/
This commit is contained in:
Translator
@@ -21,7 +21,7 @@ Oder entfernen Sie einfach die Verwendung des Authorizers.
|
||||
|
||||
### IAM-Berechtigungen
|
||||
|
||||
Wenn eine Ressource IAM-Authorizer verwendet, könnten Sie sich Zugriff gewähren, indem Sie die IAM-Berechtigungen ändern.\
|
||||
Wenn eine Ressource IAM-Authorizer verwendet, könnten Sie sich selbst Zugriff gewähren, indem Sie die IAM-Berechtigungen ändern.\
|
||||
Oder entfernen Sie einfach die Verwendung des Authorizers.
|
||||
|
||||
### API-Schlüssel
|
||||
|
||||
@@ -38,7 +38,7 @@ Um die Persistenz aufrechtzuerhalten, kann der Angreifer Elemente in der DynamoD
|
||||
|
||||
### DynamoDB als C2-Kanal
|
||||
|
||||
Ein Angreifer kann eine DynamoDB-Tabelle als **Befehls- und Kontrollkanal (C2)** verwenden, indem er Elemente erstellt, die Befehle enthalten, und kompromittierte Instanzen oder Lambda-Funktionen nutzt, um diese Befehle abzurufen und auszuführen.
|
||||
Ein Angreifer kann eine DynamoDB-Tabelle als **Command and Control (C2) Kanal** verwenden, indem er Elemente erstellt, die Befehle enthalten, und kompromittierte Instanzen oder Lambda-Funktionen nutzt, um diese Befehle abzurufen und auszuführen.
|
||||
```bash
|
||||
# Create a DynamoDB table for C2
|
||||
aws dynamodb create-table \
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - EC2 Persistence
|
||||
# AWS - EC2 Persistenz
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,11 +10,11 @@ Für weitere Informationen siehe:
|
||||
../aws-services/aws-ec2-ebs-elb-ssm-vpc-and-vpn-enum/
|
||||
{{#endref}}
|
||||
|
||||
### Sicherheit Gruppenverbindungsverfolgung Persistenz
|
||||
### Persistenz durch Verbindungsverfolgung der Sicherheitsgruppe
|
||||
|
||||
Wenn ein Verteidiger feststellt, dass eine **EC2-Instanz kompromittiert wurde**, wird er wahrscheinlich versuchen, das **Netzwerk** der Maschine zu **isolieren**. Er könnte dies mit einem expliziten **Deny NACL** tun (aber NACLs betreffen das gesamte Subnetz) oder **die Sicherheitsgruppe ändern**, um **keinen eingehenden oder ausgehenden** Verkehr zuzulassen.
|
||||
Wenn ein Verteidiger feststellt, dass eine **EC2-Instanz kompromittiert wurde**, wird er wahrscheinlich versuchen, das **Netzwerk** der Maschine zu **isolieren**. Er könnte dies mit einem expliziten **Deny NACL** tun (aber NACLs betreffen das gesamte Subnetz) oder **die Sicherheitsgruppe ändern**, um **jeglichen eingehenden oder ausgehenden** Verkehr zu verhindern.
|
||||
|
||||
Wenn der Angreifer eine **Reverse Shell von der Maschine** hatte, wird die **Verbindung nicht beendet**, selbst wenn die SG geändert wird, um keinen eingehenden oder ausgehenden Verkehr zuzulassen, aufgrund von [**Sicherheitsgruppenverbindungsverfolgung**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
|
||||
Wenn der Angreifer eine **Reverse Shell von der Maschine** hatte, wird die **Verbindung nicht beendet**, selbst wenn die SG geändert wird, um keinen eingehenden oder ausgehenden Verkehr zuzulassen, aufgrund von [**Security Group Connection Tracking**](https://docs.aws.amazon.com/AWSEC2/latest/UserGuide/security-group-connection-tracking.html)**.**
|
||||
|
||||
### EC2 Lifecycle Manager
|
||||
|
||||
@@ -23,25 +23,25 @@ Ein Angreifer könnte die **Generierung von AMIs oder Snapshots** aller Images o
|
||||
|
||||
### Geplante Instanzen
|
||||
|
||||
Es ist möglich, Instanzen täglich, wöchentlich oder sogar monatlich zu planen. Ein Angreifer könnte eine Maschine mit hohen Rechten oder interessantem Zugriff betreiben, auf die er zugreifen könnte.
|
||||
Es ist möglich, Instanzen täglich, wöchentlich oder sogar monatlich zu planen. Ein Angreifer könnte eine Maschine mit hohen Berechtigungen oder interessantem Zugriff betreiben, auf die er zugreifen könnte.
|
||||
|
||||
### Spot Fleet Anfrage
|
||||
|
||||
Spot-Instanzen sind **günstiger** als reguläre Instanzen. Ein Angreifer könnte eine **kleine Spot-Fleet-Anfrage für 5 Jahre** (zum Beispiel) mit **automatischer IP**-Zuweisung und **Benutzerdaten**, die an den Angreifer **sendet, wenn die Spot-Instanz startet** und die **IP-Adresse** mit einer **hochprivilegierten IAM-Rolle**.
|
||||
Spot-Instanzen sind **günstiger** als reguläre Instanzen. Ein Angreifer könnte eine **kleine Spot Fleet Anfrage für 5 Jahre** (zum Beispiel) starten, mit **automatischer IP**-Zuweisung und **Benutzerdaten**, die an den Angreifer **sendet, wenn die Spot-Instanz startet** und die **IP-Adresse** sowie mit einer **hochprivilegierten IAM-Rolle**.
|
||||
|
||||
### Hintertür-Instanzen
|
||||
### Backdoor-Instanzen
|
||||
|
||||
Ein Angreifer könnte Zugriff auf die Instanzen erhalten und sie mit Hintertüren versehen:
|
||||
Ein Angreifer könnte Zugriff auf die Instanzen erhalten und sie mit einer Hintertür versehen:
|
||||
|
||||
- Verwendung eines traditionellen **Rootkits** zum Beispiel
|
||||
- Hinzufügen eines neuen **öffentlichen SSH-Schlüssels** (siehe [EC2 Privilegieneskalationsoptionen](../aws-privilege-escalation/aws-ec2-privesc.md))
|
||||
- Hinzufügen eines neuen **öffentlichen SSH-Schlüssels** (siehe [EC2 privesc Optionen](../aws-privilege-escalation/aws-ec2-privesc.md))
|
||||
- Hintertür in den **Benutzerdaten**
|
||||
|
||||
### **Hintertür Startkonfiguration**
|
||||
### **Hintertür-Startkonfiguration**
|
||||
|
||||
- Hintertür das verwendete AMI
|
||||
- Hintertür die Benutzerdaten
|
||||
- Hintertür das Schlüsselpaar
|
||||
- Hintertür in das verwendete AMI
|
||||
- Hintertür in die Benutzerdaten
|
||||
- Hintertür im Schlüsselpaar
|
||||
|
||||
### VPN
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - ECR Persistence
|
||||
# AWS - ECR Persistenz
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,7 +12,7 @@ Für weitere Informationen siehe:
|
||||
|
||||
### Verstecktes Docker-Image mit bösartigem Code
|
||||
|
||||
Ein Angreifer könnte **ein Docker-Image mit bösartigem Code** in ein ECR-Repository hochladen und es verwenden, um Persistenz im Ziel-AWS-Konto aufrechtzuerhalten. Der Angreifer könnte dann das bösartige Image auf verschiedene Dienste innerhalb des Kontos, wie Amazon ECS oder EKS, auf heimliche Weise bereitstellen.
|
||||
Ein Angreifer könnte **ein Docker-Image mit bösartigem Code** in ein ECR-Repository hochladen und es verwenden, um Persistenz im Ziel-AWS-Konto aufrechtzuerhalten. Der Angreifer könnte dann das bösartige Image auf verschiedene Dienste innerhalb des Kontos, wie Amazon ECS oder EKS, auf stealthy Weise bereitstellen.
|
||||
|
||||
### Repository-Richtlinie
|
||||
|
||||
@@ -41,11 +41,11 @@ aws ecr set-repository-policy \
|
||||
}
|
||||
```
|
||||
> [!WARNING]
|
||||
> Beachten Sie, dass ECR erfordert, dass Benutzer **Berechtigungen** haben, um über eine IAM-Richtlinie **`ecr:GetAuthorizationToken`** API-Aufrufe zu tätigen, **bevor sie sich** bei einem Registry authentifizieren und Bilder aus einem Amazon ECR-Repository pushen oder pullen können.
|
||||
> Beachten Sie, dass ECR erfordert, dass Benutzer **Berechtigungen** haben, um Aufrufe an die **`ecr:GetAuthorizationToken`** API über eine IAM-Richtlinie **zu tätigen, bevor sie sich** bei einem Registry authentifizieren und Bilder aus einem Amazon ECR-Repository pushen oder pullen können.
|
||||
|
||||
### Registry-Richtlinie & Cross-Account-Replikation
|
||||
|
||||
Es ist möglich, eine Registry in einem externen Konto automatisch zu replizieren, indem Sie die Cross-Account-Replikation konfigurieren, bei der Sie **das externe Konto** angeben müssen, in dem Sie die Registry replizieren möchten.
|
||||
Es ist möglich, eine Registry in einem externen Konto automatisch zu replizieren, indem man die Cross-Account-Replikation konfiguriert, wobei Sie **das externe Konto angeben** müssen, in dem Sie die Registry replizieren möchten.
|
||||
|
||||
<figure><img src="../../../images/image (79).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - ECS Persistence
|
||||
# AWS - ECS Persistenz
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -44,7 +44,7 @@ aws events put-targets --rule "malicious-ecs-task-rule" --targets '[
|
||||
}
|
||||
]'
|
||||
```
|
||||
### Backdoor-Container in einer bestehenden ECS-Task-Definition
|
||||
### Backdoor-Container in bestehender ECS-Task-Definition
|
||||
|
||||
> [!NOTE]
|
||||
> TODO: Test
|
||||
|
||||
@@ -12,10 +12,10 @@ Für weitere Informationen siehe:
|
||||
|
||||
### Ressourcenschutzrichtlinie / Sicherheitsgruppen ändern
|
||||
|
||||
Durch das Ändern der **Ressourcenschutzrichtlinie und/oder Sicherheitsgruppen** kannst du versuchen, deinen Zugriff auf das Dateisystem aufrechtzuerhalten.
|
||||
Durch das Ändern der **Ressourcenschutzrichtlinie und/oder Sicherheitsgruppen** können Sie versuchen, Ihren Zugriff auf das Dateisystem aufrechtzuerhalten.
|
||||
|
||||
### Zugriffspunkt erstellen
|
||||
|
||||
Du könntest **einen Zugriffspunkt erstellen** (mit Root-Zugriff auf `/`), der von einem Dienst aus zugänglich ist, bei dem du **andere Persistenz** implementiert hast, um privilegierten Zugriff auf das Dateisystem zu behalten.
|
||||
Sie könnten **einen Zugriffspunkt erstellen** (mit Root-Zugriff auf `/`), der von einem Dienst aus zugänglich ist, bei dem Sie **andere Persistenz** implementiert haben, um privilegierten Zugriff auf das Dateisystem zu behalten.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,7 +12,7 @@ Für weitere Informationen siehe:
|
||||
|
||||
### Persistenz in der Instanz
|
||||
|
||||
Um die Persistenz im AWS-Konto aufrechtzuerhalten, könnten einige **Persistenzmechanismen in der Instanz eingeführt werden** (Cron-Job, SSH-Schlüssel...), sodass der Angreifer darauf zugreifen und IAM-Rollen **Anmeldeinformationen aus dem Metadatenservice stehlen** kann.
|
||||
Um die Persistenz im AWS-Konto aufrechtzuerhalten, könnten einige **Persistenzmechanismen innerhalb der Instanz eingeführt werden** (Cron-Job, SSH-Schlüssel...), sodass der Angreifer darauf zugreifen und IAM-Rollen **Anmeldeinformationen aus dem Metadatenservice stehlen** kann.
|
||||
|
||||
### Hintertür in der Version
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - IAM Persistence
|
||||
# AWS - IAM Persistenz
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,7 +10,7 @@ Für weitere Informationen zugreifen:
|
||||
../aws-services/aws-iam-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Häufige IAM-Persistenz
|
||||
### Häufige IAM Persistenz
|
||||
|
||||
- Erstellen Sie einen Benutzer
|
||||
- Fügen Sie einen kontrollierten Benutzer einer privilegierten Gruppe hinzu
|
||||
@@ -38,7 +38,7 @@ Sie könnten eine Vertrauensrichtlinie hinterlegen, um sie für eine von Ihnen k
|
||||
```
|
||||
### Backdoor-Policy-Version
|
||||
|
||||
Geben Sie Administratorberechtigungen für eine Richtlinie in nicht ihrer letzten Version (die letzte Version sollte legitim aussehen), und weisen Sie dann diese Version der Richtlinie einem kontrollierten Benutzer/einer kontrollierten Gruppe zu.
|
||||
Geben Sie Administratorberechtigungen an eine Richtlinie in nicht ihrer letzten Version (die letzte Version sollte legitim aussehen), und weisen Sie diese Version der Richtlinie einem kontrollierten Benutzer/einer kontrollierten Gruppe zu.
|
||||
|
||||
### Backdoor / Identitätsanbieter erstellen
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - KMS Persistence
|
||||
# AWS - KMS Persistenz
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,15 +12,15 @@ Für weitere Informationen siehe:
|
||||
|
||||
### Zugriff über KMS-Richtlinien gewähren
|
||||
|
||||
Ein Angreifer könnte die Berechtigung **`kms:PutKeyPolicy`** verwenden, um einem Benutzer unter seiner Kontrolle oder sogar einem externen Konto **Zugriff** auf einen Schlüssel zu **gewähren**. Siehe die [**KMS Privesc-Seite**](../aws-privilege-escalation/aws-kms-privesc.md) für weitere Informationen.
|
||||
Ein Angreifer könnte die Berechtigung **`kms:PutKeyPolicy`** verwenden, um **Zugriff** auf einen Schlüssel für einen Benutzer unter seiner Kontrolle oder sogar für ein externes Konto zu gewähren. Überprüfen Sie die [**KMS Privesc-Seite**](../aws-privilege-escalation/aws-kms-privesc.md) für weitere Informationen.
|
||||
|
||||
### Ewige Berechtigung
|
||||
|
||||
Berechtigungen sind eine weitere Möglichkeit, einem Principal einige Berechtigungen über einen bestimmten Schlüssel zu gewähren. Es ist möglich, eine Berechtigung zu erteilen, die es einem Benutzer erlaubt, Berechtigungen zu erstellen. Darüber hinaus kann ein Benutzer mehrere Berechtigungen (sogar identische) über denselben Schlüssel haben.
|
||||
Grants sind eine weitere Möglichkeit, einem Principal einige Berechtigungen über einen bestimmten Schlüssel zu gewähren. Es ist möglich, einen Grant zu vergeben, der es einem Benutzer erlaubt, Grants zu erstellen. Darüber hinaus kann ein Benutzer mehrere Grants (sogar identische) über denselben Schlüssel haben.
|
||||
|
||||
Daher ist es möglich, dass ein Benutzer 10 Berechtigungen mit allen Berechtigungen hat. Der Angreifer sollte dies ständig überwachen. Und wenn zu einem bestimmten Zeitpunkt 1 Berechtigung entfernt wird, sollten weitere 10 generiert werden.
|
||||
Daher ist es möglich, dass ein Benutzer 10 Grants mit allen Berechtigungen hat. Der Angreifer sollte dies ständig überwachen. Und wenn zu einem bestimmten Zeitpunkt 1 Grant entfernt wird, sollten weitere 10 generiert werden.
|
||||
|
||||
(Wir verwenden 10 und nicht 2, um erkennen zu können, dass eine Berechtigung entfernt wurde, während der Benutzer noch einige Berechtigungen hat.)
|
||||
(Wir verwenden 10 und nicht 2, um erkennen zu können, dass ein Grant entfernt wurde, während der Benutzer weiterhin einige Grants hat.)
|
||||
```bash
|
||||
# To generate grants, generate 10 like this one
|
||||
aws kms create-grant \
|
||||
@@ -32,6 +32,6 @@ aws kms create-grant \
|
||||
aws kms list-grants --key-id <key-id>
|
||||
```
|
||||
> [!NOTE]
|
||||
> Ein Grant kann nur Berechtigungen von diesem geben: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
|
||||
> Ein Grant kann Berechtigungen nur von diesem geben: [https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations](https://docs.aws.amazon.com/kms/latest/developerguide/grants.html#terms-grant-operations)
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - Lambda Persistence
|
||||
# AWS - Lambda Persistenz
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,17 +10,17 @@ Für weitere Informationen siehe:
|
||||
../../aws-services/aws-lambda-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Lambda Layer Persistence
|
||||
### Lambda Layer Persistenz
|
||||
|
||||
Es ist möglich, **eine Schicht einzuführen/hintertüren, um beliebigen Code auszuführen**, wenn die Lambda stealthy ausgeführt wird:
|
||||
Es ist möglich, eine **Schicht einzuführen/hintertüren, um beliebigen Code auszuführen**, wenn die Lambda stealthy ausgeführt wird:
|
||||
|
||||
{{#ref}}
|
||||
aws-lambda-layers-persistence.md
|
||||
{{#endref}}
|
||||
|
||||
### Lambda Extension Persistence
|
||||
### Lambda Erweiterungs-Persistenz
|
||||
|
||||
Durch den Missbrauch von Lambda Layers ist es auch möglich, Erweiterungen zu missbrauchen und in der Lambda persistent zu bleiben, aber auch Anfragen zu stehlen und zu modifizieren.
|
||||
Durch den Missbrauch von Lambda Layers ist es auch möglich, Erweiterungen zu missbrauchen und in der Lambda zu persistieren, aber auch Anfragen zu stehlen und zu modifizieren.
|
||||
|
||||
{{#ref}}
|
||||
aws-abusing-lambda-extensions.md
|
||||
@@ -40,25 +40,25 @@ Auf diese Weise könnte ein Angreifer eine **hintertürige Version 1** und eine
|
||||
|
||||
<figure><img src="../../../../images/image (120).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
### Version Backdoor + API Gateway
|
||||
### Version Hintertür + API Gateway
|
||||
|
||||
1. Kopiere den ursprünglichen Code der Lambda
|
||||
2. **Erstelle eine neue Version, die den** ursprünglichen Code hintertürt (oder nur mit bösartigem Code). Veröffentliche und **deploye diese Version** auf $LATEST
|
||||
1. Rufe das API-Gateway auf, das mit der Lambda verbunden ist, um den Code auszuführen
|
||||
3. **Erstelle eine neue Version mit dem ursprünglichen Code**, veröffentliche und deploye diese **Version** auf $LATEST.
|
||||
1. Kopieren Sie den ursprünglichen Code der Lambda
|
||||
2. **Erstellen Sie eine neue Version, die den ursprünglichen Code hintertürig macht** (oder nur mit bösartigem Code). Veröffentlichen und **setzen Sie diese Version** auf $LATEST
|
||||
1. Rufen Sie das API-Gateway auf, das mit der Lambda verbunden ist, um den Code auszuführen
|
||||
3. **Erstellen Sie eine neue Version mit dem ursprünglichen Code**, veröffentlichen und setzen Sie diese **Version** auf $LATEST.
|
||||
1. Dies wird den hintertürigen Code in einer vorherigen Version verbergen
|
||||
4. Gehe zum API Gateway und **erstelle eine neue POST-Methode** (oder wähle eine andere Methode), die die hintertürige Version der Lambda ausführt: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
|
||||
1. Beachte das finale :1 der arn **das die Version der Funktion angibt** (Version 1 wird in diesem Szenario die hintertürige sein).
|
||||
5. Wähle die erstellte POST-Methode aus und wähle in Aktionen **`API bereitstellen`**
|
||||
6. Jetzt, wenn du **die Funktion über POST aufrufst, wird deine Hintertür** aktiviert
|
||||
4. Gehen Sie zum API Gateway und **erstellen Sie eine neue POST-Methode** (oder wählen Sie eine andere Methode), die die hintertürige Version der Lambda ausführt: `arn:aws:lambda:us-east-1:<acc_id>:function:<func_name>:1`
|
||||
1. Beachten Sie das finale :1 der arn **das die Version der Funktion angibt** (Version 1 wird in diesem Szenario die hintertürige sein).
|
||||
5. Wählen Sie die erstellte POST-Methode aus und wählen Sie in Aktionen **`API bereitstellen`**
|
||||
6. Jetzt, wenn Sie **die Funktion über POST aufrufen, wird Ihre Hintertür** aufgerufen
|
||||
|
||||
### Cron/Event-Aktuator
|
||||
### Cron/Ereignis-Aktuator
|
||||
|
||||
Die Tatsache, dass du **Lambda-Funktionen ausführen kannst, wenn etwas passiert oder wenn etwas Zeit vergeht**, macht Lambda zu einer schönen und gängigen Möglichkeit, Persistenz zu erlangen und Erkennung zu vermeiden.\
|
||||
Hier sind einige Ideen, um deine **Präsenz in AWS stealthy zu gestalten, indem du Lambdas erstellst**.
|
||||
Die Tatsache, dass Sie **Lambda-Funktionen ausführen können, wenn etwas passiert oder wenn etwas Zeit vergeht**, macht Lambda zu einer schönen und gängigen Möglichkeit, Persistenz zu erlangen und Erkennung zu vermeiden.\
|
||||
Hier sind einige Ideen, um Ihre **Präsenz in AWS stealthy zu gestalten, indem Sie Lambdas erstellen**.
|
||||
|
||||
- Jedes Mal, wenn ein neuer Benutzer erstellt wird, generiert Lambda einen neuen Benutzerschlüssel und sendet ihn an den Angreifer.
|
||||
- Jedes Mal, wenn eine neue Rolle erstellt wird, gewährt Lambda den kompromittierten Benutzern die Berechtigung, Rollen zu übernehmen.
|
||||
- Jedes Mal, wenn neue CloudTrail-Protokolle generiert werden, lösche/ändere sie.
|
||||
- Jedes Mal, wenn eine neue Rolle erstellt wird, gewährt Lambda die Berechtigung zur Annahme von Rollen an kompromittierte Benutzer.
|
||||
- Jedes Mal, wenn neue CloudTrail-Protokolle generiert werden, löschen/ändern Sie diese.
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -6,14 +6,14 @@
|
||||
|
||||
Lambda-Erweiterungen verbessern Funktionen, indem sie sich mit verschiedenen **Überwachungs-, Beobachtungs-, Sicherheits- und Governance-Tools** integrieren. Diese Erweiterungen, die über [.zip-Archive mit Lambda-Schichten](https://docs.aws.amazon.com/lambda/latest/dg/configuration-layers.html) hinzugefügt oder in [Container-Image-Bereitstellungen](https://aws.amazon.com/blogs/compute/working-with-lambda-layers-and-extensions-in-container-images/) enthalten sind, arbeiten in zwei Modi: **intern** und **extern**.
|
||||
|
||||
- **Interne Erweiterungen** fusionieren mit dem Laufzeitprozess und manipulieren dessen Start mit **sprachspezifischen Umgebungsvariablen** und **Wrapper-Skripten**. Diese Anpassung gilt für eine Reihe von Laufzeiten, einschließlich **Java Correto 8 und 11, Node.js 10 und 12 sowie .NET Core 3.1**.
|
||||
- **Interne Erweiterungen** verschmelzen mit dem Laufzeitprozess und manipulieren dessen Start mit **sprachspezifischen Umgebungsvariablen** und **Wrapper-Skripten**. Diese Anpassung gilt für eine Reihe von Laufzeiten, einschließlich **Java Correto 8 und 11, Node.js 10 und 12 sowie .NET Core 3.1**.
|
||||
- **Externe Erweiterungen** laufen als separate Prozesse und halten die Betriebsanpassung an den Lebenszyklus der Lambda-Funktion aufrecht. Sie sind mit verschiedenen Laufzeiten wie **Node.js 10 und 12, Python 3.7 und 3.8, Ruby 2.5 und 2.7, Java Corretto 8 und 11, .NET Core 3.1** und **benutzerdefinierten Laufzeiten** kompatibel.
|
||||
|
||||
Für weitere Informationen darüber, [**wie Lambda-Erweiterungen funktionieren, siehe die Dokumentation**](https://docs.aws.amazon.com/lambda/latest/dg/runtimes-extensions-api.html).
|
||||
|
||||
### Externe Erweiterung für Persistenz, Stehlen von Anfragen & Modifizieren von Anfragen
|
||||
|
||||
Dies ist eine Zusammenfassung der Technik, die in diesem Beitrag vorgeschlagen wird: [https://www.clearvector.com/blog/lambda-spy/](https://www.clearvector.com/blog/lambda-spy/)
|
||||
Dies ist eine Zusammenfassung der in diesem Beitrag vorgeschlagenen Technik: [https://www.clearvector.com/blog/lambda-spy/](https://www.clearvector.com/blog/lambda-spy/)
|
||||
|
||||
Es wurde festgestellt, dass der Standard-Linux-Kernel in der Lambda-Laufzeitumgebung mit den Systemaufrufen “**process_vm_readv**” und “**process_vm_writev**” kompiliert ist. Und alle Prozesse laufen mit derselben Benutzer-ID, selbst der neue Prozess, der für die externe Erweiterung erstellt wurde. **Das bedeutet, dass eine externe Erweiterung vollen Lese- und Schreibzugriff auf den Heap-Speicher von Rapid hat, per Design.**
|
||||
|
||||
@@ -23,16 +23,16 @@ Der Init (Rapid)-Prozess überwacht alle API-Anfragen unter [http://127.0.0.1:90
|
||||
|
||||
<figure><img src="../../../../images/image (254).png" alt=""><figcaption><p><a href="https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.default.png">https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.default.png</a></p></figcaption></figure>
|
||||
|
||||
Die Variable **`AWS_LAMBDA_RUNTIME_API`** gibt die **IP**-Adresse und die **Portnummer** der Rapid-API an **Kindlaufzeitprozesse** und zusätzliche Erweiterungen weiter.
|
||||
Die Variable **`AWS_LAMBDA_RUNTIME_API`** gibt die **IP**-Adresse und die **Portnummer** der Rapid-API an **untergeordnete Laufzeitprozesse** und zusätzliche Erweiterungen weiter.
|
||||
|
||||
> [!WARNING]
|
||||
> Durch Ändern der **`AWS_LAMBDA_RUNTIME_API`**-Umgebungsvariable auf einen **`Port`**, auf den wir Zugriff haben, ist es möglich, alle Aktionen innerhalb der Lambda-Laufzeit abzufangen (**Man-in-the-Middle**). Dies ist möglich, weil die Erweiterung mit denselben Berechtigungen wie Rapid Init läuft und der Kernel des Systems **Änderungen am Prozessspeicher** zulässt, was die Änderung der Portnummer ermöglicht.
|
||||
> Durch Ändern der **`AWS_LAMBDA_RUNTIME_API`**-Umgebungsvariable auf einen **`Port`**, auf den wir Zugriff haben, ist es möglich, alle Aktionen innerhalb der Lambda-Laufzeit abzufangen (**man-in-the-middle**). Dies ist möglich, weil die Erweiterung mit denselben Berechtigungen wie Rapid Init läuft und der Kernel des Systems **Änderungen am Prozessspeicher** zulässt, was die Änderung der Portnummer ermöglicht.
|
||||
|
||||
Da **Erweiterungen vor jedem Laufzeitcode** ausgeführt werden, beeinflusst die Modifikation der Umgebungsvariable den Laufzeitprozess (z. B. Python, Java, Node, Ruby) beim Start. Darüber hinaus werden **nachfolgende Erweiterungen**, die auf dieser Variablen basieren, ebenfalls über unsere Erweiterung geleitet. Diese Konfiguration könnte Malware ermöglichen, Sicherheitsmaßnahmen oder Protokollierungserweiterungen direkt innerhalb der Laufzeitumgebung vollständig zu umgehen.
|
||||
Da **Erweiterungen vor jedem Laufzeitcode ausgeführt werden**, beeinflusst die Modifikation der Umgebungsvariable den Laufzeitprozess (z. B. Python, Java, Node, Ruby) beim Start. Darüber hinaus werden **nachfolgende Erweiterungen**, die auf dieser Variablen basieren, ebenfalls über unsere Erweiterung geleitet. Diese Konfiguration könnte Malware ermöglichen, Sicherheitsmaßnahmen oder Protokollierungserweiterungen direkt innerhalb der Laufzeitumgebung vollständig zu umgehen.
|
||||
|
||||
<figure><img src="../../../../images/image (267).png" alt=""><figcaption><p><a href="https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.mitm.png">https://www.clearvector.com/blog/content/images/size/w1000/2022/11/2022110801.rapid.mitm.png</a></p></figcaption></figure>
|
||||
|
||||
Das Tool [**lambda-spy**](https://github.com/clearvector/lambda-spy) wurde entwickelt, um **Speicher zu schreiben** und **sensible Informationen** aus Lambda-Anfragen, anderen **Erweiterungsanfragen** zu stehlen und sie sogar **zu modifizieren**.
|
||||
Das Tool [**lambda-spy**](https://github.com/clearvector/lambda-spy) wurde entwickelt, um **Speicher zu schreiben** und **sensible Informationen** aus Lambda-Anfragen, anderen **Erweiterungsanfragen** und sogar **diese zu modifizieren**.
|
||||
|
||||
## Referenzen
|
||||
|
||||
|
||||
@@ -18,15 +18,15 @@ Der Ladepfad, den Python in Lambda verwenden wird, ist der folgende:
|
||||
```
|
||||
['/var/task', '/opt/python/lib/python3.9/site-packages', '/opt/python', '/var/runtime', '/var/lang/lib/python39.zip', '/var/lang/lib/python3.9', '/var/lang/lib/python3.9/lib-dynload', '/var/lang/lib/python3.9/site-packages', '/opt/python/lib/python3.9/site-packages']
|
||||
```
|
||||
Überprüfen Sie, wie die **zweite** und dritte **Position** von Verzeichnissen eingenommen werden, in denen **Lambda-Schichten** ihre Dateien entpacken: **`/opt/python/lib/python3.9/site-packages`** und **`/opt/python`**
|
||||
Überprüfen Sie, wie die **zweite** und dritte **Position** von Verzeichnissen eingenommen werden, in denen **Lambda-Layer** ihre Dateien entpacken: **`/opt/python/lib/python3.9/site-packages`** und **`/opt/python`**
|
||||
|
||||
> [!CAUTION]
|
||||
> Wenn es einem Angreifer gelingt, eine verwendete Lambda **Schicht** zu **backdoor** oder eine hinzuzufügen, die **beliebigen Code ausführt, wenn eine gängige Bibliothek geladen wird**, kann er mit jedem Lambda-Aufruf bösartigen Code ausführen.
|
||||
> Wenn es einem Angreifer gelingt, einen verwendeten Lambda **Layer** zu **backdoor** oder einen hinzuzufügen, der **beliebigen Code ausführt, wenn eine gängige Bibliothek geladen wird**, kann er mit jeder Lambda-Aufruf bösartigen Code ausführen.
|
||||
|
||||
Daher sind die Voraussetzungen:
|
||||
Daher sind die Anforderungen:
|
||||
|
||||
- **Überprüfen Sie Bibliotheken**, die vom Code der Opfer **geladen** werden
|
||||
- Erstellen Sie eine **Proxy-Bibliothek mit Lambda-Schichten**, die **benutzerdefinierten Code ausführt** und die **ursprüngliche** Bibliothek **lädt**.
|
||||
- Erstellen Sie eine **Proxy-Bibliothek mit Lambda-Layern**, die **benutzerdefinierten Code ausführt** und die **ursprüngliche** Bibliothek **lädt**.
|
||||
|
||||
### Vorgebundene Bibliotheken
|
||||
|
||||
@@ -34,7 +34,7 @@ Daher sind die Voraussetzungen:
|
||||
> Bei der Ausnutzung dieser Technik stieß ich auf eine Schwierigkeit: Einige Bibliotheken sind **bereits geladen**, wenn Ihr Code ausgeführt wird. Ich erwartete, Dinge wie `os` oder `sys` zu finden, aber **sogar die `json`-Bibliothek war geladen**.\
|
||||
> Um diese Persistenztechnik auszunutzen, muss der Code eine **neue Bibliothek laden, die nicht geladen ist**, wenn der Code ausgeführt wird.
|
||||
|
||||
Mit einem Python-Code wie diesem ist es möglich, die **Liste der Bibliotheken, die vorab geladen sind**, im Python-Laufzeitumfeld in Lambda zu erhalten:
|
||||
Mit einem Python-Code wie diesem ist es möglich, die **Liste der Bibliotheken, die vorab geladen sind**, innerhalb der Python-Laufzeit in Lambda zu erhalten:
|
||||
```python
|
||||
import sys
|
||||
|
||||
@@ -83,11 +83,11 @@ import csv as _csv
|
||||
|
||||
sys.modules["csv"] = _csv
|
||||
```
|
||||
Dann erstellen Sie ein Zip mit diesem Code im Pfad **`python/lib/python3.9/site-packages/__init__.py`** und fügen Sie es als Lambda-Schicht hinzu.
|
||||
Erstellen Sie dann eine Zip-Datei mit diesem Code im Pfad **`python/lib/python3.9/site-packages/__init__.py`** und fügen Sie sie als Lambda-Schicht hinzu.
|
||||
|
||||
Sie finden diesen Code unter [**https://github.com/carlospolop/LambdaLayerBackdoor**](https://github.com/carlospolop/LambdaLayerBackdoor)
|
||||
|
||||
Die integrierte Payload wird **die IAM-Credentials an einen Server SENDEN, BEIM ERSTEN AUFRUF oder NACH EINEM RESET DES LAMBDA-Containers** (Änderung des Codes oder kaltes Lambda) senden, aber **andere Techniken** wie die folgenden könnten ebenfalls integriert werden:
|
||||
Die integrierte Payload wird **die IAM-Credentials an einen Server senden, BEIM ERSTEN AUFRUF oder NACH einem Reset des Lambda-Containers** (Änderung des Codes oder kaltes Lambda), aber **andere Techniken** wie die folgenden könnten ebenfalls integriert werden:
|
||||
|
||||
{{#ref}}
|
||||
../../aws-post-exploitation/aws-lambda-post-exploitation/aws-warm-lambda-persistence.md
|
||||
@@ -95,14 +95,14 @@ Die integrierte Payload wird **die IAM-Credentials an einen Server SENDEN, BEIM
|
||||
|
||||
### Externe Schichten
|
||||
|
||||
Es ist zu beachten, dass es möglich ist, **Lambda-Schichten von externen Konten** zu verwenden. Darüber hinaus kann ein Lambda eine Schicht von einem externen Konto verwenden, auch wenn es keine Berechtigungen hat.\
|
||||
Es ist zu beachten, dass es möglich ist, **Lambda-Schichten aus externen Konten** zu verwenden. Darüber hinaus kann ein Lambda eine Schicht aus einem externen Konto verwenden, auch wenn es keine Berechtigungen hat.\
|
||||
Es ist auch zu beachten, dass die **maximale Anzahl von Schichten, die ein Lambda haben kann, 5 beträgt**.
|
||||
|
||||
Daher könnte ein Angreifer, um die Vielseitigkeit dieser Technik zu verbessern:
|
||||
|
||||
- Eine bestehende Schicht des Benutzers backdoor (nichts ist extern)
|
||||
- Eine bestehende Schicht des Benutzers kompromittieren (nichts ist extern)
|
||||
- **Eine** **Schicht** in **seinem Konto** erstellen, dem **Opferkonto Zugriff** auf die Verwendung der Schicht gewähren, die **Schicht** im Lambda des Opfers **konfigurieren** und die **Berechtigung entfernen**.
|
||||
- Das **Lambda** wird weiterhin in der Lage sein, die **Schicht** zu **verwenden**, und das **Opfer wird** keine einfache Möglichkeit haben, den **Code der Schichten herunterzuladen** (außer durch den Erhalt einer Rev-Shell innerhalb des Lambdas).
|
||||
- Das **Lambda** wird weiterhin in der Lage sein, die **Schicht** zu **verwenden**, und das **Opfer wird** keine einfache Möglichkeit haben, den **Code der Schichten herunterzuladen** (außer durch den Erhalt einer Reverse-Shell im Lambda).
|
||||
- Das Opfer **wird keine externen Schichten** sehen, die mit **`aws lambda list-layers`** verwendet werden.
|
||||
```bash
|
||||
# Upload backdoor layer
|
||||
|
||||
@@ -26,7 +26,7 @@ Ein Angreifer könnte Zugriff auf die Instanzen erhalten und sie mit einer Hinte
|
||||
|
||||
Wenn Domains konfiguriert sind:
|
||||
|
||||
- Erstellen Sie eine Subdomain, die auf Ihre IP zeigt, sodass Sie eine **subdomain takeover** haben
|
||||
- Erstellen Sie eine Subdomain, die auf Ihre IP zeigt, sodass Sie eine **Subdomain-Übernahme** haben
|
||||
- Erstellen Sie einen **SPF**-Eintrag, der es Ihnen ermöglicht, **E-Mails** von der Domain zu senden
|
||||
- Konfigurieren Sie die **Hauptdomain-IP auf Ihre eigene** und führen Sie einen **MitM** von Ihrer IP zu den legitimen durch
|
||||
|
||||
|
||||
@@ -18,7 +18,7 @@ aws rds modify-db-instance --db-instance-identifier target-instance --publicly-a
|
||||
```
|
||||
### Erstellen Sie einen Admin-Benutzer in der DB
|
||||
|
||||
Ein Angreifer könnte einfach **einen Benutzer in der DB erstellen**, sodass er, selbst wenn das Passwort des Master-Benutzers geändert wird, **den Zugriff** auf die Datenbank **nicht verliert**.
|
||||
Ein Angreifer könnte einfach **einen Benutzer in der DB erstellen**, sodass selbst wenn das Passwort des Master-Benutzers geändert wird, er **den Zugriff** auf die Datenbank **nicht verliert**.
|
||||
|
||||
### Snapshot öffentlich machen
|
||||
```bash
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - S3 Persistence
|
||||
# AWS - S3 Persistenz
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,13 +10,13 @@ Für weitere Informationen siehe:
|
||||
../aws-services/aws-s3-athena-and-glacier-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### KMS Client-Seitige Verschlüsselung
|
||||
### KMS Client-seitige Verschlüsselung
|
||||
|
||||
Wenn der Verschlüsselungsprozess abgeschlossen ist, verwendet der Benutzer die KMS-API, um einen neuen Schlüssel zu generieren (`aws kms generate-data-key`), und er wird **den generierten verschlüsselten Schlüssel in den Metadaten** der Datei speichern ([python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)), sodass er beim Entschlüsseln diesen erneut mit KMS entschlüsseln kann:
|
||||
Wenn der Verschlüsselungsprozess abgeschlossen ist, verwendet der Benutzer die KMS-API, um einen neuen Schlüssel zu generieren (`aws kms generate-data-key`), und er **speichert den generierten verschlüsselten Schlüssel in den Metadaten** der Datei ([python code example](https://aioboto3.readthedocs.io/en/latest/cse.html#how-it-works-kms-managed-keys)), sodass er beim Entschlüsseln diesen erneut mit KMS entschlüsseln kann:
|
||||
|
||||
<figure><img src="../../../images/image (226).png" alt=""><figcaption></figcaption></figure>
|
||||
|
||||
Daher könnte ein Angreifer diesen Schlüssel aus den Metadaten abrufen und mit KMS (`aws kms decrypt`) entschlüsseln, um den Schlüssel zu erhalten, der zur Verschlüsselung der Informationen verwendet wurde. Auf diese Weise hat der Angreifer den Verschlüsselungsschlüssel, und wenn dieser Schlüssel zur Verschlüsselung anderer Dateien wiederverwendet wird, kann er ihn verwenden.
|
||||
Daher könnte ein Angreifer diesen Schlüssel aus den Metadaten abrufen und mit KMS (`aws kms decrypt`) entschlüsseln, um den Schlüssel zu erhalten, der zur Verschlüsselung der Informationen verwendet wurde. Auf diese Weise hat der Angreifer den Verschlüsselungsschlüssel, und wenn dieser Schlüssel wiederverwendet wird, um andere Dateien zu verschlüsseln, kann er ihn verwenden.
|
||||
|
||||
### Verwendung von S3 ACLs
|
||||
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - Secrets Manager Persistence
|
||||
# AWS - Secrets Manager Persistenz
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,11 +12,11 @@ Für weitere Informationen siehe:
|
||||
|
||||
### Über Ressourcenrichtlinien
|
||||
|
||||
Es ist möglich, **Zugriff auf Geheimnisse für externe Konten** über Ressourcenrichtlinien zu **gewähren**. Überprüfen Sie die [**Secrets Manager Privesc-Seite**](../aws-privilege-escalation/aws-secrets-manager-privesc.md) für weitere Informationen. Beachten Sie, dass das externe Konto auch **Zugriff auf den KMS-Schlüssel, der das Geheimnis verschlüsselt, benötigt**.
|
||||
Es ist möglich, **Zugriff auf Geheimnisse für externe Konten zu gewähren** über Ressourcenrichtlinien. Siehe die [**Secrets Manager Privesc-Seite**](../aws-privilege-escalation/aws-secrets-manager-privesc.md) für weitere Informationen. Beachten Sie, dass das externe Konto auch **Zugriff auf den KMS-Schlüssel, der das Geheimnis verschlüsselt, benötigt**.
|
||||
|
||||
### Über Secrets Rotate Lambda
|
||||
|
||||
Um **Geheimnisse** automatisch zu **rotieren**, wird eine konfigurierte **Lambda** aufgerufen. Wenn ein Angreifer den **Code** **ändern** könnte, könnte er das neue Geheimnis direkt an sich selbst **exfiltrieren**.
|
||||
Um **Geheimnisse** automatisch zu **rotieren**, wird eine konfigurierte **Lambda** aufgerufen. Wenn ein Angreifer den **Code** **ändern** könnte, könnte er das neue Geheimnis direkt **an sich selbst exfiltrieren**.
|
||||
|
||||
So könnte der Lambda-Code für eine solche Aktion aussehen:
|
||||
```python
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - SNS Persistence
|
||||
# AWS - SNS Persistenz
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,10 +10,10 @@ Für weitere Informationen siehe:
|
||||
../aws-services/aws-sns-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Persistence
|
||||
### Persistenz
|
||||
|
||||
Beim Erstellen eines **SNS-Themas** müssen Sie mit einer IAM-Richtlinie angeben, **wer Zugriff auf das Lesen und Schreiben hat**. Es ist möglich, externe Konten, ARN von Rollen oder **sogar "\*"** anzugeben.\
|
||||
Die folgende Richtlinie gewährt allen in AWS Zugriff auf das Lesen und Schreiben im SNS-Thema mit dem Namen **`MySNS.fifo`**:
|
||||
Beim Erstellen eines **SNS-Themas** müssen Sie mit einer IAM-Richtlinie angeben, **wer Zugriff auf Lesen und Schreiben hat**. Es ist möglich, externe Konten, ARN von Rollen oder **sogar "\*"** anzugeben.\
|
||||
Die folgende Richtlinie gewährt allen in AWS Zugriff auf Lesen und Schreiben im SNS-Thema mit dem Namen **`MySNS.fifo`**:
|
||||
```json
|
||||
{
|
||||
"Version": "2008-10-17",
|
||||
@@ -65,7 +65,7 @@ Die folgende Richtlinie gewährt allen in AWS Zugriff auf das Lesen und Schreibe
|
||||
```
|
||||
### Erstellen von Abonnenten
|
||||
|
||||
Um weiterhin alle Nachrichten aus allen Themen zu exfiltrieren, könnte der Angreifer **Abonnenten für alle Themen erstellen**.
|
||||
Um alle Nachrichten aus allen Themen weiter zu exfiltrieren, könnte der Angreifer **Abonnenten für alle Themen erstellen**.
|
||||
|
||||
Beachten Sie, dass, wenn das **Thema vom Typ FIFO** ist, nur Abonnenten, die das Protokoll **SQS** verwenden, genutzt werden können.
|
||||
```bash
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - SQS Persistence
|
||||
# AWS - SQS Persistenz
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -10,10 +10,10 @@ Für weitere Informationen siehe:
|
||||
../aws-services/aws-sqs-and-sns-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Verwendung der Ressourcenrichtlinie
|
||||
### Verwendung von Ressourcenrichtlinien
|
||||
|
||||
In SQS müssen Sie mit einer IAM-Richtlinie **angeben, wer Zugriff auf das Lesen und Schreiben hat**. Es ist möglich, externe Konten, ARN von Rollen oder **sogar "\*"** anzugeben.\
|
||||
Die folgende Richtlinie gewährt jedem in AWS Zugriff auf alles in der Warteschlange mit dem Namen **MyTestQueue**:
|
||||
Die folgende Richtlinie gewährt allen in AWS Zugriff auf alles in der Warteschlange mit dem Namen **MyTestQueue**:
|
||||
```json
|
||||
{
|
||||
"Version": "2008-10-17",
|
||||
|
||||
@@ -10,12 +10,12 @@ Für weitere Informationen siehe:
|
||||
../aws-services/aws-stepfunctions-enum.md
|
||||
{{#endref}}
|
||||
|
||||
### Backdooring von Step-Funktionen
|
||||
### Backdooring von Step Functions
|
||||
|
||||
Hinterlege einen Backdoor in einer Step-Funktion, um jeden Persistenztrick auszuführen, sodass jedes Mal, wenn sie ausgeführt wird, deine bösartigen Schritte ausgeführt werden.
|
||||
Hinterlasse eine Hintertür in einer Step Function, um einen Persistenztrick auszuführen, sodass jedes Mal, wenn sie ausgeführt wird, deine bösartigen Schritte ausgeführt werden.
|
||||
|
||||
### Backdooring von Aliasen
|
||||
### Backdooring von Aliassen
|
||||
|
||||
Wenn das AWS-Konto Aliase verwendet, um Step-Funktionen aufzurufen, wäre es möglich, einen Alias zu ändern, um eine neue, gehackte Version der Step-Funktion zu verwenden.
|
||||
Wenn das AWS-Konto Aliasse verwendet, um Step Functions aufzurufen, wäre es möglich, einen Alias zu ändern, um eine neue, mit einer Hintertür versehene Version der Step Function zu verwenden.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -1,4 +1,4 @@
|
||||
# AWS - STS Persistence
|
||||
# AWS - STS Persistenz
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
@@ -12,7 +12,7 @@ Für weitere Informationen zugreifen:
|
||||
|
||||
### Assume role token
|
||||
|
||||
Temporäre Tokens können nicht aufgelistet werden, daher ist das Halten eines aktiven temporären Tokens eine Möglichkeit, Persistenz aufrechtzuerhalten.
|
||||
Temporäre Tokens können nicht aufgelistet werden, daher ist das Beibehalten eines aktiven temporären Tokens eine Möglichkeit, Persistenz aufrechtzuerhalten.
|
||||
|
||||
<pre class="language-bash"><code class="lang-bash">aws sts get-session-token --duration-seconds 129600
|
||||
|
||||
@@ -22,13 +22,13 @@ aws sts get-session-token \
|
||||
--token-code <code-from-token>
|
||||
|
||||
# Der Name des Hardwaregeräts ist normalerweise die Nummer auf der Rückseite des Geräts, wie GAHT12345678
|
||||
<strong># Der SMS-Gerätename ist die ARN in AWS, wie arn:aws:iam::123456789012:sms-mfa/benutzername
|
||||
</strong># Der virtuelle Gerätename ist die ARN in AWS, wie arn:aws:iam::123456789012:mfa/benutzername
|
||||
<strong># Der Name des SMS-Geräts ist die ARN in AWS, wie arn:aws:iam::123456789012:sms-mfa/benutzername
|
||||
</strong># Der Name des virtuellen Geräts ist die ARN in AWS, wie arn:aws:iam::123456789012:mfa/benutzername
|
||||
</code></pre>
|
||||
|
||||
### Role Chain Juggling
|
||||
|
||||
[**Role Chaining ist ein anerkanntes AWS-Feature**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), das häufig zur Aufrechterhaltung von Stealth-Persistenz verwendet wird. Es beinhaltet die Fähigkeit, **eine Rolle zu übernehmen, die dann eine andere übernimmt**, was potenziell zur ursprünglichen Rolle in einer **zyklischen Weise** zurückkehrt. Jedes Mal, wenn eine Rolle übernommen wird, wird das Ablaufdatum der Anmeldeinformationen aktualisiert. Folglich, wenn zwei Rollen so konfiguriert sind, dass sie sich gegenseitig übernehmen, ermöglicht dieses Setup die ständige Erneuerung der Anmeldeinformationen.
|
||||
[**Role Chaining ist ein anerkanntes AWS-Feature**](https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_terms-and-concepts.html#Role%20chaining), das häufig zur Aufrechterhaltung von Stealth-Persistenz genutzt wird. Es beinhaltet die Fähigkeit, **eine Rolle zu übernehmen, die dann eine andere übernimmt**, was potenziell zur ursprünglichen Rolle in einer **zyklischen Weise** zurückkehrt. Jedes Mal, wenn eine Rolle übernommen wird, wird das Ablaufdatum der Anmeldeinformationen aktualisiert. Folglich, wenn zwei Rollen so konfiguriert sind, dass sie sich gegenseitig übernehmen, ermöglicht dieses Setup die ständige Erneuerung der Anmeldeinformationen.
|
||||
|
||||
Sie können dieses [**Tool**](https://github.com/hotnops/AWSRoleJuggler/) verwenden, um das Role Chaining aufrechtzuerhalten:
|
||||
```bash
|
||||
@@ -44,7 +44,7 @@ optional arguments:
|
||||
|
||||
<details>
|
||||
|
||||
<summary>Code zum Durchführen von Role Juggling aus PowerShell</summary>
|
||||
<summary>Code zur Durchführung von Role Juggling aus PowerShell</summary>
|
||||
```powershell
|
||||
# PowerShell script to check for role juggling possibilities using AWS CLI
|
||||
|
||||
|
||||
Reference in New Issue
Block a user