В июне 2026 г. исследователи обнаружили Android‑модуль‑скачатель, который устанавливается как обычный пользовательский пакет, но не скрывается под легитимным названием и не имеет пользовательского интерфейса. Его цель — сбор рекламного дохода и создание прокси‑ботнета. Установка происходила через встроенные обновляющие механизмы Android‑флеш‑апдейтов автомобильных головоломок (head‑unit), что впервые зафиксировано как цепочка заражения именно для такой категории устройств. По высокой уверенности в вине, за этой активностью стоит группировка MoYu, известная по ботнету BADBOX.

Ключевой вектор атаки — уязвимый компонент TWCore, системное приложение, отвечающее за сбор аналитики и обновление прошивки. Злоумышленники отправляли в MQTT‑сообщения ссылки на вредоносные APK‑файлы, размещённые на домене cardoor.cn. Один из таких файлов — bd80bd3c3d0e4bf6b5b4a825650d01f5.apk — представлял сервис JarService, который в дальнейшем использовался для загрузки дополнительных модулей и организации прокси‑трафика. Хеши легитимного TWCore, подменяемого в цепочке, составили 2a64c3efc11bf224aa54f24e876446c9, 7a4d3ba2dacccfdda55859a5dfee2671 и ea24487996eb70c1780922fb3063bcc5. Kaspersky классифицирует угрозу под названиями HEUR:Trojan-Dropper.AndroidOS.Agent.vu, HEUR:Trojan-Downloader.AndroidOS.Agent.ov, HEUR:Trojan-Proxy.AndroidOS.Zhima.* и HEUR:Trojan.AndroidOS.Vo1d.*. Таким образом, обычные обновления авто‑головоломок превратились в канал распространения мобильного вредоносного кода, способного превратить автомобильные устройства в часть ботнета.

Уязвимость связана не с Android Auto, а с дешёвыми китайскими aftermarket-головными устройствами, получающими вредоносные OTA-обновления — аналогично заражённым Android TV-приставкам. Вредоносное ПО распространяется через инфраструктуру поставщиков этих устройств, а не через протокол зеркалирования. Пользователи могут переносить заражённые USB-накопители между автомобилями, что создаёт вектор распространения. Автомобильная промышленность игнорирует базовые практики кибербезопасности: CAN-шина уязвима, OBD-порт позволяет клонировать ключи, ключевые системы работают без шифрования. Безопаснее использовать устройства, не являющиеся полноценными интернет-подключёнными компьютерами — например, простые держатели для телефона или «холсты» для CarPlay/Android Auto, исключающие собственную ОС и подключение к интернету. Вредоносное ПО в таких устройствах чаще направлено на рекламный фрод — монетизацию за счёт ресурсов устройства, а не на прямые атаки. Оптимально не подключать автомобили напрямую к интернету: лучше использовать прокси через обновляемый телефон с ограниченной поверхностью атаки.

В августе 2026 года в cargo.io появилась поддельная версия arrayref 0.3.10. В её зависимостях скрыт типосквот proc-macro1, чей скрипт сборки скачивает и запускает удалённый бинарный файл во время компиляции. Поскольку выполнение происходит на этапе сборки, любой проект, использующий эту версию, автоматически активирует вредоносный код.

Ключевой факт: злоумышленники использовали поддельный аккаунт dtolney, имитируя dtolnay, и разместили в proc-macro1 build‑script сервер‑команду hxxps://23[.]254[.]165[.]112:9089. Декодированные фрагменты указывают на адрес 23.254.165.112 и порт 9089 (payload) и 443 (C2). На Linux‑системах бинарник сохраняется в /tmp/rust-setup и запускается в фоне, а на Windows — в %TEMP%\rust-setup.ps1 через скрытый VBScript‑launcher, что позволяет процессу продолжать работу после завершения сборки.

Эти детали позволяют быстро распознать индикаторы компрометации: запросы к 23.254.165.112:9089 и 443, появление /tmp/rust-setup или %TEMP%\rust-setup.ps1. Удалённый код может выполнять любые действия, пока сборка уже завершена, поэтому важно сразу откатывать все зависимости от arrayref 0.3.10 и ниже, а также проверять целостность публикуемых crates.

Rust-экосистема уязвима к атакам на этапе сборки из-за отсутствия sandboxing для build.rs и proc-macro, слабого контроля зависимостей и чрезмерной фрагментации — что повторяет ошибки npm. Вредоносный код скрывается от сканеров, не попадая в финальный бинарник, а действуя только во время компиляции. Атаки типа left-pad (например, append-only-vec) показывают, что даже тривиальные зависимости увеличивают поверхность атаки. Необходимо: — реализовать sandboxing для build.rs (например, через Seatbelt на macOS, Landlock/seccomp на Linux, microVM или bubblewrap); — ввести min-release-age для зависимостей, чтобы дать время на обнаружение вредоносных пакетов; — требовать явного разрешения на новые build.rs и proc-macro, как в pnpm; — выполнять сборки в изолированных средах, исключающих доступ к ключам и чувствительным данным хоста; — применять статический анализ и AI-сканирование изменений перед публикацией на crates.io; — развивать стандартную библиотеку, чтобы снизить зависимость от сторонних пакетов для базовых операций; — внедрять языковые механизмы эффектной типизации для декларативного запрета сетевого доступа, FFI и записи в файл до компиляции; — использовать локальные репозитории для контроля версий, как в Conan для C++; — избегать автоматических обновлений зависимостей без проверки (пример: arrayref 0.3.10). Спор о том, хуже ли Rust, чем npm, несущественен: проблема — не в языке, а в политике управления зависимостями и отсутствии изоляции.

Я обнаружил на GitHub около 10 000 репозиториев, которые тайно распространяют троянские программы. Все они независимы, не являются форками, но используют одну и ту же схему: каждые несколько часов предыдущий коммит удаляется, а в новый добавляется лишь изменение readme — ссылка на zip‑архив. В архиве обычно четыре файла: .cmd‑скрипт, исполняемый .exe, .cso/.txt и lua51.dll. При проверке в VirusTotal архив выглядит чистым, но при загрузке самого zip‑файла обнаруживается троян.

Для поиска я использовал gharchive, собрал 16 млн пуш‑событий за неделю и выделил 3 000 репозиториев, обновляющихся каждые несколько часов. Затем добавил фильтры: коммит от реального пользователя, более месяца между последними коммитами и минимум два автора. После всех условий осталось лишь 14 репозиториев, полностью соответствующих шаблону. Это удивило меня — я ожидал тысяч, а их лишь десяток, что подчёркивает скрытый характер угрозы. Скрипт делал запросы к API и проверял каждую ревизию, и лишь несколько прошли все проверки.

К примеру, один из найденных репозиториев уже содержит ссылку на архив с более чем 1 000 загрузок, а в описании проекта написано: «Обновлено каждые несколько часов — всегда новая версия». Это показывает, что злоумышленники умеют маскировать вредоносный контент под обычный процесс обновления.

• Злоумышленники копируют популярные репозитории, меняют их содержимое на вредоносный код и используют SEO‑техники, чтобы их репозитории появлялись в топе поиска и в разделе «Последнее обновление».
• Они часто удаляют коммит и пушат новые, чтобы поддерживать высокую «активность» и попасть в тренды, а также скрыть следы изменения.
• Жертвы находят свои проекты переименованными или с перенаправлениями на вредоносные сайты, а GitHub часто не реагирует на сообщения о нарушении.
• Необходимо использовать инструменты статического анализа (semgrep, socket.dev) и проверять подписи/доказательства, а также повышать осведомлённость о рисках при использовании сторонних репозиториев.

В статье Джеймса Миккенса критикуется сложный и непонятный язык, используемый в исследованиях по безопасности. Автор приводит примеры абсурдных названий докладов вроде "Vertex-based Elliptic Cryptography on N-way Bojangle Spaces", которые начинаются посередине сложной темы без должного контекста. Миккенс сравнивает исследователей безопасности с триатлетами, тренирующимися для маловероятных сценариев, утверждая, что они сосредоточены на теоретических проблемах, а не на практических решениях.

Автор также критикует PR-навыки специалистов по безопасности, сравнивая их с "надменными подростками, слушающими готическую музыку", которые сосредоточены на потенциальных катастрофах, но не дают практических рекомендаций. Миккенс выражает разочарование, что сообщество безопасности изучает экзотические угрозы (например, управление кардиостимуляторами через банку Pringles), вместо решения более распространенных проблем, таких как создание запоминающихся, но надежных паролей.

• Обсуждение началось с цитаты из статьи Mickens о том, что если противник — это Mossad, то «вы уже мертвы» и ничего не поделаешь.
• Участники обсудили, насколько реалистично представленный сценарий, где противник — это государственная разведка, и какие угрозы реальны для обычных людей.
• Поднялась тема, что даже если Mossad не заинтересован в большинстве людей, то есть ли смысл в чрезмерной паранойе, и какие именно угрозы стоит считать реальными.
• Обсуждались примеры, когда разведки разных стран использовали вредоносное ПО или оборудование для слежки, и как это влияет на дискуссию о безопасности.
• В комментариях также поднялись темы, связанные с недавними событиями, включая взрывы пейджеров и телефонов, и обсуждалось, как это соотносится с обсуждаемыми темами.

С обновлением iOS 26 Apple изменила обработку файла shutdown.log, теперь он полностью перезаписывается при каждой перезагрузке вместо добавления новых записей. Это изменение эффективно удаляет ключевые индикаторы компрометации (IOCs) для шпионского ПО Pegasus и Predator, что создает серьезные проблемы для расследований и проверки устройств на зараженность. Файл shutdown.log был критически важен для обнаружения этих угроз, так как содержал следы деятельности вредоносного ПО даже во время выключения устройства.

В 2021 году в shutdown.log были обнаружены явные следы Pegasus, а к 2022 году злоумышленники стали более изощренными, полностью стирая файл, но даже это оставляло косвенные доказательства. Для версий iOS до 26 конкретным индикатором компрометации была запись /private/var/db/com.apple.xpc.roleaccountd.staging/com.apple.WebKit.Networking. Теперь же с обновлением до iOS 26 все эти следы автоматически удаляются, что происходит в момент, когда количество атак с использованием шпионского ПО только растет.

• Apple удаляет ключевой файл журнала shutdown.log, что лишает пользователей и исследователей единственного способа обнаружить Pegasus и другие вредоносные ПО, и это вызывает вопросы о том, насколько серьезно компания относится к безопасности и прозрачности.
• Удаление журнала делает невозможным обнаружение шпионского ПО, что особенно критично, учитывая что Apple позиционирует себя как защитник конфиденциальности.
• Некоторые комментаторы поднимают вопрос о том, что Apple может быть умышленно оставляет устройства уязвимыми для израильских хакеров, особенно в свете их истории сотрудничества с правительством США.
• Другие указывают на то, что Apple не предоставляет пользователям инструментов для проведения собственных расследований, что делает невозможным для них проверить свои устройства на наличие вредоносного ПО.
• В ответ на это, некоторые участники обсуждения предлагают, что Apple должна предоставить пользователям инструменты для проведения собственных расследований, включая доступ к полному дампу памяти, что позволило бы им проверять свои устройства на наличие вредоносного ПО.

Разработчик приложения Inkdrop получил пугающее письмо от пользователя, сообщавшего о проблеме с cookie consent, блокирующим доступ к сайту. Странно было то, что сайт приложения вообще не использует cookie consent — отслеживание и реклама отсутствуют. В ответ на запрос автора уточнить детали, пользователь прислал ссылку на "скриншот", которая вела на страницу с капчей и требованием выполнить вредоносную команду в терминале.

Команда, скопированная в буфер обмена, скачивала и выполняла удалённый shell-скрипт. Хотя Gmail пометил второй ответ как спам, первый выглядел вполне нормально. Такие фишинговые атаки становятся всё более изощрёнными, часто имитирующие реальные запросы поддержки. Даже на форумах автора появляются подозрительные посты, написанные, вероятно, ИИ, которые выглядят естественно, но содержат скрытые угрозы.

• Сообщения в треде подчеркивают, что фишинг становится всё более изощрённым: злоумышленники маскируют вредоносные ссылки под видом Google Sites, Cloudflare, Dropbox и т.д., а также используют фейковые сервисы поддержки, чтобы выманить у пользователей конфиденциальные данные.
• Участники обсуждения отмечают, что даже технически подкованные пользователи могут быть обмануты, если злоумышленник использует правдоподобные, но поддельные домены и визуально неотличимые от легитимных сервисов ссылки.
• Обсуждение также поднимает вопрос о том, что даже если пользователь не ведётся на кликбейт, то вредоносное ПО может быть скачено и запущено в фоновом режиме, если пользователь просто открыл вредонусную страницу в браузере.
• Участники также обсуждают, что в условиях, когда всё большее и большее количество людей полагаются на ИИ-ассистенты вроде ChatGPT, фишинг может стать ещё более изощрённым и трудным для обнаружения.
• Наконец, участники обсуждения подчеркивают, что важно помнить, что никакие легитимные сервисы не будут просить вас запустить что-то в терминале и что всегда стоит проверять URL-адреса, особенно если они ведут на сайты, которые вы не ожидаете увидеть.

Обнаружена первая вредоносная реализация MCP-сервера в дикой природе — пакет postmark-mcp, который с версии 1.0.16 тайно копирует все отправляемые письма на внешний сервер злоумышленника. Пакет скачивался 1500 раз в неделю и интегрировался в рабочие процессы разработчиков, получая полный доступ к почтовым данным, включая сбросы паролей, конфиденциальные документы и финансовые отчеты.

Атака основана на имперсонации: злоумышленник скопировал код официального репозитория Postmark, добавил скрытую строку BCC и опубликовал под тем же именем в npm. Уязвимость оставалась незамеченной, так как MCP-серверы работают вне периметра безопасности, обходя системы контроля DLP и инвентаризации активов. Это демонстрирует растущие риски supply-chain-атак через инструменты ИИ, которые получают привилегии без должной проверки.

• Участники обсуждают риски использования сторонних пакетов и инструментов, проводя параллели с историческими проблемами безопасности, такими как уязвимости в почтовых клиентах или SQL-инъекции.
• Высказываются предположения, что инцидент с пакетом postmark-mcp мог быть не злонамеренной атакой, а случайной ошибкой разработчика, оставившего отладочный код.
• Поднимается вопрос о доверии к ИИ-инструментам и MCP-серверам, которые получают чрезмерные права доступа к данным без должного контроля со стороны пользователей.
• Критикуется практика публикации статей, обработанных ИИ, что затрудняет восприятие и проверку фактов, а также общая культура безопасности в разработке, где скорость часто важнее надежности.
• Обсуждается ответственность платформ (например, npm) и необходимость более строгих правил для предотвращения подмены пакетов и supply chain-атак.

Компрометация пакетов ctrl/tinycolor и 40+ других в NPM

Популярный пакет @ctrl/tinycolor с более чем 2 млн загрузок в неделю был скомпрометирован вместе с 40+ другими пакетами в результате сложной атаки на цепочку поставок. Вредоносное ПО самораспространяется по пакетам maintainer'ов, собирает учетные данные AWS/GCP/Azure с помощью TruffleHog и создает бэкдоры через GitHub Actions.

Технический анализ

Атака реализуется через многоступенчатую цепочку, использующую Node.js process.env для доступа к учетным данным. Основной элемент — файл bundle.js (~3.6 МБ), который выполняется асинхронно во время npm install.

Механизм самораспространения
Вредоносное ПО через функцию NpmModule.updatePackage запрашивает API реестра NPM для получения до 20 пакетов maintainer'а и принудительно публикует обновления, создавая каскадный эффект компрометации.

Сбор учетных данных
Используются инструменты вроде TruffleHog для сканирования файловой системы на наличие секретов. Целевые учетные данные включают:

• Токены доступа GitHub
• Ключи доступа AWS
• Учетные данные Google Cloud Platform

• Пользователи выражают обеспокоенность невозможностью аудита всех зависимостей и их уязвимостью к атакам в npm.
• Критикуется архитектура npm, в частности выполнение postinstall-скриптов по умолчанию, в отличие от других менеджеров пакетов.
• Предлагаются решения: игнорирование скриптов в настройках, песочница (bubblewrap), использование подписей кода и каррированных пакетов.
• Указывается на системную проблему экосистемы JS: огромное количество мелких зависимостей и отсутствие сильной стандартной библиотеки.
• Обсуждается масштаб атаки (180+ пакетов) и её возможная связь с государственными акторами.
• Поднимается вопрос уязвимости других экосистем (PyPI) и необходимости обязательной 2FA и подписи артефактов.
• Высказываются радикальные предложения по замене npm или созданию безопасного форка/дистрибутива пакетов.

running-qix-malware
Репозиторий демонстрирует работу вируса QIX (1989) в эмуляторе DOS.

• Собранный DOS-бинарь запускается в браузере через эмулятор.
• Исходники на ассемблере и C, скрипты сборки.
• Инфицирует .COM-файлы, показывает бегущую линию.
• Безопасен: эмуляция изолирует вредоносный код.

• Участники вспомнили про инцидент Jia Tan и пожаловались, что npm до сих пор не автоматически блокирует публикации с обфусцированным кодом и шестнадцатеричными именами.
• Предложены меры: предпубликационный сканер с «задержкой на проверку», 2FA-апрув каждого релиза, опциональный «verified»-бейдж и поддержка Yubikey.
• Сомнения в пользе LavaMoat: не спасает от DLL в lifecycle-скриптах, не работает с Webpack HMR, а изоляция может быть дорогой.
• Обсуждали lock-файлы: хэши в package-lock защищают от перезаписи версии, но теги git всё ещё можно подменить; иммутабельность npm-тарболлов считается основной защитой.
• Namespaces (@scope) в npm есть с 2016 г., но «красивые» безскоповые имена всё ещё популярны, поэтому переход идёт медленно.