Lapsus$-hackers kwamen mogelijk bij Okta binnen via spreadsheet met wachtwoorden

De Lapsus$-hackers die eerder deze maand securitybedrijf Okta hackten, vonden eerder een spreadsheet met wachtwoorden bij een onderaannemer van het bedrijf. Via dat bedrijf, Sykes, wisten de hackers mogelijk in de Okta-systemen te komen.

De aanvallers die eerder binnendrongen bij Okta gebruikten daarvoor mogelijk wachtwoorden die ze bij Sykes hadden gevonden, schrijft Techcrunch op basis van documenten rondom de hack. In die documenten staan meer details over hoe de aanvallers klantenservicebedrijf Sykes hackten en van daaruit bij Okta binnen wisten te komen. Okta besteedde klantenservicetaken uit aan Sykes. Volgens de documenten zouden de Lapsus$-hackers daar op 21 januari zijn binnengedrongen. Dat gebeurde via een vpn die Sykes op een oud netwerk van moederbedrijf Sitel Group gebruikte.

De hackers bewogen zich vervolgens door het netwerk van Sykes heen door diensten voor remote access en openbaar beschikbare hackingtools te gebruiken. Daarbij zou ook de Azure-omgeving zijn binnengedrongen. De hackers hadden vijf dagen toegang tot Sykes' systemen. Daarna resette Sykes alle wachtwoorden op het netwerk.

Tijdens de zoektocht in Sykes' netwerk vonden de hackers een bestand genaamd DomAdmins-LastPass.xlsx. Dat zou volgens Techcrunch mogelijk een export zijn van een LastPass-account. Vijf uur na de vondst wisten de aanvallers de netwerken van Okta binnen te komen. Ook maakten de hackers een achterdeur aan door een nieuwe gebruiker aan te maken op het netwerk van Sykes-moederbedrijf Sitel, voor het geval ze zouden worden buitengesloten. Hoewel de documenten niet specifiek melden of de wachtwoorden in de spreadsheet werden gebruikt om bij Okta binnen te komen, komt dat wel overeen met de tijdlijn van de hack.

Okta heeft inmiddels in een faq zijn excuses aangeboden voor de trage reactie op het lek. "We hebben een fout gemaakt. Sitel is onze dienstverlener waar wij eindverantwoordelijk voor zijn", schrijft het bedrijf. Okta wist al een tijd over een mogelijke inbraak bij Sitel, maar kwam daar niet mee naar buiten. Het bedrijf zegt nu dat het dacht dat er weinig risico voor klanten zou zijn.

Reacties (56)

[Muncher]

Interessante twitter thread hierover. Blijkbaar hebben ze de EDR zeer makkelijk kunnen uitschakelen. En ze hebben verder geen bijzondere tooling gebruikt, alleen wat op Github beschikbaar is (denk aan: mimikatz).

https://twitter.com/BillDemirkapi/status/1508527497008361472

Wel echt heel suf dat een bedrijf dat zich op de borst klopt als beste authenticatie provider op de markt, uiteindelijk gepakt word door een spreadsheet met wachtwoorden erin...

[SunnieNL]

Tegen stommiteit van gebruikers kan niemand iets doen. Je kunt het risisco alleen zo klein mogelijk maken.
Ik geloof nooit dat Okta zijn eigen MFA niet gebruikt om binnen te komen op hun systemen (blijkt ook uit de screenshots, die vanuit de okta omgeving zelf waren). Met alleen gebruikersnaam en wachtwoord ben je er dus niet. Als je gebruikersnaam en wachtwoord hebt kun je door en loop je tegen MFA aan. Echter, als je dat snel genoeg achter elkaar doet wordt het vervelend voor de eindgebruiker en een kans is groot dat je daarna op OK klikt om van de meldingen af te zijn. https://twitter.com/GossiTheDog/status/1506569465630269443
Okta kan er daarnaast weinig aan doen dat hun onderaannemer hun zaken niet voor elkaar heeft. Daar zijn echt wel meerdere fouten gemaakt. Het is al wonderbaarlijk dat ze 5 dagen in het Sitel netwerk konden rondbewegen voordat ze werden opgemerkt.

Snap overigens niet waarom alleen Okta nu de hele tijd wordt genoemd. Het is nu vrij duidelijk dat ze diep in Sitel zaten. Die hebben veel meer klanten dan alleen Okta. Potentieel elke klant van Sitel kan op dit moment een probleem hebben.

Daarnaast ben ik voor Sitel bang dat dit ook niet zo'n goede reclame is voor ze. De marketing tekst op https://www.sitel.com/abo...rity-and-risk-management/ kunnen ze beter even de deur uit doen...

[Reactie gewijzigd door SunnieNL op 23 juli 2024 00:00]

[Triblade_8472]

Hoezo MFA?

In de eerste alinea staat al dat het om een onderaannemer gaat van Okta waar het probleem ligt.
"Dat gebeurde via een vpn die Sitel op een oud netwerk van moederbedrijf Sykes gebruikte."

Het is wat warrig (en mogelijk foutief) geschreven.
In het bronartikel staat: "Sitel said it discovered the security incident in its VPN gateways on a legacy network belonging to Sykes, a customer service company working for Okta that Sitel acquired in 2021."

Ofwel, er was een oude en/of slecht beveiligde VPN gateway van Sykes, die Sitel overgenomen had. Ik verwacht dat het om een site-to-site VPN gaat, al weet ik dit niet zeker. Deze hebben geen MFA mogelijkheid, voor zover ik het weet.

Hierop is ingebroken en is de Excel sheet gevonden met geëxporteerde LastPass wachtwoorden. De naamgeving van de sheet doet denken dat het om Domain Admin accounts gaat [van klanten, ik].

Het is (helaas) goed mogelijk dat een emergency/break-the-glass account is aangemaakt in de Okta Azure omgeving waar géén MFA voor nodig is. Tja, dan heb je vrij spel.

[SunnieNL]

Vanuit de systemen van Sykes/Sitel was nog steeds MFA nodig richting Okta.
Vanuit Sitel kom je dus op de RDP die Sitel gebruikt om te verbinden naar Okta. Op die verbinding van Okta zat de MFA van Okta weer. Sitel doet namelijk niets anders dan support voor Okta. Dat bleek ook uit de screenshots van 21 januari van de Okta omgeving, welke dezelfde omgeving is als klanten ook te zien krijgen (alleen met andere applicaties) en daar kom je alleen maar in na de MFA van Okta.
Dit staat ook omschreven in het Plus only artikel van Tweakers en vind je ook terug bij Okta op de website:https://www.okta.com/blog/2022/03/oktas-investigation-of-the-january-2022-compromise/

January 20, 2022, 23:18 - Okta Security received an alert that a new factor was added to a Sitel employee’s Okta account from a new location. The target did not accept an MFA challenge, preventing access to the Okta account.

Ik geloof nooit dat Sitel een directe verbinding heeft met Okta zonder dat daar ook maar MFA authentication op zit.

[BytePhantomX]

Tegen stommiteit kun je niets doen, maar je kunt wel gelaagdheid aanbrengen om er voor te zorgen dat de impact van die stommiteit zo klein mogelijk is.

[Reactie gewijzigd door BytePhantomX op 23 juli 2024 00:00]

[nst6ldr]

Okta kan er daarnaast weinig aan doen dat hun onderaannemer hun zaken niet voor elkaar heeft. Daar zijn echt wel meerdere fouten gemaakt. Het is al wonderbaarlijk dat ze 5 dagen in het Sitel netwerk konden rondbewegen voordat ze werden opgemerkt.

Verhelderend, maar bovenstaande stukje is niet waar. Je kan prima een bedrijf aan bepaalde randvoorwaarden laten voldoen voordat je er mee gaat samenwerken. In andere industrieën zoals defensie is dit heel normaal en zijn bedrijven als Lockheed en Raytheon juist zo duur omdat ze de normen van hun opdrachtgever moeten naleven. Dit wordt overigens ook gecontroleerd door de opdrachtgever.

Als je een groot dienstverlener bent van een belangrijk beveiligingscomponent dan heb je mijn inziens minimaal diezelfde verantwoordelijkheid.

[Verwijderd]

Op het punt dat je super veel MFA push notificaties binnen krijgt, terwijl jij niet probeert in te loggen, hoor je eigenlijk ook wel te denken van; "Hey misschien heeft iemand mijn credentials ontfutseld, laat ik de sysadmin bellen of whoever over security gaat"?

Ik vind het vreemd, dat zoals je al linkte dat de werknemers al die certificaties zouden hebben behaald en dit niet voor hun zelf kunnen bedenken.
Desnoods deinstalleer je de MFA applicatie als je echt gek wordt. (Je hebt de recovery codes van je MFA applicatie opgeslagen in je password manager, right?)

[jcnwillemsen]

Het is indeed zo sterk als je zwakste schakel..Hoeveel mensen hebben niet pw opgeslagen als notitie op hun telefoon? Die voorzien is van een 4 cijferige pincode welke vaak te relateren is aan de persoon (e.g. geboortejaar). Idem voor passwoordmanagers, het is een uitkomst en risk at the same time.

[BytePhantomX]

Alhoewel ik snap dat ze niet blij zijn dat dit op straat ligt is het super informatief. Zit je zelf in zo'n positie, maak dan eens een lijstje voor jezelf. Wat blokkeer je, wat detecteer je en hoe zou je reageren op zo'n alarm en waar blokkeer je niets en ben je blind.

Vind het ook een mooi voorbeeld waar veel organisaties op vertrouwen. "Mijn AV of endpoint oplossing houd Mimikatz wel tegen" -> niet als je jouw endpoint kan uitschakelen en/of op uitschakeling geen alarm staat.

Maar ook het aanmaken van een forward rule. Dit is een hele bekende die gebruikt wordt door allerlei actoren en met name bij CEO fraude. Iedere organisatie zou dit moeten blokkeren of er een alarm op hebben staan. Net zoals het toevoegen van een account aan een tenant admin group.

[Reactie gewijzigd door BytePhantomX op 23 juli 2024 00:00]

[rvt1]

Het is ook suf, bij de bank waar ik werk ook MFA, maar het pop-upje op de telefoon laat dan weer niet zien wie om de authenticatie vroeg, zo nu en dan krijg je ook zomaar een pop-up en dan weet je het niet of het nu graf aan was, of een ander systeem waar weer net wel of niet SSO achter zit….

[De Vliegmieren]

Lijkt me redelijk normaal dat je met admin rechten een EDR agent kan uitschakelen.
Echter zou de centrale component van de EDR oplossing dit kunnen opmerken om een eventuele waarschuwing uit te sturen (om te verifiëren of er echt iets aan de hand is).

[robobeat]

Een goede EDR / AV agent zou dat juist niet mogen toelaten, zonder grote gevolgen. Die zitten vaak dusdanig en met meerdere processen genesteld in het systeem die, bij uitschakeling van 1 proces, er automatisch voor zorgdraagt dat dit proces weer wordt gestart, of het systeem volledig blokkeert om verder misbruik te voorkomen (denk aan blokkade van enig netwerk traffic).
Hierop zou dan vervolgens je SOC (of wie je EDR dan ook in de gaten houdt) op moeten acteren omdat het systeem niet meer online is.

[De Vliegmieren]

Je kan het vast moeilijk maken met zogenaamde 'watchdog' processen, maar zodra iemand beheer rechten heeft op besturingssysteem niveau kan je bijna elke beveiliging omzeilen (behalve enkele uitzonderingen zoals toegang tot de private sleutel in een TPM).
Denk alleen al aan het feit dat Windows de processen moet kunnen afsluiten bij een herstart. Wat weerhoudt een aanvaller om dit handmatig te doen via een 'psexec.exe -s'?

[robobeat]

Klopt, daarvoor moet je dus zorgen dat er juist wordt geacteerd bij het starten van processen zoals psexec.
Daarnaast is er een verschil tussen het geforceerd willen stoppen van een proces of het shutdown signaal.
Dan heb je in Windows ook nog zoiets als een Protected Process.
Deze processen (mits juist ingericht) worden gezien als "system critical" en kunnen niet eens gestopt worden ook al zou je cmd als SYSTEM runnen.
Een mooi artikel van Crowdstrike hierover: https://www.crowdstrike.c...h-mitigations-windows-81/

Ik wil alleen aangeven dat goede dergelijke software hiervoor tegen bestand is of bij misbruik direct acties uitvoert om het tegen te gaan.

[De Vliegmieren]

Misschien vergis ik me, maar dit soort beveiliging zie ik meer als 'security by obscurity' dan iets anders.

[Muncher]

Ik merk het aan je. Succes met inhouden.

[d5stick]

Erg slordig van een bedrijf om geen MFA te gebruiken op eigen VPN's en diensten waardoor scripkiddies zo binnen konden komen.. Als de eigen beveiliging niet op orde is hoe moet een klant er dan vanuit gaan dat die van hun op orde is?

[asing]

Ik zie in het verhaal veel meer fouten die op zichzelf niet voor echte problemen zouden moeten zorgen, maar een combinatie van missers zoals het laten slingeren van een export van domain admins, maakt het mogelijk.

Hopelijk zijn ze nu wakker en doen ze er wat aan.

[DeMolT.]

Bij een 'normaal' bedrijf zou ik het met je eens zijn, maar een bedrijf dat dit soort security software maakt en zo slecht omgaat met dit soort basale dingen...ik weet niet, ik vind dat wel erg slecht eigenlijk.

Ze hadden al wakker en alert moeten zijn, dit is hun core business.

[SunnieNL]

Nee, je maakt een fout. Alles wat hierboven beschreven is, is onderdeel van een onderaannemer van Okta. Die zijn niet gespecialiseerd in security software, maar voornamelijk in customer care en afhandelen van zaken voor bedrijven.

[DeMolT.]

Ah sorry, dat was mij niet helder, dank!

[YopY]

"Bij de loodgieter lekt het ook" denk ik dan maar. Ik denk dat in dit geval, iedereen die toegang had tot lastpass deze export had kunnen maken.

en natuurlijk, waarom wordt lastpass gebruikt om wachtwoorden te delen, dat hoort ook zo niet maar in een IT-organisatie heb je tegenwoordig zoveel systemen met zoveel accounts dat je wel begrijpt dat ze uiteindelijk maar accounts gaan delen.

[Hann1BaL]

Je kunt prima lastpass gebruiken om wachtwoorden te delen, maar niet via export van je kluis, maar door de deelfunctie in de software zelf.

Daar zijn de oplossingen zoals lastpass in enterpriseomgevingen juist voor bedoeld.
Dan zorg je in ieder geval dat iedereen met toegang tot die accounts gebruik maken van een SSO + MFA zodat je daarmee risico extreem verlaagt.

Domain admins zouden daar trouwens niet onder moeten vallen. Daar moet je echt extreem voorzichtig mee zijn. Het gaat mij nu even om het feit dat accounts delen met een PW manager in enterprise omgevingen wel gewoon goed mogelijk is, door het gebruik van de deelfunctie in de oplossing zelf. Niet door export en email

[Scriptkid]

Je kunt prima lastpass gebruiken om wachtwoorden te delen,

Hier ga je al stuk,

Wachtwoorden dien je niet te delen !! zeker niet van een account met privelege dat is absoluut not done in IT.

users dienen een pasw reset zelf te doen via SSPR of via een persoonlijke in person call met iemand van het bedrijf die ze kent.

[Hann1BaL]

Je deelt accounts, zonder dat je het ww ziet. Daar zijn tal van oplossingen voor. Dat is een kwestie van verwoording.

DIt is geen universeel iets:
A. Je doet dat wel bij een generiek account van een leverancier: Waar je office supplies koopt bijv
B. Je doet dit per definitie niet met accounts die domain admin zijn, want altijd persoonlijk.

Waar je nu over heen leest is de feature van account delen wat in de enterpriseomgevingen van PW managers zit. Het delen van accounts kan zonder het ww te laten zien en is gewoon een goede feature.

Uiteindelijk moet je voor zaken als domain admin en server admin al helemaal niet leunen op individuele accounts door lateral movement, maar dien je jezelf te beschermen met Privilege Access Management solutions die je alleen even toegang geven. Waarbij je bijvoorbeeld je eigen admin account WW niet weet, maar wel je eigen admin account kunt gebruiken door de PAM oplossing.

[Franky Boy]

Of je hebt meerdere databases, en de domain admin db wordt heeeeeel selectief gedeeld.
Bij ons hebben we een db voor field engineers, dan 1 voor systeem beheerders, en dan nog 1 voor de admins, met root wachtwoorden ed. Die laatste wordt maar met 5 personen gedeeld.
Dan nog 1 database die naar de klant gaat, ....

[mrdemc]

Het probleem daarmee is dat je achteraf niet kunt achterhalen, mogelijk, wie een bepaalde actie heeft uitgevoerd. Je audit logs zijn daarmee niets meer waard. Vooral met databases en domains e.d. kun je beter specifieke gebruikersaccounts aanmaken m.i.

[Reactie gewijzigd door mrdemc op 23 juli 2024 00:00]

[Franky Boy]

Ik snap wat je bedoeld, en dat gebeurd ook zoveel als mogelijk, maar sommige (oudere) systemen laten dat niet toe of hebben een beperkte hoeveelheid aan gebruikers, daar moet je wel met 'generieke' gebruikers namen werken, zeker als de groep klein is, en de bedrijfscultuur gezond, is dat geen issue gebleken. Iedereen maakt fouten, en die geef je toe, de rest leert ervan. Audit logs zijn niet de enige manier bij ons om te weten wie wat wanneer heeft gedaan, daar zijn ook ticket systemen voor, uren registratie, ...

[raro007]

Dus wat jij zegt dat als de lijding lekt en er niks aan doet is het normaal?
Want dat is die spreadsheet een lek.

[Iblies]

Ik zie in het verhaal veel meer fouten die op zichzelf niet voor echte problemen zouden moeten zorgen, maar een combinatie van missers zoals het laten slingeren van een export van domain admins, maakt het mogelijk.
…

🧐 Okta is geen bedrijf gerund door studenten maar heeft een omzet van 1,3 mld dollar en bijbehorende salarissen voor de werknemers (directeuren)

https://investor.okta.com...rter-and-fiscal-year-2022

Fiscal year 2022 revenue totaled $1.30 billion and grew 56% year-over-year; subscription revenue grew 57% year-over-year

Het probleem dat je nou hebt is dat je niet precies weet wat de schade is. Lapsus$ is dan wel opgepakt, maar als dit de werkwijze van Okta was, waren ze dan wel de enigste.

[De Vliegmieren]

Dit speelde bij een onderaannemer van Okta, Sitel. Eerlijk gezegd is het artikel van Tweakers zelf ook heel onduidelijk geschreven, en geeft de indruk dat Sitel toegang had tot de VMs die voor de Okta infrastructuur worden gebruikt.
In alle gepubliceerde communicatie tot nu toe is dat juist ten stelligste ontkend, en had Sitel alleen toegang tot web consoles voor het afhandelen van support tickets.
Vooralsnog zie ik geen redenen om aan te nemen dat de inbraak verder heeft verspreid dan systemen van Sitel zelf. Die domain admin accounts waren dus zeer waarschijnlijk ook voor systemen van Sykes, recentelijk opgekocht door Sitel maar wellicht nog niet beveiligd op het niveau dat Sitel intern handhaaft.

[Reactie gewijzigd door De Vliegmieren op 23 juli 2024 00:00]

[SED]

Als je het stuk daadwerkelijk gelezen had wist je dat de problemen zaten bij sitel.

[paella]

Er zijn ook nog dingen als site-to-site VPN's, daar zit sowieso geen MFA op. Ik lees nergens wat voor soort VPN het om gaat...

[MADG0BLIN]

Onvoorstelbaar dat je een dienst als LastPass gebruikt en dan nog steeds exports hiervan laat rondslingeren op je netwerk.

[n4m3l355]

Ik zou het omdraaien, ik vind het uiterst voorstelbaar dat dit gebeurd. Ik weet niet hoe het bij jullie op het werk is gesteld, maar bij mijn oude werkgever zag ik met name oudere werknemers keurig alles uitwerken in een excel lijstje en deze afdrukten. Dankzij 90 dagen wachtwoorden en andere redenen werd deze lijst door hunzelf waarschijnlijk bijna iedere week bijgewerkt. En dit slingerde gewoon op het openbare netwerk.

Wachtwoorden vragen hier gewoon voor, het wordt gewoon tijd voor alternatieve methodes van verificatie.

[Muncher]

Precies en daarom maakt dit het zo pijnlijk voor Okta. Zij verkopen juist al die alternative methodes van verificatie (denk aan: SSO via WebAuthn voor MacOS).

[De Vliegmieren]

Okta verkoopt IDaaS, geen wachtwoordkluis oplossing voor IT beheer accounts.
Dit speelde bij Sitel, niet bij Okta (ja het artikel is idd niet duidelijk hierover).
Een interessante vraag voor Okta zou kunnen zijn of ze hun onderaannemers verplichten om standaard beveiligingssoftware te gebruiken zoals een PAM oplossing, en indien niet: waarom niet?

[Reactie gewijzigd door De Vliegmieren op 23 juli 2024 00:00]

[Franky Boy]

Bij ons wordt je gewoon tijdelijk buiten dienst gesteld als dit vaker dan 1 keer wordt vast gesteld. Je werkt met (zwaar) beveiligde netwerken, dus ben je je bewust van de gevaren.
Duurt even, maar de laatste jaren is er niemand meer die dit ook maar in zijn hoofd haalt. Gewoon consequent zijn, en dus ook de teamleider of manager krijgt dezelfde behandeling.

[Verwijderd]

Uh-huh, tot het bedrijf wat groter wordt en een controle hierop steeds moeilijker gaat zijn.

[MADG0BLIN]

Bij ons op het werk bij de admins gebeurt dat dus niet. We hebben hiervoor ook wachtwoordkluizen e.d. Misschien bij gebruikers inderdaad, maar zeker geen admin wachtwoord rondslingeren. Dat je in een tijd als 2022 dat als beheerder nog niet begrijpt is echt te gek voor woorden wat mij betreft. De lekken en hacks vliegen de laatste tijd weer om je oren en dat je dan admin wachtwoorden opslaat op een netwerk schijf in een excel sheet..

[Auredium]

Dit verbaasd mij niets. Beveiliging gaat vaak de deur uit op het moment dat een third party wordt ingehuurd. Als Bedrijf X bedrijf Y inhuurt dan zou je initieel zeggen dat security policy wordt nageleefd en in theorie zou dit ook moeten. De realiteit is echter dat bedrijf Y al snel 'flexibel' om gaat met de veiligheid om wille van gemak. Vaak zat in het verleden meegemaakt dat gemakshalve creditials statisch worden gehouden of gedeeld worden terwijl duidelijk is dat deze gevoelige info herbergen.
De reden hiervoor is vaak een mix van 'ze moeten zelf zorgen dat hun beveiliging in orde is' en mensen die simpelweg niet voldoende bewustzijn en training hebben gehad omtrent veiligheid en gevoelige gegevens. Dan wordt vaak gekozen voor gemak; een lijstje met inlog gegevens hier en daar op netwerkshares zodat het team makkelijk bij alles kan komen. Dat doet natuurlijk ook gelijk het nut van de beveiliging ongedaan.

Daar lijkt het hier dus ook op. Sitel werkt voor Okta en omdat er een koppeling is die niet goed wordt beheerd wordt deze aangetast en gekraakt. Dit is van beide partijen fout.

[Franky Boy]

In veel contracten met derden zie ik een heel hoofdstuk dat ze zich dienen te houden aan de security eisen. En dan uiteraard audits houden, onderaannemer bewust maken, ....
Security is niet in 1 dag geregeld, continue bijhouden, nieuwe bedreigingen zien, opnieuw inrichten.

[Herax10NL]

Dit bewijst maar weer dat je beveiliging zo sterk is als je zwakste schakel.

[HenkEisDS]

It's not a hack. It's barely social engineering. It’s more like natural selection. - Gilfoyle

[Franky Boy]

De laatste keer dat ik wachtwoorden in een Excel file heb gezien was ergens rond 2010

[Rollo]

Ik zit geregeld in online meetings met medewerkers van TCS en die delen zelfs hun scherm terwijl ze door hun wachtwoord spreadsheetjes scrollen. Als je ze vraagt even te wachten zodat je een screenshot kan maken luisteren ze nog netjes ook.

Al meerdere keren aangegeven en wordt helemaal niks mee gedaan. Echt belachelijk

[SED]

Ik had diverse van die lijstjes met pakkende namen in de honeypot staan.
Werkte altijd..

[Franky Boy]

De beste security audit

[bilkin2005]

De laatste keer dat ik wachtwoorden in een Excel file heb gezien was ergens rond 2010

Ik vorig jaar bij de export van Lastpass naar Bitwarden

[Neus]

Yup, dat gebeurt.

Deed een intake-gesprek bij een bedrijf om bij hun de IT te doen en toen ik met hun de server ruimte inliep (deur niet op slot) stond daar een oude IBM server met het scherm aan en een venster van TeamViewer (met ID en wachtwoord) gewoon open. Snel een foto van geschoten en vanaf kantoor een audit gedaan. Uiteraard had ik zeer snel full-access tot hun network; eigen admin account kunnen aanmaken, firewall kunnen aanpassen, etc.

Dit alles netjes gedocumenteerd en aangeboden... En dan was ìk nog correct en netjes.

[Valandin]

Mooi stuk om in het achterhoofd te houden als bedrijfsonderdelen uitbesteden ter sprake komt in een organisatie. Kan je zelf je security op orde hebben, maar als je onderaannemer zo lek als een mandje is..
(Al had Okta dat in dit geval natuurlijk niet)

[Reactie gewijzigd door Valandin op 23 juli 2024 00:00]

[Xfade]

Ben je dan nog een hacker groep als je inlogt met een wachtwoord ?