How webshells, backdoors, SEO spam, and persistence differ
A webshell is executable code used to run commands or file operations. A backdoor is a concealed route back into the environment. SEO spam creates unauthorized pages, links, or redirects. Persistence is the broader principle: a mechanism makes access or malicious code return after superficial cleanup.
A filename or scanner signature proves neither the original entry point nor the full scope of the incident.
Where persistence can live
- modified core, plugin, or theme files
- executables in uploads, cache, or backup directories
- tampered options and autoloaded database values
- unknown administrators, sessions, and application passwords
- WordPress cron and server-side schedulers
- altered web-server or PHP configuration
Verification after cleanup
Core files can be checked against published checksums. Plugins and themes should be replaced from a verifiable vendor source. Custom code requires a known baseline. Verification combines integrity checks, functional testing, and a fresh search for the documented indicators.
Preserve before removal
Record the location, timestamp, hash, and related log evidence before deleting a finding. Then inspect accounts, database records, and schedulers for additional persistence.
How do a webshell, backdoor, and dropper differ?
These terms describe capabilities rather than guaranteed one-file categories. A webshell commonly accepts commands through a web request. A backdoor may instead be an altered administrator, hidden API credential, or change to authentication logic. A dropper writes or retrieves another payload.
One artefact can perform several roles. Code inside a plausible plugin may execute commands for a particular parameter, create more files, and generate an external redirect. Assessment therefore asks what the code could read, write, execute, and contact—not merely what a scanner named it.
| Term | Main technical question | Common limitation |
|---|---|---|
| Webshell | Could an external request trigger commands or file operations? | A signature does not show whether or when it was used. |
| Backdoor | Which concealed route could restore access? | The route may exist outside WordPress. |
| Dropper | Which additional code could be written or fetched? | A remote payload may no longer be available locally. |
| SEO spam | How were pages, links, or redirects produced? | Visible spam is not necessarily the entry path. |
How can SEO spam be delivered?
SEO spam may live in files, database records, redirect rules, or content fetched dynamically from another server. It is sometimes shown only to certain user agents, referrers, countries, or logged-out visitors. An administrator can see a normal homepage while crawlers receive unauthorized landing pages.
Do not rely on a single browser visit. Compare responses across paths and request contexts, inspect the returned HTML, and review Search Console warnings, sitemaps, database content, server rules, and cache layers. Removed URLs may remain in a search index for some time; that alone does not prove that malware is still active.
Which persistence layers need review?
A structured search follows the environment’s trust boundaries:
- Identities: WordPress, hosting, SFTP, SSH, database, CDN, and DNS access.
- Application code: core, plugins, themes, must-use plugins, drop-ins, and custom includes.
- Stored data: options, autoloaded values, posts, widgets, templates, user metadata, and scheduled actions.
- File system: uploads, caches, temporary folders, backups, and parent directories.
- Execution: WordPress cron, system cron, queue workers, PHP settings, and web-server rules.
- Infrastructure: neighbouring sites, deployment pipelines, DNS, CDN, and shared secrets.
The boundary does not stop at wp-content. Another compromised application in the same hosting account can reintroduce code. Equally, an unusual cache timestamp must not be labelled malware without analysing the content and execution path.
How can the entry path be narrowed down?
A defensible entry-path hypothesis connects independent evidence: an early suspicious request, the component version present at the time, successful authentication, a newly written file, subsequent commands, and the visible effect. The more independent records support the same sequence, the stronger the conclusion.
If logs are missing or files were replaced before preservation, the result may only be “plausible, not confirmed”. A publicly known vulnerability in an installed plugin does not by itself prove that the vulnerability was exploited on this site.
“Probable entry path” and “confirmed entry path” are different finding classes. A useful report states the supporting evidence, competing explanations, and remaining gaps.
Why is a malware scanner not enough?
Scanners are valuable for known signatures, suspicious patterns, and integrity differences. They do not automatically understand legitimate custom code or the full hosting environment. Whether a finding was executable, when it existed, and whether persistence sits outside the scan scope requires context.
The WP Notdienst methodology therefore combines automated indicators with manual review, trusted baselines, and documented verification. The focused guide to malware scanning versus forensic investigation explains their different objectives.
How do you detect recurrence after cleanup?
Define observable checks before closing the incident: hashes of restored components, known malicious URLs, unauthorized identities, suspicious cron hooks, and external destinations. Monitor file changes, new privileged users, WAF events, and unexpected outbound connections after recovery.
Recurrence is not automatically “the same malware”. It may indicate missed persistence, a still-compromised credential, an unpatched weakness, or another infected application in the hosting account. The response should preserve the new evidence and reassess the cause instead of deleting the symptom again.
For an active incident, start with the first-60-minute playbook. The cleanup service describes replacement from controlled sources and explicit reporting of anything that could not be verified.