Microsoft как C2: когда корпоративное облако начинает работать на атакующегоПост имеет ознакомительный характер и предназначена для специалистов по безопасности. Автор и редакция не несут ответственности за любой вред, причиненный с применением изложенной информации. Распространение вредоносных программ, нарушение работы систем и нарушение тайны переписки преследуются по закону
Когда говорят про C2, в голове обычно возникает VPS, домен с подозрительным именем, HTTPS на нестандартном порту и какой-нибудь Beacon.
Пища для размышления, а не инструкция по построению C2 или эксплуатации Microsoft-инфраструктуры. Иногда самый интересный инструмент атакующего, тот, который уже установлен у администратора.
OneDrive / SharePoint 🔫
Идея проста:агент получает данные из облачного хранилища → выполняет действие → отправляет результат обратно.
При этом сетевой трафик выглядит как обычная работа с Microsoft 365.
Для исследования API можно встретить вполне штатные команды:
Connect-MgGraph -Scopes "Files.Read.All"
Get-MgDrive
Get-MgDriveChildItem -DriveId -DriveItemId
И вот здесь начинается интересная для SOC часть: важен не сам Microsoft Graph, а
кто, откуда и зачем им пользуется.
Например, PowerShell → Graph API → массовое чтение файлов с необычного хоста уже выглядит совсем иначе.
Microsoft Graph 🧐
Graph особенно интересен тем, что это огромный API для Microsoft 365.
Через него легитимные приложения работают с пользователями, группами, файлами, Teams и другими объектами.
Для атакующего это потенциально удобный канал связи, потому что запросы идут к Microsoft API, а не к VPS.
Connect-MgGraph
Get-MgContext
Get-MgUser -Top 5
В реальном инциденте интерес представляют аномалии:
один пользователь внезапно начинает работать с API с нового IP, приложение получает необычные OAuth-разрешения, появляется массовое обращение к Graph или меняется характер запросов.
Microsoft Defender отдельно выделяет подозрительную активность через Entra Graph API как возможный C2-индикатор.
Azure Storage 🍩
Для корпоративной сети обращение к Azure выглядит максимально обыденно. Более того, Microsoft сама использует Azure для компонентов Configuration Manager и других облачных сценариев.
В атаке хранилище может использоваться как условная «почтовая ячейка»:
файл появился → клиент забрал → обработал → положил результат.
Azure CLI:
az login
az storage container list --account-name
Посмотреть доступы текущего пользователя:
az role assignment list --all
или проверить назначения конкретного субъекта:
az role assignment list \
--assignee \
--all
Поэтому обнаруживать нужно не сам az.exe, а контекст его использования.
Azure Run Command 🧛
Здесь мы уже переходим от транспорта к удалённому выполнению.
Azure предоставляет штатный механизм Run Command, позволяющий администраторам выполнять команды на виртуальных машинах через установленный VM Agent.
В нормальной работе это выглядит примерно так:
az vm run-command invoke `
--resource-group `
--name `
--command-id RunPowerShellScript `
--scripts "Get-Date"
А теперь SCCM 🤹
Configuration Manager изначально умеет доставлять файлы на рабочие станции и запускать их через механизм Package/Program.
Например, администратор создаёт пакет:
New-CMPackage `
-Name "Test Application" `
-Path "\\SCCM-SRV\Packages\TestApp"
Затем создаём Program, который должен запустить EXE:
New-CMProgram `
-PackageName "Test Application" `
-StandardProgramName "Install" `
-CommandLine "test.exe" `
-RunMode RunWithAdministrativeRights `
-UserInteraction $false
И после этого пакет можно отправить на коллекцию компьютеров:
New-CMPackageDeployment `
-PackageName "Test Application" `
-ProgramName "Install" `
-CollectionName "Test Workstations" `
-StandardProgram `
-DeployPurpose Required
И именно здесь SCCM становится интересным с точки зрения Red Team.
Если атакующий получает контроль над учётной записью, которой разрешено создавать или изменять deployments, ему потенциально не требуется отдельно подключаться к каждой рабочей станции.
Он может использовать уже существующий механизм управления инфраструктурой.
Вместо:
Attacker → PC01
Attacker → PC02
Attacker → PC03
...
Вывод 😛
Главная мысль здесь даже не в SCCM, Azure или Microsoft 365.
Интерес представляет сама идея:
для C2 и удалённого управления не всегда нужен собственный сервер и неизвестный сетевой протокол.В инфраструктуре уже есть десятки сервисов, которым разрешено общаться друг с другом, выполнять административные действия и передавать данные. Надо дать волю фантазии...
Как обычно, букв получилось больше, чем хотелось ☕️
ГАЗ 10 лайков, и сделаем большой лсит по легитимным утилитам, которые можно встретить на хостах. Windows, AD, PowerShell, LOLBins, Microsoft, Azure, SCCM и ещё куча интересного и легитимного.
Думайте, подписаться!
