Каква полезна информация може да се извлече от логовете на работна станция с Windows?

Потребителската работна станция е най-уязвимото място в инфраструктурата по отношение на информационната безопасност. Потребителите могат да получат имейл на работната си поща, изглеждащ като изпратен от сигурен източник, но с линк към заразен сайт. Възможно е също така някой да изтегли полезен инструмент от неизвестен източник. Могат да се измислят десетки случаи, как вредоносен софтуер може да навлезе в корпоративните ресурси чрез потребителите. Затова работните станции изискват повишено внимание, и в статията ще разгледаме откъде и какви събития да извличаме за наблюдение на атаките.

За откриване на атака в най-ранен етап в операционна система 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 подкатегории за прецизно настройване. Минималният набор от подкатегории, които си заслужава да се включат в настройките, е:

Вход/Изход

• Вход;
• Изход;
• Заключване на акаунт;
• Други събития за вход/изход.

Управление на акаунти

• Управление на потребителски акаунти;
• Управление на групи за сигурност.

Промяна на политика

• Промяна на одитна политика;
• Промяна на политика за удостоверяване;
• Промяна на политика за упълномощаване.

Системен монитор (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 показва кой е направил промените, кога, откъде, идентификатора на процеса и предишната стойност на ключа.

Създаване на файл (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-WindowsPowerShell / 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 на по-ниско ниво, които обикновено се записват като Вербозно, но ако подозрителна команда или сценарий се използват в блока код, той ще бъде регистриран с критичност Внимание.

Обърнете внимание, че след конфигуриране на инструмента за събиране и анализ на тези събития ще е необходимо допълнително време за отстраняване на грешки, за да се намали количеството фалшиви сработвания.

Споделете в коментарите какви логове събирате за одит на информационната сигурност и какви инструменти използвате за това. Една от нашите насоки е решения за одит на събития в информационната сигурност. За задачата по събиране и анализ на логове можем да предложим да се запознаете с Quest InTrust, който може да компресира съхраняваните данни с коефициент 20:1, а един негов инсталиран екземпляр може да обработва до 60000 събития в секунда от 10000 източника.

Източник: habr.com