ESA meldt datalek; hacker claimt diefstal 200GB data en broncode

De European Space Agency meldt een datalek na een cyberaanval op externe servers van de organisatie. Hoewel de verantwoordelijke cybercrimineel spreekt van 200GB aan gestolen gegevens en broncode, benadrukt ESA dat het volgens een voorlopige analyse slechts om een 'zeer kleine hoeveelheid niet-geclassificeerde' gegevens gaat.

Volgens de hacker zijn er naast de data ook api-tokens en config-, Terraform- en SQL-bestanden buitgemaakt en afgeschermde Bitbucket-repository's zijn gecompromitteerd. ESA weerspreekt die omvang echter. De getroffen gegevens gaan volgens de organisatie voornamelijk over samenwerkingen met andere bedrijven.

In een verklaring erkent ESA dat er data is gestolen van enkele externe servers. Betrokkenen zouden zijn ingelicht over het incident. Het is niet duidelijk wat de omvang van de cyberaanval is. Volgens ESA zijn er beveiligingsmaatregelen genomen om verdere datalekken te voorkomen.

De European Space Agency is de Europese ruimtevaartorganisatie met 22 lidstaten. De organisatie coördineert de samenwerking, ontwikkeling en investering in de Europese ruimtevaart, waaronder missies met astronauten, raketlanceringen, wetenschappelijk onderzoek en de lancering van satellieten.

Reacties (47)

[Roko]

"...Volgens het ESA zijn er beveiligingsmaatregelen genomen om verdere datalekken te voorkomen". Het blijft opmerkelijk dat er achteraf altijd iets gepatched kan worden wat men niet van te voren had kunnen doen.

[wiseger]

Het blijft opmerkelijk dat er achteraf altijd iets gepatched kan worden wat men niet van te voren had kunnen doen.

Dat is helemaal niet opmerkelijk. Ter illustratie, elke maand brengt Microsoft patches uit, de welbekende patch Tuesday.

Die patch ronde moet geanalyseerd worden, wat is de impact van het installeren van die patches? Wat is de urgentie, bijvoorbeeld de CVE score? Daarna wordt er bij een bedrijf besloten welke patches die maand naar productie moeten.

Daarna gaan die patches naar de test systemen, dan volgen testen of er productie verstoringen te verwachten zijn als gevolg van die patches. Daarna wordt de patch gepland voor productie, vaak in twee stappen, eerst de primaire systemen, dan enkele tijd later de redundante systemen.

Die cyclus heeft zo een looptijd van enkele weken. Dus dat een bedrijf altijd enigszins achterloopt, is zeer verklaarbaar.

En ja, bij een hoge CVE score kan er prioriteit gegeven worden aan een patch maar ook daar geldt, blind op productie installeren is vaak een brug te ver.

[Sfynx]

Tja, dat is een keuze met consequenties die je dan moet dragen. Ik doe gewoon een apt upgrade op al mijn systemen op het moment dat een kritieke patch uitgebracht wordt.

[dingo35]

unattended upgrade werkt nog beter, alleen enkele upgrades die niet unattended kunnen wachten nog op je input ....

[Houtenklaas]

Dat is leuk voor je mediaplayer, maar een goed bedrijf met kritieke productiesystemen heeft daar een patchbeleid voor ingericht wat niet blind en ongetest iets gaat installeren.

[Het.Draakje]

Ja. Dat is uiteraard makkelijk voor privé personen en kleine bedrijfjes (bakker en dergelijke).

Praat je over, bijvoorbeeld een bank, dan wil je echt niet dat om wat voor reden dan ook zo'n patch jouw betalingsverkeer verstoort.

Ja, je praat dan over wat minder eenvoudige upgrades dan een apt upgrade op één of twee servers.

[NeuroTechie]

Of een ziekenhuis dat platligt doordat iemand denkt te kunnen doen met een apt full-upgrade of het gehele 112 netwerk

[Niema]

Kan ook zijn dat de "patches" extra regels waren rondom interne 2 staps verificatie of een eenmalige verplichte wachtwoord reset. Dat doet men meestal niet via een standaard update

[Keypunchie]

Goeie manier om je kritieke systemen down te laten gaan.

Hier op Tweakers zaniken mensen al als ze een half uurtje hun rekening niet kunnen checken via internetbankieren.

Security altijd heel erg serieus nemen, maar patches niet testen, daar krijg je CrowdStrike taferelen van...

[Tadream]

Euh dat doe je dus niet in grotere productie omgevingen.
Je wilt niet dat b.v. je e-facturen stroom of productiedatabase(s) oid om zeep worden geholpen.
Dat test je eerst en daarna rol je het verder uit.

[Sfynx]

Op zich begrijpelijk, ik draai in deze situatie wel gewoon de update en vervolgens de testsuite van de applicatie op een kopie van een systeem. Ik vraag me af hoe er getest wordt en hoe testbaar je applicatie is als het weken duurt voordat je er vertrouwen in hebt dat een update geen invloed heeft op je applicatie. Lijkt me een redelijk onwerkbare situatie aangezien belangrijke updates regelmatig langskomen.

[Reactie gewijzigd door Sfynx op 1 januari 2026 19:54]

[kozue]

Ik kan me niet voorstellen dat er veel bedrijven zijn die zoiets complex doen zoals jij omschrijft. Bij ons worden de updates gewoon iedere nacht automatisch geïnstalleerd met een apt update. Of de omschreven werkwijze moet iets specifieks uit de Windows wereld wezen…?
Ik vind het al bijzonder dat er op Windows een “maandelijkse patch dag” bestaat. Wie wil er wekenlang wachten op een patch voor een zeroday die actief wordt misbruikt? Maar dan nog eens extra lang wachten met installeren na release lijkt me een heel groot veiligsheidrisico. Veel groter dan wanneer een patch een onverwacht effect heeft en teruggedraaid moet worden.

[Keypunchie]

Bovenstaande is vrij gebruikelijk. Soms iets meer, soms iets minder uitgebreid.

Maar bij grote bedrijven met maatschappelijke functies is de verwachte schade* van ongeplande downtime door een ongeteste patch groter dan de verwachte schade* van een hack.

We hebben het hier over banken, energiebedrijven, luchtvaartmaatschappijen etc. Kortom, 24-7 bedrijfs&missie-kritische systemen.

(*verwachte schade = kans x kosten)

[fenrirs]

Doe je dan niet gewoon een patch op een schaduw system en mits geen incidenten, gelijk door naar productie?

Je kan alles testen, maar aan klanten van een bank kan je echt niet uitleggen dat je weken wacht met een patch en gehacked wordt in de tussentijd.

[Keypunchie]

Definieer "gewoon".

Een beetje georganiseerd bedrijf heeft een patchbeleid en dat wordt gevolgd. Vaak is een CVE score daarin leidend.

De realiteit is namelijk dat als je de snelste bent om te patchen, dat je beta-tester voor de rest van de industrie bent. Wat je vaak ziet is dat er dus een beleid is dat een patch met een bepaalde CVE waarde binnen "x tijd" moet zijn doorgevoerd. Al het grut met 'medium of low impact' gaat mee in de standaard patch-rondes, alleen patches met CVE hoog worden versneld doorgevoerd.

En ja, in dat soort rondes zorg ik absoluut voor dat eerst de non-kritieke systemen gepatcht worden, zodat impact kan worden bepaald.

Ook niet onbelangrijk, maar gelukkig wel steeds minder een issue, is dat patching vaak ook infra/applicatie herstart betekent. Wat ook niet altijd triviaal is, zeker bij legacy systemen met hoge SLA. Ik heb nog menig nacht van zaterdag op zondag op kantoor bij een bank gezeten. Lekker tussen 2u en 4u 's nachts patches en upgrades doorvoeren. Blegh. Die tijd is gelukkig wel meer in de achteruitkijkspiegel met de komst van Cloud Native. (Een zwakke plek blijft nog altijd database upgrades).

Maar het verklaart wel waarom kwetsbaarheden als log4shell ook zo'n drama zijn. Of laatst konden we ook lachen met React Server. Mag je al die draaiboeken ongepland op korte termijn gaan uitvoeren.

[Reactie gewijzigd door Keypunchie op 31 december 2025 20:10]

[ccnl]

luchtvaartmaatschappijen

Hoe was het nog bij Crowdstrike? Southwest Airlines had geen last omdat ze nog windows 3.x gebruikt

[Blokker_1999]

Er zijn maar weinig grote bedrijven die gewoon patches binnentrekken en onmiddelijk naar alle systemen sturen. Dat gaat eerst door een testronde heen en na testing doet men vaak een gefaseerde uitrol waarbij men eerst een kleine groep gebruikers en systemen doet om dan over enkele fases heen steeds meer gebruikers te targetten.

Ook als je de beheerstools van bijv. Microsoft gebruikt dan zullen niet alle gebruikers op patch tuesday hun patches krijgen, maar net gespreid over de tijd. Als ik de statistieken bekijk in onze omgeving dan duurt het al snel een week of 3 voordat we 90% van systemen bereikt hebben met updates. 100% haal je zelfs nooit vanwege systemen die uit staan om allerhande redenen.

Blindelings patches in productie gooien op de dag dat ze uitkomen brengt ook weer risico's met zich mee. Er kunnen aanpassingen in zitten die niet goed werken in je omgeving, of soms ook gewoon bugs die de makers van de software niet gezien hebben in hun testing. De laatste maanden niet gezien hoeveel fouten er bijvoorbeeld in de maandelijkse Windows patches zitten? Denk je dat zoiets bij Linux distributies of Apple niet voorkomt?

En als er risico is op een zero day die misbruikt wordt, dan versnel je de testing en rol je alles op een versneld schema uit wat ook weer een hoop extra werk van je teams vraagt. Maar aan de andere kant is beveiliging vandaag een gelaagd iets. 1 bug, zelfs een zero day is vandaag nog zelden in staat om heel je omgeving in gevaar te brengen. Al kan het wel een toegangspunt vormen voor een aanval.

[Houtenklaas]

Ik wel. Elk fatsoenlijk (ICT) bedrijf doet het op de manier die @wiseger meldt en dat heeft werkelijk niets te maken met op welk OS iets draait. Er is - als het goed is - een patchbeleid en een escape als je een CVE treft met een score van 10. Daar denk je vooraf over na en ga je niet blind en ongetest een patch installeren. De vraag is niet OF dit een keer misgaat waardoor je productie onderuit gaat, maar WANNEER.

[DonChaot]

Maar nu hebben ze blijkbaar toch besloten de testfase te skippen en blind in productie te gaan? Dan had dat misschien ook op voorhand het beleid moeten zijn.

[Orangelights23]

Het blijft opmerkelijk dat men nog steeds dat soort aannames stelt.

Dit is risico managemenr, een afweging van efforts versus bereidheid. Ik ken geen enkel bedrijf wat direct een patch installeert. Ik ken ook geen enkel bedrijf dat elk attack vector volledig onder controle heeft. Daarmee zeggende dat 100% veiligheid een illusie is.

[Blokker_1999]

Je moet je bewust zijn van een gat voordat je het kunt dichten. Je kan heel veel investeren in goed beheer, maar 1 foutje ergens door iemand die procedures niet volgt, of een snelle workaround voor een probleem dat nooit goed wordt opgelost, of een legacy product dat ergens is achtergebleven of 1 van duizenden andere mogelijkheden zorgt ervoor dat een aanvaller toch binnen geraakt.

Ja, als je eenmaal weet waar het lek zit is het vaak eenvoudig om het op te lossen. En dat gebeurt some zelfs met zo een knee-jerk reactie dat je letterlijk systemen gaat uitzetten of zo hard isoleren dat je eigen interne werking ook in de moeilijkheden komt maar dat je eerst wilt isoleren om daarna gecontroleerd weer vrij te geven. Ook dat is wat hier kan gebeurd zijn.

En aan zij die denken dat ze een hele omgeving 100% veilig kunnen krijgen en kunnen houden, wat vraag je per uur? Ik heb nog wel een job opening voor je.

[0xd020]

Dat is wel een hele makkelijke opmerking. Mocht je ooit zelf in een wat complexere IT organisatie komen te werken, denk dan nog maar eens terug aan wat je zei.

[Clu3M0r3]

Het blijft opmerkelijk dat er achteraf altijd iets gepatched kan worden wat men niet van te voren had kunnen doen.

Dat is niet opmerkelijk.

Ieder informatiesysteem, ieder netwerk (daar moet je van uitgaan) bevat zwakheden. Helaas hebben zelfs de beste security experts geen glazen bol waardoor ze op voorhand al kunnen voorspellen welke zwakheden.

Daarom is het niet mogelijk om op voorhand te patchen, en kan dat alleen maar achteraf gedaan worden.

Indien jij wel zo'n glazen bol hebt, en die patches op voorhand kan voorspellen en programmeren, dan ben je wellicht binnen een week schathemeltje rijk.

[Barryke]

"...Volgens het ESA zijn er beveiligingsmaatregelen genomen om verdere datalekken te voorkomen". Het blijft opmerkelijk dat er achteraf altijd iets gepatched kan worden wat men niet van te voren had kunnen doen.

Open deur natuurlijk, maar bij beveiligingsmaatregelen denk ik eerst aan toegang voorkomen zoals netwerk en server configuratie. De deuren weghalen, sleutels vervangen, geen informatie uitwisseling. Patchen is onderhoud.

[Reactie gewijzigd door Barryke op 31 december 2025 12:29]

[TheMak]

Zijn er locatiegegevens van sterren uitgelekt?

[Hansie9999]

haha,

I see what you dit there

[kameleon20]

Ja, Elvis is living on Proxima Centauri B

[-Elmer-]

Zijn er locatiegegevens van sterren uitgelekt?

Ik moest hier echt heel hard om lachen. Misschien heb ik een zwak voor woordgrappen, maar een dergelijk grappige opmerking zie ik niet dagelijks. Dankjewel :-)

[Reactie gewijzigd door -Elmer- op 31 december 2025 12:06]

[William_H]

Hoe zit het ook alweer met de nieuwe regels voor verantwoordelijkheid op de toeleveringsketen?

[NeuroTechie]

Onder NIS2 zal dat een incidentmelding zijn binnen 24 uur en dat ze de supply chain risico’s hebben behandeld, dit is het eigenlijk.

[William_H]

Ah dus toch de NIS2. Ik dacht dat er nog meer verplichtingen waren, maar dat valt blijkbaar dus mee.

[R_Zwart]

Geen idee. Wat heb jij geïmplementeerd?

[watercoolertje]

Kan je niet gewoon zeggen waar je naartoe wilt met je vraag?

Ik denk dat het hier waarschijnlijk niet/nauwlijks persoonsgegevens betreft. Het zou mij niet eens verbazen als ze geen meldplicht hebben mbt dit incident

[Reactie gewijzigd door watercoolertje op 31 december 2025 10:38]

[The Raido]

'Ik stel alleen maar vragen'.

[Mathijs Kok]

Verschuilen? Ze vermelden eenvoudig de feiten.

Er was een tijd dat Tweakers de wereld met een vrolijke blik zagen. Nu is er argwaan te zien in reacties op vrijwel elk onderwerp en kan een bedrijf het eenvoudig nooit goed doen.

[Nijl]

De hackers hebben nu alle NAW-gegevens van de Aliens in handen. Ze hebben zelfs e-mailadressen, BSN-nummers en telefoonnummers buit kunnen maken. Mijn schoonmoeder kreeg vanochtend al direct een phishingmail...

[DjoeC]

Ahh, ESA zegt NIET in de bron dat het om "'zeer kleine hoeveelheid niet-geclassificeerde' gegevens" gaat maar dat het (en dat staat wel correct in het artikel) om een kleine hoeveelheid externe servers gaat.

Een "kleine hoeveelheid gegevens" kan voor zo'n organisatie die vermoedelijk petabytes beschikbaar heeft - een kleine zoekaktie geeft al > 3,5PB - best 200GB of meer zijn.... Ofwel, er wordt volop aan damage control gedaan.....

[TheMak]

Elke afzwaaiende (al dan niet PhD)-student en gastwerker is een lopende datalek met hun laptops. Gegevens bescherming in zulk soort organisaties is dweilen met de kraan open.

[Insomnia1988]

[b]benadrukt de ESA dat het volgens een voorlopige analyse slechts om een een 'zeer kleine hoeveelheid niet-geclassificeerde' gegevens gaat.[/b]

Met alle respect, maar ik geloof dit niet meer. Iedere keer dat dit wordt gezegd, blijkt achteraf dat er meer is gejat.

[Reactie gewijzigd door Insomnia1988 op 31 december 2025 12:08]

[Keypunchie]

Wat voor geclassificeerde gegevens denk je dat ESA heeft?

Op zijn hoogst wat intellectueel eigendom.

Heel misschien wat informatie over Europese militaire satellieten (maar ik vermoed dat ESA alleen maar de lanceeropdracht krijgt en verder weinig details). En natuurlijk persoonsgevens voor de salarisadministratie, maar dat lijkt hier niet in het spel.

[SPee]

De codes voor (besturing en) communicatie met alle satellieten? Ik denk dat Rusland wel een flink bedrag wil betalen om Gallileo te kunnen bedienen.

[CPV]

"externe servers van de organisatie"

Dat is dus iets anders dan "servers van een externe organisatie"?
Wat bedoelen ze met deze uitdrukking?
Het maakt voor de hackers toch niet uit waar de servers fysiek staan, in een kluis of in een garagebox?

[as400]

Weer maar een argument om broncode open source te maken. Tenzij natuurlijk dat je er zo erg hard voor schaamt dat deze niet publiek vertoonbaar is. (ik houd mijn code liefst privé )

[Vaevictis_]

"niet-geclassificeerde data" kan dus van alles zijn, persoonsgegevens, bedrijfsgeheimen, projectplanning of ruwe data van b.v. infrastructuur.

[Boekenworm]

Gestolen in de zin van ze hebben het nu niet meer of ongeautoriseerd gekopieerd ?