Microsoft rüstet Brute-Force-Schutz von Administratorkonten für Windows nach

Windows[English]Microsoft hat mit dem Oktober-Update (11. Oktober 2022) eine Gruppenrichtlinie für alle unterstützten Windows-Versionen nachgerüstet, die lokale Administratorkonten vor Brute-Force-Angriffen schützen soll. Damit soll eine der heute zu den drei häufigsten Angriffsmethoden auf Windows-Rechner gehörende Angriffsmethode erschwert werden. Denn Administratoren können über die Gruppenrichtlinie vorgeben, dass ein Administratorkonto nach einer gewissen Anzahl Anmeldeversuche gesperrt werden soll.


Anzeige

Administratoren-Konten können auf Windows-Systemen nicht ohne weiteres gesperrt werden. Ohne die richtige Netzwerksegmentierung oder das Vorhandensein eines Intrusion Detection Service sind daher unbegrenzten Brute-Force-Angriffen auf Administratorkonten von Windows zur Ermittlung des Passworts möglich. Diese Angriffe können per RDP über das Netzwerk geschehen. Wenn die Passwörter nicht lang oder komplex sind, wird die Zeit, die für einen solchen Angriff benötigt wird, mit modernen CPUs/GPUs trivial. Daher gehören heute Brute-Force-Angriffe zu den drei häufigsten Angriffsmethoden auf Windows-Rechner.

Windows Brute Force protection for administrator accounts

Bereits im Juli hatte David Weston von Microsoft in einem Tweet darauf hingewiesen, dass Windows 11-Builds über eine Kontosperrrichtlinie verfügen, um RDP und andere Brute-Force-Passwort-Angriffe zu erschweren. Nun hat Microsoft dieses Sicherheitsfunktion auf ältere Windows-Versionen zurück portiert. Dies geht aus dem Support-Beitrag KB5020282—Account lockout available for local administrators vom Oktober 2022 hervor.

Um weitere Brute-Force-Angriffe/Versuche zu verhindern, hat Microsoft die Möglichkeit für Kontosperren für Administratorkonten unter Windows eingeführt. Sobald das kumulativen Sicherheitsupdate vom 11. Oktober 2022 oder später für die betreffende Windows-Version installiert wurde, steht eine entsprechende lokale Richtlinie zur Verfügung. Mit dieser können lokale Administratorkonten gesperrt werden. Diese Richtlinie finden Sie unter

Richtlinien für Lokaler Computer\Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Kontenrichtlinien\Kontosperrungsrichtlinien.

Windows Brute Force protection for administrator accounts (GPO)

Dort ist die Richtlinie Sperrung des Administratorkontos zulassen verfügbar, um das Sperren von Administratorkonten auf Systemen mit einem lokalen oder Domänen-GPO zu aktivieren.  Microsoft schlägt zudem vor, die drei anderen Richtlinien unter Kontosperrungsrichtlinien anzupassen und deren Wert 10/10/10 einzustellen. Dies bedeutet, dass ein Konto nach 10 fehlgeschlagenen Versuchen innerhalb von 10 Minuten gesperrt wird und die Sperrung 10 Minuten lang andauert.

Bei Windows 11 22H2-Systemen oder Systemen mit älteren Windows-Versionen, die die kumulativen Windows-Updates vom 11. Oktober 2022 im Installationsmedium enthalten, wird diese Einstellung bei der Installation standardmäßig festgelegt. Dies geschieht, wenn die SAM-Datenbank zum ersten Mal auf einer neuen Maschine instanziiert wird. Sollen diese Vorgaben nicht angewandt werden, lässt sich die Richtlinie "Sperrung des Administratorkontos zulassen" auf deaktiviert setzen.


Anzeige

Wurde eine Maschine eingerichtet, und das Oktober-Updates erst später installiert, müssen die Richtlinieneinstellungen manuell vorgenommen werden. Microsoft erzwingt zudem auf neu installierten Rechnern eine gewisse Passwort-Komplexität für lokalesAdministratorkonten. Das Kennwort muss mindestens drei der vier grundlegenden Zeichentypen enthalten (Kleinbuchstaben, Großbuchstaben, Zahlen und Symbole). Dies trägt dazu bei, dass diese Konten nicht durch einen Brute-Force-Angriff kompromittiert werden können.

Wer ein weniger komplexes Kennwort verwenden möchte, kann die entsprechenden Kennwortrichtlinien unter

Richtlinien für Lokaler Computer\Computerkonfiguration\Windows-Einstellungen\Sicherheitseinstellungen\Kontenrichtlinien\Kennwortrichtlinie

festlegen. Die obigen Richtlinien gelten für folgende Windows-Versionen:

  • Windows Server 2008 / R2 ESU
  • Windows 7 Enterprise ESU
  • Windows 7 Professional ESU
  • Windows 7 Ultimate ESU
  • Windows 8.1
  • Windows RT 8.1
  • Windows Server 2012 /R2
  • Windows 10 Windows 10
  • Windows Server 2016
  • Windows 11
  • Windows Server 2022

Weitere Details sind bei Bedarf dem Microsoft-Beitrag KB5020282—Account lockout available for local administrators  zu entnehmen.


Cookies blockieren entzieht uns die Finanzierung: Cookie-Einstellungen

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

14 Antworten zu Microsoft rüstet Brute-Force-Schutz von Administratorkonten für Windows nach

  1. BrunoK sagt:

    Ich hab das versucht.
    GPOs auf dem DC eingerichtet, geprüft dass der Zielserver diese auch erhalten hat.

    Der lokale Admin Account wird zwar korrekt nach den definierten Anzahl versuchen gelockt – aber nicht für eine gewisse Zeit.
    Heisst, ich melde mich zB 5x mit dem lok. Admin an, versuche dann weiter mit falschem Passwort. Ueber einen anderen Server kann ich sehen, dass der lok. Admin gelockt ist nach 5 Versuchen. Sobald ich mit dem korrekten Passwort anmelde, kann ich mich anmelden. Also ohne Lockout-Wartezeit die in den GPOs definiert ist.
    Hat das jemand auch schon beobachtet ?

    • Luzifer sagt:

      Ist doch auch OK. Du sollst als Angreifer ausgesperrt werden und mit falschem PW auch eine zeitliche Sperre für weitere Versuche kriegen.

      Nur der richtige User mit richtigem PW soll dadurch ja nicht ausgesperrt werden, sonnst könntest du ja ne Firma lahm legen in dem du massenweise Ihre Accounts in die Sperre zwingst!

      • Thor sagt:

        Ähm, und dann bruteforce ich weiter bis das richtige PW gefunden ist?
        Finde den Fehler…

        • Anonymous sagt:

          Scheint alles seine Richtigkeit zu haben. Manuelle Anmeldeversuche über "Secure Desktop"-Anmeldedialoge werden von der neuen Sperrmöglickeit NICHT gesperrt, sodass ein echter Administrator nicht mutwillig per DoS-Attacke komplett ausgesperrt werden kann. Nur Remoteanmeldungen per z.B. RDP werden tatsächlich gesperrt.

  2. der bug ist das ziel sagt:

    hammer. und das im jahr 2022. so handelt man jahrzehnte spaeter. kann man sich nur leisten wenn man hunderte milliarden schwerer globaler monopolist ist und narrenfreiheit geniesst.

  3. Bernd Bachmann sagt:

    Normalerweise macht man das doch so: Nach jedem fehlgeschlagenen Anmeldeversuch verdoppelt sich die Zeit, bis man das nächste Mal probieren darf.
    Aber warum einfach, wenn's auch umständlich geht.

  4. Anonymous sagt:

    Also hier in einer Umgebung unter Windows Server 2016 funktioniert diese neue Funktion per Domain-GPO jedenfalls nicht.

    Der Domain Controller in dieser Umgebung ist ein durchgepatchter Windows Server 2016. In die "Default Domain Policy" wurden Werte für alle vier Einstellungspunkte unter "Kontosperrichtlinien" eingetragen.

    Der "Test-PC" ist ebenfalls ein durchgepatchter Windows Server 2016. RSoP.msc meldet auf dem "Test-PC" für die drei altbekannten Einstellungspunkte, die Werte aus der "Default Domain Policy" (in diesem Fall 6 / 6 / 6) – nur beim Punkt "Sperrung des Administratorkontos zulassen" steht in RSoP "Nicht definiert" und unter "Quell-Gruppenrichtlinienobjekt" steht gar nichts…

    Ich kann hier auch weiterhin so häufig falsche lokale Adminpasswörter eintippen, wie ich nur will, hier wird nichts temporär gesperrt…

    Nach ein paar Fehlversuchen kommt in der Konsolenanmeldung nur die altbekannte Verzögerung von 30 Sekunden – aber diese 30-Sekunden-Strafzeit ist da bestimmt schon seit mindestens Windows Server 2012R2-Zeiten.

    Kann das jemand bestätigen, dass unter Windows Server 2016 das lokale Administrator-Konto nicht temporär gesperrt wird?

    • BrunoK sagt:

      Bei mir wirds zwar gesperrt, sobald aber das korrekte Passwort eingegeben wird, erfolgt die Anmeldung am Server. Ohne die Zeitverzögerung die eingestellt wäre. (Server 2019) – siehe erster Kommentar von mir.

      • Anonymous sagt:

        Hier kurz ein wichtiges technisches Detail:

        Die Sperre der lokalen Administratorkonten betrifft NICHT den manuellen Windows-Anmelde-Dialog direkt am Computer. Alle "Remote-Anmeldewege" werden für die konfigurierte Zeit blockiert (also zum Beispiel für 10 Minuten nach 10 Fehlversuchen). Anmeldungen über RDP sind dann also zum Beispiel für 10 Minuten nicht mehr möglich.

        Wenn man sich aber direkt am Computer mit dem richtigen Passwort anmeldet, wird diese Sperre des lokalen Administratorkontos SOFORT aufgehoben! Man ist dann sofort angemeldet. Zudem hat man dann auch sofort wieder mehrere Einwahlversuche für die Remote-Anmeldung (also zum Beispiel direkt wieder 10 Versuche für die RDP-Anmeldung frei).

        Ich habe es jetzt nicht weiter verfolgt, aber ich denke mal, dass alle "Secure Desktop"-Anmeldedialoge von der Sperre NICHT betroffen sein werden.

        BTW: Die RSoP-Anzeige ist im Moment wohl tatsächlich noch falsch…

  5. Mark Heitbrink sagt:

    aaaaaaaaAaAaaaaAaaaaaa .. was für ein Quatsch.
    Danke Microsoft. DoS Attacke fur Doofe..
    System zerlegen für Anfänger.

    script loop. 2 Zeiler, zack kaputt.

  6. Blackii sagt:

    Moin,

    da sehe ich doch potenzial, meine Kollegen zu ärgern ;)

    MfG,
    Blackii

  7. Kore sagt:

    Hallo!
    Stimmt es, dass diese Richtlinien auf einem Windows (10 pro Non-Domain Client; privates Gerät), bei dem der lokale Administrator-Account mit einem MS-Konto verknüpft ist, nicht konfiguriert werden können?
    Die Richtlinien sind zwar da, aber ausgegraut / nicht veränderbar.
    Gibt es da ev. manuelle Registry-Settings?

  8. Cornelia sagt:

    Meiner Meinung wurde die Richtlinie nur halbherzig umgesetzt. Mit separaten Einstellungen könnte eine solche Regel durchaus auch für das Login beim "Secure Desktop" bzw. an der Konsole gelten und nicht nur für RDP, Scripts etc.

    Hand aufs Herz: Welcher berechtigte Admin braucht 5-10 oder mehr Versuche, um sich an einem Server oder PC anzumelden, ausser vielleicht wenn das Tastaturlayout unbewusst falsch ist oder jemand anders das Passwort zuvor geändert hat?
    Bei einem Server mag eine längerfristige Sperre (20-30 Minuten) zwar üble Konsequenzen haben. Sofern die Sperre aber erst nach 15 oder 20 Versuchen greift, fände ich das einigermassen vertretbar – oder eine Sperre von 5 Minuten nach 8-12 Versuchen. Selbst bei einem PC mit nur einem lokalen Admin kann man sich fragen, ob eine vorübergehende Sperre nicht auch angebracht wäre.

    Der Vorschlag von Bernd Bachmann ist vom Ansatz her auch vertretbar, eine unbegrenzte Verdoppelung der Sperrzeit wäre jedoch nicht praktikabel.

Schreibe einen Kommentar

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.