Як Storm-2949 перетворив скомпрометовану ідентичність у хмарне порушення

Резюме

Storm-2949 використовував соціальну інженерію та зловживання самостійно виконуваним скиданням пароля для компрометації облікових записів Microsoft Entra ID. Після отримання привілейованого доступу загрозливий актор використовував дії з управління Azure для доступу до Сервісів додатків, Key Vaults, облікових записів зберігання та SQL баз даних. Дані були ексфільтровані з Microsoft 365, сховищ Azure та інших хмарних ресурсів. Пізніше вторгнення прогресувало до розгортання інструменту віддаленого доступу ScreenConnect на віртуальних машинах для подальшої розвідки та крадіжки облікових даних.

Розслідування

Аналітики Microsoft спостерігали, як нападники перелічують користувачів та програми за допомогою Microsoft Graph API з допомогою користувацьких інструментів Python. Вони отримували профілі публікацій з Azure App Services, вилучали секрети з Key Vaults, змінювали правила брандмауера та використовували розширення VMAccess для створення облікових записів локального адміністратора на віртуальних машинах. На пізньому етапі PowerShell скрипт встановлював ScreenConnect, очищував журнали та маскував сервіси, щоб зменшити видимість. Розслідування зв’язало цю активність з трьома IP-адресами, які контролюються нападниками.

Захист

Організації повинні активувати MFA та вимагати аутентифікацію, стійку до фішингу, для привілейованих облікових записів. Дозволи Azure RBAC мають бути суворо обмежені та контролюватися, особливо доступ рівня Owner до Key Vaults та App Services. Непотрібні розширення Azure VM мають бути вимкнені, а журнали мають бути активовані для Run Command та VMAccess активності. Microsoft Defender for Cloud та Defender for Endpoint також повинні бути активовані з захистом від втручання та блокуючим режимом.

Відповідь

Захисники повинні негайно заблокувати визначені шкідливі IP-адреси та відкликати скомпрометовані облікові дані. Паролі та реєстрації MFA для уражених облікових записів повинні бути скинуті, і всі секрети, що зберігаються в Key Vaults, мають бути обернуті. Команди безпеки також повинні провести повний перегляд призначень Azure RBAC та видалити надмірні привілеї. Правила виявлення мають бути оновлені, щоб визначати підозрілі запити профілів публікації, доступ до секретів Key Vault та неочікувану активність розширень VM.

Виконання симуляції

Передумова: Перевірки телеметрії та базових даних повинні бути успішними.

• Наратив атаки та команди:

  Супротивник, який отримав дійсний обліковий запис Azure AD (або стандартний об‘єкт обслуговування), хоче ексфільтрувати вихідний код додатка та знімки бази даних. Атакувальник виконує наступні кроки виключно за допомогою Azure CLI, генеруючи точні назва операції події, які відстежує правило:

  1. Публікація XML конфігурації веб-додатка – вилучає конфігурацію веб-додатка (включаючи облікові дані для розгортання).
  2. Створіть новий обліковий запис зберігання – забезпечує контейнер для етапу ексфільтрованих даних.
  3. Додайте правило брандмауера до SQL-сервера – відкриває сервер для діапазону IP-адрес атакуючого, що дозволяє пряме копіювання даних.

  Кожен крок створює запис у журналі активності з назва операції відповідає списку дозволених правил, що призводить до спрацьовування виявлення.

• Скрипт тесту на регресію:

  #!/usr/bin/env bash
  # Передумова: az CLI увійшов у систему з компрометованим/дійсним Azure AD об'єктом.
  set -euo pipefail
  
  # Змінні - змініть за потребою для тестового аренда
  RG="test-rg-$(date +%s)"
  WEBAPP="test-webapp-$RANDOM"
  STORAGE="teststorage$RANDOM"
  LOCATION="eastus"
  SQLSERVER="testsql$RANDOM"
  MY_IP=$(curl -s https://api.ipify.org)
  
  echo "=== Створити ресурсну групу ==="
  az group create --name "$RG" --location "$LOCATION"
  
  echo "=== Розгорніть тестовий веб-додаток ==="
  az appservice plan create --name "${WEBAPP}Plan" --resource-group "$RG" --sku B1 --is-linux
  az webapp create --resource-group "$RG" --plan "${WEBAPP}Plan" --name "$WEBAPP"
  
  echo "=== Публікація XML конфігурації (тригер виявлення) ==="
  az webapp config backup create 
      --resource-group "$RG" 
      --webapp-name "$WEBAPP" 
      --backup-name "xmlbackup-$(date +%s)" 
      --output none
  
  echo "=== Створити обліковий запис зберігання (тригер виявлення) ==="
  az storage account create 
      --name "$STORAGE" 
      --resource-group "$RG" 
      --location "$LOCATION" 
      --sku Standard_LRS 
      --kind StorageV2 
      --output none
  
  echo "=== Створити SQL-сервер (потрібно для правила брандмауера) ==="
  az sql server create 
      --name "$SQLSERVER" 
      --resource-group "$RG" 
      --location "$LOCATION" 
      --admin-user "sqladmin" 
      --admin-password "P@ssw0rd1234!" 
      --output none
  
  echo "=== Додати правило брандмауера до SQL-сервера (тригер виявлення) ==="
  az sql server firewall-rule create 
      --resource-group "$RG" 
      --server "$SQLSERVER" 
      --name "AllowMyIP" 
      --start-ip-address "$MY_IP" 
      --end-ip-address "$MY_IP" 
      --output none
  
  echo "=== Симуляція завершена. Перевірте Azure Sentinel для сигналів тривоги. ==="

• Команди для очищення:

  #!/usr/bin/env bash
  set -euo pipefail
  
  # Змінні повинні відповідати тим, що використовувалися в сценарії симуляції
  RG="test-rg-..."
  # Якщо ви зберегли точні назви з попереднього виконання, замініть відповідно заповнювачі.
  
  echo "=== Видалення ресурсної групи і всіх містять ресурсів ==="
  az group delete --name "$RG" --yes --no-wait
  echo "Очищення розпочато."