Telus, one of Canada's largest telecommunications providers, has warned customers that stolen credentials were used in a multi-month campaign to access subscriber accounts — exposing personal data and billing records. This was not a software vulnerability. There was no zero-day, no misconfiguration in a cloud bucket, no novel exploit chain. The attackers simply logged in.
That distinction matters enormously for defenders. When an adversary holds valid credentials, your perimeter stack — firewalls, WAF signatures, EDR — often has nothing to alert on. The attacker authenticates successfully, and from the application's perspective, the session looks legitimate. The Telus incident is a textbook case study in why identity telemetry, behavioral analytics, and credential hygiene have become the front line of defense for any organization operating customer-facing authentication portals.
If your organization operates a customer login portal, self-service billing system, or subscriber management platform, this threat model applies directly to you. Telecom accounts are particularly attractive targets because they contain billing records, call detail records, personal identifying information, and — critically — they are a launchpad for SIM-swap fraud and downstream account takeover of banking and email services that use SMS-based recovery.
Technical Analysis
What Happened
According to reporting, threat actors used credentials stolen from unrelated third-party breaches to authenticate against Telus customer accounts over a period spanning multiple months. The campaign pattern is consistent with classic credential stuffing (MITRE ATT&CK T1110.004):
- Credential acquisition: Attackers obtain username/password pairs from prior data breaches, combo lists sold on criminal marketplaces, or stealer-log aggregators.
- Automated validation: Tooling (e.g., OpenBullet, Sentry MBA, custom scripts) tests credential pairs against the login portal at scale, typically distributed across residential proxies or botnets to evade IP-based rate limiting.
- Account access: Successful logins expose subscriber personal data, account details, and billing records.
- Monetization: Telecom account access enables SIM swapping, interception of SMS 2FA for downstream banking/email takeover, phishing using accurate billing data, and resale of validated accounts.
Why Credential Stuffing Succeeds
- Password reuse: Industry studies consistently show 60%+ of users reuse passwords across services. Every third-party breach becomes raw material for attacks on your platform.
- Low-and-slow distribution: Multi-month campaigns deliberately throttle request rates and rotate source IPs to stay below volumetric detection thresholds. A single burst of 10,000 failed logins gets caught; 200 logins per day from 200 rotating residential IPs often does not.
- Successful-auth blind spots: Most SOC playbooks alert on failed authentication anomalies. A credential stuffer who succeeds on the first or second attempt generates a successful login event that blends into normal customer traffic unless you have impossible-travel, device-fingerprint, or new-IP baselining in place.
Exploitation Status
This is confirmed, active, in-the-wild abuse — not theoretical. Credential stuffing remains one of the highest-volume attack techniques against consumer-facing authentication globally, and telecom/billing portals are consistently targeted because of the downstream fraud value. No CVE is associated with this incident; the "vulnerability" is reused passwords and insufficient login security controls.
Detection & Response
The detections below target the observable behaviors of credential stuffing and account takeover: impossible travel, first-time IP/ASN authentication, distributed failed-login patterns, and anomalous session sources. They are written for customer-facing identity telemetry (IdP logs, WAF/auth gateway logs ingested into your SIEM) — adapt field names to your identity provider's schema.
---
title: Distributed Credential Stuffing Against Customer Portal
description: Detects a high volume of failed authentication attempts against a customer-facing login portal originating from many distinct source IPs targeting many distinct accounts within a short window — characteristic of distributed credential stuffing via proxy rotation.
references:
- https://attack.mitre.org/techniques/T1110/004/
- https://www.securityweek.com/telus-warns-customers-of-account-breaches/
author: Security Arsenal
status: experimental
date: 2026/04/06
id: 3f9c1a7e-2b48-4d65-9a01-7c8e2f4b9d31
logsource:
category: authentication
product: azure
service: signinlogs
detection:
selection:
ResultType: 50126
condition: selection
falsepositives:
- Legitimate user password typos from a small set of IPs; tune thresholds to baseline
- Corporate NAT egress if customers authenticate through enterprise proxies
level: high
---
title: Successful Login From New Country or ASN After Failed Attempts
description: Detects a successful customer portal authentication from a geographic location or ASN never before seen for that account, particularly when preceded by failed attempts — indicative of credential stuffing success and account takeover.
references:
- https://attack.mitre.org/techniques/T1078/
- https://attack.mitre.org/techniques/T1110/004/
author: Security Arsenal
status: experimental
date: 2026/04/06
id: 8b2d4e61-9c3a-4f77-b5e2-1a6d9c3f8e47
logsource:
category: authentication
product: azure
service: signinlogs
detection:
selection:
ResultType: 0
RiskDetail|contains:
- 'unfamiliarFeatures'
- 'anonymizedIPAddress'
- 'maliciousIPAddress'
condition: selection
falsepositives:
- Customers traveling internationally
- VPN usage by legitimate customers; correlate with device fingerprint and MFA result
level: medium
---
title: Password Spray Pattern Across Customer Accounts
description: Detects a small number of common passwords attempted against a large number of distinct accounts from single or few source IPs — a password spraying pattern that avoids per-account lockout thresholds.
references:
- https://attack.mitre.org/techniques/T1110/003/
author: Security Arsenal
status: experimental
date: 2026/04/06
id: c1a5f8d3-6e2b-4a91-8c74-5d9e2b7f1a36
logsource:
category: authentication
product: azure
service: signinlogs
detection:
selection:
ResultType:
- 50126
- 50053
condition: selection
falsepositives:
- Shared kiosk environments; tune per-environment
level: high
Note: the Sigma rules above assume authentication telemetry flowing from an IdP or auth gateway. For the threshold logic ("many IPs, many accounts"), implement the aggregation in your SIEM — Sigma's standard schema does not natively express cardinality, which is exactly what the KQL hunt below provides.
// Credential stuffing hunt: high-cardinality source IPs with high failure ratios
// targeting the customer login portal. Adjust TimeGenerated window and thresholds
// to your baseline. Works against Azure AD/Entra sign-in logs or custom auth logs
// ingested into Sentinel.
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType != 0
| summarize
FailedAttempts = count(),
DistinctAccounts = dcount(UserPrincipalName),
DistinctIPs = dcount(IPAddress)
by IPAddress, bin(TimeGenerated, 15m)
| where DistinctAccounts > 20 or (DistinctIPs > 50 and FailedAttempts > 100)
| sort by FailedAttempts desc;
// Successful logins from first-seen ASN/geography per account (ATO detection)
let Lookback = 30d;
let KnownLocations =
SigninLogs
| where TimeGenerated between (ago(Lookback + 1d) .. ago(1d))
| where ResultType == 0
| summarize by UserPrincipalName, Location, NetworkLocationDetails;
SigninLogs
| where TimeGenerated > ago(24h)
| where ResultType == 0
| extend AuthMethod = tostring(AuthenticationDetails[0].authenticationMethod)
| where AuthMethod !has "MFA" and AuthMethod !has "Previously satisfied"
| project TimeGenerated, UserPrincipalName, IPAddress, Location, AppDisplayName, AuthMethod, UserAgent
| where UserPrincipalName !in~ (KnownLocations | where Location == Location | project UserPrincipalName)
| join kind=leftanti (KnownLocations) on UserPrincipalName, Location
| sort by TimeGenerated desc;
// Password spray: few IPs, many accounts, single failure code
SigninLogs
| where TimeGenerated > ago(6h)
| where ResultType in ("50126", "50053")
| summarize Accounts = dcount(UserPrincipalName), Attempts = count() by IPAddress, ResultType, bin(TimeGenerated, 30m)
| where Accounts > 15
| sort by Accounts desc;
-- Hunt for automated credential-testing tooling artifacts on systems
-- that should not be running them (workstations, jump hosts, app servers).
-- Credential stuffing kits (OpenBullet, SilverBullet, custom runners)
-- leave distinctive process, file, and config artifacts.
SELECT Pid, Name, CommandLine, Exe, Username, CreateTime
FROM pslist()
WHERE Name =~ '(?i)(openbullet|silverbullet|sentry|snipr|blackbullet|stalker)'
OR CommandLine =~ '(?i)(combo|wordlist|proxylist|hits\.txt|config\.loli|anom)'
OR Exe =~ '(?i)(openbullet|bullet)'
-- Also sweep common staging paths for combo lists and hit files
SELECT FullPath, Size, Mtime
FROM glob(globs=[
'C:/Users/*/Downloads/*combo*',
'C:/Users/*/Downloads/*hits*.txt',
'C:/Users/*/Desktop/*openbullet*',
'C:/ProgramData/*/*combo*.txt',
'/tmp/*combo*',
'/home/*/*hits*.txt'
])
WHERE Size > 10000
Remediation Script
The script below audits authentication logs on a Linux-based customer portal or auth gateway for credential-stuffing indicators — high failure-rate source IPs, distributed single-attempt patterns, and user-agents associated with stuffing frameworks — and optionally blocks the worst offenders at the host firewall as a stopgap while you engage your WAF/CDN controls.
#!/usr/bin/env bash
# credential-stuffing-triage.sh — identify and optionally block stuffing sources
# Adjust LOG_PATH to your auth gateway / reverse proxy access log format.
set -euo pipefail
LOG_PATH="${1:-/var/log/nginx/access.log}"
WINDOW_MIN="${2:-60}"
FAIL_THRESHOLD=25 # failed auths per IP in window
DISTINCT_ACCT_THRESHOLD=15 # distinct accounts per IP in window
BLOCK="${3:-no}" # pass "block" as third arg to nft-block offenders
SINCE=$(date -d "${WINDOW_MIN} minutes ago" '+%d/%b/%Y:%H:%M')
echo "[*] Analyzing ${LOG_PATH} for failed-auth patterns since ${SINCE}"
# Extract IPs hitting the login endpoint with 401/403 responses
echo "[+] Top offending IPs by failed login count:"
awk -v since="$SINCE" '$4 >= "["since && ($9 == 401 || $9 == 403) && $7 ~ /login|auth/ {print $1}' \
"$LOG_PATH" | sort | uniq -c | sort -rn | head -25 | tee /tmp/stuffing_ips.txt
echo "[+] IPs targeting many distinct accounts (stuffing/spray signature):"
grep -E 'login|auth' "$LOG_PATH" | grep -E ' 401 | 403 ' | \
awk '{print $1, $7}' | sort -u | awk '{print $1}' | \
sort | uniq -c | awk -v t="$DISTINCT_ACCT_THRESHOLD" '$1 >= t {print}' | \
sort -rn | head -25
echo "[+] Suspicious automation user-agents:"
grep -iE 'python-requests|curl/|wget/|go-http-client|okhttp|java/' "$LOG_PATH" | \
grep -E 'login|auth' | awk '{print $1, $12, $13}' | sort | uniq -c | sort -rn | head -15
if [ "$BLOCK" = "block" ]; then
echo "[!] Blocking top offenders via nftables (STOPGAP — prefer WAF/CDN rules)"
nft list table inet stuffing_block >/dev/null 2>&1 || \
{ nft add table inet stuffing_block; \
nft add chain inet stuffing_block input '{ type filter hook input priority 0; }'; }
awk '$1 >= '"$FAIL_THRESHOLD"' {print $2}' /tmp/stuffing_ips.txt | while read -r ip; do
nft add element inet stuffing_block blocklist "{ $ip }" 2>/dev/null || \
nft add rule inet stuffing_block input ip saddr "$ip" drop
echo " blocked: $ip"
done
fi
echo "[*] Done. Review output, validate against legitimate traffic, and"
echo " escalate persistent sources to your WAF/CDN provider for durable blocking."
Remediation
There is no patch for this threat — remediation is architectural and procedural. Prioritize in this order:
For Organizations Operating Customer-Facing Authentication
- Enforce MFA on customer accounts — and make it phishing-resistant where possible. This is the single control that would have neutered the Telus campaign. Stolen passwords are worthless when a second factor gates the session. Prefer TOTP or push-based MFA over SMS (telecom-targeted attackers specifically exploit SMS via SIM swap). For high-value account changes (SIM change, number port-out, billing address change), require step-up re-authentication.
- Deploy breached-password screening. Check passwords at login and reset against known-compromised credential corpora (e.g., k-anonymity APIs such as Have I Been Pwned's Pwned Passwords, or commercial equivalents). Force rotation on match.
- Implement layered rate limiting and bot mitigation. Per-IP and per-account throttling alone is insufficient against distributed campaigns. Add device fingerprinting, JavaScript challenges, and a commercial bot-defense layer (or CDN-native equivalent) that can identify residential proxy networks and headless automation frameworks.
- Baseline and alert on successful-authentication anomalies. Impossible travel, first-seen ASN/country, first-seen device, and login-time clustering relative to customer timezone. The multi-month dwell time in this campaign is the clearest argument for behavior-based detection over signature-based blocking.
- Monitor for your customers' credentials appearing in breach corpora and stealer logs. Proactive forced resets for accounts confirmed in combo lists shrink the attack window before stuffing begins.
- Harden high-risk account actions. SIM swaps, port-outs, and contact-info changes should trigger out-of-band customer notification (email + app push) with a cooling-off period. This limits blast radius when ATO does occur.
- Run the detections above against your auth telemetry now. A 90-day lookback for first-seen-ASN successful logins and distributed failure patterns will tell you whether you already have a quiet campaign in progress.
For Affected Customers (and Your User-Awareness Messaging)
- Change the Telus account password immediately and anywhere else that password was reused — reuse is what makes stuffing work.
- Enable MFA on the account and prefer app-based authenticators over SMS.
- Review billing records and account changes for unauthorized modifications (added lines, changed contact info, forwarded numbers).
- Watch for targeted phishing using accurate billing details — attackers armed with real invoice data produce highly convincing lures.
- Consider credit monitoring if personal data exposure is confirmed, and place a port-out/SIM-change lock with the carrier.
IR Considerations
If your own portal shows evidence of a similar campaign: preserve raw auth logs and WAF telemetry before rotation, enumerate the set of successfully accessed accounts (successful logins from stuffing-associated IPs/ASNs), scope exactly what data each compromised account could expose, and engage breach counsel early — notification obligations under PIPEDA, GDPR, or US state breach statutes are triggered by the data accessed, not by how the attacker got in. Security Arsenal's incident response team can assist with scoping, identity-forensics, and regulatory-driven notification workflows.
Related Resources
Security Arsenal Incident Response Services AlertMonitor Platform Book a SOC Assessment incident-response Intel Hub
Is your security operations ready?
Get a free SOC assessment or see how AlertMonitor cuts through alert noise with automated triage.