Профессиональный пентестинг: углубленный курс для специалистов ИБ

Методологии проведения пентеста (PTES, OSSTMM) и техники продвинутой разведки

Коллеги, приветствую вас на курсе. Учитывая ваш бэкграунд в информационной безопасности, мы пропустим базовые определения того, что такое IP-адрес или зачем нужна конфиденциальность. Мы переходим сразу к профессиональной плоскости: как превратить хаотичный взлом в структурированный, измеримый и безопасный для бизнеса процесс.

В этой статье мы разберем два столпа профессионального пентестинга — стандарты PTES и OSSTMM, а также углубимся в техники разведки (Reconnaissance), которые выходят за рамки простого поиска в Google.

Зачем нужны методологии?

Главное отличие «этичного хакера» от киберпреступника — не только наличие разрешения, но и качество отчета. Заказчику не нужен просто «root» на сервере. Ему нужно понимание рисков, воспроизводимость атаки и гарантия того, что вы проверили всю согласованную область, а не только то, что легко ломалось.

Методологии позволяют:

Стандартизировать процесс. Вы и ваша команда действуете по единому алгоритму.

Обеспечить покрытие. Вы не забудете проверить специфические векторы.

Юридически защититься. Четкое следование этапам (особенно Pre-engagement) спасает от судебных исков.

PTES: Penetration Testing Execution Standard

PTES — это де-факто стандарт индустрии, описывающий полный жизненный цикл теста на проникновение. Он фокусируется на процессе.

!Визуализация семи основных этапов стандарта PTES

Ключевые этапы PTES

Мы не будем разбирать каждый шаг детально (это темы будущих статей), но остановимся на критически важных для старта:

Pre-engagement Interactions (Предпроектное взаимодействие). Это самый важный этап для менеджера и лида команды. Здесь определяются:

Scope (Область действия): IP-адреса, домены, приложения. Что можно трогать, а что нельзя*. * RoE (Rules of Engagement): Правила вовлечения. Можно ли проводить DoS? Можно ли использовать социальную инженерию? В какое время проводить атаки?

Intelligence Gathering (Сбор информации). Разведка, о которой мы поговорим ниже.

Threat Modeling (Моделирование угроз). Вы должны думать как злоумышленник, актуальный именно для этой компании. Кто их враг? Скрипт-кидди, конкуренты или APT-группировка?

Reporting (Отчетность). Результат вашей работы — это отчет, а не взломанная система. Отчет должен содержать как технические детали для админов, так и Executive Summary для бизнеса.

OSSTMM: Open Source Security Testing Methodology Manual

Если PTES — это про «как делать», то OSSTMM (разработан ISECOM) — это про «как измерить». Это научный подход к тестированию безопасности.

OSSTMM фокусируется на проверке операционной безопасности (OpSec) через 5 каналов: * Human (Человеческий): Социальная инженерия. * Physical (Физический): СКУД, камеры, заборы. * Wireless (Беспроводной): Wi-Fi, Bluetooth, RFID. * Telecommunications (Телекоммуникационный): VoIP, телефонные сети. * Data Networks (Сети передачи данных): Классический пентест сети.

Главная фишка OSSTMM — метрика RAV (Risk Assessment Values). Она позволяет дать количественную оценку безопасности в моменте, что очень любят CISO и риск-менеджеры.

Продвинутая разведка (Advanced Reconnaissance)

Разведка — это 70% успеха атаки. Чем больше вы знаете о цели, тем меньше шума вы создадите при эксплуатации. Мы разделим разведку на пассивную (без прямого контакта с инфраструктурой цели) и активную.

Certificate Transparency (CT) Logs

Современный веб построен на HTTPS. Центры сертификации (CA) обязаны публиковать информацию о выданных сертификатах в публичные логи (CT logs). Это золотая жила для пентестера.

Анализируя CT logs (например, через сервис crt.sh), вы можете найти: * Поддомены, созданные для разработки (dev.example.com, staging.example.com). * Внутренние сервисы, которые случайно получили публичный сертификат (vpn.internal.example.com). * Связанные бренды и дочерние компании.

ASN и картографирование инфраструктуры

Для крупных компаний простого nslookup недостаточно. Вам нужно найти всю автономную систему (ASN).

Находим IP-адрес основного домена.

Определяем ASN, к которой принадлежит IP (через bgp.he.net или RIPE DB).

Выгружаем все префиксы (подсети), анонсируемые этой ASN.

Это позволяет найти «забытые» подсети, которые администраторы могли не указать в Scope, но которые юридически принадлежат компании (важно согласовать их проверку с заказчиком!).

Математика перебора поддоменов (Subdomain Bruteforcing)

Пассивный сбор (OSINT) не всегда дает 100% покрытия. Иногда приходится прибегать к активному перебору поддоменов. Здесь важно понимать комбинаторику, чтобы оценить время атаки и выбрать правильный словарь.

Количество возможных вариантов при полном переборе (brute-force) рассчитывается по формуле размещения с повторениями:

Где: * — общее количество возможных вариантов поддоменов. * — мощность алфавита (например, 37 символов: a-z, 0-9 и дефис). * — длина поддомена.

Пример: Если мы хотим перебрать все поддомены длиной 4 символа, используя латиницу и цифры (36 символов), то вариантов. Это быстро. Но если длина 8 символов, то . Это уже займет годы.

Именно поэтому в профессиональном пентестинге мы используем словарные атаки (dictionary attacks) и перестановки (permutations), а не чистый перебор. Инструменты вроде Amass или massdns используют списки популярных слов (dev, mail, test), что сокращает пространство поиска до размера словаря (обычно от 10k до 100k строк), делая атаку эффективной.

Техники Fingerprinting (Снятие отпечатков)

Помимо стандартного сканирования портов, профессионалы используют тонкий фингерпринтинг:

* Анализ HTTP-заголовков: Порядок заголовков, специфичные куки (например, BIGipServer выдает балансировщик F5). * Хэширование иконок (Favicon): Фреймворки и CMS часто имеют стандартные иконки. Вычисляя MurmurHash иконки, можно найти все активы компании, использующие, например, старую версию Spring Boot, через поисковики типа Shodan.

!Поток данных при проведении комплексной разведки инфраструктуры

Резюме

PTES дает нам структуру процесса и правила игры.

OSSTMM дает метрики и научный подход к каналам безопасности.

Продвинутая разведка строится не на запуске сканера, а на понимании архитектуры интернета (BGP, DNS, SSL/TLS) и умении работать с большими данными.

В следующей статье мы перейдем от разведки к активному сканированию уязвимостей и анализу полученных данных.

Компрометация сетевой инфраструктуры и векторы атак на Active Directory

Коллеги, мы завершили этап разведки. Теперь у нас есть список IP-адресов, доменных имен и, возможно, понимание используемых технологий. Настало время перейти к активной фазе — получению первоначального доступа и повышению привилегий внутри корпоративной сети.

В этой статье мы разберем, как злоумышленники эксплуатируют недостатки протоколов локальной сети для перехвата учетных данных, и детально изучим архитектуру атак на Active Directory (AD). Учитывая ваш профиль, мы не будем тратить время на объяснение того, что такое контроллер домена, а сосредоточимся на механике эксплуатации протокола Kerberos и NTLM.

Атаки на уровне сетевых протоколов (Network Layer)

Прежде чем атаковать сам контроллер домена (DC), пентестеру часто необходимо получить валидную учетную запись пользователя домена. Самый быстрый способ сделать это, находясь во внутренней сети, — атаки типа Man-in-the-Middle (MitM) на протоколы разрешения имен.

LLMNR и NBT-NS Poisoning

В средах Windows, если DNS-сервер не может разрешить имя хоста, система обращается к широковещательным протоколам: LLMNR (Link-Local Multicast Name Resolution) и NBT-NS (NetBIOS Name Service). Это легаси-механизмы, включенные по умолчанию для совместимости.

Суть атаки:

Жертва ошибается при вводе адреса сетевого ресурса (например, \\fileserver вместо \\fileserver01).

DNS возвращает ошибку.

ПК жертвы отправляет широковещательный запрос: «Кто знает IP для fileserver?».

Пентестер (используя инструмент Responder) отвечает: «Я fileserver, вот мой IP».

Жертва пытается аутентифицироваться на машине атакующего, отправляя NTLMv2-хэш своего пароля.

Полученный хэш можно либо попытаться взломать оффлайн (Brute-force), либо использовать в атаке NTLM Relay.

IPv6 и атака mitm6

Более современный вектор — эксплуатация приоритета IPv6 над IPv4. Windows по умолчанию запрашивает конфигурацию IPv6 через DHCPv6. Атакующий может поднять мошеннический DHCPv6-сервер, выдать себя за DNS-сервер и перенаправить весь трафик жертвы через себя. Это часто позволяет обойти защиту от NTLM Relay и сразу создать новую учетную запись администратора, если целью атаки стал сервер.

Разведка в Active Directory

Получив доступ к любой доменной учетной записи (даже с минимальными правами), мы получаем доступ к чтению большинства объектов в AD. Это особенность архитектуры: Directory Service предназначен для того, чтобы пользователи могли находить ресурсы.

Для построения графа атак мы используем BloodHound. Этот инструмент визуализирует скрытые связи: кто является локальным админом где, у кого есть права на смену паролей (ForceChangePassword) и какие сессии активны.

!Визуализация пути атаки (Attack Path) в Active Directory через вложенные группы и права доступа.

Атаки на протокол Kerberos

Kerberos — это сердце аутентификации в AD. Он считается надежным, но имеет архитектурные особенности, позволяющие проводить атаки без отправки эксплойтов, используя только штатный функционал.

Kerberoasting

Эта техника позволяет запросить билет доступа к сервису (TGS — Ticket Granting Service) для любой учетной записи, у которой установлен атрибут SPN (Service Principal Name). Обычно это сервисные аккаунты (SQL, IIS), которые часто имеют слабые пароли и высокие привилегии.

Механика:

Мы запрашиваем TGS для сервиса у контроллера домена (KDC).

KDC выдает билет, зашифрованный на пароле сервисного аккаунта (обычно RC4 или AES).

Мы сохраняем билет на диск и переходим к оффлайн-перебору пароля.

Успех атаки зависит от сложности пароля. Время перебора () можно оценить по формуле:

где — время, необходимое для перебора всего пространства ключей, — количество возможных комбинаций паролей (пространство поиска), а — скорость перебора (хэшей в секунду).

Пространство поиска рассчитывается как:

где — количество комбинаций, — мощность алфавита (количество используемых символов), — длина пароля. Если пароль сервисного аккаунта короткий и простой, мы получим его в открытом виде за считанные минуты.

AS-REP Roasting

В Kerberos первый этап аутентификации (AS-REQ) требует предварительной аутентификации (Pre-Authentication) — шифрования метки времени паролем пользователя. Однако, для некоторых старых аккаунтов эта опция может быть отключена (флаг DONT_REQ_PREAUTH).

Для таких пользователей мы можем запросить билет AS-REP без знания пароля. KDC вернет зашифрованную часть билета, которую мы также можем брутфорсить оффлайн.

Повышение привилегий и боковое перемещение (Lateral Movement)

Pass-the-Hash (PtH) и Pass-the-Ticket (PtT)

Если у нас есть NTLM-хэш (из дампа LSASS или SAM), нам не нужно знать пароль в открытом виде для аутентификации по протоколу NTLM. Мы просто передаем хэш. Это называется Pass-the-Hash.

Аналогично для Kerberos: если мы скомпрометировали машину и выгрузили билеты (TGT или TGS) из памяти процесса lsass.exe, мы можем импортировать их в свою сессию и действовать от имени пользователя, пока не истечет время жизни билета (обычно 10 часов). Это Pass-the-Ticket.

Silver Ticket и Golden Ticket

Это техники закрепления (Persistence), основанные на подделке билетов.

Silver Ticket: Если мы узнали NTLM-хэш сервисного аккаунта (например, MSSQL), мы можем сами сгенерировать валидный TGS-билет для этого сервиса с любыми правами и любым именем пользователя. KDC в этом процессе не участвует.

Golden Ticket: Если мы скомпрометировали контроллер домена и получили хэш учетной записи krbtgt, мы можем генерировать TGT-билеты (Ticket Granting Ticket). Это дает нам полный контроль над доменом. Мы можем выдать себе билет с правами Domain Admin сроком на 10 лет.

DCSync: Финальный аккорд

Когда права администратора домена получены, нет необходимости заходить на каждый контроллер домена для дампа базы ntds.dit. Мы можем использовать атаку DCSync.

Суть атаки заключается в симуляции процесса репликации. Мы обращаемся к DC по протоколу DRSUAPI (Directory Replication Service Remote Protocol) и просим: «Привет, я соседний контроллер домена, отдай мне хэши паролей для пользователя Administrator (или krbtgt)».

Для выполнения этой атаки нужны права DS-Replication-Get-Changes и DS-Replication-Get-Changes-All. Эти права по умолчанию есть у групп Domain Admins и Domain Controllers.

!Схематичное изображение атаки DCSync, имитирующей запрос репликации данных Active Directory.

Резюме

Компрометация AD — это редко использование 0-day эксплойтов. Это цепочка логических шагов:

Вход: LLMNR Poisoning / Phishing.

Разведка: BloodHound / LDAP queries.

Эскалация: Kerberoasting / AS-REP Roasting / GPP / Unconstrained Delegation.

Доминирование: Golden Ticket / DCSync.

Понимание этих векторов позволяет не только проводить успешные пентесты, но и выстраивать грамотную защиту, отключая устаревшие протоколы и настраивая мониторинг событий безопасности.

В следующей части курса мы разберем пост-эксплуатацию и методы обхода антивирусных средств (AV/EDR) для сохранения доступа.

Продвинутый анализ защищенности веб-приложений и API: за пределами OWASP Top 10

Коллеги, в предыдущих модулях мы успешно скомпрометировали периметр, закрепились в сети и даже получили права администратора домена через атаки на Active Directory. Однако в современных реалиях «входной дверью» в инфраструктуру чаще всего служат не забытые RDP-порты, а сложные веб-приложения и API-интерфейсы.

Многие специалисты ограничиваются проверкой на наличие SQL-инъекций или XSS (Cross-Site Scripting). Но, учитывая ваш уровень подготовки, мы понимаем: современные фреймворки (React, Angular, Django, Spring) «из коробки» закрывают большинство примитивных уязвимостей. Профессиональный пентестер должен искать глубже — в логике работы приложения, архитектуре API и механизмах взаимодействия микросервисов.

В этой статье мы выйдем за рамки стандартного чеклиста OWASP Top 10 и разберем векторы атак, требующие глубокого понимания работы протокола HTTP, сериализации данных и конкурентности процессов.

Логические уязвимости и состояние гонки (Race Conditions)

Логические уязвимости (Business Logic Flaws) невозможно обнаружить автоматическими сканерами, так как с точки зрения кода ошибки нет — есть ошибка в сценарии использования. Одним из самых опасных и сложных для выявления классов таких уязвимостей является Race Condition (состояние гонки).

Механика атаки TOCTOU

Классический пример гонки — Time-of-Check to Time-of-Use (TOCTOU). Это ситуация, когда между проверкой условия (например, «достаточно ли денег на счете») и использованием ресурса (например, «списание денег») проходит определенный квант времени, в который атакующий успевает вмешаться.

Представьте многопоточное приложение. Если мы отправим 10 одновременных запросов на перевод средств, и приложение не использует блокировки транзакций (mutex) или атомарные операции базы данных, может возникнуть ситуация, когда все 10 потоков пройдут проверку баланса до того, как первый поток обновит его состояние.

!Визуализация атаки Race Condition, где параллельные запросы обходят проверку баланса из-за задержки записи данных.

Limit Overrun

В контексте веб-приложений это часто используется для обхода лимитов: применения одного купона на скидку несколько раз, накрутки голосов или перевода суммы, превышающей баланс. Для успешной эксплуатации используется техника «Turbo Intruder» (отправка пакетов с минимальной задержкой).

API Security: Mass Assignment и GraphQL

Архитектура REST и GraphQL принесла новые векторы, специфичные для API.

Mass Assignment (Массовое присваивание)

Современные ORM (Object-Relational Mapping) часто позволяют автоматически мапить JSON-объект из запроса в объект базы данных. Если разработчик не ограничил список разрешенных полей, злоумышленник может перезаписать критические атрибуты.

Пример: При регистрации пользователь отправляет JSON:

Атакующий добавляет поле, которое он нашел в документации или методом перебора:

Если бэкенд слепо копирует все поля в модель пользователя, мы получаем повышение привилегий.

Атаки на GraphQL

GraphQL позволяет клиенту запрашивать именно те данные, которые ему нужны. Это удобно для фронтенда, но кошмарно для безопасности, если не настроены лимиты сложности.

Интроспекция (Introspection): По умолчанию GraphQL позволяет запросить схему всей базы данных, включая скрытые поля и типы. Это идеальный инструмент для разведки.

DoS через вложенность: GraphQL позволяет делать вложенные запросы. Атакующий может построить циклический запрос (например, автор -> посты -> комментарии -> автор -> посты...), который положит базу данных.

Для защиты используется метрика Query Complexity Analysis. Стоимость запроса () рассчитывается по формуле:

Где: * — итоговая сложность запроса. * — количество полей в запросе. * — базовая стоимость поля (обычно 1). * — глубина вложенности поля . * — дополнительный вес для «тяжелых» полей (например, требующих JOIN в БД).

Если превышает установленный порог (например, 1000), сервер должен отклонить запрос. Пентестер должен пытаться подобрать такой запрос, который максимизирует нагрузку при минимальной видимой сложности.

HTTP Request Smuggling

Это атака на рассинхронизацию между фронтендом (балансировщиком нагрузки, CDN) и бэкендом. Она возникает из-за разной интерпретации того, где заканчивается один HTTP-запрос и начинается следующий.

Спецификация HTTP предоставляет два способа указать длину тела сообщения:

Заголовок Content-Length (CL) — длина в байтах.

Заголовок Transfer-Encoding: chunked (TE) — сообщение передается кусками (чанками), конец обозначается чанком нулевой длины.

Если атакующий отправляет запрос, содержащий оба заголовка, и фронтенд ориентируется на CL, а бэкенд на TE (атака CL.TE), или наоборот (TE.CL), возникает возможность «контрабанды» запроса.

!Механизм рассинхронизации очередей при атаке HTTP Request Smuggling.

Последствия катастрофичны: от обхода WAF до перехвата сессий других пользователей (если их запрос будет обработан в контексте нашего «контрабандного» префикса).

Небезопасная десериализация (Insecure Deserialization)

Сериализация — это процесс перевода объекта в поток байтов для передачи или сохранения. Десериализация — обратный процесс. Уязвимость возникает, когда приложение десериализует данные из недоверенного источника без проверки.

Это не просто изменение данных. В языках вроде Java, PHP, Python или .NET десериализация может приводить к удаленному выполнению кода (RCE).

Gadget Chains

Сама по себе функция десериализации (например, readObject в Java) может быть безопасной. Но в процессе восстановления объекта могут вызываться другие методы (магические методы, деструкторы). Атакующий ищет цепочки классов (Gadgets), которые уже есть в загруженных библиотеках приложения, и выстраивает их так, чтобы их последовательный вызов привел к запуску команды оболочки.

Инструмент ysoserial — это стандарт де-факто для генерации таких пейлоадов для Java. Для пентестера важно уметь идентифицировать сериализованные данные (например, по заголовку rO0 в base64 для Java или префиксу gAS для Python Pickle) и понимать, какие библиотеки используются на бэкенде.

Server-Side Request Forgery (SSRF) в облаках

SSRF возникает, когда сервер выполняет HTTP-запрос к произвольному адресу, указанному атакующим. В эпоху облачных технологий (AWS, GCP, Azure) это критическая уязвимость.

Цель атакующего — не просто просканировать внутреннюю сеть, а обратиться к Instance Metadata Service (IMDS). Это внутренний API облачного провайдера, доступный только изнутри виртуальной машины (обычно по адресу 169.254.169.254).

Если пентестер сможет прочитать ответ от этого адреса, он может получить временные ключи доступа (Access Key, Secret Key) и захватить управление облачной инфраструктурой.

Резюме

Мы рассмотрели векторы, которые требуют от специалиста ИБ не просто запуска сканера, а инженерного мышления:

Race Conditions эксплуатируют время и конкурентность.

API Attacks бьют по избыточному доверию к структуре данных.

HTTP Smuggling ломает фундаментальную обработку протокола.

Deserialization превращает данные в исполняемый код.

Эти техники позволяют находить уязвимости критического уровня там, где автоматика видит «зеленый свет». В следующем модуле мы перейдем к пост-эксплуатации и написанию профессионального отчета, который переведет эти технические находки на язык бизнес-рисков.

Техники пост-эксплуатации, закрепления в системе и обхода средств защиты (AV/EDR)

Коллеги, мы успешно прошли этапы разведки, получили первоначальный доступ и повысили привилегии. Теперь мы находимся внутри периметра. На этом этапе работа скрипт-кидди заканчивается, и начинается работа профессионала. Наша задача — не просто «пошуметь», а эмулировать действия продвинутой угрозы (APT), сохраняя доступ длительное время и оставаясь незамеченными для Blue Team.

В этой статье мы разберем архитектуру современных средств защиты конечных точек (EDR — Endpoint Detection and Response), математику обфускации и методы закрепления (Persistence), которые выходят за рамки банальной папки автозагрузки.

Анатомия EDR и методы обхода (Evasion)

Чтобы обойти защиту, нужно понимать, как она работает. Классический антивирус (AV) полагался на сигнатуры файлов. Современный EDR полагается на поведенческий анализ и телеметрию.

User-land Hooks и мониторинг API

Большинство EDR-решений работают в пространстве пользователя (User-land), внедряя свои DLL в каждый запускаемый процесс. Они перехватывают (hook) вызовы Windows API. Например, когда вы пытаетесь сделать дамп памяти процесса lsass.exe через функцию MiniDumpWriteDump, EDR перехватывает этот вызов, анализирует аргументы и блокирует исполнение, если оно кажется подозрительным.

!Сравнение прямого системного вызова и вызова, перехваченного EDR-хуком в пространстве пользователя.

Direct System Calls (Прямые системные вызовы)

Один из самых эффективных методов обхода хуков — использование прямых системных вызовов (Direct Syscalls). Вместо того чтобы вызывать функцию из kernel32.dll или ntdll.dll (где сидит «шпион» EDR), мы можем реализовать инструкцию syscall на ассемблере прямо в нашем коде.

Это позволяет обойти User-land хуки, так как мы не обращаемся к библиотекам Windows, а говорим напрямую с ядром ОС. Инструменты вроде SysWhispers автоматизируют генерацию таких вызовов.

Математика обфускации и энтропия

EDR и антивирусы анализируют файлы не только по сигнатурам, но и по их энтропии. Энтропия Шеннона — это мера неопределенности или хаотичности данных. Зашифрованные или упакованные (packed) пейлоады имеют высокую энтропию, что является красным флагом для систем защиты.

Формула энтропии Шеннона выглядит следующим образом:

Где: * — значение энтропии (обычно от 0 до 8 для байтовых данных). * — количество уникальных символов (байт) в наборе данных. * — вероятность появления -го символа в наборе данных (частота встречаемости).

Легитимный исполняемый код обычно имеет энтропию в диапазоне 4.8–6.5. Если ваш пейлоад имеет энтропию 7.9, он будет немедленно помечен как подозрительный (вероятно, это зашифрованный Shellcode). Профессиональные пентестеры используют техники снижения энтропии, например, кодирование пейлоада в английские слова или добавление блоков мусорных данных (junk code) с низкой энтропией.

Living off the Land (LotL)

Концепция «Жизнь на подножном корму» (LotL) подразумевает использование легитимных утилит, уже установленных в системе, для выполнения вредоносных действий. Microsoft называет такие утилиты LOLBins (Living Off The Land Binaries).

Примеры использования: * Certutil: Предназначен для управления сертификатами, но может использоваться для скачивания файлов (-urlcache -split -f) или декодирования base64. * Msbuild: Может компилировать и исполнять C# код «на лету» из XML-файла проекта. * Wmic: Использование WMI для запуска процессов на удаленных хостах.

Использование LOLBins затрудняет атрибуцию атаки и часто позволяет обойти Application Whitelisting (AppLocker), так как эти бинарные файлы подписаны цифровой подписью Microsoft.

Продвинутое закрепление (Persistence)

Добавление записи в HKCU\Software\Microsoft\Windows\CurrentVersion\Run — это моветон, который обнаружит даже самый простой антивирус. Рассмотрим более скрытные методы.

DLL Sideloading и DLL Hijacking

Windows ищет DLL для загрузки в определенном порядке (DLL Search Order). Если приложение пытается загрузить библиотеку без указания полного пути, система сначала ищет её в директории приложения.

Техника:

Находим легитимное, подписанное приложение (например, старую версию антивируса или утилиту от Google Update), которое уязвимо к DLL Hijacking.

Кладем это приложение в папку пользователя.

Кладем рядом нашу вредоносную DLL, переименовав её в имя библиотеки, которую ищет приложение (например, version.dll).

При запуске легитимного приложения оно подгрузит нашу DLL.

Это позволяет скрыть вредоносный код внутри доверенного процесса.

WMI Event Subscriptions

Это один из самых скрытных методов закрепления, так как он не требует наличия файлов на диске (Fileless persistence). Механизм подписки на события WMI состоит из трех компонентов:

Event Filter: Условие запуска (например, «через 5 минут после старта системы» или «при создании процесса notepad.exe»).

Event Consumer: Действие (например, запуск PowerShell-скрипта).

FilterToConsumerBinding: Связка фильтра и потребителя.

Администраторы редко проверяют репозиторий WMI, поэтому такой бэкдор может жить в системе годами.

Command and Control (C2) и скрытие трафика

После закрепления нам нужен канал связи. Простое TCP-соединение на порт 4444 будет заблокировано межсетевым экраном. Профессионалы используют скрытые каналы.

Domain Fronting и DoH

Техника Domain Fronting использует особенности CDN (Content Delivery Network). В SNI (Server Name Indication) TLS-запроса мы указываем легитимный домен (например, ajax.googleapis.com), а в HTTP-заголовке Host — наш скрытый C2-сервер, который также находится за этой CDN. Для сетевого оборудования трафик выглядит как обращение к Google.

Также популярно использование DNS over HTTPS (DoH). Трафик инкапсулируется в HTTPS-запросы к публичным DNS-резолверам (Cloudflare, Google), что делает его практически невидимым для анализаторов трафика.

Jitter и Beaconing

Регулярные запросы к серверу (Beaconing) с фиксированным интервалом (например, каждые 5 секунд) легко детектируются статистическим анализом. Чтобы избежать этого, вводится понятие Jitter (дрожание).

Формула расчета времени следующего соединения () с учетом джиттера:

Где: * — фактическое время ожидания до следующего соединения. * — базовый интервал (например, 60 секунд). * — случайное число в диапазоне от -1 до 1 (равномерное распределение). * — коэффициент джиттера (от 0 до 1, где 0.1 означает 10% отклонения).

Если и (20%), то интервал между «стуками» будет варьироваться от 48 до 72 секунд. Это сбивает алгоритмы обнаружения периодичности.

Резюме

Пост-эксплуатация — это искусство оставаться невидимым.

Мы используем Direct Syscalls, чтобы не попадаться на глаза EDR.

Мы следим за энтропией наших файлов, чтобы не выглядеть как шифрованный эксплойт.

Мы используем LOLBins, чтобы действовать руками самой операционной системы.

Мы закрепляемся через DLL Sideloading или WMI, избегая банальных ключей реестра.

В следующей, заключительной части курса, мы разберем, как собрать все полученные данные и сформировать профессиональный отчет, который принесет пользу бизнесу, а не просто напугает его.

Подготовка профессиональной отчетности, скоринг уязвимостей (CVSS) и рекомендации по устранению

Коллеги, мы подошли к финальной и, пожалуй, самой важной части нашего курса. Мы научились проводить разведку, эксплуатировать уязвимости Active Directory, взламывать API и закрепляться в системе, обходя EDR. Но давайте будем честны: если вы не сможете грамотно описать найденные проблемы и продать необходимость их устранения бизнесу, ваша работа как пентестера стоит немного.

В профессиональной среде результатом работы является не полученный шелл и не дамп базы данных, а отчет. Отчет — это единственный осязаемый продукт, который получает заказчик. В этой статье мы разберем, как трансформировать технические находки в бизнес-ценность, как математически обосновать критичность уязвимости через CVSS и как давать рекомендации, которые реально выполнить.

Структура профессионального отчета

Отчет о тестировании на проникновение читают две совершенно разные аудитории: топ-менеджмент (CTO, CISO, CEO) и технические специалисты (администраторы, разработчики). Попытка сделать универсальный текст для всех — главная ошибка новичков.

Профессиональный отчет всегда строится по принципу пирамиды и включает следующие секции:

Executive Summary (Управленческое резюме). Здесь не должно быть IP-адресов или названий CVE. Только бизнес-риски. Сколько денег может потерять компания? Остановятся ли бизнес-процессы? Была ли скомпрометирована конфиденциальная информация?

Technical Summary (Техническое резюме). Обзор векторов атак, статистика по уязвимостям, общая оценка защищенности периметра и внутренней сети.

Methodology & Scope (Методология и границы). Юридически важный раздел. Что именно тестировали, какие методы использовали (PTES, OSSTMM), в какое время проводились работы.

Findings (Детальное описание уязвимостей). Самая объемная часть, предназначенная для тех, кто будет устранять проблемы.

!Иерархия разделов отчета о пентесте: от бизнеса к технике.

Математика оценки рисков: CVSS и не только

Сказать «у вас критическая дыра» недостаточно. Необходимо обосновать уровень риска количественно. Индустриальным стандартом для этого является CVSS (Common Vulnerability Scoring System). На данный момент актуальна версия 4.0, но версия 3.1 все еще широко используется.

Анатомия CVSS вектора

Многие ограничиваются Base Score (базовой оценкой), которую выдают сканеры. Это ошибка. Базовая оценка учитывает только техническую тяжесть уязвимости в вакууме. Для профессионального отчета вы обязаны учитывать контекст.

Вектор CVSS состоит из метрик, которые формируют итоговый балл. Рассмотрим формулу расчета влияния (Impact) в упрощенном виде, чтобы понять логику формирования оценки. Влияние на актив () рассчитывается на основе потери конфиденциальности, целостности и доступности.

Формула расчета подытога влияния (Impact Sub-score) в CVSS v3.1 выглядит следующим образом:

Где: * — Impact Sub-Score (подытог влияния), числовое значение, отражающее степень потери безопасности актива. * — метрика влияния на конфиденциальность (значения: None=0.0, Low=0.22, High=0.56). * — метрика влияния на целостность (значения те же). * — метрика влияния на доступность (значения те же).

Пример: Если уязвимость позволяет полностью прочитать базу данных (High Confidentiality), но не изменить её (None Integrity) и не удалить (None Availability), то формула примет вид:

Это означает, что актив потерял 56% своих свойств безопасности. Именно так математика превращает абстрактные понятия в числа.

Temporal и Environmental метрики

Профессионал обязан корректировать базовый балл:

* Temporal (Временные): Есть ли публичный эксплойт? Есть ли патч? Если патча нет, риск выше. * Environmental (Средовые): Насколько важен этот конкретный сервер? SQL-инъекция на тестовом стенде без данных (CVSS 4.0) и та же инъекция на процессинге (CVSS 9.8) — это разные риски, хотя уязвимость одна и та же.

> CVSS измеряет техническую тяжесть (Severity), а не риск (Risk). Риск всегда включает в себя вероятность и влияние на бизнес. > — FIRST.org, разработчики стандарта CVSS

Количественная оценка риска (Quantitative Risk Analysis)

Для Executive Summary часто требуется перевести технические баллы в деньги. Для этого используется методика оценки ожидаемых потерь. Основная формула выглядит так:

Где: * (Annualized Loss Expectancy) — ожидаемые годовые потери в денежном эквиваленте. * (Single Loss Expectancy) — ожидаемые потери от одного инцидента (стоимость актива + затраты на восстановление). * (Annualized Rate of Occurrence) — частота возникновения инцидента в год (вероятность).

Если стоимость базы данных клиентов оценивается в 10 млн рублей (), а вероятность успешной атаки через найденную RCE оценивается как раз в 2 года (), то:

Это означает, что компания должна тратить на защиту от этой угрозы не более 5 млн рублей в год, иначе защита будет стоить дороже самого актива.

Описание находок (Findings)

Каждая уязвимость в отчете должна быть описана так, чтобы разработчик мог её воспроизвести, не задавая вам вопросов. Идеальная структура файндинга:

Название и CVSS вектор. Например: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H (Критическая, 9.8).

Описание. Что это за уязвимость и почему она возникла.

Proof of Concept (PoC). Пошаговая инструкция. Скриншоты, HTTP-запросы, куски кода эксплойта. Важно: скрывайте чувствительные данные (пароли, PII) на скриншотах.

Бизнес-импакт. Не пишите «злоумышленник может выполнить JS-код». Пишите «злоумышленник может перехватить сессию администратора и вывести средства».

!Пример грамотного оформления технического описания уязвимости в отчете.

Рекомендации по устранению (Remediation)

Это та часть, ради которой вас нанимали. Рекомендации типа «обновите Windows» или «исправьте код» — признак низкой квалификации. Рекомендации должны делиться на три уровня:

1. Тактические (Quick Wins)

Что нужно сделать прямо сейчас, чтобы закрыть дыру. Например: * «Добавить правило в WAF, блокирующее запросы с путем /admin». * «Отключить службу Print Spooler на контроллерах домена».

2. Стратегические (Long Term)

Как изменить процесс, чтобы проблема не повторилась. Например: * «Внедрить процесс Code Review с использованием SAST-анализаторов». * «Перейти на использование параметризованных запросов во всех модулях ORM».

3. Компенсирующие меры (Defense in Depth)

Что делать, если уязвимость нельзя исправить (например, легаси-система). Например: * «Изолировать уязвимый сервер в отдельный VLAN с доступом только с jump-host». * «Настроить повышенный уровень логирования событий доступа к данному узлу в SIEM».

Финальный этап: Retest

Процесс пентеста не заканчивается сдачей отчета. Хорошим тоном считается проведение ретеста (проверки устранения) через 1-3 месяца. Вы проверяете только те уязвимости, которые были найдены, и подтверждаете, что патч действительно работает, а не просто скрывает ошибку от сканера.

Заключение курса

Коллеги, мы прошли путь от теории методологий до написания профессионального отчета. Вы обладаете знаниями о том, как ломать сети, веб и людей. Теперь ваша задача — использовать эти знания для того, чтобы делать системы безопаснее.

Помните: настоящий хакер — это не тот, кто ломает, а тот, кто понимает систему настолько глубоко, что может заставить её делать то, что нужно ему. В нашей профессии это означает заставить систему быть безопасной вопреки энтропии и ошибкам разработки.

Удачи в полях!