Contact Sales

Blogs

Blog

Process Parameter Poisoning: Inside a Novel EDR Evasion Technique

In this post, Flashpoint analysts examine Process Parameter Poisoning—a novel EDR evasion technique we validated in Rust—and detail how abusing undocumented process parameters allows attackers to inject code and bypass standard security products.

Modern Endpoint Detection and Response (EDR) platforms have made traditional malware injection techniques significantly harder to execute. In most cases, if a threat actor attempts to write malicious code into a process, an alert will fire. However, that sense of security is being actively challenged as cybercriminals and red teams find new ways to blend malicious payloads into standard operating system routines.

Flashpoint’s Intelligence team built and tested a proof-of-concept for a newly disclosed technique known as Process Parameter Poisoning. By compiling a custom payload and layering evasion mechanics, our analysts demonstrated how easily traditional API hooks can be rendered blind in a laboratory environment—achieving zero alerts across tested EDR/XDR controls.

What is Process Parameter Poisoning?

Process Parameter Poisoning is a novel endpoint detection and response (EDR) evasion technique that combines process parameter spoofing and thread execution hijacking to inject code into foreign processes without triggering standard security detection mechanisms.

Discovered by researchers Max Hirschberger and Ogulcan Ugur, Process Parameter Poisoning is designed to inject code in foreign processes without relying on the conventional memory-manipulation workflows that modern security tooling monitors.

To execute process injection, historically security tools and threat actors alike have focused on a small set of well-known Windows application programming interfaces (APIs). Process Parameter Poisoning shifts away from these heavily watched routines entirely. Instead of calling memory-accessing APIs to allocate and write into a target process, the technique hides the malicious payload directly inside standard process initialization structures during the initial creation of a process. The result is a fundamental shift in defense evasion that effectively blinds traditional, API-hooking EDR agents during the initial stages of code execution.

How Does Process Parameter Poisoning Work?

Process Parameter Poisoning allows attackers to bypass suspicious memory-accessing Windows APIs, such as VirtualAllocEx(), WriteProcessMemory(), and MapViewOfFile2(). Security products heavily monitor these specific APIs due to their high rate of abuse in traditional process injection techniques. However, by avoiding these calls, an attacker effectively bypasses the initial primary triggers used by endpoint agents to flag malicious cross-process memory activity.

When using the Windows application programming interface (API), CreateProcessA/W(), the developer can specify parameters such as the command-line to be executed by the new process, environment variables for the new process, current working directory for the process, window title if it is a console application, create a hidden window, create the process in a suspended state, etc. Many of these parameters are passed into CreateProcessA/W() via the STARTUPINFOA/W structure.

Some entries are undocumented and labeled “reserved” by Microsoft. The discovering researchers found that data stored in STARTUPINFO->lpReserved ends up in the Process Environment Block once the new process is initialized in an entry called “ShellInfo.” Below is an example of placing data into the STARTUPINFOW->lpReserved entry in a test application and the data stored in ShellInfo while debugging the newly created process.

†

Validating Process Parameter Poisoning in Rust

Flashpoint analysts created a proof-of-concept (POC) in Rust to test this technique based on the POC C++ source code provided by the researchers:

1. First the necessary data structures are initialized and the shellcode is passed into the STARTUPINFO->lpReserved field.
2. The target process is created with the infected STARTUPINFO and then a short wait to let the program initialize.
3. NtQueryInformationProcess() is used to acquire PROCESS_BASIC_INFORMATION about the newly created process.
4. The PROCESS_BASIC_INFORMATION structure has an entry called PebBaseAddress that provides the location of the process’s Process Environment Block.
5. NtReadVirtualMemory() is used to read the memory address provided by PebBaseAddress to get the PEB for that process.
6. The PEB has an entry called ProcessParameters that holds the structure RTL_USER_PROCESS_PARAMETERS and is where the ShellInfo entry mentioned earlier is stored.
7. NtReadVirtualMemory() needs to be used again to read the RTL_USER_PROCESS_PARAMETERS structure and get the address of the ShellInfo.Buffer entry.

Flashpoint confirmed that after changing the memory to have executable permissions, the threat actors can perform thread hijacking by using GetThreadContext() to acquire information about the current running thread, change the instruction pointer to point to the ShellInfo.Buffer address, and then SetThreadContext() to apply the changes and execute the shellcode.

Flashpoint analysts further confirm that this technique also works with the WindowTitle entry, CommandLine entry using the same series of steps.

The technique also works with the Environment entry but requires additional steps. Environment blocks require a variable name and the variable data separated by an “=.” Environment blocks can contain multiple variable entries in which each entry is ended with a null terminator. Two null terminators are necessary to denote the end of the environment block. This means the payload needs to be embedded in a longer string with a “{NAME} = {VALUE}” format.

Flashpoint analysts note that four null terminators were appended to the shellcode bytes to denote the end of an environment block in Unicode. The resulting payload buffer is then passed into the lpEnvironment variable of CreateProcessW() along with the CREATE_UNICODE_ENVIRONMENT creation flag.

The rest of the process remains the same as reading the PEB and RTL_USER_PROCESS_PARAMETERS structure. The Environment entry is read, but at the offset of the embedded shellcode within the poisoned environment block string. Because four bytes were added to the beginning of the shellcode to make the Unicode environment block, execution needs to begin after four bytes from the beginning of the buffer to begin executing at the shellcode.

Flashpoint notes that the shellcode requires no NULL bytes, and, if using the PAGE_EXECUTE_READ flag, it cannot overwrite itself. This means automated shellcode generators such as MSFVenom might not work either because they contain NULL bytes or use encoders that perform memory writes during execution. Flashpoint analysts wrote custom shellcode to further test this technique. The shellcode downloads and executes an additional payload. The combination of this technique, custom shellcode, and the use of Rust as the programming language proved successful in minimizing initial static detections by security software.

Flashpoint tested this technique with a commonly-used open source EDR platform. The EDR platform itself failed to produce any alerts from executing the malicious binary. However, the XDR component blocked on the initial creation of a new process and COM interactions by the second stage payload.

Flashpoint analysts then combined this technique with the DLL unhooking technique and applied the non-Microsoft block DLL policy during the creation of the sacrificial process. Analysts observed no blocks from the XDR during execution and observed no alerts on the platform.

Associated MITRE ATT&CK

Tactic	Technique ID	Technique Name
Stealth	T1055	Process Injection
Stealth	T1055.003	Process Injection: Thread Execution Hijacking
Stealth	T1564.010	Hide Artifacts: Process Argument Spoofing

Security teams can leverage several detection strategies to identify Process Parameter Poisoning, though each approach carries distinct limitations:

• Analyzing Parameter Entropy and Argument Spoofing (MITRE ATT&CK T1564.010): Security tools can inspect initialization strings within process structures for unusually high entropy, which often indicates the presence of obfuscated or raw binary shellcode embedded within parameters.
• Monitoring Thread Execution Hijacking (MITRE ATT&CK T1055.003): Analysts can monitor for thread context manipulation; however, because Process Parameter Poisoning does not invoke explicit thread suspension or resumption APIs, specific detection rules that depend on those parameters will fail to trigger.
• Detecting Code Execution in Abnormal Memory Locations (MITRE ATT&CK T1055): Detections can flag execution attempts taking place outside the standard executable section, particularly when code executes directly within Process Environment Block (PEB) parameter buffers.
• Auditing Memory Permission Modifications: Tracking instances where memory region permissions are altered to executable states can reveal payload staging. However, enterprise security controls often tune down or avoid these specific alerts due to high volumes of false positives in normal software operations.

Stay Ahead of Process Parameter Poisoning Using Flashpoint

Process Parameter Poisoning demonstrates another advancement in stealthy process injection and the constantly evolving research into evading security products. By using the previously unknown purpose of the lpReserved field within the STARTUPINFOW structure to house shellcode, this technique bypasses standard security product triggers associated with common memory-allocation APIs. While this proof-of-concept was proven successful in lab testing, the technique has multiple opportunities for detection and will most likely require a combination of additional evasion techniques to achieve a higher success rate.

As threat actors continue to refine technique-stacking and exploit overlooked Windows internals, relying on traditional API hooks is no longer enough to protect your enterprise. Staying ahead of modern evasion mechanics requires proactive intelligence and deep visibility into emerging adversary TTPs.

Request a demo today to see how best-in-class threat intelligence can help security teams detect, prepare for, and neutralize advanced defense evasion techniques before they impact your network.

See Flashpoint in Action

Blogs

Blog

Inside Qilin Ransomware: Custom Rust Loader and Kernel-Level EDR Killer

In this post we analyze Qilin ransomware’s new custom Rust loader, break down the inner workings of its sophisticated kernel-level EDR killer, and explore how organizations can defend against these aggressive defense evasion tactics. Flashpoint customers can access the full intelligence report—complete with deeper technical analysis and all associated IOCs—directly within Flashpoint Ignite.

Qilin ransomware is a highly active and sophisticated ransomware operation that has rapidly modernized its evasion techniques. Historically focused on file encryption, the ransomware-as-a-service (RaaS) group has expanded its operations to include aggressive, kernel-level defense evasion. By deploying a specialized toolkit, Qilin now focuses heavily on blinding and permanently disabling endpoint security products before its main ransomware payload is executed on a victim’s network.

Flashpoint has observed Qilin quietly deploying a previously unreported custom packer, which has been actively observed in wild samples since May 2024, with continuous use detected as recently as last month.

Here’s how Qilin works:

How Qilin Ransomware Uses a Custom Rust Loader for Reflective PE Loading

Flashpoint analysts observed a custom Rust-written loader that performs reflective Portable Executable (PE) loading of the ransomware payload. After deobfuscation, the code execution jumps to the newly unpacked executable within the same process, avoiding noisier process injection techniques. The following is an overview of the decompiled unpacking routine:

The unpacking routine then reads each DWORD from the embedded bytes, allocates it on the heap, and performs multiple mathematical operations to deobfuscate. Flashpoint notes that the calculations and values used were unique to each sample, but the underlying methodology remained the same.

Manually performing the calculations in the sample confirms the presence of the embedded binary, with the first deobfuscated DWORD yielding an ‘MZ’ header in little-endian format.

To better understand Qilin, Flashpoint analysts created an automated unpacker and configuration extraction script that uses CPU emulation to address the issue of unique calculations per sample. This script uses pattern matching to locate the unpacking routine within the binary. It then reads the disassembly, identifying specific points in the code at which emulation should start and stop.

Reading the disassembly directly avoids issues arising from hardcoded offsets, such as when threat actors add or remove code, or when the compiler introduces changes. Additionally, it provides a smaller set of instructions for emulation, avoiding WinAPI calls and other invalid memory errors that often occur when emulating a full binary.

After additional setup, including mapping the sample into the emulator’s memory and creating a fake heap, the unpacking routine runs successfully.

The script then performs configuration extraction from the deobfuscated bytes produced by the CPU emulation, achieving a 100% success rate.

How Qilin’s New EDR Killer Blinds Security Products

An additional update with Qilin is its new endpoint detection and response (EDR) killer, which Flashpoint found to be sold on illicit marketplaces for US $2,000. This is packed via the Shanya packer—which was sold on XSS for US $100 to US $150 back in 2024. The packer is highly sophisticated, and uses several techniques that make it difficult to analyze, such as junk code, application programming interface (API) hashing, IAT hooking, pattern scanning, and VEH code execution flow.

Once unpacked, the EDR killer starts by using dynamic API hashing and PE walking to resolve a number of useful NTAPI functions it will use throughout the process, and stores them in a structure located within the GdiHandleBuffer within the Process Environment Block (PEB).

The structure stored in the PEB itself looks as follows:

The API hashing algorithm is simple: it performs a bitwise OR of each character of the API name with hexadecimal value 0x20 to convert any and all uppercase characters to lowercase, then performing additional simple calculations.

The EDR killer compares the returned locale to a known locale blacklist to avoid attacking any Commonwealth of Independent States (CIS) countries such as Russia and Belarus.

The malware then attempts to give itself the following privileges by dynamically resolving and calling RtlAdjustPrivilege():

• SE_PROF_SINGLE_PROCESS_PRIVILEGE
  • Required to gather profile information for a single process.
  • Used later to create a map of the victim machine’s physical memory space.
• SE_DEBUG_PRIVILEGE
  • Required to debug and adjust the memory of a process owned by another account.
• SE_LOAD_DRIVER_PRIVILEGE
  • Required to load or unload a device driver.

Abusing Vulnerabilities to Map Physical Memory

The EDR killer then writes a vulnerable driver to disk and loads this driver via Service Manager. This driver is the ThrottleStop driver from TechPowerUp LLC’s free and legitimate application of the same name, used to bypass CPU throttling. However, the driver suffers from a vulnerability, allowing the malware to map physical memory to kernel-mode virtual memory to perform direct kernel read and write operations.

Qilin weaponizes this vulnerability by feeding its EDR killer physical memory addresses, as the driver relies on the API to map physical memory to a kernel-mode virtual address. To achieve this, the EDR killer builds a physical memory map using a Windows memory management service that preloads frequently used applications into RAM.

1. First it gathers baseline information about all physical memory blocks. Because memory pages (typically 4KB) are allocated to physical blocks, hundreds of virtual pages can point to a single physical range.
2. It then calls the service to obtain detailed Page Frame Number (PFN) details. The malware stores this complete mapping in a global variable, giving it a reliable, built-in translation table between virtual and physical memory spaces.

Bypassing Driver Signing Checks

To run its own malicious tools, the EDR killer must first bypass Windows’ driver signing enforcement. Normally, Windows uses a built-in verification check to block unsigned or blacklisted drivers from loading. The malware tricks Windows into disabling this gatekeeper using a simple swap:

1. The malware finds a specific kernel function and uses its physical memory map to pinpoint its location.
2. It commands the vulnerable driver to scan this memory area for a specific byte signature. This leads directly to the Code Integrity callback table.
3. Within this table, the malware locates the built-in verification check and “patches” it with a harmless, dummy function.

Blinding Security Products

With driver signing checks completely bypassed, the malware uses its read/write primitives to dismantle system callbacks, it identifies and targets:

• Process notify callbacks
• Thread notify callbacks
• Image load notify callbacks
• Registry callbacks and minifilters

Rather than conducting a blanket unlinking of all system callbacks, the EDR killer checks the address of each callback. If the address falls within a memory range owned by a security product on its hardcoded blacklist, Qilin surgically unlinks it by zeroing out the pointer with null bytes.

Next, the EDR killer drops and loads its own custom driver, which appears to Windows as purpose-built. Once loaded, the Qilin EDR killer gets all relevant running processes. For any processes running that match a hardcoded list, it stores the Process ID in a vector.

For every PID found, the malware sends a message to a driver. At a high level, the driver finds the full path of the target executable, makes it unreadable, unwriteable, and undeletable to any and all users, and then terminates the process.

Interestingly, the Qilin EDR killer performs a Discretionary Access Control List (DACL) modification on the target security product executable. The driver creates a new empty ACL header and sets the flag SE_DACL_PRESENT to TRUE. This is significant because a null DACL and empty DACL are not the same. A null DACL grants everyone access, whereas an empty DACL grants no access. This process makes it so that the security product’s executable can no longer be executed without needing to delete the file like other EDR Killers. Once the driver then terminates the executable, it can’t be restarted.

Once everything is completed, the EDR killer unpatches the Code Integrity Check to avoid triggering PatchGuard and then exits.

Defend Against Qilin Using Flashpoint

The sophisticated kernel-level manipulation highlights a rapidly expanding trend in the broader threat landscape: the proliferation of highly effective malware designed purely to disable enterprise-level security products. Qilin’s integration of these techniques demonstrates how the EDR killer market is maturing in the cybercrime underground, transitioning from a niche capability into a standard prerequisite for high-impact ransomware operations.

As security platforms continuously improve their detection mechanisms, Flashpoint believes the threat landscape surrounding anti-EDR tools will only grow larger and more aggressive, forcing organizations to focus on protecting the kernel and detecting rogue driver deployments. To learn more about Qilin and the latest advancements in ransomware, request a demo.

See Flashpoint in Action