How do you detect RDP logons from public IP addresses on Windows?

Correlate RDP logons with routable source IPs

Detection starts by joining Windows logon telemetry to the network address seen at authentication time, then filtering for sources that are publicly routable and outside your approved administration ranges. That is the practical test that separates legitimate remote administration from internet-originated access you did not expect to see.

On Windows estates, the useful signal is not simply “RDP happened”, but whether the source fits the normal access pattern for that host. A public source hitting a server that should only be reached through a VPN, bastion, or private management network deserves a different response from a jump host that is intentionally internet-facing.

For the RDP-specific control picture, the Remote Desktop (RDP) Security Guide is the natural companion because it covers exposure, logon monitoring, and session abuse in the same operational context.

Which Windows logons are most worth alerting on?

Not every remote desktop logon has the same value. Successful logons from a public IP become more interesting when they also look abnormal for that account or host, such as a new geography, an unusual hour, or a user that rarely uses RDP at all. Those contextual mismatches are often what turn a noisy event into a useful detection.

Look for repeated attempts that eventually succeed, especially against privileged or shared administrative accounts. If the source IP is public and the destination is a system that should only accept private access, the event should be treated as a boundary failure, not just a logon record.

It also helps to distinguish internet-exposed jump hosts from internal administration paths. A public RDP logon to a designated bastion may be expected, but the same source reaching a database server, domain controller, or other internal system often indicates exposed management surface, misrouting, or unauthorized use of remote access.

How do you reduce false positives and still keep the signal useful?

Build the detection around allowlisted source ranges, host role, and user behaviour together. A source that is public but intentionally published for a jump server should not trigger the same way as a public source reaching an asset that has no business being exposed to the internet.

Windows event data is most useful when you enrich it with asset context, because the same logon can mean different things on different hosts. A public source on a hardened remote access gateway may be routine; a public source on a workstation, file server, or sensitive application host is much more suspicious.

The strongest alert logic usually combines source reputation, account sensitivity, and host exposure status rather than relying on a single condition. That keeps the rule resilient against routine remote work while still surfacing access paths that should not exist.

Risk and Threat Considerations

Public IP RDP logons matter because they often mark an exposed management path, credential abuse, or both. If an attacker can reach RDP from the internet, they can probe passwords, reuse stolen credentials, or pivot into a system that should have remained private.

Failure mechanism: The control fails when remote access is not constrained by network boundaries, approved admin ranges, or host role, allowing internet-originated authentication to blend in with normal administration.

Impact: The result can be account compromise, unauthorized interactive access, and a cleaner path to lateral movement if the login succeeds on a privileged or sensitive Windows server.

Practitioner Guidance

What to verify: Confirm that your alert logic knows which hosts are meant to receive public RDP, which must never do so, and which source ranges are legitimately approved. Without that inventory, the rule will either miss real exposure or drown in expected noise.

Decision rule: If a successful RDP logon comes from a public source and the destination is not an approved bastion or remote access gateway, treat it as a security event that needs triage, not as a routine administration record.

What good looks like: You can quickly answer whether the source was public, whether the destination should accept public administration at all, and whether the account used RDP in a normal way for that host. If you cannot answer those three questions, the visibility is not yet good enough.

Practitioner takeaway: The best detection is host-aware, not just event-aware, because the same RDP logon is harmless on a controlled jump host and highly suspicious on a server that should only ever see private administrative access.

Related resources from NHI Mgmt Group

• How do you detect bitsadmin downloading from unusual IP addresses or domains on Windows?
• How do you detect Microsoft 365 activity from anonymous or suspicious IP addresses?
• How do you detect sign-ins from anonymous IP addresses in Microsoft Entra ID?
• How do you detect sign-ins from malicious IP addresses in Microsoft Entra ID?