PrestaShop store hacked: why a cleanup isn’t enough to secure a store – The “Mandoline” case

A compromised PrestaShop store, a web skimmer stealing payment card numbers, a cleanup performed by the developer… and a hacker still inside.

This audit report shows why “cleaned” doesn’t mean “secure,” and what needs to be checked before considering a security incident closed.

Context

The scenario is unfortunately all too common. A PrestaShop store is compromised, and the hacker installs a web skimmer: malware that steals payment card numbers entered by customers and exfiltrates them to a server it controls.

The store’s developer identifies the script, removes it, and puts the store back online. Being cautious, “mandoline” store manager commissions us to conduct an audit. He wants to ensure the site won’t be compromised again. He was right to be careful.

Our mission

With an initial cleanup already performed, reconstructing the original attack becomes difficult: files have been deleted or replaced, and traces have been overwritten. And since the store has evolved in the meantime, such forensic analysis would have limited value anyway.

Our mission is therefore to determine whether the store is fully secured. To do this, we typically focus on three areas:

• Application and server security assessment: PrestaShop and module versions, file integrity, server configuration, scheduled tasks, user accounts, and access permissions.
• Technical data disclosure: publicly exposed information that could facilitate an attack (software versions, configuration files, backups, logs, directory listings, overly verbose HTTP headers).
• Penetration test: identifying vulnerabilities and attempting to exploit them to assess actual, rather than theoretical, risk.

What We Found

1. The attacker was still there

Despite the developer’s cleanup, our tools identified four malicious components on the server, either active or dormant:

1. A web skimmer had been reinstalled
2. A tool was exfiltrating Back Office credentials on every login
3. A dormant backdoor designed to create Back Office accounts had been planted for later use
4. A cron job was checking whether the backdoor was still present and restoring it if removed

This setup illustrates layered persistence: credential exfiltration allows the attacker to regain access even after passwords are changed, the dormant backdoor provides a fallback, and the cron job protects the entire setup against cleanup attempts.

The cron job is particularly revealing. Scheduled tasks are configured at the system or hosting level (crontab, hosting control panel), a level typically not inspected with a code cleanup..

The direct consequence: changing passwords before removing these persistence mechanisms is pointless. The new credentials are sent straight to the attacker as soon as someone logs in.

2. A wide-open attack surface

Beyond the active compromise, our audit uncovered numerous security weaknesses. None was particularly complex. Together, they help explain both the initial intrusion and how easily the attacker was able to expand their access.

Modules with publicly known vulnerabilities

Several installed modules had publicly documented vulnerabilities, making them the most likely initial entry point. On PrestaShop, third-party modules are a major source of compromise. Once a vulnerability is disclosed, it can be exploited at scale through automated scanning, often within days of its discovery.

A reminder: neither disabling nor uninstalling a module necessarily removes its files from the server, and its PHP scripts often remain directly accessible via URL. An unused module must be completely removed, including its files.

No additional protection for sensitive access points

Neither cPanel, FTP, nor the Back Office had additional security controls: no IP-based access restrictions and no two-factor authentication. Once the attacker obtained a single set of credentials, they could move from one access point to another with little resistance.

An overly permissive server configuration

• No Content Security Policy (CSP). Without a Content-Security-Policy header, the browser may load injected JavaScript or iframes from arbitrary domains. Restrictive script-src, frame-src, and connect-src directives could have prevented the skimmer from loading its code or sending stolen data to an external domain.
• Overly permissive TLS configuration, identified through an SSL Labs test. The objective is to allow only TLS 1.2 and 1.3 with modern cipher suites and enable HSTS.
• No file access restrictions. Files that should not be publicly accessible (configuration files, logs, archives, SQL dumps) must be blocked at the web server level, and PHP execution must be disabled in upload directories.
• No access restrictions on third-party service APIs. Some APIs expose sensitive information and, in certain cases, allow customer data to be retrieved. Where supported, API access should be restricted to the IP addresses used by the service provider.

No blocking or detection tools

There was no WAF, no Back Office login monitoring, and no File Integrity Monitoring (FIM) solution in place.

A WAF such as PrestaFence could have blocked attempts to exploit known module vulnerabilities. Back Office login monitoring (built into PrestaFence) could have detected suspicious login activity. A FIM solution would have flagged file creation or modification: the skimmer, the exfiltration scripts, and the backdoor restored by the cron job.

Backups Stored on the Same Server

Backups were stored on the server itself. Within the attacker’s reach, they exposed the entire database (customers, orders, password hashes) as well as configuration files, including the PrestaShop cookie key.

Backups must be stored off-server and never placed within the webroot.

No Security Procedures

There were no regular reviews of sensitive access permissions (Back Office accounts, FTP, SSH, hosting accounts, API keys), nor any procedures for rotating security-sensitive elements such as the Back Office URL or the PrestaShop cookie key (which should only be changed if you fully understand the implications).

Key Takeaways

A good developer isn’t automatically a cybersecurity specialist

Developer skills and cybersecurity skills are just different. Cybersecurity requires continuously keeping up with attackers’ techniques and tools. We clean up several compromised PrestaShop stores every month, and this hands-on experience is what allows us to maintain our expertise.

Beyond the audit report and recommendations, we also held a knowledge-sharing session with the developer to help him strengthen security on future projects.

Without the right tools, you’re working in the dark

Attackers go to great lengths to remain undetected. Without the right tools, detecting unusual activity is extremely difficult. PrestaFence monitors Back Office logins and alerts you to suspicious behavior.

Cleaning up doesn’t drive attackers away

Quite the opposite: cleanup are simply part of a compromised shop lifecycle exploitation.