An abuse report says a site on your account is doing something it should not: sending spam, hosting a phishing page, serving malware, or attacking another server. Handling one badly costs you the server; handling one slowly costs you the client's neighbours.
The reports are usually accurate. They come from automated systems that saw the traffic.
Act first, investigate second
The instinct is to check whether the report is right before doing anything. That order is wrong when the report describes active harm.
A compromised site sending spam is damaging the server's reputation every minute it continues, and that reputation is shared by every client on it. Mail from unrelated accounts starts being rejected because of one compromised site.
Suspend the account or the specific site, then investigate. Suspension is reversible in one click; a blocklisted server IP takes days to clear and affects everyone.
Tell the client immediately
Before they discover it themselves, and in plain language: what was reported, what you did, and what happens next.
A client whose site is suspended without explanation assumes you broke something. The same client told "your site was compromised and is sending spam, I have taken it offline to protect your domain's reputation" understands you are protecting them.
Say what you need from them and by when. Silence in either direction is what turns a technical problem into a lost client.
Find out how it happened
This is what stops it recurring. Skipping it means the same conversation in a fortnight.
Four causes account for nearly all of it: an outdated plugin or theme with a known vulnerability, a weak or reused password, nulled software with a backdoor built in, and another site in the same account that was compromised first.
That last one matters to you specifically. One account holding several sites means a compromise in the weakest one can reach the others, which is an argument for separate accounts rather than addon domains. Cleaning up a hacked WordPress site explains the recovery in full.
Check the neighbours
Before restoring anything, look at whether the compromise spread.
Check other accounts for files modified around the same time, and for the same patterns the log showed. A file with a world-writable permission is the usual bridge between accounts, and it is worth looking for on any server where one site was compromised. There is more on why 777 is the exposure in understanding file permissions.
Stop the outbound damage
Two immediate actions on a spam incident, independent of cleaning the site.
Clear the mail queue of the outbound messages. Otherwise they keep sending after the site is offline, and the reputation damage continues.
Then check whether the server's address ended up on a blocklist. Delisting usually requires the sending to have stopped, so do it in that order, requesting removal while spam is still leaving makes the next request harder.
Reply to the report
Most abuse reports come with an address that accepts a response, and answering matters more than people think.
Say what you found, what you did, and when. A provider that responds is treated differently by upstream networks and blocklist operators than one that ignores reports.
Keep it factual and short. You are recording that the issue was handled, not writing an incident report.
Restore deliberately
Do not unsuspend because the client asked. Unsuspend when the site is actually clean.
Three conditions: the entry point identified and closed, the software updated, and passwords changed. A site restored without the entry point closed is reinfected within days, and the second suspension is a worse conversation than the first.
If the client cannot or will not do the work, the honest options are doing it yourself as a paid job, or ending the relationship. Hosting a site you know is compromised is a decision with consequences for everyone else on the server.
Write down what happened
Date, account, what was reported, what you found, what you did, when it was restored.
This matters for two reasons. A client who is compromised twice is a pattern rather than bad luck, and you need the record to make that case. And if your upstream provider ever asks how you handle abuse, having answers is the difference between a conversation and a suspension of your own.
Reduce the odds in advance
Most of this is preventable, and cheaply.
Keep a record of which client sites run what, so a disclosed vulnerability is a search instead of an audit. Encourage or require two-factor authentication on control panel logins. Block outbound mail from anything except the mail service, so a compromised script cannot send at all.
And watch outbound volume instead of waiting for a report. A sudden rise in outbound mail from one account is visible hours before anyone complains. Managing quotas and bandwidth walks through reading it.
Set the expectation before it happens
Put it in your terms: what you will suspend for, whether you notify first, and what the client must do to be restored.
A client who agreed to that in advance reacts very differently from one meeting the policy for the first time while their site is offline. Reseller best practices walks through the wider set of things worth writing down early.
Preserve the evidence before cleaning
The instinct is to remove the damage immediately, and doing that first destroys the record of how it happened.
d=/root/incident-$(date +%F); mkdir -p "$d" cp -a /home/username/public_html "$d/files" 2>/dev/null cp ~/logs/example.com* "$d/" 2>/dev/null last -20 > "$d/logins.txt"; find /home/username -newermt '-7 days' -type f > "$d/recent.txt"
Copy the account, the logs and the recent login record before changing anything. It costs disk and minutes, and it is the only chance to capture the state.
Without it, the question of how the intrusion happened cannot be answered, which means the same route stays open after the cleanup. That is why some accounts are compromised repeatedly.
Find the entry point before restoring
Restoring a backup returns the site to a working state and does nothing about how it was reached.
find /home/username/public_html -newermt '-30 days' -name '*.php' 2>/dev/null | head -20
grep -rl 'eval(base64_decode\|gzinflate(base64' /home/username/public_html 2>/dev/null | head
awk '$9 == 200 && $7 ~ /\.php/ {print $7}' ~/logs/example.com | sort | uniq -c | sort -rn | head
Recently modified code files, obfuscated content, and unusual requests that succeeded are the three signals worth reading together.
If the backup you restore predates the intrusion, the vulnerability is restored with it. If it postdates the intrusion, so does the intruder. Establishing the date is what makes the choice of backup meaningful rather than arbitrary. Backing up and restoring covers the restore itself.