Microsoft past weergave .lnk-bestanden aan om actief misbruikt lek af te dekken

Microsoft pakt stilletjes een kritiek gat in Windows-snelkoppelingen aan dat in de praktijk al werd misbruikt voor hackaanvallen. De kwetsbaarheid zit in Windows' afhandeling van .lnk-bestanden, die in aangepaste vorm kwaadaardige code kunnen uitvoeren op kwetsbare computers.

Microsoft dicht het gat nu niet volledig, maar verandert de manier waarop Windows snelkoppelingen weergeeft. Het bedrijf doet dit met een stil uitgebrachte patch, meldt securityleverancier 0patch. Eerder stelde Microsoft dat het zou overwegen om de kwestie aan te pakken, maar dat deze bug in Windows niet voldeed aan zijn criteria voor onmiddellijke aanpak, schrijft Bleeping Computer.

Voor misbruik van deze kwetsbaarheid is gebruikersinteractie vereist. Een gebruiker moet een kwaadaardig .lnk-bestand aanklikken om daarin verwerkte malware te activeren. Het openen van een kwaadaardig bestand of het bezoeken van een kwaadaardige webpagina volstaat daarvoor, meldt het Amerikaanse ict-orgaan NIST in zijn beveiligingsbulletin over deze kwetsbaarheid.

Securityleverancier Trend Micro meldde in maart al dat dit beveiligingsgat (CVE-2025-9491) werd benut door elf hackgroepen, die het gebruikten in aanvalscampagnes sinds 2017. Deze aanvallers bestaan uit staatsgesteunde hackgroepen en cybercriminele bendes, waaronder bekende namen als Evil Corp, APT37, APT43 (ook bekend als Kimsuky), Mustang Panda, SideWinder en vele anderen. Daarbij zouden ook Europese diplomaten gericht zijn aangevallen via deze kritieke kwetsbaarheid in Windows.

Reacties (25)

[DutchReaper]

Ik snap dat de .lnk extensie interresant is. Zelfs als je de verkenner optie "weergeven van extensies" aanstaan, zullen .lnk bestanden nog steeds geen extensie weergeven. Als je dan een bestand download met de naam Factuur.docx.lnk zal je deze in verkenner zien als Factuur.docx, als je dan ook nog het icoontje aanpast moet je wel van hele goeie huizen komen wil je dat doorhebben.

Als vervolgens dit bestand wordt doorgestuurd naar de ict afdeling en die opent de properties is het wel jammer als ze dan niet kunnen zien welk command stieken word uitgevoerd.

Ps als je wil dat windows wel de lnk extensie weergeeft is dat aan te passen via een regedit. Let wel als je dit doet zie je ineens in het startmenu ook alle lnk extensies .

HKEY_CLASSES_ROOT\lnkfile and delete the NeverShowExt String;

[PD2JK]

Microsoft dicht het gat nu niet volledig, maar verandert de manier waarop Windows snelkoppelingen weergeeft

Hoe gaat dit er uit zien? Als dit al bekend is, misschien een afbeelding hiervan toevoegen aan het artikel?

[Reactie gewijzigd door PD2JK op 7 december 2025 12:06]

[Eagle Creek]

Ja hoor, maar zo spannend is het niet. Twee citaten:

The vulnerability lies in how Windows handles .LNK files, allowing threat actors to exploit the way the operating system displays them to evade detection and execute code on vulnerable devices without the user's knowledge by padding the Target field in Windows .LNK files with whitespaces to hide malicious command-line arguments.

This ensures that the file's Target field properties display only the first 260 characters due to the added whitespaces, so users can't see the actual command executed when the LNK file is double-clicked.

En na de update als volgt:

CVE-2025-9491 flaw. After installing recent updates, users can now see all characters in the Target field when opening the Properties of LNK files, not just the first 260.

Maw, het veld gaat nu alles tonen en de methode met padden middels spaties laat de argumenten niet langer verborgen zijn.

Daar komt dan enige kritiek op omdat de malafide argumenten nog steeds aanwezig blijven. Maar zoals ik in een eerder bericht al aangaf is dit meer een awareness- en detectsituatie in mijn ogen van het verkrijgen van vreemde.lnk-bestanden uit vreemde bron dan een technische kwetsbaarheid an zich. Daarnaast verwacht ik dat mailscanners en bv Microsoft Defender in bepaalde situaties ook detectie zouden kunnen doen.

[Reactie gewijzigd door Eagle Creek op 7 december 2025 12:12]

[R4gnax]

Een gebruiker moet een kwaadaardig .lnk-bestand aanklikken om daarin verwerkte malware te activeren. Het openen van een kwaadaardig bestand of het bezoeken van een kwaadaardige webpagina volstaat daarvoor, meldt het Amerikaanse ict-orgaan NIST in zijn beveiligingsbulletin over deze kwetsbaarheid.

Dat meldt NIST, maar dat klopt dus niet.

Het simpelweg bezoeken van een malafide webpagina kan hoogstens - als je je browser zo geconfigureerd hebt - automatisch een malafide .lnk file downloaden. Maar je zult nog steeds moeten kiezen om het te openen, en het zal vanuit MS nog steeds standaard een 'mark of the web' dragen en je dus om handmatige bevestiging vragen met de waarschuwing dat je dat niet zomaar moet doen.

[i7x]

Ja ik heb hier ook nogal mijn bedenkingen bij. Sinds wanneer kan het bezoeken van een webpagina maar willekeurige bestanden gaan downloaden en openen op je pc? Dit is hoe het er staat in het gelinkte artikel:

User interaction is required to exploit this vulnerability in that the target must visit a malicious page or open a malicious file.

Denk niet dat dit goed verwoord is. De vereiste interactie zal zijn het bezoeken van een pagina, het downloaden van het bestand, en dit vervolgens openen. Ik lees hier in de comments ook nog dat het vaak in Zips zit, dus dan komt er ook nog de stap van unzippen bij.

[Jan VP]

Nee, een louter bezoek (zonder daar ergens te klikken) kan wel degelijk volstaan voor een download. Het openen daarvan blijft een afzonderlijke actie.

[Reactie gewijzigd door Jan VP op 7 december 2025 14:04]

[Von Henkel]

Brave browser heeft een schuifje voor "Ask where to save each file before downloading"

[naaitsab]

Wat NIST zegt klopt wel degelijk, alleen is de interpretatie vanuit de schrijver van het artikel wat te ruim gemaakt. Als je een malafide Ink bestand hebt gedownload is het dubbelklikken erop wel degelijk voldoende om geïnfecteerd te raken. Het downloaden en uitvoeren van het bestand zelf, is inderdaad niet een automatisch process.

Er gaat wel een ander lek de ronde dat door middel van de 'ms-search' protocol handler een vergelijkbare actie uitvoert. Hier moet de gebruiker ook eerst goedkeuring voor geven. Door middel van social engineering ('click fix' campagne) wordt de gebruiker misleid om op akkoord te drukken.

Nog steeds wel knullig dat na zo veel lekken het nog steeds kinderlijk eenvoudig is om vanaf onbeveiligde links, powershell, cmd of vbs aan te roepen. Zo lang dat niet geblokkeerd kan worden is het dweilen met de kraan open. Bij Chromium kan je de meeste exploits voorkomen door de 'javascript optimalisatie' (vooral JIT) uit te schakelen, ten koste van wat performance. Zou fijn zijn al Microsoft hier ook een keer iets vergelijkbaars voor gaat ontwikkelen in plaats van elke keer achter de feiten aanlopen door te vertrouwen op meldingen richting gebruikers.

[R4gnax]

Nee. NIST zegt: "the target must visit a malicious page or open a malicious file"
En dat klopt pertinent niet.

Een malafide pagina openen kan voldoende zijn om de gebruiker een malafide lnk file te laten downloaden - maar dat zal nog steeds niets doen, tenzij de gebruiker dat file ook opent.

[Reactie gewijzigd door R4gnax op 7 december 2025 13:12]

[Eagle Creek]

Ik lees her en der grote verbazing dat Microsoft dit "lek" al heel lang heeft laten voortbestaan.

Ergens snap ik ook wel dat Microsoft niet gelijk aanpassingen heeft doorgevoerd omdat het daadwmerkelijke isbruik hier - het toevoegen van argumenten - een kernfunctionaliteit is van snelkoppelingen die ze niet zonder impact kunnen breken.

Tot nu toe rekende Microsoft vooral op bestaande beschermlagen: zo worden .lnk-bestanden die via Outlook binnenkomen standaard geblokkeerd of als onveilig aangemerkt, waarna je ze niet direct kan openen of downloaden. Daarnaast krijgen .lnk-bestanden die van internet komen een Mark of the Web, waardoor Windows en Office extra waarschuwingen tonen of uitvoering beperken. En dan moet je als gebruiker inderdaad een actief uitvoeren voordat er iets actief wordt.

Dat criminelen daar weer handig mee omgaan door te zippen etc is een logische stap maar ergens voelt het toch meer als een awareness- en detectprobleem dan daadwerkelijk een technische zero day. De huidige implementatie in Windows draagt daar zeker niet aan bij.

The vulnerability lies in how Windows handles .LNK files, allowing threat actors to exploit the way the operating system displays them to evade detection and execute code on vulnerable devices without the user's knowledge by padding the Target field in Windows .LNK files with whitespaces to hide malicious command-line arguments.

This ensures that the file's Target field properties display only the first 260 characters due to the added whitespaces, so users can't see the actual command executed when the LNK file is double-clicked.

[Reactie gewijzigd door Eagle Creek op 7 december 2025 12:08]

[i7x]

Als je dit zo schrijft zou het i.i.g. al helpen om het path standaard te trimmen. Het verandert niets aan de functionaliteit. Maar zelfs dan, alsof de gemiddelde persoon überhaupt weet waar je het path van de shortcut kunt zien. Ookal zouden ze wel de argumenten erachter zien, die weten toch niet wat dat zijn en wat het kan doen.

[PhilipsFan]

Hoe moeilijk is het om te checken of het .lnk bestand ook echt een shortcut is en niet stiekum een .exe, al dan niet met malware? Ik heb me hier al heel lang aan geergerd, zeker in combinatie met de standaardinstelling in verkenner waarbij de bestandsextensie standaard niet wordt weergegeven. Dat is gewoon vragen om ongemerkt ongeoorloofde code uit te voeren. Kun je nog zulke goede virusscanners hebben, als je basisfunctionaliteit van je OS niet deugt, dan is daar geen kruid tegen gewassen.

[Blokker_1999]

Ik begrijp de beslissing van MS ergens wel. Uiteindelijk is een lnk bestand gewoon een doorverwijzing naar iets anders. En ik ken niemand die systematisch gaat nakijken wat een lnk bestand als doelwit heeft voordat de link wordt geopend. Dus in dat opzicht begrijp ik dat MS hier niet direct moord en brand gaat schreeuwen.

Maar na de melding is MS wel begonnen met het aanpassen van dit gedrag. Want ondanks dat nu pas naar boven komt dat het gedrag is aangepast, heeft MS dit in essentie in de 2 maanden nadat zij de melding kregen door hun ontwikkeling en interne testing gekregen daar deployment van de patch eigenlijk al deze zomer begonnen is.

[TrafalgarLaw]

De exploit bestaat al 8 jaar minimaal. 8 hele jaren een zero day…

[dasiro]

TLDR: een link kon slechts 260 karakters weergeven in de UI en er theoretisch 32K bevatten. Dat is nu wat gepatcht is zodanig dat je alles kan zien als je genoeg naar voor of achter scrolt.

[HollowGamer]

Ik vind het heel vaag dat Microsoft ervoor kiest dit allemaal stilletjes te doen. Dit doen ze niet alleen voor dit lek, maar ook bij andere momenteel.

Het idee van Windows is toch vooral backwards compatible zijn? Je kunt nog steeds apps geschreven voor NT 4.0 prima draaien op Windows 11. Waarom ze nooit hebben gedacht dit in een veilige emulatie laag te draaien, snap ik niet zo? Daarom lijkt me juist open zijn ontzettend belangrijk.

[Reactie gewijzigd door HollowGamer op 7 december 2025 12:35]

[Z80]

Zelfs de bug is backwards compatible. Ook in NT4 SP6a kon je dit soort fratsen uithalen met een .lnk bestand. En als ik het goed heb is er ook een fix voor verschenen.

Maar waarom zouden er meer dan 260 karakters in een link moeten passen? Voor die uitzonderlijke keer dat een onmogelijke lange bestandsnaam ergens op een netwerkshare via een unc path staat?

[sympa]

En dan blokkeer je dat, met een popup. Daat houdt Windows toch wel van.

Or een regedit om het weer op de "gevaarlijke" manier te laten werken.

[GertMenkel]

Het lek is nogal een vage. Het probleem zit hem in dat de UI maar 260 tekens laat zien van de 32k die er daadwerkelijk in passen. Als Microsoft de UI aanpast om meer dan 260 tekens te tonen, crashen er gegarandeerd plugins die strings vanuit een buffer van grootte MAX_PATH kopiëren. Alsnog moet de gebruiker de opdracht zelf vinden, ergens in de 32k aan witregels moet een commando worden verstopt maar dat hoeft niet aan het begin of einde van het tekstveld te zijn; succes met scrollen!

De fix van Microsoft lost het probleem zoals gerapporteerd op (de opdrachtregel is niet in verkenner te zien omdat hij wordt afgekapt) maar doet weinig voor de veiligheid van gebruikers die niet 32 KiB aan opdrachtregel naar kladblok kopiëren voor analyse voor ze een .lnk van internet openen.

0patch heeft zelf een eigen "oplossing" gemaakt die links met meer dan 260 tekens gewoon kapot maakt. Werkt wel soort van, maar is ook niet echt iets waar je heel blij van wordt.

Qua Windows-op-Windows emulatie: als je dacht dat Windows nu al traag was, moet je Windows eens zien als iedere dialoog en systeemscherm een geëmuleerde kopie had wiens labels en inhoud lube gesynchroniseerd moet worden met wat de gebruiker op het scherm doet. De shell32-API en andere Explorer-functies zoals het linkdetailscherm laten zich nou niet bepaald eenvoudig sandboxen, het hele punt is om te integreren met de systeem-Ui. Je krijgt effectief Wine op Windows, en Wine doet al amper aan UI-compatibiliteit waardoor veel Windowsprogrammas niet op Linux kunnen integreren.

Microsoft heeft al drama genoeg over zich afgeroepen door vertragende DLL's van derde partijen laat in te laden (de reden dat je rechtermuisknopmenu in Windows 11 een extra uitklapoptie heeft voor ouderwetse menu-opties), als ze de hele shell zo moeten gaan patchen dan gaan mensen alleen maar harder klagen.

[Reactie gewijzigd door GertMenkel op 7 december 2025 13:36]

[theduke1989]

Ik hoop dat dit beter werkt met Kiosk modus. Tot op heden werkt niet alles even goed met de .ink bestanden!

[Damic]

het zijn link bestanden niet inkt :D

[SHFT]

John Hammond heeft een interessante video gemaakt over dit fenomeen:

YouTube: microsoft turned me down

[kodak]

Het niet zo serieus nemen dat er een ,ero-dat in je product zit. Het niet serieus nemen dat je belangrijke informatie voor gebruikers verbergt. Het opzettelijk onduidelijk zijn wanneer je de risico's gaat verhelpen. Het opzettelijk onduidelijk zijn wat je wel en niet verhelp. Het is allemaal onderdeel van een werkwijze om de klanten zo min mogelijk zelf controle te willen geven wat (on)gewenst is.

Microsoft stelt zich hiermee boven de belangen van gebruikers. Het probeert gebruikers onwetend te houden om daarmee hun afhankelijk van wat Microsoft te versterken. Je moet er als klant maar op ze vertrouwen dat Microsofts beveiligingsproducten je dan wel beschermen. Maar ook daarvan geven ze geen blijk.

Het is al jaren bij Microsoft bekend dat die lnk-bestanden en de verwerking daarvan niet door Microsoft gemaakt zijn om klanten te beschermen. Deze zero-day is niet de eerste keer dat Microsoft klanten hiermee bewust risico laat lopen. Microsoft weigert daar duidelijk over te zijn. Ze werken hiermee opzettelijk mee aan het helpen van criminelen. Omdat dit een opeenstapeling van opzettelijke oorzaken is dat die criminelen hier gebruik van maken.