A hacked site rarely looks hacked. A defacement with a message on the homepage is rare: whoever got access wants to keep it as long as possible. Below are nine symptoms you can spot without special tools.
The signs
1. The search engine shows pages you never created. Checked with a
site:yourdomain.ru query in Yandex and Google. Pages about casinos, loans, and
diplomas on a corporate site are a classic. They are deliberately hidden from
direct visitors and shown only to crawlers.
2. The browser warns of danger. Safe Browsing and Yandex flags appear before you notice anything yourself.
3. Emails from the domain go to spam. A compromised server is often used for mailings, and the domain lands on blacklists. You can check the reputation through MXToolbox.
4. Traffic grew for no reason. Especially at night and from a single region.
5. Unknown users have appeared in the admin panel. Or a known one has had their role changed.
6. Files changed without your involvement. A fresh modification date on files nobody has touched in six months. The first candidates to check are the index files and the configuration.
7. The site got slower. A miner or a mailer eats up the CPU.
8. Strange requests flicker in the web-server logs. Hits to files with names
like wso.php, shell.php, series of POST requests to one address, attempts to
open .env and .git/config.
9. Users complain about redirects. Often set up so the redirect fires only on mobile and only when arriving from search, so the site owner never sees it.
The first hour
Minutes 0 to 10. Capture the state. Before fixing anything, take a copy: files and database as they are. This is evidence and the only way to work out later how they got in. Restoring from a backup on top wipes the traces, and you get hacked a second time the same way.
Minutes 10 to 20. Isolate. Close the site behind a stub, restrict access to the admin panel by address, turn off mail sending. The goal is to stop harm to third parties while you sort things out.
Minutes 20 to 40. Change everything. Administrator passwords, the database password, API keys, hosting and registrar-panel access, SSH keys. Separately, invalidate the active sessions: changing a password without this leaves the attacker inside.
Minutes 40 to 60. Find the entry point. Look at the logs for the day before the first symptoms appeared. Look for: successful admin logins from unfamiliar addresses, file uploads, requests with signs of injection, hits to files you do not have.
What not to do
Do not restore a backup as your first action. If the vulnerability sits in the code, you will restore it along with the site.
Do not delete suspicious files without saving them. They will be needed to understand the mechanism.
Do not stop at cleaning. A web shell is rarely alone. Until the entry point is found, the site stays open.
If user data leaked
Here 152-FZ kicks in, along with the duty to notify the regulator. The deadlines are short and count from the moment of discovery. The procedure and the forms of notification are best checked against the current edition: the requirements have changed several times in recent years.
In parallel, prepare a message to users: what data is affected, what has already been done, what they should do. Silence costs more than the leak itself.
How to lower the odds
- CMS and library updates on a schedule, not on a whim.
- Two-factor authentication in the admin panel.
- Separate accounts instead of one shared "for everyone" password.
- Backups on separate storage the site has no write access to.
- File-integrity monitoring with notifications on changes.
- Regular vulnerability checks, at least with an automated scanner.
The last item costs less than any of the recovery scenarios listed above.