A Linux VM inside QEMU on Windows, no admin rights, no EDR visibility. Pure TCG emulation.

Dark Vortex provides various cybersecurity trainings, products and other services.

Dark Vortex provides various cybersecurity trainings, products and other services.

Technical reference on modern EDR architecture, detection mechanisms, evasion techniques, and reverse-engineering methodology. Covers kernel callback APIs, file-system mini-filters, ETW providers, the four detection-engine model, syscall gates (FreshyCalls, RecycledGate, SysWhispers4, Acheron, Sysplant), sleep obfuscation (Ekko, FOLIAGE, DreamWalkers), call-stack spoofing (SilentMoonwalk, VulcanRaven), ETW-TI hardware-breakpoint bypass, patchless AMSI bypass via VEH, BYOVD against the vulnerable-driver blocklist, and the eight-phase EDR research methodology.

The complete red team guide to Initial Access: Payload Development (DLL Sideloading, Shellcode Loaders, Syscalls), HTML Smuggling, Phishing (QR Code Quishing, Teams Phishing), AitM/MFA Bypass (Evilginx, Device Code Phishing), Password Spraying, Exploiting Public-Facing Applications, Vishing, Physical Access (Rubber Ducky, Bash Bunny), Supply Chain attacks with real-world APT case studies.

A full reverse-engineering teardown of the CrowdStrike Falcon sensor: the six kernel callback sources, the WFP network engine, the file-system minifilter, the cspcm4 broker, the user-mode service (DNS / AMSI / browser / Identity Protection), and the cloud-loaded detection engine — plus every structural blind spot. How Falcon sees you, and where the seams are.

Red Teamer & Low-Level Developer. Deep dives into Windows Internals, Kernel Exploitation, Driver Analysis, and Red Team techniques.

Red Teamer & Low-Level Developer. Deep dives into Windows Internals, Kernel Exploitation, Driver Analysis, and Red Team techniques.

HookChain is a novel technique aimed at bypassing Endpoint Detection and Response (EDR) solutions by leveraging low-level Windows APIs and manipulating how system calls interact with user-mode hooks. To better understand how HookChain operates, let’s dive deeper into the technical aspects with real-world examples.

This is Part II. If you haven’t read Part I — HookChain, go do that first. Part I showed how to defeat userland NTDLL hooks with IAT manipulation, dynamic SSN resolution, and indirect syscalls. That was the state of the art in 2024.

Introduction This is the second post of a series which regards development of malicious software. In this series we will explore and try to implement multiple techniques used by malicious applications to execute code, hide from defenses and persist. Previously, we’ve created basic Metasploit shellcode launcher in C++ and explored basic techniques which helped to lower detection rate of the compiled executable - payload encoding/encryption, binary signing with custom code-signing certificate and switching to x64 architecture. Now let’s dive deep into dynamic analysis and how to defend against it.

Introduction This is the third post of a series which regards development of malicious software. In this series we will explore and try to implement multiple techniques used by malicious applications to execute code, hide from defenses and persist. In the previous part of the series we discussed methods for detecting sandboxes, virtual machines and automated analysis. This time let’s see how the application can detect that it’s being debugged or inspected by an analyst.

Introduction This is the fifth post of a series which regards the development of malicious software. In this series we will explore and try to implement multiple techniques used by malicious applications to execute code, hide from defenses and persist. In the previous posts we explored anti-VM, anti-sandbox, anti-debugging and anti-static-analysis methods. In this post we’ll explore some cool tricks to further obscure our code like parent PID spoofing, process protection, environmental keying and bruteforce decryption of malware data and configuration. So this will be a mix of some cool features I’ve been implementing recently.

Introduction This is the eigth post of a series which regards the development of malicious software. In this series we will explore and try to implement multiple techniques used by malicious applications to execute code, hide from defenses and persist. This time we will implement a COFF object file loader, which is similar to BOF (beacon object file) feature of Cobalt Strike. This has been also tackled by TrustedSec.

When I was active in the red teaming space, one of my stated goals was to act on problems with solutions that would have utility 5-10 years from the time of their release. This long-term thinking was my super-power. One of the lasting fruits of my approach is Beacon Object Files. Five years ago, today…

A comprehensive deep dive into bypassing EDRs by manually mapping and reflectively injecting DLLs using a custom Windows PE loader.

Early Bird APC injection, queuing shellcode to a suspended thread.

After launching the pilot earlier this year, AV-Comparatives has now completed the 2025 round of the EDR Detection Validation Test. This independent

Delve into windows memory internals! here is the 3rd post of Malware Development, Analysis and DFIR Series.

On Windows, each process has its own virtual address space. The CR3 value loaded into a logical processor is located inside of the KPROCESS structure...

In this article you can learn how malware detection is working in a traditional approach used by Antivirus Software. Next I will guide you into the functionality of modern EDR software solutions and perform a deep dive into the way how EDR hooks are working before we start to find ways how to attack an EDR solution based on a threat model. , blog-description

Modern Endpoint Detection & Response (EDR) products rely heavily on user‑mode API hooking to monitor process behavior. As detection logic becomes more aggressive, adversaries and red teamers continue to explore increasingly low‑level strategies to bypass instrumentation—most prominently: direct and indirect syscalls. , blog-description

When an Endpoint Detection and Response (EDR) agent initializes on a Windows host, one of its primary mechanisms for gaining deep user-mode visibility is the injection of a proprietary DLL into newly spawned processes. Once loaded, this DLL alters the execution flow of critical subsystems – most notably ntdll.dll – by overwriting the prologues of Native API functions with unconditional jumps (JMP) redirecting into the EDR’s analysis logic. , blog-description

,

Interpreters are signed, trusted, and used everywhere, making them the perfect hiding spot. This post turns Bun into a fully in-memory C2: a fetch-eval one-liner for initial access, modular TypeScript post-exploitation, a BOF/COFF loader ported to TypeScript, and even a SOCKS proxy compiled to WASM.

In this article, we will explore a method for in-process shellcode execution evasion. This method is specifically designed to avoid the detection of NtAllocateVirtualMemory calls from unsigned DLLs.

True cyber security combines advanced technology and best practice. Get tips and read articles on how to take your online security even further.

True cyber security combines advanced technology and best practice. Get tips and read articles on how to take your online security even further.

True cyber security combines advanced technology and best practice. Get tips and read articles on how to take your online security even further.

What happens when you skip memory allocation, skip writing, and weaponize thread context alone? This post explores a new class of process injection that lives entirely in the execution layer — no alloc, no write, just a well-placed hijack.

Authors: Boudewijn Meijer && Rick Veldhoven Introduction As defensive security products improve, attackers must refine their craft. Gone are the days of executing malicious binaries from disk, especially ones well known to antivirus and Endpoint Detection and Reponse (EDR) vendors. Now, attackers focus on in-memory payload execution for both native and managed applications to evade…

How one Commit Broke Obfuscation: A blog post exploring the role of compilers and optimizations in the field of obfuscation and de-obfuscation.

Evade Microsoft Defender by embedding Lua into Rust: Learn advanced techniques for game modding, language exploration, and stealthy scripting approaches.

Advanced Evasion in Rust‑Based ArtifactKit: Techniques, CobaltStrike Integration, and Defensive Analysis

Experimenting with Protected Processes and Threat-Intelligence

Patching PE files is easy. Injecting new code that uses functions from external modules, however, is more complicated. In this post, we are implementing a method for rebuilding import directories, such that we can inject any type of code in an arbitrary PE file.

One of the many areas of this field that I really enjoy is the "cat and mouse" game played between RedTeam and BlueTeam, each forcing the other to up their game. Often we see some awesome tools being released to help defenders detect malware or shellcode execution, and knowing just how these defensive capabilities function is important when performing a successful pentest or RedTeam engagement. Recently I came across the awesome post "Defenders Think in Graphs Too!", which can be found over on

Introduction Process Injection is a popular technique used by Red Teams and threat actors for defense evasion, privilege escalation, and other interesting use cases. At the time of this publishing, MITRE ATT&CK includes 12 (remote) process injection sub-techniques. Of course, there are numerous other examples as well as various and sundry derivatives. Recently, I was…

Brute Ratel v1.1 codename Stoffel’s Escape is now available for download. This release brings several new feature additions and improvements to the Badger, Ratel Server and Commander, including a complete re-write of the badger’s core to avoid some subtle detection techniques following the Palo Alto blog. A quick summary of the changes can be found in the release notes. The release name (Stoffel’s Escape) gives subtle hints foreshadowing the nature of this release. This release could not have been better without the support from the blue team community. As BRc4 initially started as a personal project two years back, there were still some remnants of IOCs that needed to be changed. Palo Alto’s reversing blog came in as a surprise, but it only helped to rebuild the payload and optimize it in a certain way to avoid as many IOCs as possible. This release was focused to overcome all the IOCs listed in public or private blogs, conferences and github detections, till date, about Badger and change them to avoid attribution and detection.

Brute Ratel v1.2 codename Scandinavian Defense is now available for download. The main highlight of this release is memory evasion and support for bringing in your own injection techniques via COFF. This release brings major improvements to the badger’s core, both staged and stageless thereby avoiding every EDR trap in memory. This release was tested against 17 different EDRs and Antiviruses prior to the release to detect and bypass all possible traps into memory. There are several major changes made to the sleep masking and dot net evasion techniques following the detection blog from MdSec on suspicious stack threads and dotnet execution detections. A quick summary of the changes can be found in the release notes. The below image shows some of the top tier EDRs which were tested against these techniques and evaded successfully in their highest prevention mode.

Brute Ratel v1.3 codename Resurgence is now available for download. This release brings in various changes to evasion techniques, improvements to Badger, user experience (QOL) and several features requested by the BRc4 community. Since this is a major release, I’ve divided the blog into various segments which can be directly accessed with the links below. A quick summary of the changes can be found in the release notes.

Brute Ratel v1.5 codename Nightmare is now available for download. This release brings in new evasion techniques and user experience updates (QOL) requested by the BRc4 community. A quick summary of the changes can be found in the release notes. This release also brings several changes to the licensing server which now provides support for backward compatibility. More on this at the end of the blog.

Ghostly Reflective PE Loader — how to make an existing remote process inject a PE in itself I was studying Reflective DLL injection, a technique where a loader DLL is injected into a remote …

Useful Libraries for Malware Development, A list of some easy-to-use libraries and how to use them for malware development.

Shellcode, loaders, and the iterative grind of making your tools actually run. Two problems, two approaches., Shellcode, loaders, and the iterative grind of making your tools actually run. Two problems, two approaches.

This blog introduces a PoC technique for spoofing call stacks using timers.

Cobalt Strike 4.10 is live, with the new BeaconGate, post-ex kit, host rotation updates, a new jobs browser and more.

Cobalt Strike 4.12 introduces\xa0a refreshed GUI, a REST API, User Defined Command and Control (UDC2), new process injection options, and more.

Walk through an example of adding a DLL proxy to beacon.dll for use in a DLL Proxy attack, which can be leveraged in a red team engagement to help measure defenses.

Learn about in-memory evasion in this four part mini-course. This course is for red teams that want to update their tradecraft in this area.

This blog introduces the mutator kit, which uses an LLVM obfuscator to break in-memory YARA scanning of the sleep mask.

This blog post accompanies a new addition to the Arsenal Kit - UDRL-VS. The intention of this kit is to lower the barrier to entry for developing and debugging custom reflective loaders.

The second installment in a series revisiting the UDRL. In this post, we build upon the original UDRL-VS loader and apply custom obfuscation and masking.

The sleep mask kit was first introduced in Cobalt Strike 4.4 to allow\xa0users to\xa0modify\xa0how the sleep mask function looks in memory\xa0in order to\xa0defeat static signatures\xa0that\xa0identified\xa0Beacon.\xa0\xa0This quickly took off by the community and its limits were pushed.\xa0\xa0Updates were made in 4.5 to help address some of these limits.

﷽, ﷽

How to implement Early Cascade Injection in Rust, a stealthy Windows process injection technique that hijacks shim engine callbacks in ntdll to execute shellcode during early process initialization, before many EDR hooks activate.

The article presents T(ROP)H, a process injection technique that hijacks threads and uses a ROP chain to load a DLL without allocating executable memory, reducing common detection indicators used by EDR systems.

COMouflage is a stealthy Windows injection technique that abuses COM DLL Surrogates to execute malicious DLLs inside dllhost.exe, making svchost.exe appear as the parent process and hiding the attacker’s process from detection.

The article analyzes advanced techniques used to bypass EDR/XDR systems, showing how attackers combine evasion methods—such as indirect syscalls, ETW tampering, API unhooking, and in-memory execution—to evade detection and extend stealth during attacks.

PoisonX is a Bring Your Own Vulnerable Driver (BYOVD) research tool that leverages a signed Microsoft kernel driver to terminate any Windows process — including PP (Protected Processes) and PPL (Protected Process Light) processes such as EDR/AV services.

The article analyzes a Microsoft-signed vulnerable driver used in a BYOVD attack to kill security processes. By sending crafted IOCTL requests with a target PID, attackers can terminate EDR services such as CrowdStrike Falcon.

klezVirus introduces frame swapping — a technique that hides Windows callback frames from EDR call-stack inspectors while preserving return value recovery. Building on thread-pool execution models and tail-call optimisation, the post develops a full callback-chain primitive that produces highly variable synthetic call stacks in n! orderings. Proof-of-concept and detection guidance included.

This article discusses weaponizing NtCreateUserProcess so that it can be used on defended environments in a way that is reliable and useful.

This article explores a research project seeking to avoid spawning a conhost.exe with a commercial C2 by tricking Windows into thinking it had a console.

TL;DR

A sophisticated technique that allows attackers to execute malicious code directly in memory is gaining traction, posing a significant challenge to modern Endpoint Detection and Response (EDR) solutions.

Demystify Hollow Process injection & discover how attackers manipulate trusted programs. Hollow process injection suspends a legitimate process, overwrites its existing code section with malicious code, & then resumes the process.

Depths of Windows APC - Aspects of internals of the Asynchronous Procedure Calls from the kernel mode.

Named pipes are a mechanism for inter-process communication (IPC) in Windows operating systems. detect suspicious and malicious named pipe with splunk and these threat hunting searches

HellsGate with no Gate Part 2

Using Ekko to sort of bypass Hunt Sleeping Beacons

Who up stompin they modules

Signature-based detection — especially in-memory scanning — can be a valuable threat detection strategy. In this blog, learn how to detect Cobalt Strike regardless of configuration or stealth features...

We explore the immense value that call stacks bring to malware detection and why Elastic considers them to be vital Windows endpoint telemetry despite the architectural limitations.

With Elastic Security 8.11, we added further kernel telemetry call stack-based detections to increase efficacy against in-memory threats.

This article introduces a previously-unnamed class of Windows vulnerability that demonstrates the dangers of assumption and describes some unintended security consequences.

Threat Hunters are charged with the difficult task of sifting through vast sources of diverse data to pinpoint adversarial activity at any stage in the attack.

Elastic Security Labs detected the recent emergence of infostealers using an illicitly acquired version of the commercial evasion framework, SHELLTER, to deploy post-exploitation payloads.

The Elastic Container Project provides a single shell script that will allow you to stand up and manage an entire Elastic Stack using Docker. This open source project enables rapid deployment for testing use cases.

We aim to out-innovate adversaries and maintain protections against the cutting edge of attacker tradecraft. With Elastic Security 8.8, we added new kernel call stack based detections which provide us with improved efficacy against in-memory threats.

Disengaging Loader Lock to do anything directly from DLLMain...

A modern investigation of the Windows loader architecture and loader lock

Today’s post is a full pipeline walkthrough from a MessageBoxA call all the way to a kernel rootkit doing DKOM process hiding and callback abuse. Dynamic function loading, PEB walking, IAT hooking, process hollowing, DLL injection, shellcode encryption, APC injection all of it, with code.

Hello world!It’s July and this is another blog post on malware analysis. I came up with the idea to write this blog because I feel that beginners in the malw..., The only way to learn is to always have a newbie mindset

Learn about APC queue injection for EDR evasion using Rust, including practical code examples and detailed explanations.

Hells Hollow, a new SSDT-style hooking technique using Windows\u202f11 Alt Syscalls to intercept the KTRAP_FRAME, bypass ETW, and evade PatchGuard.

Learn how to remotely inject DLLs into another process using Rust and how to use function pointers, in this rust malware development series for ethical hackers, penetration testers, and red teamers.

Learn the process of creating a dynamic link library (DLL) in Rust with this guide. Learn how to leverage the Windows API for malware development in Rust, enhancing your coding skills and cybersecurity knowledge.

Learn how to implement the Hells Gate technique in offensive Rust to evade EDR detection using direct syscalls. Step-by-step guide with code examples.

An in-depth technical walkthrough of Vectored Exception Handling Squared (VEH²) implemented in Rust. Learn how hardware breakpoints and VEH can be combined to intercept execution without patching code, inspired by CrowdStrike research.

Learn DLL Injection in Rust and how to use the Windows API. We will learn how to use the Windows Rust Crate and Win32 API for Rust Red Team and Ethical Hacking operations using LoadLibraryA.

What happens when you run an executable on your Windows machine? This blog provides a brief overview and the flow for creating a Windows Process, the APIs and structures involved, and the Process Internals.

It’s high time we get another blog post going, and what better time than now to talk about PE loaders! Specifically, an In-Memory PE Loader. 😸 In short, we’re going to implement a PE (Portable Executable) loader that downloads a PE file (in this case, putty.exe) from one of my Github repos. We will then load it directly into a section of memory within the calling process and execute putty without ever writing it to disk! Essentially, we are using what’s called Dynamic Execution: The code is able to load and execute any valid 64-bit PE file (e.g., EXE or DLL) from a remote source, in our case, a Github file URL where I simply uploaded putty.exe to one of my github repos., It’s high time we get another blog post going, and what better time than now to talk about PE loaders! Specifically, an In-Memory PE Loader. 😸 In short, we’re going to implement a PE (Portable Executable) loader that downloads a PE file (in this case, putty.exe) from one of my Github repos. We will then load it directly into a section of memory within the calling process and execute putty without ever writing it to disk! Essentially, we are using what’s called Dynamic Execution: The code is able to load and execute any valid 64-bit PE file (e.g., EXE or DLL) from a remote source, in our case, a Github file URL where I simply uploaded putty.exe to one of my github repos.

Hello again everyone! Hope the start to the new year is treating you well. I am excited to share a new blog post with you! Furthermore, I’d consider the content shared in today’s post to be the most time I’ve spent in researching a particular offensive security topic/technique 😹 I’d say I spent well over a month looking into this exciting topic and I wanted to make sure I had all my research completed before I jumped in to making a post. Without further ado, I give you my take on what I’d like to call: Living off the Process! This is a technique that does as the name implies: We use what is already available to us in the remote process of our choosing to accomplish a given goal. In this case, the goal will be to write shellcode indirectly into the remote process with as low of a footprint as possible. When I say indirectly, I mean we won’t be using WriteProcessMemory to write the shellcode. That API does play a small role, but ultimately we will be indirectly writing our shellcode in 8 byte chunks using ROP gadgets and assembly stubs all made available in the remote process. We will also avoid the creation of RWX regions of memory. Here’s a quick overview on how it all works. We will be looking for:, Hello again everyone! Hope the start to the new year is treating you well. I am excited to share a new blog post with you! Furthermore, I’d consider the content shared in today’s post to be the most time I’ve spent in researching a particular offensive security topic/technique 😹 I’d say I spent well over a month looking into this exciting topic and I wanted to make sure I had all my research completed before I jumped in to making a post. Without further ado, I give you my take on what I’d like to call: Living off the Process! This is a technique that does as the name implies: We use what is already available to us in the remote process of our choosing to accomplish a given goal. In this case, the goal will be to write shellcode indirectly into the remote process with as low of a footprint as possible. When I say indirectly, I mean we won’t be using WriteProcessMemory to write the shellcode. That API does play a small role, but ultimately we will be indirectly writing our shellcode in 8 byte chunks using ROP gadgets and assembly stubs all made available in the remote process. We will also avoid the creation of RWX regions of memory. Here’s a quick overview on how it all works. We will be looking for:

offensive security research, offensive security research

offensive security research, offensive security research

offensive security research, offensive security research

The dragon in the dark. A red team post exploitation framework for testing security controls during red team assessments. - GitHub - 0xflux/Wyrm: The dragon in the dark. A red team post exploitation framework for testing security controls during red team assessments.

Stack spoofing Detection for CET processes by comparing shadow and user stacks. - 0xjbb/cet-spoofing-detection

Polymorphic PE rewriter for Windows x64 , rewrites binaries into semantically identical but byte-different variants - 0xMohammedHassan/morphkatz

Shellcode Loader for Master Thesis. Contribute to 0xRoam/LoadReload development by creating an account on GitHub.

Cicada is a position-independent Windows shellcode stager featuring sleep obfuscation and remote HTTPS staging - 0xROOTPLS/Cicada

An Advanced, Evasive, Persistent, Shellcode Loader and Executor for Windows - 0xROOTPLS/Doppel

Contribute to 0xROOTPLS/Fritter development by creating an account on GitHub.

A PEB walker that resolves function addresses via runtime checksum comparison, avoiding static imports. - 0xROOTPLS/PEBwalker

WaveGate is a Tauri/Rust based RAT written for fun =D - 0xROOTPLS/WaveGate

A reflective DLL development template for the Rust programming language - 0xTriboulet/rdll-rs

T-1 is a shellcode loader that leverages ML techniques to detect VM environments - 0xTriboulet/T-1

This program is designed to demonstrate various process injection techniques - 3xpl01tc0d3r/ProcessInjection

GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.

GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.

Execute payloads from .text section alignment padding of loaded system DLLs - AABUGS/GapMap

Alternative Shellcode Execution Via Callbacks. Contribute to aahmad097/AlternativeShellcodeExec development by creating an account on GitHub.

Automated script for obfuscating, rebranding and renaming the Havoc C2 Framework to evade AV/EDR and C2 hunters. - Acucarinho/havoc-obfuscator

Brovan is a user-mode x86_64 binary emulator for your malware analysis & reverse engineering. - AdvDebug/Brovan

Mirage is a PoC memory evasion technique that relies on a vulnerable VBS enclave to hide shellcode within VTL1. - akamai/Mirage

Indirect Syscall with TartarusGate Approach in Go. Contribute to almounah/superdeye development by creating an account on GitHub.

Remote DLL Injection with Timer-based Shellcode Execution - andreisss/Remote-DLL-Injection-with-Timer-based-Shellcode-Execution

GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.

Contribute to ASP4RUX/bypassEDR-AV development by creating an account on GitHub.

Public malware techniques used in the wild: Virtual Machine, Emulation, Debuggers, Sandbox detection. - GitHub - ayoubfaouzi/al-khaser: Public malware techniques used in the wild: Virtual Machine, Emulation, Debuggers, Sandbox detection.

LoadLibrary for offensive operations. Contribute to bats3c/DarkLoadLibrary development by creating an account on GitHub.

Titan: A crappy Reflective Loader written in C and assembly for Cobalt Strike. Redirects DNS Beacon over DoH - benheise/TitanLdr

💣 Boxed Windows 11 malware detonation lab - Vagrant + Hyper-V powered, with Detonator, Fibratus (ETW), Rustinel (Sigma/YARA/IOC), LitterBox and a unified Web UI for automated sample analysis - BenjiTrapp/transportable-detonation-chamber

Load various payload (DLL from memory, Exe, etc...) in a way to evade static analysis of Antivirus. It can fetch data from various methods and perform multiple data operation to deobfuscate or decrypt payloads and new configuration. - Brother-x86/malleable-rust-loader

SHAREM is a shellcode analysis framework, capable of emulating more than 20,000 WinAPIs and virutally all Windows syscalls. It also contains its own custom disassembler, with many innovative features, such as being able to show the deobfuscated disassembly of an encoded shellcode, or integrating emulation data to enhance the disassembly. - Bw3ll/sharem

Contribute to casp3r0x0/CallWindowProcW-ShellcodeLoader development by creating an account on GitHub.

A shellcode loader generator with support for multiple injection techniques, built for red team engagements. - Chaelsoo/Hollow

Nim-based encryption tool for obfuscating shellcode and payloads for evading Windows Defender. - Chaelsoo/nimcrypt

Contribute to CheckPointSW/VectoredOverloading development by creating an account on GitHub.

Contribute to CheckPointSW/VectoredOverloading development by creating an account on GitHub.

CopyReadProcessMemory expoits the miss-configuration/vulnerability present on the API Windows method ReadProcessMemory. - chmod760/CopyReadProcessMemory

ApexLdr is a DLL Payload Loader written in C. Contribute to Cipher7/ApexLdr development by creating an account on GitHub.

A Beacon Object File (BOF) template for Visual Studio - Cobalt-Strike/bof-vs

A PoC implementation for dynamically masking call stacks with timers. - Cobalt-Strike/CallStackMasker

open source implementation of the UDC2 spec used in Cobalt Strike - CodeXTF2/OpenUDC2

Evasive shellcode loader. Contribute to cpu0x00/Ghost development by creating an account on GitHub.

early cascade injection PoC based on Outflanks blog post - Cracked5pider/earlycascade-injection

Sleep Obfuscation. Contribute to Cracked5pider/Ekko development by creating an account on GitHub.

Shellcode Tester Pro is a graphical interface tool for analysis, simulated execution, and reverse engineering of malicious shellcodes. - CyberSecurityUP/shellcode-tester-pro

Windows C/C++ development environment on Linux. Contribute to dadevel/xwin-starterpack development by creating an account on GitHub.

Crystal Palace PICO loader for Sliver C2 dual-layer AMSI bypass, ETW silencing, AES-256-CBC encrypted payloads, 6 delivery variants - daniomass/SliverMirage

A POC for the new injection technique, abusing windows fork API to evade EDRs. https://www.blackhat.com/eu-22/briefings/schedule/index.html#dirty-vanity-a-new-approach-to-code-injection--edr-bypass-28417 - deepinstinct/Dirty-Vanity

Obex – Blocking unwanted DLLs in user mode. Contribute to dis0rder0x00/obex development by creating an account on GitHub.

Astral-PE is a low-level mutator (Headers/EP obfuscator) for native Windows PE files (x32/x64) - DosX-dev/Astral-PE

Reflective PE packer. Contribute to EgeBalci/amber development by creating an account on GitHub.

Assembly block for finding and calling the windows API functions inside import address table(IAT) of the running PE file. - EgeBalci/IAT_API

For when DLLMain is the only way. Contribute to ElliotKillick/LdrLockLiberator development by creating an account on GitHub.

Operating System Design Review: A systematic analysis of modern systems architecture - ElliotKillick/operating-system-design-review

Agent for AdaptixC2 with focus in evasion, capability and malleable. - entropy-z/Kharon

A compiled language for Windows position-independent x86-64 shellcode and Beacon Object Files. - entropykit/entropia

Detection of indirect syscall techniques using hardware breakpoints and vectored exception handling. - EvilBytecode/Detecting-Indirect-Syscalls

Obfuscating function calls using Vectored Exception Handlers by redirecting execution through exception-based control flow. Uses byte swapping without memory or assembly allocation. - EvilBytecode/Ebyte-Syscalls

Hides in your attic... I mean process. Contribute to Excalibra/AnneFrankInjector development by creating an account on GitHub.

Library to load a DLL from memory. Contribute to fancycode/MemoryModule development by creating an account on GitHub.

Important notes and topics on my journey towards mastering Windows Internals - Windows-Internals/Processes and Jobs/Processes/Creation Of Process.md at main · Faran-17/Windows-Internals

Important notes and topics on my journey towards mastering Windows Internals - Windows-Internals/Processes and Jobs/Processes/Overview of process creation.md at main · Faran-17/Windows-Internals

Playing around with Thread Context Hijacking. Building more evasive primitives to use as alternative for existing process injection techniques - Friends-Security/RedirectThread

Template-based generation of shellcode loaders. Contribute to gatariee/ldrgen development by creating an account on GitHub.

Automated DLL Sideloading Tool With EDR Evasion Capabilities - georgesotiriadis/Chimera

DynLoader A modular Windows loader focused on EDR evasion Built with indirect syscall (Tartarus Gate / Hell’s Gate), Manual PE parsing & Section mapping, API hashing & Dynamic resolution, fileless HTTP delivery (AES encrypted option) - h4vox/Dynloader

Patch AMSI and ETW in remote process via direct syscall - Hagrid29/RemotePatcher

HookChain: A new perspective for Bypassing EDR Solutions - helviojunior/hookchain

Simple Shellcode loader in a remote process using Apc injection or DLL injection using apc to call LoadLibrary. - Hue-Jhan/Apc-Process-Injection-and-DLL-injection

Thread Hijacking malware using direct/indirect syscalls, ntdll and low level utilities, undetected by Windows Defender and BitDefender - Hue-Jhan/Syscalls-Thread-Hijacking

Contribute to HulkOperator/CallStackSpoofer development by creating an account on GitHub.

The Definitive Guide To Process Cloning on Windows - huntandhackett/process-cloning

A Dockerized build pipeline for custom Windows x64 shellcode - HuskyHacks/windows-x64-shellcode-pipeline

PE packer/crypter for Windows. compresses and encrypts executables with a custom virtual machine into a self extracting stub. - iamsopotatoe-coder/TinyLoad

PoC module to demonstrate automated lateral movement with the Havoc C2 framework. - icyguider/LatLoader

PoC for a sleep obfuscation technique leveraging waitable timers to evade memory scanners. - Idov31/Cronos

NovaHypervisor is a defensive x64 Intel host based hypervisor. The goal of this project is to protect against kernel based attacks (either via Bring Your Own Vulnerable Driver (BYOVD) or other means) by safeguarding defense products (AntiVirus / Endpoint Protection) and kernel memory structures and preventing unauthorized access to kernel memory. - Idov31/NovaHypervisor

IronPE is a Windows PE manual loader written in Rust for both x86 and x64 PE files. - iss4cf0ng/IronPE

Two new offensive techniques using Windows Fibers: PoisonFiber (The first remote enumeration & Fiber injection capability POC tool) PhantomThread (An evolved callstack-masking implementation) - JanielDary/ImmoralFiber

From C, Rust or Zig to binary shellcode compiler based on Mingw gcc. It allows using Win32 APIs and standard libraries without any changes to the source code. - JJK96/PIClin

Contribute to JkMaFlLi/xorInject development by creating an account on GitHub.

A memory scanning evasion technique. Contribute to JLospinoso/gargoyle development by creating an account on GitHub.

Sleep Obfuscation in Rust. Contribute to joaoviictorti/hypnus development by creating an account on GitHub.

AV/EDR evasion via direct and indirect system calls Windows NT 3.1 through Windows 11 24H2 · x64 · x86 · WoW64 · ARM64 - JoasASantos/SysWhispers4

Translate virtual addresses to physical addresses from usermode. - jonomango/superfetch

In-memory Encrypted Shellcode Execution Suite. Contribute to jtalamini/shadowstep development by creating an account on GitHub.

A sleepmask based on Ekko that preserves unwind data at sleep time. - GitHub - kapla0011/InsomniacUnwinding: A sleepmask based on Ekko that preserves unwind data at sleep time.

A Cobalt Strike RL built with Crystal Palace — module overloading, NtContinue entry transfer, call stack spoofing, sleep masking, and static signature removal. - kapla0011/KaplaStrike

Version 2 - A modern 64-bit position independent meterpreter and Sliver compatible reverse_TCP Staging Shellcode based on Cracked5piders Stardust - Karkas66/CelestialSpark

an Improoved Version of 0xNinjaCyclone´s EarlyCascade Code - Karkas66/EarlyCascadeImprooved

Ported from [LACUNA Chain](https://github.com/MazX0p/LACUNA-Chain) by Mohamed Alzhrani (0xmaz). lacuna-rs is a reusable Rust crate that provides the same primitives as the original C TTP, structured so it can be dropped into any Rust project — - GitHub - Karkas66/lacuna-rs: Ported from [LACUNA Chain](https://github.com/MazX0p/LACUNA-Chain) by Mohamed Alzhrani (0xmaz). lacuna-rs is a reusable Rust crate that provides the same primitives as the original C TTP, structured so it can be dropped into any Rust project —

A POC for developing BOFs for Sliver, Havoc, Cobalt Strike or most COFFLoaders in Rust. - KickedDroid/bof_oxide

A proof of concept demonstrating the DLL-load proxying using undocumented Syscalls. - kleiton0x00/Proxy-DLL-Loads

Bring your own Unwind Data Framework. Contribute to klezVirus/BYOUD development by creating an account on GitHub.

Moonwalk++: Simple POC Combining StackMoonwalking and Memory Encryption - klezVirus/Moonwalk--

PoC Implementation of a fully dynamic call stack spoofer - klezVirus/SilentMoonwalk

Authenticode signature manipulation toolkit for Red Team operations and security research. Covers signature stealing, metadata cloning, SIP hijacking across 19 file types, WinVerifyTrust FinalPolicy bypass, PKCS#7 payload embedding, SIP execution surface implants, Smart App Control Bypass, and analyst-triggered persistence via OID handlers. - KriyosArcane/TrustMeBro

Proxll is a tool designed to simplify the generation of proxy DLLs while addressing common conflicts related to windows.h - Krypteria/Proxll

DLL proxying for lazy people. Contribute to Kudaes/ADPT development by creating an account on GitHub.

ROP-based sleep obfuscation to evade memory scanners - Kudaes/Shelter

Apply a divide and conquer approach to bypass EDRs - Kudaes/Split

Call stack spoofing for Rust. Contribute to Kudaes/Unwinder development by creating an account on GitHub.

Cobalt Strike UDRL for memory scanner evasion. Contribute to kyleavery/AceLdr development by creating an account on GitHub.

A memory-based evasion technique which makes shellcode invisible from process start to end. - lem0nSec/ShellGhost

Contribute to Maldev-Academy/Christmas development by creating an account on GitHub.

Custom Adaptix-compatible C2 agent - PIC beacon + Stardust UDRL + Go extender plugins - MaorSabag/NaX

Signtool modification for expired certificates. Contribute to mathisvickie/sign-expired development by creating an account on GitHub.

Advanced In-Memory PowerShell Process Injection Framework - MazX0p/PhantomInjector

Rusty DoublePulsar - Cobalt Strike User-Defined Reflective Loader (UDRL) in Rust (Codename: DoublePulsar) - memN0ps/doublepulsar-rs

Rusty Injection - Shellcode Reflective DLL Injection (sRDI) in Rust (Codename: Venom) - memN0ps/venom-rs

LSASS Credential Dumper that utilizes the Windows API, in-memory RC4 encryption and Base64 encoding, and HTTPS exfiltration. - Meowmycks/catdumper

Use NtProtectVirtualMemory in Ekko timers without needing to use stack pivoting or other RSP shifting tricks - Meowmycks/EkkoNtProtect

Simple ETW unhook PoC. Overwrites NtTraceEvent opcode to disable ETW at Nt-function level. - Meowmycks/etwunhook

Robust Cobalt Strike shellcode loader with multiple advanced evasion features - Meowmycks/koneko

A sophisticated, covert Windows-based credential dumper using C++ and MASM x64. - Meowmycks/LetMeowIn

Cross platform (Linux / Windows) shellcode packer for CTFs and pentest / red team exams aiming for AV evasion ! - mochabyte0x/CTFPacker

Reflective x64 Loader written in C/ASM. Contribute to mochabyte0x/MochiLdr development by creating an account on GitHub.

Minimal in-memory PE loader. Contribute to mochabyte0x/MochiMapper development by creating an account on GitHub.

Sleep Obfuscation via CreateThreadpoolTimer. Contribute to mochabyte0x/Morpheus development by creating an account on GitHub.

A proof of concept AMSI & ETW bypass using trampolines for hooking and modifying execution flow - GitHub - mochabyte0x/TrampoLatte: A proof of concept AMSI & ETW bypass using trampolines for hooking and modifying execution flow

A header-only, freestanding C++20 template for IR-bytecode VM loaders - mochabyte0x/vmkit

Adaptive DLL hijacking / dynamic export forwarding - monoxgas/Koppeling

Shellcode implementation of Reflective DLL Injection. Convert DLLs to position independent shellcode - monoxgas/sRDI

Evasive shellcode loader for Red Teaming. Contribute to monsieurPale/KhimairaLdr development by creating an account on GitHub.

A desktop operator console for Sliver C2, built with Wails. Provides a native, lightweight GUI interface for Sliver by directly interfacing with its gRPC service no proxies or protocol reimplementations required. - Mr-In4inci3le/sliver-gui

A Proof of Concept demonstrating CET-compliant callstack spoofing in Rust. It leverages Windows Thread Pool and Enum Callback trampolining (e.g., EnumSystemLocalesEx) to forge a pristine, hardware-aligned call stack for indirect syscall evasion. - MrTiz/CET-Enum-CallStack-Spoofer

Hades is a fully-featured cross-platform Chrome Extension agent. Hades is designed for Mythic 3.0 and newer. - MythicAgents/Hades

Generic PE loader for fast prototyping evasion techniques - naksyn/DojoLoader

GregsBestFriend process injection code created from the White Knight Labs Offensive Development course - naksyn/GregsBestFriend

Stealthier variation of Module Stomping and Module Overloading injection techniques that reduces memory IoCs. Implemented in Python ctypes - naksyn/ModuleShifting

pure-python implementation of MemoryModule technique to load dll and unmanaged exe entirely from memory - naksyn/PythonMemoryModule

Generate a proxy dll for arbitrary dll. Contribute to namazso/dll-proxy-generator development by creating an account on GitHub.

🥱😴🛌💤. Contribute to nbaertsch/COMegon development by creating an account on GitHub.

Indirect syscalls + DInvoke made simple. Contribute to nbaertsch/nimvoke development by creating an account on GitHub.

A repository of Windows Shellcode runners and supporting utilities. The applications load and execute Shellcode using various API calls or techniques. - Ne0nd0g/go-shellcode

AntiVE-BehaviorWatch is an advanced behavioral analysis malware that detects automated analysis systems through real-time mouse movement pattern recognition. Leveraging GRU neural networks, it provides high-accuracy classification of user behavior while identifying potential virtual machine, sandbox, or emulation environments. - NirvanaOn/AntiVE-BehaviorWatch

SHELLSILO is a cutting-edge tool that translates C syntax into syscall assembly and its corresponding shellcode. It streamlines the process of constructing and utilizing structures, assigning variables, and making system calls. With this tool, integrating strings into your shellcode and initializing Unicode strings has never been easier. - nixpal/shellsilo

Cobalt Strike BOF for beacon/shellcode injection using fork & run technique with Draugr synthetic stack frames - NtDallas/BOF_Spawn

BOF with Synthetic Stackframe. Contribute to NtDallas/Draugr development by creating an account on GitHub.

Contribute to NtDallas/Huginn development by creating an account on GitHub.

Sleep obfuscation. Contribute to NtDallas/KrakenMask development by creating an account on GitHub.

Cobaltstrike Reflective Loader with Synthetic Stackframe - NtDallas/OdinLdr

PoC tools of Bytecode Jiu-Jitsu presented at Black Hat USA 2024 Briefings - ntt-zerolab/Bytecode_Jiu-Jitsu

PoC tools of Bytecode Jiu-Jitsu presented at Black Hat USA 2024 Briefings - ntt-zerolab/Bytecode_Jiu-Jitsu

CobaltStrike BOF to spawn Beacons using DLL Application Directory Hijacking - Octoberfest7/DropSpawn_BOF

This comprehensive process injection series is crafted for cybersecurity enthusiasts, researchers, and professionals who aim to stay at the forefront of the field. It serves as a central repository of knowledge, offering in-depth exploration of various process injection techniques and methods used by adversaries. - GitHub - Offensive-Panda/ProcessInjectionTechniques: This comprehensive process injection series is crafted for cybersecurity enthusiasts, researchers, and professionals who aim to stay at the forefront of the field. It serves as a central repository of knowledge, offering in-depth exploration of various process injection techniques and methods used by adversaries.

Abusing Windows fork API and OneDrive.exe process to inject the malicious shellcode without allocating new RWX memory region. - Offensive-Panda/RWX_MEMEORY_HUNT_AND_INJECTION_DV

Reflective DLL Injection Made Bella. Contribute to oldboy21/RflDllOb development by creating an account on GitHub.

P³-Shellcode Loader is a loader that implements a code injection technique which leverages the Process Parameters structure as an execution and staging location for shellcode injection into remote processes, without triggering common detection mechanisms. - Orange-Cyberdefense/p3-loader

This is the repository for indicators of compromise (IOCs) and other data for threat intelligence articles posted on the Palo Alto Networks Unit 42 website. - Unit42-Threat-Intelligence-Article-Information/Mega-Malware-Analysis-Tutorial-Featuring-Donut.pdf at main · PaloAltoNetworks/Unit42-Threat-Intelligence-Article-Information

The code is a pingback to the Dark Vortex blog: https://0xdarkvortex.dev/hiding-memory-allocations-from-mdatp-etwti-stack-tracing/ - paranoidninja/Proxy-Function-Calls-For-ETwTI

Self-cleaning in-memory PICO loader for Crystal Palace. Automatically erases traces and operates entirely in memory for stealthy payload execution. - pard0p/Self-Cleaning-PICO-Loader

Another version of .NET loader provides capabilities of bypassing ETW and AMSI, utilizing VEH for syscalls and loading .NET assemblies - patrickt2017/VEHNetLoader

WasmForge — compile Go and C# programs to single-binary, WASM-sandboxed native executables with polymorphic output. - praetorian-inc/wasmforge

Weaponize DLL hijacking easily. Backdoor any function in any DLL. - Print3M/DllShimmer

PIC shellcode (C/C++) development toolkit designed for malware developers. - Print3M/epic

Yet another C++ Cobalt Strike beacon dropper with Compile-Time API hashing and custom indirect syscalls execution - ProcessusT/Venoma

Evasion kit for Cobalt Strike. Contribute to rasta-mouse/Crystal-Kit development by creating an account on GitHub.

GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.

Contribute to RedSiege/DigDug development by creating an account on GitHub.

DLLirant is a tool to automatize the DLL Hijacking researches on a specified binary. - redteamsocietegenerale/DLLirant

A script to generate AV evaded(static) DLL shellcode loader with AES encryption. - restkhz/ShellcodeEncrypt2DLL

executing shellcode directly from a python variable - rkbennett/pyobject_inject

Code execution/injection technique using DLL PEB module structure manipulation - RWXstoned/LdrShuffle

Encrypted shellcode Injection to avoid Kernel triggered memory scans - GitHub - S3cur3Th1sSh1t/Caro-Kann: Encrypted shellcode Injection to avoid Kernel triggered memory scans

RustyWater represents the main payload and the backbone of the entire adversarial operation in Static Kitten group attacks. - GitHub - S3N4T0R-0X0/RustyWater-ShellCode-Dropper: RustyWater represents the main payload and the backbone of the entire adversarial operation in Static Kitten group attacks.

A set of fully-undetectable process injection techniques abusing Windows Thread Pools - SafeBreach-Labs/PoolParty

A Rust port of LayeredSyscall — performs indirect syscalls while generating legitimate API call stack frames by abusing VEH. - safedv/RustVEHSyscalls

Dynamically convert an unmanaged EXE or DLL file to PIC shellcode by prepending a shellcode stub. - senzee1984/InflativeLoading

Contribute to Sizeable-Bingus/MassDriver development by creating an account on GitHub.

Contribute to sliverarmory/COFFLoader development by creating an account on GitHub.

Four-kit defense evasion suite for Sliver C2: Crystal Palace loader, sleep masking, in-memory PE execution, and remote process injection with PPID spoofing. - Squ1shification/SliverC2-Evasion-Suite

Security-first AI-native C5 teamserver (Command · Control · Cognitive · Collaborative · Coordination) for authorized red team & pentest. Built by SquidSec. - SquidSec/SquidC5

Shellcode Loader using indirect syscalls. Contribute to srothlisberger6361/ShellCodeLoader_Indirect_Syscalls development by creating an account on GitHub.

Reflective DLL injection is a library injection technique in which the concept of reflective programming is employed to perform the loading of a library from memory into a host process. - ReflectiveDLLInjection/Readme.md at master · stephenfewer/ReflectiveDLLInjection

Deploy stealthy reverse shells using advanced process hollowing with GhostStrike – a C++ tool for ethical hacking and Red Team operations. - stivenhacker/GhostStrike

Stack Spoofing with Synthetic frames based on the work of namazso, SilentMoonWalk, and VulcanRaven - susMdT/LoudSunRun

Local & remote Windows DLL Proxying. Contribute to synacktiv/DLHell development by creating an account on GitHub.

Proof of concepts demonstrating some aspects of the Windows kernel shadow stack mitigation. - synacktiv/windows_kernel_shadow_stack

Invoke-SPSI - Simple PowerShell Shellcode Injector - t1Sh1n4/Invoke-SPSI

A remote process injection using process snapshotting based on https://gitlab.com/ORCA000/snaploader , in rust. It creates a sacrificial process, takes a snapshot of the process, and injects shellcode into it. - Teach2Breach/snapinject_rs

bof-launcher - a library for loading, executing and in-memory masking BOFs on Windows (x64, x86) and Linux (x64, x86, aarch64, arm). Ready to use in C/Zig/Rust/Go/C++ applications. - The-Z-Labs/bof-launcher

A variant of Gargoyle for x64 to hide memory artifacts using ROP only and PIC - thefLink/DeepSleep

Aims to identify sleeping beacons. Contribute to thefLink/Hunt-Sleeping-Beacons development by creating an account on GitHub.

Multilayered AV/EDR Evasion Framework. Contribute to thomasxm/BOAZ_beta development by creating an account on GitHub.

Metamorphic cross-compilation of C++ & C-code to PIC, BOF & EXE. - GitHub - tijme/dittobytes: Metamorphic cross-compilation of C++ & C-code to PIC, BOF & EXE.

Using Just In Time (JIT) instruction decryption, this shellcode loader ensures that only the currently executing instruction is visible in memory. - tijme/kong-loader

Contribute to toneillcodes/UnwindRaven development by creating an account on GitHub.

Exploiting DLL Hijacking by DLL Proxying Super Easily - tothi/dll-hijack-by-proxying

Situational Awareness commands implemented using Beacon Object Files - trustedsec/CS-Situational-Awareness-BOF

FaceDancer is an exploitation tool aimed at creating hijackable, proxy-based DLLs by taking advantage of COM-based system DLL image loading - Tylous/FaceDancer

SourcePoint is a C2 profile generator for Cobalt Strike command and control servers designed to ensure evasion. - GitHub - Tylous/SourcePoint: SourcePoint is a C2 profile generator for Cobalt Strike command and control servers designed to ensure evasion.

kernel callback removal (Bypassing EDR Detections) - V-i-x-x/kernel-callback-removal

🔥📜 Forbidden collection of Red Team sorcery 📜🔥. Contribute to vari-sh/RedTeamGrimoire development by creating an account on GitHub.

Example of call stack spoofing trough the construction of syntetic frames and stack manipulation - vgeorgiev90/CallStackSpoof

Contribute to violet-devsec/win-shellcode-dev development by creating an account on GitHub.

Windows memory scanner for call stack spoofing detection, unbacked shellcode, injected DLLs and in-memory C2 implants. - Vith0r/StackSentry

A new technique that can be used to bypass memory scanners. This can be useful in hiding problematic code (such as reflective loaders implemented by C2 beacons) or other problematic executables that will be flagged by the antimalware programs(such as mimikatz). - vxCrypt0r/Voidmaw

Sickle - Payload Development Kit. Contribute to wetw0rk/sickle-pdk development by creating an account on GitHub.

Cross-platform CPU-based virtual machine detection framework for modern offensive security. - Whispergate/berlin

Rust for malware Development is a repository for advanced Red Team techniques and offensive malwares & Ransomwares, focused on Rust 🦀 - Whitecat18/Rust-for-Malware-Development

A bunch of shenanigans using functions, VEH and more - whokilleddb/funcshenanigans

Things i do because i saw it on twitter on a weekend - whokilleddb/lordran.polymorphic.shellcode

Things i do because i saw it on twitter on a weekend - whokilleddb/lordran.polymorphic.shellcode

Print the stack trace. Contribute to whokilleddb/stacktracer development by creating an account on GitHub.

Windows Kernel-Mode Shellcode Development Framework (WKMSDF) - winterknife/PLATINUMPICK

A PoC implementation for spoofing arbitrary call stacks when making sys calls (e.g. grabbing a handle via NtOpenProcess) - WithSecureLabs/CallStackSpoofer

A spiritual .NET equivalent to the Gargoyle memory scanning evasion technique - WithSecureLabs/dotnet-gargoyle

https://blog.f-secure.com/hiding-malicious-code-with-module-stomping/ - WithSecureLabs/ModuleStomping

Generating legitimate call stack frame along with indirect syscalls by abusing Vectored Exception Handling (VEH) to bypass User-Land EDR hooks in Windows. - WKL-Sec/LayeredSyscall

A PoC of Stack encryption prior to custom sleeping by leveraging CPU cycles. - WKL-Sec/StackMask

Polymorphic x64 shellcode loader — indirect syscalls, phantom DLL hollowing, call stack spoofing, patchless AMSI/ETW bypass, zero CRT dependency - xAL6/zero-loader

A CET-compatible Windows x64 loader that produces fully backed call stacks through runtime function table manipulation, code cave injection, and inverted function table collapse. - xec412/NocturneLdr

A foundational C library for building operationally credible offensive capabilities - youssefnoob003/SindriKit

NOPe - Testing some alternate NOP opcodes. Contribute to ZephrFish/NOPe development by creating an account on GitHub.

Early Bird Cryo Injections – APC-based DLL & Shellcode Injection via Pre-Frozen Job Objects - zero2504/Early-Cryo-Bird-Injections

Rust C2 agent for Mythic that produces polymorphic shellcode: per-build function shuffle + ChaCha20-encrypted data sections; no_std/no_main agent, PEB-walked APIs, WinHTTP comms. - ZZ0R0/Proteus

Explore the challenges of analyzing malware samples without relying on files or memory parsing. Learn about reconstructing executables in this in-depth technical analysis.

Explore a simple technique developed to encrypt Cobalt Strike’s Beacon in memory while executing BOFs to prevent a memory scan from detecting Beacon.

Dive into how X-Force Red experts created hypothetical detections that could be implemented to detect publicly disclosed active call stack evasion techniques.

One of the areas I really enjoy working on and learning more about is malware development. I started years ago with Sektor7’s Malware Development Essentials course and recently jumped into the Intermediate one. Overall, both courses are great and I definitely recommend them. On the intermediate course one area I found particularly interesting was reflective DLL injection. The course did a great job explaining it but I also saw it as an opportunity to challenge myself and understand it more deeply, and along the way to make some changes that align better with the current red team landscape.

Windows Process Internals: A few Concepts to know before jumping on Memory Forensics [Part 4] — VADs A Journey in to the Undocumented VAD Structures (Virtual Address Descriptors) What is Virtual …

An introduction to Havoc Professional 0.7 K-Noir, featuring a new Linux implant for x86_64 and AArch64, CET compliant stack spoofing and rules systems, new Direct and P2P communication channels, new memory allocation and thread injection techniques, and much more.

The initial release of the long awaited Havoc Professional and the Kaine-kit is finally here and new team member.

T(ROP)H: Thread Hijacking with ROP How to use ROP to inject a DLL into a remote thread TL;DR Allocating memory with EXECUTE privileges in the context of another process is a well-known IOC, as it …

Modern Endpoint Detection and Response systems depend on persistent, bidirectional communication with their cloud management console, enabling them to continuously report suspicious activity and receive updated instructions or response actions. If that communication is disrupted, the EDR continues to collect telemetry locally, but it can no longer generate alerts to the cloud console. Threat actors…

Interesting Technique to Launch a Shellcode, Author: Xavier Mertens

No Agent, No Problem: Discovering Remote EDR As the reader, I’m sure you’re thinking — “oh great, another EDR internals or bypass post”. I can fully understand that sentiment, as EDRs are …

Mirrored from WKL Security. This version is an update ahead.

Mirrored from WKL Security

Recently I was developing a simple Shellcode Loader which uses Callbacks as an alternative of Shellcode execution. While it bypasses every runtime scanning, it failed to bypass the signature detection. So I fired up ThreatCheck to identify the bad bytes:

Foreword

Foreword

TL;DR

TL;DR

Implementing an early exception handler for hooking and threadless process injection without relying on VEH or SEH

Customizing Malware to Evade YARA, PE-sieve, and More

A Beginner’s Guide to EDR Evasion Or, how to get past Crowdstrike/Defender ATP/Carbon Black on your next engagement In this post, I’m going to cover the process I used to write a shellcode loader …

Windows Defender is enabled by default in all modern versions of Windows making it an important mitigation for defenders and a potential target for attackers.

This blog post will present research into attempting to bypass memory scanners using Cobalt Strike’s beacon payload and the gargoyle memory scanning evasion technique.

Call stacks are an understated yet often important source of telemetry for EDR products.

Learn about the default x64 calling convention that one function uses to make calls into another function.

When performing process injection, one of the most important IOCs that make up behavioural signatures is passing execution to our shellcode. Whilst there are multiple techniques to doing so and this is certainly nothing purely “new” - in this post I want to showcase not just a “new proof-of-concept technique”, but the entire process I went through in hope that this can become a proper addition to a capability developer’s skill set.

Hi all, in this blog we will discuss sleep masking in detail, the default assumptions that come with it, and how we are going to break those assumptions with a novel approach called InsomniacUnwinding.

The Blog of Josh Lospinoso

A reflective retrospective on Gargoyle, temporal memory state, the 2026 refresh, and what better validation teaches defenders.

Multi-gadget pool proxy system in Zig — route arbitrary Win32 API calls through the thread pool with gadget-based return address masking. No implant code on the stack, ever.

A walk through on how implant sleep-obfuscation evolved from naive Sleep() through Ekko and friends, why call-stack hunters forced stack spoofing, and how ETW Threat Intelligence plans to catch them all.

Performing Windows API hooking with Rust on Windows ARM

Understanding the basics of user mode EDR hooking, common bypass techniques, and their limitations.

Evading user mode EDR hooks by hijacking the AppVerifier layer

Posts about Cyber Security, Malware Development, and more.

AV/EDR Evasion | Malware Development Hello! Welcome to our thrilling playlist dedicated to understanding the art of evading anti-virus solutions. Have you ever wondered how hackers manage to slip …

“” is published by Hossam Ehab.

In this writeup is continuing the first part of “EDR Evasion” that it will be your first steps in Malware Development & Anti-Virus Evasion, Anti-Virus Evasion is important topic in “Red Team…

Before we delve into the topic that talking about "Unhooking & Hiding Object Memory", allow me to reintroduce myself and provide a brief overview of this playlist. My name is Hossam Ehab and I’m here to guide you through the realm of anti-virus (AV) | EDR Evasion | Malware Development…

Bypass EDR’s memory protection, introduction to hooking Introduction On a recent internal penetration engagement, I was faced against an EDR product that I will not name. This product greatly …

Obfuscating a Mimikatz Downloader to Evade Defender (2024) Friend link if you aren’t a member Hello everyone, today I will show how to obfuscate a Mimikatz downloader to bypass Defender …

Using DInvoke and Sliver to Evade OpenEDR and Escalate Privileges Friend link if you aren’t a member Hello everyone, I finally decided to go beyond just evading Defender and move into EDR evasion …

Adventures in Dynamic Evasion Most teams I have worked with rely heavily on anecdotal evidence when it comes to evasion. If an operator is asked why they chose a technique over another, the most …

Blending In: Why “Encrypt Everything” Makes You More Visible A few months ago I set out to build my own C2 framework , Lethe, as a personal research project. My goal was not to reinvent the wheel …

Parent PID Spoofing While I was conducting my research on process injection techniques, I came across Chirag’s blog where he wrote a tool with two process injection techniques, Vanila Injection and …

Beyond the APIs: A Windows Internals Deep Dive into Process Injection Introduction Process injection is a technique that allows one process to run code inside another. It is widely used by malware to …

Bring Your Own RWX Region DLL (BYORWXDLL) Welcome to this new Medium post, today we are exploring a technique I call Bring Your Own RWX Region DLL (BYORWXDLL), inspired by the well-known BYOVD (Bring …

“” is published by S12 - 0x12Dark Development.

Havoc C2 with AV/EDR Bypass Methods in 2024 (Part 1) DISCLAIMER: Using these tools and methods against hosts that you do not have explicit permission to test is illegal. You are responsible for any …

Havoc C2 with AV/EDR Bypass Methods in 2024 (Part 2) DISCLAIMER: Using these tools and methods against hosts that you do not have explicit permission to test is illegal. You are responsible for any …

Manual Indirect Syscalls and Obfuscation for Shellcode Execution DISCLAIMER: Using these tools and methods against hosts that you do not have explicit permission to test is illegal. You are …

Finding pastures new: An alternate approach for implant design (MetaInvoke [Alpha]) — Disclaimer: This blog post is currently only meant to create an active discussion about the overarching …

Don’t Be So Primitive: Evolving the Module Stomping Staging Chain Using Undocumented Kernel Transitions to Achieve Single-Primitive Module Stomping In offensive Windows tradecraft, the multi-step …

The Single-Primitive Write: WriteProcessMemory’s Hidden Page Flip Documenting Undocumented WriteProcessMemory Behavior In offensive Windows tradecraft, we are taught to treat memory protections as …

DDM Use Case: What ATT&CK Gets Wrong about Process Injection This article is part of a series on Threat Detection. In this post, I’ll demonstrate the value of detection data models (DDMs) using …

Syscalls vs Modern AV/EDR in 2025: The Myth, the Reality, and What Actually Matters For years, offensive security circles have treated direct and indirect syscalls as some kind of dark magic — a …

A CET-compliant callstack spoofing technique that uses Windows thread-pool enum callbacks as syscall trampolines, defeating EDR stack telemetry without breaking Intel shadow-stack invariants.

The philosophy and initial usage guide for RustPack

UDRLs and prepended loaders aren’t the only way to execute a raw payload and get a direct hooking in place. In the case of Cobalt Strike, a generic PE loader can be tweaked to execute an UDRL-less Beacon and get direct hooking for an easier prototyping of Sleep obfuscation techniques. Using this approach, two techniques that bypasses the Elastic’s RX -> RW Sleep detection, along with few other scanners, are then demonstrated.

Red Teaming and offensive stuff

A journey in improving Module Stomping and Module Overloading injection technique, ending up evading Moneta and PE-Sieve

Executables with RWX sections can be abused using a variation of a Process Overwriting technique dubbed Process Stomping. Using (a modified) sRDI and leveraging the new features of Cobalt Strike 4.9 has been possible to load beacon in the RWX section itself without the need for a custom UDRL.

Red Teaming and offensive stuff

21 December 2021

If you’ve ever “understood” DLL hijacking, only to return to your lab and fail to get it working properly, this post is for you.

In this chapter we will cover another approach that helps against memory detection called module stomping, we will talk about IOCs, and how to improve the technique.

Here, we’ll demonstrate how to detect both direct and indirect syscalls by discussing detection rules using Elastic, YARA, and dedicated code. We’ll cover several approaches, including Static Analysis, Page Guard + VEH, Call Stack inspection, and ETW-TI.

In this chapter, we will explore a theoretical explanation of the Reflective DLL Injection process, developed by Stephen Fewer. We will propose insights into the involved techniques.

In this topic, I will provide a brief description of the four subsequent projects. I will start by explaining the shellcode in C, eventually demonstrating how to perform some of the implementations in Assembly. Each project will be divided into two parts: the C code and a simple loader to execute the shellcode. It’s important to note that the developed shellcode needs to be ``position-independent code (PIC).

Now that we have the address of the module loaded into memory, we need to navigate its PE structure and locate the exported function. For this, we’ll use LdrFuncAddr, which behaves similarly to GetProcAddress.

In this guide, we will explore how to develop a Stager & Local Injector, using Fibers for payload execution. To fetch the payload from a web server, we will make use of the WinHttp library. Before diving into specific implementations, it is essential to understand the components and the overall structure of the project.

In the previous chapter, RDI was presented and with improvements, now the Reflective DLL Injection (sRDI) shellcode will be presented. With RDI it is necessary to write the reflexive function exported from the dll, but with sRDI we can “patch” any Dll so that the reflective function is at the beginning of the file, so all the steps previously presented will be carried out and when it arrives in the PE it will be executed normally this is done by creating a shellcode. This isn’t very difficult when we already have the RDI ready, so this chapter won’t be very long.

This journal based on DLL Sideloading is essentially a cleaner approach to DLL Hijacking. If you’ve ever tried DLL Hijacking, you’ve probably encountered the error “The procedure entry point could not be located in the dynamic link library ". This happens because many software applications crash when they try to access a function exported from a DLL. DLL Sideloading comes into play to bypass this issue, providing a more stable and reliable solution.

In this post, we will cover topics such as memory detection evasion. We will discuss how memory scanners work and APC-based sleeping obfuscation.

Hello everyone! It’s been a while, many things happening and not much time for coding. Hard times. Nonetheless I had little time frames for playing with some stuff I would define cool enough to write some lines about it. Last time we talked about Indirect Syscalls for Reflective DLL and I want to thank everyone who liked it and shared some feedback. After that I have decided to focus on in-memory obfuscation techniques since that poor Reflective DLL was target of those scary in-memory scanning tools., Hello everyone! It’s been a while, many things happening and not much time for coding. Hard times. Nonetheless I had little time frames for playing with some stuff I would define cool enough to write some lines about it. Last time we talked about Indirect Syscalls for Reflective DLL and I want to thank everyone who liked it and shared some feedback. After that I have decided to focus on in-memory obfuscation techniques since that poor Reflective DLL was target of those scary in-memory scanning tools.

Here we go again, hello everyone! Sorry I am on a roll this period, can’t really sle(a)p well when I have something still to solve and I had some leftovers from the previous SWAPPALA adventure. What we going to talk about today? Well, lots of failures but with a bright end after all. As mentioned in the last episode I wanted to grant the Reflective DLL I worked on with SWAPPALA super powers., Here we go again, hello everyone! Sorry I am on a roll this period, can’t really sle(a)p well when I have something still to solve and I had some leftovers from the previous SWAPPALA adventure. What we going to talk about today? Well, lots of failures but with a bright end after all. As mentioned in the last episode I wanted to grant the Reflective DLL I worked on with SWAPPALA super powers.

Hello, Hello, Aloooooooo. After some time away from coding I am here again talking about sleeping masks. Thanks to the great cybersec community there is always something to work on 😄 Last time in my blog I have talked how to hide a memory mapping (where in my case a ReflectiveDLL is loaded) from memory scanners. Particularly, SLEAPING and SWAPPALA techniques are used to swap the malicious mapping with a legit Microsoft DLL at the same address, at sleeping time., Hello, Hello, Aloooooooo. After some time away from coding I am here again talking about sleeping masks. Thanks to the great cybersec community there is always something to work on 😄 Last time in my blog I have talked how to hide a memory mapping (where in my case a ReflectiveDLL is loaded) from memory scanners. Particularly, SLEAPING and SWAPPALA techniques are used to swap the malicious mapping with a legit Microsoft DLL at the same address, at sleeping time.

By Michael Barclay on 2025-11-13

Lets explore the use of direct system calls, restore hooked API calls and combine this with a shellcode injection technique called\xa0sRDI.

Direct system calls (syscalls), Indirect syscalls, unhooking, hardware breakpoints, and bringing and loading your own version of a library.

With the Bring Your Own Vulnerable Driver technique popping up in Red Teaming arsenals, check additional capabilities like EDR or LSASS.

Get an introdcution to Early Cascade, a novel process injection technique that is effective against top tier EDRs while avoiding detection.

Learn the concept and design of real-time monitoring for events for Beacon Object Files which allow operators to roll out a network of sensors and stream events to the C2 server for further processing.

A PoC C++ harness that uses LLMs to generate, compile, run, and repair Windows DLLs on target at runtime.

This blog explains how attackers use direct syscalls to overcome most EDR solutions, by first discussing the conventional Windows syscall flow and how most EDR solutions monitor those calls.

Short overview on direct and indirect system calls

DLL Proxy Loading is a technique which an arbitrary DLL exports the same functions as the legitimate DLL and forwards the calls to the legitimate DLL in an attempt to not disrupt the execution flow so the binary is executed as normal. The technique falls under the category of DLL Hijacking and it is typically…

Reflective Code Loading, continues to be a prevalent defense evasion technique frequently encountered during routine threat hunting activities. This technique can be employed by threat actors to load numerous amounts of malicious software including, malware, ransomware, and exploits against known so, Reflective Code Loading, continues to be a prevalent defense evasion technique frequently encountered during routine threat hunting activities. This technique can be employed by threat actors to load numerous amounts of malicious software including, malware, ransomware, and exploits against known software vulnerabilities.

Expose how compiling Sliver into WebAssembly beats EDR: WasmForge produces opsec-safe binaries with zero changes to the tool source.

In this blog, we will discuss how to write a C2 implant for the modern era. We will look at the history of offensive techniques and the progress of defence., In this blog, we will discuss how to write a C2 implant for the modern era. We will look at the history of offensive techniques and the progress of defence.

Endpoint Protection and Response is complicated for both offence and defence. In this blog we take a look at Kernel Callbacks, Hooks, and Thread Call Stacks from both perspectives., Endpoint Protection and Response is complicated for both offence and defence. In this blog we take a look at Kernel Callbacks, Hooks, and Thread Call Stacks from both perspectives.

Endpoint Protection and Response is complicated for both offence and defence. In this blog we take a look at AMSI and ETW from both perspectives., Endpoint Protection and Response is complicated for both offence and defence. In this blog we take a look at AMSI and ETW from both perspectives.

Breaking down the Maelstrom DLL and Loader to identify and discuss remediations for indicators-of-compromise., Breaking down the Maelstrom DLL and Loader to identify and discuss remediations for indicators-of-compromise.

A research preview of our user-mode Windows agent that comprehensively catches malicious code execution.

DLL sideloading can be used for initial access in red team operations. Find the right software, backdoor it. Great way to avoid EDR detection.

We begin the adventure with assembly and shellcoding on Windows x64. In this post, we run the WinAPI function without any imports.

Having established the fundamentals, we now step into the Hacker’s Corner. In this chapter, we dig into the specific architectural details and design choices that transform standard memory management into a fascinating—and critical—landscape for security researchers.

The post describes DLL Sideloading, a technique that allows attackers to execute custom malicious code from within legitimate windows binaries/processes.

Good morning! In today’s blog we’re going to talk about one of the most powerful protections for Windows: PatchGuard, also known as KPP (Kernel Patch Protection).

Latest Research by our Team

Latest Research by our Team

Latest Research by our Team

It’s Morphin’ Time: Self-Modifying Code Sections with WriteProcessMemory for EDR Evasion The Mockingjay process injection technique was designed to prevent the allocation of a buffer with RWX …

Introduction In this post, we’ll take an in-depth look at the new tool I’ve developed to facilitate DLL hijacking in Red Team operations: PhantomCtx. What is PhantomCtx? PhantomCtx is a tool that automates Activation Context hijacking with the objective of loading an arbitrary DLL into the vast majority of signed executables (e.g. Microsoft, Adobe, Mozilla). The loader is presented as a modern alternative to traditional DLL Hijacking and Sideloading techniques: unlike conventional approaches where you need to find a signed vulnerable binary on the target system or rely on known vulnerable Microsoft binaries listed on pages such as HijackLibs (that are usually monitored), the tool does not require a specific binary vulnerable to DLL hijacking.

For some fun and a fair bit of profit

For less fun but even more profit

All good things must come to an end

For the last few weeks, I was developing a full custom Command and Control (C2). This C2 uses several Windows DLL for network communication and specially the WINHTTP.DLL one to handle HTTP requests used for the HTTP and HTTPS listener.As everyone knows, when developing a C2 and the corresponding agent, OPSEC must be the priority, so the agent code must rise as few (ETW) events as possible.The most common way to increase OPSEC when using external DLL is to perform dynamic loading to avoid getting the loaded DLL name in the source code. This can be done using the LoadLibrary Win32 API.

Intro to OPSEC Our Ennemies Offensive Architecture Security Events OPSEC Tips Information Gathering Initial Access Kerberos Attacks Lateral Mouvement Pivoting Tooling & Malwares

A practical end-to-end guide to building command-and-control infrastructure - a minimal Rust implant, a COFF-parsing BOF loader, resilient redirector chains, and a DNS-over-HTTPS covert channel. How each layer fits together and where OPSEC attention actually pays off., A practical end-to-end guide to building command-and-control infrastructure - a minimal Rust implant, a COFF-parsing BOF loader, resilient redirector chains, and a DNS-over-HTTPS covert channel. How each layer fits together and where OPSEC attention actually pays off.

A comprehensive guide to C2 implant architecture - covering communication protocols, execution models, sleep patterns, anti-forensics, and operational security considerations., A comprehensive guide to C2 implant architecture - covering communication protocols, execution models, sleep patterns, anti-forensics, and operational security considerations.

A practical C++ guide to using x86-64 debug registers (DR0-DR7) for user-mode API hooking - how EDRs are blind to hardware breakpoints, when HWBPs beat patching, and how to build a minimal HWBP engine., A practical C++ guide to using x86-64 debug registers (DR0-DR7) for user-mode API hooking - how EDRs are blind to hardware breakpoints, when HWBPs beat patching, and how to build a minimal HWBP engine.

Advanced sleep obfuscation techniques that encrypt implant memory during sleep cycles to evade EDR memory scanning - covering Ekko, Zilean, Foliage, and custom implementations., Advanced sleep obfuscation techniques that encrypt implant memory during sleep cycles to evade EDR memory scanning - covering Ekko, Zilean, Foliage, and custom implementations.

Advanced techniques for spoofing thread call stacks to evade EDR behavioral detection - covering return address spoofing, synthetic frames, and thread stack manipulation., Advanced techniques for spoofing thread call stacks to evade EDR behavioral detection - covering return address spoofing, synthetic frames, and thread stack manipulation.

Comprehensive catalog of VM detection, sandbox evasion, debugger detection, and timing-based anti-analysis techniques - with concrete code, the rationale behind each check, and counter-measures for analysts hardening their lab., Comprehensive catalog of VM detection, sandbox evasion, debugger detection, and timing-based anti-analysis techniques - with concrete code, the rationale behind each check, and counter-measures for analysts hardening their lab.

Understanding reflective DLL loading - manually mapping a PE in memory without disk or LoadLibrary, with a complete walkthrough of the bootstrap, header parsing, section mapping, relocation fixups, import resolution, and modern OPSEC improvements., Understanding reflective DLL loading - manually mapping a PE in memory without disk or LoadLibrary, with a complete walkthrough of the bootstrap, header parsing, section mapping, relocation fixups, import resolution, and modern OPSEC improvements.

Article 1 of Malware Development series , What programming language should be used to develop Malware?

Article 10 of Malware Development series , Private vs Mapped memory

Article 2 of Malware Development series , Note: The information I will be sharing is for pure learning purpose, DO NOT USE IT IN ANY ILLEGAL ACTIONS, let us pause and consider the profound impact we can have by channeling our expertise towards POSITIVE ENDS.

Article 3 of Malware Development series , Payload placement: .rsrc section

Article 4 of Malware Development series , Local DLL InjectionCreating DLLFirst we need to prepare a DLL, we can embed our code directly inside the DLL main function and we have four choices to choose from: switch (ul_reason_for_call) { case DLL_PROCESS_ATTACH: case DLL_THREAD_ATTACH: case DLL_THREAD_DETACH: case DLL_PROCESS_DETACH: break; }Form now we will choose to run the code once the DLL is attached to a process.

Article 5 of Malware Development series , C2 connection

Article 6 of Malware Development series , In this article I am going to be exploring data exfiltration techniques, specifically we are going to obtain the processes running on the target system and send them to our C2 server.

Article 7 of Malware Development series , Encryption and obfuscation

Article 8 of Malware Development series , Definition of Thread Hijacking

Article 9 of Malware Development series , Introduction to APC Injection

In this blog post, the main difference between signature-based and behavior-based Detections are explained. In addition, examples are shown with respective D...

Researchers have developed 8 new undetectable process injection techniques exploiting Windows thread pools to bypass leading EDR solutions.

C2 operational safety is essential. Use redirectors to hide C2 or use stealthy traffic channels. Non-C2 traffic should be blocked as early as possible. Use encrypted shellcode when designing a loader.

Cybersecurity consultancy specialized in offensive security helping top-tier organisations all over the world., ,

Abstract In recent years the interest in obfuscation has increased, mainly because people want to protect their intellectual property. Unfortunately, most of what’s been written is focused on the theoretical aspects. In this article, we will discuss the practical engineering challenges of developing a low-footprint virtual machine interpreter. The VM is easily embeddable, built on open-source technology and has various hardening features that were achieved with minimal effort. Introduction In addition to protecting intellectual property, a minimal virtual machine can be useful for other reasons. You might want to have an embeddable interpreter to execute business logic (shellcode), without having to deal with RWX memory. It can also be useful as an educational tool, or just for fun. Creating a custom VM architecture (similar to VMProtect/Themida) means that we would have to deal with binary rewriting/lifting or write our own compiler. Instead, we decided to use a preexisting architecture, which would be supported by LLVM: RISC-V. This architecture is already widely used for educational purposes and has the advantage of being very simple to understand and implement. Initially, the main contender was WebAssembly. However, existing interpreters were very bloated and would also require dealing with a binary format. Additionally, it looks like WASM64 is very underdeveloped and our memory model requires 64-bit pointer support. SPARC and PowerPC were also considered, but RISC-V seems to be more popular and there are a lot more resources available for it. WebAssembly was designed for sandboxing and therefore strictly separates guest and host memory. Because we will be writing our own RISC-V interpreter, we chose to instead share memory between the guest and the host. This means that pointers in the RISC-V execution context (the guest) are valid in the host process and vice-versa. As a result, the instructions responsible for reading/writing memory can be implemented as a simple memcpy call and we do not need additional code to translate/validate memory accesses (which helps with our goal of small code size). With this property, we need to implement only two system calls to perform arbitrary operations in the host process: uintptr_t riscvm_get_peb(); uintptr_t riscvm_host_call(uintptr_t rip, uintptr_t args[13]); The riscvm_get_peb is Windows-specific and it allows us to resolve exports, which we can then pass to the riscvm_host_call function to execute arbitrary code. Additionally, an optional host_syscall stub could be implemented, but this is not strictly necessary since we can just call the functions in ntdll.dll instead. Toolchain and CRT To keep the interpreter footprint as low as possible, we decided to develop a toolchain that outputs a freestanding binary. The goal is to copy this binary into memory and point the VM’s program counter there to start execution. Because we are in freestanding mode, there is no C runtime available to us, this requires us to handle initialization ourselves. As an example, we will use the following hello.c file: int _start() { int result = 0; for(int i = 0; i < 52; i++) { result += *(volatile int*)&i; } return result + 11; } We compile the program with the following incantation: clang -target riscv64 -march=rv64im -mcmodel=medany -Os -c hello.c -o hello.o And then verify by disassembling the object: $ llvm-objdump --disassemble hello.o hello.o: file format elf64-littleriscv 0000000000000000 <_start>: 0: 13 01 01 ff addi sp, sp, -16 4: 13 05 00 00 li a0, 0 8: 23 26 01 00 sw zero, 12(sp) c: 93 05 30 03 li a1, 51 0000000000000010 <.LBB0_1>: 10: 03 26 c1 00 lw a2, 12(sp) 14: 33 05 a6 00 add a0, a2, a0 18: 9b 06 16 00 addiw a3, a2, 1 1c: 23 26 d1 00 sw a3, 12(sp) 20: 63 40 b6 00 blt a2, a1, 0x20 <.LBB0_1+0x10> 24: 1b 05 b5 00 addiw a0, a0, 11 28: 13 01 01 01 addi sp, sp, 16 2c: 67 80 00 00 ret The hello.o is a regular ELF object file. To get a freestanding binary we need to invoke the linker with a linker script: ENTRY(_start) LINK_BASE = 0x8000000; SECTIONS { . = LINK_BASE; __base = .; .text : ALIGN(16) { . = LINK_BASE; *(.text) *(.text.*) } .data : { *(.rodata) *(.rodata.*) *(.data) *(.data.*) *(.eh_frame) } .init : { __init_array_start = .; *(.init_array) __init_array_end = .; } .bss : { *(.bss) *(.bss.*) *(.sbss) *(.sbss.*) } .relocs : { . = . + SIZEOF(.bss); __relocs_start = .; } } This script is the result of an excessive amount of swearing and experimentation. The format is .name : { ... } where .name is the destination section and the stuff in the brackets is the content to paste in there. The special . operator is used to refer to the current position in the binary and we define a few special symbols for use by the runtime: Symbol Meaning __base Base of the executable. __init_array_start Start of the C++ init arrays. __init_array_end End of the C++ init arrays. __relocs_start Start of the relocations (end of the binary). These symbols are declared as extern in the C code and they will be resolved at link-time. While it may seem confusing at first that we have a destination section, it starts to make sense once you realize the linker has to output a regular ELF executable. That ELF executable is then passed to llvm-objcopy to create the freestanding binary blob. This makes debugging a whole lot easier (because we get DWARF symbols) and since we will not implement an ELF loader, it also allows us to extract the relocations for embedding into the final binary. To link the intermediate ELF executable and then create the freestanding hello.pre.bin: ld.lld.exe -o hello.elf --oformat=elf -emit-relocs -T ..\lib\linker.ld --Map=hello.map hello.o llvm-objcopy -O binary hello.elf hello.pre.bin For debugging purposes we also output hello.map, which tells us exactly where the linker put the code/data: VMA LMA Size Align Out In Symbol 0 0 0 1 LINK_BASE = 0x8000000 0 0 8000000 1 . = LINK_BASE 8000000 0 0 1 __base = . 8000000 8000000 30 16 .text 8000000 8000000 0 1 . = LINK_BASE 8000000 8000000 30 4 hello.o:(.text) 8000000 8000000 30 1 _start 8000010 8000010 0 1 .LBB0_1 8000030 8000030 0 1 .init 8000030 8000030 0 1 __init_array_start = . 8000030 8000030 0 1 __init_array_end = . 8000030 8000030 0 1 .relocs 8000030 8000030 0 1 . = . + SIZEOF ( .bss ) 8000030 8000030 0 1 __relocs_start = . 0 0 18 8 .rela.text 0 0 18 8 hello.o:(.rela.text) 0 0 3b 1 .comment 0 0 3b 1 <internal>:(.comment) 0 0 30 1 .riscv.attributes 0 0 30 1 <internal>:(.riscv.attributes) 0 0 108 8 .symtab 0 0 108 8 <internal>:(.symtab) 0 0 55 1 .shstrtab 0 0 55 1 <internal>:(.shstrtab) 0 0 5c 1 .strtab 0 0 5c 1 <internal>:(.strtab) The final ingredient of the toolchain is a small Python script (relocs.py) that extracts the relocations from the ELF file and appends them to the end of the hello.pre.bin. The custom relocation format only supports R_RISCV_64 and is resolved by our CRT like so: typedef struct { uint8_t type; uint32_t offset; int64_t addend; } __attribute__((packed)) Relocation; extern uint8_t __base[]; extern uint8_t __relocs_start[]; #define LINK_BASE 0x8000000 #define R_RISCV_NONE 0 #define R_RISCV_64 2 static __attribute((noinline)) void riscvm_relocs() { if (*(uint32_t*)__relocs_start != 'ALER') { asm volatile("ebreak"); } uintptr_t load_base = (uintptr_t)__base; for (Relocation* itr = (Relocation*)(__relocs_start + sizeof(uint32_t)); itr->type != R_RISCV_NONE; itr++) { if (itr->type == R_RISCV_64) { uint64_t* ptr = (uint64_t*)((uintptr_t)itr->offset - LINK_BASE + load_base); *ptr -= LINK_BASE; *ptr += load_base; } else { asm volatile("ebreak"); } } } As you can see, the __base and __relocs_start magic symbols are used here. The only reason this works is the -mcmodel=medany we used when compiling the object. You can find more details in this article and in the RISC-V ELF Specification. In short, this flag allows the compiler to assume that all code will be emitted in a 2 GiB address range, which allows more liberal PC-relative addressing. The R_RISCV_64 relocation type gets emitted when you put pointers in the .data section: void* functions[] = { &function1, &function2, }; This also happens when using vtables in C++, and we wanted to support these properly early on, instead of having to fight with horrifying bugs later. The next piece of the CRT involves the handling of the init arrays (which get emitted by global instances of classes that have a constructor): typedef void (*InitFunction)(); extern InitFunction __init_array_start; extern InitFunction __init_array_end; static __attribute((optnone)) void riscvm_init_arrays() { for (InitFunction* itr = &__init_array_start; itr != &__init_array_end; itr++) { (*itr)(); } } Frustratingly, we were not able to get this function to generate correct code without the __attribute__((optnone)). We suspect this has to do with aliasing assumptions (the start/end can technically refer to the same memory), but we didn’t investigate this further. Interpreter internals Note: the interpreter was initially based on riscvm.c by edubart. However, we have since completely rewritten it in C++ to better suit our purpose. Based on the RISC-V Calling Conventions document, we can create an enum for the 32 registers: enum RegIndex { reg_zero, // always zero (immutable) reg_ra, // return address reg_sp, // stack pointer reg_gp, // global pointer reg_tp, // thread pointer reg_t0, // temporary reg_t1, reg_t2, reg_s0, // callee-saved reg_s1, reg_a0, // arguments reg_a1, reg_a2, reg_a3, reg_a4, reg_a5, reg_a6, reg_a7, reg_s2, // callee-saved reg_s3, reg_s4, reg_s5, reg_s6, reg_s7, reg_s8, reg_s9, reg_s10, reg_s11, reg_t3, // temporary reg_t4, reg_t5, reg_t6, }; We just need to add a pc register and we have the structure to represent the RISC-V CPU state: struct riscvm { int64_t pc; uint64_t regs[32]; }; It is important to keep in mind that the zero register is always set to 0 and we have to prevent writes to it by using a macro: #define reg_write(idx, value) \ do \ { \ if (LIKELY(idx != reg_zero)) \ { \ self->regs[idx] = value; \ } \ } while (0) The instructions (ignoring the optional compression extension) are always 32-bits in length and can be cleanly expressed as a union: union Instruction { struct { uint32_t compressed_flags : 2; uint32_t opcode : 5; uint32_t : 25; }; struct { uint32_t opcode : 7; uint32_t rd : 5; uint32_t funct3 : 3; uint32_t rs1 : 5; uint32_t rs2 : 5; uint32_t funct7 : 7; } rtype; struct { uint32_t opcode : 7; uint32_t rd : 5; uint32_t funct3 : 3; uint32_t rs1 : 5; uint32_t rs2 : 5; uint32_t shamt : 1; uint32_t imm : 6; } rwtype; struct { uint32_t opcode : 7; uint32_t rd : 5; uint32_t funct3 : 3; uint32_t rs1 : 5; uint32_t imm : 12; } itype; struct { uint32_t opcode : 7; uint32_t rd : 5; uint32_t imm : 20; } utype; struct { uint32_t opcode : 7; uint32_t rd : 5; uint32_t imm12 : 8; uint32_t imm11 : 1; uint32_t imm1 : 10; uint32_t imm20 : 1; } ujtype; struct { uint32_t opcode : 7; uint32_t imm5 : 5; uint32_t funct3 : 3; uint32_t rs1 : 5; uint32_t rs2 : 5; uint32_t imm7 : 7; } stype; struct { uint32_t opcode : 7; uint32_t imm_11 : 1; uint32_t imm_1_4 : 4; uint32_t funct3 : 3; uint32_t rs1 : 5; uint32_t rs2 : 5; uint32_t imm_5_10 : 6; uint32_t imm_12 : 1; } sbtype; int16_t chunks16[2]; uint32_t bits; }; static_assert(sizeof(Instruction) == sizeof(uint32_t), ""); There are 13 top-level opcodes (Instruction.opcode) and some of those opcodes have another field that further specializes the functionality (i.e. Instruction.itype.funct3). To keep the code readable, the enumerations for the opcode are defined in opcodes.h. The interpreter is structured to have handler functions for the top-level opcode in the following form: bool handler_rv64_<opcode>(riscvm_ptr self, Instruction inst); As an example, we can look at the handler for the lui instruction (note that the handlers themselves are responsible for updating pc): ALWAYS_INLINE static bool handler_rv64_lui(riscvm_ptr self, Instruction inst) { int64_t imm = bit_signer(inst.utype.imm, 20) << 12; reg_write(inst.utype.rd, imm); self->pc += 4; dispatch(); // return true; } The interpreter executes until one of the handlers returns false, indicating the CPU has to halt: void riscvm_run(riscvm_ptr self) { while (true) { Instruction inst; inst.bits = *(uint32_t*)self->pc; if (!riscvm_execute_handler(self, inst)) break; } } Plenty of articles have been written about the semantics of RISC-V, so you can look at the source code if you’re interested in the implementation details of individual instructions. The structure of the interpreter also allows us to easily implement obfuscation features, which we will discuss in the next section. For now, we will declare the handler functions as __attribute__((always_inline)) and set the -fno-jump-tables compiler option, which gives us a riscvm_run function that (comfortably) fits into a single page (0xCA4 bytes): Hardening features A regular RISC-V interpreter is fun, but an attacker can easily reverse engineer our payload by throwing it into Ghidra to decompile it. To force the attacker to at least look at our VM interpreter, we implemented a few security features. These features are implemented in a Python script that parses the linker MAP file and directly modifies the opcodes: encrypt.py. Opcode shuffling The most elegant (and likely most effective) obfuscation is to simply reorder the enums of the instruction opcodes and sub-functions. The shuffle.py script is used to generate shuffled_opcodes.h, which is then included into riscvm.h instead of opcodes.h to mix the opcodes: #ifdef OPCODE_SHUFFLING #warning Opcode shuffling enabled #include "shuffled_opcodes.h" #else #include "opcodes.h" #endif // OPCODE_SHUFFLING There is also a shuffled_opcodes.json file generated, which is parsed by encrypt.py to know how to shuffle the assembled instructions. Because enums are used for all the opcodes, we only need to recompile the interpreter to obfuscate it; there is no additional complexity cost in the implementation. Bytecode encryption To increase diversity between payloads for the same VM instance, we also employ a simple ‘encryption’ scheme on top of the opcode: ALWAYS_INLINE static uint32_t tetra_twist(uint32_t input) { /** * Custom hash function that is used to generate the encryption key. * This has strong avalanche properties and is used to ensure that * small changes in the input result in large changes in the output. */ constexpr uint32_t prime1 = 0x9E3779B1; // a large prime number input ^= input >> 15; input *= prime1; input ^= input >> 12; input *= prime1; input ^= input >> 4; input *= prime1; input ^= input >> 16; return input; } ALWAYS_INLINE static uint32_t transform(uintptr_t offset, uint32_t key) { uint32_t key2 = key + offset; return tetra_twist(key2); } ALWAYS_INLINE static uint32_t riscvm_fetch(riscvm_ptr self) { uint32_t data; memcpy(&data, (const void*)self->pc, sizeof(data)); #ifdef CODE_ENCRYPTION return data ^ transform(self->pc - self->base, self->key); #else return data; #endif // CODE_ENCRYPTION } The offset relative to the start of the bytecode is used as the seed to a simple transform function. The result of this function is XOR’d with the instruction data before decoding. The exact transformation doesn’t really matter, because an attacker can always observe the decrypted bytecode at runtime. However, static analysis becomes more difficult and pattern-matching the payload is prevented, all for a relatively small increase in VM implementation complexity. It would be possible to encrypt the contents of the .data section of the payload as well, but we would have to completely decrypt it in memory before starting execution anyway. Technically, it would be also possible to implement a lazy encryption scheme by customizing the riscvm_read and riscvm_write functions to intercept reads/writes to the payload region, but this idea was not pursued further. Threaded handlers The most interesting feature of our VM is that we only need to make minor code modifications to turn it into a so-called threaded interpreter. Threaded code is a well-known technique used both to speed up emulators and to introduce indirect branches that complicate reverse engineering. It is called threading because the execution can be visualized as a thread of handlers that directly branch to the next handler. There is no classical dispatch function, with an infinite loop and a switch case for each opcode inside. The performance improves because there are fewer false-positives in the branch predictor when executing threaded code. You can find more information about threaded interpreters in the Dispatch Techniques section of the YETI paper. The first step is to construct a handler table, where each handler is placed at the index corresponding to each opcode. To do this we use a small snippet of constexpr C++ code: typedef bool (*riscvm_handler_t)(riscvm_ptr, Instruction); static constexpr std::array<riscvm_handler_t, 32> riscvm_handlers = [] { // Pre-populate the table with invalid handlers std::array<riscvm_handler_t, 32> result = {}; for (size_t i = 0; i < result.size(); i++) { result[i] = handler_rv64_invalid; } // Insert the opcode handlers at the right index #define INSERT(op) result[op] = HANDLER(op) INSERT(rv64_load); INSERT(rv64_fence); INSERT(rv64_imm64); INSERT(rv64_auipc); INSERT(rv64_imm32); INSERT(rv64_store); INSERT(rv64_op64); INSERT(rv64_lui); INSERT(rv64_op32); INSERT(rv64_branch); INSERT(rv64_jalr); INSERT(rv64_jal); INSERT(rv64_system); #undef INSERT return result; }(); With the riscvm_handlers table populated we can define the dispatch macro: #define dispatch() \ Instruction next; \ next.bits = riscvm_fetch(self); \ if (next.compressed_flags != 0b11) \ { \ panic("compressed instructions not supported!"); \ } \ __attribute__((musttail)) return riscvm_handlers[next.opcode](self, next) The musttail attribute forces the call to the next handler to be a tail call. This is only possible because all the handlers have the same function signature and it generates an indirect branch to the next handler: The final piece of the puzzle is the new implementation of the riscvm_run function, which uses an empty riscvm_execute handler to bootstrap the chain of execution: ALWAYS_INLINE static bool riscvm_execute(riscvm_ptr self, Instruction inst) { dispatch(); } NEVER_INLINE void riscvm_run(riscvm_ptr self) { Instruction inst; riscvm_execute(self, inst); } Traditional obfuscation The built-in hardening features that we can get with a few #ifdefs and a small Python script are good enough for a proof-of-concept, but they are not going to deter a determined attacker for a very long time. An attacker can pattern-match the VM’s handlers to simplify future reverse engineering efforts. To address this, we can employ common obfuscation techniques using LLVM obfuscation passes: Instruction substitution (to make pattern matching more difficult) Opaque predicates (to hinder static analysis) Inject anti-debug checks (to make dynamic analysis more difficult) The paper Modern obfuscation techniques by Roman Oravec gives a nice overview of literature and has good data on what obfuscation passes are most effective considering their runtime overhead. Additionally, it would also be possible to further enhance the VM’s security by duplicating handlers, but this would require extra post-processing on the payload itself. The VM itself is only part of what could be obfuscated. Obfuscating the payloads themselves is also something we can do quite easily. Most likely, manually-integrated security features (stack strings with xorstr, lazy_importer and variable encryption) will be most valuable here. However, because we use LLVM to build the payloads we can also employ automated obfuscation there. It is important to keep in mind that any overhead created in the payloads themselves is multiplied by the overhead created by the handler obfuscation, so experimentation is required to find the sweet spot for your use case. Writing the payloads The VM described in this post so far technically has the ability to execute arbitrary code. That being said, it would be rather annoying for an end-user to write said code. For example, we would have to manually resolve all imports and then use the riscvm_host_call function to actually execute them. These functions are executing in the RISC-V context and their implementation looks like this: uintptr_t riscvm_host_call(uintptr_t address, uintptr_t args[13]) { register uintptr_t a0 asm("a0") = address; register uintptr_t a1 asm("a1") = (uintptr_t)args; register uintptr_t a7 asm("a7") = 20000; asm volatile("scall" : "+r"(a0) : "r"(a1), "r"(a7)); return a0; } uintptr_t riscvm_get_peb() { register uintptr_t a0 asm("a0") = 0; register uintptr_t a7 asm("a7") = 20001; asm volatile("scall" : "+r"(a0) : "r"(a7) : "memory"); return a0; } We can get a pointer to the PEB using riscvm_get_peb and then resolve a module by its’ x65599 hash: // Structure definitions omitted for clarity uintptr_t riscvm_resolve_dll(uint32_t module_hash) { static PEB* peb = 0; if (!peb) { peb = (PEB*)riscvm_get_peb(); } LIST_ENTRY* begin = &peb->Ldr->InLoadOrderModuleList; for (LIST_ENTRY* itr = begin->Flink; itr != begin; itr = itr->Flink) { LDR_DATA_TABLE_ENTRY* entry = CONTAINING_RECORD(itr, LDR_DATA_TABLE_ENTRY, InLoadOrderLinks); if (entry->BaseNameHashValue == module_hash) { return (uintptr_t)entry->DllBase; } } return 0; } Once we’ve obtained the base of the module we’re interested in, we can resolve the import by walking the export table: uintptr_t riscvm_resolve_import(uintptr_t image, uint32_t export_hash) { IMAGE_DOS_HEADER* dos_header = (IMAGE_DOS_HEADER*)image; IMAGE_NT_HEADERS* nt_headers = (IMAGE_NT_HEADERS*)(image + dos_header->e_lfanew); uint32_t export_dir_size = nt_headers->OptionalHeader.DataDirectory[0].Size; IMAGE_EXPORT_DIRECTORY* export_dir = (IMAGE_EXPORT_DIRECTORY*)(image + nt_headers->OptionalHeader.DataDirectory[0].VirtualAddress); uint32_t* names = (uint32_t*)(image + export_dir->AddressOfNames); uint32_t* funcs = (uint32_t*)(image + export_dir->AddressOfFunctions); uint16_t* ords = (uint16_t*)(image + export_dir->AddressOfNameOrdinals); for (uint32_t i = 0; i < export_dir->NumberOfNames; ++i) { char* name = (char*)(image + names[i]); uintptr_t func = (uintptr_t)(image + funcs[ords[i]]); // Ignore forwarded exports if (func >= (uintptr_t)export_dir && func < (uintptr_t)export_dir + export_dir_size) continue; uint32_t hash = hash_x65599(name, true); if (hash == export_hash) { return func; } } return 0; } Now we can call MessageBoxA from RISC-V with the following code: // NOTE: We cannot use Windows.h here #include <stdint.h> int main() { // Resolve LoadLibraryA auto kernel32_dll = riscvm_resolve_dll(hash_x65599("kernel32.dll", false)) auto LoadLibraryA = riscvm_resolve_import(kernel32_dll, hash_x65599("LoadLibraryA", true)) // Load user32.dll uint64_t args[13]; args[0] = (uint64_t)"user32.dll"; auto user32_dll = riscvm_host_call(LoadLibraryA, args); // Resolve MessageBoxA auto MessageBoxA = riscvm_resolve_import(user32_dll, hash_x65599("MessageBoxA", true)); // Show a message to the user args[0] = 0; // hwnd args[1] = (uint64_t)"Hello from RISC-V!"; // msg args[2] = (uint64_t)"riscvm"; // title args[3] = 0; // flags riscvm_host_call(MessageBoxA, args); } With some templates/macros/constexpr tricks we can probably get this down to something more readable, but fundamentally this code will always stay annoying to write. Even if calling imports were a one-liner, we would still have to deal with the fact that we cannot use Windows.h (or any of the Microsoft headers for that matter). The reason for this is that we are cross-compiling with Clang. Even if we were to set up the include paths correctly, it would still be a major pain to get everything to compile correctly. That being said, our VM works! A major advantage of RISC-V is that, since the instruction set is simple, once the fundamentals work, we can be confident that features built on top of this will execute as expected. Whole Program LLVM Usually, when discussing LLVM, the compilation process is running on Linux/macOS. In this section, we will describe a pipeline that can actually be used on Windows, without making modifications to your toolchain. This is useful if you would like to analyze/fuzz/obfuscate Windows applications, which might only compile an MSVC-compatible compiler: clang-cl. Link-time optimization (LTO) Without LTO, the object files produced by Clang are native COFF/ELF/Mach-O files. Every file is optimized and compiled independently. The linker loads these objects and merges them together into the final executable. When enabling LTO, the object files are instead LLVM Bitcode (.bc) files. This allows the linker to merge all the LLVM IR together and perform (more comprehensive) whole-program optimizations. After the LLVM IR has been optimized, the native code is generated and the final executable produced. The diagram below comes from the great Link-time optimisation (LTO) post by Ryan Stinnet: Compiler wrappers Unfortunately, it can be quite annoying to write an executable that can replace the compiler. It is quite simple when dealing with a few object files, but with bigger projects it gets quite tricky (especially when CMake is involved). Existing projects are WLLVM and gllvm, but they do not work nicely on Windows. When using CMake, you can use the CMAKE_<LANG>_COMPILER_LAUNCHER variables and intercept the compilation pipeline that way, but that is also tricky to deal with. On Windows, things are more complex than on Linux. This is because Clang uses a different program to link the final executable and correctly intercepting this process can become quite challenging. Embedding bitcode To achieve our goal of post-processing the bitcode of the whole program, we need to enable bitcode embedding. The first flag we need is -flto, which enables LTO. The second flag is -lto-embed-bitcode, which isn’t documented very well. When using clang-cl, you also need a special incantation to enable it: set(EMBED_TYPE "post-merge-pre-opt") # post-merge-pre-opt/optimized if(NOT CMAKE_CXX_COMPILER_ID MATCHES "Clang") if(WIN32) message(FATAL_ERROR "clang-cl is required, use -T ClangCL --fresh") else() message(FATAL_ERROR "clang compiler is required") endif() elseif(CMAKE_CXX_COMPILER_FRONTEND_VARIANT MATCHES "^MSVC$") # clang-cl add_compile_options(-flto) add_link_options(/mllvm:-lto-embed-bitcode=${EMBED_TYPE}) elseif(WIN32) # clang (Windows) add_compile_options(-fuse-ld=lld-link -flto) add_link_options(-Wl,/mllvm:-lto-embed-bitcode=${EMBED_TYPE}) else() # clang (Linux) add_compile_options(-fuse-ld=lld -flto) add_link_options(-Wl,-lto-embed-bitcode=${EMBED_TYPE}) endif() The -lto-embed-bitcode flag creates an additional .llvmbc section in the final executable that contains the bitcode. It offers three settings: -lto-embed-bitcode=<value> - Embed LLVM bitcode in object files produced by LTO =none - Do not embed =optimized - Embed after all optimization passes =post-merge-pre-opt - Embed post merge, but before optimizations Once the bitcode is embedded within the output binary, it can be extracted using llvm-objcopy and disassembled with llvm-dis. This is normally done as the follows: llvm-objcopy --dump-section=.llvmbc=program.bc program llvm-dis program.bc > program.ll Unfortunately, we discovered a bug/oversight in LLD on Windows. The section is extracted without errors, but llvm-dis fails to load the bitcode. The reason for this is that Windows executables have a FileAlignment attribute, leading to additional padding with zeroes. To get valid bitcode, you need to remove some of these trailing zeroes: import argparse import sys import pefile def main(): # Parse the arguments parser = argparse.ArgumentParser() parser.add_argument("executable", help="Executable with embedded .llvmbc section") parser.add_argument("--output", "-o", help="Output file name", required=True) args = parser.parse_args() executable: str = args.executable output: str = args.output # Find the .llvmbc section pe = pefile.PE(executable) llvmbc = None for section in pe.sections: if section.Name.decode("utf-8").strip("\x00") == ".llvmbc": llvmbc = section break if llvmbc is None: print("No .llvmbc section found") sys.exit(1) # Recover the bitcode and write it to a file with open(output, "wb") as f: data = bytearray(llvmbc.get_data()) # Truncate all trailing null bytes while data[-1] == 0: data.pop() # Recover alignment to 4 while len(data) % 4 != 0: data.append(0) # Add a block end marker for _ in range(4): data.append(0) f.write(data) if __name__ == "__main__": main() In our testing, this doesn’t have any issues, but there might be cases where this heuristic does not work properly. In that case, a potential solution could be to brute force the amount of trailing zeroes, until the bitcode parses without errors. Applications Now that we have access to our program’s bitcode, several applications become feasible: Write an analyzer to identify potentially interesting locations within the program. Instrument the bitcode and then re-link the executable, which is particularly useful for code coverage while fuzzing. Obfuscate the bitcode before re-linking the executable, enhancing security. IR retargeting, where the bitcode compiled for one architecture can be used on another. Relinking the executable The bitcode itself unfortunately does not contain enough information to re-link the executable (although this is something we would like to implement upstream). We could either manually attempt to reconstruct the linker command line (with tools like Process Monitor), or use LLVM plugin support. Plugin support is not really functional on Windows (although there is some indication that Sony is using it for their PS4/PS5 toolchain), but we can still load an arbitrary DLL using the -load command line flag. Once we loaded our DLL, we can hijack the executable command line and process the flags to generate a script for re-linking the program after our modifications are done. Retargeting LLVM IR Ideally, we would want to write code like this and magically get it to run in our VM: #include <Windows.h> int main() { MessageBoxA(0, "Hello from RISC-V!", "riscvm", 0); } Luckily this is entirely possible, it just requires writing a (fairly) simple tool to perform transformations on the Bitcode of this program (built using clang-cl). In the coming sections, we will describe how we managed to do this using Microsoft Visual Studio’s official LLVM integration (i.e. without having to use a custom fork of clang-cl). The LLVM IR of the example above looks roughly like this (it has been cleaned up slightly for readability): source_filename = "hello.c" target datalayout = "e-m:w-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128" target triple = "x86_64-pc-windows-msvc19.38.33133" @message = dso_local global [19 x i8] c"Hello from RISC-V!\00", align 16 @title = dso_local global [7 x i8] c"riscvm\00", align 1 ; Function Attrs: noinline nounwind optnone uwtable define dso_local i32 @main() #0 { %1 = call i32 @MessageBoxA(ptr noundef null, ptr noundef @message, ptr noundef @title, i32 noundef 0) ret i32 0 } declare dllimport i32 @MessageBoxA(ptr noundef, ptr noundef, ptr noundef, i32 noundef) #1 attributes #0 = { noinline nounwind optnone uwtable "min-legal-vector-width"="0" "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" } attributes #1 = { "no-trapping-math"="true" "stack-protector-buffer-size"="8" "target-cpu"="x86-64" "target-features"="+cx8,+fxsr,+mmx,+sse,+sse2,+x87" "tune-cpu"="generic" } !llvm.linker.options = !{!0, !0} !llvm.module.flags = !{!1, !2, !3} !llvm.ident = !{!4} !0 = !{!"/DEFAULTLIB:uuid.lib"} !1 = !{i32 1, !"wchar_size", i32 2} !2 = !{i32 8, !"PIC Level", i32 2} !3 = !{i32 7, !"uwtable", i32 2} !4 = !{!"clang version 16.0.5"} To retarget this code to RISC-V, we need to do the following: Collect all the functions with a dllimport storage class. Generate a riscvm_imports function that resolves all the function addresses of the imports. Replace the dllimport functions with stubs that use riscvm_host_call to call the import. Change the target triple to riscv64-unknown-unknown and adjust the data layout. Compile the retargeted bitcode and link it together with crt0 to create the final payload. Adjusting the metadata After loading the LLVM IR Module, the first step is to change the DataLayout and the TargetTriple to be what the RISC-V backend expects: module.setDataLayout("e-m:e-p:64:64-i64:64-i128:128-n32:64-S128"); module.setTargetTriple("riscv64-unknown-unknown"); module.setSourceFileName("transpiled.bc"); The next step is to collect all the dllimport functions for later processing. Additionally, a bunch of x86-specific function attributes are removed from every function: std::vector<Function*> importedFunctions; for (Function& function : module.functions()) { // Remove x86-specific function attributes function.removeFnAttr("target-cpu"); function.removeFnAttr("target-features"); function.removeFnAttr("tune-cpu"); function.removeFnAttr("stack-protector-buffer-size"); // Collect imported functions if (function.hasDLLImportStorageClass() && !function.getName().startswith("riscvm_")) { importedFunctions.push_back(&function); } function.setDLLStorageClass(GlobalValue::DefaultStorageClass); Finally, we have to remove the llvm.linker.options metadata to make sure we can pass the IR to llc or clang without errors. Import map The LLVM IR only has the dllimport storage class to inform us that a function is imported. Unfortunately, it does not provide us with the DLL the function comes from. Because this information is only available at link-time (in files like user32.lib), we decided to implement an extra -importmap argument. The extract-bc script that extracts the .llvmbc section now also has to extract the imported functions and what DLL they come from: with open(importmap, "wb") as f: for desc in pe.DIRECTORY_ENTRY_IMPORT: dll = desc.dll.decode("utf-8") for imp in desc.imports: name = imp.name.decode("utf-8") f.write(f"{name}:{dll}\n".encode("utf-8")) Currently, imports by ordinal and API sets are not supported, but we can easily make sure those do not occur when building our code. Creating the import stubs For every dllimport function, we need to add some IR to riscvm_imports to resolve the address. Additionally, we have to create a stub that forwards the function arguments to riscvm_host_call. This is the generated LLVM IR for the MessageBoxA stub: ; Global variable to hold the resolved import address @import_MessageBoxA = private global ptr null define i32 @MessageBoxA(ptr noundef %0, ptr noundef %1, ptr noundef %2, i32 noundef %3) local_unnamed_addr #1 { entry: %args = alloca ptr, i32 13, align 8 %arg3_zext = zext i32 %3 to i64 %arg3_cast = inttoptr i64 %arg3_zext to ptr %import_address = load ptr, ptr @import_MessageBoxA, align 8 %arg0_ptr = getelementptr ptr, ptr %args, i32 0 store ptr %0, ptr %arg0_ptr, align 8 %arg1_ptr = getelementptr ptr, ptr %args, i32 1 store ptr %1, ptr %arg1_ptr, align 8 %arg2_ptr = getelementptr ptr, ptr %args, i32 2 store ptr %2, ptr %arg2_ptr, align 8 %arg3_ptr = getelementptr ptr, ptr %args, i32 3 store ptr %arg3_cast, ptr %arg3_ptr, align 8 %return = call ptr @riscvm_host_call(ptr %import_address, ptr %args) %return_cast = ptrtoint ptr %return to i64 %return_trunc = trunc i64 %return_cast to i32 ret i32 %return_trunc } The uint64_t args[13] array is allocated on the stack using the alloca instruction and every function argument is stored in there (after being zero-extended). The GlobalVariable named import_MessageBoxA is read and finally riscvm_host_call is executed to call the import on the host side. The return value is truncated as appropriate and returned from the stub. The LLVM IR for the generated riscvm_imports function looks like this: ; Global string for LoadLibraryA @str_USER32.dll = private constant [11 x i8] c"USER32.dll\00" define void @riscvm_imports() { entry: %args = alloca ptr, i32 13, align 8 %kernel32.dll_base = call ptr @riscvm_resolve_dll(i32 1399641682) %import_LoadLibraryA = call ptr @riscvm_resolve_import(ptr %kernel32.dll_base, i32 -550781972) %arg0_ptr = getelementptr ptr, ptr %args, i32 0 store ptr @str_USER32.dll, ptr %arg0_ptr, align 8 %USER32.dll_base = call ptr @riscvm_host_call(ptr %import_LoadLibraryA, ptr %args) %import_MessageBoxA = call ptr @riscvm_resolve_import(ptr %USER32.dll_base, i32 -50902915) store ptr %import_MessageBoxA, ptr @import_MessageBoxA, align 8 ret void } The resolving itself uses the riscvm_resolve_dll and riscvm_resolve_import functions we discussed in a previous section. The final detail is that user32.dll is not loaded into every process, so we need to manually call LoadLibraryA to resolve it. Instead of resolving the DLL and import hashes at runtime, they are resolved by the transpiler at compile-time, which makes things a bit more annoying to analyze for an attacker. Trade-offs While the retargeting approach works well for simple C++ code that makes use of the Windows API, it currently does not work properly when the C/C++ standard library is used. Getting this to work properly will be difficult, but things like std::vector can be made to work with some tricks. The limitations are conceptually quite similar to driver development and we believe this is a big improvement over manually recreating types and manual wrappers with riscvm_host_call. An unexplored potential area for bugs is the unverified change to the DataLayout of the LLVM module. In our tests, we did not observe any differences in structure layouts between rv64 and x64 code, but most likely there are some nasty edge cases that would need to be properly handled. If the code written is mainly cross-platform, portable C++ with heavy use of the STL, an alternative design could be to compile most of it with a regular C++ cross-compiler and use the retargeting only for small Windows-specific parts. One of the biggest advantages of retargeting a (mostly) regular Windows C++ program is that the payload can be fully developed and tested on Windows itself. Debugging is much more difficult once the code becomes RISC-V and our approach fully decouples the development of the payload from the VM itself. CRT0 The final missing piece of the crt0 component is the _start function that glues everything together: static void exit(int exit_code); static void riscvm_relocs(); void riscvm_imports() __attribute__((weak)); static void riscvm_init_arrays(); extern int __attribute((noinline)) main(); // NOTE: This function has to be first in the file void _start() { riscvm_relocs(); riscvm_imports(); riscvm_init_arrays(); exit(main()); asm volatile("ebreak"); } void riscvm_imports() { // Left empty on purpose } The riscvm_imports function is defined as a weak symbol. This means the implementation provided in crt0.c can be overwritten by linking to a stronger symbol with the same name. If we generate a riscvm_imports function in our retargeted bitcode, that implementation will be used and we can be certain we execute before main! Example payload project Now that all the necessary tooling has been described, we can put everything together in a real project! In the repository, this is all done in the payload folder. To make things easy, this is a simple cmkr project with a template to enable the retargeting scripts: # Reference: https://build-cpp.github.io/cmkr/cmake-toml [cmake] version = "3.19" cmkr-include = "cmake/cmkr.cmake" [project] name = "payload" languages = ["CXX"] cmake-before = "set(CMAKE_CONFIGURATION_TYPES Debug Release)" include-after = ["cmake/riscvm.cmake"] msvc-runtime = "static" [fetch-content.phnt] url = "https://github.com/mrexodia/phnt-single-header/releases/download/v1.2-4d1b102f/phnt.zip" [template.riscvm] type = "executable" add-function = "add_riscvm_executable" [target.payload] type = "riscvm" sources = [ "src/main.cpp", "crt/minicrt.c", "crt/minicrt.cpp", ] include-directories = [ "include", ] link-libraries = [ "riscvm-crt0", "phnt::phnt", ] compile-features = ["cxx_std_17"] msvc.link-options = [ "/INCREMENTAL:NO", "/DEBUG", ] In this case, the add_executable function has been replaced with an equivalent add_riscvm_executable that creates an additional payload.bin file that can be consumed by the riscvm interpreter. The only thing we have to make sure of is to enable clang-cl when configuring the project: cmake -B build -T ClangCL After this, you can open build\payload.sln in Visual Studio and develop there as usual. The custom cmake/riscvm.cmake script does the following: Enable LTO Add the -lto-embed-bitcode linker flag Locale clang.exe, ld.lld.exe and llvm-objcopy.exe Compile crt0.c for the riscv64 architecture Create a Python virtual environment with the necessary dependencies The add_riscvm_executable adds a custom target that processes the regular output executable and executes the retargeter and relevant Python scripts to produce the riscvm artifacts: function(add_riscvm_executable tgt) add_executable(${tgt} ${ARGN}) if(MSVC) target_compile_definitions(${tgt} PRIVATE _NO_CRT_STDIO_INLINE) target_compile_options(${tgt} PRIVATE /GS- /Zc:threadSafeInit-) endif() set(BC_BASE "$<TARGET_FILE_DIR:${tgt}>/$<TARGET_FILE_BASE_NAME:${tgt}>") add_custom_command(TARGET ${tgt} POST_BUILD USES_TERMINAL COMMENT "Extracting and transpiling bitcode..." COMMAND "${Python3_EXECUTABLE}" "${RISCVM_DIR}/extract-bc.py" "$<TARGET_FILE:${tgt}>" -o "${BC_BASE}.bc" --importmap "${BC_BASE}.imports" COMMAND "${TRANSPILER}" -input "${BC_BASE}.bc" -importmap "${BC_BASE}.imports" -output "${BC_BASE}.rv64.bc" COMMAND "${CLANG_EXECUTABLE}" ${RV64_FLAGS} -c "${BC_BASE}.rv64.bc" -o "${BC_BASE}.rv64.o" COMMAND "${LLD_EXECUTABLE}" -o "${BC_BASE}.elf" --oformat=elf -emit-relocs -T "${RISCVM_DIR}/lib/linker.ld" "--Map=${BC_BASE}.map" "${CRT0_OBJ}" "${BC_BASE}.rv64.o" COMMAND "${OBJCOPY_EXECUTABLE}" -O binary "${BC_BASE}.elf" "${BC_BASE}.pre.bin" COMMAND "${Python3_EXECUTABLE}" "${RISCVM_DIR}/relocs.py" "${BC_BASE}.elf" --binary "${BC_BASE}.pre.bin" --output "${BC_BASE}.bin" COMMAND "${Python3_EXECUTABLE}" "${RISCVM_DIR}/encrypt.py" --encrypt --shuffle --map "${BC_BASE}.map" --shuffle-map "${RISCVM_DIR}/shuffled_opcodes.json" --opcodes-map "${RISCVM_DIR}/opcodes.json" --output "${BC_BASE}.enc.bin" "${BC_BASE}.bin" VERBATIM ) endfunction() While all of this is quite complex, we did our best to make it as transparent to the end-user as possible. After enabling Visual Studio’s LLVM support in the installer, you can start developing VM payloads in a few minutes. You can get a precompiled transpiler binary from the releases. Debugging in riscvm When debugging the payload, it is easiest to load payload.elf in Ghidra to see the instructions. Additionally, the debug builds of the riscvm executable have a --trace flag to enable instruction tracing. The execution of main in the MessageBoxA example looks something like this (labels added manually for clarity): main: 0x000000014000d3a4: addi sp, sp, -0x10 = 0x14002cfd0 0x000000014000d3a8: sd ra, 0x8(sp) = 0x14000d018 0x000000014000d3ac: auipc a0, 0x0 = 0x14000d4e4 0x000000014000d3b0: addi a1, a0, 0xd6 = 0x14000d482 0x000000014000d3b4: auipc a0, 0x0 = 0x14000d3ac 0x000000014000d3b8: addi a2, a0, 0xc7 = 0x14000d47b 0x000000014000d3bc: addi a0, zero, 0x0 = 0x0 0x000000014000d3c0: addi a3, zero, 0x0 = 0x0 0x000000014000d3c4: jal ra, 0x14 -> 0x14000d3d8 MessageBoxA: 0x000000014000d3d8: addi sp, sp, -0x70 = 0x14002cf60 0x000000014000d3dc: sd ra, 0x68(sp) = 0x14000d3c8 0x000000014000d3e0: slli a3, a3, 0x0 = 0x0 0x000000014000d3e4: srli a4, a3, 0x0 = 0x0 0x000000014000d3e8: auipc a3, 0x0 = 0x0 0x000000014000d3ec: ld a3, 0x108(a3=>0x14000d4f0) = 0x7ffb3c23a000 0x000000014000d3f0: sd a0, 0x0(sp) = 0x0 0x000000014000d3f4: sd a1, 0x8(sp) = 0x14000d482 0x000000014000d3f8: sd a2, 0x10(sp) = 0x14000d47b 0x000000014000d3fc: sd a4, 0x18(sp) = 0x0 0x000000014000d400: addi a1, sp, 0x0 = 0x14002cf60 0x000000014000d404: addi a0, a3, 0x0 = 0x7ffb3c23a000 0x000000014000d408: jal ra, -0x3cc -> 0x14000d03c riscvm_host_call: 0x000000014000d03c: lui a2, 0x5 = 0x14000d47b 0x000000014000d040: addiw a7, a2, -0x1e0 = 0x4e20 0x000000014000d044: ecall 0x4e20 0x000000014000d048: ret (0x14000d40c) 0x000000014000d40c: ld ra, 0x68(sp=>0x14002cfc8) = 0x14000d3c8 0x000000014000d410: addi sp, sp, 0x70 = 0x14002cfd0 0x000000014000d414: ret (0x14000d3c8) 0x000000014000d3c8: addi a0, zero, 0x0 = 0x0 0x000000014000d3cc: ld ra, 0x8(sp=>0x14002cfd8) = 0x14000d018 0x000000014000d3d0: addi sp, sp, 0x10 = 0x14002cfe0 0x000000014000d3d4: ret (0x14000d018) 0x000000014000d018: jal ra, 0x14 -> 0x14000d02c exit: 0x000000014000d02c: lui a1, 0x2 = 0x14002cf60 0x000000014000d030: addiw a7, a1, 0x710 = 0x2710 0x000000014000d034: ecall 0x2710 The tracing also uses the enums for the opcodes, so it works with shuffled and encrypted payloads as well. Outro Hopefully this article has been an interesting read for you. We tried to walk you through the process in the same order we developed it in, but you can always refer to the riscy-business GitHub repository and try things out for yourself if you got confused along the way. If you have any ideas for improvements, or would like to discuss, you are always welcome in our Discord server! We would like to thank the following people for proofreading and discussing the design and implementation with us (alphabetical order): Brit herrcore JustMagic Renegade veritas Additionally, we highly appreciate the open source projects that we built this project on! If you use this project, consider giving back your improvements to the community as well. Merry Christmas!

Our research team is committed to continuously identifying potential security vulnerabilities and techniques that threat actors may exploit to bypass existing security controls. In this blog post, our team is detailing on a comprehensive research specifically focused on process injection techniques utilized by attackers to deceive robust security products integrated into the security stack, such as EDRs and XDRs.

Malware Development 7 : Advanced Code Injection Code Injection: The Next Level — Techniques for the Modern Hacker” Hello everyone, When I was developing my injector, I wanted to know how to find …

We’ll walk through the hooks of a particular AV (Sophos AV) and determine why many of the public methods fail, and how we created our Rust PoC to work against the self-protection techniques of similar hooking engines.

Web, Active Directory and Maldev stuff

This post will focus on the process I followed to understand the events the Threat-Intelligence ETW provider logs and how to uncover the underlying mechanisms.

Analyzing the Evolution and Execution of SysWhispers (1–3) Origins of SysWhispers SysWhispers originated as an experiment or requirement of bypassing User-land hooks placed by AV/EDR softwares to …

A collection of blog posts and experiments conducted on my spare time because I don’t know what else to do. Topics center around engineering and developement.

Injecting Java in-memory payloads for post-exploitation

Malware Development Essentials Part 1 Become an Beginner to Intermediate in Malware Development Field ! For Malware development and security professionals, understanding the inner workings of Windows …

A blog where all things adversarial simulation, malware development and security research is shared.

bof-lazy-loading

phase-dive-sleep-obfuscation

AMSI is the Microsoft anti-malware barrier that every modern user-mode loader has to deal with. Patching it is loud — every defender knows the byte signature. This post walks through a patchless bypass using x86 hardware debug registers + a vectored exception handler. Validated against a contemporary commercial EDR in a licensed lab. Implementation, stack mechanics, and detection avenues.

After the great job and inspiration by x86matthew and his blogpost I decided to play with it as well for x64 bit. The NTAPI function in this method is RtlFirstEntrySList from ntdll.dll. Its definition like Matthew mentioned in his blog is similar like this: 1 DWORD RtlFirstEntrySList(DWORD* Address)

Relatively recently, Yarden Shafir made a blog post about a new way to evade the EDRs for process injection. In the blog post, Yarden mentions that there are new added features in the recent Windows 10 build(Insider) and Windows 11 as well. Some of them are NtCreateProcessStateChange/ NtCreateThreadStateChange and NtChangeProcessState/NtChangeThreadState.

It has been a while, this is my research on trying to change the IOCs of a common remote process injection flow and the end result. I presented this in RedTreat in 2024 and I thought it was about time I publish it. As you most likely know, in order to perform remote process injection a few things need to happen: 1) Open the remote process with PROCESS_ALL_ACCESS or PROCESS_VM_OPERATION, PROCESS_VM_WRITE, PROCESS_CREATE_THREAD to obtain handle to the process 2) Remote allocate enough memory to fit your shellcode 3) Make that memory executable 4) Create a new thread that will execute that shellcode memory address

This post explains a common malware technique using shared memory sections to inject and execute code in a remote process, demonstrating the process in C…

In this blog, we are going to discuss yet another method of hiding malicious code, using Process Hollowing. At a high level, this is where malicious code…

In this post, we will focus on one very specific component of EDR: memory scanners. It scans the memory of a process and attempts to identify non-standard…

A thread can execute any part of the process code, including parts currently being executed by another thread." Essentially, a thread runs code.…

Dynamic-link library (DLL) hijacking remains a popular technique to run malware. We address its evolution using examples from the realm of cybercrime and more.

#sec #offsec #tech, Process injection on Windows 11 bypassing industry leading endpoint protection solutions.

Introduction This method of injection is famous for being used in the Powerloader malware that surfaced sometime around 2013. Nobody knows for sure when it was first used for process injection because the feature exploited has been part of the Windows operating system since the late 80s or early 90s. Index zero of the Extra�

In the evolving landscape of digital security, two prominent challenges emerge that pose significant threats to the integrity of online systems and user data:

Thread pools can be used as an alternative to sleeping threads in C2 implants with several advantages. By relying on a timer and a thread pool, a C2 implant can avoid memory scanners that look for sleeping threads. This also provides advantages in call stack evasion and evading thread creation telemetry.

Generating legitimate call stack frame along with indirect syscalls by abusing Vectored Exception Handling (VEH) to bypass User-Land EDR hooks in Windows.

This blog post is a continuation of the previous entry "Harnessing the Power of Cobalt Strike Profiles for EDR Evasion", we covered the malleable profile

Why Zig I got bored again. So I started learning Zig syntax and how it could be beneficial when it comes to writing loaders. I just wanted something new to try, and with Zig being early days still I thought why not. There aren’t many variations out there currently, so in terms of signatures and pattern detection Zig plays a role here although the underlying behaviour is the same. If you’re new to Windows internals there are some amazing resources and tools out there to help, such as SysWhispers which handles all the syscalls and structs for you. But I was taught to use MSDN for the Win32 functions and NtDoc for the undocumented counterpart. I mention this because it forces you to understand how the structs work and the pointers to such. Both are a goldmine of info :). Also definitely head over to Crr0ww, I can’t recommend his videos enough for explaining these topics. Even better, the homies at Church of Malware are always helpful with anything, I can’t praise them enough, truly inspiring.