Рабочее место пользователя является наиболее уязвимой точкой инфраструктуры с точки зрения информационной безопасности.
Пользователи могут получить письмо на свой рабочий адрес электронной почты, которое выглядит из безопасного источника, но со ссылкой на зараженный сайт. Возможно, кто-то скачает полезную для работы утилиту из неизвестного места.
Да, можно привести десятки случаев, как вредоносное ПО может проникнуть на внутренние корпоративные ресурсы через пользователей.
Поэтому рабочие станции требуют повышенного внимания, и в этой статье мы расскажем, где и какие события принимать для отслеживания атак.
Чтобы выявить атаку на самой ранней стадии, в Windows есть три полезных источника событий: журнал событий безопасности, журнал мониторинга системы и журналы Power Shell.
Журнал событий безопасности
Это основное место хранения журналов безопасности системы.Сюда входят события входа/выхода пользователя, доступа к объектам, изменения политики и другие действия, связанные с безопасностью.
Конечно, если настроена соответствующая политика.
Перечисление пользователей и групп (события 4798 и 4799).
В самом начале атаки вредоносное ПО часто просматривает локальные учетные записи пользователей и локальные группы на рабочей станции, чтобы найти учетные данные для своих теневых операций.
Эти события помогут обнаружить вредоносный код до того, как он распространится дальше и, используя собранные данные, распространится на другие системы.
Создание локальной учетной записи и изменения в локальных группах (события 4720, 4722–4726, 4738, 4740, 4767, 4780, 4781, 4794, 5376 и 5377).
Атака также может начаться, например, с добавления нового пользователя в группу локальных администраторов.
Попытки входа в систему с локальной учетной записью (событие 4624).
Добропорядочные пользователи входят в систему под доменной учетной записью, а идентификация входа под локальной учетной записью может означать начало атаки.
Событие 4624 также включает входы под учетной записью домена, поэтому при обработке событий необходимо отфильтровывать события, в которых домен отличается от имени рабочей станции.
Попытка войти под указанной учетной записью (событие 4648).
Это происходит, когда процесс выполняется в режиме «запуск от имени».
Этого не должно происходить при нормальной работе систем, поэтому такие события необходимо контролировать.
Блокировка/разблокировка рабочей станции (события 4800-4803).
К категории подозрительных событий относятся любые действия, произошедшие на заблокированной рабочей станции.
Изменения конфигурации брандмауэра (события 4944–4958).
Очевидно, что при установке нового программного обеспечения настройки конфигурации брандмауэра могут измениться, что приведет к ложным срабатываниям.
В большинстве случаев контролировать такие изменения нет необходимости, но знать о них точно не помешает. Подключение устройств Plug’n’play (событие 6416 и только для Windows 10).
За этим важно следить, если пользователи обычно не подключают новые устройства к рабочей станции, но вдруг подключают. Windows включает 9 категорий аудита и 50 подкатегорий для тонкой настройки.
Минимальный набор подкатегорий, который необходимо включить в настройках: Вход/выход из системы
- вход в систему;
- Выйти;
- Блокировка аккаунта;
- Другие события входа/выхода.
- Управление учетными записями пользователей;
- Управление группой безопасности.
- Изменение политики аудита;
- Изменение политики аутентификации;
- Изменение политики авторизации.
Системный монитор (Sysmon)
Sysmon — это встроенная в Windows утилита, которая может записывать события в системный журнал.Обычно его необходимо установить отдельно.
Те же самые события в принципе можно найти в журнале безопасности (включив нужную политику аудита), но Sysmon предоставляет более подробную информацию.
Какие события можно взять из Sysmon? Создание процесса (идентификатор события 1).
Журнал событий безопасности системы также может сообщить вам, когда был запущен *.
exe, и даже показать его имя и путь запуска.
Но в отличие от Sysmon он не сможет показать хэш приложения.
Вредоносное программное обеспечение можно даже назвать безобидным notepad.exe, но именно хэш выявит его.
Сетевые подключения (идентификатор события 3).
Очевидно, что сетевых подключений очень много, и уследить за ними невозможно.
Но важно учитывать, что Sysmon, в отличие от Security Log, умеет привязывать сетевое подключение к полям ProcessID и ProcessGUID, а также показывает порт и IP-адреса источника и назначения.
Изменения в системном реестре (ID события 12-14).
Самый простой способ добавить себя в автозапуск – это зарегистрироваться в реестре.
Журнал безопасности может это сделать, но Sysmon показывает, кто внес изменения, когда и откуда, идентификатор процесса и предыдущее значение ключа.
Создание файла (код события 11).
Sysmon, в отличие от журнала безопасности, покажет не только местоположение файла, но и его имя.
Понятно, что за всем не уследишь, но провести аудит отдельных каталогов можно.
А теперь то, чего нет в политиках журнала безопасности, но есть в Sysmon: Изменение времени создания файла (ID события 2).
Некоторые вредоносные программы могут подделать дату создания файла, чтобы скрыть ее из отчетов о недавно созданных файлах.
Загрузка драйверов и динамических библиотек (идентификаторы событий 6–7).
Мониторинг загрузки DLL и драйверов устройств в память, проверка цифровой подписи и ее валидности.
Создайте поток в работающем процессе (идентификатор события 8).
Один из типов атак, который также необходимо отслеживать.
События RawAccessRead (идентификатор события 9).
Операции чтения диска с использованием «\\.
\».
В подавляющем большинстве случаев такую активность следует считать ненормальной.
Создайте именованный файловый поток (идентификатор события 15).
Событие регистрируется, когда создается именованный файловый поток, который генерирует события с хешем содержимого файла.
Создание именованного канала и соединения (идентификатор события 17–18).
Отслеживание вредоносного кода, который взаимодействует с другими компонентами через именованный канал.
Действия WMI (идентификатор события 19).
Регистрация событий, которые генерируются при доступе к системе по протоколу WMI. Чтобы защитить сам Sysmon, вам необходимо отслеживать события с идентификатором 4 (остановка и запуск Sysmon) и идентификатором 16 (изменения конфигурации Sysmon).
Журналы Power Shell
Power Shell — мощный инструмент для управления инфраструктурой Windows, поэтому вероятность того, что злоумышленник выберет его, высока.
Для получения данных о событиях Power Shell можно использовать два источника: журнал Windows PowerShell и журнал Microsoft-WindowsPowerShell/Operational.
Журнал Windows PowerShell
Поставщик данных загружен (идентификатор события 600).
Поставщики PowerShell — это программы, которые предоставляют источник данных для PowerShell для просмотра и управления.
Например, встроенными поставщиками могут быть переменные среды Windows или системный реестр.
Появление новых поставщиков необходимо отслеживать, чтобы вовремя обнаружить вредоносную активность.
Например, если вы видите среди поставщиков WSMan, это означает, что запущен удаленный сеанс PowerShell.
Журнал Microsoft-WindowsPowerShell/Operational (или MicrosoftWindows-PowerShellCore/Operational в PowerShell 6)
Журналирование модуля (идентификатор события 4103).
События хранят информацию о каждой выполненной команде и параметрах, с которыми она была вызвана.
Ведение журнала блокировки скрипта (идентификатор события 4104).
В журнале блокировки сценариев отображается каждый выполненный блок кода PowerShell. Даже если злоумышленник попытается скрыть команду, этот тип события покажет фактически выполненную команду PowerShell. Этот тип событий также может регистрировать некоторые низкоуровневые вызовы API. Эти события обычно записываются как подробные, но если в блоке кода используется подозрительная команда или сценарий, это будет регистрироваться как предупреждение.
Обратите внимание: как только инструмент будет настроен на сбор и анализ этих событий, потребуется дополнительное время на отладку, чтобы уменьшить количество ложных срабатываний.
Расскажите в комментариях, какие логи вы собираете для аудитов ИБ и какие инструменты для этого используете.
Одно из наших направлений — решения для аудита событий информационной безопасности.
Для решения проблемы сбора и анализа логов можно предложить подробнее рассмотреть Квест ИнТраст , который может сжимать хранимые данные с соотношением 20:1, а один его установленный экземпляр способен обрабатывать до 60 000 событий в секунду от 10 000 источников.
Теги: #информационная безопасность #ИТ-инфраструктура #Софт #сбор журналов #аудит безопасности #siem #siem #SIEM #журналы событий #аудит изменений #intrust #quest #windows event
-
Amd Ryzen — Когда Красные Восстали Из Пепла
19 Oct, 24 -
Дорогой Магазин В Буржуйских Аллодах
19 Oct, 24
