Как Google Ads блокирует легальный софт как вредоносный

Введение: $500 потрачено — аккаунт заблокирован

Представьте: вы разработчик. Вы написали инструмент, подписали и нотаризировали приложение по всем правилам, развернули чистый сайт без единой уязвимости — и решили, наконец, вложить деньги в рекламу. Настраиваете кампанию в Google Ads, пополняете счёт.

А потом — бан. За «вредоносное программное обеспечение».

Именно это произошло с автором статьи на xlii.space. Он попробовал рекламировать свой продукт впервые: настроил кампанию в Google Ads, потратил $500 — и Google заблокировал аккаунт за «Malicious software». Никакого вируса, никакого трояна — просто автоматический фильтр решил иначе.

Эта история — не про хакеров и не про настоящие вирусы. Это про то, как устроена система модерации Google Ads изнутри, почему она ошибается, и что делать, если вы оказались на её пути.

⚠ Важно

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

Что происходит «под капотом» Google Ads: масштаб и механика

Прежде чем разбирать конкретный кейс, важно понять масштаб задачи, которую решает Google каждый день.

В 2025 году Google заблокировал или удалил более 8,3 миллиарда вредоносных объявлений. Используя генеративный ИИ — в частности, Gemini — платформа нейтрализует угрозы до того, как их увидит пользователь: более 99% нарушающих правила объявлений так и не добираются до экрана.

Цифры за предыдущий год не менее впечатляющие: в 2024 году Google приостановил 39,2 миллиона рекламных аккаунтов — более чем втрое больше, чем 12,7 миллиона заблокированных в 2023 году, — задействовав свыше 50 больших языковых моделей. Эти инструменты на основе ИИ обеспечивают 97% решений по применению рекламных правил, выявляя мошенническое поведение, ложные медицинские утверждения, неправомерное использование данных и нарушения торговых марок.

«Ландшафт рекламной безопасности постоянно меняется, его переформатируют технологические прорывы, новые тактики злоупотреблений и глобальные события» — Google Ads Safety Report

При таком масштабе ложноположительные срабатывания неизбежны. И именно они становятся кошмаром для добросовестных разработчиков.


graph TD
    A[Рекламодатель запускает кампанию] --> B[Автоматическая проверка объявления]
    B --> C{ИИ-фильтр Gemini}
    C -->|Чисто| D[Объявление показывается]
    C -->|Подозрительно| E[Углублённый анализ]
    E --> F{Решение системы}
    F -->|Ок| D
    F -->|Нарушение| G[Блокировка аккаунта]
    G --> H[Апелляция рекламодателя]
    H --> I{Ручная проверка или автоответ}
    I -->|Одобрено| D
    I -->|Отказ| J[Постоянная блокировка]

Кейс: легальный инструмент против алгоритма

Вернёмся к истории с xlii.space. Автор рекламировал инструмент под названием RACE. RACE намеренно запускает и управляет фоновыми процессами командной оболочки. В его конфигурации документированы три бэкенда для сохранения состояния: собственный PTY-хост, внешний dtach или режим без сохранения.

Именно это поведение — работа с фоновыми процессами — и насторожило алгоритм. С точки зрения эвристики, такой паттерн похож на поведение руткитов или персистентного вредоносного ПО. Но приложение было чистым.

Приложение было подписано и нотаризировано. Сайт был чистым и не имел никакой поверхности для атак.

Google сослался на «Malicious software» и «Compromised Site». Автор счёл это абсурдом.

Проверка через Google Search Console расставила всё на свои места — но не помогла с рекламой:

Автор открыл отчёт Security Issues для каждого домена отдельно. Оба показали «No issues detected». Не было ни заражённых страниц, ни вредоносных загрузок, ни внедрённых ресурсов.

Это показывает, что сообщает Safe Browsing для этих адресов — но не то, что обнаружил Google Ads, и используют ли эти две системы одни и те же критерии.

Вот в чём суть проблемы: Google Ads и Google Safe Browsing — это разные системы с разными критериями. Чистота в одной не гарантирует одобрение в другой.

ℹ Два разных фильтра

Google Search Console / Safe Browsing и Google Ads используют независимые системы модерации. Отсутствие проблем в одной не означает чистоту в другой. Разработчики часто не знают об этом, пока не столкнутся с блокировкой.

Апелляция: стена молчания

Автор подал апелляцию. Её отклонили, предложили предоставить новые данные и посоветовали удалить аккаунт, если таковых нет. Также упомянули варианты обжалования в ЕС. При этом не было сказано, что именно было вредоносным, что было скомпрометировано и почему предоставленные доказательства не устранили ни одно из обвинений. Автор получил инструкции для обжалования, но никакого объяснения, которое помогло бы оспорить решение.

Это системная проблема. Если нарушения правил обнаружены, аккаунт в Google Ads будет приостановлен сразу после обнаружения и без предварительного предупреждения, а рекламодателю не будет разрешено снова рекламироваться в Google Ads.

Что именно запрещает Google Ads: формальные правила

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

«Вредоносное ПО» (Malware) — это программное обеспечение, цель которого нанести вред или получить несанкционированный доступ к компьютеру, устройству или сети.

Эти требования распространяются на объявления и любое программное обеспечение, которое сайт или приложение размещает или на которое ссылается, независимо от того, продвигается ли это ПО через рекламную сеть Google.

Конкретные запреты включают:

Нарушение	Описание
Malicious redirects	Принудительные редиректы на заражённые сайты без клика пользователя
Credential stealing	HTML5-объявления, крадущие учётные данные со страниц издателей
Forced downloads	Загрузки без явного согласия пользователя
False representation	Реклама с кнопкой «Download», не указывающая, что именно скачивается
Compromised site	Любой элемент цепочки загрузки страницы, признанный вредоносным

Стоит отметить, что эти требования распространяются не только на само объявление, но и на финальную целевую страницу и всё, что она загружает: сторонние скрипты, встроенные формы, CDN, iframe и любые последующие редиректы.

📝 Пример ложного срабатывания

Инструмент для разработчиков, управляющий фоновыми процессами (PTY, shell persistence), терминальные мультиплексоры, менеджеры процессов — все они могут быть интерпретированы эвристикой как руткиты или трояны. Google не делает исключений для «легитимного» поведения, если паттерн совпадает с вредоносным.

Реальный malvertising vs. ложные срабатывания: в чём разница

Важно понимать, что кейс с xlii.space — это не про реальный malvertising. Настоящие атаки выглядят совершенно иначе.

Malvertising (от «malicious software» + «advertising») — это использование онлайн-рекламы для распространения вредоносного ПО. Как правило, он предполагает внедрение вредоносных объявлений в легитимные рекламные сети и веб-страницы. Поскольку рекламный контент может встраиваться на авторитетные сайты, malvertising даёт злоумышленникам возможность атаковать пользователей, которые иначе были бы защищены файрволами и другими мерами безопасности.

Для реальных атак характерны куда более изощрённые техники:

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

Нередко эти злоумышленники используют методы манипуляции текстом, чтобы обойти автоматические механизмы обнаружения. В других случаях они прибегают к тактике клоакинга: показывают проверяющим Google и системам одни объявления, а пользователям — другие.

А вот свежий пример реальной угрозы: вредоносная программа GPUGate использует Google Ads и поддельные коммиты GitHub для кражи данных у IT-компаний; ссылки в фиктивных коммитах ведут пользователей на вредоносные загрузки, размещённые на домене-двойнике. Вредонос первого этапа, доставляемый через отравленные результаты поиска, представляет собой раздутый MSI-файл размером 128 МБ, который благодаря своему размеру обходит большинство существующих онлайн-песочниц.

Сравнение: настоящий malvertising vs. ложное срабатывание

Критерий	Настоящий malvertising	Ложное срабатывание
Намерение	Вредоносное	Легитимное
ПО	Вирус / троян / стилер	Чистый инструмент
Сайт	Скомпрометирован или фейк	Чистый, нотаризированный
Поведение ПО	Скрытое, деструктивное	Задокументированное, открытое
Реакция Google	Справедливая блокировка	Ложная блокировка
Апелляция	Невозможна (и не нужна)	Возможна, но часто бесполезна

Что делать, если вас заблокировали: пошаговый план

Если вы разработчик легального ПО и столкнулись с блокировкой в Google Ads — вот рациональный порядок действий.

1. Проверьте все уровни цепочки

Google отклоняет объявления за вредоносное или нежелательное ПО, когда обнаруживает малварь, принудительные загрузки, мошеннические программы или скомпрометированную целевую страницу в любом звене цепочки назначения объявления — включая скрипты, iframe и редиректы, которые загружает страница.

Проверьте:

Все сторонние скрипты на landing page
CDN и внешние ресурсы
Iframe и формы
Редиректы (включая промежуточные)

2. Используйте диагностические инструменты

# Проверка через VirusTotal API
curl --request POST \
  --url https://www.virustotal.com/api/v3/urls \
  --header 'x-apikey: YOUR_API_KEY' \
  --form url=https://yoursite.com

# Проверка через Google Safe Browsing API
curl -X POST \
  'https://safebrowsing.googleapis.com/v4/threatMatches:find?key=YOUR_KEY' \
  -H 'Content-Type: application/json' \
  --data '{"client":{"clientId":"myapp","clientVersion":"1.0"},"threatInfo":{"threatTypes":["MALWARE"],"platformTypes":["ANY_PLATFORM"],"threatEntryTypes":["URL"],"threatEntries":[{"url":"https://yoursite.com"}]}}'

3. Подготовьте апелляцию с доказательствами

Если вы считаете, что произошла ошибка и вы не нарушали политику, подайте апелляцию и объясните причины. Аккаунты восстанавливаются только при наличии веских обстоятельств и достаточных оснований — поэтому важно быть тщательным, точным и честным.

В апелляцию стоит включить:

Скриншоты из Google Search Console (Security Issues → No issues)
Результаты сканирования VirusTotal для домена и файлов
Сертификаты подписи / нотаризации приложения
Документацию к ПО с объяснением поведения (особенно если оно работает с системными процессами)
Указание конкретного функционала, который мог быть неправильно интерпретирован

💡 Совет для разработчиков системного ПО

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

4. Рассмотрите альтернативные рекламные каналы

Если Google Ads недоступен, для технических продуктов есть альтернативы:

Платформа	Тип аудитории	Особенности
Reddit Ads	Разработчики, технари	Нишевый таргетинг по сабреддитам
Carbon Ads	Dev-аудитория	Специализация на IT-продуктах
HN / Product Hunt	Стартапы, инди-разработчики	Бесплатное продвижение
LinkedIn Ads	B2B, enterprise	Дороже, но точный таргетинг
Twitter/X Ads	Tech-сообщество	Широкая технологическая аудитория

Системная проблема: ИИ-модерация в эпоху гиперавтоматизации

История с xlii.space — не уникальна. Это симптом более глубокой проблемы: когда системы модерации масштабируются до миллиардов проверок в год, неизбежно возникают коллатеральные потери среди добросовестных пользователей.

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

Malvertising продолжает оставаться важным вектором первоначального доступа для вредоносного ПО: злоумышленники злоупотребляют мошенническими объявлениями в Google Search и других поисковых системах, перенаправляя пользователей на фиктивные сайты.

При этом система апелляций не успевает за масштабом: рекламодателю не сообщают, что именно было вредоносным, что было скомпрометировано и почему предоставленные доказательства не устранили ни одно из обвинений. Он получает инструкции для апелляции, но не получает объяснения, которое помогло бы её выиграть.

⚠ Структурное противоречие

Google одновременно является крупнейшей рекламной платформой мира и одним из главных борцов с malvertising. Это создаёт конфликт интересов: слишком мягкие фильтры наносят ущерб пользователям, слишком жёсткие — рекламодателям. Сейчас маятник качнулся в сторону жёсткости — и легальные разработчики платят за это.

Заключение: что это значит для разработчиков

История «How I advertise malicious software on Google Ads» — это, конечно, провокационный заголовок с долей горькой иронии. Автор не рекламировал вредоносное ПО. Он рекламировал свой инструмент — и алгоритм решил иначе.

Что из этого следует:

Google Ads и Safe Browsing — разные системы с разными критериями. Чистота в одной не гарантирует прохождение другой.
Системное ПО под особым риском: инструменты, работающие с процессами, оболочками и персистентностью, будут вызывать подозрения у эвристических фильтров.
Апелляции непрозрачны: вы не узнаете, что именно стало причиной блокировки. Готовьте доказательную базу заранее.
Масштаб порождает ошибки: при 8+ миллиардах проверяемых объявлений в год ложные срабатывания — это статистическая неизбежность, а не исключение.
Диверсифицируйте каналы: полагаться только на Google Ads при продвижении технических продуктов — значит зависеть от системы, которая может заблокировать вас без объяснений.

Самая честная рекомендация — относитесь к Google Ads как к капризному партнёру: полезному, мощному, но непредсказуемому. Стройте каналы привлечения пользователей, которые не зависят от единственной платформы.

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