NT-Forensik v3.2.0 — maschinenlesbarer findings.json-Export

Jeder Forensik-Lauf schreibt zusätzlich findings.json — einen maschinenlesbaren Export aller Befunde.

Inhalt

• run_id, Host, Domain, Zeitstempel
• Verdikte (root/wpdb) + Zähler (crit/warn/ok) + Metriken (Webshells, WP-Installs, SSH-Fehlversuche, Domains)
• actionable: Webshell-Dropper, PHP-in-Uploads, SUID, tmp-Executables, Immutable, verdächtige Cron/systemd, Persistenz, Prozesse, WP-Configs, Fremd-SSH-Keys, IOC-IPs (Angreifer + Brute-Force)

Eigenschaften

• Reines Bash-JSON — kein jq-Zwang, läuft auf minimalen Servern.
• In SHA256-Versiegelung + Übergabe-Archiv aufgenommen (Chain-of-Custody).
• Leere Kategorien = [].

Dient als sauberer Vertrag für nachgelagerte Remediation-Werkzeuge. Beispiel: examples/findings.json.

NT-Forensik v3.1.0 — DSGVO-Meldung (Art. 33) als vierter Bericht

Neuer, vierter Bericht pro Lauf: dsgvo_meldung.md — eine vorausgefüllte Datenschutz-Meldung nach Art. 33 DSGVO.

Warum

BSI-Meldung und Datenschutz-Meldung sind getrennte Meldewege an verschiedene Stellen (BSI-Portal vs. Datenschutz-Aufsichtsbehörde des Bundeslandes). Bisher deckte das Tool nur die BSI-Seite ab. Auf fast jeder WordPress-Seite liegen personenbezogene Daten — nach einem Einbruch greift daher meist zusätzlich die 72-Stunden-Frist des Art. 33 DSGVO.

Inhalt der DSGVO-Meldung

• Meldepflicht-Einschätzung 🔴/🟠/🟢, maschinell aus Befundlage + WordPress-Betroffenheit abgeleitet.
• Pflichtinhalte nach Art. 33 Abs. 3 (lit. a–d): Art der Verletzung, betroffene Personen/Datensätze, wahrscheinliche Folgen, ergriffene/vorgeschlagene Maßnahmen.
• Betroffene Datenquellen (WordPress-DBs) vorbefüllt; Datenkategorien/Betroffenenzahl als klar markierte Felder für den Verantwortlichen.
• Hinweise zu Frist (≤ 72 h), Verzögerungsbegründung, Art. 34 (Betroffenenbenachrichtigung), Art. 33 Abs. 5 (Dokumentationspflicht).
• Eindeutige Abgrenzung: eigener Meldeweg, nicht ans BSI.

Rechtsstand

Fristen und Inhalte gegen den aktuellen Stand geprüft (NIS2-Umsetzungsgesetz seit 06.12.2025 in Kraft; DSGVO Art. 33 unverändert). Beispiel: examples/dsgvo_meldung.md.

Alle Meldungs-Entwürfe ersetzen keine Rechtsberatung — vor Versand fachlich prüfen.

Vollständige Doku: Handbuch · Lizenz MIT.

NT-Forensik v3.0.0 — WordPress & Rootserver Incident-Response

NT-Forensik ist ein read-only Bash-Skript für die forensische Analyse kompromittierter WordPress/Plesk-Server. Ein Lauf sichert alle Logs, untersucht das System in 13 Abschnitten und erzeugt Kunden-, BSI- und Technik-Bericht mit SHA256-versiegelten Belegen.

Aus der Praxis unserer WordPress-Betreuung & Absicherung.

Neu in 3.0.0

• 📖 Vollständige Dokumentation: Handbuch, Erkennungs-Referenz, Incident-Response-Playbook.
• 🎨 Branding: Hero-Banner, Logo, verlinkte WordPress-Leistung im README und im Kundenbericht.

Kernfunktionen

• Erkennt obfuskierte Cookie-Backdoors, an denen Signaturscanner scheitern: Variable-Variable-Superglobale (${$a.$b.$c} → _COOKIE) + mixed-case EvaL(base64_decode(...)), case-insensitive.
• Zweistufige Webshell-Bewertung (Dropper vs. Framework-eval) mit False-Positive-Filtern.
• Prozess- & Persistenz-Forensik: Miner, gelöschte Binaries, Reverse-Shells, systemd-Units, ld.so.preload, SUID, Immutable-Flags.
• WordPress-Datenbank-Prüfung: fremde/neue Admins, manipulierte Optionen, aktive Plugins.
• Root-/Eskalations-Prüfung mit konsolidiertem Verdikt (Web-User-Ebene vs. Root-Übernahme).
• Fertige Berichte (Kunde, BSI, Technik) + Chain-of-Custody-Belege.

Verwendung

scp wp_plesk_forensik.sh root@SERVER:/root/
ssh root@SERVER "bash /root/wp_plesk_forensik.sh kundendomain.tld"

Beispielberichte mit fiktiven Daten: examples/ · Lizenz MIT.

Nur auf eigenen oder ausdrücklich betreuten Systemen einsetzen.

NT-Forensik v2.9.0 — WordPress/Plesk Incident-Response

Erste öffentliche Veröffentlichung von NT-Forensik — einem read-only Bash-Skript für die forensische Analyse kompromittierter WordPress/Plesk-Server.

Ein Lauf sichert alle Logs, untersucht das System in 13 Abschnitten und erzeugt drei fertige Dokumente plus SHA256-versiegelte Belege (Chain-of-Custody).

Highlights

• Erkennt obfuskierte Cookie-Backdoors, an denen Signaturscanner scheitern: Variable-Variable-Superglobale (${$a.$b.$c} → _COOKIE) und mixed-case EvaL(base64_decode(...)), case-insensitive.
• Zweistufige Webshell-Bewertung — kleine Obfuskations-Dropper (kritisch) vs. große Framework-Dateien mit legitimem eval (Review), getrennt per Dateigröße. Filtert Theme-Iconfonts, WP-Guards und Framework-eval als False Positives.
• Prozess- & Persistenz-Forensik — gelöschte Binaries, Krypto-Miner, Reverse-Shells, systemd-Units, ld.so.preload, at-Jobs, SUID, Immutable-Flags.
• WordPress-Datenbank-Prüfung (§11) — fremde/neue Admin-Konten, manipulierte Optionen (siteurl/auto_prepend/eval), aktive Plugins. Read-only, nutzt Plesk-Admin-Zugang.
• Root-/Eskalations-Prüfung (§12) — Root-Login-IPs & Auth-Methode, Fremd-SSH-Keys, Privilege-Escalation, dpkg -V-Binärintegrität → konsolidiertes Root-Verdikt (auf Web-User-Ebene begrenzt vs. Root nicht ausgeschlossen).
• Fertige Berichte — Kundenbericht (Ampel, Sofortmaßnahmen mit 24h/72h-Fristen, auto-gefüllter Angriffshergang), BSI-Meldung (BSIG/NIS2-Struktur, Kennzahlen, IOCs), technischer Vollbericht.
• Changelog-Abgleich (§1.6) — gleicht Befunde gegen /root/changelog.md (dokumentierte Wartung) ab.

Enthalten

• wp_plesk_forensik.sh — das Tool
• examples/ — vollständige Beispielberichte mit fiktiven Daten (RFC-5737-IPs, example-Domains)
• docs/runbook.md — Runbook für manuelle Ad-hoc-Analyse
• CHANGELOG.md

Verwendung

scp wp_plesk_forensik.sh root@SERVER:/root/
ssh root@SERVER "bash /root/wp_plesk_forensik.sh kundendomain.tld"

Nur auf eigenen oder ausdrücklich betreuten Systemen einsetzen. Read-only bzgl. Webspace; schreibt nur nach /root/wartungsscripte/.

Voller Funktionsumfang: siehe README · Lizenz MIT.