Пентест и этичный хакинг: от основ до практики

Введение: цели пентеста, роли, закон и этика

Что такое пентест и зачем он нужен

Пентест (penetration testing) — это контролируемая проверка защищённости системы путём попыток найти и подтвердить реальные пути компрометации в рамках заранее согласованных правил.

Важно отличать пентест от близких по смыслу активностей:

| Активность | Цель | Результат | Риск для систем | |---|---|---|---| | Пентест | Подтвердить, как именно можно взломать и к чему это приведёт | Доказуемые сценарии атаки + рекомендации | Средний (управляемый правилами) | | Сканирование уязвимостей | Найти известные уязвимости автоматически | Список находок (часто без подтверждения эксплуатации) | Низкий | | Red Team | Проверить способность организации обнаружить/остановить реалистичную атаку | Картина эффективности защиты и реагирования | Выше среднего | | Аудит/ревью | Оценить соответствие требованиям и практикам | Несоответствия, риски, рекомендации | Низкий |

Пентест отвечает не только на вопрос «есть ли уязвимость?», но и на более прикладной вопрос: «какой ущерб возможен при реальной атаке и как это исправить?».

Цели пентеста

Цели зависят от контекста, но чаще всего пентест делают, чтобы:

Проверить реальную устойчивость к атакам до инцидента

Найти критические цепочки атак (например, от внешнего доступа до админ-прав)

Приоритизировать исправления по реальному риску, а не по количеству находок

Проверить, что исправления действительно работают (повторное тестирование)

Подготовиться к требованиям клиентов/регуляторов (в рамках политики безопасности)

Типичные результаты (deliverables)

Обычно по итогам пентеста заказчик получает:

Отчёт для руководства: что проверяли, что удалось, бизнес-риски, приоритеты исправлений.

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

Матрицу находок: критичность, вероятность, влияние, статус исправления.

Сессию разбора: ответы на вопросы, уточнение плана исправлений.

Роли в пентесте и смежных процессах

Пентест — это не только «хакер», а взаимодействие нескольких ролей.

Основные роли

| Роль | Ответственность | |---|---| | Заказчик/владелец системы | Определяет цели, подтверждает законность, предоставляет доступы и контакты | | Пентестер (исполнитель) | Ищет и подтверждает уязвимости в рамках разрешений, документирует результаты | | Контакт по инцидентам (SOC/дежурный) | Получает предупреждения о тестах, реагирует на неожиданные эффекты | | Владельцы компонентов (Dev/Ops/админы) | Помогают со средой, устраняют уязвимости, участвуют в проверке исправлений | | Юристы/комплаенс | Формируют договорные рамки, согласуют допустимые действия и обработку данных |

Red Team, Blue Team, Purple Team

Red Team имитирует атакующего и проверяет сценарии проникновения (часто с упором на незаметность).

Blue Team защищает: мониторинг, обнаружение, реагирование, улучшение средств защиты.

Purple Team — совместная работа Red и Blue, где атаки используются как обучение и настройка детектов.

!Наглядно показывает, чем отличаются роли команд и как они взаимодействуют

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

Ключевой принцип этичного хакинга: разрешено только то, что явно разрешено.

Что такое скоуп (объём работ)

Скоуп — это перечень того, что можно тестировать и как.

Обычно в скоуп входят:

Активы: домены, IP-адреса, приложения, API, мобильные приложения, облачные аккаунты

Тип доступа: внешний/внутренний, наличие тестовой учётки, роль пользователя

Ограничения: запрет DoS, запрет социальной инженерии, временные окна

Требования к доказательствам: какие логи/скриншоты/артефакты допустимы

Документы, которые защищают обе стороны

На практике используются (названия могут отличаться по компаниям):

Договор/контракт: фиксирует стороны, ответственность, оплату, общие условия.

NDA (соглашение о неразглашении): защищает конфиденциальную информацию.

RoE (Rules of Engagement, правила проведения работ): что можно делать, когда, какими методами, кого предупреждать.

LoA (Letter of Authorization, письмо/акт авторизации): явное разрешение на тестирование конкретных активов.

SoW (Statement of Work, описание работ): цели, объём, сроки, формат отчёта.

Даже если вы тестируете собственную инфраструктуру, внутренняя письменная авторизация снижает риск недоразумений и упрощает коммуникации.

!Показывает процесс пентеста как управляемый проект с этапами и контрольными точками

Законность: где проходит граница между пентестом и взломом

Юридическая граница определяется не «намерениями», а наличием разрешения и соблюдением условий.

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

Практические правила законности

Получайте явное разрешение владельца системы до любых действий.

Тестируйте только то, что входит в согласованный скоуп.

Соблюдайте ограничения RoE (например, запрет нагрузочных атак).

Фиксируйте временные окна работ и контактных лиц на случай инцидента.

Не выходите за пределы необходимого (минимизация доступа и данных).

Для ориентиров по управлению безопасностью и оценке рисков полезны стандарты и гайды (они не заменяют юридическую консультацию, но задают общую рамку):

NIST Cybersecurity Framework

OWASP Web Security Testing Guide

Penetration Testing Execution Standard (PTES)

Этика: что делает хакинг «этичным»

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

Базовые принципы профессиональной этики

Безопасность прежде всего: избегать действий, которые могут остановить бизнес-процессы.

Минимизация воздействия: брать минимум данных, необходимый для доказательства.

Конфиденциальность: защищать данные заказчика, шифровать артефакты, контролировать доступ.

Честность и прозрачность: не скрывать методы и ограничения, не преувеличивать результат.

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

Работа с чувствительными данными

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

Сразу уведомляйте контактное лицо по инцидентам, если обнаружили критический доступ.

Не выгружайте массивы данных «на всякий случай».

Если нужно доказательство — используйте минимальный пример (например, один тестовый объект).

Храните артефакты в защищённом виде и удаляйте по согласованному сроку.

Ответственное раскрытие уязвимостей

Иногда уязвимость обнаруживается вне контракта (например, исследователь нашёл баг в публичном сервисе). Тогда применяют подход responsible disclosure — ответственное раскрытие.

Общая логика:

Сообщить владельцу сервиса приватно и предоставить детали, достаточные для исправления

Дать разумный срок на устранение (или следовать политике bug bounty/VDP, если она есть)

Не публиковать эксплуатационные подробности до исправления (или до согласованной даты)

Многие компании публикуют политику приёма уязвимостей (VDP). Если она существует, ей нужно следовать.

Как мы будем работать в этом курсе

Этот курс про этичный и практический пентест: от понимания целей и правил до выполнения тестов и оформления результатов.

В следующих материалах мы последовательно разберём:

базовые понятия сетей и веб-приложений, которые нужны пентестеру

типовой процесс тестирования (сбор информации, анализ, подтверждение, отчёт)

безопасную организацию лаборатории и практику на легальных стендах

культуру отчётности и коммуникации с заказчиком

Ключевая установка с первого урока: навыки важны, но рамки законности и этики важнее.

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

Зачем пентестеру подготовка

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

Подготовка превращает «попытки взлома» в управляемую работу:

снижает риск простоя и инцидентов

задаёт юридические и организационные рамки

помогает сфокусировать тест на реальных угрозах, а не на случайных находках

заранее определяет, как вы будете коммуницировать и фиксировать результаты

На практике качество пентеста часто определяется не набором инструментов, а тем, насколько хорошо согласованы:

скоуп (что именно тестируем)

правила взаимодействия (как работаем, как эскалируем, когда останавливаемся)

моделирование угроз (какие сценарии атак наиболее вероятны и опасны)

!Как подготовка влияет на качество и безопасность пентеста

Скоуп: границы работ, допуски и допущения

Что такое скоуп

Скоуп — это документально зафиксированный перечень активов и действий, которые:

разрешены (in-scope)

запрещены (out-of-scope)

разрешены с ограничениями (например, только в определённые часы)

Скоуп отвечает на вопросы:

что тестируем (домены, IP, приложения, облака, мобильные клиенты)

каким доступом (без учётки, тестовая учётка, роль пользователя, внутренний доступ)

какими методами (разрешена ли эксплуатация, фишинг, физдоступ)

в какое время и с какими ограничениями (запрет DoS, запрет массового брутфорса)

Что включать в скоуп

Ниже — типовые элементы скоупа. Их удобно собирать в виде таблицы.

| Раздел | Что фиксируем | Пример формулировки | |---|---|---| | Активы | Домены, IP, приложения, API, репозитории, облачные аккаунты | app.example.com, api.example.com, подсеть 203.0.113.0/24 | | Окружения | Prod/Staging/Dev, различия данных | Тест только на staging, prod — только пассивный сбор | | Тип доступа | External/Internal, VPN, VDI, тестовые учётки | Предоставлена VPN + учётка пользователя без админ-прав | | Данные и артефакты | Что можно сохранять, как хранить, сроки удаления | Скриншоты допустимы, дампы БД запрещены | | Ограничения | Запреты и «бережные» режимы | Запрещены DoS, нагрузочные тесты, массовый подбор паролей | | Критичные системы | Что нельзя трогать или трогать только с согласованием | Биллинг — только скан, эксплуатация запрещена |

In-scope и out-of-scope должны быть однозначными

Плохой скоуп звучит так: «тестируем сайт компании».

Хороший скоуп:

Перечисляет конкретные хосты и приложения.

Разделяет окружения (prod/staging) и описывает ограничения.

Указывает «соседние» зоны, которые часто путают с целями (например, корпоративная почта, провайдеры, подрядчики).

Скоуп и «неявные» границы

Частые ловушки, которые нужно проговаривать заранее:

Поддомены и сторонние сервисы

1. Поддомен может указывать на SaaS (например, конструктор форм или helpdesk), который юридически принадлежит не заказчику. 2. В скоупе фиксируют, что разрешено: тест поддомена как зоны DNS или тест конкретного SaaS по согласованию.

Облака и совместная ответственность

1. В облаке часть ответственности у провайдера, часть у клиента. 2. Скоуп должен говорить, что именно тестируем: конфигурации IAM, публичные бакеты, сетевые политики, но не инфраструктуру провайдера.

Производственная среда

1. Иногда заказчик хочет тестировать prod. 2. Тогда критичны ограничения: окна работ, запрет разрушающих техник, согласованный план остановки.

Практический ориентир: если объект не назван явно, считайте его out-of-scope и уточняйте.

Правила взаимодействия (RoE): как работать безопасно и предсказуемо

RoE (Rules of Engagement) — это «инструкция по выполнению пентеста», которая делает процесс управляемым для обеих сторон.

Если скоуп отвечает на вопрос «что можно тестировать», то RoE отвечает на вопрос «как именно работаем и что делаем при нештатных ситуациях».

Полезная базовая рамка процесса пентеста описана в PTES, а рекомендации по технической оценке безопасности — в NIST SP 800-115.

Что обязательно должно быть в RoE

| Раздел RoE | Зачем нужен | Пример | |---|---|---| | Контакты и эскалация | Быстро остановить/согласовать действия при рисках | Контакт SOC + телефон для срочной связи | | Окна работ | Снизить риск простоя в пиковое время | Тесты с 22:00 до 06:00 по МСК | | Запрещённые техники | Уменьшить шанс повреждения данных и отказа | Запрет DoS, запрет удаления/шифрования данных | | Разрешённые техники | Снять двусмысленность «можно ли эксплуатировать» | Разрешена эксплуатация до proof-of-concept без закрепления | | Уровень доказательств | Понять, что считается подтверждением | Достаточно чтения одного тестового объекта | | Правила обращения с данными | Соблюсти конфиденциальность и договорённости | Артефакты шифруются, срок хранения 30 дней | | Stop conditions | Ясный критерий, когда остановиться | При признаках деградации сервиса — немедленная пауза |

Каналы коммуникации

Заранее фиксируют:

основной канал (например, тикет-система или корпоративный мессенджер)

аварийный канал (телефон/дежурная линия)

формат уведомлений о критических находках

Хорошая практика — договориться о двух уровнях уведомлений:

Срочно: критический доступ, утечка секретов, риск простоя.

Планово: все остальные находки в отчёте или в согласованном трекере.

Управление риском во время теста

Чтобы пентест оставался «контролируемым», часто вводят дополнительные правила:

Лимиты интенсивности

1. Ограничение скорости запросов к веб-приложению. 2. Ограничение параллельности сканирования.

Безопасные режимы

1. Предпочтение «read-only» действий. 2. Запрет на изменение данных без отдельного согласования.

Предварительные проверки

1. Подтверждение, что у заказчика есть бэкапы и план отката. 2. Подтверждение, что контактные лица доступны в окно работ.

Доказательства и чувствительные данные

Цель доказательств — подтвердить риск, а не собрать максимум данных.

Практичные правила минимизации:

Если нужно подтвердить доступ к данным, используйте один минимальный пример (одна запись, один файл, один объект).

Не сохраняйте секреты (пароли, ключи, токены) в отчёте в открытом виде.

Артефакты храните:

1. в зашифрованном виде 2. с ограничением доступа 3. с заранее согласованным сроком удаления

Моделирование угроз: как выбрать правильные сценарии атак

Определение простыми словами

Моделирование угроз — это структурированный способ ответить на вопросы:

кто может атаковать систему

какие у него цели

через какие точки входа он может действовать

какие последствия наиболее опасны

В контексте пентеста это помогает:

не распыляться на малозначимые находки

строить реалистичные цепочки атак

обосновывать приоритеты (почему тестируем именно это)

Рекомендованные вводные материалы:

OWASP Threat Modeling

MITRE ATT&CK

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

Этот процесс можно сделать лёгким и быстрым, без «бюрократии».

Определить активы (что защищаем)

1. Учётные записи пользователей и администраторов. 2. Деньги, заказы, баланс, платёжные операции. 3. Персональные данные. 4. Секреты: API-ключи, токены, приватные ключи.

Определить атакующих (кто атакует)

1. Внешний злоумышленник без учётки. 2. Пользователь с обычной ролью. 3. Скомпрометированный подрядчик. 4. Внутренний нарушитель (редко, но иногда важно).

Нарисовать границы доверия и потоки данных

1. Где клиент (браузер/мобильное приложение) общается с API. 2. Где находятся базы данных. 3. Какие интеграции со сторонними сервисами.

Выделить поверхности атаки

1. Точки входа: формы, API-методы, админки, панели мониторинга. 2. Каналы: HTTP, WebSocket, SSH, VPN. 3. Механизмы: авторизация, сессии, загрузка файлов.

Сформировать топ сценариев и привязать их к тестам

1. Что проверяем в первую очередь. 2. Какие доказательства нужны. 3. Какие ограничения действуют.

!Пример DFD и границ доверия для моделирования угроз

STRIDE как удобная «памятка» по типам угроз

STRIDE — популярная модель категорий угроз. Её часто используют как чек-лист, чтобы не забыть важные классы проблем.

| Категория (STRIDE) | Суть простыми словами | Типичный пример для пентеста | |---|---|---| | Spoofing (подмена) | Притвориться другим пользователем/сервисом | Захват сессии, слабая аутентификация | | Tampering (подмена данных) | Изменить данные в пути или в хранилище | Изменение параметров заказа, подмена роли | | Repudiation (отказ от действий) | Нельзя доказать, кто что сделал | Нет логирования критичных операций | | Information Disclosure (утечка) | Данные доступны не тем | IDOR, лишние поля в API-ответе | | Denial of Service (отказ) | Сервис недоступен | Дорогие запросы, отсутствие лимитов | | Elevation of Privilege (повышение прав) | Получить больше прав, чем положено | Вертикальная/горизонтальная эскалация |

Важно: моделирование угроз не равно проведению DoS. Даже если DoS-тесты запрещены, вы можете выявлять условия, которые приводят к отказу (например, отсутствие rate limiting), не доводя систему до простоя.

Как связать моделирование угроз со скоупом и RoE

Хорошая связка выглядит так:

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

В скоупе вы фиксируете, какие платежные компоненты тестируются (и где запреты).

В RoE вы фиксируете ограничения, чтобы не сорвать реальную оплату:

1. тест только на staging или тестовые платежи 2. запрет на массовые операции 3. окно работ и контакт для срочной остановки

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

Приоритизация: что тестировать сначала

Чтобы не утонуть в деталях, используйте простой подход:

сначала проверяйте сценарии, где одновременно:

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

Практический пример приоритета для веб-приложения:

Аутентификация и управление сессией (вход, токены, восстановление пароля)

Авторизация (доступ к объектам, ролям и функциям)

Ввод/вывод данных (инъекции, загрузка файлов)

Интеграции (внешние API, вебхуки)

Админские интерфейсы и панели

Для веб-проверок полезна структура OWASP Web Security Testing Guide: она помогает не забыть важные области тестирования и оформить результаты системно.

Практический шаблон: что подготовить перед стартом

Ниже — компактный список того, что обычно нужно иметь «на руках», прежде чем начинать активные действия.

Скоуп

1. Полный перечень активов in-scope. 2. Явный out-of-scope. 3. Указание окружений (prod/staging) и ограничений.

RoE

1. Окна работ. 2. Контакты и порядок эскалации. 3. Stop conditions. 4. Правила работы с данными и артефактами.

Модель угроз (лёгкая версия)

1. Ключевые активы. 2. Основные атакующие. 3. Поверхности атаки и топ сценариев.

Доступы и инфраструктура

1. Тестовые учётки и роли. 2. VPN/Jump host при внутреннем тесте. 3. Точки логирования/контакты SOC (если нужно коррелировать события).

Итог

Подготовка — это основа этичного и результативного пентеста:

скоуп задаёт границы и юридическую чистоту

RoE делает тест безопасным, управляемым и предсказуемым

моделирование угроз помогает выбрать сценарии, которые действительно важны бизнесу

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

Разведка и OSINT: сбор информации и перечисление

Место разведки в пентесте

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

Разведка и OSINT — следующий логичный шаг: вы строите карту поверхности атаки и находите реальные точки входа, не полагаясь на предположения.

Главная идея:

Разведка отвечает на вопрос «что существует и как это устроено»

Эксплуатация отвечает на вопрос «можно ли это реально скомпрометировать»

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

!Общая логика: от договорённостей и модели угроз к сбору данных и дальнейшим проверкам

Термины простыми словами

Разведка

Разведка — это сбор информации о цели, чтобы понять:

какие активы доступны

какие технологии используются

где потенциально находятся слабые места

OSINT

OSINT (Open Source Intelligence) — информация из открытых источников: публичные записи DNS, журналы сертификатов, публичные репозитории, результаты поисковых систем, публичные базы об инфраструктуре.

Важно: «открытый источник» не означает «можно использовать как угодно». Условия использования сервисов и правила RoE всё равно обязательны.

Перечисление (enumeration)

Перечисление — это более конкретный и технический этап: вы уточняете детали активов.

Примеры:

какие поддомены реально резолвятся

какие порты открыты

какие сервисы слушают порты и какие у них версии

какие эндпоинты есть у веб-приложения или API

Пассивная и активная разведка

Различие удобно формулировать так:

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

Активная: вы обращаетесь к инфраструктуре цели (DNS-запросы, HTTP-запросы к сайту, сканирование портов) и потенциально оставляете следы в логах

Зачем пентестеру OSINT и перечисление

Хорошая разведка помогает:

обнаружить реальный периметр, включая забытые и «временные» системы

найти расхождения между тем, что думает заказчик, и тем, что доступно снаружи

быстро приоритизировать проверки по модели угроз

уменьшить риск: меньше «случайных» действий, больше точных проверок

Типовые результаты этапа разведки (артефакты, которые можно приложить к отчёту или рабочим заметкам):

перечень хостов и сервисов in-scope

гипотезы по технологиям (например, стек веб-приложения)

найденные точки входа (админки, панели, API)

потенциальные зоны риска (устаревшие сервисы, незащищённые панели)

явные ограничения покрытия (например, out-of-scope SaaS)

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

Перед любыми действиями проверьте согласованное:

что именно in-scope (домены, IP-диапазоны, приложения)

можно ли активное сканирование, и с какими лимитами

окна работ

stop conditions (когда нужно немедленно остановиться)

Практическое правило:

если актив не назван явно — считайте его out-of-scope и уточняйте

Это особенно важно для:

поддоменов, указывающих на сторонние SaaS

облачных ресурсов, которые могут принадлежать подрядчикам

хостов, попавших в внешние базы «по ассоциации»

Методология: безопасный конвейер разведки

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

Шаг

Собрать первоначальные идентификаторы

Расширить поверхность атаки через OSINT

Нормализовать и дедуплицировать список активов

Активно перечислить только то, что подтверждено как in-scope

Валидировать результаты и зафиксировать доказательства

На что обращать внимание

Подтверждаемость: каждая запись в списке активов должна иметь источник

Актуальность: OSINT часто содержит устаревшие данные

Приоритизация: важнее сначала покрыть критические потоки из модели угроз

Пассивный OSINT: типовые источники и что из них извлечь

DNS и регистрационные данные

Что полезно собирать:

NS-записи (где размещён DNS)

MX-записи (почтовая инфраструктура)

TXT-записи (часто содержат SPF, DKIM, DMARC, иногда в них встречаются следы интеграций)

Инструменты и источники:

dig, nslookup, host

RDAP/WHOIS (для понимания регистратора и иногда контактов)

Справочно:

Документация dig (BIND 9)

Журналы прозрачности сертификатов (Certificate Transparency)

Журналы CT помогают найти домены и поддомены, для которых выпускались TLS-сертификаты.

Плюсы:

часто позволяет обнаружить «забытые» поддомены

Минусы:

не гарантирует, что хост существует сейчас

часть записей может быть тестовой или временной

Полезный публичный сервис:

crt.sh

Публичные поисковые системы и базы по инфраструктуре

К таким источникам относятся поисковики по баннерам сервисов и метаданным.

Важно: у них есть свои правила использования и ограничения, а результаты нужно перепроверять.

Примеры легитимных платформ:

Shodan

Censys

Публичные репозитории и следы разработки

Что ищут в публичных репозиториях (только в рамках правил и этики):

домены и URL стендов

конфигурации (например, примеры подключений)

упоминания технологий и версий

случайно опубликованные секреты (если такое найдено — действуйте по согласованной процедуре уведомления и минимизации)

Платформы:

GitHub

Документы, метаданные и публичный контент

Иногда полезно:

анализировать метаданные публичных документов (в некоторых организациях там встречаются имена хостов, пути, версии ПО)

смотреть robots.txt и sitemap.xml веб-приложения (это не «секреты», но часто подсказки по структуре)

Ключевое ограничение: не выходить за рамки RoE, не скачивать лишнее и не собирать чувствительные данные «про запас».

Активное перечисление: что и как уточнять

Активные действия должны быть явно разрешены и выполняться бережно: лимиты скорости, контроль параллельности, понятный план остановки.

Ниже — основные направления перечисления и ожидаемые результаты.

DNS-перечисление

Цели:

подтвердить, какие поддомены реально резолвятся

понять, куда они указывают (A/AAAA/CNAME)

Типовые находки:

поддомены, указывающие на облачные/сторонние сервисы

«висячие» записи (например, CNAME на несуществующий ресурс)

Инструменты (как примеры классов решений):

OWASP Amass

Сканирование портов и идентификация сервисов

Цели:

понять, какие сетевые сервисы доступны

определить протоколы и версии там, где это возможно

Почему это важно:

разные сервисы имеют разные классы рисков и разные подходы к проверке

Инструменты:

Nmap

Пример иллюстративной команды для тестовой среды (не для реальных целей без разрешения):

Пояснения:

-sV пытается определить версии сервисов

-Pn отключает предварительную проверку доступности хоста (иногда полезно, но увеличивает «шум»)

IP 192.0.2.10 относится к документационным диапазонам и используется здесь только как пример

Справка по документационным IP-диапазонам:

RFC 5737: IPv4 Address Blocks Reserved for Documentation

HTTP(S)-перечисление веб-приложений

Цели:

определить точки входа: формы, панели, API, загрузки файлов

понять механики аутентификации и сессий

выявить «неочевидные» хосты по виртуальным хостам и редиректам

Бережные источники данных внутри самого приложения:

заголовки ответов (иногда подсказки по стеку)

публичные файлы robots.txt и sitemap.xml

ошибки приложения (их нужно фиксировать, но не провоцировать разрушительными запросами)

Инструменты для ручного анализа:

Документация Burp Suite

Перечисление API

Для API важно понять:

какие методы существуют

какая модель авторизации используется

какие объекты и идентификаторы применяются (это напрямую связано с рисками класса IDOR)

Полезная опора для структуры тестирования:

OWASP Web Security Testing Guide

Перечисление учётных контуров и внешних интеграций

В рамках этики и правил RoE можно собрать:

какие провайдеры почты и SSO используются

какие внешние сервисы интегрированы (например, helpdesk, аналитика, CDN)

Это помогает корректно описать:

где проходит граница ответственности

какие части системы могут быть out-of-scope

Как связывать разведку с моделью угроз

Модель угроз из предыдущей статьи помогает не утонуть в «сборе всего подряд».

Пример связки:

Актив: персональные данные в личном кабинете

Сценарий: злоумышленник без учётки ищет точки входа

Разведка: обнаружить поддомены, API, панели

Перечисление: подтвердить доступные эндпоинты и механики авторизации

Дальше по плану пентеста: прицельно проверять авторизацию, управление сессией и утечки

Качество данных: валидация, дедупликация и доказательства

OSINT и перечисление почти всегда дают «грязный» список: дубликаты, устаревшие хосты, активы подрядчиков.

Хорошая практика обработки результатов:

нормализовать имена (регистр, точки в конце FQDN)

фиксировать источник для каждого актива

отмечать статус: подтверждён, не подтверждён, out-of-scope, требует согласования

хранить доказательства минимально достаточные (скриншот, фрагмент ответа, хеш артефакта)

Особенно важно:

не включать в отчёт секреты в открытом виде

не прикладывать массивы данных, если достаточно одного примера

OPSEC и безопасность теста

Разведка может быть «тихой», но активное перечисление часто заметно и может повлиять на системы.

Минимальный набор практик:

соблюдать лимиты и окна работ из RoE

не запускать тяжёлые проверки на проде без отдельного согласования

заранее договориться, что делать, если SOC сообщает о деградации сервиса

вести журнал действий: что запускали, когда, с какого источника, с каким результатом

Частые ошибки на этапе разведки

Собирать слишком много и не фиксировать, откуда это взялось

Смешивать in-scope и «похожие» активы без пометок

Принимать OSINT-данные за истину без проверки доступности

Делать активное сканирование без явного разрешения и лимитов

Не связывать разведку с моделью угроз и критичностью активов

Итог

Разведка и OSINT в этичном пентесте — это управляемый процесс, который:

начинается с проверки скоупа и RoE

использует пассивные источники для расширения видимости

применяет активное перечисление только в разрешённых границах

заканчивается валидацией, приоритизацией и аккуратной фиксацией доказательств

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

Сканирование и анализ уязвимостей: сети и сервисы

Как этот этап связан с предыдущими

В прошлой статье про разведку и OSINT вы собрали карту поверхности атаки: домены, IP, поддомены, потенциальные точки входа и первичные гипотезы о технологиях.

Сканирование и анализ уязвимостей — это следующий шаг, где вы:

подтверждаете, какие сетевые сервисы реально доступны

уточняете, что именно работает на портах (протокол, продукт, версия, конфигурация)

ищете признаки известных уязвимостей и опасных настроек

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

Ключевое ограничение из первых модулей остаётся неизменным: сканировать можно только то, что явно in-scope, и только теми методами, которые разрешены в RoE.

!Конвейер от подготовки и разведки к сканированию, валидации и отчёту

Термины и границы: что мы делаем на самом деле

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

| Термин | Что это | Что получаем | Типичный риск | |---|---|---|---| | Сканирование портов | Поиск открытых портов и доступных протоколов | Список host:port | Повышенная нагрузка при высоком параллелизме | | Идентификация сервисов | Определение продукта/версии по баннеру и ответам | Гипотеза “что это за сервис” | Ложные срабатывания по баннерам | | Вульн-сканирование | Автопроверки на известные уязвимости и опасные настройки | Список потенциальных уязвимостей | Ложноположительные, риск «шумных» проверок | | Ручная валидация | Аккуратная проверка ключевых находок человеком | Подтверждённый риск и воспроизводимость | Риск воздействия, если действовать без ограничений |

Важно понимать: автоматический сканер редко даёт доказательство эксплуатации. Его задача — подсказать, куда смотреть и что перепроверить.

Безопасность и предсказуемость: как сканировать этично

Перед стартом активных проверок убедитесь, что у вас согласованы:

список активов in-scope (IP, подсети, домены, стенды)

окна работ и лимиты интенсивности (скорость запросов, параллельность)

запреты (например, DoS, массовый подбор паролей, агрессивные проверки)

stop conditions (когда вы обязаны остановиться)

контакт для срочной связи (SOC/дежурный)

Практика, которая почти всегда улучшает результат и снижает риск:

начинать с узкого безопасного профиля сканирования

постепенно расширять покрытие, если нет побочных эффектов

фиксировать, что именно запускалось: параметры, время, источник, цели

Сканирование сети: от «что живо» к «что именно слушает порт»

Обнаружение хостов (host discovery)

Задача — понять, какие узлы отвечают, чтобы не сканировать «пустоту» и не создавать лишний шум.

Что может пойти не так:

ICMP может быть запрещён, и хост будет казаться недоступным

некоторые проверки могут триггерить IDS/IPS и давать непредсказуемые ответы

Поэтому метод обнаружения хостов и параметры должны соответствовать RoE.

Сканирование портов

Задача — получить список открытых TCP/UDP-портов.

Практические замечания:

полный диапазон портов и UDP часто значительно «тяжелее», чем кажется

лучше начинать с топ-портов и расширять при необходимости

на проде почти всегда нужны лимиты скорости и параллельности

Инструмент-дефакто для этого класса задач — Nmap.

Иллюстративные команды ниже предназначены для лабораторий и тестовых стендов; IP-адреса из документационных диапазонов.

-sS SYN-скан (часто быстрее и «бережнее», чем полный connect)

-Pn не выполнять предварительный ping (полезно, если ICMP запрещён)

-T3 умеренный тайминг (обычно безопаснее, чем агрессивные профили)

--top-ports 100 быстрый старт с наиболее частых портов

Определение версии и типа сервиса

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

-sV пытается определить продукт и версию по ответам сервиса

Ограничения:

баннеры могут быть скрыты или подменены

прокси, WAF и балансировщики могут маскировать реальный бэкенд

Поэтому результаты -sV — это гипотеза, которую нужно подтверждать.

NSE-скрипты: точечные проверки

У Nmap есть движок скриптов NSE (Nmap Scripting Engine), который позволяет выполнять дополнительные проверки: от безопасного сбора параметров TLS до обнаружения типовых ошибок конфигурации.

Документация:

Nmap Scripting Engine

Пример безопасного направления: сбор информации о TLS (версии протоколов, сертификаты) с последующим анализом.

Вульн-сканирование: как работают сканеры и почему им нельзя «верить на слово»

Вульн-сканеры обычно используют комбинацию подходов:

сопоставление версии продукта с базой известных уязвимостей

проверка «сигнатурами» (специфическими запросами и анализом ответов)

проверка конфигураций (слабые шифры TLS, небезопасные методы, открытые панели)

иногда — безопасные PoC-проверки, но это всегда зависит от политики конкретного сканера

Примеры распространённых классов решений:

коммерческие: Tenable Nessus

open source/комьюнити: Greenbone Vulnerability Management (исторически связан с OpenVAS)

Неаутентифицированное и аутентифицированное сканирование

| Режим | Что видит сканер | Плюсы | Минусы | |---|---|---|---| | Неаутентифицированное | Только то, что доступно извне | Безопаснее организационно, проще запускать | Много пропусков и неточностей | | Аутентифицированное | Состояние системы «изнутри» (пакеты, конфиги, патчи) | Точнее и полезнее для исправления | Требует учёток, осторожности и правил работы с секретами |

Аутентифицированное сканирование почти всегда даёт более качественный результат, но предъявляет требования к этике и процессу:

учётные данные должны быть выданы и согласованы заказчиком

хранение секретов должно соответствовать RoE (шифрование, срок хранения, доступ)

права учётки должны быть минимально достаточными

Анализ результатов: как превращать «выгрузку сканера» в выводы пентеста

Сканирование даёт много данных. Ваша задача — превратить их в приоритетный список проверок и подтверждённых рисков.

Нормализация и дедупликация

Приведите результаты к единому виду:

единый список активов host -> порты -> сервисы

пометки: подтверждено, не подтверждено, требует проверки, out-of-scope

источники и время: когда и чем получены данные

Сопоставление с публичными базами уязвимостей

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

Надёжные источники:

NVD (National Vulnerability Database)

MITRE CVE

Практическое правило: не ограничивайтесь «популярными блогами»; используйте первичные базы и вендорные advisory.

Ложноположительные и ложноотрицательные

Два типовых режима ошибок:

ложноположительное: сканер сообщает уязвимость, но она не воспроизводится

ложноотрицательное: сканер «не видит» проблему из-за маскировки версии, фильтрации, нестандартной конфигурации, WAF

Поэтому важные находки нужно перепроверять.

Валидация: что считается «подтверждением»

Критерий подтверждения должен быть согласован в RoE. Часто достаточно:

воспроизводимого запроса/ответа, который демонстрирует проблему

минимального доказательства доступа (например, чтение одного тестового объекта)

скриншота, фрагмента лога или ответа сервера без раскрытия секретов

Если проверка требует потенциально опасных действий, остановитесь и согласуйте с контактным лицом.

Типовые находки при сканировании сетей и сервисов

Ниже — классы проблем, которые часто проявляются уже на этапе сканирования и первичного анализа.

| Категория | Как проявляется | Почему это важно | |---|---|---| | Устаревшие версии сервисов | Сервис определяется как старая версия | Часто коррелирует с известными CVE | | Открытые админ-панели | Доступны панели управления из внешней сети | Увеличение поверхности атаки | | Слабая TLS-конфигурация | Старые протоколы/шифры, ошибки сертификатов | Риски перехвата, понижения безопасности | | Анонимный/гостевой доступ | Сервис доступен без аутентификации | Часто ведёт к утечкам или изменению данных | | Избыточная экспозиция | Сервис доступен извне без необходимости | Нарушение принципа минимальной доступности |

Важно: наличие «открытого порта» не всегда уязвимость. Часто это повод задать архитектурный вопрос: почему этот сервис вообще доступен из этой сети?

Приоритизация: что проверять в первую очередь

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

Удобный практический подход:

сначала то, что доступно снаружи и ведёт к критичным активам

затем то, что может дать повышение привилегий или доступ к секретам

затем «гигиена» (слабые настройки, информационные находки)

Что помогает приоритизировать:

критичность затронутого актива (деньги, персональные данные, админ-доступ)

эксплуатируемость в ваших условиях (есть ли путь атаки, есть ли доступ)

ограничения RoE (например, если эксплуатация запрещена, вы фиксируете ограничение покрытия)

Артефакты и отчётность: что сохранять

Чтобы результаты были воспроизводимыми и полезными:

параметры сканирования (команда, профиль, список целей)

временные метки и источник выполнения

необработанные результаты (в формате инструмента) и нормализованная сводка

минимальные доказательства по ключевым находкам

список ограничений и спорных зон (например, активы, которые выглядят связанными, но не подтверждены как in-scope)

Отдельно: секреты (пароли, токены, приватные ключи) нельзя сохранять в отчёте в открытом виде. Если они случайно попались, действуйте по процедуре уведомления и минимизации из RoE.

Частые ошибки

сканировать «всё подряд», не проверив in-scope

использовать агрессивные тайминги и параллелизм на проде

воспринимать вывод сканера как факт без валидации

не фиксировать параметры запуска, из-за чего результаты нельзя повторить

не связывать находки с угрозами и ценностью активов, превращая отчёт в «простыню CVE»

Итог

Сканирование и анализ уязвимостей сетей и сервисов — это мост между разведкой и глубокими ручными проверками.

На этом этапе вы:

подтверждаете реальную экспозицию сервисов

получаете гипотезы о продуктах, версиях и конфигурациях

выделяете кандидатов на уязвимости и ошибки архитектуры

формируете приоритетный план ручной валидации

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

Эксплуатация: веб, сеть, привилегии и постэксплуатация

Зачем нужен этап эксплуатации

В предыдущих модулях вы:

зафиксировали рамки законности, скоуп и RoE

построили карту поверхности атаки через разведку и OSINT

провели сканирование портов и анализ потенциальных уязвимостей

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

При этом эксплуатация в этичном пентесте почти никогда не выглядит как "взять готовый эксплойт и запустить". Чаще это:

проверка гипотезы минимально достаточными действиями

подтверждение влияния на реальные активы из модели угроз

сбор доказательств, которые воспроизводимы и безопасны

Главный принцип остаётся прежним: разрешено только то, что явно разрешено, а уровень воздействия ограничен RoE.

!Показывает, как эксплуатация связана с предыдущими этапами и куда ведёт дальше

Термины простыми словами

Эксплуатация

Эксплуатация — это подтверждение уязвимости действием, которое демонстрирует реальный эффект.

Примеры эффектов:

чтение данных, которые не должны быть доступны

выполнение действия от имени другого пользователя

получение доступа к административной функции

Proof of Concept

Proof of Concept (PoC) — минимальный воспроизводимый сценарий, который доказывает проблему.

В этичном пентесте PoC должен быть:

минимальным по воздействию

согласованным по правилам

достаточным по доказательности

Повышение привилегий

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

Постэксплуатация

Постэксплуатация — действия после получения доступа, цель которых:

оценить реальный ущерб и охват

проверить возможные цепочки (в пределах разрешений)

собрать данные для отчёта

корректно завершить работу и убрать следы теста (в рамках правил)

Рамки безопасности: что обязательно определить до подтверждения уязвимости

Если вы дошли до точки, где потенциально возможно воздействие на данные или доступ, проверьте, что в RoE определены:

Критерии доказательства

1. Что считается подтверждением: скриншот, ответ сервера, запись в логе. 2. Допустимо ли создавать тестовые сущности: тестовый заказ, тестовый пользователь.

Правила работы с данными

1. Разрешено ли скачивать файлы, и какие. 2. Как маскировать персональные данные и секреты. 3. Как хранить артефакты и когда удалять.

Стоп-условия

1. Что делать при признаках деградации сервиса. 2. Кого уведомлять при критическом доступе.

Границы допустимых техник

1. Разрешена ли эксплуатация до получения shell. 2. Разрешены ли действия, похожие на закрепление (обычно запрещены).

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

Универсальный рабочий процесс эксплуатации

Ниже — безопасный процесс, который одинаково применим к вебу, сети и проверкам привилегий.

Сформировать гипотезу

1. Что именно уязвимо и почему вы так думаете. 2. Какие предпосылки нужны: роль, доступ, конкретный endpoint, сетевой маршрут.

Выбрать минимальный PoC

1. Как доказать риск без массовых действий. 2. Какой артефакт будет доказательством.

Подготовить контроль воздействия

1. Лимиты частоты запросов. 2. Тестовые данные вместо реальных, если возможно. 3. План отката: как вернуть состояние, если вы что-то создали.

Выполнить подтверждение и зафиксировать результат

1. Записать точные шаги воспроизведения. 2. Сохранить минимально достаточные доказательства.

Оценить влияние и возможность цепочки

1. Что становится доступно после успешного шага. 2. Можно ли повысить привилегии или выйти на критичный актив.

Остановиться вовремя

1. Не выходить в закрепление и скрытность, если это не разрешено. 2. Не собирать данные "про запас".

Эксплуатация веб-уязвимостей: типовые классы и безопасное подтверждение

Веб-эксплуатация чаще всего вращается вокруг трёх вопросов:

кто вы как пользователь

что вам разрешено

как приложение обрабатывает ваш ввод

Ниже — распространённые классы проблем и то, что обычно считают корректным PoC.

Ошибки аутентификации и сессий

Аутентификация отвечает на вопрос "кто вы".

Типовые проблемы:

слабые механики восстановления доступа

неправильное истечение сессии

ошибки в реализации многофакторной аутентификации

Признак хорошего PoC:

Вы показываете воспроизводимый сценарий.

Вы демонстрируете эффект на одной тестовой учётке.

Вы не используете массовый подбор паролей, если это не разрешено.

Полезная методологическая опора:

OWASP Web Security Testing Guide

Ошибки авторизации: IDOR и обходы доступа

Авторизация отвечает на вопрос "что вам разрешено".

IDOR (Insecure Direct Object Reference) — ситуация, когда пользователь может получить доступ к объекту, просто изменив идентификатор объекта, и приложение не проверяет права должным образом.

Примеры объектов:

профиль пользователя

заказ

файл

API-ресурс

Признак хорошего PoC:

Две учётки с одинаковой ролью.

Один конкретный объект.

Демонстрация чтения или изменения чужого объекта минимальным действием.

Инъекции: когда ввод становится командой

Инъекция — класс уязвимостей, где данные пользователя интерпретируются системой как инструкция.

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

Бережная логика подтверждения:

Сначала доказать, что ввод влияет на запрос или интерпретацию.

Затем подтвердить воздействие без разрушительных действий.

Если нужен более сильный PoC, согласовать его отдельно.

Методологическая опора по самому известному классу инъекций:

OWASP SQL Injection

SSRF и доступ к внутренним ресурсам

SSRF (Server-Side Request Forgery) — ситуация, когда серверное приложение по вашему запросу делает сетевой запрос "куда-то ещё", и этим можно достучаться до внутренних адресов или метаданных.

Почему это опасно:

внутренние сервисы часто доверяют запросам "изнутри"

можно получить доступ к конфигурациям и секретам

Корректный PoC в этичном пентесте обычно:

Использует тестовый, заранее согласованный адрес назначения.

Демонстрирует факт исходящего запроса или доступ к безопасному ресурсу.

Не использует сканирование внутренних диапазонов, если это не разрешено.

Загрузка файлов и обработка контента

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

принимает опасные типы файлов

хранит их так, что они исполняются или становятся доступны всем

не изолирует обработку файлов

Безопасный PoC:

Загрузка безвредного тестового файла.

Демонстрация нарушения правил доступа или типа.

Отказ от выполнения кода, если это не разрешено.

Как фиксировать доказательства по вебу

Обычно достаточно:

точного URL и метода запроса

параметров, которые влияют на поведение

фрагмента ответа, демонстрирующего проблему

скриншота или экспортированного запроса из инструмента перехвата

Инструмент для ручной валидации и воспроизведения запросов:

Документация Burp Suite

Эксплуатация в сети и сервисах: где чаще всего подтверждается риск

Для сетевых сервисов эксплуатация часто означает подтверждение одного из сценариев:

несанкционированный доступ

выполнение административного действия

чтение конфигураций или данных

доступ к управлению сервисом

Опасные конфигурации и избыточная экспозиция

Часто критичность определяется не CVE, а тем, что сервис вообще доступен не из той зоны.

Примеры ситуаций, которые можно подтверждать бережно:

панель администрирования доступна из внешней сети

сервис не требует аутентификации там, где должен

включены устаревшие или слабые режимы шифрования

PoC обычно сводится к демонстрации:

факта доступности

отсутствия требуемой аутентификации

административных возможностей интерфейса

Ошибки управления учётными данными

Это отдельный класс рисков:

стандартные или слабые пароли

пароли, совпадающие с сервисным именем

учётки с избыточными правами

Важное ограничение: любые проверки, похожие на перебор паролей, должны быть явно разрешены RoE и ограничены по скорости.

Связка "доступ к сервису" -> "доступ к системе"

Нередко эксплуатация начинается с малого:

доступ к сервису мониторинга

доступ к панели CI/CD

доступ к административной консоли

А затем приводит к большому:

чтение секретов

доступ к реестрам контейнеров

запуск задач от привилегированного пользователя

Здесь особенно важно не выходить за рамки разрешений и остановиться на минимальном доказательстве.

Повышение привилегий: зачем и как это делать безопасно

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

Два типа повышения привилегий

Вертикальное

1. Получить более высокую роль: пользователь -> администратор. 2. Обычно связано с ошибками авторизации или настройками системы.

Горизонтальное

1. Получить доступ к данным другого пользователя с теми же правами. 2. Часто проявляется как IDOR или неправильные проверки владения объектом.

Типовые причины повышения привилегий в системах

Без углубления в конкретные техники, важно понимать базовые источники риска:

Ошибки конфигурации

1. Избыточные права сервисных учёток. 2. Небезопасные настройки запуска задач.

Ошибки управления секретами

1. Ключи и токены в конфигурационных файлах. 2. Секреты в логах и переменных окружения.

Неправильные границы доверия

1. Сервис доверяет любому запросу из внутренней сети. 2. Отсутствует сегментация.

Минимально достаточное подтверждение повышения привилегий

В пентесте полезнее доказать факт повышения привилегий, чем "выжать максимум".

Примеры корректного доказательства:

демонстрация доступа к административной операции, ранее недоступной

чтение одного защищённого системного параметра, если это разрешено

демонстрация роли в панели управления

!Помогает понять, где заканчивается подтверждение и начинаются рискованные действия

Постэксплуатация: как оценить ущерб и не превратить пентест в инцидент

Постэксплуатация имеет смысл только как часть согласованной цели: оценить влияние.

Типовые задачи постэксплуатации

определить, какие данные и функции доступны после входа

проверить, можно ли дойти до критичного актива из модели угроз

оценить возможность распространения доступа в пределах разрешённого

собрать артефакты для отчёта

Что обычно запрещено без отдельного согласования

Даже если это технически возможно, без явного разрешения обычно нельзя:

закрепляться в системе (создавать скрытые учётки, механизмы автозапуска)

отключать защиту или чистить логи

скачивать массивы данных

проводить действия, похожие на вымогательское ПО или разрушение

Минимизация данных и артефактов

Практичные правила:

Сначала определите, что нужно доказать.

Затем соберите минимальный фрагмент, который это доказывает.

Секреты маскируйте, а не вставляйте в отчёт целиком.

Корректное завершение работ

В конце теста полезно:

удалить тестовые сущности, если это согласовано

передать заказчику список затронутых объектов

подтвердить сроки хранения и удаления артефактов

Как оформить результаты эксплуатации в отчёте

Хорошая эксплуатация отличается от "нашёл уязвимость" тем, что её можно воспроизвести и исправить.

Удобный шаблон описания находки:

Краткое описание

Затронутые активы

Предпосылки

1. Доступ, роль, сетевой маршрут.

Шаги воспроизведения

1. Коротко и точно, без лишнего.

Фактический результат

Ожидаемый результат

Влияние

1. Что может получить атакующий.

Доказательства

1. Скриншот, фрагмент ответа, лог.

Рекомендации

1. Быстрые меры. 2. Долгосрочные меры.

Ограничения покрытия

Чтобы связывать результаты с индустриальными практиками, можно использовать:

OWASP Top 10

MITRE ATT&CK

Где безопасно тренироваться

Эксплуатация требует практики, но практиковаться нужно только на легальных стендах.

Подходящие учебные платформы:

OWASP Juice Shop

Damn Vulnerable Web Application (DVWA)

Metasploitable 2

Практическая цель тренировок в лаборатории:

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

научиться фиксировать доказательства

научиться останавливаться на достаточном уровне воздействия

Итог

Эксплуатация в этичном пентесте — это контролируемое подтверждение риска:

в вебе чаще всего подтверждаются ошибки аутентификации, авторизации и обработки ввода

в сети часто критичны конфигурации, экспозиция и управление учётными данными

повышение привилегий показывает, может ли точка входа привести к серьёзному ущербу

постэксплуатация нужна для оценки влияния и подготовки качественного отчёта, а не для "максимального захвата"

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

Беспроводные и социальная инженерия: риски и проверка

Зачем это в курсе пентеста

В предыдущих модулях курса мы выстроили базовый «конвейер» этичного пентеста: согласование скоупа и RoE, разведка и OSINT, сканирование, аккуратная валидация и подтверждение рисков через минимальные PoC.

Беспроводные сети и социальная инженерия часто становятся самыми короткими путями к компрометации, но при этом несут повышенные юридические и операционные риски:

беспроводной тест затрагивает радиосреду и может случайно «зацепить» третьих лиц

социальная инженерия затрагивает людей, репутацию и процессы, а не только технологии

Поэтому ключевая мысль этой статьи: в wireless и social engineering границы и правила важнее инструментов. Проверка должна быть спланирована так, чтобы дать измеримый результат и не превратиться в инцидент.

Общие принципы перед любыми проверками

Скоуп и разрешения

Для беспроводных и социальной инженерии скоуп должен быть особенно конкретным:

какие локации разрешены (адреса, этажи, зоны)

какие SSID/BSSID и какие сегменты сети относятся к заказчику

какие действия разрешены (только наблюдение или также активные проверки)

кого можно вовлекать (категории сотрудников, подрядчики, исключения)

Практическое правило из первых статей курса здесь работает жёстко: если объект или действие не названы явно — это out-of-scope.

RoE и stop conditions

В RoE для этих типов работ обычно фиксируют:

временные окна и контакт дежурного

запрет на действия, создающие помехи и простой

правила обращения с данными людей (персональные данные, учётные данные)

чёткие критерии остановки работ

Полезный ориентир по управляемости работ как процесса — Penetration Testing Execution Standard (PTES).

Беспроводные сети: термины и модель риска

Базовые термины

Wi‑Fi точка доступа (AP) — устройство, которое предоставляет беспроводное подключение.

SSID — имя Wi‑Fi сети, которое видит пользователь.

BSSID — идентификатор точки доступа (обычно MAC-адрес радио-интерфейса).

Клиент — устройство, подключающееся к Wi‑Fi (ноутбук, телефон, терминал).

WPA2/WPA3 — распространённые семейства протоколов защиты Wi‑Fi.

WPA2‑Enterprise / 802.1X — режим, где аутентификация обычно идёт через RADIUS и персональные учётные данные.

Гостевая сеть — сегмент, отделённый от корпоративных ресурсов (в идеале).

Почему беспроводной периметр «живёт своей жизнью»

Wi‑Fi часто «выпадает» из общего управления безопасностью:

точки доступа ставят как инфраструктуру «для удобства», а не как критичный актив

конфигурации и прошивки обновляют реже, чем серверы

граница сети может выходить за стены офиса

появляются IoT-устройства и «гостевые» клиенты, которые сложно контролировать

Рекомендации по общим подходам к безопасности wireless можно сверять с NIST SP 800-153: Guidelines for Securing Wireless Local Area Networks (WLANs).

!Диаграмма показывает, где в Wi‑Fi проходят границы доверия и какие компоненты важны для оценки риска

Типовые риски беспроводной среды

Ниже — классы проблем, которые чаще всего приводят к реальным цепочкам атак.

Ошибки конфигурации и криптографии

устаревшие режимы безопасности и слабые настройки

включённые небезопасные «упрощающие» функции

отсутствие защиты управленческих интерфейсов

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

Недостаточная сегментация и избыточный доступ

гостевая сеть имеет доступ к внутренним системам

Wi‑Fi клиентов не изолируют друг от друга там, где это нужно

сетевые ACL и правила межсетевого экрана не соответствуют модели угроз

Подмена инфраструктуры и доверие к «внутреннему»

риск подключения пользователей к «не той» сети из-за похожих имён

недостаточные проверки подлинности сети со стороны клиента

доверие внутренних сервисов к любому трафику «изнутри» Wi‑Fi

Риски управления устройствами

одинаковые пароли на точки доступа

слабые пароли на админ-панели

отсутствие централизованного мониторинга и обновлений

Как проводить wireless-проверку этично и безопасно

Что согласовать до выхода «в поле»

Локации и допустимые зоны работы.

Перечень SSID/BSSID, которые точно принадлежат заказчику.

Типы проверок.

Правила работы с данными.

Процедуру эскалации, если выявлен критический доступ.

Отдельная практическая деталь: в радиосреде легко увидеть идентификаторы устройств (например, MAC). Во многих юрисдикциях это может считаться персональными данными или как минимум чувствительными техническими данными. Поэтому в RoE обычно фиксируют, как их хранить и как обезличивать.

Пассивная и активная оценка

Пассивная оценка — наблюдение и инвентаризация (что вещает в эфире, какие сети видны, какие параметры безопасности заявлены).

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

Пассивный режим обычно безопаснее и чаще разрешён по умолчанию. Активный почти всегда требует более строгих ограничений.

Рекомендуемый процесс (в терминах «управляемого пентеста»)

Уточнить список разрешённых SSID/BSSID и зафиксировать доказательства принадлежности.

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

Сопоставить результаты с тем, что ожидал заказчик.

Проверить конфигурационные риски и архитектуру доступа.

Проверить сегментацию и маршруты до критичных активов в рамках RoE.

Сформировать выводы: какой сценарий атаки возможен и что исправить.

На что обычно накладывают запрет

В типичном RoE для Wi‑Fi часто запрещают:

любые действия, создающие радиопомехи и деградацию связи

действия, затрагивающие сети или клиентов третьих лиц

массовые и агрессивные попытки подбора учётных данных

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

Что считать доказательством и как оформлять wireless-находки

Хорошая находка по Wi‑Fi — это не «в эфире видно SSID», а связка:

предпосылка (где, при каких условиях, какая сеть)

наблюдение/факт (какой параметр или маршрут подтверждён)

влияние (к чему это ведёт в модели угроз)

рекомендация (что изменить)

Примеры артефактов, которые обычно достаточны:

скриншот/экспорт параметров безопасности сети (без раскрытия секретов)

схема сегментации и подтверждение маршрута (например, доступность конкретного внутреннего сервиса с гостевой сети)

перечень затронутых точек доступа и локаций

Что обычно нельзя или нежелательно прикладывать:

реальные пароли и ключи

идентификаторы личных устройств сотрудников без обезличивания

массивы сетевых данных «на всякий случай»

Меры защиты Wi‑Fi, которые чаще всего дают наибольший эффект

переход на более современные режимы безопасности и отключение небезопасных опций

802.1X там, где нужен персональный контроль доступа

строгая сегментация гостевой сети

централизованное управление, обновления, мониторинг

контроль подключаемых устройств и минимизация доверия к «внутренней сети»

Для структурирования проверок и отчётности полезно мыслить категориями «границы доверия» из моделирования угроз, описанного ранее.

Социальная инженерия: что это и зачем её проверять

Определение

Социальная инженерия — это получение доступа или информации через влияние на поведение людей и процессы.

В отличие от «чисто технических» уязвимостей, здесь объект проверки — не код, а сочетание:

осведомлённости и привычек сотрудников

процедур (как подтверждают личность, как согласуют доступ)

технических мер (MFA, фильтрация почты, изоляция браузера)

Типовые сценарии (на уровне классов)

фишинг по электронной почте

сообщения в мессенджерах и SMS

телефонные сценарии (vishing)

сценарии с физическим доступом (проход «за спиной», выдача себя за подрядчика)

Для связи с индустриальными моделями атак полезна база техник MITRE ATT&CK, например, техника фишинга Phishing (T1566).

Как проводить проверку социальной инженерии этично

Социальная инженерия почти всегда требует расширенного согласования, потому что затрагивает людей напрямую.

Что обязательно фиксировать в скоупе и RoE

цели проверки (например, оценить устойчивость к фишингу, а не «любой ценой добыть пароль»)

аудитория (какие подразделения участвуют, есть ли исключения)

допустимые каналы (почта, телефон, физические визиты)

правила по персональным данным и учётным данным

формат метрик и отчёта

правила коммуникации с HR, юридической службой и SOC

Безопасная модель доказательств

В зрелых программах социальную инженерию стараются делать так, чтобы не собирать реальные секреты:

использовать симуляции вместо реального перехвата паролей

если ввод данных неизбежен по цели теста, заранее определить минимальный набор и правила хранения

избегать «публичного стыда» и персонального наказания по результатам

Stop conditions для social engineering

Примеры типовых условий остановки работ:

признаки реального инцидента (например, массовые обращения в поддержку)

нештатные последствия для бизнес-процессов

выход за согласованную аудиторию

риск раскрытия чувствительных персональных данных

!Схема показывает социальную инженерию как измеримый и управляемый процесс, а не «трюк»

Как измерять результат и не исказить выводы

Социальная инженерия ценна тогда, когда даёт измеримые выводы и улучшения.

Примеры полезных метрик

доля пользователей, которые распознали попытку и правильно сообщили о ней

время до первого сообщения в SOC/службу поддержки

доля пользователей, которые выполнили рискованное действие

эффективность технических барьеров (MFA, фильтрация, блокировки)

Практическая оговорка: метрики должны интерпретироваться аккуратно. Один «успешный» сценарий может быть связан с конкретной формулировкой, временем суток и контекстом.

Типовые меры защиты от social engineering

Социальная инженерия лучше всего снижается комбинацией мер:

обучение и регулярные контролируемые симуляции

понятные каналы «как сообщить о подозрении»

MFA и устойчивые процессы восстановления доступа

защита почты и домена (например, SPF/DKIM/DMARC как часть антиспуфинга)

процессы подтверждения личности и запреты на опасные операции без вторичного контроля

Методологически полезно опираться на практики OWASP по тестированию веба и процессов вокруг него, например через структуру OWASP Web Security Testing Guide, даже если сама атака социальная, потому что итог часто упирается в веб-аутентификацию и сессии.

Как связать wireless и social engineering с остальным пентестом

Эти направления редко существуют отдельно. Они часто выступают «входом» в те цепочки атак, которые вы описывали в модуле про эксплуатацию:

Wi‑Fi доступ может привести к проверкам внутренней сегментации и доступов

социальная инженерия может привести к доступу к учётной записи и проверке авторизаций, ролей, доступов к данным

Критически важно в отчёте честно фиксировать ограничения покрытия:

что было запрещено RoE

какие сценарии не проверялись

какие выводы сделаны по косвенным признакам

Итог

Беспроводные сети и социальная инженерия — это два класса рисков, где «короткий путь» к компрометации часто проходит не через сложный эксплойт, а через конфигурацию, доверие и процессы.

Этичная проверка строится на тех же принципах, что и весь курс:

чёткий скоуп и RoE

минимизация воздействия и данных

воспроизводимые доказательства

выводы в терминах сценариев риска и конкретных исправлений

Эти проверки дают максимальную пользу, когда встроены в общий контур: от модели угроз и разведки — к подтверждению, отчётности и ретесту исправлений.

Отчётность и ремедиация: доказательства, риск и рекомендации

Зачем этот этап нужен после эксплуатации

Предыдущие модули курса вели вас по цепочке подготовка → разведка → сканирование → валидация и эксплуатация → беспроводные и социальная инженерия. На каждом шаге вы собирали факты: какие активы существуют, какие сервисы доступны, какие сценарии компрометации подтверждаются.

Отчётность и ремедиация превращают эти факты в результат, который:

понятен бизнесу и техническим командам

воспроизводим (можно повторить и проверить исправление)

безопасен (не раскрывает секреты и персональные данные)

приводит к улучшениям (фиксы, компенсирующие меры, изменения процессов)

Ключевая идея: пентест ценен не находками, а тем, что заказчик реально исправит и сможет проверить. Поэтому качество отчёта и качество рекомендаций — часть профессионализма пентестера.

!Как находки превращаются в исправления и проверку результата

Что должно получиться на выходе

Типовые deliverables по итогам пентеста:

Executive summary (для руководства)

1. что тестировали и в каких ограничениях 2. главные риски и их бизнес-влияние 3. приоритеты исправлений

Технический отчёт (для инженеров)

1. список находок с доказательствами 2. шаги воспроизведения 3. рекомендации по устранению и предотвращению повторения

Артефакты и приложения

1. подтверждающие логи, скриншоты, выдержки request/response (в минимальном объёме) 2. параметры сканирования (команды, профили) 3. список ограничений покрытия (что не тестировали и почему)

Коммуникация по критическим находкам

1. быстрые уведомления во время теста 2. разбор с командами

Ретест (повторная проверка)

1. подтверждение, что уязвимость устранена 2. проверка, что исправление не сломало функциональность и не создало новый класс проблемы

Доказательства: что считается достаточным и безопасным

Принцип минимально достаточного доказательства

Доказательства нужны, чтобы:

подтвердить реальность проблемы

обеспечить воспроизводимость

помочь инженерам быстро проверить исправление

При этом доказательства не должны превращаться в утечку.

Практические правила:

Достаточно одного примера вместо выгрузки массива данных.

Секреты не включаются в отчёт в открытом виде.

Артефакты защищаются (шифрование, контроль доступа, срок хранения) — как было согласовано в RoE.

Какие виды доказательств чаще всего используют

| Тип находки | Минимальное доказательство | Что важно замаскировать | |---|---|---| | IDOR/ошибка авторизации | Два запроса от двух пользователей + факт доступа к чужому объекту | Идентификаторы пользователей, персональные данные | | Инъекция | Запрос, показывающий влияние ввода, и безопасный эффект (например, логическое различие в ответе) | Сессионные токены, ключи | | SSRF | Подтверждение исходящего запроса на согласованный тестовый адрес | Внутренние IP/имена, если это чувствительно | | Ошибка конфигурации сервиса | Вывод команды/сканера, подтверждающий параметр (TLS, открытая панель) | Внутренние хостнеймы, серийные номера | | Слабые права/привилегии | Скриншот/ответ, демонстрирующий недоступную ранее функцию | Учётные данные, токены |

Маскирование данных: как делать правильно

Чтобы отчёт оставался полезным, но безопасным, используйте маскирование по принципу сохраняем структуру, скрываем значение.

Примеры:

токен Authorization: Bearer eyJ... показывают как Authorization: Bearer <redacted>

e-mail ivan.petrov@example.com показывают как i*@example.com

часть идентификатора оставляют для сопоставления: user_id=183742 → user_id=183*

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

Риск: как объяснять критичность без «магии баллов»

В отчёте важно не просто назвать уязвимость, а объяснить риск.

Из чего обычно складывается риск

В практической пентест-отчётности риск удобно описывать как сочетание:

Влияние

1. что можно потерять: деньги, данные, контроль над системой 2. какая глубина доступа достигается

Вероятность

1. насколько доступен вектор атаки (интернет/внутренняя сеть/нужна учётка) 2. насколько сложна эксплуатация 3. нужны ли дополнительные условия

Часто это оформляют как простую матрицу.

| Вероятность \ Влияние | Низкое | Среднее | Высокое | |---|---|---|---| | Низкая | Низкий | Низкий/Средний | Средний | | Средняя | Низкий/Средний | Средний | Высокий | | Высокая | Средний | Высокий | Критический |

Важно: метод оценки должен быть согласован с заказчиком, иначе разные команды будут по-разному трактовать приоритеты.

CVSS: когда уместно и как не ошибиться

CVSS (Common Vulnerability Scoring System) полезен, когда:

вы описываете риск в терминах стандартной модели

заказчик использует CVSS в процессах управления уязвимостями

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

Надёжные источники:

Спецификация CVSS v3.1

Калькулятор CVSS v3.1

Если вы используете CVSS, в отчёте стоит указать:

вектор (строка параметров)

итоговый балл

краткое объяснение, почему выставлены такие параметры

Структура хорошей находки в техническом отчёте

Чтобы инженеры могли быстро исправить проблему, находка должна быть воспроизводимой и однозначной.

Рекомендуемый шаблон (одна находка = один блок):

Название

Затронутые активы

Краткое описание

Предпосылки

1. роль/учётная запись 2. сетевой доступ 3. условия окружения

Шаги воспроизведения

1. конкретные запросы/действия 2. минимально достаточные данные

Фактический результат

Ожидаемый результат

Влияние

1. что получает атакующий 2. возможные цепочки (в рамках того, что вы реально подтвердили)

Доказательства

1. фрагменты ответов, скриншоты, логи (с маскированием)

Рекомендации

1. быстрые меры 2. системные меры

Ссылки и классификация (по необходимости)

1. CWE как категория слабости 2. OWASP Top 10 как бизнес-понятная группировка

Полезные справочники:

CWE (каталог типовых слабостей)

OWASP Top 10

Executive summary: как писать для руководства

Руководству обычно не нужны детали request/response. Им важно понять:

что это значит для бизнеса

что исправлять в первую очередь

как быстро можно снизить риск

Практичная структура executive summary:

Контекст

1. цели и тип теста (внешний/внутренний, с учётками или без) 2. даты, окна работ 3. ключевые ограничения RoE

Главные выводы

1. 3–7 самых важных рисков 2. 1–3 типовых системных причины (например, «ошибки авторизации повторяются в разных модулях»)

Приоритетный план действий

1. быстрые меры (дни) 2. среднесрочные (недели) 3. долгосрочные (квартал)

Ограничения покрытия

1. что не тестировалось и почему

Важная этическая деталь: executive summary не должен превращаться в «страшилку». Тон должен быть деловым: риск, доказательства, план снижения.

Рекомендации: как делать их исполнимыми

Плохая рекомендация: «исправьте авторизацию».

Хорошая рекомендация:

привязана к конкретному месту в системе

даёт проверяемый критерий результата

предлагает безопасный путь внедрения

Два уровня рекомендаций

Обычно полезно разделять:

Быстрые меры

1. закрыть внешний доступ к панели 2. отключить опасную конфигурацию 3. добавить временный WAF-правил/ACL

Системные меры

1. внедрить единый middleware авторизации 2. добавить тесты (unit/integration) на контроль доступа 3. провести ревизию ролей и прав

Критерии качества рекомендации

Проверочный список:

конкретность: что именно менять

проверяемость: как подтвердить, что стало безопасно

влияние на продукт: какие риски поломки и как их контролировать

предотвращение повторения: почему это не появится снова

Полезные ориентиры для ремедиации

Если заказчик делает улучшения системно, удобно опираться на существующие практики:

OWASP ASVS (Application Security Verification Standard)

OWASP Cheat Sheet Series

ASVS полезен как «цель контроля» (что должно быть выполнено), а cheat sheets — как практические рецепты (как сделать).

Трекинг ремедиации: как превратить отчёт в план работ

Отчёт часто живёт в PDF, а исправления — в трекере задач. Чтобы не потерять смысл, делайте мост между ними.

Практичный подход:

Каждой находке присваивается стабильный идентификатор (например, PT-2026-001).

В трекере создаются задачи, которые ссылаются на этот идентификатор.

Для каждой задачи фиксируют:

1. владелец (команда) 2. приоритет и срок 3. план исправления 4. критерии приёмки (как понять, что исправлено)

Компенсирующие меры

Иногда исправление «по правильному» требует времени. Тогда важно честно зафиксировать компенсирующие меры, например:

временно ограничить доступ по сети

усилить мониторинг и детекты

включить дополнительную проверку в бизнес-процессе

Компенсирующая мера — это не «закрыли тикет», а временное снижение риска до полноценного исправления.

Ретест: как корректно проверять исправления

Ретест отвечает на вопрос: уязвимость действительно устранена?

Правила качественного ретеста:

Ретест повторяет те же шаги воспроизведения, что и в отчёте.

Ретест проверяет не только «починили точку», но и класс проблемы там, где это логично.

Результат ретеста фиксируется так же воспроизводимо:

1. что проверяли 2. в каком окружении 3. что стало иначе

Возможные статусы:

Fixed: больше не воспроизводится и нет эквивалентного обхода

Partially fixed: основной сценарий закрыт, но остаются обходы или соседние endpoints

Not fixed: воспроизводится

Cannot retest: нет доступа/изменилось окружение/нужно уточнение

Частые ошибки в отчётности

слишком много «сырых» данных без выводов и приоритетов

отсутствие чётких шагов воспроизведения

доказательства содержат секреты или персональные данные

рекомендации общие и неисполняемые

критичность не связана с активами из модели угроз

не описаны ограничения покрытия (в отчёте создаётся ложное ощущение «проверили всё»)

Итог

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

Вы должны уметь:

собирать минимально достаточные доказательства и безопасно их оформлять

объяснять риск через влияние и вероятность, не теряя бизнес-контекст

писать находки так, чтобы их можно было исправить и ретестировать

давать рекомендации двух уровней: быстрые и системные

помогать заказчику превратить отчёт в план работ и подтвердить результат ретестом

Эта дисциплина делает этичный хакинг профессиональным: вы не просто находите проблемы, вы помогаете организации стать устойчивее к атакам.