DISCLAIMER: This post aims to provide an overview of Shanya and PaaS malware platforms. The Post should only give an brief overview about the topic.

Discovery

I recently stumbled upon something curious while researching, PaaS – Packer-as-a-Service (yes, not Platform-as-a-Service – different beast entirely). A name kept popping up: Shanya. Besides its linguistic meanings ('god is gracious', 'moonlight', etc.), Shanya is used to describe something broader in the security community: an EDR killer.

That got me digging. What exactly is Shanya? How does it kill EDR systems? And what's this whole Packer-as-a-Service thing about?

The Puzzle: Understanding the Basics

Before we can understand how Shanya works, we need to talk about how Windows processes actually function. The key to this whole story lies in something called the PEB (Process Environment Block).

PEB – The Process's "Identity-Card"

The Process Environment Block is basically a structured data container, and here's the important part: every single Windows process has one. The PEB sits at a fixed memory address and holds crucial information about that process.

Why Do Processes Need It?

Imagine a process as a person. That person needs to know:

- What's in my bag? (what DLLs are loaded?)
- Where do I live? (my memory address?)
- What's is my phonenumber? (environment variables?)

The PEB is essentially the process's Identity-card. It contains loaded modules (DLLs), runtime data, environment variables, and other critical information the process needs to function.

Why Is This Useful for Malware?

Here's where it gets interesting. The PEB:

1. Exists in every process
2. Lives in user-space (Ring 3, not Ring 0 - kernel space)
3. Can be read AND written by the process itself

Malwarem, if loaded into a legitimate process, essentially has direct access to its own process's "ID-Card".

TEB – The Thread's Connection to the PEB

To understand how malware even finds the PEB, we need to briefly talk about threads.

From Processes to Threads

A process is a container. Inside that container live:

- Code (your application)
- Threads (the workers executing that code)
- The PEB (information about the whole container)

Threads are the actual executors. They're the workers that run your code. Many threads working together form the running process.

So What's the TEB?

The Thread Environment Block (TEB) is the thread's version of the PEB. While the PEB holds process information, the TEB holds thread-level information. But here's the thing: the TEB contains a pointer to the PEB.

typedef struct _TEB {
PVOID Reserved1[12];
PPEB ProcessEnvironmentBlock; <- Here!
PVOID Reserved2[399];
BYTE Reserved3[1952];
PVOID TlsSlots[64];
BYTE Reserved4[8];
PVOID Reserved5[26];
PVOID ReservedForOle;
PVOID Reserved6[4];
PVOID TlsExpansionSlots;
} TEB, *PTEB;

In technical terms:

- 32-bit systems: FS:0x30 (the PEB pointer)
- 64-bit systems: GS:0x60 (the PEB pointer)

So malware can find the PEB by following the thread's TEB.

Location: User-Space = Vulnerability

Here's the critical detail: the PEB sits in user-space (Ring 3), not kernel-space (Ring 0).

Why? Performance. If every process had to call into the kernel for basic information, Windows would crawl. By keeping the PEB in user-space, processes can read their own information quickly without kernel transitions.

But this design choice has a dark side. Because the PEB is in user-space, every process can read and write to it. Including malicious processes.

The Attack

Step 1: DLL Injection – Shanya (or malware using similar tactics) loads a malicious DLL into a legitimate process – say, notepad.exe. At this point, the DLL is now running inside the same process container. This is similar to "Living off the Land" (LOTL) techniques, but with more persistence and stealth.

Step 2: The Process Lists the Malware – Once the malicious DLL is loaded, the PEB automatically lists it:

- notepad.exe
- system.dll
- kernel32.dll
- malicious.dll ← Detectable

At this stage, EDR systems can see it. But here's where it gets sophisticated.

**Step 3: The Unlink – Since the malware is now running inside the same process container as the PEB, it can edit the PEB directly.

What it does is "unlink" itself from the DLL list (usally three).

Now the list would look like:

- notepad.exe
- system.dll
- kernel32.dll

Without the malicious.dll in it!

The malicious DLL is still in memory, still running, still executing. But from the PEB's perspective? It doesn't exist anymore.

Why This Works: The Fundamental Problem

This is the cat-and-mouse game of modern security.

The core issue is the fundamental nature of the PEB:

- It must be in user-space for performance
- But user-space means it's editable by applications
- Moving it to kernel-space would break Windows architecture

So how can EDR systems defend against this?

Current EDR Approaches (As far as i know)

1. Kernel Audit: Cross-reference user-space PEB against VAD (virtual address descriptor) – even if an DLL is unlinked in the PEB it will be revealed in the VAD
2. API Hooking: Monitor calls to functions that manipulate the PEB
3. Behavioral Analysis: Look for suspicious process creation patterns. But DLL injection into legitimate processes is legitimately hard to distinguish from normal behavior.

EDR-Killer

Here's where Shanya becomes an "EDR killer": It can load its malicious DLL before your EDR is fully initialized.

If Shanya can inject into the system before your EDR protection hooks the critical functions, the EDR system itself might not detect the injection. And if the EDR can't see the injection, it can't see the PEB manipulation that follows.

Packer-as-a-Service: Why This Matters

Shanya isn't just malware – it's part of a broader trend: Packer-as-a-Service (PaaS).

These are platforms that:

- Bundle multiple evasion techniques (DLL injection, PEB manipulation, API hooking)
- Package them as a service for other malware
- Constantly update to evade new detection methods
- Can be deployed at scale against thousands of targets

This leads to malware that's _designed_ from the ground up to be invisible to EDR systems.

Conclusion

While we can't simply "lock" the PEB – as it remains a necessary "open door" for Windows performance, the industry is rapidly moving toward **Kernel-First** detection

As an example is Microsofts `PsSetLoadImageNotifyRoutine` Callback which can notify whenever an DLL or EXE is loaded to memory. Modern EDR solutions leverage this mechanism to detect and monitor these types of attacks.