The Malicious Process Lifecycle: From Execution to Evasion

Imagine getting a frantic ping from the help desk, like a user just double-clicked a suspicious file named invoice.exe that they downloaded from some random email.

Right.

Just vanished.

You open task manager, everything looks perfectly normal.

But, you know, without a doubt, that machine is completely compromised.

I mean, the illusion is complete at that point.

So pull up a chair, grab a seat at the desk.

Today, we're doing something a little different.

What?

Yeah.

We've got the Rima eBook Foundations, some core RE101 fundamentals, and a really fresh batch of NJRS student reports.

Oh, absolutely.

We really want to show you how to look at a compromised system and see those invisible footprints left behind by malware.

Right.

Exactly.

Once you understand how a binary, say, maps its imports, or how it hollows out a legitimate process and how it melts its original tracks, nothing can hide from you.

Before a malicious process can even, you know, dream of executing in memory and wreaking havoc, it's just a dormant file sitting on the hard drive.

Right.

I love that analogy.

Practically every executable file loaded by Windows, whether it's an XC or a DL or a SysDriver, it all uses that PE format.

So when you pick up a physical book, the very first thing you see is the cover.

Right.

Right.

Right.

Right.

Right.

Right.

Right.

Right.

Right.

Right.

Right.

Yeah, the original architect of the format.

Those two bites simply tell the operating system, yes, I am a valid executable.

And once you get past the cover, you open the book and you find the table of contents.

Correct.

It acts as this instruction manual for the Windows OS Loader detailing exactly how to map this file from the hard drive into the computer's actual memory to find space requirements and it acts as an index for the actual content of the file and that content is divided into what we call sections and if the PE header is the table of contents the sections are the actual chapters of the book exactly this is where the meat of the file lives so you've got the dot text section which holds the actual machine code like the raw instructions the CPU is going to execute right and then you have the dot data or art art data sections where the program stores its hard-coded strings like IP addresses or registry keys things like that yeah and as an analyst checking the condition of those chapters is really your first clue if you open a book and the text is entirely in a scrambled completely unreadable language well you know something is wrong actually that perfectly lines up with these jigsaw ransomware report sitting right here the analysts notice that the data is stored in a completely unreadable language that the dot text section of the ransomware had incredibly high entropy okay like the data was completely randomized and compressed I'm assuming that means the code is packed or obfuscated right to hide its true intent from us exactly the structure alone tells a story before a single instruction is ever executed yeah I mean a packed dot text section just means the malware is actively trying to prevent you from reading its code statically but wait I want to challenge something here let's say the dot text section isn't packed the malware's custom code is sitting right in the middle of the system and the malware is sitting right in the middle of the system and the malware is sitting right in the middle of the system and right there in plain text how does the malware actually know how to talk to the windows operating system because the attacker didn't write an entire networking stack or a file system from scratch inside their dot text section no they absolutely did not that'd be insane malware is inherently parasitic right it has to borrow functionality from the host environment he needs the OS exactly it has to ask Windows for help and it does that through a mechanism called the import address table or the IAT okay so an index of external help yeah thank you for that thank you for that thank you for that think of it like looking inside a contractor's toolbox before they start a job on your house oh I like that the IAT is just a list of functions that the executable requests from external Windows libraries like kernel 32 DLL or user 32 DLL right if a piece of software wants to create a file it imports the create file function it wants to monitor the keyboard it imports set windows hook X oh I see where this is going so if I am analyzing a dormant file and I check its IAT and I see it requesting pipe wrenches and a soldering iron I know it's there to do plumbing and if I see it importing create process and write process memory I have a massive clue that this thing is planning to inject code into other programs that is exactly the mindset you need to have understand the IAT is your very first step in reverse engineering because it reveals the malware's capabilities before it ever runs it shows you the tools right but you know malware authors know we look at this so going back to your point about packed executables when malware is heavily packed the iat is often intentionally destroyed or hidden wow you might look at the file and see zero imported functions which is a huge red flag on its own i mean a windows program that doesn't ask windows for a single piece of help that's physically impossible yeah it means the malware is hiding its toolbox and plans to resolve those functions dynamically in memory like only after it unpacks itself now you're thinking like an analyst ah so we've analyzed the dormant file we know its structure let's move to the execution phase let's do it what happens the exact moment that user is tricked into double-clicking our invoice.exe in their downloads folder well this goes back to my scenario at the start of the deep dive the user clicks it but the file just disappears right i have to push back on this mechanically though like if i open a regular word document and then try to delete that file from my hard drive while it's open windows throws a massive error saying file is open in another program it blocks the deletion the standard file lock exactly so how does the malware delete itself while it's actively running it uses an anti-forensic technique we call the melt process it bypasses that windows file lock restriction through a really clever sequence of events okay let me do it so when invoice.exe runs from the downloads folder the very first thing it does is copy its own executable file to a hidden or less obvious system directory usually the app data folder or some type of file like the one you're using right now and then it's going to use the temporary directory.

Exactly.

So the hidden copy is now running in memory.

And the original copy in the downloads folder.

It just closes.

Wow.

It will either drop a temporary batch script onto the hard drive.

They don't even try to hide the name.

Or instead of a script, it will just invoke the Windows command line quietly using cmd.exe.cda.

That is absolutely brilliant.

By the time the user realizes something weird just happened and calls IT, the original file is already gone.

The incident responder comes looking for the payload, and they're staring at an empty folder.

Exactly.

Right.

Okay.

So the malware is still running from the app data folder.

Yeah.

Well, because malware authors evolved beyond simple process creation years ago.

In Windows, the API function to start a new program is create process.

Yeah.

So the API function to start a new program is create process.

Yeah.

Right.

So they use process hollowing.

Instead of running as an independent suspicious process, the malware hides inside the empty shell of a completely legitimate, trusted Windows process.

It's like a digital carjacking.

Or like a hermit crab taking over a discarded shell.

It's like Svcoast.exe driving normally down the street.

But the malicious payload has secretly thrown the original driver out and is now sitting behind the wheel.

Because when you are reading logs tomorrow, you really need to recognize this pattern.

Step one.

The malware calls create process to start a legitimate tool like Svcoast.exe, but it passes a specific flag called create suspended.

And they leave it in park.

Perfect analogy.

The malware calls a system function called end to unmet view off section.

This is the actual carjacking.

It literally hollows it out, leaving a void inside the trusted process boundary.

We now have a trusted Windows process name, but it's completely empty inside.

Step three.

And then it calls write process memory.

Right.

The hijacker gets behind the wheel.

Right.

Exactly.

So step four.

And finally, the malware calls set thread context to point the execution's starting line to its newly injected code.

It calls ResmThread.

You got it.

I mean, the file path points to the real C Windows System 32 as vcoast.exe.

Yeah.

If Task Manager says everything is fine, how do I actually catch this?

Well, the operating system is showing you what the malware wants it to see.

Okay.

To catch the hermit crab, you have to look deeper into the Windows kernel space, specifically at the virtual address descriptor, or the VAD tree.

Explain the VAD tree for me.

The VAD tree is the operating system's private internal map of who is allowed to use which blocks of memory.

Ah, okay.

Right.

Ah, I see.

Yeah.

You've caught the lie.

You bypassed the illusion entirely.

It's doing its thing.

What happens when the user shuts down their laptop at 5 p.m.?

The RAM gets wiped clean.

Exactly.

They need some kind of anchor.

And I know the first place everyone looks is the Windows registry, specifically the basic run keys, like current version run.

If a program puts its path there, Windows just automatically starts it upon login.

But that is malware 101.

As a high-end analyst, you have to hunt in the deeper persistence hotspots.

Like what?

They use the built-in Windows utilities tasks.exe to quietly set a trigger that relaunches the malicious code every time the system boots or maybe, you know, every day at noon.

Oh, yeah.

So the malware just blends right into the background noise of normal administration.

But if a threat actor wants highly privileged, deeply embedded persistence, they will target service creation.

Yeah.

They handle core operating system features like network translation, printing, event logging.

Stuff the user never sees.

They run completely invisible to the user.

Like what's the actual technical advantage over a scheduled task?

Pure and simple.

Oh, right.

System is the absolute highest privilege level on a Windows machine.

Oh, wow.

That's game over.

And to make it even stealthier, they rarely create a brand new standalone service.

Because a new, weirdly named service sticks out in the logs.

Walk me through what that means.

So to save memory, Windows groups multiple related services together into a single shared process.

So to save memory, Windows groups multiple related services together into a single shared process.

So to save memory, Windows groups multiple related services together into a single shared process.

Each of those is hosting a group of shared services.

Right, I've always wondered why there were so many of those.

I've always wondered why there were so many of those.

Exactly.

It literally piggybacks on a trusted Windows infrastructure.

Man.

But hidden deep in its registry parameters, the service path is pointing straight to the malicious payload.

Okay, let's zoom out a bit.

We have.

We saw the melt process erase the original file.

And we found its persistence anchors in scheduled tasks and background services.

Right.

But if I'm sitting in the lab tomorrow, how do I actually prove this happened on my victim's machine?

You have to combine static analysis with dynamic analysis.

Give me a practical example of how we map that out.

Okay.

cmd.exe slash ctasks slash create slash tn windows update.

It looks like it wants to create a fake scheduled task named windows update.

But it's just text.

It just shows intent.

So you take that static clue.

And you move to dynamic validation.

You boot up your isolated lab environment.

Okay.

You let it off the leash.

And as you scroll through the massive wall of ProcMon logs, you filter for process creation.

Suddenly, you see the malware spawn a new cmd.exe child process.

And there it is, stask, slash, create, slash, tn, windows update.

You just connected the dots.

You map the static intent, the strings sitting dormant in the file, to the dynamic behavioral footprint left on the live system.

You now have a proven, irrefutable artifact trail of exactly how this malware operates and persists.

You have reverse engineered the trick.

So to summarize our mentor session today for you listening, you now know how to read the PE format like a book and check the IAT toolbox to predict capabilities.

You know, to anticipate the melt process, deleting the original evidence.

The VAD tree.

And you know how to hunt in the deep persistence hotspots.

Malicious services and scheduled tasks.

What do you mean?

It effectively becomes fileless.

Which raises a really critical question for you to take back to your desk.

Wow.

It forces us to question the very fabric of the system.

Because at the end of the day, when you step up to an incident, the system is going to try to show you a magic.

It's going to show you clean processes, empty folders, and normal-looking services.

Don't look at the empty hand.

Look at the mechanics.