Compromised Site и Malicious Software: Полный гайд по системе детекции и выживанию

Когда Google выносит вердикт, что сайт «небезопасен», это почти всегда означает одно: система увидела паттерны, которые совпадают с поведением фишинга, мошеннических воронок или распространения вредоноса. Алгоритм не пытается понять, что вы там реально запускаете. Он просто фиксирует риск и ставит стоп.

Для арбитражников это стало особенно болезненной темой в 2024–2025 годах. Внутри документации Google Ads оба этих бана относятся к категории Policy Risk, то есть система работает не по факту нарушения, а по вероятности. И если вероятность, по мнению алгоритма, высокая — аккаунт улетает, даже если на ленде всё чисто.

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

🔍 Compromised Site — как система решает, что сайт «битый»

Что Google реально считает скомпрометированным сайтом

В политике всё звучит аккуратно: сайт взломан, подменён или заражён. В реальности же Compromised Site — это автоматический фильтр, который реагирует на любые аномалии в коде, структуре и инфраструктуре. Система не пытается понять намерения владельца. Она сравнивает сайт с миллионами паттернов вредоносных страниц и вешает флаг, если сигналов слишком много.

Чтобы разложить это по полочкам, смотрим на пять основных слоёв, которые анализирует Google.

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

1. Исходный код — система проверяет структуру HTML, CSS, JavaScript на предмет обфусцированного кода, зашифрованных функций, инлайн-скриптов, редиректов.
2. Поведение страницы — трекинг того, как страница взаимодействует с браузером (popup'ы, изменение DOM, редиректы, попытки доступа к системным ресурсам).
3. Репутация домена — проверка всех доменов на одном IP, WHOIS-данные, возраст домена, история использования.
4. Контентные элементы — структура сайта, наличие текста, меню, соцсетей, политики конфиденциальности.
5. Инфраструктура — открытые порты, неправильная конфигурация сервера, неустановленные SSL-сертификаты, совместное хостинг с подозрительными доменами.

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

🔧Cloudflare и авто-инъекции скриптов

Cloudflare в 2023 начал добавлять на proxied-домены свои Beacon-скрипты. Google читает эти вставки как неизвестный трекер и относит страницу к потенциально вредоносной.

Что отключить:

• Email Obfuscation
• Web Analytics / Beacon

Где: Cloudflare Dashboard → SSL/TLS и Analytics Engine.

Если домен боевой, лучше использовать собственный сервер или чистый CDN.

🏚 Домен с “грязной” историей

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

Что проверить:

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

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

3. Повтор одного вайта на нескольких доменах

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

Что меняем:

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

Работает просто: меньше повторов, меньше риска.

4. Креативы-близнецы в рекламных кампаниях

Система обучена на визуальном анализе. Если креативы одинаковые, Google связывает кампании в одну сеть.

Что влияет:

• Стиль текста
• Цветовые паттерны
• Сетка баннера
• Структура посадочной

Меняй хотя бы детали: кнопку, фон, формулировку.

🌐 Дешёвые и токсичные TLD

Исторически .xyz, .top, .site, .tk и другие дешёвые зоны использовались во вредоносе. Google реагирует жёстко.

Уровень риска TLD:

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

Работать можно, просто готовь домен тщательнее.

6. Проксирование и открытые трекеры

Google анализирует сетевое окружение: IP, DNS, SSL, куда уходит трафик. Если один IP обслуживает старые домены, трекеры и текущий проект, то риск высокий.

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

• Разные IP под разные проекты
• Чистый SSL
• Без “переадресаций-в-никуда”
• Без лишних сервисов на одном узле

🛠 Ошибки в серверной конфигурации

Google Transparency Report видит технические уязвимости.

Что закрыть:

• Лишние порты
• FTP
• Admin-панели
• Индексацию системных директорий
• Отсутствие SSL

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

SSH: только ключи
UFW: открыты 80/443
SFTP вместо FTP
SSL обязателен
Скрыть админ-доступ

🕷 Вредоносные скрипты, miner’ы и подозрительное поведение

Google анализирует JS и сетевые запросы. Любые странные обращения считаются вредоносными.

Проверки:

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

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

✅ Чеклист, чтобы не словить Compromised Site

Всё, что здесь перечислено, реально снижает риск, потому что закрывает основные сигналы Safe Browsing и Policy Risk.

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

Что Google подразумевает под «Malicious Software»

По формулировке Google это программное обеспечение, которое может навредить устройству или данным пользователя.
На практике Malicious Software — это более точечный бан, который реагирует на конкретные категории вредоносного кода.

Что обычно попадает под детекцию:

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

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

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

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

🧪 Статический анализ файлов

Здесь система просто читает код как есть.

• скрипты отправляются в VirusTotal
• проверка идёт по десяткам движков одновременно
• если несколько движков дают подозрение — идёт флаг

⚙️ Динамический анализ в песочнице

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

Чтобы убрать риски, трекеры нужно прятать.

Рабочие варианты:

const trackUrl = btoa('xyz-real-tracker-params');
const pixel = new Image();
pixel.src = '/api/metrics?data=' + trackUrl;

🟠 Обфусцированный 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:admin@example.com">admin@example.com</a>

<!-- После Cloudflare обработки -->
<a href="/cdn-cgi/l/email-protection#...">admin@example.com</a>
<script>/* decryption code */</script>

Google реагирует на это не всегда, но такие скрипты могут попасть под подозрение, потому что:

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

Для системы это выглядит как лишний слой активности, который не объяснён логикой сайта.

🟣 Встроенные редиректы

Некоторые редиректы выглядят для 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' }));

Эти запросы допустимы в веб-приложениях, но на стандартном вайте они выглядят лишними и создают ощущение подозрительного поведения скриптов. Black Friday promo: 6923B50B555D3

⚫ Опасные файлы на сервере

Любые скачиваемые форматы вроде:
— .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 Scanner (полное сканирование)
- VirusTotal (загрузить файлы вручную)
- Google Safe Browsing API (проверить статус)
- Lighthouse (в DevTools)

🔗 Почему Compromised Site и Malicious Software могут прилететь вместе

Эти два бана часто идут парой, потому что Google проверяет их по одинаковым техническим сигналам. Если сайт выглядит рискованно по общей структуре, система фиксирует оба нарушения сразу.

К типичным совпадениям относятся:

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

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

Короткие выводы

Вся история с Compromised Site и Malicious Software сводится к одному: сайт должен выглядеть чисто, прогнозируемо и понятно для машин. Если код прозрачный, домен без странного бэкграунда, а поведение страницы не напоминает фишинг, алгоритмы почти не задевают.

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

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

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

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

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

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