N-IOCs to Rule Them All

Table of Contents


We analyzed the top ten malware families in Switzerland (according to govcert.ch) during the period April - December 2022 to find patterns and overlaps in the forensic artifacts that a successful infection leaves on an endpoint.

We explicitly did not analyze the infection chain (how the infection happens – macros, wscript, hta, etc.), but rather the traces left by the second stage, i.e., the final malware executed on the endpoint.

This analysis resulted in eight artifacts that a SOC analyst or an incident responder can leverage to find infections of these malware families (and probably other malware strains) with a reasonably high probability. These artifacts can also be leveraged for monitoring purposes or threat hunting on the network.

We analyzed the following malware families in more detail: Malware families

As this research was done for my talk at the FIRST Conference 2023 in Montreal, the original slides are available here. A huge thank you goes to my two proofreaders Kostas, and my team colleague Asger.

IOC #1: Defender Exclusions

Nanocore RAT

Figure 1: Excluding a file (or a folder path) from Windows Defender scans

During the analysis, it was found that in many cases, the malware sets up an exception for Windows Defender so that a directory or file is not scanned, as depicted in Figure 1 by Nanocore RAT. However, the creation of such an exception is recorded in an event log (ID 5007, Windows Defender, Figure 2). If (event-)logs are already collected centrally in a SIEM, collecting and monitoring the Windows Defender event log is also recommended to monitor for newly created exclusions specifically.

Monitoring the ID 5007 event log has an additional advantage. Apart from detecting malware infections, it can also identify misconfigurations, like overly broad exclusion rules that cover entire drives or directories.

Windows Defender Event Log

Figure 2: Windows Defender Event Log

An alternative way to find these exceptions on endpoints is to extract the exceptions directly from the registry (HKLM\SOFTWARE\Microsoft\Windows Defender\Exclusions\Paths). This approach is feasible if code execution is possible on all endpoints in the network (for example, via an EDR or the req query command).

@DebugPrivilege covered Windows Defender AV logs extensively. [1]

IOC #2: Powershell Logs

Ave Maria RAT

Figure 3: Malware sets up persistency in the Registry with PowerShell

Interestingly, various malware families used PowerShell code to set up persistency on the endpoint within our analysis timeframe. There is an example of the Ave Maria RAT depicted in Figure 3. We suspect that the malware uses PowerShell instead of the Windows API to fool or circumvent the logging mechanism by some EDR products and also because PowerShell Script Block logging is not an enabled by default. When PowerShell Script Block Logging has been enabled, executed PowerShell code is stored inside the Microsoft-Windows-PowerShell event log (Figure 4).


Figure 4: PowerShell Event Log (Scriptblock)

Enable PowerShell Script Block Logging via Group Policy on all endpoints in the network. These logs are a goldmine for finding adversaries inside the network and for forensics during an incident response investigation. [2]

Extra Mile: When working on an IR case or conducting a compromise assessment, always check the PowerShell logs, even if logging is not enabled globally. You might be surprised by what you will find :)

Suspicious keywords

Figure 5: Suspicious keywords

IOC #3: Scheduled Tasks


Figure 6: Malware creates a new Scheduled Task

Creating scheduled tasks for the periodic execution of malware is a classic (Figure 6). With the open-source tool Velociraptor (Velociraptor is an advanced digital forensic and incident response tool that enhances your visibility into your endpoints [3]) and the built-in Velociraptor hunt “Windows.System.TaskScheduler”, we can collect all tasks from the endpoints where Velociraptor is running. The example above was tweaked for my FIRST presentation, but apart from the DLL file and location, the same command line was used by QakBot in the past.


Figure 7: Collecting all Scheduled Tasks with Velociraptor

Velociraptor offers a range of pre-made searches, known as hunts [4,5], and a query language called Velociraptor Query Language (VQL). This allows for convenient processing of data in notebooks built into the Velociraptor interface. [9] As a result, searches like finding DLL files or other files in user directories are relatively simple. (Figure 8).

Velociraptor Notebook

Figure 8: Examination of the collected Tasks with Velociraptor

In addition to the live data (the Tasks file) on the endpoints, various traces can also be found in the security event logs (task creation, evidence of file execution, deletion, etc.). There is even a separate event log for TaskScheduler, which could contain further traces about the executed tasks.


  • 4698: A scheduled task was created
  • 4699: A scheduled task was deleted
  • 4700: A scheduled task was enabled
  • 4701: A scheduled task was disabled
  • 4702: A scheduled task was updated


  • 140: User updated Task Scheduler task
  • 141: User deleted Task Scheduler task

IOC #4: Run Keys

404 Keylogger

Figure 9: Creating a new run key in the registry

With the help of the Run-Key within the registry, malware will automatically start when a login occurs under the user account where the Run-Key is created.

With the open-source software Sysmon [6], we can monitor the creation of registry keys (ID 13).

Monitoring registry keys

Figure 10: Monitoring registry keys with Sysmon

Or we can use Velociraptor (again) to read all run keys from the user and system hives.

Collecting run keys

Figure 11: Collecting run keys from the registry keys with Velociraptor

Data collected in this way can, in turn, be easily searched using Velociraptor’s query language (VQL). In the following example, we searched for files in the AppData directory.

Velociraptor Notebook

Figure 12: Filtering the collected data with Velociraptor

IOC #5: Startup Folder

Persistence in the Startup Folder

Figure 13: Persistence in the Startup Folder

Another classic persistence technique is to use the Startup folder. Files in this directory are executed when a user logs into the endpoint (interactively). We use the AutoRuns software from SysInternals to hunt for this persistence mechanism. [7]

Instead of manually running AutoRuns on a single endpoint, we can utilize Velociraptor to conduct a network-wide hunt and identify any infections present on multiple devices. This approach allows for a more comprehensive and efficient detecting of potential threats.[8]

Velociraptor Notebook

Figure 14: Filtering AutoRuns data by files in the startup directory

IOC #6: Appdata

AppData directory

Figure 15: Newly created file in the AppData directory

Without exception, every malware family analyzed during our research wrote a file in the AppData directory (in the local or roaming directory) at some point during the infection (not every time, as the techniques within the malware families also change). Detecting file write events can be easily achieved using Sysmon, similar to monitoring registry keys. This might be noisy (like, real noisy!), so you should filter out well-known parent processes to not drown in events, resulting in alert fatigue.

AppData directory

Figure 16: Monitoring of the newly created files in the AppData directory

Velociraptor is, again, excellent for finding suspicious files in user profiles.


Figure 17: Recursive search for file types with Velociraptor

If it is possible to monitor for newly written files on the endpoints, it would be mandatory to alert every newly created file in the C:\Users\Public\ directory because, in many cases, this directory is used by malware or by a threat actor as a staging directory.

IOC #7: Dynamic DNS (DynDNS)

Remcos RAT

Figure 18: Remcos RAT uses a dynamic domain as a C2 channel

Dynamic DNS providers, such as DDNS.net in the example above, are popular mechanisms that make taking down a malicious domain more difficult. DNS resolutions to dynamic DNS providers are rare and are usually not caused by legitimate installations. Enabling logging of DNS queries if you can. These DNS logs can, in turn, be sent to a SIEM for further processing, as this will create a large amount of data in a short amount of time (depends of the size of the network, of course).

Alternatively, setup a Passive DNS service with a mirror port on the network transition, which reads the network traffic and extracts and stores DNS packets (requests/responses). [10]


Figure 19: Running your own passive DNS Service - ISC SANS blog

In addition, DNS data can also be queried live on the endpoints in the network (Figure 20) or more conveniently with the Velociraptor hunt DNSCache. [11]

Cached DNS data

Figure 20: Reading the cached DNS data with PowerShell

IOC #8: High-Port || IP-Only

Netwire RAT

Figure 21: A Trojan uses a high port on a domain as a C2 channel

The last artifact in our series is the use of a high port (Figure 21). However, analyzing connections to a high port with firewall logs solely can be time-consuming since the associated services (the executable on the endpoint that built up the network connection) are not visible. In this case, it is again advisable to fall back on other data sources, such as Sysmon, which records network connections with the destination, port, and associated application.


Figure 22: Monitor network connections with Sysmon


We presented eight artifacts that could be used to find potential infections on endpoints. Utilizing open-source solutions, this process can be done at a low cost and with a relatively low footprint in the network.

Regular threat hunts for the artifacts mentioned in this blog can significantly reduce the risk of more significant compromises caused by infections. Organizations can detect threats faster and take necessary measures to prevent any harmful impact by conducting these hunts.

Eight artifacts

Figure 23: The eight artifacts for the targeted search for infections in the network



MD5 of the samples presented in this blog post:

  • Nanocore RAT: 69b22379d46d4c2a2dc362e4007bea3d
  • Ave Maria RAT: 71e44db97d7e1d350965103abab9f962
  • Qbot: 2a5defffe15dfba6db254bbda3a6dc26
  • 404 Keylogger: 0ccce183e7e63254b5e1722080a2f452
  • 404 Keylogger: 3128692094abd246c86a0b91b487418e
  • Loki Password Stealer: f1068187e6778378217cb6774b2374ca
  • Remcos RAT: dcf69f752db09d36ffbdab412a3c83da