После initial access'a в Active Directory атака почти никогда не заканчивается на одном удачном входе. Сам по себе foothold ещё мало что даёт, если из него нельзя сделать устойчивое присутствие, аккуратный выход в нужные сегменты и канал, который переживёт первую волну реагирования. Именно здесь и начинается та часть постэксплуатации, которая для защитника особенно неприятна: атакующий перестаёт шуметь “узнаваемым” инструментарием и старается спрятать управление внутри трафика, который в сети и так считается допустимым.
В этом и состоит главный сдвиг последних лет. Если раньше внимание Blue Team часто было приковано к самим фреймворкам и их типовым следам, то теперь реальная проблема всё чаще выглядит иначе. Не громкий C2, а тихий туннель. Не экзотический протокол, а DNS, HTTP/S, SSH или другой легитимный канал, который уже разрешён политиками, проходит через прокси, не режется сегментацией и потому выглядит почти нормально до тех пор, пока на него не посмотрят как следует.
Поэтому сегодня мы разберём тему со стороны защитника. Где скрытые каналы вообще появляются в цепочке атаки, почему после foothold в AD они становятся таким удобным инструментом, как злоупотребляют доверенным трафиком и по каким признакам это потом вытаскивать из телеметрии, сетевых отклонений и поведенческих связок. Именно здесь и проходит неприятная граница: пока защита смотрит на “подозрительные инструменты”, атакующий уже давно работает через то, что в инфраструктуре считалось штатным.
Pivoting и tunneling в AD глазами защитника
Где скрытые каналы появляются после foothold
После foothold в доменной среде атакующий обычно быстро переходит от простого присутствия к следующему шагу - разведке маршрутов, проверке ограничений и поиску канала, через который можно двигаться дальше. Поэтому скрытые каналы в AD появляются не как отдельный фокус, а как продолжение постэксплуатационной цепочки.Сначала атакующий понимает, где именно оказался. Рабочая станция, сервер приложений, jump host, терминальный узел, промежуточный сервер в удобном сегменте - это всё очень разные стартовые точки. Потом начинается разведка: какие маршруты вообще доступны, какие протоколы разрешены наружу, есть ли прямой выход в интернет, через что ходят администраторы, какие DNS-серверы используются, что видно в соседних сегментах и где проходят реальные границы между подсетями. Только после этого появляется смысл строить скрытый канал. Не раньше.
Для защитника здесь важен именно порядок. Если смотреть на tunneling как на изолированную сетевую аномалию, он и будет выглядеть как странный DNS, нетипичный HTTP/S или редкий SSH-трафик. Но если смотреть на него как на этап после foothold и разведки, картина становится другой. Тогда скрытый канал уже читается как часть маршрута: была начальная компрометация, затем появились признаки изучения среды, а после этого началось использование доверенного трафика как транспорта для дальнейшего движения.
Зачем атакующему tunneling: обход сегментации, устойчивый канал, скрытие управления
Причина тут довольно приземлённая. В нормальной AD-среде далеко не каждый узел может напрямую общаться с тем, с чем ему хотелось бы. Есть межсетевые экраны, прокси, ограничения на исходящие соединения, отдельные административные маршруты, jump hosts и просто сетевая топология, которая не даёт идти по прямой. Поэтому после initial access атакующему часто нужен не новый эксплойт, а нормальный транспорт - канал, который позволит дотянуться до нужного сегмента, не теряя управления и не привлекая слишком много внимания.Именно здесь и появляется tunneling - как способ обойти сегментацию, удержать управление и не светить более узнаваемый канал связи. Если наружу уже разрешены DNS, HTTP/S или отдельные административные маршруты, атакующий старается опереться именно на них.
Отдельно важно и то, что скрытый канал почти всегда решает несколько задач сразу. Он помогает обойти сегментацию, сохранить устойчивое управление и снизить заметность по сравнению с более узнаваемыми схемами C2. То есть для атакующего это не просто “альтернативный способ связи”, а попытка сделать следующий этап атаки дешевле, тише и устойчивее. А для защитника - сигнал, что смотреть надо уже не только на сам факт компрометации, но и на то, как внутри доверенного трафика начинает жить чужое управление.
MITRE ATT&CK: T1090, T1572, T1071.004
В ATT&CK эта зона хорошо раскладывается на несколько техник, которые удобно держать в голове как рамку для расследования. Первая - T1090 Proxy, то есть использование промежуточных узлов и прокси-механизмов для маршрутизации трафика через доверенную инфраструктуру. Вторая - T1572 Protocol Tunneling, когда данные или управление прячут внутри другого протокола, уже разрешённого в среде. Третья - T1071.004 Application Layer Protocol: DNS, где DNS используется как прикладной канал связи, а не только как обычное разрешение имён. Эти обозначения ATT&CK прямо связывает с проксированием, туннелированием и злоупотреблением DNS как протоколом прикладного уровня. (
Ссылка скрыта от гостей
)ATT&CK здесь полезен как способ не смешивать разные вещи в одну кучу. Не каждый скрытый канал - это обязательно DNS tunneling. Не каждый pivoting-сценарий - это обязательно полноценный protocol tunneling. Не каждое проксирование после foothold выглядит одинаково. Но все эти техники хорошо собираются в одну защитную картину: после начального закрепления атакующий начинает искать способ жить внутри тех маршрутов и протоколов, которые в инфраструктуре уже считаются нормальными. И именно на этом месте Blue Team чаще всего начинает проигрывать не из-за отсутствия логов, а из-за того, что смотрит на разрешённый трафик слишком доверчиво.
Какими протоколами злоупотребляют чаще всего
DNS как канал управления и вывода данных
DNS особенно удобен для злоупотребления не потому, что он магически невидим, а потому, что ему в корпоративной среде слишком часто доверяют по умолчанию. Разрешение имён нужно почти всем, запросов много, маршруты понятны, а сам трафик долго воспринимался как служебный фон, а не как место, где может жить управление. Именно поэтому после foothold DNS так часто оказывается кандидатом на роль скрытого канала: он уже разрешён, он привычен и его аномалии не всегда выглядят угрожающе на первый взгляд.Для защитника здесь важно смотреть не на сам факт DNS-обращений, а на то, как они начинают вести себя по форме. Слишком частые запросы к редким доменам, нетипичные типы записей, всплески TXT, длинные и странно выглядящие поддомены, высокий уровень случайности в именах, необычная периодичность - всё это уже не похоже на обычную жизнь приложений. Проблема в том, что по отдельности такие признаки могут выглядеть терпимо. Но как только они складываются в устойчивый рисунок, DNS перестаёт быть “просто DNS” и начинает выглядеть как транспорт.
Именно поэтому DNS для Blue Team неудобен. Он слишком легко сливается с нормальной сетевой жизнью, а расследование часто начинается поздно - уже после того, как защитник понимает, что странные запросы не были просто шумом разрешения имён. В AD-среде это особенно неприятно, потому что DNS и так играет важную роль в работе домена, а значит слишком грубая реакция на него всегда рискованна. Отсюда и главный вывод: DNS как скрытый канал почти никогда не ловится одной сигнатурой. Он ловится как отклонение от нормальной модели разрешения имён внутри конкретной среды.
HTTP/S как маскировка под обычный веб-трафик
Если DNS удобен своей служебной “серостью”, то HTTP/S удобен масштабом нормальности. В большинстве сред наружу и так ходит веб-трафик: браузеры, агенты обновлений, клиентские приложения, внутренние сервисы, API-вызовы, прокси. Поэтому попытка спрятать управление внутри HTTP/S для атакующего выглядит естественно. Не нужно пробивать что-то экзотическое. Достаточно встроиться в уже разрешённый класс соединений.Для защитника это особенно неприятно потому, что HTTP/S сам по себе слишком широк. Здесь нельзя опираться только на порт или сам факт TLS-сессии. Смотришь уже не на “может ли этот протокол быть использован”, а на профиль поведения: слишком длинные соединения, странная периодичность, нетипичные размеры запросов и ответов, повторяющиеся обращения к редким путям, необычные заголовки, непохожий User-Agent, отличающийся профиль клиента, редкие внешние назначения. Чем больше таких признаков собирается вместе, тем сильнее HTTP/S перестаёт быть просто легитимным фоном.
Для Blue Team HTTP/S tunneling обычно интересен не как одиночная сессия, а как часть маршрута после foothold: странный, но разрешённый веб-трафик из неожиданного процесса или с нетипичного узла.
SSH и SOCKS внутри корпоративной сети
SSH в доменной среде выглядит иначе, чем DNS или HTTP/S. Это уже не массовый фон, а более узкий тип трафика, который особенно интересен там, где есть Linux-узлы, jump host’ы, DevOps-инфраструктура, средства администрирования или промежуточные сегменты, где SSH давно считается допустимым инструментом. Именно поэтому злоупотребление SSH и SOCKS-прокси внутри корпоративной сети для защитника опасно не своей массовостью, а близостью к легитимной административной модели.Здесь важен сам контекст. На рабочей станции обычного пользователя появление SSH-клиента и устойчивого исходящего соединения уже выглядит заметно. На jump host’е или инженерном сервере - намного слабее. Поэтому этот класс каналов почти невозможно оценивать в отрыве от роли узла. Для одного сегмента это почти аномалия по определению, для другого - повседневная административная жизнь. И именно на этом различии атакующие и играют: прячут активность там, где она меньше конфликтует с ожиданиями защиты.
Для Blue Team здесь важнее всего несоответствие роли узла, процесса, учётной записи и маршрута. Кто инициирует соединение, с какого хоста, куда именно и насколько это вообще похоже на норму для SSH в этой среде?
ICMP как редкий, но показательный канал
ICMP обычно не первый выбор для скрытого канала. Именно поэтому он и интересен. Когда атакующий уходит в ICMP, это часто означает, что более удобные и “нормальные” варианты либо ограничены, либо слишком заметны, либо не дают нужного маршрута. В этом смысле ICMP скорее не массовый, а показательный класс канала: он хорошо демонстрирует, что после foothold злоупотребить могут даже тем трафиком, который традиционно считают просто служебной сетевой мелочью.Для защитника эта история неприятна потому, что ICMP долго воспринимался как нечто второстепенное. Echo request, echo reply, сетевые проверки, диагностика доступности - всё это кажется слишком простым, чтобы сразу ассоциироваться с транспортом для управления. Но как только ICMP начинает нести нетипичную полезную нагрузку, идти с подозрительной регулярностью, менять размер пакетов или связываться с процессами, которые вообще не должны были заниматься сетевой диагностикой, он уже перестаёт выглядеть невинно.
Поэтому ICMP полезно держать в голове как крайний, но показательный сценарий. Если всё остальное режется, а ICMP остаётся слишком доверенным, его тоже могут превратить в транспорт.
| Протокол | Где маскируется лучше всего | Что искать |
|---|---|---|
| DNS | Служебная резолюция | Энтропия, TXT, частота |
| HTTP/S | Разрешённый веб-трафик | Профиль соединения, процесс |
| SSH / SOCKS | Административные маршруты | Роль узла, клиент, маршрут |
| ICMP | Диагностический трафик | Размер, ритм, процесс |
Главная ошибка в этой теме - искать “самый популярный” скрытый канал вообще. В реальной среде такого почти не бывает. Атакующий выбирает не абстрактно лучший транспорт, а тот, который в конкретной AD-инфраструктуре выглядит наиболее допустимым. Именно поэтому для Blue Team важнее не запоминать список утилит, а понимать, в каком из доверенных протоколов среда сегодня слепа сильнее всего.
Как это выглядит в телеметрии
Скрытый канал почти никогда не выглядит как один “идеальный индикатор”, который сам всё объясняет. Именно поэтому эта зона так неудобна для расследования. Отдельно взятый DNS-запрос может выглядеть просто странно. Отдельное HTTP/S-соединение - просто не очень типично. Отдельный SSH-клиент - как редкая админская активность. Проблема начинается в тот момент, когда эти куски складываются в устойчивую цепочку: процесс на скомпрометированном узле инициирует канал, канал укладывается в допустимый протокол, а сама активность появляется в том месте маршрута, где до этого уже были признаки foothold, разведки или lateral movement.Именно поэтому скрытые каналы плохо ловятся в одном источнике и намного лучше - на пересечении нескольких. Нужен не только сетевой профиль, но и понимание, какой процесс его породил, какая учётная запись с ним связана, что происходило на узле до этого и насколько такая активность вообще типична для этого сегмента. В AD это особенно важно: одна и та же аномалия на рабочей станции, jump host’е и сервере приложений будет читаться совершенно по-разному. Без контекста роли узла защитник очень быстро получает либо шум, либо ложное чувство, что “ничего необычного не происходит”.
DNS anomalies: высокая энтропия, нетипичный объём, TXT abuse, редкие домены
Когда скрытый канал живёт в DNS, он почти всегда выдаёт себя не самим фактом запросов, а тем, как они начинают отличаться от нормальной картины разрешения имён. В доменной среде это особенно важно, потому что DNS и так очень шумный. Запросов много, они идут постоянно, а часть из них выглядит странно даже в нормальной эксплуатации. Поэтому защитнику приходится смотреть не на единичную экзотику, а на устойчивые отклонения.Самые полезные признаки здесь довольно приземлённые. Слишком длинные и визуально случайные поддомены, высокий уровень энтропии в именах, нетипичные всплески TXT-записей, резкий рост частоты запросов к редким зонам, обращения к доменам, которых раньше в среде почти не было, странная регулярность, которая больше похожа на передачу фрагментов данных, чем на обычное разрешение имён. Всё это по отдельности ещё не доказывает tunneling. Но когда такие признаки начинают повторяться на одном узле, в одном временном окне и в одном маршруте после foothold, они уже выглядят совсем иначе.
Отдельная сложность в том, что часть такой активности может идти не напрямую наружу, а через корпоративные DNS-серверы и рекурсивные маршруты. Это добавляет ложного чувства нормальности. Поэтому для Blue Team здесь особенно важны не только пограничные сенсоры, но и внутренняя DNS-телеметрия: кто запрашивал, как часто, к каким именам, с какими типами записей и насколько это похоже на обычную жизнь конкретного хоста.
HTTP/S anomalies: длинные соединения, странный профиль запросов, нетипичные заголовки и маршруты
С HTTP/S история сложнее, потому что здесь сам протокол слишком нормален. Веб-трафик в среде и так везде, а на части узлов он вообще ожидается постоянно. Поэтому поиск скрытого канала через HTTP/S почти всегда начинается не с вопроса “почему этот хост ходит по HTTPS”, а с вопроса “почему он делает это именно так”.Полезнее всего смотреть на форму соединения. Длинные и устойчивые сеансы там, где их раньше не было, странная периодичность, повторяющиеся обращения к редким путям, слишком однообразный размер полезной нагрузки, необычные заголовки, редкий User-Agent, нетипичное внешнее назначение, соединения из процессов, которые вообще не должны были общаться наружу через веб-канал, - всё это уже хороший материал для охоты. Чем больше таких признаков собирается вместе, тем меньше шансов, что перед тобой просто очередной безобидный HTTPS-фон.
Особенно ценной становится связка с прокси и журналами выхода наружу. Если хост, который обычно живёт в одном профиле трафика, внезапно начинает строить другие веб-маршруты, использовать редкие назначения или держать соединения в нетипичном ритме, это уже намного интереснее, чем сам по себе факт HTTPS. Для AD-среды это важно ещё и потому, что часть таких соединений может рождаться уже после движения по домену и выглядеть как следующий слой после компрометации, а не как стартовая активность.
Endpoint telemetry: процесс -> сетевое соединение, редкое использование ssh.exe, plink.exe и подобных клиентов
На уровне хоста скрытый канал становится заметно интереснее, когда его удаётся привязать к конкретному процессу. Это часто самый полезный разворот всей темы. Сетевой трафик сам по себе может быть спорным. Но когда видно, что внешний канал породил процесс, который обычно не должен этим заниматься, картина резко меняется.Для Windows-хостов особенно ценны связки вида процесс -> сетевое соединение -> учётная запись -> внешний адрес. Если пользовательская рабочая станция внезапно начинает держать SSH-сеанс, если на сервере приложений появляется plink.exe, если системный или редкий пользовательский процесс инициирует внешние HTTPS-соединения в нетипичном ритме, если поведение укладывается не в роль узла, а в идею скрытого транспорта, - это уже материал не для общего мониторинга, а для нормального расследования. И здесь как раз важна редкость: ssh.exe, plink.exe, нестандартные сетевые клиенты, неожиданные библиотеки и инструменты зачастую интересны не потому, что они злонамеренны сами по себе, а потому, что их присутствие плохо объясняется жизнью конкретного сегмента.
Но и здесь нужна осторожность. На jump host’ах, инженерных серверах, платформах сопровождения и узлах автоматизации часть такой активности может быть нормой. Поэтому защитнику снова приходится возвращаться к главной идее всей статьи: не ловить “подозрительный инструмент” как таковой, а смотреть, насколько конкретная цепочка соответствует роли узла, пользователя и маршрута.
Pivoting в контексте AD: связь foothold, lateral movement и последующего tunneling
Самый сильный слой телеметрии появляется тогда, когда сетевое отклонение удаётся встроить в уже известную постэксплуатационную историю. Сам по себе туннель может выглядеть спорно. Но если до него на том же узле уже были признаки foothold, потом появились разведка, необычная работа с доменной информацией, движение к соседним системам, а следом начался доверенный, но странный трафик, то это уже не просто аномалия - это маршрут.Именно здесь AD-контекст особенно ценен. У защитника появляется возможность смотреть не только на сам транспорт, но и на его место в цепочке: какой хост был первой точкой входа, какие учётные записи на нём использовались, куда шла разведка, после каких действий возник новый канал, совпадает ли он по времени с попытками lateral movement, появился ли он на узле, где раньше уже засветилась административная активность или новые межсегментные связи. Чем больше таких связок, тем меньше скрытый канал похож на “ещё одну сетевую странность”.
В зрелой среде именно это и даёт самый сильный detection. Не отдельный индикатор, а граф поведения. Foothold, затем разведка, затем попытка опереться на доверенный протокол, а после этого новый маршрут или устойчивое присутствие. Как только туннель виден в этой последовательности, он перестаёт быть просто сомнительным трафиком и начинает выглядеть как часть постэксплуатационной цепочки.
| Источник | Что даёт | Чего без него не видно |
|---|---|---|
| DNS | Подозрительные имена и типы записей | Кто именно породил активность |
| Сеть / прокси | Маршрут и профиль соединения | Контекст процесса |
| Хост | Процесс и учётная запись | Внешнее назначение и маршрут |
| AD-контекст | Место события в цепочке атаки | Почему аномалия вообще важна |
Скрытый канал становится по-настоящему заметным не тогда, когда кто-то находит один необычный пакет, а когда удаётся связать сетевое отклонение с конкретным узлом, процессом и местом в цепочке атаки. Именно поэтому хорошая телеметрия здесь ценна не количеством событий, а возможностью собирать их в одну историю.
Detection engineering и threat hunting
Скрытые каналы почти никогда не ловятся одной красивой сигнатурой. На практике detection здесь строится на умении собрать слабые признаки в одну гипотезу и проверить, насколько они укладываются в уже известную постэксплуатационную историю. Именно поэтому tunneling и pivoting в AD - это в первую очередь задача на корреляцию, а не на поиск одного “магического индикатора”.
Какие источники логов и сетевой телеметрии собирать в первую очередь
Базовая ошибка в этой теме - надеяться, что одного сетевого сенсора будет достаточно. Не будет. Скрытый канал как раз и строится на том, чтобы в сети выглядеть максимально нормально или хотя бы спорно, но не откровенно вредоносно. Поэтому минимально полезный набор для защиты здесь всегда многослойный: DNS-журналы, прокси и журналы выхода наружу, потоки или сессии на сети, а на уровне хоста - процессы, сетевые соединения и связь между процессом, пользователем и направлением трафика.Для Windows-узлов это особенно важно. Если у защитника нет нормальной хостовой телеметрии, то любой HTTPS-канал, редкий SSH-клиент или нестандартная DNS-активность будут существовать в вакууме. Да, трафик странный. Но кто его породил, в каком контексте, с каким родителем процесса, с какой учётной записью и после каких действий на хосте - уже не видно. А без этого hidden tunneling почти всегда будет либо “возможно интересно”, либо “наверное, легитимно”. Именно поэтому Sysmon, журналы сетевых соединений, телеметрия процессов и нормальная сборка DNS-жизни в SIEM здесь важнее, чем многие более красивые, но изолированные источники.
Отдельно в AD-среде ценен и инфраструктурный контекст. Не только сами логи хоста, но и понимание его роли: обычная рабочая станция, jump host, сервер сопровождения, терминальный узел, промежуточный сегмент, DNS-сервер, прокси. Один и тот же сетевой рисунок на этих узлах будет означать совсем разное. Поэтому detection для скрытых каналов почти всегда зависит не просто от “что произошло”, а от “где это произошло и насколько это вообще совместимо с ролью узла”.
Hunting-гипотезы для DNS, HTTP/S, SSH и ICMP tunneling
Полезная hunting-гипотеза в этой теме всегда должна быть чуть уже, чем просто “поиск аномалий”. Иначе получаешь слишком много шума и почти никакой пользы. Для DNS хорошая гипотеза обычно звучит так: на хосте после foothold или подозрительной разведки появляется нетипичный DNS-профиль - редкие домены, высокая энтропия имён, всплески TXT, непривычная частота запросов или однообразные обращения с регулярным ритмом. Важно, что здесь hunting начинается не с домена вообще, а с того, как конкретный узел ведёт себя относительно своей нормальной жизни.Для HTTP/S вопрос другой: какой узел или процесс начал строить веб-соединения, нехарактерные для своей роли. Не просто “есть HTTPS”, а появились длинные соединения, редкие внешние назначения, однообразная периодичность, странные пути или заголовки, а сам трафик исходит из процесса, который раньше никогда не был веб-клиентом. В этой зоне особенно хорошо работают не сигнатуры на конкретные инструменты, а отклонения от базовой линии: кто раньше не ходил наружу, а теперь ходит; кто ходил, но иначе; кто использует веб-канал из неожиданного процесса.
С SSH и ICMP история ещё жёстче завязана на контекст. Для SSH полезная гипотеза почти всегда строится через роль хоста: почему обычная рабочая станция инициирует SSH, почему на сервере приложений появился plink.exe, почему системная учётная запись строит канал, которого раньше не было. Для ICMP - почему узел внезапно начинает использовать пакеты и ритм, больше похожие на транспорт, чем на диагностику. В обоих случаях лучше всего работает не “этот протокол плохой”, а “этот протокол ведёт себя нетипично для данного узла, процесса и маршрута”.
Как отличать легитимное администрирование от скрытого канала
Это самое неприятное место всей темы. В зрелой инфраструктуре часть признаков hidden tunneling действительно похожа на нормальную административную жизнь, поэтому главное различие между админской активностью и скрытым каналом почти никогда не лежит в одном техническом признаке. Оно лежит в сочетании контекста.Первый вопрос здесь всегда один: соответствует ли активность роли узла и пользователя. Если SSH идёт с jump host’а под ожидаемой учётной записью в привычное окно времени - это одна история. Если тот же SSH появляется на пользовательской рабочей станции или на сервере, где такой профиль раньше не встречался, - совсем другая. То же касается DNS, HTTP/S и любых прокси-маршрутов. Сам по себе протокол редко доказывает злоупотребление. Его выдаёт несоответствие: кто делает, откуда делает, куда делает, когда делает и чем именно это отличается от нормальной жизни этой системы.
Второй важный вопрос - что происходило до канала и после него. Если “странный” DNS живёт сам по себе, расследование ещё может быть спорным. Но если перед ним был foothold, затем доменная разведка, а после него начались новые межсегментные маршруты или lateral movement, это уже не просто необычная активность. Именно здесь admin-like трафик и перестаёт быть похожим на администрирование. Он становится транспортом внутри постэксплуатационной цепочки.
Корреляция: сеть, хост, учётная запись, маршрут доступа
В этой теме побеждает не тот, у кого больше журналов, а тот, кто умеет складывать их в маршрут. Скрытый канал редко выглядит убедительно на одном уровне. Но как только сетевую аномалию удаётся связать с конкретным процессом, потом с учётной записью, потом с ролью узла, а потом ещё и с уже известной активностью в доменной среде, картина быстро становится жёстче.Именно поэтому для tunneling и pivoting особенно ценна корреляция по времени и контексту. На одном и том же хосте были признаки разведки, затем тот же пользователь или процесс построил нетипичный DNS или HTTPS-канал, после этого с узла пошли новые связи к внутренним сегментам или поднялась активность по lateral movement - это уже не набор случайных наблюдений. Это цепочка. И чем раньше SOC умеет видеть такие цепочки как единое поведение, тем меньше шансов, что скрытый канал проживёт долго просто потому, что выглядел “почти нормальным”.
| Зона detection | Что лучше искать | Почему это работает |
|---|---|---|
| DNS | Энтропию, TXT abuse, редкие зоны, регулярные серии запросов | Даёт поведенческий профиль, а не зависимость от одной сигнатуры |
| HTTP/S | Длинные соединения, редкие назначения, нетипичные заголовки и процессы | Помогает увидеть злоупотребление разрешённым веб-трафиком |
| SSH / ICMP | Несоответствие роли узла, времени, процесса и маршрута | Здесь контекст почти важнее самого протокола |
| Корреляция | Связь между foothold, разведкой, каналом и последующим движением | Превращает аномалию в понятный этап атаки |
Сильный detection для скрытых каналов начинается там, где защитник перестаёт искать “плохой инструмент” и начинает смотреть на доверенный трафик как на возможный транспорт атакующего. Именно в этот момент hunting становится не коллекцией странных событий, а нормальной работой по сборке маршрута внутри AD-среды.
Защита и сдерживание
Скрытые каналы плохо ломаются сигнатурами и ещё хуже - надеждой, что защита “просто заметит что-то странное”. В этой зоне намного лучше работает другая логика: не ждать идеального детекта на последнем этапе, а заранее ухудшать условия, в которых такой канал вообще может родиться. Если атакующему негде удобно прятать управление, если доверенный трафик меньше похож на открытую магистраль, если сегментация и выход наружу контролируются жёстче, то tunneling и pivoting становятся не невозможными, но заметно дороже, шумнее и менее устойчивыми.Именно поэтому защита здесь начинается не с поиска очередной утилиты, а с экономикой атаки. Каким протоколам среда доверяет слишком легко. Кто имеет право строить исходящие соединения. Как живёт DNS. Где разрешён SSH. Какие хосты могут тянуться наружу напрямую, а какие только через прокси. Где jump host действительно контролируем, а где он просто удобный промежуточный узел для тех, кто уже оказался внутри. Чем лучше на эти вопросы есть инженерный ответ, тем меньше шансов, что доверенный трафик незаметно превратится в транспорт постэксплуатации.
DNS filtering, RPZ и ограничение внешней резолюции
Если среда слишком легко выпускает DNS наружу и почти не контролирует, кто, что и куда резолвит, это почти готовое приглашение к злоупотреблению. Поэтому один из самых полезных уровней сдерживания - сделать DNS менее “прозрачным” и менее универсальным каналом. Не в смысле ломать доменную жизнь жёсткими запретами, а в смысле навести дисциплину: централизованная резолюция, понятные доверенные маршруты, ограничение прямых внешних обращений, фильтрация подозрительных зон и контроль нетипичных типов записей. RPZ - Response Policy Zone, то есть политика на стороне DNS, которая позволяет переписывать или блокировать ответы для доменов и зон по заданным правилам, - как раз хорошо ложится в такую модель.Для Blue Team это особенно полезно потому, что DNS-туннель живёт лучше всего там, где DNS считают слишком “служебным”, чтобы смотреть на него серьёзно. Как только у среды появляется жёстче контролируемая внешняя резолюция, централизованная видимость и понятная политика для подозрительных зон, удобство DNS как скрытого канала резко падает. Он либо начинает конфликтовать с правилами, либо становится заметнее по форме, либо требует от атакующего куда больше аккуратности.
Но и здесь важно не перейти в карикатурную жёсткость. Если DNS-защита строится без понимания живой инфраструктуры, она очень быстро начинает мешать легитимным сервисам, облачным платформам и внешним интеграциям. Поэтому реальная сила этой меры не в тотальном запрете, а в том, чтобы убрать бесконтрольность и сделать внешний DNS-путь управляемым.
Egress control и inspection на разрешённых протоколах
Вторая большая зона - контроль выхода наружу. Очень многие скрытые каналы рождаются не потому, что атакующий нашёл “секретный протокол”, а потому, что исходящие соединения в среде устроены слишком доверчиво. Если наружу можно спокойно строить почти любой HTTPS, если прокси пропускает слишком широкий спектр трафика, если нет нормального разделения по ролям узлов и маршрутам выхода, то встроиться в разрешённый канал становится слишком просто.Именно поэтому egress control - контроль исходящих соединений - даёт такой сильный эффект. Как только у узлов появляются понятные правила: кто вообще может ходить наружу, через какой прокси, к каким назначениям, по каким протоколам и в каком объёме, скрытый канал перестаёт быть “естественным продолжением разрешённого трафика”. Он начинает либо выбиваться из нормальной схемы выхода, либо требовать дополнительного обхода, либо проявляться в прокси и сетевых журналах заметнее, чем хотелось бы атакующему.
Inspection на разрешённых протоколах здесь особенно важен. Не в смысле полного просмотра всего подряд любой ценой, а в смысле контроля формы доверенного трафика. HTTPS, если ему доверяют безоговорочно, быстро превращается в слишком удобную маскировку. Но как только появляются разумные правила по назначениям, длительности соединений, профилю клиента, путям, заголовкам и поведению процесса-источника, этот же протокол становится намного менее комфортной средой для сокрытия управления.
Ограничение SSH, SOCKS и нестандартных исходящих соединений
SSH и связанные с ним прокси-сценарии особенно опасны там, где их считают “нормальным администрированием” и потому почти не ограничивают. В таких средах hidden channel не нужно изобретать с нуля - достаточно встроиться в уже существующую привычку: доверие к промежуточным хостам, терпимость к длинным исходящим сеансам, слабый контроль того, какие именно клиенты и на каких узлах вообще должны использовать SSH.Поэтому здесь защита строится вокруг роли и маршрута. Где SSH действительно нужен. На каких хостах. Каким администраторам. В какие сегменты. В какие окна времени. Через какие jump host’ы. И какие клиенты вообще считаются допустимыми. Чем меньше в этой зоне безадресного доверия, тем труднее атакующему использовать SSH и SOCKS как тихую административную “норму”, под которой можно спрятать реальный transport layer для pivoting.
То же относится и к другим нестандартным исходящим соединениям. Любая среда, где хосты могут произвольно строить длинные каналы наружу просто потому, что “иногда так надо”, почти неизбежно получает слишком удобную почву для скрытого присутствия. Здесь как раз работает старый, но очень полезный принцип: разрешать по роли, а не по умолчанию. Не каждый сервер, не каждая рабочая станция и не каждая служебная учётная запись должны иметь право жить в режиме “строю исходящий канал, потому что могу”.
Сегментация, jump hosts и контроль административных маршрутов
Хорошая сегментация полезна не только против lateral movement как такового, но и против той логики, на которой вообще держится post-exploitation pivoting. Чем меньше прямых путей между сегментами, чем жёстче управляются административные маршруты и чем понятнее роль промежуточных узлов, тем труднее атакующему превратить foothold в устойчивый транспорт до следующей зоны.Здесь особенно важно правильно обращаться с jump host’ами. В идеальной архитектуре это не “удобные узлы, через которые всё можно”, а жёстко контролируемые точки прохода с понятной ролью, аудитом и ограниченным набором допустимых сценариев. В плохой архитектуре jump host почти неизбежно становится местом, где доверие уже встроено в саму среду, а значит и удобной опорой для скрытого pivoting. Именно поэтому такие узлы нужно не просто иметь, а держать под отдельным контролем: кто на них заходит, что на них запускает, какие каналы оттуда строятся и насколько это соответствует реальной административной жизни.
В AD это особенно чувствительно, потому что административные маршруты часто пересекаются с самыми ценными сегментами. Если их не ограничивать и не делать прозрачными для расследования, скрытый канал почти неизбежно будет искать опору именно там. Поэтому сегментация здесь полезна не как абстрактная “лучшая практика”, а как способ отрезать удобные пути для post-exploitation и сделать любую попытку построить транспорт внутри доменной среды заметно более дорогой.
| Мера защиты | Что именно она ломает | Главное ограничение |
|---|---|---|
| DNS filtering и RPZ | Удобство DNS как бесконтрольного транспорта | Требует аккуратной настройки, чтобы не ломать легитимную резолюцию |
| Egress control и inspection | Простое сокрытие в разрешённом веб-трафике | Без нормальной ролевой модели быстро превращается в формальность |
| Ограничение SSH и SOCKS | Маскировку под “нормальное администрирование” | Зависит от зрелости контроля ролей и jump host’ов |
| Сегментация и контроль маршрутов | Дешёвый pivot между сегментами после foothold | Плохо работает, если административные исключения слишком широки |
Сильная защита в этой теме начинается там, где доверенный трафик перестаёт быть безоговорочно доверенным. Не потому, что его теперь надо запрещать целиком, а потому, что у него появляется форма, границы и роль. И как только эти границы становятся инженерно внятными, скрытый канал уже не так легко сливается с нормальной жизнью среды.
Где доверенный трафик перестаёт быть безопасным
Скрытые каналы после foothold опасны прежде всего потому, что часто прячутся в трафике, который в инфраструктуре уже считается допустимым. DNS, HTTP/S, SSH и служебные маршруты могут выглядеть частью нормальной сетевой жизни и одновременно становиться транспортом для post-exploitation.Из этого и следует главный вывод. Hidden tunneling в AD плохо ловится по названиям утилит и почти никогда не сводится к одной красивой сигнатуре. Его приходится вытаскивать из контекста: от foothold и разведки - к нетипичному каналу, от канала - к процессу, от процесса - к маршруту, от маршрута - к роли узла и месту в постэксплуатационной цепочке. И точно так же он плохо ломается одной точечной мерой. Здесь работает только комбинация - контроль выхода наружу, дисциплина DNS, ограничение административных маршрутов, нормальная хостовая телеметрия и способность собирать разрозненные сигналы в одну историю.
И вот здесь остаётся самый неприятный вопрос для любой зрелой AD-среды. Если завтра атакующий спрячет управление не в подозрительном инструменте, а в том трафике, которому ваша инфраструктура доверяет каждый день, защита увидит это как скрытый канал - или как ещё одну допустимую сетевую привычку?
