Compromised Site та Malicious Software: Повний гайд по системі детекції та виживання

Compromised Site та Malicious Software: Повний гайд по системі детекції та виживання

Коли Google виносить вердикт, що сайт «небезпечний», це майже завжди означає одне: система побачила патерни, які збігаються з поведінкою фішингу, шахрайських воронок або поширення шкідливого ПЗ. Система не намагається зрозуміти, що ви там реально запускаєте. Вона фіксує ризик і ставить стоп.

З 2025 року за детекцію відповідає не просто «алгоритм» — це моделі Gemini, які аналізують сотні мільярдів сигналів одночасно: вік акаунта, поведінкові патерни, структуру кампаній, контент лендингу. Система оцінює намір, а не просто факт порушення. І якщо намір виглядає підозріло — акаунт відлітає, навіть якщо на ленді формально все чисто.

У 2025 році Google заблокував 8,3 млрд оголошень і призупинив 24,9 млн акаунтів. Цифри виросли, точність теж — некоректних суспендів стало на 80% менше, ніж роком раніше. Це означає, що випадково зняти бан через апеляцію стає дедалі складніше. Якщо прилетіло — найімовірніше, система має рацію.

Звучить жорстко, але є плюс. Такі бани можна зняти, якщо розуміти, які сигнали реально запускають фільтри. Частина тригерів технічна, частина поведінкова, і більша частина — автоматична. Ми розберемо кожен, щоб ви розуміли, що відбувається під капотом і як мінімізувати ризик.

🔍 Compromised Site — як система вирішує, що сайт «битий»

Що Google реально вважає скомпрометованим сайтом

У політиці все звучить акуратно: сайт зламаний, підмінений або заражений. У реальності ж Compromised Site — це автоматичний фільтр, який реагує на будь-які аномалії в коді, структурі та інфраструктурі. Система не намагається зрозуміти наміри власника. Вона порівнює сайт із мільйонами патернів шкідливих сторінок і вішає флаг, якщо сигналів занадто багато.

Щоб розкласти це по поличках, дивимось на п’ять основних шарів, які аналізує Google.

📡 Основні технічні тригери Compromised Site

Вихідний код — система перевіряє структуру HTML, CSS, JavaScript на наявність обфускованого коду, зашифрованих функцій, інлайн-скриптів, редиректів.

Поведінка сторінки — трекінг того, як сторінка взаємодіє з браузером (popup’и, зміна DOM, редиректи, спроби доступу до системних ресурсів).

Репутація домену — перевірка всіх доменів на одному IP, WHOIS-дані, вік домену, історія використання.

Контентні елементи — структура сайту, наявність тексту, меню, соцмереж, політики конфіденційності.

Інфраструктура — відкриті порти, неправильна конфігурація сервера, невстановлені SSL-сертифікати, спільний хостинг із підозрілими доменами.

📍 Реальні причини бану Compromised Site у сірих схемах

🔧 Cloudflare та автоінʼєкції скриптів

Cloudflare у 2023 році почав додавати на proxied-домени свої Beacon-скрипти. Google читає ці вставки як невідомий трекер і відносить сторінку до потенційно шкідливих.

Що потрібно вимкнути:

  • Email Obfuscation
  • Web Analytics / Beacon

Де:
Cloudflare Dashboard → Analytics & Logs → Web Analytics → Manage site → Disable → Update

Важливий момент: після вимкнення обов’язково скидай кеш Cloudflare вручну, інакше скрипт продовжує інжектитися ще кілька годин, навіть якщо опція вже вимкнена. Це підтверджений баг, а не фіча.

🏚 Домен із «брудною» історією

Google зберігає репутацію кожного домену. Старі фішингові або заражені зони майже завжди викликають Compromised Site навіть при повністю білому контенті.

Що перевірити:

  • VirusTotal (history)
  • Archive.org (контент)
  • Safe Browsing API
  • Sucuri
  • URLVoid

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

🧩 Повтор одного вайта на кількох доменах

Google порівнює DOM-структуру та JS-патерни. Один і той самий майндмап на 10 доменах виглядає як масова генерація.

Що змінюємо:

  • 40% контенту
  • Структуру блоків
  • CSS-класи
  • Сет JS-функцій
  • SVG, кольори, мікроелементи

Працює просто: менше повторів — менше ризику.

🎨 Креативи-близнюки в рекламних кампаніях

Система навчена на візуальному аналізі. Якщо креативи однакові, Google пов’язує кампанії в одну мережу.

Що впливає:

  • Стиль тексту
  • Кольорові патерни
  • Сітка банера
  • Структура посадкової

Змінюй хоча б деталі: кнопку, фон, формулювання.

🌐 Дешеві та токсичні TLD

Історично .xyz, .top, .site, .tk та інші дешеві зони використовувались у шкідливому ПЗ. Google реагує жорстко.

Рівень ризику TLD:

  • .com / .org / .net — низький
  • Гео-зони — низький
  • .io / .co — середній
  • .xyz / .site / .top — високий
  • безкоштовні — критичний

Працювати можна, просто готуй домен ретельніше.

🔌 Проксування та відкриті трекери

Google аналізує мережеве оточення: IP, DNS, SSL, куди йде трафік. Якщо один IP обслуговує старі домени, трекери та поточний проєкт — ризик високий.

Технічні правила:

  • Різні IP під різні проєкти
  • Чистий SSL
  • Без «переадресацій у нікуди»
  • Без зайвих сервісів на одному вузлі

🛠 Помилки в серверній конфігурації

Google Transparency Report бачить технічні вразливості.

Що потрібно закрити:

  • Зайві порти
  • FTP
  • Admin-панелі
  • Індексацію системних директорій
  • Відсутність SSL

Базовий сетап:

  • SSH: тільки ключі
  • UFW: відкриті 80/443
  • SFTP замість FTP
  • SSL обов’язковий
  • Приховати адмін-доступ

🕷 Шкідливі скрипти, майнери та підозріла поведінка

Google аналізує JS і мережеві запити. Будь-які дивні звернення вважаються шкідливими.

Перевірки:

  • Safe Browsing
  • VirusTotal для JS
  • Lighthouse
  • DevTools Network
  • Sucuri Malware Scan

Якщо код чистий, бан майже завжди пов’язаний з інфраструктурою або доменом, а не з самим лендингом.

✅ Чеклист, щоб не словити Compromised Site

Усе, що тут перелічено, реально знижує ризик, тому що закриває основні сигнали Safe Browsing і Policy Risk.

🧭 Перед запуском домену

Доменна перевірка

  • VirusTotal — перевірка історії
  • WHOIS — інформація про реєстрацію, авторитетний провайдер
  • Archive.org — старий контент, сліди попереднього використання
  • Google Safe Browsing — поточний статус безпеки

Інфраструктура та хостинг

  • Виділений IP
  • Коректний SSL-сертифікат — Let’s Encrypt повністю підходить, криптографічно він рівний платному. Різниця між ними — лише в OV/EV-валідації юридичної особи, що для рекламних лендингів ролі не грає. Головне — налаштувати автооновлення через certbot, щоб сертифікат не протух у найневідповідніший момент.
  • Домени .com, .net, .org або регіональні TLD
  • Хостинг на стабільних провайдерах (Hetzner, Linode, DigitalOcean, Vultr)

Уточнення щодо Hetzner: частина німецьких IP Hetzner має задокументовані блокування з боку Google Cloud Platform — через сусідів по хостингу, які потрапили під санкційні обмеження. Це не масова історія, але конкретний IP перед деплоєм варто прогнати через VirusTotal та IPVoid. Якщо є флаги — запроси зміну IP у провайдера.

Підготовка коду

  • Прибрати будь-які зайві скрипти
  • Перевірити JS-файли через VirusTotal
  • Очистити від обфускованого коду
  • Прибрати popup-елементи та автоматичні редиректи

Контент і структура сторінки

  • Унікальний текст від 500 слів
  • Адекватне меню та робочі розділи
  • Соцмережі (можна підставні, але такі, що відкриваються)
  • Контактна форма або номер
  • Privacy Policy + Terms
  • Нормальна мобільна адаптація

Базовий SEO-фундамент

  • sitemap.xml
  • robots.txt
  • meta description + og-теги
  • Внутрішня перелінковка

Фінальне сканування

  • Google Mobile-Friendly Test
  • Lighthouse у DevTools (бажано score вище 50)
  • Sucuri Site Check
  • URLVoid — перевірка репутації в багатьох рушіях

🔥 Malicious Software — технічний аналіз і обхід

Що Google має на увазі під «Malicious Software»

За формулюванням Google це програмне забезпечення, яке може нашкодити пристрою або даним користувача.

На практиці Malicious Software — це більш точковий бан, який реагує на конкретні категорії шкідливого коду.

Що зазвичай потрапляє під детекцію:

  • Spyware збирає дані без згоди
  • Трояни приховано передають інформацію
  • Keylogger-скрипти перехоплюють введення
  • Dialer-модулі можуть ініціювати дзвінки або SMS
  • Malvertising-елементи впроваджують неконтрольовану рекламу
  • Небезпечні файли на кшталт .exe, .msi, .bat, доступні для завантаження
  • Приховані редиректи на заражені ресурси

Google фіксує такі сигнали через Safe Browsing і перевірку поведінки сторінки. Навіть одиничний підозрілий файл або скрипт може викликати спрацювання.

🔍 Механізм детекції Malicious Software

Google дивиться на сайт кількома рівнями. Логіка проста: якщо щось схоже на шкідливий код, фільтр спрацьовує одразу.

🧪 Статичний аналіз файлів

Тут система просто читає код як є.

  • скрипти відправляються у VirusTotal
  • перевірка йде по десятках рушіїв одночасно
  • якщо кілька рушіїв дають підозру — ставиться флаг

⚙️ Динамічний аналіз у sandbox

Google запускає скрипти у своєму sandbox-середовищі та дивиться на поведінку.

Тригери такі:

  • спроби звернення до document.cookie
  • відкриття нових вкладок
  • робота з localStorage
  • спроби перехоплювати клавіші

🌐 Репутаційний рівень

Система вивчає оточення сайту.

  • домени, на які йде трафік
  • публічні дані про домени
  • історію IP та його репутацію

Якщо є перетини зі шкідливою інфраструктурою — сайт потрапляє під підозру.

🧩 Контентний аналіз

Google звіряє код і візуальну частину.

  • знаходять обфусковані шматки
  • шукають аномально важкі JS-файли
  • порівнюють оригінальний розмір із мініфікованим

Занадто велика «вага» без причин — один зі стандартних червоних прапорів.

⚠️ Практичні тригери Malicious Software

🟡 Трекери без маскування

Якщо трекер стоїть у лоб, Google бачить його одразу.

<img src=”https://tracker.example.com/pixel.php?uid=123&data=xyz”>

<script src=”https://analytics.example.com/track.js”></script>

Що фіксує система:

  • зовнішній домен, не пов’язаний із сайтом
  • передача даних третій стороні
  • ключові слова на кшталт track, analytics, pixel

Щоб прибрати ризики, трекери потрібно ховати.

Робочі варіанти:

1. Трекер на піддомені основного сайту
track.domain.com → фактично вказує на track-server.realtracker.com

2. Пропускати запити через Service Worker
SW приймає запит → браузер не бачить зовнішній URL

3. Використовувати backend-proxy + FirstParty Cookies
Бекенд відправляє дані на трекер, для браузера все виглядає як запит до origin

🟠 Обфускований JavaScript

Google дуже чутливо реагує на зашифрований JS. Якщо в коді трапляється щось на кшталт:

var _0x4e2a=[‘obfuscated’,’code’,’here’];

var _0x3f9c=function(_0x4e2a){…};

_0x3f9c(_0x4e2a);

Google такі конструкції не любить, навіть якщо вони безпечні — сам факт обфускації вже створює підозру. Усе тому, що шкідливий код майже завжди ховають під обфускованими функціями, щоб обійти антивіруси.

Як уникнути проблем:

  • не використовувати обфускатори (Uglify, Terser) для бойових доменів
  • обмежитися мініфікацією без зміни імен змінних
  • тримати продовий код прозорим

🔵 Авто-скрипти Cloudflare

Окрім Web Analytics часто спрацьовує Email Obfuscation. Cloudflare обгортає e-mail у JavaScript, який розшифровує email при кліку. Виглядає це так:

<!– Вихідний HTML –>

<a href=”mailto:[email protected]”>[email protected]</a>

<!– Після обробки Cloudflare –>

<a href=”/cdn-cgi/l/email-protection#…”>[email protected]</a>

<script>/* decryption code */</script>

Google реагує на це не завжди, але такі скрипти можуть потрапити під підозру, тому що:

  • запускаються без дії користувача
  • змінюють поведінку сторінки через додатковий JS
  • передають дані на сервіси Cloudflare

Для системи це виглядає як зайвий шар активності, який не пояснюється логікою сайту.

Найкраще рішення — вимкнути Email Obfuscation у Cloudflare Dashboard.

🟣 Вбудовані редиректи

Деякі редиректи виглядають для Google як фішингові. Класичний приклад:

setTimeout(() => {

  window.location = ‘https://some-external-site.com?utm=’ + document.referrer;

}, 2000);

Google реагує на затримку, передачу referrer’а та редирект на зовнішній домен.

Безпечний варіант:

document.getElementById(‘btn’).onclick = () => {

  window.location = ‘https://target-site.com’;

};

Або перенаправлення через 301 на сервері.

🟢 Агресивні popup’и

Під удар потрапляє все, що заважає користувачу:

  • Autoplaying popup’и
    З’являються самі, без кліку. Система вважає це нав’язливою поведінкою та фіксує ризик.
  • Hard-to-close popup’и
    Хрестик захований, зменшений або реагує через раз.
  • Множинні popup’и підряд
    Один закрив — і одразу прилітає другий. Виглядає як сценарій тиску на користувача.
  • Fullscreen popup’и
    Екран перекритий повністю, можливо лише «прийняти» або «погодитися».

Такі елементи система відносить до «potentially deceptive user experience», і вони часто потрапляють під Malicious Software.

🔴 Приховані iframe’и

<iframe src=”https://external-tracker.com/collect” style=”display:none; width:0; height:0;”></iframe>

Прихований iframe — стандартний індикатор шкідливої активності.

🟤 Скрипти, які запитують чутливі дозволи

// Запит геолокації без контексту

navigator.geolocation.getCurrentPosition(pos => {

  console.log(pos);

});

// Доступ до камери або мікрофона

navigator.mediaDevices.getUserMedia({ video: true, audio: true })

  .then(stream => console.log(‘ok’));

// Запис великих обсягів даних у localStorage

localStorage.setItem(‘huge_data’, new Blob([bigArrayBuffer], { type: ‘application/octet-stream’ }));

Такі запити допустимі у вебзастосунках, але на стандартному вайті вони виглядають зайвими та створюють відчуття підозрілої поведінки скриптів.

⚫ Небезпечні файли на сервері

Будь-які формати для завантаження на кшталт:

  • .exe
  • .msi
  • .bat
  • .cmd
  • .scr
  • .zip / .rar з виконуваними файлами
  • .pdf із вбудованими скриптами

Google це знайде та заблокує домен.

🧭 Чеклист, щоб не словити Malicious Software

🔍 Аудит JavaScript

  1. Прогнати весь JS через VirusTotal
  2. DevTools → Network → відстежити запити
  3. DevTools → Application → перевірити cookies, localStorage
  4. Пошук патернів: eval(), btoa(), encrypt, obfuscate

Якщо щось виглядає дивно — змінюємо або видаляємо одразу.

🔐 Перевірка трекерів

  • трекери мають іти тільки через піддомени
  • Service Worker або backend-proxy для приховування реального URL
  • жодної передачі особистих даних у відкритому вигляді

🔁 Редиректи

  • редирект тільки після дії користувача
  • без setTimeout / setInterval перед переходом
  • бажано 301/302 редирект на сервері

💬 Popup-контроль

  • прибрати autoplaying
  • кнопка «закрити» має бути помітною (не менше 20px)
  • максимум один popup за сесію

🧱 iframe

  • видалити всі приховані iframe (display:none, width:0, height:0)
  • якщо iframe потрібен — він має бути видимим і мати зрозумілу функцію

🧪 Фінальна перевірка

  • Sucuri Malware Scan (повне сканування)
  • VirusTotal (завантажити файли вручну)
  • Google Safe Browsing API (перевірити статус домену)
  • Lighthouse у DevTools
  • Google Search Console → Security Issues (детальніше, ніж просто Safe Browsing)
  • Google Ads → Ads Advisor: поставити запитання «Чому мої оголошення відхилені?» прямо в інтерфейсі

🔗 Чому Compromised Site та Malicious Software можуть прилетіти разом

Ці два бани часто йдуть парою, тому що Google перевіряє їх за однаковими технічними сигналами. Якщо сайт виглядає ризикованим за загальною структурою, система фіксує обидва порушення одразу.

До типових збігів належать:

  • обфускований код
  • приховані редиректи
  • трекери, які виглядають підозріло
  • аномальна поведінка JS

Коли прилітають обидва бани, це майже завжди говорить про проблему в усій архітектурі сайту. Один виправлений файл ситуацію не змінює — потрібно розбиратись у загальному наборі сигналів, які сайт віддає системі безпеки.

📨 Як подавати апеляцію і що реально працює

Раніше можна було написати «ми все виправили» і чекати. Зараз автоматична система перевіряє конкретику — і без неї просто відхиляє.

Що потрібно додати до апеляції по Compromised Site:

  • Список видалених файлів з іменами та шляхами
  • Серверні логи за останні 30 днів — без слідів несанкціонованого доступу
  • Скриншот Google Search Console → Security Issues з нулем загроз
  • Копію SSL-сертифіката

Порядок дій — двоетапний:

  1. Спочатку подаєш апеляцію через Google Search Console, щоб зняти флаг Safe Browsing з домену
  2. Потім — окремо через Google Ads → Policy Manager → Appeal, прикріплюючи ті самі докази

Без першого кроку другий майже завжди не проходить. Система не побачить чистий домен, поки Safe Browsing не зняв свій флаг.

Хороша новина: з листопада 2025 Google розглядає 99% апеляцій протягом 24 годин. Якщо відхилили — не відправляй повторно одразу. Кожна відмова погіршує кейс. Чекай, доповнюй доказову базу, пиши точніше.

🤖 Що змінилося в системі детекції до 2026 року

Кілька речей, які з’явилися вже після того, як більшість гайдів була написана.

Google Safe Browsing v5

У 2025 році Google запустив п’яту версію Safe Browsing API. Головна відмінність — real-time перевірка з пріоритетом на приватність (OHTTP relay). Нові методи працюють швидше та дають свіжіший статус домену, ніж v4.

Для арбітражників практичний висновок один: Safe Browsing оновлюється швидше, і «чистий учора» домен може бути зафлагований сьогодні. Перевіряй статус домену безпосередньо перед запуском, а не в день покупки.

Стара v4 працюватиме до 31 березня 2027 року, потім її відключать.

→ developers.google.com/safe-browsing/reference

Gemini дивиться на весь акаунт, а не тільки на сайт

Це важливо. Система тепер оцінює не окрему сторінку, а весь контекст: вік акаунта, історію кампаній, швидкість старту, поведінкові патерни.

Новий акаунт з агресивним запуском — це вже сигнал, навіть якщо сам вайт ідеальний. Прогрів перестав бути просто порадою — тепер він впливає на те, як Gemini оцінює твій «намір».

Mixed content — прихована причина повторних флагів

Окрема історія, яку часто ігнорують. Після очищення сайту Compromised Site може прилітати знову — через HTTP-ресурси на HTTPS-сторінці або HTTP-редиректи в ланцюжку 301.

Основну загрозу прибрано, але змішаний контент залишається, і система знову фіксує аномалію.

Що перевірити додатково:

  • Усі зовнішні ресурси (шрифти, картинки, скрипти) завантажуються тільки через HTTPS
  • У ланцюжках редиректів немає жодної HTTP-ланки
  • Google Search Console → Security Issues — цей звіт детальніший, ніж просто Safe Browsing check. Дивитися потрібно саме туди, а не тільки через API

Cloaking-детекція: тепер із поведінковим аналізом

У лютому 2026 року дослідники Varonis задокументували платформу 1Campaign — сервіс клоакінгу, який показував Google-ботам білу сторінку, а реальним користувачам — фішингові воронки.

Google відреагував: системи детекції тепер включають симуляцію поведінки реального користувача, а не просто crawler-читання HTML.

Практичний висновок: вайт, який не «живе» — немає скролінгу, немає рухів миші, немає взаємодії з елементами — виглядає підозріло навіть якщо технічно чистий.

Поведінковий траст сторінки став частиною оцінки.

Короткі висновки

Уся історія з Compromised Site та Malicious Software зводиться до одного: сайт має виглядати чисто, прогнозовано та зрозуміло для машин.

Якщо код прозорий, домен без дивного бекграунду, а поведінка сторінки не нагадує фішинг, алгоритми майже не чіпають.

Google не намагається «вгадати», хороший ти чи ні. Він реагує на патерни, тому чим менше у сайта несподіванок, тим спокійніше живе рекламний акаунт.

Домен краще перевіряти заздалегідь: історія, репутація, флаги, чужі артефакти — усе це грає роль. Те саме стосується серверів та IP-адрес, особливо якщо ти працюєш із великою кількістю акаунтів.

Кодова частина — основа безпеки. Без обфускації, без прихованих переходів, без елементів, які створюють враження підміни. Чим простіше читається структура сайта, тим краще для трасту.

І ще один момент: не розганяйся різко. Нові домени, нові зв’язки та свіжі профілі завжди потребують спокійного старту. Прогрів економить нерви й часто рятує від непотрібних банів.

Якщо цього дотримуватись, імовірність прильоту обох банів одразу стає мінімальною.

🍌 А якщо не хочеться збирати вайт самому

Ми робимо чисті, оптимізовані вайти з унікальним кодом, коректною структурою, нормальними політиками, фільтрацією стоп-слів і готовими сторінками під запуск. Усе швидко, акуратно й без зайвих технічних пригод. Забрати можна в боті.

Контакти

Наш бот → @banana_ads_bot
Канал → @banana_traff_channel
Саппорт → @Supp_bananabot

 Сайт → https://banana-traff-shop.com/

0
Підписуйся