Incidents often involve multiple systems across an enterprise network. Correlating this activity is often very difficult without analyzing the event logs from multiple systems. This is where the previously discussed SIEM appliances are really helpful. Another option, if the SIEM is not preconfigured to ingest and analyze event logs, is the Skadi platform. This open source platform, available from GitHub at https://github.com/orlikoski/Skadi, is a group of applications and forensics installed on an Ubuntu 16.04 LTS server base image.

The primary tool that this chapter will focus on is the Elastic Stack that is included as part of the Skadi platform. The other major feature that Skadi offers is the ability to ingest logs and other forensic data that is acquired through CyLR.exe. As previously discussed, CyLR.exe can be configured to send its output via SFTP to a remote system. Skadi combines an additional tool with CyLR.exe, to produce a dataset that is ingestible by the Elastic Stack on Skadi. This feature allows responders to run CyLR.exe on several different systems and have it sent directly to Skadi, where it can then be processed, indexed, searched, and correlated.

For example, an initial investigation of an incident has identified a system called alien-pc that appears to have been compromised. Responders deploy CyLR.exe to the system, and run the following command:

C:Usersalien-pcDesktop>CyLR.exe -s 192.168.49.132:22 -u skadi -p skadi

In the previous command, the -s is the IP address for the Skadi server. The default username and password for the Skadi server is skadi. After CyLR.exe has completed, the responder will then log in to the Skadi console. From here, the CDQR (short for Cold Disk Quick Response) tool will be run, to convert the data acquired into a format that can be ingested by the Elasticsearch tool. The following command starts the processing with CDQR:

skadi@skadi:~$cdqr in:alien-pc.zip out:Results -z -max_cpu

The command produces the following output:

CDQR produces a file called alien-pc.plaso in the Results directory. The results of the CyLR.exe file have not been converted into a format for ingestion by Elasticsearch. CDQR is used again in the next step, with the following command:

skadi@skadi:~$cdqr in:Results/alien-pc.plaso -plaso_db -es_kb winevt

Upon completion, the CyLR.exe file that had been converted to the .plaso file has been processed and sent to the Elasticsearch portion of the Elastic Stack, as can be seen here:

After the process has completed, the results can be viewed in the Kibana GUI, as follows:

1. Navigate to the IP address of the Skadi server, and the portal shown in the following screenshot will appear:

2. Click on Kibana, and the following screen appears:

3. From here, click Discover.
4. In the top right-hand corner, set the date to an appropriate time period. Kibana defaults to the last 15 minutes of data. For offline data, set the time period that is applicable or simply click 5 years, as follows:

5. Kibana is feature-rich and provides a wide range of options in terms of analyzing data. This includes the use of customer queries, event IDs, keywords, and XML strings. In this case, the responder will focus on event ID 4688, which indicates a new process has run to identify potentially malicious code or other behavior. The Add a filter feature in the left-hand pane allows responders to filter on specific data points, as shown in the following screenshot:

6. Once the filter is set on the event ID 4688, the responder clicks Save and then refreshes Kibana by clicking on Refresh in the upper-right corner. This filters on that specific event ID, taking the results of almost 1.3 million events to 784. 
7. From here, the responder begins a cursory search of the results and identifies the whoami.exe executable . This is not a malicious executable but is suspicious, as it may indicate that an adversary has compromised the system and then attempted to ascertain the name of the system using the Windows whoami.exe file. The filter can then be further enhanced by including this keyword in the filter, as follows:

8. This additional filter produces a log entry that can be analyzed by the responder, as follows:

9. From here, the responder can determine the date, time, and the account that ran the command. There may be a legitimate reason for an administrator to run this command in their normal day-to-day activities, but it is possible that this was part of a larger compromise, and the responder should verify the use of this tool.
10. The combination of CyLR.exe and Skadi provides responders the ability to remotely access log files and automate their ingestion into a platform that allows a more detailed analysis. Skadi can also be stood up as necessary, as it can be configured as a virtual machine. From here, responders can forward all of the necessary log files, and correlate activity across multiple systems in a short time. This combination is powerful and comes at a low cost.

Skadi, combined with CyLR.exe, provides the responder with the ability to acquire and analyze log files from a number of systems involved in the incident. The ability to pivot off of specific Event IDs or keywords makes Skadi a powerful tool to zero in on specific log entries that are important in identifying additional evidence in an incident investigation.