In unseren Pentesting- und Red-Teaming-Projekten beobachten wir, dass sich etwas verändert hat in den letzten Jahren: Die Umgebungen sind besser geworden. Mindestens in der Tendenz.

Wo früher das Tiering-Konzept fehlte, ist heute vieles umgesetzt: MFA ausgerollt, Passkeys in der Einführung, dazu LAPS, Conditional Access, AppLocker und ein betreutes EDR. Der Wille ist da – und die Arbeit auch.

Und trotzdem finden wir oft Schwachstellen.

Nicht, weil die Konzepte falsch wären. Sondern weil zwischen „eingeführt“ und „vollständig“ ein Raum liegt, in dem wir uns sehr wohl fühlen. Ein Angreifer sucht nicht die Regel – er sucht ihre Ausnahme. Nicht die abgedeckten 90 %, sondern die restlichen zehn. Diese 10 % sind selten Nachlässigkeit, sondern meist ein Migrationsrest oder eine alte Ausnahme, die niemand zurückgebaut hat.

Was folgt, sind anonymisierte Einblicke aus unseren Projekten der letzten Monate – alle aus Umgebungen mit ordentlichem Sicherheitskonzept.

Ein Gastbeitrag von: MindBytes GmbH

Drei Muster, immer wieder

Drei Muster sehen wir dabei immer wieder:

1. 1. 1. Die Kontrolle greift, aber nicht überall. Der Rollout ist zu 90 Prozent gelaufen, die letzten 10 Prozent hängen an Legacy, an einem Fachverfahren oder an einer OU, die beim Ausrollen nicht im Scope war. Für die Kontrolle ist das ein Restposten. Für uns ist es der Einstieg.
      2. Die Ausnahme ist der Angriffsvektor. Fast jede Kontrolle hat eine Ausnahmeliste. Und fast jede Ausnahmeliste ist gewachsen, nie zurückgebaut und selten dokumentiert. Wir lesen Ausnahmelisten sehr gerne.
      3. Erkennung ohne Konsequenz. Der Alarm existiert – und dann passiert nichts. Audit-Modus statt Enforcement, Report-only statt Block, ein Risiko-Signal, das in einem Dashboard steht, das niemand öffnet.

Jeder folgende Fall gehört zu einem dieser Muster. Nachfolgend erwarten euch Einblicke zu:

• • Entra ID: Die Conditional Access Policy, die fast gehalten hätte
  • MFA ist ausgerollt. Und daneben steht die alte Tür noch offen.
  • Riskante Anmeldungen: erkannt, notiert, ignoriert
  • Spoofing: die eigene Domain als offene Tür
  • Clients: AppLocker mit Türen drin
  • no-ssh.exe: Umbenennung schlägt Erkennung
  • Active Directory: LAPS läuft. Fast überall.
  • Namensauflösung und Relay: der 95-Prozent-Rückbau

Entra ID: Die Conditional Access Policy, die fast gehalten hätte

Unser Kunde hatte sich genau überlegt, welche Anmeldemethoden er zulassen möchte – und welche nicht. Device Code Login wollte er explizit ausschließen.

Zu Recht: Dabei zeigt ein Gerät ohne Tastatur oder Browser, etwa ein Smart-TV oder ein IoT-Gerät, einen Code an, den man auf einem zweiten Gerät bestätigt. Ein bequemer Login-Weg, der sich aber auch hervorragend für Phishing missbrauchen lässt.

Die Ausnahme: Windows-Geräte durften trotzdem per Device Code einloggen, schließlich sollten firmeneigene, verwaltete Rechner mehr dürfen als private Geräte. Nur prüfte die Regel gar nicht, ob ein Gerät wirklich verwaltet wurde. Sie prüfte nur, ob es sich als Windows-System ausgab. Und das lässt sich vom Client frei behaupten. Wir haben uns also kurzerhand als Windows-Gerät ausgegeben, und der Login klappte – wie erwartet. Zumindest von uns.

Warum solche Lücken so schwer selbst zu finden sind, ist strukturell: Im Portal sieht die Policy vollständig und grün aus – was sie am Ende wirklich prüft, steht dort nicht. Im Fall oben sollte sie verwaltete Windows-Geräte bevorzugen, verließ sich dafür aber auf eine Angabe, die der Client frei behaupten kann. Wer Policies liest, prüft die Absicht. Wer sie mit dem Blick eines Angreifers testet, prüft die Wirkung.

MFA ist ausgerollt. Und daneben steht die alte Tür noch offen.

Die häufigste Auffälligkeit in diesem Bereich ist nicht fehlende MFA, sondern ein unvollständig abgeschalteter Altbestand. Passkeys für die Mehrheit der Belegschaft, phishing-resistent und sauber. Und parallel dazu:

• • ein Dienstkonto, das noch mit Benutzername und Passwort authentifiziert, weil ein Fachverfahren nichts anderes kann
  • Legacy-Authentifizierung, die für eine Anwendung freigeschaltet wurde und nie wieder zur Diskussion stand
  • SMS oder Telefonanruf als aktive Methode neben dem Passkey, weil beim Rollout niemand die alten Methoden entfernt hat

Der letzte Punkt ist der unterschätzte: Solange eine schwächere Methode registriert bleibt, zählt die schwächste Option, nicht die beste. Ein Passkey macht den Login phishing-resistent. Ein danebenstehender SMS-Code macht ihn wieder verhandelbar. Fertig ist der Rollout erst, wenn die alten Verfahren nicht mehr zugelassen sind.

Riskante Anmeldungen: erkannt, notiert, ignoriert

Muster 3 in Reinform. Identity Protection meldet zuverlässig Auffälligkeiten wie unmögliche Ortswechsel. In vielen Umgebungen ist die Erkennung an, die Reaktion aber nicht: keine risikobasierte Policy, die bei mittlerem Risiko eine erneute Authentifizierung erzwingt, kein automatisches Zurücksetzen bei hohem Benutzerrisiko, keine Alarmierung, die jemanden erreicht.

Spoofing: die eigene Domain als offene Tür

Eine Schwachstelle, die wir überraschend oft sehen – und ein schönes Beispiel dafür ist, wie schwer „vollständig“ hier zu erreichen ist: Absenderfälschung auf der eigenen Domain. SPF, DKIM und DMARC sind fast überall eingeführt. Und trotzdem lässt sich in vielen Tenants eine Mail verschicken, die aussieht, als käme sie vom eigenen Vorstand.

Das Schlüsselwort: Direct Send. Der aktuell meistgenutzte Weg, Microsoft selbst hat im Januar 2026 davor gewarnt (Quelle). Exchange Online nimmt solche Mails teils ohne Authentifizierung an. So lässt sich eine intern wirkende Nachricht versenden, die an sämtlichen Schutzmechanismen vorbeiläuft.

Was diese Schwachstelle so lehrreich macht, ist ihre Hartnäckigkeit. In einem unserer Projekte mussten die Administratoren dreimal nachbessern, bis das Spoofing tatsächlich unterbunden war.

Clients: AppLocker mit Türen drin

AppLocker ist ein gutes Beispiel dafür, wie eine richtige Maßnahme durch ihre Betriebsrealität verwässert wird. Die Regeln sind da. Und dann:

Pfad-Ausnahmen, die beschreibbar sind. Der Klassiker ist eine Allowlist-Regel für ein ganzes Systemverzeichnis, in dem auch Ordner liegen, in die ein normaler Benutzer schreiben darf. Wir müssen keine Regel brechen – wir legen unsere Datei einfach dort ab, wo sie erlaubt ist.

Ausnahmen für Softwareverteilung, Backup und Fachanwendungen. Fast immer vorhanden, fast immer großzügig, fast nie überprüft.

Fehlende DLL-Regeln. Sie sind standardmäßig nicht aktiv und bleiben es oft, weil sie Aufwand kosten. Das ist eine legitime Abwägung – nur ändert sie die Aussage der Maßnahme grundlegend. Wer ausführbare Dateien kontrolliert, aber DLLs auslässt, kontrolliert nicht, welcher Code läuft, sondern nur, wie er verpackt ist.

Der Audit-Modus als Dauerzustand. Muster 3. Im Reporting sieht ein Audit-Modus aus wie eine greifende Kontrolle. Beim Ausführungsversuch ist er eine Notiz.

no-ssh.exe: Umbenennung schlägt Erkennung

Manchmal sind es die simpelsten Testfälle, die viel verraten. Während das EDR die Ausführung von ssh.exe erkannt hätte, hat die Umbenennung der Datei in „no-ssh.exe“ diese Erkennung komplett ausgehebelt. Das wirft Fragen auf, vor allem, wenn man ein externes SOC dafür bezahlt.

Active Directory: LAPS läuft. Fast überall.

LAPS ist eine der wirksamsten Maßnahmen gegen laterale Bewegung. Deshalb schmerzt es besonders, wie oft der Rollout unvollständig ist. Zwei typische Fälle:

• • ausgerollt auf Clients, nicht auf Servern
  • eine OU beim Ausrollen nicht im Scope, weil dort „Sonderfälle“ liegen

Hinter einer solchen Lücke wartet der alte Zustand: ein lokales Administratorpasswort, das oft auch auf anderen Systemen gilt. Das genügt uns häufig schon für die laterale Bewegung.

Namensauflösung und Relay: der 95-Prozent-Rückbau

Ein Bereich, in dem Teilabdeckung teuer ist, ist die Namensauflösung. Schwache Fallback-Protokolle wie LLMNR, NetBIOS und – gern vergessen – mDNS gehören abgeschaltet. Meist ist das per Gruppenrichtlinie angestoßen, aber nicht überall: nicht in jeder OU, nicht auf Altsystemen. Uns genügt ein Client, der noch antwortet – dann fangen wir über einen Poisoning-Angriff Anmeldedaten ab.

Was wir damit abfangen, führt direkt zum zweiten Punkt: NTLM-Relay. Microsoft baut NTLM schrittweise zurück. In der Praxis laufen Relay-Angriffe trotzdem weiter, etwa durch Ausnahmen für Legacy-Systeme oder durch Richtlinien, die zwar gesetzt, aber nie verifiziert wurde.

Beide Male dasselbe Bild: Der Angriffspfad braucht kein flächendeckendes Versäumnis. Er braucht ein einziges System.

Fazit: Abdeckung schlägt Raffinesse

Keine der Schwachstellen in diesem Artikel beruht auf einer Zero-Day-Lücke oder besonders ausgeklügelten Techniken. Sie beruhen alle darauf, dass eine richtige Maßnahme nicht ganz fertig war.

Das ist keine schlechte Nachricht. Es heißt, dass der aufwändige Teil – die Entscheidung, das Konzept, der Rollout – bereits erledigt ist. Was fehlt, ist die Fleißarbeit: nachsehen, ob es überall gilt. Ausnahmelisten mit Ablaufdatum versehen. Vom Audit- in den Enforce-Modus wechseln. Und die eine Frage stellen, die im Konzept nicht steht: Wo genau gilt das hier nicht?

Härtung und Realitätscheck sind keine Gegensätze, sondern zwei Schritte derselben Arbeit. Das Konzept sagt, wie es sein soll. Der Test sagt, wo es schon so ist. Beides ergänzt sich.

Zum Mitnehmen: 7 Fragen für das nächste Security-Meeting

1. 1. 1. Für wie viele Konten greift unsere stärkste MFA-Methode und welche schwächeren Methoden sind daneben noch registriert?
      2. Welche Ausnahmen haben unsere Conditional-Access-Policies und wer hat sie wann zuletzt bestätigt?
      3. Ist Direct Send bei Exchange Online abgeschaltet?
      4. Was passiert automatisch, wenn Identity Protection ein hohes Benutzerrisiko meldet?
      5. Auf wie vielen Systemen ist LAPS nicht aktiv?
      6. Welche Systeme nutzen noch LLMNR, NBT-NS oder mDNS?
      7. Welche Pfade sind in AppLocker erlaubt, in die ein normaler Benutzer schreiben darf?

Wann sich Pentest oder Red Teaming bei euch lohnt und wie so ein Projekt abläuft, besprechen wir gerne mit euch.

____

Über die MindBytes GmbH:

Pentesting. Red Teaming. Mit Wirkung. Von Menschen für Menschen.
Wir starten mit eurem Worst-Case: Was ist das Schlimmste, was hier passieren kann? Die Ergebnisse machen wir greifbar – für Techie bis Management. Ein Pentest allein macht euch nicht sicherer. Eure Leute schon. Deshalb kombinieren wir Pentest und Schulung, nachhaltig und praxisnah. ISO 27001 zertifiziert. 100 % Spezialisierung auf Offensive Security.