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

Advertisements

Tags: , , , , , , , , , , ,

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: