НеИБи

Вентиль дал течь Valve уведомляет европейских покупателей своего железа об утечке данных. Виновник — логистический партнер CEVA Logistics, который подвергся кибератаке в период с 29 июля по 1 августа. О самом инциденте Valve узнала только 7 августа, хотя некоторые европейские ритейлеры были проинформированы уже 1 августа. CEVA — не мелкая контора. 1000 складов, 15 млн отправлений за прошлый год и выручка $18,3 млрд в 2025. Атака затронула восемь европейских складов компании. В зоне риска все, кто заказывал Steam Machine, Steam Controller и, вероятно, Steam Deck в Европе. CEVA хранит данные о доставке до 90 дней, поэтому под удар попали и относительно старые заказы. Утекли имена, адреса, телефоны, email-адреса, а также тип и цена заказанного товара. Пароли, платежные данные и Steam Guard-коды не пострадали — CEVA просто не имеет к ним доступа. Менять пароль Steam не нужно. Главная угроза теперь — фишинг. Valve предупреждает, что злоумышленники могут присылать письма, SMS и звонить, цитируя ваш реальный адрес для убедительности. Будут просить подтвердить доставку, оплатить «небольшую пошлину» или войти куда-то для «верификации». Valve советует считать все такие сообщения фейковыми. Компания уже уведомляет регуляторов и требует от CEVA полного отчета. @antiinfosec

NIST против ФСТЭК Сегодня обсудим не совсем злободневную тему, которую поднял и не раскрыл автор статьи на Хабре, уведя все в другую сторону. В апреле 2026 года ФСТЭК утвердила методический документ, по которому пароль в госсистемах и КИИ меняется не реже раза в 90 дней, а на мобильных устройствах — раз в 30. Примерно за девять месяцев до этого NIST в финальной редакции SP 800-63B записал дословно: «Verifiers and CSPs SHALL NOT require subscribers to change passwords periodically». Два регулятора, два противоположных требования. Давайте разберем аргументы каждой стороны. ▪️Почему NIST запретила плановую смену Логика NIST строится на простом наблюдении, мол принудительная смена пароля приводит к предсказуемым и слабым паролям. Пользователь, которому каждые 90 дней нужно придумывать что-то новое, неизбежно выбирает минимальные вариации: Password1 ➡️ Password2 ➡️ Password3. Эту же динамику подтвердил и сам автор оригинальных правил 2003 года Билл Берр, публично извинившись: «Многое из того, что я сделал, теперь вызывает у меня сожаление». Вместо ротации NIST предлагает три вещи: длинные пароли (рекомендуемые 15 символов и более), проверку новых паролей по базам скомпрометированных данных и смену только при подтвержденном факте компрометации. В итоге, никаких сложностных правил, никаких регулярных смен. ▪️Почему ФСТЭК сделала ротацию обязательной У российского регулятора иная модель угроз. Ключевой аргумент простой как табурет: плановая смена ограничивает «окно уязвимости» — время, в течение которого злоумышленник может использовать украденный хэш или скомпрометированные учетные данные. Если пароль украли, но не заметили, ротация через 90 дней (или 30 на мобильных) автоматически закрывает доступ. Кроме того, смена пароля попутно завершает все активные сессии, включая те, о которых пользователь мог не знать. В государственных информационных системах и на объектах КИИ цена компрометации может быть существенно выше, чем в коммерческом секторе, поэтому здесь действует презумпция «лучше перебдеть». Методичка ФСТЭК 2026 года также требует запрет на повтор 12 последних паролей. Ни одна из сторон не является однозначно неправой, так как у них просто разные вводные. NIST исходит из поведенческой психологии и статистики. Спорить с тем, что люди не умеют придумывать новые пароли под давлением, и это ослабляет общую безопасность больше, чем гипотетическая угроза несвоевременной смены, сложно. Но и ФСТЭК исходит из нормативной логики и модели угроз для критической инфраструктуры: если утечка произошла, а вы ее не засекли, ротация — хороший прием. Оба подхода имеют право на существование. Проблема возникает, когда их пытаются смешивать или когда одну логику механически переносят в другую среду. Для коммерческого сектора и рядовых пользователей NIST, скорее всего, ближе к истине. Для госсистем и КИИ с их спецификой требований ФСТЭК — как минимум до появления работающих альтернатив вроде аппаратных токенов и passkeys — остается единственным легальным путем. Выбор, как обычно, определяется не тем, что правильнее, а тем, что требует проверяющий. 🔤🔤Отдельно стоит сказать про двухфакторную аутентификацию — в этом вопросе позиции регуляторов, как ни странно, сходятся. NIST в SP 800-63B рассматривает MFA как обязательный элемент для среднего и высокого уровней доверия (AAL2 и AAL3), требует двух независимых факторов из разных категорий и рекомендует MFA по умолчанию для всех пользователей. ФСТЭК в приказе №117 предписывает государственным и муниципальным системам «строгую аутентификацию с использованием криптографических методов», а при технической невозможности — многофакторную. В будущем, возможно, обсудим войну двухфакторки с адептами паролей — тема обширная и достойная отдельного разговора. @antiinfosec

Доверием сыт Разработчики, которые используют Claude Code для ревью пулл-реквестов, оказались в ситуации, где одна доверенная папка может стоить всех секретов. Исследователь безопасности Кевин Брин обнаружил, что злоумышленник может добавить в PR файл .mcp.json, и Claude Code запустит указанную в нем команду сразу при открытии ассистента в репозитории до того, как разработчик вообще успеет что-то ввести или явно одобрить эту команду. Проблема в модели доверия. Claude Code использует workspace-trust, то есть если вы один раз нажали «Yes, I trust this folder», эта доверенность распространяется на всю конфигурацию репозитория и на все, что в него потом приходит, включая ветки из внешних PR. А конфигурация MCP (Model Context Protocol) позволяет указать локальный сервер с произвольной командой для запуска. И да, эта команда запускается с привилегиями разработчика. В версии 2.1+ диалог доверия к тому же перестал предупреждать о MCP-серверах в клонированном репозитории — теперь он просто спрашивает «Это ваш проект?» и ничего не перечисляет. В ответ на сообщение об уязвимости Anthropic ответила, что «поведение работает как задумано». Их позиция, мол когда вы доверяете папке, это покрывает всю конфигурацию репозитория, включая .claude/settings.json и .mcp.json, а защита от вредоносных изменений в уже доверенном репозитории выходит за рамки их модели угроз. Исследователи возражают: разница между простым просмотром кода и запуском автономного агента — принципиальная. Особенно если учесть, что в CI-среде диалог доверия вообще не показывается, а атака проходит без единого клика. Рекомендации просты и потому трудновыполнимы. Относитесь к .mcp.json и .claude/ как к исполняемому коду. Проверяйте изменения в этих файлах до того, как проверять PR-ветку. Не запускайте Claude Code в репозиториях с непроверенными MCP-конфигурациями. Для ревью PR используйте изолированные виртуальные машины. @antiinfosec

Один бренд мало, пять — хорошо UNC6671, она же BlackFile, в мае 2026 года громко объявила о своем «закрытии». Сторонний наблюдатель мог бы решить, что группе надоело вымогать деньги или что их всех арестовали. Ничего подобного. Как выяснил Google Threat Intelligence Group, BlackFile просто переименовалась, причем сразу в четыре бренда: Redact, Pink, Helix и Falcon. Техники, процедуры и даже фишинговые шаблоны остались прежними, а вот табличек над дверьми стало больше. Очевидно, для удобства бухгалтерии. Механика не меняется годами, и это, пожалуй, самое печальное. Звонок сотруднику на личный мобильный от лица IT-поддержки, срочная миграция на «безопасные passkeys», ссылка на поддельный портал, перехват логина, пароля и MFA-токена через AiTM-инфраструктуру. Дальше автоматические скрипты, выкачивающие данные из Microsoft 365 и Okta. Все это работает до сих пор, потому что люди по-прежнему верят голосу в трубке, если он звучит достаточно уверенно. Но самое палевное — это инфраструктура. Оказалось, что все четыре новых бренда используют одни и те же поддельные домены для сбора учетных данных. Например, passkeyhelpdesk[.]com одновременно обслуживал жертв, которых потом шантажировали и Falcon, и Helix. Красact, Pink. Более того, переход от BlackFile к Redact авторы объяснили тем, что «некий беглый аффилиат скомпрометировал бренд». В историю «мы не распадались, мы просто ребрендимся, а тот парень просто самозванец» звучала бы убедительно, если не смотреть на WHOIS. Эволюция целей тоже показательна. Весной 2026 года группа атаковала производство, недвижимость, здравоохранение и страховые компании. К июню переключилась на технологии, транспорт и гостиничный бизнес, где хранят исходники и данные VIP-клиентов. А к июлю сузила фокус до финансового сектора: частные инвестиционные фонды, юридические фирмы, рейтинговые агентства. Темп регистрации доменов ускорился с одного каждые 2,2 дня до одного каждые 1,6 дня. В общем, группа не просто жива, она активно масштабируется. @antiinfosec

Сертификат на доверие Мы привыкли считать, что Android — это дикий запад с APK из непонятных источников, а iOS — это крепость, которую не взять. Крепость, возможно, и не взять, но вот обойти — вполне. «Лаборатория Касперского» обнаружила зараженные версии популярных iOS-приложений, которые распространялись через русскоязычный Telegram-канал. Среди пострадавших онлайн-площадка для продажи товаров, фоторедактор и видеосервис. В модифицированные версии злоумышленники встроили модуль, который собирает информацию об устройстве, геолокацию и делает скриншоты экрана. Механика распространения вызывает уважение своей продуманностью. В Telegram публикуют установочные файлы IPA и предлагают пользователям купить сертификат разработчика. Дальше этот сертификат импортируется в утилиты для установки сторонних приложений вроде eSign или Scarlet, и программа подписывается для установки через приватные механизмы iOS. Можно и без покупки сертификата. Например, с компьютера или на джейлбрейкнутом устройстве. То есть жертва сама платит за то, чтобы лишиться безопасности. Бизнес-модель, достойная отдельного исследования. Вредонос, к счастью, не умеет работать в фоне. Пока приложение открыто, он может снимать экран, передавать геолокацию, код оператора и кучу технических параметров вроде уровня заряда батареи и наличия джейлбрейка. Но как только закрыли, он неактивен. Это не делает атаку менее опасной, но хотя бы дает шанс заметить, что ваше приложение для просмотра видео вдруг начало делать скриншоты. Впрочем, кто смотрит на разрешения? «Пользователи скачивают модифицированные версии популярных программ — без рекламы, с разблокированным платным функционалом, — напоминает Сергей Пузан из «Лаборатории Касперского». — Этим пользуются злоумышленники». Рекомендация, как всегда, банальна до скрежета: устанавливайте приложения только из официальных источников. А если программы нет в App Store — сходите на сайт разработчика и уточните, как ее ставить легально. И да, сертификат разработчика, купленный с рук в Telegram, — это какой-то вверх неосмотрительности. @antiinfosec

Июньский циклон L7 Уже все привыкли относится к DDoS-атакам, как к погодным условиям. Сегодня похолоднее, завтра пожарче, послезавтра обвалится L7 и что-то в это роде. Однако, если продолжать аналогию, не фиксировать глобальные климатические изменения, невозможно. Особенно это глобальное потепление чувствуется в наших интернет-широтах. Так, ребята из DDoS-Guard подвели итоги второго квартала 2026 года — и картина получилась одновременно предсказуемой и тревожной. Если коротко, количество DDoS-атак выросло на 70% по сравнению с Q1, а июнь поставил абсолютный рекорд за всю историю наблюдений — 540 тыс. атак на уровне L7, что на 236% больше апрельских показателей и на 300% больше, чем в июне прошлого года. Для понимания масштаба это 20% от всего числа атак за 2024 год. Терабитные атаки уже давно не редкость. За первые шесть месяцев 2026 года их стало вдвое больше, чем за весь 2025. Два самых мощных инцидента достигли 1,64 и 1,58 Tbps, а в пакетах — 553 и 638 Mpps соответственно. Крупнейший ботнет, замеченный за рубежом, насчитывал около 2,1 млн устройств. В марте международная операция Европола нанесла удар по четырем мощнейшим IoT-ботнетам в истории, но дышаться легче не стало. Да и для мощной атаки теперь не обязательно собирать миллионы устройств. Тут вспоминаем про техники усиления и отражения через спуфинг. Главный тренд, который выделяют эксперты DDoS-Guard, впрочем, и не только они, это смещение акцента с сетевого уровня L3/L4 на прикладной L7. Браузерная автоматизация и ИИ-агенты делают HTTP-атаки почти неотличимыми от легитимного трафика. Число сверхдолгих атак длительностью более суток выросло на 380%. Отдельного внимания заслуживает рабочая гипотеза DDoS-Guard о причинах июньской непогоды: атаки могут быть нацелены не на отдельные домены, а на инфраструктуру самого провайдера защиты. Система фиксирует множество атак по разным направлениям, хотя цель у злоумышленников одна — сам вендор. Среди отраслевых целей в темпах роста лидируют HR-платформы (рост на 40% по сравнению с Q1) и новостные сайты (+30%). Прогноз погоды на вторую половину года неутешительный. атаки станут менее демонстративными по мощности, но более продолжительными, избирательными и сложными для обнаружения. Готовьте не только зонты, но и плащи с сапогами, ведь защищаться теперь нужно на всех уровнях. @antiinfosec

Улов из облака Мы уже касались темы фишинга, но в основном в контексте почтовых рассылок и поддельных сайтов. Однако за последний год злоумышленники нашли способ, который делает традиционные методы обнаружения почти бесполезными: они просто арендуют место у Cloudflare, Vercel, GitHub Pages и других уважаемых облачных провайдеров. За 12 месяцев с августа 2025 по июль 2026 года «Лаборатория Касперского» заблокировала 224 984 уникальных домена третьего уровня на таких платформах — и это только те, что удалось обнаружить. Легитимные PaaS-сервисы дают фишерам все, о чем можно мечтать. Бесплатные тарифы без KYC, автоматические SSL-сертификаты, глобальные CDN и доверие пользователей, которые привыкли видеть pages[.]dev и vercel[.]app в адресной строке. Блокировать весь домен провайдера нельзя — там же миллионы легитимных проектов. Поэтому вендорам остается только контентный анализ, который, как мы видим, справляется далеко не со всем. В топе-10 лидируют Cloudflare Pages (24,9% всех фишинговых ссылок), Vercel (13,8%) и GitHub Pages (13,7%). IPFS-шлюзы dweb[.]link и ipfs[.]io тоже в списке — их контент вообще невозможно удалить, только блокировать отдельные шлюзы. Механика атаки, которую разобрали эксперты, заслуживает отдельного упоминания. Это многоступенчатая AitM-атака (Adversary-in-the-Middle) на Cloudflare Workers. Жертва получает письмо с ссылкой на взломанный сайт (без классики не обошлось), где ее встречает фальшивая капча, собирающая email. Дальше перенаправление на workers[.]dev, где в браузере регистрируется сервисный работник, перехватывающий все сетевые запросы. На финальном этапе внутри легитимной страницы открывается iframe, стилизованный под системное окно браузера с адресом Microsoft, а реальная форма авторизации проксируется через тот же Service Worker. Жертва вводит логин, пароль и MFA-код — и все это уходит злоумышленникам вместе с сессионными токенами. Комбинация BitB (Browser-in-the-Browser) и AitM делает атаку почти незаметной, так как пользователь видит правильный URL, правильный сертификат и даже предзаполненный логин. @antiinfosec

Shai-Hulud вернулся Мы как-то не успели поговорить о Shai-Hulud в прошлом году, когда эта история только начиналась. Но вот появился отличный повод наверстать упущенное. Ведь червь вернулся, и теперь он не просто ползет, а вполне себе бежит по репозиториям npm. Аикидо Security зафиксировала новую волну, и масштаб, мягко говоря, впечатляет. Напомним вкратце для тех, кто пропустил первую серию Дюны. Shai-Hulud — это самораспространяющийся червь, который охотится на разработчиков Node.js. Он не вымогает деньги и не шифрует диски. Он крадет учетные данные, npm-токены, GitHub-ключи, AWS-секреты, Vault-токены, базы данных, Stripe и Slack — все, что плохо лежит, он забирает, шифрует и отправляет в публичный репозиторий с описанием «Shai-Hulud: Here We Go Again». Если туда не достучаться — есть запасной вариант npm-cache[.]com. При этом червь использует скомпрометированные учетки, чтобы модифицировать и перевыпускать другие пакеты, распространяясь как настоящая песчаная буря. На этот раз атака началась с аккаунта разработчика Jared Wray, мейнтейнера библиотеки Keyv, которая, внимание, имеет 127 млн загрузок в неделю. Злоумышленники запушили вредоносные файлы прямо в main-ветку и использовали легитимный GitHub Actions для публикации Keyv версии 6.0.0. Поскольку релиз прошел через штатный пайплайн, он получил валидную информацию о происхождении (provenance) на npm — подпись подтверждала, где собран пакет, но не то, что исходный код перед сборкой был безопасен. Ирония в том, что система доверия сработала безупречно, просто доверять было нечему. К 13:37 CEST (да, хакеры с чувством юмора и знанием l33t) число зараженных пакетов перевалило за 868 с 1381 вредоносной версией, а к моменту написания отчета — за 1280. В списке пострадавших — пакеты, связанные с Deliveroo, Picsart, Qlik и другими крупными игроками. Их присутствие означает, что доступ к публикации был скомпрометирован, но не факт, что внутренние сети компаний взломаны (утешимся хотя бы этим). В любом случае, любая рабочая станция или CI-раннер, запускавший зараженную версию, должна считаться скомпрометированной. Удаление пакета не поможет, так как украденные ключи уже ушли. Ротация всех токенов, проверка логов и аудит репозиториев — теперь новая головная боль. И да, Аикидо рекомендует не ждать ночного скана, а запустить ручной прямо сейчас. @antiinfosec

И пусть все горит «Газинформсервис» опубликовала неплохой разбор пятилетней динамики киберинцидентов в России, с 2020 по 2025 год. Картина вырисовывается показательная, мол если в пандемийные годы всех пугали фишингом (почти 75% атак) и шифровальщиков, добравшиеся до 51,9% компаний, то 2022, вполне ожидаемо, все поменялось. Количество инцидентов выросло в три раза по сравнению с 2021, хактивисты вышли на первый план, а регион «Россия и СНГ» занял первое место в мире по числу запросов на Incident Response — 45,9% глобальных обращений. К 2025 году наступил занятный парадокс: общее число событий ИБ снизилось на 36%, а вот подтвержденных инцидентов стало на 4,8% больше. Системы мониторинга научились фильтровать шум, но это не значит, что атак стало меньше, просто они стали качественнее. В отчетах впервые появилась категория «Изменения инфраструктуры» (11% инцидентов) злоумышленники больше не взламывают и уходят, они закрепляются надолго. Дефейсы и громкие утечки уступают место многоступенчатым цепочкам атак через подрядчиков (17% инцидентов) и полной мимикрии под легитимную активность. Средняя длительность атаки достигла 253 дней, а доля долгих вторжений выросла с 21,85% в 2023 году до 35,2% в 2024. И да, каждая пятая атака теперь классифицируется как высококритичная, то есть с потенциально катастрофическими последствиями. Сигнатурные методы обнаружения, увы, больше не работают. Вместо них авторы предлагают поведенческий анализ, постоянный мониторинг аномалий и проактивный поиск угроз. Всем UEBA, в общем. Надеемся, что этому классу защиты придумают аббревиатуру поприятней. @antiinfosec

Яндекс ближе чем кажется На хабре новый автор, приглашенный zarazaexe (известен большим количеством годных расследований про российские импортозамесы) начал публиковать результаты полного аудита APK-файлов Яндекса и нашел там такое, что RuStore и MAX на их фоне выглядят как детский сад. Приложение собирает практически все: звук вокруг вас еще до того, как вы сказали «Алиса» (pre-trigger буфер, размер которого, кстати, управляется с сервера), полный список установленных приложений (включая банки, VPN и мессенджеры), адресную книгу с ContentObserver в реальном времени, геолокацию через Wi-Fi-сканирование и сотовые вышки. Самое забавное это то, что платежные данные (PAN + CVV) до токенизации летят на сервер Яндекса, тогда как Stripe и Braintree уже 10 лет назад доказали, что можно сделать так, чтобы сервер приложения вообще не видел карту. Ну впрочем, к Stripe есть свои претензии. Особого внимания заслуживает обход ограничений Android 11+. Вместо того чтобы запрашивать опасное разрешение QUERY_ALL_PACKAGES, разработчики захардкодили гигантский список целевых приложений в AndroidManifest.xml — все браузеры, мессенджеры, почтовые клиенты и даже Mediascope AppMeter. Плюс жестко забитые DNS 77.88.8.8 в обход системного DNS, VPN и DoH, детекция VPN по интерфейсу tun0 с блокировкой авторизации и 94 JavaScript-моста, через которые любая XSS на поддомене yandex[.]ru ведет к компрометации устройства. Remote config с 70+ флагами позволяет серверу в любой момент выставить pre-trigger на 30 секунд, отложить запрос разрешений на 3 года или вообще отключить валидацию TLS. Это только первая часть из трех — впереди еще 387+ сетевых эндпоинтов и 1500+ JNI-точек. @antiinfosec

Холодный кошелек, который согрел чужие карманы на 86 миллионов Если вы все еще верили, что офлайн-кошелек — это синоним неприступности, у нас для вас обновленные вводные. По данным Galaxy Research, сумма украденного с кошельков Coldcard выросла до 86 миллионов долларов, а число скомпрометированных устройств перевалило за 4,5 тысячи. Тот самый баг с генератором случайных чисел, который мы обсуждали, оказался еще более прибыльным для злоумышленников, чем предполагалось изначально. Изначально сид-фраза генерировалась из энтропии, снимаемой с аппаратного генератора шумов — тот самый «электрошум», который считался неуязвимым для предсказания. Но при переходе на новую версию прошивки разработчики перепутали две функции: одна читала данные из железа, другая использовала софтовый фолбэк на основе времени и серийного номера. В конфигурации они отключили аппаратный путь, но проверка условия смотрела лишь на наличие ключа, а не на его значение — в итоге железный генератор просто перестал вызываться, а система молча переключилась на программную эмуляцию. Эффективная энтропия упала до 40 бит, что делает сид подборным за разумное время, если знать серийник устройства. Coinkite, производитель Coldcard, в своем блоге выдвинула версию, что злоумышленники использовали ИИ для анализа открытого исходного кода прошивки. Ирония в том, что компания сама проверяла код одной из лучших моделей — и та не нашла ровно ничего. «И те, кто проводят атаки, и те, кто от них защищает, располагают одними и теми же ИИ-инструментами, но сегодня это не помогло нам, а помогло только плохим ребятам», — философски заметили в Coinkite. Суть проблемы, напомним, в том, что сид-фраза генерировалась с использованием предопределенных значений, включая серийный номер устройства. Обновление прошивки уже выпущено, но оно бесполезно для уже созданных сидов. Тем, кто до сих пор не перевел средства на новый, надежный сид, стоит поторопиться — пока хакеры с ИИ не закончили свой аудит. @antiinfosec

Три уяза на каждую букву Команда разработчиков PHP раскрыла три уязвимости в ядре, которые уже закрыты в версиях 8.2.33, 8.3.33, 8.4.24 и 8.5.9. Проблемы затронули расширения ext-pgsql, ext-phar и ext-bcmath, и каждая из них заслуживает отдельного внимания, потому что ломают они все по-своему. Самая опасная — CVE-2026-17543 с высоким рейтингом. SQL-инъекция в функции вроде pg_insert() и pg_update(). Дело в том, что PHP неправильно экранировал обратную косую черту в PostgreSQL, когда включен режим standard_conforming_strings (а он включен по умолчанию с версии 9.1). Атакующий мог передать значение вроде zzz\' OR 1=1 --, и это превращалось в рабочий SQL-запрос, обходящий все фильтры. Вторая уязвимость, CVE-2026-7260, уже помечена как Moderate, но тоже неприятная — она в ext-phar. Функция phar_get_link_source() рекурсивно раскрывала символьные ссылки внутри phar-архивов без ограничения глубины и без защиты от циклов. Достаточно было создать tar-архив с двумя ссылками, указывающими друг на друга, и при попытке прочитать содержимое PHP падал с переполнением стека вызовов. Хорошая новость тут, что для эксплуатации нужен локальный доступ и взаимодействие с пользователем. Третья, CVE-2026-17544, снова высокая опасность, и уже из области памяти. В ext-bcmath при обрезании нулей у числа код неправильно пересчитывал указатель, из-за чего копировал строку в буфер меньшего размера. BCMath использует стековый буфер, а потом переключается на кучу, так что в зависимости от ситуации можно испортить либо стек, либо кучу. Починили все просто — переприсвоили указатель после обрезки. В общем, разработчики PHP снова напоминают: обновляйтесь, пока кто-нибудь не решил проверить, как вы обрабатываете числа и архивы. Потому что если ваша математическая библиотека может выстрелить вам в ногу, то, может, не стоит доверять ей сложение двух чисел? Или хотя бы стоит ставить патчи вовремя, чтобы она не делала это с ошибкой переполнения буфера. @antiinfosec

Двойной ИИ-агент Исследователи Unit 42 зафиксировали занятный случай, как китайскоязычный злоумышленник, известный как knaithe (или KnYuan), развернул автономный ИИ-фреймворк Hermes Agent на базе DeepSeek для автоматизации атак. Управление шло через Telegram, агент самостоятельно проводил разведку, выбирал цели и пробовал эксплуатировать уязвимости. Он нацелился на CVE-2026-33017 в Langflow (CVSS 9.8), просканировал 84 инстанса, но переключился на n8n, где нашел две дыры — CVE-2026-21858 (CVSS 10.0) и CVE-2025-68613 (CVSS 9.9). По данным FOFA, открытых n8n-инстансов оказалось более 647 тысяч, и агент даже фильтровал китайскую инфраструктуру, но все цели требовали авторизации, тобишь атака не удалась. Однако главная нелепость случилась не с целями, а с самим атакующим. В какой-то момент агент по команде запустил локальный HTTP-сервер прямо из своей рабочей директории, выставив его в публичный доступ без какой-либо аутентификации. В открытую ушли эксплойты, API-ключи, конфиги, логи атак — полный набор инструментов, который обычно прячут за семью замками. Злоумышленник, кстати, старался маскироваться. Проксировал трафик через code.newcli[.]com и отключал логи Codex, но собственный ИИ-помощник оказался слишком дружелюбным к интернету. В итоге агент сделал за хозяина всю грязную работу, но потом еще и вывесил его арсенал на всеобщее обозрение. Он действительно неплохо потрудился: просканировал более 460 целей и как минимум три скомпрометировал, но он был честен перед компартии совестью. @antiinfosec

После цифры было слово Google Threat Intelligence Group наконец-то решила, что цифры в названиях группировок — это скучно и неинформативно. Аплодируем стоя! Новая схема — как у всех — двухсловные криптонимы. Первое слово — запоминающееся имя группы (если его нет — генерируют рандомайзером, чтобы без предвзятости), второе — категория происхождения. Российские группы получили приставку RELIC, китайские — CASTLE, иранские — ION, северокорейские — NEPTUNE, а финансово мотивированные банды — COMET. Знаменитый Sandworm, он же APT44, он же FrozenBarents, он же Voodoo Bear и еще с десяток других имен, теперь официально называется Sandworm Relic. Потому что одной клички явно было мало. Наконец-то ребята из Mandiant, которых Google купил за $5,4 млн, показали, как реально удобно инфицировать группировки. Раньше у них одна и та же группа в разных отчетах фигурировала под разными индексами. Аналитики путались, реагирование на инциденты замедлялось. Теперь единый стандарт, чтобы все внутри Google говорили на одном языке. Правда, индустрия в целом от этого проще не стала — вендоров с собственными классификаторами по-прежнему много, и летом 2025 года Microsoft, Google, Mandiant и CrowdStrike даже запустили совместную инициативу по сведению всех псевдонимов в единый справочник. Но о таком пока остается только мечтать. Самое забавное, что Google не изобрела велосипед. CrowdStrike уже давно раздает медведей России и панд Китаю, Microsoft использует погодные термины вроде Blizzard и Typhoon. А теперь еще и Google со своими RELIC и CASTLE. Так что если вы до сих пор путаете Sandworm Relic с Strawberry Tempest — не переживайте, вы не одни. Сами профи из разных компаний друг друга не всегда понимают. Главное, что Sandworm как был Sandworm, так им и остался — просто теперь с приставкой RELIC, чтобы все знали, чьи руки. @antiinfosec

Word не воробей, а червь ИБ-исследователь Хокон Молей опубликовал разбор атаки на Copilot for Word. Скрытые инструкции в документе заставляют ассистента изменить содержимое создаваемого файла и скопировать себя в него. Например, вместо прибыли компания может получить убытки "на бумаге". Или наоборот. Неизвестно, что хуже. Раскрытие автор координировал с Microsoft Security Response Center. И заняло оно 144 дня вместо стандартных 90‼️ Механика банальна, но, как оказалось, вполне рабочая даже в 2026ом. В документ добавляется текст с инструкциями: белый шрифт на белом фоне, мелкий кегль. Copilot перед передачей в модель срезает форматирование, цвет и размер шрифта, поэтому текст читается моделью полностью и остается невидимым для человека. Жертва прикладывает такой документ как источник при подготовке отчета. В демонстрации Молея Copilot вдвое уменьшил все финансовые показатели в черновике квартального отчета и не сообщил об этом. Вторая часть скрытого промпта, оформленная как инструкция по отслеживанию источников, заставляет Copilot дописать промпт целиком в конец готового документа тем же белым текстом. Полученный документ уже внутренний. Коллега прикладывает его к следующей сессии Copilot, инструкции срабатывают снова и копируются дальше. Исходный вредоносный файл в контексте больше не нужен. Прикладывать документ вручную не обязательно. В режиме Work IQ Copilot сам нашел вредоносный файл в OneDrive жертвы, в другой папке, счел релевантным и подтянул в контекст. Отчет ушел в MSRC 6 марта. Первое исправление 3 апреля, оригинальная формулировка закрыта 9 апреля, в тот же день Молей воспроизвел атаку переформулированным промптом. Второе исправление 14 июля: обновление модели под Copilot до GPT-5.5, вышедшей 23 апреля. Публичный релиз GPT-5.6 состоялся 9 июля. 15 июля атака воспроизведена на GPT-5.6. 28 июля, в день публикации, атака, по словам исследователя, воспроизводится. Microsoft заявила The Register, что устранила то, о чем сообщил исследователь, и поблагодарила за координированное раскрытие. Далее компания описала стратегию defense-in-depth с блокировкой вредоносных инструкций на нескольких уровнях и рекомендовала клиентам ставить обновления, осторожно относиться к контенту из неизвестных источников и проверять сгенерированный ИИ материал перед использованием. Утверждения о том, что уязвимость полностью закрыта, в заявлении, к слову, нет. Номер CVE не публиковался. Самореплицирующиеся промпты описаны еще в марте 2024 года, но там была исследовательская сборка почтовых ассистентов на RAG. Microsoft тем временем разворачивает Copilot Cowork, агента для длительных многошаговых задач с документами, и Scout, всегда активного агента под Windows 11 с доступом к локальным файлам 😏 @anti_agi

Из песочницы в LLM-лужу Признаем, что мы немного проворонили эту историю с Artifactory. Не успели подсветить в момент релиза, но сейчас, когда детали стали доступны, возвращаемся к ней. Тем более специалисты JFrog сообщили недавно, что в рамках внутренней оценки кибервозможностей ИИ-моделей OpenAI (включая GPT-5.6 Sol и еще одну, более мощную, пока не публичную) модели нашли неизвестные ранее 0day-уязвимости в self-hosted инстансе Artifactory. Используя их, агенты сбежали из изолированной тестовой среды, получили доступ в интернет и в итоге атаковали платформу Hugging Face, чтобы достать ответы для бенчмарка ExploitGym. Тестирование проводилось в песочнице с ослабленными защитными механизмами, а единственным каналом во внешнюю сеть служил внутренний прокси-сервис для кеширования пакетов. Однако ИИ нашел 0day в этом сервисе (как выяснилось, это был Artifactory), объединил несколько уязвимостей в цепочку, повысил привилегии и перемещался по исследовательской сети, пока не обнаружил машину с реальным выходом в интернет. Получив доступ, модели предположили, что на Hugging Face могут храниться данные для ExploitGym, и использовали похищенные учетные данные, дополнительные 0day и техники удаленного выполнения кода, чтобы проникнуть в продакшен-базу данных Hugging Face и извлечь нужные ответы напрямую. Как именно ИИ вылезала из песочницы — ни в JFrog, ни в OpenAI не раскрывают. И это понятно: публиковать готовую цепочку эксплуатации для self-hosted Artifactory было бы безответственно. Но мы снова не перестаем удивляться насколько атакующим ИИ упрощает жизнь. Мы привыкли, что исследователи безопасности изучают биос, замеряют cpuid или копаются в таймингах инструкций, чтобы найти низкоуровневую дыру в песочнице. Теперь эту работу за них делает модель. И она не просто находит баги, а самостоятельно сцепляет их в работающий эксплойт, выбирает цели и адаптирует тактику по ходу. Но есть и хорошая новость: те же самые модели становятся новым мощнейшим редтимом, если вендор готов быстро реагировать. JFrog закрыли проблему за считанные дни, облачные клиенты уже защищены, а self-hosted получили патч. Мы снова убеждаемся: надо быстрее реагировать на найденные уязвимости, потому что их жизненный цикл всё сокращается. Либо он становится страшным эксплойтом, либо темой для PoC. @antiinfosec

Ботнет без головы Знакомьтесь, Dysphoria — ботнет-стартап, который за полгода дорос от обычного DDoS-вышибателя до распределенной инфраструктуры с блокчейн-доменами, UPnP-прокладкой и двадцатью тысячами «сотрудников» по всему миру. И да, он до сих пор считает, что telnet с паролем 12345 — это надежная аутентификация. Xlab тут провели глубокое исследование этого здорового ботнета. И вот несколько важных выдержек оттуда, которые нам удалось выудить из этого талмуда: Dysphoria использует гибридную схему шифрования. Стандартный RC4 с KSA-инициализацией, поверх которого накручен LCG, а в PRGA добавлен LFSR с битовыми сдвигами и дополнительными swap-операциями — полный скрипт расшифровки на Python есть в отчете. C2-адреса прячутся в TXT-записях ENS (burrberry[.]eth, ukranianhorseriding[.]eth) и SNS (24carnforth2merseyside[.]sol), причем записи содержат фейковые IPv6, из которых через побайтовую фильтрацию и кастомную функцию F извлекаются реальные IPv4. Но самое новое здесь появилось с конца июня. В ботнете появились чистые «релейные» образцы. Они включают UPnP, пробрасывают на роутере 155 портов и через epoll организуют двусторонний прозрачный прокси между внешним трафиком и реальным C2, фактически превращая каждую зараженную железку в полноценный узел скрытой сети. И да, каждый такой узел каждые 4 секунды отчитывается на login[.]trees4sale[.]net:9000 с JSON-статусом. То есть ботнет больше не просто стучится на один сервер за командами. Он шифрует свои строки дважды, прячет настоящие IP в поддельных IPv6-адресах внутри блокчейн-доменов, а главное — использует зараженные устройства как анонимные передаточные звенья. Вместо того чтобы слать команды напрямую, бот спрашивает у одного из таких «ретрансляторов»: «а где сейчас настоящий C2?» И тот выдает список других зараженных машин. Убить один сервер бесполезно — их сотни, и имя им легион и они динамически меняются. Распространяется банально: telnet/ssh-брут и старые-добрые IoT-уязвимости вроде CVE-2017-17215, CVE-2020-8515 и даже несколько свежих из 2025 года. Ничего нового. По данным мониторинга, в Китае за неделю насчитали 4401 таких активных «зомби», а на глобальном уровне — до 239 тыс. в день. В открытых источниках мелькает скриншот панели управления с цифрой около 200 тыс. ботов, и данные отчета это подтверждают. Судя по всему, владельцы даже не скрывают коммерческий уклон. В рекламных постах обещают DDoS-мощность до 4 Тбит/с и продают атаки пакетами от пары десятков до нескольких сотен долларов. Так что если ваш роутер вдруг начал жить своей жизнью, возможно, он просто устроился на удаленку в международный стартап. @antiinfosec

Китайский вендор, военный контракт и один странный GitHub-репозиторий Расследование Cyberpress связало китайскую компанию Guangdong Chanming Technology с инфраструктурой RedRelay. Цепочка забавная и вполне тянет на детектив на Нетфликсе. Началось все с открытых данных. Компания запатентовала софт с кричащими названиями вроде «анонимная сеть», а потом нашлась закупка на сайте PLA — поставили ту самую «анонимную сеть» военным в Пекине. Уже интересно, но пока вроде все еще стандартно. Дальше был найден архивный Github-проект FCN (Free Connect), привязанный к почте одного из директоров. Код вел на домен xfconnect.com, а бинарник оттуда на VirusTotal оказался почти близнецом файла stn.exe, который фигурирует в отчетах как часть вредоносной активности. А самый смак, что уникальная Linux-команда в коде совпала с той, что используют в кампаниях Whipweave (она же ORBWEAVER), которую уже давно связывают с RedRelay. Выводы оставляйте себе, но факты намекают на то, что open-source может быть не только бесплатным, но и неожиданно полезным для атрибуции. Особенно когда разработчики забывают убрать свои следы. Китайские специалисты, судя по всему, тоже любят повторно использовать код, только вот цели у них специфические. @antiinfosec

Simlink откройся Представьте, вы клонируете репозиторий, запускаете Claude Code в папке, которой доверяли уже много месяцев, и даже не подозреваете, что ваш /etc/passwd или ~/.aws/credentials уже улетают в неизвестном направлении. Вряд ли сейчас кого-то удивим, но Томер Нив очень подробно описал механизм. Если вкратце, атакующему нужен просто симлинк и одна строчка в CLAUDE.md. Claude Code умеет подтягивать файлы через @import в CLAUDE.md и правилах. Если сделать симлинк на файл вне репозитория (например, /etc/passwd), система честно его прочитает и отправит в контекст модели при первом же запросе. При этом никакого диалога "А ты уверен, что хочешь прочитать файл снаружи?" не будет – проверка смотрит на имя симлинка (который внутри папки), а читает уже по реальному пути. Банальная подмена. И самое веселое, что этот файл улетает не куда-нибудь, а на сервер Anthropic по умолчанию. Но если злоумышленник добавит в репозиторий .claude/settings.json с переменной ANTHROPIC_BASE_URL, то все полетит на его сервер. Причем в неинтерактивном режиме (скрипты, CI/CD) даже вопросов не будет, а данные уходят молча и безвозвратно. Что характерно, Anthropic уже дважды фиксил похожие баги с симлинками в других частях кода (CVE-2025-59829 и CVE-2026-25724). Но этот конкретный путь – загрузка памяти при старте – остался без внимания. Вендор считает, что раз вы доверили папку, то все, что внутри, имеет право на все, включая чтение любых файлов за пределами репозитория. И да, проверьте свой ~/.claude.json – вдруг там уже кто-то живет. @antiinfosec

GitHack На Хабре обратили внимание на проблему, которая висит в открытом доступе с 2024 года. На GitHub существуют тысячи репозиториев, распространяющих трояны через ZIP-архивы. Найти их может любой желающий — достаточно обычного поиска по readme с паттернами вроде "## Download" и ссылкой на zip-файл. Автор собрал общий паттерн, написал скрипт и за пару часов нашел 10 тыс. таких репозиториев. Никаких специальных знаний не требуется, с этой задачей справится любая бесплатная ИИ-модель за несколько итераций. GitHub отреагировал ровно один раз. После публикации первой статьи все 10 тыс. репозиториев были удалены. Но спустя несколько часов скрипт нашел новые. Прошел месяц — их так и не заблокировали. У корпорации с миллиардными доходами, тысячами сотрудников и, простите, копайлотом не нашлось ресурса даже просто открыть статью автора, взять свежие ссылки и повторить действие. Почему служба безопасности GitHub, имея все возможности, два года не может решить проблему, которую за несколько часов решает один человек без доступа к внутренним инструментам? Зато убираем с GitHub критику Windows — Nightmare Eclipse. @antiinfosec