Website hacked

Website hacked: emergency help for websites and online shops

Strange redirects, spam from your own mailbox, a warning in the browser, or your hosting provider has taken the site offline: if you are here, something has probably happened. We help in a fixed order — secure, understand, restore, close — for TYPO3, WordPress and Shopware, even if we did not build the installation. Reachable Mon–Fri 9:00–16:00 on +49 441 21 21 63 0; outside office hours through the form below. Emergencies are handled before all other enquiries.

Make an enquiry 0441 21 21 63 0 Mo – Fr, 9:00 – 16:00 Uhr

How you notice that something is wrong

Very few attacks look like in the movies. Usually something small catches the eye first — and behind it a script has been running for weeks.

The site sends visitors somewhere else

Visitors end up on foreign pages, but only when coming from Google or only on a phone. In the backend everything looks normal. Typical of injected redirects that target only search engine visitors — the site owner never sees them.

Google shows pages that do not exist

Hundreds of subpages in a foreign language or with foreign products appear in the search results. The attacker is using your domain and your ranking as a vehicle for their content.

A browser warning, or your host has pulled the plug

“This site may be hacked” under the search result, a red warning page in the browser, or an email from the hosting provider who detected spam and switched the site off. From now on every hour costs customers.

Something is wrong in the shop checkout

Foreign scripts in the order process, payments that do not arrive, customers with unexplained card charges. In online shops the payment path is the target — and the damage is greatest.

First: delete nothing

The understandable impulse is to delete the suspicious files and change the password. Both destroy evidence and do not close the door. The back door is almost always somewhere other than the visible malware: in a second, inconspicuously named file, in a modified system file, in an additional administrator account, in a cron job, or in an extension that restores itself.

So the first step is: put the site into maintenance mode, make a copy of files and database, lock access, secure the logs. Only then analyse. Whoever works in this order can later say what happened — and does not have to start again in four weeks because the back door was still there.

How we find the way in

We read the access logs backwards: upload paths, login pages, installation tools, unusual requests shortly before the first change. We compare the files with the originals of core and extensions and see what was changed or added. We check the database for foreign accounts and injected content, the installed extensions for known vulnerabilities, and the question of where credentials were stored that should not have been there.

The result is a picture: when it happened, through which route, and what the attacker did. Without this picture every restore is a matter of luck — with it we know which state is clean and which gap has to be closed.

Restore cleanly instead of tidying up

The cleanest route is a backup from before the break-in, plus all updates released since. For a shop we reconcile the data created since the backup — orders, customer accounts — and carry them over after checking. If there is no reliable backup, we set up core and extensions fresh from the original sources and take over only content and uploads, after checking them.

After that all credentials are changed, without exception: administrators, database, FTP and SSH, API keys, payment providers, mail sending. A password the attacker knows makes the best restore worthless.

Afterwards: close the gap and win back trust

The actual cause — an outdated extension, an open installation tool, a form without validation, a server on a PHP version without updates — is closed and the system hardened: updates, a second factor for admin access, rights by task, and on request a firewall in front of the server with Cloudflare.

Then we win back trust: in Google Search Console we check the security issues and request a review so that the warning disappears. If the domain is on block lists for mail or browser warnings, we start the removal. If personal data was reachable, the GDPR requires notification of the supervisory authority within 72 hours (Article 33) — we provide the technical facts, the legal assessment stays with you or your data protection officer.

What it costs and what we do not promise

Emergency help is billed by effort, after a short first conversation in which we assess the situation. We do not give a time or price commitment without looking at the system — whoever does is guessing. What we do commit to: the order of steps, transparency about every step, and a short report at the end that records what happened and what was done.

And we do not promise one hundred percent security. What we offer is the state in which mass attacks come to nothing and an incident stays an incident — with ongoing support that takes care of updates, backups and monitoring so that you never need this page again.

Process

Tell us what you see.

Domain, system and what you have noticed are enough for the first step. We need access only once you commission us — and then only as much as necessary. Mon–Fri 9:00–16:00 also by phone: +49 441 21 21 63 0.

  1. 01

    Contact and situation

    You describe what you see: domain, system, since when, which access exists. We tell you immediately what you should not do yourself.

  2. 02

    Secure

    Maintenance mode, copy of files and database, logs secured, access locked. Nothing is deleted before it is secured.

  3. 03

    Analysis

    Logs, file comparison, database, extensions. Result: entry route, point in time, extent.

  4. 04

    Restore

    Clean state from backup or fresh setup, all updates, data carried over after checking, all credentials changed.

  5. 05

    Hardening

    Cause closed, admin access with a second factor, rights tidied up, on request firewall and bot protection in front of the server.

  6. 06

    Aftercare

    Search Console, block lists, basis for notification duties, short report — and a proposal for ongoing support.

Projects on this system

Shopware 6 M&S Armaturen Shopware 6 B2B shop with connected item and pricing logic
TYPO3 M&S Armaturen Multilingual TYPO3 site with a direct link into the shop
TYPO3 · Fluid · Bootstrap · WCAG 2.1 AA · EN 301 549 J. Bünting Beteiligungs AG Operable without a mouse — contrast and text size on every page.

A selection — not the full client list.

Frequently asked questions

What should we do in the first 30 minutes?

Three things: put the site into maintenance mode or have the host switch it off temporarily so that no more visitors are affected. Delete nothing and do not “tidy up”. And from a different, clean device, change the passwords of your email mailbox and your hosting customer account — not those of the website itself, they come later in the analysis. Then call us or write through the form.

Is it not enough to delete the foreign files?

No. The visible malware is almost never the only foreign body. Attackers plant back doors in several places so that they can return after the clean-up. Whoever only deletes usually has the same infection again within a few weeks — and by then no traces left from which the entry route could be read.

We have no backup. What now?

Then we rebuild core and extensions from the original sources and take over from the infected installation only what can be checked: content from the database, images and documents from the upload directory — each after checking for injected code. That is more work than a restore, but it is the route that is reliably clean in the end.

Where did the attack come from, and was it targeted?

In the vast majority of cases it was not targeted. Automated scripts check millions of domains for known weaknesses and strike wherever one is open — an outdated extension, an unprotected installation tool, a weak password. The analysis of the logs shows the route; the question of “who” is usually less important than the question of “how”.

Do we have to report the incident?

If personal data was or may have been affected — customer accounts, orders, form entries — Article 33 GDPR requires notification of the competent supervisory authority within 72 hours; in case of high risk, Article 34 also requires informing the people affected. We provide the technical basis: what was reachable, since when, what was done. The legal assessment is made by you or your data protection officer.

What does emergency help cost?

We bill by effort and assess the situation free of charge in the first conversation. How much work it becomes depends on whether a clean backup exists, how large the installation is and how long the attacker could work unnoticed. We do not quote a flat rate without looking at the system — it would be a guess.

How long until the site is running again?

We tell you after securing the system and a first look at the logs, not before. A clean backup and a small installation are a different situation from a shop without a backup and weeks of infection. What we commit to: emergencies are handled before all other enquiries, and you know at all times which step we are on.

You did not build the site — will you still help?

Yes. Most emergency enquiries concern installations we have never seen before. We need access to hosting and system, then the procedure works regardless of who built the site. Whether you have us support the site afterwards or return to your previous agency is your decision.

Enquiry

What has happened?

The more precise the description, the faster we can assess what we are dealing with. Do not send passwords through this form — we exchange them later by a secure route.

  • An answer from someone who knows the system — no phone queue
  • An assessment before the quote, even when it advises against the project
  • Your details are sent to us by email, not into a third-party CRM

Spam protection: Cloudflare Turnstile — no cookies, no tracking.

Call Start a project