The website has slowed down, even though visitor numbers haven’t gone up. The CPU stays busy at night, unfamiliar messages keep appearing in the mail queue, and the provider reports suspicious requests from the server’s IP address. The first assumption is usually simple: something has broken. But it may be more serious than that. A server can still look perfectly normal while somebody else is already using it to send spam, attack other systems, or reach stored data.
One symptom is rarely enough to confirm a breach. A backup, a coding error, or a sudden wave of bots can all cause high load. An unfamiliar file may have arrived with an update. Suspicion becomes more reasonable when several unusual changes appear together and none of them has an obvious explanation.
Signs that may point to a server breach
Start by comparing the server’s current behavior with its usual pattern. An administrator normally has a rough idea of how many resources the website uses, when background jobs run, and how much traffic passes through the server. A sharp break from that pattern needs a closer look.
Common signs of suspicious activity include:
- the CPU, RAM, or disk stays under load for no clear reason;
- unknown processes, services, users, or scheduled tasks have appeared;
- the logs show successful logins from unfamiliar IP addresses or at unusual hours;
- website files or system settings changed without the administrator doing it;
- the server is sending large volumes of email, opening external connections, or producing unusual traffic;
- the IP address has appeared on spam blocklists, or someone has reported attacks coming from your server.
None of these points proves a breach by itself. But when the server starts using more resources, connecting to unknown addresses, and running a process nobody recognizes, all at once, an ordinary fault is no longer the best explanation.
The load went up, but nothing changed on the website
The clearest sign is often a website that suddenly starts lagging. Pages take longer to load, the control panel responds slowly, and CPU usage sits close to the limit. A hidden crypto miner may behave this way. In other cases, the server is guessing passwords, scanning networks, or carrying out instructions from an attacker.
First, find out which process is using the resources. A familiar-looking name doesn’t make it safe: malware can be disguised as a system service. Check the file path, the account running it, when it first appeared, and which network connections it opens.
Disk activity matters too. Heavy writing may mean a program is creating temporary files, packaging stolen data, or bringing deleted malicious code back again and again. When the load starts just after an update, an import, or a backup job, there may be a normal reason. Otherwise, the check shouldn’t be put off.
Unknown logins have appeared
Authentication logs often say more than a general resource graph. Successful logins from addresses the administrators never use, connections in the middle of the night, or a login that follows hundreds of failed attempts are all worth investigating.
After gaining access, an attacker may stop using the stolen password. On Linux, they can add their own SSH key, create another user, or give that account permission to run administrative commands. On Windows Server, check the administrator group, Remote Desktop logins, new services, and any recent changes to security policies.
That is why changing one password does not always fix the problem. Leave behind an unknown account, key, or hidden service, and access can be restored quickly.
Files changed without anyone touching them
After a website is breached, malicious code often hides among ordinary CMS files. It may have an unremarkable filename, sit in the uploads directory, or pass itself off as part of a plugin. From the outside, the website can keep working as usual.
The effects show up later. Visitors are sent to unrelated pages, foreign content appears in search results, or browsers start warning that the site is unsafe. Sometimes the code runs only for people in certain countries or on mobile devices. The owner checks from their own computer and sees nothing.
Look at files that had no reason to change recently, along with directories that allow writing. When a suspicious file comes back after deletion, a process, scheduled task, or another script is probably still restoring it.
The provider or email service raised the alarm
Sometimes the first warning comes from outside the monitoring panel. A hosting provider may detect scans of other systems’ ports, password-guessing attempts, or an abnormal number of outgoing connections. An email service may restrict sending, and the server’s IP address may turn up on spam blocklists.
That warning shouldn’t be dismissed just because the website still opens. Taking the site down completely is often of little use to an attacker. Quietly keeping control of the server’s resources for as long as possible is much more valuable.
The attacker may not have full access to the operating system. The issue could be limited to one infected website, a vulnerable plugin, or a stolen mailbox password. Still, a local compromise can become a much larger one if the malicious code gains extra privileges.
What to do when you suspect a breach
Don’t begin by deleting files at random and rebooting the server. Logs, active connections, and other traces may disappear with them, making it harder to understand how the intrusion happened. First, restrict outside access where possible, preserve the logs, and record the system’s current state.
Then check running processes, users, keys, network connections, scheduled tasks, and recent file changes. Change passwords from a device you know is safe. This includes not only server access, but also the control panel, CMS, database, email accounts, and related services.
Finding and removing one infected file is not enough. The weakness that allowed it onto the server still needs to be closed. Other websites should be checked as well, and any hidden route back into the system must be found. In some cases, rebuilding a clean server and restoring verified data from a backup is safer than trying to clean the existing system by hand.
- When there isn’t enough experience to investigate the incident properly, bring in a system administrator or cybersecurity specialist. They can work out how the foreign code entered the system, whether hidden access remains, and which data may have been compromised. Backups should be kept away from the main server and tested occasionally to make sure they can actually restore the project. They won’t prevent a breach, but they can return the website to a clean state when the infection or damage is found too late.
Leave a Reply