Tag Archive | Access Protection

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

AP vs DDE & macros

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

Ми продовжуємо фіксувати активні спроби по доставці шкідливого коду через документи із DDE.

Не дивлячись на те, що поки це відлуння кампаній, payload яких націлені на інші країни,

ми повинні бути готовими до спроби використання DDE у цільових атаках на українські організації.

Також, варто звернути увагу, що експлуатація DDE поширюється не лише на Word та Excel, але й на Outlook (запрошення або пересилка повідомлення) та PowerPoint.

 

Вирішив поділитися з вами прикладами правил Access Protection для захисту від DDE та макросів.

Мої політики є оптимізованою версією запропонованих інженерами McAfee і будуть корисні перш за все користувачам McAfee VSE/ENS.

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

Для тих, хто вже реалізував захист за рахунок групових політик – переконайтеся, що ви врахували усі шляхи (system32, sysWOW64).

 

Чому виникає потреба дописати пару додаткових правил?

Я вже давно рекомендую блокувати створення та запуск нових *.exe файлів у каталозі профілю. Це універсальний захист від 90% атак.

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

Нагадую принцип активації приманки DDE/macros

Схема атаки DDE/macro_powershell:

email > .doc > WINWORD > CMD > powershell > GET ... > %temp%\*.exe

Головна ідея правил, які я хочу вам запропонувати, це блокувати запуск дочірніх процесів для додатків MS Office.

Правила Access Protection:

Перше правило забороняє додаткам MS Office виклик CMD.exe

За нормальних умов створення/редагування документу не повинне призводити до передачі команд на CMD.

(!) важливий момент – зверніть увагу, що додатки можуть бути прописані по імені, а процес, який забороняємо викликати – через Sys* (щоб врахувати обидва каталоги)

Зауважте також, що це правило дозволяє блокувати макроси націлені на виклик не лише powershell але й WSCript.exe (якщо ви не дезактивували його через реєстр)

Правило #1 для VSE

Name: _DDE_BLK1(cmd) 
Process to include: EXCEL.EXE, OUTLOOK.EXE, POWERPNT.EXE, WINWORD.EXE
Processes to exclude: -
File or folder name to block: C:\Windows\Sys*\cmd.exe
File actions to prevent:
+ Read
+ Write
+ Execute

Друге правило про всяк випадок, якщо буде знайдено спосіб виклику PowerShell без залучення CMD.

(!) знову важливий момент – а процес, який забороняємо викликати – через повний шлях із двома символами підстановки * (щоб врахувати обидва каталоги sys та різні версії)

Правило #2 для VSE

Name: _DDE_BLK_2(ps)
Process to include: EXCEL.EXE, OUTLOOK.EXE, POWERPNT.EXE, WINWORD.EXE
Processes to exclude: -
File or folder name to block: C:\Windows\Sys*\WindowsPowerShell\*\powershell.exe
File actions to prevent:
+ Read
+ Write
+ Execute

Одне правило для ENS

Name:  _DDE_BLK
Executables: EXCEL.EXE, OUTLOOK.EXE, POWERPNT.EXE, WINWORD.EXE
Subrule: _BLK_child_proc 
Operations:
+ Write
+ Execute
+ Read
Targets: (include)
C:\Windows\Sys*\cmd.exe
C:\Windows\Sys*\WindowsPowerShell\*\powershell.exe

Також нагадую інші способи захисту від використання приманок типу MS Office:

  1. Деактивувати оновлення посилань (DDE) – (DWORD) DontUpdateLinks = 1 (HCU\Software\Microsoft\Office\xx\Word\Options\)
  2. Заборонити процесам MS Office створювати дочірні процеси крім кількох довірених (політики ENS ATP – DAC)
  3. Заборонити для процесів PowerShell доступ до мережі Інтернет (по аналогії із першим варіантом) – але цього не буде достатньо якщо powershell викинуть із схеми
  4. Заборонити створення та зчитування/запуску *.EXE з каталогів профілю користувача %appdata% (політики VSE/ENS – Access Protection)

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

VR

IOC_Adwind_050917

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

Вчора в першій половині дня було зафіксовано спробу доставки загрози типу Adwind (Java backdoor).

Він уже потрапляв в поле мого зору двічі: у червні 16го та у травні 17го.

Рівень загрози для систем на яких встановлено Java Runtimeвисокий.

В групі ризику – працівники бухгалтерії (ДБО) та користувачі самописного софту якому потрібен JRE.

Для організацій, що прислухалися до моїх попередніх рекомендацій – низький.

Користувачі захисту кінцевих точок McAfee (VSE/ENS) зауважте, що компоненти Adwind детектуються DAT & GTI:

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

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

Причина полягає в тому, що 90% того мотлоху який щоденно тоннами розсилається у мережі не залежно від типу та форми обгортки (dropper) зводиться до примітивного – “завантажити / розпакувати / запустити .exe” (payload)

Відповідно, ті, хто звертають увагу не лише на IOC, а й на мої рекомендації, вже знають, що більшість складних/хитрих схем інфікування можна поламати через правила Acces Protection або деактивацію відповідних механізмів ОС, що дозволяє зупинити активність зразків на початковій стадії, не допускаючи значних ушкоджень системи жертви. (тут мова про сигнатури взагалі не йде бо в момент розсилки їх просто не буде)

Коли ми говоримо про Adwind потрібно вживати додаткових заходів захисту адже зразки цього типу в процесі інфікування не створюють нових запусних файлів, вони використовують встановлену JRE з дійсним цифровим підписом на яку через параметр подаються команди із файлу. Після закріплення уся активність на яку може звернути увагу технічний спеціаліст це присутність процесу javaw.exe (який досить легко сплутати з оновленнями Java) у автозавантаженні та періодична мережева активність від імені цього ж процесу – погодьтеся, що це не  буде виглядати підозрілим для системи, на якій активно використовуються Java додатки.

Даний клас зразків використовується для збору інформації, виведення облікових даних та віддаленого керування.

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

Як і завжди основний принцип залишається незмінним – “Простіше упередити інфікування на ранній стадії аніж потім розбиратися із наслідками перебування шкідливого коду

Схема атаки:

email > attach (ZIP) > JAR > %temp%\*.class & *.vbs > %Userprofile%\Windows.reg\Update.scan

Маркери, IOC:

File Name PO-7235.jar
SHA-256 Hash Identifier 70ECF5D3EC5C876901BE635484E0137A31167143C9758DB52C54294810B27C14
File Size 558587 bytes
File Type application/x-java-archive; charset=binary

При запуску JAR файлу активується процес закріплення в системі:

"C:\Program Files\Java\jre7\bin\javaw.exe" -jar "C:\Users\operator\Desktop\PO-7235.jar"

– зверніть увагу, в пам’ять системи завантажується оригінальний/дійсний файл Java, шкідливі інструкції подаються через параметр

"C:\Program Files\Java\jre7\bin\java.exe" -jar C:\tmp\_0.94455666565898946497103256142168062.class
"cmd.exe" /C cscript.exe C:\tmp\Retrive6049223750802148355.vbs
cscript.exe  C:\tmp\Retrive6049223750802148355.vbs
"cmd.exe" /C cscript.exe C:\tmp\Retrive7219502531594942910.vbs
cscript.exe  C:\tmp\Retrive7219502531594942910.vbs

– виконуючи шкідливий код Java видобуває із Jar архіву низку скриптових файлів необхідних для виконання закріплення в системі

"xcopy" "C:\Program Files\Java\jre7" "C:\Users\operator\AppData\Roaming\Oracle\" /e

– важливий момент – інструкціями передбачено дублювання запускних файлів JRE з Program Files у каталог %AppData%, це те, що має насторожити уважного адміна/ІБшника (про скрипти в %temp% я вже мовчу)

"cmd.exe" /C cscript.exe C:\tmp\Retrive5392694676028337177.vbs
cscript.exe  C:\tmp\Retrive5392694676028337177.vbs
"cmd.exe" /C cscript.exe C:\tmp\Retrive7999422219165629138.vbs
cscript.exe  C:\tmp\Retrive7999422219165629138.vbs
"xcopy" "C:\Program Files\Java\jre7" "C:\Users\operator\AppData\Roaming\Oracle\" /e

– – повторне копіювання, можливо для перестороги

"reg" add HKCU\Software\Microsoft\Windows\CurrentVersion\Run /v javaw.exe /t REG_EXPAND_SZ /d "\"C:\Users\operator\AppData\Roaming\Oracle\bin\javaw.exe\" -jar \"C:\Users\operator\Windows.reg\Update.scan\"" /f

– запис у автозавантаження через HCU

"attrib" +h "C:\Users\operator\Windows.reg\*.*"
"attrib" +h "C:\Users\operator\Windows.reg"

– приховує свої файли через атрибути файлової системи

"C:\Users\operator\AppData\Roaming\Oracle\bin\javaw.exe" -jar C:\Users\operator\Windows.reg\Update.scan

– передача керування на файл з інструкціями з каталогу користувача

"C:\Users\operator\AppData\Roaming\Oracle\bin\java.exe" -jar C:\tmp\_0.89960564281661135816979970325922234.class
"cmd.exe" /C cscript.exe C:\tmp\Retrive1106571663555988847.vbs
cscript.exe  C:\tmp\Retrive1106571663555988847.vbs
"cmd.exe" /C cscript.exe C:\tmp\Retrive4075909662068347616.vbs
cscript.exe  C:\tmp\Retrive4075909662068347616.vbs
"cmd.exe" /C cscript.exe C:\tmp\Retrive810479841220532242.vbs
cscript.exe  C:\tmp\Retrive810479841220532242.vbs
"cmd.exe" /C cscript.exe C:\tmp\Retrive1722342620952052502.vbs
cscript.exe  C:\tmp\Retrive1722342620952052502.vbs

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

"WMIC" /Node:localhost /Namespace:\\root\cimv2 Path Win32_PnpSignedDriver Get /Format:List

– збір інформації про встановленні драйвери PnP пристроїв – може бути ознакою перевірки віртуального середовища або пошук апаратних ключів чи особливої ознаки (Scada контроллери чи POS пристрої) на відміну від зразка за 16й рік, який цікавився не драйверами а параметрами брандмауєра

Після закріплення в системі Adwind ініціює з’єднання із сервером контролю:

176.10.124.239 TCP 49189 → 8073 [PSH, ACK]

Що можна було зробити аби уникнути інфікування ?

  1. На системах робота яких не залежить від JRE, цей компонент можна та необхідно видалити – тоді код взагалі не запуститься
  2. Доставку JAR файлу можна було зупинити на рівні поштового шлюзу та proxy серверу (як приклад – Web та Email Gateway)
  3. Запис самого JAR в каталозі користувача можна заборонити відповідним правилом Access Protection
  4. Процес інфікування можна зупинити на початку, якщо застосувати правило заборони створення, запису та зчитування vbs файлів у каталозі %temp% (а краще AppData повністю)
  5. Якщо ж співробітнику потрібна і JRE і JAR файли, правилами AP можна заборонити процесу javaw зчитування та виконання JAR файлів із каталогу користувача – цей підхід теж досить дієвий (що правда тоді краще забороняти запуск і зчитування будь-яких файлів адже через параметр інструкції можуть подаватися з tmp )
  6. У кого наразі немає VSE/ENS із AP можуть деактивувати WSH – це поламає процес інфікування, але файли будуть створені і їх доведеться прибирати в ручному режимі або ж в автоматичному, але за допомогою MAR

Зразки правил ENS AP:

ENS \ Threat Protection \ Access Protection > Add

Description: anti_Adwind_VR

Action: +Block +Report

Executables: All (*.exe)

Subrules:

rule1 
BLK_appdata_exe block 
+Create +Execute 
**\Users\*\**\*.exe

rule2 
BLK_appdata_script_ 
+Write +Create +Execute +Read
**\Users\*\**\*.vbs
**\Users\*\**\*.js*
**\Users\*\**\*.wsf
**\Users\*\**\*.jar

Результат дії правил:

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

Мережеві IOC:

176.10.124.239 TCP 49189 → 8073 [PSH, ACK]

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

  • Перевірка журналів мережевого обладнання по наданим маркерам
  • Блокування JAR файлів на рівні каналів передачі Web та Email
  • Інвентаризація встановленого ПЗ і видалення JRE там, де він не є критично потрібним
  • Заборона створення та зчитування/запуску *.JAR, *.VBS з каталогів профілю користувача %appdata%, а не лише у %temp% !
  • Розгортання механізмів т.з. “білих списків” для захисту від виконання несанкціонованого коду (на серверах/критичних системах)
  • Розгортання комплексу захисту McAfee ATD + ENS ATP + MAR для перевірки та блокування файлів із невідомою репутацією
  • Співбесіди з персоналом на тему сучасних цільових/масових атак із застосуванням фішингу та соц. інженерії

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

VR

Цербер який шифрує файли

cerber_pageНовий варіант Cerber Ransomware потрапив мені до рук. Минулого разу я помилково прийняв його за Dridex. Перші зразки Cerber були помічені ще на початку березня. Аналітики відносять його до так званого Ransomware as a Service (RaaS), тобто охочі заробити розповсюджують заразу, а самі автори отримують комісію з кожної транзакції. Механіка роботи наступна – при активації певний перелік файлів шифрується за допомогою алгоритму AES, жертві пропонують сплатити ~ 1,2 BTC ($500) за відновлення доступу до інформації. Через 7 днів сума викупу зростає вдвічі. Сплата проходить через ресурс що розміщений в мережі Tor.

Від інших представників ransomware Цербера відрізняє застосування вбудованого диктора (після шифрування файлів жертві голосом озвучують факт шифрування):

Set SAPI = CreateObject(“SAPI.SpVoice”)
SAPI.Speak “Attention! Attention! Attention!”
For i = 1 to 5
SAPI.Speak “Your documents, photos, databases and other important files have been encrypted!”
Next

Та вибіркову цілеспрямованість. Шифрування не відбувається, якщо скомпрометована система знаходиться у одній з наступних країн:

“blacklist”: {
“countries”: [
“am”, “az”, “by”, “ge”, “kg”, “kz”, “md”, “ru”, “tm”, “tj”, “ua”, “uz”

Саме через цю перевірку я так і не побачив фінальної дії семплу, хоч запускав його по кілька разів на різних системах. Крім того, як можна помітити із першого знімку екрану, автори полюбляють вислів “Quod me non necat me fortiorem facit” що у перекладі з латинської означає “Все у житті, що мене не вбиває, робить мене сильнішим” (Ніцше).

Отже нова версія Cerber має кілька відмінностей:

  • цього разу без PowerShell;
  • його прислали особисто мені;
  • обгортка – файл шаблону (.dotm);
  • інакший зміст UDP пакету.

Давайте розглянемо активність семплу детальніше. Усе починається із фішингового листа:

0_mailІнвойс? Мені? Вау.. Ну давайте поглянемо що в середині:

0dotm_ole_1 0dotm_ole_2При відкритті документу – автозапуск макроса. Сама приманка має наступний вигляд:

0_macroЯкщо жертва активувала макрос, в каталог %AppData% записується .vbs із довільним цифровим іменем, який обробляється системним процесом wscript.exe котрий ініціює з’єднання з файловим сервером з якого уже завантажується основний модуль:

7 8Цікаво, що від активації до завантаження файлів іде затримка 3-4 хвилини. Основний модуль та додаткові файли записуються в %AppData% і керування передається спершу .tmp файлу із довільним цифровим іменем, а вже потім .tmp копіює себе у підкаталог %AppData%\{X-Y-Z-A-AAA}\*.exe :

10Сам Cerber (у даному випадку процес cipher.exe) ініціює розсилку UDP пакетів на діапазони ІР, що належать провайдерам РФ та Германії:udpНа цій стадії семпл ініціював самознищення і видаляв активний компонент (.exe файл). Сам процес шифрування детально розглянутий за посиланням.

# # # # #

Давайте зосередимося на головних моментах:

  1. Написано досить якісно, значить цикл життя таких семплів буде довгим;
  2. Cerber використовує json конфіг файл, що дозволяє швидко адаптувати його до нових умов;
  3. Обгортки можуть відрізнятися, проте сам модуль пишеться і стартує із %AppData%

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

Іще одне – основна проблема із сучасним фішингом та семплами у тому, що на момент розсилки, вони майже не детектуются звичайними АВ-сканерами. Це підштовхує до застосування пісочниць, або до жорсткого контролю поведінки запущених користувачем процесів на рівні кінцевої точки. Чому так? Погляньте на результати перевірки документу-обгортки та самого payload на момент контакту:

vt_payload_contact vt_dropp_contact

Варіант захисту для користувачів VSE

VSE_AP_appdataВаріант захисту для користувачів Traps (Palo Alto Networks)

traps_rest2 traps_rest1

macro2 powershell

Маркери компрометації:

z43n21v1gs8e2p.dotm SHA1=0a03d6e9b6730a40d922b38b51a7f2344b09cc37

pentnt.exe SHA1=c8f3f0a33efe38e9296ef79552c4cadf6cf0bde6

сервер з якого завантажується payload по 80 TCP = 37.187.37.150

розсилка пакетів “hi005e974” по 6892 UDP = 85.93.0.x

Будьте уважними та обережними при роботі з ІТ.

Будущее — это тщательно обезвреженное настоящее

MV5BMTk3ODUxMjAwNV5BMl5BanBnXkFtZTcwNTg2ODY4Mg@@._V1_SX640_SY720_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

Intel Security Endpoint Protection 2015

Обновил свою презентацию по комплектам защиты конечных точек.

EPS_table

Добавил больше информации по еРО, расширил описание модулей.

Также внес информацию по MOVE, Email и Web Gateway.

Настоятельно рекомендую обратить внимание на слайд № 46

Информация будет полезной для специалистов ИТ/ИБ подразделений.

Если Slideshare для вас не удобен, вот прямая ссылка на pdf (~ 2Mb).

Хорошего всем дня и будьте предельно внимательны при использовании ИТ.

Vladislav Radetskiy | Technical Lead | BAKOTECH GROUP