Опубликовано: 21.09.2026 | Источник: Xakep.ru

Семантический анализ перед генерацией 1. **Primary keyword:** фишинг и обход MFA в ВКР / Phishing-as-a-Service в дипломе 2. **LSI-запросы:** adversary-in-the-middle (AiTM), reverse-proxy фишинг, phishing-as-a-service, TOTP, FIDO2/WebAuthn, passkeys, DMARC/SPF/DKIM, SIEM, MITRE ATT&CK, ISO/IEC 25010, ГОСТ 34.602-89, Kubernetes, OpenTelemetry, CI/CD, Zero Trust, RTO/RPO 3. **Вопросы студентов:** как описывать архитектуру атаки, не нарушая закон; обязательно ли писать код для ВКР по ИБ; где брать метрики эффективности защиты; как обосновать выбор стека (SIEM/EDR/скрипты); как оформить схему атаки по MITRE ATT&CK 4. **Ключевые сущности:** MITRE ATT&CK, ISO/IEC 25010, ГОСТ 34.602-89, FIDO2/WebAuthn, NIST SP 800-63B, OpenTelemetry, Kubernetes, OWASP ```html

Фишинг-платформы с обходом MFA в ВКР: анализ угрозы, проектирование защиты и метрики испытаний

В начале марта 2026 года Европол отчитался о ликвидации инфраструктуры фишинговой платформы Tycoon2FA — сервиса, который продавал атакующим «под ключ» перехват сессий и обход двухфакторной аутентификации. К 25 марта платформа вернулась к почти прежним объёмам активности: новость на «Хакере». Для выпускника ИТ-направления это не просто криминальная хроника, а готовый кейс для ВКР. Он показывает три вещи, которые сейчас плохо закрыты в типовых дипломах: аутентификация на паролях и TOTP деградирует, борьба с инфраструктурой атакующего не даёт устойчивого эффекта, а защита должна проектироваться как измеримая система, а не как набор «хороших практик». Ниже — как развернуть эту мысль в защищаемую работу.

Три темы ВКР, которые вырастают из этой новости

Тема 1. Обнаружение AiTM-фишинга в корпоративной сети

Актуальность. Классический фитинг «поддельная страница → украденный пароль» уже не работает против MFA: платформы класса Tycoon2FA строят обратный прокси, через который жертва сама отдаёт валидную сессию. Значит, защита смещается с фильтрации URL на анализ поведения сессии и признаков проксирования.

Цель: разработать методику и прототип средства выявления AiTM-фишинга на основе телеметрии прокси, DNS и аутентификационных событий.

Задачи:

• разобрать публичные отчёты по PhaaS-платформам и сопоставить их тактики с матрицей MITRE ATT&CK;
• спроектировать признаки детекции: аномалии геолокации сессии, рассинхрон User-Agent и TLS-отпечатка, повторное использование cookie после смены устройства;
• реализовать правила корреляции в SIEM и оценить долю ложных срабатываний на подготовленном датасете;
• сформулировать регламент реагирования и требования к журналированию.

Структура: Глава 1 — анализ угроз и обзор источников телеметрии; Глава 2 — архитектура сбора и корреляции событий, схема потоков данных; Глава 3 — стенд, эксперименты, метрики precision/recall и рекомендации по внедрению.

Тема 2. Проектирование аутентификации, устойчивой к перехвату сессии

Актуальность. Восстановление Tycoon2FA после рейда — прямой аргумент в пользу того, что ставка на «убьём инфраструктуру» не работает. Остаётся инженерный путь: перевести сервис на FIDO2/WebAuthn и passkeys, где перехваченный прокси-канал не даёт ключа.

Цель: обосновать и спроектировать схему миграции корпоративного портала на phishing-resistant аутентификацию с оценкой стоимости и рисков перехода.

Задачи:

• сравнить TOTP, push-подтверждения и WebAuthn по стойкости к AiTM и по NIST SP 800-63B;
• построить целевую архитектуру удостоверяющего сервиса и диаграммы последовательностей регистрации/входа;
• описать поэтапную миграцию с fallback-механикой и сценариями восстановления доступа;
• рассчитать затраты на внедрение и эффект в терминах снижения ожидаемых потерь.

Структура: Глава 1 — аутентификация как процесс и её слабые места; Глава 2 — проектирование и модели данных; Глава 3 — пилот на тестовом контуре, оценка удобства и экономики.

Тема 3. Оценка живучести системы защиты после успешной атаки

Актуальность. Кейс с Tycoon2FA отлично иллюстрирует разницу между предотвращением и живучестью: даже при работающих средствах защиты часть сессий будет скомпрометирована. ВКР, которая вводит метрики RTO/RPO и моделирует ответ на инцидент, выглядит существенно сильнее стандартной работы «обзор + антивирус».

Цель: разработать модель оценки живучести защищённого сервиса и прототип дашборда для контроля восстановления.

Задачи: формализовать сценарии инцидентов; определить набор метрик по ISO/IEC 25010 (надёжность, безопасность, сопровождаемость); собрать телеметрию через OpenTelemetry; провести учения и замерить фактические RTO/RPO и MTTR.

Структура: Глава 1 — теория живучести и стандарты; Глава 2 — архитектура мониторинга и алертинга; Глава 3 — эксперименты, графики, экономическое обоснование.

Аналитическая глава: как из статьи сделать раздел сравнения решений

Первая глава обычно самая скучная — пересказ источников. Сделайте иначе: постройте её вокруг одного вопроса «почему существующие меры не сработали в этом кейсе». Сравнительная таблица ниже — скелет такого раздела, останется добавить по 2–3 источника на каждую строку.

Обоснование стека — без «я выбрал Python, потому что он популярный»

Каждый инструмент привязывайте к требованию, а требование — к задаче из списка выше. Пример рабочей связки для темы 1: сбор событий — OpenTelemetry Collector и агенты на хостах; хранение — Elasticsearch; корреляция — правила Sigma, конвертированные в формат SIEM; оркестрация стенда — Kubernetes с манифестами в git и CI/CD-пайплайном; визуализация — Grafana. Такой стек легко защищать: он проверяем, масштабируем и описан стандартными средствами.

Проектная часть: схемы, алгоритмы, интеграция

Здесь диплом выигрывают не количеством кода, а качеством моделей. Минимальный набор графики: контекстная диаграмма C4, диаграмма последовательности для сценария входа, схема потоков данных между компонентами, карта тактик по MITRE ATT&CK для разобранного кейса. Каждую диаграмму подписывайте ссылкой на источник или на собственное решение — это сразу снимает вопрос «откуда взяли».

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

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

title: MFA-сессия, использованная с двух разных отпечатков TLS
status: experimental
logsource:
  product: proxy
  service: auth
detection:
  selection:
    event: session_created
  filter:
    tls_fingerprint|exists: true
  condition: selection and filter
  timeframe: 10m
level: medium
tags:
  - attack.credential_access
  - attack.t1621

Обратите внимание: в дипломной работе правило обязательно сопровождается описанием ожидаемого поведения легитимных пользователей (мобильный + ноутбук, корпоративный VPN), иначе первая же проверка на реальных данных покажет десятки ложных срабатываний.

Испытания и метрики: чем доказывать работоспособность

Раздел испытаний — то место, где чаще всего теряются баллы. Формулировка «система работает корректно» не означает ничего. Опирайтесь на измеримые величины и указывайте методику их получения.

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

Чему вы научитесь на такой теме

• переводить новостной кейс в формализованную постановку задачи и список требований;
• проектировать архитектуру сбора телеметрии и корреляции событий, а не «рисовать антивирус»;
• обосновывать выбор стека через требования, бюджет и эксплуатационные ограничения;
• считать метрики надёжности и безопасности по ISO/IEC 25010 вместо оценочных суждений;
• оформлять ТЗ, схемы и отчёты об испытаниях в соответствии с ГОСТ 34.602-89 и ГОСТ 19.101-77.

Вопросы, которые задают чаще всего

Обязательно ли писать код для ВКР по информационной безопасности?

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

Где брать данные для экспериментов, если нет доступа к корпоративной сети?

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

Как корректно оформить схемы и UML-диаграммы?

Используйте нотации C4 и UML 2.5, но не смешивайте их в одной схеме. Каждый рисунок — номер, название, ссылка в тексте и краткое пояснение после него. Инструмент вторичен: PlantUML, draw.io или Mermaid, главное — воспроизводимость и читаемость при печати.

Насколько глубокая техническая реализация ожидается в бакалаврской ВКР?

Достаточно работоспособного прототипа, подтверждённого измерениями. Магистерская работа требует более широкой апробации и сравнения с альтернативами. Ориентируйтесь на объём задач из задания, а не на желание «сделать как у больших». Если сложно спланировать объём — это как раз тот случай, когда полезна помощь с дипломом на этапе постановки задач.

Источник: Фишинговая платформа Tycoon2FA восстановилась после операции правоохранителей (опубликовано 2026-03-25)

```