Remote Code Execution erklärt: Wie Hacker eure Systeme übernehmen

Was ist Remote Code Execution (RCE)?

Remote Code Execution, kurz RCE, beschreibt eine Schwachstelle, bei der Angreifer aus der Ferne beliebigen Code auf einem Zielsystem ausführen können – oft ohne physischen Zugriff oder lokale Systemrechte. Das macht RCE zu einer der gefährlichsten Bedrohungen im Bereich IT‑Sicherheit.

Es gibt typische Angriffswege wie unsichere Deserialisierung, File‑Upload ohne Validierung, Buffer‑Overflows oder unsichere PUT-/POST‑Requests.

Warum ist RCE so kritisch?

Erster Zugang: Angreifer können über RCE Systeme kapern, Web‑Shells installieren, Backdoors einrichten.
Auswirkungen: Datenklau, Ransomware, Kryptomining, lateral movement im Netzwerk – die volle Übernahme.
Aktive Exploits: 2025 gab es mehrere kritische CVEs wie CVE‑2025‑24813 (Apache Tomcat), CVE‑2025‑53770 (SharePoint ToolShell), CVE‑2025‑47812 (Wing FTP) – alle mit aktiver Ausnutzung im Echtbetrieb.

Aktuelle RCE-Beispiele aus 2025

CVE‑2025‑24813 – Apache Tomcat

Ein unsicheres Temp‑File‑Handling bei PUT mit Content‑Range erlaubt es, über PUT-Requests schädliche Session‑Dateien abzulegen, die beim Deserialisieren beim Abruf per JSESSIONID Code ausführen – komplett ohne Authentifizierung.

CVE‑2025‑53770 – Microsoft SharePoint („ToolShell“)

Mehrere Deserialisierungsschwachstellen in SharePoint On‑Prem Komponente ToolPane.aspx ermöglichen unauthentifizierte RCE – Microsoft listet aktive Angriffe, CISA fordert Patch bis August 2025.

CVE‑2025‑47812 – Wing FTP Server

Ein Critical RCE‑Bug erlaubt null‐Byte Injection über Benutzernamen und Ausführung von Lua‑Code beim Session‑Deserialisieren. Root/SYSTEM Zugriff möglich – Angriffe bereits im Einsatz bei Airbus, US‑Air Force und mehr.

Weitere Highlights

Veeam Backup & Replication CVE‑2025‑23120: Domänenuser können systemweit Code ausführen.
WordPress „Contact Form 7“ Plugin CVE‑2025‑3515: unsichere Uploads (.phar) führen zu Codeausführung.
A‑Blog CMS CVE‑2025‑31103: unsichere Deserialisierung und Arbitrary File Upload → RCE.

So funktioniert eine RCE‑Exploitation

typische Angriffsverfahren:

Deserialization Attacks: Unsichere Deserialisierung (SharePoint, WordPress, CMSs).
File‑Upload Schwachstellen: Laden von .php/.phar via unzureichende Prüfung (z. B. WordPress).
PUT/POST‑Exploits: Temp‑File Manipulation oder POCs via HTTP PUT (z. B. Tomcat).
Buffer Overflows, Null‑Byte Injection (z. B. Wing FTP).

Simplified Attack-Flow:

Angreifer identifiziert offene Angriffsfläche (z. B. PUT‑Endpoint, Upload-Funktion).
Craftet Payload: Websocket, Serialized‑Objekt oder .phar mit PHP‑Webshell.
Sendet Request: PUT/POST mit Payload.
Vulnerable Server lädt Datei / deserialisiert das Objekt.
Code läuft mit privilegierten Rechten.
Persistenz: Shell installieren, lateral movement, Logs manipulieren.

Praktisches Beispiel: So funktioniert eine RCE in der Praxis

Damit du besser verstehst, wie ein Remote Code Execution Angriff in der Realität aussieht, nehmen wir ein vereinfachtes Szenario.

Wichtig: Dieses Beispiel ist rein zu Demonstrationszwecken – bitte nicht auf fremde Systeme anwenden!

Szenario

Ein Unternehmen betreibt eine interne Web-App zur Dokumentenverwaltung.

Die App erlaubt PDF-Uploads.
Hochgeladene Dateien werden in /uploads/ gespeichert.
Die App prüft nur die Dateiendung, nicht den tatsächlichen Inhalt.

Schritt 1: Recon – Lücke finden

Ein Angreifer überprüft die Upload-Funktion:

Er lädt eine harmlose test.pdf hoch und merkt:
- Die Datei ist direkt abrufbar unter: https:<span class="hljs-comment">//intranet.example.com/uploads/test.pdf</span>
Das bedeutet: Dateien landen öffentlich abrufbar im Webserver.

Schritt 2: Payload erstellen

Der Angreifer erstellt eine Webshell, konzeptionell als Pseudocode:

# Pseudocode – nur zur Veranschaulichung, nicht ausführbar
parameter = url_parameter_lesen("cmd")
wenn parameter vorhanden:
    ergebnis = betriebssystem_befehl(parameter)
    sende_als_antwort(ergebnis)

Diese Datei speichert er als shell.py.pdf (doppelte Endung) und lädt sie hoch.

Schritt 3: Server verarbeitet die Datei

Der Server prüft nur auf .pdf → Upload erfolgreich.
Die Datei landet in /uploads/shell.py.pdf.
Der Webserver (Apache/Nginx) interpretiert .py vor .pdf → Skript wird ausgeführt!

Schritt 4: Remote Code Execution

Der Angreifer ruft die Datei im Browser auf und gibt einen Befehl mit:

https://intranet.example.com/uploads/shell.py.pdf?cmd=whoami

Ergebnis:

Der Server führt den Befehl aus und gibt www-data zurück.
RCE erfolgreich!

Schritt 5: Ausweitung des Angriffs

Der Angreifer kann nun weitere Befehle ausführen, z. B.

?cmd=cat /etc/passwd
?cmd=powershell Invoke-WebRequest ...

In der Realität folgt jetzt meist:

Persistenz (Backdoor/Shell)
Privilege Escalation (Admin/SYSTEM)
Lateral Movement im Netzwerk

Wie hätte man das verhindern können?

Whitelist von Dateitypen (z. B. nur echte PDFs anhand MIME & Magic Number)
Keine direkte Ausführbarkeit von Uploads im Webroot
Web Application Firewall gegen cmd=‑Parameter

Prävention & Schutzmaßnahmen

Patching & Updates

Installiere Patches für Apache Tomcat (ab Version 11.0.3), SharePoint, Wing FTP, WordPress Plugins etc. sofort.
Microsoft Patch-Tuesday für RDP‑Client (CVE‑2025‑29966) und IE‑Mode (CVE‑2025‑30397) ist essenziell

Sicherheit bei Uploads

Whitelist statt Blacklist: Nur erlaubte Dateitypen zulassen.
Nicht nur MIME‑Type prüfen, sondern Dateiendungen und Content.
Sandboxing oder Quotes für Deserialisierung.

Deserialisierung absichern

Vermeide BinaryFormatter oder unsichere Deserialisierung in .NET.
Nutze sichere Libraries oder manuelle Validierung.
Deaktiviere Legacy APIs oder Workflows (z. B. SharePoint Workflow) wenn unnötig.

Web Application Firewall (WAF) einsetzen

Regeln blockieren POST mit Content‑Type: application/octet-stream auf workflow.aspx, file‑upload‑Pattern, PUT‑Requests etc.

Least Privilege & Auditing

Benutzerrechte beschränken: kein exzessiver ScriptVar‑Zugriff, eingeschränkte Adminrechte.
Logs überwachen: unerwartete PowerShell‑Starts, w3wp.exe Aktivitäten, Anomalien.

Threat Hunting & Incident Response

Suche nach Indicators of Compromise (IOC): ungewöhnliche POSTs, geteilte Payloads, unbekannte Prozesse wie cmd.exe oder powershell.
Entferne kompromittierte Systeme – Patch plus Forensik falls schon Exploits erfolgten.

Sicherheitsbewusstsein im Team

Entwickler schulen: sichere Deserialisierung, Input-Validierung, sichere Upload-Handling.
Admins sensibilisieren: keine RDP‑Verbindungen zu unbekannten Servern (besonders RDP‑Client CVE‑2025‑29966)

Fazit

Remote Code Execution ist kein theoretisches Risiko – 2025 zeigen zahlreiche aktive Exploits (Tomcat, SharePoint, FTP‑Server, WordPress), wie verwundbar Systeme noch sind. In deinem Unternehmen solltest du:

schnell patchen,
unsichere Uploads und Deserialisierung vermeiden,
WAF‑Regeln nutzen,
Zugriffsrechte minimieren,
laufend Logs überwachen.

Mit soliden Schutzmaßnahmen kannst du RCE‑Angriffe effektiv verhindern und die Sicherheit deiner Systeme deutlich steigern.

Bleib sicher – und nicht gehackt! 😎