Security evtx что это

Аудит безопасности на сервере. Поиск по жураналу безопасности. Power Powershell

Аудит журнала безопасности помог моему коллеге контролировать практически любые действия сотрудников, которые имеют хоть какой-то доступ к серверам или ActiveDirectory.

В топике будет много кода, который, надеюсь, будет вам полезен.

Первым делом необходимо было определить список событий, которые необходимо было отслеживать. Чтобы уменьшить количество текста, я создала процедуру, которая по ID события выдает ее описание:

Затем понадобилось описать события, которые отслеживаются по маске доступа:

Теперь мы знаем, за чем хотим следить. Следующий шаг при разработке скрипта по аудиту — это получение журнала безопасности в формате XML, так как если событий много, то построчная обработка занимает достаточно большое количество времени.

Чтобы получить события из журнала можно использовать одну из команд, в каждой из которых есть свои преимущества и недостатки:

1. Get-LogEvent security

— быстрый доступ к свойствам события;
— не нужна предварительная обработка для доступа к свойствам события.

2. Get-WinEvent –path “D:/”

— быстрая обработка журнала;
— доступ к любому журналу. Главное прописать полный путь.

— для обработки полученного журнала требуется предварительная обработка.

Следующий шаг после того как мы получили доступ к журналу, это вытягивать из журнала требуемые события и принимать по ним соответствующие решения. В большинстве случаев – это отправка информационного сообщения на почту или логирование в отдельный файл.

Задать параметры, по которым будем вытягивать информацию, возможно, используя интерфейсное решения. Диалоговое окно с вводом параметров.

1. Первый параметр предполагает, что журналы периодически экспортируются в определенный каталог, который и следует задать. Если журнал один, то задается стандартный каталог для хранения журналов: «C:\Windows\System32\winevt\Logs».

2. Второй параметр определяет сервер, по которому будет искаться логи. Если сервер один, то ставим «*».

3. Третий параметр предельно понятен: * — ищем события за весь период, если задана дата, например, 30.11.2015, то ищем за эту дату. Поиск за период осуществляется вводом начальной и конечной даты через тире (01.11.2015-30.11.2015).

4. Указываем путь для сохранения результата работы, например, «D:\log.log». Ниже приведен код, позволяющий построить интерфейс для скрипта:

Получаем введенные данные:

Если в поле дата есть символ «-«, значит введен интервал, если этот символ введен ошибочно — ваши проблемы. Проводим сепарацию по символу «-«, определяем начальную и конечную дату диапазона.

Если во введенном поле нет ни «-«, ни «*», то значит введена конкретная дата.

1. Поиск по всем серверам, по всем событиям, за весь период:

2. Поиск по всем серверам, по фильтру событий, за весь период:

3. Поиск по всем серверам, по всем событиям, за диапазон:

4. Поиск по всем серверам, по всем событиям, за определенную дату:

5. Поиск по всем серверам, по фильтру событий, за определенный период:

6. Поиск по всем серверам, по фильтру событий, за определенную дату:

7. Поиск на определенном, сервере поиск по всем событиям, за весь период:

8. Поиск на определенном сервере, по фильтру событий, за весь период:

9. Поиск на конкретном сервере, по всем событиям, за период:

10. Поиск на конкретном сервере, по фильтру событий, за период:

11. Поиск по конкретному серверу, по всем событиям, за определенную дату:

12. Поиск по конкретному серверу, по фильтру событий, за определенную дату:

В конце месяца (период индивидуально задается администраторами) журнал безопасности архивируется на сервер-хранилище, с указанием имени сервера и даты архивации.

После того как мы описали все варианты поиска событий. Полученный результат нам необходимо сохранить в файл, путь к которому прописал пользователь в последнем поле. Если путь задан, то результат сохраняется в файл. После отработки скрипта файл автоматически запускается. Если путь для сохранения результата не задан, то лог будет сохранен в рабочем каталоге под именем «log.log».

Спасибо за внимание.

Во время написания скрипта очень полезной оказалась статья «PowerShell и аудит безопасности», спасибо автору.

Источник

Исправьте ошибки Security.evtx

Иногда система Windows отображает сообщения об ошибках поврежденных или отсутствующих файлов Security.evtx. Подобные ситуации могут возникнуть, например, во время процесса установки программного обеспечения. Каждая программа требует определенных ресурсов, библиотек и исходных данных для правильной работы. Поэтому поврежденный или несуществующий файл Security.evtx может повлиять на неудачное выполнение запущенного процесса.

Файл был разработан Microsoft для использования с программным обеспечением Office. Здесь вы найдете подробную информацию о файле и инструкции, как действовать в случае ошибок, связанных с Security.evtx на вашем устройстве. Вы также можете скачать файл Security.evtx, совместимый с устройствами Windows 10, Windows 10, Windows 8.1, Windows 8, Windows 7, Windows 7, Windows Vista, Windows Vista, Windows 8, которые (скорее всего) позволят решить проблему.

Совместим с: Windows 10, Windows 10, Windows 8.1, Windows 8, Windows 7, Windows 7, Windows Vista, Windows Vista, Windows 8

Исправьте ошибки Security.evtx

Информация о файле

Наиболее распространенные проблемы с файлом Security.evtx

Существует несколько типов ошибок, связанных с файлом Security.evtx. Файл Security.evtx может находиться в неправильном каталоге файлов на вашем устройстве, может отсутствовать в системе или может быть заражен вредоносным программным обеспечением и, следовательно, работать неправильно. Ниже приведен список наиболее распространенных сообщений об ошибках, связанных с файлом Security.evtx. Если вы найдете один из перечисленных ниже (или похожих), рассмотрите следующие предложения.

Security.evtx

Не удалось запустить приложение, так как отсутствует файл Security.evtx. Переустановите приложение, чтобы решить проблему.

Проблемы, связанные с Security.evtx, могут решаться различными способами. Некоторые методы предназначены только для опытных пользователей. Если вы не уверены в своих силах, мы советуем обратиться к специалисту. К исправлению ошибок в файле Security.evtx следует подходить с особой осторожностью, поскольку любые ошибки могут привести к нестабильной или некорректно работающей системе. Если у вас есть необходимые навыки, пожалуйста, продолжайте.

Как исправить ошибки Security.evtx всего за несколько шагов?

Ошибки файла Security.evtx могут быть вызваны различными причинами, поэтому полезно попытаться исправить их различными способами.

Шаг 1.. Сканирование компьютера на наличие вредоносных программ.

Файлы Windows обычно подвергаются атаке со стороны вредоносного программного обеспечения, которое не позволяет им работать должным образом. Первым шагом в решении проблем с файлом Security.evtx или любыми другими системными файлами Windows должно быть сканирование системы на наличие вредоносных программ с использованием антивирусного инструмента.

Шаг 2.. Обновите систему и драйверы.

Установка соответствующих исправлений и обновлений Microsoft Windows может решить ваши проблемы, связанные с файлом Security.evtx. Используйте специальный инструмент Windows для выполнения обновления.

Помимо обновления системы рекомендуется установить последние версии драйверов устройств, так как драйверы могут влиять на правильную работу Security.evtx или других системных файлов. Для этого перейдите на веб-сайт производителя вашего компьютера или устройства, где вы найдете информацию о последних обновлениях драйверов.

Шаг 3.. Используйте средство проверки системных файлов (SFC).

Шаг 4. Восстановление системы Windows.

Другой подход заключается в восстановлении системы до предыдущего состояния до того, как произошла ошибка файла Security.evtx. Чтобы восстановить вашу систему, следуйте инструкциям ниже

Источник

RDP: слабые места протокола и эксперимент с развертыванием ханипота

RDP — один из самых популярных протоколов для удаленного подключения к машинам Windows. Но при неправильной конфигурации он может стать ахиллесовой пятой любой инфраструктуры.

Когда бизнес переходил на удаленку, выбор компаний пал на протокол RDP из-за простоты его настройки и использования. Но переход был экстренным и далеко не все уделили необходимое внимание безопасности. В результате организации оказались под прицелом злоумышленников.

В этой статье мы решили разобрать слабые места протокола RDP и рассказать, как обезопасить инфраструктуру компании. Также мы провели эксперимент, развернув ханипот RDP на нескольких серверах, и описали криминалистические артефакты, которые могут быть обнаружены в случае несанкционированного подключения злоумышленников.

▍Слабости RDP

Почти 4 миллиона RDP-серверов по всему миру сегодня доступны из внешней сети. Не меньшее их количество, скорее всего, доступно лишь из внутренних сетей.

Злоумышленники часто специально ищут слабые места RDP-серверов, чтобы использовать их в своих целях. Так, RDP нередко подвергается брутфорс-атакам. Кроме того, за последние два года специалисты обнаружили серьезные RCE-уязвимости, связанные с RDP.

Брутфорс-атаки

Самые распространенные атаки на RDP — атаки типа брутфорс. Их можно условно разделить на несколько групп.

Простейшим атакам и атакам с использованием словарей организации обычно уделяют должное внимание и защищаются от них. Например, часто предусматривают блокировку учетной записи после нескольких безуспешных попыток входа.

В то же время про атаки password spraying и credential stuffing зачастую забывают. Однако подобные атаки сейчас не редкость, а, напротив, скорее стали обыденностью. Бороться с ними помогает блокировка IP-адресов, с которых производятся множественные неудачные попытки входа по RDP. Также не станет лишним запрет на повторное использование паролей. Кроме того, не стоит использовать один и тот же пароль на нескольких ресурсах.

Уязвимости

С 2019 года было обнаружено несколько серьезных RCE-уязвимостей, связанных с RDP. Их эксплуатация приводит к удаленному исполнению кода на целевой системе.

Уязвимость CVE-2019-0708, получившую название BlueKeep, обнаружили не в самом протоколе RDP, а в реализации службы удаленных рабочих столов (Remote Desktop Service). Данная уязвимость позволяет неаутентифицированному пользователю удаленно исполнить произвольный код на целевой системе. Уязвимости подвержены старые версии Windows: начиная с Windows XP (Windows Server 2003) и заканчивая Windows 7 (Windows Server 2008 R2). Для ее успешной эксплуатации необходимы лишь сетевой доступ к компьютеру с уязвимой версией Windows и запущенная служба RDP. Для этого злоумышленник отправляет специально сформированный запрос к службе по RDP, что позволяет атакующему удаленно выполнить произвольный код на целевой системе. Информация о BlueKeep была опубликована в мае 2019 года, но уязвимыми до сих пор остаются более 289 тысяч RDP-серверов.

Уязвимости CVE-2019-1181/1182/1222/1226 практически аналогичны BlueKeep. Однако если предыдущей уязвимости были подвержены лишь старые версии Windows, то теперь под угрозой оказались и все новые версии ОС. Для эксплуатации уязвимостей злоумышленнику также достаточно отправить специально сформированный запрос к службе удаленных рабочих столов целевых систем, используя протокол RDP, что позволит выполнить произвольный код. Эти уязвимости были опубликованы в августе 2019 года.

Еще одна уязвимость — BlueGate (CVE-2020-0609/0610) — была найдена в компоненте Windows Remote Desktop Gateway в Windows Server (2012, 2012 R2, 2016 и 2019). Она также позволяет злоумышленникам посредством RDP и специально созданных запросов осуществлять удаленное выполнение кода на целевой системе. BlueGate была опубликована в начале 2020 года.

▍Вредоносные программы и RDP

Слабости RDP не остаются вне поля зрения операторов вредоносных программ. Злоумышленники нередко используют ставшие известными учетные данные RDP при проведении целевых атак.

После получения доступа по RDP к целевой системе атакующие вручную отключают средства антивирусной защиты и запускают вредоносные программы. В подобных атаках на зараженной системе зачастую запускаются программы-вымогатели, такие как Dharma (aka Crysis).

▍Приманка для злоумышленников, или как мы развернули ханипот

Мы решили провести эксперимент и проверить, что будет происходить с RDP-сервером, доступным из внешней сети. Для этого было развернуто два ханипота. Мы воспользовались реализацией протокола RDP на Python — RDPY, который можно найти в открытом доступе.

Один ханипот был развернут на публичном сервере DigitalOcean, другой — на сервере в сети нашей организации. Из интернета были доступны три порта:

Максимальное внимание в сети привлек стандартный порт 3389. За те полтора месяца, что работали ханипоты, в общей сложности зафиксировано 15 попыток брутфорса и 237 попыток записи невалидных данных в сокет на публичном сервере; и, соответственно, 16 и 135 попыток — на сервере в сети организации.

Также, как и следовало ожидать, стандартный порт 3389 подвергался многочисленным сканированиям из сети. При этом публичный сервер сканировался в среднем в 2,5 раза чаще, чем сервер в сети организации.

Частоту сканирований можно увидеть на графике ниже. Вертикальными линиями здесь обозначены субботы и воскресенья, которые пришлись на период работы ханипотов. В большинстве случаев на конец рабочей недели приходился спад сканирований из сети.

Попыток просканировать нестандартные порты практически не было. Следовательно, перенос RDP на нестандартный порт поможет частично защититься от большей части атак.

▍Безопасность

Обобщая все вышесказанное, можно вывести несколько правил, которые помогут обезопасить инфраструктуру при удаленном подключении по RDP.

▏Где искать следы подключения по RDP▕

Если у вас возникли подозрения о компрометации системы по RDP, можно попробовать самостоятельно выполнить несколько шагов.

События 21, 22 и 25 — для успешного входа или переподключения, 23 — для отключения. Следует искать события с необычных IP-адресов.

Даже если подключения разрешены исключительно со внутренних IP-адресов, все еще имеет смысл периодически проверять описанные выше логи на предмет внезапного подключения из внешней сети. Это позволит своевременно найти ошибки конфигурации, допущенные администраторами по невнимательности (например, при настройке форвардинга портов и пр.).

Если следы обнаружены

В случае обнаружения следов успешного проникновения через RDP необходимо в первую очередь:

Источник

Заметаем следы после взлома.

В предыдущих материалах мы достаточно подробно рассмотрели различные способы, которыми может воспользоваться злоумышленник для проникновения в корпоративную сеть. Были представлены методы, связанные с использованием беспроводных сетей, поиском и эксплуатацией уязвимостей в приложениях, разработкой эксплоитов. Темой этой статьи будет обсуждение действий хакера, который уже проник в сеть, получил шелл на различные серверы, и теперь ему необходимо найти в сети ценную информацию, а также скрыть следы своего присутствия.

Как известно, в среднем после взлома сети и до его обнаружения проходит порядка 200 дней (рекорд – восемь лет!). За это время злоумышленник успевает получить доступ практически ко всей интересующей его информации. Рассмотрим, какие действия может предпринять взломщик, проникнув в сеть, и что можно сделать, чтобы их обнаружить.

Вот основные действия хакера, о которых мы будем говорить:

Это некоторый типовой набор действий, которые обычно предпринимает злоумышленник. Перехват передаваемого трафика уже достаточно подробно рассматривался во второй статье цикла, так что здесь мы к этой теме возвращаться не будем.

Однако в зависимости от структуры компании жертвы эти действия могут отличаться.

Взлом паролей внутри корпоративных сетей.

Даже получив доступ к сети и создав свои учетные записи с административными правами, злоумышленник будет интересоваться учетными данными легальных пользователей домена, доступ к которым позволит получить доступ к большей информации, в том числе и зашифрованной данным пользователем. Также его действия будут менее заметны.

Самый простой способ, к которому он может прибегнуть, – это сделать копию файлов с паролями и затем попытаться расшифровать пользовательские пароли офлайн, то есть на своем оборудовании или с помощью ботсети. Конечно, многие могут возразить, что подбор паролей – это достаточно продолжительный и трудоемкий процесс. Однако с ростом вычислительных мощностей и развитием соответствующих технологий подбор восьмизначного символьноцифрового пароля может занять считанные минуты. Но обо всем по порядку.

Начнем с того, где хранят пароли различные операционные системы. Начнем с семейства ОС Windows.

Получаем хеши

За хранение паролей здесь отвечает Security Accounts Manager (SAM) – файл реестра в Windows. В SAM хранятся хешированные пароли пользователей (в формате LM-хеш или NTLM-хеш). Благодаря тому, что хеш-функция однонаправленная, пароли находятся в относительной безопасности. Единственным способом узнать пароль является подбор хеша. Существует множество способов получения SAM-файла. По «условиям учений» будем считать, что наш злоумышленник не имеет физического доступа к атакуемым машинам и не может их перезагружать.

В случае если это не так (например, хакеру доступна консоль гипервизора, на котором работает виртуальный сервер), он вполне может воспользоваться загружаемым дистрибутивом, таким как наш Kali Linux.

При отсутствии доступа SAM-файл необходимо экспортировать из реестра с помощью консольных команд, представленных на рис. 1.

Рисунок 1. Экспорт SAM-файла в Windows 7

В случае если по каким-либо причинам выполнить экспорт хешей паролей не представляется возможным, можно попробовать применить утилиту Gsecdump. При ее использовании есть небольшая вероятность, что система «упадет» в BSOD, но зато эта утилита работает со всеми серверными ОС Windows (см. рис. 2).

Рисунок 2. Экспорт парольных хешей в Windows 2003

Для того чтобы получить парольные хеши в ОС Linux, необходимо иметь доступ на чтение к файлам /etc/passwd и /etc/shadow. Переписав эти файлы к себе, злоумышленник может приступать к взлому.

Взлом паролей и его особенности

На рис. 3 приведен пример запуска перебора паролей с помощью John the Ripper. Первой командой unshadow мы объединяем два полученных ранее файла, а затем запускаем перебор. Утилита сначала будет пытаться подобрать пароль по собственным словарям, а затем начнет перебор всех значений.

Однако более быстрым способом поиска паролей является использование аппаратных графических ускорителей (GPU). Это умеет утилита oclHashcat из пакета HashCat (есть в Kali Linux), используемого для аудита паролей. На сайте проекта приведены требования к GPU, с которыми работает oclHashcat. Помимо скорости, это также расширенные возможности по созданию правил перебора паролей. Перед запуском oclHashcat необходимо узнать алгоритм хеширования, с помощью которого создавался хеш.

В этом нам поможет таблица с сайта Hashcat, в которой, помимо прочего, приведены примеры хешей для различных алгоритмов.

Рисунок 4. Работа с Hashcat

Сам файл с хешами и результаты перебора располагаются в специальном каталоге, путь к которому указывается в настройках утилиты.

Из своего опыта могу сказать, что для одного и того же алгоритма хеширования перебор с помощью Hashcat и одного, не самого мощного, GPU занял в десять раз меньше времени, чем использование John the Ripper.

«Соленые» радужные таблицы

Однако перебор паролей можно ускорить еще во много раз, если использовать радужные таблицы (rainbow tables), предназначенные для обращения криптографических хешфункций, использующих механизм разумного компромисса между временем поиска по таблице и занимаемой памятью.

Данные таблицы можно генерировать самостоятельно с помощью пакета Rainbowcrack, входящего в состав Kali Linux (Password Attack → Rainbowcrack, далее rtgen). Однако лучше воспользоваться уже готовыми таблицами, которые можно скачать как на официальном сайте проекта, так и на просторах интернета.

Запуск перебора с помощью радужных таблиц (файлы с расширением rt) для файла с хешами passwords будет выглядеть следующим образом.

Все вышеизложенное хорошо до тех пор, пока в хеш пароля не добавляется «соль» (хеш = f (пароль + соль). В таком случае стандартные Rainbow tables нам не помогут, так как для восстановления такого пароля взломщику необходимы таблицы для всех возможных значений «соли». При этом «соль» должна быть достаточно длинной (шесть – восемь символов), иначе злоумышленник может вычислить таблицы для каждого значения «соли», случайной и различной для каждого пароля. Таким образом, два одинаковых пароля будут иметь разные значения хешей, если только не будет использоваться одинаковая «соль».

На сегодняшний день практически все *nix используют хеши с «солью» для хранения системных паролей. ОС Windows используют хеши LM-хеш и NTLM, которые не используют «соль». Таким образом, радужные таблицы являются наиболее действенным средством при аудите парольных файлов от данных ОС. Также многие приложения используют «несоленые» хеши. Это упрощает задачу взломщику.

Также дополню, что пароли от старых ОС Windows XP/ Vista хорошо ломает утилита 0phtcrack, входящая в состав Kali Linux.

Ищем сокровища

Запустив перебор файлов с паролями, самое время провести «инвентаризацию» взломанной сети. На этот момент многие администраторы не обращают внимание, а ведь благодаря

именно активности хакера взлом можно обнаружить. Для поиска интересного в сети злоумышленник использует различные инструменты, и многие из них мы уже рассматривали: сканер сети Nmap, сканеры уязвимостей Nessus и Ovasp. Также могут использоваться самописные скрипты, которые позволяют автоматизировать процесс поиска нужной информации, например поиска инстансов СУБД.

Пожалуй, самым распространенным местом, где можно найти что-то «полезное», являются расшаренные сетевые папки – файловые «помойки», использующие в своей работе протокол SMB. Помимо официальных корпоративных файловых ресурсов, многие продвинутые пользователи расшаривают ресурсы на своих локальных машинах. Обычно для того, чтобы передать другим сотрудникам какую-либо информацию. При этом доступ в эти папки может вообще не ограничиваться.

Существует множество различных приложений для поиска SMB-ресурсов. Мы воспользуемся утилитой enum4linux, входящей в состав Kali Linux. В качестве подопытного в примерах используется наш старый знакомый – уязвимый дистрибутив Metasploitable. Первым делом попробуем выяснить, какие учетные записи есть на данной машине.

Результат для Metasploitable будет примерно следующий (см. рис. 5).

Красным на рисунке подчеркнуты наиболее интересные для нас аккаунты. Теперь попробуем найти общие сетевые ресурсы на данной машине (см. рис. 6).

Как видно, не все папки доступны. Но злоумышленник может попытаться расшифровать пароли доменных пользователей теми средствами, которые я описывал выше. В случае если у нас нет хеша пароля или мы его еще не расшифровали, можно попробовать подобрать пароль онлайн.

Для подбора пароля воспользуемся утилитой acccheck. Обратите внимание на словарь, указанный в примере. Данный каталог со словарями по умолчанию входит в состав Kali (см. рис. 7).

Так злоумышленник может быстро узнать пароль от учетной записи и затем подключиться к найденным ресурсам.

Выносим добычу незаметно

Иногда причиной обнаружения утечек информации становится невнимательность злоумышленника, который, получив доступ к взломанной сети, теряет бдительность и начинает переписывать на свой локальный компьютер файлы в открытом виде. Если в атакованной сети имеются средства обнаружения утечек (DLP), то они вполне могут засечь данную активность.

Первое, что приходит в голову, – это, конечно же, шифрование. Но и тут хакера может ожидать сюрприз. Современные антивирусы и средства DLP могут при наличии соответствующих политик уведомлять администраторов об обнаружении запароленных архивов либо файлов, чей формат не удалось распознать. В таком случае хакеру необходимо спрятать награбленное внутри какого-либо легального файла (картинки, аудиоили видеофайла) и в таком виде передать наружу. Данная технология называется стеганография. В статье она достаточно подробно расписана, поэтому здесь теория рассматриваться не будет. Перейдем сразу к практике.

В качестве примера спрячем содержимое текстового файла в картинках JPEG с помощью утилиты steghide. Данная программа распространяется в виде исходников на С и может работать как под Windows, так и под Linux, так что злоумышленник вполне сможет ее незаметно развернуть на одной из машин в сети жертвы. Все, что нужно для работы, – это JPEG-файл с большим разрешением, файл со скрываемой информацией и пароль для шифрования и сокрытия.

А извлечь данные в файл test.txt можно следующим образом:

Таким образом, злоумышленник может попытаться передать украденные данные из корпоративной сети.

Скрываем следы преступления

Одной из основных задач, которую должен решить злоумышленник как после проникновения в сеть, так и в процессе своего нахождения в ней, – это сокрытие следов своей деятельности. Здесь его главным врагом являются журналы событий операционных систем и приложений.

Операционные системы семейства Windows 2000, XP, 2003 хранят журналы событий в файлах формата EVT в каталоге c:\Windows\System32\config. ОС Windows Vista – 2012 в формате EVTX в каталоге c:\Windows\System32\ winevt\Logs.

Я не буду подробно рассматривать форматы EVT и EVTX. Желающие могут самостоятельно найти необходимую информацию в MSDN. Нас больше интересует то, что в EVT целостность ничего не гарантирует, необходимо лишь, чтобы длина записей совпадала. Для проверки достаточно открыть evt-файл в любом шестнадцатеричном редакторе и заменить, к примеру, несколько байт в имени пользователя.

С EVTX все немного сложнее. Здесь разработчики озадачились вопросами защиты информации и добавили контроль целостности журналов событий, так что простая замена байтов приведет лишь к ошибке при открытии файла

журнала. Для контроля целостности используется алгоритм CRC32, поэтому при изменении журнала необходимо заново пересчитывать контрольную сумму. Но злоумышленник может скрыть информацию о своих действиях, не нарушая целостности файлов журналов.

Для подмены журналов событий нам необходимо выполнить два основных действия: создание копии файла журналов, не содержащего «интересных» событий и подмену легального файла на нашу копию. Необходимость второго действия обусловлена тем, что *.evtx-файлы нельзя просто заменить, так как система постоянно использует их в работе.

Рассмотрим создание копии evtx-файла. Будем считать, что нам доступна только командная строка, соответственно, мы можем использовать только консольные команды.

Допустим, нам нужно удалить все записи, связанные с удачным входом в систему (событие 4624). Для этого из текущего evtx-файла экспортируем все записи, кроме 4624.

Команда wevtutil отвечает за работу с журналом событий. Ключ epl – это экспорт из файла Security d в файл Security.evtx с перезаписью. Далее мы запрашиваем все события, кроме 4624.

Синтаксис этих запросов можно легко узнать в оснастке Журнал событий. Выбираем Фильтр текущего журнала, в открывшемся окне заполняем нужные поля, а дальше выбираем вкладку XML. Вот и нужный запрос. Да, я помню, что мы договорились работать только в консоли, но кто мешает злоумышленнику сделать эти действия у себя на стенде.

Теперь вторая часть. Здесь нам потребуется утилита Handle из состава Sysinternals. Для того чтобы перезаписать файл, необходимо сначала остановить все те процессы, которые с ним работают. Узнаем с помощью handle ID процессы, которые с ней работают. Далее по ID процесса узнаем те службы, которые его используют с помощью tasklist. И, наконец, самое простое – остановим эти службы. Пример всех этих действий для 64-битной Windows 7 приведен на рис. 8.

Рисунок 8. Останавливаем сервисы

Далее остается только подменить файлы и заново запустить сервисы. Как видно, для подмены содержимого журнала событий нам не требуется никаких специализированных хакерских средств. Понятно, что для успешного выполнения всех приведенных действий необходимо наличие соответствующих прав. Но подмена логов производится уже после компрометации системы, когда необходимые права уже получены. Так что не стоит рассчитывать на записи журналов скомпрометированного узла.

Делаем выводы

Если злоумышленник уже проник в сеть и скомпрометировал один или несколько узлов, он предпримет максимальные усилия для того, чтобы скрыть свою активность. Однако правильно настроенные средства защиты могут помочь обнаружить аномалии. Основным инструментом для обнаружения подозрительной активности является Система управления событиями безопасности (SIEM). Именно в эту системы должны стекаться события со всех источников (ОС, межсетевые экраны, IDS, антивирусы, DLP и т.д.). Все описанные манипуляции с журналами событий будут бесполезны, если все события будут пересылаться в базу SIEM.

Как SIEM может узнать о действиях злоумышленника, описанных в этой статье? Попытка получить доступ к реестру отразится в журналах событий ОС, и соответствующее событие будет передано в SIEM. Для этого необходимо лишь настроить аудит обращений к реестру и файлам с паролями.

Еще одним нашим помощником может стать система DLP, точнее, ее агенты, развернутые на узлах. Вполне возможно, что хакеру придется переписать файл с паролями с одной машины в атакуемой сети на другую, где развернуты средства стеганографии. В этот момент хостовая DLP может обнаружить попытку копирования конфиденциальной информации и переслать уведомление в SIEM.

Ну и классика работы SIEM: обнаружение входов с систему в нерабочее время, не с тех узлов и не к тем узлам, что обычно, вход при отсутствии в офисе и т.д. Злоумышленник, расшифровав пароль, наверняка попытается войти в систему под ним. Если он это будет делать в нерабочее время и/или не с машины данного пользователя при его отсутствии в офисе (в СКУД не зафиксирован вход в здание), то должен быть создан соответствующий инцидент.

Инвентаризация, так или иначе, связана с обходом большого числа ресурсов (узлы, папки, файлы и т.д.). Эти активности могут быть зафиксированы как журналами событий ОС на узлах, так и средствами обнаружения вторжений в сети. Поэтому здесь достаточно просто настроить сбор событий от источников и соответствующие правила. Но здесь важно помнить, что включение аудита для всех файлов и обращений ко всем объектам в Windows приведет к лавинообразному росту числа событий, так что тут главное не перестараться.

Следующим шагом является выгрузка собранной информации. Злоумышленник может прибегнуть к стеганографии или другим механизмам сокрытия своих действий. Следовательно, рассчитывать на функционал DLP здесь не приходится. Поэтому лучше анализировать подозрительную активность. Например, в случае если доступ в интернет осуществляется через прокси, полезно будет собирать статистику, кто, какой трафик и в каком объеме передает в сеть. Загрузка большого числа картинок или видео в высоком качестве может быть признаком использования стеганографии.

Манипуляции с логами. Хакер будет теми или иными средствами пытаться удалить или модифицировать журналы событий. В случае если все события идут в SIEM злоумышленнику будет крайне сложно скрыть что-либо из своих действий. В системе управления событиями необходимо настроить правила реагирования на сообщения, связанные с удалением, переполнением или экспортом логов. Тогда любая активность, связанная с попыткой изменения логов на локальных машинах, будет немедленно обнаружена.

В целом грамотно настроенная SIEM-система способна существенно осложнить жизнь злоумышленнику.

Источник