Article
APT Encounters of the Third Kind: Incident Response Deep Dive
Was als routine Security-Assessment begann, wurde zu einem unvergesslichen Incident-Response-Abenteuer. Igor’s detaillierter Bericht zeigt, wie tief man graben muss, um einen APT zu finden.
Der Auslöser
Ein Security-Assessment für Reverse-Gateways/Load-Balancer eines Unternehmens. Die Gateways:
- 100+ Maschinen ohne internen Storage
- Booten von USB mit monolithischem Kernel und GO-Anwendung
- Die GO-App fungiert als
init-Ersatz und Reverse-Proxy - Mountet NFS-Share für Konfiguration, TLS-Zertifikate, Blacklist-Daten
Klaus (der Kunde) wollte wissen: Kann ein Angreifer PII aus dem entschlüsselten HTTPS-Verkehr extrahieren?
Die Anomalie
Bei der Analyse von Paket-Timing-Histogrammen fiel etwas auf:
- Port 80 (HTTP): Normale Verteilung
- Port 443 (TLS): Power-Law-Verteilung
- PII-relevante TLS-Verbindungen: Signifikant verzerrt und zu längeren Zeiträumen verschoben
Die Test-Setup-Daten stimmten nicht mit den Live-Daten überein.
Die Entdeckung
Über NFS-Traffic-Analyse wurden die Produktions-Konfigurationsdateien extrahiert. Das Ergebnis war alarmierend:
- Ein zweiter NFS-Server war konfiguriert – für eine andere IP
- Ein bösartiges Binary namens
klogwar im System - Der Kernel war gepatcht, um Rootkits zu verstecken
Die GOlang-Komponente
Die Analyse zeigte:
- Eine modifizierte GO-Anwendung, die scheinbar der normalen Gateway-Software entsprach
- Aber: Versteckte Funktionen für Datenexfiltration
- Der gepatchte Kernel verbarg Prozesse und Netzwerkverbindungen
Fazit
Dieser Fall demonstriert, wie tiefgründig Security-Forensik sein kann. Manchmal ist ein scheinbares “Test-Setup-Problem” tatsächlich ein Hinweis auf eine viel größere Kompromittierung.