Netwrix 1Secure bietet einheitliche Sichtbarkeit über Daten und Identität – 14 Tage kostenlos mit vollem Zugriff.Starten Sie eine kostenlose Testversion

Ressourcen­zentrumBlog

Was ist Remote Code Execution (RCE)? Wie KI die Ausnutzung beschleunigt und wie man den Schaden begrenzt

Was ist Remote Code Execution (RCE)? Wie KI die Ausnutzung beschleunigt und wie man den Schaden begrenzt

Oct 19, 2026

Remote Code Execution (RCE) ermöglicht es einem Angreifer, Befehle auf einem System auszuführen, das ihm nicht gehört, meist durch eine Schwachstelle in einer Webanwendung, einem CMS, VPN-Portal oder einer API. Ein erfolgreicher Exploit übernimmt die Berechtigungen des verwundbaren Dienstes, und viele Dienste laufen mit weit mehr Zugriffsrechten als nötig. KI verkürzt die Zeit von der Offenlegung einer Schwachstelle bis zu einem funktionierenden Exploit und ermöglicht Angreifern, Tausende exponierte Systeme gleichzeitig zu testen.

Eine Schwachstelle bei der Remote-Code-Ausführung verwandelt einen verwundbaren Server in den Computer einer anderen Person. Der Angreifer sendet Eingaben, die die Anwendung hätte ablehnen sollen, und die Anwendung führt sie als Befehl aus. KI beschleunigt die Teile dieser Arbeit, die früher Echtzeit des Angreifers erforderten.

Was ist Remote Code Execution (RCE)?

Remote Code Execution ist eine Klasse von Schwachstellen, die es einem Angreifer ermöglicht, eigenen Code oder Befehle auf einem Zielsystem über ein Netzwerk ohne vorherigen Zugriff auszuführen. Man nennt es auch willkürliche Codeausführung. In jedem Fall bestimmt der Angreifer, was die Maschine tut. Eine RCE-Schwachstelle entsteht meist durch eine Anwendung, die nicht vertrauenswürdige Eingaben in etwas einspeist, das sie ausführt: einen Shell-Befehl, eine Vorlage, ein deserialisiertes Objekt, einen Datei-Upload-Handler. Der RCE-Exploit ist die spezifische Eingabe oder Sequenz, die die Schwachstelle auslöst.

Wie die Remote-Code-Ausführung funktioniert

Der Angriff verläuft normalerweise geradlinig. Der Angreifer findet ein exponiertes System mit einer verwundbaren Komponente, sendet speziell gestaltete Eingaben und bringt Code unter dem Dienstkonto zum Laufen. Die erste Nutzlast bleibt klein, meist eine Web-Shell oder ein Befehl, der etwas herunterlädt. Größere Werkzeuge folgen, nachdem der Angreifer bestätigt hat, dass der Zugriff funktioniert.

Log4Shell (CVE-2021-44228) ist ein gutes Beispiel dafür, wie weit eine einzelne Schwachstelle reichen kann. Im Dezember 2021 in der Apache Log4j-Logging-Bibliothek bekanntgegeben, ermöglichte sie es, dass eine speziell gestaltete Zeichenkette in einem protokollierten Feld einen verwundbaren Server dazu brachte, vom Angreifer kontrollierten Code abzurufen und auszuführen. Log4j war in so vielen Anwendungen eingebettet, dass der Fehler überall auftauchte.

Die meisten RCE-Fehler beginnen klein. Die erste Funktion unten übergibt Benutzereingaben direkt an eine Shell. Die zweite verwirft die Shell und validiert die Eingabe.

      # Vulnerable: input goes straight to a shell
import os
def ping(host):
    os.system("ping -c 1 " + host)   # host = "8.8.8.8; id" runs a second command

# Safer: no shell, validated input
import ipaddress, subprocess
def ping(host):
    ipaddress.ip_address(host)        # raises ValueError unless host is an IP
    subprocess.run(["ping", "-c", "1", host], check=True)

      

Wie KI Angriffe mit Remote-Code-Ausführung verändert

Die Schwachstellenklasse ist alt. Angreifer haben die Geschwindigkeit geändert, mit der sie jede Phase durchlaufen können.

Ziele werden eingestuft

Internet-weite Scans gibt es seit Jahren. KI hilft bei der Sortierung: Scan-Ergebnisse können nach Software und Version gruppiert und danach bewertet werden, wie wahrscheinlich es ist, dass jedes System eine bekannte Schwachstelle hat, sodass Angreifer zuerst die besten Kandidaten angreifen.

Patches werden zu Exploit-Anleitungen

Anbieter veröffentlichen Patches und Hinweise, um Verteidiger zu unterstützen, und Angreifer lesen sie ebenfalls. Ein Modell kann einen Patch-Diff oder Hinweis nehmen und den verwundbaren Codepfad beschreiben, was die Reverse-Engineering-Arbeit reduziert und die Zeit zwischen öffentlicher Bekanntgabe und funktionierendem Exploit verkürzt.

Ein Proof of Concept, viele Versionen

Ein öffentliches Proof of Concept richtet sich normalerweise auf eine Version oder ein Framework. Modelle können es auf eine andere Version oder Sprache übertragen und die Nutzlast ändern, um ein bekanntes Erkennungsmuster zu umgehen.

Mehrstufige Angriffe erfordern weniger Fähigkeiten

Viele Webangriffe laufen in zwei Phasen ab. Eine kleine Injektion beweist, dass Code ausgeführt wird, dann lädt ein zweiter Schritt größere Werkzeuge herunter. Modelle können diese Kette entwerfen und bei einem Fehlschlag einer Phase mit Änderungen erneut versuchen, sodass mehrstufige Angriffe gegen ein CMS, eine API oder ein Portal weniger Können erfordern als früher.

Die Nachbearbeitung läuft über ein Skript

Nach dem Ausführen des Codes ist die Nachbereitung repetitiv: Konfigurationsdateien lesen, Schlüssel und Anmeldedaten sammeln, eine geplante Aufgabe erstellen, damit der Zugriff einen Neustart übersteht, und nach benachbarten Systemen suchen. Skript- und KI-unterstützte Routinen führen diese Schritte jedes Mal auf dieselbe Weise aus.

Die gleiche Kette, Hunderte von Organisationen

Eine Kette, die gegen eine Organisation funktioniert, kann gegen Hunderte gerichtet werden. Jede vorherige Stufe nährt die nächste, und jedes zusätzliche Ziel kostet den Angreifer weniger als das vorherige.

Stage

Traditional RCE attack

AI-assisted RCE attack

Finding targets

Manual review of scan results

Results grouped by software and version and ranked by likelihood of a known flaw

Understanding the flaw

Slow, specialist reverse engineering of a patch

Patch diff or advisory summarized into a description of the vulnerable code path

Building the exploit

Written from scratch or copied as-is from a public proof of concept

Proof of concept adapted to a new version, framework, or language

Multi-stage attacks

Planned and tested by hand

Chains drafted and retried automatically when a stage fails

After access

Operator reads files and runs commands one at a time

Configs, keys, and credentials collected by scripted routines

Scale

A few targets per operator

The same chain run against hundreds of organizations

Defender window

Time between disclosure and exploitation gives teams room to patch

Less time to patch after disclosure

Was Angreifer in den ersten Minuten nach einem RCE-Exploit tun

Die ersten Schritte nach einem erfolgreichen Exploit folgen einem Muster. Angreifer legen eine Web-Shell oder einen Loader in ein Verzeichnis, in das der Dienst schreiben kann, und fügen dann eine geplante Aufgabe, einen Dienst oder einen Cron-Job hinzu, damit der Zugriff einen Neustart überlebt. Als Nächstes ziehen sie credentials und Schlüssel aus Konfigurationsdateien und dem Speicher und beginnen, benachbarte Systeme zu sondieren.

Jeder Schritt hinterlässt eine Spur, die Sie überprüfen können. Diese Befehle zeigen kürzliche Dateiänderungen im Web-Root und neue Cron-Einträge unter Linux an.

      # Files changed in the web root in the last 24 hours
find /var/www -type f -mtime -1 -ls

# Recently modified cron entries
ls -lt /etc/cron.d /var/spool/cron 2>/dev/null | head
      

Unter Windows listet diese Abfrage geplante Aufgaben auf, die im letzten Tag registriert wurden. Aktivieren Sie zuerst das Betriebsprotokoll des Taskplaners, da es standardmäßig deaktiviert ist.

      Get-WinEvent -FilterHashtable @{
  LogName   = 'Microsoft-Windows-TaskScheduler/Operational'
  Id        = 106
  StartTime = (Get-Date).AddDays(-1)
} | Select-Object TimeCreated, Message
      

Manuelle Prüfungen wie diese funktionieren auf einem Server. Bei Hunderten von Systemen kommen sie nicht nach, und ein schneller Angreifer kann vor der nächsten geplanten Überprüfung fertig sein.

Wie man Remote-Code-Ausführung verhindert und den Schaden begrenzt

Patching und sichere Eingabeverarbeitung sind weiterhin die Hauptabwehr gegen eine RCE-Schwachstelle. Alles danach geht davon aus, dass eine Schwachstelle vor dem Patch ausgenutzt wird, daher liegt das Ziel darin, Änderungen schnell zu erkennen und zu begrenzen, was ein kompromittierter Dienst tun kann.

Netwrix Change Tracker überwacht die Systeme, die von einem RCE-Angriff betroffen sind. Es legt Konfigurations-Baselines fest und verwendet die Überwachung der Dateiintegrität, um neue oder geänderte Dateien zu kennzeichnen, wie z. B. ein Web-Shell, das zu einem Webverzeichnis hinzugefügt wurde, sowie Änderungen an kritischen Systemdateien und Einstellungen auf Windows-, Linux-, Unix- und Netzwerkgeräten. Sein Modell für geplante Änderungen vergleicht das Beobachtete mit genehmigten Änderungsanträgen, sodass eine nicht geplante Änderung zur Überprüfung markiert wird. Die Änderungsverlauf gibt Ermittlern eine Zeitachse, und die Authentifizierung von Systemdateien überprüft Dateien anhand globaler Reputationsdatenbanken, um zu bestätigen, welche vertrauenswürdig sind.

Netwrix PolicyPak begrenzt, was ein Angreifer tun kann, sobald Code auf einem Windows-System ausgeführt wird. Least Privilege entfernt lokale Administratorrechte und legt Erhöhungsregeln für Standardbenutzer fest, sodass ein kompromittierter Prozess weniger Berechtigungen hat. Mit PolicyPak können Sie Anwendungen und Skripte blockieren, wenn deren Dateibesitzer nicht zuvor auf der Whitelist standen.

Lokale Administratorrechte mit PolicyPak entfernen

Kostenlos testen

Checkliste zur Verhinderung der Remote-Code-Ausführung

  1. Patchen Sie internetexponierte Software nach einem definierten Zeitplan, beginnend mit CMS-Plattformen, VPN-Portalen und APIs.
  2. Validieren und bereinigen Sie Eingaben und halten Sie Benutzereingaben von Shells, Vorlagen und Deserialisierern fern.
  3. Führen Sie Dienste mit geringsten Rechten aus und entfernen Sie lokale Administratorrechte dort, wo sie nicht benötigt werden.
  4. Überwachen Sie Webverzeichnisse, kritische Dateien und Konfigurationen auf ungeplante Änderungen.
  5. Blockieren Sie die Ausführung nicht vertrauenswürdiger Anwendungen und Skripte auf Windows-Systemen.
  6. Behalten Sie eine durchsuchbare Änderungsverlauf, damit Untersuchungen mit einer Zeitleiste beginnen.

FAQs

Teilen auf

Erfahren Sie mehr

Über den Autor

Asset Not Found

Jarosław Bogalecki

Produktmanager

Jarosław Bogalecki ist Produktmanager bei Netwrix, verantwortlich für PolicyPak und Password Policy Enforcer. Er arbeitet seit 2019 in technischen Rollen und begeistert sich für Produktstrategie, KI und die Entwicklung von Lösungen für reale Kundenprobleme. Vor dem Product Management war er in Application Engineering und technischer Beratung tätig.