Microsoft voegt functie aan Defender toe die wachtwoorddumps in LSA voorkomt

Microsoft voegt een functie toe aan Defender waarmee Local Security Authority Server Service-processen kunnen worden geblokkeerd. Daarmee wordt een belangrijke methode om wachtwoorden uit Windows te lekken afgesloten.

Het gaat om een regel voor een Attack Surface Reduction die Microsoft toevoegt aan Defender. Die zorgt ervoor dat aanvallers geen memory dumps meer kunnen maken uit Lsass of Local Security Authority Server Service. Die Local Security Authority is een dienst in Windows waarmee gebruikers worden geauthenticeerd bij het inloggen, maar aanvallers kunnen dat misbruiken door plaintext-wachtwoorden en NTLM-hashes te achterhalen via een memory dump. De nieuwe functie voorkomt dat.

Normaal gesproken voorkomt Defenders ingebouwde Credential Guard-functie zo'n dump. Microsoft heeft nu een nieuwe regel toegevoegd die ook werkt als Credential Guard is uitgeschakeld. Dat gebeurt vaak bij bedrijven omdat Credential Guard tot problemen kan leiden met smartcarddrivers of andere software. De nieuwe regel verbiedt alle processen om lsass.exe aan te spreken, zelfs als die adminrechten hebben.

De functie wordt voortaan standaard ingeschakeld voor alle gebruikers. Ze kunnen die wel handmatig uitschakelen. Alle andere ASR-regels blijven volgens Microsoft standaard wel uitgeschakeld. Microsoft waarschuwt dat bedrijven mogelijk wel meer notificaties in hun logs krijgen over geblokkeerde inlogpogingen van andere processen. Het bedrijf zegt dat het extra filterregels heeft geïmplementeerd die het aantal meldingen terugdringt.

Door Tijs Hofmans

Nieuwscoördinator

15-02-2022 • 09:47

26

Submitter: TheVivaldi

Reacties (26)

Sorteer op:

Weergave:

Applies to:
Microsoft Defender for Endpoint Plan 1
Microsoft Defender for Endpoint Plan 2
Microsoft 365 Defender
Dus niet de standaard Windows Defender.
Officieel niet, maar het zou in de praktijk wel kunnen werken. Zo is de documentatie van MpCmdRun niet van toepassing op Windows Defender, maar alle command line opties werken wel.
Sorry, weet niet waar dit vandaan komt, maar die ASR rule waarin verwezen wordt in het artikel heb ik een jaar geleden al geactiveerd in mijn bedrijf. Mogelijks is er een nieuwe rule bijgekomen, of is deze wat bij getuned om de FP te verminderen?

@Xsion , nee, runasppl staat daar nog los van.
Als ik het goed lees is het grote verschil dat deze nu standaard aan komt te staan in plaats van optioneel.

Dit past in, wat een veranderende houding lijkt van Microsoft. Niet alleen opties geven, maar steeds vaker security maatregelen standaard aanzetten. En dan met name maatregelen tegen kwetsbaarheden die actief misbruikt worden door hackers. Credential dumping via LSASS is er zo eentje die in veel aanvallen voorkomt.

[Reactie gewijzigd door BytePhantomX op 24 juli 2024 14:14]

Ja, klopt, die ASR regel zit volgens mij ook al een tijdje in de Security Baseline.
De regel zit al jaren in Defender maar staat standaard uit. Microsoft gaat de regel nu inschakelen als standaardconfiguratie.
De nieuwe regel verbiedt alle processen om lsass.exe aan te spreken, zelfs als die adminrechten hebben.
Hoe zit het met zaken die draaien onder het system account? Denk bijvoorbeeld aan een Command Prompt onder het system account, die een admin kan starten via bijvoorbeeld Task Scheduler. Worden dit soort 'workarounds' ook netjes geblokkeerd door deze beveiliging (of door iets anders in Defender)?

[Reactie gewijzigd door The Zep Man op 24 juli 2024 14:14]

je kan al zinds windows 7 geen command prompt meer starten met NT Authority/SYSTEM rechten via task scheduler. ik weet nog in windows XP dat we de AT command gebruikte om dat wel voor elkaar te krijgen.
Let op 'bijvoorbeeld'. De vraag gaat meer over enkel de genoemde methode.

Zie bijvoorbeeld dit.
kon die link niet lezen want hij wou meteen mijn adblocker blokeren of een abbo aansmeren, sorry.
maar ja, ik heb het inderdaad over zijn voorbeeld, niet over alle mogelijke vectors waarop je dingen zou kunnen exploiten, dan ben ik over 2 jaar nog niet klaar met mijn reacie te schrijven :+
kon die link niet lezen want hij wou meteen mijn adblocker blokeren of een abbo aansmeren, sorry.
Dat zie ik niet, want ik draai een content blocker dat dit soort rotzooi blokkeert. Geen excuses nodig, uiteraard. :)

En het is geen exploiteren, maar gebruiken. Admins onder Windows kunnen processen starten onder het SYSTEM account via verschillende methoden. PsExec, NirCmd, etc. Ik vroeg mij af hoe goed dat afgeschermd wordt. Als dat namelijk niet zo is, dan staat het een stukje malware natuurlijk niets in de weg om dezelfde weg te bewandelen.

[Reactie gewijzigd door The Zep Man op 24 juli 2024 14:14]

als het goed is kan je geen interactive prompts meer krijgen met NT authority/SYSTEM rechten voor zover ik weet, dat hadden ze gedaan omdat het echt een veiligheidsprobleem was, wat duidelijk werd in XP.

maar ja je hebt de /s flag voor PsExec, en dat lijkt gewoon alles uit te voeren onder SYSTEM, waaronder interactive applications. als je op die manier cmd kan runnen, is dat best een ding, zeker omdat het sytem account geen credentials heeft om mee in te loggen, zoals Linux dat heeft.

dus ja, dat snap ik ook niet helemaal hoe dat beveiligd word
dus ja, dat snap ik ook niet helemaal hoe dat beveiligd word
Sowieso wordt dat natuurlijk beveiligd doordat enkel administrators PsExec /s kunnen gebruiken. Vergelijk het met Linux gebruikers die sudo rechten hebben.

Ik vraag mij alleen af of Defender hier nog een schepje bovenop doet/kan doen qua beveiliging.
Hoe zit het met zaken die draaien onder het system account?
Is het, als je toch al system hebt, überhaupt nog wel nodig om lsass te dumpen? Kun je dan niet dezelfde code gebruiken als lsass zelf om die hashes uit te lezen uit... waar ze uiteindelijk ook staan (sorry, met dat stuk van Windows heb ik weinig ervaring)?
Nee, je kunt de code niet gebruiken, want defender checkt op wie het uitvoert.
De feature wordt voortaan standaard ingeschakeld voor alle gebruikers. Ze kunnen die wel handmatig uitschakelen.
Misschien een domme vraag en waarschijnlijk is het antwoord "nee" of "niet zomaar", maar is het voor malware niet mogelijk om deze handeling in Defender te automatiseren?
Helaas wel… (met voldoende rechten)
Als het goed is reageert de EDR van Defender daar weer op met een alert dat die rule gemodificeerd wordt.
Zou dit tools als Mimikatz ook minder effectief maken? Of is deze tool inmiddels al niet meer effectief op de laatste windows versies?
Zeker op het gebied van LSASS dumping zal Mimikatz niet meer werken. Al verwacht ik dat Mimikatz standaard al wordt geblokkeerd door iedere AV. Het grootste probleem is echter dat je met wat aanpassingen Mimikatz kan gebruiken zonder dat je AV hem detecteert. Bijvoorbeeld door hem fileless / vanuit het geheugen uit te voeren. Deze regel helpt dan weer dat LSASS nog steeds niet gedumpt kan worden.
Mimikatz bevat een microsoft signed driver (mimidrv). Via deze driver kan ja al deze rules bypassen, zelfs runasppl. Er bestaat gelukkig wel een andere ASR rule die het laden van know vulnerable (signed) drivers stopt.
is dat runasppl?
mag ik m’n Intune proactive remediations weer aanpassen

[Reactie gewijzigd door Xsion op 24 juli 2024 14:14]

Bij veel cyber attacks zie je dat de aanvaller weet te "morphen" van "user die op phishing mail" klikt naar uiteindelijk domain admin waarmee ze ransomware kunnen deployen. Veelal doen ze dit dmv Pass the Hash/password dumpt.

Als dit werkt, zoals microsoft nu zegt, kan dit het de aanvallers echt een stuk lastiger maken.
Ik hoop dat Microsoft de ASR rules ook met Tamper Protection gaat beschermen tegen ongeautoriseerde wijzigingen.

Zonder TP kunnen veel functies worden uitgeschakeld/aangepast.
Geen verwijt naar Windows, maar mijn Intel NUC Windows 11 media PC krijgt niet eens mijn Netflix wachtwoord. Mijn chain of trust bevat alleen bsd gebaseerde apparatuur die telkens volledig ge-update is, allemaal met military grade encryption, geen 3rd party crap en al helemaal geen warez. Dat is de enige manier om niets uit te laten lekken.

Het verbaast me niet helemaal dat de in het artikel besproken functie er niet al was, of dat het überhaupt uitgeschakeld kan worden.

Edit: voor de duidelijkheid, het is geen verassing dat Windows NIET op beveiliging gebouwd en allerlei tools behoeft om een lek systeem veilig(er) te maken, dat is geen flame louter een constatering. Ik geef daarnaast een voorbeeld van iemand die beveilingsmaatregelen neemt tegen het lekken van wachtwoorden (ikzelf). Ik heb dus geen abonnement nodig om het lekken van wachtwoorden via Windows te voorkomen; er is letterlijk niets dat gelekt kan worden

[Reactie gewijzigd door Faust op 24 juli 2024 14:14]

Windows flamen en je superioriteit uiten kan ook op andere sites, daar zijn vást subreddits voor. Het voegt hier echt niets toe aan de discussie.

Op dit item kan niet meer gereageerd worden.