I found malware on a client’s computer that was quietly working out whether they had a QuickBooks account, and which financial sites they logged into. It had been doing that for six months. Their antivirus ran the entire time, up to date, reporting no threats, and never flagged a thing.

They hadn’t called me about any of that. They called me because windows kept opening on the laptop by themselves — File Explorer, then the Phone Link app, over and over. I drove over thinking Windows was being Windows.

The popup turned out to be bait. Someone put it there on purpose, and it was the only thing anyone was ever meant to see. What it was actually for took me longer to work out, and it’s the part of this I’d least have guessed.

Details are changed or left out where they’d identify the client. The technical content is exactly as I found it.

The popup was bait

The thing generating those windows was a 22 KB program sitting in a folder named to look like a Microsoft component. It carried metadata claiming it was published by Microsoft Corporation, part of “Windows Device Setup.”

Two problems. First, it wasn’t signed — real Microsoft binaries are cryptographically signed, and this one had the branding without the signature. And the version number it claimed was a Windows 11 build string, on a Windows 10 machine. Someone copied the metadata from the wrong template.

Its entire job was to repeatedly launch Phone Link so the owner would see windows opening and do something about it.

It was created forty-eight seconds after an operator connected to the machine.

Somebody logged in and left it behind on their way out. Which means the symptom that got me called was manufactured. It wasn’t a malfunction. It was the only visible part of an operation that had been careful to be invisible for six months. It ended up being why it got caught, too.

What was actually on it

Working backwards through the filesystem, the earliest trace was about six and a half months before the call.

In that time the machine had accumulated:

The implant defended itself. Its services had permissions rewritten so that even a full Administrator got “Access is denied” trying to stop them. When I disabled tasks, other tasks turned them back on. Two services had to be disabled by writing to the registry directly, because the normal way through was closed.

Why nothing caught it

This is the part I’d want a business owner to take away:

Add/Remove Programs showed nothing. Every single one of those nine installations had a flag written into its registry entry marking it as a system component, which hides it from the Programs and Features list. Nine remote-access tools installed, and the list where you’d go to look showed none of them. If a technician had checked there and reported the machine clean, they’d have been looking in the one place guaranteed to be empty. No one would have been wiser.

I don’t have to infer that this was deliberate, because the author wrote it down. The installer script is commented throughout in Russian — mundane developer notes, mostly: “storage folder,” “downloading file,” “hash comparison.” And then, immediately above the relevant block:

PowerShell скрипт для скрытия программ — “PowerShell script for hiding programs”

Underneath that comment sits the code it describes:

if($n -like '*Remote Access*' -or
   $n -like 'ScreenConnect Client (*)' -or
   $n -like '*Tactical RMM Agent*')
   { sp $_.pspath -Name 'SystemComponent' -Value 1 }

Four lines. It walks the list of installed programs, matches anything whose name looks like remote-access software, and sets one registry value that makes Windows stop displaying it. That’s the whole trick. They installed remote access software to the client’s computer and hid it.

The antivirus had never fired. Not once, in the entire history of the product on that machine, because folders had been added to its exclusion list. Windows Defender was running, up to date, reporting no threats, and had been instructed not to look at the exact places it should have.

The security event log had been wiped a few months in. There’s a single event recording that a clear happened, and then nothing before it.

So: the antivirus said clean, the installed-programs list said clean, and the logs said nothing at all. Three independent checks, three all-clears, one machine under someone else’s control for half a year.

If you take one thing from this post, let it be that. “My antivirus hasn’t flagged anything” is not evidence.

Who they were

I can’t tell you who. I can tell you what kind of operation it was, and that turned out to be the more useful question.

The remote-access installations carried operator-supplied labels, sitting in plain text in their service configuration. Here they are, verbatim:

Transfer old bots 13may
ALL_RES1405
RESTORED2605
RESTORED 0207
RESTORED 3006
RES2 0107
RES3 0107
FIXED0307
FROMRQ
NEW

Read those for what they are: batch notes. Dates jammed onto the ends — 13may, 2605, 0207, 3006, 0107, 0307. RESTORED over and over, because access kept getting removed somewhere and kept getting put back. FIXED. NEW. FROMRQ.

And then Transfer old bots 13may.

To whoever typed that label, this laptop — a real person’s actual computer, with their tax returns sitting in the Downloads folder — was stock being moved between batches on a Tuesday in May.

The rest fits the same shape. Recovered logs show a “ScreenConnect Migration Script (v2)” run three times in a single week, moving machines between control panels. The reconnaissance scripts stamp every report they send with a Panel SC: field naming which panel a given machine belongs to. Someone is running an inventory system.

Stock control, on an unsuspecting client’s personal computer.

And the hosts file — the file Windows uses to resolve names before it asks the internet — had been edited to blackhole eleven rival remote-access services, under a comment marking it a custom blocklist.

They weren’t just breaking in. They were also keeping other criminals out. Access itself was the product, and an exclusive one is worth more.

As for where they are: the Russian comments above are the strongest signal, and they’re a signal about the person who wrote the script, which isn’t necessarily the person who used it. Tools get shared and sold. Treat it as indication, not identification.

One last texture. The payloads came from throwaway Google Cloud Storage buckets with auto-generated names — fresh-heron-9956, open-creek-4191, neat-robin-1027. Different buckets, same pattern, across months. Reputable hosting, disposable containers, nothing that looks wrong in a URL bar at a glance.

How it got in

Six months of this started with an email.

It was a debt-collection notice on the letterhead of a major law firm, the kind of name you’d recognize, saying an account was overdue and had to be settled immediately. Urgent, official, faintly threatening. The exact register that makes a person act before they think.

Here is why it worked.

It passed every check your email provider makes. The three technical stamps meant to catch forged senders — the ones your IT person will name if you ask, SPF, DKIM, DMARC — all came back valid. Not bypassed. Valid. Because nothing was forged. It was a genuine Google Drive share notification, sent by Google’s own servers. The attackers opened throwaway Google accounts, uploaded their fake letter to Drive, and clicked Drive’s ordinary “share” button. Your provider sees a real message from Google and waves it through, because it is one.

The letter was a picture. The attached PDF had no text in it at all — just a single image of a letterhead with a button reading “Download E-Sign.” A scanner that reads words looking for trouble found no words. A human saw a crisp, official-looking notice from a firm they’d heard of.

The only tell lived in the details. The sender’s name used lookalike letters — a Cyrillic “а” in place of the ordinary one, invisible unless you’re hunting for it.

Click the button and it pulled a file from a Google cloud address — reputable-looking again — and that file was the first foothold.

I could reconstruct all of this because the same operation had tried this mailbox several times over the preceding months, each attempt wearing a different famous firm’s name. Most never landed. One did.

The lesson is an uncomfortable one: the email that got through was, in every technical sense, legitimate. Every automated defense in the stack passed it, because there was nothing there to fail.

What the popup was actually for

For most of this I assumed the popup was a distraction. Then I looked into what it was launching, and the answer turned out to be documented.

Phone Link is the Microsoft feature that pairs your phone to your PC. Among other things, it puts your text messages on the computer’s screen. Now recall what everything else on that machine was doing: profiling which financial accounts the owner had, and under what identity. Work that chain forward and it dead-ends in the same place every time — a two-factor code, sent by SMS.

A paired phone puts those codes on a screen the intruder already controls. No exploit against the phone. No zero-day. iOS stays sandboxed and perfectly intact; it just starts reading its texts aloud to a machine somebody else owns.

Cisco Talos published research in 2026 on malware they call CloudZ, with a plugin named Pheno, doing exactly this: finding Phone Link on a compromised PC and reading its message store for one-time passcodes. Their campaign was delivered as a fake ScreenConnect update, used a Rust loader, persisted through scheduled tasks, and has been active since at least January 2026.

I’ll let you compare that against the machine I was standing in front of: ScreenConnect, a Rust implant, scheduled-task persistence, earliest artefact 21 January 2026.

Talos documents the malware finding Phone Link active and reading its message store. What their write-up doesn’t say is how the phone got paired in the first place. On this machine, it never did — no pairing ever completed, so there was nothing to read. What there was instead was a program whose only job was to launch Phone Link over and over, dressed up as Microsoft Corporation · Windows Device Setup · PhoneLinkSyncNotice. It was unsigned, so it was never going to fool anyone who checked.

So this looks like the step before the one they documented. Not stealing from a paired phone — getting you to pair it.

I didn’t have to keep guessing, in the end. Days later I got hold of the installer for that popup — the actual program that put it on the machine — and two things in it settle the question.

Before it installs anything, it checks whether the machine even has Bluetooth, and whether Phone Link is present. If either is missing, it quits without installing. A tool built only to annoy someone has no reason to care about Bluetooth. A tool built to push you toward pairing a phone cares about nothing else — because with no Bluetooth and no Phone Link, there is no pairing to push you toward.

And then it does one more thing. It disables Task Manager — the single tool a frustrated person reaches for to force-kill a program that won’t close. Switched off, so you can’t. You’re left with a window that reopens every time you dismiss it, no way to end it, and a button promising to make it all stop if you’ll just connect your phone.

That isn’t a nuisance. That’s a room with one door, and they built the door.

You already know it works, because it nearly worked. The owner dismissed that window somewhere around sixty or seventy times, and by the end was ready to just connect the phone and make it stop. So was I. That is the same mechanic as MFA fatigue — spam someone with prompts until they approve one for the sake of peace — pointed at pairing instead of at approval. It requires no exploit and no cleverness. It just requires you to be more patient than a loop (which nobody is).

What I did about it

Two phases, and doing them in that order is most of the job.

Phase one: contain without deleting anything. For the first couple of hours I removed nothing at all. Not out of caution about breaking the machine — because the moment you delete evidence, you can no longer answer the question that actually matters afterward, which is what did they reach? Anything binned early is something nobody can examine later. So everything hostile got stopped, disabled, blocked, and left sitting exactly where it was while I worked out the shape of it.

The order:

  1. Restore point first, before touching anything.
  2. Capture the live network connections — before cutting access, because the moment you firewall them off, you lose the picture of what the machine was talking to.
  3. Kill the decoy, and the eighty-seven Explorer processes it had spawned, without killing the desktop itself.
  4. Disable the scheduled tasks that would resurrect everything.
  5. Then, and only then, start terminating.

Step five had a trap. Setting a Windows service to “Disabled” and killing its process doesn’t necessarily stop it, because a service can have recovery actions configured — instructions for what Windows should do if it crashes. These were set to restart after five seconds. Windows can’t tell the difference between a crash and you killing it, so it dutifully brought them back, disabled or not. You have to clear the recovery actions first, then terminate. Otherwise you’re playing whack-a-mole (and losing).

Phase two: removal. Once the picture was complete and the evidence was preserved, it all came out. Every implant component, all nine remote-access clients, the hidden administrator account, the scheduled tasks, the WMI persistence, the startup entries, the shutdown-interception scripts, the antivirus exclusions.

Including the part that doesn’t normally come off. That login-process registration — the one that survives an uninstall, the one this machine had nine of, two pointing at software already long gone — I wiped and reset to what it’s supposed to be. That value lives in a registry format where a careless write can leave a machine unable to log in at all, so it gets backed up first and written deliberately rather than casually. But it gets written. Leaving it means leaving the intruder’s hooks registered inside the login process of a computer you’re about to tell someone is safe to use.

The part that should worry you more than the laptop

The laptop was never the point. The question is what it could reach.

It had saved credentials for other machines on the business network — the kind that let you connect without needing to type a password. It had a VPN client into that network. It had browser password stores, work email, and personal tax documents in the Downloads folder.

Assume all of it is known. Somebody had system-level control for half a year; anything the user could read, they could read.

What I’d tell a business owner

If any of that is uncomfortably familiar, it’s worth an hour of somebody looking properly. Most of these checks take minutes once you know where they hide — and the whole reason this one ran for six months is that nobody looked anywhere except the three places designed to come back empty.