Windows APT Warfare: Identify and prevent Windows APT attacks effectively

Ever wonder what happens in that split second when you click on a program.

It seems so simple, doesn't it, Yeah, exactly.

But apparently it kicks off this incredibly complex series of events deep inside your Windows system.

It's a whole journey. And you know, as we'll find out, that complexity can sometimes well, it can open doors for vulnerabilities.

Right, So today we're doing a deep dive into that hidden world Windows internals. We're using that book you shared, Windows ABT Warfare as our guide.

That's the one. And yeah, this isn't your average user guide. It's really aimed at people who want to get under the hood of Windows security.

Wise, like engineers, malware folks.

Exactly, Windows engineers, malware researchers, ethical hackers, people like that. It gets really hands on with stuff like reverse engineering, exploit development, how attacks actually work at a low level.

Okay, So our mission today then is to pull out the really crucial, maybe even the mind blowing stuff from this book.

Yeah, to still it down right.

We want to give you the listener those aha moments about how Windows programs get built, how they run.

And critically, how that whole process can be targeted, how it can be manipulated by attackers.

Exactly, trying to cut through some of the heavy technical jargon and make it, you know, engaging.

Absolutely think of it as a guided tour of Windows Core using the book's insights. We'll hit the key mechanisms, the security side of things, so.

You get a quick but hopefully thorough grasp of some fundamental ideas.

Right, and this knowledge is honestly pretty powerful, whether you just want to stay informed, or understand software better, or maybe even prep for some technical cybersecurity chats.

Okay, let's get started in time for that deep dive into Windows APT warfare, uncovering how programs come alive and why that's maybe a double edged sword sometimes.

Let's do it. We should probably start right at the beginning the journey. A simple C program takes from code someone writes to well to a running process on your.

Machine, even just Hello World, Right, seems basic, but there's a whole transformation happening behind.

The scenes totally. First up, you've got the C compiler.

Okay, what's its job? Exact?

It basically translates that human readable C code into assembly language assembly.

Now, for those of us maybe not deep into coding, how's that different? From C. Why does that matter here?

Good question. C is relatively high level, closer to how we think. Assembly is much much closer to what the computer's processor actually understands.

So like direct instructions for the chip.

Pretty much each assembly line is usually one tiny instruction for the processor. And understanding that level is key because a lot of core Windows functions and definitely malware operate down there.

Okay, so C to assembly, then what there's an assembler involved too?

Yep. The assembler takes that assembly code and turns it into the actual machine code.

The raw binary ones and zeros.

That's it, the processor's native language.

The book mentioned tools like TDMGCC visual Studio, those are the things doing this compiling and.

A SI exactly those tools integrated development environments. They handle all these steps for you, packaging your C code into that final runnable file.

But it's not just the machine code thrown into a file, is it? The Windows linker steps in here? Sounds important?

Oh, absolutely crucial. The linker takes all the compiled machine code, grabs any other bits of the program needs like libraries, data, and packages it all up, packages it into the portable executable format, the PE format. That's your standard dot ex file in Windows.

Okay, PE format. What key things does the linker pack in there? The book's mentioned a few.

Right, Well, it sets a default image based address often zero by four hundred thousand. That's like the program's preferred home in memory referred okay, And it organizes everything into sections within that PE file, like.

The dot text section. What's that for?

That's where the actual executable code lives. Then you've got dot I data read only data like text string exactly like your Hello World string. And then there's dot iData that holds the import address table or IAT BIAT.

Something tells me we'll be hearing more about that one. What's its job?

Think of it like your program's phone book for outside help. It lists all the functions your program needs to call from other places, usually Windows own libraries.

The DLLs, so it knows who to call for certain tasks, right, And.

When your program runs, Windows uses the IAT to find the actual memory addresses of those functions. But crucially, if an attacker can rewrite those phone numbers.

Ah, they can redirect calls to their own code exactly.

It's a key vulnerability point. We'll definitely come back to that The linker also adds the optional header tons of metadata the loader needs later.

Okay, so we've got this static PE file on disc How does it become a living, breathing process in memory. That's the system application loader's job. Yep.

The loader takes that PE file and brings it to life. It reads those sections code data imports, and carefully places them into memory.

Following the instructions in the pehaders.

Precisely using that base address as a starting point. It writes the sections to memory at the right offsets and does some initial setup to get the program ready to run.

So it's not just copying, it's really constructing the process and memory more dynamic than.

I thought, absolutely, and getting this initial journey CCODE to running process. It's fundamental. It really sets the stage for all the security stuff the book dives into later how this very process gets targeted.

Right, So building on that, how the PE file gets made. Chapter two looks at how that static file actually lays out in memory when it's running process memory.

Yeah, how those PE parts, the doss header, the NT headers with the file header, and the optional header, the section headers. How they all get mapped into the process's virtual memory space.

It's all structured following the rules laid out in those headers exactly.

The book talks about the file mapping process, how the system copies bits of the PE file into memory addresses. It uses things like size of headers.

That's how big the header part is, right, and.

Then to raw data and relative virtual address RVA guide where the content of each section goes in memory.

RVA relative virtual address so like an offset from the.

Start pretty much an address relative to the module's base address in memory. Understanding rva's is key if you ever want to pick apart a PE file or understand how things link up internally.

Okay, and knowing how this mapping works leads into some well, some shadier techniques discussed in the book, Yeah, like PE infection or PE patching.

Yeah. The core idea there is adding your own malicious section, maybe with some shell code.

Shell code being that small, self contained bit of malicious.

Code, right, You add that to a normal program. Then you tweak the program's entry point.

So when the program starts, it runs the malicious code first.

Exactly, it gets redirected. It sounds really hard to spot too, would.

A normal user even notice anything? What are the signs?

That's the tricky part. The original program might still seem to work fine afterwards, maybe it takes a bit longer to start unusual network activity. Security software might flag it, hopefully by spotting the extra section or the modified entry point. But yeah, it can be subtle.

The book used that Pikachu volleyball example. Right, infecting pickaball dot ex.

Yeah, you think you're launching a game, but note something else runs first really drives the point.

Huh, definitely. And then there's process hollowing That sounds even sneakier.

It's a step up, for sure. An attacker starts a legitimate process, say Google Update dot ex, but pauses it immediately creates it in a suspended state.

Okay, so it's loaded but not running code yet. Right.

Then they basically hollow it out. They unmap its original memory and replace it entirely with their own malicious code.

So the legit process is just a shell, a container for the bad stuff exactly.

And the really deceptive part, the process's internal data structures like the people we'll talk about, might still point to the original Google Update dot.

Ex, so it looks legitimate to the system.

It can. Yeah, the book even says sometimes the original digital signature can appear valid because the systems looking at the initial process information, not the hollowed out content, makes detection way harder.

Wow hiding and plain sight. The book also mentions tiny linker. What's that about?

Oh yeah, tiny linker, It's about building a really stripped down minimal compiler and linker.

Why would you do that?

Well, partly to understand the absolute bare minimum needed for a PE file, But attackers like it because they can create incredibly small executables, tiny payloads that might slip past some security checks that look for larger, more complex files.

Okay, so from legit programs loading, we're already seeing how those mechanics get twisted. Chapter three moves on to how running programs talk to Windows Dynamic API calling.

Right, programs need to ask Windows to do things open files, show Windows talk to the network. They do this by calling Windows APIs application programming interfaces. Often this happens right down at the assembly code level.

And there are rules for how these calls are made. Conventions like WinAPI exactly.

Calling conventions are like protocols for function calls. They dictate how arguments get passed on the stack in registers. Who cleans up the memory afterwards, where does a return value go?

The book used message box as an example.

The pop up box yeah, a classic example of the WinAPI convention. Parameters usually pushed onto the stack right to left, and the message box a function itself, cleans up the stack when it's done.

Okay. Then the book introduces these really important but apparently often undocumented structures, the TEB and the PEB.

Ah Yes, the thread environment block TB and the process environment block P. They hold a gold mine of info about a running program.

So TEB is for threads, individual execution.

Paths, exactly thread specific data. The book highlights fields like exceptionalists for error handling, stack base and stack limit defining the threads, stack memory, client TITE holding process and thread IDs.

And crucially a pointer to the P right and.

A pointer to itself. So the PAY, on the other hand, holds info for the entire process.

What kind of stuff is in the P.

Things like the being debugged flag. Malware hates debuggers, so they check this. There's the image base address where the main program module loaded process parameters, has info like command line arguments, and a really important one a pointer to pebble door data.

Pebble door data sounds like it releads to loading things.

It does. It's all about the modules, the DLLs that the process is loaded into its memory.

So these TIB and PEB structures give a program context self awareness, and the book says you can sometimes access this info directly without using standard Windows functions.

Yeah, especially in thirty two bit Windows. The FS segment register often points to the teb letting code access feels directly GS register in sixty four bit. This is how stealthy malware can gather info about its environment without making noisy API calls that security software might be watching.

Sneaky at pebble. D R data structure sounds key then for tracking loaded DLLs.

It is. It contains links inload order. Modulist tracks DLLs in the order they loaded. In memory order. Modulists tracks them by memory address, an initialization order. Modulist, well, that's about initialization order.

And each entry in these lists is an LDR datable entry holding details about each DLL YEP.

Things like the DLL's base address in memory dll base, its entry point, its size, its full path and file name, a full down name based a law name, even a load count showing how many times it's been referenced.

Wow tons of detail, and the book explains how attackers can use this.

Walk through these lists exactly. They can traverse the pet LDR structure follow the pointers in those link lists to find the base address of a specific DLL they need, like kernel thirty two dot dll.

Without calling load library or get module handle.

Right, they find it manually internally evades detection that might be watching those specific API calls. It's like using an internal undocumented map instead of asking for directions.

Very clever. It gets worse the can thisss with these entries.

Yeah. The book mentions techniques to actually modify the LDR datable entry structures. You could potentially rename a loaded DLL in memory, just change the name string to confuse analysis tools, or even unlink malicious DLL entirely from these lists hide module, making it invisible to standard enumeration methods.

That's serious manipulation. The chapter also mentions parameter forgery changing command line arc briefly.

Yeah, create a process suspended, then go into its PEB and fiddle with the process parameter structure to change what command line arguments it thinks it was launched.

With so many ways to mess with a process. Once you understand these internals. Okay. Chapter four goes back to shell code, specifically how it finds those Windows API functions it needs. Right.

Because shell cut often gets injected in weird ways, it can't rely on the normal loading process setting up that import address table IAT for it. It has to find functions itself dynamically at run time.

And the key is the export address table the E within.

Each LL Exactly, The ET is like the dla's public directory. It lists all the functions the DLA exports for others to use what's in the ET. It has a few key arrays. Address of functions points to the actual code for each exported function, as rva's address of names points to the names of the functions, and address of name ordinals maps the names to ordinal numbers.

So shell code can read this ET to find the address of, say, create filet A inside kernel three D two dot DL precisely.

The book even talks about building a simple tool to purse a DL's ET and list its exports. Then it shows how shell code uses the TBNP tricks we just discussed to first find the DL's base address and memory.

Like finding kernel threet two dot DLL's.

Address right, and then it manually parses that DL's PE headers to find the ET, and then searches through the ET's arrays address of names, address off name ordinals, address of functions to locate the exact memory address of the specific function at once.

All without calling get proke address.

Exactly, totally self sufficient, like a little detective inside the process memory.

That's amazing. The chapter actually walks through writing by eighty six assembly shell code to do this.

That sounds intense, it is definitely low level. The thirty two B shell code dot atism example in the book is detailed shows accessing TUB, finding PAYAB, walking the LDR list for kernel thirty two dot DL, parsing its headers, finding the EET, and then crawling the ET tables to get the address for fatal exit. It's a masterclass in manual low level function resolution.

Phew. Okay, But for those not quite ready for assembly, the book mentions automating shell code generation from C or C plus plus AP.

Yeah. Thankfully, there are tools and techniques to compile CC plus plus code down into position independent shell code, which makes it much more accessible. Kind of bridges the gap makes.

Sense, okay. Chapter five dives deeper into the application loader itself, especially that import address table, the IAT. We keep mentioning.

Yeah, the IAT is just so central to recap. It's that table of function pointers and module. When the loader loads your program at, the IAT sees which functions you need from other DLLs, goes.

And finds the real addresses of those functions in memory.

And patches the IAT, filling in those pointers. So when your code calls say create filarea, the IAT entry now points directly to the real create filia code loaded somewhere in memory, connects the dots exactly. It wires everything up. And the book then covers a really advanced technique loading and running a whole ex inside another process's memory, no separate file on disk.

Yeah, super stealthy used by APT groups.

Yeah, The book mentions threat actors like Mustang, Panda, APT forty one, and even tools like metasploit using this for stage payloads. It avoids creating a new process that security tools might immediately notice.

Makes sense. Then there's IAT hooking, another way to mess with these function calls. Yep.

With IAT hooking, you modify the IAT after the loader has filled it in. You change a pointer that should go to a legitimate function like message box A to point to your own malicious function instead, so.

The program thinks it's calling the real function but gets hijacked exactly.

The book uses message box A hijacking as an example. Legitimate uses exist, like in game plugins or sandboxes, but malware uses it to intercept data, redirect control flow, things like that.

And then DLL sideloading comes up again.

Right exploiting that search order program needs some dot DLL. Loader checks the program's own folder first, then system thirty two, et CETERA. Attacker puts a malicious sump dot DLL in the program's folder, and the.

Loader finds and loads the malicious one before it ever looks in system thirty two.

That's the idea. The book uses hijacking Chrome with a phadversion dot DLL as an example. Very common attack vector.

And DLL proxying. What was that?

That's a variation. The malicious DLL gets loaded via sideloading, but it actually exports all the same functions as the real DLL it replaced. When the program calls a function, the malicious DLL might do something bad first, then it proxies the call, passing it along to the actual legitimate DLL, which it loads itself.

So the program still works, but the attacker gets their code executed too clever. Chapter five really shows the loading process is full of potential attack surfaces. Chapter six talks about PE module relocation. This is about loading things at different addresses exactly. Remember the linker sets a preferred image based address right like zero by four hundred thousand.

In a running system, that address might already be taken by something else, So the program just fails, not necessarily. That's where relocation comes in. It's a mechanism built into the PE format that allows a module to be loaded and run correctly even if it lands at a different address than its preferred one.

How does that work? Does something get adjusted?

Yes, there's a relocation table inside the PE file. It lists all the places in the code and data that contain absolute memory addresses addresses that assume the module is loaded at its preferred image base.

Ah. So if it loads somewhere else, those addresses would be wrong exactly.

So when the LOADO puts the module at a different address, it reads this relocation table and goes through and fixes up all those listed addresses, adjusting them based on the actual load address.

Making sure all the internal pointers are correct.

For the new location precisely. The book mentions tiny loader again here showing how a custom loader like ploader dot cpp can handle this. It parses the relocation table and applies the fix ups when loading a module, often using virtual allock to get memory wherever it can, and then carefully patching the loaded code and data.

Very important for those in memory loading techniques we discuss Okay, chapter seven packers. We've probably all run into packed executables. What's the deal with them?

Packers are tools that basically wrap an executable. They compress it, maybe encrypt it, definitely obfuscate it. The original program gets bundled inside a shell or stub.

So it's like putting the real program inside a protective.

Box kind of yeah, or maybe a confusing box. The book shows how the memory layout changes. You often get a section marked readable, writeable and executable text up x, where the un packed code will go. You get a payload section holding the packed original program, and you get the packer stub COODE.

And the stub is the code that does the unpacking.

YEP. When you run the packed file, the stub executes first. Its job is to decompress or decrypt the payload into that textrap x section. Often it also has to act like a mini loader itself, fixing imports, handling relocations for the unpacked code.

And then it jumps to the original program starting point.

Right jumps to the original entry point OEP of the now unpacked program, and the original application starts running, hopefully unaware it was ever packed.

Other different kinds of packers.

Broadly, Yeah, compression packers like upx or mprs mostly just aimed to make the file smaller. Protective packers like VM protect themta Enigma protector. They focus heavily on making reverse engineering and analysis really difficult.

How do they do that? What are these anti reverse engineering tricks?

Oh? Loads of them. Obfuscation, making the code intentionally confusing, anti VM checks, trying to detect if it's running in a sandbox, Anti debugger tricks checking that PEB being debugged, flag using weird API calls to crash debuggers.

Anti tampering too, like checking file integrity.

Yeah, using checksums, maybe comparing against the pe headers checksum, checking digital signatures authenticode. Some even use virtualization. They translate the original code into a custom bytecode and run it on a tiny virtual machine. Embedded in the packer stub, super complex stuff.

Plus commercial features like licensing checks sometimes right.

The book also touches on building a simple packer, reading the original ex compressing it, writing an assemile stub to handle unpacking, combining it all using tools like YASM and GCC.

And the unpacker stub itself has key parts right.

Yeah, routines like decompress image, recarnate HDR to rebuild the pehaders for the unpacked code, and look a poet to find where to jump. The book uses packing an old game and a schnaft as an example shows the size reduction, but more importantly how tools like IDPro can't easily see the original game code anymore. It's all hidden inside the packer stub and payload.

Okay, moving to chapter nine. Digital signatures in Authentic Code. We see these all the time when downloading stuff. What's their main job?

Authentic Code is Microsoft's tech for signing code. Two main goals verify the publisher is this really from who it says is from? And verify integrity have this file been messed with since it was signed?

Relies on trust right certificate authorities.

YEP, trusted CAS vouch for the publisher's identity before issuing the certificate used for signing.

The book mentioned embedded versus detached signatures.

Right embedded is most common for exs and DLLs. The signature data is literally tacked onto the end of the PE file itself. Detached signatures are separate, maybe in catalog files, often just containing a hash of the sign file.

So Windows checks that embedded signature when we run a downloaded.

Ex usually yeah, using APIs like when verify trust. Different file types actually use different backend components called subject interface packages SIPs to handle the specifics of validation.

And hashing is key for the integrity check.

Absolutely, a cryptographic hash is calculated over the executable's content. But, and this is crucial, certain parts are excluded from the hash, like what the p header's check, some field, the security directory entry itself which points to where the signature is stored, and the actual signature block data are all skipped during.

Hashingh skipping the signature block itself that sends an exploit opportunity there. But first, mock signatures? Can you just fake one?

The book tries it copies the signature block from a signed file like Google Update, dot ex and paste it onto an unsigned one like Pikachu Volleyball.

Do it work?

Nope. The signature data is there, but the hash embedded inside that signature block belongs to Google Update, not Pikachu. When Windows calculates Pikachu's hash and compares it, they won't match. Verification fails.

Okay, so simple copying doesn't work. What about bypassing the hash check?

Now you're talking. The book mentions research by Matt Graeber showing how you can potentially hook or patch the verification function in memory, specifically crypt SIP verify indirect data to just always return true, always say the signature is valid even when it's not.

So you trick the system into thinking the check past even if the hash is wrong.

Essentially, yes, a way to make a fake signature look legit at a certain level.

Wow, and signature steganography hiding stuff in the signature.

Yeah, this exploits that exclusion we mentioned. Since the signature block itself isn't hashed, you can append extra data after the actual signature data within that block. You just need to update the size field correctly.

And the signature still validates it.

Can Yeah, the original signed hash is still correct for the original part of the file, but now you've smuggled extra data inside the signature block, potentially hiding malware payloads where scanners might not look closely.

Very sneaky. Lastly, getting signed by abusing path normalization exploiting how Windows handles paths.

This is another subtle one, again based on path normalization research. If you create a file with a weird name like Google update dot ex with a trailing space, Windows might normalize that path differently during signature checks compared to other operations.

So you can have a legitimate Google update dot ex with a valid signature, and maybe a malicious Pikachu volleyball file at a path that normalizes to look like the Google update path during the check.

Under certain complex conditions. Yes, it's about creating collisions in how paths are interpreted, potentially tricking the system into associating a valid signature with the wrong file. Due to these normalization quirks.

The man signatures are way more complex and fragile than they seem. Okay. Chapter ten User account Control UAC, and bypassing it, UAC is meant to stop malware getting admin rights easily. Right.

That's the goal. Stop programs from getting elevated privileges without your permission. It runs most things as a standard user, even if you're logged in as admin, and prompts you when something needs more power. Only certain trusted system services can bypass the prompt automatically.

The book mentions Ray launch admin process in a pinfo dot DLL. What's that?

That's described as the core function in the UAC service that handles elevation requests. It receives the request, validates it based on rules, and if it passes, launches the process with admin rights. It takes parameters like the executable path, command line, et cetera. It's the gatekeeper and.

It has checks A two level authentication Yeah.

Authentication A and B.

What do they check?

Authentication A is mostly about the path. Is it running from a trusted system location like CU Windows? Is it on a known blacklist? Authentication B is stricter. Does it have a valid digital signature? Does the filename maybe match internal version info? If a program passes both checks, it can.

Get elevated automatically.

No prompt exactly. If it's configured for auto elevation, like many built in Windows tools, are has a valid signature and runs from a trusted path UAC might let it elevate silently.

Which naturally leads to bypass techniques trying to meet those conditions illegitimately.

You got it. The chapter covers several ways DLL sideloading again but targeting one of those auto elevating privileged processes. If you can get your malicious DLL loaded by one.

Of them, your DLL runs with elevated.

Rights too, bingo. Another way is using elevated comm objects CALM objects, yeah, component object model. Some COMM objects, like ifile operation for file tasks are designed to run elevated. A low privileged process might be able to create and use one of these elevated objects to perform admin level actions by passing the usual UAC flow. Wikileaksvault seven mentioned stuff like this.

Then there's CMSTP Connection Manager Profile.

Installer right, another legit Windows tool, CMSTP dot exc that can be abused by crafting a malicious dot inf file and tricking CMSTP into processing it. Attackers found ways to execute arbitrary code with elevated privileges. Often involves making the attacker process look like explore dot ex and messing with its.

Pebe and finally trusted path collisions again using long.

Paths YEP back to path normalization. An attacker puts their malicious executable maybe one vulnerable to DLL side loading itself like BitLocker wizardleve dot exc in the books, example, in a non trusted location, but they use a very long or weirdly constructed.

Path, so that when UAC checks the path after normalization, it.

Looks like it's coming from a trusted directory like System thirty two, even though it isn't really there. The check pass is based on the normalized path, and UAC might grant auto.

Elevation, exploiting the gap between the real path and how the system interprets it for checks. Wow. Okay. Finally, the appendix NTFS paths symbols.

Why is this important because so many security checks, as we've seen, rely on comparing file paths. Understanding how Windows defines paths when thirty two versus antipaths, how it converts and normalizes them is crucial for finding bugs or ways to trick those comparisons.

The book mentions different path types DOS paths, UNC paths, and that prefix being special.

Yeah. The prefix tells Windows don't normalize this path much and allow it to be longer than two hundred and sixty characters. It bypasses many standard steps which could be abut oh yeah. The appendix gives examples creating folders with trailing dots or spaces that confuse, explore, using path normalization differences to bypass signature checks, even how the CD command

What a deep dive. That was seriously intricate stuff, all pulled from Windows APT warfare. Looking back, what's the big picture takeaway for you?

For me, it's just the here hidden complexity. Clicking an icon seems simple, but the journey from code to process, the memory layout, the API calls the security layers like signatures in UAC.

It's incredibly deep and every layer has potential weaknesses.

Exactly every mechanism from PE loading to path handling can potentially be manipulated or subverted. If you understand it well enough. It really highlights that constant cat and mouse game between attackers finding flaws and defenders trying to patch them or detect exploitation.

Right and hopefully for you listening, getting even a glimpse of these underlying mechanisms helps make sense of how software works, maybe helps you spot weird behavior, or just understand the news about security breaches a bit better.

Absolutely, if any of this sparked your interest reverse engineering, malware analysis, Windows internals, generally, definitely dig deeper. The book itself, Windows APT Warfare and its githab Repo seem like great starting points for more hands on exploration.

Definitely. So maybe the final thought to leave you with is this, in this world where cyber shreds are always evolving, always getting more sophisticated, isn't.

Really understanding these fundamental building blocks, the very guts of the operating system like we've touched on today. Isn't that the most critical foundation for both the attackers and the defenders.

It really feels like it's all about continuous learning, right Yea. The deeper we understand these internals, the better equipped we all are