A bot changing an administrator’s password, malicious code in an online shop and login errors can all be signs of the same problem: someone has gained access to the application. Restoring the website is the first step. Reducing the opportunity for another attack is the second. Two cases from our work show why both steps matter.
Case one: a bot changed a WordPress administrator’s password
The administrator of an events website noticed that a bot had changed his account password. He recovered access, set a new password and ended the suspicious session. He also checked the other users and account details. These were appropriate immediate actions, but we still needed to establish how the attacker had gained access.
We analysed the logs, account activity and application state. Our findings pointed to an automated attack exploiting a vulnerability in the version of WordPress previously running on the site. Changing the password alone did not address the cause.
The investigation covered core files, plugins, accounts, permissions and active sessions. We found no new administrator accounts, backdoor or file changes linked to the incident under investigation. That was the result of the checks we performed, rather than a promise that a single scan can answer every question about a breach.
We verified the updated system, replaced the authentication keys and invalidated administrator sessions. We also blocked the mechanism used in the attack at server level across seven domains on the same hosting account. After making the changes, we tested the website, login and API. The service was working correctly.
In this case, the response addressed both the consequences of the incident and the route used in the attack. Further recommendations covered two-factor authentication, passwords reused in other services and log monitoring.
Case two: malware in a PrestaShop store
In a store running PrestaShop 1.6, we found malicious code in several parts of the application. Some files masqueraded as images or a stylesheet while containing code associated with the infection. Changes also affected the template libraries, controllers and administrator login mechanism.
Removing one suspicious file was therefore not enough to complete the repair. We needed to check the application code, modules and cache. We moved infected files into quarantine and removed confirmed injections from files under version control by restoring verified versions. At the same time, we preserved store customisations that showed no signs of infection.
Clearing the template cache was part of the repair: previously compiled files could continue to cause errors even after the source code had been corrected. After the cleanup, we checked the syntax of key files, the store’s response and the presence of known infection markers. The store responded correctly again, and the markers we checked were no longer present.
We also found code designed to capture administrator login credentials. We therefore recommended changing passwords and taking further steps to secure the environment. Restoring files does not replace reviewing and securing access to the store.
Following an earlier cleanup, we did not receive approval to implement the recommended security measures. The problem later returned, and the store required another intervention. This case shows the practical consequences of leaving the security work outside the scope of the repair. It does not mean we established the same entry route for every incident; it means that cleaning up the infection alone did not provide a lasting solution.
What should a repair after a breach include?
The first step is to preserve the evidence needed for analysis and establish the scope of the incident. Next, remove confirmed malicious code, restore verified files and check that the application works. At the same time, review administrator access, active sessions and secrets that may have been exposed.
The follow-up plan should reflect the condition of the particular website. It may include updating the system and modules, restricting access, adding server rules or migrating an older application. The owner should know which work has been completed and which steps remain recommendations. A working website and a completed security remediation process are two separate outcomes.
Need help with your website or online store?
If you notice unknown accounts, suspicious redirects, password changes or errors following an infection, contact Projectic. We will investigate the problem, propose a repair scope and help plan security measures after restoring the service. We can also discuss ongoing technical support for your website or store.