IOC_Zebrocy_181018
#IOC #OptiData #VR #Zebrocy #APT28 #xmltarget #W97M
Чим відрізняються цільові атаки від масових розсилок? І чому не можна одразу відкривати чергове приєднання?
Давайте розглянемо інцидент який стався вчора (18/10/18).
Мова йтиме про застосування #Zebrocy – троянське ПЗ, яке застосовується для крадіжки інформації славнозвісною групою зловмисників Sednit, також відомі як APT28 або Fancy Bear або Sofacy або STRONTIUM.
#1 Лист
Як завжди, усе починається з фейкового листа. З першого погляду пересічному користувачеві важко зрозуміти чому не можна відкривати приєднання.
Щоб було легше, нагадую про “50 відтінків фішингу“, зокрема правило 30 секунд.
Придивіться уважніше – скринька на безкоштовному Webmail I.UA підібрана таким чином, щоб скидатися на mfa.gov.ua – домен Міністерства закордонних справ України.
Претекст (зміст) листа має політичне забарвлення – окупований Крим та усе що з ним пов’язано має бути важливим для адресата-жертви.
Враження трохи псує реклама у підписі, але враховуючи той факт, що багато працівників вітчизняних компаній користуються особистими скриньками – жертву це не насторожить.
Візьміть до уваги також той факт, що на відміну від масових неперсоналізованих розсилок, даний лист був надісланий одній конкретній людині.
А якщо поглянути на лист так?
#2 Приманка
Якщо жертва дала ввести себе в оману та відкрила документ із приєднання на неї чекає неприємний сюрприз – docx файл
SHA-256 c20e5d56b35992fe74e92aebb09c40a9ec4f3d9b3c2a01efbe761fa7921dd97f
File name 1500029.docx
File size 11.4 KB
містить ресурсне посилання на зовнішній об’єкт:
Якщо трафік MS Office не контролюється і процесу Winword дозволено виходити в Інтернет відбувається завантаження другої частини – шаблону з двома макросами:
Другий документ
SHA-256 86bb3b00bcd4878b081e4e4f126bba321b81a17e544d54377a0f590f95209e46
File name Note_template.dotm
File size 401 KB
містить макрос та основну частину кодовану у Base64:
Особливість другого документу – один з макросів активується не одразу, при відкритті документу, а після того як жертва закриє другий документ.
Така схема не нова, проте мені траплялася досить рідко.
Для жертви усе проходить майже непомітно – ось тільки відкриває приєднання, одразу завантажується другий документ який демонструє звичне прохання активувати макроси:
Якщо жертва активує макроси (або ж їх запуск не блокований, як у більшості фінансових працівників) тоді перший макрос покаже чисту сторінку.
Це примусить жертву врешті-решт закрити документ. Щойно це буде зроблено – активується другий макрос, який декодує, запише на диск та запустить payload:
Отже схема атаки виглядає наступним чином:
email attach .docx > xml.rels > GET .dotm > macro > %user%\AppData\Roaming\Network\~office.exe
Зверніть увагу – шлях за яким декодується та записується перший запускний файл задано жорстко в коді макросу (!)
#3 Основна частина
Як видно із схеми процесів, перший запускний файл збирає та надсилає інформацію про систему (sysinfo + tasklist)
SHA-256 c91843a69dcf3fdad0dac1b2f0139d1bb072787a1cfcf7b6e34a96bc3c081d65
File name ~office.exe
File size 353.5 KB
C2 #1 = 185.203.118.198/en_action_device/center_correct_customer
Після збору інформації відбувається запуск другої частини, яка відповідає за закріплення та отримання команд
SHA-256 074a5836c5973bb53ab02c2bad66a4743b65c20fd6bf602cfaf09219f32d2426
File name mslicsrv.exe (mcrthost.exe)
File size 164 KB
C2 #2 = 138.204.170.189:443
В кінцевому результаті скомпрометована система виглядає так:
Для кращого відображення ось граф зв’язків по процесам:
#4 Маркери
Інфікована система ініціює наступний перелік мережевих з’єднань:
185.203.118.198 OPTIONS /documents/ HTTP/1.1 Microsoft Office Protocol Discovery – Winword, перевірка джерела
185.203.118.198 OPTIONS / HTTP/1.1 Microsoft-WebDAV-MiniRedir/6.1.7601 – Winword, перевірка джерела
185.203.118.198 GET /documents/Note_template.dotm HTTP/1.1 Mozilla/4.0 – Winword, завантаження шаблону
185.203.118.198 HEAD /documents/Note_template.dotm HTTP/1.1 Microsoft Office Existence Discovery – Winword, завантаження шаблону
185.203.118.198 POST /en_action_device/center_correct_customer/drivers-i7-x86.php?tbm=AC38D1C7 HTTP/1.0 (application/x-www-form-urlencoded) Mozilla v5.1 – ~office.exe, передача зібраної інформації (sysinfo + tasklist)
Передача “відбитків” інфікованої системи:
Завдяки @Jan0fficial отримуємо розуміння як це виглядає без обфускації:
По процесам спостерігаємо наступну картину:
WINWORD.EXE 185.203.118.198:80 – Winword, перевірка джерела
svchost.exe 185.203.118.198:80 – завантаження шаблону
~office.exe 185.203.118.198:80 ~office.exe, передача зібраної інформації (sysinfo + tasklist)
mslicsrv.exe 138.204.170.189:443 – з’єднання із С2 після закріплення
# # #
Більше маркерів (чорновик звіту) за посиланням:
https://pastebin.com/sXcERsQd
За допомогу в ідентифікації зразка дякую @Techhelplistcom
За деобфускацію дякую @Jan0fficial
#5 Контрзаходи та висновки
Контрзаходи:
- Контролюйте/блокуйте трафік для додатків MS Office
- Блокуйте на Proxy нетипові User Agent
- Блокуйте запуск макросів
- Забороняйте/контролюйте створення .exe у C:\Users\
Висновки:
- Лист було складено дуже обережно щоб не відлякати жертву
- Схема доставки навмисно обходить скрипти та powershell – розрахунок на часту роботу з макросами
- payload зашитий в другий документ – так надійніше, ніж розміщувати exe на зовнішніх джерелах
- Запуск інфікування не потребує підвищених привілеїв
- Навіть якщо закріплення з тих чи інших причин не відбудеться – зловмисники отримають “відбитки” системи = накопичення даних для наступних атак
- Персонал потрібно вчити розпізнавати фішинг
- Сигнатурного антивірусу не достатньо (елементи атаки на момент контакту мали рейт по VT 2-4/50)
- Для протидії цільовим атакам варто застосовувати рішення класу sandbox
Будьте уважні та обережні.
VR