В 2026 году у защитников корпоративных инфраструктур уже недостаточно просто «ставить заборы» и надеяться, что классические средства контроля — IDS, EDR и SIEM — успеют заметить атаку исключительно по поведенческим аномалиям. Атакующие используют легитимные инструменты (LoLBas), украденные учетные данные и скрытые каналы связи. Современная проактивная защита всё чаще опирается на технологии обмана (deception): в инфраструктуре сознательно размещаются приманки — honeypots, honeytokens и «медовые» файлы. Эти активы абсолютно не нужны бизнесу, зато позволяют поймать атакующего на ранних стадиях с почти нулевым количеством ложных срабатываний (False Positives).
Данный whitepaper представляет собой подробное руководство по архитектуре и внедрению Deception-слоя. Мы разберем не только теорию, но и технические аспекты создания ловушек, их интеграцию с SIEM и сценарии реагирования.
От реактивной обороны к проактивной: Почему классический SOC «слепнет»
Классическая модель защиты десятилетиями строилась вокруг защиты периметра, сигнатурного анализа и сложных корреляций событий:
- Firewall режет нежелательный трафик на границе;
- WAF фильтрует веб‑атаки и попытки инъекций;
- EDR и SIEM по гигантским массивам логов и поведенческим правилам пытаются вычислить необычную активность.
Но на практике, в больших enterprise-инфраструктурах это почти всегда означает тысячи алертов в сутки. Часть из них — это банальный информационный шум, легитимные действия администраторов или ошибки конфигурации, а часть — незамеченные настоящие атаки, скрытые в лавине событий (Alert Fatigue).
Практика: Среднее время пребывания атакующего в сети до обнаружения (Dwell Time) в сложных целевых атаках всё ещё может составлять недели. Классические средства защиты требуют, чтобы злоумышленник совершил ошибку (например, запустил известный вредонос). Если он использует RDP с купленными в даркнете кредами, EDR будет молчать.
Deception предлагает кардинально иную логику: вместо того чтобы пытаться «искать иголку в стоге сена» среди миллионов легитимных событий, вы создаете в инфраструктуре объекты, к которым нет и не должно быть легитимного доступа. Любое взаимодействие с ними — как натянутая растяжка для диверсанта: одно срабатывание уже почти гарантирует факт атаки и сразу поднимает приоритет инцидента до максимума (P1/Critical).
Что такое Cyber Deception в ИБ-архитектуре
Под cyber deception понимается целый класс проактивных техник, где атакующему намеренно показывают ложную, но максимально правдоподобную картину инфраструктуры: фейковые сервера, службы, уязвимые учетные записи, базы данных и чувствительные документы.
Главная цель — «индуцировать ошибочное восприятие» (deliberately inducing erroneous sensemaking). Необходимо заставить злоумышленника тратить драгоценное время на поддельные цели, а защитников (Blue Team / SOC) — вовремя получить четкий, высокоточный сигнал о его присутствии и собрать тактические данные о его действиях.
Исторически всё началось с базовых honeypots — одиночных «компьютеров‑приманок». Но к 2024–2026 годам рынок ушел далеко вперёд: в enterprise-сегменте появились полноценные платформы Deception (DDP - Distributed Deception Platforms). Они автоматически расставляют ловушки по всей распределенной сети, глубоко интегрируют их с SIEM/SOAR системами и постоянно обновляют конфигурации, чтобы они выглядели натурально, меняя порты, баннеры и имитируя рабочую нагрузку.
Аналитика инцидентов и отчеты форензики показывают, что такие платформы заметно сокращают dwell time — время между первичным проникновением и обнаружением — и радикально повышают вероятность поймать злоумышленника ещё на стадии разведки (Reconnaissance) и латерального перемещения (Lateral Movement).
Honeypots: Системы‑ловушки, а не просто «лабораторные игрушки»
Определение и архитектурные типы
Honeypot — это намеренно созданный ложный ИТ-ресурс (виртуальный сервер, микросервис, приложение, контейнер), который выглядит как нормальная боевая система, но не содержит реальных клиентских данных и не используется легальными пользователями компании.
Ключевая идея: Нормальный сотрудник или легитимный сервис туда никогда не зайдёт. Значит, любое сетевое соединение с этим хостом — это автоматом подозрительная (сканирование) или откровенно враждебная (эксплуатация) активность.
Основные разновидности honeypots в современной архитектуре:
- Production‑honeypot — приманка, плотно встроенная в боевую инфраструктуру: например, «почти настоящий» RDP‑ или SSH‑сервер, стоящий в том же VLAN-сегменте, что и реальные хосты базы данных.
- Research‑honeypot — изолированная ловушка для детального изучения техник атак (часто в составе целой honeynet — сети приманок, выведенной в интернет). Применяется Threat Intelligence командами.
- Low‑interaction — лёгкие программные эмуляции сервисов (например, скрипт, отдающий баннер приветствия SSH, или фальшивая форма логина в веб‑приложении). Они не позволяют атакующему проникнуть внутрь ОС.
- High‑interaction — полноценные ОС/сервисы (часто с намеренно пониженной защитой), где атакующий может выполнять команды, загружать пейлоады, а вы — глубоко наблюдать за его TTPs (Tactics, Techniques, and Procedures) через гипервизор или eBPF-сенсоры.
Важно: Honeynets расширяют эту идею до целой мнимой сети с «поддельными» доменами контроллеров, сегментами БД и многоуровневыми приложениями, где за всем трафиком прозрачно следит honeywall (шлюз логирования и контроля соединений).
Зачем они нужны в 2026 году
Современные honeypots решают сразу несколько критических задач:
- Раннее обнаружение проникновения: Размещенный production‑honeypot в сегменте с открытым RDP/SSH позволяет поймать перебор логинов (Brute-force) или попытки латерального перемещения (Pass-the-Hash, SMB Relay) ещё до касания настоящих production-серверов.
- Изучение приёмов атакующих: Research‑honeynet даёт чистую телеметрию по используемым эксплойтам, скриптам, фреймворкам C2 (от кастомных сборок Mimikatz до свежих профилей Cobalt Strike и Sliver).
- Отвлечение и выматывание: Чем больше реалистичных ложных целей в сети, тем сложнее злоумышленнику быстро сориентироваться и добраться до настоящих критичных данных.
При этом современные deception‑платформы уже умеют автоматически создавать десятки реалистичных decoy‑хостов (приманок), динамически синхронизировать их с топологией сети и регулярно «освежать» конфигурации: менять имена, версии ПО, открытые порты и даже генерировать фоновый легитимный трафик. Это делается для того, чтобы они не выглядели как «консервы для студентов» и не определялись популярными скриптами анти-honeypot детектирования.
Техническая реализация: Развертывание базового SSH Honeypot (Low-Interaction)
Для понимания механики, рассмотрим пример развертывания популярной ловушки Cowrie через Docker. Это классический подход для создания точек перехвата брутфорса во внутренних DMZ.
# docker-compose.yml для развертывания Cowrie Honeypot
version: '3.7'
services:
cowrie:
image: cowrie/cowrie:latest
container_name: cowrie-honeypot
restart: always
ports:
- "22:2222" # Маппинг стандартного SSH порта на внутренний порт ловушки
- "23:2223" # Опционально: маппинг Telnet
volumes:
- cowrie-var:/cowrie/cowrie-git/var
- cowrie-etc:/cowrie/cowrie-git/etc
environment:
- COWRIE_FLAVOR=default
- COWRIE_TELNET_ENABLED=yes
networks:
- deception_net
volumes:
cowrie-var:
cowrie-etc:
networks:
deception_net:
driver: bridge
# Конфигурация логирования (cowrie.cfg) для отправки данных в SIEM через Syslog/JSON
enabled = true
logfile = var/log/cowrie/cowrie.json
enabled = true
syslog_server = 10.0.50.100
syslog_port = 514
syslog_facility = USER
syslog_format = CEF
Honeytokens: Учетные данные и данные‑приманки
Если honeypot — это поддельная система целиком, требующая вычислительных ресурсов, то honeytoken — это маленький кусочек данных, легковесный артефакт, созданный исключительно ради детекта: логин/пароль, API-токен, запись в базе данных, e‑mail адрес, документ и т.п.
У honeytoken’а нет абсолютно никакой легитимной бизнес‑функции: никто из сотрудников и никогда не должен его использовать по‑настоящему. Его единственный смысл — сработать как «растяжка», когда атакующий, занимающийся сбором данных (Credential Access), попытается его применить.
Примеры внедрения Honeytokens
- Учетные данные (Credentials): Фальшивые пользователи в AD/LDAP, захардкоженные логины и пароли в конфигурационных файлах, «случайно забытые» креды в скриптах развертывания Terraform или Ansible.
- Секреты и ключи: Липовые API‑ключи, AWS‑/Azure‑учетки, токены OAuth, поддельные записи в Key Vault (CyberArk, HashiCorp Vault).
- Записи в БД: Фальшивые карточки VIP-клиентов или сотрудников, фиктивные «финансовые» записи, которые всегда остаются неиспользуемыми легитимным приложением, но привлекают внимание при дампе таблиц.
- Документы и файлы: Word, Excel, PDF с правдоподобным названием и манящим содержимым, внутри которых аппаратно или программно зашит сетевой маркер‑маяк.
- E‑mail и URL: Поддельные почтовые адреса (добавленные в скрытые списки рассылок) и уникальные ссылки, существующие только как приманки. Само получение письма на этот ящик или HTTP‑запрос по URL — это уже подтвержденный сигнал о компрометации.
Риски: Самая частая ошибка при развертывании токенов — создание реальных, полностью рабочих ключей от облачной инфраструктуры (например, AWS Access Keys), которые имеют избыточные права. Honeytoken всегда должен иметь политику Deny All, но при этом его использование должно логироваться в CloudTrail!
Пример реализации AWS IAM Honeytoken
Вместо того чтобы оставлять реальный ключ, мы создаем IAM-пользователя, вешаем на него политику, которая ничего не разрешает, но настраиваем CloudTrail на алертинг по попыткам использования этого ключа.
{
"Version": "2012-10-17",
"Statement":
}
Как только Red Team находит этот ключ (например, в публичном репозитории GitHub или на скомпрометированной машине разработчика) и вызывает команду разведки:
# Команда атакующего (AWS CLI)
aws sts get-caller-identity --aws-access-key-id AKIAIOSFODNN7EXAMPLE --aws-secret-access-key wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY
Защитники моментально получают алерт в SIEM через AWS CloudTrail: событие AccessDenied для конкретного AccessKeyId, с точным указанием внешнего IP-адреса атакующего.
Современные вендоры ИБ подчёркивают: honeytokens дают лёгкий и бесконечно масштабируемый deception‑уровень, который можно рассыпать по всей инфраструктуре — от классического on‑prem Active Directory до облаков и SaaS-приложений.
Поскольку «нормального» использования у этих объектов нет, каждое срабатывание — это высокоточный индикатор инцидента с почти нулевым уровнем ложных срабатываний.
Honey‑файлы: Документы‑ловушки для инсайдеров и хакеров
Honey‑файлы (honeyfiles, honey documents) — это частный, но крайне эффективный случай honeytokens, когда приманкой выступает документ или архивный файл, который выглядит особенно «вкусно» и ценен для атакующего, занимающегося сбором информации (Collection).
Типовые приёмы внедрения
- Документы с маяками: Файл с названием вроде VPN_paroli_top_management.xlsx или Finance_2025_Payroll.xlsx, в котором технически спрятан маркер. Это может быть скрытая уникальная ссылка, картинка размером 1x1 пиксель, подгружаемая с внешнего ресурса, макрос‑маяк (VBA) или использование механизма OLE/Template injection.
- Сетевые архивы: ZIP/RAR архив на общей сетевой шаре (SMB), названием намекающий на свежие бэкапы БД или конфигурации сетевого оборудования. Внутри вложен документ, который при открытии тянет ресурс с контролируемого вами домена, раскрывая IP-адрес открывшего.
- Облачные ловушки: Документ в корпоративном облачном хранилище (AWS S3, Azure Blob, GCS), доступ к которому строго логируется на уровне провайдера. Любое чтение файла или попытка выполнить список объектов (ListBucket) по этому префиксу ключа сразу маршрутизируется в корпоративный SIEM как инцидент.
Практика показывает, что «медовые» файлы особенно полезны против:
- Инсайдеров (злонамеренных сотрудников), которые методично пытаются найти и вынести чувствительные данные, к которым не имеют права доступа по своей роли (RBAC).
- Атакующих после первичного взлома, которые шарят (сканируют) сетевые диски предприятия в поисках конфигов, паролей администраторов, экспортов БД.
Инструментарий: Инструменты вроде Canarytokens (от Thinkst Canary) позволяют за пару кликов сгенерировать документ, URL или ключ реестра Windows, который при первом же открытии/использовании отправит уведомление на e‑mail, в канал Slack, Microsoft Teams или напрямую в веб‑хук SOC-платформы.
Продолжение на сайте redsec.by >>>