In the final blog of this series, we’ll look at ways to integrate Windows event logs with other telemetry sources to provide a complete picture of a network environment. The most common way of doing this is by forwarding event logs to a syslog server or SIEM tool.

 

The benefits of telemetry consolidation are:

  1. Scalability and performance – log collectors are built for and focused on collecting logs.
  2. False Positive Reduction – some events, even if they generate an alert, are not meaningful on their own. By combining them with other events in a query, the security analyst can determine if there was a compromise. For example multiple login failures on their own must be examined in conjunction with other events to rule out threat versus driver error.
  3. Determination of the extent of a compromise – attack detected and verified, the next step is to look for lateral movement, the route of entry to the asset initially compromised, any user specific data gleaned from the activities, failure of a security element such as a firewall or IPS to detect the issue, or conversely threat blocked at a specific point due to the successful application of the security policy. Visibility across the breadth of the organization is critical to incident response and remediation.

 

Windows Event Logs to a Syslog Host and Beyond

 

The following is an example of forwarding Windows event logs to a syslog server and from there pushing these events to a basic SIEM tool. I’m showing SolarWinds Event Log Forwarder to Kiwi Syslog Server to ELK (Elasticsearch, Logstash, Kibana) because they are great tools for illustrating the process, and they are all free in their basic form, which means you can have some gratuitous fun testing things out.

 

Step 1: Configure the event log forwarder agent on the host that is collecting the Windows event logs (refer to last week’s blog for configuring forwarding and collection).

 

Define the transport to the syslog server.

 

 

Define the event log subscription, which is the list of events to be sent to the syslog server.

 

Step 2: The syslog server should be configured to listen on the correct port. It will receive those events defined in the subscription above.

 

Step 3: The syslog server can be configured to forward events to another device, such as a SIEM tool. The example below shows how to configure an action that will forward the Windows events from the syslog server via syslog to another host. The events may have an RFC 3164 syslog header appended to them to indicate the original IP of the syslog server (useful if NAT may change the source address of the IP datagram), or you can send the syslog message using the IP of the original source of the event. Another option is to use just the original source IP address of the syslog host. This decision often relies on how the receiving host application process and indexes events.

 

 

Step 4: Install the SIEM tool, in this case Elasticsearch, Logstash and Kibana, known as the ELK stack, are installed and configured. There are some references for accomplishing this at the end of this blog.

 

The key concepts to bolt them together include defining a Logstash-simple.config file that takes an input (for example the TCP/514 events coming from your Syslog server), and outputs those to Elasticsearch which indexes your event data. Localhost:9200 is the default setting.

 

input {

     tcp {

         port => 514

    }

}

output {

elasticsearch { hosts => ["localhost:9200"] }

}

 

Once Kibana is installed it will be your user interface for viewing, indexing, searching and visualizing your events. By default it runs on localhost:5601.

 

 

Your Windows logs can then become part of an overall view of all the telemetry sources and types in your network, viewable and searchable through a single interface. This enables you to build queries across all your data types. By correlating events you increase the fidelity of your investigations by adding visibility.

 

 

Working example of a threat hunt

 

The following table summarizes the types of information that can be gathered and analyzed from a single-pane of glass provided by a log aggregator with good search and index capabilities or a SIEM tool or service.

In this case, the initial trigger is a potential suspicious lateral movement within an organization. When investigating such an event, it’s important not to treat it as an isolated incident, even if you receive only one trigger or alert. Correlation is the key to eliminating false positives. Remember the goal is to rule out false positives, and if the threat is legitimate, you must understand the extent of the attack and when and where it began.

 

 

Activity

Indicators of Compromise

Actions/Information

Detect unusual host to host activity

528, 529, 4624, 4625: Type3 (network) or 10 (RDP) login/logout

Network Information:
Collect Calling Workstation information Name:

CONNECTHOST_NAME
Source Network Address: IP
Source Port:  Port

Verify Privilege Escalations

552, 4648

Runas or privilege escalation

Account Whose Credentials Were Used:
AccountName: user@mydomain.com
Account Domain: DOMAIN

Verify Schedule Tasks

602, 4698

Unusual task names scheduled and quickly deleted

Scheduled Task created:
File Name: Name

Command: Cmd

Triggers: When run

Verify PS Exec

601, 4697

Remote code execution at CMD line following service installation

Attempt to install service:
Service Name: Internal Svc Name
Service File Name: path/name
*Service Type: Code
*Service Start Type: Code

Check VirusScan logs on Hosts

Filenames, Process name, Hashes

Activities may have been attempted by other tools on the host detected and blocked.

Check Firewall Policy

Network access policies on AAA devices

Audit logs on other critical assets

Event Timestamps, IPs, Usernames

Determine if a FW or other security element should be modified to stop further attacks based on IP addresses, ports, or other IOCs

Pull Malicious File Hashes

SHA-256 etc Submit to Sandbox or Analysis Tool

Derive other IOCs representative of this malware and search events for other occurrences and better idea of time attack may have started.

Failure of rule-based element

Set of verifiable IoCs

Update rulesets, virus.dat’s, signature sets. Patch known vulnerabilities.

*The sc query command will show you information on the active services on a workstation

 

From this example you can see it’s a best practice to start small by reacting to the initial trigger and from here collect other important artifacts that will help you cast a wider net across the entire network. Some of these artifacts will also help you to become more proactive as IoCs can be mapped to security policies and rule sets and applied to key security elements.

 

Windows logs are an important tool in your attack detection toolbox. Hopefully this series has given you some useful information on best practices and deployment.

 

Recommended References:

https://www.elastic.co/downloads

https://logz.io/blog/installing-the-elk-stack-on-windows/

https://www.ultimatewindowssecurity.com/securitylog/encyclopedia/