How do you detect unauthorised remote access software such as UltraVNC on Windows?

What to look for first when UltraVNC shows up on Windows

Start with the simplest question: is the software expected? On Windows, unauthorised remote access tools usually leave a combined footprint of an installer, a service, a running process, an autostart entry, and a listening port. UltraVNC is often easier to spot when you correlate those artefacts rather than hunting only for the application name.

That means inventory checks should cover RMM Tool Security Guide style indicators as well as native Windows persistence points, because remote access software may be launched through a renamed binary, a scheduled task, a service wrapper, or a startup key instead of a visible desktop icon.

Look for mismatch signals: a remote administration binary in a user profile, Temp path, Downloads folder, or another user-writable location; a service that did not exist before the change window; or an inbound listener that is not part of the approved remote support stack. The key is to compare what is installed and running against what the endpoint is actually authorised to use.

How to confirm it is a real remote access exposure

Confirmation should combine host telemetry with network evidence. A live listener alone is not enough, because some support software is legitimate, and some malware borrows the same ports or process names. What matters is whether the process, parent process, binary path, and autostart method line up with a known approved tool.

If the host is exposed through remote access rather than local execution, the access path matters as much as the file artefact. A remote support session, a new inbound connection from an unapproved source, or a service configured to start automatically can indicate that the tool is being used for interactive control rather than maintenance. Where remote admin tooling is central to the investigation, compare the case with Remote Access Identity Guide to distinguish expected support paths from risky exceptions.

For Windows estates, an authorised remote access inventory should include the approved vendor, the host list, and the business owner. If the software appears outside that list, treat it as suspicious even if the binary name looks familiar, because attackers frequently rename or repack tools to blend in with legitimate administration activity.

What Windows artefacts usually reveal unauthorised use

On Windows, the most useful signals are the ones that show how the tool starts and how it stays resident. Services, Run keys, Startup folders, scheduled tasks, and user-logon persistence entries are all worth checking, along with recent installer activity and process creation history. Those artefacts often tell you whether the tool was deployed intentionally, copied manually, or dropped by another payload.

Process lineage is especially useful. A remote access process spawned by Office, a browser download, a scripting host, or an unusual parent process deserves more scrutiny than the same process started by a managed software deployment tool. That distinction often separates approved support software from an opportunistic foothold or a hands-on keyboard session.

Network behaviour can help too. Listen for new inbound ports, repeated beacons from an endpoint that should be idle, or session patterns that do not match support hours. If you are mapping the activity to known intrusion techniques, Command and Control (C2) Guide helps frame why remote access tooling and beaconing can overlap operationally even when they are used for different purposes.

Risk and Threat Considerations

Unauthorised remote access software is risky because it creates a direct interactive path into the endpoint, often with the same privileges as the logged-in user or the installed service account. Once present, it can be used for persistence, data theft, lateral movement, and stealthy remote execution, especially if it is allowed through existing firewall rules or blends into approved admin traffic.

Failure mechanism: A threat actor, or an insider, installs or reuses a remote administration tool and then hides it inside ordinary Windows persistence and network patterns, making the connection look legitimate long enough to operate unnoticed.

Impact: The endpoint can become a durable remote control point, enabling credential theft, session hijack, command execution, and broader compromise across the environment if the same tooling or credentials work on multiple systems.

Practitioner Guidance

What to verify: Confirm three things before you close the case: the binary is approved, the install path is expected, and the inbound session belongs to a known support workflow. If any one of those is missing, treat the finding as unauthorised until proved otherwise.

What to prioritise: Triage hosts where the tool is installed in a user-writable path, starts from a new service or autorun entry, or appears alongside other signs of compromise such as unusual logons, scheduled task creation, or privilege changes. Those combinations usually carry more risk than a standalone install artefact.

Practitioner takeaway: The most reliable detection is not “is UltraVNC present?”, but “does the software, its launch method, and its remote session all match an authorised support pattern?”

Related resources from NHI Mgmt Group

• What breaks when a developer tool can silently install remote access software onto Windows endpoints?
• Why do session enumeration and remote SAM access create such a high risk in Windows environments?
• How can security teams detect Remote Access Software?
• How do you detect unauthorised or unauthenticated access to the Kubernetes API?