Сотрудники «Информзащиты» отметили увеличение числа компаний, где устройства пользователей имеют прямые административные каналы к серверной инфраструктуре. Анализ обращений и проектных проверок за период с января по май 2026 года показал, что доля таких сред выросла до 12,2% по сравнению с 8,9% годом ранее. Эту информацию CNews предоставили представители «Информзащиты».
Другими словами, примерно каждая восьмая организация предоставляет рабочим станциям доступ к ценным серверам через RDP, SSH, SMB, WinRM или аналогичные административные протоколы. За год этот показатель увеличился на 3,3 процентных пункта, а число инцидентов и сценариев, предшествующих инцидентам, где такая связь могла бы ускорить атаку, возросло на 37%.
Прямые маршруты от пользовательских сегментов к серверам обычно накапливаются годами: временный доступ для подрядчика, исключение для удаленной поддержки, срочная настройка после миграции, обходной путь для старого приложения или нестандартное подключение к терминальному серверу. В 73% проверенных сред хотя бы одно активное правило межсетевого экрана не имело владельца в CMDB — его создатель уволился или перешел в другой отдел, а правило осталось, так как никто не рискнул его удалить. Со временем меняются владельцы систем, обновляется инфраструктура, уходят сотрудники, а правило сохраняется — SIEM не распознает аномалию там, где трафик формально легитимен: RDP с бухгалтерского ноутбука к файловому серверу выглядит как обычная работа ровно до тех пор, пока не начинается горизонтальное сканирование. В нормальной эксплуатации такая связь может не вызывать видимых проблем. Администратор подключается к серверу, служба передает данные, инженер проверяет состояние узла. После компрометации endpoint этот же маршрут становится готовым коридором для разведки, проверки учетных данных и дальнейшего продвижения.
Особую опасность представляет сочетание широкого доступа к административным протоколам и устаревших методов аутентификации. В исследовании по боковому перемещению внутри сети указано, что 87% серверов принимают внутренний трафик RDP или SSH. Первый протокол обычно используется для удаленного подключения к Windows-серверам, второй — для администрирования Linux- и сетевых систем. Еще 78,7% серверов доступны через SMB или WinRM: SMB применяется для доступа к файловым ресурсам и служебным сетевым шарам, WinRM — для удаленного управления Windows-средой. С помощью NetExec или CrackMapExec атакующий за 3-5 минут строит карту отвечающих хостов: скрипт параллельно опрашивает сотни адресов и одновременно тестирует перехваченные хэши без ручного перебора. На практике злоумышленник, получивший контроль над ноутбуком сотрудника, может быстро проверить, какие серверы отвечают на такие подключения, где доступны файловые ресурсы, какие учетные данные сработают повторно и какие узлы допускают удаленное выполнение команд.
Дополнительные угрозы возникают из-за сохранения NTLM-аутентификации. Этот механизм составляет 43,2% всего наблюдаемого внутреннего трафика проверки подлинности. NTLM представляет собой устаревший протокол аутентификации в средах Windows, который остается привлекательной мишенью для атак, направленных на повторное использование хэша пароля. В такой ситуации злоумышленнику не обязательно знать исходный пароль: достаточно заполучить его криптографический отпечаток из оперативной памяти или с диска взломанного устройства и попытаться применить его на других доступных системах. Если пользовательское устройство имеет прямой доступ к серверным сегментам, этот метод становится значительно эффективнее. Ключевая деталь: NTLM-хэш, извлеченный из процесса lsass.exe с помощью Mimikatz или аналогичных инструментов, остается действительным до момента смены пароля – а средний период ротации паролей сервисных учетных записей в исследованных организациях достигал 187 дней. У атакующего появляется возможность проверять учетные данные не на одном устройстве, а сразу на множестве достижимых узлов.
В 34% связанных сценариев начальной точкой выступал фишинг с компрометацией рабочей станции сотрудника, после чего злоумышленник искал открытые RDP, SSH и WinRM-соединения к серверной зоне. Еще 26% случаев составляли кража или повторное использование учетных данных, включая NTLM-хэши и пароли привилегированных пользователей, которые ранее входили на обычные рабочие станции. В 18% случаев угрозу создавали сервисные и технические учетные записи с избыточными правами, поскольку такие записи часто имеют доступ к нескольким системам одновременно и слабо контролируются в повседневной эксплуатации. На эксплуатацию внутренних уязвимостей пришлось 13% сценариев: атакующий сначала закреплялся на пользовательском устройстве, затем сканировал доступные серверные сервисы и использовал незакрытые CVE. Оставшиеся 9% были связаны с ошибками сегментации в гибридных средах, где пользовательские устройства, облачные консоли, Kubernetes-кластеры и локальные сервисы оказывались связаны через исключения, созданные для удобства работы.
Сама архитектура корпоративной сети часто способствует таким ошибкам. Инфраструктура строилась вокруг доступности сервисов, скорости поддержки и минимизации обращений в ИТ-отдел, поэтому внутренний источник долгое время считался более доверенным. VPN-подключение, доменная рабочая станция или адрес из корпоративной подсети предоставляли больше прав на сетевом уровне, чем фактически требуется пользователю или процессу. Из-за этого нарушается модель tiering: обычные рабочие станции оказываются слишком близко к серверам приложений, системам резервного копирования, доменным контроллерам, консолям виртуализации и базам данных. Для защитника разница между одним и двумя переходами колоссальна: на каждом шаге есть возможность заметить аномалию и остановить продвижение. Для атакующего при широкой внутренней доступности эта разница практически исчезает, особенно при использовании автоматизированной разведки и инструментов построения путей атак.
Наиболее ярко данная проблема выражена в банковской сфере, на производстве, в розничной торговле, телекоме и компаниях с разветвлённой сетью филиалов. Согласно оценкам специалистов, из всех зафиксированных случаев прямых административных путей 27% относились к промышленным и производственным предприятиям, где ИТ-системы и АСУ ТП нередко объединены технологическими уступками и удалённым обслуживанием. На долю финансовых учреждений пришлось 22% выборки: у них наблюдается более высокая плотность управляемых серверов, больше интеграционных связей и жёстче требования к непрерывности работы, из-за чего временные разрешения часто становятся постоянными. В рознице зафиксировано 18% случаев, что в основном связано с большим количеством торговых точек, POS-инфраструктурой, терминальными серверами и системами удалённой поддержки. Телекоммуникационный сектор составил 14%, где угрозу усиливают сложные сетевые домены и обширный перечень инженерных доступов. Ещё 11% пришлось на логистику и транспорт, а 8% – на медицинские и образовательные учреждения, где уровень зрелости сегментации ниже, а зависимость от устаревших сервисов более выражена.
Первое, что стоит сделать на практике, — провести адресную инвентаризацию: извлеките из Active Directory все групповые политики (GPO), которые разрешают RDP и WinRM, сопоставьте их с перечнем конечных устройств, не входящих в Tier 0 или Tier 1, и получите точный список машин, с которых в данный момент есть прямой доступ к контроллеру домена или серверам резервного копирования. Чтобы снизить риски, компаниям следует не начинать с очередной проверки открытых портов, а создавать карту реальной доступности между пользовательскими устройствами и критически важными серверами. У каждого административного маршрута должен быть ответственный владелец, четкая цель, срок действия, а также технические ограничения по источнику, роли и времени. RDP, SSH, SMB и WinRM стоит перевести в режим доступа по запросу, внедрить MFA для административных подключений, контролировать сеансы и запретить прямой вход с пользовательских устройств на серверы высокой критичности. Отдельное внимание нужно уделить пересмотру использования NTLM, исключить постоянные привилегии у сервисных учетных записей, разграничить рабочие станции администраторов и обычных пользователей, а также изолировать инфраструктуру резервного копирования и контроллеры домена в отдельные зоны управления. Согласно данным расследований, медианное время от компрометации конечного устройства до первого подключения к серверу резервного копирования составило 4 часа 20 минут — это быстрее, чем в большинстве организаций успевает сработать эскалация из SIEM к дежурному аналитику. Компрометация ноутбука рядового сотрудника не должна давать атакующему прямой путь к серверу, от которого зависит бизнес-процесс: пока такая связность остается нормой, SOC реагирует не на человека, а соревнуется с уже выстроенной архитектурой атаки. Практический ориентир здесь прост: компрометация ноутбука сотрудника не должна открывать злоумышленнику короткий маршрут к серверу, на котором держится бизнес-процесс. Пока такая связность остается штатной частью сети, скорость реагирования SOC будет конкурировать не с человеком, а с заранее подготовленной архитектурой атаки.
