CIOlogia ИТ и безопасность · язык бизнеса, не технологий
← Все разборы Информационная безопасность

Бесплатный VPN на ноутбуке менеджера: как приложение с миллионом установок слило клиентскую базу оптовика

Разбираем на техническом уровне историю с оттоком 30 клиентов: как бесплатные VPN превращаются в шпионский SDK, какими командами это диагностируется и что реально останавливает утечку за два дня.

12 июля 2026 г. Разбор CIOlogia

История с оптовой компанией, торгующей стройматериалами, — не редкость. По данным SecurityLab, только одно из таких приложений, WireVPN, набрало миллион установок и 34 тысячи отзывов в сторе, прежде чем всплыло, что «защита данных» была лишь прикрытием: приложение собирало трафик и метаданные пользователей и отправляло их на сторонние серверы. Похожая схема была вскрыта раньше у SuperVPN (утечка 21 млн записей пользователей в 2021 году) и у семи бесплатных VPN-сервисов на инфраструктуре AWS (отчёт vpnMentor, 2020) — там тоже обещали анонимность, а по факту логировали всё: IP, DNS-запросы, историю посещений, а иногда и содержимое трафика внутри туннеля.

Наш случай — из той же категории, только цена утечки посчитана в конкретных рублях: 30 потерянных клиентов, средний чек 150 000 ₽, итого больше 4 миллионов упущенной выгоды за полгода.

Как искали дыру

Стандартная проверка ничего не дала: пароли в CRM целые, доступы бывших сотрудников отозваны, на почте директора включена двухфакторка. Дальше — анализ сетевого трафика офиса на уровне шлюза:

tcpdump -i eth0 -w office_traffic.pcap host not 192.168.1.1 and port 443

Разбор pcap в Wireshark по фильтру TLS SNI показал регулярные соединения с доменами, не относящимися ни к одному рабочему сервису:

tls.handshake.extensions_server_name contains "vpn"

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

autorunsc.exe -a * -c -h -s > autoruns.csv
tasklist /svc | findstr /i vpn
netstat -anob | findstr ESTABLISHED

Процесс держал постоянное соединение на 443/tcp с сервером, чей сертификат не совпадал с сертификатом заявленного VPN-провайдера — самоподписанный, с именем субъекта, не связанным с доменом сервиса. Это типичный признак MITM-прослойки внутри самого клиента: трафик сначала расшифровывается локальным SDK, а уже потом заворачивается в собственный туннель до сервера VPN-провайдера.

Как это эксплуатируется

Схема монетизации бесплатных VPN, построенных на шпионском SDK, обычно выглядит так:

  1. Установка с избыточными разрешениями. На Android такие приложения запрашивают права, не нужные для VPN-функциональности напрямую: READ_SMS, SYSTEM_ALERT_WINDOW, BIND_ACCESSIBILITY_SERVICE, доступ к буферу обмена. Проверяется декомпиляцией APK:
    apktool d wirevpn.apk -o wirevpn_src
    grep -A1 "uses-permission" wirevpn_src/AndroidManifest.xml
    На Windows-версии аналог — избыточные COM-объекты и hook-и в буфер обмена, видимые через Process Monitor по фильтру на RegOpenKey и ReadProcessMemory.
  2. Установление скрытого канала. После авторизации клиент открывает второе соединение — не туннель до целевого VPN-сервера, а канал телеметрии на другой хост. Проверяется перехватом через mitmproxy с подменой корневого сертификата на тестовом устройстве:
    mitmproxy --mode transparent --showhost -p 8080
    В логе видно POST-запросы с телом, похожим на дамп буфера обмена или заголовки открытых окон браузера, отправленные в формате JSON на /collect или /telemetry.
  3. Сбор данных. SDK перехватывает: содержимое буфера обмена (коммерческие предложения, цены, номера договоров), историю посещений браузера, а на части устройств — переписку в мессенджерах через чтение уведомлений (Notification Listener Service на Android) или снятие снимков экрана по таймеру.
  4. Эксфильтрация и монетизация. Данные агрегируются на C2-сервере и либо продаются напрямую брокерам данных, либо — что чаще в B2B-сегменте — попадают к конкурентам через посредников на закрытых форумах. Проверка принадлежности такого домена делается быстрым OSINT:
    whois vpn-telemetry-domain.com
    nslookup vpn-telemetry-domain.com
    curl -s "https://www.virustotal.com/api/v3/domains/vpn-telemetry-domain.com" -H "x-apikey: $VT_API_KEY"
    Домен обычно зарегистрирован через приватизированный WHOIS, хостится на дешёвом VPS в юрисдикции без запросов на раскрытие данных, а VirusTotal уже через пару месяцев после старта кампании показывает 5-10 детектов от разных вендоров.

Полутехнические пруфы

  • Соединение на 443/tcp с самоподписанным или мисматч-сертификатом — легко проверяется через openssl s_client -connect host:443 -servername host.
  • В логах DNS-резолвера офиса — регулярные запросы к доменам telemetry/analytics поддоменам, не относящимся к заявленному VPN-бренду.
  • В диспетчере задач — процесс с именем, маскирующимся под системный сервис (svchost-подобные имена), но без цифровой подписи Microsoft: Get-AuthenticodeSignature C:\Windows\Temp\vpnhelper.exe.
  • В разрешениях приложения (Android) — комбинация VPN-permission + доступ к уведомлениям + доступ к буферу обмена, которой нет ни у одного легитимного VPN-клиента с открытым исходным кодом (WireGuard, OpenVPN).

Что и почему сработало бы дальше

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

Как закрыли

Решение заняло два дня и не потребовало сложных систем:

  • Удалили все сторонние VPN-клиенты с рабочих устройств, поставили одно корпоративное решение с централизованным управлением конфигурацией.
  • Внедрили allowlist приложений через групповые политики Windows (AppLocker):
    New-AppLockerPolicy -XmlPolicy allowlist.xml -Merge
    Set-AppLockerPolicy -PolicyObject $policy -Merge
  • Настроили запрет установки неподписанного софта и уведомление ответственному в мессенджер при попытке запуска неразрешённого исполняемого файла — через связку AppLocker + Event Forwarding + вебхук.
  • На уровне шлюза добавили egress-фильтрацию: запрет исходящих 443/tcp на неизвестные хосты, кроме заранее одобренного списка (allowlist по FQDN через прокси с TLS SNI inspection).
  • Провели короткий инструктаж для сотрудников — без запугивания, с объяснением на примерах, почему «бесплатный VPN для обхода блокировок» на рабочем устройстве — не мелочь, а канал утечки коммерческой информации.

Что в итоге

Отток клиентов остановился в течение месяца после смены VPN-клиента и внедрения allowlist. Стоимость исправления оказалась на порядок ниже суммы упущенной выгоды. Менеджер, поставивший приложение, не имел злого умысла — он просто хотел заходить на зарубежные сайты в обед. Именно поэтому такие истории повторяются в компаниях любого размера под разными масками: то VPN, то конвертер файлов, то расширение браузера с хорошими отзывами. Итог всегда один и тот же — данные утекают туда, где их не должно быть, и обнаруживается это чаще всего постфактум, по счетам, а не по логам.