Взломанный контент: что на самом деле происходит, когда скомпрометирован сам сайт, а не рекламодатель
Первый признак редко приходит от кого-то официального. Это несколько странных адресов в Search Console, создание которых никто в команде не помнит, или органический трафик, падающий без видимой причины в обычных панелях, или рекламодатель, который пишет с вопросом, почему страница его объявления перенаправляет на что-то, не имеющее отношения к сайту. Иногда это посетитель, сообщающий, что браузер отказался открывать страницу. Ничто из этого не похоже на мошенничество рекламодателя, и ничто не похоже на случай с вредоносной рекламой, из-за которой сайт помечают, хотя его собственный код тут ни при чём.
Это другой случай, и это другая проблема с другим решением. Здесь что-то было действительно добавлено в файлы или базу данных сайта без того, чтобы кто-то из команды это туда положил. Каталог объявлений этой категории не может позволить себе выглядеть ненадёжным даже неделю: ни перед Google, ни перед платёжным процессором, который уже относится к этой отрасли как к более рискованной, чем в среднем, ни перед хостингом, которому, возможно, достаточно одной жалобы, чтобы приостановить аккаунт. Точно знать, что произошло, что именно проверяет Google и в каком порядке решение действительно работает, стоит здесь дороже, чем для блога обычного малого бизнеса, потому что цена неправильного порядка выше.
Как злоумышленник на самом деле проникает внутрь, и это редко бывает эффектно
На этом уровне почти никто не целится конкретно в каталог объявлений для взрослых. Обычная схема это бот, прочёсывающий открытый интернет в поисках любого сайта с определённым программным обеспечением, имеющим известную, неисправленную уязвимость, точно так же, как он прочёсывает сайты ресторанов или блоги юридических фирм. По сайту бьют потому, что он случайно работает на той же CMS, том же плагине или той же устаревшей библиотеке, что и миллион других сайтов, а не потому, что кто-то его рассмотрел и решил, что он стоит усилий.
Устаревшее программное обеспечение это реальный и распространённый фактор, но не вся история, и если относиться к нему как ко всей истории, половина реальных точек входа останется без защиты. Отчёт Sucuri о взломанных сайтах, касающийся сайтов, очищенных в 2023 году, показал, что 39,1% скомпрометированных CMS-установок на момент заражения работали на устаревшем ПО, что ниже 50,58% годом ранее. Тот же отчёт обнаружил, что лишь около 14% этих сайтов всё ещё имели идентифицируемый уязвимый плагин или тему к моменту, когда Sucuri внимательно изучила устранение последствий. Иными словами, большинство очищенных сайтов на самом деле были взломаны не через ту программную уязвимость, которую оператор ожидал бы исправить в первую очередь.
Вторая половина картины это учётные данные. Отчёт Verizon Data Breach Investigations Report за 2025 год, рассматривающий все отслеживаемые отрасли, а не только сайты, обнаружил, что украденные или угаданные учётные данные немного опережают эксплуатируемые уязвимости ПО как способ, которым злоумышленники получают первую точку опоры: 22% взломов против 20%. Это не цифра, построенная исключительно на сайтах объявлений, но она совпадает с тем, что Sucuri наблюдает при очистке именно CMS-платформ. Пароль администратора, повторно использованный из личной почты, утёкшей при не связанном с сайтом инциденте годами ранее, на практике является путём внутрь примерно столь же вероятным, как непропатченный плагин.
Практический вывод в том, что защита сайта это работа на двух примерно равных по весу направлениях, а не на одном. График обновлений закрывает половину программных брешей. Отдельная дисциплина в отношении того, у кого есть доступ, какой на самом деле у него пароль и используется ли он повторно где-то ещё, закрывает вторую половину. Оператор, который только поддерживает плагины в актуальном состоянии, сделал половину работы и может никогда этого не заметить, потому что экран предупреждения выглядит одинаково независимо от того, какая половина была пропущена.
Как это на самом деле называет Google и почему это другая проблема, чем вредоносная реклама
Другой вид предупреждения Chrome уже рассматривался здесь: случай, когда подрядная рекламная сеть показывает обманчивый или вредоносный креатив через собственные рекламные места сайта, и Google помечает сайт за контент, которого он никогда не касался. Это не тот случай. Здесь что-то было добавлено на страницы или в базу данных сайта без ведома оператора, а это именно то, что антиспам-политики Google определяют как взломанный контент: контент, размещённый на сайте без разрешения владельца из-за уязвимости в собственной безопасности сайта.
Документация Google выделяет три конкретных паттерна. Внедрение кода это вредоносный код, обычно JavaScript, добавленный непосредственно в уже существующие страницы или iframe. Внедрение страниц это новые страницы, добавленные на сайт, которых раньше не было, созданные для манипулирования поисковым ранжированием или для фишинга, в то время как страницы, которые посетитель уже знал, часто не показывают видимых признаков того, что что-то не так. Внедрение контента ещё тоньше: скрытый текст или ссылки, добавленные на существующие страницы с помощью трюков CSS или HTML, видимые поисковому роботу, но не человеку, смотрящему ту же страницу в браузере.
Внедрение страниц обычно тот паттерн, который операторы обнаруживают последним, и стоит понять, почему злоумышленник утруждает себя этим вместо того, чтобы просто создать собственный одноразовый сайт. Домен, у которого уже есть история, существующие обратные ссылки и устоявшаяся позиция в результатах поиска, отмывает спам-контент в ранжировании гораздо быстрее, чем это сделал бы совершенно новый домен, поэтому злоумышленники предпочитают заимствовать репутацию существующего сайта, а не выстраивать собственную с нуля. Это другой механизм, нежели рассмотренная в другой статье внешняя атака через ссылки: там атака направляет ссылки с других сайтов на цель извне; здесь спам-страницы созданы так, чтобы жить на собственном домене цели, внутри её собственной файловой структуры.
Как только этот контент появляется на сайте, последствия накапливаются. Отчёт о проблемах безопасности в Search Console напрямую помечает ресурс, некоторые страницы могут быть исключены из результатов или заменены предупреждением в листинге, а Safe Browsing в Chrome может начать показывать посетителям тот же красный межстраничный экран, уже описанный для случая с рекламной сетью, на этот раз из-за того, что сайт действительно размещает вредоносный или обманчивый контент, а не из-за недобросовестного креатива, проходящего через него.
Снятие предупреждения: порядок действий, который действительно работает
Собственное руководство Google конкретно в отношении порядка, и большая часть времени, теряемого на практике, уходит именно из-за выполнения этих шагов не в той последовательности. Первая задача найти и удалить каждый экземпляр внедрённого контента, а не только образец страницы, которую Search Console привёл в качестве примера проблемы. Этот адрес это образец, а не полный перечень, и очистка, останавливающаяся после его исправления, обычно оставляет на месте большую часть реального внедрения.
Вторая задача выяснить, как злоумышленник проник внутрь, и закрыть именно эту брешь, будь то непропатченный плагин, утёкшие учётные данные или неверно настроенное разрешение, потому что удаление спам-страниц без устранения точки входа просто обнуляет счётчик до тех пор, пока тот же злоумышленник или то же автоматическое сканирование не вернётся через ту же дверь. Документация Google прямо говорит, что исправление должно охватывать весь сайт, а не только главную страницу или страницу, о которой сообщил посетитель, и связанная часть того же руководства рекомендует сменить все пароли, привязанные к учётной записи с правами администратора: вход в CMS, панель управления хостингом, FTP или SFTP и базу данных, именно потому, что точка входа часто одна из них, а не страница, на которой проявился симптом.
Чаще всего операторы путают именно момент, когда просить Google проверить заново. Запрос на проверку до того, как описанная выше очистка действительно завершена, ничего не ускоряет; Google прямо говорит, что запрос проверки, пока проблема ещё существует, лишь продлевает время, в течение которого сайт остаётся помеченным. Сроки проверки варьируются по категориям: проверка простого вредоносного ПО обычно занимает несколько дней, фишинга около дня, а проверка взломанного контента, включающего внедрённые спам-страницы, может занять до нескольких недель, потому что Google относится к этой категории как к той, что может потребовать действительно ручного рассмотрения, а не автоматической повторной проверки.
Повторное появление того же предупреждения после того, как проверка уже была пройдена, обычно означает, что точка входа на самом деле так и не была закрыта в первый раз, был устранён только симптом. Удаление видимых спам-страниц создаёт ощущение завершённой работы, но если уязвимый плагин всё ещё на месте или утёкший пароль всё ещё работает, та же брешь используется снова, иногда в течение нескольких дней после снятия предупреждения.
Что на самом деле это предотвращает при бюджете, который этот бизнес способен нести
Ничто из этого не требует найма выделенной команды безопасности, и операторы, пропускающие базовые меры, обычно делают это потому, что список кажется длиннее, чем есть на самом деле. CMS, его тема и каждый установленный плагин нуждаются в фиксированном графике обновлений, проверяемом еженедельно, а не "когда будет время", а всё, что было установлено однажды и больше не используется, следует полностью удалить, а не оставлять в спящем состоянии, потому что неактивный плагин остаётся дверью, которую так и не заперли.
Дисциплина в отношении учётных данных весит столько же, сколько и патчи, учитывая то, что на самом деле показывают приведённые выше цифры Sucuri и Verizon. Это означает уникальный пароль для каждой учётной записи, способной затронуть сайт, сгенерированный и хранящийся в менеджере паролей, а не в памяти, двухфакторную аутентификацию, включённую для каждого входа, где она предлагается, и отсутствие общих логинов, передаваемых между сотрудниками или модераторами, поскольку общий логин это ещё и доступ, который нельзя проследить до конкретного человека, когда что-то идёт не так.
Резервные копии важны не меньше профилактики, потому что именно они возвращают сайт в сеть за часы, а не заставляют ждать проверку Google, которая может длиться неделями. Резервная копия, хранящаяся на том же хостинг-аккаунте, что и сайт, который она должна защищать, не такая уж хорошая резервная копия, поскольку злоумышленник с правами администратора обычно может добраться и до неё; копия, хранящаяся отдельно и действительно проверенная хотя бы одним восстановлением, а не оставленная работать без проверки, это разница между плохой неделей и плохим месяцем.
Последний элемент это просто узнать обо всём рано. Собственные email-оповещения Search Console доставляют отчёт о проблемах безопасности в почтовый ящик, который кто-то действительно читает, вместо того чтобы оператор узнавал о проблеме из жалобы посетителя или по медленному оттоку органического трафика спустя дни или недели. Ни один из этих шагов не стоит больше времени, и все они обходятся дешевле, если сделаны сейчас, а не после того, как экран предупреждения уже стоил неделю трафика, пока улаживается очистка.
Порядок действий, если предупреждение уже появилось: сначала очистить всё, закрыть конкретную брешь, которая это допустила, и только потом просить Google проверить заново, никогда не наоборот. Порядок действий, если ещё ничего не произошло: всё равно сделать те же четыре вещи по графику на этой неделе: обновить установленное, сменить все пароли с правами администратора, включить двухфакторную аутентификацию везде, где она предлагается, и протестировать реальное восстановление из резервной копии. В любом случае решение никогда не было вопросом юрисдикции сертификата или размера нанятой юридической фирмы: это вопрос того, кто может войти в систему, насколько актуально программное обеспечение и заметил бы кто-нибудь это вовремя.
