Listen to this Post

Introduction:
In a significant shift for IT administrators and security professionals, Microsoft has quietly hardened the authentication flow on both Windows 11 and Windows 10, effectively blocking a longstanding method of credential autofill used during remote support sessions. This update targets the way specific applications interact with the Secure Desktop and credential prompts, rendering virtual keyboard input from screen-sharing tools inert. While this change may disrupt streamlined workflows for helpdesk teams, it serves as a critical mitigation against “session takeover” attacks where attackers use remote administration tools to inject credentials into locked UAC prompts.
Learning Objectives:
- Understand the technical rationale behind Microsoft’s restriction of credential autofill via virtual input.
- Identify the attack vectors (e.g., RDP session hijacking, support tool abuse) that this update mitigates.
- Learn how to audit your environment for applications relying on automated authentication workflows.
You Should Know:
- The Technical Breakdown: Why Virtual Input No Longer Works
The recent Windows updates (rolling out to 24H2, 25H2, and older versions) modify the behavior of the Secure Desktop—the isolated desktop environment used for login screens, UAC prompts, and credential dialogs. Previously, applications leveraging remote desktop or screen-sharing APIs could simulate keyboard input (via `SendInput` or virtual keyboard drivers) directly into these secure prompts. Microsoft has now implemented a filter that rejects input from virtual channels not explicitly trusted by the Local Security Authority (LSA).
What this does: It stops tools like remote support software from typing passwords into a locked screen.
How to verify the change:
To see if your system has this hardening applied, check the installed KBs and review the LSA operational logs.
Windows Command (PowerShell):
Get-HotFix | Where-Object { $<em>.HotFixID -like "KB50" -or $</em>.HotFixID -like "KB60" } | Format-Table HotFixID, InstalledOn -AutoSize
Linux Perspective (If managing Windows via Linux):
While you cannot change this setting from Linux, you can audit SMB connections that might be affected. Use `remmina` or `xfreerdp` to test if your RDP wrapper scripts fail when attempting to pass credentials to a locked session:
xfreerdp /v:TargetWindowsIP /u:user /p:password +auto-reconnect Observe if the connection hangs at the login screen requiring physical interaction.
2. The “Good Reason” Explained: Preventing Session Takeover
Microsoft’s justification, as detailed in the linked article, centers on security hardening. Attackers often exploit remote support tools in “Tech Support Scams” or post-exploitation scenarios. Once they have a foothold on a network, they can use tools like ScreenConnect or RDP to access a locked workstation. By blocking virtual input, even if an attacker gains screen access, they cannot force the system to accept stolen credentials or bypass a lock screen.
Step‑by‑step guide on how an attacker previously exploited this:
1. Gain Access: Attacker compromises a user session via phishing.
2. Escalate: They run a tool to initiate a remote support connection back to their C2 server.
3. Lock Screen Bypass: The victim locks the PC. The attacker, having screen control, uses a script to simulate keyboard input typing the victim’s password into the locked login screen.
4. Access Granted: The attacker gains access to the desktop without needing to crack the hash.
Mitigation Verification (Windows):
Ensure your EDR solution is monitoring for `winlogon.exe` interactions with non-Microsoft processes.
Command Prompt (Admin) - Check for unusual autofill processes tasklist /m wow64log.dll If any third-party processes appear here, they may be impacted by the update.
3. Impact on Remote Support and Automation Workflows
Organizations that rely on scripts to automate logins for headless workstations or kiosks will face the most friction. The change specifically targets the “Credential Autofill” feature. If you have PowerShell scripts using `SendKeys` or .NET methods to populate login boxes, these will fail when the target is a Secure Desktop prompt.
Linux/Windows Comparison:
In Linux environments (Gnome/KDE), similar security is often managed via `polkit` policies. You can restrict who can authenticate via remote sessions by editing:
sudo nano /etc/polkit-1/localauthority/50-local.d/remote-access.pkla
This is analogous to Microsoft’s new stance, but Windows now enforces it at the kernel/user boundary level, not just the policy level.
- Step‑by‑Step: How to Adapt Your Remote Support Tools
For IT admins needing to maintain support capabilities, you must transition to using the native RDP session shadowing or tools that integrate with the Windows “Take Control” API correctly.
Enabling RDP Session Shadowing (Windows 11):
1. Open Group Policy Editor (`gpedit.msc`).
- Navigate to:
Computer Configuration > Administrative Templates > Windows Components > Remote Desktop Services > Remote Desktop Session Host > Connections. - Enable “Set rules for remote control of Remote Desktop Services user sessions”.
4. Choose “Full Control with user’s permission”.
- Connect via RDP, then use `mstsc /shadow:SessionID` to initiate a shadow session that bypasses the virtual input block because it uses native Windows trust.
Linux Test for Shadowing:
Using `xfreerdp`, you can attempt to shadow:
xfreerdp /v:TargetPC /u:user /shadow /auth-pkg-type:nego Note: This requires the user to accept the prompt physically.
5. Auditing and Logging for Failed Authentications
With this change, you must ensure your logging is robust to differentiate between a user fat-fingering a password and an automated tool being blocked.
Enable Command Line auditing to see if scripts are trying to execute:
auditpol /set /subcategory:"Process Creation" /success:enable /failure:enable reg add "HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Audit" /v ProcessCreationIncludeCmdLine_Enabled /t REG_DWORD /d 1 /f
After enabling, check the Security Log (Event ID 4688) for processes like `cmd.exe` or `powershell.exe` launched by remote tools attempting to interact with LogonUI.exe.
6. Cloud and Hybrid Workarounds (Azure AD/Entra ID)
If your devices are Entra ID joined, this change reinforces the move towards passwordless authentication. Tools that rely on Web Account Manager (WAM) for tokens are unaffected, as they don’t simulate keyboard input—they use API tokens.
Configuration Check:
Ensure your remote support tools are updated to support “modern authentication” (OAuth2/OpenID Connect) rather than legacy password prompts.
– Verify in Azure AD Sign-in logs: `Sign-ins > Filter by “Application” > Look for “Interactive sign-in” failures from your support tool IPs.`
What Undercode Say:
- Key Takeaway 1: Microsoft’s block on credential autofill is a strategic move to dismantle a silent attack vector used in session hijacking, forcing attackers to rely on more detectable methods like LSASS dumping.
- Key Takeaway 2: IT departments must immediately audit any third-party remote administration tools and scripts; legacy tools relying on “SendKeys” or virtual drivers will break, requiring migration to RDP shadowing or API-based support suites.
This update is more than a minor inconvenience; it is a fundamental architectural shift. By isolating the Secure Desktop from virtual input streams, Microsoft has closed a loophole that existed for decades. While it will undoubtedly cause short-term friction for helpdesk teams, the long-term gain is a significant reduction in the efficacy of remote access trojans (RATs) that attempt to interact directly with the Windows login screen. Organizations should view this as an opportunity to accelerate the adoption of passwordless authentication and manage remote support through sanctioned, API-driven channels that respect the integrity of the authentication process.
Prediction:
We will see a surge in “Session Proxy” attacks where adversaries target the browser or application after the user has already authenticated, rather than trying to inject credentials into the lock screen. Additionally, expect rapid updates from remote software vendors (TeamViewer, LogMeIn, etc.) to implement “Windows Trusted Channel” support, while attackers pivot to exploiting the Windows Hello for Business container directly.
▶️ Related Video (82% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Dave Milne – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅


