Tag Archive | powershell

malware#2

Невивчені уроки або логи антивірусних війн #2

(першу частину можна почитати тут)

22/02/19 доповідав про наші досягнення у розрізі аналізу malware та методів доставки.

Контент суто технічний. Без прив’язки до конкретних вендорів чи рішень.

Презентацію можна переглянути/взяти тут

Основні тези:

  • зміни по кількості та якості атак
  • актуальні методи інфільтрації систем захисту
  • приклади атак трьох різних рівнів
  • висновки

На прикладі #shade, #emotet та #sobaken пояснив можливі контрзаходи.

Кому зі slideshare не зручно – беріть у вигляді PDF (~1,1 Mb)

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

VR

Advertisements

IOC_digest_04_2019

(Зразки за квітень 2019го)

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

Їх було не так багато, як у березні, проте схеми доставки були досить цікавими.

08/04/19

розсилали #AZORult, .ZIP > .LNK > GET .HTA > PowerShell > GET .GIF(EXE) > %Public%\???.exe > %AppData%\0mbii\gsir.exe , звіт

11/04/19

розсилали #revengeRAT, .xlam / .doc > mshta GET pastebin1 > powershell > GET pastebin2 (base64) > run decoded exe in memory(!) , звіт

22/04/19

розсилали #formbook, attach .RAR > .EXE  , звіт

25/04/19

розсилали #nanocore, attach .doc (RTF) > OLE > 2 excel > macro_URLDownloadToFileA > GET 1 URL > .exe , звіт

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

Аналітика

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

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

  • exe/scr (без приманки) – 1 розсилка
  • RTF (OLE) – 2 розсилки
  • макроси – 2 розсилки
  • powershell2 розсилки

Схоже, що документи із вразливістю 11882 та скрипти WSH втрачають позиції. Або просто на них вже не звертають уваги.

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

  • обфускація команд PowerShell (2);
  • Документи з макросами (1) та документи з OLE (1)

Тенденції

  • PowerShell залишається одним із основних інструментів доставки та виконання payload
  • Доставку та трафіку зі С2 все частіше переводять на HTTPS або ж кодують через B64/XOR
  • Крім 1 зразка, усі інші, залишають сліди через закріплення в реєстрі ОС
  • Посилюється роль додатків MS Office в завантаженні payload

Цікавими з технічної точки зору за березень виявилися два випадки:

  • #revenge #RAT за 11/04 – powershell декодував payload і виконував його в своєму контексті
  • #nanocore #RAT за 25/04 – приманка була подвійною, у RTF файлі через OLE були дві таблиці Excel із макросами

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

  • не оновлюють MS Office та ОС
  • не блокують запуск макросів
  • не відмовилися від RTF
  • не заборонили виклик PowerShell та інших вбудованих механізмів ОС (mshta, cmd etc)
  • не контролюють GET запити на Proxy по User Agent

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

  • встановлення виправлень MS Office
  • посилена фільтрація вмісту приєднань – як по типу так і по розширенню
  • заборона запуску cmd, powershell та ?script для рядових користувачів
  • блокування web запитів з пустим або застарілим полем User Agent

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

VR

RevengeRAT або пацюк від Gorgon Group

“Я, видите ли, давно уже отвык рассуждать о человечестве в целом.

Человечество в целом слишком стационарная система, ее ничем не проймешь.”

(c) Валентин Пильман, “Пикник на обочине”

Усім доброго дня.

Продовжуємо розбирати цікаві, нетипові методи зараження.

Цього разу нашим піддослідним буде #RevengeRAT

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

З першого погляду цей лист було дуже легко сплутати з масовим фішингом який мав принести типовий #LokiBot, #Trickbot або ж #ursnif

  • підпис відсутній
  • два приєднання, одне з яких .xlam (!)
  • домен відправника не викликає довіри

 

#2 Інфікування

Якщо поштові фільтри не спрацювали належним чином і жертва, не дивлячись на ознаки обману, відкриє будь-яке із приєднань, відбувається виклик службової утиліти mshta, яка призведе до завантаження першої частини інструкцій. Цього разу код розмістили на відомому сервісі pastebin. Обфускація мінімальна:

Як можна помітити  з коду, нападники розраховували заразити системи з антивірусом Avast і сподівалися на те, що приманку запустить користувач з привілеями адміністратора. Поки усе начебто стандартно, але зверніть увагу на виклик PowerShell:

forfiles /c “”cmd /c powershell -noexit [ReFlEcTiOn.AsSeMbLy]::LoAd([CoNvErT]::FrOmBaSe64StRiNg…

Таак, а це вже цікаво. По-перше, знову декодування із Base64 за другим посиланням (теж на pastebin):

Але важливіше інше – ключ -noexit. Значить декодувати зібралися не інструкції для PowerShell а саме тіло основної частини.

Що це їм дає? Обробка першої частини інструкцій спричиняє запуск Powershell, а далі…

На відміну від попередніх прикладів, цього разу дочірнього процесу не з’являється:

Ще раз – за другим посиланням powershell забирає та декодує тіло основної частини.

Але не пише її на диск і продовжує виконувати її у своєму контексті.

Збоку це виглядає як проведення усіх операцій від імені довіреного системного процесу powershell:

Зауважте також елегантне закріплення – через довірений системний mshta із посиланням не на файлову систему (як ми уже звикли)а на друге посилання.

Тобто, при перезавантажені ОС основне тіло буде щоразу збиратися знову з “0”.

Це дозволяє досягти одразу 2х цілей:

  • захист від очистки файлової системи
  • оперативна заміна функціоналу шляхом заміни коду за посиланням

 

#3 Комунікація із С2

Кодована і відбувається по не шифрованому каналу:

 

#4 Висновки

Повний звіт із маркерами по даному зразку тут https://pastebin.com/JKMHyvgx

Отже, якщо не брати до уваги досить явні приманки (xlam та RTF) і не враховувати явних спроб зупинити процеси Avast і Windows Defender, то слід виділити наступні речі:

  • використання pastebin для хостингу інструкцій та payload
  • доставка через два документи (макрос та RTF з OLE) з передачею команд на mshta та powershell
  • mshta > powershell але без запуску окремого процесу для payload
  • закріплення не через файлову систему, довантаження з мережі
  • інфікування проходить з правами звичайного користувача

Проблеми будуть у тих, хто:
– Не контролює запуск mshta та powershell від імені користувача
– Не блокує макроси та не оновлює пакет MS Office

 

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

Практичні контрзаходи по цьому зразку (в порядку протікання зараження):

  1. Посилена фільтрація приєднань як за типом так і за розширенням (xlam, dotm і таке інше)
  2. Використання sandbox
  3. Навчання користувачів протидії фішингу
  4. Заборона активації макросів
  5. Оновлення пакету MS Office та ОС
  6. Відмова від RTF як застарілого та небезпечного формату
  7. Контроль/заборона виклику mshta
  8. Контроль/заборона виклику Powershell
  9. Блокування мережевого трафіку для Powershell
  10. Контроль/заборона GET запитів із нетиповим/пустим полем User Agent на рівні Web Proxy
  11. Контроль за зміною параметрів автозавантаження додатків (реєстр, задачі, служби)

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

 

Ось і все. До наступного зразка.

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

VR

Торпеди у воді!

Усім привіт.

Опублікували мою статтю про цільові атаки.

Контент орієнтований на ІТ/ІБ фахівців. Звичайним користувачам може бути складно, проте корисно.

Бажаю приємного читання)

https://petrimazepa.com/uk/torpedi_u_vodi

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

VR

IOC_digest_02_2019

(Зразки за лютий 2019го)

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

01/02/19

розсилали #TVRat, (.pdf.scr) > %temp%\1.exe > AppData\Roaming\d4igle\svcc.exe , звіт

06/02/19

розсилали #Trickbot, .xls > macro > cmd > powershell > GET 2 URL > $env:temp+’\tmp1806.exe , звіт

07/02/19 – високий рівень складності та загрози, без EXE файлів (!)

розсилали #SobakenRAT, .lnk > powershell > get base64 > decode > fingerprint system > POST b64 on C2 , звіт

12/02/19

розсилали #Lokibot, .RAR > bat > exe , звіт

20/02/19

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

25/02/19

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

розсилали #coinminer, .SCR > C:\Intel\* , звіт

26/02/19

 

розсилали #formbook, doc1 > xml.rels > GET1 > doc2 > 11882 > GET2 > \Public\vbc.exe , звіт

27/02/19

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

розсилали #fareit, .doc (RTF) > 11882 > GET URL > \appdata\roaming\*.exe , звіт

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

Аналітика

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

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

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

Тенденції

Кампанія з розповсюдження ransomware #shade яка розпочалася ще в кінці 2018 року продовжувалась із переключенням з приєднань на посилання на JS (WSH).

Варто виділити цільову атаку із застосуванням LNK на PowerShell (#sobaken), яка проводилась без жодних exe файлів. Це той рівень, до якого усім потрібно бути готовими.

Крім того, цікавим є спосіб доставки у #formbook – два документи, перший з xml.rels, а другий із 11882.

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

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

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

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

VR

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

Хитрий 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