C2-каналы через Spotify и Chess.com в дипломе: архитектура обнаружения и метрики SOC
25 марта 2026 года ГК «Солар» описала кампанию, в которой операторы вредоносного ПО перестали держать собственные серверы управления. Команды на заражённые машины уходят через обычный трафик к Spotify и шахматной платформе Chess.com: вредонос читает «плейлист» или профиль игрока, извлекает оттуда закодированное задание, а украденные учётные данные и данные криптокошельков складывает в тот же легитимный сервис. Для защитных систем такой канал выглядит как рядовое обращение к популярному домену — и это ломает привычную логику блокировок по чёрным спискам.
Для выпускника ИТ-направления это не просто новость. Это готовый повод пересобрать тему ВКР: вместо очередного «сравнения антивирусов» — спроектировать модуль обнаружения аномального поведения, обосновать архитектуру сбора телеметрии и посчитать метрики. Такую работу защищать проще: у неё есть живой кейс, измеримая цель и понятный заказчик — условный SOC учебной лаборатории или небольшая компания.
Три темы ВКР, которые вырастают из этой статьи
Тема 1. Обнаружение C2-каналов в легитимном трафике (SOC-модуль)
Актуальность. Атакующие уходят от классических доменов-«однодневок» к сервисам с высокой репутацией. Значит, детект должен строиться не на списках, а на поведенческих признаках: периодичность обращений, объём отклика, несоответствие клиента заявленному протоколу.
Цель: разработать модуль выявления аномальных обращений к легитимным облачным сервисам с оценкой точности детектирования.
Задачи: проанализировать MITRE ATT&CK (техники T1071, T1102); сформировать набор признаков сессии; реализовать конвейер обработки журналов; оценить precision/recall на синтетическом датасете.
Структура: Глава 1 — анализ техник сокрытия C2 и существующих SIEM-правил. Глава 2 — архитектура модуля, схема потоков данных, выбор хранилища. Глава 3 — эксперименты, метрики, расчёт стоимости внедрения.
Тема 2. Защищённый обмен заданиями: протокол и его имитационная модель
Актуальность. Если канал можно спрятать в чужом сервисе, то же свойство нужно уметь моделировать на стороне защиты — иначе нечего тестировать.
Цель: спроектировать и промоделировать протокол скрытой передачи управляющих сообщений, затем построить контрмеры.
Задачи: формализовать модель угроз; реализовать имитатор канала; предложить набор детектирующих признаков; провести нагрузочное тестирование имитатора.
Структура: Глава 1 — теоретические основы стеганографии и туннелирования. Глава 2 — проектирование имитационной модели. Глава 3 — тестирование, оценка вычислительной стоимости, выводы по применимости контрмер.
Тема 3. Аудит защищённости корпоративного периметра при обходе через доверенные сервисы
Актуальность. Кейс показывает разрыв между формальным соответствием политике и реальной видимостью трафика. Аудит, который это фиксирует количественно, — востребованный практический результат.
Цель: разработать методику аудита с оценкой полноты телеметрии по слоям инфраструктуры.
Задачи: построить матрицу «источник логов — покрываемая техника ATT&CK»; провести замеры на стенде; рассчитать остаточный риск; предложить план закрытия пробелов.
Структура: Глава 1 — обзор стандартов и практик аудита. Глава 2 — методика и стенд. Глава 3 — результаты замеров, экономика внедрения предложений.
Аналитическая глава: чем обосновывать выбор
Первая глава обычно превращается в пересказ. Сделайте иначе — постройте сравнение по критериям, которые потом вернутся в тестирование.
| Критерий | Правила на сигнатурах | Поведенческий анализ | Модель на графах сессий |
|---|---|---|---|
| Устойчивость к смене домена | Низкая | Средняя | Высокая |
| Ложные срабатывания | Мало | Много на старте | Средне, требует разметки |
| Требования к железу | Минимальные | Средние | Высокие (память, графовая БД) |
| Скорость внедрения в ВКР | 1–2 недели | 3–4 недели | 6+ недель |
Здесь же уместно сослаться на ISO/IEC 25010 как на источник формулировок нефункциональных требований: производительность, безопасность, сопровождаемость. Это снимает половину вопросов комиссии о «научности» раздела.
Проектная часть: что рисовать и как
Минимум, который ждут на защите:
- Контекстная диаграмма (уровень A-0 по ГОСТ 34.602-89 или в нотации C4) — кто источник телеметрии, кто потребитель алертов.
- Диаграмма последовательности — путь одного события от сетевого сенсора до вердикта.
- Схема развёртывания — если используете контейнеры, покажите Kubernetes-кластер, очередь сообщений и хранилище.
Пример описания выбора стека — компактно, без «воды»:
Сбор телеметрии: OpenTelemetry Collector (единый формат, экспорт в SIEM)
Обработка потока: Kafka + stream-обработчик (окно 30 с, признаки сессии)
Хранилище: PostgreSQL (правила) + ClickHouse (журналы)
Наблюдаемость: Prometheus + Grafana (метрики конвейера)Правило простое: каждое решение в проектной главе должно возвращаться в третьей главе как измеряемая величина. Выбрали Kafka — покажите пропускную способность при пике. Выбрали графовую БД — покажите время построения сессии.
Тестирование, мониторинг и метрики
Слабое место большинства ВКР — «система работает, скриншот прилагается». Замените это на измеримый протокол.
| Что измеряем | Инструмент | Пороговое значение в работе |
|---|---|---|
| Пропускная способность конвейера | Нагрузочный генератор + Prometheus | ≥ 5 000 событий/с |
| Задержка от события до алерта | Трассировка (OpenTelemetry) | ≤ 30 с |
| Precision / Recall детектора | Размеченный датасет | ≥ 0,85 / ≥ 0,80 |
| RTO / RPO при отказе узла | Сценарий аварийного восстановления | RTO ≤ 15 мин, RPO ≤ 5 мин |
| Потребление памяти | Метрики контейнера | ≤ 2 ГБ на инстанс |
Про RTO и RPO пишут единицы, а спросить могут на любом профиле. Даже если система учебная — задайте сценарий отказа и покажите замер. Это сразу выделяет работу.
Чему вы научитесь на такой теме
- Обосновывать архитектуру через требования, а не через личные предпочтения: получите навык, который напрямую переносится в собеседование.
- Собирать конвейеры телеметрии и работать с форматами журналов, очередями, трассировкой.
- Строить измеримые эксперименты и корректно интерпретировать precision/recall — без подгонки цифр под красивый вывод.
- Оформлять документацию по ГОСТ 34.602-89 и ГОСТ 19.701-90, включая схемы и спецификации.
Типичные ошибки студентов
- Подмена уровней модели угроз. Технику T1071 (использование стандартных протоколов) смешивают с T1102 (использование веб-сервисов). Комиссия ловит это сразу. Решение: выпишите идентификаторы техник и их определения дословно, ссылаясь на матрицу ATT&CK, и держите терминологию единой по всему тексту.
- Нет метрик эффективности. «Система выявила атаку» — не результат. Нужны числа: на каком датасете, сколько ложных срабатываний, какое время реакции. Решение: зафиксируйте методику измерения до начала экспериментов и не меняйте её задним числом.
- Игнорирование требований к оформлению. Отсутствие ТЗ, произвольные подписи рисунков, схемы «в Paint». Решение: сверьтесь с ГОСТ 34.602-89 и ГОСТ 19.701-90, сделайте сквозную нумерацию и убедитесь, что каждая задача из введения имеет отражение в выводах.
Частые вопросы
Насколько сложно реализовать такой модуль за семестр?
Реалистично: одна рабочая ветка детектора на 3–5 признаках плюс синтетический датасет — это 6–8 недель спокойной работы. Не беритесь сразу за машинное обучение: логистическая регрессия или решающее дерево на подготовленных признаках дают защищаемый результат быстрее и объясняются комиссии лучше.
Обязательно ли писать код для ВКР по безопасности?
На инженерных программах — почти всегда да, хотя бы в объёме стенда и скриптов обработки журналов. Если тема ближе к аналитической (методика аудита), код заменяется воспроизводимым экспериментом: конфигурации, сценарии, замеры. Главное — чтобы результат можно было повторить.
Как оформлять UML-диаграммы и схемы архитектуры?
Выберите одну нотацию и держите её до конца. Для архитектуры удобна C4 (контекст, контейнеры, компоненты), для алгоритмов — диаграммы деятельности, для потоков данных — DFD. Подпись под рисунком должна объяснять, что читатель должен увидеть, а не повторять название. Все элементы на схеме обязаны встречаться в тексте.
Где брать тестовые данные, если нет доступа к реальному трафику?
Варианты по убыванию трудозатрат: публичные датасеты сетевого трафика; синтетическая генерация на стенде с имитатором клиента; логи собственной лаборатории. Для кейса с легитимными сервисами удобно снять реальный профиль обращений к популярному домену в изолированной сети и разметить его вручную. Обязательно опишите процесс разметки — это отдельный пункт защиты.
Чек-лист перед сдачей
- Введение содержит ссылку на источник и дату события, а не абстрактное «в наше время».
- Каждая задача из введения закрыта выводом в соответствующей главе.
- Стек обоснован через критерии, а не через «мне так удобно».
- Есть минимум три схемы: контекст, последовательность, развёртывание.
- Метрики приведены с методикой измерения и условиями эксперимента.
- Приложения содержат конфигурации и фрагменты кода, на которые есть ссылки из текста.
- Оформление сверено с ГОСТ 34.602-89 и ГОСТ 19.701-90.
Если тема уже выбрана, но непонятно, как свести аналитику, архитектуру и эксперимент в защищаемую работу, — начните с бесплатной консультации: разберём ваш черновик, подскажем, каких метрик не хватает и где усилить обоснование. Помогаем студентам с ВКР и оформлением: от плана до финальной вычитки. Средний срок подготовки полноценной работы — около 120 часов, но с готовым каркасом справитесь быстрее.
Источник: ГК «Солар»: хакеры начали использовать Spotify и Chess.com для управления вредоносом, крадущим учетные данные и онлайн-кошельки (опубликовано 2026-03-25)