While looking into modern OS security models, I’ve been thinking about what I call the “Windows Trust Gap.”

At a high level, it comes from how trust can propagate between processes.

In Windows, when one process launches another process, the new process often inherits parts of the security context, permissions, and trust assumptions of its parent. In most situations, this behavior is necessary for compatibility and application workflows.

For example, a typical execution chain might look like:

User
→ opens a document
→ Microsoft Word launches
→ Word spawns another process (PowerShell, rundll32, mshta, etc.)

Because the parent application is trusted, the operating system may initially treat the child process as part of the same trusted workflow.

Attackers frequently take advantage of this design through what’s commonly known as Living-off-the-Land techniques (LOLBins), where legitimate Windows tools are used to execute malicious actions without introducing obvious malware.

Some commonly abused components include:

• PowerShell

• mshta

• rundll32

• wscript

• regsvr32

Instead of dropping a traditional malware binary, attackers chain together trusted system utilities that already exist on the system.

This creates a subtle challenge:

The system trusts the tools, but the workflow itself may be malicious.

Windows has introduced multiple mitigations over the years:

• SmartScreen

• Attack Surface Reduction rules

• Application Control / WDAC

• Defender behavioral monitoring

But the fundamental challenge remains tied to backward compatibility. Windows must still support decades of enterprise software that relies on these process relationships.

So the question becomes:

How do you enforce stricter trust boundaries without breaking legitimate workflows?

From a defensive architecture perspective, this is where behavioral monitoring and process lineage analysis become critical. Tools like EDR systems often focus on process ancestry chains rather than just individual executables.

For example:

winword.exe
   └── powershell.exe
           └── encoded command

Even though each component is legitimate, the execution pattern itself becomes the signal.

I'm curious how others here think about this trade-off between compatibility and trust boundaries in Windows.