---
title: What a hacked site looks like from the server side
description: The signs we see on our servers when a site is compromised, from outbound spam to rogue admins, and why cleanup fails without finding the way in.
date: 2026-07-06
updated: 2026-07-06
tags: [security monday, malware, incident-response]
url: "https://drivenhost.com/blog/hacked-site-server-view"
author: DrivenHost
---

This Security Monday is a bit different. Instead of telling you what to do, we want to show you what we see. When a site on our servers gets compromised, the owner usually notices last. The server notices first, and the signs are remarkably consistent. Knowing them helps you spot trouble early and understand what a real cleanup involves.

## The spam spike

The most common first symptom is not on the website at all. It is in the mail queue. A site that normally sends a handful of contact-form messages a day suddenly tries to send thousands of emails an hour, and our monitoring flags the account within minutes.

This is what most hacked small-business sites are actually for. Nobody wanted your content. They wanted a reputable server with a clean sending history to push spam and phishing through. The site keeps looking perfectly normal to visitors while the domain quietly lands on blocklists, which is often how owners eventually find out: their legitimate email stops arriving.

If your messages start bouncing out of nowhere, think compromise before you think email problem.

## The admin user nobody created

Inside WordPress, the classic artifact is an administrator account that no one remembers making. Sometimes it is brazenly named something generic; sometimes it imitates a real name with one letter changed. It frequently arrives with an email address on a domain you have never heard of.

This is worth checking this week: open your users list, filter to administrators, and account for every single one. An extra admin is not a curiosity. It is a door, and it means the attacker plans to come back after you clean up.

## Files that do not belong

At the filesystem level we find the same fingerprints again and again. PHP files with random names sitting in the uploads folder, which should contain media and nothing executable. Legitimate core files with a long line of encoded garbage prepended. Extra "plugins" consisting of a single suspicious file. Timestamps that show a cluster of files all modified at 3 a.m. on a Tuesday when nobody was working.

Individually each file looks minor. Together they are a toolkit: a way in, a way to hide, and a way to make money off your server until someone notices.

## Why deleting the malware is not the cleanup

Here is the hard-won lesson of this whole post. When people clean a hacked site themselves, they usually delete the bad files, change the admin password, and declare victory. Two weeks later the site is hacked again, and now they believe the attacker is targeting them personally.

They almost never are. The site was reinfected because the original hole was never closed. The malware was the symptom; the vulnerable plugin, the leaked password, or the forgotten second door was the disease. As we keep saying in this series, most of those holes are old, known and patched, which is [why updates matter](/blog/why-updates-matter) so much in the first place.

A real cleanup answers one question before anything else: how did they get in? That means reading logs, comparing file timestamps against access records, and checking every admin account and stored credential. Then, in order: close the hole, remove every implant (not just the obvious one), rotate every password, and restore damaged files from a clean copy. This is also the moment a tested backup pays for itself, a point we laboured happily in [backups that actually restore](/blog/backups-that-restore).

Skip the first step and the rest is redecorating a house with the back door open.

## When to call us

If you host with us and you see any of the above, or we have already flagged your account for outbound spam, contact [support](/support) sooner rather than later. We can see things you cannot from inside WordPress: the mail queue, the raw access logs, the file changes with timestamps. Finding the way in is mostly a matter of having those logs and knowing where to look, and that part of the job is much easier on day one than on day twenty.

A hacked site is a bad week, not a catastrophe, provided the cleanup finds the cause. Make sure yours does.