Operators tied to India-based scam call centers, several traced back to Kolkata, are running their fraud through legitimate remote monitoring and management software. Investigators at Huntress and AnyDesk found multiple Kolkata operations sharing cracked, self-hosted ScreenConnect instances that were resold to other groups as branded subdomains. The same tooling shows up at pig-butchering compounds, where remote access is part of the standard workflow. This analysis draws on reporting from Huntress.
The reason this works is simple. RMM software is signed by the vendor, hosted on the vendor's infrastructure, and often already permitted in your environment because your own IT team uses something similar. A rogue install runs the same installer, lands in the same location, and phones home to the same vendor endpoints as an approved one.
They talk the victim into installing it. Matt Caldwell, Director of Fraud Prevention at AnyDesk, received a lure in his own inbox: a fake Pepsi recruiter asking him to download a meeting app, which turned out to be a cracked RMM. Lures that feel personal, embarrassing, or too good to be true keep the victim from mentioning it to anyone who might stop it.
Key Insight: Attackers rarely need an exploit to get it there.
The scale has changed quickly. Remote access tool abuse climbed 277% last year according to the Huntress 2026 Cyber Threat Report, and the Huntress SOC Tactical Response team now finds the tactic in almost 40% of the incidents it investigates.
RMM abuse is the number one threat Huntress tracks across almost five million endpoints.
Victims are not only consumers. Small business owners sit on both sides of this, since the laptop a scammer talks their way onto is frequently the same one holding company email, banking portals, and saved credentials for business systems. Hands-on-keyboard access to that device gives an operator the same reach a legitimate administrator would have.
How the Remote Access Sessions Are Established and Maintained
The access chain starts with a conversation. In the case Matt Caldwell described, a fake Pepsi recruiter emailed him about a job opening and asked him to install a meeting app to take the interview. The download was a cracked RMM client. No exploit, no dropper, no bypass of endpoint controls, just a believable reason to run an installer and a pretext the target would be reluctant to escalate to IT.
That reluctance is part of the design. Lures built around job offers, investment opportunities, or personal matters keep the target from asking a coworker about it, which extends the window before anyone with security visibility hears about the session at all. In ATT&CK terms this is T1566 phishing for initial access followed by T1219 remote access software, and the second stage inherits legitimacy from the first.
Installation and use are separated in time. In one Huntress investigation, a user clicked a ScreenConnect lure in February. The operator who sent it did not sign in until July.
A rogue remote access client sat installed and dormant for five months before the attacker used it, because nothing about a remote access tool on an endpoint looks out of place.
When the operator finally connected, the activity ran through the user's own session. They accessed the browser, created inbox rules, and used the mailbox to send spam pushing a second rogue remote access tool at new targets. Inbox rule creation maps to T1564.008, hiding replies and bounce messages from the account owner, and the outbound spam originated from the customer's legitimate mail infrastructure, which is what raised the ITDR alert. Mail sent from your own domain carries your sending reputation, so the cost extends to deliverability and to whoever receives the next wave of lures.
The telemetry problem is that every artifact the rogue install produces has a legitimate twin:
- At install. An authorized deployment and an attacker-driven one run the same vendor installer and write to the same location on disk.
- At the process level. An RMM client spawned by a browser or by Outlook reads as suspicious until you account for the support links your own helpdesk emails to users all day.
- On the network. Rogue instances call back to the vendor's relay infrastructure, the same destinations your sanctioned deployments already reach.
Correlating those low-fidelity signals narrows the field without closing it. A process tree shows how the client arrived and connection records show where it went, and neither answers whether the tool belongs to IT, a vendor, a specific employee, or nobody.
Once a session is live, the operator has whatever the tool grants, which in practice is interactive control and command execution under the logged-in user. Caldwell's team demonstrated the reach of that access from the other direction, using a ScreenConnect session to run PowerShell inside a scam call center and shut down its dialer mid-call. The same capability in an attacker's hands means file staging, script execution, and configuration changes carried out through a signed, vendor-hosted client.
That signing is the reason hash-based blocking falls short. These are current, legitimately signed builds pulled from vendor infrastructure, so an allowlist keyed to file reputation clears them without objection. The distinguishing factor is authorization, not the binary.
Business Consequences of Unsanctioned RMM Software on Corporate Endpoints
In the case Huntress investigated, a user clicked a ScreenConnect lure in February and the attacker did not sign in until July. Nothing about that gap is unusual, and it changes how you have to think about cost. The exposure window is not the day someone clicked, it covers every month the install sat there unnoticed.
When the attacker did connect, they reached the user's browser, created inbox rules, and used the account to send spam advertising another rogue remote access tool. That activity came from the customer's own legitimate infrastructure, which is what triggered the ITDR alert. Your domain sending unsolicited mail to your own clients and partners costs you deliverability and credibility before a single dollar moves.
A live remote session gives the operator whatever the signed-in user can see and do. That includes:
- Banking portals and payment approval workflows opened during the session, along with one-time MFA codes typed while the attacker is watching the screen
- Corporate email, mapped file shares, and any cloud storage the endpoint is already authenticated to
- Saved credentials in the browser profile, which extend the reach well past the one machine
If a fraudulent transfer originates from a session your own employee authorized, your bank has a strong argument that the instruction was legitimate. The recovery conversation gets harder, and the loss tends to stay with your business.
Access itself is a product. An operator who establishes a foothold and finds nothing worth stealing can hand that access to someone who does, and the second party arrives with a working remote session instead of a phishing campaign. Dray Agha notes that roughly 70% of advanced attackers get in through the VPN using credentials stolen elsewhere, frequently from a personal device. Credentials captured during a remote session on a corporate endpoint feed directly into that pattern.
The compliance side is where the numbers grow. If regulated records were visible on the screen during a session, your counsel may have to treat that as access to the data, which can put you into notification territory even when nothing was copied out. You will be asked to define scope, and screen viewing rarely produces the kind of file access logs that let you narrow it.
Unmanaged remote access tools also cut against statements you have probably already made in writing. Cyber insurance applications and audit questionnaires generally assume you control what software runs on endpoints and that remote access is limited to approved administrators. A rogue install of an otherwise approved tool sitting on a finance workstation for months undercuts that assertion, which can surface during a claim review or an annual assessment.
Attribution and recovery are slower here than with commodity malware. There is no malicious binary to submit, no unusual outbound destination, and no failed login pattern, because the software is vendor signed, the traffic goes to the vendor's infrastructure, and the account activity belongs to a real employee. Your responders spend their first hours establishing whether the tool was ever supposed to be there, and that time comes out of containment. Rebuilding confidence in the affected endpoints usually means reimaging and rotating credentials for every account that touched them, since you cannot demonstrate from logs alone what the operator watched.
Detecting Unauthorized AnyDesk and ScreenConnect Activity
Start with the inventory, because every other detection rule depends on it. Sweep every endpoint for installed remote access binaries (AnyDesk, ScreenConnect and the rest of the common families), then hold that list against the one tool your IT team is actually sanctioned to run. Anything outside that list is a hunting lead, not a maintenance ticket.
The inventory is the Identify step in NIST's Cybersecurity Framework, and it has to stay current. A list built once and filed away tells you nothing about the install that landed last week, so re-run the sweep on a schedule and diff the results against the previous run. RMM Guard, the app control use case Huntress built for this problem, does the same job continuously by cataloguing every remote access tool running across the fleet and blocking anything not explicitly authorized, including attacker-controlled instances of a tool you already approve.
On the protect side, allow-listing is what turns the inventory into a control. Permit only your sanctioned RMM to execute, and deny execution from user-writable directories such as the Downloads folder, which is where a socially engineered installer lands. Block the relay and connection domains for RMM vendors you do not use at the egress point, and require an approval step before any inbound remote assistance session can attach to a workstation.
Detection work centers on the tools' own logs, which are more useful than most defenders expect. AnyDesk writes connection traces that record the incoming ID and source address for every session, and ScreenConnect keeps host and session records showing who connected and when. Pull both and look for inbound sessions from IDs and addresses that do not map to your help desk, sessions outside support hours, and any session on an endpoint your inventory says should not be running that client.
Three alert rules cover most of what the behavior described here looks like in telemetry:
- New RMM service installation on any endpoint, correlated against the approved list, treating a second remote access family on a host that already has one as high priority.
- An RMM client process spawned by a browser or a mail client, scoped so your own IT team's quick-access support links are excluded by source domain rather than ignored wholesale.
- PowerShell activity that stops services, alters exclusions, or otherwise tampers with endpoint protection, particularly when it runs inside an active remote session.
That last one matters because the same scripting access defenders used to shut down a scam dialer is available to an operator sitting on your endpoint. In environments Capstone manages, SentinelOne flags and blocks security tooling tampering of this kind at the point the command executes, which is often the first unambiguous signal in an intrusion where everything else looked like routine administration.
For response, confirm containment works before you need it. Test whether you can isolate a workstation from the network without waiting on a single person's availability, and write the RMM uninstall and credential reset into the playbook.
Two longer-term controls close the loop. Train users specifically on unsolicited remote support requests, including the ones arriving through job offers and personal channels, and put callback verification on any payment or banking change so a session that reaches finance does not translate directly into a wire.
Responding to a Confirmed Remote Support Compromise
Isolate the endpoint at the network level before you touch the software. Pulling the machine off the network with an EDR containment action or by disabling the switch port keeps the attacker out while leaving memory, session state, and installed artifacts intact. Uninstalling the remote access client first is the most common mistake, because the uninstaller removes the very session records you need to establish what happened and when.
Once the device is contained, collect the evidence before rebuilding. Prioritize:
- The remote access tool's own connection logs, which record session start and end times and the connecting endpoint identifier
- PowerShell console and script block history from the affected user profile, since the same interpreter that legitimate admins use is also what an operator reaches for during a live session
- Browser profile data, saved credential stores, and any files created or modified during the session window
- Windows event logs covering account logons, service installation, and scheduled task creation
Treat every credential typed, saved, or displayed on that machine during the session period as compromised. That includes anything the browser autofilled while the operator was watching, not just what the user deliberately entered. Rotate those passwords from a clean device, revoke active sessions and refresh tokens, and re-enroll MFA where the second factor lived on the same endpoint. Adlumin ITDR tracks the authentication that follows in managed environments, so a rotated credential that immediately gets used from an unfamiliar location surfaces as an alert instead of a quiet re-entry.
Then work outward to the accounts reachable from that browser session. Check mailbox rules and external forwarding on the affected user and on any shared or delegated mailboxes they could open. Review banking and payment portals for changed contact details, new payees, altered notification settings, and any pending transfers. Extend the same review to accounting platforms and payroll, because those are where a fraud operator monetizes access rather than where they first land.
Assume the session installed something else. Look for a second remote access client, new local accounts, added members in local administrator groups, unfamiliar services, scheduled tasks, run keys, and any tunneling utility that would give the operator a way back after you remove the original tool. Re-imaging the endpoint is the cleanest way to close that out once your evidence collection is finished.
Involve your financial institution the moment a banking or payment portal was open during the session, even if no transfer has cleared. Banks can flag the account, block pending payees, and in some cases recall funds while the transaction is still in process, and that window is short. Report the incident to law enforcement as fraud rather than only as an IT event, because the fraud reporting channel is what connects your case to other victims of the same operation and to the infrastructure takedown work that follows.
Notification obligations turn on what was reachable from the device, not on what you can prove was copied. If the endpoint had access to client records, health or financial data, or a file share holding personal information, your counsel and your cyber insurer should be reviewing the scope while the investigation is still running. Document the session timeline you built from the logs, since regulators and insurers will both ask how long the access lasted and what it touched. Finish by feeding the confirmed indicators back into your authorized-tool list so the same install cannot return unnoticed.
Treating RMM Tools as a Managed Attack Surface
Remote access software has become standard equipment for financially motivated crews, and Huntress tracks RMM abuse as the number one threat across almost five million endpoints it monitors. That ranking matters for how you allocate attention. The tooling your support team depends on is the same category of tooling criminal operators reach for first.
The economics explain the durability of the tactic. A vendor builds the client, signs it, hosts the infrastructure, patches it, and keeps it working across Windows versions. An operator who uses that stack inherits reliable remote control with no development effort and no infrastructure to maintain, and your endpoint controls see software of a type your organization already permits.
The single most effective action is deciding which remote access tools are authorized in your environment, on which endpoints, and blocking execution of everything else. Huntress frames this as curated trust, and it is a governance decision before it is a technical one. Your IT leadership names the sanctioned tool or tools, your vendors get explicitly listed if they need their own, and anything outside that list becomes a finding rather than an ambiguous alert your analysts have to argue about.
That authorization list is also what makes attacker-controlled instances of a tool you already run visible, since the question shifts from whether the binary is malicious to whether that particular install belongs to anyone. Nothing about a rogue remote session is technically abnormal, so the answer has to come from a decision you made in advance. Without that list, every investigation into remote access activity starts from zero.
