mirror of
https://github.com/HackTricks-wiki/hacktricks-cloud.git
synced 2026-07-28 22:51:09 -07:00
Translated ['src/pentesting-cloud/aws-security/aws-post-exploitation/aws
This commit is contained in:
+17
-5
@@ -21,7 +21,7 @@ Noch zu testen.
|
||||
|
||||
### `ses:SendRawEmail`
|
||||
|
||||
E-Mail senden.
|
||||
Sende eine E-Mail.
|
||||
```bash
|
||||
aws ses send-raw-email --raw-message file://message.json
|
||||
```
|
||||
@@ -37,7 +37,7 @@ Noch zu testen.
|
||||
|
||||
### `ses:SendBulkTemplatedEmail`
|
||||
|
||||
Eine E-Mail an mehrere Empfänger senden
|
||||
Sende eine E-Mail an mehrere Empfänger
|
||||
```bash
|
||||
aws ses send-bulk-templated-email --source <value> --template <value>
|
||||
```
|
||||
@@ -45,13 +45,13 @@ Noch zu testen.
|
||||
|
||||
### `ses:SendBulkEmail`
|
||||
|
||||
Eine E-Mail an mehrere Empfänger senden.
|
||||
E-Mail an mehrere Empfänger senden.
|
||||
```
|
||||
aws sesv2 send-bulk-email --default-content <value> --bulk-email-entries <value>
|
||||
```
|
||||
### `ses:SendBounce`
|
||||
|
||||
Sende eine **bounce email** für eine empfangene E-Mail (die anzeigt, dass die E-Mail nicht zugestellt werden konnte). Dies kann nur **bis zu 24h nach dem Empfang** der E-Mail durchgeführt werden.
|
||||
Sende eine **bounce email** bezüglich einer empfangenen E‑Mail (zeigt an, dass die E‑Mail nicht zugestellt werden konnte). Dies kann nur **bis zu 24h nach Empfang** der E‑Mail gemacht werden.
|
||||
```bash
|
||||
aws ses send-bounce --original-message-id <value> --bounce-sender <value> --bounced-recipient-info-list <value>
|
||||
```
|
||||
@@ -59,11 +59,23 @@ Noch zu testen.
|
||||
|
||||
### `ses:SendCustomVerificationEmail`
|
||||
|
||||
Dies sendet eine angepasste Bestätigungs-E-Mail. Möglicherweise benötigen Sie außerdem Berechtigungen, um die E-Mail-Vorlage zu erstellen.
|
||||
Dies sendet eine benutzerdefinierte Verifizierungs-E-Mail. Möglicherweise benötigen Sie außerdem permissions, um die Template-E-Mail zu erstellen.
|
||||
```bash
|
||||
aws ses send-custom-verification-email --email-address <value> --template-name <value>
|
||||
aws sesv2 send-custom-verification-email --email-address <value> --template-name <value>
|
||||
```
|
||||
Noch zu testen.
|
||||
|
||||
## WorkMail pivot, um die SES sandbox zu umgehen
|
||||
|
||||
Wenn `ses:GetAccount` anzeigt, dass das Konto noch in der SES sandbox ist und `ses:ListIdentities` keine verifizierten Absender zurückliefert, können Angreifer **pivot to WorkMail** nutzen, um sofort zu senden (keine Sandbox und höhere Standardquoten), indem sie Orgs erstellen, Domains verifizieren und Mailboxen registrieren.
|
||||
|
||||
{{#ref}}
|
||||
../aws-workmail-post-exploitation/README.md
|
||||
{{#endref}}
|
||||
|
||||
## Quellen
|
||||
|
||||
- [Threat Actors Using AWS WorkMail in Phishing Campaigns](https://www.rapid7.com/blog/post/dr-threat-actors-aws-workmail-phishing-campaigns)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
+76
@@ -0,0 +1,76 @@
|
||||
# AWS - WorkMail Post Exploitation
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
|
||||
## Ausnutzung von WorkMail zum Umgehen des SES sandbox
|
||||
|
||||
Auch wenn SES im **sandbox** feststeckt (verified-recipient only, ~200 msgs/24h, 1 msg/s), hat WorkMail keine entsprechende Einschränkung. Ein Angreifer mit langfristigen Keys kann eine temporäre Mail-Infrastruktur aufsetzen und sofort mit dem Versand beginnen:
|
||||
|
||||
1. **Create a WorkMail org (region-scoped)**
|
||||
```bash
|
||||
aws workmail create-organization --region us-east-1 --alias temp-mail --directory-id <dir-id-if-reusing>
|
||||
```
|
||||
2. **Verify attacker-controlled domains** (WorkMail invokes SES APIs as `workmail.amazonaws.com`):
|
||||
```bash
|
||||
aws ses verify-domain-identity --domain attacker-domain.com
|
||||
aws ses verify-domain-dkim --domain attacker-domain.com
|
||||
```
|
||||
3. **Provision mailbox users** and register them:
|
||||
```bash
|
||||
aws workmail create-user --organization-id <org-id> --name marketing --display-name "Marketing"
|
||||
aws workmail register-to-work-mail --organization-id <org-id> --entity-id <user-id> --email marketing@attacker-domain.com
|
||||
```
|
||||
|
||||
Notes:
|
||||
- Standardmäßiges **Empfängerlimit**, dokumentiert von AWS: **100,000 externe Empfänger/Tag pro Organisation** (aggregiert über Benutzer).
|
||||
- Aktivitäten zur Domain-Verifizierung erscheinen in CloudTrail unter SES, aber mit **`invokedBy`: `workmail.<region>.amazonaws.com`**, sodass SES-Verifizierungsereignisse eher zur WorkMail-Einrichtung gehören können als zu SES-Kampagnen.
|
||||
- WorkMail-Postfachbenutzer werden zu **application-layer persistence**, unabhängig von IAM-Benutzern.
|
||||
|
||||
## Sendewege & Telemetrielücken
|
||||
|
||||
### Web client (WorkMail UI)
|
||||
- Werden als **`ses:SendRawEmail`**-Ereignisse in CloudTrail erfasst.
|
||||
- `userIdentity.type` = `AWSService`, `invokedBy/sourceIPAddress/userAgent` = `workmail.<region>.amazonaws.com`, sodass die **wahre Client-IP verborgen ist**.
|
||||
- `requestParameters` leak weiterhin den Absender (`source`, `fromArn`, `sourceArn`, configuration set) zur Korrelation mit neu verifizierten Domains/Postfächern.
|
||||
|
||||
### SMTP (am unauffälligsten)
|
||||
- Endpunkt: `smtp.mail.<region>.awsapps.com:465` (SMTP über SSL) mit dem Postfach-Passwort.
|
||||
- **Keine CloudTrail-Datenereignisse** werden für SMTP-Zustellungen erzeugt, selbst wenn SES-Datenereignisse aktiviert sind.
|
||||
- Ideale Erkennungsansätze sind **org/domain/user provisioning** und SES-Identity-ARNs, die in nachfolgenden web-gesendeten `SendRawEmail`-Ereignissen referenziert werden.
|
||||
|
||||
<details>
|
||||
<summary>Beispiel: SMTP-Versand via WorkMail</summary>
|
||||
```python
|
||||
import smtplib
|
||||
from email.message import EmailMessage
|
||||
|
||||
SMTP_SERVER = "smtp.mail.us-east-1.awsapps.com"
|
||||
SMTP_PORT = 465
|
||||
EMAIL_ADDRESS = "marketing@attacker-domain.com"
|
||||
EMAIL_PASSWORD = "SuperSecretPassword!"
|
||||
|
||||
target = "victim@example.com" # can be unverified/external
|
||||
msg = EmailMessage()
|
||||
msg["Subject"] = "WorkMail SMTP"
|
||||
msg["From"] = EMAIL_ADDRESS
|
||||
msg["To"] = target
|
||||
msg.set_content("Delivered via WorkMail SMTP")
|
||||
|
||||
with smtplib.SMTP_SSL(SMTP_SERVER, SMTP_PORT) as smtp:
|
||||
smtp.login(EMAIL_ADDRESS, EMAIL_PASSWORD)
|
||||
smtp.send_message(msg)
|
||||
```
|
||||
</details>
|
||||
|
||||
## Erkennungsüberlegungen
|
||||
|
||||
- Wenn WorkMail nicht benötigt wird, blockieren Sie es via **SCPs** (`workmail:*` deny) auf Organisationsebene.
|
||||
- Alarm bei Provisionierung: `workmail:CreateOrganization`, `workmail:CreateUser`, `workmail:RegisterToWorkMail`, und SES-Verifizierungen mit `invokedBy=workmail.amazonaws.com` (`ses:VerifyDomainIdentity`, `ses:VerifyDomainDkim`).
|
||||
- Beobachten Sie anomale **`ses:SendRawEmail`**-Ereignisse, bei denen die Identity ARNs neue Domains referenzieren und die Quell-IP/UA `workmail.<region>.amazonaws.com` entspricht.
|
||||
|
||||
## Referenzen
|
||||
|
||||
- [Threat Actors Using AWS WorkMail in Phishing Campaigns](https://www.rapid7.com/blog/post/dr-threat-actors-aws-workmail-phishing-campaigns)
|
||||
- [AWS WorkMail limits](https://docs.aws.amazon.com/workmail/latest/adminguide/limits.html)
|
||||
|
||||
{{#include ../../../../banners/hacktricks-training.md}}
|
||||
@@ -4,7 +4,7 @@
|
||||
|
||||
## IAM
|
||||
|
||||
Sie finden eine **Beschreibung von IAM** in:
|
||||
Eine **Beschreibung von IAM** findest du in:
|
||||
|
||||
{{#ref}}
|
||||
../aws-basic-information/
|
||||
@@ -12,9 +12,9 @@ Sie finden eine **Beschreibung von IAM** in:
|
||||
|
||||
### Enumeration
|
||||
|
||||
Hauptberechtigungen, die benötigt werden:
|
||||
Hauptsächlich benötigte Berechtigungen:
|
||||
|
||||
- `iam:ListPolicies`, `iam:GetPolicy` und `iam:GetPolicyVersion`
|
||||
- `iam:ListPolicies`, `iam:GetPolicy` and `iam:GetPolicyVersion`
|
||||
- `iam:ListRoles`
|
||||
- `iam:ListUsers`
|
||||
- `iam:ListGroups`
|
||||
@@ -22,9 +22,9 @@ Hauptberechtigungen, die benötigt werden:
|
||||
- `iam:ListAttachedUserPolicies`
|
||||
- `iam:ListAttachedRolePolicies`
|
||||
- `iam:ListAttachedGroupPolicies`
|
||||
- `iam:ListUserPolicies` und `iam:GetUserPolicy`
|
||||
- `iam:ListGroupPolicies` und `iam:GetGroupPolicy`
|
||||
- `iam:ListRolePolicies` und `iam:GetRolePolicy`
|
||||
- `iam:ListUserPolicies` and `iam:GetUserPolicy`
|
||||
- `iam:ListGroupPolicies` and `iam:GetGroupPolicy`
|
||||
- `iam:ListRolePolicies` and `iam:GetRolePolicy`
|
||||
```bash
|
||||
# All IAMs
|
||||
## Retrieves information about all IAM users, groups, roles, and policies
|
||||
@@ -88,37 +88,49 @@ aws iam get-account-password-policy
|
||||
aws iam list-mfa-devices
|
||||
aws iam list-virtual-mfa-devices
|
||||
```
|
||||
### Berechtigungen Brute Force
|
||||
### Stealth permission confirmation via intentional failures
|
||||
|
||||
Wenn Sie an Ihren eigenen Berechtigungen interessiert sind, aber keinen Zugriff haben, um IAM abzufragen, können Sie sie immer brute-forcen.
|
||||
Wenn `List*`- oder Simulator-APIs blockiert sind, können Sie **Berechtigungen für Änderungsvorgänge bestätigen, ohne dauerhafte Ressourcen zu erstellen**, indem Sie vorhersehbare Validierungsfehler erzwingen. AWS wertet IAM weiterhin aus, bevor diese Fehler zurückgegeben werden, sodass das Auftreten des Fehlers beweist, dass der Aufrufer die Aktion besitzt:
|
||||
```bash
|
||||
# Confirm iam:CreateUser without creating a new principal (fails only after authz)
|
||||
aws iam create-user --user-name <existing_user> # -> EntityAlreadyExistsException
|
||||
|
||||
# Confirm iam:CreateLoginProfile while learning password policy requirements
|
||||
aws iam create-login-profile --user-name <target_user> --password lower --password-reset-required # -> PasswordPolicyViolationException
|
||||
```
|
||||
Diese Versuche erzeugen weiterhin CloudTrail-Ereignisse (mit `errorCode` gesetzt), hinterlassen aber keine neuen IAM-Artefakte, wodurch sie während interactive recon nützlich für eine **geräuscharme Berechtigungsvalidierung** sind.
|
||||
|
||||
### Permissions Brute Force
|
||||
|
||||
Wenn Sie an Ihren eigenen Berechtigungen interessiert sind, aber keinen Zugriff haben, um IAM abzufragen, könnten Sie sie immer brute-force ermitteln.
|
||||
|
||||
#### bf-aws-permissions
|
||||
|
||||
Das Tool [**bf-aws-permissions**](https://github.com/carlospolop/bf-aws-permissions) ist nur ein Bash-Skript, das mit dem angegebenen Profil alle **`list*`, `describe*`, `get*`** Aktionen ausführt, die es mithilfe der `aws` CLI-Hilfenachrichten finden kann, und **die erfolgreichen Ausführungen zurückgibt**.
|
||||
Das Tool [**bf-aws-permissions**](https://github.com/carlospolop/bf-aws-permissions) ist nur ein bash-Skript, das mit dem angegebenen Profil alle **`list*`, `describe*`, `get*`** Aktionen ausführt, die es über die `aws` CLI-Hilfetexte finden kann, und **gibt die erfolgreichen Ausführungen zurück**.
|
||||
```bash
|
||||
# Bruteforce permissions
|
||||
bash bf-aws-permissions.sh -p default > /tmp/bf-permissions-verbose.txt
|
||||
```
|
||||
#### bf-aws-perms-simulate
|
||||
|
||||
Das Tool [**bf-aws-perms-simulate**](https://github.com/carlospolop/bf-aws-perms-simulate) kann Ihre aktuellen Berechtigungen (oder die von anderen Prinzipalen) finden, wenn Sie die Berechtigung **`iam:SimulatePrincipalPolicy`** haben.
|
||||
Das Tool [**bf-aws-perms-simulate**](https://github.com/carlospolop/bf-aws-perms-simulate) kann deine aktuellen Berechtigungen (oder die von anderen principals) ermitteln, wenn du die Berechtigung **`iam:SimulatePrincipalPolicy`** hast.
|
||||
```bash
|
||||
# Ask for permissions
|
||||
python3 aws_permissions_checker.py --profile <AWS_PROFILE> [--arn <USER_ARN>]
|
||||
```
|
||||
#### Perms2ManagedPolicies
|
||||
|
||||
Wenn Sie **einige Berechtigungen gefunden haben, die Ihr Benutzer hat**, und Sie denken, dass sie von einer **verwalteten AWS-Rolle** (und nicht von einer benutzerdefinierten) gewährt werden. Sie können das Tool [**aws-Perms2ManagedRoles**](https://github.com/carlospolop/aws-Perms2ManagedPolicies) verwenden, um alle **AWS-verwalteten Rollen zu überprüfen, die die Berechtigungen gewähren, die Sie entdeckt haben, dass Sie sie haben**.
|
||||
Wenn du **einige Berechtigungen deines Users** gefunden hast und denkst, dass sie von einer **managed AWS role** (und nicht von einer benutzerdefinierten) vergeben werden, kannst du das Tool [**aws-Perms2ManagedRoles**](https://github.com/carlospolop/aws-Perms2ManagedPolicies) verwenden, um alle **AWS managed roles** zu überprüfen, die die Berechtigungen gewähren, die du entdeckt hast.
|
||||
```bash
|
||||
# Run example with my profile
|
||||
python3 aws-Perms2ManagedPolicies.py --profile myadmin --permissions-file example-permissions.txt
|
||||
```
|
||||
> [!WARNING]
|
||||
> Es ist möglich zu "wissen", ob die Berechtigungen, die Sie haben, von einer AWS verwalteten Rolle gewährt wurden, wenn Sie sehen, dass **Sie Berechtigungen für Dienste haben, die nicht verwendet werden**.
|
||||
> Es ist möglich zu erkennen, ob die permissions, die Sie haben, von einer AWS managed role gewährt werden, wenn Sie zum Beispiel sehen, dass Sie permissions für services haben, die nicht genutzt werden.
|
||||
|
||||
#### Cloudtrail2IAM
|
||||
|
||||
[**CloudTrail2IAM**](https://github.com/carlospolop/Cloudtrail2IAM) ist ein Python-Tool, das **AWS CloudTrail-Protokolle analysiert, um Aktionen** zu extrahieren und zusammenzufassen, die von allen oder nur einem bestimmten Benutzer oder einer Rolle durchgeführt wurden. Das Tool wird **jedes CloudTrail-Protokoll aus dem angegebenen Bucket analysieren**.
|
||||
[**CloudTrail2IAM**](https://github.com/carlospolop/Cloudtrail2IAM) ist ein Python-Tool, das **AWS CloudTrail logs analysiert, um Aktionen zu extrahieren und zusammenzufassen**, die von allen oder nur einem bestimmten user oder role ausgeführt werden. Das Tool wird **jedes cloudtrail log aus dem angegebenen bucket parsen**.
|
||||
```bash
|
||||
git clone https://github.com/carlospolop/Cloudtrail2IAM
|
||||
cd Cloudtrail2IAM
|
||||
@@ -126,16 +138,16 @@ pip install -r requirements.txt
|
||||
python3 cloudtrail2IAM.py --prefix PREFIX --bucket_name BUCKET_NAME --profile PROFILE [--filter-name FILTER_NAME] [--threads THREADS]
|
||||
```
|
||||
> [!WARNING]
|
||||
> Wenn Sie .tfstate (Terraform-Zustandsdateien) oder CloudFormation-Dateien finden (diese sind normalerweise yaml-Dateien, die sich in einem Bucket mit dem Präfix cf-templates befinden), können Sie diese ebenfalls lesen, um aws-Konfigurationen zu finden und herauszufinden, welche Berechtigungen wem zugewiesen wurden.
|
||||
> Wenn du .tfstate (Terraform state files) oder CloudFormation-Dateien findest (das sind normalerweise yaml-Dateien, die sich in einem Bucket mit dem Präfix cf-templates befinden), kannst du diese ebenfalls lesen, um aws-Konfigurationen zu finden und herauszufinden, welche Berechtigungen wem zugewiesen wurden.
|
||||
|
||||
#### enumerate-iam
|
||||
|
||||
Um das Tool [**https://github.com/andresriancho/enumerate-iam**](https://github.com/andresriancho/enumerate-iam) zu verwenden, müssen Sie zuerst alle API AWS-Endpunkte herunterladen. Das Skript **`generate_bruteforce_tests.py`** wird dann alle **"list\_", "describe\_", und "get\_" Endpunkte** abrufen. Schließlich wird es versuchen, **auf diese zuzugreifen** mit den angegebenen Anmeldeinformationen und **anzeigen, ob es funktioniert hat**.
|
||||
Um das Tool [**https://github.com/andresriancho/enumerate-iam**](https://github.com/andresriancho/enumerate-iam) zu verwenden, musst du zuerst alle AWS API-Endpunkte herunterladen. Aus diesen extrahiert das Skript **`generate_bruteforce_tests.py`** alle **"list\_", "describe\_" und "get\_" Endpunkte.** Schließlich versucht es mit den angegebenen Anmeldeinformationen, **auf sie zuzugreifen** und **anzuzeigen, ob es funktioniert hat**.
|
||||
|
||||
(In meiner Erfahrung **hängt das Tool irgendwann**, [**sehen Sie sich diesen Fix an**](https://github.com/andresriancho/enumerate-iam/pull/15/commits/77ad5b41216e3b5f1511d0c385da8cd5984c2d3c), um zu versuchen, das zu beheben).
|
||||
(In meiner Erfahrung **hängt das Tool irgendwann**, [**siehe diesen Fix**](https://github.com/andresriancho/enumerate-iam/pull/15/commits/77ad5b41216e3b5f1511d0c385da8cd5984c2d3c), um das zu beheben).
|
||||
|
||||
> [!WARNING]
|
||||
> Meiner Erfahrung nach ist dieses Tool wie das vorherige, funktioniert jedoch schlechter und überprüft weniger Berechtigungen.
|
||||
> Meiner Erfahrung nach ist dieses Tool wie das vorherige, funktioniert aber schlechter und prüft weniger Berechtigungen
|
||||
```bash
|
||||
# Install tool
|
||||
git clone git@github.com:andresriancho/enumerate-iam.git
|
||||
@@ -154,7 +166,7 @@ python3 enumerate-iam.py --access-key ACCESS_KEY --secret-key SECRET_KEY [--sess
|
||||
```
|
||||
#### weirdAAL
|
||||
|
||||
Sie können auch das Tool [**weirdAAL**](https://github.com/carnal0wnage/weirdAAL/wiki) verwenden. Dieses Tool überprüft **mehrere gängige Operationen auf mehreren gängigen Diensten** (es werden einige Enumerationsberechtigungen und auch einige Privesc-Berechtigungen überprüft). Es werden jedoch nur die codierten Überprüfungen durchgeführt (der einzige Weg, um mehr zu überprüfen, besteht darin, weitere Tests zu codieren).
|
||||
Du kannst auch das Tool [**weirdAAL**](https://github.com/carnal0wnage/weirdAAL/wiki) verwenden. Dieses Tool prüft **mehrere gängige Operationen auf mehreren gängigen Diensten** (prüft einige enumeration permissions und auch einige privesc permissions). Es prüft jedoch nur die codierten Checks — die einzige Möglichkeit, mehr zu prüfen, ist, selbst weitere Tests zu schreiben.
|
||||
```bash
|
||||
# Install
|
||||
git clone https://github.com/carnal0wnage/weirdAAL.git
|
||||
@@ -178,7 +190,7 @@ python3 weirdAAL.py -m recon_all -t MyTarget # Check all permissions
|
||||
# [+] elbv2 Actions allowed are [+]
|
||||
# ['DescribeLoadBalancers', 'DescribeAccountLimits', 'DescribeTargetGroups']
|
||||
```
|
||||
#### Härtungswerkzeuge zur BF-Berechtigungen
|
||||
#### Hardening Tools für BF permissions
|
||||
|
||||
{{#tabs }}
|
||||
{{#tab name="CloudSploit" }}
|
||||
@@ -208,9 +220,9 @@ steampipe dashboard
|
||||
|
||||
#### \<YourTool>
|
||||
|
||||
Keines der vorherigen Tools ist in der Lage, nahezu alle Berechtigungen zu überprüfen, also wenn du ein besseres Tool kennst, sende einen PR!
|
||||
Keines der vorherigen Tools ist in der Lage, auch nur annähernd alle Berechtigungen zu prüfen. Wenn du ein besseres Tool kennst, sende bitte einen PR!
|
||||
|
||||
### Unauthenticated Access
|
||||
### Unauthentifizierter Zugriff
|
||||
|
||||
{{#ref}}
|
||||
../aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum/README.md
|
||||
@@ -218,7 +230,7 @@ Keines der vorherigen Tools ist in der Lage, nahezu alle Berechtigungen zu über
|
||||
|
||||
### Privilege Escalation
|
||||
|
||||
Auf der folgenden Seite kannst du überprüfen, wie man **IAM-Berechtigungen missbraucht, um Privilegien zu eskalieren**:
|
||||
Auf der folgenden Seite kannst du nachlesen, wie man **abuse IAM permissions to escalate privileges**:
|
||||
|
||||
{{#ref}}
|
||||
../aws-privilege-escalation/aws-iam-privesc/README.md
|
||||
@@ -238,13 +250,13 @@ Auf der folgenden Seite kannst du überprüfen, wie man **IAM-Berechtigungen mis
|
||||
|
||||
## IAM Identity Center
|
||||
|
||||
Du kannst eine **Beschreibung des IAM Identity Center** finden in:
|
||||
Du findest eine **Beschreibung des IAM Identity Center** in:
|
||||
|
||||
{{#ref}}
|
||||
../aws-basic-information/
|
||||
{{#endref}}
|
||||
|
||||
### Connect via SSO with CLI
|
||||
### Mit SSO über die CLI verbinden
|
||||
```bash
|
||||
# Connect with sso via CLI aws configure sso
|
||||
aws configure sso
|
||||
@@ -255,18 +267,18 @@ sso_account_id = <account_numbre>
|
||||
sso_role_name = AdministratorAccess
|
||||
sso_region = us-east-1
|
||||
```
|
||||
### Aufzählung
|
||||
### Enumeration
|
||||
|
||||
Die Hauptbestandteile des Identity Centers sind:
|
||||
Die Hauptelemente des Identity Center sind:
|
||||
|
||||
- Benutzer und Gruppen
|
||||
- Berechtigungssätze: Haben angehängte Richtlinien
|
||||
- AWS-Konten
|
||||
- Permission Sets: sind mit Policies verknüpft
|
||||
- AWS Accounts
|
||||
|
||||
Dann werden Beziehungen erstellt, sodass Benutzer/Gruppen Berechtigungssätze über das AWS-Konto haben.
|
||||
Anschließend werden Beziehungen erstellt, sodass Benutzer/Gruppen Permission Sets für AWS Accounts erhalten.
|
||||
|
||||
> [!NOTE]
|
||||
> Beachten Sie, dass es 3 Möglichkeiten gibt, Richtlinien an einen Berechtigungssatz anzuhängen. Anheften von AWS-verwalteten Richtlinien, von Kunden verwalteten Richtlinien (diese Richtlinien müssen in allen Konten erstellt werden, die der Berechtigungssatz betrifft) und Inline-Richtlinien (dort definiert).
|
||||
> Beachte, dass es 3 Möglichkeiten gibt, Policies an ein Permission Set anzuhängen: AWS managed policies, Customer managed policies (diese Policies müssen in allen Accounts erstellt werden, die vom Permission Set betroffen sind), und inline policies (dort definiert).
|
||||
```bash
|
||||
# Check if IAM Identity Center is used
|
||||
aws sso-admin list-instances
|
||||
@@ -300,7 +312,7 @@ aws identitystore list-group-memberships --identity-store-id <store-id> --group-
|
||||
## Get memberships or a user or a group
|
||||
aws identitystore list-group-memberships-for-member --identity-store-id <store-id> --member-id <member-id>
|
||||
```
|
||||
### Lokale Enumeration
|
||||
### Local Enumeration
|
||||
|
||||
Es ist möglich, im Ordner `$HOME/.aws` die Datei config zu erstellen, um Profile zu konfigurieren, die über SSO zugänglich sind, zum Beispiel:
|
||||
```ini
|
||||
@@ -320,16 +332,16 @@ output = json
|
||||
role_arn = arn:aws:iam::<acc-id>:role/ReadOnlyRole
|
||||
source_profile = Hacktricks-Admin
|
||||
```
|
||||
Diese Konfiguration kann mit den Befehlen verwendet werden:
|
||||
Diese Konfiguration kann mit den folgenden Befehlen verwendet werden:
|
||||
```bash
|
||||
# Login in ms-sso-profile
|
||||
aws sso login --profile my-sso-profile
|
||||
# Use dependent-profile
|
||||
aws s3 ls --profile dependent-profile
|
||||
```
|
||||
Wenn ein **Profil von SSO verwendet wird**, um auf Informationen zuzugreifen, werden die Anmeldeinformationen **in einer Datei im Ordner** **`$HOME/.aws/sso/cache`** **zwischengespeichert**. Daher können sie **von dort gelesen und verwendet werden**.
|
||||
Wenn ein **Profil aus SSO verwendet wird**, um auf Informationen zuzugreifen, werden die **Anmeldeinformationen** in einer Datei im Ordner **`$HOME/.aws/sso/cache`** zwischengespeichert. Daher können sie **dort gelesen und verwendet werden**.
|
||||
|
||||
Darüber hinaus können **weitere Anmeldeinformationen** im Ordner **`$HOME/.aws/cli/cache`** gespeichert werden. Dieses Cache-Verzeichnis wird hauptsächlich verwendet, wenn Sie mit **AWS CLI-Profilen** arbeiten, die IAM-Benutzeranmeldeinformationen verwenden oder Rollen über IAM (ohne SSO) **annehmen**. Konfigurationsbeispiel:
|
||||
Außerdem können **weitere Anmeldeinformationen** im Ordner **`$HOME/.aws/cli/cache`** gespeichert werden. Dieses Cache-Verzeichnis wird hauptsächlich verwendet, wenn Sie **mit AWS CLI profiles** arbeiten, die IAM-Benutzer-Anmeldeinformationen verwenden oder Rollen über IAM **übernehmen** (ohne SSO). Konfigurationsbeispiel:
|
||||
```ini
|
||||
[profile crossaccountrole]
|
||||
role_arn = arn:aws:iam::234567890123:role/SomeRole
|
||||
@@ -337,19 +349,19 @@ source_profile = default
|
||||
mfa_serial = arn:aws:iam::123456789012:mfa/saanvi
|
||||
external_id = 123456
|
||||
```
|
||||
### Unauthentifizierter Zugriff
|
||||
### Nicht authentifizierter Zugriff
|
||||
|
||||
{{#ref}}
|
||||
../aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum/README.md
|
||||
{{#endref}}
|
||||
|
||||
### Privilegienerweiterung
|
||||
### Privilegieneskalation
|
||||
|
||||
{{#ref}}
|
||||
../aws-privilege-escalation/aws-sso-and-identitystore-privesc/README.md
|
||||
{{#endref}}
|
||||
|
||||
### Nach der Ausnutzung
|
||||
### Nach der Kompromittierung
|
||||
|
||||
{{#ref}}
|
||||
../aws-post-exploitation/aws-sso-and-identitystore-post-exploitation/README.md
|
||||
@@ -357,16 +369,16 @@ external_id = 123456
|
||||
|
||||
### Persistenz
|
||||
|
||||
#### Erstellen Sie einen Benutzer und weisen Sie ihm Berechtigungen zu
|
||||
#### Erstelle einen Benutzer und weise ihm Berechtigungen zu
|
||||
```bash
|
||||
# Create user identitystore:CreateUser
|
||||
aws identitystore create-user --identity-store-id <store-id> --user-name privesc --display-name privesc --emails Value=sdkabflvwsljyclpma@tmmbt.net,Type=Work,Primary=True --name Formatted=privesc,FamilyName=privesc,GivenName=privesc
|
||||
## After creating it try to login in the console using the selected username, you will receive an email with the code and then you will be able to select a password
|
||||
```
|
||||
- Erstellen Sie eine Gruppe und weisen Sie ihr Berechtigungen zu und setzen Sie einen kontrollierten Benutzer darauf
|
||||
- Gewähren Sie einem kontrollierten Benutzer oder einer Gruppe zusätzliche Berechtigungen
|
||||
- Standardmäßig können nur Benutzer mit Berechtigungen aus dem Management-Konto auf das IAM Identity Center zugreifen und es steuern.
|
||||
- Erstelle eine Gruppe, weise ihr Berechtigungen zu und weise einen kontrollierten Benutzer zu
|
||||
- Gewähre einem kontrollierten Benutzer oder einer Gruppe zusätzliche Berechtigungen
|
||||
- Standardmäßig können nur Benutzer mit Berechtigungen aus dem Management Account auf das IAM Identity Center zugreifen und es verwalten.
|
||||
|
||||
Es ist jedoch möglich, über den Delegierten Administrator Benutzern aus einem anderen Konto die Verwaltung zu ermöglichen. Sie werden nicht genau die gleichen Berechtigungen haben, aber sie werden in der Lage sein, [**Verwaltungsaktivitäten**](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html) durchzuführen.
|
||||
Es ist jedoch möglich, über Delegate Administrator Benutzern aus einem anderen Account die Verwaltung zu erlauben. Sie haben nicht genau die gleichen Berechtigungen, aber sie können [**management activities**](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html) durchführen.
|
||||
|
||||
{{#include ../../../banners/hacktricks-training.md}}
|
||||
|
||||
Reference in New Issue
Block a user