Telephony fraud usually pays the attacker directly, without a buyer or a ransom in between. Nothing is stolen or encrypted, so the usual signs of a breach are absent. The loss shows up as call spend.
That shapes the defense. You cannot detect it by looking for anything unusual in the content of a call. The controls are all about where calls may go, how many there may be, and how much they may cost.
Why is this worth defending against if my system is locked down?
Because the value of a compromise is immediate and the window is short.
A stolen SIP credential, or an open port on a PBX, the business phone system that routes a company's calls, pays out as soon as it is used. The attacker's incentive is to dial as much as possible before anyone notices. The destinations that pay best are the ones a normal business never calls.
That last point is what makes an allow list effective rather than merely tidy. Most businesses call a small and stable set of countries. An attacker needs a specific and different set. Anything that forces the two to overlap costs the attacker their entire business model.
How do destination controls work?
Every country is either enabled for your workspace or not, and calls only reach the ones you turned on.
Two separate things decide what you can do with a country, and conflating them is the usual confusion:
- Availability says whether the country is yours to enable at all.
Availablemeans Bird can place calls there from your account.Not supportedmeans it cannot, and restoring it is a support conversation. - Your toggle says whether an available country is switched on. The change applies from the moment you make it.
So a country being available tells you nothing about whether calls are currently reaching it. That is the toggle, and it is the control you operate.
Some countries carry a high risk marker, which reflects both their rates and their fraud exposure. Those are the destinations an attacker is trying to reach. Keep them off unless the business genuinely calls them, and check what a call there costs before enabling one. The voice destinations page lists every country with its availability and enabled state, and voice pricing carries the rates.
A call refused for this reason is rejected with destination_not_enabled. The fix is to turn that country on rather than to retry.
Availability applies to a country as a whole. A specific number inside an enabled country can still be unreachable. That is rejected as no_route_found.
no_route_found covers more than one cause. Bird classifies the number you dialed before it looks at your destination settings. It refuses a type it does not route. Premium rate is the one that matters here: numbers whose termination pays the person who owns them, which is what an attacker dials. Shared-cost and personal-number ranges split the call charge or forward it to another line. Non-geographic numbers belong to no country's area code. All three are refused the same way. Those refusals are deliberate. They reach the numbers an attacker wants, because a premium range inside a country you enabled never gets past the classification. A number that is genuinely unreachable reports the same code, so check the type of the number you dialed before opening a ticket about it.
What limits an attack inside a country I do allow?
Three ceilings, each of which refuses a call on its own.
| Rejection reason | The ceiling it hit |
|---|---|
daily_spend_exceeded | Your organization's daily voice spend ceiling |
concurrent_calls_exceeded | As many calls in progress as the account allows |
calls_per_second_exceeded | New calls placed faster than the account allows |
insufficient_balance | The wallet did not cover the call, so it was refused up front |
The spend ceiling behaves most like a fraud control, because it is denominated in the thing the attacker is actually taking. It is also enforced on a different path from the other two. It resets at the start of the next UTC day, so a burst that hits it is contained until then rather than merely slowed. It is also the one that does not exist until you set it: an organization with no daily voice ceiling configured has no spend ceiling enforced at all.
The other two behave in two ways that change how you rely on them.
They are checked in order, not together. The concurrent-call ceiling is evaluated first and answers immediately, so a call that is over both ceilings reports concurrent_calls_exceeded and never mentions the dial rate. That matters for diagnosis rather than defense. A campaign dialer can hit calls_per_second_exceeded while nowhere near the concurrent ceiling. Check which one you actually got before changing a setting, because they have different fixes and raising the wrong one does nothing.
A ceiling whose own check cannot complete admits the call. If the concurrent count or the rate limiter cannot be evaluated, the call goes through rather than being refused. So these ceilings bound normal operation reliably and are not a guarantee under every condition. That is another reason the destination list matters: it is the layer that does not depend on a live lookup.
insufficient_balance acts as a control without being designed as one. The wallet caps how much fraud a compromise can run up. A large automatic top-up removes that cap, which makes the top-up amount a fraud decision as well as a convenience one.
Who can send calls to my trunk in the first place?
Only the addresses on the trunk's IP allow list, the API keys it allows and the session credentials it has minted can send it calls.
A SIP trunk decides who may send it calls, and a call from anywhere else is rejected with source_not_allowed before any destination logic runs. Outbound calls are also checked against your verified caller IDs, so a call presenting a number that is not verified for the workspace is rejected with caller_id_not_verified rather than placed.
Those two are worth auditing on the same schedule as your destination list, because a permissive allow list undoes the rest. SIP trunks covers the IP allow list, API key authentication and session credentials, and caller IDs covers verification.
What should I actually do?
- Enable the countries you call and no others, and treat the list as something to review rather than something to set once. A country enabled for one campaign two years ago is a standing exposure.
- Set a daily spend ceiling, and size it so you would notice it being hit rather than so it never triggers. There is no ceiling until you configure one, and a ceiling that never fires is not a control.
- Tighten the trunk's allow list, since everything above only matters to calls that got that far.
- Watch for the rejection reasons themselves. A sudden run of
destination_not_enabledorcalls_per_second_exceededis what an attack looks like when the controls are working. They are not noise to filter out of your logs; they are the alert.
Voice destinations covers enabling and disabling countries, and the call log lists every rejection reason with its fix.
简而言之
The attacker is paid by the destination, not by you.
They compromise a phone system and dial numbers they earn revenue from, so the cost lands on your account while the profit lands on theirs.
Countries are off until you turn them on.
A destination has to be enabled before calls reach it, so the blast radius of a compromise is the list you enabled rather than the whole world.
Availability and your toggle are different things.
Availability says whether a country is yours to enable at all. Your toggle says whether it is on. A country can be available and off.
Each ceiling refuses a call on its own.
Daily spend, concurrent calls and calls per second each stop a call by themselves. The spend one exists only once you set it. It resets at the start of the next UTC day.