Japanese keyword hack: как я вычистил заражённый сайт

Что видит владелец и что видит Google

Главная особенность этого заражения в том, что владельцу сайта показывать нечего. Страницы открываются, дизайн на месте, формы работают. Заражение показывает себя только поисковому роботу.

Отвечал за это подменённый index.php — единственный файл, через который проходит каждый запрос к сайту. В норме он весит около полутора килобайт. Здесь он весил 16 622 байта, и лишние пятнадцать килобайт были зашифрованным кодом, который делал ровно одну вещь: смотрел, кто пришёл. Если в запросе значился Googlebot, Bing, Baidu или робот Яндекса — или если посетитель пришёл с японского Google, — вместо страницы сайта отдавалась японская страница про сумки и кроссовки со ссылками на чужие магазины.

Приём называется клоакинг: разный ответ разным посетителям. Владелец видит свой сайт, поисковик видит спам, и в выдаче постепенно оказываются сотни страниц, которых на сайте никогда не было.

Как это проявляется

• в Google по запросу site:вашсайт.pl находятся чужие страницы с иероглифами;
• Search Console сообщает о взломе или показывает в отчёте адреса, которых вы не создавали;
• поисковый трафик падает без видимой причины;
• сам сайт при этом работает нормально — именно поэтому проблему замечают поздно.

Что лежало на сервере

Всего я удалил 777 файлов. Это не одна закладка, а обжитая инфраструктура, которую наращивали годами:

• 191 страница-дорвей в формате .shtml. Формат выбран не случайно: сервер выполняет внутри такого файла системную команду, и каждое обращение к дорвею заново создавало на сайте бэкдор. То есть удалить один вредоносный файл было мало — его тут же восстанавливала соседняя страница.
• 576 тестовых загрузчиков во временной папке — по файлу на каждое мыслимое расширение. Так атакующий выяснял, какой тип файла хостинг пропустит.
• 22 панели управления сайтом вида папка/случайное_число/index.php, разбросанные по каталогам.
• Четыре крупные закладки в корне, включая файловый менеджер на 86 килобайт и отдельный маленький файл, назначение которого я объясню ниже, — он оказался самой интересной находкой.
• 8 каталогов-дорвеев, в том числе папка wp-includes — на сайте, который работает не на WordPress. Атака была массовой и неразборчивой: раскладывали всё подряд, что-нибудь да сработает.
• Файлы, замаскированные под ядро системы: лежат среди служебных папок, имеют правдоподобные имена и даже копирайт разработчика в шапке. Глазами по списку файлов такое не находится.

Взломщик защищал свою добычу

Отдельно меня впечатлил .htaccess — файл настроек сервера. Атакующий переписал его так, что выполнение любых PHP-файлов на сайте было запрещено, кроме короткого белого списка. В списке были его собственные закладки.

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

Почему восстановление из резервной копии не помогло

Пока я разбирался, владелец savuk.eu сделал то, что делает большинство: в 9:27 утра восстановил сайт из копии хостинга двухнедельной давности. Закладки декабря 2022 года приехали обратно вместе с ней.

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

Правило простое: резервная копия возвращает содержимое, а не безопасность. Восстанавливать имеет смысл только после того, как найден и закрыт вход, и только с проверкой самого архива.

Самое неочевидное: удалённый файл продолжает работать

Это место, на котором легко сделать неверный вывод и потерять полдня.

Заражённый index.php я заменил на эталонный в 14:13:53. Через семнадцать секунд, в 14:14:10, вредоносный код снова отработал и создал свой служебный файл. Ещё минуту после этого робот Google получал с сайта страницу с девятнадцатью килобайтами японского спама — в то время как обычные посетители видели заглушку «сайт на обслуживании».

Причина не в мистике и не во второй закладке. PHP не читает файл при каждом запросе: он держит в оперативной памяти уже скомпилированную копию (это называется OPcache) и обновляет её не сразу. Пока копия жива, сервер продолжает выполнять код файла, которого на диске больше нет.

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

Вывод для практики: после чистки кеш нужно сбросить принудительно, иначе легко решить, что заражение не убралось, и начать искать несуществующую вторую закладку.

Результат проверяется по логам, а не по списку файлов

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

На savuk.eu до сброса кеша было 62 успешных ответа на спам-адреса, после сброса — ни одного. Вот это и есть доказательство, а не тот факт, что файлы удалены.

Второй обязательный шаг — запросить страницу от имени поискового робота. Клоакинг по определению не виден из обычного браузера, и проверка «я открыл сайт, всё нормально» здесь не работает вообще:

curl -A Googlebot https://вашсайт.pl/

В Windows команду надо набирать как curl.exe: короткое curl в PowerShell означает совсем другое и ключ -A не поймёт.

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

Что я сделал по шагам

1. Снял полный слепок всех подозрительных файлов до удаления — чтобы было с чем сверяться, если что-то вернётся.
2. Перевёл сайт в режим обслуживания, чтобы во время чистки он ничего не отдавал ни людям, ни роботам.
3. Удалил 777 файлов заражения.
4. Заменил index.php на эталонный из дистрибутива системы.
5. Переписал .htaccess: вернул штатные правила, отключил выполнение системных команд внутри страниц, запретил выполнение программного кода в папках для картинок, загрузок и временных файлов. Там он не нужен никогда, а именно туда его и заливают.
6. Принудительно сбросил кеш PHP.
7. Проверил результат по журналам сервера и запросом от имени Googlebot.

Чистка — это половина работы

Удалить файлы недостаточно, потому что вход остаётся открытым. Дальше идёт обязательная часть — она одинаковая для любого заражённого сайта, и без неё всё возвращается:

• сменить все пароли — доступ к файлам, панель хостинга, база данных, администраторы сайта. Пароль от файлового доступа считается скомпрометированным по умолчанию: если он был у атакующего, любая чистка бессмысленна;
• проверить базу данных: не появилось ли лишних администраторов и чужих расширений;
• обновить систему управления сайтом до актуальной версии;
• снести расширения, которые годами никто не обновлял, — это самый вероятный вход;
• разобраться с журналами. На этом сервере, например, лежал файл ошибок на 21 гигабайт, который никто никогда не открывал.

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

Как проверить свой сайт за пять минут

Если нашли — четыре правила

• Не восстанавливайте из резервной копии вслепую. Скорее всего, заражение приедет вместе с ней.
• Сначала пароли, потом файлы. Иначе вы чистите сайт, к которому у чужого человека по-прежнему есть ключи.
• Ищите вход, а не только следы. Удалённая закладка без закрытой дыры возвращается за сутки.
• Проверяйте результат по логам и запросом от робота, а не по тому, что сайт открывается.

И последнее, менее техническое. savuk.eu был заражён почти четыре года, и всё это время он выглядел исправным. Единственное, что мешало заметить проблему раньше, — отсутствие привычки хотя бы раз в квартал заглядывать в Search Console и в журналы сервера. Это бесплатно и занимает десять минут.

Если по своему сайту вы увидели что-то похожее и не хотите разбираться сами — напишите мне, разберёмся. Ответы на частые вопросы про сопровождение сайтов собраны в разделе FAQ.

Виктор Пархимчик, основатель веб-студии IT Deweloper