# What to do in the two hours after a compromise

> The very first hours aren't for a deep cleanup, but for stopping the ongoing exploitation and preserving what will later help work out how the intrusion happened. Here's the order to act in, and what's best avoided when rushing.

- Source canonique : [https://allaux.fr/en/securite/que-faire-dans-les-deux-heures](https://allaux.fr/en/securite/que-faire-dans-les-deux-heures)
- Langue : EN
- Dernière mise à jour : 2026-09-30

## Direct answer

> Limit access to the site without wiping evidence, change the hosting and FTP/SSH passwords first, note or copy whatever looks injected before touching it, and wait until you have some idea of the flaw before deleting anything in bulk. A full cleanup is the next step, not this one.

## The sequence for the first two hours

1. **Limit access without cutting everything off** — Switching the site to maintenance mode or blocking public access stops active exploitation. Avoid deleting the hosting account or resetting the server: that can wipe out the access logs you'll need afterwards to work out how the intrusion happened.
2. **Change the server access passwords first** — Hosting, FTP/SSH and database first: these are the credentials that let you regain control if the attacker also captured the CMS admin password. The CMS admin password follows immediately after.
3. **Keep a record before deleting anything** — A suspicious file, a redirect, an unfamiliar admin account: note the exact path, the modification date and a copy if possible, before removing it. That record later helps identify the entry point and confirm it was properly closed.
4. **Check who else has access to the site** — FTP access given to a former contractor, a third-party integration still connected to the admin area: these secondary access points are often forgotten in the rush, even though they can be the real entry point.
5. **Notify the host if other sites could be affected** — On shared hosting, an infection sending mass spam or consuming resources abnormally can affect other customers on the same server; flagging the situation also avoids the account being suspended without warning.

## What not to do when rushing

> Deleting every recent file or anything that "looks off" without knowing which ones are legitimate often means breaking useful customisations while leaving the real backdoor in place, simply because it mimics a known core file name. Wait until you have something to compare against before deciding case by case.

## Why order matters more than speed

Rushing to clean everything at once, before getting a sense of how far the problem goes, often means missing the actual entry point. The site looks clean for a few days, then the infection returns, because the access the attacker used was left open.

Changing some passwords while leaving others unchanged produces the same result: if the FTP password was also captured but only the CMS admin one gets changed, the FTP access stays an open door, invisible from the admin interface.

That's why the sequence here starts with the access points that let you regain full control, before even tackling visible injected content.

## Once things are stable

- **Move on to a full cleanup** — The method, and why restoring a backup isn't always enough. ([/securite/nettoyer-un-site-infecte](/securite/nettoyer-un-site-infecte))
- **Not sure yet it's actually a compromise?** — Four free checks to settle the doubt before going further. ([/securite/verifier-si-mon-site-est-compromis](/securite/verifier-si-mon-site-est-compromis))
- **Stop it happening again** — What needs to change for good once the site is cleaned. ([/securite/se-proteger-apres-un-nettoyage](/securite/se-proteger-apres-un-nettoyage))

## FAQ

### Should I take the site fully offline or just switch it to maintenance mode?

Maintenance mode is enough in most cases, since it blocks public access while keeping the server available for you to work on. Taking it fully offline makes sense mainly if visitors are directly exposed to something dangerous, like a forced download.

### Should I tell my host straight away?

Yes, especially on shared hosting where the infection can affect other customers on the same server. The host may also hold logs or a recent backup that will be useful later.

### Can I restore a backup straight away to save time?

Not in these first two hours. Without knowing how long the infection has been active, the available backup could already contain it. That question belongs to the next step, the full cleanup.

### Should I report it to the authorities right away?

It's not a priority within these two hours: it can happen alongside the first technical actions, once access is secured, without holding up the rest of the process.

### How long do I actually have before things get worse?

There's no guaranteed window. Every hour the site stays active with the flaw still open can be used by the attacker to create further access or extend the infection, which is why limiting access comes first.
