Website Malware Investigation: How to Find Malicious Code, Determine What Changed and Investigate the Source
Discovering malware on a website creates an immediate problem.
The malicious code needs to be contained and removed.
But another question is just as important:
How did it get there?
A business may remove an infected file only to discover the malware again days later. A security scanner may identify suspicious JavaScript without explaining who placed it there. A developer may clean a compromised plugin while an unauthorized administrator account remains active. A hosting company may restore a backup that already contains the infection.
That is the difference between simply cleaning a website and conducting a website malware investigation.
A website malware investigation examines malicious or unauthorized code together with server logs, website files, accounts, databases, hosting records, security events and other available digital evidence to determine what changed, when it changed, how the compromise may have occurred and whether the attacker established additional access.
The objective is not merely:
Find malware → delete malware.
It is:
Preserve → identify → correlate → investigate → contain → remediate → verify.
What Is Website Malware?
Website malware is malicious or unauthorized code placed within a website, web application, server or related infrastructure.
Depending on the attack, malicious code may be used to redirect visitors, inject spam, steal credentials, manipulate website content, create unauthorized pages, maintain server access, load external scripts, alter checkout behavior or support additional malicious activity.
Not every suspicious file is necessarily malware.
Web applications contain thousands of legitimate scripts and files. Plugins, themes, developers, security tools and hosting systems can also create or modify files.
The purpose of the investigation is to distinguish legitimate website activity from malicious modification.
Signs a Website May Contain Malware
Some website infections are obvious.
Visitors may suddenly be redirected to unfamiliar websites. Search engines may display warnings. Security products may block the domain. Strange pages may appear in search results. Administrators may discover unknown PHP or JavaScript files.
Other infections are deliberately difficult to notice.
A redirect may affect only mobile users.
Malicious code may execute only when someone arrives from a search engine.
An injected script may target only checkout pages.
Spam pages may exist without appearing in the site’s normal navigation.
A backdoor may produce no visible changes at all.
That is why the absence of an obvious symptom does not necessarily establish that the website is clean.
Website Malware Investigation vs. Malware Removal
These are related but different activities.
Malware removal asks:
Which malicious files or code should be removed?
Investigation asks:
How did those files get there?
When did they appear?
What account or vulnerability was involved?
What happened after they appeared?
Did the attacker modify anything else?
Does another access mechanism remain?
Was sensitive information potentially affected?
Is the compromise limited to this website?
A business often needs both.
Preserve Evidence Before Cleaning Where Practical
If the website is actively harming visitors, containment may need to happen immediately.
Protecting users and systems comes first.
But when circumstances permit, preserve relevant evidence before deleting suspicious files, restoring backups or rebuilding the server.
Useful evidence may include website files, suspicious scripts, server logs, application logs, authentication records, administrator accounts, database information, hosting activity, security alerts, backups and configuration files.
Our Digital Evidence Preservation guidance explains the broader principles.
The key point is simple:
Do not destroy useful evidence unnecessarily while trying to remove the threat.
Record What Was Initially Discovered
The first observations can become valuable later.
Document:
When the problem was discovered.
Which pages were affected.
Which files were flagged.
What security product detected the problem.
Any malicious URLs or redirect destinations.
Unknown administrator accounts.
Hosting-provider warnings.
Search-engine warnings.
Recent website changes.
And any unusual behavior reported by visitors.
This creates a starting point for the investigation.
Preserve the Malware Sample
If suspicious code can be preserved safely, it may provide valuable investigative information.
Deleting the only copy immediately can eliminate clues about what the code did.
Depending on the incident, analysis may help determine whether the code was designed for redirects, credential theft, persistence, spam generation, command execution or another purpose.
Malicious code should be handled carefully and only within an appropriate authorized environment.
Establish When the Malware Appeared
Timing is critical.
Suppose a business discovers malicious code on September 20.
That does not mean the website was compromised on September 20.
The code may have existed for weeks.
Investigators may compare file metadata, backups, deployment history, logs, security alerts and other evidence to narrow the timeframe.
A simplified timeline might reveal:
September 3 — Suspicious login occurs
September 3 — Plugin file modified
September 4 — Unknown PHP file appears
September 5 — File receives repeated web requests
September 7 — Additional malicious files appear
September 10 — Mobile redirects begin
September 20 — Website owner discovers problem
The malware discovery date and compromise date can be very different.
Examine Recently Modified Files
Malicious website activity often involves file changes.
Investigators may compare current files with trusted versions, known application packages, source repositories, earlier backups or previous server snapshots.
The goal is to identify unexpected modifications.
However, modification timestamps alone should not decide the investigation.
Legitimate updates, deployments, synchronization and restoration can also alter timestamps.
They are one piece of the timeline.
Malicious PHP Files
PHP-based websites can be targeted with malicious PHP files or injected PHP code.
Suspicious code may be hidden inside legitimate-looking files or placed in directories where executable code would not normally be expected.
Investigators may examine what the code does, when the file appeared, whether it was accessed, what other files changed around the same time and whether logs reveal how it was created.
Malicious JavaScript
JavaScript injection can affect visitors directly.
A malicious script may load external resources, redirect users, alter page content, capture information or execute conditionally.
The investigation should determine where the JavaScript originated.
Was a website file modified?
Was the code stored in the database?
Was a third-party script compromised?
Was a plugin responsible?
Was a tag-management account altered?
Did an administrator intentionally add it?
The visible JavaScript is sometimes only the final symptom.
Obfuscated Code
Attackers may attempt to make malicious code difficult to understand through encoding or obfuscation.
But legitimate software also uses minification and other techniques that can make code appear unusual.
Therefore:
Obfuscated-looking code is not automatically malicious.
It should be analyzed in context.
Web Shells and Backdoors
One of the more serious findings during a website malware investigation is a web shell or other backdoor.
A web shell can potentially allow unauthorized interaction with the server through web requests.
Depending on its functionality and server permissions, it may allow an attacker to manipulate files, execute commands or facilitate further activity.
Deleting the web shell is important.
But the investigation should also ask:
How was it uploaded?
Who or what accessed it?
What happened after it appeared?
Did it create additional persistence?
Does the original access path still exist?
One Malware File May Not Be the Whole Infection
A compromised environment can contain multiple malicious components.
One file may serve as an entry point.
Another may provide persistence.
Another may inject redirects.
Another may recreate deleted malware.
That means finding and deleting the first obvious malicious file does not necessarily establish that the environment is clean.
Why Website Malware Comes Back
Recurring malware is an especially important warning sign.
Possible explanations include an unresolved vulnerability, stolen credentials, an undiscovered backdoor, a malicious administrator account, a scheduled process that recreates files, another compromised website in the hosting environment, a compromised developer account, or a backup that already contains the infection.
Repeated reinfection should trigger investigation into the root cause rather than another identical cleanup.
Scheduled Tasks
Some environments use scheduled processes for normal website maintenance.
Attackers may also abuse scheduled execution mechanisms to maintain persistence.
If malicious files repeatedly return after deletion, investigators may examine scheduled jobs, application tasks, automation and other persistence mechanisms.
Not every unfamiliar task is malicious.
Its origin and behavior need to be established.
WordPress Malware
WordPress compromises deserve particular attention because the malicious activity may exist across several layers:
WordPress core files.
Plugins.
Themes.
Uploads.
Administrator accounts.
The database.
Configuration files.
Hosting accounts.
Or the underlying server.
A future WordPress Hacked Investigation article will examine this environment in depth.
For a malware investigation, the important point is not to assume that replacing WordPress core files eliminates the entire compromise.
Malicious Plugins and Themes
Attackers may modify legitimate plugins or themes.
They may also install unauthorized components that appear legitimate at first glance.
Investigators can compare files with known versions, examine installation timing, review administrator activity and correlate changes with server logs.
An outdated plugin may also contain a vulnerability.
But finding vulnerable software installed does not automatically establish that it was exploited.
The evidence should connect the suspected weakness to the incident where possible.
Vulnerability Exploitation
One possible malware entry path is exploitation of vulnerable web software.
An attacker may send specially crafted requests against a vulnerable application, plugin, extension, theme or custom component.
Server logs can sometimes preserve evidence of suspicious requests around the time malicious files appeared.
That correlation can be extremely valuable.
Stolen Credentials
Malware does not always arrive through a software vulnerability.
An attacker may obtain legitimate administrative credentials.
Possible targets include CMS accounts, hosting control panels, FTP/SFTP accounts, SSH credentials, developer accounts and cloud administration.
If valid credentials were used, simply patching website software may not eliminate the access path.
Compromised Developer Accounts
A developer’s workstation or account may also provide access to the website.
If an attacker compromises a developer’s email, password manager, source repository, deployment system or computer, malicious changes may enter the website through apparently legitimate channels.
This is why the broader Website & Server Investigation pillar matters.
Sometimes the website is the destination of the compromise rather than its origin.
Administrator Account Investigation
Review administrator accounts carefully.
An attacker may create an additional administrator after gaining initial access.
That account can survive removal of the original malware.
Investigators may examine when accounts were created, which privileges were assigned, authentication activity and available records showing account changes.
Unknown accounts should be investigated rather than automatically attributed to an attacker.
Developers, agencies, hosting companies and automation can also create legitimate accounts.
Database Malware
Not all malicious website code lives in files.
Attackers may inject malicious content into a database.
That can include scripts, spam links, redirects, altered configuration or unauthorized administrator information.
Replacing infected files may therefore fail if the database remains compromised.
The website can simply begin producing malicious content again.
Search Engine Spam
Some website malware exists primarily to manipulate search engines.
Attackers may generate unauthorized pages targeting unrelated commercial searches.
The legitimate website may appear normal to the owner while search engines index thousands of malicious URLs.
Investigators may examine website files, database content, rewrite rules, sitemap behavior, server logs and other relevant evidence to determine how the spam is being generated.
Malicious Redirects
Redirect malware can be particularly difficult to investigate.
It may activate only for:
Mobile devices.
Search-engine visitors.
Specific browsers.
Certain geographic locations.
First-time visitors.
Or users without particular cookies.
This selective behavior can make the website appear normal when the administrator checks it.
A dedicated Malicious Website Redirect Investigation article can eventually target that problem specifically.
E-Commerce Malware
Online stores face additional risks.
Malicious scripts may target checkout processes, credentials or customer information.
Investigators may need to examine website code, checkout modifications, external scripts, administrator activity, server logs and relevant integrations.
If customer or payment information may have been exposed, the matter may require broader security, legal, contractual or regulatory response.
Examine Server Logs
Logs can connect malicious code to the activity surrounding it.
For example, an investigation may reveal:
14:31 — Suspicious request targets vulnerable component
14:31 — Server returns successful response
14:32 — Unknown PHP file appears
14:34 — New file receives first external request
14:39 — Additional files are created
That sequence is far more informative than merely finding the PHP file.
A future Website Log Forensics article will examine this process more deeply.
Authentication Logs
If the malware appears to have been installed through legitimate administrative access, authentication evidence becomes important.
Investigators may examine login timestamps, accounts, IP addresses, devices, MFA activity, failed attempts and other available records.
An IP address can support correlation.
It does not automatically identify the person responsible.
Hosting Account Evidence
A compromised hosting account can provide access beyond one website.
Depending on the provider, the attacker may reach files, databases, backups, DNS, email or other hosted services.
If multiple websites suddenly become infected, the investigation should consider whether the compromise exists at the hosting-account or server level.
Multiple Websites on the Same Server
Suppose a company cleans Website A repeatedly.
The malware keeps returning.
Website B on the same hosting account contains an undiscovered backdoor.
Website B may provide the path that continually reinfects Website A.
Shared environments should therefore be considered when malware affects more than one property or repeatedly returns.
File Permissions
Incorrect file or directory permissions can contribute to security problems.
Investigators may examine whether sensitive areas were writable more broadly than necessary.
But insecure permissions alone do not prove they were the path used by an attacker.
They should be treated as a security weakness unless evidence connects them to the compromise.
Configuration Files
Website configuration files may contain important information about databases, services and application behavior.
Attackers may modify them or potentially access secrets stored within them.
If configuration exposure is suspected, affected credentials may need to be treated as potentially compromised.
DNS and Redirect Problems
Not every apparent malware redirect comes from website files.
DNS or domain registrar compromise can redirect users elsewhere without modifying the web application.
Investigators should therefore determine whether the malicious behavior originates from the website, server, CDN, DNS, registrar or another layer.
Content Delivery Networks
A CDN can introduce another source of configuration and cached content.
If the origin website appears clean but users continue receiving malicious content, investigators may need to consider CDN configuration, edge behavior, cache state and associated accounts.
Backups Can Help Reconstruct the Compromise
Historical backups can provide valuable comparison points.
Investigators may determine:
When a malicious file first appears.
When a legitimate file changed.
Whether suspicious administrator accounts existed earlier.
Whether database content changed.
Or whether a supposedly “clean” backup was already compromised.
That last point matters.
Restoring an infected backup can reintroduce the problem.
Compare Known-Good and Compromised Versions
Where reliable earlier versions exist, investigators may compare them with the compromised environment.
This can help identify unexpected file additions and modifications.
For custom websites, source-control history can also provide a valuable reference.
But the comparison must account for legitimate deployments and updates.
Security Scanner Results Are Leads
Malware scanners can be extremely useful.
They can identify suspicious files, patterns and known malicious signatures.
But scanner output should be treated as investigative evidence rather than unquestionable truth.
False positives can occur.
And sophisticated malicious code may not match known signatures.
A clean scanner result does not necessarily prove that no compromise exists.
Determine Whether Data Was Accessed
Once unauthorized server access is established, businesses may need to know whether sensitive data was affected.
Investigators can examine available evidence involving databases, files, application activity, administrative actions and other records.
A Data Breach Investigation may become necessary if customer, employee, financial or other sensitive information could have been exposed.
Access Is Not Automatically Exfiltration
An attacker may gain the ability to access a database.
That does not automatically prove the database was downloaded.
Investigators should distinguish between potential access and evidence of actual access or transfer.
This distinction can be important for technical reporting and subsequent legal or regulatory analysis.
Determine Whether Persistence Remains
Before considering the incident resolved, the investigation should consider whether the attacker established alternative access.
Possible persistence can involve unauthorized accounts, web shells, malicious plugins, scheduled tasks, modified code, SSH keys, stolen sessions, access tokens or compromised external accounts.
The exact possibilities depend on the environment.
Can Website Malware Reveal Who Hacked the Site?
Usually not by itself.
Malicious code may contain infrastructure references, domains, IP addresses, identifiers or other useful clues.
But those indicators do not automatically reveal the real-world identity of the attacker.
Infrastructure can be rented, compromised, shared or deliberately misleading.
Attribution should be based on evidence, not assumptions.
What a Website Malware Investigation May Determine
Depending on the available evidence, an investigation may help establish:
- Which files or database records were maliciously modified
- What the malicious code was designed to do
- Approximately when the infection began
- Whether a web shell or backdoor was present
- Whether malicious administrator accounts existed
- Whether legitimate credentials may have been abused
- Whether server logs support a particular exploitation path
- Whether multiple malware components were involved
- Whether persistence mechanisms existed
- Why malware may have returned after cleanup
- Whether multiple websites were affected
- Whether the incident extends beyond the CMS
- Whether sensitive information may have been accessed
- Which conclusions are confirmed and which remain uncertain
The available evidence determines how much can be established.
What the Investigation Cannot Automatically Determine
Finding malware does not automatically reveal how it arrived.
An outdated plugin does not automatically prove that plugin was exploited.
An IP address does not automatically identify an attacker.
Database access does not automatically establish data theft.
A scanner reporting “clean” does not prove the entire infrastructure is uncompromised.
And deleting malicious files does not automatically prove the attacker can no longer return.
Those distinctions are central to a credible investigation.
How Cyb3rsect Approaches Website Malware Investigations
Cyb3rsect begins with the malware or suspicious website behavior that triggered the investigation.
The affected domain, hosting environment, CMS or application, approximate timeframe and available evidence are identified.
Where practical, relevant evidence is preserved before unnecessary deletion or restoration.
Suspicious files and code can then be examined alongside server logs, authentication activity, administrator accounts, database records, hosting information, security alerts, historical backups and other authorized evidence.
A timeline is built.
For example, a malicious PHP file might be correlated with a suspicious HTTP request, file-creation time, subsequent requests to the file, additional modifications, administrator activity and later malware deployment.
Possible access paths are tested against the evidence.
Persistence is investigated.
The scope is expanded if evidence suggests that the hosting account, server, developer credentials, database, DNS, cloud infrastructure or other websites may also be affected.
Confirmed observations are separated from likely explanations and unresolved possibilities.
The objective is not simply to report that malware existed.
It is to determine what the malware did, how it fits into the compromise, what else may have been affected and what evidence exists about the source of the incident.
Contact Cyb3rsect About a Website Malware Investigation
If malware, malicious code, unexpected redirects, web shells, injected scripts, unauthorized pages or repeated reinfection has been discovered on your website, preserve relevant evidence before permanently deleting suspicious files or restoring over the affected environment whenever doing so is practical and safe.
Cyb3rsect provides website malware investigation, website and server investigation, hacked website investigation, digital forensics, cyber investigation, data-breach investigation and digital evidence preservation support.
Useful starting information can include the affected domain, when the problem was discovered, hosting provider, CMS or application, suspicious filenames, security alerts, malware-scanner findings, screenshots, redirect destinations, server logs, administrator accounts, backups and any cleanup already performed.
Do not send passwords, private keys, access tokens or other authentication secrets through an ordinary initial inquiry.
Contact us to determine which website files, logs, database records, hosting activity, accounts, backups and other digital evidence may still be available for investigation.
Removing Malware Is Only Half the Question
A cleaned website can still leave unanswered questions.
How did the malware arrive?
When did the compromise begin?
What did the malicious code do?
Was there a web shell or backdoor?
Were legitimate credentials compromised?
Was the database affected?
Did the attacker create another way to return?
Were other websites or servers affected?
Is there evidence that sensitive information was accessed?
Why did the malware return after previous cleanup?
A professional website malware investigation is designed to answer as many of those questions as the available digital evidence allows.
