What SIP scanners reveal about themselves

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

In the first article, I described the SIP honeypot and the broad traffic volumes: 48,721,111 requests, 12,634,617 signatures, and 57,970 distinct IPs between November 2021 and September 2026.

This second part looks at behavior. The numbers do not attribute an attack to a person or organization, but they do reveal the strategies being used: broad exploration, insistent repetition, misleading User-Agents, identifier bruteforce, and recognizable probes.

A small minority of IPs produces a lot of traffic

Addresses are replaced by their rank. This ranking is stable only inside this dataset snapshot.

The top ten IPs total 4,308,050 requests, or 8.84% of all traffic. Their profiles differ significantly: IP-04 generates almost one signature per request, while IP-05 repeats a small set of signatures many times. The former looks like broad exploration; the latter looks like an insistent campaign over a more limited set of combinations.

This is behavioral interpretation, not attribution. An IP can be a compromised machine, a relay, a VPN, a reassigned address, or shared infrastructure.

/24 subnets

Grouping sources by /24 mostly helps check whether a large volume comes from a whole block or from one machine. In this snapshot, the most active prefix exceeds 1.32 million requests spread across 147 IPs, while another exceeds 542,000 requests with only one active IP.

High /24 volume does not always mean a distributed botnet. It can indicate a truly active range, but also a single very noisy source inside an otherwise quiet block.

How long does an IP remain visible?

For each IP, I calculated the difference between its first and last observation. It is better to call this an observation span rather than an activity duration: two requests separated by four years do not prove continuous activity between them.

• median duration: 40.4 hours;
• average duration: 59.9 days;
• 75% of IPs disappear in less than 69.9 days;
• 90% disappear in less than 144.8 days;
• maximum observed duration: 1,655 days, around four years and six months;
• 39 IPs were observed over a period longer than four years.

The contrast is clear: many addresses only pass through, but the long tail is real. Volumes become low after one year, yet they never fully drop to zero.

The oldest IPs are revealing. They mostly sent spaced-out OPTIONS requests. This looks like a stable probe or periodic check, but several explanations remain possible: a misconfigured legitimate service, a recurring scanner, equipment keeping a fixed IP, shared NAT, or reassignment of the same address to several machines.

User-Agents often lie

The User-Agent field looks tempting as an attribution source, but it is entirely controlled by the sender. A scanner can announce the name of a real softphone, use a fabricated string, or change identity for each campaign.

It should therefore be treated as a campaign indicator, not as a software identity. Its real value appears when it is crossed with the method, target, frequency, and time period.

The top ten strings together represent 34.4 million requests, about 70.6% of all observed traffic.

The hierarchy is very asymmetric: pplsip dominates, followed by a group of strings between 2.4 and 3.4 million requests. This ranking mainly says something about campaign families and tool configurations, not directly about operators.

These names do not mean that 3.4 million requests truly came from Polycom phones or that 3 million came from Avaya phones. In a SIP request, the scanner freely chooses its User-Agent. Reusing the name of common equipment may help mimic an endpoint, test specific rules, or simply reflect a tool default.

pplsip is the default User-Agent value in SIPPTS, Pepelux’s SIP tool suite. The string does not prove that every packet came from the official repository, because the -ua option is configurable and the code can be reused or modified, but it explains why this label appears massively in automated campaigns. friendly-scanner remains associated with SIPVicious, while strings such as erafsadfasfa look deliberately artificial. PBX and ims are more generic.

Large REGISTER volumes

REGISTER accounts for almost 33.4 million requests in the database. On this honeypot without user accounts, very large volumes are compatible with identifier discovery or automated bruteforce.

IPs are replaced with REG-01, REG-02, and so on. The “tested identifiers” column is the number of distinct caller values; the number of recipients is identical or almost identical here.

REG-01 and REG-03 combine high volume, one User-Agent, and tens of thousands of distinct identifiers over a short period. REG-10 concentrates more than 307,000 requests in less than a day. These profiles are strongly compatible with automated enumeration or bruteforce campaigns.

REG-05 and REG-07 are different: several User-Agents and activity spread over nearly two years. A single public IP may be shared, reassigned, or used by several machines; persistence alone is therefore not enough to conclude that there is one actor.

A few recognizable probes

Some traffic looks neither like REGISTER bruteforce nor like INVITE call attempts. There are also very occasional OPTIONS requests, often sent without a User-Agent, that are closer to service discovery for exposed SIP.

I keep the detailed analysis of these signatures for the next article, because it depends more on the From, To, Call-ID, and CSeq fields than on raw source volume. The important point here is simply that the corpus mixes insistent campaigns and much lighter probes.

What I take away

SIP traffic exposed on the Internet mixes several behaviors. Some look like very broad scanning, with few requests per IP. Others are far more insistent, with hundreds of thousands of REGISTER or INVITE attempts. User-Agents help group families of behavior, but they do not prove the identity of a tool or actor.

This behavioral reading is useful, but it still says little about the identifiers placed in SIP headers. That is the subject of the third article: What SIP identifiers reveal about scanners.

Methodological notes

• IP and /24 rankings are computed over the complete table, then anonymized by rank.
• No raw IP address is published in this article.
• An IP observation span is the difference between its oldest first_seen and newest last_seen. It does not measure continuous activity.
• A SIP User-Agent is declarative and should not be treated as attribution proof.