Build a post-incident hardening checklist after a brute-force attack

Server logs for the last 6 hours show this:

[- 14,213 failed login attempts against /wp-login.php from a rotating pool of
roughly 200 IPs, concentrated on the usernames "admin" and "editor"
- One successful login on the "editor" account at 03:14 UTC, password matches a
hash that appears in a public breach dump
- "editor" holds the Editor role, not Administrator
- No new plugins, themes, or files created since the successful login
- Uptime monitoring shows no downtime and no defacement]

Work through this the way an incident responder would:
1. Scope the compromise from the one successful login. Editor role can't install
   plugins, but it can edit any post, inject scripts into post content, and see
   other users' drafts. Given that, what exactly needs checking: post revision
   history since 03:14, any new pages or redirects, whether editor's application
   passwords or connected integrations were touched, and whether any admin
   account shows signs of privilege escalation attempts right after.
2. Immediate containment before investigation goes further: force-terminate the
   editor account's active sessions, reset its password, and check whether the
   same password is reused on any admin-level account on this site or others the
   same person manages.
3. Once contained, turn this into a hardening checklist that targets the actual
   attack pattern shown in the logs, not a generic list: username enumeration
   (admin/editor as targets), credential stuffing (breach-dump password reuse),
   and login endpoint exposure. Cover rate limiting or login lockouts, renaming
   obvious usernames, mandatory 2FA for any role above Subscriber, and blocking
   or challenging the IP ranges seen in the log.
4. State the one condition that would make you escalate this to a full forensic
   review instead of closing it out with the checklist, for example any sign the
   editor account touched files, users, or settings outside what its role
   permits.