По результатам пентестов, проведенных нашими специалистами в 2021–2022 годах, 96% компаний оказались не защищены от проникновения в локальную сеть, причем в 8 из 10 организаций мог бы проникнуть даже низкоквалифицированный злоумышленник. Среди протестированных предприятий каждое пятое — из отрасли промышленности, и инциденты на них гораздо серьезнее и страшнее, чем взлом кассового аппарата продуктового магазина. Остановка турбины АЭС грозит экологической катастрофой, авария на металлургическом заводе практически всегда приводит к человеческим жертвам. А что будет, если хакеры атакуют аэропорт?
Мы проверили и узнали — ничего хорошего. На кибербитве Standoff команда красных взломала SCADA-систему аэропорта виртуального Государства F. Более того, им удалось получить контроль над телетрапом. Мы подробно рассказывали об этой истории в нашем блоге.
Сегодня мы пошагово разберем действия red team, расскажем, как модели машинного обучения могли бы помочь их поймать, и покажем, какими методами можно обнаружить атаку и выявить ее источник.
Шаг 1. Социальная инженерия в деле
Любая успешная кибератака начинается с того, что атакующие преодолевают периметр корпоративной сети. Это можно сделать разными способами: при помощи эксплуатации уязвимости, использования утечек данных сотрудников или методами социальной инженерии.
Что случилось: в случае с аэропортом красные использовали последний вариант. Они отправили фишинговое письмо с вредоносным ПО во вложении, которое открыл работник HR-отдела. Это позволило получить доступ к узлу жертвы, и дальше нападающие развивали атаку так, как будто они сидят за ее офисным компьютером.
Что делать: по нашим данным, во II квартале 2023 года злоумышленники использовали методы социальной инженерии в 37% атак на организации и в 90% атак на частных лиц. В нашем случае сотрудник не стал бы жертвой, если бы знал о фишинговых письмах: какие они бывают, кому и зачем их отправляют и главное — что произойдет, если открыть подозрительное письмо от неизвестного адресата и загрузить вложение на свой компьютер.
Есть несколько способов не допустить распространения вредоносных программ на самом раннем этапе атаки. Мы разработали для таких случаев модуль поведенческой аналитики. Он использует множество разных моделей машинного обучения и статистических подходов, чтобы определить набор действий, ожидаемых от каждого пользователя. Когда пользователь делает что-то необычное, ему начисляются «очки» риска. Если балл высокий, очень вероятно, что перед нами черный хакер. Такой подход помогает специалистам по ИБ определить, кто из пользователей может представлять угрозу для инфраструктуры. Как отреагирует система, если процесс всегда автоматически запускался со стандартными параметрами, а в один прекрасный момент параметры были указаны вручную?
Модуль не рубит сгоряча: вместо того чтобы вынуждать оператора вручную рассматривать каждую конкретную аномалию, он собирает информацию по каждому сотруднику в отдельный профиль и на основе экспертных правил и моделей машинного обучения выносит вердикт: являются ли действия работника компании легитимными или на той стороне сидит коварный злоумышленник.
Давайте рассмотрим работу одной из ML-моделей — анализ цепочки запускаемых процессов, который помогает определить случаи фишинга. Допустим, вы запускаете Outlook, и там есть вложение. Вы кликаете по нему — открывается winword.exe. Вы читаете документ, а он в фоновом режиме запускает cmd.exe и утилиту whoami.exe. Модуль сочтет эти действия подозрительными, потому что таким способом киберпреступники зачастую проверяют свои права в системе.
Алгоритм машинного обучения будет видеть цепочку процессов, состоящую из звеньев изменяемой длины. Для повышения эффективности его работы достаточно разбить цепочку A — E на четыре пары: A — E, B — E, C — E, D — E. Это позволит построить матрицу взаимодействия, где каждая ячейка соответствует паре. Как в таком случае модуль фиксирует аномалии, читайте в другой статье нашей команды.
Разумеется, анализ цепочек не панацея. Но в этом кейсе он позволяет изучить, помимо прочего, нетипичные подключения процессов к внутренним ресурсам компании.
Шаг 2. Загрузка агента С2-сервера на узел
Что случилось: сотрудник компании-жертвы кликнул на злополучное письмо, открыл вредоносный файл — и подключился к управляющему узлу , с которого «красные» могут отправлять команды. В этом случае, как правило, коммуникация идет по зашифрованному трафику, поэтому сигнатурные детекты бессильны.
Что делать: поможет система поведенческого анализа сетевого трафика (network traffic analysis, NTA). Анализируя зашифрованный трафик, мы можем выяснить, является ли сессия вредоносной. Нас интересует не то, что передают друг другу клиент и сервер, а как и в каком объеме, то есть статистические признаки. Достаточно посмотреть длину переданных и принятых пакетов, чтобы найти интересные закономерности, которые позволяют свести задачу к бинарной классификации.
Таким образом задача определения вредоносного ПО существенно упрощается. Для наглядности мы подготовили гистограммы: голубой — подозрительные признаки, желтый — легитимные.
Еще один способ поиска зловредов в зашифрованном трафике — использование песочницы. Так называют класс продуктов, который эмулирует операционную систему и проверяет каждый файл на наличие вредоносной нагрузки. Песочницы проводят статический и динамический анализ, причем динамический — частично с помощью машинного обучения.
Каждый запущенный процесс оставляет после себя последовательность системных вызовов, с помощью которых он взаимодействовал с операционной системой — она называется трассой.
Мы заранее проанализировали большое количество зловредных и чистых трасс, чтобы выделить последовательности, характерные для трасс с вредоносным ПО. Большое количество вызовов сводится к конечному вектору признаков, понятному для ML-модели, которая классифицирует это поведение как «плохое» или «хорошее». Подробнее о поведенческом анализе в песочнице мы рассказывали в этой статье.
Шаг 3. Повышение привилегий
Что случилось: после того как атакующие получают возможность выполнить вредоносный код на узле внутри периметра компании, им нужно закрепиться в сети и повысить привилегии. Есть множество способов это сделать: от эксплуатации известных уязвимостей ядра до использования ошибок в конфигурации.
На кибербитве Standoff «красные» использовали подмену исполняемого файла сервиса. Они поменяли zabbix_agent.exe на вредоносное ПО и повысили свои привилегии до максимальных. После этого атакующие могли делать на захваченном узле практически все что угодно.
Что делать: с точки зрения защиты можно заметить, что цепочка процессов, в отличие от метаинформации Zabbix-агента, не изменилась. Еще один подозрительный момент: агент начал совершать подключения как во внутреннюю, так и во внешнюю сеть. Это характерный признак использования туннелей для перенаправления вредоносных команд на скомпрометированный узел.
На этом шаге все действия черных хакеров можно фиксировать в модуле поведенческой аналитики, о котором мы рассказывали на втором шаге.
Шаг 4. Активная разведка
Что случилось: на этом этапе «красные» начали большую разведку с целью поиска информации для дальнейшего перемещения внутри периметра, чтобы достичь конечной цели — получить доступ к управлению телетрапом. Они внимательно изучали права пользователей внутри сети, искали привилегированные учетные данные и знакомились с внутренними сервисами.
Что делать: на помощь снова приходит модуль поведенческой аналитики, а именно — модель рекомендательной системы. Вы наверняка встречали рекомендательные системы в сфере ритейла: это они советуют нам товары, музыку и кино. Мы адаптировали эту систему для рекомендации процессов в зависимости от функциональных групп пользователей.
Представим ситуацию: разработчик ежедневно использует одни и те же программы. Выходит новая IDE (integrated development environment), и он решает потестировать, насколько она удобна. Будет ли сам по себе запуск ранее не использовавшейся программы считаться аномалией? В классических системах защиты — да, новый процесс однозначно классифицировался бы как потенциальный инцидент безопасности, который должен анализировать оператор SOC (security operations center). В нашем случае мы заранее знаем, какие инструменты может использовать разработчик, поэтому повода для паники нет.
А если перенести эту ситуацию на сотрудника отдела, не связанного с программированием? Согласитесь, не каждый день бухгалтер устанавливает Visual Studio Code. Для группы пользователей с одинаковыми функциями — бухгалтеров, финансовых аналитиков или маркетологов — запуск такой программы будет нетипичным событием, и рекомендательная система оповестит специалиста по безопасности, что этот процесс подозрителен, а значит, что-то идет не так.
Подробнее о применении рекомендательной системы для детектирования аномального поведения рассказал наш коллега Игорь Пестрецов.
А в нашем кейсе модуль, конечно же, заметит аномалии в поведении захваченных учетных записей, которые запускают нетипичные для себя программы и действуют в неожиданных сегментах системы.
Шаг 5. Получение учетных данных
Что случилось: главной находкой red team внутри сети стал узел, в памяти которого хранились учетные данные администратора аэропорта. Атакующим хватило прав, чтобы извлечь их дистанционно, не заходя на узел.
Существует несколько популярных инструментов для получения удаленного доступа. Например, утилиты из набора Impacket часто используются реальными киберпреступниками для исполнения кода и извлечения данных.
Что делать: обнаружить такое поведение можно с помощью модели, которая будет сигнализировать об аномалиях в событиях Windows: для таких аномалий зарезервировано событие с идентификатором 5145. При создании ML-модели есть два действенных подхода:
На основе разнообразия: собираются факты посещения пользователями сетевой папки. При появлении каждого нового уникального юзера в нетипичном для него месте система может оценить, насколько часто подобные события вообще могут происходить.
На основе вероятности: проводится анализ — сколько раз определенный пользователь заходил в конкретные подразделы сетевой папки.
Шаг 6. Эксплуатация уязвимости iTop
Что случилось: захватив один узел и получив доступ к привилегированной учетной записи домена, атакующие переместились из пользовательского сегмента сети в серверный.
«Воротами» в сердце инфраструктуры стал сервис заявок в IT-службу iTop. Сотрудники аэропорта в Государстве F использовали необновленную версию ПО с известной уязвимостью. «Красные» ее легко проэксплуатировали и проникли к серверам, предоставляющим широкий доступ к сетевым ресурсам. Например, с сервера Remote Desktop Gateway (RDG) можно подключиться по протоколу удаленного рабочего стола почти к любой рабочей станции.
Что делать: можно применить статистические модели с использованием «склейки событий» — объединения нескольких фактов, зафиксированных в системе. Например, некоторые события дают информацию о том, был ли в сети условный процесс A. Склеив их с событием входа 4624, мы можем понять, как процесс A повлиял на процесс B в рамках одного узла. Статистика по таким склейкам позволяет обнаружить аномалию.
Шаг 7. Перемещение внутри периметра
Что случилось: используя данные администратора, широкий сетевой доступ с сервера RDG и абсолютно легитимные инструменты ОС, «красные» переместились на один из компьютеров оператора АСУ ТП и получили возможность управлять телетрапом в аэропорту виртуального Государства F.
Что делать: на протяжении всей атаки подозрительные действия фиксируются системой, возникает большое количество событий безопасности. Модуль поведенческой аналитики присваивает очки риска каждому подозрительному процессу и выводит ранжированный список — это повышает скорость реакции на инцидент и снижает нагрузку на операторов SOC.
Что в итоге
Как правило, операторам АСУ ТП доступно управление различными системами (например телетрапами). На их узлах есть сохраненные подключения, в которых зачастую содержатся учетные данные — за ними и охотятся злоумышленники. Немного локальной разведки, и киберпреступник может забраться так глубоко в инфраструктуру, что последствия его деятельности могут оказаться фатальными. К счастью, наша история произошла в виртуальном Государстве F во время кибербитвы Standoff, а значит, ни один реальный аэропорт не пострадал, пассажиры успели на свои рейсы, а специалистам по ИБ не пришлось отвечать за проникновение черных хакеров в инфраструктуру.
Если вам нравится machine learning так же, как и нам, присоединяйтесь к ML-команде Positive Technologies. Сейчас мы ищем ML-инженеров: опытных специалистов с хорошим знанием Python, пониманием основ статистики, техник машинного обучения и желанием разбираться в новых современных решениях. Подробнее о том, что мы делаем, можно узнать по ссылке.
Авторы:
Кирилл Кирьянов, руководитель группы обнаружения атак на конечных устройствах
Юлия Фомина, ведущий специалист группы обнаружения атак на конечных устройствах
Николай Лыфенко, руководитель группы анализа трафика
Артем Проничев, старший специалист отдела перспективных технологий
Игорь Кабанов, специалист отдела перспективных технологий
