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

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

Вступ

Активне використання механізму 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. Якщо вже так сталося, що вас або вашого колегу/родича/знайому пошифрувало – почніть самі і поможіть їм розпочати створювати резервні копії.
   • приклад комерційного ПЗ
   • приклад ПЗ з відкритим кодом
   • або хоча би тим же на зовнішній жорсткий диск чи флешку Cobian Backup (бажано поєднати із шифруванням через контейнер – LUKS або ж Cryptomator)
10. Стежити за новинами в світі Ransomware краще на порталі bleepingcomputer.com, особливо рекомендую рубрику The Week in Ransomware

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

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

VR