It's time for another quick analysis of a prevalent SIP scanner that has been active for the last 4-5 months. It is particularly interesting because it is spreading like a worm, seems to use multiple scanning techniques (ssh and SIP) and acts like a botnet.
This scanner likely responsible for the uptick in port 5060 (SIP) scanning noted on this SANS Internet Storm Center diary entry. We noticed this scanner first hit our honeypots on July 8, at the same time SANS posted the note about significant increase in UDP port 5060 (SIP) scanning.
First of all, here is a redacted version of the contents of a typical scan:
Source: 124.89.88.18:5060
Datetime: 2010-07-09 hh.mm.ss
Message:
OPTIONS sip:100@honeypot_IP_removed SIP/2.0
Via: SIP/2.0/UDP 192.168.1.9:5060;branch=zqwehwebK-0523432245;rport
Content-Length: 0
From: "sipsscuser"<sip:[email protected]>; tag=removed
Accept: application/sdp
User-Agent: sundayddr
To: "sipssc"<sip:[email protected]>
Contact: sip:[email protected]:5060
CSeq: 1 OPTIONS
Call-ID: removed...
Max-Forwards: 70
Note the order and layout of the SIP headers is very similar to that of the sipvicious tool, which I described in an earlier blog entry. This suggests that a modified version of sipvicious is being used. It is trivial to modify sipvicious in this way, just by changing the python script.
- "sundayddr" replaces the usual "friendly-scanner" in the User-Agent header
- "sipsscuser" replaces the usual "sipvicious" in the From header
- The source extension is now set to [email protected], changed from [email protected] in original sipvicious tool.

Up till today (this analysis and graphics were done in early in August) we now detected these scans coming from hundreds more IP addresses. This indicates we are dealing with a botnet, not the opportunistic scans from single IP's that we more often see. Of course it is technically possible that UDP spoofing could be the cause of these multiple IP's, but it is reasonable to rule this out in this case, as it would not make any sense to spoof the UDP messages because the attacker would not get a response to the SIP scan.



Although we haven't located the kit responsible for this, here is a theory put forward by a security colleague, and which is fairly strongly supported by our results: The scanning network most likely consists of Unix-like systems that offer ssh login, and that have weak passwords that can easily be brute forced, and the sequence of events may be as follows.
This scanner is still very active today. An IP from China scanned one of our Australian honeypots as I was writing this, on 27 October 2010.
Using a self propogating/botnet-like infrastructure is just another evolution of malicious SIP scanning, and it is evident that more and more development is being put into systems that can automate the discovery of vulnerable SIP servers, for subsequent nefarious use.