A compromised server rarely sits idle. Within minutes of gaining access, attackers deploy web shells, install cryptocurrency miners, pivot to internal networks, or use your server as a launchpad for phishing campaigns and brute-force attacks against other targets. Your hacked server becomes someone else's problem too.
After you contain the breach — isolating the server, killing malicious processes, and beginning recovery — there's a critical step that many administrators skip: reporting. Filing abuse reports with your hosting provider and the attacker's ISP helps shut down the infrastructure behind the compromise, protects other potential victims, and creates an official record that may matter if the breach escalates to a legal or regulatory issue.
This guide walks through the entire post-compromise reporting process, from evidence collection to filing reports with the right parties. It's part of my complete guide to reporting IP abuse, focused specifically on server compromise scenarios.
How to Identify a Server Compromise
Sometimes the signs are obvious — a defaced homepage or a flood of customer complaints about spam originating from your domain. Other times, the indicators are subtle and only surface when you actively look. Here are the key things to check.
Unexpected processes
Look for processes you don't recognize, especially those running as root or under web server user accounts:
ps aux --sort=-%cpu | head -30
Watch for processes with suspicious names like kdevtmpfsi, kinsing, .sshd (note the leading dot), or generic names like java, python3, or bash running from unusual paths such as /tmp, /dev/shm, or /var/tmp.
Unusual outbound network connections
Check for connections to unfamiliar IP addresses, especially on non-standard ports:
ss -tunap | grep ESTABLISHED
netstat -tunap | grep ESTABLISHED
A compromised server often phones home to a command-and-control server or sends traffic to targets it's attacking. Connections on ports like 4444, 5555, 6667 (IRC), or high-numbered random ports are red flags.
Modified system files and suspicious cron jobs
Check for recently modified files in system directories and unauthorized cron entries:
# Files modified in the last 3 days in system directories
find /etc /usr/bin /usr/sbin -mtime -3 -type f 2>/dev/null
# All cron jobs across all users
for user in $(cut -f1 -d: /etc/passwd); do
crontab -l -u "$user" 2>/dev/null | grep -v '^#' | grep -v '^$' && echo " ^ $user"
done
# Check system-wide cron directories
ls -la /etc/cron.d/ /etc/cron.daily/ /etc/cron.hourly/
Unfamiliar user accounts and SSH keys
Look for accounts or SSH keys that you didn't create:
# Recently added users
grep -v 'nologin\|false' /etc/passwd
# Check authorized_keys for all users
find / -name "authorized_keys" -type f 2>/dev/null -exec echo "=== {} ===" \; -exec cat {} \;
Web shells and backdoors
If you're running a web server, check for recently added or modified PHP, ASP, or JSP files:
# PHP files modified in the last 7 days
find /var/www -name "*.php" -mtime -7 -type f 2>/dev/null
# Look for common web shell signatures
grep -rl "eval\s*(base64_decode\|system\s*(\|passthru\|shell_exec" /var/www/ 2>/dev/null
Log anomalies
Review authentication and system logs for evidence of unauthorized access:
# Failed and successful SSH logins
grep -i "accepted\|failed" /var/log/auth.log | tail -50
# Sudo usage
grep "sudo" /var/log/auth.log | tail -30
Evidence Gathering Checklist
Before you wipe anything or begin restoring from backups, collect evidence. This is critical for abuse reports, and essential if law enforcement gets involved later. Save everything to an external location — not the compromised server itself.
Here's what to gather:
- Authentication logs —
/var/log/auth.log,/var/log/secure(failed and successful logins, sudo usage, SSH key authentications) - System logs —
/var/log/syslog,/var/log/messages,journalctloutput - Web server logs — Access and error logs from Apache (
/var/log/apache2/) or Nginx (/var/log/nginx/) - Modified file inventory — Full list with timestamps using
find / -mtime -7 -type f - Running process list — Full
ps auxoutput captured at time of discovery - Network connections —
ss -tunapornetstat -tunapoutput showing established connections - Cron entries — All cron jobs for all users
- New user accounts — Any accounts added to
/etc/passwdor/etc/shadow - SSH authorized keys — Any keys added to
~/.ssh/authorized_keysfiles - Malware samples — Copy any web shells, backdoors, or malicious scripts (keep in a password-protected archive)
- Disk image — If possible, create a forensic image of the compromised disk before remediation
A quick way to capture the most critical runtime state:
mkdir /tmp/evidence-$(date +%Y%m%d)
cd /tmp/evidence-$(date +%Y%m%d)
ps aux > processes.txt
ss -tunap > connections.txt
last -50 > login_history.txt
cp /var/log/auth.log ./
cp /var/log/syslog ./
crontab -l > crontab_root.txt 2>&1
find / -mtime -3 -type f > modified_files.txt 2>/dev/null
tar czf evidence-bundle.tar.gz ./*
Transfer the bundle off the server immediately. Attackers who maintain access may tamper with or delete logs.
Finding the Abuse Contact
Once you've identified the attacker's source IP address from your logs, you need to find who's responsible for that IP. Use the IP Location tool to look up the IP — it returns the ISP, organization, ASN, and geographic information.
The WHOIS record for the IP will typically include an abuse-mailbox field with the correct email address for reporting. For major cloud and hosting providers, abuse contacts are well-documented:
- AWS — [email protected]
- Google Cloud — [email protected] (or through the GCP console)
- Microsoft Azure — abuse portal at msrc.microsoft.com
- DigitalOcean — [email protected]
- OVH — [email protected]
- Hetzner — [email protected]
If the attacker's IP belongs to a hosting provider, that provider can take direct action against the offending account. If it belongs to a residential ISP, the response may be slower, but the ISP can notify the subscriber whose machine may itself be compromised and part of a botnet.
You can also use the Port Scanner to check what services are exposed on your own server — this helps you understand the attack surface that was exploited and document it in your report.
Hacked Server Abuse Report Template
A well-structured report gets faster results. Include all relevant details so the recipient can identify the attacker's account and take action without needing to ask follow-up questions.
Subject: Abuse Report – Server Compromise Originating from [IP ADDRESS]
To Whom It May Concern,
I am reporting a server compromise that originated from an IP address
under your administration.
-- Attacker Information --
Source IP: [ATTACKER_IP]
Attacker ASN: [ASN_NUMBER]
Attack Method: [e.g., SSH brute force, web application exploit, etc.]
-- Victim Server Information --
Server IP: [YOUR_SERVER_IP]
Hosting Provider: [YOUR_PROVIDER]
Operating System: [e.g., Ubuntu 22.04 LTS]
Primary Service: [e.g., Web server running Apache/Nginx]
-- Timeline --
Estimated compromise date: [DATE/TIME with timezone]
Discovery date: [DATE/TIME with timezone]
Containment date: [DATE/TIME with timezone]
-- Evidence Summary --
The following evidence ties the attack to the reported IP address:
1. Authentication logs showing [brute-force attempts / successful login]
from [ATTACKER_IP] beginning [DATE/TIME]:
[PASTE RELEVANT LOG LINES - 10-15 lines max]
2. Network connections from the compromised server to [ATTACKER_IP]
observed on port [PORT]:
[PASTE ss/netstat OUTPUT]
3. Malicious activity performed post-compromise:
- [e.g., Cryptocurrency miner deployed at /tmp/.hidden/xmrig]
- [e.g., Web shell installed at /var/www/html/uploads/cmd.php]
- [e.g., Outbound SSH scans launched against multiple /24 ranges]
-- Impact --
[Describe impact: data exposure, service disruption, spam sent, etc.]
-- Request --
Please investigate the reported IP address and take appropriate action
to prevent further attacks from this source. If the server at this IP
has itself been compromised, I would appreciate notification to its owner.
I have preserved full forensic evidence and logs and can provide
additional details upon request.
Regards,
[YOUR NAME]
[YOUR ROLE / ORGANIZATION]
[CONTACT EMAIL]
Attach the evidence bundle or offer to share it via a secure method. Avoid sending malware samples directly in email attachments — most mail systems will strip them.
Where to Report
Your hosting provider (first priority)
Your own hosting provider should be your first call. They need to know about the compromise because:
- They may detect ongoing malicious activity from your server that you haven't noticed yet
- They can help with forensic analysis or provide additional logs (network-level traffic data you don't have access to)
- Some providers have incident response teams that will assist with containment
- There may be contractual or regulatory obligations to disclose breaches
Most hosting control panels have a support or security incident reporting mechanism. For urgent situations, use phone support if available.
The attacker's ISP
Send your abuse report to the ISP that owns the attacker's source IP. Use the abuse contact from the WHOIS record. This is how you shut down the attacker's infrastructure or get a compromised intermediary server cleaned up.
Cloud provider abuse portals
If the attack came from a major cloud provider, use their dedicated abuse forms in addition to email. These often get routed more quickly:
- AWS — aws.amazon.com/forms/report-abuse
- Google Cloud — support.google.com/code/contact/cloud_platform_report
- Microsoft Azure — msrc.microsoft.com/report/abuse
- DigitalOcean — digitalocean.com/company/contact (abuse category)
Law enforcement
For serious breaches involving data theft, financial loss, or personally identifiable information, you should also report to law enforcement. I cover this process in detail in my guide on reporting cybercrime to law enforcement and the FBI IC3. Key points: file an IC3 complaint in the US, or contact your national CERT if you're outside the US.
Common Compromise Scenarios
Web application exploit
WordPress, Joomla, Drupal, and other CMS platforms are frequent targets. Attackers exploit outdated plugins, themes, or core versions to upload web shells. In your report, include:
- The vulnerable component and version (e.g., "WordPress 5.8 with Contact Form 7 plugin v5.4")
- The web shell path and contents
- Access log entries showing the exploit payload
Check access logs for POST requests to unusual paths — this often reveals the initial exploitation vector.
SSH or RDP credential compromise
Whether through brute force or stolen credentials, remote access compromises are common. Your auth logs will show the evidence clearly. I cover this attack type and reporting process in detail in my guide on reporting brute-force SSH and RDP attacks. Include failed login counts, the successful authentication timestamp, and any lateral movement observed afterward.
Supply chain compromise
Sometimes the breach comes through a compromised software dependency — a malicious npm package, a backdoored Docker image, or a tampered update. These are harder to trace to a single IP, but you should still report what you find. The attacker's C2 server IP will be in your network connection logs.
Cryptojacking
Cryptocurrency mining is one of the most common payloads after a server compromise. Signs include sustained 100% CPU usage, processes named xmrig, kdevtmpfsi, or kinsing, and outbound connections to mining pools on ports 3333, 5555, or 14433. In your report, include the mining pool address and wallet ID if you can extract them from the miner's configuration — this can help trace the attacker across multiple compromised servers. My guide on reporting malware and botnet C2 traffic covers the C2 reporting angle in more detail.
What to Expect After Reporting
Response times vary significantly depending on who you're reporting to.
Your hosting provider — Expect a response within hours for a security incident. Most providers take compromise reports seriously because a hacked server on their network affects their reputation and other customers. They may suspend your server temporarily while the situation is resolved.
The attacker's ISP — Cloud providers with automated abuse systems (AWS, GCP, DigitalOcean) typically respond within 24-48 hours and may suspend the offending instance. Traditional ISPs may take 3-7 business days. Some providers in certain jurisdictions may not respond at all.
Law enforcement — IC3 complaints are logged and may be used in aggregate investigations, but don't expect individual case follow-up unless the breach is large-scale. National CERTs may provide incident response guidance.
Don't be discouraged by slow responses. Each report contributes to a pattern that abuse teams and law enforcement use to build cases and take down infrastructure. If you don't receive a response within a reasonable timeframe, escalate — resend the report, CC the provider's NOC, or use their online abuse portal if you initially used email.
Prevention: Reducing the Risk of Future Compromise
Once you've reported and recovered, take steps to harden your infrastructure:
- Patch consistently — Apply security updates within 24-48 hours of release, especially for internet-facing services. Most compromises exploit known vulnerabilities with available patches.
- Enforce key-based SSH authentication — Disable password authentication entirely. This eliminates brute-force SSH attacks as a vector.
- Minimize your attack surface — Run only the services you need. Use a firewall to block all ports except those required. Check what's exposed with the Port Scanner.
- Implement monitoring — Set up alerts for unusual CPU usage, outbound connections to unfamiliar IPs, new user accounts, and modified system files. Tools like OSSEC, Wazuh, or even simple cron scripts that check for changes can catch compromises early.
- Use the principle of least privilege — Web applications should run as non-root users with minimal filesystem permissions. Database accounts should have only the permissions they need.
- Maintain tested backups — Keep offline or immutable backups. Test your restoration process regularly. A clean backup is your fastest path to recovery.
- Enable multi-factor authentication — For all administrative access including SSH (via PAM modules), control panels, and CMS admin interfaces.