Ноутбук на антистатическом коврике с приоткрытой крышкой, на экране терминал с чек-листом проверки и янтарным индикатором тревоги рядом со строкой имени хоста. Тёплый акцентный свет скользит по гра...


На прошлогодней операции мы потеряли три недели подготовки из-за одной строчки. Оператор подключился к целевому 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')"
Эквивалент для Windows:
Код:
# 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.
 
Мы в соцсетях:

Взломай свой первый сервер и прокачай скилл — Начни игру на HackerLab

Похожие темы

🚀 Первый раз на Codeby?
Гайд для новичков: что делать в первые 15 минут, ключевые разделы, правила
Начать здесь →
🧭 Навигатор · ИБ 2026
Не знаешь, какой трек твой?
5 направлений ИБ, реальные зарплаты и точка входа для каждого — в одном треде.
JuniorSenior+
100K → 600K+ ₽ /мес
Открыть навигатор →
🔴 Свежие CVE, 0-day и инциденты
То, о чём ChatGPT ещё не знает — обсуждаем в реальном времени
Threat Intel →
💼 Вакансии и заказы в ИБ
Pentest, SOC, DevSecOps, bug bounty — работа и проекты от проверенных компаний
Карьера в ИБ →

HackerLab