CloudZ RAT & Windows Phone Link: Abusing Native Features for OTP Theft
Has anyone else been digging into the recent reporting on CloudZ RAT? It looks like the threat actors behind it have deployed a previously undocumented plugin called 'Pheno' that specifically targets the Windows Phone Link feature (YourPhone.exe).
While CloudZ itself is a known commodity, leveraging a legitimate OS syncing mechanism to facilitate credential and OTP theft is a significant evolution. The functionality suggests the malware is abusing the trusted bridge created by Phone Link to intercept SMS one-time passwords directly from the desktop, effectively bypassing traditional SMS-forwarding detection.
We need to update our detection baselines. We're hunting for standard RAT C2 traffic, but we also need to look for anomalies around the Phone Link process.
Here is a KQL query to start hunting for suspicious process injection or unexpected parent processes interacting with Phone Link:
DeviceProcessEvents
| where Timestamp > ago(7d)
| where FileName in~ ('YourPhone.exe', 'PhoneLink.exe')
| where InitiatingProcessFileName != 'explorer.exe'
| where InitiatingProcessFileName !in~ ('ShellExperienceHost.exe', 'SearchApp.exe')
| project DeviceName, FileName, InitiatingProcessFileName, AccountName, SHA256
The report indicates this is primarily aimed at credential harvesting. Are you seeing this in your environments? How is everyone handling Phone Link in their corporate baselines? Are you hard-blocking via GPO/Intune, or just relying on behavioral analysis?
We actually started blocking YourPhone.exe via AppLocker a few months ago when we noticed excessive network usage from it unrelated to user activity. It’s a great feature for personal use, but in an enterprise, the risk surface is too high. We used this GPO path to disable it entirely:
Computer Configuration -> Administrative Templates -> Windows Components -> Mobile OS -> 'Allow Phone-Link' -> Disabled
If you haven't killed it yet, I'd highly recommend it. The convenience isn't worth the OTP theft risk.
Good catch on the parent process check. We usually ignore YourPhone.exe because of false positives, but this makes a strong case for tighter tuning. We also found that CloudZ often leaves specific mutexes. You might want to cross-reference your process creation data with known CloudZ IoCs. The Pheno plugin specifically hooks into browser credential stores too, so checking for unexpected access to the User's AppData\Local\Google\Chrome\User Data\Default\Login Data is another angle.
From an offensive perspective, abusing Phone Link is brilliant because it bypasses the need for a separate SMS-forwarding malware on the phone itself. The user does the heavy lifting by pairing the device. I suspect the initial access vector here is still phishing to get the RAT installed, but once inside, using a native OS feature for data exfiltration makes detection significantly harder compared to a bespoke C2 channel.
To expand on detection, monitoring for unusual child processes is key since the malware needs to invoke commands through the sync bridge. Legitimate usage rarely spawns shells, so catching YourPhone.exe calling cmd or powershell is effective. Here’s a quick KQL rule to filter out the noise:
DeviceProcessEvents
| where InitiatingProcessFileName =~ "YourPhone.exe"
| where ProcessFileName !in ("YourPhone.exe", "explorer.exe", "RuntimeBroker.exe")
This reinforces why SMS is the weakest MFA factor. If Phone Link is strictly required, consider restricting it to specific device IDs. In the interim, you can disable the feature via registry on high-risk endpoints while your team migrates users to FIDO2 or Push notifications:
New-Item -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\YourPhone" -Force
Set-ItemProperty -Path "HKLM:\SOFTWARE\Policies\Microsoft\Windows\YourPhone" -Name "AllowYourPhone" -Value 0
From an IAM standpoint, we should consider managing this attack surface through MDM rather than just local registry edits. If you use Intune, deploying a Win32 app wrapper that removes the 'Your Phone' package is far more scalable for high-privilege user groups.
Here is the PowerShell command you can package for removal:
Get-AppxPackage -AllUsers *YourPhone* | Remove-AppxPackage
This ensures the bridge is completely removed on managed devices, preventing any plugin interaction.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access