Tag Archive | #troldesh

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

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

* 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

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

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

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

Вступ

Активне використання механізму 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

IOC_digest_12_2018

Оскільки усе не встигаю, а відкладати уже не можна,

то ось вам дайджест по розсилкам які були наприкінці 2018-го:

14/11/18

розсилали #formbook, xlsx > 11882 > ProgramData\Ms_Office.exe, звіт

15/11/18

розсилали #formbook, .7z (RAR) > exe, звіт

розсилали #lokibot, .doc(RTF) > 11882 > GET > msiexec.exe, звіт

28/11/18

розсилали #lokibot, attach .jar (RAR) > exe, звіт

розсилали #lokibot,doc > ole > %tmp%\_output62EE4B0.exe, звіт

01/12/18

розсилали #lokibot, n/a, звіт

розсилали #lokibot, .doc(RTF) > 11882 > GET wwhmvf.jpg > exe, звіт

03/12/18

розсилали #lokibot, .pdf.arj(zip) > exe, звіт

04/12/18

розсилали #emotet, .doc > macro > cmd > powershell > GET 5 URL > %temp%\***.exe, звіт

20/12/18

розсилали #emotet, .doc > macro > cmd > powershell > GET 5 URL > %temp%\***.exe, звіт

24/12/18 – “подробности заказа”

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

25/12/18

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

26/12/18

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

розсилали #Adwind, .JAR > WSH > JRE > AppData\Roaming\*.jar + *.vbs, звіт

28/12/18

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

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

Аналітика

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

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

Тенденції

Наприкінці року дуже сильно посилилися спроби доставки #shade #troldesh

Низькоякісний фішинг. Доставка через WSH.

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

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

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

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

VR

IOC_troldesh_121118

12/11/18 проходила розсилка шкідливого коду типу #troldesh (#shade) ransom
Метод доставки – js у оболонці zip.
Ступінь загрози – середній.

Аналітика:

  • Payload пакований
  • Використовує мережу Tor
  • Шифрує із затримкою 10-11 хв

Мережеві маркери:
– – – – – – – – – – – – – – – – – –

wscript.exe 2968 TCP s5.mizbandp.com http ESTABLISHED

rad3C919.tmp 2644 TCP localhost 49324 ESTABLISHED
rad3C919.tmp 2644 TCP localhost 49323 ESTABLISHED
rad3C919.tmp 2644 TCP tor.dizum.com https ESTABLISHED
rad3C919.tmp 2644 TCP tor.noreply.org https ESTABLISHED
rad3C919.tmp 2644 TCP 133-241-15-51.rev.cloud.scaleway.com 9001 ESTABLISHED
rad3C919.tmp 2644 TCP 154.35.32.5 443 SYN_SENT

rad3C919.tmp 2644 TCP 127.0.0.1 49324 ESTABLISHED
rad3C919.tmp 2644 TCP 127.0.0.1 49323 ESTABLISHED
rad3C919.tmp 2644 TCP 194.109.206.212 443 ESTABLISHED
rad3C919.tmp 2644 TCP 86.59.21.38 443 ESTABLISHED
rad3C919.tmp 2644 TCP 51.15.241.133 9001 ESTABLISHED
rad3C919.tmp 2644 TCP 5.9.151.241 4223 ESTABLISHED
rad3C919.tmp 2644 TCP faravahar.rabbani.jp https SYN_SENT

# # #

Повний перелік маркерів:
https://pastebin.com/1y8MpRZq

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

  • Заборонити обробку WSH
  • Блокувати вихідний трафік для wscript та cscript
  • Заборонити на proxy завантаження додатків
  • Контролювати виклик cmd та інших системних додатків

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

VR

IOC_troldesh_ransom_120918

(!) оновлено 13/09 – додані маркери (адреси, IP)

Доброго вечора, панове.

Сьогодні о другій половині дня проходила масова розсилка #Troldesh Ransomware.

Рівень загрози – високий!, для організацій, що прислухалися до наших попередніх рекомендацій – низький.

УВАГА! Зловмисники застосовують нову схему доставки.

Трохи аналітики:

  • Замість скриптів чи документів із приєднання цього разу розповсюджують через посилання на FTP
  • Після активації посилання жертва отримує SCR у оболонці ZIP
  • FTP джерела різні, контрольні суми архівів та SCR відрізняються (як мінімум 2 набори)
  • payload не кодований (!This program cannot be run in DOS mode.)
  • Зразок закріплюється в системі і шифрування починає із затримкою 10-15 хв
  • Затримка дозволяє обходити онлайн sandbox у яких час перевірки лімітований
  • Користувачі захисту кінцевих точок McAfee (VSE/ENS) зауважте, що payload детектуються по GTI.

Схема атаки:

email > URL > FTP > ZIP > SCR > %temp% > Program Data\Windows\csrss.exe

Маркери IOC:

Приклади листів із посиланням на FTP джерела:

Теми листів:(оновлено 13/09)

Платіжна інформація 9/12/2018
інформація 6065341
інформація 2194379
інформація 2836783
інформація 1438232
ЗВIТ ПЛЮС

Адреси серверів з яких велась розсилка: (оновлено 13/09)

66.60.130.30
194.79.65.168
72.52.210.40
212.54.57.98
212.54.57.99
212.54.57.96

Скриньки з яких велася розсилка: (оновлено 13/09)

a.igor@arcor.de
silke.berg@arcor.de
murdock3@arcor.de
janinacaspers@arcor.de
kaierle@arcor.de
nadaf@arcor.de
clemo.w@arcor.de
elli.winter@arcor.de
neke81@arcor.de
denis.pielka@arcor.de
kasten.m@arcor.de
onkel-mike@arcor.de
oli-gerhard@arcor.de
ge-47se@arcor.de
ronnsen_g@arcor.de
stkroeger@arcor.de
fabian.schossau@arcor.de
franz216@arcor.de
okamerlog@arcor.de
chrissifuessel@arcor.de
sternentreiber@arcor.de
kd-53@arcor.de
thwagner@arcor.de
thomas.croy@arcor.de
j.zynda@arcor.de
stevesteel@arcor.de
arslanu@arcor.de
thwagner@arcor.de
cojahn@arcor.de
eadavid@arcor.de
philippklemm@arcor.de
roland.steurer@arcor.de
badneo@arcor.de
c.burbach@arcor.de
lars.sylvia@arcor.de
michappe2@arcor.de
johannes.steinbrecher@arcor.de
amiri111@arcor.de
vincentschwiedeps@arcor.de
oezdinc@arcor.de
varan@arcor.de
tobisperling@arcor.de
silke.berg@arcor.de
fabianahrens@arcor.de
andy-lieb@arcor.de
markxy2@arcor.de
tibe99@arcor.de
rosenstolz-100@arcor.de
rolf.kissel@arcor.de
raimondkiess@arcor.de
danielkempgen@arcor.de
vo-zi@arcor.de
dubidubidam@arcor.de
peterbartzsen@arcor.de
cjonientz@arcor.de
thomasvogt1@arcor.de
botbot@arcor.de
carstenconstabel@arcor.de
t.rick@arcor.de
c_ortiz@arcor.de
spamfelix@arcor.de
f.paul.pp@arcor.de
lars.sylvia@arcor.de
batyr4@arcor.de
cytomic@arcor.de
sebastian.strobl@arcor.de
robert.kagan@arcor.de
mario.muehlbach@arcor.de
a.igor@arcor.de
exog@arcor.de
derglagla@arcor.de
brharun@arcor.de
samed.yilmaz@arcor.de
bernhardschild1@arcor.de

ruim13@iol.pt
j.belem@iol.pt
jmaia79@iol.pt
angelo.c@iol.pt
neoteo@iol.pt
ampimenta@iol.pt
manuelmonteiro1974@iol.pt
siriusgrey@iol.pt
joaonn13@iol.pt
onapp@iol.pt
hugo_china@iol.pt
gtdesk@iol.pt
claudia_ferreir@iol.pt
filipe.t@iol.pt
fpimentel@iol.pt
nina_faria@iol.pt
ricksilva@iol.pt
jm3ze@iol.pt
tfcoelho@iol.pt
anakar1@iol.pt
ritaportela@iol.pt
ndsous@iol.pt
olga_rodrigues@iol.pt

j.morgan06@blueyonder.co.uk
lf012r2929@blueyonder.co.uk

tiff1pets@reliable-mail.com
bre90oplign@reliable-mail.com
bre90oplign@reliable-mail.com

qpecota@surewest.net
chairman@phoenixhc.co.uk

stolen@ghettojam.net
ian.p.hamilton@virgin.net
robiwahn@vodafone.de
engelchen1959@alice.de
p-morell@stofanet.dk
sara@woodsidestables.com

Адреси FTP: (оновлено 13/09)

f11p:\makoblue:london92@www.makoblue{.} com.au/public_html/2018/administrator/components/com_joomdoc/libraries/joomdoc/html/123-info001.zip
f11p:\freedomp:E8o1s8qpW5@freedompublishing{.} com.au/.trash/HTML/eoplata007.zip
f11p:\wontasti:85221064@ftp.wontastic{.} com/.htpasswds/public_html/0297_docs_tre_88.zip
f11p:\wontasti:85221064@ftp.wontastic{.} com/.trash/kitchen/wp-content/plugins/jetpack/modules/minileven/images/docs_spwo_374.zip
f11p:\j0elb:d3al4@users.tpg.com{.} au/selattyncottages/images/docs_spwo_374.zip
f11p:\mergit.com{.} au:a1d4nm143y@s46950.gridserver{.} com/domains/mergit.com{.} au/html/mergit/v00.01.13/tmp/Prvd_docs.zip
f11p:\wontasti:85221064@ftp.wontastic{.} com/.trash/kitchen/wp-content/plugins/meeting-scheduler-by-vcita/images/docs_spwo_374.zip
f11p:\sbbccom/#?-bWZ(Z_v3;@ftp.sbbc.com{.} au/.cagefs/var/cache/php-opcache/d949132ff7e5a1b34f35758ccce8ff12/home/sbbccom/public_html/mngd001.zip
f11p:\zvillanovaplaye:ATWaS1948@villanovaplayers{.} com/httpdocs/images/Prvd_docs.zip
f11p:\f189031:s3yn9bsk@cpfacilitation.com{.} au/webspace/httpdocs/wordpress/wp-content/plugins/contact-form-7/images/Prvd_docs.zip
f11p:\topuksto:zrhqh3j1ka4q19la@europa.servers.rbl-mer.misp.co{.} uk/mail/ukbargaincentral.com/steve.bartlett/.Sent/tmp/docs_spwo_374.zip
f11p:\dabaco:RqPid6!!!H0Iz5f@ftp.dabaco.com{.} au/public_html/administrator/components/com_admin/helpers/html/0297_docs_tre_88.zip
f11p:\topuksto:zrhqh3j1ka4q19la@ftp.ukbargaincentral{.} com/mail/ukbargaincentral.com/steve.bartlett/.Junk/tmp/Prvd_docs.zip
f11p:\topuksto:zrhqh3j1ka4q19la@europa.servers.rbl-mer.misp.co{.} uk/mail/.Drafts/tmp/docs_spwo_374.zip
f11p:\thestore:Soot777!@thestoreroomnsw.com{.} au/public_html/administrator/templates/khepri/html/123-info001.zip
f11p:\f189031:s3yn9bsk@cpfacilitation.com{.} au/webspace/httpdocs/wordpress/wp-content/plugins/contact-form-7/images/docs_spwo_374.zip
f11p:\etrain:*!?qfP#^QgU%@e-train.com{.} au/public_html/eoplata007.zip
f11p:\bimbella:q2h1q8a8n5@ftp.bimbellabeef.com{.} au/public_html/mngd001.zip

Архіви:

SHA-256 aa819503e6fa943c7802a6fd1d14b918fd33cf9ad97fba7140cdd7742e5192bb
File name Prvd_docs.zip
File size 853.95 KB

 

SHA-256 8b9b32c0965a707f26aaa9d8c316bba46d850ef768ebd1d9f2449325a311e15c
File name mngd001.zip
File size 853.77 KB

 

SCR файли:

SHA-256 270cbd6b5c344b952eb23b3383b30c4b97dc3f5b3e7702c61bb08c19e7f0320a
File name docs_spwo_374.scr
File size 911 KB

 

SHA-256 e7f43c2e20deb45a295eb7f3774c238e29a4a89e3d2487d9f852ada216052148
File name 0297_docs_tre_88.scr
File size 911 KB

Після запуску SCR дублює своє тіло у C:\ProgramData\Windows\csrss.exe

Закріплюється через HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run\Client Server Runtime Subsystem

Через 10-15 хв після активації розпочинає процес шифрування файлів, зашифровані файли отримують розширення .crypted000007

Цитата із вимог про викуп:

“Вaшu файлы былu зашuфрoвaны.
Чmобы pасшифpовamь иx, Вам неoбхoдuмо omправuть kод:
85F93484188BBACD2983|833|6|8
нa элeкmрoнный адрeс VladimirScherbinin1991@gmail.com .”

Мережева активність скомпрометованої системи:

194.109.206.212	www.khfpgbxlw5p6pzvklzug{.} com		Client Hello
86.59.21.38	www.j4pl75jorexd4e{.} com		Client Hello
192.3.169.210	www.33llfq{.} com		        Client Hello

0297_docs_tre_88.scr	194.109.206.212	443	ESTABLISHED										
0297_docs_tre_88.scr	192.3.169.210	443	ESTABLISHED										
0297_docs_tre_88.scr	86.18.115.93	9001	ESTABLISHED

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

  • Перевірка журналів мережевого обладнання по наданим маркерам
  • Обмеження FTP з’єднань для пересічних користувачів за білим списком джерел
  • Заборона довільного завантаження додатків для пересічних користувачів на рівні Web Proxy
  • Заборона створення та зчитування/запуску *.SCR та *.EXE з каталогів профілю користувача %appdata%
  • Розгортання механізмів т.з. “білих списків” для захисту від виконання несанкціонованого коду (на серверах/критичних системах)
  • Розгортання комплексу захисту McAfee ATD + ENS ATP + MAR для перевірки та блокування файлів із невідомою репутацією
  • Співбесіди з персоналом на тему сучасних цільових/масових атак із застосуванням фішингу та соц. інженерії

Постраждалим(!):

ID Ransomware

No More Ransom

Інструкція по розшифровці (на свій ризик!)

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

VR

IOC_troldesh_ransom_220917

Доброго вечора, панове.

Сьогодні було зафіксовано спробу доставки різновиду Troldesh Ransomware.

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

Трохи аналітики:

  • Зловмисники комбінують зразок який я уже розбирав із методом доставки через OLE
  • Файл-приманка не містить макросів, натомість там обфускований JS у вигляді OLE об’єкту
  • По при примітивний підхід сама приманка (dropper) мала низький рейтинг на VT (6/59)
  • Обидві частини dropper та payload розповсюджуються із двох різних скомпрометованих сайтів зони AU
  • Зразок закріплюється в системі і шифрування починає із затримкою 10-15 хв
  • Основна частина (payload) замаскована під png файл
  • Користувачі захисту кінцевих точок McAfee (VSE/ENS) зауважте, що payload детектуються по GTI.

Схема атаки:

email > URL > DOCX > OLE > JS > WScript > URL > GET > %APPDATA%\Microsoft\Windows\Templates\random.exe

Маркери IOC:

Сам документ приманка розповсюджується із скомпрометованого серверу (досі активний!):

142.4.12.133  h11p://http://www.bajaparts.com.au/kvit_recepr_92217.docx

File Name kvit_recepr_92217.docx
SHA-256 Hash Identifier 35CE8815C0D78DDD58C651FC520D65343CF919388944683F693BA994AD7C57D9
File Size 47017 bytes
File Type application/vnd.openxmlformats-officedocument.wordprocessingml.document

При відкритті користувачу пропонують активувати два OLE об’єкти (два JS скрипти)

Якщо користувач запускає подвійним кліком один із них, він записується та оброблюється WSCript із %temp%

File Name Квитанция.js
SHA-256 Hash Identifier A6201F69711961EF02FBC1A584A65FCF7FFA431E57F4F9F8653F005F3F2961CF
File Size 50304 bytes

Його активація призводить до завантаження основної частини із скомпрометованого серверу (досі активний!):

27.121.64.61 h11p://www.papermillmedia.com.au GET /wp-includes/customize/copy_example_.png HTTP/1.1

у випадку успішного завантаження основне тіло записується процесом WSCript у каталог “%APPDATA%\Microsoft\Windows\Templates\939299.exe”

File Name copy_example.png            >>  939299.exe
SHA-256 Hash Identifier 1DCF33CE009B879CE5D5197904151DC32112476F84E50F808BF55E8C9EA2130D
File Size 1028608 bytes

Після запуску дублює своє тіло у C:\ProgramData\Windows\csrss.exe

Закріплюється через HKEY_USERS\SID\Software\Microsoft\Windows\CurrentVersion\Run\

Через 10-15 хв після активації розпочинає процес шифрування файлів, зашифровані файли отримують розширення .crypted000007

Цитата із вимог про викуп:

“Baши фaйлы были зашифрoваны.

Чтобы pасшифрoваmь uх, Вaм нeoбxодимо omправumь кoд:

85F93484188BBACD2983|839|6|8

нa элеkmрoнный адpec VladimirScherbinin1991@gmail.com”

Мережева активність скомпрометованої системи:

939299.exe 2192 TCP 127.0.0.1 49283 ESTABLISHED
939299.exe 2192 TCP 127.0.0.1 49282 ESTABLISHED
939299.exe 2192 TCP 194.109.206.212 443 ESTABLISHED
939299.exe 2192 TCP 131.188.40.189 443 ESTABLISHED
939299.exe 2192 TCP 94.31.53.203 443 ESTABLISHED
939299.exe 2192 TCP 89.233.27.241 443 ESTABLISHED
939299.exe 2192 TCP 89.223.27.241 443 ESTABLISHED

Що можна було зробити аби уникнути інфікування ?

  1. Завантаження документу з OLE можна було перервати через блокування OLE на шлюзах WEB та EMAIL
  2. Активацію OLE можна було заблокувати через параметри реєстру
  3. Запис JS приманки на диск (розпаковку) можна було попередити заборонивши створення VBS, JS файлів в профілі користувача (групові політики або Access Protection Rules)
  4. Запуск VBS, JS приманки можна було зупинити через деактивацію механізму Windows Script Host (зміна одного ключа реєстру)
  5. Завантаження основного коду можна було зупинити блокуванням мережевих з’єднань для процесу WSCript.exe (одне правило вбудованого брандмауера)
  6. Створення та подальший запуск основного тіла можна було заборонити блокуванням створення та запуск .exe файлів у каталозі профілю %Userprofile% (групові політики або Access Protection Rules)

Таким чином, як бачите, до запуску основного тіла було 6 кроків, упередження хоча би одного з них = зупинка атаки.

Мережеві IOC:

завантаження файлу-приманки (dropper)

142.4.12.133  h11p://www.bajaparts.com.au/kvit_recepr_92217.docx

завантаження основної частини (payload)

27.121.64.61  h11p://www.papermillmedia.com.au GET /wp-includes/customize/copy_example_.png HTTP/1.1'

трафік після запуску payload

194.109.206.212 443 ESTABLISHED
131.188.40.189 443 ESTABLISHED
94.31.53.203 443 ESTABLISHED
89.233.27.241 443 ESTABLISHED
89.223.27.241 443 ESTABLISHED

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

  • Перевірка журналів мережевого обладнання по наданим маркерам
  • Блок запуску OLE об’єктів через параметри пакету MS Office (HKCU\Software\Microsoft\Office\<Office Version>\<Office application>\Security\PackagerPrompt)
  • Блокування доступу до мережі Інтернет для процесу WScript.exe (варіант 1й)
  • Заборона створення та зчитування/запуску *.JS, *.VBS, *.EXE з каталогів профілю користувача %appdata%, а не лише у %temp% !
  • Розгортання механізмів т.з. “білих списків” для захисту від виконання несанкціонованого коду (на серверах/критичних системах)
  • Розгортання комплексу захисту McAfee ATD + ENS ATP + MAR для перевірки та блокування файлів із невідомою репутацією
  • Співбесіди з персоналом на тему сучасних цільових/масових атак із застосуванням фішингу та соц. інженерії

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

VR