Compromised Accounts & Outbound Abuse

If you run an email service provider (ESP) or a hosting service, the biggest threat to your reputation that you cause yourself is abuse leaving outbound through your own infrastructure. It can come from a compromised customer account, a stolen credential, a hacked content management system (CMS), or a scripted signup flow pushing spam through shared IP addresses.

Three documents from the Messaging, Malware and Mobile Anti-Abuse Working Group (M3AAWG) cover detection, containment and remediation:

• the Compromised User ID Best Practices (v1.0.1, March 2018; first published September 2014; document M3AAWG083);
• the Anti-Abuse BCP for Hosting and Cloud Service Providers, a Best Common Practices (BCP) document written with the Internet Infrastructure Coalition (March 2015; M3AAWG0094);
• the BCP for Mitigating Abuse of Web Messaging Systems (v1.1, March 2019; first published 2010; M3AAWG032-2019).

Why this matters

• Sending spam directly from infected subscriber PCs became harder, because of port-25 blocking and vigilance in the community. Spammers moved their botnets to sending through compromised user email accounts. As spam filters got better at blocking direct SMTP connections, they also moved to scripting web-based messaging interfaces: webmail, e-cards, invitations, "share this article" buttons, comment forms, gateways from the web to SMS, and REST messaging APIs.
• Providers should assume there will always be compromised accounts. Attacks that exploit human weakness always succeed at some rate. The operational goal is to detect compromise fast, limit the damage, and prevent the account from being compromised again. Zero compromise is not a realistic goal.
• Analyze the metrics carefully before you decide how an attack works. What looks like account compromise may actually be abuse of the trial account signup process: malicious registrations rather than hijacked customers. The two need different responses (see "Compromised vs malicious accounts" below).

Definitions (Compromised User ID BCP)

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

Some cases are outside the scope of the BCP, although they are handled through the same channels: accounts created for abuse, compromised employee accounts (which need a heavier remediation approach), and tricks that trigger a single action (clickjacking, trojans that steal credentials, worms).

How accounts get compromised

• Credential compromise. Unpatched vulnerabilities leak credentials, or an attacker steals a legitimate site's credential database to reuse elsewhere.
• Phishing. The attacker impersonates a legitimate site or sender, and users willingly hand over their credentials.
• Keyloggers. Malware on the user's compromised machine captures everything typed.
• Theft of temporary credentials (cookies), through network sniffing on unencrypted connections or cross-site scripting (XSS).
• Password guessing and brute force: common passwords tried across many accounts, or many passwords tried against one account.
• Also, social engineering aimed at the account holder or at the provider's own employees.

Detection

Behavior-feedback sources

Attackers make a compromised account behave differently from how its legitimate owner would. Good sources for detection are:

• Account owners who report that their own account is compromised, for example after seeing spam sent from their address.
• Other users and third-party data providers who report activity consistent with compromise.
• Tracking and analysis of behavior against the account's established pattern. The classic signs of compromise are a login from an unexpected location, suddenly messaging all contacts, and deleting all sent mail.
• Behavior that is always suspicious, whatever the account's history: logins from locations far apart within a short time ("impossible travel"), and messages that contain hostile URLs.
• Feedback loops from other providers. An account that suddenly generates a significant number of spam reports or complaints is in trouble (see Complaint Feedback Loops).

Advance-warning sources

Compromise often happens long before any abuse can be detected. Attackers may hold harvested credentials for weeks or months before the spam campaign starts. Use intelligence from third parties for early warning:

• Security researchers who report caches of credentials they have discovered.
• Attackers who publish lists of compromised accounts.
• Notification of related compromise. Lists of compromised accounts at one site identify linked accounts that can be attacked 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. Confirm that accounts are actually compromised, or very probably so, before you act. Automated checks may not be enough, and you may need to consult the real account owner.

Compromised vs malicious accounts

A suspicious account is not necessarily compromised. The holder may be abusive on purpose, with a single account or with mass registrations. A pattern of earlier valid use is the main sign that a genuine owner has lost control. The distinction decides the response. Compromised accounts are recovered for their owners. Fraudulent accounts get no data retrieval and no warning (see Abuse Desk Operations).

Patterns of registration abuse depend on the kind of account:

• For free accounts that are easy to open, detection means spotting registration patterns, such as mass signups from one IP range or template data.
• For paid accounts, look for stolen or disposable credit cards.
• For accounts that involve close contact with the provider (advertiser accounts, for example), look for holders who are suspiciously casual about the account requirements. Signs include surprising identity claims (an unknown advertising agency with famous clients; a distant "interior design firm" eager for local representation; a large financial firm whose address is a mail drop), ignoring delays or rules that other users question, and changing their story instantly to fit the requirements.

Platform telemetry (Hosting & Web Messaging BCPs)

Set up internal telemetry that reports on the state of the network: self-scans of the network, traffic analysis, and monitoring of the outbound spam filter. For web platforms, list every resource that can be abused and track each one. Example baseline metrics:

• User and account metrics: new registrations, logins, password changes, account deactivations.
• Abusive transactions: visits to pages that do not exist, suspicious query strings, visits to uncommon ports.
• Potentially suspicious transactions: total actions completed (messages sent, comments posted), and identities that reach any limit or heuristic.

How to collect and store the data:

• Scraping logs is the most common source; hooks in the application are better.
• Keep data for a week or longer to catch attackers who work slowly and at low volume.
• Store the User-Agent string for each login. Attackers rarely match a legitimate user's User-Agent exactly, and some User-Agent values are only ever seen from abusers.
• Correlate across webmail, IMAP and POP, and the MTA, and share data on detected abusers between these systems.

Hard statistics also make the case for a budget for anti-abuse work.

Proactive defense (Web Messaging BCP)

There are three areas to defend, and each can be exploited on its own: (1) the abuser's access to the user interface, (2) the content a user may submit, and (3) how widely that content is distributed. The underlying economics: every step an abuser must take has a cost, so raise the cost until it exceeds what the attack is worth.

UI access

• Authentication. Requiring an account raises the cost of an attack. Account registration and provisioning need the same protections as messaging. Alternatively, rely on established identity providers for authentication: accept credentials from major platforms through their API, and use OpenID Connect for a standard, interoperable integration.
• Multifactor authentication. It does not solve everything, but it is very useful against abuse of compromised accounts, because a username and password are no longer enough. Second factors include SMS one-time codes, TOTP or HOTP authenticator apps or hardware, and U2F public-key hardware tokens. Advice for the rollout:
  • Do not force everyone to enroll at once, or support calls will flood in.
  • Start with users who were compromised before or who are at high risk, and let everyone else enroll themselves.
  • Use risk-based enforcement: ask for the second factor only on suspicious logins or sensitive actions (changing a password, sending to a large number of recipients).
  • Allow "remembered devices."
• CAPTCHA. It clearly reduces abuse, but its cost to attackers keeps falling, because optical character recognition (OCR) improves and human solvers are cheap. Always combine it with other techniques, and use a maintained implementation proven in the field (such as reCAPTCHA), never one you built yourself.
• Page hardening against scripting. Randomize or vary the page structure (change the HTML ids of required fields). Obscure the structure (field names encrypted with JavaScript, fields presented with AJAX). Set honeypot traps: fields hidden with CSS that people skip but bots fill in. Two cautions: this harms accessibility for users who cannot see the page, and it provides no real security. It only adds cost and effort, which still deters casual attackers.
• Rate limiting. It should be used on almost all web services that accept or relay content generated by users. Choose a stable identity to count against, such as a combination of the remote IP address, User-Agent, username, session or cookie ID, and a computed machine identifier. Implementations range from plugins such as mod-security to a simple counting server. An example rule is 50 messages/hour and 100/day for each user ID, after which the user is redirected to an error page. Protect every access point to the feature (all servers behind the load balancer), and do not rely on the client to follow redirects.
  • Pitfalls in rule design: legitimate spikes (announcing "I just had a baby" to the whole address book), and clustering mistakes (an internet café IP address shared by 20 users; a traveler logging in from many unusual places). When a user reaches the limit, show a plain message ("You are not allowed to send more than 100 messages per hour") rather than a vague "suspicious activity detected" page that generates support requests. Spammers usually already know the limits, while legitimate users may share a NAT address with an infected machine.
  • Dynamic blocking is rate limiting with an allowance of zero transactions. Third-party feeds can seed blocklists, and Spamhaus AuthBL is suited to abuse of authentication. Be careful when using a list for a purpose it was not built for: the PBL lists IP addresses that should not connect to port 25, and it is completely unsuitable for blocking port 80.
  • IPv6. Track ranges, not /128s. ISPs give customers stable blocks, typically no smaller than /64, with ranges for each customer from /64 up to /48. Because the address space is so large, you may need to lower thresholds. Carrier-grade NAT, with dozens to hundreds of users behind each IPv4 address, may require raising them.
• Web application security. Follow the OWASP Top 10.

Content filtering

• Least privilege. Allow only the content types you must, and use an allowlist rather than a blocklist, because blocklisting turns into an endless chase. Sanitize content generated by users with an engine more capable than one that strips script tags: encoding tricks defeat simple sanitizers, and a sanitizer based on a real browser's rendering code detects far more. Restrict attachments and uploads by type, and scan them for malware. Limit the length of the content to what the feature needs (a note shared with a link needs ~200 characters, not 1000), which lowers the field's value for spam.
• Heuristics. Blocklists of tokens, URLs and strings work, but they are maintained by hand and easy to evade ("V.1agra", URL redirectors). They need a process that adds and expires rules at scale. The alternative is to build an open-source or proprietary spam-filtering engine into the submission path, before messages are accepted.
• Reputation models. Online or offline models that change with outbound content and sender profiles. For example, compute a user's trust from the account's age, the number of positive actions and the number of suspicious actions, and consult the model for each questionable submission to get a prior probability that it is spam.
• Batch analysis. This is the most flexible method. Cluster recent messages on a broad set of features to find unexpected patterns (for example, accounts all registered on June 7 from one /16, all sending 103-word messages), then load the patterns you find back into the outbound filters.

Distribution controls

• Limiting recipients. Cap the number of recipients per message for users who are not trusted. In systems where distribution is implicit (blogs, comments), require moderation or quarantine for new posts.
• There are three ways to respond to a message the filter judges bad:
  • Challenge. Messages in a gray area trigger a further validation step: a CAPTCHA or, increasingly, a second authentication factor. Protect the challenge interface as well as the submission interface. Relying too much on CAPTCHA lets attackers send borderline spam for the price of an automated solver.
  • Quarantine. Delay the message for longer automated examination (for example, when the volume of submissions is unusually large) or for manual moderation.
  • Reject. Deliver nothing. Deleting silently confuses users, generates support requests, and makes debugging miserable, while an open rejection tells spammers what happened. Most providers compromise: they show an error, and keep its wording vague and generic.

Containment and remediation (Compromised User ID BCP)

Returning a compromised account to its rightful owner takes three steps: (1) identify the compromise, (2) remove the inappropriate access and give control back to the owner, and (3) secure the account against a new compromise. Classify each detection by type of compromise, because each type needs different treatment:

Securing against re-compromise

After returning the account:

• Help the user find and remove back doors the attacker left: changed contact details, email forwarding rules, reply-to addresses.
• Prevent password reuse, and set stronger password requirements.
• Ask the user to turn on two-factor authentication where it is available.
• Explain to the user how the account was compromised, if you know.
• Notify other providers if the compromise involves accounts with them.
• Encourage the user to use only secure access protocols (for example, IMAPS instead of IMAP).

Re-compromised accounts

Accounts that are compromised again and again need special handling, not the same recovery process once more. The causes can be false positives from flawed detection; compromise of something other than the credentials (the holder's computer, a network they use, or the provider itself); or holders who do not have the skills to protect their credentials. Each cause needs its own handling. For the last one, someone must have the authority to make the business decision: keep the customer under special requirements, or ask them to take 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 mechanism that forces the user to authenticate again, ideally one the user can complete without help. The recovery channel must rely on information or access that does not fall to the attacker automatically when the main credential is compromised. The mechanisms and their trade-offs:

• Secret questions. Users know them, but they have drawbacks. Answers are hard to check automatically, because free-form answers vary. Users choose answers that can be guessed ("what color is the sky") or researched ("what school did you go to"). Phishing routinely collects answers to secret questions, so attackers may already have them. Users forget their own answers, especially when answers change over time ("favorite movie").
• Alternate contact methods, such as a phone number or a separate email address for recovery codes. They are easy to automate and to understand, but they have drawbacks too. Users are reluctant to share mobile numbers. Entry errors are common, and users often abandon verification. Users make two accounts each other's recovery contact, so when one falls, both fall. Because passwords are reused, the recovery mailbox may be compromised with the same credentials. Users do not update the contact after losing control of it, which turns the safety measure into a way in for attackers. To reduce these risks, require positive verification of the alternate contact, and repeat it periodically.
• Other account information, such as a postal code, date of birth, location at registration or previous passwords, or for business relationships "what was your last order?" and "what is the serial number on your modem?". No special enrollment is needed. However, providers of free accounts deliberately collect little data that can be verified, so this information is often not available. It is also hard to find data the attacker cannot discover or change from inside the account. Automating these checks can even leak verification data to an attacker who has not yet committed to the attack: for example, showing a set of pictures to choose from reveals that one of them means something to the owner.

Hosting and infrastructure prevention baseline (Hosting Abuse BCP)

Who is responsible for handling abuse depends on the hosting model. The BCP's matrix covers:

• shared hosting: the provider controls the hardware, operating system and software, and the provider and customer handle abuse together;
• virtual private servers (VPS): the provider owns the virtual environment and the operating system, and the customer controls the software and access;
• dedicated or unmanaged hosting: the customer controls the operating system and software, and abuse issues fall to the customer;
• managed hosting: the provider controls the whole stack;
• reseller hosting: customers resell to their own clients, and resellers of resellers add degrees of separation that slow down abuse handling.

Common types of abuse are outbound spam; websites advertised by spam; phishing, almost always through compromised end-user accounts running outdated scripts; hacked or defaced pages, where most accounts are compromised through outdated CMS installations such as Joomla and WordPress; child sexual abuse material (CSAM); copyright and trademark issues; distributed denial-of-service (DDoS) attacks and other hostile outbound traffic (amplification, botnet command and control); and malicious signups, which become an endless chase across many accounts and platforms.

Prevention practices:

• Require customers to keep their software updated, in the contract: operating system, plugins, CMS, themes, hardware and firmware. Outdated software is one of the main causes of hosting abuse. Agreements should state that it may breach the contract, and automatic updates should be enabled where possible. Encourage regular backups stored securely, so that servers that were broken into can be restored to a known good state.
• Controls at the network edge: intrusion detection and prevention systems; automated security scanning and penetration testing of web applications; at minimum, a hardware or software firewall on every network. Promote web application firewalls (such as ModSecurity) for hosted clients. Managed providers should maintain a core WAF rule set on client servers.
• Password and staff security: require complex passwords, offer two-factor authentication (2FA), make passwords expire at fairly short intervals, and keep a history of passwords and policies for each client. Security inside the provider is paramount: every measure on the customer side is pointless if staff credentials can be guessed. Follow standards at the level of PCI-DSS.
• IPv6. Addresses are not scarce, so give each customer a separate /64. Even on the smallest shared systems, every customer and website should have a unique address. This makes it easier to trace the source of abuse, lets receivers block one offender without affecting others, and simplifies suspending and restoring service.
• Stay in close contact with customers. Keep several up-to-date ways to reach them (email, phone, chat, portals) so that notices of compromise actually reach someone. Authenticate ongoing communication with the identity collected during vetting.
• Data security (Appendix 3). Treat databases of subscriber email addresses as valuable targets for criminals: "criminals rob banks because that's where the money is," and ESPs are where the addresses are. Maintain a complete security program, using OWASP and SANS resources. Some members follow the ISO/IEC 27002:2013 controls for Access Control, Communications and Operations Management, and Incident Management. Never assume that a store is unattractive because it holds "only email addresses".

Once outbound abuse is detected, the remediation loop driven by complaints is covered in Abuse Desk Operations: validate, notify the customer with a citation of the terms of service, allow a remediation window, suspend, and terminate. Fraudulent accounts do not receive the courtesies given to customers.

Related articles

• Abuse Desk Operations, on report intake and the remediation workflow
• Customer Vetting, on keeping deliberate bad actors out
• Blocklists & Spamhaus, including AuthBL and listings caused by compromise