Hubbry Logo
ShellcodeShellcodeMain
Open search
Shellcode
Community hub
Shellcode
logo
7 pages, 0 posts
0 subscribers
Be the first to start a discussion here.
Be the first to start a discussion here.
Shellcode
Shellcode
Shellcode
View on Wikipedia
from Wikipedia

Shellcode is executable code intended to be used as a payload for exploiting a software vulnerability. The term includes shell because the attack originally described an attack that opens a command shell that the attacker can use to control the target machine, but any code that is injected to gain access that is otherwise not allowed can be called shellcode. For this reason, some consider the name shellcode to be inaccurate.[1]

An attack commonly injects data that consists of executable code into a process before or as it exploits a vulnerability to gain control. The program counter is set the shellcode entry point so that that the shellcode runs. Deploying shellcode is often accomplished by including the code in a file that a vulnerable process downloads and then loads into its memory.

Common wisdom dictates that to maximum effectiveness, a shellcode payload should be small.[2] Machine code provides the flexibility needed to accomplish the goal. Shellcode authors leverage small opcodes to create compact shellcode.[3][4]

Types

[edit]
Local

A local shellcode attack allows an attacker to gain elevated access privilege on their computer. In some cases, exploiting a vulnerability can be achieved by causing an error such as buffer overflow. If successful, the shellcode enables access to the machine via the elevated privileges granted to the targeted process.

Remote

A remote shellcode attack targets a process running on a remote machine – on the same local area network, intranet, or on the internet. If successful, the shellcode provides access to the target machine across the network. The shellcode normally opens a TCP/IP socket connection to allow access to a shell on the target machine.

A remote shellcode attack can be categorized by its behavior. If the shellcode establishes the connection it is called a reverse shell, or a connect-back shellcode. On the other hand, if the attacker establishes the connection, the shellcode is called a bindshell because the shellcode binds to a certain port on the victim's machine. A bindshell random port skips the binding part and listens on a random port.[a] A socket-reuse shellcode is an exploit that establishes a connection to the vulnerable process that is not closed before the shellcode runs so that the shellcode can re-use the connection to allow remote access. Socket re-using shellcode is more elaborate, since the shellcode needs to find out which connection to re-use and the machine may have many open connections.[5]

A firewall can detect outgoing connections made by connect-back shellcode as well as incoming connections made by bindshells, and therefore, offers some protection against an attack. Even if the system is vulnerable, a firewall can prevent the attacker from connecting to the shell created by the shellcode. One reason why socket re-using shellcode is used is that it does not create new connections and, therefore, is harder to detect and block.

Download and execute

A download and execute shellcode attack downloads and executes malware on the target system. This type of shellcode does not spawn a shell, but rather instructs the machine to download a certain executable file from the network and execute it. Nowadays, it is commonly used in drive-by download attacks, where a victim visits a malicious webpage that in turn attempts to run such a download and execute shellcode in order to install software on the victim's machine.

A variation of this attack downloads and loads a library.[6][7] Advantages of this technique are that the code can be smaller, that it does not require the shellcode to spawn a new process on the target system, and that the shellcode does not need code to clean up the targeted process as this can be done by the library loaded into the process.

Staged

When the amount of data that an attacker can inject into the target process is too limited to achieve the desired effect, it may be possible to deploy shellcode in stages that progressively provide more access. The first stage might do nothing more than download the second stage than then provides the desired access.

Egg-hunt

An egg-hunt shellcode attack is a staged attack in which the attacker can inject shellcode into a process but does not know where in the process it is. A second-stage shellcode, generally smaller than the first, is injected into the process to search the process's address space for the first shellcode (the egg) and executes it.[8]

Omelet

An omelet shellcode attack, similar to egg-hunt, looks for multiple small blocks of data (eggs) and combines them into a larger block (omelet) that is then executed. This is used when an attacker is limited on the size of injected code but can inject multiple.[9]

Encoding

[edit]

Shellcode is often written in order to work around the restrictions on the data that a process will allow. General techniques include:

Optimize for size

Optimize the code to decrease its size.

Self-modifying code

Modify its own code before executing it to use byte values that are otherwise restricted.

Encryption

To avoid intrusion detection, encode as self-decrypting or polymorphic.

Character encoding

An attack that targets a browser might obfuscate shellcode in a JavaScript string using an expanded character encoding.[10] For example, on the IA-32 architecture, here's two unencoded no-operation instructions (used in a NOP slide): 

90             NOP
90             NOP

As encoded:

Null-free

Shellcode must be written without zero-value bytes when it is intended to be injected into a null-terminated string that is copied in the target process via the usual algorithm (i.e. strcpy) of ending the copy at the first zero byte – called the null character in common character sets. If the shellcode contained a null, the copy would be truncated and not function properly. To produce null-free code from code that contains nulls, one can replace machine instructions that contain zeroes with instructions that don't. For example, on the IA-32 architecture the instruction to set register EAX to 1 contains zeroes as part of the literal (1 expands to 0x00000001). 

B8 01000000    MOV EAX,1

The following instructions accomplish the same goal (EAX containing 1) without embedded zero bytes by first setting EAX to 0, then incrementing EAX to 1: 

33C0           XOR EAX,EAX
40             INC EAX
Text

An alphanumeric shellcode consists of only alphanumeric characters (0–9, A–Z and a–z).[11][12] This type of encoding was created by hackers to obfuscate machine code inside what appears to be plain text. This can be useful to avoid detection of the code; to allow the code to pass through filters that scrub non-alphanumeric characters from strings.[b]. A similar type of encoding is called printable code and uses all printable characters (alphanumeric plus symbols like !@#%^&*). A similarly restricted variant is ECHOable code not containing any characters which are not accepted by the ECHO command. It has been shown that it is possible to create shellcode that looks like normal text in English.[13] Writing such shellcode requires in-depth understanding of the instruction set architecture of the target machines. It has been demonstrated that it is possible to write alphanumeric code that is executable on more than one machine,[14] thereby constituting multi-architecture executable code.

A work-around was published by Rix in Phrack 57[11] in which he shows that it is possible to turn any code into alphanumeric code. Often, self-modifying code is leveraged because it allows the code to have byte values that otherwise are not allowed by replacing coded values at runtime. A self-modifying decoder can be created that initially uses only allowed bytes. The main code of the shellcode is encoded, also only using bytes in the allowed range. When the output shellcode is run, the decoder modifies its code to use instructions it requires and then decodes the original shellcode. After decoding the shellcode, the decoder transfers control to it. It has been shown that it is possible to create arbitrarily complex shellcode that looks like normal English text.[13]

Modern software uses Unicode to support Internationalization and localization. Often, input ASCII text is converted to Unicode before processing. When an ASCII (Latin-1 in general) character is transformed to UTF-16 (16-bit Unicode), a zero byte is inserted after each byte (character) of the original text. Obscou proved in Phrack 61[12] that it is possible to write shellcode that can run successfully after this transformation. Programs that can automatically encode any shellcode into alphanumeric UTF-16-proof shellcode exist, based on the same principle of a small self-modifying decoder that decodes the original shellcode.

Compatibility

[edit]

Generally, shellcode is deployed as machine code since it affords relatively unprotected access to the target process. Since machine code is compatible within a relatively narrow computing context (processor, operating system and so on), a shellcode fragment has limited compatibility. Also, since a shellcode attack tends to work best when the code is small and targeting multiple exploits increases the size, typically the code targets only one exploit. None the less, a single shellcode fragment can work for multiple contexts and exploits.[15][16][17] Versatility can be achieved by creating a single fragment that contains an implementation for multiple contexts. Common code branches to the implementation for the runtime context.

Analysis

[edit]

As shellcode is generally not executable on its own, in order to study what it does, it is typically loaded into a special process. A common technique is to write a small C program that contains the shellcode as data (i.e. in a byte buffer), and transfers control to the instructions encoded in the data function pointer or inline assembly code). Another technique is to use an online tool, such as shellcode_2_exe, to embed the shellcode into a pre-made executable husk which can then be analyzed in a standard debugger. Specialized shellcode analysis tools also exist, such as the iDefense sclog project (originally released in 2005 in the Malcode Analyst Pack). Sclog is designed to load external shellcode files and execute them within an API logging framework. Emulation-based shellcode analysis tools also exist such as the sctest application which is part of the cross-platform libemu package. Another emulation-based shellcode analysis tool, built around the libemu library, is scdbg which includes a basic debug shell and integrated reporting features.

See also

[edit]

Notes

[edit]

References

[edit]
[edit]
Revisions and contributorsEdit on WikipediaRead on Wikipedia

Shellcode

View on Grokipedia
from Grokipedia
Shellcode is a compact sequence of machine code instructions, typically written in assembly language, that serves as the payload in software exploit attacks to execute arbitrary commands on a compromised system. It is injected into a vulnerable process—often via techniques like buffer overflows—and executed directly by the processor, bypassing normal application flow to achieve goals such as spawning a remote command shell for attacker control. The term "shellcode" derives from its historical role in opening a command-line interpreter (e.g., /bin/sh on Unix-like systems or cmd.exe on Windows), granting interactive access to the target machine. Originally emerging in the context of early exploits, shellcode has evolved from simple shell-spawning routines to sophisticated payloads capable of , , or deployment. Key characteristics include position independence, allowing execution regardless of memory location, and often the avoidance of null bytes to prevent string termination during injection. In modern cybersecurity, shellcode is integral to both offensive tools like frameworks for penetration testing and real-world attacks, where it inherits the privileges of the exploited process for elevated operations. Common types encompass bind shells (which listen for incoming connections) and reverse shells (which connect back to the attacker), alongside more advanced variants like polymorphic shellcode that mutates to evade detection. Defensive measures focus on techniques such as (ASLR), data execution prevention (DEP), and runtime monitoring to neutralize shellcode execution. Despite these mitigations, shellcode remains a foundational element in vulnerability exploitation, underscoring the ongoing cat-and-mouse dynamic between attackers and security researchers.

Fundamentals

Definition and Purpose

Shellcode is a small piece of or assembly instructions designed to perform a specific task, such as spawning a command shell or executing arbitrary commands, without relying on calls and instead using direct system calls to the operating system kernel. This compact payload enables execution in constrained environments where full programs cannot be loaded. The primary purpose of shellcode is to serve as the in exploits, where it is injected into a vulnerable program's memory to overwrite the return address and redirect execution flow, thereby granting attackers unauthorized control over the target system. Secondary applications include proof-of-concept demonstrations to illustrate software vulnerabilities and integration as modular components in payloads for post-exploitation activities. Key characteristics of effective shellcode include position-independence, achieved through relative addressing techniques like jumps and calls to avoid dependency on absolute memory locations; avoidance of null bytes (0x00), which could terminate the prematurely when injected via string-copy functions; and conciseness, with basic implementations typically measuring under 100 bytes to fit within limited buffer spaces. A representative example is this 46-byte x86 assembly shellcode that invokes the execve to spawn /bin/sh, followed by an exit call:

assembly

jmp 0x1f popl %esi movl %esi,0x8(%esi) xorl %eax,%eax movb %eax,0x7(%esi) movl %eax,0xc(%esi) movb $0xb,%al movl %esi,%ebx leal 0x8(%esi),%ecx leal 0xc(%esi),%edx int $0x80 xorl %ebx,%ebx movl %ebx,%eax inc %eax int $0x80 call -0x24 .string "/bin/sh"

jmp 0x1f popl %esi movl %esi,0x8(%esi) xorl %eax,%eax movb %eax,0x7(%esi) movl %eax,0xc(%esi) movb $0xb,%al movl %esi,%ebx leal 0x8(%esi),%ecx leal 0xc(%esi),%edx int $0x80 xorl %ebx,%ebx movl %ebx,%eax inc %eax int $0x80 call -0x24 .string "/bin/sh"

History

The concept of injecting executable code into vulnerable programs predates the formal term "shellcode," with early examples appearing in the 1988 , which exploited buffer overflows and command injection vulnerabilities to propagate across the , marking it as a precursor to modern techniques. This self-replicating program, created by , demonstrated the potential for remote code execution but lacked the structured payload now associated with shellcode. The term "shellcode" emerged in the amid growing research into exploits, referring to small, position-independent snippets of designed to spawn a command shell upon execution. Its first notable demonstration came in Elias Levy's (pseudonym Aleph One) 1996 magazine article "Smashing the Stack for Fun and Profit," which detailed a x86 shellcode that executed /bin/sh via an execve , providing a foundational template for exploit developers. This publication catalyzed widespread interest in stack-based exploits, shifting focus from theoretical vulnerabilities to practical . By the late , shellcode had become synonymous with exploit payloads in security research. In the , shellcode evolved to counter detection mechanisms, with polymorphic variants rising in through encryption and code mutation to alter signatures while maintaining functionality, evading signature-based antivirus tools. This period saw increased integration into worms and viruses, enhancing propagation and persistence. Post-2010, adaptations addressed memory protections like (ASLR) and Data Execution Prevention (DEP), incorporating (ROP) chains to chain existing code gadgets and bypass non-executable memory restrictions. Researchers like Matt Miller advanced portable shellcode techniques, such as signal-based framing for cross-architecture compatibility. By the 2020s, shellcode had integrated into advanced persistent threats (APTs) and red teaming frameworks, with groups like APT41 employing advanced tools for stealthy payload delivery in cyberespionage campaigns. Similarly, APT29 utilized in-memory shellcode execution via mapped DLLs to maintain persistence. In red teaming, tools like Shellter enable shellcode injection into legitimate Windows applications for evasion testing, reflecting ongoing adaptations to endpoint detection as of 2025.

Development

Writing Techniques

Shellcode is typically crafted using low-level assembly languages such as x86 assembly in or syntax to generate that executes directly on the target architecture. A fundamental requirement is (PIC), which ensures the shellcode runs regardless of its loading address in memory, achieved through relative addressing techniques like jumps and calls that compute offsets dynamically. For instance, a common method involves a forward jump over the payload followed by a call instruction, where the call pushes the return address (pointing to the data section) onto the stack, allowing subsequent instructions to pop and use it as a base pointer for string literals or offsets. To avoid problematic characters such as null bytes (0x00), which can terminate string-based buffer copies during exploitation, developers replace direct moves of zero values with operations like XOR on registers, as xorl %eax, %eax clears the register without embedding null bytes in the . Alternative instructions are selected for loading constants; for example, pushing multi-byte values onto the stack in segments avoids direct moves that might introduce nulls. is managed with short jumps or calls to minimize footprint while maintaining functionality, ensuring the code remains executable in constrained environments like stack overflows. Optimization focuses on reducing size to fit within buffer limits, prioritizing compact instructions for system calls, such as using int $0x80 on x86 to invoke syscalls directly rather than longer sequences. Instruction selection emphasizes shorter opcodes; for example, zeroing registers via XOR (2 bytes) over explicit moves saves space, and combining pushes for argument setup streamlines syscall preparation. These choices balance functionality with brevity, often resulting in payloads under 50 bytes for basic operations like spawning a shell. The development process begins with writing the assembly code in a , targeting the desired syscall such as execve for shell execution. Next, the code is assembled into using an assembler to produce raw bytes, which are then examined for bad characters. Testing occurs in a like GDB, where the shellcode is injected into a vulnerable program or a custom harness, stepping through execution to verify register states, stack setup, and syscall invocation while iterating for fixes like null byte removal. Compatibility checks across environments ensure the final version executes cleanly without crashes. A representative example is a 24-byte x86 shellcode for Linux that invokes the execve syscall to run /bin/sh with null arguments, demonstrating PIC and null-free techniques. The assembly (in Intel syntax) is:

BITS 32 SYS_EXECVE equ 0xb _start: push SYS_EXECVE pop eax xor esi, esi push esi push 0x68732f2f ; "//sh" push 0x6e69622f ; "/bin" mov ebx, esp xor ecx, ecx mov edx, ecx int 0x80

BITS 32 SYS_EXECVE equ 0xb _start: push SYS_EXECVE pop eax xor esi, esi push esi push 0x68732f2f ; "//sh" push 0x6e69622f ; "/bin" mov ebx, esp xor ecx, ecx mov edx, ecx int 0x80

This assembles to the machine code: \x6a\x0b\x58\x31\xf6\x56\x68\x2f\x2f\x73\x68\x68\x2f\x62\x69\x6e\x89\xe3\x31\xc9\x89\xca\xcd\x80. Breaking it down byte-by-byte:
  • \x6a\x0b: Pushes 11 (execve syscall number) onto the stack (1 byte for push imm8).
  • \x58: Pops into EAX, setting the syscall number.
  • \x31\xf6: XOR ESI, ESI to zero ESI (avoids nulls).
  • \x56: Pushes ESI (NULL) to null-terminate the filename string on the stack.
  • \x68\x2f\x2f\x73\x68: Pushes "//sh" (reversed as "hs//" due to little-endian stack).
  • \x68\x2f\x62\x69\x6e: Pushes "/bin" (reversed as "nib/").
  • \x89\xe3: Moves ESP (now pointing to "/bin//sh") into EBX as filename argument.
  • \x31\xc9: XOR ECX, ECX to zero ECX (argv pointer, NULL).
  • \x89\xca: Moves ECX into EDX (envp pointer, NULL).
  • \xCD\x80: Invokes int 0x80 to execute execve(EBX, ECX, EDX).
This structure uses stack pushes for PIC string placement and XOR for null avoidance, executing a shell upon successful invocation.

Tools and Languages

Shellcode development primarily relies on low-level programming languages to ensure precise control over machine instructions, with assembly language serving as the foundational choice for most implementations. Architectures such as x86 (and its 64-bit extension, x86-64) and ARM are commonly targeted, where developers write position-independent code to execute payloads without relying on fixed addresses. For prototyping and initial testing, higher-level languages like C can incorporate inline assembly to facilitate rapid iteration and integration with existing codebases, allowing developers to embed assembly snippets directly within C functions before extracting pure shellcode. Key tools in shellcode development include assemblers for compiling assembly code into machine-readable binaries. The (NASM) is widely used for x86 and architectures, supporting flat binary output formats suitable for shellcode without unnecessary headers. The GNU Assembler (GAS), part of the suite, is preferred for ARM-based systems, enabling cross-compilation for diverse platforms. Debuggers play a crucial role in verifying shellcode behavior; the GNU Debugger (GDB) allows stepping through execution, inspecting registers, and setting breakpoints on and systems. On Windows, facilitates kernel-mode and user-mode debugging, including loading shellcode into memory for analysis. Frameworks like Metasploit's msfvenom streamline payload generation by combining encoding and formatting options to produce ready-to-use shellcode. Disassemblers such as objdump from and the free version of IDA Pro aid in verifying and reverse-engineering generated code, revealing instruction flows and potential issues. Testing environments isolate shellcode execution to prevent unintended system impacts, often utilizing virtual machines (VMs) or emulators. Tools like provide controlled VMs with configurable protections disabled, such as (ASLR), for safe iteration on x86 systems. For cross-architecture testing, emulates various processors including , allowing developers to validate shellcode portability without physical hardware. These setups enable repeated execution and debugging in a sandboxed manner. Best practices in shellcode development emphasize organized workflows to maintain reliability and reproducibility. Using version control systems like for managing assembly snippets and prototypes ensures traceability of changes across iterations. Automation scripts, often written in shell or Python, can integrate tools like msfvenom or NASM into pipelines for consistent payload generation, reducing manual errors in repetitive tasks. These approaches, drawn from secure principles, help developers track modifications and automate testing cycles efficiently.

Types

Conventional Types

Conventional shellcode encompasses standard payloads designed for straightforward remote access or command execution on compromised systems, without employing mutation or evasion techniques. These types focus on core functionalities like establishing network connections to spawn command interpreters or running isolated commands, often tailored for specific operating systems such as Windows or Linux. A bind shell is a conventional shellcode variant that creates a listening socket on the target machine, typically on a predefined port such as 4444, to await incoming connections from the attacker. Once connected, it redirects the input/output of a command interpreter, like cmd.exe on Windows, to the established socket, enabling remote shell access. This inbound model requires the target to have an open port, which can be advantageous in environments without strict inbound filtering but may fail if firewalls block unsolicited connections. In contrast, a reverse shell initiates an outbound TCP connection from the compromised system to a listener controlled by the attacker, often on port 4444, thereby delivering a command shell over the channel. By leveraging outbound traffic, reverse shells are particularly effective for evading (NAT) and firewalls that permit egress connections while restricting ingress, as the target machine acts as the client. Command execution shellcode provides a lighter alternative by invoking a single command or downloading and running an external without spawning a full interactive shell. For instance, it might execute a command like to reveal user privileges or use functions such as InternetOpen and InternetReadFile to fetch and launch a secondary from a remote server, facilitating staged attacks. This approach minimizes footprint and avoids persistent shells, though it often results in larger payloads due to the added download logic. Key differences among these types lie in their communication direction and resource demands: bind shells rely on inbound connections, making them susceptible to port blocking, while reverse shells favor outbound initiation for better firewall traversal. Additionally, reverse shells tend to be smaller (approximately 325–376 bytes on Windows) compared to bind shells (353–404 bytes) or command execution variants (493–502 bytes), owing to simpler socket handling without listening mechanisms. These shellcodes frequently incorporate encoding to evade detection by avoiding problematic bytes that could disrupt transmission during exploitation.

Advanced Variants

Polymorphic shellcode maintains core functionality while varying its instruction sequences to evade signature-based detection systems, typically achieved through the addition of and decryption stubs that obfuscate the at rest and reveal it only during runtime execution. This approach encrypts the shellcode body with a simple XOR operation or similar , appending a small decryptor routine that runs first to restore the original code before transferring control. By generating unique encrypted variants for each deployment, polymorphic shellcode disrupts pattern-matching heuristics in intrusion detection systems, as no fixed byte sequence persists across instances. Metamorphic shellcode advances evasion further by completely rewriting the code structure without relying on , preserving behavioral semantics through techniques such as insertion and register swapping. insertion adds innocuous instructions—like redundant arithmetic operations or jumps to nowhere—that execute without altering outcomes but inflate and diversify the code's footprint, making static analysis unreliable. Register swapping reassigns variables across non-standard registers (e.g., swapping EAX and EBX usages) or substitutes equivalent instructions, ensuring the logic remains intact while the binary representation changes entirely with each iteration. Unlike polymorphic variants, metamorphic shellcode avoids self-modifying traits, rendering it invisible to emulators that flag decryption routines. Egg hunters represent an adaptive technique for deploying larger payloads in constrained memory environments, where a compact searcher scans for a predefined marker or "" preceding the full shellcode. This involves iterating over memory pages using system calls like NtDisplayString on Windows or access() on to probe for the tag—often an 8-byte repeated twice—while handling access violations gracefully to avoid crashes. NOP sleds may precede the egg for alignment, facilitating reliable jumps once located, though advanced variants employ pattern scanning to minimize false positives in noisy memory regions. The egg hunter itself remains under 50 bytes, enabling its injection into tight buffer overflows while offloading the bulk of functionality to the hidden payload. By 2025, fileless shellcode has evolved to leverage scripting environments like and for cross-platform adaptability and reduced forensic footprints, executing directly in memory without disk artifacts. In loaders, obfuscated base64-encoded byte arrays are decoded and allocated via VirtualAlloc, with dynamic API resolution from the process environment block to invoke shellcode—such as for remote access trojans—bypassing endpoint protections through trusted interpreters. variants, often embedded in documents or web contexts, chain to for payload execution, supporting cross-platform delivery via browsers while maintaining evasion via in-memory and anti-debugging checks. These methods exploit legitimate runtimes for broad compatibility across Windows ecosystems and web vectors, emphasizing stealth over traditional binaries.

Encoding

Reasons for Encoding

One primary motivation for encoding shellcode is to eliminate null bytes (0x00), which can prematurely terminate s during exploitation of vulnerabilities in C-based functions like strcpy or gets. These functions treat null bytes as delimiters, truncating the payload before it can be fully executed, as demonstrated in early techniques. Encoding also enables shellcode to bypass input validation filters imposed by s and security appliances, such as those blocking non-printable or suspicious characters in user inputs. The proliferation of firewalls (WAFs) in the early , exemplified by the launch of open-source in 2002, intensified the need for such evasion techniques by normalizing and inspecting payloads for attack signatures. Beyond basic filtering, encoding facilitates evasion of intrusion detection systems (IDS) through payload normalization resistance and polymorphism, where encoded variants avoid static matches. For instance, techniques like XOR encoding or steganographic transform shellcode to defeat pattern-based alerts in network traffic. This remains relevant against modern (EDR) tools, which monitor for raw shellcode execution; encoding allows in-memory decoding to sidestep behavioral heuristics. Architectural constraints further necessitate encoding, particularly in environments restricting payloads to alphanumeric characters only, such as certain web forms or file uploads that filter out opcodes. Alphanumeric shellcode, constructed using a limited instruction set like IMUL and PUSH, ensures compatibility while maintaining functionality for system calls in exploits. However, encoding introduces trade-offs, including increased payload size from decoder stubs, heightened complexity in development and testing, and potential reliability issues due to decoder across architectures or versions. These factors can expand shellcode from tens to of bytes, complicating injection into constrained buffers.

Techniques

Shellcode encoding techniques transform raw binary into obfuscated forms that can evade detection or restrictions while maintaining executability. These methods typically prepend a decoder stub to the encoded , which restores the original shellcode at runtime. Common approaches include alphanumeric encoding, XOR-based , and or custom schemes suitable for transport. Alphanumeric encoding restricts the shellcode to printable ASCII characters (0-9, A-Z, a-z) to input filters or intrusion detection systems that block non-printable bytes. This is achieved by constructing the using only valid alphanumeric opcodes and operands, often leveraging stack manipulation techniques such as PUSH instructions to build bytes in reverse order and JMP or CALL for . For instance, non-alphanumeric bytes are reconstructed via categories like zero-pushing with INC/DEC operations or XOR patching with bytes to dynamically calculate offsets. A binary shellcode can thus be transformed into an alphanumeric by encoding each byte through these stack-based or memory-patching methods, resulting in a longer but filter-resistant string that self-decodes upon execution. XOR encoding provides a straightforward key-based obfuscation by applying the exclusive-or operation to each byte of the shellcode with a predefined value, such as 0x96, producing an altered payload free of problematic characters. A compact decoder stub is then prepended, which iterates over the encoded data—typically using a loop with instructions like XOR BYTE PTR [EAX], 0x96 and a counter in ECX set to the payload length—to restore the original bytes before jumping to it. For added complexity, multi-stage XOR applies different keys to segments of the shellcode, requiring nested decoders that progressively unveil the payload, enhancing evasion against signature-based analysis. This method is simple yet effective for avoiding null bytes in buffer overflows. Base64 encoding converts shellcode into a printable format using a 64-character , primarily for safe transmission over networks or text-based channels where might corrupt. The encoded is followed by a runtime decoder that reverses the Base64 process—often implemented via lookup tables or algorithmic unpadding—to yield the executable binary. Custom variants adapt this for specific needs, such as combining Base64 with additional layers for compactness during transport. These approaches ensure the shellcode survives protocol constraints before decoding and execution on the target. In recent years, new encoding methods have emerged to counter advanced detection. For example, dictionary-based encoding hides shellcode within sequences of common words to reduce and avoid signatures, as implemented in tools like DictionShellcode. Similarly, the Delta Encoder, introduced in 2024, uses dynamic bitwidth selection for shorter printable shellcode representations. Tools like msfencode (now integrated into msfvenom in the Framework) automate these transformations by applying encoders such as x86/shikata_ga_nai, a polymorphic XOR variant that randomizes the decoder stub across iterations to vary the output. For example, a raw Windows reverse shell payload can be encoded with -e x86/shikata_ga_nai -c 3 -b "\x00", producing a prefixed decoder (e.g., starting with a jmp/call setup) followed by the obfuscated shellcode, output in formats like raw bytes or C arrays for easy integration. Custom scripts, often written in Python or Assembly, allow tailored encoding by implementing decoder logic and key selection, enabling fine-tuned s for specific exploits.

Compatibility

Platform Dependencies

Shellcode execution is inherently tied to the underlying hardware architecture, requiring precise alignment with instruction sets, register sizes, and memory models to function correctly. On x86 architectures, 32-bit shellcode utilizes 32-bit registers such as EAX, EBX, and ESP, with system calls invoked via the INT 0x80 , which passes parameters through registers and the stack. In contrast, x64 extends to 64-bit registers like RAX and RDI, employing the SYSCALL instruction for kernel transitions, which alters parameter passing conventions and increases for operations. These differences necessitate architecture-specific assembly to avoid segmentation faults or invalid operations during execution. ARM architectures, prevalent in mobile and IoT devices, introduce further variances due to their RISC design. The 32-bit AArch32 variant features 16 general-purpose 32-bit registers (R0–R15) and support for both ARM (32-bit instructions) and Thumb (16-bit instructions) modes. The 64-bit AArch64 variant, common in modern devices, uses 31 general-purpose 64-bit registers (X0–X30) with fixed 32-bit instructions and optional 16-bit Thumb-like encodings in some extensions. Unlike x86's CISC variable-length instructions, ARM mandates fixed 4-byte alignments in AArch32 (2-byte in Thumb), complicating code density and requiring conditional execution flags for branching. Endianness plays a critical role, with most modern ARM implementations (e.g., ARMv7-A and ARMv8-A) defaulting to little-endian byte ordering, matching x86, though legacy big-endian modes demand byte-swapping in multi-architecture porting to prevent data corruption. Emerging open architectures like RISC-V, used in some IoT and research contexts, employ a RISC design with 32 general-purpose registers (x0–x31) in the base RV32I/RV64I ISAs, supporting both compressed 16-bit and 32-bit instructions, and little-endian by default. Operating system dependencies amplify these architectural constraints, particularly in syscall invocation. Linux shellcode on x86/x64 relies on direct syscalls like execve (number 11 in 32-bit, 59 in 64-bit), using INT 0x80 or SYSCALL to request services without library intermediaries, while ARM AArch32 employs the SVC instruction with parameters in R0–R3 registers (execve number 11). On AArch64, execve uses syscall number 221 with parameters in X0–X5. Windows shellcode, however, avoids native syscalls in favor of user-mode APIs from kernel32.dll, such as WinExec for process spawning, which requires dynamic resolution of function addresses via the Process Environment Block (PEB) due to randomized loading. Protections like Address Space Layout Randomization (ASLR) exacerbate this by randomizing module bases, compelling shellcode to use relative addressing or runtime base discovery to locate APIs reliably. Cross-platform development faces challenges from byte order discrepancies and avoided library dependencies, favoring direct syscalls to minimize portability issues. While x86, dominant ARM variants, and RISC-V share little-endianness, porting to big-endian systems requires explicit handling of multi-byte values to maintain instruction integrity. For instance, porting an x86 Linux reverse shell using INT 0x80 and stack-based strings to ARM involves rewriting for SVC calls, R0–R3 (or X0–X5) parameter passing, and Thumb mode for compactness, highlighting instruction set divergences that can inflate code size by 20–50% without optimization. Encoding techniques may briefly address character restrictions arising from these variances, such as null-byte avoidance in ARM's fixed instructions.

Mitigation Strategies

To address platform dependencies and enhance portability, shellcode developers utilize universal techniques like dynamic address resolution through memory scanning. This method parses structures such as the Process Environment Block (PEB) on Windows systems to locate loaded modules and scan export tables for functions at runtime, circumventing (ASLR) that would otherwise render hard-coded addresses ineffective. Similarly, on , shellcode can scan the Global Offset Table (GOT) or use linker symbols for resolution, ensuring functionality without platform-specific offsets. As an alternative to injecting executable shellcode, (ROP) chains leverage existing code fragments, or "gadgets," from the program's libraries to construct malicious behavior, avoiding the need for writable executable memory and improving compatibility with randomized layouts. ROP mitigates issues from non-executable memory protections by reusing instruction sequences ending in return statements, chained via controlled stack manipulation to achieve effects like system calls without new . Testing shellcode for cross-environment reliability involves multi-architecture emulation tools like , which simulate diverse CPU architectures such as x86, , and MIPS, enabling developers to build and validate payloads without specialized hardware. For OS-specific adaptations, conditional code paths detect the runtime environment—via checks on system calls, instructions, or memory patterns—and branch to appropriate execution logic, such as selecting syscalls versus equivalents. Operating systems deploy modern defenses to hinder shellcode execution and force compatibility challenges. Data Execution Prevention (DEP), implemented via the on processors, designates stack and heap pages as non-executable, blocking injected shellcode from running unless permissions are explicitly altered. Stack canaries insert random guard values between buffers and control data on the stack; any overflow attempting to redirect execution to shellcode corrupts the canary, triggering termination before exploitation. In Windows, Control Flow Guard (CFG) enforces validation of indirect branches to approved targets, disrupting ROP-based shellcode alternatives that rely on arbitrary jumps. Adopting best practices further bolsters shellcode portability. separates concerns like resolution, payload execution, and cleanup into independent components, facilitating recompilation and adaptation across architectures like x86 to with minimal rework. Staged payloads employ a compact initial loader that dynamically fetches and deploys a full secondary over the network, reducing initial size for easier injection while allowing environment-specific customization post-deployment.

Analysis

Static Methods

Static analysis of shellcode involves examining the code in a non-executable manner to reveal its structure, functionality, and potential malicious intent without risking runtime execution. This approach relies on tools and algorithms that parse the binary data, identify patterns, and infer behavior from static artifacts such as instruction sequences and data embeddings. Common techniques include disassembly, string extraction, and control flow graphing, which help reverse engineers map out the code's logic and dependencies. Disassembly is a foundational technique where binary shellcode is converted into human-readable assembly instructions. Tools like objdump from the GNU Binutils suite allow analysts to disassemble raw binary files by specifying the architecture and bit width, such as using the command objdump -D -b binary -m i386 shellcode.bin to produce an Intel-syntax listing of x86 instructions. Similarly, radare2, an open-source reverse engineering framework, supports quick disassembly of shellcode binaries with commands like r2 -a x86 -b 32 -q -c pd shellcode.bin, enabling visualization of instruction flows in 32-bit x86 mode. These tools facilitate initial code inspection but may require manual adjustments for obfuscated or position-independent code. String extraction complements disassembly by identifying embedded plaintext or encoded data within the shellcode, such as command strings or API references that hint at intended actions like file operations or network connections. Analysts scan the for ASCII or sequences using built-in tools in disassemblers or utilities like strings from , revealing payloads that might invoke system commands. graphing builds on this by constructing a of basic blocks connected by jumps and branches, often generated during disassembly to model decision points and loops. For instance, radare2's afl command analyzes the code to produce a function-like graph, while academic methods employ recursive traversal to handle potential overlaps in instructions. Signature-based methods enhance detection by comparing shellcode against known patterns. Hashing computes cryptographic digests (e.g., or SHA-256) of the entire payload or normalized subsequences to match against databases of verified malicious samples, allowing rapid identification of reused exploits. Entropy analysis quantifies the randomness of byte distributions using , where values approaching 8 bits per byte (maximum for 8-bit data) indicate encoded or obfuscated content, such as XOR-encrypted sections that suggest evasion attempts. High in shellcode often signals techniques like those in polymorphic variants. Despite these strengths, static methods have notable limitations, particularly against advanced obfuscations. They fail on polymorphic shellcode, where engines generate semantically equivalent but structurally diverse variants using or junk insertions, rendering signatures and graphs unreliable due to the vast variability in decoding routines. Additionally, accurate interpretation of system calls, such as those invoking execve, often requires manual annotation, as automated tools may misalign indirect jumps or unresolved addresses without runtime context. A representative example is the static analysis of a 64-bit Linux execve shellcode for spawning /bin/sh, presented in hex as \x6a\x3b\x58\x99\x48\xbb\x2f\x62\x69\x6e\x2f\x73\x68\x00\x53\x48\x89\xe7\x68\x2d\x63\x00\x00\x48\x89\xe6\x52\xe8\x08\x00\x00\x00\x2f\x62\x69\x6e\x2f\x73\x68\x00\x56\x57\x48\x89\xe6\x0f\x05. Disassembly reveals an initial push of 0x3b (syscall number 59 for execve) into RAX, followed by loading /bin/sh\0 into RBX and pushing it to the stack for RDI as the filename argument. A subsequent push of 0x632d (-c) sets up RSI for the argv array, with a relative call to duplicate the string on the stack and finalize arguments before the syscall instruction (0f 05). String extraction uncovers /bin/sh and -c, while entropy calculation on the byte sequence yields approximately 7.2 bits, indicating moderate randomness from packed instructions but no heavy encoding. Control flow graphing shows a linear path with minimal branches, confirming the straightforward payload intent.

Dynamic Methods

Dynamic methods for shellcode analysis involve executing the code in controlled environments to observe its runtime behavior, interactions with the operating system, and potential malicious activities, providing insights that static analysis cannot capture. These techniques are essential for understanding how shellcode establishes , communicates externally, or manipulates system resources during execution. By monitoring execution in isolated setups, analysts can safely replicate real-world impacts without risking the host system. Key techniques include emulation within specialized sandboxes designed for malware dissection. Tools like Cuckoo Sandbox automate the execution of shellcode in virtualized environments, capturing detailed logs of file modifications, registry changes, and process creations triggered by the code. Similarly, REMnux provides a Linux-based toolkit for dynamic reverse engineering, including utilities to convert and run shellcode samples while monitoring their effects in a contained setup. Debugging with tools such as GDB enables step-by-step execution; analysts set breakpoints at critical offsets in the shellcode to inspect register states, memory accesses, and control flow jumps during runtime. For instance, breakpoints can halt execution just before a system call, allowing examination of arguments passed to the kernel. Network monitoring complements these by detecting outbound connections, such as reverse shells where shellcode initiates a TCP connection back to an attacker-controlled host, often using tools like Wireshark to capture packet payloads and ports involved. Behavioral analysis focuses on tracing shellcode's interactions at the system level. is widely used to intercept and log system calls made by the executing shellcode, revealing operations like socket creation for network access or file writes for payload drops; for example, it can trace an execve call attempting to spawn a command shell. Memory forensics tools, such as Volatility, identify injection points by scanning process memory for executable regions with anomalous permissions (e.g., RWX pages) where shellcode resides, often cross-referencing with process lists to pinpoint the host application. This approach uncovers how shellcode evades detection by hiding in non-standard memory areas. Advanced dynamic methods extend to for variant discovery and hybrid approaches integrating runtime data with preparatory static disassembly. involves feeding mutated inputs to shellcode emulators to generate and test variants, observing how changes in opcodes affect behavior like evasion tactics or delivery. Hybrid analysis combines dynamic execution traces—such as syscall sequences—with static disassembly to map obfuscated control flows, enabling comprehensive of polymorphic shellcode. Static disassembly may serve as an initial step to identify entry points before dynamic monitoring. A practical example involves running shellcode in a (VM) environment, such as using or integrated with analysis tools, to safely execute and capture outcomes. For a reverse shell variant, the VM setup allows monitoring spawned processes (e.g., via ps or ProcMon) and open ports (e.g., via netstat), revealing a listener on port 4444 after execution without compromising the host. This isolates artifacts like network traffic dumps and process trees for further forensic review.

Applications

In Exploitation

Shellcode plays a central in the integration of exploits for vulnerabilities such as and use-after-free errors, where it serves as the to achieve remote code execution (RCE). In attacks, attackers overwrite the return address on the stack with the location of shellcode, allowing hijacking to execute arbitrary instructions, often establishing a reverse shell for persistent access. Similarly, in use-after-free vulnerabilities, freed memory objects are repurposed to point to shellcode, enabling attackers to invoke malicious code when the is dereferenced, as seen in browser and scripting engine exploits. To bypass modern mitigations like Data Execution Prevention (DEP), shellcode is frequently chained with (ROP) gadgets, which reuse existing code snippets from the application's libraries to construct a that allocates memory and jumps to the shellcode. Prominent case studies illustrate shellcode's deployment in high-impact attacks. The exploit (CVE-2017-0144), leveraged in the 2017 WannaCry campaign, utilized shellcode delivered via in the SMBv1 protocol to gain RCE on unpatched Windows systems, enabling lateral movement and payload deployment across networks. In the 2021 vulnerability (CVE-2021-44228), attackers exploited JNDI lookups to achieve RCE in applications, often downloading and executing remote scripts or malicious classes for cryptomining or further exploitation. Malware campaigns have extensively incorporated shellcode for and persistence. Stuxnet, discovered in 2010, employed shellcode in zero-day exploits like MS08-067 (RPC) and MS10-073 (Win32k.sys) to inject payloads into privileged processes, targeting systems for sabotage without detection. As of late 2024, groups such as Black Basta evolved payloads using shellcode loaders, where initial access exploits delivered shellcode to evade endpoint detection and deploy routines. By November 2025, successor groups like BlackSuit continued operations with advanced loaders and injection techniques, though specific shellcode usage has shifted toward memory-based evasion in social engineering campaigns. While shellcode enables unauthorized attacks by black hat actors for data theft or disruption, its ethical application in white hat penetration testing simulates real threats to identify weaknesses, with strict adherence to ensuring no harm or occurs.

In Research

on shellcode has primarily focused on improving detection mechanisms and understanding evasion techniques to enhance cybersecurity defenses. Early seminal work examined the limitations of modeling polymorphic shellcode, demonstrating that automatic transformations into semantically equivalent variants render traditional signature-based detection infeasible due to the in possible variants. This analysis highlighted the challenges in using for intrusion detection systems against such code, as the diversity of decoder routines defies tractable modeling. Subsequent studies advanced polymorphic shellcode detection by leveraging emulation to execute potential instruction sequences and profile their behavior against known benign patterns. For instance, network-level detection techniques embedded CPU emulators in intrusion detection systems to identify obfuscated shellcode in traffic streams, achieving high accuracy on real-world polymorphic samples without relying on static signatures. Building on this, into runtime heuristics proposed comprehensive detection frameworks that monitor memory accesses, anomalies, and calls during execution, reporting low false positives on diverse shellcode sets including encrypted and metamorphic variants. Evasion research challenged conventional shellcode representations by developing "English shellcode," which embeds payloads in human-readable text to content-based filters, proving that superficial byte patterns are insufficient for reliable detection. This work stimulated discussions on proactive defenses, emphasizing the need for semantic over syntactic matching. More recently, forensic tools like SHELLOS have enabled rapid in-memory of injected by inputs directly, supporting both detection and attribution in live environments with minimal overhead. Pioneering research from 2022 explored generative approaches using to automatically produce shellcode from textual descriptions, evaluating transformer-based models on assembly generation tasks with success rates exceeding 80% for simple exploits. Dual-transformer architectures integrated generation and summarization, aiding by condensing obfuscated payloads into interpretable forms. As of 2025, advancements include AI-powered shellcode protection modules, such as Palo Alto Networks' Cortex Shellcode AI, which detect unseen variations using precision , and empirical studies confirming high accuracy in NLP-based shellcode generation. These methods underscore shellcode's role in studying automated attack synthesis, though they raise ethical concerns for defensive tool development.

References

  1. https://www.techtarget.com/searchsecurity/answer/What-is-the-relationship-between-shellcode-and-exploit-code
  2. https://www.sentinelone.com/blog/malicious-input-how-hackers-use-shellcode/
  3. https://inst.eecs.berkeley.edu/~cs161/fa08/papers/stack_smashing.pdf
  4. https://arstechnica.com/information-technology/2015/08/how-security-flaws-work-the-buffer-overflow/
  5. https://www.rapid7.com/blog/post/2019/01/02/the-ghost-of-exploits-past-a-deep-dive-into-the-morris-worm/
  6. https://www.bekk.christmas/post/2020/15/hacking-like-it%27s-1996-a-short-history-of-the-stack-buffer-overflow.
  7. https://www.nccgroup.com/research-blog/defeating-windows-dep-with-a-custom-rop-chain/
  8. https://www.ieee-security.org/TC/SP2014/papers/FramingSignals-AReturntoPortableShellcode.pdf
  9. https://www.trendmicro.com/en_us/research/21/h/apt41-resurfaces-as-earth-baku-with-new-cyberespionage-campaign.html
  10. https://cyble.com/threat-actor-profiles/apt-29/
  11. https://github.com/A-poc/RedTeam-Tools
  12. https://phrack.org/issues/49/14.html
  13. https://www.exploit-db.com/exploits/39160
  14. https://www.usna.edu/Users/cs/choi/it432/lec/l12/lec.html
  15. https://seedsecuritylabs.org/Labs_20.04/Files/Shellcode/Shellcode.pdf
  16. https://www.offsec.com/metasploit-unleashed/msfvenom/
  17. https://cloud.google.com/blog/topics/threat-intelligence/loading-kernel-shellcode/
  18. https://www.praetorian.com/blog/reversing-and-exploiting-embedded-devices-part-1-the-software-stack/
  19. https://www.perforce.com/blog/vcs/8-version-control-best-practices
  20. https://www.hick.org/code/skape/papers/win32-shellcode.pdf
  21. https://ntrs.nasa.gov/api/citations/20150000388/downloads/20150000388.pdf
  22. https://ieeexplore.ieee.org/document/10963744
  23. https://dl.acm.org/doi/10.1145/1315245.1315312
  24. https://dl.acm.org/doi/10.1145/1920261.1920305
  25. http://www.hick.org/code/skape/papers/egghunt-shellcode.pdf
  26. https://blog.qualys.com/vulnerabilities-threat-research/2025/05/15/fileless-execution-powershell-based-shellcode-loader-executes-remcos-rat
  27. https://www.mdpi.com/2079-9292/14/15/3134
  28. https://www.approach-cyber.com/wp-content/uploads/2024/08/isaca_techbrief_-_waf_where_do_we_stand_final.pdf
  29. https://www.blackhat.com/presentations/bh-usa-06/BH-US-06-Sutton.pdf
  30. https://cloud.google.com/blog/topics/threat-intelligence/staying-hidden-on-the-endpoint-evading-detection-with-shellcode/
  31. https://phrack.org/issues/57/15.html
  32. https://phrack.org/issues/62/7.html
  33. https://github.com/wsummerhill/DictionShellcode
  34. https://redsiege.com/blog/2024/04/introducing-delta-encoder/
  35. https://www.offsec.com/metasploit-unleashed/msfencode/
  36. https://www.exploit-db.com/docs/english/13121-shellcoding-for-linux-and-windows-tutorial.pdf
  37. https://www.kernel.org/doc/html/latest/x86/syscall-quickref.html
  38. https://www.virusbulletin.com/virusbulletin/2013/01/shellcoding-arm
  39. https://riscv.org/technical/specifications/
  40. https://www.kernel.org/doc/html/v5.15/arm64/syscalls/index.html
  41. https://www.corelan.be/index.php/2010/02/25/exploit-writing-tutorial-part-9-introduction-to-win32-shellcoding/
  42. https://www.blackhat.com/presentations/bh-usa-08/Sotirov_Dowd/bh08-sotirov-dowd.pdf
  43. https://attack.mitre.org/techniques/T1620/
  44. https://www.usenix.org/legacy/event/sec11/tech/full_papers/Snow.pdf
  45. https://www1.cs.columbia.edu/~angelos/Papers/theses/vpappas_thesis.pdf
  46. https://www.blackhat.com/docs/us-15/materials/us-15-Xenakis-ROPInjector-Using-Return-Oriented-Programming-For-Polymorphism-And-Antivirus-Evasion-wp.pdf
  47. https://samsclass.info/127/proj/ED412.htm
  48. https://www.usenix.org/system/files/conference/usenixsecurity17/sec17-xu-meng.pdf
  49. https://www.sans.org/blog/stack-canaries-gingerly-sidestepping-the-cage/
  50. https://learn.microsoft.com/en-us/windows/win32/secbp/control-flow-guard
  51. https://github.com/ixty/xarch_shellcode
  52. https://rapid7.com/blog/post/2015/03/25/stageless-meterpreter-payloads/
  53. https://d3fend.mitre.org/technique/d3f:DynamicAnalysis/
  54. https://core.ac.uk/download/pdf/325990564.pdf
  55. https://docs.remnux.org/discover-the-tools/dynamically%2Breverse-engineer%2Bcode/shellcode
  56. https://github.com/rshipp/awesome-malware-analysis
  57. https://docs.pwntools.com/en/stable/gdb.html
  58. https://web.mit.edu/gnu/doc/html/gdb_7.html
  59. https://www.elastic.co/guide/en/security/8.19/potential-reverse-shell.html
  60. https://www.juniper.net/us/en/threatlabs/ips-signatures/detail.SHELLCODE:PHP:REVERSE-SHELL.html
  61. https://man7.org/linux/man-pages/man1/strace.1.html
  62. https://d3fend.mitre.org/technique/d3f:SystemCallAnalysis/
  63. https://www.sciencedirect.com/science/article/pii/S1742287619301574
  64. https://sites.cs.ucsb.edu/~chris/research/doc/raid11_shellzer.pdf
  65. https://chaowang-vt.github.io/pubDOC/Li13SymRAS.pdf
  66. https://philarchive.org/archive/KAMDMA
  67. https://cloud.google.com/blog/topics/threat-intelligence/emulation-of-malicious-shellcode-with-speakeasy
  68. https://cwe.mitre.org/data/definitions/416.html
  69. https://www.usenix.org/legacy/event/sec11/tech/full_papers/Schwartz.pdf
  70. https://www.sentinelone.com/blog/eternalblue-nsa-developed-exploit-just-wont-die/
  71. https://blogs.vmware.com/security/2021/12/log-in-the-shell-an-analysis-of-log4shell-exploitation.html
  72. https://web-assets.esetstatic.com/wls/2012/11/Stuxnet_Under_the_Microscope.pdf
  73. https://www.rapid7.com/blog/post/2024/12/04/black-basta-ransomware-campaign-drops-zbot-darkgate-and-custom-malware/
  74. https://www.rapid7.com/blog/post/2025/06/10/blacksuit-continues-social-engineering-attacks-in-wake-of-black-bastas-internal-conflict/
  75. https://www.darkowl.com/blog-content/ethical-hacking-white-hat-hackers-vs-black-hat-hackers/
  76. https://www3.cs.stonybrook.edu/~mikepo/papers/emulation.dimva06.pdf
  77. https://www3.cs.stonybrook.edu/~mikepo/papers/gene.acsac10.pdf
  78. https://dl.acm.org/doi/10.1145/1653662.1653725
  79. https://link.springer.com/article/10.1007/s10515-022-00331-3
  80. https://arxiv.org/abs/2202.09785
  81. https://live.paloaltonetworks.com/t5/community-blogs/introducing-the-new-cortex-shellcode-ai-protection-a-precision/ba-p/591962
  82. https://www.semanticscholar.org/paper/Can-we-generate-shellcodes-via-natural-language-An-Liguori-Al-Hossami/b15fa9e57fb791899154a0f6c321eb703f1c0b09
Add your contribution
Related Hubs
User Avatar
No comments yet.