Reverse / Bind Shells (Lab)

# RULES OF ENGAGEMENT (READ FIRST)
# - Authorised testing only. Written scope, target list, allowed techniques, blackout windows.
# - No real customer data. Use synthetic data or a sandboxed copy.
# - No DoS, no destructive actions, no detection evasion against systems you do not own.
# - All examples below run inside the bundled lab VM (./shell-lab). Do not point them anywhere else.
# - Coordinate with the SOC / blue team so legitimate alerts are not mistaken for an incident.
# - Capture evidence (timestamps, source IPs, commands run) for the engagement report.

# ===== Shell taxonomy (for the report, not for the wild) =====
# - Reverse shell: target initiates outbound to attacker (bypasses inbound firewalls)
# - Bind shell:    target listens; attacker connects in
# - Web shell:     code planted in a web app that executes attacker-supplied commands
# - Living off the land: built-in tools (powershell, bash, certutil, curl) used as shells

# ===== What a reverse-shell beacon looks like on the wire =====
# - Outbound TCP to an unusual port (4444, 1337, 8443)
# - Long-lived connection, low data volume, periodic keepalive
# - TLS to a domain with no prior history
# - User agent absent or generic

# ===== What a web shell looks like =====
# Hallmarks: a single .php / .jsp / .aspx file that:
# - Reads a parameter named 'cmd', 'c', 'x', 'q'
# - Executes it via system(), exec(), passthru(), Runtime.exec()
# - Lives in an upload directory or in a recently-modified file
# - Has high entropy or base64-encoded payload near the top

# Detection rule (Wazuh / Sigma style, simplified):
#   if file under /var/www and modified in last 24h and matches /(system|exec|passthru|popen)\s*\(/i
#   then: alert HIGH, isolate file, preserve, page on-call

# ===== Hardening (the part you actually ship) =====
# 1. Egress controls
#    - Default-deny outbound from app servers; allowlist registries + APIs
#    - Log every blocked egress attempt; alert on bursts
# 2. Process lineage
#    - Web server should never spawn /bin/sh, /bin/bash, powershell.exe
#    - EDR rule: alert if w3wp.exe or nginx forks a shell
# 3. Filesystem invariants
#    - Web roots are read-only at runtime; deploys go through a separate path
#    - File integrity monitoring (auditd / FIM) on document root
# 4. WAF + upload controls
#    - Reject executable content-types; verify magic bytes server-side
#    - Move uploads to a scanned bucket; only render after scan-clean
# 5. Auth + segmentation
#    - SSH keys only; admin segments isolated from app egress paths
# 6. Patching cadence
#    - CVE feed to ticket queue; SLAs on patch time for internet-facing services

# ===== Tabletop drill (do this quarterly) =====
# Scenario: a web shell at /var/www/uploads/x.php
# Steps to rehearse:
#   1. Detect: how would the alert fire? (FIM rule, EDR, egress beacon)
#   2. Triage: who pages? what info is in the first alert?
#   3. Contain: isolate host, snapshot disk, preserve memory
#   4. Eradicate: rebuild from known-good image
#   5. Recover: re-onboard with patched stack
#   6. Lessons: what would have caught it earlier?

# ===== Reporting template =====
# Engagement: <client>, <scope>, <dates>
# Finding: <one-liner>
# Evidence: <screenshots / pcap excerpts / timestamps>
# Reproduction: <steps in the lab; not against prod>
# Recommendation: <hardening change>
# Severity: <CVSS or CWSS scored>
# Verification: <how the client tests the fix>

# ===== Patterns to internalise =====
# - Defense-first: every offensive technique earns a detection rule + a hardening control in the report
# - Authorise everything in writing before any keystrokes
# - Lab on your own VM; never on prod or third-party services without scope
# - Report mindset: would your blue team thank you for the section, not be angry at it?

# ===== Pitfalls =====
# - Demoing reverse shells outside scope (legal risk, contract breach)
# - Sharing payloads publicly without redacting hostnames + tokens
# - Skipping the hardening side -> report reads as a brag sheet, not a deliverable
# - No SOC coordination -> your test triggers a real incident page at 3am

# Reverse vs bind shells — fundamental network concepts.
# Reverse: target connects out to you (works through outbound firewalls).
# Bind:    target listens, you connect to it.
# Practice in LAB or HTB / THM rooms — never on production systems.