Sitel: Okta-hackers vonden geen wachtwoorden in spreadsheet

Lapsus$-hackers maakten bij de aanval op loginprovider Okta geen gebruik van wachtwoorden die in een spreadsheet stonden. Dat zegt Sitel, het moederbedrijf van dienstverlener Sykes dat als toeleverancier werd gehackt door Lapsus$.

Sitel Group zegt in een verklaring dat er geen wachtwoorden in een spreadsheet stonden. Eerder deze week schreef TechCrunch op basis van documenten dat de hackers van Lapsus$ bij een inbraak een spreadsheet hadden gevonden met de naam DomAdmins-LastPass.xlsx. Hoewel TechCrunch niet bevestigde dat daar wachtwoorden in stonden, legden veel lezers wel een verband tussen de vondst en de hack. De hackers zouden de spreadsheet vijf uur vóór de inbraak op Okta hebben gevonden, wat impliceerde dat de spreadsheet inderdaad een export bevatte van domeinadminwachtwoorden.

Sitel wilde dinsdag TechCrunch geen reactie geven op dat nieuws. Nu zegt het bedrijf dat het nieuws niet klopt. "Deze spreadsheet bevatte accountnamen, maar geen wachtwoorden", schrijft het bedrijf. "De enige verwijzing naar wachtwoorden in de spreadsheet was de datum waarop wachtwoorden werden veranderd per account." Het bedrijf zegt ook dat de situatie 'niet bijdroeg aan de hack'.

Eerder deze maand bleek hackersgroep Lapsus$ toegang te hebben gekregen tot interne systemen van loginprovider Okta. Dat gebeurde via Sykes, een klantenservicebedrijf dat onderdeel is van Sitel Group. Het is nog steeds niet duidelijk hoe de hackers zijn binnengedrongen bij Sykes en hoe ze vervolgens via Sykes naar Okta zijn doorgedrongen.

Reacties (28)

[SunnieNL]

Tja, langzaam kun je wel wat lijntjes leggen hoe zaken gegaan zijn op basis van de lapsus$ chat (die gewoon op telegram open stond), de blog van okta en wat er verder naar voren komt. Dat de accounts niet bijdroegen kan ik mij niet direct voorstellen. Maar aan de andere kant, is het ook niet moeilijk te zoeken naar mensen die werken bij het bedrijf. Aan de lijst van accountnamen kun je vervolgens ook wel gokken hoe de gebruikersaccounts zijn opgebouwd.
Als er geen wachtwoorden in stonden, maar wel accountnamen, is het niet zo moeilijk om te gaan zoeken of er van een bepaalde accountnaam of voornaam.achternaam mogelijk standaard wachtwoorden in een lijst staan. Die probeer je uit. Nice, we zijn binnen op een RDP sessie (lapsus$ screendumps).. he, we hebben toegang tot okta. Mmm.. zelfde gebruikersnaam/wachtwoord werkt, maar we lopen tegen MFA aan (okta blog). Bombardement aan MFA requests naar een gebruiker en hij klikt ineens op goedkeuren midden in de nacht. (lapsus$ chat). Volgende stap, we voegen een nieuw device voor mfa toe (okta blog).
Dus we weten al best een hoop hoe dingen gegaan kunnen zijn. Het is nog wel gebaseerd op aannames, maar dat is sowieso altijd bij dit soort onderzoeken.

[mjtdevries]

Aannames die niet erg aannemelijk zijn.

Waarom denk je dat het document DomAdmins-LastPass.xlsx heet?
Zou dat er wellicht op wijzen dat LastPass gebruikt werd? Een wachtwoordbeheerder.
En is het dan niet extreem onwaarschijnlijk dat er in LastPass standaard wachtwoorden staan? Het soort dat een hacker kan proberen?

En juist bij een bombardement aan MFA request klikt een gebruiker niet, maar waarschuwt hij/zij IT security.

[robertlinke]

En juist bij een bombardement aan MFA request klikt een gebruiker niet, maar waarschuwt hij/zij IT security.

hoop je. ik zie het ook wel gebeuren dat iemand half slaap dronken op ja drukt om van dat constate piepende telefoon af te zijn terwijl ie slaapt.

[Scriptkid]

als hij dat doet dan kost dat hem bij ons een enorme boete,

als hij zijn telefoon niet wil horen zet hij hem uit, Je weet dat je elevated permissies hebt due je waarschuwd IT via de ingebouwde report functie en daarna zet je je telefoon gewoon uit kost je snachts net zo veel moeite als ok klikken alleen je hebt wel je juiste actie gedaan zonder repocussies.

[thanx]

Hmmmm… ik denk dat er heel veel gebruikers met MFA werken zonder echt te begrijpen wat het is. Zeker als het vanuit IT ingericht is voor gewone gebruikers en niet op eigen initiatief van de gebruiker zelf. Kans dat iemand niet beseft wat er gebeurd, en op een ongelegen moment de MFA melding wegklikt klinkt voor mij iig niet onrealistisch.

[Scriptkid]

daarvoor heb je verplichte trainingen waar bij je ondertekend dat je begrijpt wat er in de training geleerd is , voldoe je daar niet aan onderteken je nog niet en zoek je hulp,

Dit soort trainingen doen wij elke maand met voltallig personeel , iedereen weet dat er sancties en berispingen hangen aan het niet volgen van het beleid.

[thanx]

Werk jij bij een IT- bedrijf? Of doe je IT bij een bedrijf in een andere branche. Gezien jouw reactie vermoed ik het eerste….
Niet dat ik het geen goede aanpak vindt maar ik zie praktijkvoorbeelden vooral bij niet-IT-bedrijven en daar werkt het toch vaak anders….

[mjtdevries]

Hoop ik niet. Dat zie ik in de praktijk.

[laurens0619]

Gebruikers zullen het vast vaak rapporteren

Maar als jij nooit ziet gebeuren dat mfa zo gekraakt wordt dan zou ik mij toch afvragen of je niet misschien een compromised account gemist hebt?

Het is nl vrij lastig om (vanaf een non managed device) legitieme en malicious signins te onderscheiden. Helemaal nu aanvallers inloggen vanuit ip adressen uit dezelfde regio als slachtoffer en legitieme logins ook steeds vaker komen via vpn.

Nee dr aanval is aannemelijk, gelukkig heeft ms eindelijk een optie (in beta) om een otp in te voeren als onderdeel van de push auth. Dat gaat zeker helpen

[Bergen]

Als jij ligt te slapen, en je telefoon piept de hele tijd omdat iemand een MFA-request doet, doen klik je toch niet op "ja" om van het gepiep af te zijn? Ik kan me niet voorstellen dat iemand dat echt doet.

[serkoon]

Dit is gewoon een standaard praktijk van aanvallers om MFA te omzeilen. Nogal luidruchtig, maar het werkt.

[[BoSS]]

"Dit bestand heeft niet bijgedragen aan de hack want het bevat enkel account namen"

Accountnamen zijn toch ook best handig om te hebben bij een hack

[.oisyn]

Lijkt me inderdaad een prima startpunt voor social engineering.

[Royale de Luxe]

Niet alleen social engineering. Alles is afhankelijk wanneer een account blocked, welke de minimale paswoord voorwaarden zijn en of eerdere paswoorden al eventueel ergens in een database beschikbaar zijn op het darknet.

Credential stuffing is een veel voorkomende vorm van hacking en er zijn heel wat meer mogelijkheden.

[_Eend_]

Het scheelt een hoop werk inderdaad. Anders moet je naar mailadressen gaan kijken, die niet altijd gelijk zijn aan de gebruikersnamen, of je moet de gebruikersnamen uit metadata van door het doelwit gepubliceerde documenten trekken.

[mjtdevries]

Accountnamen zijn toch ook best handig om te hebben bij een hack

Het scheelt iets werk.

Maar tegenwoordig word meestal gesteld: "Security through obscurity is not security".
Het bekend worden van de accountnamen zou niet mogen uitmaken.

[.oisyn]

Maar tegenwoordig word meestal gesteld: "Security through obscurity is not security".

Het is dan ook geen vorm van security. Maar dat neemt niet weg dat het weten van een accountnaam een belangrijk gegeven voor een hacker om verder te werken. Zeker gezien het feit dat die accountnamen tegenwoordig vaak gewoon een emailadres zijn, waar je meer mee kan dan alleen inloggen in dat ene systeem.

[mjtdevries]

Houd je er wel rekening mee dat we het hier specifiek over domain admin accounts hebben?

[Overheid]

Alsof je middels een lijst met gebruikersnamen geen (veel gebruikte) wachtwoorden kunt proberen 🤪

[PdeBie]

Inderdaad. Je mag hopen dat ze een strenge policy hebben qua wachtwoord gebruik, maar als ze bijvoorbeeld "adm1n!" toestaan als wachtwoord is die snel genoeg geraden natuurlijk.

[croc]

ALS (met de nadruk op) ze regelmatig passwords wisselden en gebruik maakten van Lastpass mag ik toch hopen/veronderstellen dat het om random passwords ging met voldoende lengte.

[njitter]

nog beter, rolling Admin accounts. Ik moet die elke dag uit een Password Vault halen. Inlog in de Vault is met een RSA token.

[ETH0.1]

tjah, blijft lastig, je wachtwoorden moet je ergens op slaan omdat je als admin er simpelweg te veel hebt. of ze nu uit lastpass komen of dat ze in een excel lijst hebben gestaan, of dat ze zichzelf domain admin hebben gemaakt middels het hacken van de domain servers. Uiteindelijke conclusie is dat ze de sjaak zijn.

Overigens een kleine tip voor als je wel wachtwoorden op slaat, maakt niet uit waar. Al onze wachtwoorden staan ook ergens opgeslagen, maar niet volledig. In de database staat bv Wachtwoord1234! (alleen dan wat moeilijker )

Wat er niet in staat is dat al onze wachtwoorden een prefix hebben en een suffix hebben, mocht de database ooit gehacked worden moeten ze ook de prefix en suffix weten, die prefixen en suffixen staan nergens opgeslagen en dan is het raden geblazen.

Dus in de database staat bv: Wachtwoord1234!
Maar in werkelijkheid is het wachtwoord AB&Wachtwoord1234!@007

vergeet niet regelmatig de prefix en suffix te veranderen en zorg dat niemand die prefixen en suffixen opslaat, uit het hoofdje stampen!

[DaMonkey]

Tot je een bedrijf met een paar duizend meedewerkers bent waar er jaarlijks tientallen/honderden vertrekken. Ga je dan telkens je prefix en suffix aanpassen? Want iemand laat ze wel lekken.

[ETH0.1]

zoveel medewerkers hoeven die wachtwoorden niet te weten toch? en ja, bij vertrek veranderen wij die wachtwoorden.

Ik werk bij een bedrijf met 55.000 medewerkers en daar zijn maar een handje vol mensen die bepaalde wachtwoorden weten, en ook nog eens in het eigen team een select aantal (Hoeveel mensen moeten het wachtwoord weten van je storage, switches, iDrac, vCenter, vmware root etc etc etc) Dat zijn er niet heel veel.

Het leeuwendeel vind plaatst via AD authenticatie en dat doe je natuurlijk met je eigen account

[Overheid]

[mijn reactie was dubbel geplaatst..]

[Reactie gewijzigd door Overheid op 29 juli 2024 00:35]

[nopcode]

Ze hadden al toegang tot verschillende accounts voordat ze de DomAdmins-LastPass.xlsx downloaden van O365 (onedrive/sharepoint).

Als er inderdaad enkel usernames in die xlsx stonden, zal het niet zo veel meer uitgemaakt hebben op dat punt..
Ze zaten al in de O365 en waren localadmin op de thinclient dus konden sowieso de AD groups dumpen en die users vinden.

Volgens de timeline blijkt ook dat er geen nieuw account is gebruikt na het downloaden van de excel om een TenantAdmin aan te maken.
Ik concludeer dat ze op de RDP/thinclient al meteen een O365 admin hebben kunnen dumpen.

Lijkt me dat deze excel gewoon een interessante naam heeft waardoor het in het rapport staat.

[PcDealer]

Dat is frappant. Aon heeft de klantenservice (gedeeltelijk) geoutsourced aan Sitel. Aon gebruikt Okta: https://www.okta.com/integrations/aon-hewitt/#overview