Tag Archive | WSH

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

Ліки від скриптів

“выигрывает вовсе не тот, кто умеет играть по всем правилам;
выигрывает тот, кто умеет отказаться в нужный момент от всех правил,
навязать игре свои правила, не известные противнику,
а когда понадобится — отказаться и от них..”
Брати Стругацькі, “Град обречённый”

* WSH – клас методів доставки malware, що використовує функціонал Windows Script Host (cscript/wscript)

Скрипти в якості засобу доставки шкідливого коду почали використовувати не вчора і навіть не рік тому (я почав відстежувати WSH ще у 2015му). Не дивлячись на наявність наведених способів боротьби із скриптами, я періодично отримую інформацію про інциденти з ransomware на різних українських підприємствах.

Останнього разу жертвами #troldesh #shade стала велика організація.
Кампанія з темою розсилки “о заказе” триває вже майже рік…
Коли я поцікавився чому не було вжито контрзаходів проти WSH, виявилося що “оце не можемо, а оце не хочемо, а про це не знаємо..”

Я вважаю, що у 19му році втрачати дані і час від Ransomware який зайшов через WSH – це нонсенс.
Нагадаю іще раз з чим ми маємо справу:

Це третя зміна тактики. Спершу були архіви у приєднанні. Потім архіви за посиланням. Тепер додали проміжний PDF.

Схема атаки: email attach .PDF > URL > .ZIP > .JS > GET .EXE > encrypt

Отже якщо з певних причин ви не можете, або не хочете повністю вимкнути WSH або хоча би заблокувати мережевий трафік для wscript/cscript чи посилити фільтрацію Web та Email, ось вам ще один спосіб:

Нам потрібно зробити так, аби жертва (користувач) не змогла клікнути і запустити скрипт на виконання. Скрипт жертва може отримати через пошту (приєднання) або ж через Web (посилання на архів).

Я буду це робити через Access Protection у McAfee ENS.

Спершу потрібно обрати єдиний архіватор для усіх систем. Приклад правила буде із використанням 7zip, але це можна модифікувати під інший додаток.

Єдиний архіватор потрібен для того аби присвоїти йому і тільки йому відкриття/розпаковку архівів різного типу (ZIP, RAR, LZH, 7Z etc):

Якщо ви користуєтеся McAfee VSE/ENS або просто уважно поставилися до моїх порад, тоді при зміні реєстрації типів файлів ви можете отримати помилку (як отримав я, коли готував цей матеріал):

Нічого страшного – нам просто потрібно _тимчасово_ вимкнути вбудоване правило Access protection:

І застосувати прив’язку розширень для усіх користувачів іще раз:

А тепер потрібно створити нове правило Access Protection, яке буде блокувати спробу архіватора записати на диск скриптові типи файлів:

Action: Block + Report

Executables: 

**\7z.exe
**\7zFM.exe
**\7zG.exe

User Names: (не вказуємо конкретні, усі)

subrules > type: File

Operations: Create

Targets:

**\Users\**\*.js
**\Users\**\*.jse
**\Users\**\*.vb
**\Users\**\*.vbs
**\Users\**\*.vbe
**\Users\**\*.ws
**\Users\**\*.wsf
**\Users\**\*.exe

Правило враховує роботу із 7zip, але замість нього можна взяти інший додаток.

Формуємо перелік типів файлів, які заборонено писати на диск процесам архіватора.

Я обрав основні типи WSH, але за бажанням список можна розширити.

Правило створене і активоване. Давайте застосуємо і перевіримо його:

Три архіви: документи, скрипти і запускний файл. Почнемо:

Документи розпаковуються без зауважень. А що буде із скриптами?

Скрипти блокуються згідно логіки правила. А що буде із ЕХЕшником ?

Запис ЕХЕ на диск блокований. Все. Результат досягнуто.

Ми не вимикали WSH. Ми не блокували запуск wscript/cscript.

Ми заборонили архіватору писати (видобувати) на диск скриптові файли.

Сподіваюсь даний спосіб стане у нагоді і вбереже читачів від інцидентів із malware.

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

VR

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

Усім привіт.

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

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

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

https://petrimazepa.com/uk/torpedi_u_vodi

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

VR

IOC_digest_03_2019

(Зразки за березень 2019го)

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

07/03/19

розсилали #trickbot, .doc > macro_AutoClose > 4 bat > BITS > GET > AppData\Roaming\wnetwork\*.exe , звіт

15/03/19

 

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

19/03/19

розсилали #shade, (RAR) > pass > JS > WSH > GET .mpwq > %temp%\*.tmp , звіт

21/03/19

розсилали #cobaltstrike, EXE (SFX) > .bat > Startup\explorer.exe , звіт

25/03/19

розсилали #shade, (RAR) > pass > JS > WSH > GET .mpwq > %temp%\*.tmp , звіт (за 19те)

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

   

розсилали #sobaken, .ZIP > .PPSX > XML_RELS > GET > WSH > %temp%\tmp4E07.tmp > %userprofile%\NTUSR.DAT , звіт

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

Аналітика

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

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

  • exe/scr (без приманки) – 2 розсилки
  • BITS – 1 розсилка
  • WSH – 3 розсилки, включаючи цільову атаку (28/03)
  • Вразливість 11882 – 0 розсилок
  • powershell – 0 розсилок

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

  • архіви з паролями;
  • Документи з макросами (1) та документи з посиланням xml.rels (1)

Тенденції

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

Все ще може становити загрозу для непідготованих користувачів.

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

#1 цільова атака із застосуванням аналітики по виборам в якості приманки (xml.rels > WSH).

  • Якісний привід (презентація по виборам).
  • Використання WSH для закріплення та збору інформації про заражену систему.
  • Без створення та запуску нових exe.
  • Сильна обфускація команд.

#2 доставка #trickbot через макрос на закриття документу та завантаження через службу BITS.

У цьому випадку одразу стикаємось із двома способами, що застосовуються помітно рідше.

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

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

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

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

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

подробности заказа

Або чому людей досі (успішно) продовжують ламати скриптами ?

Вступ

Активне використання механізму Windows Script Host (WSH) для доставки malware розпочалося кілька років тому.

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

Але нещодавно, з великим подивом, я дізнався що багато установ все ще не блокують JS/VBS скрипти.

ІТ/ІБ фахівці виправдовують себе по різному – страх ускладнень, не бажання змінювати політики захисту або ж використання Logon-скриптів для виконання адміністративних задач.

Поштовхом до написання цього матеріалу стала широка кампанія з розсилки #shade #troldesh ransomware, яка розпочалася ще наприкінці року (див. дайджест).

З чим ми маємо справу (детальний аналіз)

Ото ж до чого тут “подробности заказа”?

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

Поля “від:” довільні, генеруються скриптом.

Поле підпису змінюється рідше, вказується кілька установ (мені траплялися більше банки)

Поле “тема:” містить один і то й же текст “подробности заказа“.

Для обходу фільтрів пошти зловмисники застосували простий трюк – приєднання у вигляді архіву містить в собі ще один архів (2й ступінь), у якому міститься приманка у вигляді обфускованого .JS скрипт та документ довільного змісту.

Оскільки JS файли фактично є тестовими, а варіативність математичних перетворень (частіше операцій з масивами) вельми широка, то обфускуються вони досить вдало.

Через це зловмисники отримують можливість генерувати такі JS приманки пачками по тисячі в день і більшість антивірусів із переліку Virustotal в перші години (а дехто і дні) будуть не помічати шкідливого вмісту. Це треба сприйняти як факт і перестати покладатися на сигнатури. (Власне це треба було зробити ще роки 3-4 тому, проте люди особи інертні)

Після активації приманки жертвою відбувається обробка JS скрипта вбудованими засобами Windows, що призводить до двох можливих сценаріїв:

  • завантаження та запуск payload через процес wscript.exe
  • передача команд з wscript.exe на powershell.exe і завантаження через нього

В кінцевому випадку усе зводиться до завантаження основної частини.

Основна частина (по цій конкретній кампанії) являє собою некодований запускний файл, який зловмисники розповсюджують на зламаних та фейкових web сторінках.

Аби ускладнити детектування основної частини, її на web серверах розміщують під виглядом графічного файлу довільним іменем “*.jpg” :

В процесі інфікування, обробка JS скрипту призводить до завантаження основної частини *.jpg > %temp%\*.tmp

Після запуску основної частини (в залежності від параметрів конфігурації) може бути затримка в 9-11 хв перед початком шифрування файлів.

Остання фаза роботи – ransomware ініціює видалення тіньових копій.

 

В результаті усе закінчується зіпсованими документами та заміткою про викуп:

# # # # # # # #

Контрзаходи

Давайте тепер разом витратимо ще кілька хвилин і розберемо можливі дієві способи протидії.

Що можна зробити аби не стати жертвою чергової розсилки #shade або іншого ransomware який використовує скрипти для доставки ?

Аби мені закидали, що мої поради носять “суто лабораторний характер” і не придатні до застосування у робочому середовищі,

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

Отож, іще раз, нам потрібно обірвати схему атаки до моменту збереження і запуску основної частини.

Схема інфікування:

email attach .ZIP > 2nd .ZIP > JS > WSH > GET (1 – 5 URLs) *.jpg > %temp%\*.tmp

Покроково:

1. Регулярне створення резервних копій на окремому носії/мережевому сховищі – завжди зберігається ймовірність зараження тому про документи або інші результати праці потрібно дбати постійно, а не тільки після інцидентів.

2. Блокування приєднань що містять скриптові файли – дієво, проте не усі поштові шлюзи це можуть.

Передивіться параметри своїх антиспам рішень. Врахуйте можливість застосування нетипових форматів типу LZH або TAR

3. Блокування WSH глобально через параметри реєструуже описував, дієво, проте може спричинити помилки у роботі екзотичного/самописного ПЗ.

Якщо ви для адміністрування не використовуєте так звані Logon – скрипти і у вас відсутня екзотика – спробуйте цей метод.

4. Заборона запуску процесів WSH (wscript та cscript) від імені простого користувача – якщо відключити WSH повністю ви не можете, подбайте про те, щоб

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

Тоді ви зможете заборонити запуск ?script.xe для звичайних користувачів.

Це можна реалізувати правилами Access Protection McAfee VSE/ENS.

В правилі необхідно буде додати виключення для системних облікових записів (local/system)та адміністративних (domain/admin)

Приклад правила:

Action: Block + Report

Executables: (не вказуємо конкретні, усі)

User Names: exclude local/system, eclude domain/admin

subrules > type: File

Operations: Execute

Targets: **\?script.exe (або ж два елементи: **\wscript.exe та **\cscript.exe)

(!) Зверніть увагу, що для посилення безпеки також потрібно блокувати запуск **\powershell.exe, **\cmd.exe та **\mshta.exe

Детальніше про налаштування користувацьких правил Access Protection можна подивитися у записі вебінару (дивитися з 48-ї хвилини)

5. Заборона мережевого трафіку для процесів WSH (?script.exe) та powershell.exe – уже описував, дієво. Мало хто робить.

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

6. Заборона завантаження запускних файлів в явному вигляді + блокування http.request із пустим або нетиповим полем User Agent – для тих систем, що працюють через корпоративний Proxy це ідеальна страховка від інфікування не лише ransomware а й іншими видами malware.

Має три недоліки:

  • не всі Proxy/UTM підтримують перевірку поля User Agent
  • не всі рішення можуть виконувати інспекцію SSL трафіку
  • системи, які отримують доступ до Інтернет непряму залишаються в зоні ризику

7. Контроль створення та/або запуску нових файлів у каталозі профілю користувача – описував тут і тут(2).

Максимальна ефективність + максимальна складність через потребу вносити виключення для додатків MS, браузерів та іншого ПЗ, що полюбляє оселятися у **\Users\*\.

Це порада, яка викликає найбільш активне обговорення.

Але ви повинні розуміти, що це останній ешелон захисту.

Якщо із ви не впевнені або не можете задіяти хочаби один із попередніх контрзаходів – усе що відділяє вас від запуску шкідливого коду – дане правило.

Так, воно потребує обов’язкового тестування і створення великого списку виключень. Але повірте, це того варте.

# # # # # # # #

Ось і усе.

Вищеописані контрзаходи лишаються на ваш розсуд.

Але тільки не кажіть мені, що у 2019-му році ви не можете мінімізувати ризик від зараження JS файлами, бо це не так.

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

Як пережити атаку Ransomware ?

Не дивлячись на те, що ransomware потроху здає позиції різним троянам та модульним malware,

мені стабільно раз на місць надходять запитання на кшталт: “Ааааа! В нас систему/базу/сервер пошифрувало. Шо робити?!

Резервних копій або не було взагалі, або вони застарі, або ж (іронія) … бекапи теж зашифровані.

Ото ж, коротенька інструкція, збережіть собі, на той випадок, якщо ваші файли будуть зашифровані.

  1. Не переводити кошти злочинцям. Я серйозно. Не платити викуп.
  2. За наявності зовнішнього HDD достатнього об’єму зняти образ диску (ів) повністю
    • якщо диску потрібного об’єму нема – скопіювати на флешку каталоги в яких були важливі (робочі) документи
  3. Провести дезинфекцію інфікованої системи (тема для окремого допису)
  4. Спершу потрібно визначити тип Ransomware, для цього необхідно скористатися порталом ID Ransomware
      • варто завантажити або зразок зашифрованого файлу або замітку про викуп або ж адреси email з ransom note

  5. Якщо вам пощастить і це виявиться відомий представник свого виду – портал підкаже чи є до цієї зарази дешифратор та направить на окрему сторінку форуму де обговорюють порятунок даних від цієї зарази (утиліти для розшифровки можуть бути написані як дослідниками-одинаками так і представниками компаній РФ. використання таких утиліт – на ваш розсуд та ризик)
  6. Якщо пункт 4 не дав конкретної інформації, дешифратор можна спробувати пошукати на порталі nomoreransom.org
  7. Якщо і в попередньому пункті ви не знайшли ліків, або ж дешифратор був для старішого варіанту, я можу порекомендувати звернутися в особистому порядку до Michael Gillespie @demonslay335  який може спробувати проаналізувати зразок ransomware та зашифрований файл і можливо (50/50) допоможе із розшифровкою
  8. Якщо ж жоден із трьох варіантів не приніс результатів – не варто опускати руки. Потрібно зберегти копії зашифрованої інформації і запастися терпінням. Часом буває, що дослідники добиваються успіху і випускають дешифратор, або ж самі автори ransomware зливають в мережу ключі шифрування.
  9. Якщо вже так сталося, що вас або вашого колегу/родича/знайому пошифрувало – почніть самі і поможіть їм розпочати створювати резервні копії.
  10. Стежити за новинами в світі Ransomware краще на порталі bleepingcomputer.com, особливо рекомендую рубрику The Week in Ransomware

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

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

VR