Как ИНН, PostgreSQL и антивирус помогли захватить два домена

Кейс оказался показательный: сначала исследователи получили доступ к почте через ИНН, а затем через связку внутренних сервисов дошли до двух доменов и критичных систем. На старте у них был только масочный домен и внешний доступ через интернет, а на пути стоял WAF, который заметно усложнил работу.

Этот разбор полезен не только специалистам. Он показывает, как слабая дисциплина с паролями, открытые материалы для сотрудников и лишнее доверие между сервисами превращают обычный офисный ИТ-ландшафт в цепочку для захвата серверных логов и подозрительных запросов или, наоборот, для тихого проникновения внутрь.

Какую проблему решали

Авторы тестировали крупную розничную компанию с развитой экосистемой сервисов для продавцов. Цель была не сводилась к одному серверу: требовалось попасть во внутреннюю сеть, взять под контроль домены и добраться до бухгалтерии на базе 1С, систем резервного копирования, антивирусной защиты, виртуализации и корпоративного приложения, которое еще находилось в разработке.

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

Что подготовить до атаки на инфраструктуру

В источнике сильнее всего бросаются в глаза три вещи. Во-первых, любая публичная информация о правилах формирования паролей — даже если она спрятана в презентации для новых сотрудников. Во-вторых, понимание бизнес-процессов: кто чем пользуется, какие роли есть у сотрудников, какие сервисы связаны между собой.

В-третьих, важна карта зависимостей. Если у компании есть SSO, dev-стенды, почта, базы данных и вспомогательные сервисы, то одна скомпрометированная учетная запись может открыть гораздо больше, чем кажется на первый взгляд. Именно поэтому в корпоративной среде так полезны жесткие правила для секретов, минимальные привилегии и регулярная проверка того, что доступно через связки сервисов.

Пошагово: как развивалась атака

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

Дальше команда проверила еще несколько ящиков, чтобы понять структуру ролей и прав. После этого она посмотрела, куда ведет SSO, и обнаружила dev-стенд за авторизацией. Такие находки часто дают больше, чем прямой вход в прод: тестовые панели, забытые сервисы и внутренние разделы нередко содержат детали архитектуры и новые точки входа.

Затем началась работа с веб-ресурсом, где нашлись запросы на C# с использованием LINQ. Это уже не про случайную уязвимость, а про цепочку, в которой одна техническая ошибка помогает перейти к следующей. В подобной ситуации важны не только прямые эксплойты, но и внимательный разбор логики приложения и того, как оно общается с бэкендом.

На следующем этапе команда добралась до PostgreSQL, а потом использовала связку NTLM relay и shadow credentials. Такой набор уже выводит атакующего на уровень доменных механизмов и дает возможность развивать атаку дальше. Если вам интересен похожий класс рисков, посмотрите наш разбор про компрометацию через обновления и утечку секретов: там тоже важна не одна ошибка, а цепочка слабых мест.

Финальный рывок шел через инфраструктуру бэкапов и антивируса. Авторы нашли, что эти системы тоже можно использовать для продвижения, а затем получили доступ к критическим сегментам. В таких кейсах особенно опасно, когда защитные сервисы живут по тем же правилам доверия, что и обычные рабочие станции: тогда злоумышленник сначала получает опору, а потом уже ломает весь периметр.

Как проверить себя

Проверка здесь не сводится к одной галочке в чек-листе. Нужно посмотреть, не используют ли сотрудники предсказуемые пароли, нет ли в открытом доступе инструкций для новичков с чувствительными деталями и не связаны ли dev-стенды с продом слишком тесно.

Отдельно стоит проверить, какие данные видны через SSO и как быстро одна учетная запись открывает доступ к соседним сервисам. Если почта, базы данных, бэкапы и защитные системы тянут друг друга за рукав, это уже повод пересмотреть архитектуру доверия и права доступа.

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

Что делать, если не получилось

Если в компании уже нашли похожую схему, лучше не чинить по одному симптому. Меняйте правила формирования паролей, убирайте совпадения с открытыми данными, закрывайте лишние dev-стенды и отделяйте служебные системы от пользовательских.

Параллельно проверьте, не дают ли почта и SSO слишком широкий доступ к внутренним сервисам. Для удаленной работы и команд в чужих сетях уместен дополнительный слой защиты трафика для рабочих задач, но он не заменяет нормальную аутентификацию, сегментацию и контроль секретов.

Чек-лист

• Уберите из инструкций для сотрудников любые намеки на формирование паролей по открытым данным.
• Проверьте, не совпадает ли пароль с ИНН, номером телефона или другим публичным идентификатором.
• Закройте dev-стенды за отдельной авторизацией и не связывайте их с продом без нужды.
• Ограничьте, что именно видно через SSO для обычной учетной записи.
• Проверьте права у почты, PostgreSQL, бэкапов, антивируса и систем виртуализации.
• Посмотрите, не осталось ли в открытом доступе презентаций, схем и внутренних памяток с чувствительными деталями.
• Сверьте журналы доступа и найдите странные переходы между сервисами.
• Составьте план, как изолировать критичные системы от пользовательского контура.