Incident response for an Exponential site #

This page is for administrators, security officers and project managers of public bodies. It adapts the project's hosting runbook (Runbook: compromised site) to a public body's site. Signs of an incident: defaced pages, unknown administrator accounts, files that should not exist, spam sent from the site, an audit alert such as admin_role_granted or chain_broken.

Note This page describes features and common practice; it is not legal advice. Check the law that applies to your organization with your legal counsel.

Contents #

1. Contain
2. Preserve evidence
3. Investigate
4. Rebuild and recover
5. Notify
6. Prevent a repeat
7. Related pages

Contain #

1. Take the public site offline with maintenance mode, letting only your addresses in: php bin/php/maintenance.php on --message="Maintenance" --allow-ip=<your address> --allow-root-user (Maintenance mode). For a public body, publish essential information through another channel meanwhile.
2. Restrict the administration at the network level if an administrator account or session may be in the attacker's hands.
3. If the machine itself may be compromised, isolate it and work from a copy.
4. Do not delete anything yet.

Preserve evidence #

• Copy the files and a database dump to a place the site's user cannot write.
• Copy the logs: var/log/ (error.log, security.log, auth.log, the audit directory), Velocity's logs, the web server's and PHP-FPM's logs.
• Export the relevant audit records in a signed bundle: ./console exp:audit export --from=<time> --format=bundle --out=<file> --allow-root-user.
• Note the time of every action you take.

Investigate #

Rebuild and recover #

1. Code from a known-good source: the release tag and composer install from your lock file, your extensions from their repositories.
2. Data from the newest clean backup, or review the current database for unknown accounts, roles and content.
3. Update to the newest 6.0.x if the hole may be a known one.
4. Change credentials: administrator passwords, database password, API keys and tokens; rotate the audit signing key if it may have been read (./console exp:audit key rotate --apply --allow-root-user).
5. End sessions: password changes sign out other sessions; remove all sessions under Setup > Sessions with the database session handler.
6. Clear all caches (php bin/php/ezcache.php --clear-all --allow-root-user; restart Velocity and clear its response cache), verify, then switch maintenance mode off.

Notify #

• Internally, as your incident procedure says (security officer, data protection officer, management).
• To authorities and affected people where the law requires it, within its deadlines (for example under the GDPR for personal data breaches, or national cybersecurity rules).
• To the Exponential project, privately, if a vulnerability in Exponential or an extension was the cause (see "Vulnerability disclosure").

Prevent a repeat #

• Review the go-live checklist and the hardening layers; make the code read-only for the site's user.
• Forward the audit trail off the machine; check that request-shield is enforcing (Setup > Request shield) and add a rule for what the attacker used.
• Hold a lessons-learned meeting and update this procedure.

Related pages #

• Runbook: compromised site
• Audit integrity and verification
• Backups and recovery
• Free documentation: this page is free to copy, translate and improve under the GNU FDL 1.3.