How attackers read your MFA codes from a Windows database without ever touching your phone

The Context

Microsoft Phone Link (previously called "Your Phone") is a built-in Windows 10 and 11 feature that mirrors your smartphone's SMS messages, call logs, and app notifications to your desktop. It is installed by default and requires no additional software purchase. For many employees, it is simply on, because Windows enabled it and no one turned it off.

When Phone Link is active and a phone is paired, the application maintains a local SQLite database on the Windows machine. The Phone Link database, named PhoneExperiences-*.db, stores the synced content from the phone, including every SMS message that arrives, including authentication codes.

The CloudZ campaign, disclosed by Cisco Talos researchers Alex Karkins and Chetan Raghuprasad on May 5, 2026, targeted this database as the final objective of a four-phase attack chain that had been running undetected for at least four months.

The Attack, Phase by Phase

Phase 1: Fake Software Update Delivers the Foothold

The attack begins with a file disguised as a ConnectWise ScreenConnect update — a widely used remote support tool, so an "update" prompt is plausible to most employees. The file, named systemupdates.exe or Windows-interactive-update.exe, is a Rust-compiled dropper.

Once executed, the dropper decrypts and drops a second malicious file into C:\ProgramData\Microsoft\windosDoc\, disguised as a text file named update.txt or msupdate.txt. A hidden PowerShell script then creates a scheduled task named SystemWindowsApis that runs at every system startup under the SYSTEM account. The task executes the malicious loader using regasm.exe, a legitimate Windows binary normally used for registering software components — a living-off-the-land technique designed to avoid triggering security alerts.

Phase 2: The Loader Checks Whether It's Being Watched

Before deploying the main malware, the loader runs evasion checks. It tests whether the system responds to a timing trick (sandboxes often manipulate time artificially). It scans running processes for common security analysis tools: Wireshark, Fiddler, Procmon, and Sysmon. It also searches for strings in the system path and hostname that suggest a virtual machine.

If any check fails, the loader stops. If all checks pass, it deploys CloudZ RAT directly into memory — the malware never writes its most sensitive components to disk, where security tools are more likely to find them.

Phase 3: Pheno Plugin Scouts for Phone Link

With CloudZ running, the attacker instructs it to download the Pheno plugin. CloudZ tries three download methods in sequence — curl, then PowerShell's Invoke-WebRequest, then bitsadmin — ensuring delivery even if one method is blocked by security policy.

Pheno scans every running process for three names tied to Phone Link: YourPhone, PhoneExperienceHost, and Link to Windows. If found, it logs the process details to a staging file. It then checks its own output for the word proxy, which indicates Phone Link is actively relaying data between the PC and the paired phone. When confirmed, Pheno writes Maybe connected to its output file. CloudZ reads that file and sends the result to the attacker's command server.

Phase 4: MFA Codes Read from the Local Database

With an active Phone Link session confirmed, the attacker has everything needed. Phone Link has already been writing every incoming SMS to the local PhoneExperiences-*.db database — including six-digit codes from banks, email providers, corporate VPNs, and any other service using SMS-based two-factor authentication. Push notification content from authenticator apps may also appear as readable text.

CloudZ exfiltrates the Pheno staging data to the command server. The attacker retrieves current or recent OTP codes. The victim's phone was never touched. No SIM swap occurred. No interception happened in transit. The codes were already on the Windows machine, waiting.

What Made This Possible

1. Phone Link creates a local copy of mobile data on the PC. "Synced to your desktop" means stored in a file on your Windows machine — accessible to any process running with sufficient privileges, including malware.

2. MFA threat models assumed the phone was the hard target. Organizations invested in mobile device management and SIM-swap protections. None of those controls apply to a file sitting on a Windows desktop. The attacker found the gap between two security programs each doing their job correctly.

3. Phone Link is on by default and rarely audited. Because it ships with Windows and requires no installation step, it often exists where no one made a deliberate decision to enable it. Features that are on by default tend to fall outside regular security reviews.

Every convenience feature that bridges device boundaries also bridges security boundaries.

What Should Have Stopped This

• Disable or restrict Phone Link via Group Policy. Organizations without a business need for Phone Link can block it entirely. If the application is not running, the database is not being populated, and Pheno has nothing to find.
• Replace SMS-based MFA with phishing-resistant alternatives. Hardware security keys (FIDO2) and passkeys generate credentials that never appear as readable codes anywhere. An attacker reading a local database finds nothing useful.
• Monitor for regasm.exe running with unusual arguments. Security teams can configure alerts for regasm.exe invocations that do not match expected software registration patterns. Dark Reading confirmed this detection method with Cisco Talos.
• Audit scheduled tasks for unexpected entries. The SystemWindowsApis scheduled task is the persistence mechanism. Regular audits of tasks running under the SYSTEM account can surface this class of attack before it reaches the data collection phase.

The Takeaway

The CloudZ campaign is a structural warning about how security models age. When SMS-based two-factor authentication became widespread, the threat model assumed an attacker would need to intercept the SMS in transit or compromise the phone itself. Organizations treated the phone as a trusted second factor and built defenses accordingly.

Phone Link created a third location where SMS content exists: a local file on the Windows PC. The threat model never accounted for that location, because the feature did not exist when the model was built.

This is the same class of failure as the Stryker Intune wipe: a trusted, built-in platform feature weaponized against the organization it was built to serve. The meta-pattern is identical — security boundaries collapse when a trusted tool aggregates data across a boundary that defenders assumed was hard to cross.

Cisco Talos Head of Outreach Nick Biasini put it directly: "MFA bypass is becoming a bigger and bigger part of the compromise chain." The Pheno plugin represents a new method in that category — one that requires no mobile compromise at all.

Pattern to remember: A second authentication factor is only as secure as the least-protected device where its codes are stored.

What changed: Attackers can now bypass SMS-based MFA entirely from the Windows endpoint, without touching the phone, by reading codes from a sync database that the operating system itself created and populated.

The Technical Mechanism

The CloudZ campaign uses a four-stage chain: a Rust-compiled dropper, a .NET loader with anti-analysis logic, the CloudZ RAT itself, and the Pheno plugin as a modular capability extension.

Stage 1: Rust dropper (rustextractor.pdb). Compiled January 1, 2026, as a 64-bit PE. Delivered under filenames systemupdates.exe or Windows-interactive-update.exe. Decrypts and drops an embedded .NET loader to C:\ProgramData\Microsoft\windosDoc\ as update.txt or msupdate.txt. Executes an embedded PowerShell script that creates a scheduled task named SystemWindowsApis configured to run at system startup under the SYSTEM account, invoking the loader via regasm.exe (a LOLBin technique using the .NET COM registration utility).

Stage 2: .NET loader anti-analysis gauntlet. Before deploying CloudZ, the loader runs three evasion checks: (1) a timing-based sleep test to detect sandbox time acceleration, (2) process enumeration for Wireshark, Fiddler, Procmon, and Sysmon, and (3) string searches in the system path and hostname for VM/sandbox indicators. If any check triggers, execution halts. If all pass, CloudZ is reflectively loaded into memory.

Stage 3: CloudZ RAT. Compiled January 13, 2026, obfuscated with ConfuserEx. Key evasion technique: uses System.Reflection.Emit.DynamicMethod combined with ILGenerator to generate the most sensitive functions as in-memory IL (Intermediate Language) at runtime, defeating static analysis and most decompilers. Also queries the _ENABLE_PROFILING environment variable via GetEnvironmentVariable Windows API to detect attached .NET profilers or debuggers. Decrypts an embedded configuration blob at runtime, retrieves C2 IP and port from attacker-controlled staging URLs and Pastebin pages under account HELLOHIALL, and establishes an encrypted TCP socket connection. Rotates among three hardcoded browser-style user-agent strings (Firefox, Safari, Chrome) with anti-caching HTTP headers to blend C2 traffic. Full command set includes browser credential theft, file management, shell execution, screen recording, and plugin lifecycle management.

Stage 4: Pheno plugin. Downloaded via three-method fallback (curl → Invoke-WebRequest → bitsadmin). Scans running processes for YourPhone, PhoneExperienceHost, and Link to Windows. Logs matching PIDs and file paths to a staging file named after the victim hostname. Performs secondary check reading its own output for the case-insensitive string proxy to confirm an active Phone Link relay session. Writes Maybe connected to output when confirmed. CloudZ reads the staging file and exfiltrates contents to C2. With an active session confirmed, the attacker can access PhoneExperiences-*.db, the local SQLite database populated by Phone Link, containing synchronized SMS messages (including OTP codes), call logs, and app notification content (including authenticator push notification text).

CVE and Advisories

No CVE identifier has been assigned to this campaign as of the disclosure date. The attack does not exploit a software vulnerability in Phone Link; it abuses the application's intended functionality. Cisco Talos has not filed a CVE, and no vendor patch is applicable to the core technique.

Indicators of compromise, ClamAV signatures, and Snort rules were published by Cisco Talos on May 5, 2026, available at the Cisco Talos GitHub IOC repository.

MITRE ATT&CK Mapping

Indicators of Compromise

Detection is complicated by the in-memory execution model and LOLBin usage. The most reliable behavioral indicators are:

• regasm.exe executing with arguments that do not correspond to legitimate COM registration activity
• Scheduled task named SystemWindowsApis present under SYSTEM account
• Files named update.txt or msupdate.txt in C:\ProgramData\Microsoft\windosDoc\
• Outbound HTTP requests with rotating browser user-agent strings to Pastebin URLs associated with account HELLOHIALL
• Process access events targeting YourPhone.exe, PhoneExperienceHost.exe, or Link to Windows from unexpected parent processes
• File read events against PhoneExperiences-*.db from processes other than Phone Link itself

Cisco Talos confirmed that staging Pastebin URLs remained active at time of publication, indicating the campaign was ongoing. Full file hashes, domains, and IP addresses are published in the Cisco Talos IOC repository.

Attribution

Unattributed. Cisco Talos explicitly states the activity has not been linked to any known threat actor, nation-state group, or previously identified tooling. The Pastebin account HELLOHIALL and Cloudflare Workers infrastructure used for staging are the primary disclosed infrastructure identifiers. No independent attribution assessments from other threat intelligence organizations had been published as of May 7, 2026.

Primary Sources