На прошлогодней операции мы потеряли три недели подготовки из-за одной строчки. Оператор подключился к целевому SMB-ресурсу, и в NTLM-хендшейке улетело имя машины -
YOURNAME-LAPTOP. SOC заказчика вытащил hostname из Sysmon Event ID 3, сопоставил с LinkedIn-профилем коллеги, и через два часа операция была раскрыта. Hostname. Который никто не проверил перед выходом на цель. Десять секунд на hostname в терминале - и шесть месяцев работы не превратились бы в историю для конференции. Проверка рабочей станции перед red team - не ритуал параноика, а разница между операцией на полгода и операцией, которая закончилась в первый день.Зачем проверять рабочую станцию перед red team операцией
Когда blue team ловит артефакт с вашей рабочей станции, они получают не просто индикатор компрометации - они получают точку атрибуции. Реальный hostname в Kerberos-тикете. MAC-адрес физического адаптера в ARP-таблице. User-Agent с уникальной конфигурацией браузера. DNS-запрос к домашнему резолверу, проскочивший мимо VPN-туннеля.По данным ForgeBound Research, большинство провалов OPSEC - не одна критическая утечка, а агрегация мелких, по отдельности безобидных деталей. LinkedIn-обновление, timestamp GitHub-коммита и анонс доклада на конференции - ничего чувствительного по отдельности, но вместе они идентифицируют оператора и клиента. Рабочая станция работает по той же логике: hostname + часовой пояс + версия PowerShell + user-agent = уникальный отпечаток, который привязывается к конкретному человеку.
Red team подготовка начинается не с выбора C2-фреймворка и не с закупки инфраструктуры. Она начинается с проверки окружения перед атакой - того, с чего вы будете оперировать. Если рабочая станция «фонит», любой beacon понесёт следы, ведущие к вам. По сути, вы выполняете те же техники Discovery из MITRE ATT&CK (T1082, T1033, T1049), только направленные на собственную систему: ищете то, что blue team найдёт, анализируя ваш трафик и артефакты.
Проверка сетевой изоляции и утечек трафика
DNS-утечки и VPN kill switch
[Применимо: внешний пентест, любая инфраструктура]DNS-утечка - самый частый и самый тихий провал OPSEC. VPN поднят, трафик идёт через туннель, а DNS-запросы тихо уходят на резолвер провайдера. Blue team с доступом к Passive DNS видит запрос к вашему C2-домену с IP жилого провайдера - и получает географию оператора. Поздравляю, вы только что сдали свой город.
Требования к окружению: ОС Linux/Windows/macOS, активный VPN-туннель (OpenVPN, WireGuard или коммерческий), доступ в интернет.
На Linux проверка начинается с
cat /etc/resolv.conf - nameserver должен указывать на VPN-шлюз или локальный резолвер (127.0.0.53 при systemd-resolved), а не на 192.168.1.1 домашнего роутера. Далее - nslookup whoami.akamai.net и проверка, через какой интерфейс ушёл запрос. На Windows: Get-DnsClientServerAddress в PowerShell покажет DNS-серверы на каждом интерфейсе - если на физическом адаптере висит DNS провайдера, запросы пойдут мимо туннеля.Работает если: VPN-клиент форсирует full-tunnel и переключает DNS. Не работает если: используется split-tunnel VPN - на большинстве конфигураций Windows DNS по умолчанию уходит через основной интерфейс. На macOS
scutil --dns покажет реальную картину: система любит игнорировать VPN DNS для .local доменов, и это не баг - это by design.Kill switch обязателен. Без него при разрыве VPN трафик переключается на основной интерфейс, и следующий beacon полетит с реального IP. На Linux решается правилами
iptables/nftables, блокирующими исходящий трафик мимо tun-интерфейса. Проверка: отключите VPN и выполните curl -s ifconfig.co. Если вернулся IP - kill switch не работает. И лучше узнать об этом сейчас, а не из отчёта SOC заказчика.WebRTC и IPv6-утечки
[Применимо: внешний пентест, операции с использованием браузера]WebRTC раскрывает локальный IP даже через VPN - вектор древний, но его по-прежнему забывают проверить. Зайдите на
browserleaks.com/webrtc через рабочий браузер и убедитесь, что в разделе Local IP нет адресов реальной сети. Отключение: в Firefox - media.peerconnection.enabled = false в about:config. В Chromium-based - расширение WebRTC Control или флаг --disable-webrtc.IPv6 - отдельная головная боль для OPSEC red team. VPN может туннелировать только IPv4, а IPv6 трафик пойдёт напрямую. Проверка:
curl -6 -s --max-time 3 ifconfig.co - если вернулся адрес, IPv6 не туннелируется. На Linux отключается через sysctl -w net.ipv6.conf.all.disable_ipv6=1, на Windows - через свойства адаптера (снять галку «Internet Protocol Version 6»).Аудит системных идентификаторов рабочей станции
Hostname и username
[Применимо: внутренний пентест, lateral movement, legacy и modern инфраструктура]Hostname утечёт в десятках мест: SMB-хендшейки, Kerberos-запросы, NTLM-аутентификация, DHCP-запросы, mDNS/LLMNR-анонсы. Прямая аналогия с техникой System Owner/User Discovery (T1033, Discovery): blue team использует те же методы, чтобы определить источник подключения.
Проверка:
hostname на Linux/macOS, $env:COMPUTERNAME в PowerShell. Имя должно быть нейтральным - DESKTOP-A1B2C3D, PC-2024-WRK. Ничего, что содержит ваше имя, фамилию или название компании-подрядчика. Я видел станцию с hostname REDTEAM-ATTACK - серьёзно, кто-то так назвал свою рабочую машину.Username проверяется через
whoami. Если работаете под ivan.petrov, любой сетевой хендшейк выдаст имя оператора. Для операций создайте отдельную учётную запись с нейтральным именем.Работает если: станция под полным контролем (personal device, выделенная VM). Не работает если: корпоративная доменная машина - NTLM-хеш содержит исходные данные даже при смене отображаемого имени. Единственный вариант - выделенная VM с чистым профилем. Compartmentalization из методологии OPSEC: ни одна система не получает больше контекста, чем требует функция.
MAC-адрес и сетевые адаптеры
[Применимо: внутренний пентест, физический доступ к целевой сети]MAC-адрес физического адаптера связывает станцию с конкретным устройством при подключении к корпоративной сети. Он попадает в ARP-таблицы, DHCP-логи, RADIUS-журналы - любой из этих источников доступен blue team. Техника System Network Connections Discovery (T1049, Discovery) описывает именно такой сбор информации защитниками.
На Linux:
ip link show для просмотра, macchanger -r eth0 для рандомизации. На Windows: Get-NetAdapter | Select Name, MacAddress для просмотра, смена через свойства адаптера или реестр.Ограничение: Wi-Fi-адаптеры в режиме мониторинга могут сбрасывать спуфленный MAC при смене канала. Некоторые драйверы тупо игнорируют программную подмену - после применения обязательно проверьте результат через
ip link show. Доверяй, но проверяй.Ревизия процессов и защитного ПО на рабочей станции
Обнаружение телеметрии и корпоративных агентов
[Применимо: любой тип пентеста, внутренний и внешний]Настройка рабочей станции для пентеста включает аудит всего, что на ней запущено. Зеркало техник Process Discovery (T1057, Discovery) и Security Software Discovery (T1518.001, Discovery), направленных на собственную машину. Telemetry-клиенты, EDR/AV-агенты на атакующей станции перехватывают payload'ы, отправляют хеши в облако и компрометируют ваш инструментарий ещё до его доставки на цель. На одном проекте коллега собрал кастомный лоадер, а Defender на его же станции тихо отправил хеш в Microsoft - через неделю сигнатура уже была в базе.
На Windows:
Get-Process | Select-Object ProcessName, Path | Sort-Object ProcessName покажет все процессы. Ищите: MsMpEng (Windows Defender), CSFalconService (CrowdStrike), cb (Carbon Black), SentinelAgent, а также корпоративные агенты - Tanium, SCCM-клиент, DLP-системы.На Linux:
ps aux --sort=-%mem | head -30 + systemctl list-units --type=service --state=running для проверки автозагрузки.Работает если: станция полностью под вашим контролем. Не работает если: корпоративная машина с GPO - агенты переустанавливаются централизованно. Единственный вариант - выделенная изолированная станция или VM без корпоративного управления.
VM-маркеры и sandbox-проверка
Если payload'ы разрабатываются и тестируются на той же станции, с которой выходите на операцию, проверьте VM-маркеры. Некоторые защитные решения на стороне цели проверяют характеристики подключающейся системы: имена VM-адаптеров (VMware, VirtualBox), характерные MAC-префиксы виртуальных карт (00:0C:29, 08:00:27), guest additions. Техника System Information Discovery (T1082, Discovery) работает в обе стороны.На Windows:
Get-WmiObject Win32_ComputerSystem | Select-Object Manufacturer, Model - если возвращает VMware, Inc. или innotek GmbH, sandbox-detection на целевой стороне может это распознать.Ограничение: маскировка гипервизора через вложенную виртуализацию добавляет сложность и может ломать сетевые адаптеры. Для критичных операций надёжнее выделенная физическая машина.
Очистка метаданных артефактов
Каждый файл, создаваемый оператором, несёт метаданные. DOCX для фишинговой кампании содержит имя автора из учётной записи Office. PDF - timestamp создания и ПО-генератор. Изображение - EXIF с GPS-координатами, моделью устройства, серийным номером. Однажды видел фишинговый документ, где в свойствах стоял автор «Иванов И.И., ООО Безопасность». Занавес.На Linux:
exiftool -all= filename.jpg удалит EXIF. Для Office-документов проще создавать их в чистой VM с нейтральной учёткой, чем вычищать свойства постфактум.Git-конфигурация - отдельная ловушка при подготовке к red team операции. Приватный репозиторий с payload'ами:
git config user.name и git config user.email содержат реальные данные. При случайном пуше в публичный репозиторий - прямая атрибуция. Проверка: git config --global --list | grep user. Три секунды.ForgeBound Research справедливо отмечает: WHOIS-запись с реальным именем на тестовом домене, TLS-сертификат на личную почту, комментарий в коде с упоминанием аффилиации - каждый артефакт по отдельности безвреден. В совокупности - полная деанонимизация оператора.
Проверка браузерного fingerprint и разделение контекстов
[Применимо: внешний пентест, социальная инженерия, phishing-кампании]Если операция включает работу через браузер - web-разведка, фишинговые страницы, взаимодействие с web-приложениями цели - браузерный отпечаток должен быть проверен. Зайдите на
amiunique.org или browserleaks.com и оцените уникальность: Canvas fingerprint, WebGL renderer, установленные шрифты, разрешение экрана.Работает если: используете отдельный профиль браузера или выделенный Firefox с модифицированным
about:config (resist fingerprinting). Не работает если: работаете через основной браузер с расширениями, авторизованными аккаунтами Google/Yandex и историей. JavaScript на целевом ресурсе соберёт fingerprint, который при перекрёстном анализе свяжет операционную активность с вашей повседневной.Operational security пентестера строится на compartmentalization: операционный браузер - отдельный профиль, отдельные закладки, отдельная история. Если один контекст привлекает внимание - вы «сливаете» его, не теряя второй.
Автоматизация pre-flight проверок
Чек-лист пентестера, который проходится вручную, рано или поздно пропускается. Человеческий фактор - главная причина OPSEC-провалов: ForgeBound Research отмечает, что усталость, стресс и спешка - моменты, когда сообщение уходит не в тот канал, а credential коммитится в публичный репозиторий. Автоматизация - единственный способ это снять.Скрипт для Linux, который запускается при логине или перед операцией:
Bash:
#!/bin/bash
# Pre-flight OPSEC check
echo "[*] Hostname: $(hostname)"
echo "[*] Username: $(whoami)"
echo "[*] DNS: $(grep nameserver /etc/resolv.conf | awk '{print $2}')"
echo "[*] External IP: $(curl -s --max-time 5 ifconfig.co)"
echo "[*] IPv6: $(curl -6 -s --max-time 3 ifconfig.co || echo 'disabled')"
echo "[*] MAC:" && ip link show | grep ether
echo "[*] VM: $(cat /sys/class/dmi/id/sys_vendor 2>/dev/null || echo 'N/A')"
echo "[*] Git user: $(git config --global user.name 2>/dev/null || echo 'not set')"
Код:
# Pre-flight OPSEC check - Windows
Write-Host "[*] Hostname: $env:COMPUTERNAME"
Write-Host "[*] Username: $env:USERNAME"
Get-DnsClientServerAddress | Where {$_.ServerAddresses} | Select InterfaceAlias,ServerAddresses
Write-Host "[*] External IP:" (Invoke-RestMethod -Uri ifconfig.co -TimeoutSec 5)
Get-NetAdapter | Select Name, MacAddress
(Get-WmiObject Win32_ComputerSystem).Manufacturer
Get-Process | Where {$_.ProcessName -match "MsMpEng|Falcon|Tanium|Carbon|Sentinel"}
.bashrc / $PROFILE или в задачу автозагрузки. Любая аномалия - красный флаг до выхода на цель.Минилаб для отработки
Требования к окружению: гипервизор (VirtualBox 7.x / VMware Workstation 17+), RAM минимум 8 GB (4 GB на VM), ОС: Kali Linux 2024.x или Parrot OS, VPN-конфиг (подойдёт бесплатный ProtonVPN), доступ в интернет.Разверните чистую VM, подключите VPN и пройдите чек-лист по каждому пункту. Намеренно оставьте hostname
kali, username kali, не настраивайте kill switch - затем отключите VPN и выполните curl ifconfig.co. Зафиксируйте, что именно утечёт без подготовки. Лучше увидеть это в лабе, чем на контракте стоимостью несколько миллионов.Финальный чек-лист OPSEC red team
📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме
Эту таблицу стоит распечатать или вставить в вики команды. Первичная проверка перед пентестом занимает 10-15 минут. Стоимость пропуска одного пункта - от раскрытия операции до потери контракта.
Девять из десяти OPSEC-провалов, с которыми я сталкивался, были не техническими - они были организационными. Не «забыл настроить kill switch», а «не было привычки проверять kill switch каждый раз». Разница принципиальная. Чек-лист - не документ, который ты читаешь перед первой операцией. Это привычка, работающая на автомате, как пилот проходит preflight check перед каждым вылетом. Даже если летает двадцать лет. В red team комьюнити часто звучит: «У нас опытная команда, мы это помним». А потом
IVAN-WORK всплывает в Sysmon-логах заказчика.Отдельная история - уставшие операторы. Два часа ночи, beacon потерял связь, VPN-клиент тихо переподключился на другой exit node, и последние пять минут C2-трафик летит с реального IP. Автоматизация через pre-flight скрипт, который запускается при каждом логине и блокирует работу при обнаружении проблемы - единственный надёжный способ снять этот фактор. Не дисциплина оператора, а инженерное решение.
Подготовка к red team операции - не про выбор между Cobalt Strike и Sliver. Это про дисциплину, которая не позволяет выйти с непроверенной станцией. Пока в русскоязычном сообществе обсуждают фичи C2-фреймворков, никто толком не проговаривает, что любой из них бесполезен, если DNS утечёт мимо туннеля в первый час работы. Если хочешь повторить шаги в контролируемой инфре - лаба OPSEC на HackerLab.