Attackers use IRSF, or International Revenue Share Fraud, to generate artificial calls to premium-rate or revenue-share numbers they control so they can collect call revenue. They may drive traffic through diallers, bots, or social engineering. Defenders should monitor call spikes, unusual destinations, short-duration patterns, and traffic that does not match normal customer behaviour.
How IRSF is typically executed
IRSF works by creating large volumes of chargeable traffic to numbers that route revenue back to the fraudster or an accomplice. The attacker’s goal is not to sell a service to real callers, but to manufacture billable usage, usually by exploiting telecom termination incentives, weak routing controls, or carriers that pay out on inbound volume.
In practice, the fraud often depends on scale and automation. Attackers may use autodiallers, bot-driven call origination, SIM farms, or social engineering to generate traffic that looks active enough to avoid immediate suppression. The Financial Crimes Enforcement Network is a useful reference point when the fraud intersects with suspicious payment flows, proceeds laundering, or reporting obligations.
What matters operationally is that IRSF is traffic abuse, not a one-off scam call. The abuse pattern is usually repetitive, distributed across many origins, and aimed at call destinations with an economic incentive attached to each minute or connection.
What the fraud depends on in the telecom path
The scheme usually works only when the attacker can control or influence where calls terminate, how long they stay up, and whether the revenue share is paid out before abuse is detected. That can involve premium-rate destinations, compromised or rented numbering assets, or arrangements that conceal the true beneficiary behind intermediaries.
In a broader threat context, the same behaviour sits alongside other telecom abuse patterns documented in CISA cyber threat advisories, especially where fraud is paired with infrastructure abuse, social engineering, or post-compromise monetisation. The key security issue is not just the calls themselves, but the hidden economic relationship behind them.
For defenders, the practical question is whether destination, duration, and origin patterns can be reconciled with legitimate demand. If they cannot, the traffic may be synthetic even when individual calls appear technically valid.
Why defenders focus on volume, destination, and calling pattern anomalies
IRSF is easiest to spot when you compare current traffic to normal customer behaviour. A spike in calls to a narrow set of international or premium destinations, many short-duration attempts, repeated calling from unusual source ranges, or traffic concentrated outside expected business hours are all strong indicators of abuse.
That is why MITRE ATT&CK Enterprise is useful here as a detection lens, even though IRSF is a fraud scheme rather than a classic endpoint intrusion. The attacker’s method relies on abuse of communications infrastructure, operational persistence, and scale, so defenders should think in terms of repeatable patterns, not isolated events.
Where carriers, resellers, or enterprise voice platforms expose APIs or automated provisioning, abuse can also resemble broad service misuse. In that sense, controls that limit abuse of externally reachable services are relevant, even when the final loss mechanism is call revenue rather than data theft.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
MITRE ATT&CK addresses the attack and risk surface, while CIS Controls v8 and NIST CSF 2.0 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-8 — Audit Log Management | Call-pattern anomalies depend on logs that preserve destination, duration, and origin detail. |
| Recommendation — Centralise call and billing logs so abuse patterns are detected before payout. | ||
| NIST CSF 2.0 | DE.CM-01 — Monitored Networks and Systems | IRSF detection depends on monitoring for abnormal communications activity and destination spikes. |
| RS.MA-01 — Incidents are Contained | IRSF response requires rapid suppression of abusive call paths and affected accounts. | |
| Recommendation — Monitor voice traffic for destination concentration and burst anomalies. Quarantine abusive trunks or accounts before further revenue accumulates. | ||
| MITRE ATT&CK | T1090 — Proxy | Abuse often hides the true origin or routing path behind intermediaries and call relays. |
| Recommendation — Map routing intermediaries to exposed abuse paths and tighten relay controls. | ||
Practitioner Guidance
What to prioritise: Build alerting around destination concentration, call duration, call burst patterns, and first-seen numbering ranges. Those signals are more actionable than raw call count because they distinguish legitimate spikes from revenue-driven abuse.
What to verify: Check whether your voice platform can attribute traffic to a customer, account, trunk, or reseller fast enough to suspend abuse before charges compound. If attribution lags behind billing, containment will be too slow to matter.
Escalation / exception: Treat repeated short calls to premium or international destinations as a billing and abuse event, not only a telecom anomaly. If the same pattern persists after rate limiting or blocklisting, assume the traffic path or account controls are being bypassed.
Practitioner takeaway: IRSF is best handled as a fraud problem with network indicators, not just a telecom noise problem. The fastest wins usually come from detecting abnormal destination economics early enough to stop the revenue flow before reconciliation catches up.