Logging command lines of executed processes can be a powerful second line in detection of unknown malicious attacks as well as in determination of the root cause of infections during the incident response remediation phase.

In a large organization, centralized logging is one of the principal measures allowing defenders to increase visibility of various types of network and endpoint events. The log data is usually provided by operating system event providers, optionally enriched with the information generated by malware protection and EDR platforms.

When we log Windows events, there are literally hundreds of event types that generate a huge amount of data that can only be analysed using a data analytic platform.

Considering the amount of data, which is too large to be handled manually by humans, it is crucial for defenders to know what they should look for in order to reduce the set of data to the point where it can be relatively easily handled by blue team members.

In this paper, we focus on analysing command lines and their respective parameters for detecting malware attacks as well as manual attacks conducted remotely by human attackers. We also look at malicious usage of operating system tools and command interpreters.

For example, PowerShell is frequently used in one of the infection stages. If we analyse its command line parameters as well as process parents and children, we can create process trees. If a process tree shows that PowerShell was launched by one of the Office applications, it is an event that should be investigated and a good indicator of an attack that was missed using our other lines of defence.

Analysis of command lines and process trees allows us to build a picture of what happened during the attack. Once a suspect event is identified we can drill down to all events generated by a particular system to build a more detailed picture of the attack for remediation.

By running analytic jobs, we build a set of approximate rules for detection and provide general guidelines for the defenders on what to look for when triaging their own logs. For every rule to reduce the amount of log data to investigate we discuss cases of recent malware discovered by applying them.

We conclude the paper with summary stats of malware detected using the developed set of rules. The data set is received through an EDR product telemetry and analysed using Apache Spark analytics.