Русский
Русский
English
Статистика
Реклама

Clm

Как снизить стоимость владения SIEM-системой и зачем нужен Central Log Management (CLM)

29.07.2020 08:08:02 | Автор: admin
Не так давно, Splunk добавил ещё одну модель лицензирования лицензирование на основе инфраструктуры (теперь их три). Они считают количество ядер CPU под серверами со Splunk. Очень напоминает лицензирование Elastic Stack, там считают количество нод Elasticsearch. SIEM-системы традиционно недешёвое удовольствие и обычно стоит выбор между заплатить много и очень много. Но, если применить смекалочку, можно собрать подобную конструкцию.

image

Выглядит крипово, но иногда такая архитектура работает в проде. Сложность убивает безопасность, а, в общем случае, убивает всё. На самом деле, для подобных кейсов (я про снижение стоимости владения) существует целый класс систем Central Log Management (CLM). Об этом пишет Gartner, считая их недооценёнными. Вот их рекомендации:

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


В этой статье поговорим о различиях подходов к лицензированию, разберёмся с CLM и расскажем о конкретной системе такого класса Quest InTrust. Подробности под катом.

В начале этой статьи я рассказал о новом подходе к лицензированию Splunk. Виды лицензирования можно сравнить с тарифами на прокат автомобилей. Давайте представим, что модель по количеству CPU это экономичный автомобиль с неограниченным пробегом и бензином. Можно ехать куда угодно без ограничений по расстоянию, но нельзя ехать очень быстро и, соответственно, проезжать много километров в день. Лицензирование по объёму данных похоже на спортивный автомобиль с моделью оплаты по ежедневному километражу. Можно лихо наваливать и на большие расстояния, но за превышение дневного лимита километража придется заплатить больше.



Чтобы получить выгоду от использования лицензирования по нагрузке, нужно иметь наименьшее возможное соотношение ядер CPU к количеству загружаемых ГБ данных. На практике это означает что-то типа:

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

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

Лицензирование по объему данных основывается на количестве данных, которые отправляются в пасть SIEM. Дополнительные источники данных наказуемы рублём (или другой валютой) и это заставляет задуматься о том, что не очень-то и хотелось собирать. Чтобы обхитрить такую модель лицензирования, можно обкусать данные до их инжекции в SIEM-систему. Один из примеров такой нормализации перед инжекцией Elastic Stack и некоторые другие коммерческие SIEM.

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

  • Упрощение агрегации и нормализации данных.
  • Фильтрация шумовых и наименее важных данных.
  • Предоставление возможностей анализа.
  • Отправка отфильтрованных и нормализованных данных в SIEM

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

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

То самое загадочное промежуточное решение не что иное как CLM, о котором я упоминал в начале статьи. Вот таким его видит Gartner:

image

Теперь можно попробовать разобраться насколько InTrust соответствует рекомендациям Gartner:

  • Эффективное хранилище для тех объёмов и типов данных, которые нужно хранить.
  • Высокая скорость поиска.
  • Возможности визуализации не то, что требуется для базового CLM, но поиск угроз это как BI-система для обеспечения безопасности и анализа данных.
  • Обогащение данных для дополнения необработанных данных полезными контекстными данными (вроде геолокации и других).

Quest InTrust использует собственную систему хранения со сжатием данных до 40:1 и высокой скоростью дедупликации, что снижает накладные расходны на хранением для систем CLM и SIEM.

image
Консоль IT Security Search c google-like поиском

Специализированный модуль с веб-интерфейсом IT Security Search (ITSS) может подключаться к данным о событиях в репозитории InTrust и предоставляет простой интерфейс для поиска угроз. Интерфейс упрощен до такой степени, что работает как Google для данных журнала событий. ITSS использует временные шкалы для результатов запроса, может объединять и группировать поля событий и эффективно помогает при поиске угроз.

InTrust обогащает события Windows идентификаторами безопасности, именами файлов и идентификаторами входа в систему безопасности. InTrust также нормализует события к простой схеме W6 (Who, What, Where, When, Whom и Where From кто, что, где, когда, кого и откуда), чтобы данные из разных источников (собственные события Windows, логи Linux или syslog) можно было видеть в едином формате и на единой консоли поиска.

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

  • Password-spraying.
  • Kerberoasting.
  • Подозрительная PowerShell-активность, например, исполнение Mimikatz.
  • Подозрительны процессы, например, LokerGoga ransomware.
  • Шифрование с использованием логов CA4FS.
  • Входы с привелигерированным аккаунтом на рабочих станциях.
  • Атаки с подбором пароля.
  • Подозрительное использование локальных групп м пользователей.


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


Преодпределённые фильтры для поиска потенциальных уязвимостей




Пример набора фильтров для сбора сырых данных




Пример использования регулярных выражений для создания реакции на событие




Пример с правилом поиска уязвимостей PowerShell




Встроенная база знаний с описанием уязвимостей

InTrust это мощный инструмент, который можно использовать как самостоятельное решение так и в составе SIEM-системы, как я описал выше. Наверное, основное преимущество этого решения, что его можно начинать использовать сразу после установки, т.к. InTrust имеет большую библиотеку правил обнаружения угроз и реакций на них (например, блокировки пользователя).

В статье я не рассказал о коробочных интеграциях. Но сразу после установки можно настроить отправку событий в Splunk, IBM QRadar, Microfocus Arcsight или через вебхук в любую другую систему. Ниже пример интерфейса Kibana с событиями из InTrust. С Elastic Stack интеграция уже тоже есть и, если вы используете бесплатную версию Elastic, InTrust может использоваться как инструмент для выявления угроз, выполнения упреждающих оповещений и отправке уведомлений.

image

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

Почитайте другие наши статьи по теме информационной безопасности:

Выявляем атаку вируса-шифровальщика, получаем доступ к контроллеру домена и пробуем противостоять этим атакам

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows (популярная статья)

Отслеживание жизненного цикла пользователей без плоскогубцев и изоленты

А кто это сделал? Автоматизируем аудит информационной безопасности
Подробнее..

Как InTrust может помочь снизить частоту неудачных попыток авторизаций через RDP

30.07.2020 20:10:43 | Автор: admin
image

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

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

В Quest InTrust можно настроить ответные действия при срабатывании правила. С агента-сборщика логов InTrust получает сообщение о неудачной попытке авторизации на рабочей станции или сервере. Чтобы настроить добавление новых IP-адресов в брандмауэр, необходимо скопировать существующее специализированное правило обнаружения множественных неудачных авторизаций и открыть его копию для редактирования:

image

События в журналах Windows используют так называемые InsertionString. Посмотрите соответствия для события с кодом 4625 (это неудачный логон в систему) и увидите, что интересующие нас поля хранятся в InsertionString14 (Workstation Name) и InsertionString20 (Source Network Address), При атаке из интернета, поле с Workstation Name будет, скорее всего, пустым, поэтому важно на это место подставить значение из Source Network Address.

Примерно так выглядит текст события 4625
An account failed to log on.Subject:Security ID:S-1-5-21-1135140816-2109348461-2107143693-500Account Name:ALebovskyAccount Domain:LOGISTICSLogon ID:0x2a88aLogon Type:2Account For Which Logon Failed:Security ID:S-1-0-0Account Name:PaulAccount Domain:LOGISTICSFailure Information:Failure Reason:Account locked out.Status:0xc0000234Sub Status:0x0Process Information:Caller Process ID:0x3f8Caller Process Name:C:\Windows\System32\svchost.exeNetwork Information:Workstation Name:DCC1Source Network Address:::1Source Port:0Detailed Authentication Information:Logon Process:seclogoAuthentication Package:NegotiateTransited Services:-Package Name (NTLM only):-Key Length:0This event is generated when a logon request fails. It is generated on the computer where access was attempted.The Subject fields indicate the account on the local system which requested the logon. This is most commonly a service such as the Server service, or a local process such as Winlogon.exe or Services.exe.The Logon Type field indicates the kind of logon that was requested. The most common types are 2 (interactive) and 3 (network).The Process Information fields indicate which account and process on the system requested the logon.The Network Information fields indicate where a remote logon request originated. Workstation name is not always available and may be left blank in some cases.The authentication information fields provide detailed information about this specific logon request.- Transited services indicate which intermediate services have participated in this logon request.- Package name indicates which sub-protocol was used among the NTLM protocols.- Key length indicates the length of the generated session key. This will be 0 if no session key was requested.


Дополнительно, добавим значение Source Network Address в текст события.

image

Затем нужно добавить скрипт, который будет блокировать IP-адрес в брандмауэре Windows. Ниже пример, который для этого можно использовать.

Скрипт для настройки брандмауэра
param(         [Parameter(Mandatory = $true)]         [ValidateNotNullOrEmpty()]            [string]         $SourceAddress)$SourceAddress = $SourceAddress.Trim()$ErrorActionPreference = 'Stop'$ruleName = 'Quest-InTrust-Block-Failed-Logons'$ruleDisplayName = 'Quest InTrust: Blocks IP addresses from failed logons'function Get-BlockedIps {    (Get-NetFirewallRule -Name $ruleName -ErrorAction SilentlyContinue | get-netfirewalladdressfilter).RemoteAddress}$blockedIps = Get-BlockedIps$allIps = [array]$SourceAddress + [array]$blockedIps | Select-Object -Unique | Sort-Objectif (Get-NetFirewallRule -Name $ruleName -ErrorAction SilentlyContinue) {    Set-NetFirewallRule -Name $ruleName -RemoteAddress $allIps} else {    New-NetFirewallRule -Name $ruleName -DisplayName $ruleDisplayName -Direction Inbound -Action Block -RemoteAddress $allIps}


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

image

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

image

После выполненных настроек, количество неудачных авторизаций снизилось на 80%. Профит? Ещё какой!

image

Иногда небольшой рост возникает снова, но это из-за появления новых источников атак. Потом всё снова идёт на спад.

За неделю работы в правило брандмауэра попало 66 IP-адресов.

image

Ниже таблица с 10 частыми именами пользователей, которые использовались для попыток авторизаций.
Имя пользователя
Количество
В процентах
administrator
1220235
40.78
admin
672109
22.46
user
219870
7.35
contoso
126088
4.21
contoso.com
73048
2.44
administrador
55319
1.85
server
39403
1.32
sgazlabdc01.contoso.com
32177
1.08
administrateur
32377
1.08
sgazlabdc01
31259
1.04

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

Если интересно посмотреть InTrust в работе, оставьте заявку в форме обратной связи на нашем сайте или напишите мне в личку.

Почитайте другие наши статьи по теме информационной безопасности:

Выявляем атаку вируса-шифровальщика, получаем доступ к контроллеру домена и пробуем противостоять этим атакам

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows (популярная статья)

Отслеживание жизненного цикла пользователей без плоскогубцев и изоленты

А кто это сделал? Автоматизируем аудит информационной безопасности

Как снизить стоимость владения SIEM-системой и зачем нужен Central Log Management (CLM)
Подробнее..

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

04.08.2020 12:21:41 | Автор: admin


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

Дополнительный фактор легитимности криптографическая подпись: многие оригинальные программы подписаны вендором. Можно использовать факт отсутствия подписи как метод выявления подозрительных элементов автозагрузки. Но опять же есть вредоносное ПО, которое использует украденный сертификат, чтобы подписать самого себя.

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

Признаков злонамеренного процесса может быть масса. В этой статье мы расскажем как включить аудит соответствующих событий в Windows, разберём признаки, на которые опирается встроенное правило InTrust для выявление подозрительного процесса. InTrust это CLM-платформа для сбора, анализа и хранения неструктурированных данных, в которой есть уже сотни предустановленных реакций на различные типы атак.

При запуске программы, она загружается в память компьютера. Исполняемый файл содержит компьютерные инструкции и вспомогательные библиотеки (например, *.dll). Когда процесс уже запущен, он может создавать дополнительные потоки. Потоки позволяют процессу выполнять разные наборы инструкций одновременно. Существует много способов проникновения вредоносного кода в память и его запуска, рассмотрим некоторые из них.

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

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

Файл можно указать, используя полный путь (например, C:\Windows\system32\cmd.exe) или неполный (например, cmd.exe). Если исходный процесс небезопасен, он позволит запускать нелегитимные программы. Атака может выглядеть так: процесс запускает cmd.exe без указания полного пути, злоумышленник помещает свой cmd.exe в такое место, чтобы процесс запустил его раньше легитимного. После запуска вредоносной программы она, в свою очередь, может запустить легитимную программу (например, C:\Windows\system32\cmd.exe), чтобы исходная программа продолжала работать должным образом.

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

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

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

image

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

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

image

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

image

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

image

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

image

В цепочке своих действий 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 автоматически распространит его.

image

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

image

В InTrust есть сотни других правил, некоторые из них:

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

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

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

Почитайте другие наши статьи по теме информационной безопасности:

Как InTrust может помочь снизить частоту неудачных попыток авторизаций через RDP

Выявляем атаку вируса-шифровальщика, получаем доступ к контроллеру домена и пробуем противостоять этим атакам

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows (популярная статья)

Отслеживание жизненного цикла пользователей без плоскогубцев и изоленты

А кто это сделал? Автоматизируем аудит информационной безопасности

Как снизить стоимость владения SIEM-системой и зачем нужен Central Log Management (CLM)
Подробнее..

Sysmon теперь может записывать содержимое буфера обмена

21.09.2020 16:09:27 | Автор: admin
О релизе 12 версии Sysmon сообщили 17 сентября на странице Sysinternals. На самом деле в этот день вышли также новые версии Process Monitor и ProcDump. В этой статье я расскажу о ключевом и неоднозначном нововведении 12 версии Sysmon типе событий с Event ID 24, в который логируется работа с буфером обмена.



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

Новое событие содержит следующие поля:

Image: процесс, данные из которого были записаны в буфер обмена.
Session: сеанс, в котором выполнилась запись в буфер обмена. Это может быть system(0)
при работе в интерактивном или удаленном режиме и т.д.
ClientInfo: содержит имя пользователя сеанса, а в случае удаленного сеанса исходное имя хоста и IP-адрес, если эти данные доступны.
Hashes: определяет имя файла, в котором был сохранен скопированный текст (аналогично работе с событиями типа FileDelete).
Archived: статус, был ли сохранен текст из буфера обмена в архивной директории Sysmon.

Пара последних полей вызывают тревогу. Дело в том, что с версии 11 Sysmon может (при соответствующих настройках) сохранять разные данные в свою архивную директорию. Например, Event ID 23 логирует в себя события по удалению файлов и может их сохранять всё в той же архивной директории. К имени файлов, созданных в результате работы с буфером обмена, добавляется тег CLIP. Сами файлы содержат точные данные, которые были скопированы в буфер обмена.

Так выглядит сохраненный файл
image

Сохранение в файл включается при установке. Можно устанавливать белые списки процессов, по которым текст сохраняться не будет.

Так выглядит установка Sysmon с соответствующей настройкой архивной директории:
image

Тут, я думаю, стоит вспомнить о менеджерах паролей, которые также используют буфер обмена. Наличие Sysmon в системе с менеджером паролей позволит вам (или злоумышленнику) захватывать эти пароли. Если допустить, что вам известно какой именно процесс аллоцирует скопированный текст (а это не всегда процесс менеджера паролей, а может быть какой-нибудь svchost), это исключение можно добавить в белый список и не сохранять.

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

Подведем итог возможностей Sysmon по работе с буфером обмена.

Фиксируются:

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

Не фиксируются:

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


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

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

Чтобы узнать подробнее про InTrust, прочитайте наши предыдущие статьи или оставьте заявку в форме обратной связи.

Как снизить стоимость владения SIEM-системой и зачем нужен Central Log Management (CLM)

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

Как InTrust может помочь снизить частоту неудачных попыток авторизаций через RDP

Выявляем атаку вируса-шифровальщика, получаем доступ к контроллеру домена и пробуем противостоять этим атакам

Что полезного можно вытащить из логов рабочей станции на базе ОС Windows (популярная статья)

А кто это сделал? Автоматизируем аудит информационной безопасности
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru