An online shop flagged by Google Restored in 48 hours.
A stolen administrator password, three trojanised extensions, a site flagged by Google and a domain that no longer sends e-mail. A Swiss online shop, with no contract with Avepto, asked us to step in.
- Client
- Online shop French-speaking Switzerland
- Relationship
- One-off intervention No service contract
- Scope
- WordPress, WooCommerce Three sites, one hosting plan
- Solution
- Clean-up and hardening In 48 hours, shop open
Contents
An online shop that has been running for years.
The shop sells physical goods on WordPress and WooCommerce. Several thousand orders, Twint as the main payment method, several hundred customer accounts. Three sites share one hosting plan. The site was built, then patched, by a succession of agencies, with no IT lead in charge. When Google’s warning screen appeared, the company had nobody to call. It called Avepto.
A first-try login, then a shop at a standstill.
On a Monday evening, shortly before 11 p.m., an address rented from a foreign hosting provider lands directly on the admin page. It does not browse the site. Three minutes later the login succeeds at the first attempt, with the administrator account’s valid password. Within four minutes three trojanised extensions are uploaded; one of them creates a hidden administrator account. None of it is visible from the shop.
Twelve days later, Google Safe Browsing classifies the site as “social engineering”. A warning screen replaces the storefront, major ISPs block the domain, e-mail stops going out and coming in. The Federal Office for Cybersecurity contacts the company and its host. Two days after the flag, the site is cleaned, hardened and back online; some customers cannot reach it for another two to three weeks.
Four ordinary weaknesses, one exposed shop.
The attack did not exploit a flaw in the site. It chained four weaknesses found on most shops built up over the years.
A password stolen upstream of the site
The logs show no brute force and no exploitation of a flaw: the attacker knew the password. It was obtained elsewhere, by a credential-stealing programme on a workstation, a reused password from a leak, or phishing. The login captcha was passed by hand.
One account, no two-factor authentication
The administrator account, the only one able to install extensions, had neither two-factor authentication nor lockout after failed attempts, and the login URL was the default. Once the password was known, everything was open.
Provider access left open
Two remote-management extensions installed by former providers still gave full access to the site from outside, including a password-less login for a developer long gone. Such access bypasses the password, the hidden URL and two-factor authentication.
A dormant backdoor from an earlier incident
A trojanised extension from an older incident was still sleeping on disk. A bulk re-activation of extensions, the day before Google flagged it, put it back in service by accident. On a shop, a hidden administrator sees customers, addresses and order history, and can alter the checkout.
Trace, remove, secure, streamline, reopen.
Understand before cleaning
The server’s access logs made it possible to reconstruct the attack minute by minute: the direct arrival on the admin page, the successful login, the three extension uploads. That reconstruction identified the observed entry point: a valid credential. Within that sequence, the logs show no sign that a flaw in the site was exploited.
Nothing was deleted blindly. Suspect items were quarantined and kept for independent review. Every open session was destroyed: a stolen cookie was worth nothing any more.
Eradicate and verify all three sites
The three trojanised extensions, the dormant backdoor and the two hidden administrator accounts were removed. The three sites on the hosting plan were then put through the same check: malicious extensions, backdoor key, webshell patterns, unauthorised accounts.
The checksums of the WordPress core and of the thirty public extensions matched. False positives were inspected one by one, including an image of payment icons and an overnight automatic update mistaken for a reinfection.
- Trojanised extensions eradicated
- Hidden administrator accounts removed
- WordPress core verified
- Thirty extensions verified
- Sessions destroyed
- Items kept in quarantine
Close the doors
The administrator password was reset and handed over through a separate channel, the session keys rotated on all three sites, two-factor authentication enabled, the login URL hidden, lockout after five failures set up and a Wordfence web application firewall deployed.
The two former providers’ remote-management tools were removed, five stale accounts purged and public registration closed: it had produced nearly 2,000 junk accounts, mixed in with real customers. One privileged account remains, protected.
Lighten the shop
Every extension was checked against its real usage data before any decision: orders, tables, rendering on the pages. The payment gateways in use were kept; a fake-review generator and a file manager were removed, seven extensions with no demonstrated use deactivated.
The site had had no page cache for over a year. One was installed, with the cart, checkout and accounts excluded. The server’s response time went from about two to three seconds to 0.2 seconds.
Lift the flag
Once the restoration was complete, a review request was submitted to Google Safe Browsing. It set out the measures taken. The host and the Federal Office for Cybersecurity were informed. Google lifted its warning in the following days.
Not every operator kept pace: a major Swiss internet service provider went on blocking the site for its subscribers. Each operator keeps its own list; when one does not respond, all that remains is to document the clean-up, follow up and wait. The domain only came off every list after two to three weeks, and e-mail resumed.
Forty-eight hours to restore, up to three weeks to clear the blocklists.
Restoration
48 h
From the first intervention to the handover of access: investigation, eradication, verification of the three sites and hardening. Once the site was cleaned and reopened, the shop resumed taking payments while analysis and hardening continued. A card payment went through on the morning of the second day, with Google’s warning still showing.
Intervention timeline.
Server response time
×10
From about two to three seconds down to 0.2 seconds on the home page once the page cache was in place. Measured before and after, on the same hosting plan.
No flaw in the site was exploited: there was a key, and that key was lying around. The measures above mean a stolen password is no longer enough, and a forgotten access no longer outlives whoever created it.
A shop closed by a red screen.
For the shop
The risk, before
Reduced sales for weeks, a red screen and blocked e-mail. Two hidden administrator accounts had access to hundreds of customer accounts, requiring an assessment of whether the Federal Data Protection and Information Commissioner had to be notified.
The benefit, since
A single privileged account, protected by two-factor authentication. Provider access removed. A lighter, faster shop, and a restoration file to show Google, the host and the payment partners.
For the site
The risk, before
Three trojanised extensions, a dormant backdoor, two remote-management tools open to the outside, no web application firewall, no cache, haphazard updates.
The benefit, since
Web application firewall in blocking mode, login lockout, session keys rotated, scheduled scans, a formal update policy and response time cut to a tenth.
Testimonial
We found out about the attack from Google’s red screen, not from the site. Within two days we knew what had happened, and above all who still had a key.
A shop is an information system.
- A shop’s administrator account gives access to customer data, orders and payments. It deserves the same rules as business e-mail: two-factor authentication and a unique password kept in a password manager.
- Provider access outlives providers. Every departure must end with access revoked, and every online shop deserves an inventory of who can get in.
- Being flagged costs more than being broken into: storefront, e-mail and reputation go down together, and a .ch domain can even be blocked at the request of a federal authority. Lifting the blocks is out of the company’s hands.
When the report was handed over, three items remained in the company’s hands: analyse the workstation the password was stolen from, rotate all its passwords from a clean machine, and move its hosting credentials out of a shared document into a password manager. The door is closed again; those three actions decide whether it stays closed.
Your shop
Start by knowing who has the key.
Accounts, third-party access, extensions: three things to check on a shop before a red screen does it for you. No commitment.
Book a security audit