Горшочек с мёдом против пчел! Honeypot аналитика

Пару недель назад на необъятных просторах новостной ленты всплыл вот этот ролик (https://www.youtube.com/watch?v=T2mHPGbRPgA), в котором рассматривается оценка событий на honeypot T-Pot. Мое внимание захватили: красивая инфографика, аналитические отчеты и глубина анализа данных, которые заботливо были продемонстрированы автором. В его исследовании отражена оценка киберпротивостояния во время недавнего конфликта в известном проливе и я испытал жгучее желание провести собственный анализ рынка масскана, но с важной оговоркой — страна-хостер обязательно должна быть Россия.

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

1. Rust security-наблюдатель, собирающий события и отображающий их в дашборде в виде нескучных графиков.

2. Отказ от этой идеи в пользу комбинированного набора ловушек-сенсоров, которые не сложат малюсенькую VPS при единовременном запуске.

3. Поэтапная загрузка сенсоров на VPS с проверкой оставшихся мощностей спустя сутки работы.

4. Развитие красочного дашборда. Тут можно бесконечно размазывать теплое по мягкому, но суть простая — создан собственный дашборд и параллельно с ним поднята кибана с эластиком. Очевидно, что второй вариант и нагляднее, и проще в разворачивании, и удобнее в вопросах редактирования.

   

О чем пойдет речь?

Почему не T-pot? Как говорилось ранее — готовый и открытый продукт хорош во всем, но у него есть изъян — он не рассчитан на жадных до грошей людей. Его системные требования превосходят параметры самого дешевого сервака у RuVDS, а значит мне он не подходит.

Итак, первый этап покупка VPS:

Второй этап — раскатка сенсоров:

Отсюда и далее нужно держать в голове, что все действия проводились Codex Gpt-5.5 под моим чутким руководством.

Первым на борт поднялся Cowrie. Этот мужчинский сенсюнярик сразу же получил себе 22 порт, а свой админский я перенес в отдельный приватный management-сегмент, ибо глупее идеи чем оставить единственную линию связи и настройки в контуре сенсора для вредоносной активности придумать сложно.  Это сразу дало поток логинов, fingerprint-ов и попыток выполнить цепочку закрепления, но очевидно дальше сенсора эти попытки не выходили, в связи с чем время пребывания на 22-ом сводилось у ботов к минимуму.

Затем на борту оказалась Dionaea. Вклад этого гиганта неоценим: профиль ханипота расширился на SMB, MSSQL, SIP и, главное, появилась возможность регистрировать образцы ВПО, которые мне загружались сканерами. Тут чуть-чуть пришлось напрячься и объяснить Codex-у детальный рабочий процесс по транспортировке зараженных образцов в локальный карантин на хосте (да, как в поговорке, курить так до фильтра, заражаться так до BSOD-а).

Затем я добавил Redis, Conpot для ICS-поверхности (была теория, что промышленная поверхность атакуется чаще), веб-приманку с синтетической легендой и Suricata как NSM-слой.

Параллельно развивался аналитический слой, заведомо вынесенный на хост. Простого HTML-дашборда сначала хватало, но он быстро стал слишком длинным и нечитаемым. Поэтому появился локальный Elasticsearch/Kibana и графики по практикам сканирования. HTML-dashboard остался как быстрый читабельный отчет, Kibana — как исследовательская система.

Архитектура и что получилось собрать

• VPS: Cowrie, Dionaea, Redis honeypot, Conpot, Suricata, веб-приманка.

  

• Хост: pull-пайплайн, нормализация, GeoIP/ASN, VT проверка по хэшам и карантин для локального анализа (мы ничего не запускаем и тем более не отправляем вовне) в Ghidra по MCP, HTML-дашборд, Elasticsearch/Kibana.

Такой подход решает две задачи. Во-первых, VPS не превращается в прожорливый T-Pot-подобный комбайн. Во-вторых, когда аналитика тормозит, падает Kibana на хосте и копятся логи — это не влияет на сенсоры, VPS продолжает собирать события.

На момент финального обновления локальная витрина показывает:

В локальном Elasticsearch сейчас:

Сразу видно, что самая большая часть потока — Suricata. Очевидно, что не все 4 млн событий одинаково важны для нас, так как значительная часть NSM-данных — это просто поток соединений, «транспортных аномалий» и контекстных событий. Поэтому в аналитике я отдельно разделил «транспортный шум» и «значимые alert-события», а на финальном проходе добавил более детальную классификацию: event_family, payload_pattern, network_context и attack_detail.

Что чаще всего искали

Текущая агрегированная картина выглядит так:

Топ портов:

• 1433/MSSQL — 997 442 событий;

• 22/SSH — 486 537;

• 5060/SIP — 116 343;

• 445/SMB — 43 987;

• 3306/MySQL — 15 081;

• 6379/Redis — 1 045.

На свежем дневном срезе Suricata дополнительно показала активность по 5061/SIP over TLS, 1900/SSDP и ряду случайных портов.

После детализации Suricata стало лучше видно, что внутри «одинаковых» событий сидят разные нагрузки. Например, transport.closewait_fin_window дал 758 070 срабатываний, но они раскладываются по разным attack_detail: MSSQL/1433 с разными bucket’ами retransmission/packet shape, UDP/1900 SSDP-like поток, DCERPC/135, SIP/TLS/5061. Это полезнее, чем один плоский счетчик сигнатур, потому что можно отличать потоковый транспортный шум от конкретных протокольных волн.

Отдельно интересен Cowrie. В сумме по SSH получилось 90 562 успешных honeypot-логина и 85 666 командных вводов. Среди типовых действий — проверка системы, попытки работы с .ssh, команды разведки CPU/RAM и попытки подготовить окружение для латерального перемещения. Как по мне, это хороший срез массовой автоматизации, так как можно сказать, что боты не просто проверяют пароль, они заходят и выполняют сценарий.

Две зарегистрированные бот-кампании

Первая кампания — SSH бот-пробив в Cowrie. Она хорошо видна по поведению: один доминирующий источник дал 461 452 Cowrie-события, а самая частая команда echo -e «\\x6F\\x6B» (буквально echo ok) встретилась 57 679 раз. Это похоже на автоматическую проверку «живой ли shell после логина». Дальше идут uname -s -v -n -r -m — 23 010 раз, попытки переписать ~/.ssh/authorized_keys — 942 раза, и разведка окружения через CPU/RAM/uptime/last. Самые частые пары логин/пароль не поразили воображение: support/support, admin/admin, root/admin, root/root, плюс странные одноразовые строки вроде 345gs5662d34.

Вторая кампания — SMB/MSSQL/WannaCry-like кластер. Здесь картина видна сразу в трех слоях. На сетевом уровне доминируют 1433/MSSQL и SMB/DCERPC; Suricata показывает сотни тысяч transport/protocol аномалий вокруг 1433, а Dionaea фиксирует бинарные загрузки. ВПО корпус почти весь сходится к Win32 DLL и тегам cve-2017-0147 / cve-2017-0144, а VirusTotal (далее VT) чаще всего называет семейства trojan.wanna/wannacry, trojan.wannacry/wanna, trojan.wanna/cztf. Это, разумеется, не говорит об одном операторе WannaCry, но показывает живую автоматизированную экосистему, которая до сих пор ищет Windows/SMB-поверхность и стреляет старыми exploit/ransomware-like бинарями.

Пару слов о вредоносах

Самая вкуснятина лично для меня — это анализ образцов ВПО. Забегая вперед — следующую статью я хочу посвятить именно разбору вредоносов, которые смогу зарегистрировать на своем узле, чтобы сказать как и чем сейчас работают злоумышленники, если речь идет о бот-кампаниях. Собственно цель проекта не заявление, что «мы с Codex поставили несколько honeypot’ов», а на полученных данных провести свой Threat Intelligence, если так можно выразиться, и сделать заключение о том, как выглядит картина атак на российские сервисы. Собственно сам факт того, что легковесный VPS начал ловить реальные загружаемые образцы уже меня порадовал и вокруг этого появился безопасный и воспроизводимый алгоритм работы с ВПО:

1. Dionaea фиксирует загрузки бинарей.

2. Локальный pull забирает манифест и SHA256.

3. Образцы уходят только в зашифрованный локальный карантин.

4. Во внешние сервисы отправляются только SHA256.

5. VT-результаты нормализуются в отдельный индекс и попадают в дашборд/Kibana.

На текущий момент накоплено 172 уникальных SHA256. Из них 166 найдены в VT, 163 имеют malicious > 0. Максимальное число malicious-детектов по одному образцу — 69. Последний pull за 15 июня добавил 19 новых SHA256; после lookup-only проверки 18 из них уже нашлись в VT, один остался в статусе ошибки/unknown.

По категориям VT картина такая:

По типам файлов доминируют Win32 DLL — 150 объектов. Есть также ELF — 6, текстовые файлы — 5, shell scripts — 2, HTML/XML-артефакты и один unknown. По семействам заметно доминирование Wanna/WannaCry-like классификаций: trojan.wanna/wannacry — 80, trojan.wannacry/wanna — 35, trojan.wanna/cztf — 28, но как мы помним за это нужно быть благодарным автоматизированной кампании от 12.06, именнр на этот день пришелся ее пик . По тегам картина та же: exploit, overlay, pedll, cve-2017-0147 — 148, cve-2017-0144 — 27.

Что можно сказать об активности злоумышленников по этим образцам? Ханипот, как и ожидалось, не стал целью для конкретного исполнителя, но попал в массовую воронку для автоматизированных операторов: они ищут открытые Windows/SMB/MSSQL-сервисы, старые EternalBlue/WannaCry-compatible поверхности, слабые SSH-учетки, Redis без нормальной защиты и, в меньшей степени, ICS-протоколы. По корпусу ВПО отчетливо виден устаревший набор вредоносов и автоматизированная-самораспространяющаяся инфраструктура. Отсюда вывод: сенсор попал в поле деятельности ботнетов и автоматизированных загрузчиков, ориентированных на плохо защищенные серверы и старые уязвимые сервисы.

Attack Map и GeoIP

Для Attack Map я сначала пытался делать «карту мира» с пузырями по регионам. На практике это быстро стало нечитаемым: самые активные регионы накладывались друг на друга, подписи конфликтовали, что мешало анализу.

Поэтому карта превратилась в поточную схему: топ регионов раскладываются в фиксированные строки, а линии ведут к локальному сенсору. Это менее похоже на географическую карту, но лучше работает как аналитическая визуализация: видно ранг, объем и регион.

Сейчас в топе регионов видны Европа/Украина, Северная Америка/США, Европа/Россия, приватный/локальный сегмент, Азия/Турция, Европа/Андорра, Нидерланды, Германия и другие. Но этот блок нужно читать с оговоркой: GeoIP — это не атрибуция атакующего, а атрибуция сетевой точки выхода. Хостинг, VPN, прокси и зараженные машины легко искажают картину.

Из примечания — для привязки использовались dbip-asn+city-lite.mmdb, так как без этой базы, Codex с интернетом разводил руками и говорил, что ~78% узлов — Unknown, а известный сервис MaxMind не дал мне зарегистрироваться.

Ограничения

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

Во-первых, события не равны атакам. Один поток из Suricata и один успешный honeypot login имеют разный смысл. Поэтому я не говорю «нас атаковали N миллионов раз», а «было зарегистрировано N событий, из которых такие-то классы похожи на такие-то практики».

Во-вторых, GeoIP — приблизительный слой. Он полезен для визуализации и поиска перекосов, но не доказывает реальную страну оператора.

В-третьих, VT аналитика — это hash-репутация, а не полноценный реверс ВПО. Он отвечает на вопрос «что об этом SHA256 уже известно», но не заменяет статический и динамический анализ.

Ключевые результаты или TLDR выжимка

Почему не T-Pot: это зрелая готовая honeypot-платформа с большим набором сенсоров и уже собранной аналитикой. Мой проект не пытается быть «маленьким T-Pot». Его задача — проверить, насколько далеко можно уехать на ограниченном VPS, если вынести тяжелую аналитику на хост и добавлять сенсоры, контролируя RAM, swap, конфликты портов и качество данных.

Плюс такого подхода — управляемость. Я вижу, какой сенсор дает какую нагрузку, какие события являются шумом, какие данные стоит нести в статью, а какие лучше оставить в слое аналитики. Минус — больше ручной инженерии: нужно самому строить пайплайн, чинить визуализации, контролировать копирование, GeoIP-привязку, VT, Kibana.

По результатам работы можно отрапортовать:

• поднят мультисенсорный VPS-контур: SSH, загрузка ВПО, Redis, ICS, веб-приманка, NSM;

• собран локальный контур аналитики с HTML-дашбордом, Elasticsearch/Kibana;

• настроен безопасный алгоритм первичного анализа ВПО: шифрованный карантин + SHA256 VT справка;

• накоплено 172 уникальных SHA256, 163 из них имеют детекты в VT;

• подтвержден устойчивый интерес сканеров к MSSQL/1433, SSH/22, SIP, SMB/DCERPC и Redis;

• получены реальные командные сценарии в Cowrie, включая SSH bot-loop, разведку системы и попытки работы с SSH-окружением;

• Suricata дала широкий NSM-контекст; финальная нормализация раскладывает шум по event_family, payload_pattern, network_context и attack_detail;

• корпус ВПО указывает прежде всего на автоматизированную-самораспространяющуюся инфраструктуру вокруг SMB/MSSQL/WannaCry-like образцов, а не на доказуемую targeted-группу.

Главный вывод: даже дешевый VPS, если развернуть его как аккуратный набор сенсоров и вынести аналитику наружу, превращается в полезный наблюдательный узел. Самое ценное здесь не количество логов, а связка: широкая поверхность, безопасный сбор образцов, нормализация, обогащение и визуализация, которую можно использовать не только для «просмотра графиков», но и для написания воспроизводимого аналитического отчета.

P. S.

Большое спасибо, дочитавшим до конца! Я надеюсь, что вы не остались разочарованными и не жалеете о потраченном времени. Если у вас вдруг появилось желание развернуть ентого Франкенштейна самостоятельно, то я с удовольствием дам вам гитверс, наполненный нейрослопом, который за ручку проведет вас от А до Я при конфигурировании своего собственного ханипотика!