Microsoft: Russische staatshackers hadden toegang tot e-mailaccounts managers

Microsoft meldt dat de Russische hackersgroep Nobelium onlangs toegang had tot e-mailaccounts van managers en personeel van het bedrijf. De hackers zouden e-mails en bijlagen hebben buitgemaakt, maar hadden naar verluidt geen toegang tot klant- of productgegevens.

Microsoft schrijft dat de hack eind november van start ging en op 12 januari is ontdekt. Het Amerikaanse bedrijf zegt dat de hackers gebruik hebben gemaakt van een password spray attack. Dat is een cyberaanval waarbij veelgebruikte wachtwoorden worden uitgetest op verschillende accounts in de hoop om zo toegang te krijgen tot sommige van die accounts zonder dat daarbij de accountblokkering wordt geactiveerd.

De hackers zouden op die manier toegang hebben gekregen tot een oud testaccount binnen het bedrijf en dankzij de permissies van dat account wisten ze ook e-mailberichten en bijlagen van personeelsleden en enkele hooggeplaatste managers te bemachtigen. Uit intern onderzoek zou overigens blijken dat de aanvallers op zoek waren naar informatie over henzelf.

Volgens Microsoft gaat het om hackers van Midnight Blizzard. Dit hackerscollectief staat ook bekend als Nobelium en wordt in verband gebracht met de SolarWinds-cyberaanvallen in 2020. Volgens de Amerikaanse regering waren bij die aanvallen minstens honderd bedrijven en negen Amerikaanse overheden getroffen. Microsoft maakt zich heden ten dage sterk dat er geen sprake is van een kwetsbaarheid in de interne systemen. Het bedrijf zegt ook dat er geen klant- of productgegevens zijn buitgemaakt.

Update, 09.35 uur: de term 'kaderleden' in de titel, inleiding en broodtekst vervangen door 'managers'.

Reacties (68)

[DirtyBird]

Password spraying, briljant. Je zou op een domein dus ook over meerdere accounts heen moeten kijken of er vaak een verkeerd password wordt gebruikt in een korte tijd.
En hoe doe je dat als je bijv. Google bent die gmail wil beveiligen?
Ik ben echt benieuwd hoe je je hier tegen kunt wapenen.

[banaj]

Twee opties (die ook te combineren zijn):

(1):
Gebruik MFA.

(2):

• Wachtwoord blacklist. Bijvoorbeeld de top 1000 van meest gebruikte wachtwoorden plus variaties Plus organisatie-specifieke wachtwoorden zoals de naam, het adres etc..
• Beperkt aantal pogingen per account. Daarna tijdelijk op slot of verplichte CAPTCHA.
• Beperkt aantal pogingen per IP. Daarna ban.

De eerste bullet is goede hygiene zodat slechte wachtwoorden niet gebruikt mogen worden. De tweede en derde zorgen dat je niet eindeloos kunt proberen.

Merk trouwens op dat er een verschil is tussen password spraying (= alles proberen zonder context) en credential stuffing (= eerdere combinaties die door het account gebruikt zijn, en gelekt). Dit probleem bij MS was password spraying. Dat is de simpelste aanval van de twee. Beschermen tegen credential stuffing is veel moeilijker. Oftewel: dit was nog maar de beginnersfout. Zelfs als ze de drie basispunten hadden doorgevoerd dan zou credential stuffing alsnog succesvol kunnen zijn...

[Reactie gewijzigd door banaj op 22 juli 2024 18:12]

[Verwijderd]

banaj schreef onder meer:

• Beperkt aantal pogingen per account. Daarna tijdelijk op slot of verplichte CAPTCHA.
• Beperkt aantal pogingen per IP. Daarna ban.

Ik ben het eens met de rest, maar m.b.t. de hierboven genoemde twee punten:

• Lawrence Abrams, oprichter van Bleeping Computer, schreef hierover:

A password spray is a type of brute force attack where threat actors collect a list of potential login names and then attempt to log in to all of them using a particular password. If that password fails, they repeat this process with other passwords until they run out or successfully breach the account.

Bij een dergelijke aanpak hebben de aanvallers minder last van ingelaste vertragingen en zouden grote aantallen accounts geblokkeerd kunnen worden. Een captcha is mogelijk bij webmail, maar hoe doe je dat in Outlook? Door de SSO-aanpak van MS ontkom je mogelijk niet aan het blokkeren van gehele Microsoft accounts.

• Stateful attackers beschikken vaak over een botnet (of huren dat). Het is bij dit soort aanvallen zelden zo dat die vanaf één IP-adres afkomstig zijn.

Dat neemt niet weg dat de laatste twee maatregelen die je noemde verstandig zijn, maar soms helpen ze onvoldoende, en kun je beter focussen op de eerdere opties die je noemde (de "top 1000" wachtwoorden checken lijkt mij overigens veel te weinig).

Opmerkelijk (los van wat banaj schreef)
Zoals anderen al schreven, het meest opmerkelijke is dat via een gecompromitteerd "legacy non-production test tenant account" de e-mail accounts van senior medewerkers (waaronder securitymensen) gehacked konden worden.

En dat Microsoft mogelijk nog niet alle schade in beeld heeft; als je na het ontdekken van de aanval op 12 januari (bijna 2 maanden nadat ingebroken werd), 1 week later nog bezig bent met het volgende, lijkt er een flinke slag om de arm te worden gehouden:

We are in the process of notifying employees whose email was accessed.

The attack was not the result of a vulnerability in Microsoft products or services. To date, there is no evidence that the threat actor had any access to customer environments, production systems, source code, or AI systems. We will notify customers if any action is required.

Edit 12:09: tekst verduidelijkt

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

[Verwijderd]

Ip block is wel fijn binnen een bedrijf, dan hebben ineens hele afdelingen geen toegang meer 😅

[rob12424]

Een blacklist moet een controlle uitvoeren. Dat lijkt mij ook weer een veiligheidsrisico?

[PolarBear]

Verschillende oplossingen:

• Password manager met alleen maar random wachtwoorden, ook voor de 'niet intressante' sites.
• MFA
• FIDO
• Paskeys

[DirtyBird]

Dat is vanuit een gebruikersperspectief, tenzij je het forceert. Ik weet niet zeker of MS dat op dit moment doet.

[WillySis]

Een wachtwoordmanager met een gemakkelijk te raden hoofdwachtwoord is niet bepaald een goede beveiliging. Wachtwoorden in de cloud bewaren vind ik dubieus. Zodra een wachtwoordmanager is gekraakt liggen je wachtwoorden ook snel op straat.

Ik gebruik wel een wachtwoordmanager (password safe), maar sla de kluis lokaal op. Collega's gebruiken hetzelfde programma. Wachtwoorden in de browser opslaan is verschrikkelijk gemakkelijk, maar ook dat is een veiligheidsrisico. Ik doe dat alleen voor een beperkt aantal sites waar hackers nauwelijks persoonlijke informatie op kunnen vinden.

[_Joe_]

Na een bedreiging als deze, zelfde beetje als met Okta, denk ik dat je al voorbij dat punt bent dat een password manager nog effectief zal zijn.

Zullen veel meer op Zero Trust basis gaan moeten werken en dan echt de focus op hen processen en gedrags policies aanpassen.

Laatste 3 puntjes zeker maar dan met iets als Hashicorp Vault om “least privileges” van wachtwoorden op profiel/gebruiker af te dwingen, die dan ook de wachtwoorden rouleert en by default randomized.

Telkens hoor je weer dat het ging om wachtwoorden die hergebruikt werden en al ergens in een database stonden met compromised credentials.

[Reactie gewijzigd door _Joe_ op 22 juli 2024 18:12]

[Yo!Bananas]

Secure, quick, reliable login (SQRL)

[Blokker_1999]

Het verbaasd me dat het binnen MS dus mogelijk is om een test account te hebben in de productie mail omgeving die toegang heeft tot meerdere mailboxen zonder dat er een vorm van goede beveiliging geforceerd wordt.

[Webgnome]

Het is net een echt bedrijf

[Cergorach]

Het is Microsoft verdomme, ze bieden zelf vergaande beveiligingsproducten aan die je hier prima tegen zouden bewapenen. Een al hele oude is MFA, die werkt prima tegen password spraying, alleen weer niet tegen andere attacks.

Dit lijkt weer zo een gevalletje "Do as we say, not as we do!".

Het gaat om een "legacy non-production test tenant account", hoe die in hemelsnaam bij productie heeft kunnen komen is mij een raadsel...

[djwice]

Een grote valkuil van de security teams bij grote bedrijven is dat ze het interne netwerk meer vertrouwen dan internet.

Waardoor er als iemand op het interne netwerk zit bijvoorbeeld geen MFA wordt gevraagd. Ook als ze normaal alle devices van kantoorgebruikers een vast IP geven, komt er geen alarm of extra veiligheidscheck als de gebruiker via een ander dan eerder, IP-adres inlogt.

Vaak hebben interne wél SSO (single-sign-on) met de AD (Active Directory, zeker bij Microsoft), maar niet altijd https. Ben je ingelogd bij een, werkt die token ook bij een andere (https) applicatie. Vaak zelfs als die tweede MFA vereist om de token te verkrijgen, kom je er zonder MFA in als je al een token hebt van een andere app.

Ook is de segmentatie niet altijd aanwezig of niet volledig doorgevoerd, waardoor test servers toegang kunnen hebben tot productie systemen en het kantoor netwerk.


Dus dit is eigenlijk een type aanval die in elk groot bedrijf effectief uitvoerbaar is. Hoe erg de security baas ook roept van niet (hoe harder de ontkenning ...).

Ik vind het opvallend dat als er toegang is geweest tot e-mail dat er geen managers bij zaten die klant contact hebben. In e-mail heb je immers vaak toegang tot e-mailadressen (contacten).

[Reactie gewijzigd door djwice op 22 juli 2024 18:12]

[OruBLMsFrl]

Dit is een service account, daar kun je geen mfa op zetten tenzij je accepteert dat die steeds stilvalt totdat iemand ergens namens dat service account de mfa check doorloopt. Dat is vaak totaal onpraktisch.
Verder helemaal eens met wat je zegt. De praktijk is helaas weerbarstig.

[EnigmA-X]

Wat niet goed in het artikel hierboven staat, maar wel in het artikel van Microsoft:

the threat actor used a password spray attack to compromise a legacy non-production test tenant account and gain a foothold

Een legacy non-production test tenant dus. Hoogstwaarschijniljk daarom ook zonder de "security defaults" die ze tegenwoordig op alle tenants forceren en daarmee ook MFA wordt geforceerd.

Slordig? Absoluut en dat gaan ze nog wel een paar keer horen.

[AJediIAm]

Het is net alsof er mensen werken die menselijke fouten maken.

[Cergorach]

Natuurlijk werken er mensen, natuurlijk worden er fouten gemaakt. Maar fouten van dit kaliber, die al zo lang bestaan en dan zoveel in een keer? Dat is in mijn ervaring laxheid. Dit is (of hoort) hun corebusiness te zijn.

En don't get me wrong, ik geef niet specifiek de mensen de schuld die dit fout hebben gedaan, maar dergelijke situaties ontstaan door een bepaald type corporate culture die wordt gefosterd door alle medewerkers en dus het hele bedrijf, wat dus het probleem is. Overal worden fouten gemaakt, doen we allemaal. Vaak worden die fouten opgevangen door bestaande (controle) processen, maar soms glipt er wel eens wat doorheen. Maar wat ik zo tussen de regels doorlees bij het bron artikel, is dit een oude (legacy) test omgeving die voor de een of andere reden genoeg rechten had om dingen te doen op de Exchange Online productie omgeving... Niet alleen zijn er verschillende fouten gemaakt ergens in een ver verleden, maar niemand controleert in de tussentijd. En dat baat mij zorgen!

Ook weet ik dat MS vaak producten verkoopt met mooie praatjes, die eigenlijk toch niet echt productie klaar blijken te zijn. Dat weet je omdat je al decennia heel veel werkt met verschillende MS producten en er regelmatig heel diep in moet duiken. Maar ik heb altijd de instelling gehad dat MS een betere keuze is qua IT diensten dan alles zelf willen doen en zelf willen hosten omdat het hun core business is en daarmee zouden ze het beter doen dan het gros van de interne IT organisaties. Die mening heb ik nog steeds, maar daar zijn wel iets meer scheurtjes in ontstaan met dit soort shenanigans, helemaal dat het anderhalve maand heeft geduurd voordat het werd ontdekt. Dat is nog wel steeds beter dan bij veel interne IT organisaties...

[Aldy]

Dit is een waarschuwing voor alle bedrijven. Kijk of er nog testaccounts aanwezig zijn en als ze niet meer gebruikt worden, verwijder ze dan volledig. Elk middelgroot tot groot bedrijf heeft weleens testen gedaan met testaccounts en die zijn of vergeten of de verantwoordelijke persoon heeft inmiddels het bedrijf verlaten.

[FriXion]

Wat ook zou kunnen is dat er een testomgeving was waarin gebruikers van de live omgeving zaten (bijvoorbeeld omdat ze een database van de live omgeving gebruikt hebben op de testomgeving). Als ze met een test account dan in die testomgeving komen en gaan rondsnuffelen in de andere accounts die daar staan, kunnen ze de ontdekte gebruikersgegevens weer gebruiken op de live omgeving.

[Verwijderd]

Volgens mij heb ik vroeger bij een bedrijf de inlogprocedure aangepast vanwege iso 27001. Bij 5 foute inlogpogingen een blokkade van 15 minuten voor dat ip adres en die gebruiker. Zodat alleen dat account 15 minuten geblokkeerd was. Echter mochten ze 1000den ip adressen hebben ben je er met een sterk wachtwoord nog niet. Geeft je slechts 5000 wachtwoorden per kwartier per 1000 ip adressen vrij. Waterdicht is het natuurlijk niet. Je zult ook een trigger kunnen instellen zoals totaal aantal inlogpogingen per dag overschrijven dan andere gebruikersnaam aanvragen

[Verwijderd]

En daar zullen de hacker niet aan gedacht hebben? Als je dit gewoon over weken maanden uitsmeert zal je niet sn l gedetecteerd worden lijkt me, zeker met ti up adressen

[Verwijderd]

Nou als je goed gaat loggen per account, kan je dat monitoren en zodoende de gebruikersnaam na zoveel foutieve inlogpogingen wijzigen waardoor de teller opnieuw begint voor die nieuwe inlognaam. Dus ww wijzigen eens per maand. Gebruikersnaam wijzigen na x aantal foutieve triggers. Dit is goed te monitoren

[bdevogt]

de gebruikersnaam na zoveel foutieve inlogpogingen wijzigen

Je hebt even geen idee wat er allemaal aan een gebruikersnaam hangt,
tientallen achterliggende systemen waar de sync omvalt (die op inlognaam werkt)

Het aanpassen van een inlog naam heeft grote gevolgen.

[Verwijderd]

Is het niet beter om een username aan een vast id te hangen en dat id te koppelen aan die andere systemen?

[bdevogt]

Kon dat maar,
verschillende systemen verschillende ontwerpers

[rob12424]

Dat klopt. Maar dan moet je als hacker een delayer gaan gebruiken. Een persoon kan maar x zo snel typen en een computer sneller. Dus komen je aanvragen te snel binnen. Kun je er ook een permanente blok opgooien (mits je netwerk goed is afgesteld en dat ook toestaat)

[d3burt]

MFA is een goede eerste stap, maar dat moet dan wel op alle accounts aan staan. Daar ging het hier ook mis, want Microsoft gebruikt intern bijna overal MFA.

Het probleem met detecteren is dat de boefjes over zulke grote botnets beschikken dat je zelden meer dan één combinatie van username en password van hetzelfde IP adres zult ontvangen. Ik heb een zeer agressieve fail2ban configuratie op mijn mail server, en die ziet bijna nooit tweede pogingen. Je moet van heel veel mail servers de data aggregeren voor je er iets mee kunt.

Sommige bedrijven hebben passwords compleet vervangen door Passkeys. Als je dan een password voorbij ziet komen weet je dat iemand je wil hacken. Kennis waarmee je alsnog weinig kunt trouwens...

[Peatsmoke]

Dat tante Sjaan of Henk dit overkomt, vind ik nog begrijpelijk, maar van managers en alle andere medewerkers van Microsoft, zou je toch wel mogen verwachten dat ze fatsoenlijke wachtwoorden en op zijn minst 2FA gebruiken.

[Miglow]

Om vervolgens hun wachtwoord nog steeds op een briefje aan de monitor te plakken omdat de eisen die aan hun wachtwoord gesteld worden zo onmogelijk zijn?

De zwakste schakel in cyber beveiliging is de mens van wie de gegevens beveiligd moeten worden.

[Reactie gewijzigd door Miglow op 22 juli 2024 18:12]

[Verwijderd]

Of het wachtwoord naar zichzelf te sturen in een email of whatsapp bericht om het niet te vergeten

[-tom-562]

Het overkomt Floris-Jan de consultant en Fleur van HR ook gewoon hoor.

[PB.]

Ik vind het wel goed van Microsoft dat ze dit (hopelijk eerlijk) aangeven. Dat is wel de juiste manier om met dit soort dingen om te gaan. Het is natuurlijk voor Microsoft van levensbelang dat bedrijven hun security vertrouwen, maar dat begint wel hier. Dit soort dingen hoor je niet onder het tapijt te schuiven, dat zou pas een security risico zijn.

[Verwijderd]

Door PB.:

Ik vind het wel goed van Microsoft dat ze dit (hopelijk eerlijk) aangeven.

Zeker. Maar sowieso zijn de regels m.b.t. datalekken bij beursgenoteerde bedrijven in de USA de laatste tijd flink opgeschroefd, het is niet meer zo of er een keuze bestond.

Daarbij, zoals ik in de tweede helft van eerdere reactie schreef, ik vind het (na de Chinese hack van medio vorig jaar) opmerkelijk dat via een gecompromitteerd "legacy non-production test tenant account" de e-mail accounts van senior Microsoft medewerkers (waaronder securitymensen) gehacked konden worden.

Dit heeft nul-komma-niets met "zero trust" te maken. Aangezien nagenoeg alle bedrijven na een datalek (geadviseerd door juristen) alleen melden wat zij nu zeker weten, kon ook dit lek wel eens een dikkere staart krijgen.

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

[Wouterie]

Hmm... behalve dat het wel redelijk gekleurd is. Sowieso de term staatshackers. Die gooien ze erin zonder dat er ook maar enig bewijs is dat die gasten in opdracht van de staat werken. Nu is er alle aanleiding om dat wel aan te nemen, maar er is geen bewijs.
Daarbij heeft Microsoft een tijd geleden een rapport uitgebracht met een leuk overzicht van cybercriminaliteit wereldwijd. Uiteraard staan Rusland, China en Noord-Korea in de top, maar de grote afwezige was de VS.
Microsoft heeft een politieke agenda en die agenda dient de VS. Uiteraard ook haar bondgenoten, maar we weten allemaal hoe de VS omgaat met bondgenoten. De VS zijn er alleen maar voor de VS.

[MrX_Cuci]

Het verbaast mij dat mensen verbaasd zijn dat dit is gebeurd. Een van de Best practices van MS is een zogenaamd break-out account in te stellen, zodat je in noodsituaties (falende MFA services bijvoorbeeld) toch bij je Tenant kan komen.

[pe0mot]

Terecht, daarom dus twee MFA mechanismen.
Alles redundant, ook de login's. Maar wel altijd MFA.

[mutley69]

Dus de managers van Microsoft gebruiken geen MFA?

[Oliekoets]

Precies mijn gedachte, management weet precies wat goed voor hun is, ondanks de ideeen van hun technici.

Iets dat ikzelf ook te vaak herhaal voor management:

Het maakt hackers niet uit waarom het zo is, alleen dat het zo is.

[PolarBear]

Voor alle duidelijkheid het gaat om medewerkers van Microsoft zelf, namelijk: "members of our senior leadership team and employees in our cybersecurity, legal, and other functions".

/Edit: voor de duidelijkheid dit was gepost toen het bericht nog over kaderleden sprak en niet verwees naar Microsoft zelf.

[Reactie gewijzigd door PolarBear op 22 juli 2024 18:12]

[PolarBear]

Wel intressant in het statement van Microsoft:

We will act immediately to apply our current security standards to Microsoft-owned legacy systems and internal business processes, even when these changes might cause disruption to existing business processes.

En

This attack does highlight the continued risk posed to all organizations from well-resourced nation-state threat actors like Midnight Blizzard.

Wat je ook van Microsoft vind ik hoop dat deze inzichten breed worden gedeeld, ook in het MKB, in directies en management. Security niet serieus nemen is gewoon een tikkende tijdbom.

[pe0mot]

Oeps, waarom geen MFA!!! Microsoft zegt dat o365 admins de MFA moeten verplichten. Maar zelf hebben ze dit niet begrepen.
testaccount? Dan minimale rechten.

[adjep07]

Gaan er geen alarm bellen bij hun Ciso af als er continue - als een soort mitrailleur stel ik mij zo voor - met hetzelfde wachtwoord op verschillende accounts wordt getracht in te loggen?

[S.McDuck]

Daar zit je met je handreikingen, SCIRT's frameworks en processen: Als een bedrijf als Microsoft zich al niet kan verdedigen hoe kan het gemiddelde bedrijf zich dan beveiligen tegen dit soort actoren?
De resources en middelen zijn vele maken groter als een gemiddeld bedrijf. Ach ja nog maar een awareness filmpje kijken

[ralpje]

Vergeet ook niet dat deze aanvallers waarschijnlijk zeer gericht op zoek waren naar bepaalde informatie. De commitment om dan daadwerkelijk binnen te komen (en dus de inzet) is dan ook een stuk groter.
Met zaken als MFA en een fatsoenlijk wachtwoordbeleid bescherm je jezelf prima tegen dit soort aanvallen, de ROI voor de aanvaller wordt dan al heel snel heel veel kleiner.
In dit geval is er echter zoveel 'te halen' dat de ROI (ondanks de extra inzet) hoog genoeg blijft om door te zetten.
Het is dus niet zomaar te zeggen dat 'als Microsoft dit niet kan, hoe kan het gemiddelde bedrijf het dan wel'. Hoge bomen vangen veel wind. De beveiliging die voor een gemiddeld bedrijf prima is, is dat dat voor een bedrijf als Microsoft niet.

[kodak]

Het nieuws is niet dat Microsoft de beveiliging heel goed geregeld had. Eerder het omgekeerde, omdat er geen heel geavanceerde problemen genoemd worden waarmee het deze problemen gaf. Dus dan zomaar doen alsof je Microsoft als voorbeeld kunt nemen alsof een ander bedrijf dus maar niet opgewassen kan zijn tegen het probleem in dit nieuws is te makkelijk.