Стежити 
Detection stack
- AIDR
- Alert
- ETL
- Query
Резюме
Фішингова кампанія, що маскується під DHL, розроблена для викрадення облікових даних користувачів. Ланцюжок атаки використовує підроблену сторінку одноразового пароля та брендований портал входу, а потім ексфільтрує захоплені дані через EmailJS. Після викрадення облікових даних жертви перенаправляються на легітимний сайт DHL, щоб зменшити підозру. Операція, здається, націлена на споживачів у всьому світі, використовуючи відносно легку інфраструктуру.
Розслідування
Компанія Forcepoint X-Labs вивчила фішинговий електронний лист, зловмисні посилання та JavaScript, відповідальний за генерування клієнтського OTP. Їх аналіз показав, що фішинговий набір збирав дані про пристрій та геолокацію перед передачею зібраної інформації на поштову скриньку під контролем атакуючого через EmailJS. Дослідникам вдалося відтворити повний потік атаки в середовищі пісочниці.
Пом’якшення Наслідків
Організації повинні блокувати підозрілі домени відправників та стежити за невідповідностями вирівнювання DKIM, які можуть свідчити про підробку. Команди безпеки також повинні фільтрувати або блокувати URL-адреси, що вирішуються в ідентифіковані зловмисні домени. Моніторинг неочікуваної активності EmailJS з незвичайними навантаженнями може допомогти виявити спроби викрадення облікових даних, тоді як впровадження MFA на акаунтах, пов’язаних з DHL, додає ще один шар захисту.
Реакція
Захисники повинні повідомити цільових користувачів про фішингову кампанію та вимагати скидання пароля для будь-яких зламаних облікових записів. Зловмисний електронний лист повинен бути поміщений у карантин, а пов’язані домени повинні бути заблоковані на рівнях поштових та веб-шлюзів. Правила виявлення також повинні бути оновлені для виявлення спостережуваних зразків URL-адрес та методу ексфільтрації на базі EmailJS.
graph TB %% Class Definitions classDef action fill:#99ccff classDef technique fill:#ffcc99 %% Nodes phishing_email[“<b>Дія</b> – <b>T1566 Фішинг</b><br/><b>Опис</b>: Надсилання шкідливих електронних листів, що виглядають легітимними, щоб заманити жертв.<br/><b>Підтехніка</b>: Підміна електронної пошти (T1672)”] class phishing_email action fake_otp_page[“<b>Дія</b> – <b>T1656 Імітація</b> та <b>T1001.003 Імітація протоколу</b><br/><b>Опис</b>: Розміщення підробленої сторінки одноразового пароля, що імітує цільовий сервіс.”] class fake_otp_page action gather_email[“<b>Техніка</b> – <b>T1589 Збір ідентифікаційної інформації жертви</b><br/><b>Опис</b>: Захоплення електронної адреси жертви з підробленої сторінки.”] class gather_email technique browser_discovery[“<b>Техніка</b> – <b>T1217 Виявлення інформації браузера</b> та <b>T1596.005 Пошук у відкритих технічних базах даних</b><br/><b>Опис</b>: Визначення даних браузера, пристрою та ОС середовища жертви.”] class browser_discovery technique credential_harvest[“<b>Дія</b> – <b>T1056.003 Захоплення через веб-портал</b><br/><b>Опис</b>: Перенаправлення жертви на веб-портал збору облікових даних.”] class credential_harvest action exfil_emailjs[“<b>Техніка</b> – <b>T1114 Збір електронної пошти</b> та <b>T1102.002 Двосторонній зв’язок через веб-сервіс</b><br/><b>Опис</b>: Використання EmailJS для ексфільтрації облікових даних і даних сесії.”] class exfil_emailjs technique legit_redirect[“<b>Дія</b> – Перенаправлення жертви на легітимний сайт DHL після ексфільтрації даних.”] class legit_redirect action %% Connections phishing_email –>|leads_to| fake_otp_page fake_otp_page –>|collects| gather_email fake_otp_page –>|collects| browser_discovery gather_email –>|provides| credential_harvest browser_discovery –>|provides| credential_harvest credential_harvest –>|exfiltrates| exfil_emailjs exfil_emailjs –>|final_redirect| legit_redirect
Потік Атаки
Детекції
## Виконання симуляції
Передумова: перевірка телеметрії та базового проекту повинна завершитися успішно.
Обґрунтування: цей розділ детально описує точне виконання техніки супротивника (TTP), розробленої для ініціювання правила виявлення. Команди та наратив МАЮТЬ точно відображати ідентифіковані TTP та прагнути генерувати точну телеметрію, яка очікується від логіки виявлення.
-
Наратив та команди атаки:
Суперник, що прагне зібрати облікові дані DHL, підроблює
cupelva.comдомен (відомий схожий) і створює електронний лист з точною темою, використаною в останніх кампаніях. Надіславши цей лист через зламаний зовнішній SMTP-сервер, лист досягає поштових скриньок Exchange, створюючи журнали транспорту, які відповідають критеріям правила. -
Сценарій тестування регресії:
# Симульований фішинговий електронний лист – повинен ініціювати правило виявлення $smtpServer = "smtp.malicious-host.com" # зламаний зовнішній сервер $msg = @{ From = "dhl@cupelva.com" To = "victim@contoso.com" Subject = "DHL EXPRESS WAYBILL CONFIRMATION REQUIRED" Body = @" Dear Customer,
Транспортна накладна для вашої недавньої відправки потребує підтвердження. Будь ласка, натисніть на посилання нижче, щоб перевірити свої дані:
https://malicious.example.com/verify
Regards, DHL Express “@ SmtpServer = $smtpServer } Send-MailMessage @msg
- **Команди очищення:**
powershell
# Видалити тестовий електронний лист із скриньки жертви (Exchange PowerShell)
Import-Module ExchangeOnlineManagement
Connect-ExchangeOnline -UserPrincipalName admin@contoso.com
Search-Mailbox -Identity "victim@contoso.com" -SearchQuery 'Subject:"DHL EXPRESS WAYBILL CONFIRMATION REQUIRED"' -DeleteContent
Disconnect-ExchangeOnline -Confirm:$false## Оцінка обходу та рекомендації щодо впровадження
| Потенційна техніка обходу | Ймовірність | Вплив на правило | Пом’якшення Наслідків |
|---|---|---|---|
| Змінити тему (наприклад, додати пробіли, змінити регістр) | Висока | Правило проґавлює подію | Використовуйте регекс, чутливий до регістру, та нечітке ключове слово (subject|contains|regex: "DHLs+EXPRESS.*WAYBILL.*REQUIRED"). |
Використовуйте інший підроблений домен (наприклад, dhl-express.co) |
Висока | Правило проґавлює подію | Внедрити виявлення відмов DKIM/SPF і шукати брендові ключові слова, незалежно від домену відправника. |
| Вбудувати зловмисне посилання, але залишити тему незмінною | Середня | Правило все ще активується (добре) | Додати перевірку репутації URL для підвищення впевненості. |
| Надіслати як вкладення (T1192), а не в тілі | Low | Правило не змінюється (тема все ще відповідає) | Розширити правило для перевірки метаданих вкладення (імена файлів, MIME-типи). |
Рекомендації
- Розширена оцінка відправника: Замість одного жорстко закодованого домену позначайте будь-який електронний лист, що не відповідає вирівнюванню SPF/DKIM для бренду “dhl.com” і містить ключові слова, пов’язані з DHL.
- Нечітке співставлення теми: Замініть точну відповідність рядка на регекс, що захоплює варіації, відмінності реєстру і загальні заплутаності.
- Збагачення репутацією URL: Аналізуйте тіло повідомлення на наявність URL; позначте, якщо будь-яке посилання веде до відомого зловмисного хоста або використовує скорочення URL.
- Додати евристику вкладень: Коли правило позначає
attack.t1192, інтегруйте перевірки на файли з подвійними розширеннями або скриптами, які зазвичай використовуються в фішингу, пов’язаному з DHL.
Впровадження цих кроків закріплення підвищить оцінку витривалості до 4–5, знижуючи ризик простого обходу, зберігаючи при цьому низький рівень хибно-позитивних результатів.