The attacks that actually hit stores
- Card skimming: a few lines of JavaScript added to the checkout page, or a form quietly pointed at another host. The site stays up and sales continue, which is why it runs for weeks.
- Credential stuffing against customer and admin logins, heaviest around sales events.
- Bots hammering checkout, search and cart endpoints until real shoppers time out.
- A plugin or extension a version behind a disclosed vulnerability, which is how the skimmer got in.
- A web shell left in an uploads directory, so the attacker returns after you clean up.
Watching the page the shopper gets
Most store compromises are invisible from the server's process list. SecAI probes each website you ask it to monitor every five minutes and keeps a small fingerprint of what came back: the script and iframe domains the page loads, where its forms post, its redirects, its outbound links and hidden elements. Once three probes agree, that is the page's normal, and from then on a new script domain, a form posting elsewhere or a new redirect becomes a finding that names what changed. A change has to be seen on two consecutive probes, so a deployment in progress does not read as an injection, and when you resolve a finding yourself the current page becomes the new normal.
Once a day the same page is fetched as a search engine would fetch it, because some injections only show themselves to crawlers, and the URL is checked against Google Safe Browsing. Website monitoring is part of the Pro plan and above.
Staying up during a sale
On a server set to Automatic, SecAI blocks the address behind repeated login failures, vulnerability-scanner probing, WordPress login abuse, HTTP floods and connection exhaustion, through the firewall the server already runs, usually within a minute or two, and the block expires on its own after 6 hours, longer for an address that keeps coming back, never more than 7 days. Your own addresses, and the edges of a CDN in front of the store, are never blocked, so the store cannot be taken down by its own traffic. A flood large enough to saturate the link is reported as that, and the fix is upstream at the provider or the CDN; SecAI says so rather than claiming otherwise.
The server behind the storefront
The agent reports changes in the web root with the hash before and after, so a modified core file or a new PHP file in uploads is a finding rather than a surprise. Installed packages are matched against vulnerability data every twelve hours. The weekly AI audit reviews exposed services, SSH settings, accounts and pending updates with the evidence attached. Anything it proposes to change, a hardening fix, a package update, quarantining a suspected web shell, waits for your approval, and an approved fix is rolled back on its own if it breaks the site.
PCI DSS evidence, not a certificate
If you take cards, somebody will ask for evidence: file integrity monitoring on the systems in scope, a record of changes and who approved them, vulnerability management, access monitoring. SecAI produces a PCI DSS evidence report from what it actually observed on your servers, control by control, with the gaps stated. It supports an assessment; it does not make a store compliant, and no monitoring tool can.
What it does not do
- It is not a web application firewall and does not inspect or rewrite requests to your store.
- It does not clean infected files; a suspected web shell is quarantined in place, on your approval, and never deleted.
- It does not see inside a hosted payment page or your payment provider's systems.