RMM Delivery

Fake Patient Portal Messages Install Remote Access Tools in Healthcare

5 min read

A fake patient portal message sent a healthcare employee through three redirects to a four-day-old domain that public scanners rated safe, where one download installed a signed remote access tool that hands the attacker the keyboard.

A fake patient portal message sent a healthcare employee through three redirects to a four-day-old domain that public scanners rated safe, where one download installed a signed remote access tool that hands the attacker the keyboard.

Threat snapshot

Attack Type

RMM Delivery

Attack Vector

Trusted Platform Abuse

Attack Goal

Malware Install

Impersonated Brand

Patient Portal

Published

What is a remote access tool phishing attack?

A remote access tool phishing attack tricks someone into installing legitimate remote monitoring and management (RMM) software that the attacker controls. Nothing in the email is malware. Once the person runs the installer, the attacker has a live session on the machine, through software that IT teams and security tools already trust.

At a glance

  • Seen by Ocean: October 29, 2026

  • Industry: Healthcare and life sciences

  • Email platform: Microsoft 365

  • Attack type: Phishing that installs a legitimate remote monitoring and management (RMM) tool, giving the attacker hands-on-keyboard access

  • Lure: "You have a new Document" from a widely used patient portal

  • Delivery: URL shortener, three redirects, a deep-link service, then a four-day-old domain that serves the installer

  • Ocean verdict: Malicious, high severity. Indicators: Suspicious link, Obfuscation technique, Impersonation attempt

What happened

On October 29, an employee at a healthcare and life sciences organization received an email that looked like a patient portal notification. The subject read "You have a new Document ID RE8200." The body said a new document was waiting and told the reader to "allow the file viewer to run after downloading" to read the message. A green "View My Document" button sat under it, followed by a line in a different font: "Document is accessible from Desktop/PC only."

The sender was a .site domain with no tie to the portal. The only warning in the inbox was the standard first-contact banner: "You don't often get email from…"

The email as delivered. Recipient and portal brand redacted.

Three lines in that email do the attacker's work. "Download" and "allow the file viewer to run" prepare the reader to click through a security prompt. "Desktop/PC only" moves the reader off a phone and onto a Windows machine, where an installer can run. A real patient portal shows messages inside the portal. It never asks you to download and run a viewer.

Where the link went

The button pointed to a URL shortener. That link bounced through three redirects, passed through a deep-link service that marketing teams use for app links, and ended on a domain registered four days earlier. Its TLS certificate was issued on October 26.

Ocean's link analysis: original link, redirect chain and final page.

The final page served a file named like a routine IT support client: a signed installer for a legitimate remote access tool. One double-click installs it, already configured to connect to the attacker's server.

The file the final page offers to save.

Why the attacker wants a remote access tool

Remote monitoring and management tools are what IT teams use to fix laptops from a distance. They are signed, trusted software, so antivirus, EDR and application allowlists usually treat them as normal IT tools. Their traffic goes to the vendor's own cloud over standard encrypted ports, so network controls rarely flag it.

Once the client is installed, the attacker has a live, persistent session on the machine. The tool's own features do the rest: file transfer, a remote shell, unattended access. With those, an attacker can:

  • Harvest browser sessions and saved passwords

  • Steal session tokens that skip MFA

  • Stage infostealers or ransomware loaders

Many organizations already run one remote access tool, so a second, unsanctioned one blends in. Attackers also rotate between remote access brands to get past blocklists aimed at any single one.

How it got past the checks

  • No attachment, no known-bad link. The email carried a shortened link and nothing else to scan.

  • Borrowed infrastructure. The shortener and the deep-link service are legitimate services with good reputations. A common threat intelligence service had 0 of 93 participating vendors rate malicious. One called it 73.8% likely to be legitimate.

  • A fresh domain as the final payload. The final domain was four days old, so reputation feeds had no history on it: not on public blacklists, completely clean reputation. A common threat intelligence service had 1 out of 93 participating vendors rate malicious and one called it 98.4% likely to be legitimate.

  • Cloaking. The final page blocks automated scanners with a "Sorry, you have been blocked" screen. Scanners saw an error page. A person clicking from a work laptop got the installer.

  • Padding for filters. The email body was packed with a repeated nonsense string, "ag2HH7F1V5H4Y1R2Ld5j4," which breaks up the text that content filters try to match. The reader never sees it.

  • A trusted payload. The file at the end is legitimate, signed software. Endpoint tools have no reason to stop it.

Public scan of the deep link: 0 of 93 engines flagged it.

A public URL checker called the deep link safe, and only 1 of 93 engines flagged the final page.

How Ocean caught it

Ocean read the email for what it asked the reader to do, and followed the link to where it ended. The verdict came back malicious and high severity, with three indicators:

  • Impersonation attempt. A .site sender posing as a patient portal.

  • Suspicious link. A shortener redirecting to an unrelated domain that blocks traditional scanners.

  • Obfuscation technique. The repeated nonsense string written into the body to evade automated detection.

Ocean's verdict. Recipient and portal brand redacted.

Why this matters in healthcare

Healthcare runs on the trust between patients and their care team. This lure borrows that trust.

  • Everyone is a patient. Clinicians, billing staff and researchers all get real portal notices about their own care. A "new document" message from a portal looks expected, even at a work address.

  • Health news gets opened fast. A message about a test result or a note from a doctor gets clicked before it gets questioned. In August 2026, more than a dozen health systems warned patients about fake portal messages.

  • Remote access is already everywhere. Hospitals depend on remote access for vendor support, IT and telehealth. Federal health-sector guidance notes that because these tools have legitimate uses, their misuse "is frequently not flagged as malicious by security tools or processes."

  • One workstation can reach patient records. Hands-on-keyboard access to a machine that touches clinical systems puts patient data and patient care at risk. Federal alerts have already tied remote access tool abuse to intrusions at a healthcare provider and a pharmaceutical company.

  • The same lure reaches patients at home. When an attacker fools a patient with a fake portal message, the health system's name takes the hit.

What to do now

  1. Hunt for unsanctioned remote access tools. List the remote access tools you approve. Alert on any other client install, and on new installs of approved tools that connect to a tenant or relay you don't own.

  2. Search recent mail for patient portal notices sent from domains the portal doesn't use, and for links that run through shorteners or deep-link services.

  3. Restrict installs. Require admin approval for new MSI and EXE installs on clinical and business workstations.

  4. Don't trust a clean scan. Pages that block scanners look harmless to reputation checks. Judge the email on what it asks the reader to do.

  5. Tell staff and patients the same rule. A patient portal shows messages inside the portal. It never asks you to download and run a viewer, and it never says "desktop only."

Ocean's take: This email never needed malware. It needed a patient's trust and a remote access tool that IT already allows. As attackers move from malicious files to legitimate software, the only reliable signal is what the email is asking someone to do. Want to see what's reaching your clinicians and staff? Run a free email health assessment: read-only API, no MX change.

Related reading

Get ahead of zero-day phishing

Get ahead of zero-day phishing

Ocean’s agents investigate every email for intent, including attacks no rule has been written for yet.