Abuse Handling, Compromised Accounts, and Incident Response
Abuse work sits at the intersection of security, customer support, network operations, contracts, and evidence handling. The provider must stop harm quickly without destroying information, making unsupported accusations, or turning every report into an emergency shutdown.
On this page
Build a Reliable Abuse Intake Process
Abuse reports arrive through automated feeds, email, support tickets, upstream providers, law enforcement, customers, and members of the public. Some are precise; others are incomplete, mistaken, malicious, or sent to the wrong provider.
Minimum report fields
- Reporter contact and organization
- Source and destination IP addresses
- Domain, URL, hostname, or message ID
- Timestamp with time zone
- Protocol and destination port
- Relevant log excerpt, headers, packet sample, or screenshot
- Type of alleged activity
- Requested action and deadline
Verify ownership and time
IP assignments change. A valid report must be matched to the correct customer and service at the reported time, not merely the current assignment. Preserve DHCP, provisioning, NAT, proxy, and account records needed to make that determination.
Do not trust links or attachments automatically. Abuse mail itself can contain phishing links, malware, or misleading evidence. Use isolated review procedures and verify the reporter through known channels when necessary.
Triage by Impact and Confidence
| Severity | Examples | Typical response |
|---|---|---|
| Critical | Active compromise of provider control systems, destructive malware, broad customer impact, major exfiltration | Immediate incident declaration, containment, leadership and legal escalation |
| High | Active phishing, malware distribution, large spam campaign, credential theft, outbound attack affecting others | Rapid containment, customer contact, evidence preservation, focused investigation |
| Medium | Single compromised site, scanning, repeated policy violation, smaller mail abuse | Time-bounded customer remediation or limited suspension |
| Low | Unverified complaint, stale evidence, minor content dispute, first-time nonmalicious misconfiguration | Validate, request details, document, and monitor |
Separate confidence from impact
A severe allegation with weak evidence is not the same as a confirmed active incident. Track:
- Confidence: How strongly does the available evidence identify the service and activity?
- Impact: What harm is occurring or likely to occur?
- Urgency: How quickly must action be taken to prevent additional harm?
- Scope: Is one account affected, one server, one customer, or the provider control plane?
A Practical Incident Response Process
Modern NIST guidance integrates incident response across cybersecurity risk management rather than treating it as a standalone emergency procedure. For day-to-day operations, the following phases remain useful:
- Prepare. Maintain contacts, access, logging, backups, tools, policies, and practice scenarios.
- Detect and analyze. Confirm the event, identify affected assets, establish a timeline, and determine scope.
- Contain. Stop or limit harm while preserving enough evidence and service state to understand the incident.
- Eradicate. Remove malicious code, credentials, persistence, unauthorized accounts, and vulnerable entry points.
- Recover. Restore clean service, monitor closely, and return capacity in controlled stages.
- Improve. Update controls, runbooks, customer guidance, product boundaries, and monitoring.
Containment options should be proportional
- Block a destination port or outbound protocol.
- Rate-limit mail or traffic.
- Disable one mailbox, API key, website, or virtual host.
- Move a service to a quarantine VLAN.
- Snapshot a VM and isolate it from external networks.
- Suspend the entire account or server when narrower controls are not sufficient.
- Null-route or blackhole traffic during a large attack.
The narrowest safe action preserves unaffected customer service and often preserves better evidence. However, do not delay decisive containment when ongoing harm is clear.
Compromised Shared-Hosting Account
Common indicators
- Unexpected PHP files, obfuscated code, or recently modified core application files
- New administrator accounts or changed contact information
- Unusual outbound mail or web requests
- Scheduled tasks, cron entries, or persistent processes
- Modified
.htaccess, redirect rules, or injected JavaScript - Uploads in writable cache, image, or temporary directories
- Logins from unusual networks or repeated successful authentication after failures
Response sequence
- Record current state. Preserve relevant logs, timestamps, process lists, and a snapshot or archive where appropriate.
- Contain outbound harm. Disable the affected site, mailbox, or account capability as narrowly as possible.
- Identify the entry point. Check vulnerable plugins, stolen credentials, writable files, exposed admin tools, and neighboring account boundaries.
- Rotate credentials. Hosting, CMS, database, mail, SFTP, API, and any reused credentials may need replacement.
- Restore from a known-clean source. Cleaning individual files without replacing vulnerable software often leaves persistence.
- Patch and harden. Update application code and extensions, remove unused components, and correct permissions.
- Validate. Scan, review logs, test functions, and monitor outbound behavior before full reactivation.
Important distinction: A malware scanner finding no additional signatures does not prove the account is clean. Validate the application source, credentials, persistence mechanisms, and original vulnerability.
Spam, Phishing, and Mail Reputation
Mail abuse can begin with a stolen mailbox password, compromised web application, abused forwarding rule, open relay, or customer intentionally violating policy.
Investigate the source path
| Source | Indicators | Containment |
|---|---|---|
| Authenticated mailbox | SMTP authentication logs, one mailbox, external login IPs | Disable mailbox login, rotate password, revoke sessions |
| Web application | Messages sent by local script user, web logs near send time | Disable script/site, preserve files, patch application |
| Forwarder abuse | Large forwarded volume, remote rejection, backscatter pattern | Disable or redesign forwarding, use destination-side retrieval |
| Open relay or misroute | Unauthenticated external-to-external relay | Correct SMTP policy immediately and review scope |
| Intentional sender | Repeated bulk behavior after warning, purchased lists, policy conflict | Enforce acceptable-use terms and preserve communication history |
Reputation recovery
- Stop the abusive source before requesting delisting.
- Review queue and logs for continued traffic.
- Correct authentication and identity records.
- Explain the cause and remediation accurately to reputation providers.
- Monitor future volume and remote responses.
- Avoid moving abusive traffic to a fresh IP as the only “solution.”
Scanning, Attacks, and DDoS
Not every scan is an incident, but sustained outbound scanning may indicate compromise or intentional abuse. Correlate flow data, firewall logs, process information, customer ownership, and timestamps.
Outbound attack workflow
- Confirm the source address belonged to the service at the reported time.
- Determine whether traffic is continuing.
- Identify the source VM, container, account, process, or NAT mapping.
- Contain traffic with a narrow firewall or network policy where possible.
- Preserve volatile and historical evidence.
- Notify the customer with evidence and a remediation deadline.
- Escalate to suspension if the customer cannot or will not stop the activity.
Inbound DDoS response
- Confirm target, protocol, rate, packet size, and whether the attack saturates the access circuit.
- Determine whether local filtering can help or if upstream mitigation is required.
- Apply RTBH, flowspec, scrubbing, ACL, or provider-specific controls according to the network design.
- Protect management and monitoring paths from the same congestion.
- Communicate impact and mitigation state without promising an unsupported completion time.
- Preserve flow summaries and provider ticket information for review.
Evidence, Privacy, and Communication
Collect only what is necessary and permitted by policy and law. Hosting providers hold customer data and logs that may be sensitive even when an account is accused of abuse.
Basic evidence record
- Who collected the item and when
- Source system, timezone, and clock accuracy
- Original filename or log location
- Hash when appropriate
- Actions taken before and after collection
- Storage location and access controls
- Who received a copy
Customer communication should be factual
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.
Avoid claiming that a customer “hacked” another system unless the evidence and legal context support that statement. Describe observed activity and required remediation.
Prepare Before the First Serious Incident
- Published abuse contact and monitored queue
- Acceptable-use, suspension, privacy, and data-retention policies
- Customer and service ownership history
- Time-synchronized logs with known retention
- Flow, firewall, authentication, web, mail, and control-plane logs
- Quarantine VLANs and preplanned firewall controls
- Emergency access and out-of-band management
- Incident severity definitions and escalation contacts
- Customer and status-page communication templates
- Legal counsel and law-enforcement request process
- Post-incident review template
Post-incident questions
- What first indicated the incident?
- What delayed detection or containment?
- Which logs or access were missing?
- Did the response create avoidable customer impact?
- Did backups and recovery work as expected?
- Which control would most reduce recurrence or impact?
- What should be added to onboarding, monitoring, or product policy?