ES EN
Index

VoIP · Chapter 9

The one who wanted me to pay for their calls

This time no binary landed. A fraud did: for two hours, fifteen machines tried to make my PBX place 3,457 international calls — the trial run of an International Revenue Share Fraud (IRSF), with the bill in my name. A chapter with no Ghidra: just protocol, money and OSINT.

The previous eight chapters were all the same shape: someone gets in, drops a binary, and I take it apart. But the honeypot has forty services listening, and not all of them are about malware. This one is about money. No file landed — a phone fraud did, live, and it's a different kind of story that's just as worth telling.

The honeypot that caught it is SentryPeer, a VoIP decoy: it pretends to be a SIP phone switch on port 5060 and logs everyone who tries to use it to place calls. And for a little over two hours, plenty of people tried.

01What am I looking at

Before the teardown, the concept — because without it the logs mean nothing. There's a fraud called IRSF (International Revenue Share Fraud), and it works like this:

  • A fraudster rents a range of international premium-rate phone numbers — the kind that, when called, generate revenue shared between the carrier and whoever rented them.
  • Then they look for a misconfigured PBX belonging to someone else (a company phone system, a VoIP router) that will place calls without asking for credentials.
  • They make it call their numbers, thousands of times. Every completed call is money into their pocket… and onto the bill of whoever owns the PBX.

It's stealing using someone else's phone. My honeypot pretends to be exactly that misconfigured PBX — so I get to see, risking nothing, exactly who they'd call and with what tools.

02The catch

A window of 2 h 11 min, fifteen distinct machines, 210 numbers dialed and 3,457 call attempts (SIP INVITE messages). It wasn't a person: it's automated, industrial traffic. Here's one attempt exactly as it hits the decoy:

INVITE received on 5060 (number and IP masked)
INVITE sip:00.421232229XXX@XX.XX.XX.XX SIP/2.0
Via: SIP/2.0/UDP 172.26.196.11:55161;branch=z9hG4bK99242351
From: <sip:1001@XX.XX.XX.XX>;tag=508880652
To: <sip:00.421232229XXX@XX.XX.XX.XX>
User-Agent: Linksys-SPA942
...
m=audio 25282 RTP/AVP 0 101      # wants to open a voice channel

Read it as a command: "from extension 1001, call this number in Slovakia". The From: 1001 is a bluff — they're betting the PBX has a generic 1001 extension and lets it dial out. And the User-Agent says Linksys-SPA942, a perfectly ordinary desk phone: they disguise themselves as legitimate hardware.

03Three acts, three trades

Splitting the fifteen attackers by behavior, they're not all doing the same thing. There are three distinct roles — shared by six machines; the other nine stayed background noise, with no role to pin on them:

A

The one testing the lock (recon)

One IP shows up with the User-Agent friendly-scanner — the unmistakable signature of SIPVicious, the Swiss Army knife of SIP scanning. It calls no one: it just checks whether the PBX answers and what it allows. It's the equivalent of jiggling the door handle.

B

The one guessing extensions (brute force)

Two other IPs don't try to call: they send REGISTER requests trying extension numbers one after another — 3, 33, 404, 100, 101, 44444… They're hunting for an extension that exists and will let them register, so they can speak from inside. It's the same old credential brute force, but in telephony.

C

The ones already dialing (the fraud itself)

And the heavyweights: three machines that carry almost all of the volume, each hammering with its own tool. These don't probe — they call:

IPTool (User-Agent)Attempts
172.110.223.49pplsip1,339
94.26.31.62VOIP1,239
23.111.166.26Cisco-SIPGateway736

That pplsip isn't a phone: it's the default User-Agent of sippts, a SIP auditing suite in the style of SIPVicious, listed in the blocklists of SIP servers like Kamailio. The Cisco-SIPGateway is disguise — they pose as a Cisco gateway to slip past inattentive logs.

04The tell: probing the dial plan

And this is what says the most about the incident. One and the same London number shows up dialed over and over, with every prefix form imaginable:

the same number, every variant (masked)
+442037699XXX      0000442037699XXX
00.442037699XXX    000442037699XXX
00+442037699XXX    01144442037699XXX
0442037699XXX      00442037699XXX

It's not clumsiness: it's method. They don't know how my PBX's dial plan is set up — whether calling abroad needs a leading 00, 011, a 0 for an outside line, or nothing. So they try them all against the same known destination, hunting for the magic combination the PBX will agree to route. The moment one works, they'll repeat that one at scale. It's reconnaissance of the dialing syntax, disguised as noise.

The destinations, by prefix, are the usual IRSF map: the United Kingdom (+44), Italy (+39), Slovakia (+421), Canada (+1 289)… destinations where numbering is easy to rent and a call raises no eyebrows.

And a correction is due here, because I took it for granted myself at first: none of those numbers is premium-rate. +44 20 is London, +44 1904 is York and +1 289 is Ontario — all three ordinary geographic numbering. Which makes sense: at this stage they aren't billing yet, they're testing whether the PBX will route. For that you want a destination that sounds harmless and actually answers. The expensive numbering comes later, once they know the door opens.

05Where do they call from? — passive OSINT

As always, passive intelligence only: I ask the regional registries (RDAP/whois) and third-party databases. At no point do I touch the attackers' machines — that would be crossing to the other side. Where does each one live?

IPRoleHosting (OSINT)
172.110.223.49flood (pplsip)AS23470 ReliableSite.Net (US) · resold block
94.26.31.62flood (VOIP)AS29802 Hivelocity (US)
23.111.166.26flood (Cisco spoof)Hivelocity (US, Tampa)
158.51.78.101REGISTER brute2E Telekomünikasyon (Turkey)
185.114.48.195REGISTER bruteAS199792 ClearStack (NL)

And there's the interesting thread: two of the three heavyweights —the ones that attempted the most calls— live at the same provider, Hivelocity. It doesn't prove they're the same actor, but it fits a known pattern: VoIP fraud is run from cheap, disposable hosting, and when one goes down another comes up on the same farm. The rest spread across providers in the US, the Netherlands and Turkey — the same resilience logic we already saw in the botnets' infrastructure (Chapter 4).

What can't be known coldPassive OSINT tells me where the calling machines are hosted, not who's behind the premium numbering — that lives in opaque deals between carriers. As in the RedTail and Sysorbit chapters: the mechanism is fully visible; the identity of whoever gets paid isn't. And that's where I stop.

06Indicators (IOCs)

Ready to block at any SIP edge or feed into a list. Of the fifteen machines I publish the five with a role and volume; the scanner is given away better by its User-Agent than by its IP.

TypeValue
IPs (INVITE flood)172.110.223.49 · 94.26.31.62 · 23.111.166.26
IPs (REGISTER brute)158.51.78.101 · 185.114.48.195
Malicious User-Agentspplsip · friendly-scanner · VOIP · Cisco-SIPGateway (spoof)
Extension probedFrom: 1001 · REGISTER 3/33/404/100/101/44444
Test destinations observed+44 · +39 · +421 · +1 289 — for correlation, not for blocking
Volume3,457 INVITE · 210 numbers · 15 IPs · 2 h 11 min

07What I take away

  • Not every attack brings a binary. There's nothing here to open in Ghidra — the "weapon" is the SIP protocol itself, used exactly as designed, against a PBX that shouldn't allow it.
  • The User-Agent still gives them away. pplsip, friendly-scanner… attack tools announce themselves. Filtering by UA won't stop a pro, but it sweeps away 90% of the noise.
  • Fraud does reconnaissance too. Trying every prefix variant against a known number is as much "recon" as scanning ports — only here what's being mapped is the dial plan.
  • An open PBX is an open credit card. All of this only works if the switch places calls without authenticating. Registering extensions with real passwords and closing off unused international dialing defeats the whole fraud.

To be continued — the decoy stays lit, and not only on 22 and 5555: there are forty doors listening. When someone knocks on another one in an interesting way, there'll be a tenth chapter. 🍯

Comments