N-IOCs to Rule Them All

Introduction

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:

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

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.

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

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).

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 :)

IOC #3: Scheduled Tasks

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.

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).

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.

Security.evtx

• 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

Microsoft-Windows-TaskScheduler%4Operational.evtx

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

IOC #4: Run Keys

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).

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

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.

IOC #5: 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]

IOC #6: Appdata

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.

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

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)

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]

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]

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

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.

Conclusion

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.

References

• [1] https://m365internals.com/2021/07/05/why-are-windows-defender-av-logs-so-important-and-how-to-monitor-them-with-azure-sentinel/
• [2] https://www.techtarget.com/searchwindowsserver/tutorial/Set-up-PowerShell-script-block-logging-for-added-security
• [3] https://docs.velociraptor.app/
• [4] https://docs.velociraptor.app/artifact_references/
• [5] https://docs.velociraptor.app/exchange/
• [6] https://learn.microsoft.com/en-us/sysinternals/downloads/sysmon
• [7] https://learn.microsoft.com/en-us/sysinternals/downloads/autoruns
• [8] https://docs.velociraptor.app/artifact_references/pages/windows.sysinternals.autoruns/
• [9] https://docs.velociraptor.app/vql_reference/
• [10] https://isc.sans.edu/diary/Running+your+Own+Passive+DNS+Service/24784>
• [11] https://docs.velociraptor.app/artifact_references/pages/windows.system.dnscache/

Samples

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