SMS Pumping and Artificially Inflated Traffic: Detection Signals on Your Own Gateway

SMS pumping, also called artificially inflated traffic, is an attack on your messaging bill rather than on your data. Nobody steals a credential; the attacker arranges for a large number of messages to be sent to numbers they control or are paid for, and the cost lands on the sender.

This article covers what pumping looks like in the logs of your own hardware, the signals that separate it from a legitimate campaign spike, the controls available on the gateway itself, why form design is the most effective control, and what a gateway fundamentally cannot enforce.

What does SMS pumping look like in your own logs?

A burst to unfamiliar number ranges with no uptake.

Pumping shows up as a high volume of messages to a narrow set of prefixes, generated from a small number of sources, with almost none of the resulting codes being used.

The shape is what distinguishes it from a campaign. Real traffic has a distribution of destinations that reflects a customer base, and it produces a predictable proportion of completions. Pumped traffic is generated to order, so its destination distribution is narrow, its arrival pattern is machine-like, and the proportion of codes that are subsequently used is close to zero. Looking at those three properties together is more reliable than any single threshold.

Your own gateway is a good place to observe this because it records what was submitted and what happened next. Delivery outcomes and status reports follow the model defined in ETSI TS 123 040, and the destination numbers are structured according to the ITU-T E.164 plan, which is what makes prefix-level analysis possible at all. Without normalised numbers, an operator cannot group traffic into ranges, and grouping is the whole detection method.

Signal	Campaign traffic	Pumped traffic
Destination range	Broad, matching the customer base	Narrow, concentrated on few prefixes
Arrival pattern	Varies with time of day and campaign	Uniform or machine-like
Completion rate	A predictable proportion	Close to zero
Source concentration	Many sources over time	Few sources, high repetition

Which signals separate SMS pumping and artificially inflated traffic from a legitimate spike?

Completion, not volume.

A legitimate campaign can be large and fast, so volume alone proves nothing; the discriminating signal is how many of the codes that were sent were actually used.

That measurement requires linking the send to the event it was meant to enable, which is why detection is often an application problem rather than a gateway one. Where the platform records which verification codes were entered, the ratio of sent to completed is available directly. Where it does not, the ratio has to be inferred from later activity, and the inference is weaker.

Three supporting signals narrow the picture. Destination concentration, measured as the share of traffic going to the largest few prefixes, rises during an attack. Source concentration, measured as the share of requests from the largest few sources, rises as well. And the distribution of inter-arrival times becomes less variable than human behaviour normally produces. None of the three is decisive alone; together they distinguish an attack from a busy day.

SMS pumping and artificially inflated traffic detection: controls on your own hardware

Cap what a prefix can consume in a period.

A per-prefix ceiling limits how much damage any single destination range can do, and a velocity limit stops a burst before the ceiling is reached.

Both controls belong in the pacing layer described for any messaging deployment, and both have to be set from observed traffic rather than from a round number. The ceiling should be high enough that legitimate demand for a busy market is never throttled and low enough that an attack cannot generate an unbounded bill. That range is usually wide, which is why the setting is workable rather than delicate.

The velocity limit is the earlier control and the more useful one, because it acts within seconds while the ceiling acts over a period. Where the deployment can shape traffic by destination prefix, a limit expressed as messages per prefix per minute will slow an attack enough for detection to catch up. Where it cannot, the equivalent control has to sit in the application, which is the honest conclusion rather than a reason to skip the control.

Familiarity is worth measuring over time rather than per campaign. Keep a list of the prefixes your legitimate traffic actually reaches, refreshed monthly, and treat traffic to prefixes outside that list as something to examine. The list is not a block list, because markets expand and new prefixes appear legitimately; it is a filter that reduces the volume of traffic anyone has to look at during a busy week.

Record the pattern even when the investigation concludes that the traffic was legitimate. A near miss that is documented becomes the baseline for the next one, and the difference between a busy campaign and an attack is only visible when the two records sit next to each other.

How do you design the form so pumping is unattractive?

Make each message cost more to provoke than it earns.

Pumping is an economic attack, so the most effective controls are those that raise the attacker’s cost per message or remove the reward entirely.

Four measures are widely used. Rate limiting at the form, by source and by destination, removes the ability to generate volume quickly. A challenge that costs the requester something — a proof-of-work puzzle, a simple interaction, or a check that the request originated from a real browser session — raises the cost per attempt. Requiring the destination to be confirmed before messaging removes the reward for choosing a number the attacker controls but does not read. And validating that the destination is plausibly related to the service being requested reduces the fraction of requests that reach a pumpable range.

Authentication guidance is a useful reference for the last of these, since the design of verification flows and the treatment of rate limiting are covered in NIST SP 800-63B. The general principle is that a verification step should be cheap for a legitimate user and expensive to repeat at scale.

What the gateway cannot enforce

It cannot tell intent from traffic.

A gateway can limit rate, enforce ceilings and report patterns, but it cannot know whether the request behind a message is genuine, and it cannot decide on its own to stop serving a range.

That limitation matters when a deployment is looking for a technical fix to an economic problem. Any control the gateway applies is a rate control, and a determined attacker will stay below whatever rate is set because the margin per message is large. The controls that change the economics live at the form and in the application, where intent can be inferred from session behaviour and where a request can be refused before a message is generated at all.

The gateway’s contribution is therefore evidence and delay: evidence through logs that make the pattern visible, and delay through rate limits that slow the attack while a decision is made. Both are valuable, and neither is a complete answer. Advisory material on messaging abuse patterns, including the material published by CISA and the general guidance at CISA secure our world, is useful for understanding the broader abuse landscape that pumping belongs to.

An incident checklist

Work the list in order, because the first items bound the loss.

1. Apply a rate limit to the affected destination prefixes immediately, before investigating.
2. Identify the prefixes receiving traffic and the sources generating it.
3. Measure completion: how many codes were used, per prefix and per source.
4. Compare with the same measurement on a normal day, not with an absolute threshold.
5. Decide which traffic to block and who authorises blocking it.
6. Record the sequence, the volumes and the actions, since recovery may involve a commercial conversation.
7. Adjust the ceilings from what the incident revealed about legitimate demand.

The record matters because the cost of an attack is usually negotiated rather than absorbed. Refusal reasons on the network side are expressed with standardised cause codes, described in ITU-T Q.850, and having the vocabulary settled makes the operator conversation shorter.

Is SMS pumping the same as SMS spoofing?

No, and confusing them leads to the wrong controls.

Pumping inflates your cost by generating traffic, while spoofing misrepresents the sender, and smishing deceives the recipient into acting on a message.

The three attacks have different victims and different defences. Pumping targets the sender’s budget, and its controls are rate limits, form design and completion monitoring. Spoofing targets the trust in the sender identity, and its controls involve registration and identity rules. Smishing targets the recipient, and no control inside your platform addresses it. Searching for one topic returns material about the others, which is why the distinction is worth stating explicitly before a control is chosen.

Access-control objectives that support the response are organised in NIST SP 800-53 Rev. 5, and they cover the practical question of who may block traffic during an incident. That authority is worth deciding in advance, because an attack is the wrong moment to discover that nobody can act without a meeting.

{
“@context”: “https://schema.org”,
“@type”: “FAQPage”,
“mainEntity”: [
{
“@type”: “Question”,
“name”: “Can a gateway detect SMS pumping on its own?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Not reliably. A gateway sees volume, destination and outcome, which is enough to show a pattern and not enough to establish intent. The measurement that separates pumping from a busy campaign is completion, which lives in the application, so detection is normally a combination of gateway volume data and application completion data. Neither source is sufficient on its own, and the join between them is where the signal appears.”
}
},
{
“@type”: “Question”,
“name”: “Is SMS pumping fraud or an attack?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “It is an economic attack on the sender rather than a theft of data or credentials. The mechanism relies on sending high volumes to numbers that generate revenue or cost for the attacker. That is why the effective controls are economic ones, such as raising the cost per request, rather than purely technical filtering. A control that makes the attack unprofitable works even when detection does not.”
}
},
{
“@type”: “Question”,
“name”: “Should we block a prefix permanently after an attack?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Only with evidence and a decision owner, because prefixes contain legitimate users too. Blocking a range removes genuine traffic from that market, which may cost more than the attack. Apply a rate limit first, measure completion by prefix, and block narrowly rather than broadly when the evidence supports it. Record the decision and the date, because prefix allocations change. Any block should also carry an expiry date, so it is revisited rather than left in place for years.”
}
},
{
“@type”: “Question”,
“name”: “How do we know our ceilings are set correctly?”,
“acceptedAnswer”: {
“@type”: “Answer”,
“text”: “Test them against legitimate peak demand rather than against the attack. A ceiling that throttles real traffic during a busy period is too low; a ceiling that an attack reaches without being slowed is too high. Where the two overlap, the answer is a shorter period rather than a lower ceiling, since a per-minute limit constrains an attack more than a per-day limit does. Re-test whenever demand changes.”
}
}
]
}