Patch Tuesday-ronde repareert 49 bugs waaronder ernstig lek in Kerberos

Microsoft heeft tijdens de Patch Tuesday-ronde van januari 49 bugs gerepareerd. Een daarvan is een ernstige remote code execution in authenticatieprotocol Kerberos, waarvan Microsoft verwacht dat het kan worden uitgebuit.

Microsoft heeft cumulatieve updates KB5034123 voor Windows 11-versies 23H2 en 22H2, en KB5034122 voor Windows 10 21H2 en 22H2 uitgebracht. In die Patch Tuesday-reparatieronde repareert het bedrijf in totaal 49 kwetsbaarheden, een relatief laag aantal. In 12 gevallen gaat het om een remote code execution. Twee bugs krijgen de klassificatie Kritiek. Een daarvan is CVE-2024-20700, een remote code execution-bug in Hyper-V waarmee een aanvaller een virtuele machine kon overnemen. Daarvoor was het wel nodig om eerst toegang tot een netwerk te krijgen en een race condition te 'winnen'.

Een andere kritieke bug is CVE-2024-20674. Dat is een feature-bypasskwetsbaarheid in authenticatieprotocol Kerberos. Microsoft zegt dat het waarschijnlijk is dat die kwetsbaarheid in de toekomst zal worden uitgebuit. Een aanvaller kan daarmee de authenticatie op bijvoorbeeld een Entra ID-, voorheen Azure Active Directory-, omgeving omzeilen door een gebruiker te spoofen. Microsoft noemt een man-in-the-middleaanval als voorbeeld van hoe dat kan. Het bedrijf geeft verder geen details over die kwetsbaarheid, maar geeft die een CVSS-score van 9.

In de Patch Tuesday-ronde zijn verder nog tien privilege-escalationbugs gerepareerd, net als zeven manieren om de beveiliging van een systeem te omzeilen. Ook zijn er elf bugs gerepareerd waarmee informatie kon worden afgelezen, zes denial-of-servicebugs en drie spoofingkwetsbaarheden.

Reacties (64)

[Wouterie]

De installatie van KB5034441 komt op mijn systemen nu telkens voorbij maar de installatie mislukt. Eerst een downloadfout, dan 0x80070643. Ik heb dit nu op 3 systemen. Maar goed, morgen weer een dag.

Update: Schijnt een probleem met Bitlocker te zijn. De standaard recovery partition schijnt niet groot genoeg te zijn maar het vergroten daarvan lukt niet als Bitlocker ingeschakeld is. https://support.microsoft...a5-4fee-a02a-2fdea17075a8

[Reactie gewijzigd door Wouterie op 22 juli 2024 21:18]

[Groentjuh]

Ik liep tegen dezelfde issue aan. Na handmatig die recovery partitie te vergroten werkt de update.

Aanvulling: Om dit te doen kun je de stappen uitvoeren, die staan op deze pagina (in Nederlands; let op commandos zijn hier meevertaald!). Volg de stappen goed en zorgvuldig, want je past hiermee de partities aan!

[Reactie gewijzigd door Groentjuh op 22 juli 2024 21:18]

[WhiteSnake76]

Zou je ook kunnen uitleggen hoe/waar je dat doet voor de mensen die dat nog niet weten?

[Wouterie]

https://support.microsoft...43-461c-ada9-24c8229763bf

Euh... misschien kun je beter het Engelse stappenplan erbij pakken want ze hebben ook wat invoer vertaalt die echt in het Engels moet.

[WhiteSnake76]

Ik heb het op een andere manier gedaan, (om te kijken of dat wel werkte) met Minitool Partition Wizard, ongeveer 150MB van mijn Windows C partite af gehaald en toen de Recovery partitie groter gemaakt met het schuifje.

[Kalief]

Draaide daarna die update wel goed?

Update.
Getest: als je op die manier de recovery partitie wijzigt van grootte (1) wordt automatisch WinRE uitgeschakeld waardoor de update alsnog mislukt. Pas na herstarten van de PC wordt WinRE weer ingeschakeld (2) en lukt de update wel.

1. ca 250MB groter
2. check met CMD > reagentc /info

[Reactie gewijzigd door Kalief op 22 juli 2024 21:18]

[WhiteSnake76]

Ik kreeg een melding van Minitool Partition Wizzard dat ik de PC eerst opnieuw moest opstarten, en na het Opstarten lukte de update gelijk, geen problemen dus.

Recovery partitie was bij mij meer als 500MB, en nu iets meer als 700MB groot.

[Reactie gewijzigd door WhiteSnake76 op 22 juli 2024 21:18]

[Mlazurro]

Toch een beetje absurd dat dit de oplossing zou zijn voor elke thuisgebruiker. Niet iedereen is een administrator of IT'er.

[WhiteSnake76]

Daarom probeerde ik het eerst met Schijfbeheer in Windows wat niet lukte, maar met Minitool Partition Wizard ging het wel gelukkig, moest het bij beide Win 10 desktops doen, bij mijn Win 11 laptop nog niet gekeken.

[Groentjuh]

Inderdaad. Ik had zelf de Engelse gepakt toen ik het uitvoerde. Dat systeem stond ook op Engels, dus dat ging automatisch. Ik heb het linkje aangepast naar de Engels pagina met Nederlands tussen haakjes.

[Groentjuh]

De stappen op deze pagina kun je daarvoor volgen.

[WhiteSnake76]

Thx, ik probeerde het in schijfbeheer en kreeg mijn Windows partitie wel kleiner maar kreeg de Recovery partitie niet groter (of kleiner)

[Wouterie]

Ja, echt idioot. Die recovery partitie wordt door Microsoft zelf ingesteld op een bepaalt formaat (ik heb hier een laptop met een schone installatie van een paar maanden oud) maar het is blijkbaar niet groot genoeg voor hun eigen update en om het te verwerken.

[LongBowNL]

BitLocker is hier niet ingeschakeld, maar de update mislukt alsnog.

[Wouterie]

Als je Bitlocker hebt ingeschakeld dan kun je de recovery partitie niet verhogen (of zo) Als het uit staat dan kun je handmatig de partitie vergroten en zou de update moeten lukken. Zeggen ze. Goed getest weer. -zucht-

[LongBowNL]

Aha, op die manier. Duidelijk. Ik wacht lekker de oplossing van Microsoft af.

[Railgunner]

Deze foutcode krijg ik ook op mijn zakelijke Win10 Business 22H2 laptop. Hopelijk lost MS het snel op.

[segil]

geen probleem hier met de installatie en ik gebruik Bitlocker.

[deMercer]

Hier is de installatie ook gelukt op een laptop met BitLocker.

[Hansvw22]

ik krijg precies dezelfde foutmelding...

[bzzzt]

Tijd voor een inzameling zodat ze bij Microsoft een extra computer met Bitlocker kunnen aanschaffen om mee te testen... of gewoon eens tijd om Bitlocker onderdeel van de standaard installatie te maken.

[WhiteSnake76]

Ik heb exact het zelfde maar gebruik geen Bitlocker.

Echt weer superdom als het aan het formaat van de recovery partitie ligt, dat is iets wat Windows zelf instelt

[MossMan]

Interessant... ik heb hetzelfde probleem meegemaakt meerdere keren op een Win10 systeem met Veracrypt systeem-encryptie. Ik had eigenlijk nooit verwacht dat dat ook met de "officiele" encryptie voor zou komen!

In mijn geval moet ik geheel het systeem-partitie decrypten, update uitvoeren, daarna systeem-partie opnieuw encrypten. Ben dus wel een weekend mee bezig om de zoveel maanden, best irritant.

Voor dat ik achterhaalde wat de oorzaak was is het me in 2019 gelukt om update de mist in te sturen (dmv. allerlei hotfixes enz. toe te passen) waardoor Windows kompleet vernaggeld werd. Ik begrijp dus niet waarom Microsoft niet gewoon een check uitvoert tijdens de update en aangeeft hoe men de recovery partitie kan vergroten (of liefst doet dat gewoon automatisch).

[Wouterie]

Ja, het zou kunnen gebeuren met software van derden, maar dit is gewoon prutswerk van Microsoft. Ik denk dat we deze patch nog even gaan tegenhouden op het werk

[Mlazurro]

Hier ook hetzelfde probleem. Het lijkt wel heel random. Mensen met grote recovery partitie kunnen de update ook niet installeren. Ook mensen die de partitie vergroten omdat ze denken dat het de oplossing is, ook niet. Sommigen konden de update gewoon installeren, ook met een kleine partitie. Lijkt mij ergens een slordigheid van MS.

Het kan toch niet dat ze nu van elke huis & tuingebruiker tussen 11 en 99 jaar doodleuk even vragen om hun partitie te vegroten

Wel jammer dat het niet in het artikel staat, het is echt wel wijdverspreid.

[Reactie gewijzigd door Mlazurro op 22 juli 2024 21:18]

[Dim]

Het is toch eigenlijk wel een beetje kwalijk dat Microsoft dit overduidelijk niet getest heeft. Als je op een willekeurige UEFI machine een verse installatie van Windows 10 doet, krijg je standaard een 100 MB EFI System partitie, dan een partitie voor je C: drive, en hij maakt zelf altijd een ~550 MB recovery partitie aan.

En dus hebben ze zelf niet eens doorgehad dat hun recovery update te groot was om hierop te passen? Ik wist dat Microsoft hun QA team grotendeels ontslagen heeft, maar dit is echt wel een beetje te gek.

Microsoft moet nu gewoon niet gaan vragen van miljoenen non-technische gebruikers om allemaal enge DISKPART commando's in te gaan tikken, waardoor je met een klein miskleuntje alles kwijt kunt raken, alleen maar omdat zij niet wat bloatware uit hun recovery kunnen halen.

[mikeoke]

Microsoft heeft een Sample PowerShell script beschikbaar gesteld, voor systeembeheerders en tweakers

PatchWinREScript_2004plus

With the device started up into the running version of Windows installed on the device, the script will perform the following steps:

• Mount the existing WinRE image (WINRE.WIM).
• Update the WinRE image with the specified Safe OS Dynamic Update (Compatibility Update) package available from the Windows Update Catalog. We recommend that you use the latest Safe OS Dynamic Update available for the version of Windows installed on the device.
• Unmount the WinRE image.
• If the BitLocker TPM protector is present, reconfigures WinRE for BitLocker service.

Important This step is not present in most third-party scripts for applying updates to the WinRE image.

Voorbeeld van Powershell script:
.\PatchWinREScript_2004plus.ps1 -packagePath "\\server\share\windows10.0-kb5021043-x64_efa19d2d431c5e782a59daaf2d.cab

[Wouterie]

Bedankt voor de tip. Ik ben ermee aan de slag gegaan en hoewel het lijkt te werken blijft Windows Update de KB5034441 aanbieden, wat dus mis gaat. Blijkbaar kan Microsoft nog niet goed nagaan of de update nog wel nodig is na het 'handmatig' installeren van de achterliggende update.
Maar goed, ze zullen t.z.t. wel met een echte fix komen. Voor de bedrijfsomgeving laat ik deze patch nog wel even liggen.

[mikeoke]

zelf heb ik script nog niet kunnen testen.
Misschien kun je nog een "UsoClient RefreshSettings" doen?

[Wouterie]

Ook aan gedacht, maar helaas blijft de update weer komen. Geeft verder niet, ik hou gewoon niet zo van foutmeldingen maar het kan geen kwaad. Hoop ik.

[Alxndr]

"Dat is een feature-bypasskwetsbaarheid in authenticatieprotocol Kerberos."

Ik geloof niet dat ik ooit iets te doen heb met "een Azure Active Directory-omgeving", maar het klinkt me net zo hocus-pocus als alle processen die ik in Taskmanager zie die (blijkbaar) normaal/noodzakelijk zijn.

Hoeveel % van dit soort fixes is relevant voor iemand die bij wijze van spreken alleen maar z'n browser en z'n games draait op z'n PC?

Ik installeer uiteindelijk natuurlijk wel braaf alle updates en patches, maar met alle problemen die ze tegenwoordig met zich meebrengen wacht ik wel altijd een paar weken. Hoe onverstandig is dat?

[Llopigat]

Ik geloof niet dat ik ooit iets te doen heb met "een Azure Active Directory-omgeving"

Azure AD gebruikt helemaal geen Kerberos (Overigens hebben ze Azure AD nu weer hernoemd naar "Entra ID").

Hoeveel % van dit soort fixes is relevant voor iemand die bij wijze van spreken alleen maar z'n browser en z'n games draait op z'n PC?

Niets. Dit speelt alleen in bedrijfsomgevingen. Als je Windows shares gebruikt op je lokale netwerk zou je er eventueel nog last van kunnen hebben maar omdat dat soort spul het internet niet op gaat is de kans extreem klein. Als je gewoon een enkele PC hebt en geen windows filesharing doet, heb je er helemaal geen last van.

[Reactie gewijzigd door Llopigat op 22 juli 2024 21:18]

[rbr320]

Azure AD gebruikt helemaal geen Kerberos

Niet in een cloud-only configuratie, maar het is wel degelijk mogelijk en soms zelfs wenselijk om Kerberos authenticatie toe te voegen aan Azure AD.

https://techcommunity.mic...rberos-works/ba-p/3070889
https://www.maximerastell...or-on-premises-resources/

[Llopigat]

Mja maar dan is het niet echt Azure AD meer, maar hybrid met AD.

Dat is inderdaad wel wat momenteel het meest gebruikt wordt inderdaad.

[TheVMaster]

Maar in veel gevallen wel weer onnodig. Om met een AAD machine te authentiseren op een on-prem fileshare is hybrid niet nodig. Maar goed, dat is off-topic.

[MZONDERL]

Afhankelijk of je authenticatie onder user-context (user account) of onder device-context (system account) is.

Een EntraID Joined device kan niet onder "system-context" op een on-prem file share, maar wel via user-context (de user die rechten heeft op on-prem omgeving).

[TheVMaster]

Eens, maar in dat soort specifieke scenario’s zou je dan iets met Hybrid moeten. OF je moet gewoon zorgen dat je altijd op user-basis authenticeert natuurlijk. 😎 Op device basis authenticates voelt best legacy namelijk. 😋

Dat hoort natuurlijk ook niet thuis in een moderne omgeving, althans je zou zoiets eigenlijk moeten proberen uit te faseren. 😎

[Reactie gewijzigd door TheVMaster op 22 juli 2024 21:18]

[StephanVierkant]

"Overigens hebben ze Azure AD nu weer hernoemd naar "Entra ID""

Waar Google berucht is vanwege het stoppen van diensten (killed by Google) is Microsoft wel actief met het (verwarrend) hernoemen van producten: https://m365maps.com/renames.htm

[junkchaser]

Wat me wel opvalt is dat ze proberen categorieën te vormen dmv de naamgeving. Zo is het wel makkelijker om diensten terug te vinden in je zoektocht naar gerichte oplossingen.

[DeFeCt]

Handig overzicht, al mis ik ook nog de nodige, met name op het gebied van CoPilot zijn er ook alweer de nodige naamswijzigingen geweest.

[Pasteis]

"Overigens hebben ze Azure AD nu weer hernoemd naar "Entra ID""

Waar Google berucht is vanwege het stoppen van diensten (killed by Google) is Microsoft wel actief met het (verwarrend) hernoemen van producten: https://m365maps.com/renames.htm

Ik vind het naar verhouding meevallen, ten opzichte van Google. Maar ze lijken inderdaad moeite te hebben met het aanhouden van goede benamingen.

Lijkt soms wel alsof Microsoft niet centraal overstijgend overziet welke soort producten en diensten ze hebben en applicaties onder welke soort naamgeving hangt.

Overigens vind ik de naamswijziging van AAD naar Entra beetje zonde. AAD was inmiddels aardig ingeburgerd

[Blokker_1999]

Ik denk zelfs niet dat het alleen voor AAD is, maar ook gewoon on-prem misbruikt kan worden. De samenvatting geeft aan dat een systeem in hetzelfde netwerk een bericht kan sturen naar de client om de client te doen denken dat dat systeem een kerberos server is waardoor er authenticatiegegevens uitgelekt kunnen worden.

[lenwar]

Hoeveel % van dit soort fixes is relevant voor iemand die bij wijze van spreken alleen maar z'n browser en z'n games draait op z'n PC?

Daar is niets over te zeggen. De ene bug is te misbruiken, al gebruik je het mechanisme zelf niet (bewust). De andere bug moet je echt gebruik van maken. In dit specifieke geval (het Kerberos item), maak je op je gaming-pc waarschijnlijk geen gebruik van en zul je er geen last van hebben.

[dasiro]

dat is de cloud-omgeving van microsoft waarmee veel bedrijven gekoppeld zijn voor bvb office365 (meest gebruikte toepassingen zijn mailboxen, sharepoint, teams, maar ook nog een hele resem andere die eventueel gekoppeld zijn aan andere externe applicaties/websites). Als privé-persoon zonder professionele account zou je hier weinig gevaar door kunnen lopen, maar aangezien het een bug is die in het OS zit, gaat de workaround/oplossing naar alle toestellen gestuurd worden.

[telenut]

Als je enkel de browser gebruikt zou ik overschakelen op een Chromebook :-)
Voor games kan dat nog een probleem zijn...

[Alxndr]

een Chromebook, met Chrome OS... Ik probeer zo goed en zo kwaad als het gaat zelfs de Chrome browser te vermijden.

Zelfs als ik geen PC gamer zou zijn zou ik m'n data liever door een hacker laten stelen dan dat ik het vrijwillig aan Google geef. (bij wijze van spreken natuurlijk)

Het enige alternatief voor Windows is voor mij Ubuntu.

[smooc]

In Kerberos of in de implementatie van MS? Is nogal een wezenlijk verschil aangezien MIT / Heimdal op heel veel andere plekken worden gebruikt.

edit: Ah de CVE is specifieker: Windows Kerberos

[Reactie gewijzigd door smooc op 22 juli 2024 21:18]

[Verwijderd]

Bij Win 10 gaat het bij mij fout met de update van KB5034441.
Hier zijn al veel meldingen van op internet. Wel enkele oplossingen i.v.m. vergroten van de herstelpartitie, welke te klein zou zijn om de update te verwerken.

Ik wacht nog wel even op actie van MS zelf.

[Reactie gewijzigd door Verwijderd op 22 juli 2024 21:18]

[Blokker_1999]

En dan zie je dat er zelfs nog een bugfix is voor Server 2008r2 die uiteraard door niemand meer gebruikt wordt .

Toont direct aan dat MS CVE-2024-20674 als zeer kwetsbaar inschat, al vereist wel dat je op hetzelfde netwerk zit als je doelwit.

[fantafriday]

Is dat niet gewoon voor de extended security support klanten?

[pc_freak1]

je zult je verbazen hoeveel je die toch nog tegenkomt...

[Cambionn]

Ik denk dat @Blokker_1999 sarcastisch was .

[StGermain]

Heeft hier 5 minuten op 0% gehangen bij reboot voordat hij er opeens doorkwam (5800x3D met 32GB RAM W11 23H2) en alle updates staan als geslaagd.

[Llopigat]

Ik wou dat ze eens ophielden met Active Directory en Kerberos. Er zitten zo veel inherente problemen in dat het 1 grote lappendeken van maatregelen is om het nog een beetje veilig te houden. De meeste maatregelen die je kan nemen zijn niet eens waterdicht dus je moet echt met argusogen naar je logging kijken.

Denk bijvoorbeeld aan het "pass the hash" verhaal. En "Kerberoasting", "Golden Ticket Attack" enz. Allerlei problemen die niet op zijn te lossen zonder het incompatibel te maken met eerdere implementaties. Het wordt tijd om gewoon de handdoek in de ring te gooien en alleen nog maar cloud AAD (of nu "EntraID") toe te staan.

Bij ons op het werk zitten we zelfs nog vast aan oude AD versies omdat de produktiekant per se extreem verouderde en lang uit support zijnde Windows versies wil gebruiken. Ik ben het zo zat om securitywerk te doen terwijl ondertussen door totale imbecielen de stoelpoten onder je vandaan gezaagd te krijgen.

[Reactie gewijzigd door Llopigat op 22 juli 2024 21:18]

[Blokker_1999]

dus je wil decennia aan legacy overboord gooien, heel leuk, maar de meeste bedrijven gaan dat niet kunnen doen. Maar gooi gerust je eigen AD servers buiten en ga cloud only werken als je denkt dat dat de oplossing is. Niets dat je tegenhoud, niets dat je verplicht AD te gebruiken.

En productie kan mogelijks goede redenen hebben om antieke Windows versies in leven te houden. Ook wij hebben nog ergens een 2003 machina draaien omdat 1 van onze klanten die nog heeft draaien en wij moeten kunnen testen. Dan mag men vanuit security zo hard roepen dat zoiets ongehoord is als men wenst, je ontkomt er niet aan. En recent problemen bij een andere klant waar onze remote access oplossing niet meer wou werken omdat zij ons product laten werken op een 2008r2.

[sfranken]

... maar de meeste bedrijven gaan dat niet kunnen doen.

Niet kunnen óf niet willen? In mijn ervaring is het vaak het laatste, en dat is nogal een verschil.

[bzzzt]

Als je kritieke business processen op een stuk legacy software heb draaien wat alleen op een oude versie van Windows werkt en er geen mensen zijn of geen geld is vrijgemaakt om te migreren of er helemaal geen duidelijk migratiepad is wordt het vaak wel borderline 'kunnen'... uiteindelijk valt alle functionaliteit wel te herbouwen maar dan ga je een lang traject in.

[Llopigat]

dus je wil decennia aan legacy overboord gooien

Decennia aan oude zooi die niet meer ondersteund wordt, ja. Nou wordt AD nog wel ondersteund maar met name de nieuwere versies die wij niet kunnen gebruiken.

En productie kan mogelijks goede redenen hebben om antieke Windows versies in leven te houden. Ook wij hebben nog ergens een 2003 machina draaien omdat 1 van onze klanten die nog heeft draaien en wij moeten kunnen testen

Maar doe dat dan in een testlab. Bij ons willen ze het in de produktie omgeving waardoor onze hele AD versie verouderd moet zijn. Voor een handjevol machines...

Ik snap het wel maar zij hebben destijds een verkeerde aankoop gedaan (geen long term support van de leverancier) en in plaats van nu geld uit te geven om het probleem op te lossen door wat nieuws te kopen, zetten ze de security van het hele bedrijf op het spel om hun eigen afdelingsbudget te redden. Erg kortzichtig gedrag.

Ik heb ook allang geopperd om de produktieomgeving gewoon helemaal apart te gooien waarbij de kantooromgeving dan gewoon op de laatste standaarden kan werken. Maar dat wil men ook niet want dan moeten ze twee keer inloggen.

Helaas krijgen ze de (ook niet al te bijster intelligente) CIO mee in hun gedram. Dus we zitten er aan vast. Maar echt normaal werken kan het niet zo als je werk security is en men moedwillig de achterdeur open laat staan.

[Reactie gewijzigd door Llopigat op 22 juli 2024 21:18]

[William_H]

Ik weet niet of ik wel bij zo'n bedrijf zou willen werken. Ik heb letterlijk bij een sollicitatie ooit eens nee gezegd toen ze mij toch wilden hebben.

[Cergorach]

Kerberos is inderdaad een groot drama, maar echt niet het enige grote drama. Ook zonder Kerberos zijn er genoeg zaken waar je je eigenlijk niet fatsoenlijk tegen kan beschermen voor periode x. Hoe goed kan jij je systeem beveiligen tegen attacker-in-the-middel scenarios die gewoon je token pakken en password+MFA helemaal niets meer doen? Hoe lang duurde het voordat MS er enigszins mitigatie voor had (maar op een heel beperkte schaal die in de praktijk niet bruikbaar is)? Dan zit je geheel op AAD, gebruik je geen Kerberos meer, maar ben je nog steeds afhankelijk van je intrusion detection om aanvallers te detecteren die een account misbruiken. En dan maar hopen dat het wordt gedetecteerd...

Bij de meeste MKB kan je nog wel redelijk vlot manoeuvreren (mits het geld ervoor is), maar bij grote organisaties met complexe systemen... Voordat je de infrastructuur changes er allemaal doorheen heb om een gat te dichten is het volgende gat er alweer. En zo blijft het doorgaan, er is geen veilig systeem, never has been, never will be. En dat is zo een beetje de hele IT, constante verandering, upgraden, etc. Dat is echt niet alleen security!

Het is altijd een puzzel en dat is imho juist de uitdaging van IT/security.

[Llopigat]

Hoe goed kan jij je systeem beveiligen tegen attacker-in-the-middel scenarios die gewoon je token pakken en password+MFA helemaal niets meer doen?

Nou, met FIDO2 Webauthn bijvoorbeeld. Dat beveiligt heel goed tegen man in the middle attacks.

Helaas vindt men dat bij het corporate leiderschap ook weer 'eng' want het is nieuw en kost een klein beetje geld omdat je iedereen een token moet geven.

Dan zit je geheel op AAD, gebruik je geen Kerberos meer, maar ben je nog steeds afhankelijk van je intrusion detection om aanvallers te detecteren die een account misbruiken. En dan maar hopen dat het wordt gedetecteerd...

Ja dat soort dingen hou je altijd, maar Kerberos is inmiddels zo ver geweaponised dat het gewoon met elke red team pentest weer klaar is. Elke keer weer komen ze op die manier binnen, en zo blijf je bezig. Altijd hetzelfde verhaal, pass the hash, bloodhound om een escalatiepad te vinden enz. Het is zowat helemaal geautomatiseerd in cobaltstrike. En dat wordt echt alleen niet gebruikt door de goeden.

Als je keer op keer verteld wordt dat je kwetsbaar bent, zou er eens een keer een belletje af moeten gaan. Maarja...

En dat is zo een beetje de hele IT, constante verandering, upgraden, etc. Dat is echt niet alleen security!

Het is altijd een puzzel en dat is imho juist de uitdaging van IT/security.

Mijn probleem is vooral dat er te weinig verandert. Men leert niet meer van de lessen en pentests. Het is allemaal van "ach het loopt wel los".

Uiteindelijk komt er gewoon weer een situatie zoals destijds met WannaCry / NotPetya en dan wordt er weer een tijdje echt geluisterd naar ons. Voorlopig is het maar afwachten.

[Reactie gewijzigd door Llopigat op 22 juli 2024 21:18]

[Ventieldopje]

Nou, met FIDO2 Webauthn bijvoorbeeld. Dat beveiligt heel goed tegen man in the middle attacks.

Helaas vindt men dat bij het corporate leiderschap ook weer 'eng' want het is nieuw en kost een klein beetje geld omdat je iedereen een token moet geven.

En je krijgt binnen de kortste keren gezeur dat mensen het te omslachtig vinden. Vergt weer veel support van IT (ook als mensen hun token kwijt raken).

Ik zou het graag zelf ook zien, groot voorstander. Maar goeie beveiliging is (nog) niet gebruiksvriendelijk genoeg, al gaat het de goeie kant op.

[nullbyte]

Onzin niet elke instantie of bedrijf kan/mag in de cloud.

[Server.1968]

Heb zojuist drie Win 11 pc's geüpdatet; geen problemen ondervonden en blijkbaar iets veiliger nu, prima MS.