This post summarises a recent case of credit card details hijacking that took place on one of our clients’ websites. It is estimated that this type of attack can be replicated on any Magento store where:

• all admin users have access to the backend config area,
• 2-factor authentication is not in place.

The issue

An intruder got access to the admin user account and injected JS code in the Scripts and Style Sheets section. The malicious JS was referring to obfuscated (encrypted) w.js file on purechat.org, which closely resembles the legit purechat.com.

How the issue was manifested

On the Checkout page, under the PayEx option, an extra in-line field for card details was included, which was not a part of the client’s original integration. When attempting to inspect the page to see source code, the field disappeared.

The field was only found to show up in a number of instances, which may signify that the fraudsters decided to target a certain percentage of the client’s traffic.

After entering the required data – order and shipment information and card details – an error message would pop up, saying “Sorry, Data could not be processed. Now you will be automatically redirected to our website for payment processing.” This message too was not a part of the original integration.

If the customer clicked OK, the original “Place order” button was clicked automatically, and the customer got redirected to the actual payment page.

As a result, the customer would have to fill the details once more. In the end, they would get the order and the company would get the money, but the fraudsters would have fetched the card details in the meantime.

The story in short

The client accidentally noticed that changes had been made to their website – specifically, an inline form, requesting credit card details, was added to the checkout page.

They got in touch with Scandiweb PM assigned to the project, asking to check if the changes were sanctioned, or their site was hacked.

After a quick check of the PayEx module, we found no mentioning of an option for an inline CC detail form. Hence, the client was advised to investigate the issue on the code level with a developer.

Since all the malicious work was done on the third-party side, we assumed that the intruder didn’t have full access to the server, and started by examining the possibilities of injecting code from backend.

We began by extracting the value representing the config page from the backend URL. For example, https: //~path~/section/osc, where OSC stands for One Step Checkout.

Then we searched the server’s access logs, filtering POST requests that included the value from above. This provided us with a list of IPs that performed SAVE operations in that backend area.

After that, we compared the IP list with the admin user report in the backend and located the compromised admin user.

Then we located all the all POST requests made by that IP and admin user and were able to trace the intruder’s actions: all in all, 11 meaningful operations, performed in one day inside a 20 min window – changes in other admin user accounts, customer ID modifications, content and store configuration changes.

Unfortunately, due to the nature of logging, we were only able to record the fact of the changes being made, but not the actual changes.

Also, before we were able to get our hands on the injected code the client had already erased it.

Actions performed during and after the investigation

1. Disabled the compromised payment option,
2. Cleared the malicious JS code,
3. Disabled compromised admin users,
4. Created a trigger in DB to prevent any changes in OSC config,
5. Restored the payment option,
6. Revised all admin users and limited their level of access to the backend,
7. Implement 2-factor authentication for all admin users.

Suggestions to prevent such attacks in the future

• Enable 2-factor auth for all admin users,
• Keep backend config area access limited to only those admins who really need it.

We hope you found this article useful! Have some additional questions or comments? Looking for specific web development & security solutions? Feel free to get in touch via [email protected] and let’s see how we can help!

Share on: