Compromised Accounts & Outbound Abuse

An ESP's or hosting provider's single biggest self-inflicted reputation threat is abuse flowing outbound through its own infrastructure: a compromised customer account, a stolen credential, a hacked CMS, or a scripted signup flow pumping spam through shared IPs. This article digests three M³AAWG documents: the Compromised User ID Best Practices (v1.0.1, March 2018; original September 2014; document M3AAWG083), the Anti-Abuse BCP for Hosting and Cloud Service Providers (with the Internet Infrastructure Coalition, March 2015; M3AAWG0094), and the BCP for Mitigating Abuse of Web Messaging Systems (v1.1, March 2019; original 2010; M3AAWG032-2019).

Related: Abuse Desk Operations (report intake and remediation workflow), Customer Vetting (keeping intentional bad actors out), Blocklists & Spamhaus (AuthBL, listings caused by compromise).

Why this matters

• As direct botnet spamming from infected subscriber PCs got harder (port-25 blocking, community vigilance), spammers moved botnets to sending through compromised user email accounts — and, as spam filters improved at blocking direct SMTP connections, to scripting web-based messaging interfaces (webmail, e-cards, invitations, "share this article," comment forms, web→SMS gateways, REST messaging APIs).
• Providers should assume there will always be compromised accounts: attacks exploiting human susceptibility always succeed at some rate. The operational goal is fast detection, mitigation, and prevention of re-compromise — not the fantasy of zero compromise.
• Careful metric analysis matters before assuming the mechanism: what looks like account compromise may actually be abuse of the trial-account signup process (malicious registrations rather than hijacked customers). The two require different responses — see "Compromised vs malicious accounts" below.

Definitions (Compromised User ID BCP)

• User Account: a set of services provided to a user for exclusive use, secured by a password or other authentication method.
• Compromised User Account: a user account fully or partially under the unauthorized control of someone other than the legitimate user.

Out of scope of the BCP (but handled through the same channels): accounts created for abuse, compromised employee accounts (which need a heavier remediation approach), and one-time-action tricks (clickjacking, credential-stealing trojans, worms).

How accounts get compromised

• Credential compromise — unpatched vulnerabilities leak credentials, or an attacker steals a legitimate site's credential database for reuse elsewhere.
• Phishing — attacker impersonates a legitimate site/sender; users hand over credentials willingly.
• Keyloggers — compromised user machine captures everything typed.
• Theft of temporary credentials (cookies) — network sniffing on unencrypted connections, or XSS.
• Password guessing / brute force — common passwords across many accounts, or many passwords against one account.
• Also: social engineering of the account holder or of the provider's own employees.

Detection

Behavior-feedback sources

Attackers make a compromised account behave differently than its legitimate owner would. Good detection feeds:

• Account owners reporting their own account compromised (after seeing spam emitted from their address, etc.).
• Other users and third-party data providers reporting activity consistent with compromise.
• Behavior tracking and analysis against the account's established pattern — classic compromise indications: login from unexpected locations; suddenly messaging all contacts; deleting all sent mail.
• Consistently suspicious behaviors regardless of history: logins from widely separated geographies in short periods ("impossible travel"); messages containing hostile URLs.
• Feedback loops from other providers: an account suddenly generating a significant number of spam reports/complaints is in trouble. (See Complaint Feedback Loops.)

Advance-warning sources

Compromise often happens long before detectable abuse — attackers may sit on harvested credentials for weeks or months before the spam campaign starts. Tap third-party intelligence for early warning:

• Security researchers reporting discovered credential caches.
• Attackers publishing lists of compromised accounts.
• Notification of related compromise: compromised-account lists at one site identify linked accounts attackable at another — attackers follow those links, so defenders must too.
• Pattern propagation: once one compromised account is confirmed, use its characteristics to find others.

None of these methods is fully reliable. Verify accounts are actually compromised (or highly probably so) before acting; machine verification may not suffice — consulting the actual account owner may be required.

Compromised vs malicious accounts

Suspicious accounts are not necessarily compromised — the holder may be intentionally abusive (single account or mass registrations). A pattern of previous valid use is the key differentiator suggesting a genuine owner who lost control. The distinction drives the response: compromised accounts get recovered for their owners; fraudulent accounts get no data retrieval and no tip-off (see Abuse Desk Operations).

Registration-abuse patterns: for free/easy accounts, detection means spotting registration patterns (mass signups from an IP range, template data); for paid accounts, stolen or disposable credit cards; for high-touch accounts (e.g., advertiser accounts), holders suspiciously lax about the account requirements — surprising identity claims (unknown ad agency with top-name clients; distant "interior design firm" hungry for local representation; a large financial firm whose address is a mail drop), ignoring delays/rules other users question, or instantly reshaping their story to fit requirements.

Platform telemetry (Hosting & Web Messaging BCPs)

Set up internal telemetry reporting on the state of the network: network self-scans, traffic analysis, outbound spam filter monitoring. For web platforms, audit every abusable resource and track each; example baseline metrics:

• User/account metrics: new registrations, logins, password changes, account deactivations.
• Abusive transactions: visits to non-existent pages, suspicious query strings, visits to uncommon ports.
• Potentially suspicious transactions: total actions completed (messages sent, comments posted); identities that hit any limit or heuristic.

Collection and storage guidance: log-scraping is the commonest source, application hooks are better; retain data a week or longer to catch low-and-slow attackers; store the User-Agent string per login (attackers rarely match legitimate users' UA exactly, and some UA values are only ever seen from abusers); correlate across webmail, IMAP/POP, and MTA systems and share detected-abuser data between them. Hard statistics also make the budget case for anti-abuse work.

Proactive defense (Web Messaging BCP)

Three areas to defend, each independently exploitable: (1) the abuser's access to the UI, (2) the content a user may submit, (3) the distribution breadth of the content. The economics frame: every step an abuser must take has a cost; raise the cost until it exceeds the attack's value.

UI access

• Authentication: requiring an account raises attack cost. Account registration and provisioning deserve the same protections as messaging — or outsource authentication to established identity providers (accept credentials via API from major platforms; use OpenID Connect for standard, interoperable integration).
• Multifactor authentication: not a panacea but extremely useful against compromised-account abuse, since username+password no longer suffices. Second factors: SMS one-time codes, TOTP/HOTP authenticator apps or hardware, U2F public-key hardware tokens. Rollout advice: don't force-enroll everyone at once (support-call storm); start with previously compromised or high-risk users while offering self-enrollment to all; use risk-based enforcement — demand the second factor only on suspicious logins or sensitive actions (password change, sending to a large recipient count); allow "remembered devices."
• CAPTCHA: undeniably reduces abuse, but its cost to attackers keeps falling (OCR advances, cheap human solver sweatshops) — always use in conjunction with other techniques, and use a field-tested maintained implementation (e.g., reCAPTCHA), never homemade.
• Page hardening against scripting: randomize/vary page structure (changing HTML ids of required fields), obfuscate structure (JS-encrypted field names, AJAX-presented fields), lay honeypot traps (CSS-invisible fields humans skip but bots fill). Caveats: harms accessibility for non-visual users, and provides no true security — only added cost/hassle, which still deters casual attackers.
• Rate limiting: should be employed on almost all web services accepting or relaying user-generated content. Choose a stable identity handle to count on — combinations of remote IP, User-Agent, username, session/cookie ID, computed machine identifier. Implementations range from mod-security-style plugins to a simple counting server; example rule: 50 messages/hour and 100/day per user ID, then redirect to an error page. Protect every access point to the feature (all servers behind the load balancer) and don't rely on the client honoring redirects.
  • Rule-design pitfalls: legitimate spikes ("I just had a baby" to the whole address book); clustering misfires (an internet café IP = 20 users; a traveler logging in from many unusual locales). At the limit, prefer a straightforward message ("You are not allowed to send more than 100 messages per hour") over vague "suspicious activity detected" pages that drive support volume — spammers usually already know the limits, while legitimate users may be sharing NAT with an infected machine.
  • Dynamic blocking is rate limiting with a zero-transaction allowance. Third-party feeds can seed blocklists — Spamhaus AuthBL is applicable for auth-abuse; but beware repurposing lists (the PBL lists IPs that shouldn't connect to port 25 — completely inappropriate for blocking port 80).
  • IPv6: track ranges, not /128s — ISPs assign customers stable blocks, smallest typically /64, per-customer ranges from /64 up to /48; the vast space may require lowering thresholds. Carrier-grade NAT (dozens–hundreds of users per IPv4 address) may require raising them.
• Web application security: adhere to the OWASP Top 10.

Content filtering

• Least privilege: allow only the content types you must, allowlist rather than blocklist (blocklisting degenerates into whack-a-mole). Sanitize user-generated content with an engine more sophisticated than script-tag stripping (encoding tricks defeat primitive sanitizers; a sanitizer based on a real browser's rendering code detects far more). Restrict attachments/uploads by type and malware-scan them. Cap payload length to the intended need (a share-note needs ~200 characters, not 1000) to reduce the field's spam value.
• Heuristics: token/URL/string blocklists work but are manually maintained and easily evaded ("V.1agra", URL redirectors) — they need a scalable rule-population-and-expiry process. Alternatively integrate an open-source or proprietary spam-filtering engine into the submission path before accepting messages.
• Reputation models: online/offline models evolving with outbound content and sender profiles — e.g., user trust computed from account age, count of positive actions, count of suspicious actions; consult the model per questionable submission for a prior probability of spam.
• Batch analysis: the most flexible — cluster recent messages over a broad feature vector to find unexpected patterns (e.g., accounts all registered June 7 from one /16 all sending 103-word messages), then load the discovered patterns back into outbound filters.

Distribution controls

• Recipient limiting: cap recipients per message for untrusted users; in implicit-distribution systems (blogs, comments), require moderation or quarantine of new posts.
• Responses to a filtered "bad" message — three paths:
  • Challenge: grey-area messages trigger a further-validation UI — CAPTCHA or, increasingly, a second authentication factor. Layer the challenge UI with the same security as the submission UI; over-reliance on CAPTCHA lets attackers ship borderline spam for the price of an automated solver.
  • Quarantine: delay for extended automated examination (e.g., unusually large submission volume) or manual moderation.
  • Reject: deliver nothing. Silent deletion confuses users, generates support volume, and makes debugging miserable; overt rejection informs spammers. Most providers compromise: show an error, keep the wording vague/generic.

Containment and remediation (Compromised User ID BCP)

Returning a compromised account to its rightful owner: (1) identify, (2) remove inappropriate access and return control to the owner, (3) secure against re-compromise. Categorize the detection by compromise type — each needs different treatment:

Compromise type	Examples	Distinguishing characteristics	Mitigation	Requirements / recommendations
Temporary credential	Cookie theft via XSS or sniffing; session hijacking	Confined to actions the temporary credential permits	Invalidate the temporary credential; user re-authenticates with the permanent one	Issue temporary credentials with limited lifespan; bulk invalidation mechanism; let users invalidate their own suspect sessions
Permanent credential, mass exploit	Accounts spamming their contacts or operating as botnet nodes; credentials in a known dump	Large numbers of accounts, cookie-cutter exploitation, little customization; distinguished from abusive registration by a pattern of previous good behavior	Invalidate the compromised credential, force the owner to set a new one	Prompt for new password at login; lock out the old credential while still allowing owner reset; bulk force-change mechanism; make the change flow hard to automate (CAPTCHA, recovery questions) to raise attacker cost
Permanent credential, customized exploit	"Stranded traveler" scams — mail to the victim's contacts claiming a mugging abroad, asking for wired money	Hand-crafted per victim, but numerous victims; attacker socially/physically distant	Always requires human intervention by staff combining customer-service, fraud, and technical skills; sometimes the only option is canceling the account (owner indeterminable) or migrating contents to a fresh account	Escalation process to trained personnel; ability to freeze accounts in contention; ability to transfer account contents
Permanent credential, human exploit	Stalking of celebrities, ex-partners, family members	Personal scale; attacker physically or socially close to the victim, willing to invest heavily	As above — human intervention	Same: identify-and-freeze mechanisms, trained staff, staff access to relevant account data

Securing against re-compromise

After returning the account:

• Help the user find and remove back doors left by the exploit: altered contact mechanisms, email forwarding rules, reply-to addresses.
• Prevent password reuse; institute stronger password requirements.
• Request the user enable two-factor authentication where available.
• Educate the user about the compromise vector, if known.
• Notify other providers if the compromise involves their accounts.
• Encourage secure access protocols only (e.g., IMAPS instead of IMAP).

Re-compromised accounts

Repeatedly compromised accounts need special handling, not the same recovery loop again. Causes: false positives from flawed detection; compromise of something other than the credentials (the holder's computer, a network they frequent, or the provider itself); holders who lack the skills to protect credentials. Each requires separate handling; for the last, someone must be authorized to make the business call — retain the customer with special requirements, or send their business elsewhere.

Notification and self-service recovery

Detection alone prevents nothing — the compromise must be resolved and ownership restored, or the account taken offline. At any real scale this means an automated forced re-authentication mechanism, ideally self-service. The recovery channel must rely on information or access that does not automatically fall to an attacker upon compromise of the primary credential. Mechanisms and trade-offs:

• Secret questions — familiar to users, but: hard to verify automatically (free-form answers vary); users pick guessable ("what color is the sky") or researchable ("what school did you go to") answers; phishing routinely harvests secret-question answers, so attackers may already have them; users forget their own answers (worse when answers change over time — "favorite movie").
• Alternate contact methods (phone number or independent email for recovery codes) — easy to automate and understandable, but: users resist sharing cell numbers; entry errors are common and verification flows often abandoned; users set two accounts as reciprocal recovery contacts (one falls, both fall); password reuse means the recovery mailbox may be compromised with the same credentials; users don't update the contact after losing control of it, turning the safety measure into an attack route. Mitigate with required positive verification of the alternate contact, repeated periodically.
• Other account information (zip code, birth date, registration geolocation, previous passwords; for business relationships: "what was your last order?", "serial number on your modem?") — needs no special enrollment, but free-account providers deliberately collect minimal unverifiable data, so it's often unavailable; and it's hard to find data the attacker can't discover or change from inside the account. Automating such flows can even leak verification data to a not-yet-committed attacker (e.g., showing a picture-choice set reveals that one option is meaningful to the owner).

Hosting/infrastructure prevention baseline (Hosting Abuse BCP)

Context: responsibility for abuse handling varies by hosting model — the BCP's matrix runs from shared hosting (provider controls hardware/OS/software; abuse handled by provider and customer together) through VPS (provider owns virtual environment and OS; customer controls software and access), dedicated/unmanaged (customer controls OS+software; abuse issues land on the customer), managed (provider controls the stack), to reseller hosting — where customers resell to their own clients, and resellers-of-resellers add degrees of separation that create latency in abuse handling. Abuse types commonly seen: outbound spam, spamvertised sites, phishing (almost always via compromised end-user accounts running outdated scripts), hacked/defaced pages (most accounts compromised via out-of-date CMS installs — Joomla, WordPress), CSAM, copyright/trademark issues, DDoS/outbound hostile traffic (amplification, botnet C&C), and malicious signups ("whack-a-mole" multi-account/multi-platform).

Prevention practices:

• Require customers to keep software updated — contractually: OS, plugins, CMS, themes, hardware/firmware. Out-of-date software is one of the primary causes of hosting abuse; agreements should state it may violate the contract; enable automatic updates where possible. Encourage regular, securely stored backups so intruded servers can be restored to a known good state.
• Network-edge controls: intrusion detection/protection systems; automated web-app security scanning and penetration testing; a hardware or software firewall on every network minimum; promote web application firewalls (e.g., ModSecurity) for hosted clients — managed providers should manage a core WAF ruleset on client servers.
• Password and staff security: require complex passwords, offer 2FA, expire passwords at relatively short intervals, keep a per-client password/policy history. Provider-internal security is paramount — all customer-side measures are pointless if staff credentials are guessable; follow PCI-DSS-grade standards.
• IPv6: with no address scarcity, assign each customer a separate /64; even on the smallest shared systems every customer and website should have a unique address — easier abuse-source tracking, lets receivers block one offender without collateral damage, simplifies suspend/restore.
• Maximize customer contact: maintain multiple updated contact avenues (email, phone, chat, portals) so compromise notifications actually land; authenticate ongoing communications using the identity collected at vetting.
• Data security (Appendix 3): treat subscriber email-address databases as high-value criminal targets — "criminals rob banks because that's where the money is," and ESPs are where the addresses are. Maintain a comprehensive security program (OWASP, SANS resources; some members adhere to ISO/IEC 27002:2013 Access Control, Communications and Operations Management, and Incident Management controls). Never assume "only email addresses" makes a store an unattractive target.

For the complaint-driven remediation loop once outbound abuse is detected (validate → notify with ToS citation → remediation window → suspend → terminate; fraudulent accounts excluded from customer courtesies), see Abuse Desk Operations.