Verifikation · mit Beweis

Active Exploitation (RCE-Verifikation)

Ein Scanner sagt „verwundbar“, Active Exploitation beweist es. In streng abgestuften Modi wird eine Schwachstelle kontrolliert ausgenutzt, um ihre tatsächliche Wirkung nachzuweisen – ohne Kollateralschaden. Jeder Versuch ist an eine explizite Autorisierung gebunden und vollständig auditiert.

Kostenlosen Scan starten Tarife & Preise

Verfügbar ab Tarif Enterprise.

Nur bei aktivem allowActiveExploitation; reverse_shell erfordert ein zweites Opt-in.

Was geprüft wird

Diese Aspekte deckt der Active Exploitation ab – konkret und nachvollziehbar.

oob_only: Out-of-Band-Callback (DNS/HTTP) belegt die Verwundbarkeit ohne Befehlsausführung
command_proof: read-only-Befehl (id, hostname), stdout als Beweis
reverse_shell: interaktiver Listener – nur mit zweitem, explizitem Opt-in
Exploit-Library: log4shell, spring4shell, java_deserialization, ssti, cmd_injection
Automatisches Matching passender Findings auf verfügbare Exploits
Erfassung jedes Versuchs als ExploitSession mit vollständigem Command-Audit

Dein Nutzen

Was dir der Active Exploitation konkret bringt – über die reine Technik hinaus.

Schluss mit Diskussionen

Ein konkreter Beweis beendet die Debatte, ob ein Befund „nur theoretisch“ ist – das beschleunigt Priorisierung und Freigabe der Behebung enorm.

Abgestufte Eskalation

Vom harmlosen Out-of-Band-Callback bis zur interaktiven Shell – du bestimmst, wie weit getestet wird, jeder Schritt mit eigenem Opt-in.

Kein Kollateralschaden

Read-only-Beweise und enge Grenzen sorgen dafür, dass die Verifikation belegt, ohne Systeme zu gefährden.

Lückenloser Nachweis

Jeder Befehl und jede Session landen im Audit-Trail – ideal für Compliance und interne Freigabeprozesse.

So läuft es ab

1
Voraussetzung prüfen
Active Exploitation läuft nur, wenn das Engagement allowActiveExploitation gesetzt hat.
2
Finding matchen
Der Dispatcher ordnet passende Findings einem Eintrag der Exploit-Library zu.
3
Modus wählen
Von oob_only über command_proof bis reverse_shell – mit jeweils erforderlichem Opt-in.
4
Beweis & Audit
Das Ergebnis wird als ExploitSession mit allen Befehlen revisionssicher protokolliert.

Typische Befunde

Log4Shell mit bestätigter Befehlsausführungkritisch
Java-Deserialisierung führt zu RCE (command_proof)kritisch
SSTI mit Out-of-Band-Callback verifizierthoch
Command-Injection mit read-only-Beweishoch

Beispielhafte Befundkategorien. Tatsächliche Ergebnisse hängen von deiner Umgebung ab.

Einsatzszenarien

Eindeutiger Nachweis kritischer Schwachstellen für schnelle Freigaben
Validierung von N-Day-Exposition bei akuten Bedrohungen
Belastbare Beweisführung für Management und Auditoren
Qualitätssicherung automatisierter Befunde vor der Eskalation

Häufige Fragen

Ist das gefährlich für meine Systeme?

Die Standardmodi sind bewusst schonend: oob_only führt keinerlei Befehle aus, command_proof nur harmlose read-only-Kommandos. Die interaktive Shell ist ein bewusster, doppelt bestätigter Sonderfall.

Wer darf das auslösen?

Nur innerhalb eines Engagements mit aktivem allowActiveExploitation. reverse_shell verlangt zusätzlich ein zweites, explizites Opt-in.

Wird alles dokumentiert?

Ja. Jeder Versuch wird als ExploitSession inklusive aller ExploitCommands im append-only Audit-Trail festgehalten.