Comparing a SIP honeypot with APIBAN
After exploring more than four years of SIP traffic, I compared the sources observed by my honeypot with the active list from APIBAN. Historical overlap is low, but it increases sharply when looking close to the end of the collection period.
APIBAN is a blocklist service specialized in SIP traffic. It collects addresses seen as unwanted by distributed honeypots, then exposes these IPs to help VoIP servers block them before they generate scanning, enumeration, or call attempts. Its documentation says an address remains active for seven days, then must be observed again to be reactivated.
In the first three articles, I described the experiment and the observed behaviors: REGISTER bruteforce, INVITE attempts, misleading User-Agents, long-lived sources, SIP identifiers, and Nmap signatures. For this comparison, I use an updated export of 57,970 distinct IP addresses, whose latest observation was on September 9, 2026.
Overlap by time window and traffic type
The APIBAN snapshot downloaded on September 9, 2026 contained 1,952 active IPv4 addresses in the SIP dataset used for this comparison. I compared that list with three honeypot windows, then with two subsets: REGISTER sources and sources using the nm -> nm2 pair across all methods. That second set is mostly OPTIONS, with a few INVITE requests and one REGISTER.
| Source type | Full history | Last 30 days | Last 7 days |
|---|---|---|---|
| All methods | 1.10% 636/57,970 | 26.05% 192/737 | 56.22% 113/201 |
REGISTER | 0.12% 54/46,347 | 28.47% 39/137 | 75.00% 27/36 |
Over the last seven days, APIBAN finds 56.22% of all-method sources and 75.00% of REGISTER sources. The windows differ: 737 IPs over 30 days versus 201 over 7 days, including respectively 137 and 36 REGISTER sources.
The other direction gives a useful reference point: among the 1,952 IPs active in APIBAN that day, 636 had already been seen by my honeypot, or 32.58% of the list. This does not mean my sensor should have seen the rest: honeypots do not share the same address, region, or exact SIP behavior.
IPs observed for more than four years
The local export contains 39 IPs whose first and last observations are separated by more than four years. Among them, 4 appear in the APIBAN snapshot, or 10.26%.
This result shows that a small share of these long-lived addresses was still in the active APIBAN list at the time of comparison. It does not prove, however, that the same machine or actor used them for four years.
Rotation is plausible at two levels:
- scanners can distribute campaigns across many addresses and evolve their infrastructure;
- operators can reassign the same public IP to different subscribers or servers over time.
Conversely, some addresses may belong for a long time to a hosting provider, a measurement service, or infrastructure with fixed IPs. In this database, the longest-lived IPs mostly sent a few widely spaced OPTIONS requests. That looks more like a periodic probe or reuse of the same fingerprint than four years of continuous bruteforce.
What I take away
Comparing the full history to an active list gives only 1.10% overlap and says little. But the rate reaches 56.22% over the last seven days, and 75.00% for REGISTER sources in that same period.
The comparison therefore shows two things: independent sensors do overlap on part of the same sources, and temporal synchronization is essential to measure that overlap correctly.
In this snapshot, the overlap reaches 56.22% of recent sources and 75.00% of REGISTER sources. APIBAN provides a complementary signal to filter part of the SIP noise, but these proportions measure neither the share of blocked requests nor whether each IP was already listed at the exact moment it contacted the honeypot.
The recorded data is not perfect. It was collected with a fairly simple goal at first, then explored after the fact, with the limits that implies: aggregation by signature, imperfect time windows, and an APIBAN comparison decided only at the end. Even so, digging through this database and seeing coherent behaviors emerge was genuinely interesting.
If a V2 of the honeypot appears, the goal will be to keep more useful context and to measure how long it takes for an IP to appear in the list, how long it remains there, and the exact share of traffic already known at the moment it reaches the server.
Methodological notes
- APIBAN dataset used:
sip, 1,952 active IPv4 addresses. - Local honeypot export: 57,970 distinct IPs.
- The 30-day and 7-day windows are computed from the latest available observation.
- For
REGISTER, the filter uses the latest observation of that method. - Because
hitscounters are aggregated over the whole lifetime of a signature, the windows compare IP sets, not an exact number of requests received during those periods only. - No raw IP address is published in this article.