Recovery and hardening of a compromised Magento store

Why this record reads differently from the others

A security record has a discipline the others do not. Nothing here describes how the store was reached or what weakness was used: that information helps the next attacker, and the register records none of it. Nothing here suggests the client did anything wrong either. Stores are compromised for many reasons, most of them unremarkable, and a supplier that implies otherwise is not one to call when it happens to you.

What is publishable is the work: its order, its artefacts and its stated limits.

Phase one: investigation and assessment

A security scan with a cause analysis; a full malware scan across the source code and the database; checks of server logs, file permissions and abnormal files; and a damage assessment. The phase ends with two deliverables, an infected-file report and a recovery plan, which the client can read and check against its own store before repair begins.

Phase two: cleaning and system recovery

Malware and backdoors removed; Magento core files restored at the matching version; file permissions fixed; the database cleaned. Restoring at the matching version matters: it separates what the store is supposed to contain from what was added to it, without quietly changing the version the shop runs on.

Phase three: file restore, recoding and hardening

Damaged files, modules and themes repaired; Magento security patches applied; the server and the administrator area hardened. Rewriting modules or themes from scratch is excluded from this scope, so a store with badly damaged customisations may need separate work afterwards, decided once the assessment is in.

What is claimed, and what is not

No measured result exists for this engagement and none is published. There is no figure, no period and no before-and-after.

Nor is a state of security claimed. Netbase does not say this store, or any store, is secure afterwards. The project document itself excludes a complete recovery guarantee, and this record keeps that exclusion rather than dropping it on the way to a website. The 6 to 13 days is a typical range depending on the damage found; it is not a commitment, and a duration is not a result.

What a client is left with is verifiable rather than asserted: an infected-file report and a recovery plan naming what was found; core files restored at a known version; security patches applied; permissions, server and administrator area hardened. Each can be checked by the client or by a reviewer of its own choosing, which is the only honest form a claim of this kind can take.

Questions buyers ask

Will my store be secure after this work? No supplier can promise that, and this one does not. The document behind this record excludes a complete recovery guarantee. The work removes what is found, restores core files, applies patches and hardens the server and administrator area, and it reports what it found so you can verify the work rather than trust it.

Does this record say how the store was compromised? No. The cause analysis belongs to the client, and publishing a route into a live store would be reckless. This record describes the recovery, not the incident.

How long would mine take? Typically 6 to 13 days, depending on the damage. That is what the document records; your own scope is set by the investigation phase, not before it.

Does a compromise mean the client was negligent? Nothing in this record supports that reading, and none is intended.