Aanvaller UvA en HvA kwam binnen via besmette laptop van student
De aanvaller achter de aanval op de Universiteit van Amsterdam (UvA) en de Hogeschool van Amsterdam (HvA) kwamen binnen via een besmette laptop van een student, zo blijkt uit onderzoek. Bij de aanval werden meer dan zestig servers van de onderwijsinstellingen geïnfecteerd en werden versleutelde wachtwoorden van zowel studenten als medewerkers buitgemaakt.
De laptop van de student raakte op 11 februari besmet met malware waardoor de aanvaller toegang tot meerdere accountgegevens krijgt, waaronder inloggegevens van een HvA/UvA-gebruikersaccount. Hoe de infectie precies plaatsvindt wordt niet door de onderzoekers vermeld. In het onderzoeksrapport staat alleen dat malware op de laptop wordt gedownload. Op 12 februari, binnen 24 uur na de aanval op de laptop, gebruikt de aanvaller buitgemaakte inloggegevens om de Citrix-omgeving van de onderwijsinstellingen te verkennen.
Een andere aanvaller maakt op 13 februari gebruik van het op de laptop verkregen account om in te loggen op de it-omgeving van de HvA/UvA. Daarbij verzamelt hij steeds meer rechten. Twee dagen later op 15 februari signaleert het Security Operations Center (SOC) verdachte activiteiten op het netwerk die van vrijdagnacht 12 februari tot en met zondag 14 februari plaatsvonden. Het gaat onder andere om password spraying en verkenning van het netwerk.
Password spraying is een techniek waarbij een aanvaller door middel van veelgebruikte wachtwoorden probeert om op een account in te loggen. Om detectie te voorkomen probeert een aanvaller eerst één wachtwoord tegen een groot aantal accounts, voordat er een tweede wachtwoord wordt gebruikt. Door deze techniek voorkomt de aanvaller dat een account wordt geblokkeerd en de aanval wordt opgemerkt.
Na deze aanvallen gebruikt de aanvaller tenminste één beheerdersaccount om vanuit Citrix toegang te krijgen tot onder andere de scriptingserver. Uit onderzoek blijkt dat tenminste elf gebruikersaccounts, waarvan tien beheerdersaccounts, 62 servers en alle drie de domeinen (hva.nl, uva.nl en foret.nl) in de infrastructuur van de onderwijsinstellingen zijn gecompromitteerd.
De aanvaller heeft op tenminste drie manieren toegang gekregen tot gebruikersgegevens. Zo is er een kopie gemaakt van de Active Directorydomeindatabase. Deze database bevat onder andere inloggegevens zoals gebruikersnamen en wachtwoordhashes, e-mailadressen en telefoonnummers.
Het SOC signaleert de aanval op maandagochtend 15 februari en meldt dit aan het Computer Emergency Response Team (CERT) van de UvA en HvA. In overleg met het CERT worden maatregelen genomen om het risico te beperken. Zo wordt onder andere de monitoring uitgebreid, een aantal wachtwoorden gereset en een aantal gecompromitteerde beheerdersaccounts geblokkeerd. Volgens de onderzoekers passen de waargenomen activiteiten bij een ransomware-aanval. Er is vooralsnog geen bewijs dat de twee aanvallers aan elkaar te koppelen zijn.
"De tweede aanvaller heeft als doel om ransomware te installeren en start die route door eerst zoveel mogelijk informatie te vergaren over het Active Directory-domein en de trust-relaties tussen de domeinen. Er is geen verklaring waarom de aanvaller koos voor de HvA/UvA, anders dan toeval, voortkomend uit de gecompromitteerde gegevens van patiënt-0", zo staat in een rapport van COT Instituut voor Veiligheids- en Crisismanagement dat onderzoek naar de aanval deed.
Aangezien de Active Directory-domeindatabases is gestolen vragen de UvA/HvA aan medewerkers en studenten om hun wachtwoorden te wijzigen. Binnen een paar dagen hebben ruim honderdduizend mensen hun wachtwoord aangepast. Ondertussen gaat de strijd tegen de aanvaller door. Op 10 maart wordt het sein "brand meester" gegeven. Het herstel neemt echter nog enige tijd in beslag.
Het COT stelt dat de crisisorganisatie van de onderwijsinstellingen goed gefunctioneerd heeft. Zo is er door veel mensen goed en effectief samengewerkt. Wel moet er in de komende periode nog meer gebeuren om de veiligheid te vergroten, zo staat in de aanbevelingen.
Joh echt. Open deur.
Ze hadden beter de open deur kunnen gebruiken om de IT afdeling buiten te trappen.
ingelogde gebruiker uiteindelijk het hele systeem/netwerk kan overnemen.
Je kunt toch nooit uitsluiten dat zo'n student account "in verkeerde handen valt", bijvoorbeeld omdat je een student
hebt binnengehaald die voor een hackersclub of vreemde mogendheid blijkt te werken.
Als het systeem van binnenuit zo gemakkelijk te hacken is dan is de situatie waarschijnlijk verloren.
Even verder lezen svp: Patiënt-0 is geïdentificeerd, het is de laptop van een student.
Even verder lezen svp: Patiënt-0 is geïdentificeerd, het is de laptop van een student.
Je hebt zat studenten met extra ''rechten'' op het intranet omdat ze student-assistent zijn of van een of andere interne commissie. Zo misbruikten we vaak de ''medewerkers'' pas van een medestudent voor gratis koffie en printergebruik. Koffie en printen is duur tegenwoordig, dus alle beetjes helpen.
Is dit echt terug te voeren op één zwak wachtwoord voor een beheerdersaccount (én géén 2fa daarop)?
Joh echt. Open deur.
Ze hadden beter de open deur kunnen gebruiken om de IT afdeling buiten te trappen.
Inderdaad, je hebt gelijk want als IT hun zaakjes op orde had dan is een hack of een virus of gebruiken van gestolen credentials gewoon godsonmogelijk!
Heel goed te voorkomen met goed ingericht beheer en duidelijke richtlijnen. Bv: een domain admin account heeft nooit iets te zoeken op systemen waar bij te komen is vanaf gebruikerssystemen.
Dat is al jaren bekend, maar de UvA had het alleen al kunnen lezen in het verslag van de UM.
Kennelijk had/heeft beveiliging geen prioriteit.
Ik kan alleen voor mijzelf spreken maar bij mij is dit zeker niet algemeen bekend.
Zou je dit met wat bronnen en redenen kunnen toelichten?
Ik kan alleen voor mijzelf spreken maar bij mij is dit zeker niet algemeen bekend.
Zou je dit met wat bronnen en redenen kunnen toelichten?
Werd eens tijd dat er meer ingezet wordt op wachtwoordlengte, ipv het veroorzaken van hergebruik van zwakke wachtwoorden met hooguit kleine wijzigingen. Dat is een van de redenen waarom NIST niet aanraadt om niet periodiek wachtwoorden te wijzigen.
Ook bijzonder om te zien dat men trots is op de afhandeling, maar nergens een woord over het feit dat in 2021 dit aanvalspatroon al lang ondervangen had moeten zijn. IT-managment heeft jaren zitten slapen.
Dat is niet leuk om te onderkennen, maar wel belangrijk om beter te worden.
Ik kan alleen voor mijzelf spreken maar bij mij is dit zeker niet algemeen bekend.
Zou je dit met wat bronnen en redenen kunnen toelichten?
Alstublieft:
https://docs.microsoft.com/en-us/microsoft-365/admin/misc/password-policy-recommendations?view=o365-worldwide
Citaat: "Password expiration requirements do more harm than good, because these requirements make users select predictable passwords, composed of sequential words and numbers which are closely related to each other."
https://gisf.ngo/wp-content/uploads/2014/09/0185-Zhang-et-al-2010-Password-Security.pdf
Citaat: "We believe our study calls into question the merit of continuing the practice of password expiration"
https://people.scs.carleton.ca/~paulv/papers/expiration-authorcopy.pdf
Abstract: "Many security policies force users to change passwords within fixed intervals, with the apparent justification that this improves overall security. However, the implied security benefit has never been explicitly quantified. In this note, we quantify the security advantage of a password expiration policy, finding that the optimal benefit is relatively minor at best, and questionable in light of overall costs."
https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-63b.pdf
Zie pagina 14: "Verifiers SHOULD NOT require memorized secrets to be changed arbitrarily (e.g., periodically)."
https://www.ftc.gov/news-events/blogs/techftc/2016/03/time-rethink-mandatory-password-changes
https://www.ncsc.gov.uk/collection/passwords/updating-your-approach
Citaat: "Regular password changing harms rather than improves security. Many systems will force users to change their password at regular intervals, typically every 30, 60 or 90 days. This imposes burdens on the user and there are costs associated with recovering accounts."
https://www.ncsc.gov.uk/blog-post/problems-forcing-regular-password-expiry
Is dit echt terug te voeren op één zwak wachtwoord voor een beheerdersaccount (én géén 2fa daarop)?
Nee, het was ook een laptop (en netwerk servers) die een besturingssysteem voor lichte consumententoepassingen gebruiken in een professionele context.
Is dit echt terug te voeren op één zwak wachtwoord voor een beheerdersaccount (én géén 2fa daarop)?
Nee, het was ook een laptop (en netwerk servers) die een besturingssysteem voor lichte consumententoepassingen gebruiken in een professionele context.
Linux doosjes zijn even kwetsbaar op dit punt hoor: ook bij Linux kan je onder root/admin rechten de wachtwoorden uit het geheugen vissen, of de kerberos tickets exporteren.
En als een beheerder van een Linux doos een onveilig wachtwoord gebruikt zonder MFA, is het niet lastig om onder de credentials van die Linux beheerder kerberos tickets van collega's te exporteren.
Daarnaast zijn het vaak de Linux dozen op een enterprise netwerk die nog met legacy cipiers werken. Hoe vaak DES en RC4 op 'Windows omgevingen ' niet uitgezet kan worden binnen kerberos omdat de Linux systemen dan niet meer werken.
Of dat ze nog NTLMv1 vereisen dat al 20 jaar als onveilig wordt gezien.
Nee, niet zo neerbuigend naar Windows doen, terwijl je weet dat credential treft binnen Linux even eenvoudig uitgevoerd kan worden.
Deze posting is gelocked. Reageren is niet meer mogelijk.
Junior DevOps Engineer
Certified Secure is op zoek naar een Junior DevOps Engineer. Deze functie is een stuk interessanter dan de term doet vermoeden! Om jou als potentiële nieuwe collega meteen te laten zien wat we doen hebben we speciaal voor jou een selectie gemaakt van een aantal leuke security challenges. Are you ready for a challenge?
Cybersecurity Trainer / Streamer
Toe aan een nieuwe nieuwe job waarmee je het verschil maakt? In de Certified Secure trainingen laat je deelnemers zien hoe actuele kwetsbaarheden structureel verholpen worden. Ook werk je actief mee aan de ontwikkeling van onze gamified security challenges. Bij het maken van challenges kom je telkens nieuwe technieken tegen, van Flutter tot GraphQL, van Elastic Search tot Kubernetes.
