Microsoft теперь сам даёт хакерам ключи от систем — спасибо, Azure Arc
NewsMakerAzure Arc неожиданно стал каналом управления для хакеров — и всё по правилам.
Функция удалённого управления Azure Arc , предназначенная для централизации администрирования гибридной инфраструктуры, неожиданно оказалась полезной не только администраторам и DevOps-командам. Исследование , опубликованное специалистом по безопасности Энди Гиллом, продемонстрировало, как с её помощью можно развернуть полноценный канал командования и управления (C2) в обход традиционных средств обнаружения.
Сервис Azure Arc был представлен ещё в ноябре 2019 года, но оставался вне поля зрения большинства специалистов по безопасности до недавнего времени. Его основное назначение — управление инфраструктурой за пределами Azure, включая физические серверы, виртуальные машины и кластеры Kubernetes, находящиеся как в других облаках, так и в локальных ЦОДах. Визуально и логически подключённые системы отображаются в интерфейсе Azure и управляются как родные ресурсы. Однако именно это свойство стало привлекательным для атакующих.
Злоумышленник, получивший права локального администратора на целевой машине и доступ «Contributor» в соответствующем ресурсе Azure, может использовать Arc для регистрации устройства и установки агента. Эта процедура стандартна и не вызывает подозрений: достаточно сгенерировать скрипт через Azure Portal, запустить его на целевом хосте и авторизоваться через браузер. В результате, устройство появляется на панели управления Azure, где к нему можно применять различные «расширения» — в том числе и встроенный SSH-агент.
Подключение к машине осуществляется прямо через Azure Cloud Shell или CLI, а выполнение команд происходит от имени пользователя, указанного при подключении. При этом никакого дополнительного вредоносного ПО не требуется: все действия осуществляются с помощью легитимного агента Microsoft, прошедшего авторизацию и взаимодействующего с облаком через зашифрованные каналы.
Особое внимание в отчёте уделено Custom Script Extension — одному из встроенных механизмов Azure Arc, который позволяет загружать и выполнять произвольные PowerShell- или Bash-скрипты на подключённом устройстве. Это превращает Arc в полноценный канал удалённого исполнения кода, а если учесть, что агент работает от имени SYSTEM, злоумышленник может легко повысить привилегии. Примеры выполнения скриптов, приведённые в исследовании, демонстрируют создание файлов, получение системной информации и выполнение сетевых команд.
Функциональность расширений Arc также поддерживает сценарии загрузки скриптов с внешних ресурсов, включая GitHub и Azure Storage, что делает возможным динамическое управление командами без необходимости постоянного присутствия на целевой машине.
С точки зрения защиты, исследование содержит ряд рекомендаций. В частности, для обнаружения использования Azure Arc предлагается мониторинг активности процессов
Отдельно подчёркивается, что Custom Script Extension после первичной настройки используется крайне редко, и его повторная активация может свидетельствовать о компрометации. Также упоминается, что хотя Azure логирует сам факт создания или обновления расширения, содержимое выполняемого скрипта в логах не сохраняется — его придётся извлекать с целевого хоста вручную.
Энди Гилл также обратил внимание на возможность взаимодействия с Arc-ресурсами через REST API. Такой подход позволяет запускать команды без зависимости от хранилищ и без явных индикаторов на стороне клиента, что значительно повышает скрытность операций.
Azure Arc, как и многие другие корпоративные сервисы, на практике оказывается двуликим инструментом: при неправильной конфигурации или при наличии у злоумышленника минимального доступа он может использоваться для скрытого контроля над машинами в гибридной инфраструктуре. Это поднимает важный вопрос: достаточно ли средств мониторинга у организаций для отслеживания таких «законных» каналов взаимодействия?
Функция удалённого управления Azure Arc , предназначенная для централизации администрирования гибридной инфраструктуры, неожиданно оказалась полезной не только администраторам и DevOps-командам. Исследование , опубликованное специалистом по безопасности Энди Гиллом, продемонстрировало, как с её помощью можно развернуть полноценный канал командования и управления (C2) в обход традиционных средств обнаружения.
Сервис Azure Arc был представлен ещё в ноябре 2019 года, но оставался вне поля зрения большинства специалистов по безопасности до недавнего времени. Его основное назначение — управление инфраструктурой за пределами Azure, включая физические серверы, виртуальные машины и кластеры Kubernetes, находящиеся как в других облаках, так и в локальных ЦОДах. Визуально и логически подключённые системы отображаются в интерфейсе Azure и управляются как родные ресурсы. Однако именно это свойство стало привлекательным для атакующих.
Злоумышленник, получивший права локального администратора на целевой машине и доступ «Contributor» в соответствующем ресурсе Azure, может использовать Arc для регистрации устройства и установки агента. Эта процедура стандартна и не вызывает подозрений: достаточно сгенерировать скрипт через Azure Portal, запустить его на целевом хосте и авторизоваться через браузер. В результате, устройство появляется на панели управления Azure, где к нему можно применять различные «расширения» — в том числе и встроенный SSH-агент.
Подключение к машине осуществляется прямо через Azure Cloud Shell или CLI, а выполнение команд происходит от имени пользователя, указанного при подключении. При этом никакого дополнительного вредоносного ПО не требуется: все действия осуществляются с помощью легитимного агента Microsoft, прошедшего авторизацию и взаимодействующего с облаком через зашифрованные каналы.
Особое внимание в отчёте уделено Custom Script Extension — одному из встроенных механизмов Azure Arc, который позволяет загружать и выполнять произвольные PowerShell- или Bash-скрипты на подключённом устройстве. Это превращает Arc в полноценный канал удалённого исполнения кода, а если учесть, что агент работает от имени SYSTEM, злоумышленник может легко повысить привилегии. Примеры выполнения скриптов, приведённые в исследовании, демонстрируют создание файлов, получение системной информации и выполнение сетевых команд.
Функциональность расширений Arc также поддерживает сценарии загрузки скриптов с внешних ресурсов, включая GitHub и Azure Storage, что делает возможным динамическое управление командами без необходимости постоянного присутствия на целевой машине.
С точки зрения защиты, исследование содержит ряд рекомендаций. В частности, для обнаружения использования Azure Arc предлагается мониторинг активности процессов
azcmagent.exe, himds.exe и CustomScriptHandler.exe, отслеживание подключений к доменам *.arc.azure.com и *.guestconfiguration.azure.com, а также анализ изменений в системных каталогах и реестре Windows. Кроме того, автор предлагает набор правил для Splunk и Elastic, нацеленных на аномальное использование Arc-агентов и подозрительные дочерние процессы. Отдельно подчёркивается, что Custom Script Extension после первичной настройки используется крайне редко, и его повторная активация может свидетельствовать о компрометации. Также упоминается, что хотя Azure логирует сам факт создания или обновления расширения, содержимое выполняемого скрипта в логах не сохраняется — его придётся извлекать с целевого хоста вручную.
Энди Гилл также обратил внимание на возможность взаимодействия с Arc-ресурсами через REST API. Такой подход позволяет запускать команды без зависимости от хранилищ и без явных индикаторов на стороне клиента, что значительно повышает скрытность операций.
Azure Arc, как и многие другие корпоративные сервисы, на практике оказывается двуликим инструментом: при неправильной конфигурации или при наличии у злоумышленника минимального доступа он может использоваться для скрытого контроля над машинами в гибридной инфраструктуре. Это поднимает важный вопрос: достаточно ли средств мониторинга у организаций для отслеживания таких «законных» каналов взаимодействия?