# Wat we leren van Log4Shell, MOVEit, xz utils en Snowflake URL: https://brainpowergroup.eu/nl/blog/wat-we-leren-van-bekende-hacks Datum: 2025-04-30 (bijgewerkt 2026-10-01) Door: Bas Leijder Havenstroom, Brainpower Group Log4Shell, MOVEit en Snowflake hadden een gewone oorzaak. Weet wat je draait, patch snel, zet MFA op elk account en maak afspraken met je leveranciers. De bekende hacks van de afgelopen jaren hadden zelden een exotische oorzaak. Log4Shell zat in een logbibliotheek die in veel Java-software wordt gebruikt. Bij MOVEit raakten ook organisaties die de software zelf niet gebruikten data kwijt, via een leverancier. Bij Snowflake-klanten logden de aanvallers in op accounts zonder tweestapsverificatie. De lessen zijn daarom praktisch: weet wat je draait, patch snel, zet MFA op elk account en maak goede afspraken met je leveranciers. ## Log4Shell: weten wat er in je software zit In december 2021 werd CVE-2021-44228 openbaar, beter bekend als Log4Shell. Het lek zat in Log4j 2, een veelgebruikte logbibliotheek voor Java. Wie tekst in een logbericht kon krijgen, kon de server code van buitenaf laten laden en uitvoeren. Versie 2.15.0 zette die functie standaard uit, maar dat bleek niet genoeg; 2.16.0 haalde hem helemaal weg. Het patchen zelf was niet het moeilijkste. Lastiger was uitzoeken waar Log4j overal zat: in eigen applicaties, als dependency van een dependency of in software van een leverancier. Mijn advies is om per applicatie een softwarelijst (een SBOM) bij te houden waarin je kunt zoeken. Bij het volgende grote lek wil je binnen een uur weten welke systemen geraakt zijn. Vraag je leveranciers hetzelfde: hoe snel kunnen zij zeggen of hun product kwetsbaar is? ## MOVEit: lekken bij je leveranciers Vanaf 27 mei 2023 misbruikte de ransomwaregroep Cl0p een onbekend lek in MOVEit Transfer, software om bestanden met andere organisaties uit te wisselen. Het ging om een SQL-injectie (CVE-2023-34362). Volgens de Amerikaanse cyberdienst CISA plaatste de groep een webshell en stal ze daarmee data uit de databases achter MOVEit. Een deel van de slachtoffers gebruikte MOVEit niet zelf. De BBC, British Airways en Boots verloren personeelsgegevens via Zellis, hun salarisverwerker. Zellis meldde dat er data van acht klanten was gestolen. Vraag je leveranciers daarom welke systemen met jouw data aan het internet hangen en hoe snel ze kritieke lekken patchen. Leg in de verwerkersovereenkomst vast hoe snel ze een incident melden en hoe lang ze bestanden bewaren, want een bestand dat na de overdracht is verwijderd, kan niemand meer stelen. ## xz utils: vreemde signalen onderzoeken Eind maart 2024 meldde ontwikkelaar Andres Freund een backdoor in xz utils (CVE-2024-3094). Dat is een compressiebibliotheek die op onder meer Debian, Ubuntu en Fedora via systemd in de SSH-server terechtkomt. Freund merkte dat SSH-logins veel CPU gebruikten: een test-login duurde ongeveer 0,8 seconde in plaats van 0,3. Toen hij uitzocht waarom, vond hij de backdoor. De aanvaller had er ruim twee jaar aan gewerkt. Onder de naam Jia Tan leverde die persoon nuttige bijdragen, kreeg commitrechten en bracht uiteindelijk zelf releases uit. Bij de ontdekking zat de besmette versie al in Fedora Rawhide, de bèta van Fedora 40 en Debian unstable. Zo'n aanval houd je als klein bedrijf nauwelijks tegen. Je kunt wel zorgen dat productie niet zonder reden op de nieuwste versies draait en dat je weet welke versie waar staat. Geef je team ook de ruimte om een vreemde vertraging uit te zoeken, want zo is deze backdoor gevonden. Hoe aanvallen via npm en PyPI werken, beschrijft Milos in [supply chain-aanvallen op npm en PyPI](/nl/blog/supply-chain-aanvallen-op-npm-en-pypi). ## Snowflake: inloggen zonder MFA In 2024 stal een groep die Mandiant UNC5537 noemt data uit de omgevingen van Snowflake-klanten. Mandiant en Snowflake waarschuwden ongeveer 165 organisaties. Volgens Mandiant was Snowflake zelf niet gehackt: de aanvallers logden in met gebruikersnamen en wachtwoorden die eerder door infostealer-malware waren buitgemaakt. Mandiant noemt drie oorzaken. De accounts hadden geen MFA, dus een gebruikersnaam en wachtwoord waren genoeg. Gestolen wachtwoorden werkten soms jaren later nog, omdat niemand ze had vervangen. Ook was er geen allowlist die de toegang beperkte tot bekende netwerken. Destijds moest de klant MFA bij Snowflake zelf aanzetten. Controleer dus per SaaS-dienst of MFA voor alle gebruikers is afgedwongen, ook voor accounts die bijna nooit gebruikt worden. Vervang wachtwoorden en keys op een vast moment, en beperk de toegang tot dataplatforms tot je eigen netwerk of VPN waar dat kan. ## Wat ik als opdrachtgever geregeld zou willen hebben Als ik CTO of founder van een scale-up was, zou ik na deze vier incidenten dit op orde willen hebben: - een actuele lijst van applicaties, dependencies en leveranciers, met per onderdeel een eigenaar; - een afgesproken patchtermijn in dagen voor kritieke lekken in systemen die aan het internet hangen; - MFA op elk account, ook voor externe developers en leveranciers; - in contracten: hoe snel een leverancier een incident meldt, welke data hij bewaart en hoe lang; - een restore die je echt hebt geoefend, voor het geval ransomware toch slaagt. Dat laatste werkt Aleksa uit in [backups en disaster recovery](/nl/blog/backups-en-disaster-recovery). Onze developers werken op beheerde, versleutelde laptops met centraal beheerde accounts, SSO met tweestapsverificatie en afgeschermde toegang (zie onze [werkwijze](/nl/werkwijze)). Daarmee is MFA voor onze developers geregeld. Welke systemen er draaien, hoe snel er gepatcht wordt en wat er in je contracten staat, blijft werk voor jou als opdrachtgever. Valt je organisatie onder NIS2, dan staan veel van deze punten ook in de wet. Erik schreef daarover [NIS2 en je developmentteam](/nl/blog/nis2-en-je-developmentteam). ## Bronnen - [CVE-2021-44228 (Log4Shell)](https://www.cve.org/CVERecord?id=CVE-2021-44228) - [CISA: CL0P Ransomware Gang Exploits CVE-2023-34362 MOVEit Vulnerability](https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-158a) - [BBC: MOVEit hack, BBC, BA and Boots among cyber attack victims](https://www.bbc.com/news/technology-65814104) - [Andres Freund op oss-security: backdoor in upstream xz/liblzma](https://www.openwall.com/lists/oss-security/2024/03/29/4) - [Russ Cox: Timeline of the xz open source attack](https://research.swtch.com/xz-timeline) - [Mandiant: UNC5537 targets Snowflake customer instances](https://cloud.google.com/blog/topics/threat-intelligence/unc5537-snowflake-data-theft-extortion) ## Veelgestelde vragen **Wat was Log4Shell precies?** Een lek in Log4j 2, een veelgebruikte logbibliotheek voor Java, bekend sinds december 2021 als CVE-2021-44228. Wie tekst in een logbericht kon krijgen, kon de server code van buitenaf laten uitvoeren. Versie 2.16.0 haalde de functie die dat mogelijk maakte helemaal weg. **Hoe kwamen de aanvallers bij de Snowflake-klanten binnen?** Met gebruikersnamen en wachtwoorden die eerder door infostealer-malware waren gestolen, op accounts zonder MFA. Volgens Mandiant was Snowflake zelf niet gehackt. **Wat is de belangrijkste les uit deze hacks voor een kleiner techbedrijf?** Weet welke software en leveranciers je gebruikt, patch systemen die aan het internet hangen snel en zet MFA aan op elk account dat bij data kan. Leg met leveranciers vast hoe snel ze een incident melden. --- Bron: https://brainpowergroup.eu/nl/blog/wat-we-leren-van-bekende-hacks Brainpower Group, contact: https://brainpowergroup.eu/nl/contact, hello@brainpowergroup.eu