Intervention Procedure: Audit, Cleanup and Maintenance for a Compromised PrestaShop Site

Goal and scope

This article precisely describes the course of a Securantis intervention on a compromised PrestaShop store: diagnosis, targeted backups, investigation of the entry point, controlled cleanup (files, modules, theme, overrides), verification of employees and orders, hardening and final report. The intervention aims to restore a safe and documented state; any destructive action (permanent deletion, restore from backup) requires an explicit human decision.

Prerequisites before the intervention

1. Back office PrestaShop access (administrator profile) and contact details of the decision‑maker.
2. FTP/SFTP access or access to the hosting file manager (or panel access such as Plesk/cPanel if necessary).
3. Existing backups: indicate if a recent backup is available (database and files).
4. For paid interventions, validation and secure transmission of credentials via the client area after payment (we never request passwords by email or chat).
5. Temporary blocking of the production site may be required depending on risk (maintenance mode or access restriction); plan a downtime window if necessary.

Detailed steps of the intervention (typical order)

1. Initial diagnosis and targeted backup

• Initial state: collection of information (PrestaShop version, PHP version, active modules, SSL status, recent known changes).
• Targeted backup: export of the database (or partial copy if the DB is large) and copy of sensitive directories (modules, theme, overrides). The objective is to preserve orders, customers and catalog before any modification.

2. Analysis of symptoms and identification of compromised areas

• Frontend checks: search for redirects, injected scripts in pages, product pages or spam content.
• Module inspection: detection of unknown extensions, files added inside known modules, obsolete or vulnerable modules.
• Theme and JavaScript: analysis of templates and externally integrated scripts in the frontend.
• Overrides: examination of class and controller overrides that may alter store behavior.
• Employee accounts: review of back‑office accounts (administrator users, login history, recent IPs).
• Payment & webhooks: verification of sensitive payment modules and webhook or notification settings.

3. Investigation of the entry point

• Prioritization: the most likely vector (vulnerable module, compromised theme, fraudulent employee, compromised FTP or panel access, unofficial extension).
• Evidence: collection of indicators (recently added files, traces of modified orders, timestamps, access logs). These elements are documented in the report.

4. Controlled cleanup

• Quarantine: isolation of suspicious files and placement into quarantine. Securantis does not delete automatically: every quarantined item is listed for decision.
• Removable but restorable cleanup: removal of identified backdoors and malicious scripts, replacement or repair of corrupted files where possible.
• Modules and theme: temporary deactivation of compromised modules; proposal to update or replace with a clean, compatible version.
• Overrides: restoration or neutralization of dangerous overrides, prioritizing preservation of the catalog and orders.

5. Business checks (orders & payments)

• Order integrity: inspection for suspicious modifications (addresses, amounts, statuses).
• Payments: review of payment integration logs and webhooks to ensure no redirectors or data leaks were installed.
• Customer notifications: review of automated email sends if fraudulent campaigns were detected.

6. Hardening and preventive measures

• Updates: apply compatible PrestaShop updates and secure module updates.
• Access: rotation of administrator, FTP and database passwords and, if necessary, API keys (credentials transmitted via the secure client area after commercial validation).
• Protection: recommendation to enable available Securantis protections (firewall WAF, 2FA on administrator accounts, reCAPTCHA for sensitive forms, manual quarantine).
• Cron & tokens: verification and regeneration of automation tokens if compromised.

7. Final tests and report

• Order flow: full purchase test from cart to confirmation to ensure absence of redirects or injections.
• Back‑office tests: login, product editing, order creation, email sending.
• Detailed report: summary of actions, collected evidence, files placed in quarantine, recommendations and hardening plan. The report also lists items requiring a human decision (restorations, permanent deletions).

Expected outcome

• Functional store with no visible redirects or malicious scripts.
• Modules and theme verified or replaced with clean, compatible versions.
• Legitimate employee accounts confirmed; compromised accesses revoked.
• Comprehensive report describing the probable cause, actions taken and operational recommendations.

Prudent settings and human decisions

• Any permanent deletion of a file or restoration from a backup is subject to validation.
• Temporary takedown may be proposed if the risk is high; the decision rests with the site owner.
• We prioritize non‑destructive corrections to limit business impact.

Common mistakes and points of attention

• Ignoring overrides: overrides can hide backdoors. Always check overrides systematically.
• Updating without testing: an untested module or core update can break customizations. Always test in preproduction if possible.
• Not changing credentials: leaving compromised accounts/FTP unchanged exposes to immediate recurrence.

Quick troubleshooting (if problem persists)

• If redirects persist: check server rules (htaccess/nginx) and CDN/Edge cache.
• If back office is locked: revoke administrator sessions and force password resets via secure channels.
• If orders are altered: restore the targeted DB copy after validation and compare with the initial dump to isolate malicious changes.

Legal and operational precautions

• We never request passwords by email. Transmit credentials only via the secure client area after commercial agreement.
• If sensitive customer data appears compromised, follow your local legal obligations (CNIL/GDPR notification if applicable) and retain intervention logs.

When to contact Securantis support

• Before the intervention if you have access constraints or a maintenance window.
• Immediately if you observe new injections after the intervention.
• For any decision regarding permanent deletion or restoration from backup: contact support to plan and document the operation.

Additional information useful to provide at startup

• PrestaShop version (1.7.x, 8.x, 9.x).
• List of payment modules and third‑party modules installed.
• Availability of a recent full backup and possible maintenance window.

Conclusion

Securantis’ intervention on PrestaShop follows a methodical approach: diagnosis, backup, quarantine, controlled cleanup, business verifications and hardening. We favor operational security and preservation of business data. Any destructive action is subject to human decision and documented in the final report. To start an intervention or request a quote, contact support via the client area.