Trojanerbefall in Stadt Bad Homburg und Hochschule Freiburg

Gestern wurden zwei neue Cyber-Angriffe auf die IT-Netzwerke der Verwaltung des nördlich von Frankfurt gelegenen Taunusstädtchens Bad Homburg sowie auf die Katholische Hochschule Freiburg bekannt. In allen Fällen wird hinter dem Vorfall eine Infektion mit dem Trojaner Emotet vermutet. Die IT-Netzwerke der Betroffenen wurden aus Sicherheitsgründen heruntergefahren.


Anzeige

Neben der Stadtverwaltung von Frankfurt/Main und der Universität Gießen sowie des Klinikums Fürth (siehe Links am Artikelende) hat es jetzt zwei weitere öffentliche Institutionen getroffen.

IT der Stadt Bad Homburg abgeschaltet

Blog-Leser 1St1 hat hier auf den Fall hingewiesen (danke dafür). Die Verwaltung des Städtchens Bad Homburg hat nach der Meldung des Rathauses seine IT-Systeme heruntergefahren. Es besteht der Verdacht, dass das Netzwerk der Stadt Bad Homburg mit einer Schadsoftware befallen ist. Daher hat die Verwaltung vorsorglich sämtliche Systeme runterfahren lassen.

Das hat zur Folge, dass die Stadtverwaltung und alle ihre Ausstellenstellen bis auf weiteres nur einen eingeschränkten Service anbieten können. Auch die telefonische Erreichbarkeit ist davon betroffen. Die Mobilitätszentrale im Bahnhof muss am Freitag, 20. Dezember 2019, geschlossen bleiben. Die Kindertageseinrichtungen haben wie gewohnt geöffnet.

Diese Webseite berichtet, dass eine Spam-Mail mit dem Emotet-Virus im Anhang sowohl die IT-Systeme der Stadt Frankfurt als auch von Bad Homburg lahm gelegt habe.

Ransomware befällt Katholische Hochschule Freiburg

Es war ebenfalls schon hier im Blog als Kommentar angemerkt worden und ich hatte den Beitrag bei heise gesehen. Auch die Katholische Hochschule Freiburg erlebt den Shutdown ihrer IT-Systeme in Folge einer Infektion mit Schadsoftware.

IT-Shutdown der Katholische Hochschule Freiburg

Auf Facebook findet sich der oben abgebildete Eintrag der Katholische Hochschule Freiburg, in dem der IT-Shutdown ab Dienstag angekündigt wurde.


Anzeige

Shutdown der IT-Infrastruktur der Katholischen Hochschule Freiburg ab dem 17.12.2019 aus Sicherheitsgründen.

Dies betrifft sämtliche hochschuleigenen IT-Services, Portale, Plattformen, Netzwerke und Kommunikationsmöglichkeiten. Wir bedauern diesen notwendigen Schritt und arbeiten mit Hochdruck daran, Ihnen unsere umfassenden Informations- und Kontaktmöglichkeiten wieder bereitstellen zu können. Wir bitten zudem, die aus dem Shutdown resultierenden Verzögerungen in Verwaltungsangelegenheiten zu entschuldigen.

Heise berichtet unter Berufung auf die Badische Zeitung, dass ein Virus, konkret wird Emotet genannt, im Netzwerk der Katholischen Hochschule Freiburg (KH) wütet. Der Shutdown soll dessen Ausbreitung verhindern. Aktuell ist aber unklar, wie die Schadsoftware auf Rechner der Hochschule kam. Es dürfte aber eine Mail gewesen sein, die Emotet entweder im Anhang hatte oder Links auf eine Webseite enthielt, auf der der Emotet-Dropper bereitgehalten wurde. Jedenfalls wurden die Mitarbeiter der Hochschule vorzeitig in Urlaub geschickt. Die Hochschule hatte, laut Berichtserstattung, viel Geld in die IT-Infrastruktur und –Sicherheit gesteckt – es rächt sich jetzt aber die Windows-Monokultur.

BTW: Kaspersky bereitet das Thema Ransomware in dem in obigem Tweet verlinkten Artikel allgemein auf und gibt kommunalen Einrichtungen noch ein paar Tipps zum Schutz mit auf den Weg.

Ähnliche Artikel
Stadt Frankfurt/Main Opfer eines Cyber-Angriffs (19.12.2019)
Neues zum Virenbefall der Uni Gießen
Uni Gießen: Sicherheitsvorfall legt IT-Systeme lahm
Klinikum Fürth wegen Trojaner offline
Klinikum Fürth im Betrieb zurück, Uni Gießen nutzt Desinfec't

Die IT-Notfallkarte des BSI für KMUs
FAQ: Reagieren auf eine Emotet-Infektion


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

Dieser Beitrag wurde unter Sicherheit abgelegt und mit , verschlagwortet. Setze ein Lesezeichen auf den Permalink.

14 Antworten zu Trojanerbefall in Stadt Bad Homburg und Hochschule Freiburg

  1. 1ST1 sagt:

    Ich glaube nicht, dass eine Windows Monokultur schuld ist. Ich glaube eher, dass trotz hoher Ausgaben in die Sicherheit ein paar entscheidende Sachen nicht gemacht wurden. Der Emotet-Dropper muss irgendwie gestartet werden. Wenn jeder Benutzer aus seinem Downloads-Ordner starten kann, wars das schon, Applocker bzw. die ältere Software Restriction Policy, welche nicht nur unter Entwerprise, sondern auch unter Pro funktioniert, würde dies bereits verhindern, muss man nur mal einführen. Das macht halt das Installieren von neuen Anwendungen etwas umständlicher, "Ausführen als", na und? Eine weitere Sache könnte die Windows-Firewall sein, die einfach mal aus gelassen wird, wäre sie an gewesen, hätte Emotet nicht versuchen können, benachbarte PCs per BlueKeep etc. anzugreifen. Apropos BlueKeep: Patch as you can… Man kann das alles verhindern, es liegt nicht an einer Monokultur, wie bei Bleeping von Vorgestern zu lesen ist, hat Lazarus jetzt auch einen Linux-Virus mit umfangreichem Schadcode-Schweizer-Taschenmesser im "Angebot". Irgendwo, wars bei Beleeping, wars bei Hacker-News oder sonstwo, war neulich die Meldung, dass es ein Mac-Virus erstmalig unter die Top 5 geschafft hatte. Es ist nicht die Monokultur, es ist, was man daraus macht.

    • Tim sagt:

      100% Zustimmung!

    • Günter Born sagt:

      Deine Ausführungen sind nachvollziehbar und die unterschreibe ich auch. Trotzdem greift das zu kurz. Monokultur meint ja nicht nur das Betriebssystem an sich, sondern auch die Verfahren drum herum – und da ist macOS inzwischen auch nicht mehr besser.

      Du erwähnst es: Es gibt Software Restriction Policies und nun Applocker. Die SRP sind imho auf dem sterbenden Ast (deprecated) und es wurde nie als default eingeführt. Die ganzen Home-Nutzer kriegen das eh nicht – es soll ja alles möglichst komfortabel und einfach mit dem Installieren gehen. Alles, was Microsoft und Apple und Google so als default raushauen, ist dann Standard. Und die von dir erwähnten Möglichkeiten müssen von Admins eingeführt werden. Können die, liegen dann aber abseits des 'Standards'.

      Wenn es eine Funktion gäbe, dass Admins Programme, die installiert und ausgeführten werden dürfen, genehmigen müssen, wäre möglicherweise bereits einiges verhindert worden. Es ist immer ein Kompromiss zwischen Komfort und Sicherheit – vordefiniert von der von mir als Monokultur bezeichneten IT-Landschaft.

      • 1ST1 sagt:

        Stimmt alles, aber eine Stadt Frankfurt, Bad Homburg, Neustadt am Rübenberge, Krankenhaus Fürth, Uni Gießen und Marburg, Kath. Hochschule Freiburg, Saarländische Krankenhäuser, Norsk Hydro, …., die sollten diese Möglichkeiten haben. Die haben Admins, es gibt dieses Know-How, und wenn man es selbst nicht kann (Wissen, Ressourcen, …) dann muss man eben zur Einführung dieser Schutzmaßnahmen (auch ein gescheiter Mail- und Webproxy!) mal eben einen gescheiten Dienstleister hinzuziehen, als Stadt, Uni, Krankenhaus, Firma, … muss man halt mal dieses Geld in die Hand nehmen. Das ist genau so wichtig wie dass Strom und Wasser ins Haus fließt.

        Das mit "Monokultur" abzutun ist Resignation und drauf warten, dass "endlich" so eine Mail kommt.

        • Chris sagt:

          Ich sehe das Problem eher darin das es sich Städte und Einrichtungen eben KEINE eigenen Admin mehr leisten und wenn, dann meistens nur Hilfsadmins als Ansprechpartner für die Leute vor Ort.

          Alles andere wird an Dienstleister "Outgesourced" um Kosten zu sparen. Der Dienstleister wird das System immer so einrichten, das er die wenigsten Anfragen bekommt.

          Webproxy?
          Um Gottes willen, dann meldet sich ja jede Woche jemand das er auf Seite XY nicht zugreifen kann. Oder das Seite XY heute nicht mehr so funktioniert wie gestern, das es an der Seite selber liegen könnte ist erstmal egal. Der Dienstleister hat es pauschal zu prüfen.

          Mailproxy?
          Täglich Anrufe ala, ich hätte vor einer Stunde schon eine Mail bekommen sollen, die ist immer noch nicht da. Am Ende stelt sich raus, die vernisste Mail wurde gar nicht abgeschickt.

          Der "Hilfsadmin" vor Ort wird ein Teufel tun die Systeme zu verändert, weil dann sagt der Dienstleister hinterher, die Änderungen wurden nicht durch uns durchgeführt, der Support ist ausserhalb des Rahmenvertrags und wird extra berechnet.

    • Bernard sagt:

      Ah, die Fan-Boys sind heute schnell.

      Wenn die Nutzung von Applocker oder Software Restriction Policies so einfach wäre, hättest du auch einen Link auf eine Anleitung setzen können.

      Aber das Thema ist nicht "mal eben" abzuarbeiten, wie dein Post suggeriert.

      Es stimmt, eine Hochschule mit IT-Abteilung sollte dazu in der Lage sein. Ein kleiner Betrieb oder ein e.V. wird da aber schon Probleme haben.

      P.S. Und wenn Kaspersky in einem Tweet schreibt "how to install #kaspersky antivirus on your computer?", dann ist auch DAS keinerlei Hilfe.

      • 1ST1 sagt:

        Es ist in einem AD wirklich einfach. Ist alles in der Gruppenrichtlinienverwaltung drin. Wenn man Applocker aktiviert, wird einem sogar schon ein Basis-Regel-Set automatisch angelegt, das die wichtigsten Regeln (c:\windows, c:\program files, c:\program files (x86)) bereits enthält. In vielen Fällen braucht man bereits nicht mehr. SRP ist etwas schwieriger, weil einem da diese 3 Basisregeln nicht erstellt werden, aber das ist ruckzuck erledigt. Wer Startupscripte aus \\domain\netlogon verwendet, oder so, braucht noch ein paar Zusatzregeln und ist meistens schon fertig. Manchmal muss man noch c:\appdata\* freigeben, manche Programme laden exe und dlls von dort nach. c:\users\hanswurst\downloads geht dann schon nicht mehr.

        Schwerer wirds nur, wenn man Programme außerhalb dieser Pfade installiert hat.

        Pfad-Regeln sind normalerweise ausreichend. Man kann auch Hashes erzeugen und als Regel nutzen, hat aber den Nachteil dass sich bei Softwareupdates diese Hashes ändern und man das wieder aktualisieren muss, wers mag… Hersteller-Zertifikate sind auch gut.

        Außerdem empfehle ich noch, die Webartikel von Stefan Kanthak und Schneegans.de zum Thema Software-Restriction-Policy und SAFER durchzulesen. Denn leider gibt es unter c:\windows ein paar tief verschachtelte Unterordner, die leider für Benutzer zum Schreiben freigegeben sind, schafft es ein Schädling, seine Datei da rein zu legen, ist die Tür auf. In diesen Artikeln vom Kanthak und Schneegans ist das beschrieben, bei Schneeganz gibt es ein Test-Script, das einem eine Reg-Datei für SRP ausspuckt, um diese Ordner nicht ausführbar markiert. Die Pfade aus der Reg-Datei lassen sich auch als Ausnahmen in die Applocker-Regel für c:\windows einfügen, dann ist auch das dicht.

        https://skanthak.homepage.t-online.de/SAFER.html (der ist etwas schwerer zu verstehen)
        https://schneegans.de/windows/safer/ (der ist leichter zu verstehen)

        Das ist mal ein Tag zum Lesen und probieren, und dann kann man das mal auf eine Test-OU, und dann auf den gesamten Betrieb ausrollen.

        Wer kein AD hat, kann insbesondere die Schneegans-Anleitung nutzen, um sich das für privat umzusetzen, hab ich bei meinem Vater seinem PC gemacht, und seit dem viel weniger Stress…

        • Günter Born sagt:

          Du sprichst ein Thema an, welches ich schon länger auf der Agenda habe, aber aus Zeitgründen noch nicht adressieren konnte. Wäre imho auch für die Windows 7-Nutzer, die ab dem 14.1.2020 weiter fahren wollen/müssen, ganz interessant.

        • Bernard sagt:

          @ 1ST1

          Ganz herzlichen Dank für die ausführliche Erläuterung!

          :-)

          • 1ST1 sagt:

            Das Ganze hat aber leider noch einen Haken. Der heißt "DDE": Applocker und SRP lässt sich mit Excel umgehen, selbst wenn Makros ausgeschaltet sind. Es reicht eine Zelle mit dem "CMD=" Befehl in einer Excel-Tabelle. Für lokale Angreifer ist das offen wie ein Scheunentor, manche Antiviren erkennen aber solche Inhalte und blockieren das Speichern solcher Dateien, einfach weiter verbreiten geht dann nicht, bei Sophos habe ich das z.B. nachvollziehen können. Fürs Mailbombardement lässt sich das aber nur schwer verhindern, manche Mailappliance kann XLS(X) Dateien als Attachment analysieren und man kann dann einen passenden Aussortier-Filter basteln, ansonsten muss man leider den Empfang von Office-Docs per Mail sperren.

            Hier weiter lesen, mir gelang es nur die Excel-Beispiele nachzuvollziehen, die für Word, Outlook und OneNote funktionieren scheinbar nicht mehr:

            https://pentestlab.blog/2018/01/16/microsoft-office-dde-attacks/

            Solche DDE-Attacken können auch in IQY-Dateien stecken:

            https://www.bleepingcomputer.com/news/security/buran-ransomware-infects-pcs-via-microsoft-excel-web-queries/

            Den Dateityp auf dem Mailgateway und auf dem Webproyx am Besten auch gleich sperren, und im Explorer per Registry-Hack auf Notepad oder eine Batch (@del %1) umleiten.

    • Volko sagt:

      Genauso ist es!
      Zusätzlich könnte man noch überlegen, Browser und E-Mail-Client standardmäßig z.B in Sandboxie laufen zu lassen … allerdings funktioniert das meines Wissens nicht mit Edge und wie es mit der Sandboxie Entwicklung weitergeht ist z.Zt. leider auch ungewiss. Privat nutze ich das Tool selber seit vielen Jahren und installiere dieses auch auf von mir gewarteten Rechnern im Freundes- und Bekanntenkreis. Sollte dann trotz umsichtigen Verhaltens einmal Schadsoftware doch zur Ausführung gelangen läuft diese im Kontext der Sandbox und nach Löschen letzterer ist der Spuk vorbei.
      Eine Schulung der Anwender, wie man mit Dateianhängen und Links umzugehen hat ersetzt Sandboxie nicht, ist aber ein weiterer Baustein neben den im ersten Kommentar genannten Maßnahmen, den IT-GAU zu verhindern.

      • 1ST1 sagt:

        Sandboxie ist schon etwas schwierig zu benutzen. Für viele Fälle reicht auch der Privat-Modus, den moderne Browser anbieten, schon aus. Mir supekte Seiten öffne ich meistens erstmal damit.

  2. Bernard sagt:

    @ Chris

    full ACK

    Gerade in kleineren Betrieben kommen ständig Beschwerden wegen solcher Web- und Mailproxies. Da gibt es NULL Verständnis, warum es so etwas gibt.

    Besonders nervend sind tatsächlich diese Supportanfragen wegen einer E-Mail, die schon vor 10 Minuten da sein sollte…

    Übrigens wundert es mich sehr, dass es Norsk Hydro getroffen hat. Gerade DIE sollten Geld genug haben, um eine IT-Abteilung zu bezahlen.

    Aber es ist wie so oft:

    Wenn alles gut läuft, rationalisiert man die IT weg. Eventuell an auswärtige Anbieter. Dabei sollte JEDER Betrieb froh sein, wenn die IT wenig zu tun hat, weil dann eben alles gut läuft.

    • 1ST1 sagt:

      Das kommt aber dann auch auf den Dienstleister an. Eigentlich sollte es im Interesse des Dienstleisters liegen, Aufträge zu generieren. Da ist so ein rundrumsorglos-Wartungsvertrag natürlich nix, wenn der Dienstleister nur kommt, wenn der Kunde will, das was getan wird, oder etwas pssiert ist. Der Dienstleister sollte daher die allgemeine Gefahrenlage beobachten, und dann zum Kunden gehen, und sagen, da ist gerade Emotet unterwegs, wir haben da neue Erkenntnisse, wie man den abwehren kann, wir schlagen vor, deine Umgebung auf diese neue Gefahrenslage, die nicht mit Standardprocedures abwehrbar ist, abzuklopfen und dichten das dann ab. Genug warnende Beispiele, die man aufführen kann, gibts ja.

Schreibe einen Kommentar zu Tim Antworten abbrechen

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert

Hinweis: Bitte beachtet die Regeln zum Kommentieren im Blog (Erstkommentare und Verlinktes landet in der Moderation, gebe ich alle paar Stunden frei, SEO-Posts/SPAM lösche ich rigoros). Kommentare abseits des Themas bitte unter Diskussion.