Your Store Was Hacked or Card-Skimmed: The First 48 Hours

If your store was hacked or a card skimmer was found, act in order: contain it without wiping the evidence, preserve logs and a disk image, rotate every credential, then find and close the entry point. Tell your payment provider early, and bring in a certified forensics specialist for anything touching card data. This is engineering incident response, not a certified forensic service; confirm regulated steps with your adviser.

If you want the entry point found and closed, and your store hardened afterwards, see how RAITHub would fix this below. First, the clock.

What should you do in the first hour?

Contain the damage while keeping the evidence intact, because wiping a compromised server destroys the record of how they got in and what they took.

1. Isolate, do not delete. Take the affected site into maintenance mode or move it behind a block, rather than rebuilding on top of the running system. If you must take a server down, snapshot it first.
2. Preserve evidence. Save access, application and database logs, and take a disk image or snapshot before you change anything. A forensics specialist cannot work from a server you have already cleaned.
3. Rotate every secret. Admin passwords, API keys, database credentials, payment-provider keys, and any shared hosting login. Assume everything the attacker could reach is compromised.
4. Tell the people who need to know. Your payment provider, your card acquirer, your hosting provider, and one internal owner who coordinates the response. For card data specifically, your acquirer and the card brands have rules about notification and forensics.
5. Do not pay, negotiate or improvise with an attacker before you have advice. Those are decisions for specialists and your adviser, not a late-night call.

How do you tell what kind of breach it is?

The response depends on what was reached. Work out the type before you choose the fix.

Breach type	Signs	First priority
Card skimmer (client-side script)	Unknown script on checkout; buyers report fraud; payment pages altered	Remove the script, preserve it, engage card-data forensics
Admin or account takeover	Unexpected admin users, changed settings, orders you did not create	Rotate credentials, revoke sessions, check what was changed
Data exfiltration	Large unusual queries or exports; customer data for sale; unusual egress	Identify what was taken; this triggers notification obligations
Defacement or ransomware	Pages replaced; files encrypted; a ransom note	Preserve a copy, restore from clean backup, find the entry point
Injected malware or redirects	Store redirects buyers; spam pages; warnings from search engines	Find and remove the injection; audit every file changed

A client-side card skimmer, often called a formjacking or digital-skimming attack, is the highest-urgency case because it is actively capturing card numbers from live buyers. Removing it stops the bleeding; preserving it lets a specialist trace the scope. Anything involving card data or large amounts of personal data is where a certified forensics investigator and your adviser take over the lead, not an engineer.

How do you find how they got in?

Most store breaches come in through a known class of weakness, not a novel exploit. The OWASP Top 10 is the standard list of the most critical web application security risks, and it is the right checklist to work through when hunting the entry point (OWASP Top 10).

• Access control. Can one user reach another user's orders or an admin page by changing an ID or URL? Broken access control is consistently near the top of the OWASP list.
• Injection. Does any input reach a query or a shell unsanitised? Check search, filters and any raw SQL.
• Outdated components. A vulnerable plugin, theme, dependency or server package is a common door. List installed versions against known advisories.
• Exposed secrets. An API key in client-side code, a service credential in a public repository, or a misconfigured storage bucket.
• Third-party scripts. A skimmer often arrives through a compromised tag or a script loaded from a third party. Audit every external script on the checkout page.

Read the preserved logs for the first sign of the intrusion, not just the latest symptom, so you close the real door rather than a later one. If the store was built quickly with AI tools and never reviewed, the vibe-coded app security checklist lists the checks most often skipped.

What should you harden before going back online?

Do not restore the site as it was, or the same door is still open. Before the store goes live again:

• Patch or remove the component that let them in, and update everything else while you are there.
• Rotate every secret again after the clean-up, in case any were captured during the incident.
• Add a Content Security Policy so an injected script cannot load from an unexpected source, and lock down which scripts the checkout page may run.
• Enforce least-privilege access: fewer admins, strong authentication on every admin account, and sessions that can be revoked.
• Add monitoring that would catch a recurrence, such as alerts on new admin users, on changes to checkout scripts, and on unusual data egress.

Who must you bring in, and for what?

Task	Who leads it	Why
Card-data forensics (PFI)	A certified forensic investigator	Card-brand rules require certified investigation after a suspected card breach; an engineer cannot produce the attestation
Breach notification and legal duties	Your legal or compliance adviser	Notification deadlines and obligations are a legal matter; confirm with your adviser
Payment provider and acquirer contact	You, early	They have their own rules and can help contain card exposure
Finding and closing the entry point	An engineering team	Application-level review against OWASP and hardening the store
Rebuild and prevention	An engineering team	Patching, CSP, least-privilege access and monitoring

The split matters. Engineering can contain the incident, find the entry point and harden the store. A certified forensics investigator and your adviser own the card-data investigation and the notification decisions, because those produce legal and compliance outcomes that application testing does not. Treat security testing as honest engineering readiness against OWASP guidance, not a certified penetration test or a compliance attestation.

Buy, build or hire?

Option	What you get	Choose this when
Platform security tooling	The platform's own malware scan and patching	You are on a hosted platform and the compromise is within its scope
A certified forensics firm	The card-data investigation and attestation	Card data was or may have been exposed; this is required, not optional
Engineering incident response and hardening	The entry point found and closed; the store hardened	You need the application-level cause fixed and recurrence prevented
Your own team	Full control, if they can read logs and review against OWASP	You have the skills and the incident is small and contained

How RAITHub would fix this

• Scope: help contain the incident without destroying evidence, review the application against OWASP guidance to find the entry point, close it, rotate secrets, add a Content Security Policy and least-privilege access, and set up monitoring that would catch a recurrence.
• Timeline: containment and finding the entry point is fast; a full hardening pass sits inside the code rescue range of 2 to 4 weeks.
• What you receive: the entry point identified, the fix and hardening behind tests in your CI, a short incident write-up, the IP assigned to you and an NDA as standard. Card-data forensics and breach-notification decisions stay with your certified specialist and adviser.
• Next step: a free 15-minute technical audit, then a written fixed quote.

RAITHub's security testing is application-level testing against OWASP guidance; it is not a CREST- or PCI-certified penetration test and produces no compliance attestation, so engage a certified specialist for forensics and confirm legal steps with your adviser. The testing discipline shows in the platforms RAITHub built: Sundor Skin runs a security suite that tries to read other buyers' data, with CI failing if a buyer-scoped table lacks row-level security, among 530+ tests; TheSkinProof, the founder's own venture, carries 750+ tests. For the broader lessons of a sector-wide software compromise, see car dealership software security. See the eCommerce industry page and the security testing service, or book the free 15-minute audit with what you have found so far.

Documentation checked on 11 October 2026. This is general engineering guidance, not legal advice; confirm notification and compliance steps with your adviser.

Frequently asked questions

What is the first thing to do when my store is hacked?

Contain it without destroying evidence: take the site into maintenance mode or block it rather than rebuilding on the running system, snapshot the server and save the logs, then rotate every credential. Tell your payment provider, acquirer and hosting provider early, and name one internal owner to coordinate.

What is a card skimmer, and how do I stop it?

A card skimmer, also called digital skimming or formjacking, is a malicious script that captures card numbers from your checkout page as buyers type them. Remove and preserve the script, audit every external script the checkout loads, add a Content Security Policy to block unexpected sources, and engage a certified card-data forensics specialist.

Should I wipe and rebuild the hacked server immediately?

Not before you preserve the evidence. Wiping the server destroys the record of how the attacker got in and what they took, which a forensics investigation needs. Snapshot the server and save the logs first, then rebuild clean after you know the entry point.

Do I have to report an e-commerce data breach?

Often yes, on a deadline, but the specifics are a legal matter that depends on where you and your customers are. Treat this as general information and confirm your notification obligations with your legal or compliance adviser, and contact your payment provider and acquirer early for card-data cases.

Can an engineering team do a forensic investigation?

An engineering team can contain the incident, find the application-level entry point against OWASP guidance and harden the store. A certified card-data forensic investigation, and any compliance attestation, must come from a certified specialist, because those produce the legal and card-brand outcomes that engineering testing does not.

How do I stop it happening again?

Close the entry point, patch or remove the vulnerable component, and rotate secrets again after clean-up. Then harden: a Content Security Policy, least-privilege admin access with strong authentication, revocable sessions, and monitoring that alerts on new admins, changed checkout scripts and unusual data egress.