Four years with a SIP honeypot exposed on the Internet
A public SIP server almost always ends up being discovered once it remains exposed on the Internet. Even with decent passwords and protections such as automatic blocking after too many failures, it is often only a matter of time before scanners try username/password pairs, common extensions, or international destinations. And when a real PBX lets calls go through outside the plan or toward international numbers, the bill can become painfully expensive.
I installed this SIP honeypot as a personal experiment, mostly out of curiosity. I wanted to see what would spontaneously reach a SIP service exposed on the Internet. After several years of operation, before reinstalling the server cleanly, I analyzed the accumulated statistics.
The figures below come from an instance observed from November 30, 2021 to September 9, 2026. IP addresses and SIP identifiers are anonymized or aggregated. The server does not relay calls and does not provide any usable account.
Why SIP attracts so much noise
SIP, the Session Initiation Protocol, is used to establish multimedia sessions, most commonly VoIP calls. An exposed SIP server can therefore interest several kinds of actors:
- those who simply want to check whether equipment answers;
- those who inventory Internet-facing services;
- those who test accounts or extensions;
- those who try to trigger fraudulent outbound calls.
On a real PBX, a REGISTER request can be perfectly normal: it lets a phone or softphone register. On this honeypot, no extension exists. A burst of REGISTER requests is therefore mainly a signal of enumeration or bruteforce activity.
The same logic applies to INVITE: on legitimate infrastructure, this method initiates a call. Here, it looks more like a routing test: will this server accept a call to this number? Does an international prefix work? Does a presentation variant change the response?
Collection architecture
The instance runs on a Debian VPS hosted by OVHcloud. Kamailio receives the SIP packets and extracts a few attributes: source address, SIP method, User-Agent, caller identifier, and called number. A dedicated route then computes an MD5 fingerprint of that combination and writes the result to MariaDB.
The deduplication key is this combination:
source IP + method + User-Agent + From user + To user
A new combination creates a row. If the same combination appears again, the honeypot increments hits and updates last_seen. This greatly reduces storage compared with keeping every raw packet, while still making repeated behavior visible.
The main model includes:
| Field | Role |
|---|---|
methode | Observed SIP method: REGISTER, INVITE, OPTIONS, etc. |
ip_address | Source address stored as a number |
ua | User-Agent header declared by the client |
from_uri_username | Caller identifier |
to_uri_username | Targeted identifier or number |
hits | Number of repeats of the same signature |
first_seen, last_seen | First and last observation of that signature |
hash | Unique fingerprint of the signature |
This collection does not see everything that touched the server. Network protections may intervene upstream, and Kamailio discards packets that do not look like usable SIP. The figures below therefore describe requests that were received, recognized, and parsed, not every bit of noise that reached the port.
What the database contains
In the analyzed snapshot, the database contains:
- 48,721,111 requests recognized as SIP;
- 12,634,617 distinct signatures;
- 57,970 distinct IP addresses;
- an observation range from November 30, 2021 to September 9, 2026;
- about 1.59 GB of data.
A signature is not necessarily one request: the hits column aggregates repeats. On average, a signature was therefore observed 3.86 times.
Two methods account for almost all traffic: REGISTER and INVITE.
| Method | Signatures | Requests | Share of requests |
|---|---|---|---|
| REGISTER | 5,771,958 | 33,392,795 | 68.54% |
| INVITE | 6,353,732 | 14,506,866 | 29.78% |
| ACK | 432,021 | 641,530 | 1.32% |
| CANCEL | 60,408 | 95,907 | 0.20% |
| OPTIONS | 12,920 | 76,443 | 0.16% |
| BYE | 2,121 | 4,939 | 0.01% |
| Others | 1,457 | 2,631 | < 0.01% |
REGISTER and INVITE together represent 98.31% of observed requests. This is not very surprising: these are the two most interesting gestures for an attacker looking either for a usable account or for an exploitable call route.
SIP methods in practice
REGISTER normally associates a user with an endpoint. On this honeypot without accounts, it generally indicates reconnaissance or an authentication attempt. With 33,392,795 requests grouped into 5,771,958 signatures, it shows many repeats. The ratio between signatures and hits is consistent with actors retrying the same combinations.
INVITE initiates a SIP session, most often a call. The 14,506,866 INVITE requests observed suggest exploration of telephone routes: international numbers, alternative prefixes, and variations around the same recipient.
The minority methods also add context. OPTIONS is often used to check whether an endpoint answers. ACK is normally part of the dialog created by an INVITE. MESSAGE carries SIP instant messaging. REFER asks an endpoint to initiate another session and deserves special attention when it arrives from the Internet.
The long tail contains valid methods, typos such as INVATE or ivite, and even verbs unrelated to SIP such as HELLO, PING, TRACE, or SYNC. These anomalies are useful: they reveal generic tools, approximate parsers, or traffic sent to the wrong protocol.
What this first snapshot says
This database does not measure “SIP attacks on the Internet.” It measures what reached one IP address, one port, one transport, and one response behavior over a little more than four and a half years.
Even with that limitation, the order of magnitude is telling. A simple SIP server, with no usable account and no ability to relay calls, still received more than 48 million usable requests. Most traffic targets account registration and call attempts, the two surfaces most directly monetizable in a VoIP context.
The next part of the analysis looks at who generates this traffic: how many IPs come back often, how many disappear immediately, what User-Agents say, and what scan signatures can be recognized. That is the subject of the second article: What SIP scanners reveal about themselves.
Methodological notes
- Main source: MariaDB table
honeypot.requests. - Exact count: 12,634,617 signatures, 48,721,111 aggregated requests, and 57,970 distinct IPs.
- First and last observations in the snapshot: November 30, 2021 and September 9, 2026.
- IP addresses and SIP identifiers are not published in this article.