Free Micropatches for Windows Remote Access Connection Manager DoS (0day)

 

During our investigation of CVE-2025-59230, a Windows Remote Access Connection Manager elevation of privilege vulnerability that was patched by Microsoft with October 2025 Windows updates, we found an exploit for it that nicely demonstrated local arbitrary code execution as Local System when launched as a non-admin Windows user.

Interestingly though, this exploit - while exploiting CVE-2025-59230 - also included an exploit for another vulnerability that turned out to have remained unpatched to this day. Let's take a closer look.

CVE-2025-59230 is a fairly simple vulnerability, conceptually similar to CVE-2025-49760, which we had recently patched. Upon startup, the Remote Access Connection Manager ("RasMan") service registers an RPC endpoint that other services subsequently connect to and trust. The vulnerability lies in the fact that when RasMan is not running, any process - even attacker's unprivileged exploit - can register the same RPC endpoint and have privileged services connect to it and trust its responses. This trust can be abused to instruct a connecting service to execute attacker's code.

So much for CVE-2025-59230. But you probably noticed the "when RasMan is not running" part; the RasMan service usually gets stared automatically upon Windows startup (even though it may be configured as "manual" on Windows 11), and even a scheduled task created by a local attacker would not be quick enough to find it in a "not running" state and outrun it towards registering its RPC endpoint.

Consequently, a working exploit must therefore be able to (also) stop the RasMan service to release said RPC endpoint. And this was the second, non-obvious vulnerability that the CVE-2025-59230 exploit we had found utilizes: one that allows an unprivileged user to crash the RasMan service. Without this capability, CVE-2025-59230 could hardly be exploited. 

We alerted Microsoft about this issue; they will likely provide an official patch for still-supported Windows versions in one of future Windows updates.

The Vulnerability  

We traced the vulnerability to a flawed coding logic, whereby a circular linked list is being traversed in a loop, and the loop is exited if the current element of the list points to the first element, meaning that the entire list has been traversed. Inside the loop, the pointer to the current element is compared with NULL - which is a reasonable sanity check. If the pointer is not NULL, some value of the current element is read and can potentially also exit the loop. But if the pointer is NULL...

... the loop is not exited - rather, the execution continues by reading the pointer to the next list element from this NULL pointer. This causes memory access violation and crashes the RasMan service.

Let's look at the vulnerable code on the latest Windows 11 version. The image below shows the code traversing the linked list, including a flawed sanity check. 

To be fair, it's easy to imagine how this error was made: when expecting a circular linked list, this function could - justifiably - rely on whoever had built the list to have done it properly, guaranteeing that each element will point to an actual next element, not NULL. The programmer here was extra cautious to have decided to add a check for a NULL pointer. However, this check probably could never have been tested for correctness because in test cases, all linked lists have been valid and did not contain elements pointing to NULL.

What the check should have done is exit the loop if a NULL were encountered.

 

Our Patch

Our patch does exactly that. As shown on the image below, our patch (code added in blue and green code blocks) injects another check for a NULL pointer that exits the loop.

 

 

Let's see the vulnerability and our patch in action. On the video you can see that with 0patch enabled., the exploit is able to crash the RasMan service, and with 0patch enabled, the crash does not occur. (Errata: the video highlights the "Remote Access Auto Connection Manager" instead of the "Remote Access Connection Manager".)

 

 

Micropatch Availability

Micropatches were written for the following security-adopted as well as still-supported Windows versions:

1. Windows 11 v25H2 - fully updated
2. Windows 11 v24H2 - fully updated
3. Windows 11 v23H2 - fully updated
4. Windows 11 v22H2 - fully updated
5. Windows 11 v21H2 - fully updated
6. Windows 10 v22H2 - fully updated
7. Windows 10 v21H2 - fully updated
8. Windows 10 v21H1 - fully updated
9. Windows 10 v20H2 - fully updated
10. Windows 10 v2004 - fully updated
11. Windows 10 v1909 - fully updated
12. Windows 10 v1809 - fully updated
13. Windows 10 v1803 - fully updated
14. Windows 7 - fully updated with no ESU, ESU 1, ESU 2 or ESU 3
15. Windows Server 2008 R2 - fully updated with no ESU, ESU 1, ESU 2, ESU 3 or ESU 4
16. Windows Server 2012 - fully updated with no ESU or ESU 1
17. Windows Server 2012 R2 - fully updated with no ESU or ESU 1
18. Windows Server 2016 - fully updated
19. Windows Server 2019 - fully updated
20. Windows Server 2022 - fully updated
21. Windows Server 2025 - fully updated

 

Micropatches have already been distributed to, and applied on, all affected online computers with 0patch Agent in FREE, PRO or Enterprise accounts (unless Enterprise group settings prevented that). 

As always, we included these 0day patches in our FREE plan until the original vendor has provided their official patch. 

Note that about 40% of our customers are using 0patch on still-supported Windows versions like Windows 11 25H2 and Server 2025 as an additional defense against 0days. 

Vulnerabilities like these get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, start a free trial, then install and register 0patch Agent. Everything else will happen automatically. No computer reboot will be needed.

Did you know 0patch security-adopted Windows 10 and Office 2016 and 2019 when they went out of support last October, allowing you to keep using them for at least 3 more years (5 years for Windows 10)? Read more about it here and here. 

To learn more about 0patch, please visit our Help Center.

Microsoft Silently Patched CVE-2025-9491 - We Think Our Patch Provides More Security

Patching What You See vs. Patching What You Execute

Summary: Trend Micro discovered that attackers have long been using a trick to hide what a Windows shortcut actually does, preventing users from seeing malicious commands. Microsoft decided this was not patch-worthy. Others then found this same trick still being exploited, and the issue got a CVE. Microsoft doubled down, but silently patched the issue so that malicious commands can no longer be hidden. We created a different patch that actually blocks discovered attacks.

The story - or at least its public part - begins on March 18, 2025, with Trend Micro's publication of Advisory ZDI-25-148 and an associated article titled Windows Shortcut Exploit Abused as Zero-Day in Widespread APT Campaigns. This article by Peter Girnus and Aliakbar Zahravi describes how they observed close to a thousand malicious Windows shortcut (.lnk) files being used in various offensive campaigns dating back to 2017. These shortcut files were crafted such that viewing their properties in Windows, one could not see the entire commands the shortcuts executed. The trick was an old one: using various "whitespace" characters to move the malicious part of the command out of user's sight.

For instance, the article shows how Windows 11 would show properties of a shortcut file with a target like this:

conhost.exe<265 spaces>calc.exe

 

Windows 11 showing an obfuscated target in a Windows shortcut
(Image borrowed from Trend Micro's article)

As you can see, the Target field shows only space characters (selected, therefore in blue), and even scrolling left or right would not reveal the presence of "calc.exe", or whatever malicious command there might be at the end. Instead of space characters, various other characters could be used to achieve a similar effect.

As Peter and Aliakbar explained, Microsoft was notified about this issue but decided it didn't meet their bar for servicing. In other words, they would not consider it a vulnerability worth patching.

At this point we have to admit we (too?) misunderstood the problem Trend Micro was presenting in April. We thought the issue was just that padding a malicious command with spaces would not show the malicious command in the dialog because the dialog always showed the end of the command - and when padded with spaces, the end is just all spaces. We considered that a bit silly as the user could always scroll back to the start of the field and see everything - and we found Microsoft's decision to not fix this reasonable, albeit the trick was actually being used in malicious campaigns.

After all, what could be done? One can't ban whitespace characters from the command string, and if the Properties dialog showed the beginning of the target instead of the end, malicious code could then be hidden at the end. In addition to these technical details, there was also a social engineering aspect: what profile of user gets a PDF-lookalike Windows shortcut file, checks its properties, sees something like "powershell.exe" - without the hidden malicious arguments - and based on that still decides to double-click it? Most users, we thought, would either be non-IT persons and not look at properties at all, or would be somewhat IT persons and probably concerned by seeing some script there, likely also scrolling left and right in the Target field to see the whole thing.

Following this reasoning, we also decided not to patch this issue.

Case closed.

Until end of October, that is, when Arctic Wolf published an article titled UNC6384 Weaponizes ZDI-CAN-25373 Vulnerability to Deploy PlugX Against Hungarian and Belgian Diplomatic Entities. UNC6384 is code name for a Chinese-affiliated threat actor, and ZDI-CAN-25373 is Trend Micro's working ID for the described issue.

Arctic Wolf identified a campaign by threat actor UNC6384 specifically targeting Hungarian and Belgian diplomatic entities during September and October 2025 - using Windows shortcuts exploiting the described vulnerability. This discovery revived the interest in this issue, which was by then assigned CVE-2025-9491. Microsoft was under some heat in the media for not having patched this exploited-in-the-wild issue yet, but they doubled-down with and advisory titled Microsoft Guidance on CVE-2025-9491 Windows LNK File UI Behavior.

In this advisory, Microsoft claimed that "during the user experience, the user is warned several times that proceeding may be harmful."

Now, "several times" is a bit of an exaggeration for what must have been just once in described actual attacks, but fact is, if one downloads a .lnk file from the Internet (which has to be packaged in a ZIP archive as browsers deliberately mangle its file name to protect users), it will have Mark of the Web and double-clicking it will warn the user about opening a potentially harmful file from the Internet. That is, unless the attacker knows of some vulnerability that bypasses Mark of the Web like this one.

The advisory concludes: "Due to the user interaction involved and the fact that the system already warns users that this format is untrusted, Microsoft does not consider this a vulnerability."

Having read this advisory with our then-current understanding of the issue, we still agreed with Microsoft's conclusion. 

But then we looked again. And finally saw what the issue really was: it was not just the sliding of malicious content out of the Target field's default focus. Instead, a .lnk file structure allows the Target arguments to be a very long string (tens of thousands of characters), but the Properties dialog only shows the first 260 characters, silently cutting off the rest.

So it is possible to construct a .lnk file that runs a reeeeealy long PowerShell or BAT script, but only the first 260 characters of it would be shown to the user who viewed its properties. And these characters could be mostly "whitespace" characters to push the interesting bits entirely out of the Target field - even if the user scrolled to the very end.

Now this makes it more interesting: it's now a matter of trust in the user interface. The string that Windows are showing to you -- is not the entire string that will actually be executed. Even if you're an IT person, you can be fooled by this issue because you rightfully expect the UI can be trusted to show you the whole command.

This did look patch-worthy, so we decided to analyze the issue deeper in order to come up with a good patch.

While we were developing our patch, the November Patch Tuesday brought new Windows Updates. And as expected ("Microsoft does not consider this a vulnerability"), there was no mention of anything remotely akin to this issue among its 63 patched vulnerabilities. [Update 12/4/2025: see * below]

However...

 

Microsoft's Patch

However, we noticed something did change with November* Windows Updates: now, the Properties dialog of a .lnk file shows the entire Target command with arguments, no matter how long it is. The theoretically-up-to-32k-character-long string is now shown in the same single-line field that can't even reveal an entire modest-sized command without selecting some text and moving the mouse left or right. But okay, at least one can select all, copy and paste the string to a text editor.

* [Update 12/4/2025: A friend in the know subsequently pointed out that this change had been deployed by Microsoft already in June 2025 but it may have been activated gradually. For instance, one of our testing Windows 11 24H2 computers we re-inspected had it activated in August. Our claim that it was deployed in November was therefore incorrect. Props to said friend for pointing this out.] 

The issue was apparently demoted from vulnerability to functional bug, silently fixed without an advisory, and trust in the user interface was restored.

Arguably, if the problem was defined as "The properties dialog does not always show exactly what will be executed," it would indeed have been resolved. But this approach was weird: namely, it has always been the case that the "ordinary" way to create or modify a Windows shortcut - via Explorer user interface - only allowed you to enter up to 260 characters to the Target field. The only way for this string to be longer is to create the shortcut programmatically, e.g. using Windows API. (And some application may be creating such legitimate shortcuts for its own use.) So how much would showing all Target characters in a small field improve chances for victims targeted in actual attacks?

 

Our Patch

We decided to take a different route: Our premise was that a legitimate non-malicious .lnk file that regular Windows users come across would be created manually and would therefore never have a Target with more than 260 characters. However, we still accept that shortcut files with more than 260 character Target can be valid, just not meant for manual opening by users. Consequently, our patch has the following logic:

If the process opening the .lnk file is Windows Explorer, AND the Target has more than 260 characters, then we cut the Target at 260 characters and alert the user that a suspicious .lnk file was shortened.

 

 

Our patch would break the 1000+ malicious shortcuts identified by Trend Micro for all targeted users, while Microsoft's patch would only allow the most cautious among these users - who would probably not launch such shortcuts anyway - to see the entire malicious command string. Even though malicious shortcuts could be constructed with fewer than 260 characters, we believe disrupting actual attacks detected in the wild can make a big difference for those targeted.

Let's see our patch in action. On the video below you can see that a shortcut file looking like a PDF document has a Target that doesn't fully show in the Properties dialog, while a hex editor reveals its full content. Launching it with 0patch disabled results in spawning the calculator (which was hidden from the Properties dialog), but launching it with 0patch enabled results in a security notification and the execution of only the first 260 characters of the shortcut's Target.

 

 

Micropatch Availability

Micropatches were written for the following security-adopted Windows versions:

1. Windows 11 v22H2 - fully updated
2. Windows 11 v21H2 - fully updated
3. Windows 10 v22H2 - fully updated
4. Windows 10 v21H2 - fully updated
5. Windows 10 v21H1 - fully updated
6. Windows 10 v20H2 - fully updated
7. Windows 10 v2004 - fully updated
8. Windows 10 v1909 - fully updated
9. Windows 10 v1809 - fully updated
10. Windows 10 v1803 - fully updated
11. Windows 7 - fully updated with no ESU, ESU 1, ESU 2 or ESU 3
12. Windows Server 2008 R2 - fully updated with no ESU, ESU 1, ESU 2, ESU 3 or ESU 4
13. Windows Server 2012 - fully updated with no ESU or ESU 1
14. Windows Server 2012 R2 - fully updated with no ESU or ESU 1 

In addition, patches were written for the following still-supported fully updated Windows Server versions, which for some reason did not receive a patch from Microsoft (note that Server 2025 did get the patch for some reason):

1. Windows Server 2016 
2. Windows Server 2019
3. Windows Server 2022 

We'd like to thank Peter Girnus and Aliakbar Zahravi with Trend Micro for sharing the details, which allowed us to create a patch for our users.

Micropatches have already been distributed to, and applied on, all affected online computers with 0patch Agent in PRO or Enterprise accounts (unless Enterprise group settings prevented that).

Vulnerabilities like these get discovered on a regular basis, and attackers know about them all. If you're using Windows that aren't receiving official security updates anymore, 0patch will make sure these vulnerabilities won't be exploited on your computers - and you won't even have to know or care about these things.

If you're new to 0patch, create a free account in 0patch Central, start a free trial, then install and register 0patch Agent. Everything else will happen automatically. No computer reboot will be needed.

Did you know 0patch security-adopted Windows 10 and Office 2016 and 2019 when they went out of support last October, allowing you to keep using them for at least 3 more years (5 years for Windows 10)? Read more about it here and here. 

To learn more about 0patch, please visit our Help Center.