Користувальницька робоча станція — найуразливіше місце інфраструктури щодо інформаційної безпеки. Користувачам може прийти на робочу пошту лист начебто із безпечного джерела, але з посиланням на заражений сайт. Можливо, хтось скачає корисну для роботи утиліту з невідомого місця. Так можна придумати не один десяток кейсів, як через користувачів шкідливе програмне забезпечення може впровадитися на внутрішньокорпоративні ресурси. Тому робочі станції вимагають підвищеної уваги, і у статті ми розповімо, звідки та які події брати для відстеження атак.
Для виявлення атаки на ранній стадії в ОС WIndows є три корисні джерела подій: журнал подій безпеки, журнал системного моніторингу і журнали Power Shell.
Журнал подій безпеки (Security Log)
Це основне місце зберігання системних логів безпеки. Сюди складаються події входу/виходу користувачів, доступу до об'єктів, зміни політик та інших активностей, пов'язаних із безпекою. Зрозуміло, якщо настроєно відповідну політику.
Перебір користувачів та груп (події 4798 та 4799). Шкідливе програмне забезпечення на самому початку атаки часто перебирає локальні облікові записи користувачів і локальні групи на робочій станції, щоб знайти облікові дані для своїх темних справ. Ці події допоможуть виявити шкідливий код раніше, ніж він рушить далі і, використовуючи зібрані дані, пошириться на інші системи.
Створення локального облікового запису та зміни в локальних групах (події 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 та 5377). Атака може починатися, наприклад, з додавання нового користувача до групи локальних адміністраторів.
Спроби входу з локальним обліковим записом (подія 4624). Добропорядні користувачі заходять із доменним обліковим записом і виявлення входу під локальним обліковим записом може означати початок атаки. Подія 4624 включає також входи під доменним обліковим записом, тому при обробці подій потрібно зафільтрувати події, в яких домен відрізняється від робочої станції.
Спроба входу із заданим обліковим записом (подія 4648). Таке буває, коли процес виконується як “Запуск від імені” (run as). У нормальному режимі роботи систем такого не повинно бути, тому такі події мають бути під контролем.
Блокування/розблокування робочої станції (події 4800-4803). До категорії підозрілих подій можна віднести будь-які дії, що відбувалися на заблокованій робочій станції.
Зміни конфігурації файрволла (події 4944-4958). Очевидно, що при установці нового програмного забезпечення налаштування конфігурації файрволла можуть змінюватися, що викличе помилкові спрацьовування. Контролювати такі зміни в більшості випадків немає необхідності, але знати про них точно не буде зайвим.
Підключення пристроїв Plug'n'play (подія 6416 і тільки для WIndows 10). За цим важливо стежити, якщо користувачі зазвичай не підключають нові пристрої до робочої станції, а тут раптом і підключили.
Windows включає 9 категорій аудиту і 50 субкатегорій для тонкої настройки. Мінімальний набір субкатегорій, який варто включити у налаштуваннях:
Вхід/вихід
- Logon;
- Logoff;
- Account Lockout;
- Інші Logon/Logoff Events.
Управління рахунками
- User Account Management;
- Security Group Management.
Зміна політики
- Audit Policy Change;
- Authentication Policy Change;
- Authorization Policy Change.
Системний монітор (Sysmon)
Sysmon – вбудована у Windows утиліта, яка вміє записувати події у системний журнал. Зазвичай потрібно встановлювати його окремо.
Ці ж події можна знайти в журналі безпеки (включивши потрібну політику аудиту), але Sysmon дає більше подробиць. Які події можна забирати із Sysmon?
Створення процесу (ID події 1). Системний журнал подій безпеки теж може сказати, коли запустився якийсь *.exe і навіть покаже його ім'я та шлях запуску. Але на відміну від Sysmon не зможе показати хеш програми. Зловмисне програмне забезпечення може називатися навіть нешкідливим notepad.exe, але саме хеш виведе його на чисту воду.
Мережеві підключення (ID події 3). Очевидно, що мережевих підключень багато, і за всіма не встежити. Але важливо враховувати, що Sysmon на відміну від того ж Security Log вміє прив'язати мережне підключення до полів ProcessID та ProcessGUID, показує порт та IP-адреси джерела та приймача.
Зміни у системному реєстрі (ID події 12-14). Найпростіший спосіб додати себе в автозапуск - прописатися у реєстрі. Security Log це вміє, але Sysmon показує, хто вніс зміни, коли, звідки, process ID та попереднє значення ключа.
Створення файлу (ID події 11). Sysmon, на відміну Security Log, покаже як розташування файлу, а й його ім'я. Зрозуміло, що за всім не встежиш, але ж можна проводити аудит певних директорій.
А тепер те, чого в політиках Security Log немає, але є в Sysmon:
Зміна часу створення файлу (ID події 2). Деяке шкідливе програмне забезпечення може підміняти дату створення файлу для його приховання зі звітів з нещодавно створеними файлами.
Завантаження драйверів та динамічних бібліотек (ID подій 6-7). Відстеження завантаження в пам'ять DLL та драйверів пристроїв, перевірка цифрового підпису та його валідності.
Створення потоку в процесі, що виконується (ID події 8). Один із видів атаки, за яким теж потрібно стежити.
Події RawAccessRead (ID події 9). Операції читання з диска з допомогою “.”. В абсолютній більшості випадків така активність має вважатися ненормальною.
Створення іменованого файлового потоку (ID події 15). Подія реєструється, коли створюється іменований файловий потік, який генерує події з хеш вмісту файлу.
Створення named pipe та підключення (ID події 17-18). Відстеження шкідливого коду, який комунікує з іншими компонентами, через named pipe.
Активність WMI (ID події 19). Реєстрація подій, які генеруються під час звернення до системи за протоколом WMI.
Для захисту самого Sysmon потрібно відстежувати події з ID 4 (зупинка та запуск Sysmon) та ID 16 (зміна конфігурації Sysmon).
Журнали Power Shell
Power Shell - потужний інструмент управління Windows-інфраструктурою, тому великі шанси, що атакуючий вибере саме його. Для отримання даних про події Power Shell можна використовувати два джерела: Windows PowerShell log та Microsoft-Windows PowerShell / Operational log.
Windows PowerShell log
Завантажено постачальника даних (ID події 600). Постачальники PowerShell - це програми, які служать джерелом даних для PowerShell для перегляду та керування ними. Наприклад, вбудованими постачальниками можуть бути змінні середовища Windows або реєстр. За появою нових постачальників слід стежити, щоб вчасно виявити зловмисну активність. Наприклад, якщо бачите, що серед постачальників з'явився WSMan, то було розпочато віддалений сеанс PowerShell.
Microsoft-WindowsPowerShell / Operational log (або MicrosoftWindows-PowerShellCore / Operational в PowerShell 6)
Журналування модулів (ID події 4103). У подіях зберігається інформація про кожну виконану команду та параметри, з якими вона викликалася.
Журнал блокування скриптів (ID події 4104). Журнал блокування скриптів показує кожен виконаний блок коду PowerShell. Навіть якщо зловмисник намагатиметься приховати команду, цей тип події покаже фактично виконану команду PowerShell. Ще в цьому типі події можуть фіксуватися деякі низькорівневі виклики API, що виконуються, ці події зазвичай записується як Verbose, але якщо підозріла команда або сценарій використовуються в блоці коду, він буде зареєстрований як з критичністю Warning.
Зверніть увагу, що після налаштування інструменту збору та аналізу цих подій потрібен додатковий час на налагодження для зниження кількості помилкових спрацьовувань.
Розкажіть у коментарях, які збираєте логи для аудиту інформаційної безпеки та які інструменти для цього використовуєте. Один із наших напрямків — рішення для аудиту подій інформаційної безпеки. Для вирішення завдання збору та аналізу логів можемо запропонувати придивитися до , який вміє стискати дані, що зберігаються з коефіцієнтом 20:1, а один його встановлений екземпляр здатний обробляти до 60000 подій в секунду з 10000 джерел.
Джерело: habr.com