KW 05/2026: Wenn Authentifizierung zum Risiko wird

Wenn ich diese Woche die Security-News durchgehe, fällt mir ein Muster auf: Alles dreht sich um Vertrauen – und wie leicht es verspielt wird. Egal ob Microsoft NTLM endlich in Rente schickt, ShinyHunters Single Sign-On (SSO) aushebeln oder offene MongoDBs weiter für Lösegeld missbraucht werden – am Ende geht es immer um Identität, Kontrolle und, ehrlich gesagt, basics, die immer noch nicht überall umgesetzt sind. Für Unternehmen in Aachen, NRW und darüber hinaus zeigt diese Woche vor allem eins: Wer jetzt nicht nachzieht, sitzt bald in der Authentifizierungs-Falle.

Microsoft verabschiedet sich von NTLM – endlich, aber mit Folgen

Microsoft hat angekündigt, NTLM künftig standardmäßig zu deaktivieren. Laut BleepingComputer betrifft das alle zukünftigen Windows-Versionen. Damit geht nach über 30 Jahren eines der ältesten Authentifizierungsprotokolle in den Ruhestand. Technisch gesehen ist das längst überfällig. NTLM war nie für moderne, hybride Umgebungen gedacht und hat bekannte Schwächen – von Pass-the-Hash-Angriffen bis zu fehlender Unterstützung für zeitgemäße Sicherheitsmechanismen.

Was bedeutet das in der Praxis? Unternehmen müssen prüfen, wo noch NTLM-Authentifizierung genutzt wird – oft unauffällig in Legacy-Anwendungen, alten Druckservern oder bei bestimmten Drittanbieter-Tools. Microsoft empfiehlt den Wechsel zu Kerberos oder noch besser zu modernen Token-basierten Verfahren wie OAuth2 beziehungsweise 'Modern Authentication'. Klingt einfach, ist es aber nicht. Viele Organisationen haben über Jahre Workarounds aufgebaut, die eng an NTLM hängen. Ein abrupter Abschalttermin könnte reihenweise Anwendungen lahmlegen.

Ehrlich gesagt: Es ist schon bemerkenswert, dass wir 2026 noch über NTLM reden müssen. Aber es zeigt, wie träge Migrationsprojekte bei Authentifizierung sind. Für Unternehmen in der Städteregion Aachen, wo oft Spezialsoftware aus Produktion, Bau oder Maschinenbau eingesetzt wird, kann das zu echten Herausforderungen führen. Wer jetzt proaktiv Inventuren fährt, Abhängigkeiten dokumentiert und gestaffelte Rollouts plant, wird später weniger Stress haben. Wer es verschläft, steht irgendwann vor der Wahl: Sicherheit oder Betriebsfähigkeit.

Und das führt uns direkt zum nächsten Thema – dort geht es nämlich auch um Authentifizierung, nur diesmal auf ganz andere Weise.

ShinyHunters schlagen mit SSO-Vishing zu – Social Engineering in Reinform

Laut einem aktuellen Bericht von BleepingComputer und Mandiant hat die bekannte Hackergruppe ShinyHunters begonnen, SSO-Portale gezielt mit Vishing und Phishing anzugreifen. Dabei rufen die Täter Mitarbeiter an, geben sich als interner IT-Support aus und locken die Opfer auf täuschend echt nachgebaute Login-Seiten ihrer eigenen Firmen. Dort greifen sie die Single-Sign-On-Zugangsdaten ab und nutzen sie, um auf Cloud-Speicher, SaaS-Plattformen und interne Tools zuzugreifen. Danach wird alles heruntergeladen, was wertvoll erscheint. Häufig inklusive vertraulicher Daten aus Jira, Slack oder SharePoint.

Das Perfide: Der Angriff nutzt keine klassischen technischen Schwachstellen. Er missbraucht Vertrauen – sowohl menschliches als auch technisches. Viele Unternehmen verlassen sich auf SSO als Allheilmittel: ein Login, volle Kontrolle. Was viele dabei vergessen, ist die Schattenseite. Wenn ein Angreifer einmal das Ticket bekommt, hat er eben auch vollen Zugriff – quer durch alle Systeme. Besonders kritisch wird es, wenn keine starke Multi-Faktor-Authentifizierung aktiv ist oder wenn die zweite Stufe zu leicht ausgetrickst werden kann.

Aus meiner Sicht zeigt der Vorfall, dass wir mehr über Phishing-Resilienz als über Technik reden sollten. Schulungen, kontinuierliches Security-Monitoring und intelligente Session-Überwachung sind hier der Schlüssel. Es reicht nicht, nur technische Barrieren aufzubauen, wenn der Mensch sie mit einem Anruf umgehen lässt. Und wer SSO-Implementierungen ohne penible Protokollüberwachung betreibt, hat eigentlich gar kein zentrales Identity-Management, sondern eine zentrale Schwachstelle eingerichtet.

Auch in der Praxis hier in Aachen sehe ich das: Viele Unternehmen nutzen SSO-Lösungen über Azure AD, Okta oder Google Workspace – aber kaum jemand überwacht aktiv, von wo und wie sich Nutzer anmelden. Dabei wären verdächtige Login-Orte oder Sitzungsanomalien ein klarer Hinweis auf Missbrauch. Nur: Wer schaut schon regelmäßig ins Audit-Log? Leider: fast niemand.

MongoDB – der Klassiker der Fehlkonfigurationen lebt weiter

Und dann ist da noch die dritte Baustelle: Exposed MongoDB-Instanzen werden weiterhin massenhaft für Erpressungsversuche missbraucht. Laut BleepingComputer scannen Angreifer automatisiert nach offenen NoSQL-Datenbanken im Internet, löschen Daten und hinterlassen eine Lösegeldforderung à la: „Schicken Sie Geld, dann bekommen Sie Ihre Daten zurück.“ Ob diese Drohung überhaupt realistisch ist, sei dahingestellt – meist haben die Täter die Daten gar nicht vollständig kopiert. Das eigentliche Problem: Offene Ports, fehlende Authentifizierung und keine Backups.

Seit Jahren wird vor genau dieser Konfiguration gewarnt. Trotzdem sind immer wieder tausende MongoDBs ungeschützt online erreichbar. Das ist die digitale Variante von „Bürotür auf, Serverraum offen, bitte bedienen Sie sich“. Die technischen Ursachen sind banal: Default-Installationen ohne Authentifizierung, unbedachte Cloud-Deployments oder Admins, die Firewalls deaktivieren, um „es kurz mal einfacher zu machen“.

Was mich daran stört, ist die Wiederholung. Wir reden nicht über Zero-Day-Lücken oder hochtechnische Exploits. Wir reden über Grundlagen. Und wenn grundlegende Schutzmaßnahmen immer noch ignoriert werden, muss man sich fragen, ob Security-Awareness überhaupt ankommt. Für kleine Unternehmen in NRW, die mit Cloud-Anwendungen arbeiten, sind falsch konfigurierte Datenbanken ein echtes Risiko. Angreifer haben es hier leicht: einmal scannen, gefunden, gelöscht – und der Schaden ist da.

Technisch wäre die Lösung simpel: Authentifizierung aktivieren, Netzwerke isolieren, regelmäßige Backups und Monitoring. Aber weil keiner die Verantwortung zentral übernimmt, bleibt es oft bei guten Vorsätzen.

Was jetzt zu tun ist

Die drei Themen dieser Woche sind sehr unterschiedlich – aber im Kern geht es immer um Identitäts- und Zugriffskontrolle. Deshalb ist der wichtigste Schritt, die eigene Authentifizierungslandschaft kritisch zu prüfen. Unternehmen sollten jetzt beginnen, sämtliche Altsysteme auf NTLM-Abhängigkeiten zu scannen. Microsoft selbst bietet dafür Tools wie den „Authentication Mechanism Audit“. Wer erst wartet, bis das Update NTLM endgültig deaktiviert, riskiert Betriebsunterbrechungen.

Für SSO gilt: Sicherheit entsteht nicht durch Bequemlichkeit. Prüfen Sie, ob überall Multi-Faktor-Authentifizierung wirklich aktiv ist, und schulen Sie Mitarbeiter regelmäßig zu Social-Engineering-Taktiken. Eine Phishing-Mail lässt sich schnell erkennen, ein gut inszenierter Vishing-Anruf eher nicht.

MongoDB-Instanzen sollten auf keinen Fall direkt aus dem Internet erreichbar sein. Falls doch, muss Authentifizierung sofort aktiviert und der Zugriff auf bekannte Netze beschränkt werden. Backups gehören offline gesichert und regelmäßig getestet – nicht nur angelegt. Darüber hinaus empfehle ich, Logdaten an zentralen Ort weiterzuleiten, um Anomalien früh zu erkennen.

Speziell für Unternehmen in der Städteregion Aachen kann man es so zusammenfassen: Authentifizierung ist kein Nebenthema mehr, sondern einer der größten Hebel für IT-Sicherheit. Ob im Mittelstand oder in Forschungsumgebungen – überall, wo Identitäten digital verwaltet werden, entscheidet die Umsetzung über Vertrauen oder Chaos.

Mein Fazit

Diese Woche zeigt exemplarisch, wie unterschiedlich, aber gleichzeitig verwoben moderne Sicherheitsrisiken sind. Microsoft zieht endlich die Reißleine bei NTLM, Angreifer umgehen SSO durch psychologische Tricks, und NoSQL-Systeme werden weiter durch triviale Fehlkonfigurationen kompromittiert. Drei Seiten derselben Medaille: unzureichend gepflegte Identitätsmechanismen.

Die gute Nachricht: Es liegt alles in unserer Hand. Migrationen können geplant, SSO kann gehärtet und Datenbanken können geschlossen werden. Die schlechte: Das erfordert Zeit, Aufmerksamkeit und Verantwortungsbewusstsein – Dinge, die im IT-Alltag oft fehlen. Ehrlich gesagt, wer bis heute NTLM-Only-Systeme betreibt oder seine MongoDB ohne Passwort laufen hat, sollte jetzt nicht nur patchen, sondern strategisch neu denken.

Falls Sie unsicher sind, ob Ihre Umgebung betroffen ist oder Sie Unterstützung bei der Migration oder Security-Härtung benötigen – melden Sie sich gern. Ein gezielter Security-Check spart langfristig Zeit, Geld und Nerven. Besser jetzt investieren als später die Folgen eines Angriffs tragen.