7min Security

Microsoft SharePoint zero-day: wat ging er mis en wat moet je doen?

Grote dreiging voor on-prem SharePoint uitgelegd

Microsoft SharePoint zero-day: wat ging er mis en wat moet je doen?

De zero-days in Microsoft SharePoint (CVE-2025-53770 en CVE-2025-53771) is inmiddels een paar dagen bekend. We zetten de feiten nog eens op een rijtje. Wat is er gebeurd, hoe werd de zero-day ontdekt, en weten we zeker dat hij op tijd is ontdekt? Mocht je nog altijd niets hebben gedaan tegen deze aanvallen, dan is het zaak om haast te maken met maatregelen, ook als je denkt niet getroffen te zijn. Patchen alleen is niet genoeg.

CVE-2025-53770 en CVE-2025-53771 zijn gezamenlijk een zeer serieuze zero-day. Dat heeft meerdere redenen. Allereerst is er uiteraard het feit dat het een product betreft van Microsoft, een bedrijf met een enorme zogeheten installed base. De on-premises varianten van SharePoint die getroffen zijn door deze kwetsbaarheid (SharePoint Server 2019, SharePoint Server 2016 en SharePoint Server Subscription Edition) staan nog op behoorlijk wat plaatsen. Het gaat dan met name om omgevingen waar dit naar alle waarschijnlijkheid een bewuste en/of afgedwongen keuze is. Met andere woorden, omgevingen die niet voor de online-versie van SharePoint kunnen of mogen kiezen.

Bovenstaande klanten zijn vaak juist gewilde doelen. Onder andere overheden, maar bijvoorbeeld ook telecombedrijven vallen hier vaak onder. Dat was ook zeker het geval bij deze aanval, blijkt uit een rapport van Check Point Research. Het lijkt ons dan ook vrij veilig om aan te nemen dat de aanval uit de hoek van statelijke actoren komt, of in ieder geval van hackers met banden met een overheid die met name de VS niet gunstig is gezind.

Een tweede reden waarom dit een zeer serieuze zero-day is, heeft te maken met de combinatie van uitvoering en impact vanuit het perspectief van de aanvallers. CVE-2025-53770 en CVE-2025-53771 hebben namelijk de ideale combinatie van die twee te pakken: de impact ervan is hoog en ze zijn eenvoudig uit te voeren. De hackers hoeven zich niet bezig te houden met het verkrijgen van inloggegevens of het kraken van MFA en SSO. Met andere woorden, ze hoeven zich niet te authenticeren. De aanval werkt daar netjes omheen. Aanvallers maken gebruik van de kwetsbaarheden in SharePoint om uiteindelijk volledig ‘legaal’ code te kunnen draaien in SharePoint.

Als aanvallers het RCE (Remote Code Execution)-stadium eenmaal hebben bereikt, kunnen ze ook in andere onderdelen gaan rondneuzen. Aangezien SharePoint vaak geïntegreerd is in omgevingen waar ook zaken zoals Office, Teams, OneDrive en Outlook draaien, is de potentiële payoff voor de aanvallers enorm. Het biedt ze als het ware een rechtstreeks lijntje naar een groot gedeelte van de belangrijke data die organisaties hebben.

Hoe ontdekte Eye Security de SharePoint zero-day?

Het Nederlandse securitybedrijf Eye Security was de eerste die breed publiceerde over de CVE-2025-53770 en CVE-2025-53771 zero-days in Microsoft SharePoint. In een uitstekende post zet het bedrijf uiteen hoe het te werk is gegaan.

Enkele dagen voordat Eye Security erover rapporteerde, had een ander bedrijf, Code White uit Duitsland, op X al uit de doeken gedaan dat enkele al bekende CVE’s, namelijk CVE-2025-49706 en CVD-2025-49704 (deze werden later bekend als CVE-2025-53770 en CVE-2025-53771, ook al bracht Microsoft al gedeeltelijke patches uit voor de originele kwetsbaarheden), gezamenlijk ingezet konden worden als de exploit die het “ToolShell” noemde. Deze was eerder al op Pwn2Own in Berlijn gebruikt om SharePoint te hacken. Dat evenement vond plaats tussen 15 en 17 mei 2025.

Werd de zero-day op tijd ontdekt?

Met bovenstaand tijdspad in het achterhoofd, kun je je afvragen of Eye Security er wel op tijd bij was. Er zat immers een maand tussen de demo tijdens Pwn2Own en het moment waarop het bedrijf. Wie zegt ons dat er niet al ruim voor 18 juli misbruik van is gemaakt? Volgens het rapport van Eye Security was er ten tijde van de demo nog vrijwel niets bekend over hoe deze aanval precies in zijn werk ging. Geen publieke code en vrijwel geen andere details. De HTTP Referer header die volgens het bedrijf de originele CVE-2025-49706-kwetsbaarheid eventueel tot zero-day (CVE-2025-53770) heeft kunnen promoveren, werd pas publiekelijk ontdekt op 17 juli.

Was deze persoon op X daadwerkelijk de eerste die de HTTP Referer header heeft weten te fuzzen (oftewel te ontmaskeren als de boosdoener)? En zo dus de authenticatie-bypass in SharePoint op het spoor kwam? Op basis van de sterke groei in aanvallen afgelopen weekend zou dat best kunnen.

Het al eerder aangehaalde rapport van Check Point Research laat echter iets anders zien. Volgens de onderzoekers van dat bedrijf waren er al pogingen om misbruik te maken van de kwetsbaarheden op 7 juli. Toen waren deze wellicht nog niet succesvol. Of waren ze dat wel en kwamen we er pas echt achter nadat Eye Security er eens goed indook nadat het in de avond een alert kreeg van Crowdstrike Falcon EDR bij een van haar klanten. Feit is in ieder geval dat de aanvallen stevig opgeschroefd werden op 18 en 19 juli.

Koppeling met Ivanti EPPM-kwetsbaarheid

Naast de melding dat het al op 7 juli pogingen heeft gedetecteerd om de zero-day in Microsoft SharePoint te misbruiken, zit er nog iets interessants in het rapport van Check Point Research. De onderzoekers van dat bedrijf vonden namelijk een koppeling met enkele Ivanti-kwetsbaarheden. Daar zijn er de afgelopen jaren nogal wat van geweest. Het gaat in dit geval specifiek om CVE-2025-4427 en CVE-2025-4428. Een van de IP-adressen die volgens Check Point werd gebruikt voor de aanvallen op Microsoft SharePoint is ook gekoppeld aan aanvallen die misbruik maakten van de Ivanti-kwetsbaarheden.

Bij Check Point Research trekken ze vervolgens de conclusie dat “aanvallers bekende Ivanti-kwetsbaarheden inzetten gedurende de campagne”. We hebben hier verder geen concreet bewijs voor gezien in het rapport, behalve dan dat er een overeenkomst zit in de infrastructuur die gebruikt wordt. Op zich is dat laatste niet zo heel bijzonder. Dat zagen we ook bij de Ivanti-kwetsbaarheden. We gaan er echter vanuit dat Check Point dit niet zomaar zegt en dat ze er wel degelijk bewijzen van hebben gezien. Opvallend is dat een van de Ivanti-kwetsbaarheden ook te maken heeft met het omzeilen van authenticatie, iets wat ook een belangrijke component is van de SharePoint zero-day van Microsoft.

Als aanvallers actief gebruik hebben gemaakt van de Ivanti-kwetsbaarheden tijdens de aanvallen op de on-premises SharePoint-omgevingen, dan kan dat betekenen dat er nog de nodige organisaties zijn die de Ivanti-kwetsbaarheden nog niet hebben gepatcht. Die zijn er al sinds 13 mei. Het kan ook zijn dat die patches niet voldoende waren om volledig veilig te zijn.

Patchen alleen is niet genoeg

De “ToolShell”-aanval die is gekoppeld aan CVE-2025-53770 en CVE-2025-53771 is een vrij geraffineerde. Als men eenmaal binnen is, kan men binnen blijven. Dit is mogelijk omdat er zogeheten ASP.NET machine keys buitgemaakt zijn door de aanvallers. Dit zijn keys die data valideren en encrypten binnen een ASP.NET-applicatie. Dit zijn geen eenmalige keys en kunnen dus hergebruikt worden. Als een aanvaller eenmaal binnen zit, dan kan deze dus ook na het patchen van de kwetsbaarheden zijn werk doen.

Om dit te voorkomen is het noodzakelijk om nieuwe keys te ontwikkelen en deze te gaan gebruiken. Uiteraard is dat van belang bij servers die aantoonbaar zijn aangevallen. We zouden dit echter voor de zekerheid ook maar doen bij alle andere SharePoint-servers die organisaties nog hebben staan.

Naast het vernieuwen van de ASP.NET machine keys is het uiteraard eerst en vooral belangrijk om de patches te installeren. Inmiddels zijn die er voor alle drie de getroffen omgevingen. Daarnaast is het belangrijk om dit niet allemaal zelf te willen doen. Schakel Incident Response teams in of een van de securitybedrijven waar je zaken mee doet.