Removing Malicious Code from a Website: A Guide for Businesses
15 min read
Removing Malware From a Website: A Guide for Businesses
If your website is suddenly redirecting visitors to suspicious pages, your browser shows a warning, or your host reports detecting malicious code on the server, you're dealing with an infection that needs to be removed carefully and in the right order. Removing malware from a site isn't just deleting one suspicious file — it's a process where you first contain the damage, preserve evidence, remove every one of the attacker's entry points, rotate credentials, fix the vulnerability, and only then bring the site back online. This guide walks you step by step through remediation, when restoring from a backup is the right call, and how to prevent the infection from coming back a week later.
Moxy-web — Strengthen your website's securityMoxy-web builds custom web solutions and offers hosting, technical support, and maintenance for businesses.Check out Moxy-web's servicesTL;DR
Don't delete everything right away: first isolate the site or server and export the logs, otherwise you'll lose the trail of how the attacker got in.
A visible malicious file is often just a symptom; behind it there can be a web shell, additional admin accounts, and stolen passwords.
Rotate every credential (admin, database, hosting, FTP/SSH), fix the exploited vulnerability, and only then restore the site from a verified clean backup.
After cleanup, monitor the site, request a review from Google, and consider voluntarily reporting the incident to SI-CERT.
Regular updates, two-factor login, centralized logs, and regular, verified backups are the most reliable way to prevent reinfection.
Table of Contents
1. How to recognize that your site is infected
A website infection rarely announces itself with a dramatic message on the homepage. Far more often, you notice small but telling signs: mobile visitors get redirected to gambling sites or fake sweepstakes, strange foreign-language pages you never published show up under your domain in search results, forms start sending bizarre messages, or your host notifies you of unusual resource usage or a detected suspicious file. Sometimes a customer calls to say their antivirus software blocked them from visiting your site.
Google is also an important signal. When it detects a compromised site, it can show a warning in search results that the site may have been hacked, and the owner can see examples of affected URLs in Search Console. If your site is connected to Search Console, that's one of the first places to check. Through its Safe Browsing service, Google warns visitors about dangerous sites and helps owners identify and fix the issue, which means a warning like this directly affects traffic and trust.
It's also worth understanding why an infection is a business problem, not just a technical inconvenience. In its overview of website security, the US agency CISA lists site defacement, downtime, theft of sensitive data, and using a site to attack visitors among the consequences of a compromise. Your website, then, is part of your business infrastructure, much like a physical storefront: if someone breaks into your shop, you don't just replace the broken glass — you check what was taken and change the locks.
2. First steps: contain the damage before you start cleaning
Most owners' first instinct is to immediately delete suspicious files or overwrite the entire site with an old backup. That's understandable, but it's exactly the most common mistake. OWASP's guidelines on hosting and web presence warn that overwriting too quickly loses data about the initial point of entry, the scope of the compromise, and any potential data theft. Without that information, you might clean the site, only for the attacker to walk back in through the same door.
So contain the damage first. Temporarily put the site into maintenance mode, or have your host take it out of public access, so visitors stop receiving the malicious code. If it's your own server or a virtual server, isolate it, in coordination with your host, from other systems it's connected to. Then preserve your evidence: export your server and web logs, firewall logs, web application firewall (WAF) logs, and content delivery network (CDN) logs, and make a copy of the database and the entire site folder in its current, infected state. When a server compromise is suspected, CISA explicitly recommends isolation and preserving logs before removing anything.
Slovenia's national response center, SI-CERT, accepts exactly this kind of information when you report an incident: logs, samples of the malicious code, original messages, and URLs. Screenshots of redirects or warnings come in handy too. If you suspect customer personal data was stolen, or that this is a targeted attack, consult an incident-response specialist and a lawyer or data protection officer before taking any destructive action, since careless cleanup can destroy evidence you'll need later.
3. Why deleting the visible file isn't enough
When you open your site's folder and find a file with a strange name, or code that obviously shouldn't be there, the fix seems simple. In practice, though, a visible infection is often just the last link in a chain. Attackers typically leave multiple doors open behind them: a web shell, additional admin users, altered system files, scheduled tasks that re-trigger the infection, and stolen passwords.
A web shell is malicious code planted on a vulnerable web server that lets an attacker run commands, steal data, and upload additional files. With it, an attacker retains access even after you've closed the original hole. That's why the choice between quick deletion and a controlled, forensically sound remediation depends on the risk: a simple brochure site with no forms or user accounts calls for a different approach than an online store with payments and a customer database.
The same goes for automated scans. Scanners offered by your host, or security plugins, are useful for an initial assessment, but on their own they don't guarantee complete removal. Even for infected computers, SI-CERT warns that an antivirus scan doesn't necessarily remove all malicious software. The same logic applies to a website: a scanner finds known patterns, but it can miss cleverly hidden or new modifications.
4. The cleanup process, step by step
Once the damage is contained and evidence preserved, you move on to the actual cleanup. The order below follows CISA's recommendations for removing known malware and web shells, adapted for a typical business website.
Scope the infection. Compare current files against a known-clean version (source code from your repository, or the official version of your content management system). Look for files modified during the period before detection, and review the database for inserted scripts and unknown users.
Identify the entry point. Look through the logs for the first suspicious requests. Common causes include an outdated extension, a weak or stolen password, a vulnerable file-upload form, or a compromised hosting account.
Remove every element of the infection. Delete web shells, malicious files, injected code in the database, unknown admin accounts, and any scheduled tasks you didn't create.
Replace the core. Don't manually clean system files and libraries line by line — replace them with fresh, verified copies from the official source.
Fix the vulnerability. Update the application, server software, and all dependencies, and close the hole the attacker came through.
Rotate every credential. More on this in section 6, since this step matters enough to deserve its own treatment.
Verify and monitor. Rescan the system for indicators of compromise, and keep a close eye on the site for a few weeks, since an infection that wasn't fully removed often returns within days.
This last step often gets skipped, because the site appears to be fine again. But CISA stresses that you need to confirm removal was successful and monitor the system after restoration, otherwise an attacker who retained access simply continues where they left off.
5. Restoring from a backup: when it's the right choice
A backup can be the fastest path to a clean site, but only under two conditions: it was made before the compromise, and it's verified clean. If you don't know when the attacker first got in, you risk restoring a backup that already contains the web shell, reintroducing the infection to the server with your own hands. That's why CISA recommends restoring from an untainted image or replacing compromised files, and verifying integrity before bringing the site back online.
| Situation | Recommended approach |
|---|---|
| The infection is fresh, you have a backup from before the breach, and you know the cause | Restore from a verified backup, rotate passwords, fix the vulnerability |
| The breach date is unknown, backups may be infected | Clean based on comparison with clean source code, use backups for content only |
| Suspected theft of customer or payment data | Bring in an incident-response specialist before any deletion |
| The infection keeps coming back after cleanup | A full review of the server, hosting, and connected accounts, migrating to a clean environment if needed |
| The site is outdated with no security updates | Consider a redesign instead of repeated patching |
Only restore from a backup after you've fixed the vulnerability and rotated passwords — never before. A well-designed retention strategy helps here too: our guide to website backups for businesses explains how many versions to keep and where, and our article on checking RTO, RPO, and recoverability explains how to verify in advance that a restore would actually work.
6. Passwords, access, and connected systems
Rotating passwords is the step businesses most often carry out only partially: they change the site administrator's password and leave every other access point untouched. If an attacker accessed your files, it's very likely they also read your configuration files, including the database password and possibly keys to external services. When discussing removing web shells, CISA lists rotating admin, database, hosting, and FTP/SSH credentials as an integral part of remediation.
In practice, that means changing the passwords of every content management system user, database passwords, your hosting control panel, FTP, SFTP, and SSH access, API keys for payment, email, and analytics services, and access to your domain registrar. That last one is often overlooked, even though OWASP describes attacks where an attacker takes over a hosting or registrar account and changes what your domain displays. Alongside this, enable two-factor login everywhere you can.
Also check your connected systems. If your website connects to a CRM, a warehouse system, or a mail server, review whether unusual requests passed through those integrations. For an online store, check whether code was inserted into your checkout page that could intercept customer data. If personal data was compromised, consult your data protection officer or a lawyer about your obligations, since the deadlines for action are short.
7. Google, visitors, and SI-CERT
Once your site is clean, you need to rebuild trust with search engines and visitors. If Google flagged your site as compromised, review the security issues report and sample URLs in Search Console, and request a review once you've fixed the issue. In its Search Help, Google stresses that you need to fix the security issue that enabled the infection, otherwise it can happen again. So don't submit a review request until you're confident the cause is resolved.
It's also worth considering notifying your customers. A brief, honest message explaining that you detected the issue, fixed it, and strengthened your protections usually preserves more trust than silence, especially if customers were redirected to suspicious pages.
You can voluntarily report a website infection to SI-CERT, which advises identifying the infection, removing it, and addressing its consequences. Entities covered by Slovenia's information security act (ZInfV-1) can, per SI-CERT's guidance, also report incidents that don't meet the threshold for mandatory reporting, since the data benefits the broader community. For small and medium-sized businesses without their own security team, this is valuable support. SI-CERT's system protection information page also publishes verified lists of phishing URLs your IT team can build into email filters and other security systems.
8. How to prevent reinfection
A cleaned site with no change to how it's maintained is a site waiting for its next breach. For website security, CISA recommends a combination of measures: regular backups, centralized logs, two-factor login, a content security policy (CSP), a web application firewall, a CDN, and static and dynamic code security scans.
For a business website, this translates in practice into regular updates to the application, server, and every dependency, as few third-party extensions as possible, access limited to those who genuinely need it, and clearly defined accountability: someone needs to know who applies updates, who reviews the logs, and who acts on an alert. Hosting is also a big part of this protection; we cover how to set it up in our guide to secure website hosting, with a broader framework in our article Web Security for Businesses Without Unnecessary Risk.
If a site gets infected repeatedly, or runs on outdated technology that no longer receives security patches, patching is often more expensive than a redesign. We explain when this step makes sense in our article When Does a Website Redesign Make Sense?.
Our view: security starts with architecture
At Moxy-web, we build websites, stores, and applications custom, writing our own code rather than assembling solutions out of pre-built platforms and a pile of extensions. Experience has taught us that every additional third-party component is another door that needs regular locking, so we believe the best malware removal is the one you never have to perform. When your code is transparent, integrations with external systems are deliberate, and content is managed through a simple interface, an attacker has less room to work with and you have more control.
At the same time, we're realistic: no site is invulnerable. That's why we consider what happens after launch just as important as secure development — regular maintenance, updates, access control, and backups we actually restore and verify from time to time. We advise businesses to think of security as an ongoing process, not a one-time fire to put out. If an infection reveals that your site rests on an outdated foundation, that can be an opportunity for a solution that's more secure, faster, and easier to manage.
— Ziga
A secure site with clear maintenance
If you want your website's security looked after by a team that knows the site down to the last line of code, Moxy-web offers custom website, store, and application development, hosting and domain registration, and support and maintenance. We take an individual approach to assess your current state and propose a solution that fits your business. Check out our services or read more about our team and get in touch.
Frequently asked questions
Can I remove the malicious code myself?
For a simple presentational site, where you have a clean backup from before the breach and know the cause, it's possible, as long as you consistently follow the order: isolation, preserving logs, cleanup, rotating passwords, fixing the vulnerability, and monitoring. For an online store, a site with user accounts, or suspected data theft, it's safer to bring in a specialist, since a mistake during cleanup can destroy evidence or leave the attacker with access.
How long does removing an infection take?
Duration depends on the scope of the infection, the quality of your backups, and how quickly you find the entry point. A simple case with a clean backup can be resolved quickly, while a complex breach with multiple web shells and compromised accounts requires a more thorough analysis. Don't forget that cleanup is followed by a monitoring period lasting a few weeks.
Is it enough to just restore the site from a backup?
Not always. A backup is only usable if it was made before the breach and is verified clean, and you should only restore it after rotating passwords and fixing the vulnerability. Otherwise, an attacker simply re-enters through the same door, or you reintroduce the web shell along with an infected backup.
Do I have to report the infection to SI-CERT?
For most businesses, reporting an infected website is voluntary but useful, since SI-CERT uses the data to identify infected systems and warn others. Entities covered by ZInfV-1 have specific reporting obligations, so they should check SI-CERT's guidance. If personal data was compromised, consult your data protection officer about any additional obligations.
How long will Google keep showing the warning after cleanup?
The warning typically disappears once Google confirms, after your review request in Search Console, that the site is clean. Only submit the request once you've fixed the cause of the infection, otherwise the review will fail and the process will take longer.