A remote desktop gateway is a login page that leads to a desktop inside your network, which makes it one of the most attacked services you can publish. CISA’s StopRansomware guide has listed remote desktop access among the most common intrusion routes for years, and the pattern rarely changes: valid credentials, no second factor, and a session on an internal machine within a minute.
What testers check first
The first questions are about authentication, not about vulnerabilities. Is multi-factor authentication enforced for every user, including service accounts and the administrator who set it up? Does the gateway lock accounts after failed attempts, and does that lockout apply across the whole authentication path? Is Network Level Authentication required, so an unauthenticated user cannot reach the session host’s login screen? A tester will also try a slow password spray, one attempt per account every half hour with a seasonal password, because that pattern stays under most lockout thresholds while covering the whole staff list.
The information the service gives away
Remote Desktop Web Access has a habit of confirming which usernames exist. Timing differences between a valid and an invalid account, or subtly different error messages, let an attacker turn a list of names scraped from a professional network into a list of real accounts. That matters because password spraying works far better against confirmed accounts. Check the certificate too, since the common name and subject alternative names often reveal internal server naming, and look at whether the gateway version is advertised in headers where a public advisory can be matched to it.
“Every business that has been hit by ransomware through remote access told me beforehand that the service was fine because it was patched. Patching was never the problem. Somebody in accounts had a password that appeared in a breach dump three years ago, and the gateway did not ask for anything else.”
William Fieldhouse, Director, Aardwolf Security Ltd
Reducing what you publish
You should question whether the gateway needs to face the whole internet at all. Options in rough order of effort are restricting source addresses to known offices and supplier ranges, putting the service behind a VPN or a zero trust proxy that authenticates before the connection reaches Windows, or replacing it with a managed remote access service. Where the gateway must stay public, enforce multi-factor authentication for all users, apply Conditional Access rules if you use Entra ID, and disable the web access interface if nobody uses it. Perimeter penetration testingwill confirm which of these are actually in force rather than configured.
Watching the service properly
Log successful and failed authentications and alert on patterns rather than individual events. A single failed login means nothing. Twenty accounts each failing once in an hour is a spray, and it deserves a call. Track sign-ins from countries where you have no staff, and from hosting provider address ranges, since attackers rarely connect from a residential broadband line in the same town. When you shortlist penetration testing companies in the UK for external work, ask them to test the detection as well, because knowing that nothing alerted is as valuable as the finding itself.
Frequently asked questions about remote desktop exposure
These questions come up whenever remote access is reviewed after an incident elsewhere.
Is a VPN safer than a published gateway?
Usually, because it adds an authentication layer before Windows is reachable. It is not automatically safer: a VPN appliance without multi-factor authentication and behind on patches has been the starting point for plenty of incidents.
How often should this be tested?
Quarterly for the exposure itself, which is quick, and annually as part of a fuller external assessment. Re-test immediately after any change to the authentication path.
