MANTIS: A Deep Dive Into IRIS C2's Flagship Windows Agent
Introduction
Most commercial C2 frameworks ultimately deliver reflectively loaded DLLs or executables, wrapped in layers of obfuscation. MANTIS takes a different path, being architected from the ground up as pure position-independent shellcode that executes entirely in memory without ever touching disk.
To the extent that legacy C2 platforms offer PIC shellcode versions of their full agents, they are typically compiled EXEs that are being converted to shellcode with Donut. This conversion comes with a host of potential issues, the most notable of which is the signature ultimately imparted upon the resulting shellcode, which EDR providers have tuned their systems to detect.
Note on Technical Disclosure: This article describes MANTIS's architecture and capabilities in detail while intentionally withholding specific implementation details that could enable signature development by defensive vendors. Where technical specifics are generalized, this is a deliberate operational security decision, not a limitation of the implementation.
The Fundamental Architecture: Why Pure PIC Matters
To understand why MANTIS's architecture represents a significant departure from industry standards, we need to examine what most C2 frameworks actually deploy to a target system.
When Cobalt Strike deploys a beacon, it's loading a DLL. When Brute Ratel deploys a badger, it's loading a DLL. When Sliver deploys an implant, it's serving an executable or DLL that can optionally be converted to shellcode. The Portable Executable format, with its import tables, relocation tables, and structured sections, creates a wealth of indicators for defensive tools to key on. Even when these payloads are converted to shellcode post-facto, they carry the structural signatures of their PE heritage.
MANTIS takes a different approach. The agent itself—highly optimized and compact—was written to execute as pure shellcode from the moment the first function is called. There is no PE header. There are no import tables for EDR hooks to intercept. There are no structured sections for memory scanners to analyze. Instead, MANTIS leverages the process's existing memory space, resolves its own API functions through novel, original techniques at runtime, and exists as a completely self-contained blob of executable code that could be placed at any address in memory and function correctly.
This architectural decision has a number of implications. When a reflectively loaded DLL executes, even with all the obfuscation in the world, it still needs to interact with the host operating system through a well-defined interface. Import tables can be rebuilt, but the very act of resolving imports creates a pattern. Export tables may be hidden, but the structure remains. MANTIS sidesteps this entirely by implementing its own minimal loader logic for the specific task of API resolution while maintaining zero PE structure in its own code. And critically, it does so in a manner which we've heavily tested to ensure robustness and reliability. Every possible issue that you might imagine a PIC shellcode implant having, is something that we've gone through in testing and fixed.
TRADITIONAL C2 (Reflective DLL) MANTIS (Pure PIC) ┌─────────────────────────────┐ ┌─────────────────────────────┐ │ Host Process │ │ Host Process │ │ ┌─────────────────────────┐ │ │ ┌─────────────────────────┐ │ │ │ Reflective Loader │ │ │ │ Stage Zero / Agent │ │ │ └──────────┬──────────────┘ │ │ └──────────┬──────────────┘ │ │ ▼ │ │ │ │ │ ┌─────────────────────────┐ │ │ ▼ │ │ │ PE Structure │ │ │ [Module / API Discovery] │ │ │ [DOS Header] │ │ │ │ │ │ │ [NT Headers] │ │ │ ▼ │ │ │ [Section Headers] │ │ │ [Syscall Resolution] │ │ │ [Import Table] ◄───────┼─DETECT │ │ │ │ │ [Export Table] │ │ │ ▼ │ │ │ [Relocations] │ │ │ [Indirect Syscall + ROP │ │ └─┬────────┬──────────────┘ │ │ Stack Spoofing] │ └───┴────────┴─────────────────┘ └─────────────────────────────┘
The Legacy Tooling Problem: Why Crypters, Packers and Loaders Aren't Enough
To understand why MANTIS represents a meaningful shift, we need to examine the operational reality most red teams face. The typical offensive stack consists of proven C2 frameworks—Cobalt Strike, Mythic, Sliver—that provide mature capabilities and extensive module libraries. However, these frameworks share a common architectural characteristic: while they can generate position-independent shellcode stagers, the full agent that runs long-term is a PE or DLL structure that must be reflectively loaded into memory.
This is where the detection surface expands. Reflective PE loading is both a science and an art—sophisticated implementations use User-Defined Reflective Loaders (UDRLs) to customize the loading process and minimize telemetry. These represent genuine technical expertise. However, reflective PE loading still requires operations that EDRs are specifically designed to detect: mapping PE sections, processing import tables, applying relocations, and setting memory protections that follow PE structural requirements. Once loaded, the agent exists in memory with PE structural characteristics—IAT patterns, VA layouts, section relationships—that memory scanners can fingerprint even when traditional headers are stomped.
The Signature Treadmill
Faced with signatured frameworks, operators turn to commercial crypters, packers, and custom loaders to obfuscate the reflective loading process and in-memory structure. This works, sometimes. An operator might deploy successfully on Monday only to find the same configuration detected on Wednesday.
EDR vendors actively acquire commercial crypters (whether through partnerships, honeypots, or direct purchase), generate hundreds of output samples with different configurations, and analyze what remains constant. Even highly polymorphic tools leave fingerprints: instruction sequences in unpacking stubs, API resolution patterns, memory allocation sizes, PE header modification artifacts. These signatures may be faint, but they're usually sufficient to achieve some appreciable detection rate.
The more successful a crypter becomes, the higher priority it is for signature development. Operators find themselves on a treadmill: invest in a crypter, achieve success for weeks, watch detection rates climb as signatures roll out, rotate to different tools, repeat. The operational cost is time testing configurations, uncertainty about target environments, and risk of detection mid-engagement when signatures update.
Why MANTIS is Different
MANTIS doesn't use a shellcode stager to load a PE-based agent. The stager loads another piece of position-independent shellcode—the full MANTIS agent itself. There is no reflective PE loading phase because there is no PE to load. The full agent, with all its capabilities—encryption, tasking, BOF execution, injection, lateral movement—exists entirely as position-independent code.
Quick interlude: It's not to say that PIC shellcode vs PE loading is the only way to run an agent on a system. People do very neat things with Powershell in-memory, scripting languages and a variety of other live-off-the-land techniques. And we even have some of these available in IRIS C2.
There is no "MANTIS loader signature" to extract because there is no separate loader performing reflective PE mapping. There is no PE structure to fingerprint in memory because the agent was never a PE. The evasion techniques—indirect syscalls, stack spoofing, sleep obfuscation—are intrinsic to the agent's architecture.
For operators moving from legacy tooling plus crypter workflows, the difference is immediate: no crypter compatibility testing, no signature treadmill around loader artifacts, no wondering if this configuration works against this EDR version. The result is a full-featured agent that never exists as a PE structure at any point in its lifecycle.
And importantly, because IRIS C2 customers are very highly vetted, and IRIS C2 takes measures to prevent cracks/leaks, operators aren't faced with the detection rates that come with the endless deluge of signatures that result from the endless deluge of cyber criminals using open source and cracked-commercial C2 platforms.
The Two-Stage Deployment Strategy
MANTIS implements a sophisticated two-stage deployment architecture that balances operational flexibility with minimal initial footprint. Understanding this architecture requires examining both stages in detail.
┌─────────────────┐
│ Stage-Zero │ Extremely compact PIC shellcode stager
│ (Small) │ • Embedded C2 config
└────────┬────────┘ • HTTP GET to listener
│
│ Downloads
▼
┌─────────────────┐
│ Full Agent │ Fully featured MANTIS implant
│ (Large) │ • All C2 capabilities
└─────────────────┘ • BOF execution, lateral movement
│ • Custom encryption
│ Executes in memory
▼
┌─────────────────┐
│ MANTIS C2 │ Full beacon functionality
│ Session │ • Task execution
└─────────────────┘ • File operations, etc.Stage Zero: The Minimal Stager
The first stage, Stage Zero, is a compact piece of PIC shellcode that is served into memory through anyone of the shellcode loaders offered in the IRIS C2 platform. Alternatively, some customers end-up loading Stage Zero through memory corruption exploits where payload size constraints are a major concern.
The stage zero PIC shellcode loader itself employs a number of techniques to remain evasive. The techniques increase the size of the shellcode to some degree, of course. But we think that we struck the right balance on those tradeoffs.
The stager's primary mission is straightforward but must be accomplished with extreme care: download the full MANTIS agent from the C2 server and transfer execution to it. To accomplish this, Stage Zero performs an HTTP/HTTPS request to a configurable endpoint. The C2 configuration—hostname, port, endpoint, TLS settings, and user-agent string—is embedded directly into Stage Zero at compile time, eliminating the need for any configuration parsing logic that might be signatured.
What makes Stage Zero particularly sophisticated is its memory allocation strategy. It's novel, original and yet it's reliable. I could earn a great deal of nerd-points by describing it here, and it would make for a great conference talk. But I prefer money and combat effectiveness to nerd-points.
When the C2 endpoint is unavailable or returns an unexpected response, Stage Zero takes a conservative path by default: it performs a bounded number of retries over a controlled time window and then tears itself down cleanly. Memory allocated for the attempted download is released, network handles are closed, and execution returns to the original thread without leaving a long‑lived polling loop behind. The goal is to fail quietly and predictably rather than remain as a noisy, half-initialized stager.
Critically, Stage Zero can optionally leverage call stack spoofing for these syscalls. When this feature is enabled, instead of calling the allocation API directly and leaving a telltale call stack pointing back to the stager's shellcode region, Stage Zero constructs a fake call stack that appears to originate from legitimate Windows system DLLs. This technique, which is far from new, but cleverly and compactly implemented, defeats call-stack-based behavioral detection.
The Full Agent: Engineered for Stealth
Once Stage Zero successfully retrieves and executes the full MANTIS agent, a considerably more sophisticated piece of code takes over. The full agent implements a complete C2 framework including encryption, tasking, post-exploitation capabilities, and the full suite of evasion techniques.
The agent's initialization sequence reveals the careful thought put into its design. Rather than relying on the standard C runtime library (which would introduce dependencies and create signatures), MANTIS implements its own custom heap allocator on top of Windows heap primitives. The agent creates a private heap, allocates a main MANTIS control structure, then proceeds to initialize each of its component subsystems: cryptography, transport, syscall handling, process manipulation, token management, injection capabilities, BOF execution, and more.
Each subsystem is allocated from the custom heap and initialized through a series of operations that establish the agent's internal state. This modular architecture, implemented in C++ and assembly with careful attention to avoid CRT dependencies, allows different capabilities to be enabled or disabled at build time.
Once initialized, the agent enters its main beacon loop: sleep (with optional obfuscation), check the kill date, then dispatch any queued tasks. This loop continues until the agent is explicitly commanded to exit or encounters its kill date.
Evasion Techniques: A Defense-in-Depth Approach
Modern EDR solutions use overlapping layers of detection: user‑mode API hooks, call‑stack inspection, memory scanning, and network analytics. MANTIS responds with its own layered evasion stack. Indirect syscalls and stack spoofing reshape how sensitive operations appear in telemetry, while sleep and heap obfuscation minimize the static footprint between beacons, and malleable C2 profiles blend traffic into the surrounding environment.
Indirect Syscalls: Bypassing Userland Hooks
User‑mode EDR components typically hook high‑value Windows APIs by patching their stubs in system libraries. Calls to functions like VirtualAlloc, CreateRemoteThread, or WriteProcessMemory are intercepted before they reach the kernel and evaluated against detection logic.
MANTIS's indirect syscall implementation exploits this architectural limitation. Rather than calling APIs that would hit the EDR's hook, MANTIS parses system libraries at runtime to extract syscall numbers and then executes syscalls directly. The implementation locates the syscall stub, extracts the syscall number from the instruction bytes, and then executes the syscall itself using inline assembly.
The elegance of this approach lies in its simplicity. MANTIS doesn't need to maintain a database of syscall numbers for different Windows versions—it extracts them at runtime by parsing the very same libraries that the EDR is hooking. When Windows updates and syscall numbers change, MANTIS adapts automatically.
The actual syscall execution happens through a small assembly stub that sets up the syscall number in the appropriate register, loads the syscall instruction address (also extracted from the system library to handle scenarios where syscalls are performed indirectly), and executes it. From the kernel's perspective, this is identical to a normal syscall. From the EDR's perspective, its userland hooks were never triggered.
MANTIS also remains resilient when user‑mode stubs are tampered with. If the exported entry for a syscall is hooked or modified, the resolver avoids trusting a single stub instance and instead derives stable syscall entry points via cross‑checks that do not rely on on‑disk metadata or already‑hooked exports. The specifics of this fallback logic are intentionally withheld, but the design goal is clear: tolerate common user‑land hooking strategies without degrading stability.
STANDARD API CALL MANTIS INDIRECT SYSCALL
┌──────────────────────────┐ ┌──────────────────────────┐
│ Application Code │ │ MANTIS Agent │
│ call VirtualAlloc │ │ Find Syscall ID │
└────────────┬─────────────┘ └────────────┬─────────────┘
│ │
▼ │
┌──────────────────────────┐ │
│ kernel32.dll │ │
│ VirtualAlloc stub │ │
└────────────┬─────────────┘ │
│ │
▼ │
┌──────────────────────────┐ │
│ ntdll.dll │ │
│ NtAllocateVirtualMemory│ │
│ [ JMP EDR_HOOK ] ◄─────┼─ BLOCKED │
│ ... │ │
│ syscall │ ◄──────────────────────┘
│ ret │ DIRECT EXECUTION
└────────────┬─────────────┘
│
▼
┌──────────────────────────┐
│ Windows Kernel │
└──────────────────────────┘Call Stack Spoofing: Deceiving Behavioral Analysis
Call stack spoofing targets a newer class of detections that examine the call stack around sensitive operations. If a call to allocate or make memory executable originates from unbacked shellcode memory, that is a straightforward detection opportunity.
Call stack spoofing defeats this entire category of detection by constructing fake call stacks that appear to originate from legitimate system DLLs. The implementation is intricate and represents one of MANTIS's most sophisticated evasion techniques.
When MANTIS needs to make a sensitive syscall with stack spoofing enabled, it doesn't simply call the function directly. Instead, it calls into a custom assembly routine that constructs an artificial call stack before executing the target function.
The spoofing process begins by saving the current register state and real return address. MANTIS then constructs a fake call stack that includes frames for standard system execution paths (like thread initialization functions) and a carefully selected ROP gadget from a legitimate system module. These frame addresses are selected because they represent legitimate execution paths that the EDR expects to see.
The implementation uses Windows' own function entry lookup and unwind information to calculate the exact stack frame sizes for each function in the spoofed call chain. This ensures that the fake stack is structurally correct—the frame sizes, return addresses, and stack pointer alignment all match what would exist in a legitimate call chain.
Once the fake stack is constructed, MANTIS transfers execution to the target syscall. From the EDR's perspective, when it captures a call stack trace for that syscall, it sees a call originating from legitimate Windows system code rather than from unbacked shellcode memory. After the syscall completes, the restoration routine unwinds the fake stack frames, restores the saved registers, and returns execution to the real caller.
Importantly, the spoofed stack is assembled dynamically per invocation using live process state, rather than replaying a static template. This allows frame sizes, return addresses, and unwind metadata to reflect the actual environment at the time of the call—closing gaps that advanced scanners sometimes exploit when they compare fixed, synthetic stacks against the thread's real context.
SUSPICIOUS STACK (Standard) SPOOFED STACK (MANTIS)
┌──────────────────────────┐ ┌──────────────────────────┐
│ 0x7FF... Syscall Stub │ │ 0x7FF... Syscall Stub │
├──────────────────────────┤ ├──────────────────────────┤
│ 0x002... Unbacked Memory │ ◄ FAIL │ 0x7FF... KernelBase.dll │ ◄ LEGIT
│ (Shellcode Location) │ │ (ROP Gadget) │
├──────────────────────────┤ ├──────────────────────────┤
│ 0x002... Unbacked Memory │ │ 0x7FF... kernel32.dll │
└──────────────────────────┘ │ (Thread Init) │
├──────────────────────────┤
│ 0x7FF... ntdll.dll │
│ (Thread Entry) │
└──────────────────────────┘The gadget selection deserves special mention. MANTIS dynamically searches for useful ROP gadgets in loaded system modules—specifically looking for gadgets that align with the expected stack frame layout. These gadgets are used to construct stack frames that satisfy the EDR's expectations about how legitimate call stacks are structured. The gadget search happens at runtime, adapting to whatever system modules are loaded in the process, making the technique portable across different Windows configurations.
Sleep Obfuscation: Hiding in Plain Sight
When an agent sleeps between beacon intervals, it presents a unique detection opportunity. The agent's code and data sit in memory, potentially for minutes, hours or even days, waiting for the next callback. Memory scanners can identify known patterns. Anomalous memory regions—unbacked executable memory—can be flagged for analysis.
MANTIS implements sophisticated sleep obfuscation techniques to address this threat. The implementation provides multiple techniques with different tradeoffs between stealth and complexity.
The timer-based sleep obfuscation technique is particularly elegant. Rather than simply sleeping and hoping to avoid detection, MANTIS creates a duplicate thread context, encrypts the agent's executable sections in memory, waits for the sleep interval, and then decrypts the code before resuming execution.
The process leverages Windows' thread pool API and timer callbacks. MANTIS creates a timer that will fire after the sleep interval. While the timer is pending, the agent's code region has been obfuscated in place, rendering it unrecognizable to signature-based scanners. When the timer fires, a callback restores the code, and execution resumes.
This technique defeats memory scanning during sleep periods. A memory dump captured while MANTIS is sleeping will show what appears to be random data in the agent's code region rather than executable code with recognizable patterns. The transformation key is derived from runtime values, making it impossible for a scanner to simply reverse the process without executing the code.
The jitter implementation adds unpredictability to the sleep interval. Rather than beaconing at fixed intervals (which creates a highly regular network pattern that anomaly detection systems can key on), MANTIS calculates a random sleep duration within a configurable jitter range. This irregular pattern is far more difficult to detect than a metronome-like beacon. Operators may also select bounded distributions suited to the environment (for example, uniform or bounded‑normal), enabling timing that better mimics legitimate background activity patterns in the target network.
Heap Obfuscation: Protecting Sensitive Data
Beyond the code itself, the agent maintains considerable sensitive data on the heap: encryption keys, task buffers, command responses, extracted credentials, and more. This data represents a significant OPSEC risk if captured in a memory dump.
MANTIS's heap obfuscation feature addresses this by protecting heap-allocated data during sleep periods using the same timer-based approach as code obfuscation. When enabled, the agent's custom heap allocator tracks all allocations. During the sleep obfuscation routine, MANTIS walks its allocation list and encrypts each heap block before sleeping. After waking, it decrypts the heap before processing tasks.
The implementation is carefully designed to avoid corrupting heap metadata. Only the actual data regions are protected—the heap's internal structures remain intact, allowing standard heap operations to continue functioning correctly after restoration.
Malleable C2 Profiles: Blending In With Legitimate Traffic
The network layer provides another rich source of indicators for defenders. HTTP request patterns, user-agent strings, URL structures, HTTP headers, and request timing can all be used to fingerprint C2 traffic.
MANTIS implements a flexible transport layer that supports full C2 profile customization. The operator can configure custom HTTP headers, user-agent strings, endpoint URLs, and more. The agent's HTTP client, built on native Windows APIs, generates traffic that can be crafted to blend with whatever network patterns exist in the target environment.
Critically, all C2 communication is encrypted using a custom block cipher implementation designed specifically for C2 communication. The custom block cypher implementation would be fascinating to read about in more detail, but for the sake of opsec, I chose to leave it out of this blog post. What I can say is that in internal testing, encryption overhead is negligible compared to typical network latency for beacon traffic. This approach provides robust encryption for C2 communication while maintaining MANTIS's zero-dependency architecture. The cipher is strong enough to resist all traffic analysis while remaining lightweight enough to not burden the agent.
The agent supports both HTTP/HTTPS and SMB transports. The SMB transport is particularly valuable for lateral movement scenarios and for establishing peer-to-peer communication channels between agents that don't have direct internet access.
BOF Execution: Post-Exploitation Without Dropping Files
One of MANTIS's most powerful features is its ability to execute Beacon Object Files (BOFs) in memory. For the few of you who made it this far and don't know: BOFs are small C programs compiled to object file format that can be loaded and executed within the agent's process space without spawning new processes or touching disk.
IRIS C2 Agent Interaction Window: Operators can browse and execute hundreds of post-exploitation modules organized by MITRE ATT&CK categories, all running in-memory within the MANTIS agent process.
MANTIS implements a full COFF (Common Object File Format) loader that can parse object files, resolve their imports, apply relocations, and execute their code. This capability transforms MANTIS from a simple C2 agent into a platform for post-exploitation operations.
The BOF loader begins by parsing the object file's headers to understand its structure. MANTIS walks the symbol table, categorizing each symbol as either an imported function (requiring resolution from the host process), a defined function (existing within the BOF), or a variable.
For imported functions, MANTIS implements an API resolution system that can resolve both standard Windows APIs and internal MANTIS functions. This latter capability is particularly powerful—BOF authors can call back into MANTIS to use its encryption, networking, or injection capabilities, effectively extending the agent's functionality without modifying its core code.
Once symbols are resolved, MANTIS allocates memory for the BOF, copies each section into its proper location, and applies relocations. Relocations adjust addresses in the code to account for where the BOF was actually loaded in memory.
With relocations applied, MANTIS locates the BOF's entry point, sets up the calling convention, and calls into the BOF code. The BOF executes within the agent's process space, with full access to the agent's capabilities through the import mechanism.
When the BOF completes, MANTIS captures any output it generated, packages it as a task result, and sends it to the C2 server. The BOF's memory is optionally retained or freed.
We have tested IRIS C2's library of more than 500 BOFs and experienced very, very few crashes of the beacon process. You can drag and drop your internal library of BOFs into IRIS C2 and have confidence in the MANTIS agent's ability to run them reliably.
Some of what we covered in this section about BOF operations in this section sounds a lot less stealthy than many of the operations of the MANTIS agent. In the next section, we'll cover our BOF API hooking system, which is designed to solve for that potential lack of stealth.
The BOF API Hooking Subsystem
MANTIS's BOF execution capability includes an sophisticated optional feature: API hooking. When enabled, the BOF loader can intercept calls from BOF code to sensitive Windows APIs and route them through MANTIS's own implementation instead.
Consider a BOF that calls a memory allocation API. Without hooking, that call goes directly to the system library, where EDR hooks are likely waiting. With MANTIS's BOF API hooking enabled, the loader resolves the API to a MANTIS-internal function that performs the same operation using indirect syscalls and stack spoofing.
The hook table maintains mappings from API name hashes to MANTIS function pointers. When the BOF loader resolves imports, it checks each import against the hook table. If a match is found, the loader redirects the import to the MANTIS function instead of the system API. This allows legacy BOFs written without OPSEC considerations to benefit from MANTIS's evasion techniques automatically.
The hook table includes mappings for memory operations, context manipulation, and other sensitive operations. The implementation is extensible—new hooks can be added simply by updating the table and implementing the corresponding MANTIS function.
Transparent OPSEC Wrapper for Community BOFs
In practice, this means operators can run large portions of the community BOF ecosystem—even code that was never written with EDR evasion in mind—while inheriting MANTIS's syscall indirection and stack spoofing automatically. Calls that would normally light up user‑mode hooks are sanitized at the import boundary and executed via MANTIS's hardened pathways. BOFs that statically link unusual APIs or perform unsupported operations will execute with standard semantics (i.e., without redirection), so operators should continue to validate tradecraft in a lab. But for the vast majority of "classic" BOF use cases, the wrapper effect is immediate and requires no source changes to the BOF itself.
Delivery Mechanisms: Never Touching Disk
An implant's evasion capabilities mean little if the initial delivery mechanism burns the operation. MANTIS's two-stage architecture provides operational flexibility, but how does Stage Zero reach the target in the first place?
This is where IRIS C2's integrated payload generation capabilities come into play. MANTIS doesn't exist in isolation—it's part of a complete offensive platform that includes sophisticated delivery mechanisms designed to complement the agent's capabilities.
JAVELIN: The Polymorphic Loader
The JAVELIN FUD (Fully Undetectable) Loader is engineered specifically for deploying shellcode payloads like MANTIS's Stage Zero. JAVELIN can be compiled as either a standalone executable or a DLL for side-loading attacks, and every build generates a completely unique binary through polymorphic compilation. You can read more about JAVELIN in our blog post about it here.
MK 48: The PE Infector
For scenarios where executables must appear legitimate, IRIS C2 provides the MK 48 PE Infector. MK 48 takes a legitimate, signed Windows executable and injects MANTIS's Stage Zero shellcode into it through advanced PE manipulation techniques.
The infected executable retains all of its original functionality—it will still launch, still perform its intended purpose, and still present a valid digital signature (or at least not present an obviously invalid one). But embedded within its code section, hidden among legitimate instructions, lies the Stage Zero shellcode.
When the infected executable runs, MK 48's carrier component locates the embedded shellcode, allocates memory, decrypts and copies the shellcode, transitions the memory protections, and executes it. The legitimate executable then continues its normal execution as if nothing happened. From the user's perspective, they launched a program and it worked correctly. From the operator's perspective, MANTIS is beaconing back.
This approach has several operational benefits. The infected executable appears completely legitimate—it's a real program, potentially one the user expects to see, potentially one that already exists in the environment. There's no suspicious new executable appearing in Downloads or on the desktop. File reputation systems, which track known good files, may give the infected binary a pass if it was based on a commonly-used legitimate executable. And again, the full MANTIS agent never touches disk—only the tiny Stage Zero exists on disk, encrypted within a legitimate executable.
MK 48, at this point, is categorized as moderately evasive against the leading EDRs.
Enterprise‑Scale Validation
MANTIS's claims are grounded in hands‑on validation across more than thirty production‑grade EDR/AV/XDR products in lab and partner environments that mirror real enterprise deployments. We exercised delivery, staging, and post‑exploitation against representative vendors including Microsoft Defender for Endpoint, CrowdStrike Falcon, SentinelOne, Palo Alto Cortex, Elastic EDR, Trend Micro, Kaspersky, Cybereason, Positive Technologies (MaxPatrol), Qi‑Anxin/360, Venustech, and Sangfor.
Under the versions and configurations tested, our current version of MANTIS achieves the intended operational outcome with no detections or crashes observed in our evaluations. To preserve OPSEC and avoid enabling targeted signatures, we do not publish vendor‑specific playbooks, version information, or tuning data.
Operational Stability and Integration
The technical sophistication of an implant means little if it crashes in production or doesn't integrate with post-exploitation tooling. MANTIS has been extensively tested for stability across a wide range of Windows versions, from Windows 10 through Windows 11 and Windows Server 2019/2022.
The agent implements comprehensive error handling throughout its codebase. Memory allocation failures are caught and handled gracefully. Network timeouts don't crash the agent. Malformed task responses are rejected safely. When MANTIS encounters an error, it logs it (through encrypted C2 channel), handles it, and continues operating. This robustness is critical in real-world operations where network conditions are unreliable and unexpected situations are the norm.
Conclusion: The Return of Craftsmanship in Offensive Tooling
In an industry that often leans on wrapped open-source tools and obfuscation-as-a-service, MANTIS represents something rarer: deliberate craftsmanship in implant design. Every component was built with operational security as the primary requirement and evaluated against how modern EDR actually detects things in the field.
For red teams in mature environments, penetration testers demonstrating realistic adversary capability, and government customers facing off against the most hardened targets, MANTIS shows what pure PIC architecture can deliver when it is the foundation rather than an afterthought.
Note: To maintain operational security and prevent the creation of specific signatures by defensive cybersecurity providers, certain technical implementation details, specific metrics, and exact offsets of the MANTIS agent have been generalized or omitted from this public release.