Николай Анисеня, Positive Technologies: Мобильное приложение даёт злоумышленнику больше векторов для атаки

В июле 2026 года Positive Technologies провела эксперимент: специалисты предложили нейросетям проанализировать готовые Android-приложения и модифицировать их. В результате выяснилось, что успешная модификация может стоить всего один рубль. При этом подменённое приложение продолжит работать как оригинал, а пользователь даже не заметит, что внутри появился вредоносный код. Что это значит для отрасли, компаний и их клиентов — обсудили с Николаем Анисеней, руководителем разработки PT MAZE.

Для начала давайте поговорим об эксперименте. Мне кажется, вы первые, кто оценил сложность, скорость и, главное, стоимость модификации готовых приложений с помощью нейросетей. Но что это на самом деле означает с точки зрения безопасности? 

Н. А.: Если коротко, всё очень плохо. Сейчас объясню почему. 

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

Если вы интересуетесь играми, достаточно открыть YouTube: в рекомендациях наверняка найдутся ролики с невероятными модификациями, когда с помощью нейросетей одну игру переделывают в другую.

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

Это впечатляет с точки зрения возможностей больших языковых моделей. Но в чём здесь риск для обычных пользователей? Кто-то может взять Android-приложение, изменить его, и что дальше?

Н. А.: В эксперименте мы рассмотрели один из сценариев атаки на мобильное приложение: тот, с которым вполне может столкнуться обычный пользователь.

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

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

А можете привести пример вредоносного кода, который может быть встроен, например, в игру или банковское приложение? Что он сможет делать?

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

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

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

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

Получается, что низкая цена и разнообразие таких атак открывают перед злоумышленниками целый горизонт возможностей?

Н. А.: Твоя метафора с горизонтом хорошо описывает то, что сейчас происходит. Если посмотреть на ситуацию с уязвимостями в целом, мы увидим, что хакеры ускорились на порядки, буквально в сотни раз. Если раньше эксплуатация уязвимости класса one-day доходила до жертв примерно за 72 часа, то теперь на это может уходить около 40 минут.

А что мы видим в мобильных приложениях? Раньше серьёзные уязвимости в них редко становились инструментом массовых атак. Ими в основном занимались багхантеры, участники CTF-соревнований, а в отдельных случаях такие уязвимости использовали для сложных атак, например с помощью zero-click-эксплойтов в самых популярных приложениях.

А теперь, ускорившись в 100 раз, злоумышленникам становится экономически выгодно искать и эксплуатировать даже сложные уязвимости. В результате мобильные приложения просто становятся ещё одним инструментом в их арсенале. Недавние громкие взломы, которые начинались с анализа Android-приложений, это хорошо показывают. Злоумышленники уже активно используют такой подход, хотя ещё год назад он не был популярным.

Раньше, когда мы говорили об угрозах для мобильных приложений, я представлял это так: есть приложение, в нём можно найти уязвимость, а затем использовать её для атаки. Получается, ваше исследование доказывает, что есть и другой риск?

Н. А.: На мой взгляд, мобильное приложение даёт злоумышленнику больше векторов для атаки, чем веб-приложение. Конечно, можно рассматривать его как обычное веб-приложение. Например, изучить API, составить карту взаимодействия с бэкендом и дальше искать способы атаковать серверную часть.

Другой вариант — атаковать непосредственно пользователя, модифицируя приложение и встраивая в него вредоносный код. 

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

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

И теперь искать описанные мною уязвимости становится гораздо проще.

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

Н. А.: Защитные технологии тоже сильно продвинулись. Если лет 10 назад все говорили о базовой обфускации, то сейчас продвинутые компании используют не только статическую защиту, но и защиту во время работы приложения — RASP (Runtime Application Self-Protection). Также используют виртуальные машины, которые могут динамически получать с бэкенда новые проверки, собирать аналитику и передавать её в SIEM-системы для дальнейшего анализа.

Необязательно сразу строить настолько сложную систему. Можно использовать, например, решения класса Application Shielding. Как правило, они объединяют несколько уровней защиты. На статическом уровне — это обфускация, шифрование и упаковка кода, на динамическом — проверки на наличие root-доступа, jailbreak, запуска в эмуляторе, разблокированного загрузчика и модификаций самого приложения. 

Когда все эти механизмы работают вместе, они не только защищают приложение, но и мешают обходить другие проверки. Хакеру приходится преодолевать несколько уровней защиты одновременно, а не последовательно. Это существенно увеличивает стоимость атаки.

Мы проводили эксперименты с нейросетевыми моделями и увидели, что затраты на модификацию приложения при использовании такой защиты могут вырасти на порядки. Наш модуль защиты от агентского реверс-инжиниринга увеличивает стоимость атаки ещё примерно на 68% сверх затрат, которые уже создают встроенные в приложение механизмы защиты.

Поэтому самый простой путь для разработчика — использовать решения класса Application Shielding, протекторы приложений. Они не требуют сложной настройки или написания кода: достаточно встроить такое решение в приложение. Так мы снова выравниваем баланс затрат между защитником и злоумышленником.

 

 

Вы говорите, что защита увеличивает стоимость атаки на десятки, а то и сотни процентов. Но если изначально модификация приложения стоит рубль, то даже если она подорожает в 50 или 100 раз, это всё равно будут небольшие деньги. Получается, защиту нужно делать ещё сложнее?

Н. А.: В моём понимании защита от агентского реверс-инжиниринга сейчас строится на двух компонентах.

Первое — увеличить расход токенов, потому что от этого зависит стоимость атаки. Допустим, у злоумышленника есть 1 000 долларов. Если проверка одного приложения стоит доллар, он сможет проверить 1 000 приложений. А если из-за защиты проверка станет стоить дороже, он сможет проверить уже гораздо меньше.

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

Давайте сравним? Если бы ту же самую задачу (анализ приложения, реверс-инжиниринг, внесение изменений и повторная сборка) выполнял человек, сколько времени это заняло бы и во сколько примерно обошлось?

Н. А.: Это довольно сложно посчитать. У меня нет статистически подтверждённых данных, на которые я мог бы опереться. По моему личному опыту, злоумышленники обычно не хотят браться за реверс-инжиниринг, если понимают, что работа займёт больше пары недель. А если приложение защищено коммерческим протектором, многие и вовсе отказываются от такой работы. Они понимают, что потратят слишком много времени, за которое могли бы провести реверс-инжиниринг нескольких гораздо более простых приложений.

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

Такая защита работает против человека. С нейросетями всё немного иначе: сама нейросеть не устаёт и не теряет мотивацию, но в какой-то момент ей приходится привлекать человека. А вот он уже может устать и разочароваться в процессе.

Можно ли защититься от таких атак только на уровне API — например, отслеживая подозрительные запросы к бэкенду? Или без защиты самого мобильного приложения всё-таки не обойтись?

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

Защита на уровне бэкенда никак не спасёт от вредоносных клонов приложений и фрод-ферм. Поэтому механизмы защиты всё равно придётся внедрять на стороне клиента.

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

Расскажи немного о PT MAZE. Как он помогает снизить риски, о которых мы сегодня говорили, и как компании могут применять его на практике?

Н. А.: PT MAZE относится к классу решений Application Shielding или протекторов мобильных приложений. Он сочетает статическую защиту, включая обфускацию и шифрование всего кода или отдельных его частей, с защитой во время работы приложения. Сюда входят защита от вмешательства в работу решения, контроль целостности самого приложения и его окружения, а также обнаружение хакерских инструментов на устройстве.

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

Возможность настройки у нас тоже есть, но она реализована так, чтобы злоумышленник не мог понять, как именно обойти защитные механизмы.

То есть для злоумышленника это будет работать как чёрный ящик?

Н. А.: Использовать продукт довольно просто. Не нужно писать ни строчки кода: всё работает в формате no-code-сервиса. Приложение загружается в систему, после чего нужно подождать в среднем 15 минут. Точное время зависит от сложности конфигурации и размера приложения. Затем можно скачать уже защищённый бандл.

Дальше остаётся переподписать приложение. Это можно сделать вручную или через конвейер CI/CD, в зависимости от того, как организован процесс у конкретной компании. После этого приложение можно публиковать.

Для пользователя всё максимально просто, а для злоумышленника задача становится значительно сложнее.

А как тарифицируется PT MAZE? По количеству переупаковок или запусков? Или стоимость зависит от количества приложений?

Н. А.: Сейчас количество обращений для заказчика не ограничено. Можно создавать хоть по 10 задач каждый день. Это особенно важно для компаний, у которых есть собственная команда и которые хотят подобрать оптимальную конфигурацию защиты. Ведь недостаточно просто защитить приложение, важно ещё и сохранить его производительность. Нельзя допустить, чтобы пользователи получали плохой пользовательский опыт.

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

Не создаёт ли использование протектора дополнительную нагрузку на приложение? Не начинает ли оно из-за этого тормозить?

Н. А.: Это одно из главных возражений со стороны тех, кто рассматривает использование протектора, но переживает за качество приложения после внедрения защиты. У нас даже есть статья на Хабре «Как не сломать приложение с помощью протектора». Мы знаем, с какими проблемами можно столкнуться, и умеем их обходить. В целом у нас хорошо отлажен процесс тестирования: прежде чем модуль попадёт в продакшн, он проходит серьёзную проверку. Поэтому в релиз не попадают решения, которые могут нарушить работу приложения.

Остаётся вопрос производительности. Здесь все механизмы защиты можно настраивать: например, ограничить защиту теми 5%, 10% или 20% кода, которые представляют интерес для злоумышленника, и не затрагивать остальную часть, которую необязательно защищать.

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

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

Н. А.: На самом деле, придумать способ проще, чем этот, наверное, сложно. 

У меня даже есть забавная история. Одному заказчику мы подготовили демонстрационную защищённую сборку и отправили её ему. Он запустил нейросеть GLM 5.3, и примерно через час она просто скачала оригинальную версию приложения и начала реверс-инжиниринг уже её, потому что справиться с нашей защитой не смогла.

Интересно. Кстати, в вашем исследовании есть интересная статистика по отраслям. Вы сравнивали успешность модификации приложений, и результаты заметно различались: в одних отраслях показатель был всего 10-15%, а в других превышал 80%. Почему такая разница?

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

С другой стороны, причиной неудачи могла быть и обычная техническая ошибка, например проблема с пересборкой приложения.

Чаще всего защитные механизмы встречаются в банковских приложениях. В одних случаях их использование обусловлено требованиями регуляторов, в других за защиту отвечает сильная команда AppSec.

Есть и популярные приложения, которые сталкиваются с большим количеством ботов. Создавать ботов для мобильного API значительно проще, чем для веб-приложений, поскольку на мобильных устройствах сложнее контролировать действия пользователя. В вебе для этого можно использовать разные механизмы защиты на уровне браузера и веб-инфраструктуры, например WAF. В мобильных приложениях приходится полагаться в том числе на встроенные механизмы защиты, но их можно обойти или подделать.

Николай, большое спасибо вам за интересное интервью. Мне кажется, сегодня мы действительно глубже разобрались в теме защиты мобильных приложений!