How to block remote access tools on your network
Remote desktop and support tools are some of the most useful software IT teams have. They are also the first thing a support scammer asks a victim to install, and a favourite way for intruders to keep access.
This guide shows IT admins, MSPs, school IT teams and vendors how to allow one approved tool and block the rest.
Why organisations block remote access tools
The risk is not the software itself but who is on the other end. Two different threats use the same tools, and a good policy covers both.
Scams and social engineering
- Fake tech support and refund scams that walk the user through installing a tool.
- Callers pretending to be the internal help desk or a bank's fraud team.
- Older staff, volunteers and students are frequent targets.
- Losses often hit personal and company bank accounts in the same session.
Intrusions and persistence
- Attackers install a second remote tool to keep access after the first entry point is closed.
- Legitimate signed software rarely triggers antivirus alerts.
- Ransomware groups use remote tools to move between machines and copy data out.
- Insiders can use personal remote access to reach work machines from home without oversight.
From the public record: a joint advisory from CISA, NSA and MS-ISAC in January 2023 (AA23-025A) described criminals using phishing emails to get federal staff to download legitimate remote monitoring and management software, then using it in a refund scam. It noted that portable versions can run without admin rights, bypassing common software controls.
The principle: one approved tool, everything else blocked
Choose
Pick one remote support tool, or one per clearly defined team, and record who owns it.
Harden
Require multi-factor sign-in for technicians, restrict who can start sessions and keep session logs.
Block the rest
Block every other remote access product by category, by application signature and on the device.
This is easier to run than a blocklist of individual tools, because new products appear all the time. If it is not the approved tool, it does not connect. It also gives users a simple rule to remember: anyone asking you to install a different tool is not from IT.
Common remote access tools and how to handle them
Names below are examples of widely used legitimate products, not a judgement on any of them. Each is fine when your IT team runs it and a risk when a stranger asks a user to install it.
| Tool type | Examples | Typical abuse | How to control it |
|---|---|---|---|
| Attended remote support | AnyDesk, TeamViewer, Splashtop | Scam calls, user reads out a session code | Category blockApp control |
| Self hosted remote support | ScreenConnect, RustDesk | Attackers run their own server, so the domain is not the vendor's | App controlNew domain rule |
| Browser based remote desktop | Chrome Remote Desktop | Set up quietly on a work machine for access from home | URL blockBrowser policy |
| Built in operating system tools | Windows Quick Assist, Remote Desktop (RDP) | Social engineering, internet exposed RDP | Remove or restrictInbound firewall rules |
| RMM platforms | Tools used by MSPs to manage fleets | A second, unknown RMM agent installed by an attacker | Allow one RMMCategory block |
| Screen sharing in meeting apps | Video meeting tools with remote control | Scammer asks for control during a "support" meeting | Disable remote control setting |
Self hosted tools are the reason domain blocking alone is not enough. Pair a category block with application control, and treat newly registered domains with suspicion, because attacker controlled relay servers often sit on fresh domains.
Methods: where to block remote access tools
- Use a filtering DNS resolver that blocks the Remote Access Tools category, with your approved tool allowlisted.
- Block outbound DNS to other resolvers.
- Never forward RDP (TCP 3389) or other remote access ports from the internet to internal machines.
- Block the remote access URL category and the remote access application group, then add an allow rule for your approved tool above it.
- Block inbound RDP from the internet; use a VPN or gateway for staff remote access.
- Log and alert on any remote access application detected other than the approved one.
- Block the Remote Access Tools category for all user groups.
- Allowlist the domains your approved tool needs, using the vendor's published list.
- Block Malware / Phishing / Suspicious too, since fake "support" pages often host the download link.
- Use app control (WDAC or AppLocker) to allow only the approved remote tool, which also stops portable versions.
- Remove Quick Assist on devices where your help desk does not use it.
- Add Defender custom indicators for remote access download sites and relay domains you find.
- Use Defender alerts for new remote access software appearing on a device.
- Block remote desktop sites through the URL blocklist or a category filter.
- Use Chrome policies to control whether Chrome Remote Desktop hosts can be set up on managed devices.
- Allowlist extensions and Android apps so remote control apps cannot be added.
- Keep remote control and screen sharing apps out of the managed catalogue unless IT uses them.
- Phone scams increasingly ask victims to install screen sharing apps to watch banking codes.
- Push your DNS or filtering profile so the category block applies on mobile too.
Do not forget the inbound side. Outbound blocks stop users reaching remote access services. Inbound exposure is a separate risk: remote desktop ports open to the internet are scanned constantly and attacked with stolen or guessed passwords. Close them, put remote access behind a VPN or gateway with multi-factor sign-in, and check your public addresses after every network change.
Order of rules matters. On firewalls and DNS filters, place the allow rule for your approved tool above the category block, and test it from each site. A help desk that suddenly cannot connect is the most common reason these blocks get switched off again.
Bypass risks and how to close them
Remote access tools are designed to work through firewalls, so they try many routes when one fails. These are the gaps admins most often find.
Attacker run relay servers
Self hosted tools connect to a server the attacker controls, not the vendor's. Close it with app control and rules for uncategorised and fresh domains.
Fallback to port 443
Most tools fall back to ordinary HTTPS when their own ports are blocked. Port rules alone will not stop them; category and signature rules will.
Portable executables
No installation, no admin rights needed. Only application allowlisting on the device stops these reliably.
Tunnels and VPNs
A personal VPN hides the remote tool's traffic. Block them with our guide to blocking VPN apps.
Browser only sessions
Some tools run a viewer or even a host inside the browser. URL categories and browser policy cover them.
Unmanaged home devices
Staff working from personal computers are outside your controls. Offer guidance and require managed devices for sensitive work.
Policy starting points by organisation
| Organisation | Approved tools | Block | Extra step |
|---|---|---|---|
| K-12 school | The district's own support tool for staff devices | All remote access on student devices and networks | Remove built in remote assistance from student images |
| Office business | One remote support tool run by IT or the MSP | All other remote access and RMM products | Awareness message about fake support calls |
| Healthcare and finance | Approved vendor support through a gateway with session recording | Direct vendor tools on clinical or trading systems | Time limited access approvals |
| Libraries and public PCs | None for patrons | All remote access on public machines | Reset machines after each session |
| MSP tenants | The MSP's RMM and support tool | Every other RMM by default | Monthly report of unknown agents |
Public library and school machines are attractive to scammers because many people use them. Our pages on library web filtering and K-12 school web filtering cover the wider filtering policy.
For MSPs: an RMM hygiene checklist
MSPs depend on remote tools more than anyone, and attackers know it. A compromised or unknown RMM agent on a client network can reach every machine at once. See also our page on web filtering for MSPs.
- Standardise on one RMM and one remote support tool across all tenants.
- Block every other RMM and remote access product in each tenant's filter policy.
- Require phishing resistant multi-factor sign-in for every technician account.
- Limit which technicians can reach which tenants.
- Review the list of installed remote tools on every endpoint each month.
- Alert when a second RMM agent appears on any device.
- Keep session recordings or logs for an agreed period.
- Tell clients exactly how your technicians will contact them, so fake calls stand out.
- Remove agents promptly when a client leaves.
- Rehearse what you will do if your own RMM account is compromised.
Red flags to teach users
Technical blocks catch most attempts, but a short awareness message closes the gap on unmanaged phones and home computers.
Unexpected calls
Real IT teams and banks do not call out of the blue and ask for remote access.
Pop-ups with a phone number
Browser warnings that tell you to call support are scams. Close the browser.
Refunds and overpayments
"We refunded too much, please send it back" is the classic refund scam script.
Requests for codes
Never read out a session code or a one time password to someone who contacted you.
Pressure and urgency
Scammers rush victims and discourage them from hanging up to check.
"Do not tell anyone"
Any request to keep the call secret from colleagues or family is a warning sign.
If someone already let a scammer in
Speed matters more than blame. Give staff a simple sequence and make reporting feel safe.
- Disconnect the device from the network or Wi-Fi straight away.
- Report it to IT or the MSP immediately, including the time and what the caller said.
- Contact the bank if banking pages were opened or card details shared.
- Change passwords from a different, clean device, starting with email and banking.
- IT removes the remote tool and checks for other tools or accounts left behind.
- IT reviews logs for the session and any data that left the device.
- Add the scam's domains to your block policy and check their category with a lookup.
- Share an anonymous summary with staff so others recognise the same script.
How to test the remote access block
| Test | How | Pass |
|---|---|---|
| Download sites | Open the download pages of three remote access products that are not approved | Block page with the remote access category |
| Category check | Look up those domains in our domain lookup tool | Remote Access Tools listed |
| Portable run | On a managed Windows test device, run a portable remote tool from the downloads folder | App control blocks it |
| Connection | On an unmanaged test laptop with a tool installed, try to start a session | Connection to the vendor's servers fails |
| Approved tool | Start a session with your approved tool from the help desk | Works normally, with multi-factor sign-in |
| Built in tools | Try Quick Assist and browser remote desktop on managed devices | Removed or blocked as per policy |
| Inbound exposure | Scan your public addresses for open remote access ports | No open RDP or similar ports |
| Alerting | Check the SIEM or MSP ticketing system for the test events | Each attempt recorded |
Category-based blocking with our database
Our database includes a dedicated Remote Access Tools category within its 59 web filtering categories. It covers remote desktop, screen sharing and RMM services, their web consoles and download sites, so one policy line replaces a hand maintained list.
Combine Remote Access Tools with phishing and malware categories, because fake support pages often carry the download links. The full category list is in our taxonomy, and licensed customers can export lists as DNS RPZ, hosts files or firewall external dynamic lists.
Because each domain can carry several ranked categories, a meeting tool with a remote control feature can be recognised both as Web-based Applications and as Remote Access Tools. That lets you decide per policy whether to allow it, instead of guessing.
Remote access blocking FAQ
Why block remote access tools if they are legitimate software?
Because criminals use the same legitimate tools. Support scammers talk victims into installing them, and intruders use them to keep access, often without triggering antivirus. Allowing only the tool your IT team uses removes that route.
What is the safest way to allow remote support?
Choose one approved tool, deploy it centrally, require multi-factor sign-in for technicians, and block every other remote access product by category and by application control.
Can portable remote access tools run without admin rights?
Yes. Several remote access products offer portable versions that run from the downloads folder without installation. A joint advisory from CISA, NSA and MS-ISAC in January 2023 highlighted this as a way attackers bypass software controls. Application allowlisting is the reliable fix.
Should we block Windows Quick Assist?
If your help desk does not use it, consider removing or blocking it. Microsoft has reported criminal groups abusing Quick Assist in social engineering attacks. If you do use it, make sure staff know IT will never call unannounced and ask them to start a session.
Which category covers remote access tools?
Our database includes a Remote Access Tools category for remote desktop, screen sharing and remote monitoring and management services, including their web consoles and download sites.
What should someone do after letting a scammer connect?
Disconnect the device from the network, report it to IT immediately, change passwords from a different device, contact the bank if any financial details were shown, and let IT check the device for tools left behind.
Close the remote access scam route in your product
License a categorized domain database with a Remote Access Tools category, daily updates and a lookup API, running in your own systems. Starter database tiers from $999; enterprise and OEM licences are quoted per deployment.
AnyDesk is a trademark of AnyDesk Software GmbH. TeamViewer is a trademark of TeamViewer Germany GmbH. Splashtop is a trademark of Splashtop Inc. ScreenConnect is a trademark of ConnectWise, LLC. RustDesk is a trademark of its respective owner.
Microsoft, Windows, Quick Assist, Intune and Defender are trademarks of Microsoft Corporation. Google, Chrome and Android are trademarks of Google LLC. These names are used here only to identify the products discussed. Web Filtering Database is not affiliated with, sponsored or endorsed by any of these companies.