Все верно. Поэтому "зеленый" вердикт от Virustotal или антивируса ни в коем случае не гарантия того, что файл или ссылка безопасная. Но если явно "красный", то открывать точно не стоит.
Вот так бы APK с Max-ом разобрать, что и куда он отправляет.
Уже было очень поверхностное исследование https://habr.com/ru/articles/938518/ Но надо смотреть какие изменения в коде были за это время, функционал мог добавиться разный, даже если разрешения не поменялись. Сегодня явного вредоносного функционала нет, а завтра?
Как-то не впечатляет. Лет десять назад на почту без спам-фильтров валилось великое множество зловредов, были среди них и JAR-файлы.
Злоумышленнику нет никой задачи впечатлить исследователя. Главная - пройти статические фильтры и усложнить беглый анализ. Тут всё работает по схеме "время стоит денег" и времена, когда хакеры писали код для того, чтобы показать свои технические навыки, уже ушли. В вашем случае JAR файлы были сложнее, потому что должны были пройти возможную проверку антивирусом на стороне почтового сервера. В большинстве случаев в вирусах Мамонт-like никто даже строки не шифрует - антивирусов на телефонах нет. И, к сожалению, это всё работает и довольно успешно.
Если хочется почитать, про более сложные вещи - у Angara Securityвыходила статья про BT MOB Rat - там и тех поддержка есть и более сложные алгоритмы противодействия исследованию.
Формулировка "перед тем скачать, проверить" явно кривоватая. Если пришла ссылка на файл, то её можно проверить через Virustotal - там может и не файл вовсе. Если прям пришёл файл в сообщении, то можно воспользоваться телеграм-ботом от Доктор Веб (https://telegram.me/drwebbot).
Так изначально специалисты GroupIB/F.A.C.C.T/F6 назвали семейство ВПО (https://www.f6.ru/media-center/press-releases/fake-courier/). Потом даже злоумышленники подхватили и стали сами так называть внутри свои приложения. Сейчас это целое семейство схожих между собой вредоносных приложений, нацеленных на обман пользователей Android и получение доступа к SMS, всплывающим сообщениям и любым способам монетизации зараженных устройств. Разработчики в основном русскоязычные - в марте 2025 даже нескольких МВД уже взяли (https://tass.ru/proisshestviya/23545883). Но как показала практика схема еще долго не "вымрет".
Конечно, в разных версиях ОС у kernel32.dll разные CRC. Поиск kernel32.dll осуществляется через PEB в памяти текущего процесса по имени библиотеки (BaseDllName). Чтобы не было явного сравнения с kernel32 в коде, имя библиотеки хешируется и сравнивается с 0x6A4ABC5B. Это стандартная практика неявного получения необходимых функций. Обычно получают LoadLibrary, GetProcAddress, VirtualAlloc, VirtualProtect). Здесь можно посмотреть пример поиска https://www.ired.team/offensive-security/code-injection-process-injection/finding-kernel32-base-and-function-addresses-in-shellcode . Только по ссылке не используется хеширование.
Указанный плагин в данном фрагменте не сильно поможет, тут вашим скриптам конкурентов нет. Я его привёл в качестве готового инструмента, который тоже может помочь при разборе такого рода таблиц импорта. И да, он лучше всего подходит для разбора шеллкодов. Для данных образцов плагин максимум прокомментирует хеши, чтобы получилось примерно так:
Комментарии плагина в псевдокодеКомментарии к найденным хешам
Мне всё равно пришлось добавить функцию хеширования BlackMatter в скрипт сбора хешей и пересчитать базу для него, так как среди имеющихся функций хеширования ни одна не подошла. Зато теперь можно указывать соль, когда плагин ищет по всей IDB, и для образцов с другой солью пересчитывать хеши не придётся.
Спасибо за отличную статью по восстановлению импорта. Несколько предложений:
Если для первого образца всё равно используется IDAPython, то почему бы не получить импорт через IDA Debugger?
Для восстановления импорта по хешам можно использовать плагин Shellcode_hashes от Flare/Mandiant. У них была отличная статья еще в 2012 году (https://www.mandiant.com/resources/precalculated-string-hashes-reverse-engineering-shellcode). Плагин должен работать на IDA 7.2+, они его обновляют. Конечно, в случае с использованием соли как в BlackMatter он не сильно поможет, но в таком случае всё равно без предварительно анализа не обойтись. Ведь сначала надо эту соль найти и пересчитать хеши.
Все верно. Поэтому "зеленый" вердикт от Virustotal или антивируса ни в коем случае не гарантия того, что файл или ссылка безопасная.
Но если явно "красный", то открывать точно не стоит.
Уже было очень поверхностное исследование https://habr.com/ru/articles/938518/
Но надо смотреть какие изменения в коде были за это время, функционал мог добавиться разный, даже если разрешения не поменялись.
Сегодня явного вредоносного функционала нет, а завтра?
Злоумышленнику нет никой задачи впечатлить исследователя. Главная - пройти статические фильтры и усложнить беглый анализ. Тут всё работает по схеме "время стоит денег" и времена, когда хакеры писали код для того, чтобы показать свои технические навыки, уже ушли.
В вашем случае JAR файлы были сложнее, потому что должны были пройти возможную проверку антивирусом на стороне почтового сервера.
В большинстве случаев в вирусах Мамонт-like никто даже строки не шифрует - антивирусов на телефонах нет. И, к сожалению, это всё работает и довольно успешно.
Если хочется почитать, про более сложные вещи - у Angara Securityвыходила статья про BT MOB Rat - там и тех поддержка есть и более сложные алгоритмы противодействия исследованию.
Формулировка "перед тем скачать, проверить" явно кривоватая.
Если пришла ссылка на файл, то её можно проверить через Virustotal - там может и не файл вовсе.
Если прям пришёл файл в сообщении, то можно воспользоваться телеграм-ботом от Доктор Веб (https://telegram.me/drwebbot).
Так изначально специалисты GroupIB/F.A.C.C.T/F6 назвали семейство ВПО (https://www.f6.ru/media-center/press-releases/fake-courier/). Потом даже злоумышленники подхватили и стали сами так называть внутри свои приложения. Сейчас это целое семейство схожих между собой вредоносных приложений, нацеленных на обман пользователей Android и получение доступа к SMS, всплывающим сообщениям и любым способам монетизации зараженных устройств. Разработчики в основном русскоязычные - в марте 2025 даже нескольких МВД уже взяли (https://tass.ru/proisshestviya/23545883). Но как показала практика схема еще долго не "вымрет".
Конечно, в разных версиях ОС у kernel32.dll разные CRC.
Поиск kernel32.dll осуществляется через PEB в памяти текущего процесса по имени библиотеки (BaseDllName). Чтобы не было явного сравнения с kernel32 в коде, имя библиотеки хешируется и сравнивается с 0x6A4ABC5B. Это стандартная практика неявного получения необходимых функций. Обычно получают LoadLibrary, GetProcAddress, VirtualAlloc, VirtualProtect). Здесь можно посмотреть пример поиска
https://www.ired.team/offensive-security/code-injection-process-injection/finding-kernel32-base-and-function-addresses-in-shellcode . Только по ссылке не используется хеширование.
Указанный плагин в данном фрагменте не сильно поможет, тут вашим скриптам конкурентов нет. Я его привёл в качестве готового инструмента, который тоже может помочь при разборе такого рода таблиц импорта. И да, он лучше всего подходит для разбора шеллкодов.
Для данных образцов плагин максимум прокомментирует хеши, чтобы получилось примерно так:
Мне всё равно пришлось добавить функцию хеширования BlackMatter в скрипт сбора хешей и пересчитать базу для него, так как среди имеющихся функций хеширования ни одна не подошла. Зато теперь можно указывать соль, когда плагин ищет по всей IDB, и для образцов с другой солью пересчитывать хеши не придётся.
Спасибо за отличную статью по восстановлению импорта. Несколько предложений:
Если для первого образца всё равно используется IDAPython, то почему бы не получить импорт через IDA Debugger?
Для восстановления импорта по хешам можно использовать плагин Shellcode_hashes от Flare/Mandiant. У них была отличная статья еще в 2012 году (https://www.mandiant.com/resources/precalculated-string-hashes-reverse-engineering-shellcode). Плагин должен работать на IDA 7.2+, они его обновляют. Конечно, в случае с использованием соли как в BlackMatter он не сильно поможет, но в таком случае всё равно без предварительно анализа не обойтись. Ведь сначала надо эту соль найти и пересчитать хеши.