Hacked Magento Store: Analysis and Cleanup After a StyleSmuggler Attack
Industry: E-commerce / online store
The situation
The Magento store had been hacked earlier in an incident that showed signs of the StyleSmuggler campaign. The security patch was already applied, but the analysis showed that patching the vulnerability alone did not solve the problem: the first signs of infection appeared before the hotfix was applied.
In situations like this, the biggest mistake is assuming the store is clean once a few suspicious files are deleted.
Here the problem went much deeper. I had to establish what had actually been changed, whether the attacker had left a way back in, and whether access to the server, the store and the services connected to it could still be trusted.
The problem: a hacked Magento store is more than a few malicious files
The first broader review turned up hundreds of files that needed checking, and several dozen of them were later classified as clearly malicious.
But the number of files was not the biggest problem here.
The attack was not limited to Magento itself. The server also had mechanisms that let the attacker keep access to the system and restart unwanted components. That meant simply scanning the store directory and deleting the files found could only give a temporary sense of security.
On top of that, the server ran quite a few custom extensions and integrations. Not every unusual file was malware, and automatically deleting everything that looked suspicious could simply break the store.
So the most important thing was not the "cleanup" itself, but doing things in the right order.
What I did: Magento malware removal step by step
I started by stopping normal store operation and collecting information about the state of the server. Before I deleted anything, suspicious items were preserved for later analysis. That way I could work without destroying evidence and compare the results of each check with the previous ones.
Then, step by step, I checked not only the Magento files but also the places through which the infection could persist or come back. It was important to tell real traces of the attack apart from normal system processes. The work documentation stated plainly that a single unusual process or file cannot automatically be treated as malware without checking its context.
Only after this investigation did the actual work of cutting off the infection, piece by piece, begin.
- I preserved the artifacts I found before neutralizing them, instead of permanently deleting everything on the first pass.
- I removed the known mechanisms that let the infection persist outside the Magento directory.
- I ran another check of the store, its modules, its configuration and the places where changes like these most often hide.
- I verified the client's custom modules and integrations separately, so that legitimate code would not be mistaken for leftovers of the break-in.
- I also checked the protections that limit the ability to run files like these directly through the website.
- After cleaning the server, I ran another round of checks to make sure the mechanisms found earlier were not coming back.
Once the cleanup was finished, it was time for a step you cannot skip after an incident like this: rotating credentials.
I changed the passwords, keys and access details for the services tied to the store, including administrative access to the server, the database, Magento, the backup system and the third-party integrations the store uses. This rotation can only be done once the infection is under control, because setting new passwords earlier could get them stolen again. The incident documentation laid out exactly this order: first remove the mechanisms that keep access, then change the credentials and verify again.
Finally, I checked both the system and the store once more before bringing normal traffic back.
The whole job (from analyzing the incident, through preserving evidence and cleanup, to changing every password and access to the store's services) took me just under 8 hours.
Result
After the work was done, the known components of the infection were neutralized, and repeated Magento checks found no active known webshells or mechanisms keeping the infection alive in the areas checked.
But the most important result was not deleting several dozen files.
The store went all the way from "we know it was attacked" to "we know what we were looking for, what we found, what we removed, what we checked again and which credentials were changed".
That is an important difference, because with an infected online store, removing the visible symptoms does not yet mean the problem is solved.
With access this deep into the server, I also have to be honest: cleaning an existing system never gives quite the same guarantee as rebuilding the whole environment from scratch. In this case the goal was to safely recover the existing installation, with evidence preserved, repeated verification and rotated credentials, instead of a quick "antivirus scan" and putting the store back online.
Dealing with a hacked Magento store, or suspect that deleting the infected files is not enough? I'll respond within 24 hours.
Describe the problemFacing a similar problem?
Tell me what you're dealing with - I'll respond within 24 hours and be straight with you about whether I can help. No strings attached.