Фильтр журнала windows по пользователю

В Windows Server 2003 / Windows XP в журнале событий системы можно было с легкостью отфильтровать события по учетной записи конкретного пользователя, указав в фильтре в поле User фильтра журнала имя нужной учетной записи. Но в Windows Server 2008 / Windows 7 и выше этот простой способ найти события, связанные с конкретным пользователем, не работает, хотя в настройках фильтра само поле User имеется (видимо осталось по-старинке).

В Windows Server 2008 в стандартном виде журнала событий отсутствует поле User. Попробуем добавить его с помощью меню View -> Add/Remove Columns.

Теперь в представлении журнала появился столбец User, но имени пользователя, инициатора события в этом столбце нет, вместо этого отображается N/A. Иформация об учетной записи теперь содержится внутри описания самого события ( в значениях атрибутов Security ID и Account Name в данном примере). Как же теперь можно отфильтровать события в журнале? Для фильтрации событий по имени учетной записи пользователя ( и любым другим атрибутам событий), в Windows Server 2008 (и выше) можно воспользоваться возможность ручной модификации XML запросов (XPath) на выборку.

Итак, откройте нужный журнал в Event View (в нашем примере это журнал Security) и в контекстном меню выберите пункт Filter Current Log….

Перейдите на вкладку XML и отметьте чекбокс Edit query manually.

Скопируйте следующий код, позволяющий выбрать из журнала все события по конкретному пользователю (замените username на нужную учетку).

<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">* [EventData[Data[@Name='subjectUsername']='username']]</Select>
</Query>
</QueryList>

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

Если, к примеру, нужно дополнительно отфильтровать события по пользователю и Event ID 4624 (Удачный вход — An account was successfully logged on) и 4625 (неудачный вход — An account failed to log on.), фильтр XPath может выглядеть так:

<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">*[System[(EventID=4624 or EventID=4625)]]</Select>
<Select Path="Security">* [EventData[Data[@Name='subjectUsername']='username']]</Select>
</Query>


</QueryList>

Текстовая версия выступления на PHD11

Пару слов о проблеме

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

Live response — это область, которая занимается сбором информации с работающего компьютера, чтобы определить, произошел ли инцидент.

При проведении live response анализа, полезно быстро понять, что происходило с компьютером в последнее время.

Существуют различные инструменты для проведения live response: коммерческие, с открытым исходным кодом и встроенные возможности ОС.

Использование opensource и коммерческих инструментов связано с рядом проблем:

• Утилиты могут отправлять телеметрию разработчику

• Отсутствие описания анализируемых журналов и EventId

Неудобство фильтрации оснасткой eventvwr.msc

Фильтрация evtx с помощью стандартной оснастки просмотра событий (eventvwr.msc) ограничена в возможностях.

Проблемы:

• отсутствует возможность вывести информацию в колонках

• отсутствуют регулярные выражения и поиск подстрок

• отсутствует группировка

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

Одним из основных ограничений XPath 1.0 является то, что он не поддерживает поиск по атрибутам. То есть, если вы хотите найти события, связанные с определенным EventID, вы можете воспользоваться элементом EventID, но вы не сможете использовать атрибуты, вложенных элементов для поиска событий, например: TargetUserName.

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

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

Как показано выше, узлы «Элемент» могут содержать «Атрибуты», и мы можем использовать подстановочный знак «@» для поиска узлов «Data».

Пример ниже позволяет найти все события из журнала Security c EventID = 4688. Атрибут Path в директиве Query можно опустить. Путь к журналу указывается в в атрибуте Path директивы Select.

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[EventID=4688]]</Select>
  </Query>
</QueryList>

В пример ниже добавляем использования логического оператора OR для поиска события с EventID 4688 или 4624.

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[EventID=4688 or EventID=4624]]</Select>
  </Query>
</QueryList>

В следующем примере добавим фильтрацию по разделу XML — EventData. Для объединения двух условий в одном Select используется логический оператор AND. Вторая часть запроса начинается со знака *, который означает что верхний узел может принимать любое значение, далее мы указываем путь к атрибуту значение которого хотим указать в условии EventData -> Data -> @Атрибут=»значение».

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[EventID=4688]] and 
             *[EventData[Data[@Name="SubjectUserName"]="hacker"]]</Select>
  </Query>
</QueryList>

XPath позволяет искать значение по всем атрибутам, как в примере ниже. Структура указанные выше изменилась до EventData -> Data -> @Атрибут =»значение». Следующим запросам мы найдем все события где в атрибутах фигурировало «C:\Windows\System32\lsass.exe»

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[EventID=4688]] and 
*[EventData[Data="C:\Windows\System32\lsass.exe"]]</Select>
  </Query>
</QueryList>

Оператор Suppress позволяет исключить из конечной выборки события, которые подходят под условие в нем. В примере ниже, мы найдем все события 4624, в которых LogonType=5.

<QueryList>
  <Query Id="0" Path="Security">
    <Select Path="Security">*[System[EventID=4624]]</Select>
    <Suppress Path="Security">*[EventData[Data[@Name='LogonType']=5]]</Suppress>
  </Query>
</QueryList>

В пределах одного Query мы можем указывать несколько Select-запросов, также есть возможность запрашивать события из разных журналов.

<QueryList>
  <Query Id="0">
    <Select Path="Security">*[System[EventID=4688]]</Select>
    <Select Path="Windows PowerShell">*</Select>
  </Query>
</QueryList>

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

<QueryList>
    <Query Id="0" Path="Security">
        <Select Path="Security">*[System[EventID=4688]]</Select>
    </Query>
    <Query Id="1" Path="Microsoft-Windows-Sysmon/Operational">
        <Select Path="Microsoft-Windows-Sysmon/Operational">*</Select>
    </Query>
</QueryList>

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

Возможности CMD

Возможности CMD ограничены использованием двух основных утилит wevtutil и Findstr. wevtutil позволяет работать с параметрами журналов и создавать к ним запросы. Для запросов в wevtutil также используются XPath-запросы.

wevtutil.exe qe Security /q:"*[EventData[Data[@Name='TargetUserName']='User1' and Data[@Name='LogonType']=2]]" /f:text

При использовании findstr, наши возможности расширяются для поиска интересующих нас строк.

wevtutil.exe qe Security /q:"*[EventData[Data[@Name='LogonType']=11]]" /f:text | findstr "Account Name"

Возможности PowerShell

В Powershell для работы с журналами существуют два командлета Get-EventLog и Get-WinEvent. Мы рассмотри второй командлет так как он считается актуальным.

Основные возможности Get-WinEvent это использование хеш-таблиц и Xpath для фильтрации событий. Для использование хеш-таблиц используется аргумент -FilterHashtable, его можно опустить и строить запрос сразу с @{<выражение>}.

Рассмотрим несколько примеров использования командлета Get-WinEvent и построения конвейеров с ним.

Следующим примером мы выведем 1000 событий из журнала Security.

Get-WinEvent -LogName Security -MaxEvents 1000

Тот же запрос, но используем Format-List для приведения вывода в читаемый.

Get-WinEvent -LogName Secutity -MaxEvents 10 | Format-List

Используем FilterHashtable. Выведем события из журнала Security с EventId 4688.

Get-WinEvent @{logname="security";ID=4688} -MaxEvents 100 | Format-List

Для понимания дальнейших фильтров давайте посмотрим как представлено событие в Powershell, для этого выведем одно событие и воспользуемся командлетом Get-Member.

Get-WinEvent @{logname="security";ID=4688} -MaxEvents 1 | Get-Member

Свойство Properties — это список, который хранит основные параметры события, которые расположены в секции EventData xml-представления.

После того, как мы научились получать события из определенного журнала и по определенному EventId, давайте посмотрим каким образом мы можем получить интересующие нас данные. Давайте выведем события 4688, и отобразим время создания события и {$_.Properties[5].value}, которое хранит имя запущенного процесса. Номер элемента списка Properties соответствует номеру атрибута в секции EventData xml-представления события.

Get-WinEvent @{logname="security";ID=4688} -MaxEvents 100 | 
select timecreated,{$_.Properties[5].value} | Format-List

Powershell позволяет нам создавать группировки, используя командлет Group-Object. Следующим запросом сгруппируем события Sysmon EventId 3 по следующим полям: процесс, адрес получателя, доменное имя получателя, порт получателя.

Get-WinEvent @{LogName="*sysmon*";ID=3}  -MaxEvents 10000 | 
Where-Object {$_.Properties[16].Value -ne 443} | 
Group-Object {$_.Properties[4].Value},{$_.Properties[14].Value}, {$_.Properties[15].Value}, {$_.Properties[16].Value} | 
Select-Object Name, Count | Sort-Object Count -Descending  | Format-List

Для поиска подстрок можем воспользоваться -Match или -Like.

Get-WinEvent @{LogName="*sysmon*";ID=1}  -MaxEvents 1000 | 
Where-Object {$_.Properties[10].Value -Match ".*cmd.exe" }  | 
Select-Object {$_.Properties[10].Value} | 
Format-List

Поиска событий с известным значением атрибута выполняется быстрее при использовании XPath запросов, чем конвейеров Powershell. Например: запрос ниже найдет все события, связанные с пользователем R00t1k\Vadim.

Get-WinEvent -LogName *Sysmon* -FilterXPath "*[EventData[Data[@Name='User']='LAB\vadim']]" | 
Where-Object {$_.Properties[4].Value -Match ".*WINWORD.exe"} | 
Format-List

Poweshell позволяет представить сообщение в виде xml, выполнив следующий код.

$eventlog = Get-WinEvent -FilterHashtable @{LogName="Security";ID=4624} -MaxEvents 1
$xml = [xml]$eventlog.ToXml()
$xml.Event.EventData.Data

Модуль Powershell Convert-EventLogRecord преобразовывает события в структуру данных, которая позволяет обращаться к атрибутам по их имени. Конвейер для фильтрации событий с Convert-EventLogRecord будет выполняться в 2-3 раза дольше, в отличие от ковейера без его использования.

# С использованием Convert-EventLogRecord
Get-WinEvent -FilterHashtable @{LogName="Security";ID=4624} | 
Convert-EventLogRecord | Where-Object LogonType -ne 5 | 
Select TimeCreated, TargetUserName, LogonType

# Без использования Convert-EventLogRecord
Get-WinEvent @{LogName="Security";Id=4624} | 
Where-Object {$_.Properties[8].Value -ne 5} | 
Select TimeCreated, {$_.Properties[5].Value}, {$_.Properties[8].Value}

Используя командлет Out-GridView мы можем вывести события в виде таблицы.

Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624} |
    Select-Object TimeCreated, 
@{Name='User'; Expression={$_.Properties[5].Value}}, 
@{Name='LogonType'; Expression={$_.Properties[8].Value}},
@{Name='SrcIp'; Expression={$_.Properties[18].Value}}  |
    Out-GridView

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

 Get-WinEvent -FilterHashtable @{LogName='Security'; ID=4624, 4688} -MaxEvents 1000 | Where-Object {$_.Properties[8].Value -ne 5} |
    ForEach-Object {
        if ($_.Id -eq 4624) {
            $Username = $_.Properties[5].Value
            $LogonType = $_.Properties[8].Value
            $LogonProcess = $_.Properties[9].Value
            $IpAddress = $_.Properties[18].Value
        }
        elseif ($_.Id -eq 4688) {
            $SubjectUserName = $_.Properties[1].Value
            $SubjectUserDomain = $_.Properties[2].Value
            $NewProcessName = $_.Properties[5].Value
            $CommandLine= $_.Properties[8].Value
            $ParrentProcessName= $_.Properties[13].Value
        }
        [PSCustomObject]@{
            Time = $_.TimeCreated
            EventID = $_.Id
            Username = $Username
            LogonType = $LogonType
            LogonProcess = $LogonProcess
            IpAddress = $IpAddress
            SubjectUserName = $SubjectUserName
            SubjectUserDomain = $SubjectUserDomain
            NewProcessName = $NewProcessName
            CommandLine = $CommandLine
            ParrentProcessName = $ParrentProcessName
                    }
    } | Out-GridView

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

Какими утилитами при реагировании на инциденты Вы пользуетесь?

Проголосовал 21 пользователь.

Воздержались 10 пользователей.

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

<QueryList>
<Query Id="0" Path="Security">
<Select Path="Security">* [EventData[Data[@Name='TargetUserName']='user_io']]</Select>
</Query>
</QueryList>

win, журнал, фильтр

Microsoft

First published on TechNet on Sep 26, 2011

Hi guys,

Joji Oshima

here again. Today I want to talk about using

Custom Views

in the

Windows Event Viewer

to filter events more effectively. The standard GUI allows some basic filtering, but you have the ability to drill down further to get the most relevant data.


Starting in Windows Vista/2008, you have the ability to modify the XML query used to generate Custom Views.

Limitations of basic filtering:

Basic filtering allows you to display events that meet certain criteria. You can filter by the event level, the source of the event, the Event ID, certain keywords, and the originating user/computer.

Basic Filter for Event 4663 of the security event logs

You can choose multiple events that match your criteria as well.

Basic filter for Event 4660 & 4663 of the security event logs

A real limitation to this type of filtering is the data inside each event can be very different. 4663 events appear when auditing users accessing objects. You can see the account of the user, and what object they were accessing.

Sample 4663 events for users ‘test5’ and ‘test9’

If you want to see events that are only about user ‘test9’, you need a Custom View and an XML filter.

Using XML filtering and Custom Views:

Custom Views using XML filtering are a powerful way to drill through event logs and only display the information you need. With Custom Views, you can filter on data in the event. To create a Custom View based on the username, right click

Custom Views

in the

Event Viewer

and choose

Create Custom View

.

Click the

XML

Tab, and check

Edit query manually

. Click

ok

to the warning popup. In this window, you can type an XML query. For this example, we want to filter by SubjectUserName, so the XML query is:

<QueryList>

<Query Id=»0″>

<Select Path=»Security»>

*[EventData[Data[@Name=’SubjectUserName’] and (Data=’test9′)]]

</Select>

</Query>

</QueryList>

After you type in your query, click the

Ok

button. A new window will ask for a

Name

&

Description

for the Custom View. Add a descriptive name and click the

Ok

button.

You now have a Custom View for any security events that involve the user

test9

.

Take It One Step Further:

Now that we’ve gone over a simple example, let’s look at the query we are building and what else we can do with it. Using XML, we are building a SELECT statement to pull events that meet the criteria we specify. Using the standard AND/OR Boolean operators, we can expand upon the simple example to pull more events or to refine the list.

<QueryList>

<Query Id=»0″>

<Select Path=»Security»>

*[EventData[Data[@Name=’SubjectUserName’] and (Data=’test5′ or Data=’test9’)]]

</Select>

</Query>

</QueryList>

Event Metadata:

At this point you may be asking, where did you come up with SubjectUserName and what else can I filter on? The easiest way to find this data is to find a specific event, click on the details tab, and then click the XML View radio button.

From this window, we can see the structure of the Event’s XML metadata. This event has a <System> tag and an <EventData> tag. Each of these data names can be used in the filter and combined using standard Boolean operators.

With the same view, we can examine the <System> metadata to find additional data names for filtering.

Now let’s say we are only interested in a specific Event ID involving either of these users. We can incorporate an AND Boolean to filter on the System data.

The query below looks for 4663 events for user test5 or test9.

<QueryList>

<Query Id=»0″>

<Select Path=»Security»>

*[EventData[Data[@Name=’SubjectUserName’] and (Data=’test5′ or Data=’test9′)]]

and

*[System[(EventID=’4663′)]]

</Select>

</Query>

</QueryList>

Broader Filtering:

Say you wanted to filter on events involving

test5

but were unsure if it would be in SubjectUserName, TargetUserName, or somewhere else. You don’t need to specify the specific name that the data can be in, but just search that some data in <EventData> contains

test5

.

The query below looks for events that any data in <EventData> equals test5.

<QueryList>

<Query Id=»0″>

<Select Path=»Security»>

*[EventData[Data and (Data=’test5′)]]

</Select>

</Query>

</QueryList>

Multiple Select Statements:

You can also have multiple select statements in your query to pull different data in the same log or data in another log. You can specify which log to pull from inside the <select> tag, and have multiple <select> tags in the same <query> tag.



The example below will pull 4663 events from the security event log and 1704 events from the application event log.

<QueryList>

<Query Id=»0″>

<Select Path=»Security»>*[System[(EventID=’4663′)]]</Select>

<Select Path=»Application»>*[System[(EventID=’1704′)]]</Select>

</Query>

</QueryList>

XPath 1.0 Limitations:

Windows Event Log supports a subset of

XPath 1.0

. There are

limitations

to what functions work in the query. For instance, you can use the «position», «Band», and «timediff» functions within the query but other functions like «starts-with» and «contains» are not currently supported.

Further Reading:

Create a Custom View

http://technet.microsoft.com/en-us/library/cc709635.aspx

Event Queries and Event XML

http://msdn.microsoft.com/en-us/library/bb399427(v=VS.90).aspx

Consuming Events (Windows)

http://msdn.microsoft.com/en-us/library/dd996910(VS.85).aspx

Conclusion:

Using Custom Views in the Windows Event Log can be a powerful tool to quickly access relevant information on your system. XPath 1.0 has a learning curve but once you get a handle on the syntax, you will be able to write targeted Custom Views.

Joji «the sieve» Oshima

[Check out pseventlogwatcher if you want to combine complex filters with monitoring and automation. It’s made by AskDS superfan Steve Grinker:

http://pseventlogwatcher.codeplex.com/

– Neditor]