BOOK CONSULTATION
BOOK CONSULTATION

Magento Open Source · Adobe Commerce · incident

Magento store hacked? Here is the first hour.

A skimmer on the checkout, your bank details swapped, phishing sent from your domain, or a store that is simply gone. I take over, stop the damage without destroying the evidence, find how they got in, and bring the store back clean.

Send the URL and what you see or book a call now

For store owners and e-commerce managers on Magento or Adobe Commerce whose store is compromised, or looks like it.

First hour Example
  1. 00:00 Copy the evidence Files, database, server and admin logs. Before anyone deletes or restores anything.
  2. 00:15 Stop the harm Take the affected part offline: the store, the checkout, payments or outgoing email.
  3. 00:30 Take back control New passwords and keys, unknown admins and SSH keys removed, sessions ended.
  4. 00:45 Find how they got in Version against security bulletins, logs, changed files.
  5. Next Clean or rebuild, patch, verify Only once the way in is known.

Not yet Restore a backup, delete files, reopen the store

  • 6 h reply on working days, Monday to Friday
  • 24 h reply at weekends
  • 0 changes to your store without your OK
Which of these do you see?

Signs of a hacked Magento store

  • The bank account on your checkout, invoices or order emails is not yours, and transfers went to someone else.
  • Your payment provider or bank says card fraud was traced back to your store.
  • Customers mention a payment form that looks different, or say they had to enter card details twice.
  • Phishing or spam went out from your domain, or your mail server landed on a blocklist.
  • The store is gone or defaced: files or the database deleted, a ransom note, or pages you never made.
  • Chrome or Google search warns visitors that your site is dangerous, or Google shows spam pages under your domain.
  • There are admin users you did not create, or admin emails and passwords changed without you.
  • Your host suspended the account or sent a malware notice.
  • Hundreds of small failed card payments in an hour.

If any of these but the last is true, treat the store as compromised until it is shown to be clean. Attackers on Magento often hide in the database, not in a file, and stay quiet for weeks before they act.

The last one is usually a carding attack: bots testing stolen cards on your checkout. The store may not be infected at all, but the fees, the chargebacks and your payment provider's patience are real. It gets stopped at the checkout and at the edge, before it reaches Magento.

The first hour

What to do, and what not to do

Do

  • Copy before you change anything: files, a database dump, web server logs and the admin action log, with the time you took them.
  • Stop the harm where it happens: maintenance mode, the checkout or payment method switched off, outgoing email paused, a defaced page taken down.
  • Change admin, hosting, SSH and database passwords from a device you trust, and remove admin users you do not know.
  • Tell the people who have to act: your payment provider if cards are involved, your bank if payment details were swapped, your email provider if phishing went out.
  • Write a short timeline: what was seen, when, and by whom.

Do not

  • Do not restore a backup and move on. The backup may hold the backdoor, and the hole they used is still open.
  • Do not delete suspicious files before copying them. They show how the attacker got in and what they touched.
  • Do not reopen the store, the checkout or outgoing email until the way in is closed.
  • Do not let three people fix the server at once without notes. Changes nobody wrote down look like the attacker.
How I work

Six steps from "we are hacked" to a clean store

  1. 1

    Contain

    Copy the evidence, take the affected part offline, and lock admin and server access. The store stays down only as long as it has to.

  2. 2

    Find the way in

    I compare your exact version with Adobe's security bulletins, read the access and admin logs, and diff the code against a clean copy of the same release. A malware scanner such as Sansec eComscan adds known signatures.

  3. 3

    Clean or rebuild

    Remove backdoors from the code, skimmers and swapped payment details from the database, and rogue admin users and cron jobs. If the code cannot be trusted, I rebuild it from your repository and a clean release.

  4. 4

    Close the hole

    Patch the bug they used or update the vulnerable extension. Rotate the encryption key, passwords and API tokens, because the attacker may have read them.

  5. 5

    Verify

    Rescan, diff the files again, and order as a customer: check what loads on the payment step, the payment details shown and the emails that go out. Then request a review in Google Search Console.

  6. 6

    Monitor

    Alerts on changed files and new admin users, and a web application firewall rule set in front of the store, so a second attempt shows up early.

Hacked Magento store: the incident response path Six steps: contain the incident by copying the evidence and taking the affected part offline, find how the attacker got in from logs, admin users, the Magento version and changed files, clean code, database, admin users and cron jobs, close the hole by patching and rotating keys and passwords, verify with a rescan and a test order, then monitor file and admin changes. Cleaning without closing the hole leads to reinfection. 1. ContainCopy evidence,stop the harm 2. Find the way inLogs, admins,version, files 3. CleanOr rebuild froma clean release 4. Close the holePatch, rotatekeys, passwords 5. VerifyRescan, placea test order 6. MonitorAlerts on fileand admin changes Skip step 4:reinfected Hacked Magento store: the incident response path Six steps: contain the incident by copying the evidence and taking the affected part offline, find how the attacker got in from logs, admin users, the Magento version and changed files, clean code, database, admin users and cron jobs, close the hole by patching and rotating keys and passwords, verify with a rescan and a test order, then monitor file and admin changes. Cleaning without closing the hole leads to reinfection. 1. ContainCopy evidence, stop the harm 2. Find the way inLogs, admins, version, files 3. CleanOr rebuild from a clean release 4. Close the holePatch, rotate keys, passwords 5. VerifyRescan, place a test order 6. MonitorAlerts on file and admin changes Skip step 4:reinfected
Hacked Magento store, incident response: contain, find the way in, clean, close the hole, verify, monitor. A clean-up without step 4 brings the attacker back.

Step 2 starts from public data. magento.watch, my open tracker for Magento, lists the security bulletins that apply to each 2.4.x version. A Google warning is listed in the Security issues report in Search Console, which is also where you ask for a review once the store is clean.

The honest part

What I cannot do for you

  • I am not a PCI forensic investigator. If card data may have been exposed, your payment provider or the card brands can require a PFI. I keep the evidence intact for one and work alongside them.
  • Notifications are your legal call. Whether you must tell customers or a data protection authority (under GDPR, within 72 hours where it applies) is a question for a lawyer. I give you the facts they need.
  • A backup can contain the backdoor. Attackers often sit in a store for weeks before anyone notices.
  • Cleaning without closing the way in means reinfection. The same bug or the same stolen password lets them back in, often within days.
  • Hosting controls part of the stack. On Adobe Commerce Cloud or a managed host, server logs, the firewall and parts of the file system sit with their support team. Some steps wait for them.
  • No one can promise that nothing was missed. I can show you exactly what was checked, what was found and what was changed.
Proof

  • Tools I use

  • Incidents I have handled

    • A carding attack on a military outfits store. Bots testing stolen cards on the checkout, stopped.
    • Infections removed from multiple stores. In one wave after a public Magento exploit, about 1,200 webshell files found and removed, and the hole they came through patched.
    • Customer data exposed through a store API. Found API endpoints that handed customer records to anyone who asked, and closed them.
    • A bot flood stopped at the edge. Errors fell from about 18,000 an hour to under 30, and the server now only accepts traffic through Cloudflare.
    • An access audit. Shared SSH keys and admin accounts reviewed across 35 servers, and access nobody needed any more removed.
Effort and time

What decides how long it takes

  • How long they were in. A skimmer added yesterday is a smaller job than access that has been open for months.
  • How they got in. One known bug is quick to close. Stolen admin or SSH passwords, or a vulnerable extension, mean more doors to check.
  • What evidence is left. Logs kept and files untouched make the search short. A store already "cleaned" by restoring a backup makes it long.
  • Access. Full SSH and database access, or a managed host where some steps go through their support.
  • The version gap. How far the store is from a patched release decides whether closing the hole is a patch or an upgrade.

Response time. I reply within 6 working hours, Monday to Friday, and within 24 hours at weekends.

After the incident

Once the infection is gone, let's secure it for the future

A clean store on an unpatched version is a target again next month. People search for a "Magento security audit" at this point. What the store needs is narrower: the security patches its exact version lacks, a plan for the upgrade, and a hotfix routine for the next exploited bulletin.

Book a call about it →
Questions

My Magento store is hacked. What do I do in the first hour?

Copy the evidence before you change anything: files, database and logs. Take offline whatever is doing harm: the checkout, a payment method, outgoing email or the whole store. Change passwords from a trusted device and remove admin users you do not know. Then find how they got in before you clean, or the clean-up will not hold.

Is a Magento malware scan enough?

A scan is a good start, not the end. A malware scanner finds known signatures in files and the database. It does not tell you which bug or which stolen password let the attacker in, and new skimmers can be missed. The scan, the logs and a diff against a clean release together answer that. Sansec eComscan is one such scanner.

Can I restore a backup and move on?

Not on its own. The attacker may have been in the store for weeks, so the backup can contain the backdoor. Even a clean backup still has the hole they used. Restore only after the way in is known and patched, and keep a copy of the infected state for the investigation.

Who do I have to tell, and what?

Tell the parties who have to act early, and stick to facts: the payment provider if cards were involved, your bank if payment details were swapped, your host and email provider if the server sent phishing. If card data may have been exposed, they can require a PCI forensic investigator (PFI); I am not one, but I can keep the evidence ready for one. What you tell customers, and whether you must notify a data protection authority (under GDPR within 72 hours, where the rules apply), is a legal decision. Talk to a lawyer. I give you the facts: what was touched and when.

Our agency did the last change and is not answering. Can you take over?

Yes. I need hosting or SSH access, admin access and the code repository. Blame can wait. If your agency comes back, I share what I found so they can keep running the store safely.