Day after Verschlüsselungstrojaner: Kann ich dem SAP noch vertrauen?
Autor: Christoph Nagy | 18. März 2020
Immer wieder werden Unternehmen Opfer von Verschlüsselungstrojanern, Tendenz steigend. Es wird viel über das Wiederaufsetzen der Clients gesprochen. Aber wie findet man in der Hektik nach dem GAU nachträglich heraus, ob das SAP System nicht durch ausgespähte Zugangsdaten kompromittiert wurde?
Infiltration über Monate
Natürlich sollte man – wenn möglich – auf konsistente Backups zurückgreifen bei der Wiederherstellung. Aber aktuelle Generationen von Kryptotrojanern haben einen langen Zeitraum von Infektion bis zum tatsächlichen Ausbruch. Oft wird über Monate das System ausgespäht und weiter infiziert, wie das Beispiel der Stadtverwaltung von Neustadt am Rübenberge zeigt.
Wenn sich das Chaos also lichtet, und vielleicht auch Erleichterung einkehrt, dass zwar sämtliche Windows-PCs neu installiert werden müssen aber (ja, feiert das nur) die Linux-Server inklusive SAP überlebt haben, kommt beim Nachdenken schnell Ernüchterung. Denn im „Standardpaket“ des Leistungsumfangs von Emotet & Co. sind Keylogger die Zugangsdaten abgreifen und an die Command & Control-Server und ihre Herren darüber zurückmelden. Über Remote-Shells bekommen dieser Zugang zu allen Systemen und Servern, die von Clients erreichbar waren. Eben auch dem laufenden SAP – an dem ich mich zwar wieder fehlerfrei anmelden kann – aber wo keiner weiß, was in den sechs Monaten zwischen Infektion und Ausbruch alles passiert ist.
Spurensuche im SAP am Tag danach
So auch bei einem Kunden, dem wir geholfen haben, eine Integritätsprüfung im SAP zu machen. Bei dem Unternehmen gab es einen großflächigen Kryptoangriff, und es wurde vermutet, dass auch der Zugriff auf das SAP System möglich war.
Grundsätzlich stecken Anmeldeinformationen und ungewöhnliche Aktivitäten in den Logs – z.B. den SAP Security Audit Log im Filesystem, aber natürlich auch in Änderungsbelegen innerhalb von SAP. Die Systeme in der Landschaft hatten eine vollständige Security Audit Log Konfiguration, trotzdem war die Herausforderung groß, viele verteilte Log Dateien und Informationen wieder zu einem Gesamtbild zu verknüpfen.
Die Idee zur 1:1 Übertragung in externe Log Management Lösungen wurde schnell verworfen, da die Log-Einträge nur durch vorherige Übersetzung, Normierung und Anreicherung in ein bewertbares Format zu bringen sind. Ein Beispiel – Die Bedeutung der SAL- Meldungen „Logon Failed (Reason = 1, Type = A)“ verhindert die sinnhafte Bewertung.
Beispiel aus SAP Security Audit Log
Übersetzt bedeutet die Meldung: „Die Dialog-Anmeldung war aufgrund von inkorrekten Anmeldedaten (Benutzer/Kennwort) nicht möglich“. Wichtige Zusatz Information wie z.B., dass der Account im Benutzerstamm des SAP Systems nicht existiert gehen aus dem Logeintrag nicht hervor.
Software-gestützte Forensik in Eigenregie
Um ein möglichst vollständiges Gesamtbild zu schaffen, wurden innerhalb von drei Tagen alle Log-Informationen von den Produktiv-Mandanten normiert, angereichert und in eine ebenfalls von uns installierte Auswertungsapplikation übernommen. Dazu gehörten das Security Audit Log, Gateway Logs, Änderungsbelege, DB Audit Log und weitere Kommunikationslogs.
Schon nach kurzer Einarbeitung konnten die Mitarbeiter selbstständig, dank der konsolidierten Sicht in unserer Softwarelösung, typische Angriffsmuster suchen. Zum Beispiel der Download von Tabelleninhalten, der Aufruf von betriebssystemnahen Funktionen oder die Manipulation von Änderungsbelegen. Glücklicherweise konnten alle Verdachtsfälle aufgeklärt werden, dadurch konnte das Vertrauen in das SAP wiederhergestellt werden.
Hilfe vor und nach dem Störfall
Das Rz10 Netzwerk hilft Unternehmen bei der Überprüfung und Absicherung von SAP Systemen. Benötigen Sie Unterstützung oder haben Sie Fragen? Jetzt unverbindlich informieren.
Erkenntnisse und Ausblick
Für die Zukunft wird die Protokollierung des SAP Systems noch mehr auf die Unterstützung von Integritätsprüfungen optimiert, damit im Fall des Falles noch schneller und leichter eine forensische Analyse ausgeführt werden kann. Wäre keine Protokollierung aktiviert gewesen, wäre eine nachträgliche Untersuchung nicht möglich gewesen. Daher auch meine Empfehlung:
- unbedingt das Security Audit Log anschalten dabei
- so wenig wie möglich filtern und
- die Logs möglichst lange, jedoch mindestens 1 Jahr aufheben
