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

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

Trackbacks / Pingbacks

  1. IOC_chthonic_160318 | Слава Україні — Героям Слава! - 20/03/2018
  2. IOC_ursnif_210318 | Слава Україні — Героям Слава! - 22/03/2018
  3. IOC_vba_d0c_worm_140318 | Слава Україні — Героям Слава! - 23/03/2018
  4. IOC_trickbot_290318 | Слава Україні — Героям Слава! - 29/03/2018
  5. IOC_trickbot_280318 | Слава Україні — Героям Слава! - 29/03/2018
  6. IOC_ursnif_020418 | Слава Україні — Героям Слава! - 03/04/2018
  7. IOC_Dyreza_040418 | Слава Україні — Героям Слава! - 05/04/2018
  8. IOC_ACE_0504-0604-18 | Слава Україні — Героям Слава! - 11/04/2018
  9. IOC_HawkEye_110418 | Слава Україні — Героям Слава! - 12/04/2018
  10. Application Control standalone how-to | Слава Україні — Героям Слава! - 24/04/2018
  11. IOC_NetWire_RAT_250418 | Слава Україні — Героям Слава! - 25/04/2018
  12. IOC_Pony_030518 | Слава Україні — Героям Слава! - 04/05/2018
  13. IOC_Adwind_100518 | Слава Україні — Героям Слава! - 11/05/2018
  14. IOC_LokiBot_110518 | Слава Україні — Героям Слава! - 11/05/2018
  15. IOC_FlawedAmmyyRAT_250518 | Слава Україні — Героям Слава! - 07/06/2018
  16. IOC_FlawedAmmyyRAT_070618 | Слава Україні — Героям Слава! - 07/06/2018
  17. ENS 10.6 – посилений захист | Слава Україні — Героям Слава! - 15/06/2018
  18. IOC_Trickbot_110618 | Слава Україні — Героям Слава! - 17/06/2018
  19. IOC_18-8174_180618 | Слава Україні — Героям Слава! - 19/06/2018
  20. 9:1 або ENS10.6 vs IE exploit | Слава Україні — Героям Слава! - 20/06/2018
  21. IOC_Trickbot_040718 | Слава Україні — Героям Слава! - 05/07/2018
  22. IOC_lzh_190718 | Слава Україні — Героям Слава! - 19/07/2018
  23. IOC_doc_rtf11882_190718 | Слава Україні — Героям Слава! - 20/07/2018
  24. подробности заказа | Слава Україні — Героям Слава! - 31/01/2019

Leave a Reply

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

WordPress.com Logo

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

Google photo

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

Twitter picture

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

Facebook photo

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

Connecting to %s

%d bloggers like this: