Malware Blueprints in Portable Executable Headers

Imagine you're staring at a screen filled with just two million random letters and numbers.

Right, a complete wall.

And you're supposed to make sense of it.

A very detailed map.

A map that tells you exactly how an attacker plans to compromise your network, what tools they brought with them, and where they're trying to hide.

So today we're doing a deep dive into your research notes on reverse engineering and malware analysis.

Those reports are fantastic for practical context, by the way.

So we are settling in for a focused technical mentorship session today, just the two of us looking at this map.

Right, Rima clarity.

of a portable, executable, or PE file.

Because a lot of junior analysts see a hex dump and they just freeze.

It's a critical shift in mindset for any security researcher, really.

Like just a block of math.

But see, the very beginning of that file, the portable executable header, the PE header, it isn't random data at all.

A blueprint for a building.

It contains the precise instructions that the Windows operating system loader actually needs to, you know, map that file into memory and run it.

Treating the file not just as code, but as a literal battle plan.

We always tell you guys, the listeners, to jump straight into the code, start looking for malicious functions.

But looking through the materials here, it's clear the header tells a massive part of the story before you even fire up your debugger.

Before you execute a single instruction safely in your VM.

So, let's start at the absolute beginning, offset zero.

Right.

Right.

And in ASCII, that translates to the letters MZ.

That is the historical origin, yeah.

Oh, yeah.

Yeah, back in the early 1980s.

Wait, I have to stop you there.

If the MZ signature is just a legacy historical artifact from the 80s, why does a modern 64-bit Windows 11 system still demand it be there?

Like, why haven't we evolved past a 40-year-old initial?

Well, it really comes down to the rigid mechanics.

Okay, walk me through that.

A bouncer.

When a process creation request starts, the loader doesn't read the whole file at once.

Just the MZ.

If it does not see 45A, it immediately aborts the process.

Yeah.

It's not a valid executable.

Just instantly reject it.

But the MZ isn't just a nostalgic badge, right?

Right.

And buried inside that DOS header at a specific offset called alpha new is a pointer.

Yes.

Which is the letters PE followed by two null bytes.

So the MZ is basically a signpost pointing to the real starting line.

Let me ask about the mechanics of a really common trick that trips up beginners in the lab.

Yeah.

They know you, the victim, won't click something called malware.exe.

No one clicks that.

A classic move.

From what you're saying about the loader being a strict bouncer, does a simple name change completely break the execution process?

It doesn't care at all.

The extension is mostly a user interface convenience.

Oh, that makes sense.

The magic bytes.

If the operating system is forced to evaluate that file, say, some other process calls it, the loader looks at the internal header.

Right.

It follows the alpha new pointer to the PE signature.

Your internal structure dictates you are a portable executable.

It will absolutely attempt to map it into memory as code.

The static analysis fundamentals.

Static analysis always begins with identifying the true file type through internal magic bytes.

Never trust the extension.

The environment setup.

Once the loader verifies the PE signature, it needs to know what kind of environment to actually prepare.

The zoning laws for our building, so to speak.

Let's go.

There are two specific fields you highlighted.

So the image optional header is a bit of a misnomer, to be honest.

Right.

This is where the loader gets the hardware and environmental requirements.

Let's break down machine type first.

So for instance, a hex value of 0x0x014C instructs the loader that this is in by 8632.

And for a 64-bit?

Simple enough.

The subsystem field tells the OS how to handle the user interface.

Yes.

A graphical user interface.

Okay.

Okay.

Let's start with the GUI.

Let's start with the GUI.

Let's start with the GUI.

Let's start with the GUI.

Let's start with the GUI.

The GUI means the OS comes into the device.

So when you add a GUI into the device using theoh 그� listener sample against another agency, let's pick a desires-ection.

Then it doesn't go away.

It doesn't grid as a built-in support Mae, though, since it完 ут costing this seminal.

parameters also well because the machine type is by 86 you know instantly you need to provision a 32-bit windows virtual machine for dynamic analysis oh because if you run it on 64-bit if you try to run it in a native 64-bit environment without the proper emulation layers it might just crash or worse it might exhibit altered behavior which completely ruins your analysis exactly you get bad data and the subsystem value of two that gui flag that is the real warning sign for malware like njrt wait really because it tells you how the malware intends to present itself to the victim actually precisely the opposite it tells you how it intends to hide hide with a gui yes think about it legitimate gui applications use that subsystem to draw windows right buttons visual elements on the screen yeah but malware authors use the gui subsystem flag so that the operating system doesn't spawn a default command program to draw windows right buttons visual elements on the screen yeah but malware authors use the gui subsystem flag so that the operating system doesn't spawn a default command prompt window when the process executes oh wow i've never thought about that and jr adi wants to run completely silently in the background so if you use the console subsystem a big black box would pop up on the victim screen exactly it would be an immediate red flag so if you the analyst see a gui subsystem in the header and you execute the malware in your sandbox and nothing visual happens right you shouldn't assume the malware is broken you should assume it's successfully loaded into memory and it's currently operating invisibly that is brilliant you are literally reading the due print to predict the attacker's evasion strategy before they even execute that's the power of the header okay so the loader has checked the signatures it has provisioned the correct environment based on the machine type and subsystem the plot is secured right now it needs to actually start moving the files contents into the computer's memory your email ebook notes focus heavily on the section table here this is a crucial part if the header is the blueprint this really looks like the actual floor plan of the building the floor plan analogy is highly accurate yes the section table is basically an array of headers that describe the different functional chunks of the executable the rooms of the house exactly when the loader maps the file into virtual memory it places these different chunks into distinct memory regions based on this table okay let's walk through these rooms the most critical one seems to be the dot text section the dot text section yes the engine room i see in the notes that the dot text section is where the actual cpu instructions live the compiled machine code that is where the actual logic resides but why does the os bother separating the instructions into their own specific room i mean why not just mix the code and the data together in one big block see that goes straight to the heart of modern memory protection mechanisms securing boundaries right the operating system needs to apply very specific permissions to different areas of memory to prevent exploitation like buffer overflows exactly the dot text section contains instructions the cpu must execute so the loader grants the specific memory region execute permissions make sense it has to run however it usually denies write permissions this is known as w XOR X or write XOR X acute ah I see may make sure I have this so if the memory region is writable it shouldn't be executable yes and if it's executable like the dot text section it shouldn't be writable correct fundamentally if you misinterpreted any sources into the gameplayfile when you write as it's not valid you have to first mixed data and code, an attacker could potentially execute a buffer overflow attack.

And then force the CPU to execute that variable.

That is so elegant.

The storage pantry.

If .txt is the engine room, .data is the pantry.

The statting information it needs to access.

Since it only holds data, it gets read and write permissions, but never execute permissions.

But malware doesn't always play by the rules.

Which means during your analysis, if you are looking at the section table and you see a .data section that has been manually granted execute permissions by the OS, that's a massive red flag.

It immediately suggests the malware plans to unpack hidden code into that data section and run it.

That leads perfectly into the third room you highlighted in the Rima notes, the .rsrc section or the resource section.

The attic of the executable.

Like icons, dialog box menus, maybe some embedded audio files or multi-language strings.

Right.

The vulnerability really lies in the sheer size and flexibility of the resource section.

Exactly.

Gigabytes of stuff sometimes.

And because of this, many automated security scanners and antivirus engines are going to be able to use it.

Really?

To avoid bogging down system performance, standing massive high-res icons for malware is computationally expensive.

Unbelievable.

That's exactly it.

So the primary file, the one the victim actually clicks, that's just a small, simple dropper program.

When it runs, it reaches up into its own attic, pulls down that encrypted blob, decrypts it in memory, and unleashes the real payload.

It is a very clean example.

Right.

A completely different architecture.

It is a brilliant evasion technique, honestly.

And that's because it was in the same compartment before the malware ever had a chance to open it.

Precisely.

OK, so the malware has successfully smuggled its payload into the house.

It needs tools.

A small dropper executable doesn't usually bring its own massive, complex networking stack or file system management code.

It would be huge.

From the operating system itself.

The import address table or the IAT?

To understand it, we have to look at how Windows applications are built fundamentally.

Microsoft provides dynamic link libraries or DLLs.

Yes.

So if a program wants to create a text file on the hard drive.

Exactly.

They simply tell their program to call the create file function, which already exists inside a Windows file called kernel32.da.

Yeah.

A menu.

Yeah.

Right.

The IAT is the menu.

That is a very accurate mechanical description.

Yes.

It sees, OK, the malware is requesting create file from kernel32.dl.

And resolves the memory addresses so the malware's instructions can seamlessly jump to the Windows code.

Exactly.

The program is not allowed to execute its first instruction until the loader has successfully served every single item requested on that IAT menu.

Which means as an analyst, if we just read the menu.

That is huge.

The IAT tells a very, very specific story.

Walk me through what we see there.

OK, what is that?

Or if it specifically imports functions like Internet Open or Socket, you know, with absolute certainty that this binary contains code to communicate over a network.

It is almost certainly going to attempt to.

And what if it's importing from a WS232.dlol?

WS232.dlol handles advanced API services.

The registry.

If you see those specific functions, the malware is planning to read and write registry keys.

Like modifying the registry.

The infected machine reboots.

Or let's say you see user32.dltl importing get a syncy state.

The program is monitoring physical keyboard strokes.

Which is the absolute hallmark of a keylogger.

I want to pause there for a second.

Ah, ordinals.

If the IAT is supposed to list the names of the functions like create file, how does an ordinal change that dynamic?

To hide the menu items.

Instead of explicitly putting the text string create file in the IAT, which is incredibly obvious to you as an analyst, the attacker configures the IAT to request function number 74 from kernel32.dll.

Right.

The waiter knows the secret menu number.

But anyway.

They only see the number 74.

That is incredibly sneaky.

They can't hide the fact that they are asking for something.

So the loader has checked the signatures.

It mapped the sections.

The environment is perfectly staged.

Now, the loader has to actually start the engine.

The final step.

The entry point.

Address off entry point.

An offset from the base of where the file was loaded in memory.

When the OS loader finishes all its preparation, it takes this exact memory coordinate and loads it into the CPU's instruction pointer register.

So that is literally the big red you are here star on the map.

It's the exact coordinate of the very first operation the malware will execute.

So where does it usually point?

Right at the beginning of the developer's main code block.

Start in the engine room.

But this is where your notes on the Jigsaw ransomware report become highly relevant.

They absolutely do not.

Packers.

But let's break down the actual mechanism here.

If the entry point is the front door to the executable.

Can the attacker just like move the front door?

Really?

And encrypts the entire dot text and dot data sections into an unrecognizable blob of high entropy data.

Total gibberish.

Usually called the unpacking stub.

But.

It no longer points to the original dot text section.

Oh wow.

The ransomware doesn't actually start.

The unpacking stub starts.

When you first analyze a packed file.

You are only looking at the Packers decryption routine.

Right.

It allocates some new memory.

And then what?

The unpacking stub executes a specific instruction.

A tail jump.

And drops it directly onto the newly decrypted malware.

Yes.

Finding that specific memory address seems like the ultimate holy grail for a malware analyst.

How do you even do that?

And let the unpacking stub run.

To pause the CPU execution at the exact millisecond after the decryption finishes.

Exactly.

You can dump the newly decrypted dot text section out of the system's volatile memory.

And suddenly you have the true unhidden blueprint.

You can see the real import address table.

The real attack plan.

It really does.

Let's summarize this because it's so powerful.

Right.

You map the section table to identify where the code lives and where payloads might be hidden.

And you trace the entry point to determine if you are dealing with a packed file.

It is all in the header.

Let's leave you, the listener, with an advanced scenario to consider.

Exactly.

Yeah.

But this raises a critical question.

Right.

But attackers also employ techniques known as structural PE malformation.

They will intentionally corrupt, zero out, or overlap non-vital parts of the PE hardware.

Why would they do that?

Well, because the Windows OS loader, as strict as it is about the initial MZ and PE signatures, is surprisingly forgiving about other structural anomalies.

Yes.

So the kernel will execute it.

But our analysis tools, disassemblers like IDEA Pro or parsers like Pview.

They are built to strictly follow the Microsoft documentation.

They just crash.

Wow.

Yeah.

It's an incredibly effective anti-analysis trick.

When you open a file and your primary disassembler immediately crashes because the header has been intentionally mangled, how do you step in?

Exactly.

It's a great challenge.

Keep analyzing those anomalies.

Until next time.