Для фахівців із кібербезпеки, системних адміністраторів та веб-майстрів злам ресурсу є критичним інцидентом. Проте найгірший сценарій — це компрометація, яка залишається непоміченою місяцями. Зловмисники навчилися монетизувати репутацію легітимних корпоративних сайтів для просування спаму та фішингу так, щоб власники бізнесу не бачили ознак проблеми при звичайному перегляді.
Ця техніка приховування називається клоакінгом (cloaking). Вона дозволяє показувати адміністраторам та аудиторам абсолютно чистий, працездатний сайт, тоді як пошуковим роботам (наприклад, Googlebot) віддається шкідливий контент. У цій статті ми розберемо механіку cloaking, логіку його реалізації на рівні веб-сервера та методику виявлення через Google Search Console (GSC) із подальшим аналізом HTTP-заголовків.
Анатомія cloaking: чому звичайний браузер не бачить злам сайту
Механізм клоакінгу базується на динамічному розділенні контенту на стороні сервера. Коли клієнт надсилає HTTP-запит до веб-сервера, шкідливий скрипт аналізує метадані цього запиту перед генерацією сторінки. Зловмисники налаштовують умовні правила, орієнтуючись на такі параметри:
- User-Agent: Сервер перевіряє, чи містить заголовок запиту сигнатури пошукових роботів (зокрема, Googlebot). Запит від звичайного браузера отримує легітимну сторінку, а запит від пошукового бота — спам.
- HTTP Referer або тип пристрою: Зловмисники налаштовують редиректи, які спрацьовують лише тоді, коли користувач переходить на сторінку з пошукової видачі Google або використовує мобільний пристрій. Якщо адміністратор введе адресу прямо в рядок браузера, шкідливий сценарій не активується.
Згідно з правилами Google Search Central, контент, доданий на сайт без дозволу власника через уразливість, класифікується як «hacked content». У випадку застосування cloaking це найчастіше проявляється у двох формах:
- Content Injection (ін'єкція вмісту): Впровадження прихованих посилань або тексту у легітимні сторінки. Візуально вони невидимі для користувача, але пошуковий робот їх індексує.
- Page Injection (ін'єкція сторінок): Створення зловмисником нових, неавторизованих spam-сторінок на скомпрометованому сайті. При звичайному аудиті CMS таких сторінок може фізично не бути в структурі файлової системи, оскільки вони генеруються «на льоту».
Згідно з дослідженням ENISA Threat Landscape 2025, фішинг залишається одним із ключових векторів для отримання початкового доступу. Після компрометації облікових даних або експлуатації вразливостей зловмисники впроваджують механізми маскування, що робить виявлення зламу без емуляції дій пошукових систем майже неможливим.
Google Search Console як інструмент первинної діагностики інциденту
Хоча Google Search Console є інструментом для роботи з пошуковою видачею, а не повноцінним антивірусним сканером, він діє як ефективний індикатор компрометації (IoC). Оскільки Googlebot сканує сайт ззовні, він може «побачити» те, що приховано від внутрішнього адміністратора.
Головним маркером є звіт Security Issues (Проблеми безпеки). Тут Google відображає попередження про наявність hacked content. Водночас важливо пам'ятати: список URL-адрес у звіті Security Issues часто є неповним. Цей перелік слід розглядати виключно як приклади інфікованих сторінок, а не як вичерпний масив скомпрометованих об'єктів.
Крок за кроком: як виявити розбіжності через URL Inspection Tool
Щоб порівняти відображення сторінки, використовується інструмент URL Inspection. Це дозволяє поглянути на ресурс від імені Googlebot.
Алгоритм перевірки:
- Скопіюйте підозрілий URL зі звіту Security Issues або сторінку, на якій зафіксовано аномальний трафік.
- Вставте адресу в рядок пошуку у верхній частині панелі GSC.
- Натисніть Test Live URL (Перевірити збережену копію) для ініціації запиту в режимі реального часу.
- Після завершення натисніть View Tested Page (Переглянути протестовану сторінку).
- Перейдіть на вкладку HTML. Це точний вихідний код, який ваш сервер згенерував для Googlebot.
- Порівняйте отриманий код із вихідним кодом цієї ж сторінки, відкритої у вашому звичайному десктопному браузері.
Якщо код у GSC містить блоки іноземного тексту, сторонні посилання на сумнівні ресурси або скрипти, відсутні в оригіналі, ви маєте справу з cloaking.
Аналіз HTTP-заголовків та умовних редиректів: де шукати шкідливі правила
Якщо інцидент підтверджено, необхідно локалізувати шкідливий код. Зловмисники найчастіше впроваджують перевірку запитів на рівні конфігураційних файлів веб-сервера або глобальних скриптів CMS.
На рівні веб-сервера (наприклад, у файлі .htaccess для Apache або nginx.conf для Nginx) можуть бути розміщені правила RewriteCond для перевірки HTTP_USER_AGENT на наявність сигнатур googlebot. Якщо правила на рівні сервера відсутні, логіку cloaking найімовірніше реалізовано у файлах ініціалізації додатка (наприклад, index.php). У коді слід шукати функції eval(), base64_decode() та gzinflate(), які часто використовуються для обфускації шкідливих сценаріїв.
Збереження доказів (Evidence Preservation) та локалізація точок ін'єкції
Для розслідування інциденту (incident response) фахівцю необхідно зафіксувати точні HTTP-відповіді сервера до внесення будь-яких змін.
Використовуйте утиліту curl для імітації запиту від імені Googlebot та фіксації HTTP-заголовків (ключ -I):
curl -I -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://your-site.com/suspicious-page
Уважно проаналізуйте статус-код (наприклад, сервер може віддавати 200 OK для сторінок, які в нормальних умовах повинні повертати 404), а також заголовки перенаправлення (Location). Це дозволяє зібрати докази безпосередньої роботи шкідливого коду.
Чому очищення Search Console не дорівнює закриттю вразливості
Типова помилка під час реагування — видалити спам-файли та обмежитися запитом на перевірку в GSC. Попередження у Google Search Console є лише симптомом компрометації. Якщо ви усунули наслідки, але не закрили структурну вразливість бекенду (наприклад, залишили застарілий плагін чи скомпрометований доступ), зловмисники автоматично відновлять скрипти cloaking.
Згідно з Cisco Cybersecurity Readiness Index 2025, лише 27.7% організацій мають достатній рівень готовності до сучасних кіберзагроз. Побудова стійкого захисту вимагає комплексного підходу, а не простої реакції на попередження пошукової системи.
Для бізнесів, що потребують не просто точкового очищення CMS, а побудови стійкої інфраструктури, консорціум Intecracy Group пропонує послуги з комплексного аудиту кібербезпеки та впровадження процесів безпечної розробки (DevSecOps) силами спеціалізованих команд, зокрема Softengi. Це дозволяє забезпечити проєктування захищених архітектур та проактивне усунення структурних вразливостей веб-ресурсів.
Алгоритм перевірки та фіксації cloaking на скомпрометованому сайті
| Етап перевірки | Технічна дія | Очікуваний результат |
|---|---|---|
| Первинний моніторинг | Перевірка звіту Security Issues у GSC для отримання прикладів скомпрометованих URL. | Локалізація ознак hacked content. |
| Порівняння рендерингу | Запуск URL Inspection Tool та аналіз HTML-коду сторінки, згенерованого для Googlebot. | Виявлення неавторизованих посилань чи ознак page injection. |
| Емуляція запитів | Виконання запиту з підробленим User-Agent ('Googlebot') через утиліту curl. | Збереження доказів (заголовків і тіла відповіді) для розслідування. |
| Аналіз маршрутизації | Ревізія файлів конфігурації веб-сервера (.htaccess, nginx.conf) на предмет умовних редиректів. | Виявлення шкідливих правил перенаправлення. |
| Аудит коду додатку | Пошук функцій обфускації (наприклад, base64_decode, eval) у вихідному коді CMS. | Знаходження та видалення бекдорів на рівні файлової системи. |
Пам'ятайте, що ефективне реагування на інциденти включає повний цикл: від виявлення за допомогою засобів GSC та фіксації доказів до усунення першопричини (root cause analysis) та перегляду архітектури безпеки.
Поширені питання
Як перевірити сторінку сайту від імені Googlebot без Search Console?
Це можна зробити за допомогою термінала та утиліти curl, змінивши заголовок User-Agent. Наприклад: curl -A "Mozilla/5.0 (compatible; Googlebot/2.1; +http://www.google.com/bot.html)" https://your-site.com/. Також можна використати інструменти розробника в браузері (DevTools), увімкнувши емуляцію мережевих умов.
Чому після видалення шкідливого коду Google все одно показує попередження про злам?
Google Search Console не оновлюється в реальному часі після локальних змін на вашому сервері. Після повного очищення сайту та закриття вразливості необхідно зайти у звіт Security Issues і надіслати запит на повторну перевірку (Request Review). Процес перевірки пошуковими системами може тривати кілька днів.
Як зловмисники налаштовують редиректи тільки для мобільних користувачів з пошуку?
Механізм базується на перевірці двох HTTP-заголовків: HTTP_REFERER (щоб визначити, що перехід відбувся з google.com, bing.com тощо) та HTTP_USER_AGENT (наявність сигнатур мобільних пристроїв, таких як Android чи iPhone). Якщо обидві умови збігаються, серверний скрипт або конфігурація веб-сервера примусово повертає HTTP-статус перенаправлення на цільовий спам-ресурс.
Джерела даних
- Google Search Central: Security issues report: hacked content
- Google Search Central: Spam policies: hacked content and cloaking
- ENISA Threat Landscape 2025
- Cisco Cybersecurity Readiness Index 2025
- NIST: Artificial Intelligence Risk Management Framework (AI RMF 1.0)
- FCC First Caller ID Authentication Report and Order