Abuse complaint: your server is attacking others or sending spam

Updated November 2026

If your hosting provider or another network’s abuse desk says your server is attacking others, scanning, brute-forcing passwords or sending spam, assume the server has been compromised until you can prove otherwise. Find the process or script doing it, stop it without destroying the evidence, close the hole it came through, and reply to the abuse desk with a short account of what you did.

How abuse complaints work

Every block of IP addresses has an abuse contact. In the RIPE NCC region (Europe, the Middle East and parts of Central Asia) it is the abuse-c: attribute in the RIPE Database, which points to an abuse-mailbox: address. Victims and automated systems look it up and send reports there, usually to your hosting provider, which forwards them to you. You can do the same lookup:

whois -h whois.ripe.net -b 192.0.2.10      # RIPE region: brief output with abuse-mailbox
whois 192.0.2.10 | grep -i abuse           # other regions: look for OrgAbuseEmail or abuse-mailbox

Domain registrars run abuse desks too: under ICANN’s registrar agreement they must take reasonable and prompt steps to investigate reports and respond appropriately. The anti-abuse group M3AAWG recommends that hosting providers confirm a complaint is valid, notify the customer, give time to fix it, confirm it is resolved, and suspend customers who do not respond. That is the process you are now part of.

Common complaint types

Step 1: find the process

Match the complaint to live traffic. These commands work on Debian, Ubuntu and RHEL-family systems:

# Outgoing connections with the owning process; look for many
# connections to port 22, 25, 80/443 or to the victim's address
sudo ss -tunp state established
sudo ss -tnp state syn-sent              # many of these = scanning
sudo ss -tunp | grep 198.51.100.7        # the address named in the complaint

# Busiest processes, with start time and full command line
ps -eo pid,user,%cpu,lstart,args --sort=-%cpu | head -20

When you have a suspicious PID, record it before you touch it:

PID=12345
sudo ls -l /proc/$PID/exe /proc/$PID/cwd         # real binary and working directory
sudo tr '\0' ' ' < /proc/$PID/cmdline; echo
sudo cat /proc/$PID/status | grep -E 'Name|PPid|Uid'
sudo mkdir -p /root/evidence
sudo cp /proc/$PID/exe /root/evidence/exe-$PID   # copy works even if the file was deleted
sudo kill -STOP $PID                             # freeze it; nothing is lost

If nothing shows up, the bot may run only at certain times. Compare the complaint times with your logs (journalctl --since, web server access logs) and check scheduled jobs in the next step. More techniques are in Suspicious process or port.

If the complaint is about spam

postqueue -p | tail -n 1         # Postfix: size of the queue
sudo postsuper -h ALL            # Postfix: hold all queued mail (nothing is deleted)
sudo exim -bpc                   # Exim (exim4 on Debian/Ubuntu): messages in the queue

PHP’s mail.add_x_header setting adds an X-PHP-Originating-Script header naming the script and its user ID, which points straight at the sender. The full spam clean-up, including delisting, is in IP blacklisted / spam.

Step 2: contain it

If you cannot find the process quickly, stop the traffic itself. This nftables example blocks outgoing SMTP for every user except Postfix and logs the user ID of whoever tries; adjust ports and the user for your case (Exim runs as Debian-exim on Debian and exim on RHEL):

sudo nft add table inet emergency
sudo nft add chain inet emergency out '{ type filter hook output priority 0; policy accept; }'
sudo nft add rule inet emergency out tcp dport '{ 25, 465, 587 }' meta skuid != $(id -u postfix) \
  log prefix '"smtp-block "' flags skuid drop
sudo journalctl -k -g smtp-block      # see which UID is trying
# Remove the emergency rules later:  sudo nft delete table inet emergency

For outgoing SSH brute force, block destination port 22 in the same way, leaving incoming SSH alone. If the attacker has root, local firewall rules can be removed, so ask your provider to apply a block at the network level too.

Step 3: find how it got in and clean up

# Persistence: cron jobs, systemd timers and services
sudo ls -la /etc/cron.* /var/spool/cron* 2>/dev/null
for u in $(cut -d: -f1 /etc/passwd); do sudo crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done
systemctl list-timers --all
sudo find /etc/systemd/system /usr/lib/systemd/system -mtime -14 -type f

# Recently changed files in temp and web directories
sudo find /tmp /var/tmp /dev/shm /var/www -type f -mtime -14 \
  -printf '%TY-%Tm-%Td %TH:%TM %u %p\n' 2>/dev/null | sort

# Logins and new keys
last -a | head -30                     # Debian 13: install wtmpdb and use "wtmpdb last"
sudo find / -name authorized_keys -mtime -30 2>/dev/null

Typical entry points are a weak or reused SSH password, an outdated CMS or plugin, an exposed admin panel, or a stolen control-panel or FTP password. Then:

• If the process ran as a normal user (www-data, apache, a mailbox user) and there is no sign of root access, remove its files and persistence, kill it (sudo kill -9 $PID), patch the application and change that user’s passwords and keys.
• If it ran as root, or you find modified system binaries or unknown kernel modules, do not try to clean it. Rebuild from a clean install and restore data from a backup taken before the compromise (Restore from backup). See Find backdoors for why.
• In both cases, change every password and key that was stored on or used from the server (Leaked credentials).

Step 4: reply to the abuse desk

Abuse desks handle large volumes. A short, factual answer that shows the problem is stopped and the cause is fixed closes the ticket fastest. Do not attach malware or large logs unless asked.

Subject: Re: [ticket number] Abuse report for 192.0.2.10

We investigated the report. The outgoing SSH scanning came from a
bot running as user "www-data", installed on 2026-10-30 through an
outdated WordPress plugin.

Actions taken (times UTC):
- 2026-11-03 09:12  process stopped; outbound port 22 blocked
- 2026-11-03 10:40  malicious files and cron entry removed
- 2026-11-03 11:30  WordPress and all plugins updated; passwords changed
No traffic to the reported addresses has been seen since 09:12.

Contact: admin@example.com

If you believe the complaint is wrong (for example, the IP was reassigned or the times do not match any activity), say so politely and include the log lines that show it.

Confirm it is fixed

• sudo ss -tunp shows no connections to the victim addresses or unexpected ports, over at least a day.
• The emergency firewall log shows no further blocked attempts.
• The mail queue is normal and no new complaints arrive.
• Your provider has closed the ticket.

Prevent it

• Use SSH keys and turn off password logins (SSH hardening); rate-limit login attempts (Brute-force attacks).
• Keep the OS, CMS and plugins updated automatically (Automatic updates).
• Restrict outgoing traffic: most web servers never need to open SMTP or SSH connections to the internet.
• Monitor outgoing traffic volume so you notice before someone else does (Logging and monitoring).

When to get help

Ask your provider or an incident-response firm if the attacker had root, if the server holds personal or payment data (see Personal data breach), if traffic continues after your fixes, or if the provider has already suspended the server and you need console access to investigate.

Sources

• abuse-c Information, RIPE NCC
• Abuse Contacts, RIPE Database documentation
• Registrar Abuse Reports, ICANN
• Anti-Abuse Best Common Practices for Hosting and Cloud Service Providers, M3AAWG
• Mail runtime configuration, PHP manual
• postsuper(1), Postfix
• The Exim command line, Exim specification