- Scalability and performance – log collectors are built for and focused on collecting logs.
- 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.
- 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.
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/
