June 4th, 2026
Windows 11 includes multiple built-in telemetry systems that observe keyboard input for accessibility, diagnostics, and security. These systems are not keyloggers, but they do buffer keystrokes. As a result, typed passwords entered into PuTTY, WinSCP, MySQL, SSH clients, and other applications may appear in system processes such as LSASS.exe, Microsoft Defender (MsMpEng.exe), ctfmon.exe, and conhost.exe.
Clipboard DATA
A deep technical analysis of Windows input pipelines, security telemetry, and why PuTTY, WinSCP, MySQL, SSH, and SFTP passwords may leak into system memory
This article explains:
- Why typed passwords appear in LSASS and ctfmon.exe
- Why Credential Guard does not protect these passwords
- Why this is expected behavior, not a vulnerability
- Why clipboard data ends up in LSASS and CTFMON
- The real security risks this creates
- How to mitigate the issue
Introduction: A surprising discovery
Security researchers and malware analysts have recently observed something unexpected: passwords typed into third-party applications can appear inside LSASS memory on Windows 11. This includes:
Security researchers and malware analysts have recently observed something unexpected: passwords typed into third-party applications can appear inside LSASS memory on Windows 11. This includes:
- PuTTY SSH passwords
- WinSCP SFTP/FTP passwords
- MySQL interactive passwords
- Linux server root passwords
- Database credentials
- Cloud service credentials
Even more concerning: closing the application does not immediately remove the password from memory. In testing, WinSCP passwords remained inside the ctfmon.exe process long after the application was closed. Because ctfmon.exe is not a protected process, non-admin malware could extract the password.
This behavior is surprising because LSASS is normally associated with Windows authentication secrets, not third-party credentials. But the explanation is architectural, not malicious.
Why Typed Passwords Appear in LSASS Memory
Typed passwords travel through five Windows subsystems before reaching the application:
1. Win32k keyboard input
2. Text Services Framework (TSF) / ctfmon.exe
3. Console Host (conhost.exe) or Win32 message loop
4. ETW security telemetry
5. Microsoft Defender behavioral monitoring
LSASS receives telemetry from ETW providers for:
- Credential Guard
- Anti-credential-theft heuristics
- Security auditing
- Behavioral analysis
This means LSASS may temporarily contain:
- Fragments of typed passwords
- Input buffers
- Telemetry strings
This is not LSASS "reading your keystrokes." It is LSASS receiving telemetry from Windows security subsystems.
1. Win32k keyboard input
2. Text Services Framework (TSF) / ctfmon.exe
3. Console Host (conhost.exe) or Win32 message loop
4. ETW security telemetry
5. Microsoft Defender behavioral monitoring
LSASS receives telemetry from ETW providers for:
- Credential Guard
- Anti-credential-theft heuristics
- Security auditing
- Behavioral analysis
This means LSASS may temporarily contain:
- Fragments of typed passwords
- Input buffers
- Telemetry strings
This is not LSASS "reading your keystrokes." It is LSASS receiving telemetry from Windows security subsystems.
Why WinSCP, PuTTY, and MySQL Are Affected
Applications like PuTTY, WinSCP, MySQL CLI, SSH clients, and SFTP tools use standard Windows input APIs, not secure credential APIs.
They do not use:
- Secure Desktop
- Windows Hello
- Credential Manager
- CredUIPromptForWindowsCredentials
Therefore, Windows treats their password fields as ordinary text input.
Ordinary text input is:
- Buffered
- Observed
- Telemetry-processed
- Not isolated
This is why your WinSCP password appears in LSASS memory.
Applications like PuTTY, WinSCP, MySQL CLI, SSH clients, and SFTP tools use standard Windows input APIs, not secure credential APIs.
They do not use:
- Secure Desktop
- Windows Hello
- Credential Manager
- CredUIPromptForWindowsCredentials
Therefore, Windows treats their password fields as ordinary text input.
Ordinary text input is:
- Buffered
- Observed
- Telemetry-processed
- Not isolated
This is why your WinSCP password appears in LSASS memory.
NEW FINDING: Passwords Remain in ctfmon.exe After Application Exit
During testing, a critical behavior was observed:
Even after closing WinSCP, the typed password remained in the memory of ctfmon.exe.
This is important for two reasons:
1. ctfmon.exe is not a protected process.
2. Non-admin malware can read its memory.
This means:
- A low-privilege malware sample could extract your SSH or SFTP password.
- The password may remain in memory for minutes or hours.
- Closing the application does not clear the buffer.
This is not a theoretical risk. It is reproducible and consistent.
During testing, a critical behavior was observed:
Even after closing WinSCP, the typed password remained in the memory of ctfmon.exe.
This is important for two reasons:
1. ctfmon.exe is not a protected process.
2. Non-admin malware can read its memory.
This means:
- A low-privilege malware sample could extract your SSH or SFTP password.
- The password may remain in memory for minutes or hours.
- Closing the application does not clear the buffer.
This is not a theoretical risk. It is reproducible and consistent.
Why Credential Guard does not protect these passwords
Credential Guard protects:
- NTLM hashes
- Kerberos tickets
- Windows logon secrets
- SSO tokens
It does not protect:
- Linux SSH passwords
- WinSCP passwords
- PuTTY passwords
- MySQL passwords
- Any password typed into a normal input field
Because these passwords:
- Never enter LSASS as credentials
- Never become Windows authentication material
- Are just raw keystrokes
Credential Guard was never designed to protect them.
- NTLM hashes
- Kerberos tickets
- Windows logon secrets
- SSO tokens
It does not protect:
- Linux SSH passwords
- WinSCP passwords
- PuTTY passwords
- MySQL passwords
- Any password typed into a normal input field
Because these passwords:
- Never enter LSASS as credentials
- Never become Windows authentication material
- Are just raw keystrokes
Credential Guard was never designed to protect them.
Is this a security vulnerability? From Microsoft's perspective: No. Because:
- Console input is inherently insecure
- Applications choose to handle passwords manually
- LSASS is a protected process (PPL)
- No data is exfiltrated
- No keylogging API is involved
This is considered expected behavior.
However, from a security-research perspective, it is a real risk:
- Memory forensics tools can extract these passwords
- Malware with PPL bypasses could theoretically access LSASS
- Non-admin malware can extract passwords from ctfmon.exe
- Administrators may assume Credential Guard protects them (it does not)
This is a design limitation, not a bug.
- Console input is inherently insecure
- Applications choose to handle passwords manually
- LSASS is a protected process (PPL)
- No data is exfiltrated
- No keylogging API is involved
This is considered expected behavior.
However, from a security-research perspective, it is a real risk:
- Memory forensics tools can extract these passwords
- Malware with PPL bypasses could theoretically access LSASS
- Non-admin malware can extract passwords from ctfmon.exe
- Administrators may assume Credential Guard protects them (it does not)
This is a design limitation, not a bug.
What actually happens to your typed passwords. Typed passwords may appear in:
- LSASS.exe
- Microsoft Defender (MsMpEng.exe)
- ctfmon.exe
- conhost.exe
- ETW buffers
This is because Windows:
- Buffers input
- Analyzes input
- Logs input metadata
- Sends telemetry to security subsystems
None of this is exfiltrated. But it does remain in memory.
- LSASS.exe
- Microsoft Defender (MsMpEng.exe)
- ctfmon.exe
- conhost.exe
- ETW buffers
This is because Windows:
- Buffers input
- Analyzes input
- Logs input metadata
- Sends telemetry to security subsystems
None of this is exfiltrated. But it does remain in memory.
Real-world impact for Administrators
This behavior matters for:
Penetration testers:
- Memory forensics tools can extract SSH and database passwords.
Incident responders:
- LSASS dumps may contain non-Windows credentials.
System administrators:
- Tools like PuTTY, WinSCP, MySQL CLI, psql, and redis-cli are widely used for privileged access.
- Typed passwords may remain in memory long after the application closes.
Malware analysts:
- Non-admin malware can extract passwords from ctfmon.exe.
This behavior matters for:
Penetration testers:
- Memory forensics tools can extract SSH and database passwords.
Incident responders:
- LSASS dumps may contain non-Windows credentials.
System administrators:
- Tools like PuTTY, WinSCP, MySQL CLI, psql, and redis-cli are widely used for privileged access.
- Typed passwords may remain in memory long after the application closes.
Malware analysts:
- Non-admin malware can extract passwords from ctfmon.exe.
How to mitigate the íssue? Use secure credential APIs:
- Windows Credential UI
- Secure Desktop
- Windows Hello
- Credential Manager
Use key-based authentication:
- SSH keys
- Disable password login
- Use agent forwarding
Avoid typing passwords into consoles:
- Use .pgpass
- Use .mylogin.cnf
- Use SSH keys
- Use WinSCP stored sessions
Use password managers with secure injection:
- Some managers use isolated injection APIs
Use virtualization:
- WSL
- Linux VM
- Dedicated jump host
This avoids Windows input telemetry entirely.
- Windows Credential UI
- Secure Desktop
- Windows Hello
- Credential Manager
Use key-based authentication:
- SSH keys
- Disable password login
- Use agent forwarding
Avoid typing passwords into consoles:
- Use .pgpass
- Use .mylogin.cnf
- Use SSH keys
- Use WinSCP stored sessions
Use password managers with secure injection:
- Some managers use isolated injection APIs
Use virtualization:
- WSL
- Linux VM
- Dedicated jump host
This avoids Windows input telemetry entirely.
Conclusion
Windows 11's input pipeline is deeply integrated with accessibility, diagnostics, and security telemetry. As a result, typed passwords, even in applications like PuTTY, WinSCP, and MySQL, may appear in system processes such as LSASS, Defender, and ctfmon.exe. This is not a keylogger. This is not a vulnerability. This is not cloud exfiltration. It is a side effect of Windows architecture, and one that administrators must understand when handling sensitive credentials. The new finding that passwords remain in ctfmon.exe even after closing WinSCP, and that non-admin malware can extract them, highlights the need for better application design and safer credential handling practices.
Windows 11's input pipeline is deeply integrated with accessibility, diagnostics, and security telemetry. As a result, typed passwords, even in applications like PuTTY, WinSCP, and MySQL, may appear in system processes such as LSASS, Defender, and ctfmon.exe. This is not a keylogger. This is not a vulnerability. This is not cloud exfiltration. It is a side effect of Windows architecture, and one that administrators must understand when handling sensitive credentials. The new finding that passwords remain in ctfmon.exe even after closing WinSCP, and that non-admin malware can extract them, highlights the need for better application design and safer credential handling practices.
Clipboard text and typed passwords can appear inside LSASS memory on Windows due to shared input buffers, secure desktop transitions, and text service architecture. This article explains the real technical reasons and how to mitigate the issue.
Many security researchers and forensic analysts are surprised when clipboard text or even typed passwords appear inside LSASS memory dumps. Because LSASS is the Local Security Authority Subsystem Service, it is easy to assume that Windows is intentionally harvesting clipboard data or tracking user activity. In reality, the explanation is far more technical and far less malicious. Clipboard data ends up in LSASS due to shared memory regions, text service architecture, and secure desktop transitions. This article explains exactly why this happens, how Windows input subsystems work, and what security implications follow.
LSASS is not harvesting clipboard data, it is responsible for authentication, token generation, and credential provider communication. It does not contain any code that reads the clipboard or monitors user activity. When clipboard text appears in LSASS, it is not because LSASS is collecting it. Instead, LSASS inherits or maps memory regions that already contain clipboard or text input data. This is a side effect of how Windows handles text input, accessibility, and secure UI operations.
Shared input buffers and clipboard leakage.
Windows uses shared memory buffers to handle text input across the entire operating system. These buffers are used by:
- Text Services Framework (TSF)
- Input Method Editors (IME)
- CTFMON (ctfmon.exe)
- Accessibility tools
- Language services
These components store keystrokes, clipboard text, and intermediate text states. Because these buffers are global and shared, any process that interacts with the text service architecture may map or inherit them. LSASS interacts with these systems during authentication events, which can cause clipboard data to appear in its memory space. This is not intentional harvesting. It is a side effect of shared memory design.
Windows uses shared memory buffers to handle text input across the entire operating system. These buffers are used by:
- Text Services Framework (TSF)
- Input Method Editors (IME)
- CTFMON (ctfmon.exe)
- Accessibility tools
- Language services
These components store keystrokes, clipboard text, and intermediate text states. Because these buffers are global and shared, any process that interacts with the text service architecture may map or inherit them. LSASS interacts with these systems during authentication events, which can cause clipboard data to appear in its memory space. This is not intentional harvesting. It is a side effect of shared memory design.
Secure desktop transitions and memory duplication.
When Windows switches to the Secure Desktop, such as during UAC prompts or credential entry dialogs, LSASS becomes involved in credential provider negotiation. During this transition, Windows may:
- duplicate memory regions
- freeze clipboard state
- copy text buffers
- preserve IME and TSF data
If clipboard text was recently used, these buffers may be duplicated into the secure desktop environment. LSASS may then inherit or map these duplicated regions, causing clipboard text to appear in LSASS memory dumps.
When Windows switches to the Secure Desktop, such as during UAC prompts or credential entry dialogs, LSASS becomes involved in credential provider negotiation. During this transition, Windows may:
- duplicate memory regions
- freeze clipboard state
- copy text buffers
- preserve IME and TSF data
If clipboard text was recently used, these buffers may be duplicated into the secure desktop environment. LSASS may then inherit or map these duplicated regions, causing clipboard text to appear in LSASS memory dumps.
CTFMON and text services retain data after applications close. It is the global text input broker for Windows. It manages:
- keyboard input
- language switching
- IME composition
- TSF communication
CTFMON often retains text buffers long after an application closes. For example, if a user types a password into WinSCP, PuTTY, or a console application, the text may remain in CTFMON memory. If LSASS interacts with TSF or IME during a secure desktop event, it may map these buffers. This explains why clipboard text or typed passwords can appear in LSASS even after the original application has exited.
- keyboard input
- language switching
- IME composition
- TSF communication
CTFMON often retains text buffers long after an application closes. For example, if a user types a password into WinSCP, PuTTY, or a console application, the text may remain in CTFMON memory. If LSASS interacts with TSF or IME during a secure desktop event, it may map these buffers. This explains why clipboard text or typed passwords can appear in LSASS even after the original application has exited.
User activity correlation is not a feature of LSASS.
Some people believe that LSASS or Windows Defender tracks clipboard contents to correlate user activity with authentication events. This is incorrect. Neither LSASS nor Windows Defender performs clipboard correlation. However, some enterprise Data Loss Prevention products do track clipboard events. This may be the origin of the misconception. Windows itself does not correlate clipboard data with authentication.
Why this looks like credential harvesting.
Even though LSASS is not intentionally collecting clipboard data, the result can look suspicious. Seeing passwords or clipboard text inside LSASS memory feels like a security breach. The real causes are:
- shared memory regions
- text service buffers
- IME and TSF architecture
- secure desktop duplication
- clipboard buffers not being cleared
These mechanisms create the appearance of credential harvesting even though no such feature exists.
Even though LSASS is not intentionally collecting clipboard data, the result can look suspicious. Seeing passwords or clipboard text inside LSASS memory feels like a security breach. The real causes are:
- shared memory regions
- text service buffers
- IME and TSF architecture
- secure desktop duplication
- clipboard buffers not being cleared
These mechanisms create the appearance of credential harvesting even though no such feature exists.
Security implications
Even though this behavior is not intentional, it still has security consequences. Malware with administrative privileges can dump LSASS memory. If clipboard text or typed passwords are present in shared buffers, they may appear in the dump. Non-admin malware can also read ctfmon.exe memory, which may contain sensitive text. Credential Guard protects Windows authentication secrets but does not protect passwords typed into third party applications.
Even though this behavior is not intentional, it still has security consequences. Malware with administrative privileges can dump LSASS memory. If clipboard text or typed passwords are present in shared buffers, they may appear in the dump. Non-admin malware can also read ctfmon.exe memory, which may contain sensitive text. Credential Guard protects Windows authentication secrets but does not protect passwords typed into third party applications.
How to reduce clipboard leakage
While it is impossible to fully eliminate shared buffer behavior without breaking Windows input architecture, several mitigations exist:
- avoid typing passwords into applications that use standard text controls
- use password managers with secure input fields
- clear clipboard contents after use
- enable Credential Guard to protect authentication secrets
- use applications with custom secure input implementations
While it is impossible to fully eliminate shared buffer behavior without breaking Windows input architecture, several mitigations exist:
- avoid typing passwords into applications that use standard text controls
- use password managers with secure input fields
- clear clipboard contents after use
- enable Credential Guard to protect authentication secrets
- use applications with custom secure input implementations
Conclusion
Clipboard data appears in LSASS memory not because Windows is harvesting credentials, but because of how Windows handles text input, shared memory, and secure desktop transitions. Understanding these mechanisms helps security professionals correctly interpret LSASS dumps and avoid false assumptions about malicious behavior. The issue is architectural, not intentional, and can be mitigated with proper security practices.
White Byte © 2026 HEXDEREF.COM - DO NOT REPRODUCE CONTENT WITHOUT PERMISSION