Volkskrant: TU/e-hackers hadden gestolen credentials

De aanvallers die de Technische Universiteit Eindhoven eerder deze maand hackten, bezaten de inloggegevens van een werknemer en een student, schrijft de Volkskrant. Die waren door infostealers buitgemaakt.

De Volkskrant baseert zich op anonieme betrokkenen bij het onderzoek. Volgens de krant hadden de aanvallers de beschikking over inloggegevens van minimaal een werknemer en een student. De aanvallers konden daarmee inloggen op Windows-systemen in het universiteitsnetwerk. Eenmaal binnen werden de aanvallers al snel gespot en haalde de universiteit de netwerken preventief offline. Het lijkt er vooralsnog niet op dat de aanvallers gegevens hebben gestolen.

Het is niet exact bekend hoe de aanvallers aan de inloggegevens kwamen. Wel zijn die credentials later teruggevonden in infostealers. Het is niet bekend welke infostealers dat zijn en op welke plekken die werden verkocht, of dat de aanvallers die zelf hadden ingezet.

De TU/e werd eerder deze maand getroffen door een cyberaanval en schortte daarom het onderwijs tijdelijk op. Veel is echter nog onduidelijk over de aanval; de universiteit wil op zijn vroegst pas in april informatie delen over het onderzoek. De TU/e heeft Fox-IT ingeschakeld voor het forensisch onderzoek.

Door Tijs Hofmans

Nieuwscoördinator

24-01-2025 • 07:41

81

Submitter: Doane

Reacties (81)

81
81
57
4
0
19
Wijzig sortering
Als een student account schade aan je infrastructuur kan aanrichten mag je eens iemand gaan ontslaan.

MFA is ook een dingetje, bij veel scholen ook niet of net pas actief op studenten accounts. Leraren die hun eigen laptops gebruiken zonder enige vorm van ERD er op. En dan maar hopen dat er een scan plaatsvindt op hetgeen een student upload.
MFA was het eerste waaraan ik zelf dacht, en heb uiteindelijk mijn post niet gepltaats wantn ik bedacht me dat wanneer je aanmeld op Windows, er geen eenvoudige manier is om MFA af te dwingen. De aanvallers kunnen perfect op de campus op een computer hebben aangemeld met de gestolen credentials en niet remote, waarna ze een remote access tool hebben opgezet om daarna verder vanop afstand te kunnen werken.

Dat is al avengoed als de medewerker die een interessant document opent met daarin een malafide payload die zich installeert op je systeem. Je bent een gewone gebruiker, zonder rechten, maar je hebt al wel toegang tot het netwerk. Je bent vertrokken.

1 van de pentests die wij regelmatig laten uitvoeren is dan ook een systeem met de rechten van een standaard gebruiker meegeven, en het duurt wel even, maar als je dan een tijd later het rapport terugkrijgt en ziet hoe ver ze geraakt zijn, dan heb je zelf toch ook altijd weer wat werk om onopgemerkte gaten te dichten.
2fa bij een Windows login is blijkbaar prima af te dwingen. Bij inloggen op servers met rdp moet ik na ingeven van de credentials ook nog een mfa nummer intikken…
Kan prima, maar is geen default config. en ook geen config die echt veel wordt ingezet. Zeker niet als er al een resem andere controls zijn (denk aan VPN, vlans, goeie rechtensets, password rotation...)

Effort, security, usability en zelfs fallbacks nopen tot risicoanalyses en daaruit volgende maatregelen. Een kmo/MKB heeft heel andere uitkomsten dan een school, overheid of seveso bedrijf.
Imo is een bedrijf de schuld geven zonder verdere kennis van de opzet en de attackvectoren gewoon blame-shaming.
Bij Fontys (Eindhoven) is MFA sinds enkele jaren verplicht voor alle medewerkers en studenten.
Bij de TU/e is MFA ook al jaren verplicht, en vraagt tot vervelens toe vaak om weer eens via je mobieltje een code te bevestigen.
Als al dat extra werkt (steeds weer met de mobiel code intikken) eigenlijk voor nop is omdat hackers het kunnen omzeilen dan gaan er denk ik nogal wat mensen morren...
Normaal gezien moeten hackers ook als ze je gebruikersnaam en wachtwoord hebben gestolen nog steeds niet kunnen inloggen zonder ook nog eens je telefoon te stelen.

[Reactie gewijzigd door pauldebra op 24 januari 2025 14:53]

ik bedacht me dat wanneer je aanmeld op Windows, er geen eenvoudige manier is om MFA af te dwingen
Dat klopt.
Indien er gebruik gemaakt wordt van Intune/Entra ID joined devices, dan moet je het device wel met MFA aan de tenant koppelen als je de eerste keer inlogt. Je hebt dus niet enkel credentials nodig, maar ook een reeds onboarded device wil je zonder MFA verder kunnen. Wellicht dat de TUe andere ontwerpkeuzes gemaakt heeft, maar zonder verdere kennis van de omgeving blijft het theeblaadjes lezen.
Met Windows Hello is MFA prima te implementeren.
MFA is een hangslotje erbij, maar heeft een hoop risico's.

MFA pass the cookie, waarbij de sessie cookie wordt gestolen. Dan heb je toegang nodig tot user profile van de gebruiker op zijn C schijf.

Andere die tegen kwam was phishing email, user logt in met zijn credentials op een website, geeft MFA goedkeuring. En vervolgens wordt zijn MFA token gepakt op de website, de aanvaller registreert zijn eigen Android device als mfa authenticator en voila ze konden in blijven loggen en zelf MFA goedkeuren :)
Aanloggen op je laptop met smartcard+pin, of yubikey+fingerprint.
Omslachtig, maar wenbaar.

Wordt zo ingezet bij minimaal 1 van de grootbanken
Grootbanken hebben een iets ander risicoprofiel.... en zijn dus bereid om meer aan security uit te geven.
Beetje fatsoenlijke laptop kan tegenwoordig Windows Hello doen via de ingebouwde webcam. Macbooks hebben standaard TouchID tegenwoordig. Beiden kan je inzetten als MFA en breken niet perse je workflow. Het is allemaal niet gratis maar het hoeft ook weer niet meteen ontzettend veel geld te kosten.
Dat zou kunnen, maar onderwijsinstellingen (zo niet altijd, hoger dan de middelbare school) hebben meestal een Bring Your Own Device policy voor hun studenten.

Het is natuurlijk mogelijk, maar dan moet je eisen gaan stellen aan de laptops van een doelgroep die het (over het algemeen) niet al te breed heeft.
Helder, ik doelde meer op de medewerkers.
MFA is op TUe verplicht op alle diensten die gebruikmaken van SSO. De VPN was toegankelijk zonder. Ik vond dat altijd al gek, omdat het ervoor zorgt dat enkele interne diensten ook zonder MFA toegankelijk zijn. Maar gezien de VPN nu voor ‘een aantal weken’ offline is, lijkt het me dat dit aangepakt wordt.

[Reactie gewijzigd door eedaan op 24 januari 2025 08:52]

Aha! Ik dacht al, hoe is het mogelijk omdat we toch al MFA hebben... VPN toegankelijk houden zonder is natuurlijk een risico...
Vaak komen indringers met een normaal account "binnen" en gaan ze dan op zoek naar kwetsbaarheden. Het hoeft niet direct een admin account te zijn waarmee ze binnendringen al zouden ze dat natuurlijk allemaal wel heel erg graag willen.
Het is ook zo vaak te makkelijk om een beheerder FF te laten inloggen om een probleempje te bekijken. En van Desktopadmin naar domainadmin is makkelijker dan op het eerste zicht moet lijken
Zou je dan niet kiezen voor 2 computers, de ene voor Desktopadmin en de andere Domeinadmin?
Dat is meestal wel zo. Domainadmin gebruiken op een end-user pc is heel bad practice. Maar eenmaal binnen bestaat zoiets als laterale movement, waarbij je bereikbare devices infecteert tot je iets interessant vind.
Je hoeft ook geen domainadmin te worden... Data is namelijk meestal beschikbaar voor sets van eindgebruikers... De boekhouding moet kunnen boekhouden en servicedesk moet wachtwoorden kunnen resetten... Je snapt het plaatje wel
Er is nergens gezegd dat er schade is aan infra, studenten en werknemers hebben logischerwijs veel toegang tot belangrijke data. Er draait dus waarschijnlijk goede software die misbruik herkent en daarop is preventief gereageerd.
Dit is inderdaad ook wat ik denk maar blijft toch een beetje vaag met deze berichtgeving.
Maar MFA exhaustion is ook een ding. Als je bij genoeg mensen maar continu MFA verzoeken blijft versturen zal er altijd eentje zijn die op accepteren klikt om er maar vanaf te zijn. Al is dat met de nieuwe challenges waar je een nummer moet overtypen wel lastiger dan.
Ja en nee? Volgens mij dwingen ze de outlook Authenticator met nummers af waarbij je dus echt zelf de poging moet doen anders weet je niet welk cijfer tussen 10 en 100 er staat
Inderdaad. Je moet heel vaak weer op je mobieltje zo'n nummer intikken.
Als een student account schade aan je infrastructuur kan aanrichten mag je eens iemand gaan ontslaan.
Een aanval bestaat echt zelden uit één fase/trap, als je niet kan denken als een aanvaller dan is het over het algemeen beter geen uitlatingen te doen over dit onderwerp.
Als student van de TU, MFA is al een tijd actief en moet je vervelend vaak opnieuw gebruiken. Het voelt elke week bij Microsoft systemen.
Aangezien ze het hebben over Windows systemen weet ik vrij zeker dat je daar geen MFA voor nodig hebt maar ik heb me nooit aangemeld op windows sinds dat MFA kwam dus misschien dat iemand anders dit beter weet.
Ook snap ik nog steeds niet precies wat er nou is gebeurd.
Inloggen op windows systemen in het netwerk klinkt mij gewoon als een domain controlled windows apparaat inloggen die niet eens fysiek daar is.
Volgens mij kan ook de VPN zonder MFA gebruikt worden maar durf ik niet 100% zeker te zeggen.
Maar wat is er nou effectief gebeurd dat als aanval werd beschouwd wil ik nog steeds wel weten.

Je zegt als je als student of medewerker iets kan doen op het systeem dan moet je gaan kijken wat er allemaal mis is maar ik denk dat die lijn veel vager is dan je denkt in alle gevallen.
Simpelweg kun je het gewoon zien als verhoogde privileges, iemand die buiten het netwerk zit kan veel minder dan iemand die er al binnen is maar niet meteen alles van alle admins.

[Reactie gewijzigd door PaulHelper op 24 januari 2025 09:11]

Hoezo? Zo veel verschil zit er niet tussen medewerkers en studenten wat betreft taken en verantwoordelijkheden. Heel veel studenten hebben een bijbaantje op de universiteit, dat kan overal zijn, dus ook bij het systeembeheer. En als jij een afstudeeropdracht doet, draai je volwaardig mee in een onderzoek, en heb je dus toegang tot alle tools en alle data.

Als het nodig is voor hun opdracht, hebben studenten hebben ook nachtpassen e.d. Daarmee kunnen ze ook ongestoord enorme schade aan de fysieke infrastructuur aanbrengen. Net zoals jij dat waarschijnlijk zou kunnen bij je eigen werkgever.
Het zal niet zo zwart-wit zijn zoals je stelt. Met die inloggegevens hebben hackers de eerste stap kunnen maken. Grote kans dat als jij echt wil jij nu ook op je werk verder kunt hacken omdat je bent ingelogd. Geen enkel netwerk is waterdicht.
Nou, dat is een heel ander verhaal dan eerst: een "kwetsbaarheid in de beveiliging".
Eh nee. Of zie jij een uitgelekte credential (of meer dan één, in dit geval) niet als een beveiligings-kwetsbaarheid?

Een op straat liggende credential vormt, zoals nu dus gebleken is, wel degelijk een serieuze kwetsbaarheid in de beveiliging van een netwerk.
Eh nee. Of zie jij een uitgelekte credential (of meer dan één, in dit geval) niet als een beveiligings-kwetsbaarheid?

Een op straat liggende credential vormt, zoals nu dus gebleken is, wel degelijk een serieuze kwetsbaarheid in de beveiliging van een netwerk.
Ik geloof dat het hier meer om definities gaat. Niemand zegt dat een uitgelekt wachtwoord geen probleem is.

De vraag is of je het ziet als fundamentele fout van het systeem of als een beperking van een verder goed beveiligingsmiddel. Is het een onvoorzien probleem of een geaccepterd en gemitigeerd risico.

Kwetsbaarheden los je op. Je kan niet "oplossen" dat mensen nooit hun wachtwoord uitlekken zolang je gebruik maakt van wachtwoorden.

Niks is perfect, alles gaat een keer stuk, alles heeft beperking en als het goed is hou je daar rekening mee. Als het goed is hou je dus ook rekening met uitgelekte wachtwoorden.
de manier waarop ze op straat zijn komen te liggen en het al dan niet op de hoogte zijn van die status is de kwetsbaarheid, maar dat is zo met alle authenticatiemechanismen. Als iemand je pincode weet te achterhalen en steelt of skimt je bankkaart om vervolgens aan de automaat je rekening leeg te halen, dan zit er geen kwetsbaarheid bij de bank, maar in de persoonlijke bewaring bij de user.
Als iemand je pincode weet te achterhalen en steelt of skimt je bankkaart om vervolgens aan de automaat je rekening leeg te halen, dan zit er geen kwetsbaarheid bij de bank, maar in de persoonlijke bewaring bij de user.
Een kwetsbaarheid zit nog steeds bij de bank. Iemand kan met een tank het huis van de klant inrijden om diens pas te stelen en xkcd/538 toe te passen. De gebruiker valt dan niets te verwijten over het niet goed bewaren van de pas en het niet uitgeven van de PIN-code. Dat heet "overmacht" waar de gebruiker niets aan kan doen, maar de bank wel. Het is en blijft immers het systeem van de bank, niet van de gebruiker.

Voorbeelden van mitigaties die in de praktijk door banken worden toegepast:
• Beperkingen in hoeveel opgenomen kan worden in een bepaalde tijdsperiode.
• Actieve monitoring op het gedrag van de gebruiker. Bij verdachte zaken ingrijpen. Denk aan (veel) geld proberen op te nemen op een locatie waar de gebruiker niet is of niet kan zijn. Bijvoorbeeld: smartphone waarmee actief mobiel bankieren wordt gebruikt in Nederland, pas wordt gebruikt in Polen.

[Reactie gewijzigd door The Zep Man op 24 januari 2025 10:51]

hoeveel authenticatiemethodes zijn dan voldoende volgens jou? Er zal altijd een afweging tussen bruikbaarheid en beveiliging gemaakt moeten worden. Sommige van mijn peers hebben de theoretische focus zo hard op security gelegd in hun designs dat ze de praktische bruikbaarheid zwaar beïnvloeden, tot op het punt dat projecten zelfs gewoon afgeblazen worden door hun klant/gebruiker.

*edit* mitigatie is trouwens géén beveiliging, slechts damage control

[Reactie gewijzigd door dasiro op 24 januari 2025 11:47]

hoeveel authenticatiemethodes zijn dan voldoende volgens jou?
Waarom vraag je dit aan mij? Zo'n vraag is niet algemeen te beantwoorden en ik heb geen casus voor mij liggen. Als je zo'n vraag stelt en ik moet onderzoek doen voordat ik jouw vraag kan beantwoorden, dan mag je een factuur van mij verwachten.
*edit* mitigatie is trouwens géén beveiliging, slechts damage control
Mitigatie refereert naar wat gedaan wordt met een risico. Correcte mitigatie kan het risico verlagen door een betere beveiliging.

[Reactie gewijzigd door The Zep Man op 24 januari 2025 11:50]

ik ben geen bankier of klant, dit was gewoon een simpel voorbeeld van waar volgens mij de verantwoordelijkheid ligt en niet de kwetsbaarheid.
Sterker, het creëren van accounts en uitgeven van credentials brengt al een risico met zich mee en is daarmee een kwetsbaarheid.
Het uitgeven van accounts is geen kwetsbaarheid. Dat is onderdeel van een regulier proces dat gebruikers een systeem laat gebruiken.

Een risico is de mogelijkheid dat uitgegeven accounts gebruikt worden door iemand die niet de bestemde partij daarvoor is. Dat risico kan je mitigeren (sterkere authenticatie, actieve monitoring, ...). Als het risico niet voldoende gemitigeerd is, dan kan je spreken van een kwetsbaarheid. Wat "voldoende" is, is afhankelijk van de hoogte van het risico. Die hoogte wordt onder andere bepaald door de context van het systeem.

[Reactie gewijzigd door The Zep Man op 24 januari 2025 08:52]

Het uitlekken is dan niet de kwetsbaarheid, het feit dat je iedereen credentials moet geven is de kwetsbaarheid, want daarvan is geweten dat ze kunnen uitlekken. Vandaar ook dat MFA steeds belangrijker wordt.
Daarnaast heb je daarna nog een boel werk te doen om van 1 of 2 credentials door te kraken tot je echt in een positie bent om het netwerk over te nemen… Een student id of docent id is waarschijnlijk niet het account met de hoogste privileges. De escalatie poging is het gedeelte wat de TU/e waarschijnlijk wel heeft opgemerkt (aanname)
Ook het inloggen met een gelekt account kan opgemerkt worden.

Voorbeeld.

In Microsoft Entra ID heb je Entra Identity Protection (EIP). Hierbij krijgt een gebruiker een risicofactor low/medium/high op basis van gedrag. Je hebt hier onder andere "sign in risk". Wanneer EIP bijvoorbeeld merkt dat een user account normaliter inlogt vanuit de campus, maar plotseling vanuit een ander land en wellicht zelfs vanaf een anoniem ip adres, dan kan EIP al acteren.

En voor de andere reageerders: een "kwetsbaarheid in de beveiliging" is volgens chatgpt:
Een kwetsbaarheid in de beveiliging is een zwakke plek of fout in een systeem, software, netwerk of proces die kan worden misbruikt door een aanvaller om ongeoorloofde toegang te krijgen, gegevens te stelen, schade aan te richten of andere ongewenste acties uit te voeren. Het kan variëren van technische fouten in de software tot menselijke fouten of slechte configuraties.
Wanneer iemand inloggegevens van een medewerker heeft gestolen, kan de beveiliging nog steeds op orde zijn. Gelukkig was de beveiliging wél op orde, want de indringer is op tijd betrapt.
Het niet hebben van MFA kun je ook typeren als een kwetsbaarheid in de beveiliging. En het lijkt er ernstig op dat dit hier het geval was.
Daar heb je een punt. Nou is MFA ook niet de heilige graal, maar wel weer een extra drempel. :)
Dat is wat een junior/medior pentester waarschijn al wel kan in zo'n comples te beheren en te beveiligen omgeving als de TUE. En ransomware aanvallers hebben dat helemaal uitgewerkt.

In hoofdlijnen als je al op een windows systeem zit:
- credentials dumpen van dat systeem
- in kaart brengen van het netwerk (nmap, advanced ip scanner etc)
- met een account dat je hebt gevonden op het eerste systeem of door een kwetsbaarheid in een server, lateraal bewegen naar die server (grote kans dat in zo'n netwerk nog verouderde systemen draaien waar ze niet vanaf kunnen)
- daar weer credentials dumpen, grote kans dat je credentials vind die op veel systemen kan inloggen of zelfs domain admin is
- herhaal tot je domain admin bent, soms gebruiken ze een tool als bloodhound om de korste route in kaart te brengen

- ipv dumpen van credentails kunnen ook gelekte wachtwoorden worden gebruikt, of wachtwoorden die hergebruikt zijn worden misbruikt.
- kerberoasting is ook nog een optie

Hier staat een casus aardig uitgeschreven: https://thedfirreport.com/2024/08/26/blacksuit-ransomware/ en als je meerdere incidenten op die website leest zul je een herhalend patroon van activiteiten zien.

En als je het echt slecht voor elkaar hebt, dan zijn aanvallers bij stap 1 al domain admin (bijvoorbeeld Hof van Twente)

[Reactie gewijzigd door BytePhantomX op 24 januari 2025 09:53]

Een geleakt wachtwoord is volgens jou geen “Kwetsbaarheid in de beveiliging”?

Beveiliging hoeft niet per se een beveiligingssysteem te zijn. Beveiliging is een heel breed concept waar wachtwoorden prima onder vallen.
Sorry hoor, maar dat is niet wat een normaal mens verstaat onder kwetsbaarheid in de beveiliging in de wijze waarop het in dat artikel verwoord werd.
En als de "kwestbaarheid gedicht is" dan betekent dat simpelweg dat ze het password gereset hebben?

Dat is dan een zeer misleidende wijze van verwoorden.
Geen MFA is overigens ook gewoon een kwetsbaarheid in de beveiliging. Simpel.

Linksom of rechtsom ging het hier gewoon om een kwetsbaarheid in de beveiliging. Als een normaal mens dat anders intepreteert betekent het niet dat wat er staat niet waar is.

[Reactie gewijzigd door Ricco02 op 24 januari 2025 19:01]

Dat klinkt inderdaad heel anders.
Bij de aangestipte kop krijg je het idee dat het lek komt door slecht onderhoud of een verkeerde configuratie.
Gelekte creds is natuurlijk ook een kwetsbaarheid, maar dat gevoel krijg je niet bij zo'n kop.
Het is echt triviaal om gebruikersnamen en wachtwoorden van studenten te stelen die met Android met het wifi verbinden op een onveilige manier. Ik denk dat als je op een universiteit rondloopt, je zo een tiental wachtwoorden te pakken hebt. Deze onveilige manier van verbinden staat regelmatig in de handleiding van de universiteiten en scholen zelf.

Geen idee of er in dit geval gebruik van is gemaakt, maar dit is een sluimerend probleem dat niet echt adequaat wordt aangepakt.
Het enige wat je ermee zou kunnen doen (wat zeker een probleem is), is dat je een Wifi netwerk kunt opzetten om te spoofen. Helaas kan ik je vertellen dat een Wifi-netwerk met dezelfde naam, ook al vaak voldoende is voor dat doel.

Wat ik dan wel gek vind, is normaal gaat dat (portaal) verkeer ook over TLS, m.a.w. die versleuteling zit op applicatie niveau. Je kunt daar alleen bij met DPI, wat dacht ik alleen kan als je ook je eigen certificaat installeert op de clients.

Misschien is dat dan mogelijk? Ben geen expert in netwerken, ik probeer enkel te zoeken waar het mogelijke probleem in zit.
Wat bedoel je met dat "het enige wat je ermee zou kunnen doen (...), is dat je een Wifi netwerk kunt opzetten om te spoofen"? Je kan met deze methode (inderdaad d.m.v. een rogue AP) de gebruikersnaam en het wachtwoord waarmee verbonden wordt met wifi achterhalen. Aangezien de meeste onderwijsinstellingen je laten inloggen met je account wat je ook elders gebruikt, is dit een ernstig probleem. Zeker ook omdat mensen wachtwoorden hergebruiken voor bijvoorbeeld hun privé emailaccount.

"Wat ik dan wel gek vind, is normaal gaat dat (portaal) verkeer ook over TLS, m.a.w. die versleuteling zit op applicatie niveau."

De kwetsbaarheid die ik beschrijf gaat niet over een portaal, maar over de WPA2 beveiliging van het wifi-netwerk zelf. Daarvan gaat de handshake inderdaad over TLS, maar onderwijsinstellingen raden vaak aan hun gebruikers aan om het certificaat van de verbinding niet te valideren op Android. Daarmee kan je de MSCHAPV2 handshake achterhalen, en die is al een jaar of 10 compleet kapot.

Zie ook dit topic voor meer details.

[Reactie gewijzigd door Dalitso op 24 januari 2025 09:35]

Je hebt geen DPI nodig. Je kan perfect een cloned portal opzetten. En als je dat cloned portal opzet met een domeinnaam die heel erg gelijkt of hetgeen je nabouwt of bv Unicode tekens gebruikt in je domeinnaan kan je perfect een valide certificaat verkrijgen en valt het amper op en lopen er heel veel mensen in.
Zo triviaal is dat in recentere Android en iOS versies gelukkig niet meer. Daarvoor wordt tegenwoordig "Trust On First Use" gebruikt. Waarbij het certificaat (verplicht bij WPA Enterprise) dat de eerste keer aan de gebruiker getoond wordt, gezien wordt als het juiste certificaat. Als het certificaat dan wijzigt, zal een gebruiker expliciet actie moeten ondernemen om de verbinding te resetten.

Ook voor veel (bedrijfs)laptops is dit tegenwoordig vaak goed ingesteld. Of via Trust On First Use, of dat bij het uitrollen van de laptops het certificaat al ingeladen wordt.

(neemt niet weg dat er ook nog heel wat oudere Android en iOS telefoons in omloop zijn die deze maatregelen allemaal niet hebben, waardoor ze nog steeds kwetsbaar zijn)
2 factor authenticatie niet verplicht ? Dan had je dit voorkomen als ik het zo lees. Ondanks het ‘ gedoe ‘ van deze stap zou het overal verplicht moeten zijn in mijn ogen

Voorkomt hoop ellende
Inloggen op windows PC’s in een domein vereist geen mfa (in bijna alle scenarios). Ongeacht de instellingen van AD of account.
Dat klopt niet volledig.
Met Hello for Business kan je dat verplichten, alsook had je vroeger al smartcard authenticatie en via bv Silverfort kan je MFA verplichten op alles die met AD spreekt.
Zoals mrdaviper ook al zegt. Meerdere plekken gehad waar je toch echt niks van windows in kon stellen totdat je de 2FA door was of bij sommige zelfs per inlog IT expliciete goedkeuring
En wordt ook al op grote schaal omzeild via AiTM token theft.

Device based authentication zoals met een Yubikey of Windows Hello for Business is al nodig.

Meer info:
https://www.huntress.com/...ary-in-the-middle-attacks
Dank voor info , interessant , wist niet hoe dit in elkaar zat. Vandaar dat mijn bedrijf yubi keys heeft uitgedeeld
MFA op de Wifi lijkt me echt bloedirritant, dat ik elke keer m'n authenticator app erbij moet pakken om m'n telefoon / tablet weer van Wifi te voorzien.

Ik zou ook niet weten hoe ze dat technisch moeten implementeren, dan zou je iets van een landing page moeten maken, maar daar kunnen heel veel IoT devices niet meer overweg.
Als deze gestolen inloggegevens via infostealer malware zijn verkregen, kan het zijn dat het niet alleen inloggegevens waren maar dat ook de sessiecookies buitgemaakt waren. Daarmee kun je om MFA heen werken, doordat een lopende sessie geen MFA vereist.
Een behoorlijk aantal reacties hier gaat over allerlei aannames. Check gewoon met de school of 2FA verplicht is (volgens mij wel). Het mag best wat feitelijker allemaal.
Zeer zorgwekkend dat mensen die betrokken zijn bij het onderzoek zich laten verleiden tot het delen van informatie met derden. Het kan het onderzoek schaden.
Integriteit van de onderzoekers is een absolute voorwaarde om het onderzoek goed te kunnen doen.

[Reactie gewijzigd door Videopac op 24 januari 2025 09:45]

Een universiteit is een semi-openbare instelling. Dat maakt dat je op een andere wijze moet nadenken over je IT-landschap en de beveiliging ervan. Een consequentie van een populatie van tienduizenden waarvoor je niet alles kunt afdwingen is dat er continu devices zijn gecompromitteerd. Iedere dag.

Met dat gegeven: 'ik houd een netwerk in de lucht waarvan delen zijn gecompromitteerd' ga je een architectuur bedenken.
Daar mag je op veel plaatsen nog aan toevoegen in het onderwijs: 'met een bestuur dat niet in staat is krachtdadig op te treden en de autonomie van studenten en medewerkers en afwijkend gedrag een gegeven is'. Denk aan het uitwisselen van wachtwoorden, het draaien van illegale servers etc.

Wanneer je een hele universiteit moet platleggen omdat er accounts zijn gehackt heb je het gewoon slecht ingericht.
Een universiteit is een semi-openbare instelling. Dat maakt dat je op een andere wijze moet nadenken over je IT-landschap en de beveiliging ervan. Een consequentie van een populatie van tienduizenden waarvoor je niet alles kunt afdwingen is dat er continu devices zijn gecompromitteerd. Iedere dag.

Met dat gegeven: 'ik houd een netwerk in de lucht waarvan delen zijn gecompromitteerd' ga je een architectuur bedenken.

Wanneer je een hele universiteit moet platleggen omdat er accounts zijn gehackt heb je het gewoon slecht ingericht.
Ik ben het in principe met je eens maar het is makkelijker gezegd dan gedaan en er zijn altijd grenzen. Als bv het wachtwoord van een netwerkbeheerder is uitgelekt zal het lastiger zijn om vast te stellen welke delen nog veilig zijn.

In praktijk weet je meestal niet direct weet wat er aan de hand is en via welke route de aanvaller is binnen gedrongen en hoe ver de aanval is doorgedrongen. Je weet niet of je het begin van de aanval ziet en er eigenlijk nog niks aan de hand is, of dat je aan het einde zit en de aanvaller het niet meer nodig vindt om voorzichtig te zijn.

Ik heb ook wel eens in die situatie gezeten en zo'n beetje het enige dat je kan doen is zo snel mogelijk de deur dicht gooien, de boel bevriezen en onderzoeken wat er aan de hand is. Inschatten of je drastische maatregelen moet nemen zoals de TU/e gedaan heeft is enorm lastig, je hebt nog geen volledige informatie en moet vooral vertrouwen op je onderbuik. Bestuurders houden daar niet van en willen zekerheid. Alles down is een bekende en voorspelbare situatie. Dus liever de boel afsluiten en zeker weten dat er niks gebeurt dan met twijfel doordraaien.
Zeker weten dat er niks gebeurt... inderdaad gedurende meer dan een week(!) alles plat. Daar mag het bestuur op worden aangesproken.

Ik volg je dat het een lastige afweging kan zijn, maar dat komt ook doordat de inrichting er niet voor is.

Je moet naar een situatie waar je ook bij een aanval door kunt met die delen waar je geen aanwijzing hebt dat er iets aan de hand is.
Zeker weten dat er niks gebeurt... inderdaad gedurende meer dan een week(!) alles plat. Daar mag het bestuur op worden aangesproken.
Dat weet het bestuur vast. Het bestuur weet ook dat het gesprek nog lastiger wordt als blijjkt dat gevoelige data is uitgelekt (bv van buurman ASML).
Je moet naar een situatie waar je ook bij een aanval door kunt met die delen waar je geen aanwijzing hebt dat er iets aan de hand is.
We zijn het eens over het ideaal maar ik kan ze niet heel erg kwalijk nemen dat het ideaal nog niet bereikt is, volgens mij is de hele sector nog niet zo ver.
Ook 2FA tokens kunnen gehackt of gelekt worden. Het is al eerder gebeurd bij Authy bijvoorbeeld.
MFA tokens worden niet gehacked, maar worden via een MITM (Man-in-the-Middle) of BiTB (Browser In The Browser) "attack" verkregen.
TOTP secrets (en daarmee ook de tokens) kunnen natuurlijk eventueel wel worden verkregen door een hack/lek.

[Reactie gewijzigd door begintmeta op 24 januari 2025 09:16]

TOTP wel inderdaad, een Microsoft Authenticator token bv niet. (al kunnen ze wel eenmaal ze een succesvolle MiTM gedaan hebben en de tijdelijke MS Auth token hebben ook inloggen op je MS profiel en extra authenticators of GSM nrs voor MFA toevoegen)
Dank voor de aanvulling!
Ik neem aan dat je dan de passwordless Sign-In van MS Authenticator bedoelt—dat werkt voor zover ik weet in tegenstelling tot TOTP niet met een shared secret maar met public key authentication. Ook daarbij is het in principe natuurlijk mogelijk dat een private key wordt verkregen door een hack of lek. Ook bij FIDO2 is dat mogelijk, maar vanwege de aandacht die men normaalgesproken schenkt aan het veilig ontwerpen van dergelijke hardware/software, is de kans dat dat lukt natuurlijk bijzonder klein, zeker als men geen fysieke toegang tot de hardware heeft.

Het risico dat men erin slaagt TOTP-tokens of andere zaken waar een gebruiker meer bij betrokken is kan onderscheppen (mitm) is natuurlijk enorm veel groter.

[Reactie gewijzigd door begintmeta op 24 januari 2025 12:30]

Ik bedoel geen passwordless sign-in.
Ik bedoel de MFA functionaliteit van de authenticator app. Passwordless sign-in is/was - laatst ik controlleerde - enkel voor de web-based office apps.
Tenzij je Hello for business bedoelt, maar dat is niet aan de MS Authenticator app gelinked
Is verplicht alleen zou het bij sommige services zoals windows of VPN kunnen zijn dat je dit niet altijd nodig hebt. Zeker vanwege het feit dat VPN een tijd uit de lucht is klinkt dit als het meest aannemelijke mechanisme dat gebruikt is.
Gehackt.....wat word dat toch snel gezegd. Ze hadden de credentials, dus ze zijn gewoon ingelogd met buitgemaakte inloggegevens. Hacken is in mijn ogen wat anders. :)

Als ik iemand fop/afpers/bespioneer en bemachtig zo credentials, maakt me dat geen hacker. Eerder een boefje.
Als ik nou ergens fysiek of digitaal binnen kom, waarbij ik creatief heb moeten zijn dmv, bijvoorbeeld het exploiten van een vulnerability die je zelf gevonden hebt, dan wel

de Media kan de termen misschien wat secuurder gebruiken

[Reactie gewijzigd door Zjemm op 24 januari 2025 08:48]

Vanuit algemeen perspectief mee eens. Maar vanuit de definitie klopt het gewoon, een persoon die een computersysteem binnendringt en vanuit daar goed of kwaadaardige pogingen doet tot vergaren van gegevens.
Als je alleen maar inlogt met andermans credentials ben je nog niet aan het hacken. Maar als je daarna gaat zitten peuren in het netwerk om te kijken hoe ver je kunt komen ben je wel aan het hacken. Gezien de paniek op TU/E kunnen we rustig aannemen dat de persoon die de credentials had meer heeft gedaan dan alleen maar inloggen.
Vreemd, een beetje organisatie kun je weinig met gebr/wachtwoorden behalve op Wi-Fi inloggen etc maar nog steeds niet bij de bestanden komen gezien daar MFA voor vereist is.

Op dit item kan niet meer gereageerd worden.