•  

Bedeutung von Emotet-Vorfällen für Energieunternehmen

Im Juni 2019 machte der Heise-Verlag einen massiven Angriff mittels der Schadsoftware Emotet im eigenen Haus öffentlich und nannte auch Details zu den internen Auswirkungen und dem Umgang damit. Grund genug für uns, die bekannt gewordenen Informationen auszuwerten und ihre exemplarische Bedeutung für die Bedrohungslage von Energieversorgungsunternehmen (EVU) in Deutschland zu betrachten. Anders als der Heise-Verlag müssen diese nicht nur ihren eigenen Betrieb, sondern auch die Versorgungssicherheit berücksichtigen. Die Vermutung liegt deshalb nahe, dass die vom Heise-Verlag veröffentlichte interne Vorfallsreaktion nicht unmittelbar auf EVUs übertragbar ist und sogar unerwünschte negative Folgen haben könnte. Inwieweit die Erkenntnisse trotzdem hilfreich für Energieunternehmen sein könnten, soll im Folgenden beleuchtet werden. Zunächst wird der Artikel die Schadsoftware Emotet charakterisieren, den Umgang damit beim Heise-Verlag beleuchten und eine Einordnung in anerkannte Best Practices des Sicherheitsvorfallsmanagements (engl. Security Incident Management) vornehmen. Die für EVUs spezifische Bedrohungslage und die daraus resultierenden Handlungsfelder und Schnittstellen werden im zweiten Teil des Artikels dargestellt.

Emotet begann ursprünglich als Banking-Trojaner, d.h. auf einem infizierten System liest und manipuliert er die „sicheren“ Verbindungen zu Banken und kann Zugangsdaten abgreifen und unautorisierte Transaktionen ausführen. Er wurde erstmalig im Jahr 2014 von Trend Micro entdeckt und benannt.

Worin unterscheidet Emotet sich nun von den zahlreichen ähnlichen Vertretern an Schadprogrammen? Hauptsächlich in seinem Erfolg. Er wird fortlaufend weiterentwickelt, die Schadmechanismen sind geografisch zielgerichtet (z.B. erst deutsche und österreichische Banken, später schweizerische) und er besitzt die Fähigkeit, nach erfolgreicher Infektion weitere Funktionsmodule nachzuladen. Dazu benötigt er einen Zugriff auf sogenannte C&C-Server (Command and Control) im Internet. Über diese Server steuern die Angreifer Bots, laden neue Schadsoftware-Varianten auf befallene Systeme oder Applikationen, spähen Informationen aus und aktivieren weitere Schadens- und Verbreitungsfunktionen, z.B. Ransomware, Erpressungs-Trojaner, Brute-Force-Login-Versuche, sowie an das Angriffsziel individuell angepasste Phishing-Mails, um die weitere Ausbreitung voranzutreiben. Die Angriffstechniken sind damit variabel, mehrstufig und zeitlich verteilt. In Sicherheitskreisen hat sich dafür die Abkürzung APT (Advanced Persistant Threads) eingebürgert. Wer tiefer in die Evolution und Funktion des Emotet-Schadprogrammes eintauchen möchte, findet unter https://de.securelist.com/banker-emotet-evolution-einer-bedrohung/59222/  einen umfangreichen Bericht.

Wie arbeitet aber nun der derzeit bekannte Emotet:


Abbildung-1: Arbeitsweise von Emotet

Das wichtigste vorweg: Eine Erstinfektion benötigt, soweit bekannt, eine Beteiligung des Anwenders. Der Hauptverbreitungsweg sind Emails, mit denen der Anwender dazu gebracht werden soll, einen Anhang auszuführen, bzw. die Makros in einem angehängten Worddokument zu aktivieren.

Der Erfolg Emotets beim Phishing liegt unter anderem an dem seit Ende 2018 genutzten Funktionsmodul, das Kontakt- und Inhaltsdaten aus Outlook nutzt. D.h. Emotet verschickt Emails an Kommunikationspartner des Besitzers des infizierten Rechners und nutzt dabei auch die Emailinhalte, um die Phishing-Mails besser an die Empfänger anzupassen (z.B. Bewerbungen an Personalabteilungen). Das macht es auch für vorsichtige Personen schwierig, Spam-Mails von echten Mails zu unterscheiden. Wenn dann im angehängten Worddokument nach dem Öffnen noch kurz um ein „Enable Editing“ gebeten wird, geben viele Anwender Emotet unwissend die Berechtigung, Code auf ihrem Rechner auszuführen und infizieren damit ihren Rechner.

Dabei verwendet Emotet keine neuen Technologien. Phishing-Mails mit schadsoftwarebehafteten Anhängen gibt es seit vielen Jahren. Ein Antivirenprogramm hat gute Chancen, die Infektion zu verhindern. Natürlich nur, sofern die Virenpattern aktuell sind und Emotet nicht in einer bisher unbekannten neuen Version verbreitet wird. Ob die Überprüfung schon am Mailgateway stattfindet oder erst lokal beim Zugriff auf den Anhang spielt dabei keine Rolle. Natürlich würden auch restriktive Sicherheitspolicies, wie das technische Verhindern eines Austausches von Dateien mit Makros oder ausführbaren Programmen über Email, eine Erstinfektion wirksam unterbinden. Doch häufig siegt der Wunsch nach vereinfachtem Dateiaustausch über Sicherheitsüberlegungen oder die Sicherheitsrisiken werden ganz einfach unterschätzt.

Bisher haben wir jedoch nur die Erstinfektion betrachtet. Phishing wird genutzt, um den „Kern-Emotet“ auf den Rechner zu bringen. Nach erfolgter Infektion kann Emotet über nachgeladene Funktionsmodule weitere Schwachstellen im internen Netzwerk ausnutzen, um sich auf andere Systeme zu verbreiten. Auch greift er auf lokal verfügbare Passworte und Credentials zu. Einige Versionen von Emotet schickten auch gefundene Informationen zu fremden Servern im Internet.

Während die Zahl der Infektionen Mitte 2019 nachließ, startete in den letzten Wochen wieder eine neue Welle. Laut BSI (https://www.sicher-im-netz.de/trojaner-emotet-kombination-mit-ransomware-im-umlauf ) werden aktuell vermehrt die Bankingtrojaner Trickbot und die Ransomware Ryuk von Emotet nachgeladen.

Umgang mit dem Befall

In den Heise-Berichten über den Umgang mit einen Emotet-Befall in ihrem Netzwerk sind die vier wesentlichen Phasen aus der ISO/IEC 27035 (Information security  incident management) erkennbar:

1. Erkennen und melden
2. Eindämmen und eskalieren
3. Schäden beheben
4. Lehren ziehen

Erkennen und melden

Bemerkenswert dabei war, dass nach der eigentlichen Erstinfektion mittels eines durch einen Mitarbeiter ausgeführten Word-Makros aus einer Spam-Mail, die schnelle Verbreitung im internen Netz und die Schwierigkeiten der Betroffenen, die Kommunikation von Emotet mit seinen C&C-Servern schwer zu unterbinden war. Nach der Erstinfektion schlugen zwar Virenscanner an und riefen die IT-Abteilung auf den Plan, diese behandelte die Einzelereignisse aber zunächst als Standardfall mit lokaler Bereinigung. Nach zwei Tagen wurden verdächtige Aktivitäten auf der Firewall festgestellt, die die Sicherheitsvorfalleskalation in Gang setzte.

Eindämmen und Eskalieren

Innerhalb kurzer Zeit gelangten die Angreifer an lokale Administrator- und Domänen-Administrator-Credentials und konnten so weitere Systeme infizieren. Die IT-Abteilung beobachtete diverse automatisierte Ausbreitungsversuche wie z.B. Brute-Force-Angriffe mit bekannten Passwörtern und die Ausnutzung von Schwachstellen in veralteten Protokollversionen (in diesem Fall SMBv1 für Netzwerkshares). Erst eine komplette Netzwerk-Abschottung vom Internet und das Trennen sämtlicher augenscheinlich betroffener Rechner vom internen IT-Netz ermöglichte die Eindämmung des Vorfalls und eine kontrollierte Untersuchung durch die hinzugezogenen Forensikfirmen und Incident-Response-Spezialisten. Vermutlich konnten so auch weitere Schäden verhindert werden, wie z.B. die häufig einige Zeit nach der Infektion stattfindenden Verschlüsselung der Daten und die darauf aufbauenden Lösegeldforderungen.  

Schäden beheben

Trotzdem entstanden durch den Befall hohe Kosten allein durch anfängliche (erfolglose) Bereinigungsversuche, den Untersuchungsaufwand durch Spezialisten und das Neuaufsetzen fast des gesamten IT-Netzes. Schließlich besitzt Emotet auf befallenen Systemen auch verschiedene, unter anderem vom amerikanischen Geheimdienst NSA entwickelte Methoden, um sich vor einer Entdeckung zu verstecken, z.B. durch Veränderung des eigenen Codes.[1]  Eine anfänglich erfolgreiche Durchführung von „Reparartur/Desinfektion“-Funktionen konnte das Auftreten weiterer Folgeerscheinungen im internen Netz nicht stoppen. Damit mussten nicht nur eindeutig infizierte Systeme neu aufgesetzt werden.

Lehren für das Sicherheitsvorfallmanagement von EVU‘s

Die Erkennungs- und Bereinigungsfunktionen der gängigen Virenscanner können bei fortgeschrittenen APT-Angriffen (Advanced Persistent Threads) nie vollständig sicherstellen, dass keine aktiven Code-Teile zurückbleiben. Es muss davon ausgegangen werden, dass alle Systeme, die sich in dem befallenen Netz befanden, eine Quelle für die erneute Ausbreitung sein können.

Voraussetzung für eine erfolgreiche Rückführung in den Normalbetrieb ist natürlich ein Datensicherungsbestand aus einer Zeit vor der Infektion und dass die für die Datenrückspielung verwendeten Backup-Systeme ebenfalls nicht befallen sind. Beides kann zu einer nachhaltigen Beeinträchtigung der Aufgabenerfüllung führen, selbst wenn noch keine Ransomware zur Ausführung gekommen ist. Darüber befindet sich in den Heise-Veröffentlichungen keine nähere Angabe, z.B. zur Aktualität des tatsächlich wiederhergestellten Datenbestandes. Für EVU könnte dies eine ungleich größere Bedeutung haben, da hier Systeme und Datenbestände betroffen sein können, die die Steuerung von Energienetzen und Kraftwerken betreffen.

Problematisch für Energieunternehmen ist es demzufolge auch, wenn die IT-Abteilung in einem unkontrollierten Verfahren IT-Netzverbindungen zu mutmaßlich gefährdeten Systemen vorsorglich und evtl. vorschnell trennt. Davon könnten dann auch Verbindungen zu betriebskritischen Systemen betroffen sein und die Aufgabenerfüllung damit gestört werden. Das betrifft neben dem eigenen Betrieb auch Anlagenkopplungen zu anderen Energieunternehmen, mit denen z.B. Übergabestationen oder Energieleitungen gemeinsam genutzt werden. In Notfallsituationen würde sich die Laststeuerung nicht wie erwartet verhalten und die Versorgungssicherheit könnte gefährdet werden. Ein zu langes Zögern andererseits könnte die Wiederherstellung von Datenbeständen, z.B. Anlagenfahrpläne, Schaltdaten, Parametrierungen usw. gefährden und eine Ausbreitung im eigenen Unternehmen und auch in verbundenen anderen Unternehmen begünstigen.

Das CERT-Bund hat auch bereits mehrere Fälle beobachtet, in denen Wartungs-Zugänge eines befallenen IT-Dienstleisters ausgenutzt wurden, um weitere Firmen zu infizieren.[2]  Einige  Energieunternehmen sind in widrigen Betriebssituationen auf den Wartungszugang mancher Dienstleister angewiesen. Eine Netztrennung dieser Zugänge ist nicht immer möglich.

Die IT-Abteilungen befinden sich also in einem Dilemma, welches sie allerdings durch technische Vorkehrungen und durch das Vorbereiten von Eskalationsprozeduren abmildern können. Im Rahmen des Sicherheitsvorfallmanagements werden auch die organisatorischen Schnittstellen zu Leittechnikabteilungen, Leitwarten und Dienstleistern sowie die notwendige Kommunikation und Entscheidungsbefugnis im Ernstfall berücksichtigt. Die Ziele des Sicherheitsvorfallmanagements von Energieunternehmen orientieren sich im Wesentlichen an tolerablen Ausfallzeiten für die Aufgabenerfüllung und an tatsächlichen IT-Bedrohungen. Die Ausfallzeiten müssen in der Regel durch ein betriebliches BCM (Business Continuity Management) ermittelt werden. Das BCM ermittelt ebenfalls, ob ein komplettes Neuaufsetzen bestimmter IT-Umgebungen, wie im Falle von Heise, überhaupt möglich ist, ohne die Existenz des Unternehmens oder die Versorgungssicherheit zu gefährden.

Für die Analyse von IT-Bedrohungen sind die Erkenntnisse des Heise-Vorfalls sehr hilfreich. Im Analyseprozess kann ermittelt werden, ob bisherige IT-technische Vorkehrungen ausreichen, um das Risiko von Schäden durch APT-Angriffen auszuschließen. Hierbei werden der Aufbau der IT-Infrastruktur, die betrieblichen Fachanwender und die eingesetzten Dienstleister mit einbezogen. Es ist anzunehmen, dass eine verzögerte ad-hoc Reaktion, wie im Falle von Heise, für mehrstufige APT-Angriffe auf Energieunternehmen in manchen Situationen nicht schnell und umfassend genug ist, um Beeinträchtigungen des Energiebetriebs auszuschließen. Auf vermutete APT-Angriffe sollte frühestmöglich und in vorab abgestimmter Weise reagiert werden, damit eine Ausbreitung auf Leitsysteme und Automatisierungstechnik unter allen Umständen verhindert wird. Dazu ist eine fundierte Vorgehensplanung zu erstellen und zu testen.

Risikolage bei Energieunternehmen

Die Risikolage von Energieunternehmen unterscheidet sich vom oben beschriebenen Heise-Vorfall auch wegen der im Energiemarkt bereits vorhandenen technischen und organisatorischen Vorkehrungen und den regulatorischen Auflagen für KRITIS-Unternehmen und Energienetzbetreiber. Dazu gehört mindestens ein Krisenmanagement für energietechnische Notfälle. Eine bewusst strenge Abgrenzung von Büro-IT-Anwendungen und dem IT-Betrieb für Energieanlagen ist ebenfalls Stand der Technik. Bei einigen Unternehmen ist bereits eine technische Trennung der IT-Netzbereiche durch Firewalls und Datenschleusen weitgehend umgesetzt und der Empfang von Emails im Anlagen-Netz ist eingeschränkt. Durch die regulatorischen Vorgaben haben die Energieunternehmen auch ausreichend Personal aufgebaut, welches in der Lage ist, gemeldete Sicherheitsvorfälle ad-hoc zu untersuchen und Gegenmaßnahmen einzuleiten. So lässt sich theoretisch ein schnelles und vollständiges Abschottungsszenario für Notfälle aufbauen, in welchem ein Mitarbeiter ein Patchkabel zieht oder eine zentrale Netzwerkkomponente stromlos schaltet.

Ist unter Beachtung von Emotet und vergleichbaren Bedrohungen ein ad-hoc-Management von Sicherheitsvorfällen also weiterhin ausreichend?

Zunächst müssen sich Unternehmen darüber klarwerden, ob das Sicherheitsvorfallsmanagement für sich genommen in einem Ernstfall im Anlagen- oder Leitwartenbereich überhaupt ausreichend ist, um mit den Folgen umzugehen. In der Regel gibt es bereits ein betriebliches BCM und Krisenmanagement, welches ebenfalls benötigt wird, um auf die Wiederherstellung der gewünschten Fahrweise von Kraftwerken und Energienetzen vorbereitet zu sein. Es berücksichtigt z.B. eine komplette Synchronisation des Schalterinventars sämtlicher Anlagen und eine Aktualisierung aller Schaltzustände durch Abfrage der Automatisierungskomponenten bzw. SPS‘en. Bei genauerer Betrachtung der IT-Situation reift möglicherweise dennoch die Erkenntnis, dass für eine Komplett-Wiederherstellung wie im Heise-Fall die bisherige tolerable Ausfallzeit und die zuverlässig „sauberen“ Datensicherungsbestände nicht ausreichen. Spätestens an diesem Punkt erscheint die Einführung eines IT-spezifischen BCM’s sinnvoll, welches die vorhandenen betrieblichen BCM- und Krisenmanagement-Vorbereitungen erweitert.

Eine belastbare Einschätzung sollte sowohl technische als auch organisatorische Aspekte berücksichtigen und die Entscheidungsfaktoren dokumentieren. Dies ist Aufgabe einer IT-Risikoanalyse. Die verbleibenden Gefahrenherde müssen den bekannten Ausbreitungs- und Schadenszenarien der Angriffssoftware gegenübergestellt werden. Ein möglicher Ansatz besteht darin, aus der betrieblichen Dokumentation, z.B. Asset-Inventarisierung, Anwendungslisten, Netzstrukturplänen und Organigrammen abzuleiten, wieviel betrieblich notwendige Datenkommunikation das Anlagennetz trotz separierter IT-Netze weiterhin benötigt. Die folgende Abbildung skizziert beispielhaft einige Gefahrenherde (rot).
 

Abbildung-2: Gefahrenbereiche im IT-Netzverbund

Die Fähigkeit zur vollständigen technischen Abschottung in Notfällen ist für sich genommen nicht ausreichend. Angesichts der Ausbreitungsfähigkeit von Emotet muss auch die Verzögerung zwischen der ersten Verdachtsmeldung und der Notfalltrennung und die danach benötigte Zeit für die Aufklärung und ggf. Bereinigung berücksichtigt werden. Der Entscheidung für eine Notfalltrennung und die spätere Verbindungswiederherstellung sollten belastbare Informationen zugrunde liegen, um ein erneutes Ausbreiten zu verhindern. Es sollte auch berücksichtigt werden, dass zu häufige Nottrennungen, die sich später als False Positive herausstellen, sich negativ auf die Akzeptanz und damit die Wirksamkeit Sicherheitsvorfallmanagements auswirken können.

Man erkennt, dass die zu treffenden Entscheidungen nicht nur technischer Natur, sondern auch von hoher geschäftlicher Bedeutung sind. Demzufolge müssen Sicherheitsvorfallsprozeduren definiert und eingeübt werden, die bereits bei einer Verdachtsmeldung greifen und auch die Kommunikation zu Entscheidungsträgern sowie die dafür relevanten Informationsbedarfe enthalten. Definierte Eskalationsprozeduren ermöglichen es dann, Entscheidungen bzw. Entscheidungskriterien bereits im Vorfeld freizugeben, auf zeitintensive Kommunikation im Notfall teilweise verzichten zu können und gleichzeitig die Folgen dennoch beherrschbar zu halten.

Vorhandene Sicherheitszertifizierungen

Unternehmen mit vorhandener Sicherheitszertifizierung für den Anlagenbetrieb haben in der Regel schon strukturierte Sicherheitsvorfallsprozeduren innerhalb ihres Zertifizierungsbereichs definiert. Nach heutigem Stand (2019) umfasst dieser in der Regel jedoch nicht den Bürobereich. Eine Zertifizierung sagt auch nichts über die Robustheit vorhandener Prozeduren gegenüber Emotet und anderen APT-Bedrohungen aus, was z.B. die abteilungsübergreifende Notfallkommunikation, die Entscheidungskriterien bzgl. IT-spezifischen Problemen und die tolerierbaren Reaktionszeiten angeht.

Die Unternehmen müssen individuell beurteilen:

1. Ist eine Verbesserung des Sicherheitsvorfallmanagements allein im zertifizierten Bereich ausreichend?
2. Welche Unternehmensteile außerhalb des Zertifizierungsbereichs müssen Teil der Melde- und Eskalations-Prozeduren sein bzw. werden? (z.B. Büronetz)
3. Berücksichtigen die vorhandenen Eskalationspläne im bisherigen BCM und Krisenmanagement auch APT-Szenarien?
4. Sind die Nottrennungsmechanismen umfassend genug und mit Entscheidungswegen hinterlegt, die sowohl für die Abschaltung als auch die Wiederverbindung gelten?
5. Ist innerhalb des Anlagennetzbereichs eine ausreichende netzwerktechnische Segmentierung für besonders kritische Betriebsfunktionen vorhanden, etwa zentrale Leitsysteme, und sind diese in den Prozeduren für Erkennung und Reaktion auf Vorfälle berücksichtigt?

Fazit

Es besteht angesichts von Pressemeldungen zu Emotet zunächst kein übermäßiger Grund zur Panik. Dies liegt unter anderem daran, dass bisher nur befallene Windows-Systeme bekannt geworden sind, während z.B. in der Automatisierungstechnik vorrangig Linux-Derivate verbreitet sind. Bereits vorhandene technische und organisatorische Sicherheitsmaßnahmen senken das Risiko, sofern sie aufrechterhalten werden und mit der Entwicklung von APT-Bedrohungen Schritt halten. Die folgende, nicht abschließende Aufstellung zeigt darüberhinausgehende Anhaltspunkte für die Vertiefung bzw. Verstärkung von Maßnahmenaspekten:

1. IT-Netze der Energieanlagen sind ausreichend zu segmentieren und durch Sicherheitsgateways abzuschotten. Dies hilft auch dabei, die Ausbreitung von Vorfällen effektiver einschätzen zu können.
2. Sicherheitsvorfallsprozeduren sollten technische, organisatorische und bei Bedarf auch geschäftliche Aspekte berücksichtigen, z.B. bei Notfallabschottung einzelner segmentierter Netzbereiche.
3. Sicherheitsvorfallsprozeduren des Anlagenbetriebs müssen bereits im Bereich der Büro-IT beginnen.
4. Sicherheitsvorfallsprozeduren sollten ausreichend formalisiert und von Entscheidungsträgern freigegeben sein.
5. Die Wiederverbindung nach einer Netztrennung sollte nicht zu früh und wenn möglich anhand definierter Kriterien erfolgen, um eine erneute Ausbreitung zu verhindern.
6. Die Verzahnung von Managementaktivitäten unterschiedlicher Bereiche kann kontinuierlich verbessert werden, um mehrstufigen Angriffen besser widerstehen zu können. Für Notfälle müssen schnittstellenübergreifende Eskalationsstufen definiert und geschult sein.

Opens external link in new windowAutor: Willy Wauschkuhn, GAI NetConsult GmbH


[1] https://blog.malwarebytes.com/threat-analysis/2018/05/malware-analysis-decoding-emotet-part-1/

[2] https://www.heise.de/ct/artikel/Trojaner-Befall-Emotet-bei-Heise-4437807.html

Autor: Willy Wauschkuhn

Diesen Artikel empfehlen