WordPress Hacked Investigation: How to Find Out How a WordPress Site Was Compromised

A hacked WordPress website can create an obvious emergency.

Visitors may be redirected to suspicious websites. Unknown administrator accounts may appear. Security scanners may detect malware. Search results may suddenly contain spam pages. Website files may change without authorization. Customers may report warnings. The site may even be disabled by the hosting provider.

The immediate instinct is usually:

Clean the website.

That is necessary, but cleanup alone may not explain the incident.

If the attacker originally entered through a compromised administrator account, vulnerable plugin, stolen hosting credential, exposed server account, malicious file or compromised developer environment, removing the visible malware may leave the underlying problem unresolved.

A WordPress hacked investigation examines the WordPress installation together with available server, hosting, authentication, database and account evidence to determine what happened, when the compromise may have begun, how access may have been obtained and whether unauthorized access remains.

The objective is not merely to make WordPress appear clean again.

It is to investigate the compromise.

How Do You Know Whether a WordPress Site Has Been Hacked?

Not every WordPress problem is evidence of a cyberattack.

A broken plugin can produce errors.

A failed update can take the site offline.

A caching problem can display unexpected content.

A legitimate administrator may accidentally change configuration.

But some symptoms deserve investigation, particularly when they occur unexpectedly.

These can include unknown administrator accounts, unauthorized file changes, unfamiliar plugins, malicious redirects, unexpected JavaScript, PHP files in unusual locations, search-engine spam, security warnings, changed homepage content, unexplained configuration changes, repeated reinfection, suspicious database entries, unfamiliar scheduled activity, or hosting alerts.

The important question is not simply whether something looks unusual.

It is whether the evidence supports unauthorized activity.

WordPress Cleanup and WordPress Investigation Are Different

Suppose a security plugin identifies five malicious files.

They are deleted.

The scanner now reports the site as clean.

That is useful.

But several important questions remain:

How were those files created?

When did they first appear?

Were they accessed by someone outside the organization?

Was an administrator account compromised?

Did the attacker create another account?

Was a plugin or theme exploited?

Was the hosting account compromised instead?

Did the attacker alter the database?

Is another backdoor still present?

Were customer or user records accessed?

A broader Website & Server Investigation may be appropriate when the incident extends beyond WordPress itself.

Preserve Evidence Before Reinstalling Everything

One of the easiest ways to lose useful evidence is to immediately replace the entire WordPress installation.

Sometimes rapid containment is necessary.

But when practical and safe, relevant evidence should be preserved before major changes are made.

That can include WordPress files, database records, web-server logs, authentication records, hosting activity, administrator-account information, security-plugin alerts, backups, suspicious files and other relevant data.

Our Digital Evidence Preservation guidance covers this principle more broadly.

Record the Initial Condition

Document what you observed before making unnecessary changes.

Useful information can include suspicious URLs, redirect destinations, security warnings, malware detections, unknown users, altered pages, filenames, timestamps, hosting notifications and the approximate time the problem was first noticed.

This gives investigators a starting point even if emergency remediation must begin.

Build a WordPress Compromise Timeline

The date the website owner notices the hack may not be the date the compromise began.

Imagine the evidence eventually shows:

June 4 — Suspicious request targets a plugin

June 4 — Unknown PHP file appears

June 5 — File receives external requests

June 5 — New WordPress administrator created

June 8 — Database content modified

June 10 — Redirect code appears

June 15 — Visitors begin reporting redirects

June 17 — Website owner discovers the problem

Without a timeline, the business might assume June 17 was the beginning.

The evidence suggests otherwise.

Examine WordPress Administrator Accounts

The WordPress user list can be one of the first places to examine.

An attacker who obtains sufficient access may create a new administrator account.

That account could remain after visible malware is removed.

Investigators may ask:

When was the account created?

Which privileges does it have?

Does the username correspond to a known administrator, agency or developer?

Is there evidence showing how it was created?

Was the account used?

What actions occurred afterward?

An unfamiliar administrator is a strong reason for investigation, but it should not automatically be labeled malicious without context.

Compromised WordPress Administrator Accounts

Attackers do not necessarily need to create new users.

They may compromise an existing administrator account.

Evidence can include unusual authentication, password changes, unfamiliar sessions, account-profile changes, security alerts and activity occurring at unexpected times.

But a WordPress username alone does not establish who physically performed an action.

Credentials can be shared, stolen or used from compromised devices.

Administrator Passwords Are Only One Part of the Investigation

Changing every WordPress password is a sensible security response after many incidents.

But it does not answer how the original compromise happened.

And WordPress may not be the only access layer.

The attacker might have access through the hosting provider, SFTP, SSH, a developer account, database credentials or another system.

That is why the investigation should map the environment rather than focus exclusively on wp-admin.

Plugin Vulnerabilities

Plugins expand WordPress functionality, but they also increase the amount of software exposed to the internet.

A vulnerable plugin may provide an attacker with a path into a website.

Investigators may examine the installed plugin version, update history, vulnerability timing, suspicious web requests, file changes and activity immediately following the suspected exploitation.

However:

A vulnerable plugin being installed does not prove that it was exploited.

This distinction is important.

If a site has ten outdated plugins and malware is discovered, simply selecting the most vulnerable-looking plugin as the cause is not forensic analysis.

The available evidence should support the proposed entry path.

Abandoned and Unsupported Plugins

Plugins that are no longer maintained can create additional risk because security problems may remain unresolved.

An investigation should identify outdated or unsupported components as potential security concerns.

But again, vulnerability and exploitation are different findings.

The report should preserve that distinction.

Theme Compromise

WordPress themes can also contain executable code.

Attackers may modify legitimate theme files or place malicious code in locations that appear related to the active theme.

Investigators may compare suspicious theme files with trusted copies or known-good versions where available.

Custom themes require additional care because legitimate code may not exist in a public repository for comparison.

WordPress Core Files

Unexpected changes to WordPress core files can be important.

Investigators may compare installed core files with the appropriate trusted WordPress version.

But not every difference is malicious.

Updates, incomplete installations, hosting modifications or manual changes may create differences.

The context still matters.

The `wp-config.php` File

wp-config.php is a particularly important file because it contains critical WordPress configuration information.

Unauthorized changes may deserve investigation.

If sensitive credentials stored in configuration files may have been exposed, the response should consider whether those credentials need to be rotated.

Simply restoring the file without understanding the broader compromise may leave other access paths intact.

WordPress Uploads Directory

The uploads directory normally contains media and other uploaded content.

Executable or unusual files appearing there may deserve closer examination depending on server configuration and website functionality.

Attackers sometimes attempt to hide malicious files in locations containing large numbers of legitimate files.

Investigators may examine when suspicious files appeared, their contents, surrounding requests and whether they were subsequently accessed.

Web Shells in WordPress

A web shell can provide an attacker with continued interaction with the server.

Finding one is significant.

But deleting it answers only one question.

Investigators should determine, where evidence allows:

How did the web shell arrive?

When did it appear?

Was it accessed?

What happened after it appeared?

Were additional files created?

Does another backdoor exist?

This is where a Website Malware Investigation becomes particularly valuable.

Malicious PHP Hidden Inside Legitimate Files

Attackers do not always create obviously suspicious filenames.

Malicious PHP may be inserted into otherwise legitimate WordPress, plugin or theme files.

That can make visual inspection difficult.

File comparison, malware analysis, source history and other forensic techniques may help identify unauthorized modifications.

Obfuscated WordPress Malware

Malicious code may be encoded or obfuscated to make manual inspection harder.

But legitimate WordPress components can also contain minified, encoded or otherwise complex code.

Obfuscation should therefore be treated as an investigative clue rather than automatic proof of maliciousness.

Database Injection

A WordPress compromise can exist partly or entirely in the database.

An attacker may alter posts, options, user information, configuration values, injected scripts or other stored content.

This explains why replacing website files does not always remove the problem.

The files may be clean while WordPress continues loading malicious content from the database.

WordPress Options and Configuration

WordPress stores extensive configuration information in its database.

Unexpected changes can affect site behavior, URLs, plugins, themes and other functions.

Investigators may compare suspicious database values with historical backups or known configurations when available.

Malicious Redirects

WordPress redirect malware can be frustrating because it may not affect every visitor.

The malicious logic might redirect only users arriving from search engines, mobile users, particular browsers, first-time visitors or visitors meeting other conditions.

An administrator can repeatedly visit the website and see nothing unusual while customers continue being redirected.

The investigation may need to examine PHP, JavaScript, database content, plugins, themes, server configuration and external scripts.

Search Engine Spam

A hacked WordPress website may begin generating unauthorized pages targeting unrelated search terms.

The website owner may never see them through normal navigation.

Search engines might nevertheless index thousands of them.

Investigators may need to determine whether the spam originates from files, database content, rewrite behavior, malicious plugins, server configuration or another mechanism.

Removing indexed spam URLs without fixing the underlying compromise will not solve the root problem.

WordPress Cron and Scheduled Activity

WordPress includes its own scheduled-event system.

Scheduled activity is normal and widely used by legitimate plugins and WordPress functions.

But suspicious scheduled behavior may become relevant when malware repeatedly returns.

Investigators may examine unusual scheduled events and determine which component created them and what they execute.

The existence of an unfamiliar scheduled task alone is not enough to establish malicious intent.

Server-Level Scheduled Tasks

The environment may also use operating-system or hosting-level scheduled jobs.

If malware keeps returning after WordPress itself has been cleaned, investigators may need to look beyond WordPress.

A server-level task could recreate malicious files.

This is another reason not to treat every WordPress compromise as purely a CMS problem.

Why WordPress Malware Keeps Coming Back

Repeated infection is one of the clearest reasons to move from basic cleanup to investigation.

Recurring compromise can result from an unresolved vulnerable component, stolen credentials, hidden backdoors, unauthorized administrator accounts, scheduled persistence, infected backups, compromised hosting accounts, another compromised website on the same environment, or access through a developer account.

Cleaning the same malware repeatedly without identifying the access path can become an endless cycle.

Hosting Account Compromise

Many WordPress websites are managed through hosting control panels.

If the hosting account itself is compromised, the attacker may have broader access than WordPress provides.

Depending on the provider, this might include website files, databases, backups, email, DNS or multiple hosted websites.

The investigation should therefore examine hosting-level evidence when the circumstances suggest broader access.

FTP, SFTP and SSH

WordPress files may be modified without anyone logging into the WordPress dashboard.

Developers and administrators may access the environment through FTP, SFTP, SSH or deployment tools.

Relevant authentication records can sometimes explain file changes that appear to have bypassed WordPress completely.

Compromised Developer Credentials

A website agency or developer may legitimately have extensive access.

If one of those accounts or devices is compromised, an attacker may use legitimate deployment mechanisms.

The WordPress site then appears hacked even though the initial compromise occurred elsewhere.

Investigators should consider this possibility when WordPress-level evidence does not explain how files changed.

Multiple WordPress Sites on One Hosting Account

A hosting account may contain several WordPress installations.

If one site is vulnerable or contains a backdoor, the attacker may potentially affect other sites depending on the hosting architecture and permissions.

If several websites become infected, the investigation should examine whether they share an underlying access path.

Cleaning only the most visible site may leave the source untouched.

File Permissions

Overly permissive file and directory settings can increase security risk.

Investigators may document inappropriate permissions.

But weak permissions alone do not establish that an attacker actually used them.

The investigation should distinguish security weaknesses from confirmed attack activity.

WordPress Database Accounts

The WordPress application normally connects to its database using configured credentials.

If those credentials are exposed, database access may become another part of the incident.

Relevant database evidence can help determine whether suspicious queries, modifications or other activity occurred where adequate logging exists.

Were Customer Records Accessed?

A compromised WordPress site may store user, customer, membership, order or other sensitive information.

The existence of malware does not automatically mean all of that information was stolen.

Investigators should distinguish between:

The attacker potentially could access information

and

evidence shows particular information was accessed or transferred.

If sensitive information may have been affected, a broader Data Breach Investigation may be appropriate.

WooCommerce and E-Commerce WordPress Sites

WooCommerce and other e-commerce environments can create additional investigative concerns.

Attackers may target checkout functionality, administrator accounts, customer information, payment-related integrations or scripts loaded during transactions.

The investigation may need to examine checkout-page modifications, plugins, external scripts, database activity, administrator changes and server evidence.

Potential payment-data exposure may also trigger contractual, legal or regulatory considerations requiring appropriate specialists.

Examine Web-Server Logs

Server logs can be crucial when determining how WordPress malware appeared.

Imagine the investigation finds:

02:14:03 — Request sent to vulnerable plugin endpoint

02:14:04 — Successful server response

02:14:07 — Unknown PHP file created

02:15:21 — External request accesses that PHP file

02:17:40 — Additional malicious files appear

That sequence provides much stronger evidence than merely observing that the vulnerable plugin was installed.

A dedicated Website Log Forensics article will cover this type of analysis in greater depth.

Compare Backups

Historical backups can help establish when compromise began.

Suppose:

Backup A from July 1 is clean.

Backup B from July 8 contains an unknown PHP file.

Backup C from July 15 contains the same file plus an unauthorized administrator account.

The compromise window can potentially be narrowed.

But a backup should not automatically be considered clean simply because it predates discovery.

The attacker may have been present much earlier.

Restoring a Backup Can Reintroduce Malware

This is a common mistake.

A website is compromised.

The business restores last week’s backup.

The website looks normal.

Three days later, the malware returns.

One possibility is that the backup itself already contained a backdoor.

Backup restoration should therefore be paired with investigation and remediation of the original access path.

Security Plugin Evidence

WordPress security plugins can provide useful alerts and logs.

They may record login attempts, file changes, blocked requests, malware detections or other events.

That information can be valuable.

But security-plugin findings should be correlated with server and application evidence where possible.

No single scanner or plugin has complete visibility into every layer of the environment.

Search Console and External Warnings

Search engines, browsers, hosting providers and security services may identify malicious behavior before the website owner notices it.

Those alerts can help establish when the issue was externally observed.

They should be preserved along with the technical evidence.

Was WordPress Actually the Entry Point?

This is one of the most important questions.

The website may run WordPress, but that does not prove WordPress was how the attacker entered.

The initial compromise might involve:

A hosting account.

A developer computer.

A reused password.

A compromised email account.

A stolen session.

SFTP credentials.

SSH access.

DNS or registrar access.

Another website on the same environment.

Or another connected service.

The investigation should follow the evidence instead of blaming the CMS by default.

Can You Determine Which Plugin Was Exploited?

Sometimes the evidence can strongly support exploitation of a particular plugin or component.

For example, server requests may align with a known vulnerability and be immediately followed by malicious file creation.

In other cases, the evidence may only establish that vulnerable software existed.

If logs have expired, identifying the exact initial access method may no longer be possible.

The report should say so.

Can You Identify Who Hacked the WordPress Site?

WordPress and server evidence may reveal IP addresses, domains, accounts, files, request patterns and infrastructure associated with the attack.

That information can be valuable for understanding and correlating the incident.

It does not automatically identify the real-world attacker.

Attackers may use VPNs, proxies, cloud servers, compromised systems or other intermediaries.

Attribution should remain evidence-based.

What a WordPress Hacked Investigation May Determine

Depending on the available evidence, investigators may be able to determine which WordPress files were modified, whether malicious PHP or JavaScript was present, whether the database was altered, whether unauthorized administrator accounts existed, whether plugins or themes may have been involved, whether a web shell or backdoor existed, whether server logs support a particular attack path, whether hosting credentials were abused, whether persistence mechanisms remained, whether multiple websites were affected, and approximately when suspicious activity began.

The investigation may also determine that some questions cannot be answered because relevant logs or historical evidence no longer exist.

That is still an important finding.

What a WordPress Investigation Cannot Automatically Prove

An outdated plugin does not automatically prove exploitation.

A suspicious IP address does not automatically identify the attacker.

An unknown file does not automatically establish its origin.

A WordPress administrator username does not automatically identify the person who used it.

Malware does not automatically establish that customer data was stolen.

And a successful cleanup does not automatically prove that the original access path has been eliminated.

Professional reporting should preserve these distinctions.

How Cyb3rsect Approaches WordPress Hacked Investigations

Cyb3rsect begins with the symptoms that caused the business to suspect compromise.

The WordPress installation, hosting environment, approximate timeframe, administrator accounts, affected functionality and available evidence are identified.

Where practical, relevant evidence is preserved before unnecessary deletion, restoration or rebuilding removes it.

The investigation can then examine authorized evidence from WordPress files, plugins, themes, administrator accounts, databases, server logs, hosting systems, authentication records, security alerts, backups and related infrastructure.

A timeline is constructed.

For example, a suspicious request against a plugin may be correlated with file creation, later access to that file, administrator-account changes, database modifications and additional malware.

Possible entry paths are tested against the evidence.

Persistence is investigated.

The scope is expanded if evidence indicates that the hosting account, server, developer credentials, database, DNS or another website may also be compromised.

Observed facts are separated from likely explanations.

Evidence gaps are documented.

The objective is not simply to declare:

“WordPress was hacked.”

It is to determine what the available evidence can establish about how the compromise occurred, what the attacker did, what was affected and whether unauthorized access may still exist.

Contact Cyb3rsect About a Hacked WordPress Website

If your WordPress website has malware, unknown administrator accounts, malicious redirects, spam pages, suspicious PHP or JavaScript, unexplained file changes or repeated reinfection, preserve relevant evidence before wiping the site or overwriting the affected environment whenever it is practical and safe to do so.

Cyb3rsect provides WordPress hacked investigation, website malware investigation, website and server investigation, cyber investigation, digital forensics and digital evidence preservation support.

Useful starting information can include the affected domain, hosting provider, approximate discovery date, WordPress version, security alerts, suspicious files, unknown administrator accounts, plugin or theme concerns, server logs, redirect destinations, backups and details of any cleanup already performed.

Do not send passwords, hosting credentials, API keys or other authentication secrets through an ordinary initial inquiry.

Contact Cyb3rsect to determine which WordPress files, database records, server logs, hosting records, accounts, backups and other digital evidence may still be available for investigation.

Fix the Website — But Investigate Why It Happened

A WordPress website that looks clean again can still have unanswered questions.

When did the compromise begin?

Was a plugin actually exploited?