Fortra Reports 475% Rise in Phishing Attacks Abusing Remote-Management Tools

The most dangerous part of a fake bank-support conversation may be the moment it appears to become helpful. A customer worried about an account problem accepts an offer of assistance, opens a remote-access tool, and gives someone else control of the computer used for banking. The software can be genuine. The person operating it is not.

New research from Fortra, published October 8, reports a sharp increase in phishing campaigns that incorporate remote monitoring and management tools, commonly called RMM. Through the first nine months of 2026, the company recorded 475% more such attacks than during all of 2025, with North American financial institutions and commercial banking accounts a particular focus.

The finding highlights a problem that malware detection alone cannot solve: attackers can persuade people to authorize a legitimate capability for a fraudulent purpose.

What the 475% figure tells us

Fortra’s comparison is between January–September 2026 and the entire preceding year. A 475% increase means the observed count was 5.75 times the baseline, not 4.75 times. Because the periods differ in length, the result should not be described as a conventional same-period year-over-year comparison.

It is also a measure of attacks observed by Fortra, not a census of all global phishing activity, confirmed compromises, or financial losses. The percentage is striking, but it does not establish how frequently a victim granted access or how much money was stolen. Those distinctions matter when translating threat-research findings into business risk.

When a phishing page becomes a remote-control session

Fortra describes fraudulent bank-support pages whose chat prompts lead to a download of remote-access software, commonly AnyDesk. The attacker then guides the victim into granting access. The company reports that campaigns adapted after restrictions on downloads linked from Firebase, shifting delivery to other infrastructure. Its researchers describe efforts to disrupt several parts of the chain, rather than only the initial phishing page.

That progression changes the nature of the threat. A fake login page attempts to obtain information from a person. A remote-control session can put an operator alongside that person while they use applications and accounts. The boundary being crossed is control of the endpoint, with potential consequences beyond one password.

There is no need to assume that the remote-access product has been compromised for this scenario to work. The abuse comes from deception about who is requesting access and why. A recognizable application name can actually reinforce the victim’s belief that the process is legitimate.

For an organization, this creates two separate verification tasks: determining whether a tool is approved and determining whether this particular session is authorized. Passing the first test cannot answer the second.

An established technique with a renewed banking focus

The broader technique predates this report. In a January 2023 joint advisory, CISA, NSA, and MS-ISAC described a phishing campaign abusing legitimate AnyDesk and ScreenConnect software in refund scams. The agencies also warned that remote-management access could support persistence or be sold to other attackers.

A particularly important technical detail was the use of portable executables. The advisory explained that these can run in a user’s context without full installation or administrator privileges. Consequently, a policy that blocks installation may leave a gap if it does not also control execution.

This is why removing local administrator rights is valuable but cannot be treated as a complete answer to remote-access abuse. Defenders need to understand which applications can actually run, how they connect, and what their users have permitted them to do.

The history also puts Fortra’s increase in perspective. Its report is evidence of rising observed use of an established approach, rather than the discovery of a wholly new class of attack. The challenge is that a familiar technique remains effective when a convincing support story meets weak authorization controls.

Trust the session, not just the application name

AnyDesk’s own abuse-prevention guidance warns that criminals misuse remote-access software to steal information, access codes, and money. It advises against giving unfamiliar people device access or sharing banking credentials, and identifies unexpected offers of technical help as a warning sign.

The practical lesson is to establish a support request through an independently trusted channel. If an incoming message claims a banking emergency, contacting the institution through its established app or a known number avoids relying on the contact details supplied by the person raising the alarm.

For employees, the same principle applies to internal support. An urgent request should be verifiable against the organization’s normal process. Training is stronger when it specifies what legitimate support looks like and how to check it, rather than simply asking people to detect suspicious wording.

AnyDesk also documents security controls including custom client policies, two-factor authentication for unattended access, and access-control lists that restrict incoming sessions to authorized IDs or aliases. These controls illustrate that remote access can be constrained beyond merely allowing the executable.

Configuration still needs to match the threat. Strong protection for a company-managed client does not automatically govern a separate copy launched outside the approved support workflow. Nor does authentication of a remote-access account prove that the operator’s request is legitimate.

What defenders should change

CISA’s advisory recommends auditing remote-access tools, reviewing execution logs, and applying application controls to unauthorized software—including portable versions. That is a useful starting point for organizations evaluating this trend.

The operational goal should be a remote-support process that can answer three questions:

• Which tool is authorized? Maintain an inventory of approved software and enforce execution rules, rather than relying only on installation records.
• Who can connect? Constrain approved clients and accounts, and make exceptions visible to the team responsible for them.
• Why is this session happening? Connect remote support to a verifiable request and review activity that falls outside normal patterns.

These questions also help distinguish ordinary maintenance from misuse. A new remote-access process on a banking workstation during an unsolicited support call deserves different scrutiny from a scheduled session by an approved technician. Neither the product name nor its legitimate business purpose supplies that context by itself.

If someone has already granted suspicious access, AnyDesk advises contacting affected account providers, changing potentially compromised passwords, having the device checked by an IT specialist, and reporting the scam. In an enterprise, prompt escalation to the security team is essential so the response can consider both device access and account exposure.

A warning about borrowed legitimacy

Fortra’s report is a reminder that phishing is not limited to stolen passwords. It can be a route to convincing a person to delegate control of a trusted device.

The central defensive challenge is authorization: legitimate software, an encrypted connection, and an apparently helpful conversation can coexist with a fraudulent operator. Organizations that verify support requests and govern individual remote sessions will be better positioned to address that gap than those that equate a familiar application with a safe interaction.