Фишинг через сервисы онлайн-опросов в ВКР по ИБ: архитектура детектора и метрики защиты
Поддомен: Cybersecurity · Роль эксперта: Специалист по ИБ
Введение: почему кейс Касперского — это готовая фактура для диплома
«Лаборатория Касперского» зафиксировала волну рассылок, где злоумышленники прячут фишинговые страницы за легитимными российскими сервисами онлайн-опросов. Только за январь–февраль 2026 года защитные решения компании заблокировали порядка 35 000 таких писем. Схема простая и потому опасная: домен в ссылке действительно принадлежит известной платформе, сертификат валиден, репутация чистая — значит, классические фильтры «плохой домен из чёрного списка» здесь не работают.
Для выпускника направления «Информационная безопасность» — это не просто новость, а готовый кейс для главы 1 (анализ угроз) и главы 2 (проектирование СЗИ). Разберём, как превратить эту историю в защищаемую ВКР с измеримым результатом, а не в реферат про «мошенников в интернете».
FAQ: что чаще всего спрашивают студенты по этой теме
Где брать данные для обучения детектора фишинга?
Три источника: PhishTank и OpenPhish (готовые фиды), собственная разметка через краулер доменов конструкторов форм, а также синтетика — генерация легитимных и поддельных страниц опросов по шаблонам. Для 35 000 писем из статьи как источника референса достаточно качественной выборки в 3–5 тыс. доменов. Указывайте в работе, что разметка проводилась вручную, с коэффициентом согласия (Cohen's kappa ≥ 0.8).
Можно ли обойтись без ML и уложиться в эвристики?
Можно, но защита будет слабее. Базовая эвристика — это комбинация SPF/DKIM/DMARC-проверок, анализ редирект-цепочек и сравнение визуального отпечатка бренда. Однако именно легитимный домен опросника обнуляет репутационные фильтры. Здесь ML-модель на признаках URL и DOM даёт выигрыш по recall. В ВКР достаточно сравнить два подхода и показать, где классическая защита «проваливается».
Какую архитектуру нужно описывать по ГОСТ 34?
Функциональную и структурную схемы, схему информационных потоков и описание алгоритма функционирования. Практически удобно продублировать их в нотации C4 (Context + Container). ГОСТ 34.602 требует ТЗ, а C4 даёт понятную декомпозицию для пояснительной записки.
Как считать эффективность, чтобы её приняли на защите?
Не «точность 99%», а матрица ошибок: precision, recall, F1, ROC-AUC и, главное, бизнес-метрики — доля заблокированных фишинговых писем из тестовой выборки и False Positive Rate. Для 35 000 писем покажите, сколько из них поймал бы ваш прототип. Это самый убедительный слайд на защите.
Темы ВКР: три готовых вектора под этот кейс
-
Тема 1. Система выявления фишинговых URL, эксплуатирующих легитимные платформы опросов.
Актуальность: кейс из статьи показывает, что репутация домена перестала быть надёжным признаком.
Цель: разработать модуль, который по URL и цепочке редиректов определяет фишинг, замаскированный под страницу опроса.
Задачи: (1) анализ существующих методов детектирования; (2) формирование набора признаков; (3) реализация классификатора; (4) оценка метрик и False Positive Rate.
Структура: Гл.1 — обзор угроз и методов; Гл.2 — проектирование и код модуля; Гл.3 — тестирование на выборке писем.
-
Тема 2. Корпоративный шлюз фильтрации почты с эвристикой на поддельные страницы-опросы.
Актуальность: массовые рассылки (35 000 заблокированных писем за два месяца) требуют автоматизированной защиты на периметре.
Цель: спроектировать шлюз, интегрированный с почтовым сервером и SIEM.
Задачи: (1) разбор SPF/DKIM/DMARC; (2) парсинг вложений и ссылок; (3) правила корреляции событий; (4) отчётность.
Структура: Гл.1 — ландшафт угроз (MITRE ATT&CK: T1566.002); Гл.2 — архитектура шлюза; Гл.3 — нагрузочное тестирование и метрики.
-
Тема 3. Сравнительный анализ методов детектирования фишинга на легитимных доменах.
Актуальность: нужен ответ на вопрос, какой подход даёт наименьший прирост False Positive в сценарии с доменами-конструкторами.
Цель: эмпирически сравнить репутационный, морфологический и ML-подходы.
Задачи: (1) выделить тестовый корпус; (2) реализовать три baseline; (3) посчитать precision/recall; (4) сделать вывод о гибридной схеме.
Структура: Гл.1 — теория и OWASP-ориентиры; Гл.2 — методика эксперимента; Гл.3 — результаты и рекомендации.
Как встроить материал статьи в главы ВКР
Глава 1: анализ угроз без «воды»
Не пересказывайте новость. Постройте таблицу угроз и сопоставьте её с MITRE ATT&CK: тактика Initial Access, техника Phishing (T1566), подтехника Spearphishing Link. Дальше — диаграмма в нотации C4 Context: абонент → почтовый сервер → шлюз фильтрации → внешний домен-конструктор. Домены-конструкторы выносите как «полу-доверенные», это и есть корень проблемы.
| Признак | Классический фишинг | Фишинг через сервис опросов |
|---|---|---|
| Домен | Похожий, свежий | Легитимный, известный |
| Сертификат | Самоподписанный / нет | Валидный |
| Репутация | Плохая | Чистая |
| Детекция фильтром | Блокируется | Пропускается |
Глава 2: проектирование детектора
Разбейте конвейер на этапы: проверка подлинности письма (SPF/DKIM/DMARC), извлечение признаков URL, разворачивание коротких ссылок без захода на ресурс (через HEAD-запрос), анализ DOM подозрительной страницы в песочнице. Ниже — псевдокод извлечения признаков, его можно положить в приложение и оформить по ГОСТ 19.402 как описание программы.
def extract_url_features(url: str) -> dict:
parsed = urlparse(url)
return {
"domain_len": len(parsed.netloc),
"path_depth": parsed.path.count("/"),
"has_ip": bool(re.match(r"^\d+\.\d+\.\d+\.\d+$", parsed.netloc)),
"suspicious_tld": parsed.netloc.endswith((".zip", ".top", ".xyz")),
"redirect_count": resolve_redirects(url), # без тела, только HEAD
"brand_in_subdomain": contains_brand(parsed.netloc),
"path_entropy": shannon_entropy(parsed.path),
}
def decide(features: dict, model) -> str:
score = model.predict_proba(features)[0][1]
return "BLOCK" if score >= 0.82 else "REVIEW"
Отдельно опишите проверку почтовой аутентификации — это иллюстрация того, почему часть писем всё же доходит.
# пример проверки на шлюзе (упрощённо)
spf=$(dig +short TXT example-survey.ru | grep "v=spf1")
dkim=$(dig +short TXT selector._domainkey.example-survey.ru)
dmarc=$(dig +short TXT _dmarc.example-survey.ru)
# если SPF/DKIM/DMARC валидны, но ссылка ведёт на форму с внешним редиректом —
# фиксируем в SIEM: auth=pass, link_risk=high
Глава 3: тестирование и метрики
Соберите тестовый корпус: 200–300 легитимных писем, 200–300 фишинговых (реальные и синтетика). Посчитайте:
| Метрика | Формула / смысл | Целевое значение |
|---|---|---|
| Precision | TP / (TP + FP) | ≥ 0.90 |
| Recall | TP / (TP + FN) | ≥ 0.85 |
| F1 | 2·P·R / (P + R) | ≥ 0.87 |
| FPR | FP / (FP + TN) | ≤ 0.05 |
| MTTD | среднее время до детекции | ≤ 30 с |
Свяжите метрики с ISO/IEC 25010: например, security и reliability. Это снимает вопрос комиссии «почему именно такие числа».
Практические выводы: чему вы научитесь
- Проектировать конвейер детекции фишинга и обосновывать выбор признаков.
- Проверять почтовую аутентификацию (SPF/DKIM/DMARC) на реальных доменах.
- Оценивать качество модели через матрицу ошибок и ROC-AUC, а не «на глаз».
- Описывать архитектуру по C4 и оформлять ТЗ и схемы по ГОСТ 34.
- Связывать угрозы с MITRE ATT&CK и OWASP — то, что требуют рецензенты.
- Каждая задача из введения закрыта выводом в соответствующей главе.
- Схемы выполнены по ГОСТ 34 / оформлены в C4 и пронумерованы.
- Метрики содержат и технические, и эксплуатационные показатели (FPR, MTTD).
- Список литературы: ≥ 15 источников, среди них OWASP, ISO/IEC 27001, MITRE ATT&CK.
- Код вынесен в приложение по ГОСТ 19.402 с описанием входов/выходов.
- Проверка на антиплагиат — ≥ 75% оригинальности по вашему вузу.
- Оформлены ссылки на источник статьи и даты обращения к фидам PhishTank/OpenPhish.
- Опора только на чёрные списки. В кейсе из статьи домен легитимен — чёрный список бесполезен. Добавьте поведенческие признаки: редирект-цепочка, аномальный путь, наличие формы ввода данных банковской карты.
- Метрики без тестового корпуса. «Точность 99%» без описания выборки — повод для вопроса на защите. Фиксируйте размер, разбиение train/test и критерий разметки.
- Одна глава = один параграф теории, остальное — код. Комиссия оценивает баланс: анализ, проектирование, апробация. Код — в приложение, а не в основной текст.
Источник: Российские сервисы для онлайн-опросов используются для криптовалютного скама (опубликовано 2026-03-24)