'Verkeerd geconfigureerde Microsoft-server lekte gegevens van 65.000 bedrijven'

Securitybedrijf SOCRadar heeft een datalek ontdekt op een server van Microsoft. Het bedrijf kreeg toegang tot 2,4TB aan gegevens met daarin data van meer dan 65.000 bedrijven. Microsoft erkent het datalek, maar zegt dat SOCRadar het aantal slachtoffers overdrijft.

Volgens SOCRadar bevatte de Microsoft-server meer dan 335.000 e-mailadressen, maar ook informatie over meer dan 133.000 bedrijfsprojecten en data van ongeveer 548.000 personen. Het securitybedrijf kon offertes, bestelformulieren, ondertekende documenten, prijslijsten, verkoopstrategieën en andere belangrijke bedrijfsdata identificeren.

SOCRadar heeft Microsoft op 24 september ingelicht over het lek. Het Amerikaanse bedrijf kwam daarna snel met een oplossing en schermde de data daarna af. Microsoft betreurt naar eigen zeggen de fout en bevestigt dat namen van personen, e-mailadressen, e-mails, bedrijfsnamen, telefoonnummers en bestanden toegankelijk waren via de server. Het bedrijf stelt wel dat SOCRadar de omvang van het lek verkeerd heeft ingeschat. Volgens Microsoft zouden er veel dubbele gegevens op de server staan.

Het bedrijf betreurt ook dat SOCRadar een tool heeft gepubliceerd waarmee klanten kunnen nagaan of er data van hen is gelekt. Volgens Microsoft kan deze tool de gegevens van klanten alsnog blootstellen. Alle klanten die bij het lek zijn betrokken, zijn volgens Microsoft inmiddels ingelicht.

Door Jay Stout

Redacteur

20-10-2022 • 09:41

90

Reacties (90)

90
86
48
7
0
28
Wijzig sortering
Zeer groot punt als kanttekening: de detectietool van SOCRadar kijkt niet alleen naar dit lek, maar naar alle informatie die het bedrijf heeft. Een melding "Detected" is dan ook geen garantie dat de data in deze BlueBleed dataset zit.

Getroffen organisaties hebben via hun admin portal een bericht van Microsoft gekregen (te lezen door Global Admins). Heb je hier geen bericht, dan zitten er geen gegevens van je organisatie in dit lek. Ik heb hier bevestiging van gehad van Microsoft voor mijn eigen organisatie.

[Reactie gewijzigd door the_shadow op 26 juli 2024 02:21]

bij mij staat de melding er wel.. maar heel moeilijk te vinden.. had ik nooit naar gekeken als dit bericht niet op tweakers voorbij had gekomen

geen idee of MC442057 een generieke code is of specifiek voor mijn tenant.. je kan filteren op tag: Data Privacy
https://admin.microsoft.c...enter/:/messages/MC442057

titel: Investigation Regarding Misconfigured Microsoft Storage Location
tag: Data Privacy
MC442057 · Published Oct 4, 2022 (last updated Oct 10)

Message Summary
In coordination with an external security research firm, we recently became aware and subsequently corrected an issue affecting a subset of Microsoft customers. A legacy endpoint was found to be accessible to the Internet which contained business transaction data between your organization, Microsoft or an authorized Microsoft partner. The identified information was not related to your use of Microsoft products or services but corresponds to user and organization contact information used for business interactions between Microsoft and prospective customers.

We’ve confirmed that the endpoint has been secured as of Saturday, September 24, 2022, and it is now only accessible with required authentication. Microsoft is committed to helping keep our customers secure. As part of this effort, we continuously monitor our services and collaborate with external partners to identify activity which is unusual or of concern.

Our investigation did not find indicators of compromise of the exposed storage location. Additionally, we found that no customer accounts and systems were compromised due to unrestricted access. However, an external security research firm who reported the issue to Microsoft, confirmed that they had accessed the data as a part of their research and investigation into the issue.

Root Cause

The issue was caused by an unintentional misconfiguration on a legacy endpoint that is not in use across the Microsoft ecosystem. This was not a result of a security vulnerability, and the isolated incident is not indicative of any issues with our cloud operations, or their infrastructure. The affected endpoint was no longer intended for production use and is scheduled for permanent decommissioning in the near future.

How does this affect my tenant?

We’ve identified that your organization was in scope of this incident. Affected data types that may have been involved included names, email addresses, company name, address, or phone numbers. We are unable to provide the specific affected data from this issue.

[Reactie gewijzigd door MvGroenigen op 26 juli 2024 02:21]

We are unable to provide the specific affected data from this issue.
Is dat niet tegen de AVG / GDPR in?
Lekken van die persoonsgegevens moet jij als bedrijf melden bij de autoriteit en je moet de personen kunnen informeren.
Deze verplichting geldt voor de gegevens verantwoordelijke. MS heeft hier de rol van verwerker.

Als je de melding hebt, moet je er van uit gaan dat alle accounts in die tenant geraakt zijn. En daarvan kun je dan zelf een lijst genereren.
Enig idee hoe je dan kan na gaan in welk datalek je wel betrokken bent?
We krijgen de melding Detected maar hebben geen bericht in ons Microsoft Admin portal
Hier kan je je doein checken of je erbij zit: https://socradar.io/labs/bluebleed
Hun eigen artikel: https://socradar.io/sensi...isconfigured-data-bucket/

De manier waarop socradar dit heeft gevonden: (En microsoft dit met hun eigen Extended Threat Intelligence platform niet heeft opgemerkt)
SOCRadar, an Extended Threat Intelligence platform, continuously monitors the surface web, deep web, and darknet for vulnerabilities and data leaks. BlueBleed Part I is discovered as the result of such monitoring. On September 24, 2022, SOCRadar’s built-in Cloud Security Module detected a misconfigured Azure Blob Storage maintained by Microsoft containing sensitive data from a high-profile cloud provider.

[Reactie gewijzigd door HKLM_ op 26 juli 2024 02:21]

Dat zijn heel veel buzzwords om zo min mogelijk duidelijk te zijn waar ze de gegevens vandaan hebben en wat ze zijn gaan verwerken.
misconfigured Azure Blob Storage
Dat is heel concreet en maakt direct duidelijk waar ze de data vandaan hebben. Een "open" storage account levert direct een threat melding op, tenminste bij mij. Hoe ze dit genegeerd hebben of geaccepteert is de vraag
Het is daarmee alleen concreet waar de gegevens oorspronkelijk stonden. Het maakt niet duidelijk of het bedrijf die Azure Blob Storage zelf heeft gebruikt, of dat anderen dat al gedaan hadden en bijvoorbeeld sommige gegevens op het dark web probeerde te verkopen en ze daar achter kwamen.
Wat ik ervan begrijp is dat op die storage account allerlei bestanden stonden, waaronder ook database backups. Al die bestanden waar ze bij konden hebben ze doorgenomen en daar kwam de informatie vandaan. Er is voor zover ik kan lezen niks "gelekt" naar het darkweb, maar de informatie was publiekelijk toegankelijk. Of het daadwerkelijk uitgelezen is en ergens op het darkweb terecht is gekomen (behalve de lees acties door socradar zelf) kan ik indedaad nergens terugvinden.
Het is ook anders te lezen. Het bedrijf stelt op verschillende manieren te zoeken naar mogelijke lekken, zonder duidelijk te noemen waar ze de gegevens gevonden hebben die ze op het spoor bracht van deze verkeerd geconfigureerde azure omgeving.
Dan is het onduidelijke of de gegevens al gelekt waren en ze zo op het spoor kwamen van deze azure omgeving. Of dat ze een deel van de gegevens vonden en daarna de azure gegevens vonden en daar misschien meer gegevens haalde. Of dat ze eerst de azure omgeving vonden en daar de gegevens vandaan haalde.

Hoe dan ook zou ik het redelijker vinden als het bedrijf eens heel duidelijk is waar ze zelf de relevante gegevens vandaan hebben, welke gegevens dat zijn, waar ze de grens hebben getrokken en waarom ze hun verwerking redelijk vinden.
Dat zijn heel veel buzzwords om zo min mogelijk duidelijk te zijn waar ze de gegevens vandaan hebben en wat ze zijn gaan verwerken.
misconfigured Azure Blob Storage maintained by Microsoft containing sensitive data
Dit is toch vrij duidelijk? De blob was waarschijnlijk publiek toegankelijk (echt een beginners fout) en dan is downloaden van data een eitje.
Alleen heeft Microsoft ondertussen ook al gemeld dat er geen ongeautoriseerde toegang is geweest tot die bucket. M.a.w. voor zover we weten is SOCRadar's de enige die er ooit toegang toe had en nu dus ook de enige die (deels) deze informatie op straat gooit. Dat gezegd hebbende blijkt ook dat een groot deel van die 65.000 in werkelijkheid dubbele versies van elkaar zijn...
Juist. Dus Microsoft claimt dat niemand toegang heeft gehad en jij claimt daarna dat SOCRadar toegang heeft gehad... dat kan niet beide waar zijn.
'Niemand heeft ongeauthoriseerde toegang' is damage control. Sowieso heeft SOCRadar toegang gehad, anders zouden ze dit lek niet op het spoor gekomen zijn. Tenzij SOCRadar geauthoriseerd is, bijvoorbeeld als pentest partij, en er verder inderdaad niemand anders bij is geweest, zou ik Microsoft niet op hun blauwe ogen geloven.
De PR-afdeling van SOCRadar heeft een belang om het op te blazen.
Waarheid zal ergens in het midden liggen.
Houdt dit dan in dat SOCRadar nu eigenlijk het lek is geworden ?
De data is "gelekt" naar SOCRadar, zo zou je het kunnen omschrijven. Het is best kwalijk dat SOCRadar die data vervolgens beschikbaar stelt om te zoeken of je wel of niet in voorkwam. Dat moet je eerst overlaten aan het bedrijf waar de configuratie fout zat. Die kan iedereen die in de data voorkwam informeren, dat hoef je niet zelf doorzoekbaar te maken lijkt mij.
Het is ook een lek als een bedrijf zonder toestemming alsnog die gegevens is gaan verwerken of gegevens daaruit zomaar aan het delen is geweest. En daar lijkt het hier helaas ook op. Het lek bij Microsoft is kennelijk nu dicht, maar dit bedrijf toont kennelijk niet aan dat ze zelf geen lek zijn of waren door de gegevens te verwerken.
Het lijkt me niet redelijk dat er geen ongeauthoriseerde toegang was terwijl een bedrijf dan gegevens toont die uit dat lek komen.
en heeft dus niks te maken met dark net, deep web en dat soort vage termen.
Ook het eigen artikel klinkt meer als een stuk reclame voor hun diensten dan informatie verstrekking.
Dat denk ik, het is ook vaak zo als lekken een eigen logo/catchy naam/website krijgen
Het punt is ook dat het bedrijf socradar nu in bezit is van gestolen of tenminste illegaal verkregen data, ze hadd het ook kunnen melden zonder zich de data toe te eigenen. Daarnaast is ook niet zeker dat deze data ook in handen is van kwaadwillenden, dus het enige datalek is vooralsnog socradar zelf. Daarmee rijst de vraag wat het nut van de tool is totdat bewezen is dat de betreffende data ook in handen is van anderen.
Ze kunnen ook hashes gemaakt hebben van de data, en dus de data zelf niet toegeëigend hebben.
Maar door de hash opnieuw te berekenen van het invoerveld in de tool kan er dus een match gevonden worden.
Maar als ze een hash hebben gemaakt dan hebben ze tenminste de data ongeautoriseerd verwerkt...
Er was geen autorisatie ingesteld op de BLOB storage. Dus kan je dan wel spreken van ongeauthoriseerd?
En privacy gewijs zijn hashes geen probleem lijkt me.
Omdat een deur niet op slot zit geeft dat nog geen toestemming om naar binnen te gaan.
Het feit dat je als bedrijf kunt zien dat je onderdeel was van dit lek en daarop adequate maatregelen kunt nemen (bijvoorbeeld je data elders neerzetten en personeel extra scherp maken op mogelijke phishing pogingen de komende periode). Dat lijkt me al erg nuttig.

Ik vind het best opmerkelijk dat je meteen over 'gestolen' en 'illegaal verkregen data' begint. Het is in beginsel Microsoft die (al dan niet onwetend) die data publiceert. Dan kun je de messenger wel neerschieten maar dat gaat je als gedupeerde niet helpen. SOCRadar heeft in mijn ogen gewoon netjes gehandeld door Microsoft in te lichten over het lek en ze de tijd te geven het euvel op te lossen. Als SOCRadar daarna de eventueel gedownloade gegevens verwijderen lijkt me dat ze niets te verwijten valt.
gmail.com - detected

zegt helemaal niks

[Reactie gewijzigd door cracking cloud op 26 juli 2024 02:21]

Ik houd altijd al een dubbel gevoel over aan 'de cloud', aangezien je eigenlijk geen idee hebt waar je data precies blijft en hoe er mee omgegaan wordt. Je vertrouwt het toe aan een andere organisatie en gaat er vanuit dat het goed zit. Dit is een voorbeeld waarom ik het zo tricky vind, zeker (naar ik aanneem) dat dit een menselijke fout is die blijkbaar zo gemaakt is...
Zeker als bedrijf, waar het hier om gaat, kun je prima nagaan waar je data wordt opgeslagen. De "cloud" is niks anders dan VM/server in een datacenter op een locatie. Ik weet voor ons bedrijf precies waar dat is. Daar hoef je helemaal niet blind op te vertrouwen, dat is wat mij betreft onderdeel van je due diligence.
Dit is niet zo zeer een issue met de 'cloud' ansich, maar een issue met de persoon die een specifieke (MS) clouddienst heeft ingesteld voor reden X en kennelijk niet wordt meegenomen in MS zijn eigen security checks. Zoals @Blokker_1999 ook al aangeeft, je kan een eigen server super secure afleveren (op locatie), maar als er dan iemand (met voldoende rechten) toegang alsnog open zet, dan is daar moeilijk wat aan te doen. Monitoring is leuk, maar als dit juist is gemarkeerd als publiek toegankelijk en mensen gaan daar data in zetten die niet publiek toegankelijk hoort te zijn... Ook daar zijn (MS) oplossingen voor, maar kennelijk niet gebruikt in dit geval.

Wat ik me dus afvraag is waarom die data überhaupt in een Azure Blob Storage zit. MS heeft zelf diensten waar die data in 'hoort', Exchange Online, Sharepoint Online, Dynamics, etc. en die zijn zeker al beschikbaar sinds 2017 en hebben juist 'features' die dergelijke ongein tegen moeten gaan. Of is dit een backup van die data uit die diensten, unencrypted en slecht geconfigureerd?
Zou me niets verbazen als die diensten de data vervolgens in Azure Blob Storage zetten.
Wellicht (maar ik betwijfel het), maar als dat het geval was geweest dan was er niet data specifiek van 65.000 bedrijfsklanten van MS uitgelekt, dan was alles uitgelekt.

Azure Blob Storage is een specifieke dienst, met een specifieke functie, ik weet dat er backup solutions zijn die dus backups (kunnen) maken in Azure Blob Storage (of AWS/Google/etc varianten daarvan). MS produceert Windows 10/11, maar dat betekend nog niet dat hun 'cloud' op Windows 10/11 draait...

Daarnaast zijn de genoemde diensten vaak al gebouwd op tech die veel ouder is dan de Azure Blob Storage. Het een kan het ander gebruiken, maar vaak niet zo geïntegreerd als mensen denken.
Maar dit hoeft niet noodzakelijk een cloud probleem te zijn. Dit kan ook een gewone service zijn die foutief is geconfigureerd, bijvoorbeeld een CRM systeem wat ook vanaf internet toegankelijk moet zijn zodat klanten informatie kunnen bijwerken in dat systeem.
Het 'cloud' deel van het probleem is dat er in 1 keer meer dan 65.000 bedrijven zijn geraakt door dit probleem. Als het een eigen machine van 1 bedrijf zou zijn geweest dan zouden slechts 1 of een paar samenwerkende organisaties zijn geraakt.

Tel daar bij op dat een cloud-provider zoals microsoft ook een iets grotere aantrekkingskracht heeft voor alle kleuren hoedjes: White-hat, blue-hat, red-hat en black-hat (en de rest van de regenboog).

Als deze niet zo goed geconfigureerde machine bij een bedrijf in een eigen rekencentrum gestaan zou hebben... dan hadden wij het hier niet gelezen omdat het waarschijnlijk niet gebeurd zou zijn en anders dat het minder nieuwswaarde heeft.
Dat heeft toch weinig met "de cloud" te maken. Ik heb al moeite om bij mijn lokale kapper mn gegevens achter te laten in hun systeem.
Elk bedrijf dat gegevens van je claimt is een risico, ongeacht waar ze het opslaan.
Een server die alleen intern te gebruiken is heeft één ingang (de VPN) nu heb je al 1000'den ingangen, namelijk elke PC wereldwijd.
Nee, de VPN heb je geconfigureerd en de server heb je geconfigureerd om die VPN te gebruiken. Je kan met Azure ook prima VPN instellen en het afsluiten voor de rest van de wereld, maar als de persoon die dit geconfigureerd heeft niet instelt, dan zal deze dat ook niet doen op een lokale server/netwerk.

@Kevinp Het staat niet 'meer' online per definitie, de 'cloud' is niet meer dan een server ergens anders hebben staan die door weer iemand anders beheerd wordt (echter worden veel on-premises oplossingen ook al heel lang niet meer beheerd door intern personeel). Effectief een server op een netwerk met een internet connectie, exact hetzelfde wat je ook met een on-premises oplossing heb. Tenzij je een van de weinige bedrijven ter wereld bent die geheel geen internet connectie hebben aangesloten op hun netwerk. VLANs, afgeschermde servers is leuk, maar het zit fysiek allemaal op elkaar aangesloten en alleen door software settings zorg je ervoor dat je de boel niet openzet voor de hele wereld. Ook hier geld, misconfiguration, bugs, backdoors, etc. zijn een issue. Waar hier over wordt gesproken bij MS, is een misconfiguration.

Je kan prima je gehele Azure oplossing afsluiten van de rest van het internet en alleen maar toegankelijk maken via een VPN naar je eigen netwerk/computer. De backend (de Azure admin interface die je gebruikt om de boel te configureren) kan je ook beschikbaar maken voor slechts je eigen IPs met 2FA, alleen maar compliant devices, etc. Het is echter wel zo handig als je ergens een breakglass account veiligstelt, anders heb je een issue als je IP niet meer bereikbaar is of je geen compliant device tot je beschikking hebt...

[Reactie gewijzigd door Cergorach op 26 juli 2024 02:21]

Toch staaat het dan meer online dan een server op je eigen netwerk. Immers moet dat anders kan je er niet eens bij.
Dat is volledig afhankelijk van hoe je het instelt. Je kan prima en virtueel netwerk aanmaken in de cloud en deze bijvoorbeeld via een express route koppelen aan je eigen netwerk zonder dat deze toegankelijk is van buitenaf. Het omgekeerde kan ook, dat je iets op je eigen netwerk hebt staan en vervolgens alles open zet. Dan kan iedereen erbij (mits je netwerk gekoppeld is het aan internet uiteraard).

Hoe dan ook, in beide gevallen kun je alles potdicht maken of open stellen.
Ook in “de cloud” ben je nog steeds verantwoordelijk voor de beveiliging van je spullen die je daar host. En ja MS biedt er wel de tools voor maar die moet je altijd zelf nog wel inrichten en gebruiken..

[Reactie gewijzigd door DigitalExorcist op 26 juli 2024 02:21]

Mijn ervaring is dat internationale cloud leveranciers dit vaak professioneler aanpakken dan Nederlandse bedrijven. Eenmaal binnen is het meestal een kwestie van tijd en resources voordat een binnendringer verder komt omdat ergens een leverancier iets niet veilig geconfigureerd heeft.
Cloud is op zich wel veilig. De standaard bij een azure blob is niet publiceren naar buiten. Dat moet je daarna openstellen. En daar is het dus fout gegaan. Ipv opzetten voor een paar mensen, is die opengezet voor iedereen. De implicit deny rule (die bijna op alles in Azure van toepassing is) is daarmee uitgeschakeld.
Vergeet alleen niet, en dat merk ik wel vaker bij de cloud discussie, dat als je geen cloud dienst van Microsoft/Google of andere grote partij pakt de kapper op de hoek zelf maar wat laat doen door een 'zolderkamer it-er aka het neefje'.

Microsoft maakt nu inderdaad een slordige, menselijke, fout en dat kan niet goed gepraat worden. Maar kan je je voorstellen als we allemaal weer onze eigen 'opslag en backup' gaan doen? Komt er op neer dat je dan een hoop meer menselijke fouten gaat krijgen ben ik bang.

Soms moet je iets waar je zelf geen tijd, verstand of geld (voor externe bedrijven) voor hebt neerleggen bij een grote cloud dienst.
Vroeger stond mijn HR (persoons) data op een fysieke server, achter een gesloten deur naar de serverruimte, in een pand voorzien van toegangssystemen, en bepaalde mijn IT collega's wie waar bij mocht. Nu dat in de cloud staat, wordt diezelfde veiligheid gegarandeerd door een SLA en verwerkersovereenkomst waar "legal" en onze inkopers zo blij van zijn, dat ze klem zitten onder het bureau van genot.
Wat probeer je hiermee aan te geven? Dat je data vroeger beter fysiek beveiligd was dan nu in een datacenter van ms of amazon?
Wat probeer je hiermee aan te geven? Dat je data vroeger beter fysiek beveiligd was dan nu in een datacenter van ms of amazon?
Het punt is denk ik vooral de aandacht is verschoven van "voorkomen dat dingen mis gaan" en "controle over je data" en "zorgzaamheid" naar "financiele schade & verantwoordelijkheid minimaliseren". Zakelijk gezien is dat vast de beste benadering maar het gaat wel een beetje over de rug van de gebruikers.

Het idee dat je een zekere plicht hebt om goed voor je gebruikers te zorgen lijkt vaak ver te zoeken, zolang je maar kan aantonen dat iemand anders verantwoordelijk is en opdraait voor eventuele kosten.

Een beetje overdreven gesteld voelt het af en toe alsof een transportbedrijf besluit om hun couriers voortaan zonder helm te laten rijden omdat het goedkoper is om twee keer per jaar een begrafenis te betalen.

Puur zakelijk gezien is het misschien ok als iedereen dan netjes z'n verantwoordeljkheden neemt. Het lastige is wel dat IT'ers niet van contracten snappen en contractmanagers niks van IT. Daardoor zijn de afspraken en beloftes vaak boterzacht maar daar kom je pas achter als er een conflict is.

Over het algemeen zijn de machtsverhoudingen ook zo dat die contracten eenzijdig worden opgesteld. De kleine partij heeft daarbij niks te kiezen. Of de beloftes realistisch zijn of niet, er is vaak niks te kiezen. Zeker als je door vendor lock-in toch wel vast zit aan een bepaald product of leverancier.

Daardoor zie ik vaak een hele stapel aan "voldongen feiten" en "niks te kiezen" contracten en afspraken die op grote afstand staan van de technische realiteit maar wel een hoop ronkende taal bevatten. Ik denk dat @uncle_sjohie daar een beetje op doelt. De afdeling inkoop klopt elkaar tevreden op de schouder terwijl de IT-afdeling zit te Facepalmen over de onrealistische beloftes.
Of dit is een giga breach, of de titel is overdreven, of SOCradar overdrijft. Ik heb een paar grote nederlandse bedrijven in de SOCradar ingevoerd (https://socradar.io/labs/bluebleed), en praktisch allemaal "detacted"

Heineken.com
ASML.com
rabobank.nl
ING.nl
SNS.nl
aegon.com
DNB.nl

Ben wel benieuwd naar wat er daadwerkelijk gelekt is.

[Reactie gewijzigd door lucatoni op 26 juli 2024 02:21]

lol, ik kan bijna geen bekende domein-naam vinden die NIET detected is....

airbus
boeing
microsoft
spacex
tesla

etc
etc
Een abnamro.com is 'detected' een abnamro.nl is 'not detected'.
Een amazon.com is 'detected'...

Ik zie dat de primaire .com domeinen van verschillende grote multinationals wel worden 'detected', maar dat verschillende domeinen die eigenlijk 'primair' zijn (de daadwerkelijke IT organisaties) en de afgelopen vijf jaar MS diensten zijn gaan afnemen daar verdacht op ontbreken...
Je kunt een gratis account aanmaken op de site en dan zien hoe of wat voor je domeinnaam.
Dit heeft momenteel geen nut, want de zoekopdrachten op deze bluebleed breach zijn nu uitgeschakeld.
Als je kijkt op de pagina welke je deelt is een kopje "What's in bleed" zie je een hoop verschillende datasoorten waaronder een paar miljoen emails.

Als je hierna een domeinnaam door bluebleed haalt krijg je als melding "SOCRadar detected data relevant to your company in the Bluebleed!". Data relevant voor je bedrijf en gelekte bedrijfsdata zijn nogal grootte verschillen. Specificeren op welke criteria je bedrijfsnaam gezocht wordt in de dataset (zonder te betalen) doen ze in elk geval niet.

Het wekt bij mij in elk geval de impressie op dat een bucket of email waarin jouw domeinnaam voorkomt al als voldoende wordt gezien om te kwalificeren als relevante data.
Heb je zelf een account aangemaakt? Ik werk bij een grote organisatie die ook "detected" is, en twijfel of ik mijn gegevens hier moet achterlaten om te zien wat voor info ze hebben. Erg onduidelijk of het gratis is, en wat de addertjes zijn.
Ik laat het bij mijn organisatie aan de IT/security officers over, zag dat er wel wat over werd gesproken op teams. Ik ga mijn contactgegevens in elk geval niet achterlaten bij de vrienden van Bleed..
Ik heb exact hetzelfde! Denk dat je uiteindelijk ook mag gaan betalen om in te zien...
Bijvoorbeeld onze eigen bovenste beste KPN.com
Het securitybedrijf kon offertes, bestelformulieren, ondertekende documenten, prijslijsten, verkoopstrategieën en andere belangrijke bedrijfsdata identificeren.
Oef wat ik dik gedrukt heb vind ik wel serieuze zaken die je niet op straat wilt hebben.
met op nr 1 Ondertekende documenten.

Hopen dat bedrijven niet veel nazorg hier aan hebben.

Edit:
Weet iemand of er een soort 2FA is voor handtekeningen?

[Reactie gewijzigd door crzyhiphopazn op 26 juli 2024 02:21]

docusign doet MFA: https://www.docusign.com/trust/security/esignature?

"We also use world-class security software and hardware to protect the physical integrity of DocuSign eSignature and all associated computer systems and networks that process customer data. We do this through a centralized management system that controls access to the production environment through a global two-factor authentication process."
Thanks.

Even door de website spitten na werk.
Ik krijg een beetje kippenvel van deze hacken als reclamemodel bedrijfjes. Elke hack krijgt tegenwoordig een hippe merk naam en wordt volledig uitgemolken. Het 'Artikel' van SOC radar bevat meer reclame als echte informatie. Het is ook niet alsof ze iets wereldschokkends gevonden hebben, alleen één server die niet correct geconfigureerd is.

Wat betreft die tool, wat geeft hun het recht om data die ze in principe illegaal hebben verkregen, op te slaan en beschikbaar te maken? Diensten als have i been pwned vind ik nog weer anders omdat die alleen al gelekte informatie bekend maken. Maar hier is er echt geen enkele legitieme reden, zeker aangezien MS het gewoon netjes opgepakt heeft en iedereen heeft ingelicht. Het is alleen maar een manier om wat meer hits op de reclame voor hun diensten te krijgen.
Het bedrijf betreurt ook dat SOCRadar een tool heeft gepubliceerd waarmee klanten kunnen nagaan of er data van hen is gelekt. Volgens het Microsoft kan deze tool de gegevens van klanten alsnog blootstellen.
De reacties hier met bedrijfsnamen bewijzen dat dit waar is.

Dit geeft ethisch hacken gewoon een heel slechte naam als je het nog ethisch kan noemen. Als je in Nederland op deze manier te werk gaat ben je gewoon strafbaar bezig. Het is best ok om onderzoek te doen, een proof of concept waar je gelimiteerd data verkrijgt is al op het randje, maar gewoon servers leeg trekken is gewoon niet ok en illegaal. Ik vind zelf ook wel eens wat en het is frustrerend als bedrijven niks doen maar dit gaat wat te ver.

[Reactie gewijzigd door jmzeeman op 26 juli 2024 02:21]

Wie weet hoeveel man met deze data reeds aan de haal is gegaan zonder dit te laten lekken.
tesla.com, twitter.com en sec.gov ook , Heb toch het idee dat het wat groter is dan Microsoft laat blijken
Ik snap wel dat MS die detectietool niet passend vind om zo openbaar te zetten zonder enige vorm van domeinverificatie.

[Reactie gewijzigd door ETH0.1 op 26 juli 2024 02:21]

Microsoft moet hiervoor bestraft worden - zo gaat dat met privacygebonden lekken. En Microsoft heeft ook contractuele verplichtingen - dus schadevergoeding te dokken!
Het bedrijf betreurt ook dat SOCRadar een tool heeft gepubliceerd waarmee klanten kunnen nagaan of er data van hen is gelekt. Volgens het Microsoft kan deze tool de gegevens van klanten alsnog blootstellen.
Ik hoop dat SOCRadar inderdaad maatregelen heeft getroffen om misbruik van die tool tegen te gaan. Ik denk ook dat er betere implementaties te bedenken zijn om zulke informatie beschikbaar te maken, bijvoorbeeld door ipv om het domein te vragen een email adres te vragen op dat domein. Dan is de kans op een datalek vele malen kleiner.

Op dit item kan niet meer gereageerd worden.