Abuse Handling, Compromised Accounts, and Incident Response
Abuse handling is one of the parts of hosting nobody tells you about up front. It's security, customer support, network ops, contracts, and evidence handling all at once. The job is to stop the harm quickly, without destroying the information you need, accusing anyone of something you can't back up, or treating every report like a five-alarm fire.
Taking in reports
Abuse reports come from everywhere: automated feeds, email, support tickets, upstream providers, law enforcement, customers, random people on the Internet. Some are precise. Others are incomplete, wrong, malicious, or meant for a completely different provider.
What I want in a report
- Who's reporting, and how to reach them
- Source and destination IPs
- Domain, URL, hostname, or message ID
- A timestamp, with a time zone
- Protocol and destination port
- Log lines, headers, a packet sample, or a screenshot
- What they think is happening
- What they're asking you to do, and by when
Check who had the IP, and when
IP assignments change. You need to match the report to whoever had that address at the time it happened, not who has it now. That means keeping DHCP, provisioning, NAT, proxy, and account history around long enough to answer the question.
Triage
| Severity | Examples | What happens |
|---|---|---|
| Critical | Your own control systems are compromised, destructive malware, lots of customers affected, major data theft | Declare an incident now, contain it, bring in leadership and legal |
| High | Active phishing, malware hosting, a big spam run, credential theft, attacks going out at someone else | Contain fast, contact the customer, save evidence, investigate |
| Medium | One hacked site, scanning, repeat policy violations, smaller spam problems | Give the customer a deadline to fix it, or a limited suspension |
| Low | Unverified complaints, old evidence, minor content disputes, an honest misconfiguration | Verify, ask for details, write it down, keep an eye on it |
Confidence isn't the same as impact
A scary accusation with weak evidence is different from a confirmed, active incident. I try to think about these separately:
- Confidence: how sure am I that this is our service, doing this thing?
- Impact: what harm is happening, or about to?
- Urgency: how fast do I need to act to stop more harm?
- Scope: one account, one server, one customer, or our own infrastructure?
The response process
NIST's current guidance folds incident response into overall security risk management instead of treating it as a standalone emergency procedure. For everyday work, these phases still hold up well:
- Prepare. Contacts, access, logging, backups, tools, policies, and practice.
- Detect and analyze. Confirm it's real, figure out what's affected, build a timeline, and work out the scope.
- Contain. Stop or limit the harm while keeping enough evidence to understand what happened.
- Eradicate. Get rid of the malicious code, stolen credentials, persistence, rogue accounts, and the hole they came in through.
- Recover. Bring clean service back, watch it closely, and ramp up in stages.
- Improve. Update controls, runbooks, customer guidance, product rules, and monitoring.
Match the response to the problem
- Block a port or outbound protocol.
- Rate-limit mail or traffic.
- Disable one mailbox, API key, website, or vhost.
- Move it to a quarantine VLAN.
- Snapshot a VM and cut it off from the outside.
- Suspend the whole account or server when nothing narrower will work.
- Null-route or blackhole traffic during a big attack.
The narrowest action that's safe usually keeps innocent customers online and preserves better evidence. But don't let that slow you down when the harm is obvious and ongoing.
A hacked shared hosting account
Signs to look for
- PHP files that shouldn't be there, obfuscated code, or core files modified recently
- New admin users, or changed contact info
- Unusual outbound mail or web requests
- New cron jobs or processes that keep coming back
- Modified
.htaccess, weird redirects, or injected JavaScript - Uploads in cache, image, or temp folders
- Logins from strange networks, or a success right after a pile of failures
What I do, in order
- Save the current state. Logs, timestamps, process lists, and a snapshot or archive if it makes sense.
- Stop the outbound harm. Disable the site, mailbox, or feature as narrowly as you can.
- Find how they got in. Vulnerable plugins, stolen passwords, writable files, exposed admin tools, or a hole between accounts.
- Change the passwords. Hosting, CMS, database, mail, SFTP, API keys, and anything reused.
- Restore from something known-clean. Cleaning files one at a time without replacing the vulnerable software usually leaves a backdoor behind.
- Patch and harden. Update the app and plugins, remove what isn't used, and fix permissions.
- Check before turning it back on. Scan, read the logs, test the site, and watch outbound traffic.
Spam, phishing, and mail reputation
Mail abuse can start with a stolen mailbox password, a hacked web app, an abused forwarder, an open relay, or a customer who's just ignoring the rules on purpose.
Figure out where it's coming from
| Source | How you can tell | What to do |
|---|---|---|
| A logged-in mailbox | SMTP auth logs, one mailbox, logins from far away | Disable the login, change the password, kill sessions |
| A web app | Sent by the local script user, web logs around the same time | Disable the script or site, save the files, patch the app |
| A forwarder | Lots of forwarded mail, remote rejections, backscatter | Turn off or rethink the forwarding |
| Open relay | Unauthenticated mail from outside going back outside | Fix SMTP policy right now, then figure out how bad it was |
| Intentional sender | Keeps bulk mailing after a warning, bought lists | Enforce your terms and keep a record of the conversation |
Getting your reputation back
- Stop the source before asking to be delisted.
- Check the queue and logs to make sure it's really stopped.
- Fix SPF, DKIM, DMARC, and PTR if they need it.
- Be honest with blocklist operators about what happened and what you did.
- Keep watching volume and what remote servers say.
- Don't just move the spam to a fresh IP and call it fixed.
Scanning, attacks, and DDoS
Not every scan is an incident. But steady outbound scanning often means a compromised box, or someone doing it on purpose. Line up flow data, firewall logs, process info, who owns the IP, and timestamps.
When the attack is coming from you
- Confirm that IP belonged to that service at the time.
- Is it still happening?
- Find the VM, container, account, process, or NAT mapping it's coming from.
- Block it as narrowly as you can.
- Save both live and historical evidence.
- Tell the customer, with evidence and a deadline.
- Suspend if they can't or won't stop it.
When the DDoS is coming at you
- Figure out the target, protocol, rate, packet size, and whether it's filling your circuit.
- Decide whether you can filter it locally or need help upstream.
- Use RTBH, FlowSpec, scrubbing, ACLs, or your provider's tools, depending on your setup.
- Make sure management and monitoring don't get choked by the same traffic.
- Tell people what's affected and what you're doing, without promising when it'll end.
- Keep flow summaries and provider ticket numbers for the review afterward.
Evidence, privacy, and communication
Only collect what you need and what your policies and the law allow. You're holding customer data and logs that are sensitive even when someone's been accused of abuse.
A basic evidence record
- Who collected it and when
- Which system, what time zone, and whether its clock was accurate
- Original filename or log location
- A hash, when it makes sense
- What was done before and after collecting it
- Where it's stored and who can access it
- Who got a copy
Stick to the facts with customers
Subject: Action required: outbound SMTP abuse from VPS 203.0.113.25
We detected sustained authenticated SMTP traffic from your VPS beginning
at 2026-07-16 14:32 UTC. The traffic generated repeated remote-provider
rejections and exceeded the service's normal outbound pattern.
To stop continued impact, outbound TCP/25 has been temporarily restricted.
The VPS remains reachable for administration.
Please review the attached timestamps and source-account details, rotate
mail and administrative credentials, inspect the system for compromise,
and reply with your findings. We will re-enable normal outbound delivery
after the source has been remediated and validated.
Notice what that message doesn't say: "you hacked someone." Unless the evidence (and the legal context) really supports that, describe what you saw and what needs to happen. Most of the time the customer is a victim too.
Get ready before the first serious incident
- A published abuse contact that someone actually reads
- Acceptable use, suspension, privacy, and data retention policies
- History of which customer had which service and IP
- Logs with synced clocks and a known retention period
- Flow, firewall, auth, web, mail, and control-panel logs
- Quarantine VLANs and firewall rules ready to go
- Emergency access and out-of-band management
- Severity definitions and who to escalate to
- Templates for customer emails and status page posts
- A lawyer, and a process for law enforcement requests
- A post-incident review template
Questions for afterward
- What tipped us off first?
- What slowed down detection or containment?
- What logs or access were we missing?
- Did we cause customer impact we didn't need to?
- Did backups and recovery work like we expected?
- What one control would make this less likely or less bad next time?
- What should change in onboarding, monitoring, or product policy?