Threats and Countermeasures

Virtual Network Computing (VNC) is a technology which enables one or more clients (aka viewers) to control a remote computer system. VNC is a cross-platform tool popular for remote systems support and administration over IP networks. The remote framebuffer (RFB) protocol, the underlying specification upon which VNC relies, and the varied VNC implementations have a mixed track record. The original RFB protocol employed relatively weak authentication mechanisms and made no special provision for encrypting sessions between the viewer and server. Many administrators and many systems, including many virtual machine (VM) environments, have VNC deployed in networks with insufficient safeguards. While VNC implementations and deployments can easily improve upon VNC’s native authentication and transport security, many VNC installations by default do not and therefore may be susceptible to session hijacking and brute force password attacks attacks. The VNC daemon is helping to monitor and combat this threat.1

This white paper is another in a series to help educate and foster security best practices within the Internet community. Below we discuss common VNC threats and countermeasures.

VNC Authentication and Transport Weaknesses

The remote framebuffer (RFB) protocol is used by VNC to setup and manage a remote control session between a client and server over TCP. The IANA reserved and commonly used server port for VNC is 5900 although other ports are often used in certain configurations. In practice there is a only a single VNC authentication handshake security type commonly in use as defined in section 7.2.2 of IETF RFC 6143.2 In this scheme, as specified in IETF RFC 6134:

“The client encrypts the challenge with DES, using a password supplied by the user as the key. To form the key, the password is truncated to eight characters, or padded with null bytes on the right.”

IETF RFC 6134 continues:

“This type of authentication is known to be cryptographically weak and is not intended for use on untrusted networks. Many implementations will want to use stronger security, such as running the session over an encrypted channel provided by IPsec [RFC4301] or SSH [RFC4254].”

This specified authentication mechanism is weak in two ways. First, notice that the specification limits a password to eight characters. This is a relatively few number of bits by modern standards, making a brute force password attack feasible with modest hardware. Second, because only the password is used as the key to DES, an eavesdropper could feasibly conduct a password cracking attack on the client’s response to the challenge, possibly using a precomputed dictionary to speed the attack under certain conditions. The text from the specification above also hints at a third security issue. The RFB protocol makes no special provision to ensure secrecy of the VNC session data, furthering the risk of eavesdropping attacks.

The specification suggests, but perhaps not strongly enough, that users ought to run VNC on top of a another specification such as IPsec or SSH. Running VNC over SSH is a popular, easy, and reasonable approach to protecting VNC access and sessions. We illustrate this method using OpenSSH to improve VNC’s access control and transport privacy:

Fortunately, many VNC implementations do include support for enhanced authentication and encryption. While the number of VNC implementations prohibits us from enumerating all options and solutions, it should be possible to either first manually wrap VNC sessions in an IPsec, SSH or SSL tunnel, or make use of advanced authentication and encryption services provided by the VNC software provider or through a third party plug in. We strongly advocate that VNC users never rely on the original and inherently weak RFB authentication mechanism and to always tunnel RFB sessions inside an encrypted channel.

Monitoring and Alerting

In this section we briefly discuss four general areas that offer additional insight and ability to alert an administrator about VNC probes and attacks. Each offers their own unique perspective on probe events or attacks. Not all sites need to make full use of each, but having multiple views of your landscape improves your ability to detect and respond. Each category consists of an approach that has been widely implemented in other networks. Other systems and processes are possible, including many packages available from commercial vendors. However, in each section below, use of these subsystems can generally be done with little to no additional cost except for the time required for setup and management.


Netflow was a concept originally developed by Cisco to summarize network traffic traversing routers.4 Today it is widely implemented in many vendor hardware platforms as well as a general tool to summarize network traffic by other means. There are a number of tools available for Netflow collected data. Using them for VNC probe monitoring is relatively straightforward since generally VNC attacks occur over the IANA registered TCP port 5900. However, web-based VNC is typically implemented as a Java application and often run over TCP port 5800 by default. Furthermore, if the VNC server supports multiple displays, such as in a VM environment, additional port listeners may be active, one for each display. Generally VNC servers simply increment by one the starting port number for each additional display. Netflow tools are good at monitoring and alerting on well known traffic characteristics such as these. Furthermore, you can use Netflow to monitor for TCP VNC traffic from your hosts since a successful brute force attack may result in the compromised system becoming part of a larger brute force attack network.

Crypto + VNC traffic inspection

Ideally, VNC traffic will be wrapped inside another protocol that handles authentication and encryption. In the case of SSH-wrapped VNC traffic, unless you are witnessing multiple TCP connection attempts, which may indicate a brute force attack taking place over the secure channel, identifying threats may be limited and even then still look much like other interactive sessions. Similarly, IPsec, SSL or other mechanisms may or may not have VNC traffic running over one of the common ports, if you could even see the TCP session data at all. You may be able to identify key and certificate exchanges, which can provide clues into the identify of the viewer and server. Here again, multiple TCP connection attempts or unique flow characteristics over short intervals may indicate a brute force attack occurring on the secure channel. Ultimately however you may need to be able to identify and verify that the communicating end hosts are in fact witting parties by other means. Perhaps of most interest to the network administrator is identifying VNC RFB traffic that is not wrapped inside another secure protocol. There are a number of tools that examine network traffic and are able to identify particular applications such as VNC irregardless of the port used. This approach may be helpful not only for identifying legitimate, unprotected VNC sessions, but to also uncover trojans or compromised machines running otherwise hidden VNC back door servers.5


Few VNC server implementations devote much effort to ensuring VNC communications can be logged with varying degrees of verbosity to a remote syslog server. When the VNC server is used on a system that does not tend to utilize a centralized logging facility, such as many Microsoft Windows hosts, the ability to monitor VNC server logs, if they even exist, can be difficult if not impossible. If your VNC implementation supports some form of logging we recommend you use it and ensure logs are sent to another secure host for later analysis if the need should arise. Take note that logs may not indicate any specific user name or password attempted, since those credentials are not communicated explicitly during the typical RFB challenge/response authentication phase.

Community alerts and notification

As far as we are aware, the vncrfb.txt report is the only available source of specific VNC probe insight based on a custom VNC application listener module that analyzes actual VNC session attempts.6 Some organizations provide TCP “scanner” events in a more general report, which may of course include TCP protocol events on common VNC ports.78


There are relatively few tools available that aim to help administrators both detect and respond to VNC probe threats. Most are of the type that help identify open and vulnerable VNC servers. We list a number of the tools we are aware of below. Note, we avoid including generic port scanning tools, but those may also be helpful to identify otherwise unknown VNC servers. CAUTION: Please use active probing and penetration testing tools responsibly. VNC server daemon 1
This is a small, fake VNC server daemon coded in Perl with syslog support, developed by
fakevnc 9
A small, fake VNC server coded in Python with syslog support.
Ncrack 10
Brought to you by the developer of Nmap, Ncrack performs brute force attacks against a handful of common application services including VNC.
THC-Hydra 11
The Hacker’s Choice tool is another brute force attack tool that includes support for VNC attacks.
VNCrack 12
Phonelit VNC cracking tool does remote and offline cracking.
Medusa 13
This brute force attack tool from Foofus.Net includes support for VNC.
Crowbar 14
Another brute force tool that includes support for VNC authentication.
Shodan 15
A search engine for Internet services such as known VNC server listeners. Requires an account some queries.

Commentary on filtering

Some networks actively packet filter a select set of applications based on TCP protocol ports and in fact some networks filter TCP port 5900 traffic between their network and others. Filtering on a specific port is at best an incomplete solution and depending on how it’s configured it may result in collateral damage to other, unrestricted traffic. Most VNC server implementations allow the listening port to be set to most any arbitrary value. A packet filter that allows any unexamined TCP traffic may therefore be bypassed by a savvy end user who configures a VNC server to use one of the allowed ports. If the port filter blocks TCP packets irrespective of the direction of the opening connection, benign traffic may be dropped if a client-side application happens to select the filtered port as it’s ephemeral port. A network administrator should carefully consider the implications of any filtering policy to optimally deny all the undesirable traffic, while permitting legitimate traffic.16


VNC threats have been known and seen in the wild for many years. The attack surface for many VNC servers is often insufficiently protected, but this rarely needs to be the case. Putting VNC authentication and session traffic on top of another system such as IPsec, SSH or SSL can nearly eliminate many anonymous VNC threats. The aim of any administrator should be to improve their monitoring, prevention, detection and response capabilities. The aim of this white paper was to help shed some light on VNC threats and countermeasures as a means to help improve your security posture in one or more of those four areas. We welcome your comments, feedback, and support. Contact us.

Pointers to Other Resources

  1. VNC server daemon [html↩︎ ↩︎

  2. IETF 6143 - The Remote Framebuffer Protocol [html↩︎

  3. SSH Password Authentication: Threats and Countermeasures [html↩︎

  4. Cisco IOS Netflow [html↩︎

  5. The Trojan.Hydraq Incident [html↩︎

  6. VNC RFB report [txt↩︎

  7. DShield Data Feeds [html↩︎

  8. Shadowserver reports [html↩︎

  9. fakevnc [html↩︎

  10. Ncrack [html↩︎

  11. THC-Hydra [html↩︎

  12. VNCrack [html↩︎

  13. Medusa [html↩︎

  14. Crowbar [html↩︎

  15. Shodan [html↩︎

  16. jtk blog post, Ops: Port filtering [html↩︎