Фішери використовують менеджер бізнес-акаунтів Meta

Резюме

Невідомий суб’єкт загрози зловживає легітимною службою менеджера бізнесу Meta для доставки дуже переконливих фішингових електронних листів. Повідомлення використовують змінену назву компанії, яка містить URL-адресу, заохочуючи цільовий сегмент відвідувати фішингові сайти або взаємодіяти з чатботами Facebook Messenger. Кампанія призначена для викрадення облікових даних облікового запису Meta, кодів двофакторної автентифікації (MFA) і документів, що підтверджують особу.

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

Huntress проаналізував ланцюжок атак після виявлення фішингового електронного листа в капкані у червні 2026 року. Розслідування показало перехід від раніших методів перенаправлення через Google Sites до більш удосконаленого підходу, використовуючи чатботів Facebook Messenger і фішингові сторінки з інтегрованими iFrame. Дослідникам також вдалося відстежити діяльність ексфільтрації через такі домени, як api.goautolink.com і пов’язані з цим боти Telegram.

Пом’якшення

Meta впровадила технічні засоби контролю, які блокують бізнес-акаунти, що намагаються використовувати URL-адреси в назвах компаній. Користувачам слід залишатися пильними у разі неочікуваних запитів на партнерство з бізнесом та ретельно перевіряти будь-які пов’язані ресурси. Уникання підозрілих посилань в електронних листах, навіть коли відправник виглядає легітимним, залишається ключовою лінією оборони.

Реакція

При виявленні підозрілих запитів на партнерство з бізнесом адміністратори повинні підтвердити їх легітимність через офіційні канали Meta. Якщо облікові дані або документи, що підтверджують особу, скомпрометовані, мають бути негайно вжиті дії щодо відновлення акаунта та скидання MFA. Організації також повинні контролювати облікові записи Meta Business Manager для виявлення будь-якого несанкціонованого доступу або змін.

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

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

Обґрунтування: Цей розділ детально описує точне виконання техніки противника (TTP), призначеної для запуску правила виявлення. Команди та розповідь МАЮТЬ безпосередньо відображати виявлені TTP і спрямовані на генерацію точної телеметрії, очікуваної логікою виявлення. Абстрактні або не пов’язані приклади призведуть до неправильної діагностики.

• Опис атаки та команди: Суб’єкт загрози надіслав фішинговий електронний лист, що маскується під повідомлення про менеджера бізнесу Meta. Щоб автоматизувати тестування свого фішингового посилання або збирати інформацію з цільової сторінки за допомогою локалізованого сценарію, зловмисник виконує сценарій PowerShell. Цей скрипт містить закодовані шкідливі URL-адреси: sites.google.com/view/profile1012 and aussiecleaningservices.com. Коли скрипт виконується, PowerShell engine записує вміст блоку скрипта, що містить ці рядки, тим самим викликаючи правило виявлення.

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

  # Симуляційний скрипт для активації правила виявлення шляхом включення шкідливих URL-адрес у блок скрипта.
  $maliciousUrl1 = "https://sites.google.com/view/profile1012"
  $maliciousUrl2 = "http://aussiecleaningservices.com/login"
  
  Write-Host "Імітація обробки фішингових посилань..."
  $testString = "Обробка посилань: $maliciousUrl1 та $maliciousUrl2"
  Write-Output $testString

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

  # Ніяких постійних змін в системі не зроблено; очищення не вимагається.
  # Якщо були створені файли транскрипції, видаліть їх:
  # Remove-Item C:Users<User>DocumentsPowerShell_Transcript.txt -ErrorAction SilentlyContinue