It's sometimes useful to scan a closed port (host discovery and fingerprinting).
Assuming TCP, VNC may use it, if you compare the DShield graphs for ports 5900, 5901, 5902, 5903 and 5904 there's some visible agreement between 5901, 5902, and 5904 but notably not with 5903. 5900 has too much background noise.
On a hunch, I compared permutations of ports, and found 5904 drops around when 5490 starts, but the number of target systems isn't comparable (nmap
tells me port 5490 is a HTTP/CONNECT proxy, but fairly scarcely seen, in the bottom 1%). So much for my hunch of a misfired scanner.
I can tell you that I have recorded (logs only, not packet captures or honeypot data) recent scans targeting TCP/5900,5901,5902,5904 (not 5903). Discounting 5900 (since that's constantly scanned) from 25 unique hosts.
All the destination 5904 probes came (notionally) from a single IP registered to a large French web/virtual hosting company, 80% of the total port 590{1,2,4} probes in all. Over a 60+ hour period from March 7-11 every probe used the same four source/destination port pairs, with target port 5904 being approx 50% of total. Different target ports were favoured on different days and by different hosts, scans possibly started on March 6 with port 5901. A low-rate, non-sequential, non-uniform scan (from 10-30 probes per host) of an IP block was performed. I suspect it was also network mapping attempt because an upstream device (on a different IP block) also recorded the same scans (source host & port, destination ports) interleaved with those scans.
Best guess is a distributed parallelised scan for VNC ports (with a generous addition of lesser-used ports) via hijacked hosts, and perhaps they got lucky with a well connected system in the unnamed French ISP which skewed port 5904 statistics. I cannot explain the omission of port 5903.