Tag Archive | Exploit Prevention

Блок виклику WMI через OLE/Macros

“Нет на свете ничего такого, чего нельзя было бы исправить.”

Брати Стругацькі, “Пикник на обочине”

На мою думку, серед методів доставки malware, зараз основну і найбільшу небезпеку становлять … документи.
Погодьтеся, що і скрипти і примітивні SCR(EXE) можна заблокувати (майже) без суттєвих наслідків для бізнесу.
А от із документами біда.

Сьогодні я покажу вам як захиститися від документів, що викликають WMI.
Вперше такий спосіб доставки мені трапився 15/05/19 при аналізі #emotet.

Отже з чим ми маємо справу (свіжий документ за 27/09/19, знов #emotet):

В чому небезпека виклику WMI?

Стандартно запуск ланки інфікування такий:
winword/excel > macro > (cmd) > wscript/powershell
В даному випадку для захисту достатньо заборонити додаткам MS Office запускати дочірні процеси.

Ланка інфікування з WMI:
winword/execel > macro || (інший контекст) wmiprvse.exe > powershell > …
В цьому випадку заборона дочірніх процесів не спрацює.

Схожа схема із вразливістю редактору формул (11882). Але, якщо у випадку із 11882 нам достатньо просто заблокувати запуск eqnedt32.exe, то заборонити запуск сервісів WMI у корпоративному середовищі – не вихід.

Що ми можемо зробити, маючи на руках базовий ENS Threat Prevention без моїх User-defined правил AP?

Три простих, вбудованих(!) механізми, які по замовчуванню не активні:

1. EP – Enable Windows Data Execution Prevention
2. EP – сигнатура 6131 “Weaponized OLE object infection via WMI”
3. EP – сигнатура 6087 “Powershell Command Restriction – EncodedCommand”

Давайте перевіримо результат:

Активуємо EP – Enable Windows Data Execution Prevention і відкриваємо документ:

При спробі запустити макрос процес winword зупиняється з помилкою. Інфікування не пройшло:

Активуємо EP – 6131 “Weaponized OLE object infection via WMI” (DEP деактивовано для демонстрації) і відкриваємо документ:

Макрос відпрацьовує, але як тільки доходить до виклику WMI – він блокується. Інфікування не пройшло:

Активуємо EP – 6087 “Powershell Command Restriction – EncodedCommand” (DEP та 6131 деактивовано для демонстрації) і відкриваємо документ:

Макрос відпрацьовує, виклик WMI проходить, але виконання base64 на PowerShell блокується. Інфікування не пройшло:

Все. Результат досягнуто.

Ми не вимикали макроси повністю. Ми не блокували запуск WMI чи PowerShell повністю.

Ми просто активували три механізми захисту від нетипових макросів, WMI та PowerShell.

Сподіваюсь даний “рецепт” стане у нагоді та вбереже читачів від інцидентів із malware.

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

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

why McAfee ? (ENS how to)

“выигрывает вовсе не тот, кто умеет играть по всем правилам;

выигрывает тот, кто умеет отказаться в нужный момент от всех правил,

навязать игре свои правила, не известные противнику, а когда понадобится — отказаться и от них…”

(с) Братья Стругацкие, “Град обреченный”

Як правильно користуватися антивірусом, або чому саме McAfee?

Усім привіт.

Нещодавно я мав честь виступати перед публікою на #Security Forum Kyiv.

Розповідав я про історію успіху одного із наших замовників (презентація у pdf), якому ми допомагали із побудовою комплексного захисту із застосуванням рішень McAfee.

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

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

Давайте я вам покажу чому ж я віддаю перевагу захисту McAfee.


Перш ніж переходити до практичних екзерцисів давайте одразу чітко визначимось:

#1 ми не будемо покладатися на сигнатури.

ми достатньо освічені люди щоб усвідомлювати – один і той же зразок можна пропустити через то й же Veil , а потім вбудувати отриманий перепакований та пошифрований .exe-шник у цілком пристойний документ використовуючи широкий спектр вразливостей MS Office, наприклад 11882. Саме тому сидіти і чекати доки вендор антивірусу додасть чергову сигнатуру на документ-приманку по сьогоднішній розсилці (а завтра їх буде ще більше) – це програшна тактика. Як людина, котра більше 4х років займається тех. підтримкою я достатньо наслухався типових звернень “а ваш антивірус не розпізнав нову приманку із тисячі, він поганий, ось результати VirusTotal“.. Скажу так – моя задача як інженера показати вам що варто не влаштовувати лови на конкретний зразок (яких щодня генерують тисячами), а розбиратися із механікою і перекривати канали доставки.

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

Все. Якщо це сталося – ми втратили систему, навіть якщо зразок не призвів до шифрування файлів. Чому так? Тому що у нас немає права на помилку. Просто тому що правильно побудована стратегія захисту не повинна розбиратися – що прилетіло сьогодні – троян чи шифрувальщик? Запуск шкідливого коду це вже інцидент. І досить часто замовникам не вистачає часу/бажання а іноді й компетенції щоб розбиратися – чи достатньо просто видалити сам файл, чи система уже переналаштована?

“А мы ошибаться не должны. Нам разрешается прослыть невеждами, мистиками, суеверными дураками. Нам одного не простят: если мы недооценили опасность. И если в нашем доме вдруг завоняло серой, мы просто не имеем права пускаться в рассуждения о молекулярных флуктуациях — мы обязаны предположить, что где-то рядом объявился черт с рогами, и принять соответствующие меры, вплоть до организации производства святой воды в промышленных масштабах.” (с) Братья Стругацкие, “Жук в муравейнике”

Знову ж таки, тут моя задача – зробити так, щоб у користувача-потенційної жертви не було можливості активувати приманку і запустити процес інфікування, і байдуже що там прилетіло. Це я (коли у мене є час та натхнення) можу займатися (і займаюся) аналізом зразків. А бізнес не буде чекати, доки ІТ/ІБшнік розколупає черговий семпл. Бізнесу треба щоб процеси не припинялися. Саме тому, наше завдання не ганятися за черговою мільярдною сигнатурою, а зробити усе можливе, щоб якщо фішинг все ж таки пройшов крізь фільтри, а жертва-користувач проявив людську необачність і перейшов за посиланням/відкрив приєднання – нічого не сталося. Щоб приманка не спрацювала і нападники облажалися по повній. Щоб вони витрачали час, зусилля і кошти знов і знов у спробах пройти захист, а ми просто відстежували чергову пачку спрацювань і займалися більш важливими справами ніж аналіз маркерів по черговій, сотій/тисячній розсилці.

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


Не будемо брати якийсь уявний інцидент, давайте подивимось чого вартий правильно налаштований McAfee Endpoint Security проти останньої розсилки, яку ми детально розібрали.

Давайте уважно поглянемо на послідовність атаки:

  • жертва відкриває файл-приманку, у даному випадку надбудова Excel (xlam)
  • макрос, який міститься у файлі активується і передає кодовані інструкції на PowerShell
  • PowerShell завантажує, записує на диск та запускає основну частину

Наше поле битви – рівно до моменту запуску завантаженої основної частини. Якщо ми не зупинили атаку до цього – ми програли.

Отже, що ми можемо зробити у випадку, коли в компанії макроси використовуються і їх заборона на є прийнятною? Дозволю собі процитувати уривок із переліку контрзаходів:

  • Блокування мережевих запитів із локальної мережі з User Agent Mozilla/4.08 (Charon; Inferno) – не на рівні кінцевих точок
  • Заборона запуску макросів (параметри пакету MS Office або реєстр ОС або GPO) – бізнесу потрібні макроси, вимкнути їх не варіант
  • Блок запуску дочірніх процесів для додатків MS Office (Excel > CMD > PowerShell) – GPO або правило Access Protection
  • Блок запуску PowerShell з кодованими командами – GPO або сигнатури блоку Exploit Prevention ENS
  • Блокування доступу до мережі Інтернет для процесів PowerShell
  • Заборона створення та зчитування/запуску *.EXE з каталогів профілю користувача %appdata%, а не лише у %temp% !

Давайте я покроково продемонструю вам як це зробити засобами базового антивірусу McAfee ENS.

Отож я нагадаю, що поточна версія McAfee ENS може включати такі модулі:

  • ENS Platform – GUI, основний framework на базі якого запускаються інші компоненти
  • ENS Threat Prevention – антивірусне ядро + перехоплення експлойтів + блок HIPS + політики Access Protection
  • ENS Firewall – мережевий брандмауер із центральним керуванням з єдиної консолі McAfee ePO
  • ENS Web Protection – клієнтська веб-фільтрація, перевірка репутації та категоризація URL
  • ENS Adaptive Threat Protection – розширений захист, механізми DAC, Real Protect та передача файлів на ATD*

Мінімальний комплект – Platform + Threat Prevention. Усе інше – за бажанням.

*Adaptive Threat Protection в базовий комплект не входить. В рамках даного допису його не застосовуємо тому його вимикаю.

Трохи про можливості модулю ENS Threat Prevention:

  • OAS, ODS сканування – перевірка по DAT та GTI
  • Упередження використання експлойтів, контроль операцій в пам’яті системи
  • Сигнатурний HIPS, блокування відомих вразливостей як локально так і на рівні мережевого трафіку (привіт MS17-010)
  • Мої улюблені правила захисту доступу або ж Access Protection

Оскільки ми з вами на початку домовилися сигнатурами не користуватися, я вимикаю OAS сканування, а ODS відключаю від GTI.

Одразу попереджаю усі знімки екрану, які я буду наводити відображають не стандартні, не стокові (My Default) політики.

(Увага!) не повторюйте це на продуктиві, без підготовки та знань це може призвести до небажаних наслідків та інфікування систем


Отож почнемо з налаштування згідно переліку контрзаходів.

#1 Блок запуску дочірніх процесів для додатків MS Office (Excel > cmd > PowerShell)

У випадку коли макроси потрібні по роботі і їх не можна просто вимкнути, щоб вберегтися від документів приманок ми можемо заблокувати запуск дочірніх процесів від імені додатків пакету MS Office. Ну розсудіть самі – невже штатний режим роботи із документами Word та Excel передбачає запуск CMD та/або PowerShell ? Якщо я відкриваю документ, то  я очікую попрацювати з документом і зберегти його, я не очікую виконання якихось команд в фоні, правда ж?

Дану задачу досить просто і швидко закрити засобами правил Access Protection, увага на екран знімки екрану:

Створюємо дубль політики Access Protection, переходимо у новостворену політику і додаємо нове користувацьке правило з наступними умовами:

Вище ми вказали кому ми забороняємо запускати, далі ми створюємо Subrule щоб вказати що саме ми блокуємо:

Зберігаємо зміни в політиці, призначаємо політику групі систем, виконуємо виклик McAfee Agent щоб система швидко застосувала нову політику. Запускаємо документ і спостерігаємо за результатом:

Ой, я правда не очікував цього, чесно. Я збирався продемонструвати вам роботу Access Protection, а ENS відстежив і заблокував роботу макросу через переповнення буферу. Я ж попереджав, що у мене політики не стокові.

Ок, 1:0 на користь McAfee. Давайте вимкнемо механізм DEP щоб отримати спрацювання по Access Protection:

Запускаємо документ вдруге і спостерігаємо за результатом:

Ок, 2:0 на користь McAfee. Давайте вимкнемо блокування для нашого правила Access Protection і перейдемо до наступного пункту:

#2 Блок запуску PowerShell з кодованими командами (-e, pOWErshELL -EncODeDCOMmaNd)

В аналізі розсилки, приманку якої ми препаруємо ви можете бачити, що макрос містить кодовані у base64 інструкції, що через cmd передаються на powershell. У тому випадку, якщо адміністратори широко застосовують powershell для рутинних задач, можна не повністю блокувати запуск powershell, а з певними параметрами. У цьому нам допоможе HIPS, який інтегровано у модуль ENS Threat Prevention, дивіться уважно:

Отже я активував сигнатури 6108 та 6087 які дозволяють мені блокувати підозріле використання PowerShell. Втретє відкриваємо документ-приманку:

Ок, 3:0 на користь McAfee. Вимикаю сигнатури і переходимо до наступного пункту.

#3 Блокування доступу до мережі Інтернет для процесів PowerShell

А дійсно – наскільки часто в штатному режимі роботи powershell з клієнтських машин повинен завантажувати з Інтернет файли? Якщо це не є ключовим моментом роботи оператора АРМ чи працівника департаменту HR, то давайте це заблокуємо засобами модулю ENS Firewall:

Правило Firewall доволі просте – я забороняю мережеву активність для певного переліку додатків:

Отже я створив та активував правило для ENS Firewall яке дозволяє мені блокувати трафік процесу PowerShell. Відкриваємо документ-приманку в четвертий раз:

Хм, ми бачимо спрацювання Access Protection по іншому правилу – blk_exe_prof (заборона створення файлів типу .exe у каталозі користувача), але зовсім не Firewall (ті які видно в списку – 16:16 – 16:28 не мають відношення до powershell, то блок broadcast). Чому? Усе просто – я забув вимкнути наперед створене правило Access Protection, а при завантаженні файлів спершу виконується функція створення файлу, а вже потім його завантаження. Отже спроба створити файл була заблокована, а передачі мережевих пакетів так і не відбулося. Давайте вимкнемо блокування по правилу AP, бо це буде наступним пунктом і все ж таки побачимо спрацювання брандмауера:

Тепер у мене створення файлів не блокується і ми відкриваємо документ-приманку вп’яте:

Ок, 4:0 на користь McAfee. Вимикаю брандмауер і переходимо до наступного пункту.

#4 Заборона створення та запуску *.EXE з каталогів профілю користувача %appdata%

О, це справді досить суперечливий метод, проте максимально дієвий. Справа у тому, що 90% усього шкідливого мотлоху, який потрапляв мені до рук за останні ~3 роки, не залежно від форми та типу обгортки, в кінцевому результаті призводив до створення (завантаження або генерація) нового .ехе файлу у каталозі користувача.

Так, я знаю, що по цьому правилу буде багато, досить багато false positive завдяки сучасним програмістам, які вважають, що записати додаток у каталог користувача це простіше і легше а ніж помістити його у Program Files і навести лад із дозволами…

Але зрозумійте одне – варто один раз витратити кілька годин щоб прописати необхідні виключення і ми отримаємо універсальний захист від різноманітних розсилок, навіть від тих обгорток та вразливостей, які ще не застосовувалися. Адже ми блокуємо фінальний етап атаки – запис та запуск шкідливого додатку. Дивіться самі як це працює:

Важливо!

Останнім часом замість %temp%, payload усе частіше записують у %AppData% або ж у Public тому правильна умова для правила – C:\Users\*\**\*.exe

Отже одним або двома правилами (якщо розносити блок запису та запуску окремо) ми забороняємо усім процесам (мінус виключення) створювати та запускати .exe файли із AppData. Відкриваємо документ-приманку вшосте:

Хм, спрацювання є, але не потому каталогу, в якому ми очікували основну частину. Давайте поглянемо на WireShark:

Але ж я обіцяв вам показати усі способи захисту в дії. Що ж скористаємося засобами PowerShell для завантаження цілком легітимного файлу – пакету 7zip:

Правило blk_exe_prof_create відпрацювало як і було задумано – сповістило проте не блокувало. А тепер давайте спробуємо запустити .exe :

Отже 5:0 на користь McAfee. Навіть якщо payload усе ж таки буде доставлено та записано через 0day вразливість ми тупо блокуємо його запуск.

І лише після деактивації блокування для правила blk_exe_prof_create жертва зможе запустити умовний payload і відбудеться інфікування системи:


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

І це без сигнатур, в яких на момент тестування payload уже був:

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

Зверніть увагу – замість того, щоб зациклюватися на конкретному зразку, я блокую канали доставки. Таким чином я прибираю у користувача можливість помилитися і стати жертвою. Я не покладаюся на шлюзи/фільтри та сигнатури – я просто знаю як працює той чи інший тип приманок і перерізаю їм роботу, навіть не замислюючись що це було – черговий ransomware чи trojan. Коли чергова фішингова розсилка буде відбиватися вищенаведеними правилами – тоді у ІТ/ІБ фахівців буде час розбиратися із дійсно важливими та складними атаками, а не вовтузитися із кожною новою хвилею примітивщини. А поки для нашого сегменту атаки на кшталт badrabbit будуть сприйматися і розганятися по ЗМІ як “супер-пупер-мега-складна” атака – ми залишатимемося вразливими для більш тонких і справді складніших операцій.

Так, по замовчуванню, одразу після розгортання продукту політики потрібно переналаштувати. Але зверніть увагу, що показані мною правила не “заточені” під конкретний зразок чи ба, навіть, під конкретну розсилку, адже приміром блок створення дочірніх процесів захистить мене не лише від макросу але й від 11882 чи DDE, а блокування кодованих команд PowerShell від інших способів атаки, наприклад OLE. Що ж до блокування створення та запуску нових .exe – цей спосіб вельми універсальний, потрібно лише правильно прописати виключення.


Отже ми з вами на прикладі одного документу із макросом розглянули реалізацію наступних механізмів захисту:

  • Блок запуску дочірніх процесів для додатків MS Office (Excel > CMD > PowerShell) – ENS Access Protection
  • Блок запуску PowerShell з кодованими командами – ENS Exploit Prevention
  • Блокування доступу до мережі Інтернет для процесів PowerShell – ENS Firewall
  • Заборона створення та запуску нових *.EXE файлів з %userprofile%, а не лише у %temp% – ENS Access Protection

Крім того, ми отримали ще додаткове спрацювання Exploit Prevention на переповнення буферу при активації макросу (не стандартні політики, максимальний захист).

Так, частину із описаних вище контрзаходів можна реалізувати засобами ОС, проте дозвольте вам зауважити, що замовник, який правильно експлуатує  захист кінцевих точок, може оперативно вносити зміни в політики захисту, адаптуючи систему захисту під нові види загроз. І це в базовому варіанті, без можливостей розширеного захисту із застосуванням ENS Adaptive Threat Protection.

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

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

 

VR

New Traps v3.4: Protect Yourself From (Anti)virus

Screenshot_2016-08-04_10-54-27

It is truly hard to be secured in these days – all those waves of countless phishing campaigns, increase of ransomware activity which day by day spreads like a plague and even worth – all those low profile hi-skilled APT..

In this conditions traditional signature-based AV solutions can not guarantee enough level of protection. You just need to keep in mind that signatures always late, from the beginning. It is obvious for us, technical guys, but may be it is not clear for business decision makers. The problem is that to make a signature you need a sample or threat. It means that somebody needs to be infected first, needs to be a so called “0-patien”. In modern world no one wants to be him because usually it involves reputation risks and data breach. Another issue what I saw many times – when company implements traditional AV they may low setting to avoid conflicts with business software. This reduce overall level of protection from low to ground. And even when security convinced use additional measurements (like EMET or intrusion prevention system) – implementation of this additional layer usually take more time and recourses. For technical department it is difficult to correctly implement such systems. As a result many customers does not full implementation of it or run it without prevention enabled. It means that they got level of protection which is not far from AV.

Screenshot_2016-08-04_10-55-06

I saw many different samples which was pushed by email. More often bad guys are use OSINT and Social Engineering technics to evade protection and force victim employers to let them in. If you saw ”Please enable macro/content” you know what I mean. It is something caustic and irony to see how attackers use sample code, sometimes very primitive to run payload. But it works great and brings them nice monetization. This is the reson why they generate new samples so fast and in such big quantity. Those who keep an eye on this process can noticed – hey, this is industrial scales.

Thats why enterprise customers need new different approach to protect their endpoints. In nowadays endpoints are main vector of modern (targeted) attacks.

Fresh version of Palo Alto Traps 3.4 introduce new capabilities and bunch of improvements. Thats why enterprise can replace their AV by Traps:

starlight-figure1

In addition to strong and multi-layer exploit mitigation and malware prevention developers implement possibility of static analysis, which expand Traps arsenal against new unknown executables.

Along with protection enforcement new version got possibility to exclude enterprise applications by their publisher and digital signature, which no doubt is “must have” for large enterprise companies.

And as usually all this are deployed with interception of exploit technics. Memory Corruption Prevention was improved. There are also some changes implemented in Logic Flaw Prevention functionality which helps Traps better recognize and mitigate attempts to interrupt and change normal OS running.

starlight-figure2-1

As I mentioned it before in my first look at Traps – I really like how it operates and how it resist against samples which I collected. Especially how it was done with WildFire integration.

Let me explain it little bit more. When Traps detected attempt to execute new unknown code, depends on policies, he can block it until its behavior will be checked by WildFire. Even if company decided not enable such paranoid mod (which I like) WildFire will notify ESM later and if it was harmful next attempt to run these code again will be blocked by bad reputation. Meanwhile even if unknown code was run it goes through Policy Restriction first and after that it will be inspected with malware and exploit mitigation. It is powerful multilayer approach to keep system clean and untouched.

And guess what? It works without engine (scanning) it means minimal impact to system and application productivity. Because it is not AV.

I really like possibility prevent execution from %temp% & %appdata% – because almost each ransomware, or RAT or other threats use this paths to run its operation. Moreover with Traps I can prevent creating child process for list of potential-to-be-hacked application. Serious, why my MS Word must spawn some PowerShell or wscript or event cmd child process if all what I want to do is just create or read new document?

And main exploit & malware protection keep me safe even when I partially disable it for test. It means that even if new 0day allows attackers do not trigger ROP or Heap Spray mitigation, their operations will stopped by others (DLL injection, Shellcode etc).

Bellow you can find examples of my policies. They allow you better understood capabilities of Palo Alto Traps

Screenshot_2016-08-04_11-52-37

WildFire settings – a bit paranoid but thats how it should be for those who operate with tons of phishing/SPAM everyday

Screenshot_2016-08-04_12-04-45

Execution Restrictions – in 90% legit software does not use those paths, instead malware just literally love them

Screenshot_2016-08-04_12-08-45

Child Processes restrictions – this is really handle when you must deal with VBA, java and PowerShell decoys

Screenshot_2016-08-04_12-24-46

List of exploit protection modules – oh, did I mentioned that all them are enabled out of box?

If you want to know more about Traps and improvements of new version I suggest you read initial announce.

As quick as I will get new version I will write a more practical review of it.

Stay secure.

VR

Новая защита конечных точек – McAfee ENS10.1

Полтора года тому я принимал участие в бета-тесте ENS. С тех пор решение претерпело ряд качественных изменений и с начала 2016-го года ENS 10.1 был введен в состав комплектов защиты конечных точек.

Основные моменты, про которые следует знать:

  • модуль Threat Prevention объединил в себе AMCore (АВ) и функции HIPS`а;
  • политики были переделаны для упрощения администрирования;
  • интеграция с DXL позволяет получить доступ к TIE и ATD;
  • сканирование по запросу (по планировщику) сводит нагрузку на систему к минимуму;
  • в 10.1 вернули мой любимый конструктор правил Access Protection

eps_oldvsnew2

Отличие интерфейса ENS10 от VSE и HIPS

AP_rules_diff

Отличие на уровне политик

Копия презентации по недавнему вебинару. Краткий обзор ENS10.1

Кому не удобно со slideshare – забирайте PDF (~1,6 Mb)

PS

Бонусом – хороший документ по нововведениям на английском (~ 1Mb)

Будьте внимательны и осторожны при работе с ИТ.

VR