Wie ein Cyber-Angriff auf ein Softwareprodukt Flughäfen lahm legte
Sicherheitsvorfall bei RTX-Tochter Collins Aerospace
Cybersecurity hat es mal wieder in die Tagespresse geschafft, und Flughäfen auch. Kommt Ihnen bekannt vor? Das könnte am Crowdstrike-Fall liegen, der ist ungefähr ein Jahr her (siehe Hard-Hats-Briefing 08/2024).
Aktualisiert am 03.11.2025.
Was ist passiert?
An den Flughäfen in Berlin, Brüssel, Dublin und London musste die Passagierabfertigung teils händisch (mit Stift und Papier, ich stelle mir das in etwa so vor wie oben auf dem Bild) erledigt werden, was zu langen Wartezeiten, Verspätungen und annullierten Flügen über mehrere Tage führte.
Im Gegensatz zu Crowdstrike, bei der eine Security-Lösung es ganz ohne Angreifer geschafft hat, Flughäfen lahmzulegen, gab es diesmal einen Angriff, wohl am 19. September.
Allerdings keinen direkten Angriff auf die Flughäfen, sondern auf den Software-Anbieter Collins Aerospace, genauer seine cMUSE-Software. Die Collins-Software ARING cMUSE wird für die Passagierabfertigung eingesetzt — also für Prozesse wie Check-in und Gepäckabgabe.
Was für ein Angriff war es und wie geht Collins damit um?
Über die Art des Angriffs und den Umgang des Softwareunternehmens damit gibt es fast keine Informationen, außer der Meldung des Vorfalls des börsennotierten Collins-Mutterkonzerns RTX an die US Securities and Exchange Commission vom 19. September. Dort steht auch, dass es ein Ransomware-Angriff war — und natürlich, dass keine finanziellen Auswirkungen auf den börsennotierten Mutterkonzern RTX zu erwarten sind.
Von Collins Aerospace selbst, einem US-amerikanischen Unternehmen, das technische Lösungen für kommerzielle und militärische Luft- und Raumfahrt anbietet, gibt es nichts.
Einige Medienartikel beziehen sich auf Informationen der EU-Cybersicherheitsbehörde ENISA, nach denen die genaue Ransomware-Gruppe ENISA bekannt sei.
In einer Tagesschau-Meldung vom 24. September liest man, Collins Aerospace “scheine das System erneut neu aufzubauen, nachdem es am Montag versucht hatte, es neu zu starten”. Im Wikipedia-Artikel zum Vorfall heißt es, am 29. September begann Collins am Brüsseler Flugafen ein “Ersatzsystem” auszurollen. Ob dieses Ersatzsystem nun aus einem Backup kommt oder man alles komplett neu baut, geht aus den Meldungen nicht hervor.
Wie wird der Angriff eingeordnet?
In vielen Artikeln liest man Beschwichtigungen: Die Luftsicherheit sei zu keiner Zeit beeinträchtigt gewesen und überhaupt sei der Angriff ja gar kein Angriff auf Flughäfen gewesen, die seien ja nur indirekt betroffen, ein Kollateralschaden quasi.
In einer Zeit, in der ständig russische Flugzeuge an Orten auftauchen, wo sich nicht hingehören, sind diese Beschwichtigungen sicher auch sinnvoll.
Das mit der Luftsicherheit ist glaubwürdig; die Passagierabfertigung ist wirklich weit entfernt von Software, die die Luftsicherheit beinträchtigen könnte. Aber: Collins entwickelt auch Software-Lösungen z.B. für Cockpit, Antrieb und Fluglotsen.
Das mit dem Kollateralschaden bleibt eine These. Klar, es könnte eine rein wirtschaftlich intressierte Ransomware-Bande gewesen sein, dann ist ein Luftfahrtunternehmen genauso ein Zufallstreffer wie eine Gummibärchenfabrik. Aber: Auch wenn das Ziel tatsächlich das Lahmlegen von Flugverkehr war, wäre ein Software-Anbieter für Flughäfen eine aus Angreifersicht gute Wahl.
Genauere Betrachtung des Produktsicherheitsvorfalls
Unabhängig davon, ob die Auswirkungen auf die Flughäfen nun beabsichtigt waren oder nicht: Aus Betreibersicht bleibt das Ganze ein Supply-Chain-Vorfall, bei dem ein Angriff auf einen Software-Lieferanten zu Auswirkungen beim Betreiber geführt hat.
Und in jedem Fall ist es ein Produktsicherheitsvorfall. Wäre der CRA schon in Kraft, müsst Collins Aerospace nun eine Meldung an die ENISA machen, mindestens mal für einen “severe incident”, vielleicht auch für eine “actively exploited vulnerability”.
In der offiziellen Meldung von RTX bestätigt RTX bemerkenswerterweise explizit einen “product cybersecurity incident involving ransomware on systems that support its Multi-User System Environment (“MUSE”) passenger processing software”.
Laut Collins-Website kann cMUSE in der Cloud, OnPremise oder Hybrid genutzt werden; es gibt aber keine Informationen dazu, welches Modell die betroffenen Flughäfen gewählt haben.
In der RTX-Meldung heißt es, die MUSE-Systeme würden bei den Flughäfen in eigenen Netzwerken betrieben, “außerhalb des RTX Enterprise-Netzwerks”. Das klingt nach einer On-Premise Installation.
Die wirklich spannende Frage aus Sicht der Produktsicherheit bleibt damit unbeantwortet: Wie ist die Ransomware auf “unterstützende Systeme” für die MUSE-Software zu den Installationen der Collins-Software in den vier Flughäfen gekommen?
Wüssten wir das, wüssten wir auch, wie viel Sorgen wir uns um die anderen, aus Angreifersicht möglicherweise interessanteren, Produkte von Collins Aerospace machen müssen. Dabei sind immerhin so Kleinigkeiten wie Navigation, Kommunikation, Radar und Zielsysteme für Militärflugzeuge.
Update am 03.11.2025: Verstolpertes Vorfallsmanagement?
Mittlerweile hat sich die Hackergruppe Everest zum Vorfall geäußert. Und offenbar ist die Antwort auf die obenstehenden Frage (wie führt Ransomware beim Mutterkonzern zum Ausfall der On-Premise-Produktinstanzen an den Flughäfen?!) viel banaler als gedacht.
Aber von vorn.
Im Kommunikations-Vakuum seitens Collins / RTX hat die Hackergruppe Everest, die behauptet, hinter dem Angriff zu stecken, ihr Vorgehen erklärt.
Die Bezeichnung “Ransomware” ist demnach nur im weiteren Sinne korrekt. Everest habe nämlich keine Daten verschlüsselt, sondern über einen mit schwachem Passwort versehen FTP-Zugang heruntergeladen und Collins damit erpresst, diese Daten zu veröffentlichen. Daraufhin hat Collins die Systeme, statt Lösegeld zu zahlen, offenbar ganz heruntergefahren.
Wenn diese Version stimmt (eine Hackergruppe steht nicht ganz oben auf der Liste der vertrauenswürdigen Quellen), war der Vorfall — wie so oft — ziemlich banal:
Ein schwaches Passwort für einen FTP-Zugang ermöglichte Datenklau, die Angreifer haben mit Datenleak gedroht, daraufhin hat das erpresste Unternehmen die Systeme selbst offline genommen (das Datenleck damit aber nicht verhindert).
Kein fancy Hack. Kein “sophisticated attacker”. No zero days needed. Aber auch kein gutes Vorfallsmanagement seitens Collins:
Die Kommunikation den Angreifern überlassen, die Auswirkungen auf die Nutzer nicht verhindert, sondern verschlimmbessert. Denn zusätzlich zum Datenleck gab es auch noch Systemausfälle on top.
Also, wie kam die Ransomware in die On-Premise-Produktinstanzen? Wenn die Berichte der Everest-Gruppe stimmen, ist die verblüffende Antwort: Gar nicht. Collins hat die Systeme als Reaktion auf die Everest-Erpressung selbst abgeschaltet. Was die Veröffentlichung der bereits abgeflossenen Nutzerdaten natürlich nicht verhindern konnte.
Diese Systemausfälle haben also nicht direkt die Angreifer verursacht, wie die Ransomware-Meldung vermuten ließ, sondern: das verstolperte Vorfallsmanagement seitens Collins.
Dieser Beitrag ist als Teil des monatlichen “Security-Briefing für Hard Hats” erschienen. Hier können Sie es abonnieren.
