CSIRT Insights: Optimisation of Event Log Analysis and Recording in DFIR

Velociraptor is a powerful and modern DFIR software (Digital Forensics and Incident Response) application used across a range of organisations. The Velociraptor Query Language (VQL) is used to execute queries on one or more hosts. This simplifies things for incident responders because they can query specific elements without having to perform lengthy searches and queries via compact file systems. Find out how easy it is to use built-in accessors to access files and event logs, what an artefact looks like and how the collected data can be enriched and normalised.

What are accessors and Velociraptor functions?

Accessors or plugins are functions built into Velociraptor that enable the VQL query language to open and search certain file types. The VQL code is integrated into a YAML file (known as an artefact). Analysts can then use these artefacts for queries and searches.

In our example, we’re using the ‘parse_evtx’ accessor, which can analyse Windows event logs. Instead of downloading the event logs from the host, we can run a VQL query and collect the events specific to our purpose.

Note: Other commonly used plugins are ‘read_file’, ‘users’, ‘glob()’, and ‘OSPath’.

Efficient filtering of ‘Windows Defender’ protocols with Velociraptor EVTX accessors

Native artefacts such as ‘Windows.EventLogs.evtx’ and ‘Windows.EventLogs.evtxHunter’ have already integrated the EVTX accessor within Velociraptor. This introduces an abstraction layer that enables the filtering of events based on data, channels, event IDs and Volume Shadow Copies (VSS).

We’re using the artefact ‘Windows.EventLogs.evtx’ to illustrate this, as shown below:

Figure 1: Artefact ‘Windows.EventLogs.evtx’

This article focuses on Windows Defender logs, which are usually an excellent starting point for investigations.

If you apply the artefact to the entire ‘Microsoft-Windows-Windows Defender%4Operational.evtx’ file, every log within the EVTX is analysed, producing thousands of entries for an uninfected computer that contain a considerable amount of irrelevant data. Entries such as “Endpoint Protection client is up and running in a healthy state” or “Microsoft Defender Antivirus security intelligence version updated” are also parsed and generate a lot of background noise.

Potential event IDs: Optimise your search with RegEx patterns

We reduce the background noise by incorporating appropriate filters into the search. The official Microsoft documentation guides us through the steps for identifying event IDs of potential interest.

We’ve selected the following event IDs for this article:

Table 1: Examples for the refined search of event IDs

This enables us to refine the original search even further, so we focus exclusively on the new event IDs listed above.

We can add them as RegEx patterns:

«^(1006|1007|1008|1009|1010|1011|1012|1013|1015|1116|1117|1118|1119|1160|2050|2051|3002|3007|5000|5001|5004|5007|5008|5009|5010|5011|5012|5013)$” to the ‘IDRegex’ filter.

Despite this refinement, a lot of results are still returned. We were able to reduce the results from 10,000 to 500 entries on our test workstation. However, this is nonetheless a vast amount of data when the search is extended to thousands of hosts.

Assigning relevance levels to event IDs

One solution is to assign a relevance level to each of these event IDs which allows us to effectively control the granularity of our search. To achieve this, we need to expand the artefact ‘Windows.EventLogs.Evtx’ by adding custom VQL queries.

We classify the 25 event IDs into five levels, with level 1 the most detailed. In other words, it offers the lowest probability of finding something interesting to investigate.

We can then create a selector with an aggregation of if conditions. This approach allows us to refine our search criteria based on the assigned relevance levels and thus optimise the search process.

Figure 2: Example of a five-stage Velociraptor artefact

This configuration allows us to run the artefact at a level 4 or 5, enabling a swift triage when thousands of hosts are managed. Conversely, we can use lower levels to collect additional information when working on a specific group of target hosts.

This refinement has effectively reduced the number of results to five at level 4, which is a reasonable amount for the analysis.

Optimisation and enrichment of search results

Once the search has been optimised, it is important to enrich the results in a targeted manner. During data enrichment, new fields are added to give the event a context (e.g. adding a category or translating the login ID into the associated value).

In our example, we’ll introduce three enrichments with the names ‘eSymbolicName’, ‘eMessage’ and ‘eDescription’, which correspond to the values described in the Windows documentation. Although some of this information is already available in the standard message fields, these new fields often provide more precise information than is available there.

Below you’ll find an example of enrichment with symbolic names using a dictionary and a function for selecting the relevant element based on the event ID:

Figure 3: Example of enrichment with symbolic names

Enrichment is an excellent method of adding context to an event. However, it also increases the amount of data sent, which could have an impact on the Velociraptor server. It is a trade-off between the importance of the context and the impact on the amount of data used.

The relevance and frequency of the results should also be taken into account. For example, malware detections are crucial and don’t usually very often, so they don’t generate excessive traffic compared to Windows login activity.

Consistency of artefacts through normalised field names

The next step is to normalise the field names to ensure consistency across all artefacts. In our example, the data is extracted from Windows EVTX, meaning that most of the relevant information is stored in JSON format in the ‘EventData’ field, as shown in the partial result below.

Figure 4: Normalisation of field names

This indicates that we can access malware information by name via the ‘EventData.Threat Name’ field. However, this approach is specific to Windows Defender protocols and may not apply to other antivirus solutions.

One way to solve this problem is to clone certain fields and rename them with a more generic and relevant name.

Figure 5: Renaming fields

Once the artefact has been validated against all relevant events and there is confirmation that the essential fields are covered, the recording of ‘EventData’ (marked here with *) can be set to reduce the recorded data to a strict minimum.

Efficiency and consistency: the role of artefact naming for reuse

Once all steps have been completed, it is advisable to assign a relevant name to the artefact for future reuse, which is crucial for maintaining efficiency and eliminates the need to repeat each step if the same search is required. This approach not only increases productivity, but also promotes the consistency and organisation of the investigation process.

Perfect combination: Velociraptor and the expertise of an ISO 27001:2022-certified incident response team

Utilising the powerful features of Velociraptor can significantly improve your incident response and digital forensics processes. Our services ensure seamless integration and optimisation of Velociraptor for your specific requirements, allowing you to analyse event logs and extract important data quickly and efficiently.

The experts in our "Computer Security Incident Response" team (CSIRT) use Velociraptor on a daily basis. Take advantage of the experience of our ISO 27001:2022 certified CSIRT team, increase the efficiency of your analysis processes and utilise the full potential of Velociraptor. 

Are your crown jewels adequately protected? We support your security team with a compromise assessment so that you can recognise potential security gaps and rectify them in good time.