“The malware has not returned yet” is not proof. A backdoor may wait for cron, a specific visitor, an administrator login or an external controller. Verification must test the route identified during investigation and observe the site beyond its previous recurrence interval.
Define the evidence before declaring the cleanup complete.
State the suspected route precisely
Write a short cause statement: vulnerable upload endpoint created a PHP loader; stolen SFTP account modified three sites; malicious cron restored an injected option.
Separate confirmed facts from inference and unavailable logs. If the route remains unknown, say so and apply broader monitoring rather than claiming closure.
Record affected time window, components and accounts.
Verify the entry control
Confirm the vulnerable component is patched, removed or access-restricted using vendor-supported checks. Do not replay destructive public exploits.
For stolen credentials, prove sessions/tokens were revoked and the credential source/device addressed. For account isolation, test that one site user cannot write another site’s paths through authorised filesystem checks.
Keep before-and-after configuration evidence with secrets redacted.
Remove established persistence
Verify trusted core/plugins/themes against clean sources. Review custom code, uploads, database injections, administrators, application passwords, WordPress/server cron and hosting/DNS/CDN layers.
Search for known hashes, paths, domains and code strings from the incident. Absence of one indicator does not cover variants, so combine it with provenance and behaviour checks.
Document quarantined/deleted items and replacement sources.
Recreate normal trigger cycles
Run normal WordPress cron, Action Scheduler, backups, cache regeneration, deployments and authorised plugin updates. Save settings that previously caused file regeneration in staging first.
Repeat original visitor conditions—mobile, search referrer, first visit, affected path—inside a safe browser profile.
Do not contact attacker infrastructure or execute old payloads to prove the route is closed.
Monitor meaningful changes
Create a post-cleanup hash baseline for trusted code and alerts for executable files in uploads, unknown administrators, new cron and sensitive configuration changes.
Exclude expected cache/media churn. Alerts that fire on every thumbnail will be ignored.
Retain web, authentication and file-change logs long enough to cover the previous recurrence plus scheduled cycles.
Seek evidence outside the compromised server
Use independent records that the attacker could not easily rewrite: CDN requests, hosting authentication history, external uptime checks, email-provider logs and repository/deployment history.
Compare them with the cleaned server timeline. If local logs disappeared during compromise, external evidence can still show the last redirect, unknown panel login or deployment that introduced a changed file. Record retention gaps explicitly; absence of local events is not proof that no access occurred.
Verify account and environment boundaries
Check every installation under the compromised hosting user. Confirm retired staging/old sites are inaccessible and deployment artefacts are clean.
Review panel/SFTP/SSH users, email accounts used for resets, API keys, DNS and CDN accounts. Ensure individual least-privilege access and multi-factor authentication where supported.
A clean WordPress directory cannot compensate for an active panel session.
Test business functionality
Submit forms, verify email, exercise login/password reset and complete authorised WooCommerce sandbox checkout. Confirm security changes did not break payments, webhooks or scheduled orders.
Inspect public HTML/outbound requests for previous malicious domains and verify accurate 404/410 responses for removed spam URLs.
Set an observation and response plan
Choose monitoring duration from evidence: previous return interval, cron schedule, traffic trigger and credential risk. Define who receives an alert and what containment step is pre-approved.
Provide the owner with findings, limitations, credential actions and a dated verification record.
When independent verification helps
Request a second review when the entry route is uncertain, checkout was affected or several sites shared access. Initial assessment can use the incident timeline and sanitised indicators.
Confidence comes from route-specific tests and stable evidence, not a single green scanner result.