Включаємо збір подій про запуск підозрілих процесів у Windows та виявляємо загрози за допомогою Quest InTrust

Включаємо збір подій про запуск підозрілих процесів у Windows та виявляємо загрози за допомогою Quest InTrust

Одна з типів атак, що часто зустрічаються, — породження зловмисного процесу в дереві під цілком собі добропорядними процесами. Підозра може викликати шлях до виконуваного файлу: часто шкідливе ПЗ використовує папки AppData чи Temp, але це нехарактерно легітимних програм. Заради справедливості, варто сказати, що деякі утиліти автоматичного оновлення виконуються в AppData, тому однієї перевірки місця запуску недостатньо для твердження, що програма є шкідливою.

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

Ще можна перевіряти значення криптографічних хешей MD5 або SHA256, які можуть відповідати деяким раніше виявленим шкідливим програмам. Можна виконувати статичний аналіз, переглядаючи сигнатури у програмі (за допомогою правил Yara або антивірусних продуктів). А ще є динамічний аналіз (запуск програми в будь-якому безпечному середовищі та відстеження її дії) та реверс-інжиніринг.

Ознак зловмисного процесу то, можливо маса. У цій статті ми розповімо як увімкнути аудит відповідних подій у Windows, розберемо ознаки, на які спирається вбудоване правило InTrust виявлення підозрілого процесу. InTrust – це CLM-платформа для збору, аналізу та зберігання неструктурованих даних, в якій є вже сотні встановлених реакцій на різні типи атак.

При запуску програми вона завантажується в пам'ять комп'ютера. Виконуваний файл містить комп'ютерні інструкції та допоміжні бібліотеки (наприклад, *.dll). Коли процес уже запущено, він може створювати додаткові потоки. Потоки дозволяють процесу виконувати різні набори вказівок одночасно. Існує багато способів проникнення шкідливого коду в пам'ять та його запуску, розглянемо деякі з них.

Найпростіший спосіб запустити шкідливий процес - змусити користувача запустити його безпосередньо (наприклад, з вкладення електронної пошти), потім за допомогою ключа RunOnce запускати його при кожному увімкненні комп'ютера. Сюди ж можна віднести «безфайлове» шкідливе програмне забезпечення, яке зберігає скрипти PowerShell у ключах реєстру, які виконуються на основі тригера. У цьому випадку сценарій PowerShell є шкідливим кодом.

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

Файл можна вказати за допомогою повного шляху (наприклад, C:Windowssystem32cmd.exe) або неповного (наприклад, cmd.exe). Якщо вихідний процес є небезпечним, він дозволить запускати нелегітимні програми. Атака може мати такий вигляд: процес запускає cmd.exe без вказівки повного шляху, зловмисник поміщає свій cmd.exe у таке місце, щоб процес запустив його раніше легітимного. Після запуску шкідливої ​​програми вона, у свою чергу, може запустити легітимну програму (наприклад, C:Windowssystem32cmd.exe), щоб програма продовжувала працювати належним чином.

Різновид попередньої атаки - DLL-ін'єкція в легітимний процес. Коли процес запускається, він знаходить та завантажує бібліотеки, які розширюють його функціональні можливості. Використовуючи DLL-ін'єкцію, зловмисник створює шкідливу бібліотеку з тим самим ім'ям та API, що й у легітимній. Програма завантажує шкідливу бібліотеку, а вона, у свою чергу, завантажує легітимну, і при необхідності для виконання операцій викликає її. Шкідлива бібліотека починає виконувати роль проксі для хорошої бібліотеки.

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

Тепер розберемося методикою включення збору подібних подій у Windows і з правилом InTrust, яке реалізує захист від подібних загроз. Для початку активуємо його через консоль управління InTrust.

Включаємо збір подій про запуск підозрілих процесів у Windows та виявляємо загрози за допомогою Quest InTrust

Правило використовує можливості відстеження процесів Windows. На жаль, включення збору таких подій далеко не є очевидним. Потрібно змінити 3 різні налаштування групової політики:

Computer Configuration > Policies > Windows Settings > Security Settings > Local Policies > Audit Policy > Audit process tracking

Включаємо збір подій про запуск підозрілих процесів у Windows та виявляємо загрози за допомогою Quest InTrust

Computer Configuration > Policies > Windows Settings > Security Settings > Advanced Audit Policy Configuration > Audit Policies > Detailed Tracking > Audit process creation

Включаємо збір подій про запуск підозрілих процесів у Windows та виявляємо загрози за допомогою Quest InTrust

Computer Configuration > Policies > Administrative Templates > System > Audit Process Creation > Include command line in process creation events

Включаємо збір подій про запуск підозрілих процесів у Windows та виявляємо загрози за допомогою Quest InTrust

Після включення правила InTrust дозволяють виявляти невідомі раніше загрози, які демонструють підозрілу поведінку. Наприклад, можна виявити описане тут шкідливе ПЗ Dridex. Завдяки проекту HP Bromium відомо, як влаштована така загроза.

Включаємо збір подій про запуск підозрілих процесів у Windows та виявляємо загрози за допомогою Quest InTrust

У ланцюжку своїх дій Dridex використовує schtasks.exe для створення запланованого завдання. Використання саме цієї утиліти з командного рядка вважається вельми підозрілою поведінкою, аналогічно виглядає запуск svchost.exe з параметрами, які вказують на папки користувача або з параметрами, схожими на команди «net view» або «whoami». Ось фрагмент відповідного правила SIGMA:

detection:
    selection1:
        CommandLine: '*svchost.exe C:Users\*Desktop\*'
    selection2:
        ParentImage: '*svchost.exe*'
        CommandLine:
            - '*whoami.exe /all'
            - '*net.exe view'
    condition: 1 of them

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

  • Процеси, що виконуються з незвичайних місць, таких як тимчасові папки.
  • Добре відомий системний процес із підозрілим наслідуванням — деякі загрози можуть спробувати використати ім'я системних процесів, щоб залишитися непоміченими.
  • Підозрювальні виконання адміністративних інструментів, таких як cmd або PsExec, коли вони використовують облікові дані локальної системи або підозріле наслідування.
  • Підозрілі операції тіньового копіювання - звичайна поведінка вірусів-вимагачів перед шифруванням системи, вони вбивають резервні копії:

    - Через vssadmin.exe;
    - Через WMI.

  • Реєстрові дампи цілих кущів реєстру.
  • Горизонтальне переміщення шкідливого коду при віддаленому запуску процесу за допомогою таких команд, як at.exe.
  • Підозрілі локальні групові операції та доменні операції з використанням net.exe.
  • Підозрілі операції брандмауера за допомогою netsh.exe.
  • Підозрювальні маніпуляції з ACL.
  • Використання BITS для ексфільтрації даних.
  • Підозрілі маніпуляції з WMI.
  • Підозрювальні скриптові команди.
  • Спроби здампувати безпечні системні файли.

Об'єднане правило дуже добре працює для виявлення загроз, таких як RUYK, LockerGoga та інших вірусів-вимагачів, шкідливих програм та наборів інструментів для кіберзлочинів. Правило перевірено вендором у бойових середовищах, щоб мінімізувати хибні спрацьовування. А завдяки проекту SIGMA більшість цих індикаторів виробляють мінімальну кількість шумових подій.

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

Включаємо збір подій про запуск підозрілих процесів у Windows та виявляємо загрози за допомогою Quest InTrust

Крім того, можна перевірити всю телеметрію, пов'язану з подією: скрипти PowerShell, виконання процесів, маніпуляції із запланованими завданнями, адміністративну активність WMI і використовувати їх для постмортемів при інцидентах безпеки.

Включаємо збір подій про запуск підозрілих процесів у Windows та виявляємо загрози за допомогою Quest InTrust

InTrust має сотні інших правил, деякі з них:

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

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

Підписуйтесь на нашу сторінку у Фейсбуці, публікуємо там короткі нотатки та цікаві посилання.

Почитайте інші наші статті на тему інформаційної безпеки:

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

Виявляємо атаку вірусу-шифрувальника, отримуємо доступ до контролера домену і пробуємо протистояти цим атакам

Що корисного можна витягнути з логів робочої станції на базі Windows (популярна стаття)

Відстеження життєвого циклу користувачів без плоскогубців та ізолятори

Хто це зробив? Автоматизуємо аудит інформаційної безпеки

Як знизити вартість володіння SIEM-системою і навіщо потрібний Central Log Management (CLM)

Джерело: habr.com

Додати коментар або відгук