Veebileht häkitud? Kui WordPress hakkab võõraste uste taga käima

Your website should showcase your services, generate enquiries and help drive sales. But one WordPress website had quietly taken on a few extra responsibilities without its owner's knowledge: scanning other servers and running malicious scripts.

Someone had hired themselves for the job. They didn't ask for a salary, but they certainly knew how to cause damage.

A hacked website can look perfectly normal on the surface. The logo is in place, the service descriptions are still there, and the contact form is ready for enquiries. Under the hood, however, something entirely different might be going on.

In this case, the web host noticed suspicious activity. In a suspension notice, a technician shared a figure that was enough to raise a few eyebrows: the virtual server had made nearly 700,000 outbound connections in just 30 minutes. At the same time, port-scanning scripts were running on the server.

No, those weren't new customers.

As a website owner, you don't need to play detective inside your own server. But it's worth knowing which warning signs to look out for and why deleting one suspicious file doesn't necessarily mean the problem is solved.

In this article, we'll walk through a real case, explain what the attacker was doing on the server, how we removed the malware, and what it took to get the websites running safely again.

Website in quarantine: what did the web host's suspension notice mean?

The web host restricted access to the website after detecting activity that suggested the server had been compromised. The technician's comments revealed that several port-scanning scripts were running on the server.

A port scanner checks which network services respond on other computers or servers. In this case, it was part of the attacker's toolkit.

Put simply, your website should be welcoming customers. Instead, it had started rattling the door handles of strangers. Halloween, but not on October 31.

Thanks to COVID-19, everyone is familiar with the idea of quarantine. As Estonian rapper nublu once sang: "Some virus came along, and everyone got a vacation." Unfortunately, a website virus works the other way around. Instead of taking a holiday, the website administrator has to head into battle. Luckily, there's no need to say goodbye to the wife and kids first.

The web host restricted access to the website through the .htaccess file. The website was effectively placed in quarantine, but quarantine and recovery are not the same thing. Malicious processes can continue running in the background even when visitors can no longer access the website.

The owner didn't have to go into battle with the code themselves. Our job was to find out what was happening behind the scenes, remove the malware, cut off the attacker's access, and work with the web host to confirm that the threat had been eliminated.

The website has a virus. But what does that actually mean?

People often use the word "virus" to describe any kind of website malware. In reality, it can refer to several different problems: malicious code, hidden access points, modified files, or scripts that automatically perform harmful actions.

The same hosting account contained eight WordPress websites, only three of which were up to date. The remaining five had not been updated for a long time. Because all the websites shared the same server account, a vulnerability in one website could potentially expose files belonging to the others.

That meant we had to investigate the entire environment, not just one website. Let's just say the server environment resembled Berghain nightclub at four in the morning.

Here's what we discovered during the investigation:

The last discovery was particularly concerning. If the attacker had managed to gain elevated privileges on the server, other customers hosted on the same server could also have been at risk.

We also couldn't initially determine exactly how the attacker had gained access. The WordPress logs showed no successful unauthorised logins, but that didn't rule out the possibility of a vulnerable plugin or a security flaw in the server software.

For example, one suspicious file was found in the Akeeba plugin directory. However, that didn't prove the plugin was the entry point.

A suspect and a culprit are two different things. Even in WordPress.

Delete a file. It comes back. Like Rannamaja getting stuck in Inception.

A large part of the work involved examining files and directories. We had to distinguish the attacker's tools from normal hosting environment files, plugin components, and completely harmless temporary files.

Not every strangely named file is malware. Not every familiar-looking file is clean.

We removed the identified web shells, backdoors and malicious configurations. We also checked databases, scheduled tasks and WordPress files.

But while we were cleaning things up, more malware appeared.

This showed that the attacker still had access or that their automated processes were continuing to run. A bit like tidying up after a small child: you get one room in order, and by the time you're done, the toy box has already been emptied all over the floor in another.

During the investigation, we discovered that some malicious database tables were being recreated automatically. The attacker had also modified PHP settings and established a separate command channel that allowed commands to be executed on the server.

Removing malware and preventing it from coming back are two separate jobs. Simply deleting suspicious files wasn't enough. We also had to eliminate the mechanisms that recreated them and close any potential access routes the attacker could still use.

To make sure the websites were reliable and secure, we carried out a more thorough cleanup:

• We replaced all WordPress core files with clean original versions to eliminate any malicious changes to WordPress's own code.
• We replaced the plugins with clean versions to make sure malicious code wasn't hiding inside familiar plugin directories.
• We inspected and cleaned the databases, removing malicious entries and tables along with the mechanisms responsible for recreating them.
• We changed all important passwords and access credentials, including those belonging to WordPress users, FTP accounts and database users. We also replaced the SSH keys.
• We checked server configurations and automated tasks to prevent the attacker from restarting the removed malware.

Because several WordPress websites were hosted under the same account, the entire environment had to be checked. There's little point in cleaning one website if the attacker still has a backdoor through another.

After the cleanup, the web host reviewed the account and confirmed that everything was in order.

This time, cleaning up meant more than just emptying the trash. We had to make sure nobody could secretly fill it up again.

How can you tell if your website has been hacked?

Website owners usually can't see the processes running in the background on their servers. The first warning sign might come from the web host, a customer, or even a browser security warning.

In our case, the web host raised the alarm after detecting unusual server activity. But things don't always work out that neatly. Sometimes the problem only becomes apparent when customers start reporting strange behaviour.

Which warning signs should you look out for?

Of course, a slow website doesn't automatically mean it has been hacked. A broken plugin, an overloaded server, or another technical issue can cause similar symptoms.

Just like a mild cough doesn't necessarily mean you have pneumonia. Although there's always that one man who's convinced otherwise...

At the same time, it's worth remembering that a website working normally doesn't always mean everything is fine. Attackers aren't exactly obliged to announce themselves on your homepage.

What should a website owner do?

When you discover that your website may have been hacked, your first instinct is usually to fix the problem as quickly as possible. Especially if your website generates enquiries or sales.

But before you start deleting suspicious files or restoring a random backup, it's worth involving people who know how to assess the extent of the problem.

1. Forward the web host's notice to your website administrator

If your web host sends a warning, forward the entire message to your website administrator. Even technical details that seem meaningless at first can be extremely useful when investigating the problem.

For example, in our case, the number of outbound connections and the mention of port scanners helped us understand what was happening on the server.

If you notice the problem yourself or a customer reports it, make a note of the following:

• What did you notice, or what did the customer report?
• Which URL was affected?
• When was the problem first noticed?
• Do you have a screenshot or an error message?

That's enough to get started. There's no need to include passwords in your first email.

2. Involve both your web host and website administrator

Your web host can see what's happening on the server and restrict access when necessary. Your website administrator understands the website's structure, plugins and normal behaviour.

A more serious incident may require both parties to work together. In our case, the web host restricted access to the website while we handled malware removal and cleaned the environment. Once the work was completed, the web host carried out its own review of the account.

This also prevents the website owner from getting stuck between two parties, with one claiming everything is fine on their end while the other is still trying to figure out why the malware keeps coming back.

3. Agree on the order of cleanup and recovery

Wanting to get your website back online as quickly as possible is completely understandable. But rushing the process can bring the problem right back.

For example, restoring a random backup might restore the malware along with the website. If the vulnerability or backdoor used by the attacker is still there, the same problem could soon return.

That's why it's important to determine which files and backups can be trusted, which access credentials need updating, and what must be done before the website goes live again.

The "Restore" button should mean recovery, not another season of the same mess.

When can you say your website is safe again?

A working homepage isn't enough.

Just because your website loads and the contact form works doesn't mean the entire environment is secure. Especially if the attacker has left behind multiple backdoors and mechanisms that automatically restore malware.

In our case, the web host's confirmation that the account had been cleaned was an important milestone, but the recovery work didn't end there.

We eventually replaced all WordPress core files and plugins with clean versions, inspected and cleaned the databases, and updated all access credentials, including user passwords, FTP accounts, database users and SSH keys.

The goal was to make sure we had removed not only the visible malware but also the opportunities that could allow the attacker to return.

One question, however, remained unanswered: how did the attacker originally gain access to the server?

During the investigation, we identified several possible entry points, but the available evidence wasn't enough to confirm any of them. This also matters for future security, because if the original entry point remains unknown, the risk of a similar incident can't be completely ruled out.

After an incident like this, website owners should ask four questions:

• What was discovered, and which websites were affected?
• What malware was removed, and how was the attacker's access blocked?
• Have all necessary recovery steps and security updates been completed?
• How will the websites be monitored to prevent the problem from recurring?

The answer doesn't need to be ten pages of server logs. But it should make clear what happened, what was fixed, and what condition the websites are currently in.

No website can be made completely immune to future attacks. But you can certainly do everything possible to make sure the same unwanted guest doesn't walk back in through the backdoor the next day.

Can a hacked website affect SEO?

Yes, it can. If visitors end up on an unfamiliar website instead of your service page, or encounter a security warning, both trust and the likelihood of receiving enquiries can suffer.

Google may display warnings in search results or browsers for websites with security issues. You can check detected problems in the Security Issues report in Google Search Console.

In our case, we found no SEO spam or malicious redirects. However, that doesn't mean you should skip checking your website's search visibility after removing malware.

After the cleanup, it's worth checking:

• Are all important service and product pages working?
• Has any unfamiliar content or unwanted redirects been added to the website?
• Does Google Search Console report any security issues?
• Do you need to request a review after resolving the issues detected by Google?

If Google has identified a security issue on your website, make sure the problem has been resolved across the entire website before requesting a review. Fixing just one example page isn't enough.

The time and money invested in SEO deserve a website that remains technically sound. Casino links added by an attacker probably aren't part of your content strategy for the next quarter.

What can we learn from this case?

The most important lesson from this case is simple: website security doesn't depend on just one plugin or a strong password. If several websites share the same hosting account, all of them need proper maintenance.

A security plugin alone won't save you. It can help detect threats and block certain attacks, but it doesn't replace regular updates or secure access management. An old campaign website or a forgotten test environment can also become a weak link. A website doesn't magically become secure just because nobody visits it anymore.

A hacked website doesn't always need to be rebuilt from scratch. In our case, we managed to restore the websites by replacing WordPress core files and plugins, cleaning the databases and updating all access credentials. The important thing is to assess the extent of the damage and make sure the files and data used for recovery can be trusted.

Consistent maintenance is the best defence. WordPress, plugins and other server software need regular updates. Unused accounts and plugins should be removed, passwords should be unique, and two-factor authentication should be enabled wherever possible. It should also be clear who's responsible for backups, updates and responding to security warnings.

The most important thing is that maintenance actually happens. "I think someone's taking care of it" isn't exactly a solid security strategy.

Website owners don't need to read malicious code or understand every server configuration. But they should respond quickly when problems arise and involve people who know how to resolve them.

If your website is doing things you never asked it to do, get in touch with Ballers. Include the notice from your web host or describe what you've noticed. We'll help you figure out what's going on and where to start.