Microsoft brengt bescherming tegen brute-forceaanvallen op adminaccounts uit

Microsoft introduceert een optie om met inlogpogingbeperkingen administratoraccounts te beschermen tegen brute-forceaanvallen. De nieuwe optie is onderdeel van de Oktober-update voor Windows 11.

Tot dusver is het mogelijk om met een brute-forceaanval oneindig veel inlogpogingen te doen op een lokaal adminaccount, wat Microsoft met update KB5020282 wil voorkomen. Met een nieuwe policy kunnen ook adminaccounts voortaan tijdelijk 'op slot' gezet worden, waardoor er geen inlogpogingen meer mogelijk zijn. Dit kan onder de instelling Computer Policy\Computer Configuration\Windows Settings\Security Settings\Account Policies\Account Lockout Policies.

Microsoft zegt over de nieuwe Account Lockout Policies: "We raden aan om '10/10/10' in te stellen. Dit betekent dat accounts op slot gezet worden na tien gefaalde loginpogingen binnen tien minuten. De maatregel duurt tien minuten, waarna het account automatisch weer gedeblokkeerd wordt." Administrators zijn vrij om de parameters van de brute-forcebescherming aan te passen, bijvoorbeeld door het automatisch deblokkeren van een adminaccount uit te schakelen of door het aantal inlogpogingen verder te beperken.

Nieuwe systemen met Windows 11 of pc's die in aanmerking komen voor de cumulatieve update van 11 oktober 2022 hebben de 10/10/10-verhouding als standaardinstelling. Voor alle andere systemen moeten de bovenstaande stappen gevolgd worden om de policy in te schakelen. De functie was al langer beschikbaar voor alle andere soorten accounts op een Windows-systeem, maar lokale administrators vielen hier tot dusver niet onder.

Reacties (54)

[Lucb1e]

Eerder deze week hadden we het nog over dat admin accounts buiten de lock-out policy vallen, dus dat we niet per ongeluk het hele bedrijf lam kunnen leggen tijdens een red-teaming als we teveel wachtwoorden zouden proberen en alle admins buitensluiten.

Wel grappig om dit nu te zien.

Tien minuten valt natuurlijk mee, maar een echte aanvaller zou niet zomaar stoppen...
De oplossing is een goed wachtwoord instellen zodat het niet te raden/kraken valt -- en daarmee bedoel ik niet om méér regeltjes te maken voor speciale tekens of zo, maar mensen (admins! Moet lukken toch?) leren hoe je een sterk wachtwoord maakt. Het beste willekeurig genereren, een paar dergelijke wachtwoorden onthouden voor de belangrijkste zaken waaronder een password manager, en de rest in die password manager. Vooral geen wachtwoorden hergebruiken.

Edit: en het niet moeten wijzigen als je niet vermoed dat het gelekt is. Ook deze week was het weer raak met iemand die 'Oktober2022!' als wachtwoord had.

[Reactie gewijzigd door Lucb1e op 25 juli 2024 02:20]

[willieverhoef]

Bedenk ook even dat een aanvaller bewust 10x kan inloggen on te zorgen dat een admin moet wachten en dus 10 min buiten gesloten zit.

[Lucb1e]

Dat is precies wat ik bedoel. En exact het moment dat het account zich unlockt, wat je mooi kan zien want het geeft een andere status terug wanneer het wachtwoord onjuist is dan wanneer het account gelockt is, direct opnieuw 10x fout doen. Scriptje aan en veel succes met controle over je domein terugkrijgen.

Van dergelijke risico's proberen we bedrijven in ieder geval bewust te maken. Voor diegene die dit leuk lijkt: vooral doen om uit te proberen, maar meld het vervolgens wel direct volgens responsible disclosure en blijf het niet herhalen.

[Reactie gewijzigd door Lucb1e op 25 juli 2024 02:20]

[Zomborro]

Scriptje aan en veel succes met controle over je domein terugkrijgen.

Neen.

Dit gaat om een bescherming op Windows 11 niveau en dus niet op Domain / Enterprise admin niveau wat alleen leeft op Domain Controllers. Deze bescherming is er dus vooral op geënt om lokale W11 admin accounts op endpoints, welke eventueel gebruikt kunnen worden voor step-up aanvallen / lateral movement, veiliger te maken.

Domain / Enterprise admin accounts leven alleen op Domain Controllers en deze kunnen by design niet gelocked worden, juist om dit soort scenario's te voorkomen.

[Reactie gewijzigd door Zomborro op 25 juli 2024 02:20]

[Lucb1e]

niet op Domain / Enterprise admin niveau

Oh! Dan heb ik dat fout begrepen, ik zag Windows 11 wel maar er stond ook iets over updates die op de 11e uitkwamen en ik nam aan dat dat ook patches voor servers zouden zijn. Thanks

[Rolfie]

Domain Admins en Enterprise admins kunnen gewoon gelocked worden zonder enige problemen bij design.

Bij een goede inrichting zal je inderdaad wel met het tiering model Enterprise access model het nodige kunnen afschermen.

[Karimpje]

Volgens mij hebben we het hier over een local admin en niet over een domain admin of wat voor andere AD-admin dan ook.
Het artikel gaat specifiek over Windows 11, dus client, lijkt me sterk dat je daarmee het gehele bedrijf plat legt, overigens als het local admin account gelocked is, kan je met je gebruikelijke account nog gewoon inloggen.

[laurens0619]

Mass lockout is idd een lelijke adverse effect van de security lock control

Azure ad heeft dat stukje beter gemaakt door aparte lockout counters bij te houden (hoe precies is magic/secret). Voordeel is dat een aanvaller een lock voor zijn kiezen krijgt terwijl jouw login op hetzelfde account wel werkt

[Lucb1e]

hoe precies is magic/secret). Voordeel is dat een aanvaller een lock voor zijn kiezen krijgt terwijl jouw login op hetzelfde account wel werkt

Dat moet dan kijken naar het IP-adres of andere dingen die je meestuurt zoals het browsertype; zoveel opties zijn er niet.

[laurens0619]

Tegenwoordig best veel
Zo kun je ieder managed device herkennen omdat er een “iscompliant” “domain joined” veld inzit. Hiermee herken je al enorm veel van de corporate devices (ook je mdm managed smartphones).

[Het.Draakje]

Je wilt in een bedrijf geen account "Administrator" of "Beheerder" nodig hebben.

Maak een user: security_manager (geef het alleen een mooiere naam). Die kan dan het administrator account vrijgeven voor programma's die hardcoded door administrator geïnstalleerd moeten worden. Standaard zet je admin als local-login-only en disable.

Beheer voer je uit op persoonlijke accounts met admin-rechten via de beheer-groep.

Daarbuiten: Er zijn wachtwoord-managers die een account (ook die van admin) kunnen beheren. Ik meld me aan en vraag om beheer van server xyz (windows of unix-varianten maakt het systeem niets uit). Krijg netjes het wachtwoord en typ dat in. Jij wil (enige ogenblikken later) dezelfde server benaderen en krijgt van de ww.mngr het antwoord: is in gebruik bij .... Zodra ik klaar ben met mijn beheer werk, meld ik dat af in de ww.mngr en die reset het wachtwoord. En daarna kan jij gewoon het wachtwoord opvragen. (Is al weer wat jaartjes terug dat ik nog werkzaam was, maar IIRC hoefde je zelfs het wachtwoord niet over te tikken bij een windows machine).

Niet moeilijk doen met wachtwoordregels, de ww.mngr regelt dat allemaal netjes zelf. En die heeft absoluut geen moeite met wachtwoorden zoals "aj2$#%7_qQEDV".

En de manager (die persoon die altijd lastig doet) stond de volgende dag gewoon aan je bureau als je vergeten was om de server vrij te geven. (Eerste keer: koffie halen voor de afdeling. Tweede keer: doe er maar gebak bij. Leer je gauw om de boel vrij te geven).

[Bor]

Je wilt in een bedrijf geen account "Administrator" of "Beheerder" nodig hebben.

Maak een user: security_manager (geef het alleen een mooiere naam). Die kan dan het administrator account vrijgeven voor programma's die hardcoded door administrator geïnstalleerd moeten worden. Standaard zet je admin als local-login-only en disable.

Je bedoelt vast wat anders want je spreekt jezelf nogal tegen. Je geeft aan dat je geen Administrator wilt hebben om vervolgens val alles als Administrator of met bijbehorende rechten uit te willen voeren

[Reactie gewijzigd door Bor op 25 juli 2024 02:20]

[Het.Draakje]

Er zijn programma's die alleen onder het account 'administrator' geïnstalleerd kunnen worden. Als beheerder heb je niet altijd de optie om dergelijke rotzooi te weren van het systeem. Door een sec_manager heb je e dan de mogelijkheid om toch even de administrator account op enabled te zetten. Voor de rest staat 'Administrator' altijd op slot.

Je beheertaken (inclusief installatie van fatsoenlijke software) voer je uit onder een ander account met admin privileges. Maar wel - of gepersonaliseerd - of via een gedeeld account wat je onder een ww.mngr (zoals beschreven) laat delen.

[grrfield]

Het gaat over de naam van het account, niet wat de privileges zijn. Hij wil wel een administrator account, maar niet met die naam. Begrijpend lezen?

[Simon Weel]

Je geeft aan dat je geen Administrator wilt hebben

Microsoft heeft een zeer uitgebreide handleiding Best Practices for Securing Active Directory waarin o.a. staat dat je het admin-account alleen gebruikt voor de initiële installatie en 'disaster recovery' en dat je het daarna nooit meer mag gebruiken. Dus daar komt die security manager van @Het.Draakje om de hoek want voor sommige zaken heb je nu eenmaal admin-permissie nodig.

[rammes]

Ik zie liever het gebruik van rechten als je het echt nodig hebt (bij de taak welke je uitvoerd) . Privileged Identity Management

[ZinloosGeweldig]

Edit: en het niet moeten wijzigen als je niet vermoed dat het gelekt is. Ook deze week was het weer raak met iemand die 'Oktober2022!' als wachtwoord had.

Dank je! Ik heb zo'n hekel aan expiration policies, die moedigen alleen slecht wachtwoordbeleid aan.

[PdeBie]

Hangt van de termijn af. Elke maand (ja dat gebeurt) is een ramp en een voorbode voor Oktober2022!. Maar 1x per half jaar bijvoorbeeld is prima.

Het komt alleen nooit uit bij sommige van de gebruikers natuurlijk, dus die zullen alsnog een veel te makkelijk wachtwoord kiezen.

[ZinloosGeweldig]

Ik ben er überhaupt geen voorstander van voor gebruikerswachtwoorden... Ook al doe je een half jaar, gaan veel mensen na een keer of 2/3 toch weer wachtwoorden volgens een patroon kiezen, volgnummers aan een anderzijds prima of in elk geval degelijk wachtwoord toevoegen bijvoorbeeld. En dat is het grootste gevaar m.i.

Want het enige voordeel van ze laten vervallen is dat heimelijk gelekte wachtwoorden niet meer geldig zijn. Maar als het gelekte password een patroon bevatte, dan is het nieuwe password snel gevonden. Je maakt daarmee een password change dus een minder effectief middel tegen daadwerkelijk gelekte wachtwoorden, als je dit soort patronen aanmoedigt.

Als je geen vervalbeleid voert, maar enkel een password change afdwingt wanneer er signalen zijn dat er wachtwoorden gelekt zijn, dan is de password change maatregel waarschijnlijk veel effectiever. Je hebt dan wel een groter risico van heimelijk gelekte wachtwoorden, maar in de meeste gevallen zul je er toch vrij snel signalen van opvangen.

Admin wachtwoorden is een ander verhaal, die rouleer je sowieso maar daar kan je als het goed is een beter wachtwoordbeleid met gegenereerde wachtwoorden voeren.

[Reactie gewijzigd door ZinloosGeweldig op 25 juli 2024 02:20]

[Bor]

Want het enige voordeel van ze laten vervallen is dat heimelijk gelekte wachtwoorden niet meer geldig zijn. Maar als het gelekte password een patroon bevatte, dan is het nieuwe password snel gevonden. Je maakt daarmee een password change dus een minder effectief middel tegen daadwerkelijk gelekte wachtwoorden, als je dit soort patronen aanmoedigt.

Daarom stel je ook niet alleen een wachtwoord beleid in maar voed je mensen ook op door awareness programma's en maak je het melden van (mogelijke) incidenten makkelijk zodat je snel kan inspringen op de zaken die gebeuren.

[TheVivaldi]

Maar dan nog vang je niet iedereen op. Er zijn ook al tig BOB-campagnes geweest om mensen bewust te maken dat ze niet met alcohol achter het stuur moeten kruipen, maar er zijn wekelijks nog altijd teveel mensen die dat wel doen. Zo'n campagne - ook zo eentje omtrent wachtwoorden die jij voorstelt - is beter dan niks, maar afdoende is het nooit.

[Reactie gewijzigd door TheVivaldi op 25 juli 2024 02:20]

[TheVivaldi]

En ook al zou je patronen filteren, zoals bijvoorbeeld ING doet ("Uw nieuwe wachtwoord lijkt teveel op het oude"), dan nog zijn risico's, bijvoorbeeld dat iemand het wachtwoord op een briefje schrijft en dat kwijtraakt.

[Argantonis]

Maar goed, dat probleem heb je natuurlijk ook als je géén wachtwoord changes afdwingt, alleen dan heb je daar óók nog eens het probleem bij dat dat wachtwoord waarschijnlijk ook bij 100 andere services in gebruik is (al dan niet met een 1 of 2 of 2022 erachter)

[jmvdkolk]

Zoals anderen ook opmerken zorgt ook 1x per half jaar voor slecht gedrag. Ikzelf maak mij hier ook schuldig aan. Sinds ik mijn werk-ww iedere 6 maanden moet updaten, kies ik een wachtwoord dat voldoende lijkt op de vorige zodat ik hem makkelijk kan onthouden. Iedere 6 maanden weer een nieuw 16 karakter ww onthouden is te veel moeite. Bovendien moet ik hem dan de eerste 2 weken ergens noteren omdat ik hem niet in 1x onthoud. Opschrijven is natuurlijk absoluut uit den boze. Maar als ik moet kiezen tussen vergeten en password reset aanvragen of noteren (op een min of meer veilige plek), dan weet ik de keuze wel.

[DJMaze]

Inderdaad, of het nou per maand, kwartaal, halfjaar of jaar is, het maakt het zo slecht!
Q1-2022
Winter2022
Wachtwoord2022
Etc.

En dan hebben we het nog niet over de post-it op de monitor omwille van de policies...

[Bor]

Suprise, dergelijke slechte wachtwoorden maken mensen ook zonder verlooptermijn als ze de kans krijgen. Die post-it zie je ook wanneer je wachtwoorden niet laat verlopen.

[Reactie gewijzigd door Bor op 25 juli 2024 02:20]

[avdongen]

Ik ben begonnen met een volledig random password met letters, cijfers, leestekens. Met wat oefenen zit dat best goed tussen de oren. Bij elke gedwongen wijziging verander ik hem een klein beetje, maar elke keer anders. Een extra teken middenin, stukjes een toets op het toetsenbord verschoven, hoofd/kleine letters wisselen, etc. Door de kleine wijziging is dat weer snel te onthouden, maar blijft het een behoorlijk sterk wachtwoord dat niet te raden is en wel snel in te typen (spiergeheugen).

[telenut]

Maar als je zo al meer dan 100 wachtwoorden moet memoriseren begint dit wel aardig lastig te worden... En dan krijg je nog eens een lock op uw account wegens te veel verkeerde pogingen.
Er zitten dan nog eens 5000 wachtwoorden in een wachtwoordmanager ook, maar sommige moet je gewoon van buiten kennen dus.

[Timoo.vanEsch]

https://xkcd.com/936/

[Exoronic]

En dan hebben we het nog niet over de post-it op de monitor omwille van de policies...

Bij die helden pas ik het wachtwoord op de post-it soms een klein beetje aan, sommige hebben het niet eens door.
to many failed login attemps, account 30 minuten locked. zijn ze nog kwaad ook.

hehe good times

[virtualite]

Zoals hierboven benoemd is LAPS een mooie oplossing.

[tweazer]

Raar dat met een lockout de bron niet wordt meegenomen als in te stellen parameter. Max X pogingen vanaf 1 ip adres is IMHO ook nuttig ?

[tweakkjoost]

Voor dit probleem is er ook een optie om RDPguard te installeren op je server. (Google op RDPguard) Werkt uitstekend met handige opties is mijn ervaring.

[Bor]

Het nadeel is dat je weer een extra en zelfs 3rd party tool nodig bent die onderhouden moet worden en waar ook kwetsbaarheden in zitten. In een productieomgeving van een bedrijf zet je doorgaans niet in op oplossingen van dit soort kleine partijen.

[tweakkjoost]

Het voordeel van een 3rd party oplossing is dan weer dat het onderhouden veel makkelijker gaat en minder foutgevoelig is. Verder gebruikt deze oplossing standaard het ingebouwde 'Windows Filtering Platform' dus dat lijkt me behoorlijk robuust.

[Bor]

Waarom is het onderhoud van een 3rd party opllossing makkelijker en minder foutgevoelig? Dat lijkt mij niet aan de orde en meestal niet opgaan. Het is in feite nog een extra pakket om te beheren en een vergroting van het aanvalsoppervlak.

[tweakkjoost]

een 3rd party oplossing is specifiek voor dat onderdeel en maakt instellen en onderhouden juist eenvoudiger dan de oplossing die windows zelf biedt. Anders was de 3rd party oplossing niet nodig. Het verkleint dus ook het aanvalsoppervlak door het faciliteren van een juiste configuratie.

[laser50]

Had voor de grap laatst de logs erbij gepakt om te zien of er nog iets op te zien was (Mijn ubuntu ssh poort krijgt minimaal honderd+ pogingen per dag).. En jahoor, ook op de Windows Server word er constant geprobeerd in te loggen. Het is vrij normaal deze dagen.

Ik zou de poort van in ieder geval SSH wel van het net af kunnen halen, maar uit interesse heb ik deze aangesloten op een abuse-ip database waardoor alle pogingen en IPs direct worden gerapporteerd, naast dat deze een week worden verbannen van de server zelf. Ook staat root login uit en verder komen ze ook zeker niet met brute-force.

Windows Server gebruikt nu IPBan, en ook dat lijstje begint redelijk vol te lopen, al kan ik deze helaas nog niet verbinden met de database.

Aan het eind van de dag denk ik echter niet dat een lockout enig meer resultaat boekt dan dat ik zelf zoals hierboven heb beschreven, je kan bannen wat je wil maar aan het eind van de dag is het simpelweg dweilen met de kraan open en stopt het niet.

Wil je er echt wat aan doen, zorg dan dat je ofwel de 'bekendste weg' (Administrator account renamen of uitzetten) afzet, of dat je gewoon die netwerkpoorten niet opent op het internet.

[segil]

administrator account renamen heeft niet zoveel zin, omdat de SID dezelfde opbouw heeft bij alle installaties: S-1-5-domain-500.
In een Windows domain kan je LAPS uitrollen, waarbij elke xx dagen het local admin wachtwoord automatisch wordt gewijzigd op een domain member, en opgeslagen in AD bij het computer object. Ik heb dit uitgerold bij mijn huidige opdrachtgever en het werkt prima.

[themadone]

Ik neem aan dat dit alleen geldt voor losse windows 11 machines?

Ik mag hopen dat in een zakelijke omgeving dit centraal geregeld is en de local admin accounts sowieso op slot staan.

Bij mijn klanten, allemaal LAPS en vervolgens de lokale admin accounts disabled, succes met de bruteforce.

Dus voor de meeste waarschijnlijk niet echt een nieuwe feature denk ik.

[choogen]

En voor Windows 10 is er niets geregeld qua bescherming tegen brute-force aanvallen op lokale accounts?

[SirBlade]

Upgraden naar Windows 11 (en eventueel veiligere hardware).

[linuxrev]

Wat leuk dat Microsoft nu een basisbeveiliging ontdekt die Linux van server tot desktop altijd al had. Ik herinner het mij nog uit de eerste commandline-oefening van de cursus Linux admin & netwerkbeheer aan de Oostendse Avondschool. Was ook een methode om jezelf 5 minuten extra pauze te geven...

En wat betreft het nut hiervan: deze week meldde Wordfence 900+ admin-inlogpogingen binnen een uur op mijn website vanuit de Russische Federatie. En ook mijn VPS zelf werd een keer geprobeerd. Het is dus geen overbodige beveiliging.

[RoestVrijStaal]

Microsoft zegt over de nieuwe Account Lockout Policies: "We raden aan om '10/10/10' in te stellen. Dit betekent dat accounts op slot gezet worden na tien gefaalde loginpogingen binnen tien minuten. De maatregel duurt tien minuten, waarna het account automatisch weer gedeblokkeerd wordt."

Waarom zo'n syntax dat zo slecht leesbaar en interpreteerbaar is? Wordt er dan niet geleerd van cron en chmod?

[Verwijderd]

Wat is hier niet interpreteerbaar aan dan? Aantal gefaalde inlogpogingen/ binnen aantal minuten/ duur blokkade.

[LevelZero]

Er is helemaal geen slecht leesbare syntax. Het zijn 3 losse registry settings, zoals te lezen is op de oorspronkelijke pagina (staat zelfs een mooi screenshot bij)
1) Account Lockout Threshold
2) Account Lockout Duration
3) Reset account lockout counter after

Microsoft adviseert alle 3 de waardes op 10 te zetten.
Het is echt niet zo dat het 1 registry setting is die op 10/10/10 gezet moet worden.

[grrfield]

Waarschijnlijk is dit geen syntax, maar een wijze om het te omschrijven.

[uNoTopia]

Zou je ook 0 inlogpogingen als max waarde kunnen instellen?

[loki504]

Vast wel. Wat dan weer neer komt op oneindig. Zoals gebruikelijk is bij 0

[Lucb1e]

A software QA engineer walks into a bar.

He orders a beer. Orders 0 beers. Orders 99999999999 beers. Orders a lizard. Orders -1 beers. Orders a ueicbksjdhd.

First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone.

Waarschijnlijk kun je 0 wel instellen maar crasht het zodra je het venster sluit met alt+f4 in plaats van het kruisje of zo

[Reactie gewijzigd door Lucb1e op 25 juli 2024 02:20]

[Dihylopas]

De enige reden dat ik MalwareBytes gebruik is de brute-force bescherming door middel van een IP-block voor bepaalde tijd.
Wordt met de group policies een IP-block gedaan of alleen het Administrator account dichtgezet?

edit: gaat dit wel over RDP?

[Reactie gewijzigd door Dihylopas op 25 juli 2024 02:20]

[Zwelgje]

gaat over het lokale admin account op welke wijze hij ook gebruikt wordt, via RDP, via SMB via NFS via console of SSH whatever

geen IP block verder alleen account dichtgezet

[Menesis]

Ik dacht dat dat allang zo was. Bizar eigenlijk

[satya]

Iets dergelijks zit ernaar mijn ervaring al in idd.