или как намеренно внести Win32-приложение в вирусные базы без смс, но с регистрацией
Представьте: вы разработчик коммерческого ПО. В один прекрасный день пользователи начинают сообщать, что популярный блокировщик uBlock Origin не дает скачать ваш продукт. Никакой рекламы или сторонних баннеров в приложении нет и никогда не было. Невозможно? Вчера один из дружественных проектов столкнулся именно с такой беспощадной атакой на репутацию. Под катом — интриги, расследование, анатомия атаки и выводы, которые могут спасти и ваш проект.
1. Тревожный звонок: блокировка в uBlock Origin
Изначально было совершенно неясно, как ссылка на обычный лаунчер-обновлялку вдруг стала считаться рекламой. После взгляда в источники списков блокировки uBlock Origin стало понятно: дело не в рекламе. Ссылка попала в настоящий список вредоносного ПО (malware list), который поддерживается SpamHaus.
Вскоре была найдена и запись в базе, которая вела на MalwareBazaar — проект, тесно связанный со SpamHaus и агрегирующий отчеты из множества онлайн-песочниц (sandbox).
2. Расследование: по следам вредоноса
Я начал с изучения отчетов из разных песочниц. В большинстве из них срабатывания были вызваны пересечением строк пострадавшего с другими подозрительными файлами (на деле — это были общие строки из стандартных библиотек, классический false positive).
Однако в отчете одной из песочниц всплыло кое-что интересное. Анализ показал, что лаунчер не был основной целью проверки. Он запускался в цепочке как дочерний процесс, соседствуя с откровенным malware. Вредонос запускал лаунчер, имитируя обращения к следующей ступени атаки на систему, что в итоге привело к распространению красных флагов.
3. Анатомия атаки: force false-positive
По сторонним каналам коллегам удалось выяснить картину целиком. Конкурент добавил прямую ссылку на лаунчер в собственноручно написанный вирус-криптор и VNC-бэкдор, упаковал всё это в один исполняемый файл и загрузил его на несколько популярных песочниц.
Результат был предсказуем: сканеры обнаружили вредоносную активность и пометили все образцы как опасные. А поскольку лаунчер был частью этого адского бульона, его контрольная сумма и связанные с ним строки тоже попали в отчеты с пометкой "malicious". Так было создано искусственное ложноположительное срабатывание (force false-positive).
4. Что делать, если вас атаковали? План спасения
Если вы оказались в такой ситуации, время — ваш главный ресурс. Системы анализа часто обмениваются данными, и одно срабатывание может вызвать лавинообразное распространение блокировок.
Вот что нужно делать:
Немедленно оспаривайте результаты, свяжитесь с поддержкой песочницы или антивирусного вендора. Предоставьте доказательства, что ваш файл легитимен, а срабатывание вызвано его запуском в связке с вредоносом.
Перепроверьте все площадки для загрузки, убедитесь, что на сайтах, где распространяется ПО, лежат чистые, не модифицированные файлы, не произошло компрометации репозиториев.
Проинформируйте пользователей, честно расскажите о ситуации в своем блоге или соцсетях. Это лучше, чем молчание.
5. Профилактика: как защититься заранее?
Гарантированно застраховаться от такой атаки сложно, но можно сильно усложнить жизнь злоумышленнику и упростить себе реабилитацию.
Самостоятельно загружайте образцы на площадки проверок, так вы будете знать какие антивирусы/песочницы реагируют на ваш исполняемый файл. Уже на данном этапе стоит отработать по каждому красному флагу.
Пользуйтесь цифровой подписью, подписывайте свой код, в идеале — сертификатом Extended Validation (EV Code Signing). Файлы с валидной подписью вызывают больше доверия у аналитических систем и антивирусов, это может предотвратить автоматическое попадание в черные списки.
Проверка родительского процесса: Как вариант противодействия, можно встроить в приложение механизм, который проверяет, кто его запускает, и запретить запуск, если родительский процесс не имеет цифровой подписи. Это может, однако, вызвать проблемы в некоторых легитимных сценариях, отдельно тестируйте подобные трюки.
Послесловие
Эта история показала, насколько легко при минимальных затратах "очернить" репутацию любого легитимного ПО.
Хочу обратить внимание авторов площадок статического и динамического анализа на подобные векторы атак. Я считаю, что эвристические правила не должны полагаться только на "соседство" с вредоносным файлом в цепочке процессов, а пытаться комбинировать взаимодействие с отдельными частями таких цепочек.
Разработчикам ПО для Windows я настоятельно рекомендую внимательно следить за репутацией своих файлов и скоростью реакции на инциденты. Надеюсь, данный опыт будет вам полезен.
Комментарии (14)
Krypt
11.06.2025 20:03А проверка родительского процесса хоть как-нибудь поможет?
- ваше приложение всё равно запустится перед тем как закрыться при сканировании, попав в список вызовов
- exec("start ./app.exe")
boris768 Автор
11.06.2025 20:03Это скорее для того, чтобы сам файл не запустил еще какую-либо логику, не обратился к основному апи на бекэнде, дабы не задело еще там. Песочницы отслеживают все обращения по сети, так что чем меньше исполняемый файл сделает - тем меньше будет проблем.
skwo73
11.06.2025 20:03попытки представить обычные приложения как вредоносные скорей всего будут ширится. когда это станет популярным тогда попытаются придумать защиту от этого.
EjikEjikovich
Почему сам экзешник вызывает вопросы на VirusTotal?
boris768 Автор
Насколько я знаю, сам файл просто обновляет ресурсы, скачивает еще несколько исполняемых файлов, так что для многих АВ строгий триггер
David_Osipov
Имхо, прочитав репорты о вашем exeшнике, я бы сам его пометил малварью
Репорт Hybrid-analysis
Репорт any.run
И хотя описанная в статье "force false-positive" - это реальная проблема, конкретно ваш файл сам по себе вызывает слишком много вопросов. Дело не в том, что его кто-то запустил рядом с вирусом. Дело в том, что он сам ведет себя как какой-то троянец.
Вот лишь несколько самых очевидных красных флагов из этих репортов:
Сбор информации о системе и подозрительные вызовы. Чтение BIOS, проверка UAC, и, что самое странное, — запуск slui.exe (клиент активации Windows). У легитимного лаунчера нет причин обращаться к компонентам лицензирования ОС.
Активные попытки уклонения от анализа. Тут целый букет: от прямых вызовов IsDebuggerPresent до использования TLS-коллбэков для выполнения кода до основной точки входа - зачем? Секции с аномально высокой энтропией (.text, .data, .rsrc) - тут использование упаковщика или шифровщика для защиты от реверс-инжиниринга.
Прямые индикаторы шпионского ПО. Отчет Hybrid-Analysis четко указывает на наличие функционала для перехвата клавиатуры ("retrieve keyboard strokes") и доступа к буферу обмена ("open the clipboard"). Это уже не просто подозрительно, а гиперподозрительно!
Сетевая активность и C2. Связь идет с C2-сервером (api.metaskins.gg), который помечен вредоносным. Вдобавок, в теле файла найдены строки с .onion - ну тут сами думайте.
Так что дело не в "соседстве с вредоносом в цепочке процессов". Ваш файл, судя по всему, и сам использует сомнительные техники + ещё и не подписан.
PrinceKorwin
Вот это букет!
boris768 Автор
Так и не увидел в графе вызова slui.exe, его упоминаний и нет в самом экзешнике
IsDebuggerPresent вызывается в TLS колбеке MS CRT и вы это можете найти в многих экзешниках буквально у себя на компьютере просто поиском строки внутри файла (скриншот ниже под спойлером). Поясню сразу же - это поиск дебаггера на случай сбоя, по коду в спойлере это очевидно. Больше того еще скажу, что никто в качестве антиотладки не будет использовать настолько слабую проверку, если что есть варианты посолиднее
Такой результат можно получить вообще на любой экзешник, который обратится к буферу обмена, не новость.
В этом и была цель злоумышненика - внести домен в спамхаус. И в чем поинт про .onion в случае, если есть обычный домен с API? Я чуток посмотрел, погуглил, увидел знакомый бибилиотечный вызов. Curl - малварь с C2 в onion?
Скрытый текст
Вы извините, но слишком уж странные тезисы. С таким подходом можно что угодно обозвать малварью.
David_Osipov
Да, вы правы, что каждый отдельный индикатор можно интерпретировать как легитимный. Однако задача аналитика и ML сканера - смотреть на всю картину в целом. И вот что выходит:
1. Про упаковщик/протектор, энтропию и анти-отладку.
Использование протектора объясняет и высокую энтропию секций, и наличие анти-отладочных приемов. Но для специалиста по безопасности использование подобных упаковщиков - это само по себе огромный красный флаг. Легитимные разработчики используют их для защиты своего кода, но 99% всей малвари в дикой природе использует их для сокрытия вредоносного функционала. Когда аналитик и/или ML сканнер видит упакованный файл без подписи, он не думает: "О, разработчик защищает свою интеллектуальную собственность". Он думает: "От меня что-то прячут, и я должен выяснить, что именно".
2. Про slui.exe
Я перепроверил граф вызовов в отчете any.run. Да, MetaSkins.exe не вызывает slui.exe напрямую. Его вызывает системный сервис SppExtComObj.Exe. Это моя неточность однако этот вызов произошел во время работы вашего приложения. Это нетипичное совпадение. Почему во время работы обычного лаунчера вдруг активизируется служба защиты ПО Windows? Возможно, ваше приложение делает какой-то специфичный запрос или вызов, который триггерит эту службу. Для меня это остается подозрительным, которое требует объяснения. Само по себе это не доказывает злой умысел, но добавляет веса в общую копилку подозрительной активности.
3. Про C2, домен и .onion строки
"Как вы определили, что сервер является C2?" Когда анализируешь ПО, любой сервер, с которым приложение связывается для получения данных, функционально является C2 сервером для этого приложения. Это его "командный центр". Когда этот сервер прячется за Cloudflare, а само приложение неподписано и использует техники уклонения от анализа, любой эксперт будет рассматривать этот канал связи как потенциально вредоносный C2.
"В чем поинт про .onion?" Да, Вы говорите, что это просто часть библиотеки curl. Но вопрос не в этом. Вопрос: зачем в простом лаунчере для винды библиотека, которая умеет работать с Tor и другая библиотека, которая почему-то работает с wine? Это избыточный функционал, который непонятно почему там присутствует. Даже если вы не используете этот функционал, его наличие в коде - это уже странно.
Даже если принять все ваши объяснения, картина получается следующая:
Мы имеем приложение, которое упаковано коммерческим протектором, скрывающим его истинный код, без цифровой подписи. Это приложение использует анти-отладочные приемы и заснуло 525 раз во время анализа. Во время его работы происходят нетипичные системные вызовы (триггер slui.exe). Оно имеет функционал для доступа к буферу обмена, перехвата клавиатуры и содержит в себе код для работы с анонимной сетью Tor. Его основной домен спрятан за Cloudflare и тоже помечен, как подозрительный или вредоносный. Учитывая перегруженность аналитиков, никто не будет залезать и стараться зареверсить прогу, чтобы понять, что она делает на самом деле.
Да, ни один из этих пунктов в отдельности не является 100% доказательством, но их совокупность создает подозрительное впечатление, а антивирусным компаниям проще заблочить, чем разбираться.
boris768 Автор
Во-первых, если у вас нет экспертизы - зачем вы вообще пытаетесь спорить? Я абсолютно уверен, что вы прогоняете эти отчеты и мои ответы через нейронку, но я и без вас могу с ней по поспорить.
Далее, как вы определили наличие протектора, если его там нет? Вы хоть бы воспользовались какими-либо инструментами для анализа, IDA Pro/ghidra/Binary Ninja? Если не умеете реверсить, Detect It Easy к вашим услугам, это уж точно надежнее поверхностных ответов нейронки. Но всё же рекомендую найти руками хотя бы упаковкщик (его применение всегда очевидно), не говоря уж об обфускаторах по типу VMProtect или Themida, разница между обычным кодом и мутированным/виртуализированным с их помощью всегда видна на глаз.
Я еще раз говорю, что CURL определяет домен первого уровня ONION, и он же включен в состав самого экзешника, вот вам базовый анализ по строкам в IDA - абсолютно понятно происхождение строк. Ссылку на curl я привожу повторно
Скрытый текст
Причем тут вообще Wine - я ума не приложу, спишем на галлюцинацию нейронки.
slui.exe обычно запускается самой системой для проверки текущего состояния активации Windows, он может как сразу запуститься, так и не запуститься вовсе, это логика кода Microsoft, и вовсе не относится к какой-либо malware активности.
В общем - я жду Вашего анализа, лично Вашего, не нейронки, хоть сколько-то углубленного, ручного. Я могу даже лично с Вами пообщаться, ответить на вопросы. И прошу Вас воздержаться от использования нейронок таким образом - Вы не даете полный контекст для нее, а она в свою очередь строит выводы только лишь с Ваших слов, а не с фактуры.
David_Osipov
Интересные времена пошли, что теперь можно снизить credibility комментария натягиванием нейронки.
Я делаю свои выводы на основе двух репортов, которые выше уже мной приведены. И там, как раз, и wine_get_version есть (hybrid analysis) и slui.exe (any.run), вы, наверное, не читали репорты.
А тут у нас попытка авторитетом задавить?
А тут попытка покомандовать другим человеком.
В общем, я попытался вам помочь в силу своих возможностей. Дальше уже вам решать, что делать. Я же прекращаю тут писать комментарии.
rappelbliss
Все же хорошо, что у вас тайтл B2B Lead Product Manager
boris768 Автор
Я не вижу тут никакой Вашей помощи, не понимаю даже в чем она. Я Вам постарался объяснить на основании чего можно и чего - нельзя делать какие-либо вообще выводы, ответил по существу на все ваши вопросы. Вы же не привели ничего кроме ответов нейронки, и не нужно этого отрицать. Это не упрек, что у вас нет экспертизы - я уверен, что она есть у вас в другой области. Однако, глядя на то, что пишете лично Вы - это только самослив и нежелание разобраться руками, почему Ваши аргументы несостоятельны. Никто Вас не пытается задавить авторитетом, никто Вами не командует, да и вообще Вы свободны в принципе ничего не писать. Но строча на хабре комментарии - будьте готовы к технически подкованному сопротивлению претензиям, увы - такова площадка.
По поводу wine_get_version - напоминаю, что в файле есть Curl и он используется для тех целей, для которых и нужен сам файл - обновлять ресурсы с сервера.
По поводу slui.exe - вообще не вижу проблемы, это нормальное поведение windows - запускать механизм проверки активации.
rappelbliss
Обычное поведение при использовании Themida/VMP/иного софта
Обычное поведение при проверке прав админа
А как вы определили, что сервер является C2?
Оставлю ссылку без дополнительных комментариев