Archive | February 2019

IOC_digest_01_2019

Продовжуючи формат переднього дайджесту, ось вам перелік зразків, результати аналізу яких я можу оприлюднити:

07/01/19

розсилали #nanocore, .xlsx > 11882 > GET > AppData\Roaming\*.exe, звіт

09/01/19

розсилали #agenttesla, .xlsx > 11882 > GET > AppData\Roaming\*.exe, звіт

10/01/19

розсилали #smokeloader, (lzh) > js > WSH > Powershell > GET > AppData\Local\TempZna40.exe, звіт

розсилали #LokiBot, .doc(RTF) > 11882 > GET .jpg > %temp%\1.exe , звіт

10/01/19

розсилали #smokeloader, (lzh) > js > WSH > GET > AppData\Roaming\Microsoft\Windows\Templates\*.exe, звіт

14/01/19

розсилали #shade, .ZIP > 2nd .ZIP > JS > WSH > GET > %temp%\*.tmp , звіт

15/01/19

розсилали #shade, .ZIP > 2nd .ZIP > JS > WSH > GET *.jpg > %temp%\*.tmp , звіт

23/01/19

розсилали #emotet, .doc (XML) > macro > cmd > powershell > GET > %temp%\***.exe, звіт

28/01/19

розсилали #emotet, .doc (XML) > macro > cmd > powershell > GET > %temp%\***.exe, звіт

– – – – – – – – – – – – – – – – – – – – – – – –

Аналітика

Методи доставки

Для обходу фільтрів застосовували наступні трюки

Якщо розбити по категоріям, тоді отримаємо

Тенденції

Масова кампанія з розсилки #shade яка розпочалася ще в кінці 2018 року продовжувала застосовувати подвійні архіви із скриптами (WSH).

Поки що, документи із вразливістю редактору формул разом із макросами залишаються основним інструментом компрометації  робочих станцій.

Загалом, вищеописані зразки могли створити інциденти тим організаціям які:

  • не контролюють макроси
  • не контролюють WSH
  • не королюють запуск powershell
  • не посилили фільтрацію приєднань

Узагальнені контрзаходи

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

VR

Advertisements

Хитрий emotet

Люди, котрі заробляють на життя фішингом/розповсюдженням malware постійно вдосконалюють свої навички.

Ті, хто захищають інформаційні системи, повинні швидко адаптуватися під зміни методів доставки.

 

Сьогодні я розкажу вам про трюк, який дозволяє актуальним приманкам обходити _деякі_ sandbox.

А для тих, хто дочитає до кінця, буде бонусний контент ;)

Вступ

PowerShell вже кілька років є улюбленим помічником зловмисників для завантаження та запуску payload.

З 2017го року, відсоток приманок, що застосовують PowerShell тільки збільшується.

З початком 2019го року я стикнувся з тим, що на одній із моїх тестових машин приманка із макросом не відпрацювала повний цикл.

 

Суть

Отже це був черговий зразок банківського трояну #emotet.

В якості приманки використали XML файл із макросом, який мав передати на powershell інструкції – де взяти payload, куди завантажити і як запустити.

Але під час динамічного виконання послідовність команд дивним чином обривалася:

Я не міг збагнути, чому інфікування не проходить.

Отже я спробував скопіювати перехоплений рядок обфускованих інструкцій і запустити його через cmd вручну:

Виявилося, що виконання математичних операцій із масивами (досить поширений варіант обфускації) саме на цій тестовій системі

призводило до генерування команди із помилкою – ‘powershtll’ замість ‘powershell’:

Через це послідовність атаки і зупинялася.

Що ж, принаймні тепер я мав адреси джерел payload, які одразу ж перевірив:

Вони навіть не приховали payload під виглядом графічного файлу (так як це роблять при розповсюдженні #shade).

Отримавши зразки payload я одразу ж перевірив їх на приналежність конкретного виду за допомогою сервісу INTEZER Analyze:

Але мені не давало спокою, чому ж той скрипт із приманки не відпрацював докінця?

Кілька хвилин моніторингу і я знайшов причину у дописі My Online Security ‏ @dvk01uk

Як виявилося, скрипт не відпрацював через застарілу версію PowerShelll.

Справа у тім, що на Windows 7 PS не оновлюється автоматично.

А інструкції, які були у коді макросу, використовували змінні, котрі не працюють на версіях старіших за 5-ту.

 

Мій трюк (костиль)

Оскільки замовнику необхідно було надати перелік маркерів (IOC) якнайшвидше, я не став витрачати час на заміну тестового середовища

чи оновлення PowerShell.

Ось що я зробив – я знав, що команда обривається через помилку і назві запускного файлу powershell.

Мені потрібен був аліас на powershtll який би викликав powershell.

За допомогою google я згадав про таку корисну функцію як DOSKEY і нашвидкоруч створив аліас:

Це дало мені змогу запустити процес виконання скрипту і отримати результат:

Так, це костиль. І для іншого зразка із зміненою обфускацією він не працюватиме.

Але це дозволило мені вкластися у штатні 40 хв на аналіз зразка і надати замовнику маркери – https://pastebin.com/D9TDts5J.

– – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – – –

Отже мораль цієї історії наступна – подбайте про оновлення ваших тестових ВМ у sandbox

та переконайтеся, що актуальні схеми обфускації відпрацьовують схему інфікування до кінця.

Інакше ви ризикуєте пропустити загрозу і втратити дані із скомпрометованої системи.

Висновки

  • PowerShell і надалі будуть застосовувати для доставки і запуску malware
  • На тестових Windows 7 потрібно оновити PS до 5ї версії
  • Варто очікувати нових способів обфускації
  • Від так необхідно обмежувати запуск вбудованих інструментів Windows для простих користувачів

PS

– – –  // Бонусний контент для уважних та допитливих

McAfee створило непогане відео про #emotet в якому показали як правилами Access Protection вберегти користувачів від зараження

Користуйтеся:

– – –  // Бонусний контент для уважних та допитливих

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

VR