Fake CAPTCHAs Fueling IRSF: The 120+ Keitaro Campaign Connection
Has anyone had a chance to deep dive into the Infoblox report regarding the massive surge in IRSF (International Revenue Share Fraud)? It’s wild how they’ve evolved from simple premium-rate dialers to sophisticated web-based scams.
The gist is that threat actors are renting phone numbers and using fake CAPTCHA verification pages to trick users into sending international SMS messages. The report highlights over 120 distinct campaigns utilizing the Keitaro traffic management system. For those unfamiliar, Keitaro is essentially a TDS (Traffic Direction System) often used in affiliate marketing, but here it's being abused to geofence victims and route traffic efficiently.
Technical Breakdown
The attack flow usually looks like this:
- User lands on a site (often via malvertising).
- Fake CAPTCHA overlay appears.
- JavaScript executes a hidden form submission or
sms:link trigger. - The user's device sends a text to a premium-rate number owned by the attacker.
Since the attackers are using Keitaro, detecting them can be tricky due to URL randomization. However, the underlying JS often gives it away. Here is a quick Python snippet to help scan for common suspicious patterns in downloaded landing pages:
import re
def check_scam_js(js_content):
# Pattern to look for sms: links or specific Keitaro API paths
sms_pattern = r'sms:\/\/[0-9]+'
keitaro_pattern = r'\/k\.php\?[^"\']+'
if re.search(sms_pattern, js_content, re.IGNORECASE):
return "Potential SMS Fraud Link found"
if re.search(keitaro_pattern, js_content):
return "Keitaro TDS fingerprint detected"
return "Clean"
We've started blocking known Keitaro campaign domains at the proxy level, but the infrastructure rotates so fast it feels like playing whack-a-mole.
**How are you guys handling this?** Are you focusing on user awareness regarding "verify you are human" prompts, or are you actively blocking TDS-related infrastructure at the perimeter?
We caught a similar campaign last month hitting our sales team. The Keitaro fingerprint is definitely the smoking gun. We deployed a Suricata rule to block outbound connections to known Keitaro management panels, but the attackers are increasingly using cloudflare-fronted domains to hide the backend.
For detection, we're actually monitoring for spikes in failed 404s or strange User-Agent strings that these traffic directors sometimes inject. It’s not perfect, but it gives us a heads-up before the helpdesk gets flooded with billing complaints.
From a red team perspective, this is surprisingly effective because it bypasses traditional email filters. The payload is just a link, and the 'malware' is the user's own phone.
One detection method we've recommended to clients is inspecting the Referer header on internal traffic. If you have internal users suddenly hitting a landing page that was referred from a suspicious URL shortener or an unrelated CDN, it's worth flagging. Also, blocking the specific country codes used for the premium-rate numbers at the SIP/SMS gateway level is a solid stopgap if your telco allows it.
Verified Access Required
To maintain the integrity of our intelligence feeds, only verified partners and security professionals can post replies.
Request Access