Relay-based remote-desktop products commonly establish outbound connections to vendor infrastructure, so a session may be brokered without a conventional inbound port on the endpoint. That architecture can create an external access path through NAT, but it does not make every running client remotely controllable. The client must reach the relay and permit the requested incoming session, and the operator must satisfy the configured approval, authentication, allowlist, account, device-trust, and permission requirements. Egress filtering, DNS or proxy policy, application control, conditional access, and self-hosted or on-premises designs can further restrict the path.
# review endpoint and network evidence together
# - is the client or service running?
# - can it reach the vendor relay through DNS, proxy, and firewall policy?
# - which incoming-session and authorization controls apply?
Exploitation notes#
- Network segmentation and egress controls remain relevant because they can limit which endpoints communicate with public relay infrastructure.
- A device ID identifies a destination but does not authenticate a connection; review the controls described in ID-based access.
- Interactive sessions require user acceptance under applicable policy, while unattended sessions require their configured authentication and authorization controls.
- Pair reachability analysis with configuration review rather than inferring access from installation or relay traffic alone.