NXLog Legacy Documentation

Sysmon

System Monitor (Sysmon) is part of the Sysinternals suite used for monitoring and logging system activity. It helps system administrators to identify malicious activity through its detailed output. Sysmon is available for both Windows and Linux systems.

Sysmon for Windows

NXLog can be configured to capture and process audit logs generated by the Sysinternals Sysmon utility. Sysmon for Windows is a Windows system service and device driver that logs system activity into Windows Event Log. Supported events include (but are not limited to):

Process creation and the full command line used
Loading of system drivers
Network connections
Modification or file creation timestamps

On Windows Vista and higher, Sysmon writes events to the Microsoft-Windows-Sysmon/Operational Windows Event Log channel. On older systems, it writes events to the default System channel.

Setting up Sysmon for Windows

To download Sysmon for Windows and for full details about configuring and installing Sysmon, see the Sysmon page on Microsoft Docs.

Download and extract the Sysmon ZIP archive.
Install the Sysmon service with the default parameters. The service will be activated immediately; no restart is required. The service will remain resident across reboots. Other command-line parameters are available to enable or disable various types of logging.
```
> sysmon -accepteula -i
```
A complex configuration with filtering can be deployed by creating a custom XML configuration file for Sysmon.

See SwiftOnSecurity Sysmon configuration, or IONStorm Sysmon configuration on GitHub. Both provide good information for understanding what is possible with Sysmon and include many examples.

Use the -c option to update the service with a new configuration.
```
> sysmon -c config.xml
```
To uninstall the Sysmon service, use the -u option.
```
> sysmon -u
```

Collecting Sysmon logs

When Sysmon generates event log data, it encodes details of the event into the EventData tag of the Windows Event Log record.

Example Sysmon Windows Event Log entry

<EventData>
  <Data Name="UtcTime">2015.04.27. 13:23</Data>
  <Data Name="ProcessGuid">{00000000-3862-553E-0000-001051D40527}</Data>
  <Data Name="ProcessId">25848</Data>
  <Data Name="Image">c:\Program Files (x86)\nxlog\nxlog.exe</Data>
  <Data Name="CommandLine">"c:\Program Files (x86)\nxlog\nxlog.exe" -f</Data>
  <Data Name="User">WIN-OUNNPISDHIG\Administrator</Data>
  <Data Name="LogonGuid">{00000000-568E-5453-0000-0020D5ED0400}</Data>
  <Data Name="LogonId">0x4edd5</Data>
  <Data Name="TerminalSessionId">2</Data>
  <Data Name="IntegrityLevel">High</Data>
  <Data Name="HashType">SHA1</Data>
  <Data Name="Hash">1DCE4B0F24C40473Ce7B2C57EB4F7E9E3E14BF94</Data>
  <Data Name="ParentProcessGuid">{00000000-3862-553E-0000-001088D30527}</Data>
  <Data Name="ParentProcessId">26544</Data>
  <Data Name="ParentImage">C:\msys\1.0\bin\sh.exe</Data>
  <Data Name="ParentCommandLine">C:\msys\1.0\bin\sh.exe</Data>
</EventData>

Sysmon audit log data can be collected with im_msvistalog (or other modules, see Windows Event Log). The Data tags will be automatically parsed, and the values will be available as fields in the event records. The log data can then be forwarded to a log analytics system to allow the identification of malicious or anomalous activity.

Example 1. Collecting Sysmon Windows events

Here, the im_msvistalog module will collect all Sysmon logs from Windows Event Log. A sample Windows event is shown below.

nxlog.conf

<Input in>
    Module  im_msvistalog
    <QueryXML>
        <QueryList>
            <Query Id="0">
                <Select Path="Microsoft-Windows-Sysmon/Operational">*</Select>
            </Query>
        </QueryList>
    </QueryXML>
</Input>

Output sample

{
  "EventTime": "2015-04-27 15:23:46",
  "Hostname": "WIN-OUNNPISDHIG",
  "Keywords": -9223372036854776000,
  "EventType": "INFO",
  "SeverityValue": 2,
  "Severity": "INFO",
  "EventID": 1,
  "SourceName": "Microsoft-Windows-Sysmon",
  "ProviderGuid": "{5770385F-C22A-43E0-BF4C-06F5698FFBD9}",
  "Version": 3,
  "Task": 1,
  "OpcodeValue": 0,
  "RecordNumber": 2335906,
  "ProcessID": 1680,
  "ThreadID": 1728,
  "Channel": "Microsoft-Windows-Sysmon/Operational",
  "Domain": "NT AUTHORITY",
  "AccountName": "SYSTEM",
  "UserID": "SYSTEM",
  "AccountType": "Well Known Group",
  "Message": "Process Create:\r\nUtcTime: 2015.04.27. 13:23\r\nProcessGuid: {00000000-3862-553E-0000-001051D40527}\r\nProcessId: 25848\r\nImage: c:\\Program Files (x86)\\nxlog\\nxlog.exe\r\nCommandLine: \"c:\\Program Files (x86)\\nxlog\\nxlog.exe\" -f\r\nUser: WIN-OUNNPISDHIG\\Administrator\r\nLogonGuid: {00000000-568E-5453-0000-0020D5ED0400}\r\nLogonId: 0x4edd5\r\nTerminalSessionId: 2\r\nIntegrityLevel: High\r\nHashType: SHA1\r\nHash: 1DCE4B0F24C40473CE7B2C57EB4F7E9E3E14BF94\r\nParentProcessGuid: {00000000-3862-553E-0000-001088D30527}\r\nParentProcessId: 26544\r\nParentImage: C:\\msys\\1.0\\bin\\sh.exe\r\nParentCommandLine: C:\\msys\\1.0\\bin\\sh.exe",
  "Opcode": "Info",
  "UtcTime": "2015.04.27. 13:23",
  "ProcessGuid": "{00000000-3862-553E-0000-001051D40527}",
  "Image": "c:\\Program Files (x86)\\nxlog\\nxlog.exe",
  "CommandLine": "\"c:\\Program Files (x86)\\nxlog\\nxlog.exe\" -f",
  "User": "WIN-OUNNPISDHIG\\Administrator",
  "LogonGuid": "{00000000-568E-5453-0000-0020D5ED0400}",
  "LogonId": "0x4edd5",
  "TerminalSessionId": "2",
  "IntegrityLevel": "High",
  "HashType": "SHA1",
  "Hash": "1DCE4B0F24C40473CE7B2C57EB4F7E9E3E14BF94",
  "ParentProcessGuid": "{00000000-3862-553E-0000-001088D30527}",
  "ParentProcessId": "26544",
  "ParentImage": "C:\\msys\\1.0\\bin\\sh.exe",
  "ParentCommandLine": "C:\\msys\\1.0\\bin\\sh.exe",
  "EventReceivedTime": "2015-04-27 15:23:47",
  "SourceModuleName": "in",
  "SourceModuleType": "im_msvistalog"
}

Filtering Sysmon events

Some scenarios require more advanced filtering of Sysmon logs to achieve more useful results. There are three main ways to filter Sysmon logs.

Sysmon configuration

Sysmon supports filtering tags to avoid logging unwanted events. See [setup] above and the Sysmon page for details about the available tags. This method is the most efficient because it avoids creating unwanted log entries in the first place.

Windows Event Log XPath query

The im_msvistalog Query or QueryXML directive can be used to limit the entries read via the Windows Event Log API. Because this method restricts the number of entries that reach NXLog, it is a fairly efficient way to filter logs.

Example 2. Filtering Sysmon events with an XPath Query

The following example shows a query that collects only events that have an event ID of 1 (process creation).

nxlog.conf

<Input in>
    Module  im_msvistalog
    <QueryXML>
        <QueryList>
            <Query Id="0">
                <Select Path="Microsoft-Windows-Sysmon/Operational">
                    *[System[(EventID='1')]]
                </Select>
            </Query>
        </QueryList>
    </QueryXML>
</Input>

NXLog language

Finally, the built-in filtering capabilities of NXLog can be used, which may be easier to write than the XML query syntax provided by the Windows Event Log API.

Example 3. Filtering Sysmon events in an Exec block

This example discards all network connection events (event ID 3) regarding HTTP network connections to a particular server and port, and all process creation and termination events (event IDs 1 and 5) for conhost.exe.

nxlog.conf

<Input in>
    Module  im_msvistalog
    <QueryXML>
        <QueryList>
            <Query Id="0">
                <Select Path="Microsoft-Windows-Sysmon/Operational">*</Select>
            </Query>
        </QueryList>
    </QueryXML>
    <Exec>
        if ($EventID in (1, 5) and
            $Image == "C:\\Windows\\System32\\conhost.exe") or
           ($EventID == 3 and
            $DestinationPort == 80 and
            $DestinationIp == 10.0.0.1)
           drop();
    </Exec>
</Input>

Sysmon for Linux

To download Sysmon for Linux and for full details about configuring and installing Sysmon, follow the documentation on the SysmonForLinux page of Sysinternals on GitHub.

If compiling Sysmon from source, compile both SysinternalsEBPF and Sysmon for Linux.

Setting up Sysmon for Linux

Download and install the package according to your operating system.
Run the following command to accept the EULA.
```
$ sysmon -accepteula
```
You need a configuration file for this setup. See SysmonForLinux-CollectAll-Config which provides an excellent example. It is a good starting point to create your final configuration.

Use the -i to update the service with a new configuration.
```
$ sysmon -i <configuration_file>
```
Confirm that logs are being produced.
```
$ tail -f /var/log/syslog
```
The logs are produced using XML and will show Provider Name="Linux-Sysmon".

The provided XML configuration file for Sysmon is an example and using this in a production environment can result in a considerable amount of events being forwarded to your platform of choice.

Collecting Linux Sysmon logs

This configuration file provides an example on how to capture the log data from /var/log/syslog. Any messages that do not match the requirements are dropped.

The parse_windows_eventlog_xml() procedure with the PrefixWinEvent option set to TRUE is being used to capture all of the fields contained in the log entry generated by Sysmon.

Example 4. Collecting Sysmon logs

nxlog.conf

<Extension _syslog>
    Module            xm_syslog
</Extension>

<Extension _json>
    Module            xm_json
</Extension>

<Extension _xml>
    Module            xm_xml
    PrefixWinEvent    TRUE
</Extension>

<Input sysmon>
    Module            im_file
    File              '/var/log/syslog'
    Exec              if $raw_event !~ /Linux-Sysmon/ drop();
</Input>

<Output output_file>
    Module            om_file
    File              '/tmp/output.json'
    <Exec>
        parse_syslog();
        parse_windows_eventlog_xml($Message);
        to_json();
    </Exec>
</Output>

<Route main>
    Path              sysmon => output_file
</Route>

The output sample below contains the parsed fields. The original XML content is retained in the Message field.

Output sample

{
  "EventReceivedTime": "2021-11-23T10:22:33.037206-08:00",
  "SourceModuleName": "linux_sysmon",
  "SourceModuleType": "im_file",
  "SyslogFacilityValue": 1,
  "SyslogFacility": "USER",
  "SyslogSeverityValue": 5,
  "SyslogSeverity": "NOTICE",
  "SeverityValue": 2,
  "Severity": "INFO",
  "Hostname": "debian-10-r60",
  "EventTime": "2021-11-23T10:22:32.650662-08:00",
  "SourceName": "sysmon",
  "Message": "<Event><System><Provider Name=\"Linux-Sysmon\" Guid=\"{ff032593-a8d3-4f13-b0d6-01fc615a0f97}\"/><EventID>1</EventID><Version>5</Version><Level>4</Level><Task>1</Task><Opcode>0</Opcode><Keywords>0x8000000000000000</Keywords><TimeCreated SystemTime=\"2021-11-23T18:22:32.650662000Z\"/><EventRecordID>168726</EventRecordID><Correlation/><Execution ProcessID=\"500\" ThreadID=\"500\"/><Channel>Linux-Sysmon/Operational</Channel><Computer>debian-10-r60</Computer><Security UserId=\"0\"/></System><EventData><Data Name=\"RuleName\">-</Data><Data Name=\"UtcTime\">2021-11-23 18:22:30.517</Data><Data Name=\"ProcessGuid\">{c636843b-3166-619d-1d59-511611560000}</Data><Data Name=\"ProcessId\">28904</Data><Data Name=\"Image\">/opt/nxlog/bin/nxlog</Data><Data Name=\"FileVersion\">-</Data><Data Name=\"Description\">-</Data><Data Name=\"Product\">-</Data><Data Name=\"Company\">-</Data><Data Name=\"OriginalFileName\">-</Data><Data Name=\"CommandLine\">/opt/nxlog/bin/nxlog -f -q</Data><Data Name=\"CurrentDirectory\">/</Data><Data Name=\"User\">root</Data><Data Name=\"LogonGuid\">{c636843b-0000-0000-0000-000000000000}</Data><Data Name=\"LogonId\">0</Data><Data Name=\"TerminalSessionId\">4294967295</Data><Data Name=\"IntegrityLevel\">no level</Data><Data Name=\"Hashes\">-</Data><Data Name=\"ParentProcessGuid\">{00000000-0000-0000-0000-000000000000}</Data><Data Name=\"ParentProcessId\">1</Data><Data Name=\"ParentImage\">-</Data><Data Name=\"ParentCommandLine\">-</Data><Data Name=\"ParentUser\">-</Data></EventData></Event>",
  "ProviderGuid": "{ff032593-a8d3-4f13-b0d6-01fc615a0f97}",
  "EventID": 1,
  "Version": 5,
  "LevelValue": 4,
  "TaskValue": 1,
  "OpcodeValue": 0,
  "Keywords": "0x8000000000000000",
  "RecordNumber": 168726,
  "ExecutionProcessID": 500,
  "ExecutionThreadID": 500,
  "Channel": "Linux-Sysmon/Operational",
  "UserID": "0",
  "EventData.RuleName": "-",
  "EventData.UtcTime": "2021-11-23 18:22:30.517",
  "EventData.ProcessGuid": "{c636843b-3166-619d-1d59-511611560000}",
  "EventData.ProcessId": "28904",
  "EventData.Image": "/opt/nxlog/bin/nxlog",
  "EventData.FileVersion": "-",
  "EventData.Description": "-",
  "EventData.Product": "-",
  "EventData.Company": "-",
  "EventData.OriginalFileName": "-",
  "EventData.CommandLine": "/opt/nxlog/bin/nxlog -f -q",
  "EventData.CurrentDirectory": "/",
  "EventData.User": "root",
  "EventData.LogonGuid": "{c636843b-0000-0000-0000-000000000000}",
  "EventData.LogonId": "0",
  "EventData.TerminalSessionId": "4294967295",
  "EventData.IntegrityLevel": "no level",
  "EventData.Hashes": "-",
  "EventData.ParentProcessGuid": "{00000000-0000-0000-0000-000000000000}",
  "EventData.ParentProcessId": "1",
  "EventData.ParentImage": "-",
  "EventData.ParentCommandLine": "-",
  "EventData.ParentUser": "-",
  "EventType": "INFO"
}

Disclaimer

While we endeavor to keep the information in this topic up to date and correct, NXLog makes no representations or warranties of any kind, express or implied about the completeness, accuracy, reliability, suitability, or availability of the content represented here. We update our screenshots and instructions on a best-effort basis.

The accurateness of the content was tested and proved to be working in our lab environment at the time of the last revision with the following software versions:

NXLog version 5.4.7313

Last revision: 4 April 2022