What SIP identifiers reveal about scanners

9/10/2026 :: en :: SIP, honeypot, VoIP, scan, security

In the first two articles, I described the SIP honeypot architecture, then the main behaviors observed: highly active sources, subnets, observation spans, User-Agents, and recognizable scans. One natural angle remained: the identifiers placed in the From and To headers.

These values are not verified identities. On the Internet, a SIP client can write almost anything in these fields. They are still interesting, because they reveal the strategy of a tool: testing a common extension, walking through a numeric range, calling an international destination, or simply checking that a SIP service answers.

The analysis uses the same MariaDB table as the previous articles: 12,634,617 signatures, representing 48,721,111 requests recognized as valid SIP messages by Kamailio, between November 30, 2021 and September 9, 2026. A signature groups the source IP, method, User-Agent, From, and To; its hits counter indicates how many times that combination was received.

Almost everything looks like a number

The database contains 618,429 distinct From values and 2,440,955 distinct To values. This difference is logical: the same caller identifier can be reused to try a very large number of destinations.

The most striking result is the symmetry: almost 71% of requests use the same identifier on both sides. The most frequent pairs are 100 -> 100, 101 -> 101, 1001 -> 1001, 201 -> 201, and 1000 -> 1000. This behavior is compatible with SIP extension enumeration: the tool places the tested extension in several parts of the request and observes the server response.

In this chart, numeric categories indicate the length of the To identifier in digits; text groups non-purely numeric values. The 42,311 requests with a missing To are excluded from the chart, but included in the full corpus. Short three- or four-digit extensions alone account for 26,918,525 requests, or 55.25% of the whole corpus. At the other end, numeric identifiers of thirteen digits or more represent 11,497,767 requests. This second family corresponds more to prefix variations and call attempts than to searching for a local extension.

The most tested extensions

The most frequent pairs are very classic: 100 -> 100 exceeds 341,000 requests, 101 -> 101 exceeds 284,000, followed by 1001, 201, 1000, 200, 2001, and 2000. This ranking does not point to one unique tool: these values appear in the habits of many phones, PBXs, homegrown scripts, and dictionaries.

Their presence across several thousand IPs mostly shows that scanners favor a small common vocabulary. Tools such as Nmap, SIPVicious, and SIPPTS can all walk numeric ranges, use dictionaries, or test very common starting values.

User-Agent plus identifier: a more useful clue

Crossing identifiers with the User-Agent makes some behaviors easier to read. For REGISTER requests where numeric From equals To, the largest families are:

Phone names do not prove that those devices really emitted the packets: the User-Agent is as easy to spoof as the From. A scanner can imitate a Polycom or Avaya phone to look like an ordinary client. Conversely, pplsip corresponds to SIPPTS’s default User-Agent, and friendly-scanner is historically associated with SIPVicious. These two strings are therefore more meaningful than PBX or ims, even though they remain configurable.

The pair pplsip + 125,671 tested identifiers is consistent with campaigns launched with SIPPTS or with a tool that keeps its default values. The pair friendly-scanner + 166,390 identifiers matches the SIPVicious operating style.

test, admin, and cisco are not tool signatures

Text identifiers are dominated by a few predictable words. test appears as From in 4,029,133 requests, cisco in 398,785, admin in 71,023, and GLOVO in 68,014.

The details for test show why attribution based on this field alone would be fragile:

Here, test is mostly a generic caller identity during campaigns that scan hundreds of thousands of destinations. User-Agents, periods, and IP counts differ enough to indicate several implementations or configurations.

The cisco case is similar. A campaign using pplsip produced 376,409 INVITE requests from only 31 IPs toward 54,619 targets. Some series methodically vary prefixes in front of the same number root. This looks more like a route generator or a phone fraud campaign than the behavior of authentic Cisco equipment.

GLOVO is even more concentrated: 68,014 requests, four IPs, and 63,199 destinations, mainly with a User-Agent imitating a Linksys SPA942 between April and May 2023. The word is distinctive in this corpus, but nothing allows a link to the company of the same name.

A few tool-shaped signatures

Some combinations are more meaningful than an isolated identifier. The pair nm -> nm2, almost always sent as OPTIONS without a User-Agent, represents 2,385 signatures, 4,275 requests, and 2,350 distinct IPs. It matches the shape of the SIPOptions probe published in nmap-service-probes, but the database does not preserve enough headers to make that a formal proof.

The same caution applies to pplsip. This User-Agent is the default value used by SIPPTS, and it appears with 6,791,909 REGISTER requests in the numeric From = To subset, 383 IPs, and 125,671 tested identifiers. This is consistent with SIPPTS or with tools that keep its default values, but the string remains configurable.

What can be concluded

This analysis reveals three main profiles:

1. Extension enumeration, dominated by three- or four-digit values and symmetric From=To pairs.
2. Telephone destination scanning, with a fixed From such as test, cisco, or GLOVO and tens or hundreds of thousands of different To values.
3. Service profiling, where Nmap’s nm -> nm2 probe is the clearest attributable example.

SIP identifiers are therefore useful to recognize intent and group campaigns. They are less reliable for naming a tool, except when a set of constants precisely matches a published probe. Serious attribution should combine as much as possible: method, From, To, User-Agent, Call-ID, CSeq, Via branch, header order, and emission rhythm.

The final part of the series changes scale: instead of looking only at what the honeypot knows, it compares its sources with a specialized external list. That is the topic of the next article: Comparing a SIP honeypot with APIBAN.

Limits

• The honeypot only keeps messages that Kamailio recognized as valid SIP. It does not measure transport fuzzing, invalid sockets, or messages rejected before parsing.
• The database stores usernames extracted from URIs, not complete SIP headers. Some useful attribution fingerprints were therefore lost.
• From, To, and User-Agent fields are declarative and easily falsified.
• Counters are aggregated by signature. A signature seen in one year may continue to accumulate hits in later years.
• The VPS was hosted by OVHcloud. Upstream filtering or protection may have modified the population of packets that actually reached the server.

Despite these limits, the data clearly shows the difference between scanning a SIP service, enumerating its extensions, and attempting telephone routes. That is precisely the value of keeping several attributes per request: no single value is decisive, but their combination eventually draws very recognizable behaviors.