A children's museum's WordPress site was hardened after a drive-by defacement attempt

Representative examplesEvery case study in this library is an illustrative composite of the kind of engagement we deliver — written to show our method and standards, not to name clients.

Where they started

Hands-on exhibits and school-group programs fill this children's museum, and the website is the front door for field-trip bookings — teachers check availability and submit inquiry forms daily. It's a nonprofit with a small staff and an events coordinator, and a long history of volunteer help on the website: over the years, well-meaning people installed plugins, created accounts, and moved on. There's no IT department; the closest thing is a go-to contractor called when something breaks. Several past volunteers still hold scattered credentials nobody has inventoried.

What it was costing

An attempted defacement during a school-group booking week exposed how exposed the site was: an abandoned admin account, plugins installed by a long-gone volunteer, no malware scan, and the museum's field-trip form quietly stopped delivering email.

What they could see

• A defacement attempt replaced the homepage banner during a school-group booking week; staff heard about it from a teacher.
• The field-trip inquiry form had stopped delivering email months earlier; bookings arrived only when teachers phoned to follow up.
• An admin account belonging to a volunteer who left years ago was still active with full permissions.
• Plugins installed by long-gone volunteers had no owner, no update history, and in some cases no known purpose.
• Nobody could say what the site ran or who could access it — the credential list lived in people's heads.

The constraints we worked inside

• The site must stay up during the investigation and hardening — school groups book through it daily.
• The museum cannot afford enterprise tooling; the hardening must be durable with free-tier tooling and careful configuration.
• Several past volunteers hold scattered credentials; access must be reset and centralized without blame.

What had been tried before

The museum's regular IT contractor ran a malware scan after the defacement attempt and reported the site clean.

Signature scans check for known malware only; the abandoned admin account, ownerless plugins, and dead mail path weren't malware, so every one of them survived the all-clear.

A past volunteer had rigged the field-trip form to also send an SMS alert as a stopgap.

The stopgap ran on the volunteer's personal account, which lapsed quietly — it failed the same silent way the form had, and nothing distinguished working from broken.

After the scare, passwords were collected into a shared spreadsheet for the staff.

The list recorded credentials without owners or purposes; stale logins looked as alive as current ones, and the abandoned account stayed enabled on a page nobody re-checked.

What we proposed

We proposed an audit-first hardening: users, plugins, file integrity, and logs reviewed before anything changed, then credential resets, abandoned-account removal, least-privilege roles, and file-integrity monitoring — closing doors before decorating the house. The field-trip form's silent mail failure gets its own fix: a transactional email service with delivery logs, so a lost booking email becomes an alert rather than a parent's follow-up call. The museum can't afford enterprise tooling, so every control was chosen to be durable on free-tier tooling and careful configuration, operable by staff rather than specialists.

Just as important is what we ruled out, and why:

• An enterprise security platform with managed monitoring — The budget line doesn't exist; the same doors close durably with free-tier tooling and careful configuration, which is also easier for small nonprofit staff to understand.
• Taking the site offline during the investigation — School groups book through it daily; an outage during booking week would convert a security fix into a program problem the museum couldn't absorb.
• An external incident-response engagement — This was an attempt, not a confirmed breach; an audit-first triage fit the risk, and the museum needed to own the knowledge afterward, not a report.

How the work ran

Delivered by the systems pod — engineer over 4 weeks, with working increments reviewed with the client every week.

The stack, and the reasoning

WordPress

School groups book through the site daily; a rebuild or platform swap mid-booking-week multiplies risk, so hardening the existing install was the only live-safe path.

2FA + role hardening

Least-privilege roles mean next year's well-meaning volunteer can't leave an admin account behind, and two-factor on the remaining logins closes the door this one opened.

File-integrity monitoring

A tampered core file is what would poison the field-trip form teachers rely on; integrity alerts catch the change before the next school-group inquiry travels through a page nobody vetted.

Transactional email

The field-trip form's mail path moves to a service with delivery logs — a lost booking email becomes an alert instead of a parent's follow-up call.

Off-site backups

The practiced restore exists for booking week: a defacement or broken plugin rolls the site back to this morning while the field-trip form keeps taking school-group inquiries — what it protects is teachers' trust in the form, not just the files.

What went wrong

How we worked together

Cadence

A short Monday call with the events coordinator during booking hours, a mid-week written log of audit findings, and director check-ins at week one and week four.

Client side

The events coordinator owned the field-trip form's requirements and testing; the director decided credential policy and communicated the access reset to past volunteers.

Decisions

Audit findings were triaged weekly — fix now, schedule, or accept — with the coordinator; the director broke the two ties, both about volunteer access.

They provided

Hosting and registrar access, the list of past volunteers for the credential reset, and one teacher's account of the booking journey for testing.

What changed

The headline: audit items closed, form delivery verified by logs, monitoring live — Exposed → hardened and monitored, read from Hardening checklist sign-off. A second check: field-trip inquiries lost to silent mail failure since the rebuild at 0.

Booking week passed without a single missed inquiry, and the events coordinator stopped keeping a private paper list of form submissions as insurance. Staff send teachers to the site directly now, without checking it first themselves. The credential conversation with past volunteers happened without blame, and the board received a plain-language summary of what changed — the first honest picture it has ever had of the website it owns.

The result was read from Hardening checklist sign-off against the pre-engagement baseline over the stated window, with a guardrail check on field-trip inquiries lost to silent mail failure since the rebuild. Where platform-reported numbers and business outcomes differ, this record says which layer it is quoting.

What they own now

• A hardening checklist with sign-off, showing what was closed and how it's verified.
• The transactional email account with delivery logs, owned by the museum, tested weekly.
• Two-factor enrollment for active accounts and a documented least-privilege role map.
• File-integrity alerts routed to a shared inbox, with a first-response note attached.
• A credential register naming owners and purposes, replacing the spreadsheet that wasn't.