Аналіз кампанії Blinder Tunnel: Тактики, техніки та інфраструктура

Резюме

Державний актор загрози, пов’язаний з Іраном, проводить кампанію Blinder Tunnel проти організацій критичної інфраструктури на Близькому Сході. Зловмисники використовують соціальну інженерію, видаючи себе за аеропорти Дубаю для розповсюдження небезпечних проектів Visual Studio. Ці проекти зловживають вбудованими інструментами розробника для розгортання спеціального шкідливого програмного забезпечення, включаючи ShelbyLoader V2 та утиліти тунелювання Blackwood, використовуючи інфраструктуру командування і керування на базі GitHub.

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

Дослідники Unit 42 відстежили діяльність від підготовки інфраструктури в кінці 2025 року до активного націлювання, яке спостерігалося у 2026 році. Розслідування виявило багатоступеневий ланцюг зараження із захопленням AppDomainManager і завантаженням DLL. Аналіз шкідливого програмного забезпечення також виявив використання GitHub API для C2 зв’язку і dead-drop резолверів, а також тематичний стиль і брендування, натхненний серіалом Peaky Blinders.

Пом’якшення

Організаціям слід зміцнювати середовища розробників та відслідковувати підозріле виконання довірених утиліт, таких як msbuild.exe. Введення строгих правил завантаження DLL і виявлення неочікуваних або нестандартних DLL у системних каталогах може зменшити ризик атаки. Команди з безпеки також повинні розгортати передові рішення для захисту кінцевих точок, здатні виявити виконання в пам’яті та несанкціоновану активність PowerShell.

Відповідь

Коли виявлена підозріла активність, організаціям слід ізолювати уражені кінцеві точки та розпочати скидання паролів. Команди з безпеки повинні перевірити телеметрію визначення і реагування на кінцевих точках (EDR) для виявлення ненормальної поведінки процесів, особливо ознак захоплення легітимних процесів. Дослідники також мали б переглянути несанкціоновані з’єднання з публічними хмарними сервісами, такими як GitHub, для виявлення незвичайних або нестандартних шаблонів трафіку.

Виконання моделювання

• Історія атаки та команди: Противник ініціює фішингову кампанію. Жертва отримує електронний лист, який виглядає як спільний документ від Google Cloud. Коли жертва клацає на посилання, їхній браузер виконує GET-запит до https://cloud.g-drive.cam/login/auth. Цей запит фіксується корпоративним проксі-сервером, що має запустити правило виявлення на основі присутності шкідливого домену в URL.

• Сценарій регресійного тестування:

  # Сценарій моделювання для запуску правила виявлення шляхом запиту фішингового домену.
  # Це моделює користувача, що клацає на посилання у фішинговому електронному листі.
  
  $PhishingUrl = "https://cloud.g-drive.cam/auth/login?user=victim"
  Write-Host "Моделюється з’єднання з фішинговим доменом: $PhishingUrl"
  
  try {
      # Ми використовуємо -ErrorAction SilentlyContinue оскільки домен фактично не існує,
      # але DNS-запит і спроба підключитися сформують лог проксі.
      Invoke-WebRequest -Uri $PhishingUrl -Method Get -UseBasicParsing -ErrorAction SilentlyContinue
      Write-Host "Спроба з'єднання завершена. Перевірте SIEM для логів проксі."
  }
  catch {
      Write-Host "З’єднання не вдалося як очікувалося (домен, ймовірно, не існує), але телеметрія має бути створена."
  }

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

  # Постійні зміни в систему не вносяться. 
  # Для очищення локального веб-кешу, якщо це необхідно:
  Clear-History
  Write-Host "Очищення моделювання завершено. Немає залишків на вузлі."