Meta Description
CloudZ RAT abuses Windows Phone Link to steal credentials, SMS messages, and OTPs from synced phones through infected Windows PCs.
Introduction
Two-factor authentication is supposed to make stolen passwords less useful.
But attackers are constantly looking for ways around that protection.
A newly reported CloudZ RAT campaign shows how threat actors can abuse a trusted Windows feature, Microsoft Phone Link, to potentially intercept SMS messages, mobile notifications, and one-time passwords from a victim’s synced phone data.
The most concerning part is this:
The attacker does not need to infect the phone.
Instead, the malware compromises the Windows PC and targets the bridge between the PC and the mobile device.
Microsoft Phone Link is built into Windows 10 and Windows 11. It allows users to connect an Android device or iPhone to a Windows computer over Wi-Fi and Bluetooth. Once paired, users can view messages, receive notifications, make calls, and interact with phone content from the desktop.
That convenience creates a new risk.
If the PC is compromised, synchronized phone data may become accessible to malware running on the Windows machine.
CloudZ RAT uses a previously undocumented plugin called Pheno to inspect the Phone Link environment and collect data that may include credentials, SMS content, and OTP-related messages.
There is no confirmed CVE behind this campaign.
The issue is not that Microsoft Phone Link itself is confirmed as vulnerable through a specific software flaw. The risk comes from malware abusing legitimate synced data after the Windows endpoint is compromised.
For organizations, the message is clear:
If authentication codes are synced to a compromised endpoint, the second factor may no longer be separate.
What Happened
Cybersecurity researchers disclosed details of an intrusion involving CloudZ RAT and a custom plugin named Pheno.
CloudZ is a modular remote access trojan designed to run on infected Windows systems, communicate with a command-and-control server, collect system data, execute attacker instructions, and load additional plugins.
The newly observed Pheno plugin gives CloudZ a specific capability:
It performs reconnaissance against Microsoft Phone Link on the victim machine.
The plugin checks for active Phone Link processes and attempts to locate data associated with the Phone Link application. This includes synchronized phone data stored locally on the Windows PC.
Researchers reported that the malware may access Phone Link SQLite database files, including files matching patterns such as PhoneExperiences-*.db.
That matters because Phone Link can synchronize mobile messages and notifications to the PC.
If SMS-based authentication codes or authenticator notifications appear in the synced data, malware on the PC may be able to collect them.
The attack has reportedly been active since at least January 2026.
At the time of reporting, the activity had not been attributed to a known threat actor group.
The campaign began with an as-yet-undetermined initial access method. Once the attacker gained a foothold, they dropped a fake ConnectWise ScreenConnect executable.
That fake support-themed executable downloaded and ran a .NET loader.
The loader performed environment and hardware checks to evade detection, then deployed CloudZ RAT. Persistence was established through a scheduled task that repeatedly executed the malicious loader.
Once CloudZ was running, it established an encrypted socket connection with its command-and-control server and waited for Base64-encoded instructions.
Supported commands included capabilities for system metadata collection, shell execution, browser data theft, Phone Link reconnaissance log theft, plugin loading, plugin saving, and plugin upload.
In simple terms:
CloudZ gives attackers remote control of the infected PC.
Pheno gives them a path into synced mobile data.
Together, they create a powerful credential and OTP theft risk.
Why This Issue Is Critical
This issue is critical because it attacks the practical trust model behind SMS-based two-factor authentication.
Many organizations still rely on SMS messages or mobile notifications for login verification.
That means sensitive authentication data may appear on the user’s phone.
When Phone Link is enabled, some of that data may also appear on the user’s PC.
If the PC becomes infected, attackers may no longer need to compromise the mobile device directly.
That changes the threat model.
A user may believe their phone is safe. The phone may not have malware. The SIM card may not be hijacked. The mobile operating system may be fully patched.
But if the authentication message is synced to the infected Windows PC, the attacker may still see it.
This creates several major risks:
- Password theft can be paired with OTP theft
- SMS-based two-factor authentication can be weakened
- Authenticator notifications may be exposed
- Phone messages may leak sensitive information
- Corporate endpoints may become mobile-data collection points
- Malware can bypass the need to infect phones directly
- Legitimate Windows features can become attacker leverage
The incident is also critical because Phone Link is built into modern Windows environments.
That does not mean every organization is exposed.
But it does mean security teams should know whether Phone Link is enabled, who is using it, what data it syncs, and whether endpoint controls can detect abuse.
What Caused the Issue
The campaign was caused by malware abusing a legitimate cross-device synchronization feature after compromising a Windows endpoint.
There is no confirmed Microsoft CVE tied to the attack.
Several factors made the campaign possible.
Compromised Windows Endpoint
The attacker first gained access to the victim’s PC.
Once malware runs on the endpoint, any locally accessible data becomes a potential target.
Phone Link Data Synchronization
Microsoft Phone Link synchronizes selected phone data to the Windows machine.
This can include messages, notifications, and other mobile-linked activity.
Local Data Storage
Phone Link uses local data storage on the PC, including SQLite database files.
CloudZ and Pheno target that local data rather than attacking the phone.
Plugin-Based Malware Design
CloudZ is modular.
That means attackers can add functionality through plugins like Pheno without rebuilding the entire malware platform.
Fake Support Tool Delivery
The attack chain used a fake ConnectWise ScreenConnect executable.
This tactic abuses trust in legitimate remote support tools and IT administration workflows.
Scheduled Task Persistence
The malware established persistence through a scheduled task.
That allows it to survive reboots and continue operating.
Weak Endpoint Visibility
If security tools do not monitor Phone Link data access, suspicious scheduled tasks, fake support binaries, or unusual database reads, the attack may remain hidden.
SMS-Based MFA Dependence
If organizations rely heavily on SMS-based OTPs, any technique that exposes SMS messages can weaken authentication security.
How the Attack Chain Works
The CloudZ RAT campaign follows a staged endpoint compromise and mobile-data abuse chain.
Initial Foothold
The attacker gains access to the victim’s Windows machine through an unknown initial access method.
This could involve phishing, social engineering, fake software, remote access abuse, or another compromise path, but the confirmed reporting does not identify the initial vector.
Fake ScreenConnect Dropper
A fake ConnectWise ScreenConnect executable is deployed.
Because ScreenConnect is a legitimate remote support platform, the name may appear believable in enterprise environments.
Loader Execution
The fake executable downloads and runs a .NET loader.
The loader performs environment and hardware checks to avoid sandboxing, analysis tools, or detection environments.
Persistence Creation
An embedded PowerShell script creates a scheduled task.
That scheduled task runs the malicious .NET loader repeatedly, giving the attacker persistence.
CloudZ RAT Deployment
The loader deploys the modular CloudZ trojan.
CloudZ decrypts its embedded configuration and connects to a command-and-control server through an encrypted socket connection.
Command Handling
CloudZ waits for Base64-encoded commands from the attacker.
These commands allow the attacker to collect metadata, execute shell commands, steal browser data, load plugins, save plugins, and retrieve Phone Link reconnaissance data.
Pheno Plugin Loading
The attacker loads the Pheno plugin.
Pheno inspects the Windows machine for Microsoft Phone Link activity and writes reconnaissance data to a staging folder.
Phone Link Data Access
If Phone Link is active, the malware may identify and access local Phone Link database files.
These files may contain synchronized phone messages, notifications, and OTP-related data.
Credential and OTP Theft
The attacker can combine stolen browser credentials with potential OTPs or mobile notifications.
This may help bypass SMS-based two-factor authentication or support account takeover.
Further Exploitation
Once credentials and OTPs are captured, attackers may access email accounts, SaaS platforms, banking portals, VPNs, cloud services, or internal applications.
Why This Incident Matters for Cybersecurity
This incident matters because it shows how attackers can exploit convenience features without exploiting a traditional vulnerability.
Phone Link is designed to make users more productive.
It lets people handle phone messages and notifications directly from their desktop.
But from a security perspective, it also moves sensitive mobile data into the endpoint environment.
If that endpoint is compromised, the phone’s synced messages may no longer be protected by the phone’s security boundary.
This is important for enterprise defenders.
Many organizations treat phones and PCs as separate security domains.
They assume that an attacker who compromises a laptop still cannot see SMS messages unless they also compromise the phone.
Phone Link weakens that separation when messages and notifications are synchronized.
This becomes especially risky when SMS is used for authentication.
SMS-based MFA has already faced criticism because of SIM swapping, telecom interception, phishing, and social engineering.
CloudZ adds another concern:
MFA messages may be exposed through PC synchronization.
The incident also highlights the growing risk of legitimate tool abuse.
Attackers used a fake ScreenConnect-themed executable. They used scheduled tasks. They used encrypted C2. They used a modular plugin system. They targeted a built-in Windows feature.
None of these elements looks like a classic exploit chain by itself.
Together, they create a practical path to credential theft and MFA weakening.
Common Risks Highlighted by the Incident
This campaign highlights several risks that organizations should take seriously.
Phone Link Data Exposure
Synced phone messages and notifications may be accessible from a compromised Windows PC.
SMS OTP Theft
If OTPs arrive by SMS and are synced to the PC, malware may be able to collect them.
MFA Weakening
Stolen passwords combined with intercepted OTPs can defeat weaker two-factor authentication methods.
Remote Access Trojan Risk
CloudZ gives attackers remote control, data theft capability, command execution, and plugin-based expansion.
Fake Support Tool Abuse
A fake ScreenConnect executable shows how attackers abuse trusted IT support branding.
Scheduled Task Persistence
Malicious scheduled tasks can keep malware running after reboot.
Browser Credential Theft
CloudZ supports browser data exfiltration, which may expose saved passwords, cookies, sessions, and autofill data.
Plugin-Based Expansion
Modular malware can quickly add new capabilities based on attacker objectives.
Endpoint-Monitored Data Blind Spots
Security teams may not monitor legitimate application databases such as Phone Link storage.
Potential Impact on Organizations
The potential impact can be significant, especially in environments that rely on SMS-based MFA or allow Phone Link on corporate devices.
Organizations may face:
- Credential theft
- OTP interception
- Microsoft 365 account takeover
- VPN compromise
- SaaS account compromise
- Banking or financial portal access
- Cloud console compromise
- Browser credential theft
- Session cookie theft
- Internal application access
- Data exfiltration
- Remote command execution
- Persistent endpoint access
- Wider malware deployment
- Ransomware preparation
- Incident response disruption
- Regulatory exposure
The impact is highest for users with privileged access.
This includes:
- IT administrators
- Finance teams
- Executives
- Developers
- Security analysts
- HR staff
- Legal teams
- Cloud administrators
- Helpdesk staff
If these users sync phone messages to Windows devices, and those devices are compromised, attackers may gain access to both credentials and verification codes.
That combination can turn one infected endpoint into a broader identity compromise.
What Organisations Should Do Now
Organizations should review whether Microsoft Phone Link is appropriate for corporate environments.
Recommended actions include:
- Inventory Windows endpoints with Phone Link enabled
- Determine whether Phone Link is allowed by policy
- Disable Phone Link where it is not required
- Restrict Phone Link use for privileged users
- Move away from SMS-based MFA where possible
- Adopt phishing-resistant MFA such as FIDO2 security keys or passkeys
- Monitor for suspicious access to Phone Link database files
- Monitor for access by unusual processes
- Search for fake ScreenConnect executables
- Hunt for suspicious scheduled tasks
- Monitor staging
- Alert on unknown .NET loaders
- Review PowerShell-created scheduled tasks
- Monitor for CloudZ-related behavior
- Review browser credential theft indicators
- Revoke sessions after suspected credential theft
- Rotate passwords where compromise is suspected
- Review recent MFA usage and login activity
- Add Phone Link abuse to endpoint threat hunting playbooks
Organizations should also review employee guidance.
Users should understand that syncing phone messages to a corporate PC may expose sensitive content if the PC is compromised.
For high-risk roles, Phone Link should be disabled unless there is a clear business need and strong monitoring.
Detection and Monitoring Strategies
Detection should focus on endpoint behavior, Phone Link data access, persistence, and credential theft.
Security teams should monitor for:
- Execution of fake ScreenConnect binaries
- Unexpected ConnectWise ScreenConnect-themed files
- Unknown .NET loaders
- PowerShell creating scheduled tasks
- Scheduled tasks running from unusual paths
- Non-Phone Link processes reading Phone Link data
- Plugin files saved to disk by unknown processes
- Encrypted outbound socket connections
- Base64-encoded command patterns
- Browser credential store access
- Browser cookie database access
- Unusual access to SMS or notification data
- Unknown processes enumerating Phone Link processes
- Endpoint telemetry showing Phone Link recon
- CloudZ command behavior such as shell execution or metadata collection
- C2 communication from unknown .NET binaries
Security teams should correlate:
- EDR telemetry
- Windows event logs
- Sysmon logs
- PowerShell logs
- Scheduled task logs
- Defender alerts
- Proxy logs
- DNS logs
- Identity provider logs
- Microsoft 365 sign-in logs
- VPN logs
- SaaS application logs
If OTP theft is suspected, defenders should review authentication activity carefully.
Important questions include:
- Did the user receive SMS OTPs during the compromise window?
- Were there logins shortly after OTP arrival?
- Were logins from unusual devices or locations?
- Were sessions created from suspicious IP addresses?
- Were MFA prompts satisfied unexpectedly?
- Were new devices registered?
- Were tokens or sessions reused?
Detection should not focus only on the malware.
The real objective is account takeover.
Security teams must investigate the identity layer after endpoint compromise.
The Role of Incident Response Planning
CloudZ and Phone Link abuse require incident response teams to think beyond the infected endpoint.
If malware may have accessed synced OTPs, the incident becomes an identity security event.
A strong response plan should include:
- Endpoint isolation
- Memory and disk evidence preservation
- Malware removal or full reimaging
- Scheduled task review
- Phone Link data access review
- Browser credential exposure analysis
- Password resets
- Session revocation
- MFA method review
- SMS-based OTP exposure assessment
- SaaS and VPN login review
- Cloud account audit
- User communication
- Legal and compliance escalation if sensitive data was accessed
- Post-incident MFA hardening
Responders should ask:
- Was Phone Link enabled?
- Was a phone paired with the PC?
- Were SMS messages or notifications synced?
- Did the malware access Phone Link databases?
- Were OTPs received during the compromise?
- Were credentials stolen from browsers?
- Were accounts accessed after OTP receipt?
- Were new sessions created?
- Were MFA settings changed?
- Were cloud or SaaS accounts accessed?
- Was data exfiltrated?
If the answer to these questions is unclear, defenders should assume higher risk.
A compromised endpoint with synced OTPs should not be treated as a simple malware cleanup.
It may require identity-wide containment.
The Role of Penetration Testing
Penetration testing can help organizations understand whether convenience features such as Phone Link create unexpected attack paths.
A strong assessment should evaluate more than internet-facing systems.
For CloudZ-style risk, penetration testing can examine:
- Whether Phone Link is enabled on corporate devices
- Whether privileged users are allowed to sync phone data
- Whether SMS-based MFA is still used
- Whether endpoint controls detect Phone Link data access
- Whether scheduled task persistence is detected
- Whether fake support tools can execute
- Whether browser credentials are protected
- Whether EDR alerts on suspicious SQLite database access
- Whether malware can access OTP-related data
- Whether session revocation procedures work quickly
- Whether identity logs detect post-compromise login activity
A red team exercise can safely simulate the attack path:
- Compromise a test endpoint under controlled conditions
- Check whether Phone Link is enabled
- Attempt safe access to simulated Phone Link data
- Test detection for suspicious database reads
- Simulate credential theft without exposing real secrets
- Trigger controlled identity alerts
- Measure SOC response time
- Validate session revocation and MFA reset procedures
This type of testing helps answer a practical question:
If an attacker compromises a Windows endpoint, can they also capture the user’s second factor?
That is the question organizations must answer before real attackers do.
Protection and Mitigation Measures
Organizations should apply layered protections across endpoint security, identity controls, user policy, and mobile synchronization.
Disable Phone Link Where Not Needed
If Phone Link has no business purpose, disable it on managed devices through policy.
Reducing unnecessary sync features reduces attack surface.
Restrict Phone Link for Privileged Users
Administrators, executives, finance users, developers, and security staff should avoid syncing SMS and notifications to corporate endpoints unless absolutely necessary.
Move Away From SMS-Based MFA
SMS OTPs are vulnerable to multiple attack paths.
Use phishing-resistant MFA such as FIDO2 security keys, passkeys, or certificate-based authentication.
Monitor Phone Link Data Access
Alert when non-standard processes access Phone Link databases or related local storage.
Harden Endpoint Controls
Use EDR, application control, PowerShell logging, scheduled task monitoring, and least privilege to reduce malware execution risk.
Block Fake Remote Support Tools
Monitor for suspicious ScreenConnect, AnyDesk, Quick Assist, and other remote support-themed binaries.
Protect Browser Credentials
Disable browser password storage for corporate accounts where possible.
Use enterprise password managers with strong controls.
Revoke Sessions After Endpoint Compromise
If credentials or OTPs may have been exposed, revoke active sessions immediately.
Password resets alone are not enough.
Review MFA Events
Investigate MFA approvals, OTP use, new device registrations, and sign-ins during the compromise window.
Educate Users
Employees should understand the risk of syncing phone messages, especially OTPs, to corporate endpoints.
Threat Hunt Regularly
Search for suspicious scheduled tasks, Phone Link database access, unknown .NET loaders, and plugin staging directories.
Test Controls
Include Phone Link abuse, OTP exposure, and endpoint-to-identity compromise paths in penetration testing and incident response exercises.
Key Takeaway
CloudZ RAT’s abuse of Microsoft Phone Link shows how attackers can weaken two-factor authentication without compromising the phone itself.
By infecting the Windows PC and using the Pheno plugin to inspect Phone Link activity, attackers may access synced SMS messages, mobile notifications, and OTP-related data stored on the endpoint.
There is no confirmed CVE behind this campaign.
The weakness is the trust created by cross-device synchronization.
If sensitive mobile messages are mirrored to a compromised PC, the attacker may gain access to both credentials and verification codes from one infected endpoint.
Organizations should review Phone Link usage, restrict it where unnecessary, monitor local Phone Link database access, move away from SMS-based MFA, deploy phishing-resistant authentication, and include endpoint-to-identity attack paths in penetration testing.
The message is simple:
A second factor is only strong if it stays separate from the compromised device.
