WordPress Incident Response: 90-Min Case
A direct-to-consumer brand discovered an attacker exfiltrating order data through a compromised admin account. We contained the incident in 90 minutes from notification and walked away with a hardening brief the client actually adopted.
WordPress Incident Response: A Six-Hour Window and What We Did With It
WordPress incident response in India now operates under the DPDP-notification clock — this is what 90-minute containment looks like in practice.
An admin login from a country the brand didn't sell into. A six-hour exposure window. And a customer-data conversation we hoped not to have.
The call came in at 11:42 PM on a Friday. The client's e-commerce ops lead had just noticed an admin login from an IP geolocating to a country they did not sell into, and orders were exporting to CSV at an unusual rate. They had ~₹2 cr monthly GMV, no MFA on admin accounts, and a small in-house team. We had the call on speakerphone within four minutes.
The WordPress Incident Response Challenge
Three things were true at the same time, and that was the hard part:
- The compromise was active — we did not know what else the attacker had access to.
- Aggressive lockdown could break the live storefront on a Saturday morning, costing the client real revenue.
- India's DPDP framework requires reasonable, timely action and notification — the clock had effectively started.
Our WordPress Incident Response Approach
We worked the incident in three concurrent tracks: contain, preserve, communicate.
- Contain (first 90 minutes): rotate admin passwords for every account, enable MFA via authenticator app for every remaining admin, kick all active sessions, push an .htaccess rule blocking the attacker's known IPs, force-flush LiteSpeed cache.
- Preserve (in parallel): snapshot the entire production VM, capture access and error logs from the last 14 days, copy the WooCommerce orders/customers tables into a read-only forensic DB.
- Communicate: hourly written updates to the client; a draft customer notification on standby in case payment data turned out to be in scope.
What We Built After the WordPress Incident Response
Once contained, the three-week hardening phase produced:
- Phishing-resistant MFA on every admin account (FIDO2 hardware keys for the founder and ops lead, authenticator app for the rest).
- Admin URL renamed;
wp-login.phpbrute-force surface removed from public discovery. - Wordfence Premium configured for live attack rules; Cloudflare Pro WAF on the perimeter.
- Content Security Policy in report-only mode for two weeks, then enforce; XSS injected via the compromised admin user would not have run under the new CSP.
- MDR/SOC subscription — 24/7 monitoring on the WP and Cloudflare logs.
- Backup verification: their UpdraftPlus backups had been writing into webroot. Moved to private storage; tested restore.
Outcomes
- Containment in 90 minutes from the client's first notification.
- Full attack timeline reconstructed over 4 days: initial access via re-used admin password (founder's leaked credential from an unrelated 2024 SaaS breach), 6-hour active window, two CSV exports of customer order data.
- No payment data exposed — payments were tokenised through a third-party gateway, attacker had no access to PAN data.
- DPDP notification filed within the prescribed window; affected customers (~12,000) received an email notification with our drafted language.
- Zero recurrences in the 14 months since.
What We'd Do Differently
This one is uncomfortable to write but it matters. We had quoted this client an MFA + hardening engagement five months before the incident. They declined because of perceived friction at admin login. The post-incident hardening engagement cost roughly 3.5x the proactive one, plus the legal and customer-comms work, plus the unquantifiable trust damage. We have changed how we propose proactive engagements: we now lead with a written estimate of "expected remediation cost in the breach scenario" alongside the proactive quote. It is not a sales tactic; it is the actual decision the client is making.
Operationally, we should have insisted earlier on enrolling the client in a basic MDR service. The 6-hour exposure window existed because the client's logging produced no alerts; an MDR with even basic WP-admin login alerting would have surfaced the foreign-IP login within minutes.
Stack & Tools
- Wordfence Premium, Cloudflare Pro (WAF + Bot Fight Mode)
- Microsoft Defender for Business (endpoint MDR)
- UpdraftPlus moved to private S3-compatible target
- FIDO2 hardware keys (YubiKey 5C for two roles)
- Custom forensic timeline scripts on the snapshot VM
FAQ
How did the attacker get the admin credential?
Credential reuse. The founder had used the same password on a SaaS service that suffered a breach in mid-2024. The credential leaked into combolists; an opportunistic attacker tried it against the WP admin URL and it worked. No phishing was involved.
Why did MFA not exist before?
Friction at login was the stated reason. In retrospect — and we said this clearly to the client — that decision saved roughly 5 seconds per admin login and cost a six-figure incident response. We do not judge the original decision; we present the actual trade-off in writing now.
Was DPDP notification mandatory here?
Yes — the exfiltrated CSV contained personal data (names, addresses, phone numbers, order histories). DPDP requires notification to the Data Protection Board within the prescribed window and notification to affected data principals. We worked with the client's legal counsel on the notification text.
How do you decide when an incident requires customer notification?
If personal data was provably accessed or exfiltrated, we recommend notification by default. The legal trigger is set by DPDP / sector-specific regulators (RBI, IRDAI, etc.) but our operational stance is "be conservative, communicate clearly." Customers find out anyway; how they find out matters.
Why WordPress Incident Response Has Specific Indian Implications
WordPress incident response in India operates inside the DPDP-notification clock; that compresses what is already a chaotic 90-minute window. WordPress incident response done right preserves forensic evidence, contains lateral movement, communicates with regulators on time, and produces a hardening backlog the team will actually execute. The proactive version of WordPress incident response — MFA, Wordfence, immutable backups, MDR — costs roughly a third of the reactive version. We can quote both for any client; usually both quotes change minds.
Further reading: VITI Security cybersecurity services · WordPress.org official Hardening guide.