Recent modification time is useful during a WordPress incident, but normal updates, cache generation, image uploads, translations and backups also change files. A list sorted by date is a timeline lead, not a malware verdict.
Preserve metadata before updates or bulk copies reset it, then correlate each cluster with legitimate activity.
Work from a snapshot when possible
Create a filesystem snapshot or copy that preserves paths and timestamps. Keep the original unchanged and perform searches on a duplicate outside the web root.
Record server timezone and collection time. File modification time reflects content change, while metadata change time can reflect permissions or ownership; neither necessarily equals initial creation.
Do not run repair tools before capture if visitor safety permits containment first.
List a bounded time window
On an authorised Linux host, find files modified during a defined period:
find /path/to/wordpress -type f
-newermt '2026-07-20 00:00:00'
! -newermt '2026-07-21 00:00:00'
-printf '%TY-%Tm-%Td %TH:%TM:%TS %s %pn'Adjust dates and path explicitly. Do not use a broad root path or follow untrusted symlinks. Tool support differs on managed hosting.
Save results as evidence rather than changing the listed files.
Group by expected owner
Separate WordPress core, plugin, theme, uploads, cache, language, backup and unknown root files.
A plugin update can modify hundreds of files within one minute. Media processing creates several thumbnails near an upload. Cache directories change continually by design.
An isolated PHP file inside uploads or a core file modified hours after the update cluster deserves closer inspection.
Correlate with change records and logs
Compare file times with WordPress auto-updates, deployments, administrator actions, SFTP/panel logins, cron, backup and security logs.
Account for copied files preserving their old modification time or archives assigning extraction time to everything. Hosting restores can make a whole site look newly modified.
No matching log does not prove malware; retention may be incomplete.
Check clock drift between the web server, database, CDN and control panel. Convert evidence to one timeline without rewriting the original records. A ten-minute offset can make a malicious POST appear unrelated to the file it created.
Compare content with trusted sources
Verify WordPress core checksums and compare plugin/theme directories with the exact official or vendor package. Review custom code against the deployment repository.
Hash comparisons are stronger than timestamps. A recent file identical to the verified package is explainable; an old file with a malicious hash can still be infected.
Do not replace custom themes because they differ from a parent package.
Prioritise high-risk anomalies
Review unexpected executable files in uploads, root PHP with random names, modifications to wp-config.php/.htaccess, unknown must-use plugins and code containing unfamiliar external domains.
Inspect statically in quarantine. Avoid executing, browsing or publicly decoding suspicious files.
Search the database and scheduled tasks for related strings; filesystem time alone cannot reveal database persistence.
Build a repeatable baseline
After verified cleanup, create a hash manifest for trusted code and document expected writable directories. Monitor meaningful changes rather than alerting on every cache file.
Update the baseline only after an approved deployment and validation. Otherwise a compromised file can become the new “known good.”
Retain historical manifests securely and exclude secrets from reports.
Review baseline ownership annually.
When deeper analysis is needed
Request an assessment when timestamps form unexplained clusters, trusted packages differ or several sites share write access. Send the timeline and redacted paths, not suspicious executables.
A professional review combines time, provenance, content, logs and behaviour so legitimate maintenance remains intact while malicious changes are removed.