Incident reports often turn the first visible symptom into the presumed cause: "the plugin was outdated" or "the password was weak." A useful conclusion links the earliest trustworthy events to a capability and states what the available evidence cannot prove.
Build a timeline, test competing explanations and assign confidence.
Separate facts from interpretations
Facts include installed version, request path/status, successful login, user creation time, file hash/change and provider alert. Interpretations connect those facts into a possible entry route.
Label each statement clearly. Do not describe a scanner detection date as the compromise time unless logs support it.
Use one timezone and preserve source references.
Define the earliest known activity
Work backward from redirects, spam or unknown administrators to the first file, account, request or configuration change. Compare with last known good backup and log retention.
Later attacker actions may use normal login or uploaded tools and hide the original route. Avoid treating the loudest payload as the entry point.
Record the boundary of available evidence.
Build candidate hypotheses
Examples include anonymous plugin exploitation, stolen WordPress session, compromised hosting/SFTP, exposed database tool, primary-email takeover or unsafe staging deployment.
For each, list the evidence expected if it occurred and the evidence actually present. Include legitimate alternatives such as authorised deployment or failed migration.
Do not reproduce exploitation against production to increase confidence.
Validate component applicability
For plugin/theme hypotheses, record exact version, source, active/inactive status, configuration, vulnerability prerequisites and disclosure timeline.
An advisory affecting another version or requiring administrator access cannot alone explain anonymous code execution. A vulnerable version proves exposure, not exploitation.
Link to the vendor/trusted advisory in the internal report.
Correlate account evidence
Review WordPress/hosting/email/DNS users, sessions, reset events, keys and application passwords. Compare successful access with malicious change times.
IP or country is supporting context, not identity proof. VPNs, shared networks and stolen sessions complicate attribution.
Preserve unknown account identifiers before revocation.
Correlate technical evidence
Match web requests, file/database changes, cron creation, mail activity and outbound domains. Use hashes/IDs and timestamps rather than sharing payloads or customer data.
File modification times can be altered; database timestamps may use different timezone. Prefer multiple independent sources.
State when logging gaps prevent correlation.
Test the timeline for contradictions
Ask whether each proposed cause existed before the first activity and could produce the observed permissions. Check timezone, clock drift, restored-file timestamps and log rotation.
If a plugin was installed after the first malicious user, it cannot be the original vector. If hosting access predates all WordPress events, application logs alone may describe only later actions.
Record contradictions explicitly; they often expose a false narrative.
Assign confidence and alternatives
Use clear language such as confirmed, highly likely, plausible or undetermined, with a short justification. List the strongest alternative explanation and what evidence would distinguish it.
Do not turn confidence labels into percentages without a defined method. Avoid naming an individual attacker when the evidence identifies only an account.
Update the conclusion when new provider logs arrive.
Preserve report reproducibility
Reference log filenames, query criteria, hashes, advisory versions and snapshot IDs so another authorised responder can verify the conclusion. Store raw evidence separately under restricted access.
Do not paste payloads or personal data into the narrative. Redacted examples should retain timestamps and correlation IDs.
Set a review date if provider logs or device findings are still pending.
Connect conclusions to controls
The report should state what was patched/removed, credentials rotated, persistence checked, sites/environment affected and monitoring added. Close every plausible high-impact route, not only the preferred hypothesis.
Retain snapshots/logs according to the incident process and minimise personal data.
Request specialist incident review when cause affects legal scope or repeated reinfection. Share redacted timelines, versions and source references—never exploits, credentials, private keys or customer databases.