Tag Archive | dropper

Windows Script Host або як перестати боятися скриптів

Всім привіт.
Останнім часом почастішали спроби доставки ransomware та троянського шкідливого коду через приманки у вигляді скриптів (.js*, .vbs, .wsf)
І хоча такий підхід абсолютно не новий (перший раз мені JS потрапив до рук 05/11/2015) але люди чомусь досі клікають і запускають, тому опишу прості прямолінійні варіанти як можна убезпечити організацію від зараження через цей механізм. Але давайте про все по порядку.
Нижче ви можете бачити зразки фішингових листів що ілюструють два типових способи доставки: приєднання та посилання:
Наша команда не одноразово наголошувала про необхідність блокування таких файлів по каналам web та email а також заборону їх створення у %AppData%.
Для тих, у кого поки немає комплексного захисту із білими списками та пісочницею, а також для тих, хто ігнорує застосування правил Access Protection у VSE/ENS пропоную на вибір два простих методи захисту від зараження через скрипти:
#1 Блокування доступу до мережі для процесу WScript
cmd від імені Адміністратора

netsh advfirewall firewall add rule name="_BLK_WScript" dir=out action=block program="C:\Windows\System32\wscript.exe"

* варто зазначити, що для повного захисту потрібно також створити схоже правило для консольного процесу cscript.exe
Результат роботи правила – при спробі запустити скрипт-приманку користувач буде отримувати помилку, а основна частина не буде завантажена:
#2 Деактивація механізму обробки скриптів
regedit від імені Адміністратора
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Script Host\Settings
Створити параметр типу “DWORD” з іменем “Enabled” і значенням “0
Результат роботи цього методу проілюстровано на знімку екрану вище – при спробі запуску будь якої скриптової приманки користувач отримуватиме помилку.
PS
Важливо зазначити, що дані контрзаходи базуються на вбудованих можливостях ОС і працюють одразу без перезавантаження.
І так, я в курсі, що такий підхід може спричинити проблеми в роботі програм, які залежать від скриптів, але в більшості випадків пересічний користувач може жити з виключеним WSH.
Використання описаних вище способів може бути тимчасово припинено у разі необхідності.
Але варто усвідомлювати, що навіть застосування одного із цих методів не є повноцінним захистом від сучасних масових та цільових атак.
Варто міркувати над впровадженням хочаби Access Protection або ж повного комплексу MAR, ATP =DAC + ATD
Будьте уважні та обережні.
VR
Advertisements

Правила роботи з email #2

Короткий допис по гарячих слідах чергової атаки.

Детальний звіт буде згодом!

Якщо коротко, то ситуація виглядає наступним чином:

  1. Жертва отримує електронного листа з фейкової адреси
  2. Жертва відкриває приєднання (у цьому випадку це був .XLS, але це не суттєво)
  3. Жертву просять увімкнути макроси (!)
  4. Після активації макросів з оболонки XLS в %temp% розпаковується .EXE
  5. .exe здійснює з’єднання з C&C та виконує перевірку системи (OS, hostname…)
  6. Далі з C&C здійснюється завантаження необхідних модулів

Проміжні висновки:

  • перевіряйте заголовки листів
  • не запускайте одразу приєднання
  • не дозволяйте макроси без попередньої перевірки на окремій ВМ або VirusTotal
  • якщо працювати з файлами від невідомих потрібно – блокуйте запуск скриптів та запускних файлів з каталогів %temp% та AppData

Мої рекомендації із старого допису досі залишаються актуальними.

Процес інфікування тестової системи:

winxp1 winxp2 winxp3 winxp7 winxp8

XLS`ий файл – приманка для користувача, його задача – змусити людину активувати макрос.

Макрос видобуває тіло test_vb.exe, який виконує збір інформації про машину та відправляє на C&C.

Зауважу – тут не йдеться про якийсь свіжий, небезпечний exploit.

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

PS

Спеціалісти CERT-UA відреагували швидко. C&C блоковано.

Слідкуйте за оновленнями. І пам’ятайте про правила здорового глузду при роботі із поштою.

VR