В прошлый раз мы рассказывали о том, как взлом сайта может привести к компрометации корпоративной переписки через контроль содержимого трафика.

В этой статье будет более захватывающе и интереснее. Прямо как в детективном романе. Мы расскажем, как злоумышленник с навыками Конкурентной Разведки (OSINT) может попасть в локальную сеть.

Этап первый. Разведка.

Начиналось все как обычно. Мы проводили проверку внешнего периметра сети заказчика на возможность проникновения. Кто же знал, что самое интересное будет уже на самом первом этапе тестирования — Разведке.

Традиционно, target — условное обозначение нашего заказчика. Приступаем к сбору информации. Что у нас имеется? Юридическое лицо (Назовем ОАО «Target») и сайт — target.ru.

Очень часто крупные и не очень предприятия берут на практику студентов, те в свою очередь пишут отчеты. Если практика преддипломная — пишут дипломный проект на основе полученного опыта. Вот и в данном случае поиск по юридическому лицу в поисковике вывел нас на дипломный проект 2010 года.

Изучив его дипломный проект мы увидели, что ОАО «Target» ранее принадлежало доменное имя «trgt.ru». Начали собирать информацию о домене trgt.ru и увидели, что домен был снят с регистрации год назад.

Часто имя домена AD внутри компании совпадает с внешним доменным именем почты или сайта. Вы могли убедиться в этом в предыдущей статье. Поскольку домен trgt.ru был зарегистрирован раньше, чем target.ru — было предположено, что у Заказчика в AD использовалось, а, возможно, сейчас используется, доменное имя trgt.ru.

И... Бинго. Мы без проблем зарегистрировали домен trgt.ru и, настроив веб сеПеренорвер на нашей VDS, начали ожидать поступающих запросов.

Полевые сводки
Полевые сводки

Этап Второй. Просмотр логов и установка Responder

Клиенты таргета не заставили себя долго ждать. Буквально через 5 минут посыпались логи с запросами вида: /wpad.dat. Напомним, что wpad.dat это файл для получения конфига для прокси.

Логи веб-сервера
Логи веб-сервера

Разворачиваем Responder на VDS. Инструмент для пентеста виндовой локалки Responder имеет модуль для работы с протоколом WPAD (параметр ‑w).

мануал по Responder
мануал по Responder

После запуска ждем некоторое время, пока «наши» клиенты начнут получать конфиги wpad. При обращении за wpad.dat, виндовый клиент предоставляет для аутентификации свой NTLMv2 хеш, который включает в себя имя пользователя и хешированый пароль. Результат не заставил себя долго ждать. Мы получили логин внутреннего пользователя AD и его NTLMv2 хеш. Далее его можно попытаться сбрутить.

Перехваченный NTLMv2 хэш
Перехваченный NTLMv2 хэш

Этап четвертый. Брутфорс полученных хешей и подключение к VPN

Можно использовать любой инструмент для брута. Мы использовали john.

Восстановленный NTLMv2 хэш
Восстановленный NTLMv2 хэш

Получен пароль пользователя - 123 (о, да, и не говорите). Далее удалось захватить еще несколько аккаунтов. Пароли не сильно отличались стойкостью. Ниже еще пример работы Responder.

Перехват хешей Responder
Перехват хешей Responder

На одном из субдоменов target.ru находился вход в Cisco ASA VPN. Причем вход можно было осуществить через AD (обычная практика).

Попробовали использовать полученные креды (несколько штук) и они успешно подошли. Нам удалось получить доступ до внутренней сети предприятия.

Web панель CISCO VPN
Web панель CISCO VPN

Также можно подцепиться через клиент Cisco Any Connect.

Подключение через Cisco Any Connect
Подключение через Cisco Any Connect

Дальше уже можно развлекаться с внутренней сеткой :)

Конечно, если бы на VPN шлюзе стояла двухфакторка, то такого вектора можно было избежать.

Итоги

C первого взгляда невероятный, но такой критичный мисконфиг, можно было бы с легкостью предотвратить. Shadow IT послужило первоочередной причиной. Конечно, это произошло из-за отсутствия регламента по выводу из эксплуатации доменного имени организации.

Второй фактор - это слабая парольная политика или, скорее, её полное отсутствие. Слабые пароли достаточно легко поддаются полному перебору или перебору по словарю.

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

Комментарии (5)


  1. PereslavlFoto
    03.02.2023 13:40

    Однако на предприятиях, где локальная сеть не использует AD, таких проблем не возникнет?


    1. lmsecurity Автор
      03.02.2023 15:11

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

      Отвечая коротко на Ваш вопрос. Без AD такого не будет, но есть нюансы :)


  1. scruff
    03.02.2023 14:09

    И всё-таки интересует время брутфорса пароля, который "немного" сложнее чем 123, типа А#@u55nd2. Хотя бы грубо - дни, месяцы, годы, десятилетия...


    1. lmsecurity Автор
      03.02.2023 15:15

      Да, задача определения стойкости паролей является основополагающей. Мы сейчас как раз занимается сбором статистики по переборам паролей. Ожидайте в ближайшем будущем!

      Дабы не оставить Ваш вопрос без ответа, прикладываю статью про карточки GTX4090 для приблизительного понимания стойкости паролей:
      https://www.ixbt.com/news/2022/10/18/geforce-rtx-4090-48.html

      Длинный пароль - это не панацея. Грамотный внутрянщик найдет другие способы компрометации домена. Однако следует придерживаться лучших практик. 16-18 символов для привилегированных УЗ.


  1. Dark_Purple
    04.02.2023 04:15

    Казалось бы, причём тут Altium Designer..