Сайт взломали, посетителей редиректит куда-то ещё — что делать в первый час?

Первым делом скачайте через FTP конфигурационный файл сервера и посмотрите, что внутри. Обычно они прячут среди правил редиректа внешние перенаправления из бессмысленных наборов символов. Если знаете оригинальный вид файла, удалите эти чужие строки и сохраните — хотя бы временно редирект прекратится.

То, что редирект срабатывает только на мобильных и на переходах из поисковика, — классическая проверка источника перехода. Вредоносный код может быть прописан не только в ядровых файлах, но и прямо в таблицах настроек базы данных. Если у вас есть SSH-доступ к серверу, можно просканировать файлы, изменённые за последние 48 часов, и сразу получить список чужих файлов.

Открывая тикет в хостинг-компании, передайте эти три сведения полностью: 1) С какого устройства и источника срабатывает редирект, 2) Первый час и минута, когда заметили инцидент, 3) Есть ли в директориях неизвестные файлы, созданные без разрешения. Так они передадут обращение напрямую в службу безопасности вместо стандартного автоответа.

В прошлом году у нас то же самое случилось с оптовым сайтом во Франкфурте. В панике накатили вчерашний бэкап, а через два часа нас снова взломали, потому что в необновленном плагине форм была уязвимость. Теряли по 2.000 Euro в день. Просто восстанавливать бэкап, не закрыв дыру — вообще не вариант решения.

Примечание: пишу на основе своего опыта, у других может быть иначе.

Были ли на сайте сторонние темы или плагины, которые давно не обновлялись? И еще: у вас виртуальный хостинг (shared) или собственный VPS? Если шаред то очень высока вероятность, что зараза перекинулась с соседнего сайта на том же сервере.

если у хостера есть автобэкап ни в коем случае сразу не перезаписывайте. сначала слейте текущую зараженную копию куда-нибудь в сторонку и иногда вчерашний бэкап который кажется чистым тоже уже заражен, может понадобиться откат минимум на неделю назад.

Поскольку вы работаете на рынке Германии, с точки зрения юридической ответственности крайне важно проверить, произошла ли утечка пользовательских данных. Если есть вероятность доступа к информации клиентов или платежным страницам, у вас может возникнуть обязательство уведомить орган по защите данных соответствующей федеральной земли.

Срочно проверьте Search Console: если во вкладке с проблемами безопасности висит предупреждение, то сразу после чистки нужно будет немедленно отправить запрос на перепроверку.

Отличная работа. Пытаться сделать это в одиночку — самый дорогой путь.

Если напишете результат здесь, это поможет и другим.

Появились три разных мнения, они дополняют друг друга. Автоматический отчет о сканировании и пентест — это не одно и то же.

Давайте разделим понятия, их путают. Меры, принятые без инвентаризации оставляют открытыми двери о которых вы не знаете.

Если не зафиксировать это письменно с самого начала, потом возникнут споры. Пишите, если есть вопросы, отвечу по мере возможности.

У нас было так. Люди защищают не процесс, а привычку. Сопротивление идет оттуда.

Надеюсь это будет полезно.

Слежу за темой.

у нас было так. в общем доступность резервной копии в той же сети и под той же учетнной записью делает ее частью цели атаки.

интересно, есть ли те кто делает иначе.

Краткое резюме для новичков: Доступность резервной копии в той же сети и под той же учетной записью делает ее частью цели атаки.

Конечно, если ваша ситуация отличается, всё меняется.

Я проходил через это, расскажу. Спешка в решениях оборачивается исправлениями через полгода.

Если разрешение и объем тестирования не зафиксированы письменно, тест не начинать. Если напишете результат здесь, это поможет и другим.

Хочу задать вопрос. Большинство инцидентов начинается не с уязвимости, а с украденного пароля.

Исправьте, если я ошибаюсь.

Если пойдете этим путем, сразу решите вот этот вопрос. Начните с небольшого эксперимента, не привязывайте всё сразу.

При принятии решений записывайте и худший сценарий, а не только лучший. Пишите, если есть вопросы, отвечу по мере возможности.