Phishing Emails Are Installing Remote Access Tools on SMB PCs

What happened

Microsoft has issued a warning about phishing campaigns that deliver an installer for MSP360, a legitimate remote monitoring and management (RMM) product, disguised behind lures like meeting invitations, PDF-themed attachments, and fake software update prompts. According to reporting syndicated via feeds.feedburner.com, Attackers Abuse MSP360 to Deploy ScreenConnect in Dual-RMM Phishing Attacks, the installer is renamed to look harmless, and once a user runs it, the attacker has remote management access to that machine.

From there, the reporting describes a second remote-access tool, ScreenConnect, being deployed, giving the intruder a backup channel if the first one is removed. Both tools are real commercial software signed by real vendors, which is precisely the point: nothing here looks like malware. If you want more technical specifics than that, read the source directly, and ask your IT provider to confirm which exact file names, domains, and indicators Microsoft published rather than assuming a generic block will cover it.

Why this matters for Pittsburgh SMBs

This attack pattern is uncomfortably well-aimed at companies in the 10 to 200 employee range. You do not have a 24/7 security operations center staring at every process launch. You do have staff who receive meeting invites and PDFs all day long, and who have been trained for years that their IT provider installs remote-support software on their machine. When a renamed RMM installer shows up, the muscle memory is to click through it.

The industry mix we see across Western PA makes the downside sharper than "one infected laptop." A CPA firm in the middle of extension season has client tax data, bank authorizations, and e-filing credentials sitting on workstations. A law practice has privileged matter files. Medical and behavioral health practices are holding ePHI, and a remote-access session that touches a workstation with chart access is a potential HIPAA breach analysis whether or not data visibly moved. Financial advisory firms are under FTC Safeguards obligations to detect and respond to unauthorized access to customer information. And if you are a defense supplier on the Mon Valley manufacturing side, unauthorized remote control of a machine that handles CUI is not just an incident, it is a control failure you will have to speak to during a CMMC assessment and, depending on your contract terms, potentially a DFARS 7012 reporting event. Verify your specific reporting clock with your contracting officer or counsel rather than guessing at it.

There is a second, quieter problem. Hands-on remote control is how attackers set up the slow version of a breach: harvest credentials, read email to learn who approves wire transfers, then redirect a payment. Pittsburgh manufacturers and professional services firms have been hit by exactly that kind of invoice fraud for years. A silent remote session is a very efficient way to run it.

What to do about it this week

1. Inventory every remote-access tool that is legitimately allowed. You should be able to name the one or two products your IT provider uses and nothing else. Anything outside that list, including free personal remote tools, is unauthorized by default. This is a one-afternoon exercise and it is the foundation for everything below.
2. Block unapproved remote tools technically, not by policy alone. Use application control, allow-listing, or endpoint policy to prevent unapproved RMM and remote-desktop binaries from executing. Ask your provider which mechanism they are using and request evidence it is actually enforcing, not just reporting.
3. Alert on new remote-access installs and outbound sessions. Your EDR or MDR tooling should raise a ticket when a remote-control agent appears on an endpoint or a new remote-session domain is contacted. Confirm someone is reviewing those alerts after hours, not just during business hours.
4. Remove local administrator rights from day-to-day accounts. Most of these installers need elevation. Standard-user accounts plus a controlled elevation process stops a large share of this class of attack outright and simultaneously satisfies least-privilege expectations under SOC 2 and NIST-aligned frameworks.
5. Retrain on this exact lure, with your own branding in the example. Tell staff plainly: we will never email you a remote-support installer, and a meeting invite will never ask you to run a setup file. Add a no-blame reporting path. A thirty-second recorded message from your managing partner outperforms a generic annual video.
6. Harden the Microsoft 365 layer around email. Verify safe-attachment and safe-link handling, external-sender banners, and that quarantine release is restricted to administrators. While you are in there, confirm your Microsoft 365 tenant blocks legacy authentication and enforces phishing-resistant MFA for anyone with financial or clinical system access.
7. Decide now who gets called, and write it down. A one-page incident runbook with your provider's escalation number, your cyber insurance hotline, and your regulatory notification owner. Put a calendar hold in the next 60 days, before the end of November, to test that the phone numbers on it still work.

How we help

PGH Networks runs managed IT and patch management for Pittsburgh-area firms with the assumption that remote access is a controlled, auditable privilege, not a convenience. That means a documented tool allow-list, endpoint detection that flags unexpected remote agents, identity hardening in Microsoft 365, and a vCIO who maps all of it back to the HIPAA, SOC 2, FTC Safeguards, or CMMC obligations your contracts actually impose. If you are also evaluating Copilot or an AI readiness assessment, the same access-control discipline is what makes that project defensible instead of risky.

Talk to us

Want a straight answer on whether an unapproved remote tool could run on your network right now? Call 724.888.7007 or reach us through the contact form and we will walk your environment with you.