SIP Campaign Observed Across 39 Sensors Coming From The US

59,874 SIP Sessions in 24 Hours: Anatomy of a Coordinated VoIP Campaign

Over the past 24 hours (Feb 8-9, 2026), the SikkerNet sensor network recorded 59,874 SIP sessions across all 39 globally deployed sensors. Every single session originated from US-hosted infrastructure. Two IPs alone accounted for 78% of the total volume.

For context, SIP traffic outpaced SSH attacks during this window, unusual for US-originating activity, which typically dominates our SSH honeypots.

This post breaks down what happened, who did what, and what the traffic reveals about modern VoIP attack infrastructure.

The Data

All numbers come from a raw CSV export of session-level data from the SikkerNet Collector. Each row is one SIP session with transport, timing, auth attempts, call counts, and user agent metadata.

• 59,874 total sessions
• 366 unique source IPs
• 39 sensors targeted (every sensor in the network)
• 100% US-originating (geolocated to cloud and hosting providers)
• 7,375 sessions included actual SIP calls
• 705 sessions attempted authentication

Two Ports, Two Roles

Traffic split almost evenly between ports 5060 and 5061, but the behavior on each port was completely different.

Port 5061: Pure Scanning (28,903 sessions)

One IP — 103.195.101.98 (Miami) — generated 28,684 of the 28,903 sessions on port 5061. 99.3% were zero-byte: a TCP or UDP connection opened, nothing sent, connection held for ~5 minutes, then dropped.

The user agent string was just "VOIP" across all sessions. It hit 30 of 39 sensors.

Port 5061 is normally SIPS (SIP over TLS), but 99.2% of this traffic arrived over UDP, not even attempting a TLS handshake. This is transport-layer port scanning, mapping which hosts have something listening on 5061, with no intention of speaking SIP.

Port 5060: Real SIP Activity (30,971 sessions)

Port 5060 was where the actual probing happened. 98.5% of sessions sent at least one SIP request. Multiple distinct actors operated here, each with different tactics.

The Actors

Actor 1: The Scanner

103.195.101.98 — 28,684 sessions (48% of total)

Pure exposure mapping. Zero bytes, zero requests (99.3%), port 5061 only, 30 sensors. User agent "VOIP." This IP's job was answering one question: which of these hosts have port 5061 open?

Actor 2: The Caller

15.204.145.230 (Reston, VA) — 18,294 sessions (31% of total)

This IP produced 4,715 actual SIP calls across 26 sensors. Zero authentication attempts. Two user agents: "ciscocall" (99.4%) and "Linksys-SPA942" (0.6%). Every session targeted port 5060 over UDP.

The pattern was consistent: single-request sessions, device-like user agents designed to look like legitimate Cisco hardware, and high call volume with no interest in registering or authenticating. This is SIP enumeration — sending INVITE requests to discover which extensions answer, ring, or reject.

The SikkerNet SIP honeypot emulates a realistic Asterisk 18.12.1 PBX. When an INVITE targets a valid, registered extension, the sensor responds with 100 Trying, then 180 Ringing after a short delay, then 200 OK with a full SDP media answer including codec negotiation (PCMU, PCMA, G729, telephone-event). For extensions that exist but have no registered device, it returns 480 Temporarily Unavailable after ringing. For non-existent extensions, it returns 404 Not Found immediately.

This differentiation is intentional, it tries to mirror how real PBX systems behave and reveals how enumeration tools adapt their scanning based on response codes and timing.

Actor 3: The Extension Enumerator

38.248.90.115 (New York) — 414 sessions, 368 auth attempts, 329 unique usernames

User agent "ims" across all sessions. This actor cycled through hundreds of numeric extensions: sequential ranges, common defaults (100, 200, 300, 1000, 2000, 3000), and long numeric strings (999999, 9999999999, 99999999999). It was testing whether each extension existed by attempting REGISTER with digest authentication.

The honeypot always issues a 401 Unauthorized challenge with a proper RFC 2617 digest nonce, then accepts whatever credentials come back. This captures the exact username, nonce response, and digest hash from every attempt — useful for understanding what credential lists these tools carry.

Actor 4: The Targeted Brute Forcer

185.150.190.238 (Piscataway, NJ) — 1,975 sessions, 317 auth attempts, only 43 unique usernames

Unlike the enumerator above, this actor didn't scan widely. It repeatedly targeted a short list of specific extensions — 6255, 4104, 8409, 1000, 1940, 0 — hitting each one ~26 times. No user agent string. This behavior suggests a tool that already has a target list (from prior enumeration) and is now trying credentials against known-good extensions.

Actor 5: The Brute Force Sprayer

104.243.45.20 — 8 sessions, 101 auth attempts (12.6 per session), only 2 usernames

User agent "VaxSIPUserAgent/3.1." Rather than one attempt per session, this tool crammed multiple auth cycles into each connection. High attempt density, low username diversity — classic password spraying against a small number of known accounts.

Known Scanning Tools

532 sessions across 21 IPs used openly identified scanning tools:

• friendly-scanner — a well-known SIP scanning tool
• Xman-SIPScanner (versions 1.0, 6.2, 6.3) — another common VoIP reconnaissance tool

These represent a small fraction of total volume but confirm that purpose-built SIP attack tooling is active in the wild.

Uniform Session Timing

99.5% of sessions with recorded durations fell in the 5-10 minute window. Mean duration: 5.2 minutes. Median: 5.3 minutes. The clustering is remarkably tight.

This uniformity doesn't reflect real call lengths. The SikkerNet sensors enforce a 5-minute session timeout. What this tells us is that nearly every actor held connections open until timeout — either because their tooling doesn't send BYE to terminate cleanly, or because maintaining the session was part of their scanning strategy.

Only 211 sessions terminated in under 60 seconds — mostly from the explicit scanner tools (friendly-scanner, Xman) that send a single OPTIONS probe and disconnect.

Infrastructure Coordination

The data paints a clear picture of role separation:

1. Scanning (103.195.101.98): Map exposure on port 5061 across the internet. Zero application-layer interaction.
2. Calling/Enumeration (15.204.145.230): Send INVITE requests on port 5060 to discover valid extensions through response differentiation.
3. Auth Testing (38.248.90.115, 185.150.190.238, 104.243.45.20): Target discovered extensions with credential guessing — some broad, some targeted, some dense.

All from US cloud infrastructure. All within the same 24-hour window. All hitting the same sensor network. Whether this is one operator with multiple VPS instances or a coordinated group is impossible to say from network data alone, but the timing and targeting overlap is notable.

What the Honeypot Reveals

The SikkerNet SIP sensors aren't passive listeners — they engage. When attackers send REGISTER requests, they receive proper digest authentication challenges and successful registrations (the honeypot accepts all credentials). When attackers send INVITE requests, they hear ringing, get answered with full SDP media negotiation, and see realistic call state progression.

This interaction is what makes the data useful. A passive listener would see connection attempts and nothing else. By completing the SIP dialog, we capture:

• Credential lists — exact usernames and digest responses from every auth attempt
• Extension targeting — which ranges attackers scan, which defaults they expect
• Tool fingerprinting — user agent strings, SIP header patterns, connection behavior
• Call patterns — how enumeration tools handle ringing vs rejection vs timeout
• Infrastructure mapping — which IPs perform which role in the attack chain

The complete dataset is available through the SikkerAPI lookup endpoint — every source IP in this campaign has been scored and is queryable via the public API.