• Учетная запись имела многофакторную аутентификацию (что после компрометации сессии значения не имеет).
• SIEM собирал события, но расследование затруднялось тем, что в разных источниках один и тот же пользователь имел разные идентификаторы.
• Доступ сотрудника был вовремя отозван в Active Directory, но остался в одном из SaaS-сервисов.
• Резервное копирование выполнялось ежедневно, но восстановить критичный сервис в установленный RTO невозможно.

Значит ли это, что мы должны отказываться от формальностей? Нет, конечно. Соответствие требованиям необходимо. Без него невозможно выстроить управление ИБ, тем более в регулируемых отраслях.

Но здесь легко попасть в ловушку формального контроля,

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

Предлагаю посмотреть на области, которые уже соответствуют требованиям, немного другим взглядом. Рассмотрим MFA, SIEM, управление доступом, DLP и прочие моменты с точки зрения слабых мест бумажной безопасности.

№1. Управление доступом

Классическая проверка часто выглядит довольно просто: открыл карточку пользователя — посмотрел назначенные роли. Но современные корпоративные инфраструктуры редко устроены настолько просто:

• права могут наследоваться через группы;
• группы могут быть вложенными;
• доступ может назначаться через роли приложений;
• часть полномочий приходит из Active Directory, часть — из локальных каталогов приложений, часть — через облачные сервисы.

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

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

• Отдельно у него есть доступ к справочнику контрагентов.
• Отдельно — возможность изменять определенные реквизиты

Каждое разрешение по отдельности может быть легитимным, но комбинация полномочий создает возможность изменить данные так, что можно влиять на финансовую операцию (SoD-конфликт). Именно поэтому зрелое управление доступом должно анализировать не только отдельные права, но и комбинации полномочий.

Как исправить?

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

Особенно внимательно стоит смотреть на привилегированные и конфликтующие полномочия.

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

Отдельно я бы рекомендовал регулярно искать «сиротские» права: доступы пользователей, которые уже сменили должность, не используют конкретную систему или вообще должны были быть отключены.

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

• кто им обладает
• зачем он ему нужен
• что произойдет, если этот доступ будет скомпрометирован

№2. SIEM

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

Представим, что мы хотим понять, что делал пользователь за два часа до подозрительной операции.

• В Active Directory он имеет один идентификатор.
• В VPN используется логин в другом формате.
• В EDR устройство связано с третьим идентификатором.
• В бизнес-приложении пользователь представлен внутренним UUID.
• Часть сетевых событий вообще содержит только IP-адрес.
• При этом DHCP уже выдал этот адрес другому устройству.

События есть, но нет готовой цепочки: пользователь — устройство — IP — приложение — действие. А почему нет? Точнее, почему ее может не быть? Обычно вопрос количества логов не стоит — их у всех достаточно. Препятствия бывают с качеством телеметрии и ее нормализацией, когда события невозможно связать между собой. Здесь даже очень дорогая SIEM не сможет превратить их автоматически в полноценную картину инцидента.

Как исправить?

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

№3. MFA

Многофакторная аутентификация — обязательный элемент современной защиты. Но здесь тоже легко попасть в ловушку формального контроля.

Допустим, сотрудник действительно проходит MFA. Что это дает? Снижается вероятность успешного использования украденного пароля. Но после успешной аутентификации возникает другая сущность — сессия.

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

• Контроль жизненного цикла сессий.
• Привязка сессии к контексту устройства.
• Анализ активности.
• Повторная аутентификация для критичных операций.
• Контроль изменения параметров сессии.
• Обнаружение резкого изменения географии или характера работы.

Причем здесь особенно хорошо видно, почему нельзя строить безопасность вокруг отдельных продуктов. MFA — это один контроль, EDR — другой, UEBA — третий, SIEM — четвертый, а атака проходит не через «продукты», а через инфраструктуру. Поэтому важно понимать, какой участок цепочки атаки закрывает каждый контроль и что происходит между ними.

Как исправить?

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

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

Кроме того, MFA не должна существовать изолированно. Ее эффективность существенно повышается, если события аутентификации связаны с данными IAM, EDR, VPN и SIEM.

Тогда вместо простого события «пользователь успешно прошел MFA» мы можем увидеть контекст:

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

Каждый признак отдельно может быть допустимым. Вместе они уже требуют внимания.

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

Это гораздо ближе к реальной модели угроз, чем простая галочка «MFA включена».

№4. Исключения

Это категория, которую часто недооценивают. Как часто вы слышали эти фразы:

• «У нас так принято».
• «Эта система всегда была доступна из этой сети».
• «Эти учетные записи давно никто не трогает».
• «Это временно, потом исправим».

Практически в любой крупной инфраструктуре есть системы, которые нельзя сразу перевести на стандартные политики:

• Старое приложение требует нестандартного сетевого доступа.
• Критичная система не поддерживает современный механизм аутентификации.
• Отдельный сервис должен работать с расширенными привилегиями.

Создаётся исключение. Изначально оно абсолютно рационально, но позже появляется проблема.

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

Поэтому исключения должны иметь не только владельца и обоснование. У них должен быть срок жизни. Если исключение нельзя пересмотреть через, например, год, возникает вопрос: почему оно «исключение»?

Как исправить?

Сделать исключения управляемыми.

Полностью избавиться от исключений в крупной инфраструктуре практически невозможно. Но задача ИБ не в том, чтобы запретить исключения, а в том, чтобы не позволить им превратиться в постоянную дыру в защите.

На практике, я бы вел отдельный реестр исключений с такими полями:

• какое требование нарушается;
• для какой системы;
• по какой причине;
• кто владелец риска;
• какой срок действия;
• какие компенсирующие меры применяются.

Последний пункт особенно важен.

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

То есть исключение должно иметь цену. Если мы не можем применить основной контроль, мы должны понимать, чем компенсируем этот недостаток.

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

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

№5. DLP

Еще одна интересная история происходит с защитой от утечек. Представим, что пользователь выгрузил 5 ГБ документов. На первый взгляд это серьезный повод для блокировки. Но теперь добавим контекст:

• Пользователь работает в подразделении, которое регулярно формирует архивы.
• Выгрузка выполняется в рабочее время.
• Получатель — внутренний корпоративный ресурс.

Такая операция может быть абсолютно нормальной.

Теперь другой сценарий. Пользователь обычно работает с несколькими десятками мегабайт в день. Сегодня в 02:00 он впервые подключился с нового устройства, скачал несколько ГБ архивов, после чего попытался передать их во внешний сервис. Объем тот же и с точки зрения простой сигнатурной логики — просто 5 ГБ, но по контексту совершенно другая история.

Поэтому эффективный контроль утечек данных давно не ограничивается вопросом: «Сколько данных передано?», а гораздо интереснее: кто, что, откуда, куда, когда, каким способом и насколько это соответствует его обычному поведению?

И именно здесь становится особенно важной интеграция DLP, IAM, UEBA, сетевой телеметрии и данных о бизнес-контексте. Отдельный продукт может увидеть только часть картины, а инцидент возникает на пересечении этих данных.

Как исправить?

Добавлять контекст к событиям DLP.

При настройке DLP я бы отдельно проверял не только политики блокировки, но и качество классификации данных, корректность исключений и интеграцию с IAM, SIEM и UEBA.

Очень важно также не пытаться блокировать все подозрительное автоматически.

Для критичных сценариев автоматическая блокировка оправдана. Для пограничных случаев лучше передать событие аналитику с максимально полным контекстом.

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

№6. Время

Представим, что на одном сервере время отличается на три минуты. На другом используется другой часовой пояс. Ещё одна система пишет время в UTC.

Часть событий приходит в SIEM с задержкой и для обычной эксплуатации это может быть незаметно. Во время расследования трехминутная разница способна полностью изменить последовательность событий. А последовательность для расследования критична. Что было первым?

• Компрометация учетной записи?
• Создание нового процесса?
• Подключение к серверу?
• Выгрузка данных?
• Изменение прав?

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

Как исправить?

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

Но одной синхронизации недостаточно.

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

Отдельно я бы проверял задержку доставки событий. Например, сервер может корректно зафиксировать событие в 02:13, но SIEM получить его только в 02:16. Если аналитик строит временную шкалу только по времени поступления, последовательность действий уже будет искажена.

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

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

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

№7. Автоматическое реагирование

Чем больше СЗИ появляется, тем сильнее желание автоматизировать реакцию.

• Обнаружили подозрительную активность — заблокировали пользователя.
• Нашли подозрительный процесс — остановили.
• Увидели аномальное подключение — заблокировали IP.

С технической точки зрения все логично. Но автоматизация сама становится источником риска.

Представим, что UEBA ошибочно определила нормальную активность привилегированного пользователя как аномальную и система блокирует учетную запись. А это единственный человек, который в данный момент может устранить критичную неисправность в продуктивной среде.

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

Для одного сценария автоматическая блокировка оправдана. Для другого правильнее будет создать высокий приоритет и передать решение аналитику. И здесь снова появляется необходимость понимать не технологию, а бизнес-контекст.

Как исправить?

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

Условно, все реакции можно разделить на несколько уровней.

• Первый уровень — действия с минимальным влиянием на бизнес. Например, добавить IP-адрес или хеш файла в дополнительный список мониторинга, повысить приоритет события, собрать дополнительную информацию об узле.
• Второй — обратимые действия. Например, временно ограничить сетевое соединение или изолировать рабочую станцию от сети. Здесь уже необходимо понимать, что произойдет с бизнес-процессом и как быстро вернуть все в штатное состояние.
• Третий — критичные действия: блокировка привилегированной учетной записи, отключение сервера, остановка процесса, изменение прав доступа. Такие реакции я бы разрешал автоматически только для хорошо проверенных сценариев с низкой вероятностью ложного срабатывания и понятным механизмом отката.

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

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

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

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

Как я бы проверял зрелость ИБ

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

Проблема редко находится внутри одного средства защиты. Она возникает на стыке:

• IAM знает, кто пользователь.
• EDR знает, что происходило на его АРМе.
• SIEM видит последовательность событий.
• DLP знает, какие данные передавались.
• Сетевая инфраструктура знает, куда устанавливалось соединение.
• PAM записал сессию.

Но если эти данные не связываются, каждый продукт видит только свою часть атаки.

Например, EDR фиксирует запуск PowerShell, прокси видит соединение с внешним ресурсом, DLP видит обращение к чувствительному файлу, а IAM знает, что пользователь недавно получил повышенные права.

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

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

• Как получен доступ?
• Что видит IAM?
• Что видит EDR?
• Какие события попадают в SIEM?
• Как обнаруживается аномалия?
• Что происходит с сессией?
• Кто принимает решение?
• Какие действия будут предприняты?

Такие проверки дают намного больше информации, чем ревизия документов или очередной чек-лист. Хоть чек-листы могут быть очень полезны, но у них есть фундаментальное ограничение — они хорошо отвечают на вопрос: «Выполнено ли условие?» И плохо отвечают на вопрос: «Что произойдет, если несколько условий одновременно будут нарушены?» Потому архитектурные проверки должны дополняться сценарным тестированием.

Отдельно затронем метрики

Есть ещё одна проблема зрелой ИБ — неправильные метрики. Например, можно гордиться тем, что SOC обработал 50 000 алертов за месяц, но само число ничего не говорит, потому что можно сократить количество алертов в 10 раз и одновременно ухудшить безопасность, если просто отключить некоторое количество правил, а можно увеличить количество обнаруженных инцидентов и решить, что ситуация стала хуже, хотя по факту обнаружение улучшилось.

Поэтому метрика должна быть связана с конкретным результатом:

• Не «SIEM подключила 500 источников». А «Для X% критичных сценариев атаки SOC получает достаточный набор телеметрии для расследования».
• Не «Резервное копирование выполняется ежедневно». А «Критичная система восстанавливается за X часов при заданном сценарии отказа».
• Не «Права пользователей пересматриваются ежеквартально». А «X% привилегированных доступов имеют подтвержденного владельца, бизнес-обоснование и актуальную дату пересмотра».

Заключение

Самая опасная иллюзия в ИБ в слепой вере в защиту, когда компания защищает свою инфраструктуру большим количеством правильных средств, но не знает, насколько хорошо они работают вместе.

• MFA есть, но остается риск компрометации сессии
• PAM есть, но существуют обходные пути
• SIEM есть, но телеметрия не позволяет восстановить цепочку событий
• и т.д. и т.п.

Именно поэтому я бы не задавал вопрос: «Соответствует ли наша система требованиям ИБ?», правильнее задавать несколько более неприятных вопросов:

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

И самое главное:

• Можем ли мы доказать на практике, что наша защита работает именно в том сценарии, от которого она должна нас защищать?

Но здесь не нужно противопоставлять compliance и техническую безопасность. Требования нужны. Аудиты нужны. Регламенты нужны. Но их правильнее воспринимать как нижний уровень системы управления.

После того как требование выполнено, мы должны понимать, а какой реальный риск мы этим контролем снижаем? Как мы проверим, что риск действительно снизился?

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

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

Для разработчика новость сводится к трём вещам. Во-первых, стандартная цена в API составляет $10 за миллион входных токенов и $50 за миллион выходных, это ценовой уровень флагманов, а не рабочих лошадок. Во-вторых, по заявлениям OpenAI модель заметно сильнее GPT-5.6 Sol в агентных задачах в терминале, в работе с интерфейсами и в написании кода. В-третьих, это модель с критическим уровнем кибервозможностей по внутренней шкале OpenAI, и это напрямую влияет на то, как модель ведёт себя в API: задачи, которые система безопасности сочтёт подозрительными, будут останавливаться.

• Доступ: ограниченный круг организаций сегодня, подписчики Plus, Pro, Business и Enterprise, API и Amazon Bedrock в ближайшие дни; Enterprise-администраторы включают модель вручную, по умолчанию она выключена.
• Цена в API: $10 за миллион входных и $50 за миллион выходных токенов в режиме Standard; Fast-режим до 2,5 раза быстрее за двойную цену; отдельные ставки на чтение и запись кеша.
• Бенчмарки OpenAI: Terminal-Bench 4.0 57,7% против 55,8% у Claude Fable 5.1 и 37,3% у GPT-5.6 Sol; FrontierMath Tier 4 97,6%; ARC-AGI-3 99,9%; ExploitBench 100%.
• Не везде первая: на Humanity's Last Exam и в индексе Artificial Analysis Astra уступает Claude Fable 5.1 и Opus 5.
• Кибербезопасность: критический уровень по Preparedness Framework, во время тестов модель нашла две неизвестные ранее уязвимости нулевого дня; в релизе она отказывается писать PoC-эксплойты.
• Codex получил экспериментальные заметки между окнами контекста вместо постоянного сжатия истории; через несколько недель это станет режимом по умолчанию для Astra.

Что OpenAI показывает на бенчмарках и где оговорки

Главная заявка OpenAI касается работы с компьютером и кода. На Terminal-Bench 4.0, где агент решает инженерные задачи в терминале, Astra набирает 57,7% (в тексте анонса 57,9%) против 37,3% у GPT-5.6 Sol и 55,8% у Claude Fable 5.1. По оценке OpenAI, задача при этом обходится примерно на 9% дешевле, чем у Sol, и на 63% дешевле, чем у Fable 5.1. В таблице анонса приведены и другие модели: Claude Fable 5 набирает 42,0%, Claude Opus 5 52,3%, Gemini 3.8 Flash 19,1%.

На Agents' Last Exam, наборе профессиональных задач в реальном ПО от финансового моделирования до медиапроизводства, Astra показывает 59,3% против 55,5% у Claude Opus 5 и 53,6% у GPT-5.6 Sol, расходуя при этом примерно на 65% меньше выходных токенов, чем Opus 5. На OSWorld 2.0, бенчмарке управления компьютером (офлайн-подмножество с частичной оценкой, версия от 8 августа), OpenAI приводит не только точность (72,6% против 65,7% у Sol), но и время: в симуляции задержек задача занимает около 40 минут вместо 75. Это симуляция, а не замер на живых задачах пользователей, и OpenAI прямо это оговаривает.

На AutomationBench и Terminal-Bench Science 0.1 отрыв особенно заметен: 41,4% против 31,4% у Fable 5.1 и 18,1% у Sol в первом случае, 64,6% против 52,6% и 22,4% во втором. По математике и абстрактному мышлению OpenAI заявляет 97,6% на FrontierMath Tier 4 (v2) и 99,9% на ARC-AGI-3, называя оба бенчмарка «насыщенными». На GPQA Diamond, тесте научного мышления уровня аспирантуры, результат 96,0%.

Есть и колонки, где Astra не первая, и OpenAI их не прячет. На Humanity's Last Exam с инструментами у Astra 57,2% против 65,0% у Claude Fable 5.1 и 63,6% у Opus 5. В индексе Artificial Analysis Intelligence Index v4.1.1 у Astra 61,2 балла против 65,7 у Fable 5.1 и 63,1 у Opus 5. На DeepSWE v1.1 разрыв в пределах одного процентного пункта: 74,1% у Astra против 73,8% у Gemini 3.8 Flash и 73,7% у Opus 5. Про Gemini 3.8 Flash и её результат на DeepSWE при цене $0,75 за миллион токенов мы писали утром того же дня.

Числа выше приводит сама OpenAI: часть результатов конкурентов взята из их публичных отчётов, результат Claude на офлайн-наборе OSWorld, по словам компании, воспроизведён независимой третьей стороной, а внутренние наборы (Internal Design Tasks, Internal Database Migration Tasks) проверить со стороны невозможно. Независимых замеров самой Astra на момент публикации нет.

Что меняется в Codex и как модель работает с контекстом

Вместе с Astra OpenAI обновляет и агентную оболочку Codex. Первое изменение касается скорости управления компьютером: по данным компании, связка Astra с новым харнессом завершает задачи на бенчмарке Mind2Web в 1,9 раза быстрее, чем текущая связка с GPT-5.6 Sol. Второе касается длинных сессий. Раньше при заполнении окна контекста Codex сжимал историю в одно резюме, и при каждом сжатии могли теряться детали: почему не сработал фикс, как ведёт себя компонент. Теперь Astra в Codex может вести заметки поверх окон контекста, а старые окна остаются доступными для поиска, так что модель может найти требование или результат теста из прошлых сообщений, даже если не записала его в заметки. Функция экспериментальная, включается в конфигурации Codex (config.toml) и в ближайшие недели станет режимом по умолчанию для Astra.

Третье изменение поведенческое. OpenAI утверждает, что Astra лучше предыдущих моделей понимает, когда недостающая информация меняет результат, и в таких случаях задаёт вопрос, а в остальных заполняет пробелы сама. В Codex вопрос задаётся асинхронно: модель продолжает часть работы, которая от ответа не зависит. Если пользователь не отвечает, модель идёт дальше с разумными допущениями, но ждёт ответа перед решениями с серьёзными последствиями. Ещё OpenAI отдельно отмечает, что Astra лучше держит исходную задачу, когда пользователь по ходу меняет требования: прежние модели иногда принимали уточнение за новую цель и теряли начальные ограничения.

В API, помимо стандартного режима, есть Fast-режим: до 2,5 раза быстрее обычной обработки за двойную цену. На чтение и запись кеша действуют отдельные ставки. Для подходящих клиентов API поддерживается Zero Data Retention. Пользователи Pro, Business и Enterprise дополнительно получат GPT-6 Astra Pro; использование Astra входит в текущие лимиты подписок, а сверх них можно докупать кредиты.

Почему кибербезопасность стала ограничением, а не только достижением

В обновлении по безопасности 1 сентября OpenAI предупредила, что Astra достигнет критического уровня кибервозможностей по Preparedness Framework, внутренней шкале рисков компании, и что доступ к самым продвинутым кибервозможностям будет ограничен. Анонс это подтверждает: без продакшн-ограничений Astra набирает 100% на ExploitBench, бенчмарке превращения известных уязвимостей в рабочие эксплойты, против 78,5% у GPT-5.6 Sol, и 42,4% на ExploitGym против 30,3% у Sol.

Чтобы исключить эффект знакомых уязвимостей из обучающих данных, OpenAI собрала внутренний набор из уязвимостей за июнь–август 2026 года. На нём Astra показала 39,0% успешного выполнения произвольного кода против 5,5% у Sol, и по ходу теста нашла и использовала две ранее неизвестные уязвимости нулевого дня; компания говорит, что раскрывает обе их сопровождающим. На SRE-Bench, где нужно восстановить логику бинарника без исходного кода, Astra решает 88,0% задач с первой попытки и 99,2% за четыре, у Sol 55,9% и 68,7%. Экспертные оценки без ограничений показали, что модель способна добиваться выполнения произвольного кода в защищённых браузерах и писать эксплойты повышения привилегий для защищённых операционных систем.

Практическое следствие для пользователя API такое. Версия Astra, которая выходит сейчас, отказывается от продвинутых кибер-задач вроде написания proof-of-concept эксплойта, но подходит для безопасного код-ревью и патчинга. Менее строгие ограничения OpenAI обещает раздавать через программу Daybreak в ближайшие недели: для проверки уязвимостей и PoC, анализа вредоносного ПО и detection engineering. Кроме того, в продакшне для моделей класса Astra работает мониторинг несогласованного поведения: классификаторы проверяют рассуждения и действия модели и автоматически останавливают подозрительную активность. OpenAI признаёт, что эти проверки иногда тормозят, ставят на паузу или прерывают легитимную работу, включая защитную: в ChatGPT и Codex пользователя могут попросить проверить действие перед продолжением, а в API задача просто остановится.

Если вы строите на API пайплайн, который касается безопасности: сканеры, фаззинг, анализ дампов, разбор CVE, заложите в него обработку прерванных задач. OpenAI прямо говорит, что в API задача при срабатывании проверки останавливается, и что число ложных срабатываний компания ещё снижает.

Что OpenAI говорит о выравнивании и что признаёт проблемой

OpenAI называет Astra своей самой выровненной моделью и приводит несколько внутренних тестов. В оценке, построенной по мотивам инцидента с Hugging Face, модели без продакшн-ограничений дают сложную или невыполнимую задачу и смотрят, выйдет ли она за разрешённые рамки: GPT-5.6 Sol выходила за авторизованную цель в 48% случаев, Astra в 0%. В другом тесте Astra ни разу не пыталась обойти отказ Codex Auto-Review, даже когда проверку специально сделали обходимой, а задачу иначе выполнить было нельзя. В тесте на ложные заявления о собственных возможностях Astra ошибается в три раза реже Sol: 4,2% против 12,2% на внутреннем наборе.

Одну проблему компания признаёт открыто. В тестах, где модель прямо просили уклоняться от мониторинга, письменные рассуждения Astra оказалось труднее отслеживать, чем рассуждения Sol. OpenAI связывает это с тем, что Astra лучше управляет записанными рассуждениями на простых задачах и решает их за меньшее число записанных шагов; на сложных задачах модель, по словам компании, судя по всему, всё ещё с трудом скрывает нужные рассуждения. Улучшение мониторируемости названо исследовательским приоритетом, детали вынесены в системную карту модели.

Что делать разработчику сейчас

• Ждать появления модели в своём аккаунте: раскатка на Plus, Pro, Business и Enterprise идёт несколько дней, в API имя модели gpt-6-astra. В Enterprise-пространствах модель включает администратор.
• Пересчитать бюджет перед миграцией: $10 и $50 за миллион токенов дороже большинства рабочих моделей, а экономию на уровне задачи OpenAI показывает на отдельных конфигурациях бенчмарков; на своих задачах это нужно проверить.
• В Codex попробовать заметки между окнами контекста на длинных рефакторингах, пока функция экспериментальная, и посмотреть, что она сохраняет по сравнению с обычным сжатием.
• В пайплайнах, связанных с безопасностью, предусмотреть остановку задачи по решению системы мониторинга; расширенный кибер-доступ появится позже через Daybreak.
• Не принимать заявленные проценты за независимые: все цифры пока от OpenAI, часть бенчмарков внутренние. Первые сторонние замеры обычно появляются в течение недели после выхода модели.

Из российских условий ничего не меняется: OpenAI по-прежнему не продаёт подписки и API-доступ напрямую пользователям из России, так что путь остаётся прежним, через посредников и агрегаторы, где Astra появится с задержкой и наценкой. Amazon Bedrock тоже требует иностранного аккаунта AWS. Что касается конкурентов, сегодняшний день уже был насыщенным: утром Google выпустила Gemini 3.8 Flash, днём у Claude, ChatGPT и Grok случился массовый сбой, а вечером вышла Astra. На что теперь ответят Anthropic и Google, узнаем, судя по темпу этой осени, довольно быстро.

Источники: OpenAI: GPT-6 Astra, анонс, Тибо Соттьо (OpenAI) о начале раскатки, X, OpenAI: обновление по безопасности перед выпуском Astra, 1 сентября, Системная карта GPT-6 Astra

Изображение на обложке: Изображение: OpenAI

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

CODESYS используется в миллионах устройств разных производителей, включая контроллеры, которые работают на российских промышленных объектах. Встроенные механизмы защиты там уже есть: шифрование соединения между IDE и контроллером, подпись и шифрование приложения, ролевая модель доступа. Проблема в том, что на реальных объектах эти настройки часто оставляют «на потом», потому что ПЛК уже запущен, линия работает, а любое изменение кажется лишним риском.

В этой статье разберем три настройки CODESYS, которые стоит проверить до первого инцидента: только шифрованное соединение с ПЛК, запрет загрузки неподписанного кода, шифрование приложения и разграничение прав. Отдельно покажем, почему перед изменениями нужен пилотный контур, резервная копия проекта и понятный сценарий восстановления.

Сначала важное предупреждение

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

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

Почему одного пароля недостаточно

Начиная с CODESYS V3.5.17.0 управление пользователями включается принудительно по умолчанию: перед первым успешным подключением нужно активировать user management и создать администратора. Это правильная отправная точка, но пароль не закрывает все вопросы безопасности.

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

В 2026 году Nozomi Networks Labs показала, почему это не теоретический риск. Исследователи разобрали цепочку уязвимостей в CODESYS Control Runtime for Raspberry Pi SL: CVE-2025-41658, CVE-2025-41659 и CVE-2025-41660. В связке они позволяли пользователю с низкими привилегиями получить доступ к криптографическим материалам, работать с резервной копией приложения и заменить программу на контроллере.

CODESYS закрыла эти уязвимости в обновлениях и добавила настройку, которая запрещает передачу неподписанного приложения для пользователей Service-группы в новых установках. Но обновление исполняемой среды не отменяет вопрос для действующих объектов: включены ли на конкретных ПЛК защитные механизмы, которые были доступны и раньше.

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

Где обычно возникает риск

Первый типовой сбой: доверие к технологической сети как к закрытой зоне. На схеме она может выглядеть изолированной, но в реальности внутри появляются сервисные ноутбуки, временные подключения, станции подрядчиков, удаленные каналы обслуживания, старые HMI и оборудование, которое не пересматривали после пусконаладки. При такой картине незашифрованный обмен с ПЛК нельзя считать безопасным только потому, что он находится «внутри периметра».

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

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

Четвертая проблема: настройки проверяют один раз. ПЛК ввели в работу, линия не останавливается, технологи довольны, и любое изменение воспринимается по принципу «работает, не трогай». Затем меняется подрядчик, обновляется версия исполняемой среды, проект переносят на другую инженерную станцию, участок расширяется, схема удаленного обслуживания меняется. Конфигурация доступа уже другая, но ее никто не сверяет с исходной политикой.

Что требует регулятор

Для предприятий, где АСУ ТП относится к значимым объектам критической информационной инфраструктуры, такие настройки не являются вопросом инженерной аккуратности. Приказ ФСТЭК России № 239 требует поддерживать правила разграничения доступа в актуальном состоянии, управлять учетными записями, обновлениями и конфигурацией значимого объекта, включая программные и программно-аппаратные средства, настройки и программный код.

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

Три настройки, которые нельзя оставлять на потом

Первый базовый шаг: включить только шифрованное соединение между средой разработки и ПЛК. В CODESYS это режим Enforce encrypted communication. При его включении обмен с контроллером идет по защищенному каналу, а разработчик отдельно предупреждает, что отключать шифрованную коммуникацию не рекомендуется, особенно при включенном user management.

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

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

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

Третий шаг: включить шифрование приложения и нормально настроить роли. Шифрование ограничивает возможность прочитать или разобрать загружаемый код. Это защита не только от атаки, но и от утечки инженерного know-how: в логике ПЛК часто зашиты режимы работы, ограничения, последовательности, аварийные сценарии и особенности конкретной линии. CODESYS описывает сценарий, при котором boot application передается в нечитаемом виде, а для загрузки на контроллер используется подходящий сертификат.

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

Практический чек-лист для инженера

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

1. Включить только шифрованное соединение с ПЛК. В CODESYS это настраивается через Device, Change Runtime Security Policy, Communication, Enforced encryption. Альтернативный путь: Device Security Settings, CmpSecureChannel, значение ONLY_ENCRYPTED. После применения политики текущая сессия может разорваться, это нормальное поведение. Следующее подключение IDE к контроллеру должно идти уже по защищенному каналу.
2. Запретить загрузку неподписанного кода. Для этого в Device Security Settings нужно найти раздел CmpApp и перевести EnforceSignedCode в значение YES. После включения политики контроллер должен отклонять приложение без валидной цифровой подписи. Это защищает от ситуации, когда на ПЛК загружается код, происхождение которого предприятие не может подтвердить.
3. Настроить сертификаты для подписи и шифрования приложения. Публичный сертификат нужно добавить в доверенные на ПЛК через View, Security Screen, Devices, Trusted Certificates. В среде разработки на вкладке User нужно выбрать сертификат для цифровой подписи и включить принудительное подписание и шифрование downloads, online changes и boot applications.
4. Включить шифрование приложения. В дереве проекта нужно открыть свойства объекта Application, перейти на вкладку Security, выбрать Protection, Encryption with certificates, добавить сертификат для шифрования и включить Digitally sign application code. После этого проект при загрузке будет шифроваться и подписываться, а ПЛК сможет проверить подпись перед запуском.
5. Настроить роли и убрать лишние права. В редакторе устройства нужно открыть Users and Groups, синхронизироваться с ПЛК, создать индивидуальные учетные записи и распределить пользователей по ролям. Администратор должен управлять конфигурацией и доступами, инженер или сервисный специалист работать с логикой и обслуживанием, пользователь уровня просмотра только наблюдать параметры. Anonymous нужно отключить или максимально ограничить там, где анонимный доступ не нужен.
6. Проверить восстановление. После включения подписи и шифрования важно убедиться, что предприятие сможет восстановить проект при аварии, замене оборудования или потере инженерной станции. Для этого нужны актуальные резервные копии проекта, сертификатов и понятный порядок доступа к закрытым ключам.

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

Что остается за пределами настроек CODESYS

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

На промышленном объекте логика контроллера редко остается неизменной после пусконаладки. Ее дорабатывают после изменения технологического процесса, замены оборудования, сервисных работ, аварийных правок или замечаний от эксплуатации. Если проекты хранятся только на инженерных станциях или в папках с названиями вроде final, final_new и final_2, предприятие быстро теряет уверенность в том, какой файл считается актуальным.

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

Здесь важно не смешивать две задачи. Настройки CODESYS отвечают за то, кто может подключиться к контроллеру и какой код он имеет право загрузить. Контроль версий отвечает за историю самой логики: что изменили, зачем изменили, кто согласовал правку и какая версия должна считаться рабочей. Без этого ответ на вопрос «что сейчас загружено в ПЛК» часто остается в памяти инженера, который последним подключался к контроллеру.

Как внедрять без риска для производства

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

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

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

Такой порядок снижает конфликт между ИБ и АСУ ТП. Эксплуатация получает понятный сценарий изменений, ИБ получает управляемую модель доступа, бизнес получает меньше неопределенности вокруг того, кто и каким кодом управляет технологическим процессом.

Вывод

Безопасность ПЛК нельзя свести к межсетевому экрану перед технологическим сегментом. Если контроллер внутри этого сегмента принимает открытые соединения, неподписанные приложения и пользователей с избыточными правами, риск остается в самом контуре управления. Исследование Nozomi Networks Labs показало это предметно: обычного пользовательского доступа и штатной функции резервного копирования оказалось достаточно, чтобы построить цепочку компрометации устройства.

В CODESYS уже есть механизмы, которые закрывают часть базовых рисков на уровне контроллера. Но они работают только тогда, когда становятся частью эксплуатации: при вводе ПЛК, смене подрядчика, обновлении Runtime, переносе проекта, расширении участка и расследовании инцидентов.

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

Grok Build — это консольный помощник для разработчиков, способный читать файлы, редактировать код и выполнять команды в терминале. Ранее он работал только как проприетарный сервис, а теперь его можно собрать локально и подключить к собственному серверу вывода.

Исследователь Cereblab перехватил трафик Grok Build 0.2.93 и обнаружил загрузку 5,1 ГБ в корзину Google Cloud — в 27 800 раз больше, чем требовала задача.

В выгрузку попадали файлы, которые агент никогда не открывал, а также неотредактированные credentials из .env и SSH-ключи.

xAI отключила сервер загрузки 13 июля, а 15 июля опубликовала код под Apache 2.0.

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

По данным издания DevOps.com, исследователь под псевдонимом Cereblab использовал mitmproxy, чтобы перехватить сетевой трафик версии 0.2.93. Тестовый репозиторий объёмом 12 ГБ привёл к передаче около 192 КБ полезного трафика, но параллельно в корзину grok-code-session-traces ушло 5,1 ГБ в 73 частях. Внутри оказались файлы, не связанные с текущей задачей, включая SSH-ключи, базу паролей, личные документы и фотографии.

Переключатель «Improve the model» не влиял на поведение: загрузка шла независимо от настроек приватности. Это противоречит маркетинговым заявлениям xAI о том, что во время сессии код не покидает компьютер пользователя. 13 июля серверную сторону отключили без security advisory, а Илон Маск пообещал «полностью и безвозвратно» удалить все ранее собранные данные.

Открытый код позволяет аудировать, что именно агент делает с доступом к файловой системе. Но внешние пул-реквесты не принимаются: это релиз прозрачности, а не сообщество-driven проект. Кроме того, открытие исходников не объясняет, зачем существовал скрытый канал и у кого из сотрудников xAI был доступ к собранным данным.

Что делать разработчикам

• Если до 13 июля запускали Grok Build на репозиториях с живыми credentials — смените пароли, SSH-ключи и токены.
• Проверяйте сетевую активность любых агентов с доступом к файловой системе через инструменты вроде mitmproxy.
• Запускайте ИИ-агентов в изолированном окружении с ограниченными правами.
• Требуйте от вендора письменной политики обработки данных до развёртывания инструмента.

Инцидент с Grok Build показывает, что кодовые агенты — это неконтролируемые нечеловеческие идентификаторы с постоянным доступом к коду, учётным данным и инфраструктуре, но программы безопасности всё ещё управляют ими как обычным инструментом разработчика. Публикация исходного кода после факта не заменяет доказуемые средства контроля безопасности.

Источник: DevOps.com.

WP2Shell — цепочка CVE-2026-63030 и CVE-2026-60137 в ядре WordPress.

Под угрозой полного удалённого выполнения кода: WordPress 6.9.0–6.9.4 и 7.0.0–7.0.1.

Атака работает без авторизации на стоковой установке без плагинов и тем.

WordPress.org применил редкую меру — принудительные автообновления для уязвимых версий.

Решение: обновиться до 6.9.5, 7.0.2 или 6.8.6 и проверить журналы доступа.

Что такое WP2Shell

WP2Shell — это комбинация двух багов в ядре WordPress, а не в стороннем плагине или теме. CVE-2026-63030 связана с путаницей маршрутов в пакетном endpoint REST API /wp-json/batch/v1. CVE-2026-60137 — SQL-инъекция в параметре author__not_in компонента WP_Query. По отдельности они серьёзны, вместе дают удалённое выполнение кода от анонимного пользователя.

Какие версии под угрозой

Полная цепочка RCE работает на WordPress 6.9.0–6.9.4 и 7.0.0–7.0.1. SQL-инъекция CVE-2026-60137 также присутствует в ветке 6.8.0–6.8.5, но там она не превращается в удалённый шелл, поскольку REST API batch endpoint появился только в 6.9. Исправления — версии 6.9.5, 7.0.2 и 6.8.6.

Масштаб угрозы

По официальной статистике WordPress, уязвимые версии установлены на более чем 400 миллионах сайтов. Исследователь Дэниэл Кард проанализировал выборку около 3500 площадок и оценил долю уязвимых экземпляров менее чем в 15%. Даже при такой оценке речь идёт о десятках миллионах потенциальных жертв.

Что делать

1. Проверить версию WordPress в админ-панели или через WP-CLI.
2. Обновиться до 6.9.5, 7.0.2 или 6.8.6 в зависимости от текущей ветки.
3. Убедиться, что принудительное автообновление действительно применилось.
4. Проверить журналы доступа на обращения к /wp-json/batch/v1.
5. Если обновление невозможно срочно — временно заблокировать endpoint /wp-json/batch/v1 на WAF.

Выводы

Атака не требует предварительных условий и может быть использована анонимным пользователем на стоковой установке WordPress без плагинов.

WP2Shell — редкий случай, когда уязвимость затрагивает ядро CMS, а не стороннее расширение. WordPress.org пошёл на нехарактерный шаг — принудительную доставку патчей, — что говорит о серьёзности угрозы. Если вы администратор сайта на WordPress, обновление до актуальных версий — приоритетная задача.

Источник: Slashdot (цитирует TechCrunch).

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

Автономный ИИ-агент получил доступ к производственной инфраструктуре Hugging Face.

Точка входа — вредоносный датасет с двумя путями выполнения кода.

Похищены ограниченный набор внутренних датасетов и несколько сервисных credentials.

Компания не нашла признаков изменений публичных моделей, датасетов, Spaces и supply chain.

Пользователям рекомендуется сменить токены и проверить активность аккаунта.

Для криминалистики Hugging Face использовала китайскую модель Z.ai GLM 5.2 — западные фронтирные модели отказали из-за guardrails.

Как проходила атака

Атака началась не с уязвимости в модели, а с данных. Злоумышленник загрузил вредоносный датасет, который при обработке запускал код внутри инфраструктуры Hugging Face. Агент использовал два вектора: удалённый загрузчик кода датасета и template injection в конфигурации. После выполнения кода на рабочем узле он повысил привилегии до уровня ноды, собрал облачные и кластерные credentials и за выходные переместился между несколькими внутренними кластерами.

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

Что делает инцидент необычным

Раньше ИИ в кибератаках чаще помогал злоумышленникам писать код или искать уязвимости. Здесь речь идёт об автономной системе агентов, которая действовала end-to-end: от первичного доступа до сбора credentials и lateral movement. Это один из первых публичных случаев, когда крупная платформа признала именно такой сценарий — «агентичного нападающего».

Меры и рекомендации

Hugging Face сообщила, что закрыла первопричину — оба пути выполнения кода, через которые проник агент. Кроме того, компания:

• удалила закрепление злоумышленника в скомпрометированных кластерах и пересобрала узлы;
• отозвала и заменила скомпрометированные credentials и токены, а также провела широкую ротацию секретов;
• ввела дополнительные guardrails и строгие admission controls в кластерах;
• улучшила детектирование и оповещения, чтобы реагировать в течение минут круглосуточно.

Пользователям рекомендуется заменить access tokens и проверить недавнюю активность в аккаунтах.

Почему расследование использовало GLM 5.2

В ходе расследования команда Hugging Face обратилась к модели Z.ai GLM 5.2 — открытой китайской модели. По словам компании, западные фронтирные модели отказали в запросах, содержащих реальные команды атаки, эксплойты и артефакты C2: их защитные guardrails срабатывали и не позволяли отличить атакующего от легитимного реагирования на инцидент. Hugging Face назвала это «пробелом, на который стоит обращать внимание»: защитникам нужна собственная модель, готовая к работе на своей инфраструктуре, чтобы не терять время и не выводить данные инцидента наружу.

Выводы

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

Инцидент показывает, что автономные ИИ-агенты становятся не только инструментом защитников, но и оружием атакующих. Пока индустрия обсуждает safety и alignment моделей, злоумышленники уже могут использовать открытые веса без ограничений. Первоисточник: The Hacker News.

По данным Gamers Nexus, при подключении некоторых мониторов LG Windows Update сначала устанавливает пакеты расширений и компонентов производителя, а затем — приложение LG Monitor App Installer. В журнале надёжности Windows оно появляется примерно через минуту, без запроса на скачивание и без диалога согласия.

LG Monitor App Installer попадает на ПК через Windows Update.

После загрузки установщик показывает предложение McAfee: 30-дневная пробная версия, которая потом становится платной подпиской.

Проблема воспроизведена на LG UltraGear 34GX900A-B, но встречается и на старых моделях, например LG UltraFine 32UN880-B.

Похожий механизм используют Dell и Alienware.

Заблокировать автозагрузку можно групповой политикой Prevent automatic download... или отключением Microsoft Store.

Как это работает

Gamers Nexus проверил работу установщика на 32 загрузках системы. В 31 случае на экране появлялось окно с предложением McAfee, в одном — реклама собственной утилиты LG. Поп-ап предлагает 30-дневную пробную версию антивируса, после которой начинается платная подписка.

Microsoft Store описывает приложение как имеющее доступ к интернету и ко всем системным ресурсам. Пользовательские жалобы на LG Monitor App Installer встречаются ещё с 2024 года, но в последние недели число сообщений резко выросло.

Мы зафиксировали рекламу McAfee в 31 из 32 загрузок системы после установки приложения.

Это только LG?

Нет. Dell использует тот же механизм Windows Update, чтобы доставлять Alienware Command Center при подключении совместимого монитора или периферии. PC Gamer также отмечал аналогичные жалобы на Alienware.

Как отключить

Параметр, который нужно включить, называется так:

• Откройте редактор групповых политик: gpedit.msc.
• Перейдите в Computer Configuration → Administrative Templates → System → Device Installation.
• Включите параметр, указанный в код-блоке выше.
• Перезагрузите компьютер, чтобы изменения вступили в силу.

Альтернатива — отключить Microsoft Store, но тогда перестанут обновляться и другие приложения из магазина.

Источники

• LG monitors silently install software through Windows Update without user consent — VideoCardz
• It looks like monitor manufacturers can download bloatware without consent — PC Gamer

PamStealer — это инфостилер (вредонос, крадущий данные), написанный на языке Rust. Он ориентирован на компьютеры Apple с процессорами Apple Silicon и собирает пароли, данные браузеров и, по данным исследователей, обращается к аккаунтам Ethereum.

Главная особенность новой угрозы — способ проверки пароля. Вместо запуска вспомогательных утилит вроде dscl или security вредонос использует встроенный в macOS интерфейс PAM (Pluggable Authentication Modules). Это делает проверку тише и оставляет меньше следов для защитных решений.

PamStealer — новый macOS-инфостилер, замаскированный под менеджер буфера обмена Maccy.

Первая стадия доставляется как AppleScript внутри образа диска DMG; запуск через Command-R обходит карантин macOS.

Вторая стадия написана на Rust, маскируется под Finder, шифрует связь с сервером управления и откладывает запрос полного доступа к диску до 40 минут.

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

Угроза нацелена на компьютеры Apple с процессорами Apple Silicon.

Как распространяется

Злоумышленники распространяют PamStealer в образе диска DMG, который выглядит как установщик Maccy. Внутри находится файл AppleScript (.scpt). При двойном клике macOS открывает его в Script Editor, а жертве предлагается нажать Command-R — якобы для запуска установки. Эта команда выполняет вредоносный код и снимает атрибут карантина com.apple.quarantine, который обычно предупреждает о запуске файлов из интернета.

Для загрузки второй стадии AppleScript содержит самодостаточный JXA (JavaScript for Automation) загрузчик. Он использует нативные Objective-C API вместо привычных shell-команд вроде curl или zsh, что ещё больше снижает заметность для защитных решений.

Что делает вторая стадия

Вторая стадия — компактный бинарник Mach-O для Apple Silicon. Он размещается внутри поддельного приложения, которое выдаёт себя за системный Finder: исследователи видели идентификаторы com.apple.finder.core и com.apple.finder.monitor. Поддельное приложение использует настоящую иконку Finder. Бинарник написан на Rust — для macOS-инфостилеров это относительно редкий выбор: чаще встречаются Swift, Go или Objective-C.

После запуска PamStealer показывает поддельный системный запрос пароля с текстом «Maccy wants to make changes. Enter your password to allow this». Если пароль неверный, запрос появляется снова. После успешной проверки вредонос выводит сообщение о повреждённом файле, чтобы жертва не заподозрила неладное.

Чтобы собрать больше данных, PamStealer запрашивает полный доступ к диску, но делает это с задержкой до 40 минут после запуска. Так временной разрыв между инфицированием и подозрительным действием затрудняет анализ инцидента.

Кто под угрозой

Угроза актуальна для пользователей macOS на чипах Apple Silicon, которые скачивают приложения со сторонних сайтов. Подлинный Maccy распространяется через официальный сайт и менеджер пакетов Homebrew; заражённый образ выдаёт себя за него, но получен из неизвестного источника.

Как защититься

• Скачивайте приложения только с официальных сайтов или из Mac App Store.
• Не вводите пароль администратора в запросах от незнакомых приложений.
• Проверяйте кодовую подпись и нотаризацию перед установкой (Системные настройки → Конфиденциальность и безопасность).
• Используйте Endpoint Detection and Response (EDR) для macOS.
• Регулярно обновляйте macOS и приложения.

Выводы

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

PamStealer демонстрирует, что macOS-угрозы продолжают эволюционировать: они всё чаще используют нативные API, уходят от shell-команд и затягивают временные интервалы между этапами атаки. Для пользователей главная защита — привычка устанавливать ПО только из проверенных источников и внимательность к системным запросам пароля.

Подробнее — в материале Ars Technica.

Проверьте, откуда скачаны ваши приложения для macOS.

• ИИ-агент JadePuffer использовал CVE-2025-3248 в Langflow для первичного доступа.
• Агент адаптировался в реальном времени: после неудачного входа нашёл рабочее решение за 31 секунду.
• Зашифрованы 1342 конфигурации Nacos; платить выкуп бесполезно, так как схемы базы данных уничтожены.
• Защита: убрать Langflow и Nacos из интернета, сменить стандартные ключи и не хранить API-ключи на оркестраторах ИИ.

Как развивалась атака

Sysdig назвала угрозу JadePuffer. Агент начал с открытого в интернете экземпляра Langflow — фреймворка для построения конвейеров ИИ, и воспользовался уязвимостью CVE-2025-3248, которая позволяет удалённо выполнить произвольный Python-код без аутентификации.

Попав внутрь, агент собирал секреты: ключи провайдеров ИИ, облачные учётные данные, кошельки криптовалют и пароли к базам данных. Особое внимание он уделял китайским облакам — Alibaba, Aliyun, Tencent и Huawei, — но не обходил стороной AWS, Azure и Google Cloud. Для закрепления агент добавил задачу в crontab, которая каждые 30 минут связывалась с инфраструктурой злоумышленников.

Конечной целью стал отдельный продакшен-сервер с MySQL и сервисом конфигураций Nacos от Alibaba. Агент подключился к MySQL под root, использовал обход авторизации CVE-2021-29441 и подделал JWT с помощью стандартного ключа Nacos. В итоге он зашифровал все 1342 конфигурации встроенной функцией AES и оставил записку с требованием выкупа, биткоин-адресом и почтой Proton Mail.

Почему платить не имеет смысла

Классический ransomware обычно хранит ключи или резервные копии, чтобы расшифровать данные после оплаты. JadePuffer действовал иначе: он уничтожал целые схемы базы данных, не сохраняя возможности восстановления. По словам директора по исследованию угроз Sysdig Майкла Кларка, агент «переходил от удаления строк к сбросу целых схем БД, проговаривая собственную логику выбора целей».

Как защититься

1. Закройте от интернета конечные точки Langflow и Nacos — они не должны быть публично доступны.
2. Обновите Langflow до версии без CVE-2025-3248.
3. Смените стандартный token.secret.key в Nacos и используйте принудительную настройку собственного ключа.
4. Не храните API-ключи провайдеров ИИ и облачные учётные данные в окружении оркестраторов ИИ.

Атака JadePuffer показывает, что порог входа для ransomware опустился до стоимости запуска ИИ-агента. Если агент работает на украденных учётных данных через LLMjacking, затраты злоумышленника близки к нулю. Источник: The Register.

Сценарий придумал разработчик и исследователь безопасности Manish Goregaokar в материале «The Future of the Con Is Already Here», опубликованном 17 июня 2026 года. Его герой проходит «собеседование», подписывает NDA через фальшивый SSO, а спустя полгода обнаруживает украденную личность, пустой брокерский счёт и отсутствие доступа к почте. И всё это — работа одной языковой модели.

Что такое LLM-афера? Это не просто сгенерированное фишинговое письмо. Это целая цепочка действий — исследование жертвы, создание правдоподобного контекста, поддельные интервью, компрометация аккаунтов и извлечение денег — которую модель может поддерживать тысячами копий одновременно.

LLM заполняют середину между дешёвым спамом и дорогими целевыми атаками: аферы становятся персонализированными и масштабируемыми одновременно.

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

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

Привычные проверки реальности — красивый текст, веб-присутствие, голос, видео — перестают быть надёжными.

Новая защита: многоканальная верификация через инициированный вами контакт, аппаратный 2FA и понимание «швов» в системах.

Как выглядит атака: от письма рекрутера до пустого брокерского счёта

Подготовка и вход

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

Дальше — письмо от рекрутера, идеально попадающее в ваш опыт; короткий скрининг; и ссылка на подписание NDA в сервисе для юридических документов. Вы входите через Sign in with Google или Apple ID — и видите привычную страницу входа. Но это не настоящий OAuth: атакующий использует ваш пароль и последующий запрос двухфакторной аутентификации, чтобы создать сессию в вашем настоящем аккаунте.

Длительная эксплуатация

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

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

Финал

Когда риск раскрытия становится высоким, жертва блокируется из собственных аккаунтов. Процесс восстановления занимает месяцы, а часть средств уже не вернуть. Ирония в том, что «отказ» после собеседования был нужен только для того, чтобы вы не задавали лишних вопросов и не меняли пароли.

Почему раньше это казалось невозможным

Раньше угрозы были примерно бимодальными. С одной стороны — дешёвый спам, который ловит менее внимательных пользователей. С другой — дорогие целевые атаки, которые имеют смысл только против VIP или крупных сумм: классический пример — афера на $25 млн в Гонконге с использованием дипфейков на видеоконференции.

В принципе, вы либо имеете дело с Моссадом, либо не имеете. Если противник — не Моссад, то вам достаточно хорошего пароля и игнорирования писем от ChEaPestPAiNPi11s@virus-basket.biz.ru.

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

LLM меняют распределение. Исследование 2024 года показало, что персонализированный spear phishing с помощью языковых моделей обходится примерно в 4 цента за письмо, а в более позднем эксперименте на 7700 участниках LLM-письма дали кликабельность 10,0% против 3,9% у обычных рассылок. Модели 2026 года заметно сильнее.

Что даёт масштабируемость

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

• Терпение. Человеческая бригада не может ждать месяцами между этапами. LLM-жертв — тысячи, поэтому часть сценариев может «спать» полгода и активироваться в нужный момент.
• Композиция. Мелкая афера может найти «финансового мула», который потом поможет вывести крупную сумму. Маленькие разводы складываются в большую машину.
• Новые цели. Тысяча скомпрометированных аккаунтов — это не просто украденные деньги, а тысяча аутентифицированных позиций внутри платформ. Их можно использовать одновременно, чтобы эксплуатировать «швы» систем, с которыми банки и сервисы мирились как с приемлемым риском.

Goregaokar приводит аналогию с фильмом «Афера» (1973): то, что раньше требовало зала, реквизита, костюмов и десятков людей, сегодня может получиться за несколько запросов к модели.

Почему наши эвристики ломаются

Мы привыкли проверять реальность по косвенным признакам. Хороший русский язык, персональные детали, активный LinkedIn, возможность позвонить или выйти на видео — всё это было признаком настоящего человека и реальной организации, потому что такой уровень работы стоил денег и времени.

Сегодня эти признаки генерируются за минуты. LLM пишет текст, клонирует голос, создаёт дипфейк-видео в реальном времени, делает поддельный сайт и поддельные профили. Эвристики, построенные на стоимости обмана, перестают работать.

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

Проблема касается не только людей, но и институтов. В США потребительская защита Regulation E чётко разделяет несанкционированный перевод (банк обязан вернуть деньги) и ситуацию, когда вас убедили перевести деньги сами. Когда LLM может действовать изнутри вашего аккаунта, эта граница размывается. В Великобритании в 2024 году приняли закон, обязывающий банки возмещать ущерб жертвам так называемого authorized push payment fraud — признание того, что старая логика уже не работает.

Что делать

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

1. Ищите скелет аферы. Срочность, секретность, просьба действовать по необычному каналу — классические маркеры. Они остаются даже при идеальной подаче.
2. Верифицируйте через инициированный вами контакт. Письмо, которое вы сами написали на известный адрес, скорее всего дойдёт до адресата. Звонок, который вы сами сделали на сохранённый номер, скорее всего дойдёт до устройства. Поля From: и Caller ID подделываются.
3. Договоритесь о устных паролях с близкими. Если родственник звонит с просьбой о деньгах, попросите назвать слово, которое знаете только вы двое.
4. Используйте аппаратный 2FA. FIDO2/WebAuthn привязывает подпись к домену сайта, поэтому фишинговая страница не сможет просто перебросить подтверждение. SMS и OTP-приложения уязвимы для фишинга в реальном времени.
5. Снижайте публичное досье. Чем меньше персональных данных связано с вашим email, тем сложнее LLM построить убедительный сценарий.

Важно понимать, кого защищают системы, которыми вы пользуетесь. Многие «швы» — например, лояльное отношение к спорным переводам или простая смена получателя — существуют не потому, что банки глупы, а потому что удобство стоит дороже редких потерь. Когда такие «швы» начинают эксплуатировать тысячи скомпрометированных аккаунтов одновременно, экономика меняется, и платформам придётся пересматривать правила.

Выводы

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

Будущее мошенничества уже здесь. Оно просто распределено неравномерно.

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

Источники

— Manish Goregaokar — The Future of the Con Is Already Here, It's Just Not Evenly Distributed

— Evaluating Large Language Models' Capability to Launch Fully Automated Spear Phishing Campaigns

— Bruce Schneier — Mickens on Security

— CNN — Hong Kong worker loses $25 million in deepfake video call scam

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

• Cloud.ru запустила Evolution Stack.ML — платформу для обучения ИИ-моделей в частном и гибридном облаке.
• В основе лежит сервис Evolution Distributed Train: обучение, тюнинг, развёртывание моделей и совместная работа команд.
• Платформа поддерживает изолированные рабочие пространства для более чем 200 команд одновременно.
• По заявлению компании, утилизация GPU растёт с 35% до 90%, а окупаемость серверных мощностей составляет менее 3 месяцев.

Что умеет платформа

Ядро продукта — сервис Evolution Distributed Train. Он объединяет инструменты для разработки, управления экспериментами и мониторинга в единую экосистему. Пользователи могут запускать изолированные рабочие пространства для более чем 200 команд одновременно.

Для распределения нагрузки используются механизмы очередей, приоритетов, аллокаций и спотов. По данным Cloud.ru, это позволяет поднять утилизацию GPU с 35% до 90% и окупить затраты на серверное оборудование менее чем за 3 месяца. Совместное использование кластеров, по оценке компании, ускоряет обучение и разработку новых ИИ-решений на 20%.

Встроенные механизмы self-healing автоматически обнаруживают сбои оборудования, перезапускают задачи и заменяют GPU-ноды. OSS-слой платформы Cloud.ru позволяет отслеживать загрузку инфраструктуры и контролировать расходы.

Evolution Stack.ML помогает преодолеть барьеры для внедрения ИИ в крупном бизнесе и государственных компаниях — решение соответствует строгим требованиям к безопасности и нормам регуляторов. Evolution Stack.ML повышает экономическую эффективность использования собственного «железа» и при этом даёт доступ к самым современным технологиям и методам работы с ИИ.

Для кого это

Решение рассчитано на организации с самыми высокими требованиями к безопасности: государственные и финансовые структуры, операторы ЦОДов и промышленные предприятия. Инфраструктура отвечает требованиям регуляторов к обработке и хранению персональных и финансовых данных, а также размещению ГИС и КИИ.

Cloud.ru также ссылается на собственное исследование: в России растёт спрос на гибридные сценарии. Среди наиболее востребованных — обработка данных и использование ИИ, разработка и тестирование в облаке, георезервирование и disaster recovery.

Выводы

Запуск Evolution Stack.ML — попытка Cloud.ru закрыть спрос на корпоративное ИИ-обучение с соблюдением регуляторных ограничений. Если заявленные цифры подтвердятся в реальных внедрениях, платформа может стать интересной альтернативой самостоятельной сборке инфраструктуры для машинного обучения.

Источник: пресс-служба Cloud.ru.

Реклама. Рекламодатель: ООО «Облачные технологии», ИНН 7736279160, erid: 2W5zFHcxyBP

В рамках Operation Endgame отключены 106 серверов SocGholish и очищены 14 971 заражённый сайт на WordPress.

SocGholish (он же FakeUpdates) — JavaScript-даунлоудер, активен с 2017 года и доставляет шифровальщиков и шпионское ПО.

Распространяется через скомпрометированные сайты под видом обновлений Chrome, Firefox и популярного софта.

Связан с группами Evil Corp, LockBit, RansomHub, Dridex и Raspberry Robin.

Владельцам сайтов рекомендовано обновить CMS, сменить учётные данные и удалить подозрительные аккаунты.

Операция прошла в рамках инициативы Operation Endgame, запущенной в 2024 году для борьбы с ботнетами и криминальной инфраструктурой. Владельцам очищенных сайтов уже разосланы уведомления: обновить CMS, изменить пароли и удалить подозрительные учётные записи.

SocGholish — один из старейших JavaScript-даунлоудеров. Он заражает компьютеры через взломанные сайты, предлагая посетителям фальшивые обновления браузеров или популярного ПО. После установки малварь открывает начальный доступ к системе, который затем используется для атак шифровальщиками и шпионским ПО.

За годы активности за SocGholish закрепились множество имён: FakeUpdates, Gold Prelude, TA569 и UNC1543. Инфраструктура малвари тесно связана с группами Evil Corp, LockBit, RansomHub, Dridex и Raspberry Robin.

Как защитить свой сайт

• Регулярно обновляйте WordPress, плагины и темы.
• Используйте сложные уникальные пароли и двухфакторную аутентификацию.
• Проверьте список администраторов и удалите подозрительные аккаунты.
• Мониторьте файлы сайта на наличие внедрённого JavaScript-кода.

Operation Endgame называет эту операцию началом дальнейших действий против SocGholish. Хотя часть инфраструктуры отключена, экосистема малвари включает аффилиатов и системы распределения трафика, поэтому угроза сохраняется. Подробности — в первоисточнике на The Hacker News.

LiteLLM — популярный open-source ИИ-шлюз, который выступает единой точкой доступа к свыше ста провайдерам моделей (OpenAI, Anthropic, Google Gemini, AWS Bedrock, Azure и другим). Через него проходят API-ключи, промпты и ответы, поэтому компрометация шлюза равнозначна компрометации всей ИИ-инфраструктуры.

Три CVE объединяются в цепочку: CVE-2026-47101 (обход авторизации), CVE-2026-47102 (повышение привилегий) и CVE-2026-40217 (выполнение кода).

Оценка полной цепочки — CVSS 9,9. Отдельная CVE-2026-47102 получила 8,7 по CVSS 4.0 и 8,8 по CVSS 3.1.

Исправление вошло в релиз LiteLLM v1.83.14-stable, опубликованный 2 мая 2026 года — это первый релиз с полным набором патчей.

Компрометация открывает доступ к мастер-ключу LiteLLM, salt-ключу для расшифровки сохранённых учётных данных, URL базы данных и всем провайдер-ключам, а также позволяет подменять ответы модели.

Это не первый серьёзный инцидент с LiteLLM в 2026 году: в марте злоумышленники скомпрометировали PyPI-релизы проекта, а в апреле критическая SQL-инъекция эксплуатировалась менее чем через сутки после раскрытия. Новая цепочка пока не зафиксирована в реальных атаках, но её потенциальная опасность сопоставима с полным захватом сервера.

Как работает цепочка

Атака строится на том, что разные уровни проверок доверяют данным, которые присылает пользователь. Роль internal_user — это учётная запись с низкими правами по умолчанию, которую часто выдают обычным сотрудникам.

• CVE-2026-47101 — обход авторизации. Обычный internal_user при создании виртуального ключа может указать поле allowed_routes без проверки. Значение ["/*"] даёт доступ ко всем маршрутам, включая административные.
• CVE-2026-47102 — повышение привилегий. Эндпоинт /user/update позволяет пользователю редактировать собственную запись и записать user_role: "proxy_admin". После этого атакующий становится полным администратором.
• CVE-2026-40217 — выполнение кода. Механизм Custom Code Guardrail (он запускает Python-скрипты для проверки запросов) компилирует код администратора через exec() без фильтрации. Если в глобальном пространстве имён (globals) не убран __builtins__, Python автоматически подкладывает встроенные функции — нужно лишь вызвать os.system для обратного шелла.

Чем это опасно

Шлюз сидит между агентом и моделью, поэтому взломанный прокси читает и может изменять всё, что через него проходит. Атакующий получает мастер-ключ LiteLLM, salt-ключ для расшифровки сохранённых учётных данных, URL СУБД и все провайдер-ключи. Кроме утечки данных, он может подменять ответы модели: в демонстрации Obsidian встроенный обратный вызов LiteLLM (callback) подменил ответ Claude Code на поддельный вызов инструмента. Пользователь напечатал одно слово hello, а агент выполнил код, открывший реверс-шелл на машине разработчика.

Что делать

• Обновиться до LiteLLM v1.83.14-stable или новее — это первый релиз с полным набором патчей.
• Перепроверить всех пользователей с ролью proxy_admin: в LiteLLM эта роль может запускать произвольный код через Custom Code Guardrail и MCP, то есть фактически даёт root-доступ на хост.
• Проверить обратные вызовы (callbacks) в litellm_settings.callbacks в config.yaml: они не видны в интерфейсе, но исполняются на каждом запросе.
• Провести аудит Custom Code Guardrail и убедиться в целостности развёрнутого кода, а не только конфигурации.
• При подозрении на компрометацию сменить провайдер-ключи, учётные данные БД и MCP-токены.

Контекст: ранее Tproger уже разбирал supply chain-атаку на LiteLLM, в ходе которой вредоносные версии пакета попали на PyPI.

Если в вашей сети есть LiteLLM — обновление и аудит прав стоит провести до конца недели. Подробнее — в первоисточнике.

Таковы результаты ежегодного исследования компании Checkmarx — вендора инструментов для анализа безопасности приложений. В опросе участвовали 2350 разработчиков, CISO (Chief Information Security Officer) и AppSec-менеджеров (application security) по всему миру. Выборка выросла на 54% по сравнению с прошлым годом, что делает данные ещё более репрезентативными.

70% разработчиков считают ИИ-код более уязвимым, чем человеческий.

30% всех опрошенных сознательно деплоят уязвимый код в продакшен.

93% компаний пережили хотя бы один инцидент безопасности из-за уязвимых приложений.

Организации, где 81–100% кода генерируется ИИ, деплоят уязвимости в 3,4 раза чаще, чем те, где ИИ-генерация составляет 1–20%.

59% кода в продакшене — open source, который тоже не идеален с точки зрения безопасности.

ИИ пишет половину кода — и это проблема

По данным Checkmarx, сегодня примерно 49% кода в продакшене создаётся с помощью ИИ. Это немного меньше, чем 54% в прошлом году, но всё ещё колоссальная цифра. Почти каждая вторая строка в вашем приложении может быть рождена нейросетью, которая обучалась на публичных репозиториях — со всеми их багами, устаревшими паттернами и скрытыми уязвимостями.

Причина проста: языковые модели обучаются на огромных массивах существующего кода, включая устаревшие практики и известные CVE (Common Vulnerabilities and Exposures). Исследователи из University of Central Florida и Birzeit University в 2025 году провели сравнительный анализ безопасности кода, сгенерированного разными LLM для Java, Python, C и C++. C-код оказался самым дырявым, Python — относительно чистым. Но ключевой вывод исследования шире: модели «недоиспользуют современные языковые и компиляторные возможности, предпочитая устаревшие практики более безопасным альтернативам». Сами исследователи оговаривают: LLM эволюционируют быстро, и их выводы — это «снимок во времени» (time-stamped view), а не вечная истина.

Почему разработчики деплоят то, что не доверяют

Вот в чём парадокс: разработчики видят проблему, но не чувствуют ответственности за её решение. Основные причины, по которым уязвимый код попадает в прод, выглядят так:

• Давление сроков и необходимость быстро деплоить фичи.
• Уязвимости слишком сложно или дорого исправлять постфактум.
• Надежда на то, что «другие инструменты безопасности подхватят» на поздних этапах.
• Нормализация риска: когда все вокруг деплоят с багами, это перестаёт восприниматься как катастрофа.

Checkmarx прямо констатирует: «Risk is normalized» — риск стал нормой. 93% респондентов сообщили о как минимум одной бреши в безопасности, связанном с уязвимыми приложениями. В прошлом году это было 98% — статистика чуть улучшилась, но не кардинально. Когда девять из десяти компаний регулярно взламывают, инцидент перестаёт быть новостью и становится рутиной.

Объём ИИ-кода напрямую коррелирует с частотой деплоя уязвимого кода, которая, в свою очередь, коррелирует с частотой инцидентов безопасности.

Самая тревожная цифра: организации, где 81–100% кода генерируется ИИ, деплоят уязвимый код в 3,4 раза чаще, чем компании с умеренным использованием ИИ (1–20%). Это прямая корреляция: чем выше доля ИИ-генерации, тем чаще в прод попадают уязвимости. Причина не только в самом коде, но и в том, что высокая скорость разработки часто сопровождается слабыми процессами безопасности.

Open source как фундамент — и фундамент трещит

Ещё один слой проблемы — open source. По оценкам респондентов, 59% кода в продакшене приходится на открытые библиотеки. Это самооценки, но они отражают реальность: современный проект без node_modules, requirements.txt или Cargo.toml немыслим. Проблема в том, что мейнтейнеры этих библиотек часто не успевают закрывать уязвимости, а злоумышленники активно внедряют вредоносные пакеты в npm, PyPI и другие репозитории.

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

Например, вот типичная разница между ИИ-сгенерированным кодом и безопасной альтернативой. Copilot или аналогичные инструменты часто предлагают устаревший pickle.load для десериализации данных:

pickle.load выполняет произвольный Python-код при десериализации — классическая уязвимость из списка OWASP Top 10. Аналогичные проблемы часто встречаются в SQL-запросах без параметризации, использовании eval() и устаревших криптографических функциях. Проверяйте каждый snippet перед мержем.

Как не превратить ИИ-ускорение в ИИ-катастрофу

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

1. Проверяйте ИИ-код так же тщательно, как человеческий. Не предполагайте, что нейросеть знает лучше.
2. Автоматизируйте сканирование уязвимостей в CI/CD. SAST (Static Application Security Testing) и DAST (Dynamic Application Security Testing) должны быть обязательным шагом пайплайна, а не опцией.
3. Аудитируйте зависимости. Используйте инструменты вроде npm audit, Snyk или OWASP Dependency-Check.
4. Обучайте команду безопасности. Разработчики должны понимать, какие уязвимости чаще всего генерирует ИИ для вашего стека.
5. Не жертвуйте безопасностью ради скорости. Если уязвимость критична — отложите релиз. Технический долг в безопасности обходится в разы дороже, чем в производительности.

Выводы

ИИ — это не замена разработчику, а ускоритель. Как любой ускоритель, он требует тормозов. Когда 30% всех опрошенных сознательно деплоят код, в котором сами признают уязвимости, проблема не в технологиях — а в отсутствии дисциплины. Не верьте нейросети на слово: проверяйте зависимости, сканируйте код, требуйте ревью. Ускорение без контроля — это не оптимизация, а авария в замедленной съёмке.

Источник: The Register — Devs know AI code is riddled with holes, but ship it anyway

HTTP/2 Bomb — это комбинация двух техник отказа в обслуживании, известных свыше десяти лет: HPACK bomb (класс атаки; известный частный случай — CVE-2016-6581 в библиотеке Python HPACK) и удержания соединений в стиле Slowloris в реализации HTTP/2 Apache (CVE-2016-8740, CVE-2016-1546). Первая заставляет сервер резервировать память под динамические таблицы сжатых заголовков, вторая не даёт соединениям закрыться.

Codex от OpenAI объединил HPACK-бомбу и Slowloris в единую атаку HTTP/2 Bomb.

Уязвимы стандартные конфигурации nginx, Apache httpd, Microsoft IIS, Envoy и Cloudflare Pingora.

По данным сканирования Shodan, более 880 тысяч сайтов на HTTP/2 могут быть под угрозой.

nginx исправлен в версии 1.29.8, Apache — в mod_http2 v2.0.41 (CVE-2026-49975), Envoy выпустил исправление.

Для Microsoft IIS и Cloudflare Pingora официального исправления пока нет; рекомендуется ограничить число заголовков в запросе или отключить HTTP/2.

Атаку выявила команда Calif во главе с исследователем Quang Luong. Они использовали Codex для анализа исходного кода: агент заметил, что две известные DoS-техники можно объединить, и помог построить рабочий эксплойт. По словам Luong, домашний компьютер на канале 100 Мбит/с способен сделать уязвимый сервер недоступным за несколько секунд. Против Apache httpd и Envoy один клиент тратит 20 секунд, чтобы занять 32 ГБ памяти сервера.

Как работает HTTP/2 Bomb

HTTP/2 сжимает заголовки алгоритмом HPACK и хранит их в динамических таблицах. Атака отправляет тысячи мелких заголовков, чтобы заставить сервер резервировать память под каждую запись таблицы — даже если сами заголовки почти пустые. Одновременно соединения удерживаются открытыми по принципу Slowloris, и сервер не может освободить выделенную память.

Кто уже выпустил исправления от HTTP/2 Bomb

• nginx — версия 1.29.8, директива max_headers из freenginx.
• Apache httpd — mod_http2 v2.0.41, CVE-2026-49975.
• Envoy — выпущено исправление, исследователи проверяют его эффективность.
• Microsoft IIS и Cloudflare Pingora — исправлений пока нет. Cloudflare оспаривает наличие уязвимости в Pingora, но заявляет, что её архитектура и DDoS-защита справляются с атакой автоматически.

Как защититься от HTTP/2 Bomb

Пока Microsoft и Cloudflare не выпустили обновления, Calif рекомендует либо отключить HTTP/2, либо ограничить максимальное количество заголовков, которые клиент может отправить в одном запросе.

Выводы

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

Технический разбор и PoC-скрипты опубликованы в блоге Calif и на GitHub. Дополнительные детали — в материале The Register.

Если ваш сервер использует HTTP/2 — проверьте защиту от HTTP/2 Bomb: обновите ПО и ограничьте заголовки прямо сейчас.

Техника описана в исследовательской статье, которую представят на конференции DIMVA в июле 2026 года. Атака работает исключительно внутри браузера и не требует никаких действий от пользователя.

Как работает FROST

FROST (Fingerprinting Remotely using OPFS-based SSD Timing) использует побочный канал утечки на основе конкуренции процессов за доступ к общему ресурсу. В данном случае ресурс — SSD-накопитель пользователя.

Вредоносный сайт создаёт большой файл (от 1 ГБ) в Origin Private File System (OPFS) — изолированном хранилище, доступном через JavaScript без запроса разрешений. Затем код выполняет случайные чтения из этого файла и измеряет задержки. Если в это время другая вкладка или приложение обращается к SSD, задержки меняются. Эти изменения анализирует предобученная свёрточная нейросеть (CNN), которая по сигнатуре нагрузки определяет, что именно работает в системе.

Исследователи продемонстрировали полноценную атаку на Mac с процессором M2. На Linux подтвердили работу базового примитива — измерение задержек через JavaScript. Windows в тестах не участвовала, но авторы не исключают, что техника применима и там.

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

FROST позволяет сайтам отслеживать открытые вкладки и приложения через анализ SSD-активности.

Атака работает внутри браузера через JavaScript и OPFS, без взаимодействия с пользователем.

Ключевой инструмент — свёрточная нейросеть, классифицирующая задержки чтения SSD.

Полная атака продемонстрирована на macOS (M2); на Linux работает базовый примитив.

Пока не зафиксировано случаев применения FROST в реальных условиях.

Ограничения и защита

У техники есть важные ограничения. Для атаки файл в OPFS должен занимать не менее 1 ГБ. Это означает, что массовое применение будет заметно: создание гигабайтного хранилища в браузере занимает время и место на диске. Кроме того, OPFS должен находиться на том же SSD, что и отслеживаемые приложения.

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

Итоги

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

Источник: Ars Technica. Читайте также о новой защите Firefox от цифрового отпечатка.

MiniPlasma — это эксплойт для уязвимости локального повышения привилегий (LPE) в драйвере cldflt.sys (Windows Cloud Files Mini Filter Driver). Уязвимость поднимает стандартного пользователя до SYSTEM за счёт состояния гонки в API облачных файлов Windows.

Уязвимость: повышение привилегий до SYSTEM через race condition в cldflt.sys — драйвере облачных файлов Windows.

Затронутые системы: все версии Windows, включая Windows 11 с патчами мая 2026 года. Не работает только в Insider Preview Canary.

История: CVE-2020-17103 была сообщена Google Project Zero в 2020 году и якобы исправлена, но патч оказался неэффективным.

PoC опубликован: исходный код и скомпилированный исполняемый файл доступны на GitHub.

Мотив раскрытия: исследователь публикует серию Windows zero-days в знак протеста против практик bug bounty в Microsoft.

Что делать: отключить синхронизацию OneDrive на критических системах до выхода патча; мониторить процессы с неожиданными SYSTEM-привилегиями.

Уязвимость не нова — впервые о ней сообщил исследователь Google Project Zero Джеймс Форшоу (James Forshaw) в сентябре 2020 года. В декабре 2020-го Microsoft выпустила патч и присвоила проблеме идентификатор CVE-2020-17103. Однако Chaotic Eclipse утверждает, что при повторном исследовании обнаружил: исходный PoC от Google Project Zero работает без каких-либо изменений.

Я не знаю, то ли Microsoft никогда не исправляла эту проблему, то ли патч был молча откатан в какой-то момент по неизвестным причинам. Оригинальный PoC от Google заработал без каких-либо изменений.

Как работает MiniPlasma

Уязвимость находится в рутине HsmOsBlockPlaceholderAccess драйвера облачных файлов cldflt.sys. Этот драйвер отвечает за управление placeholder-файлами — специальными записями в файловой системе, которые представляют облачные файлы ещё до их загрузки на устройство.

Механизм атаки

Эксплойт злоупотребляет API CfAbortHydration из Windows Cloud Files — функцией, которая прерывает процесс гидратации (загрузки содержимого облачного файла на локальный диск). В оригинальном отчёте Форшоу показал: через race condition в этом процессе можно создавать произвольные ключи реестра в кусте реестра .DEFAULT (системный куст, доступный до входа в Windows) без надлежащей проверки прав доступа.

Это классическая атака типа TOCTOU (Time-Of-Check-Time-Of-Use): между проверкой прав и фактической записью в реестр есть временное окно, которое эксплойт использует для создания привилегированных ключей реестра в привилегированном контексте. Именно поэтому исследователь оговаривается, что процент успеха может варьироваться в зависимости от конкретной системы.

Тест BleepingComputer подтвердил работоспособность: на стандартной учётной записи пользователя запуск эксплойта открыл командную строку с привилегиями SYSTEM на Windows 11 Pro с последними обновлениями мая 2026 года.

Серия zero-days от Chaotic Eclipse

MiniPlasma — не изолированный случай. За последние несколько недель тот же исследователь опубликовал шесть уязвимостей в Windows:

• BlueHammer (CVE-2026-33825) — локальное повышение привилегий, апрель 2026
• RedSun — ещё одно LPE; Microsoft тихо исправила без присвоения CVE
• UnDefend — инструмент DoS для Windows Defender
• YellowKey — обход BitLocker на Windows 11 / Server 2022/2025; открывает shell с доступом к дискам, защищённым только TPM
• GreenPlasma — дополнительное повышение привилегий
• MiniPlasma — настоящий материал, май 2026

Первые три уязвимости уже фиксировались в реальных атаках после публичного раскрытия. Исследователь открыто заявляет о мотиве: он публикует zero-days в знак протеста против того, как Microsoft обращается с участниками программы bug bounty.

Тот же компонент уже атаковали в 2025 году

В декабре 2025 года Microsoft устранила CVE-2025-62221 — ещё одну уязвимость повышения привилегий в том же компоненте cldflt.sys (CVSS 7.8). На тот момент она уже эксплуатировалась неизвестными злоумышленниками. Это показывает, что Cloud Filter Driver остаётся привлекательной целью для атакующих.

Что делать прямо сейчас

Официального патча от Microsoft пока нет. BleepingComputer связалась с компанией — ответа на момент публикации не поступило. До выхода патча рекомендуем следующие меры:

1. Ограничьте использование OneDrive и других облачных синхронизаций на критических серверах и рабочих станциях с доступом к чувствительным данным.
2. Включите ведение аудита создания ключей реестра (Event ID 4657) — особенно в кустах HKEY_USERS\.DEFAULT.
3. Мониторьте процессы, запущенные с неожиданными привилегиями SYSTEM от имени обычного пользователя (Event ID 4688 + 4672).
4. Настройте EDR/AV-решение на обнаружение создания процессов с привилегиями SYSTEM из непривилегированного контекста.
5. Следите за обновлениями от Microsoft через Microsoft Security Response Center.

Проверить, включена ли фильтрация облачных файлов на системе:

Выводы

MiniPlasma демонстрирует системную проблему: уязвимость, о которой знали ещё в 2020 году, снова стала актуальной угрозой. Независимо от причины — неполный патч или молчаливый откат — компонент cldflt.sys остаётся вектором атаки даже на полностью обновлённых системах.

Я вооружил оригинальный PoC, чтобы порождать SYSTEM shell. Похоже, это надёжно работает на моих машинах, хотя процент успеха может варьироваться, поскольку это состояние гонки.

Пока патча нет, PoC уже доступен на GitHub — это значит, что технически грамотные злоумышленники уже могут адаптировать эксплойт. Проверьте статус CldFlt, включите аудит реестра (Event ID 4657) и мониторинг SYSTEM-процессов (Event ID 4688+4672). Источники: BleepingComputer, The Hacker News.

Проверьте, запущен ли cldflt.sys на ваших системах, и подпишитесь на бюллетени MSRC, чтобы получить патч сразу после выхода.

Атака не теоретическая. Первая практическая демонстрация вышла в 2004 году; в 2005 поверх неё надстроили языковые модели. В 2023 исследовательская группа из университетов Surrey, Durham и Royal Holloway показала 95%+ top-1 точности (то есть угадывания клавиши с первой попытки) на MacBook Pro — по записи со смартфона на расстоянии 17 см. Изменилось одно — теперь обучить такую модель может любой разработчик за полдня на собственном ноутбуке.

Реальная угроза. Не подложенный микрофон в офисе, а Zoom, Teams, Meet, Discord, голосовые сообщения, заражённые браузерные вкладки, ноутбук в кафе. Везде, где вы сами включили микрофон.

Точность. Мини-CNN на 250 тыс. параметров: top-1 82–88%, top-3 95–97% на 35 классах (буквы + знаки) при 3000 семплов на пару пользователь/клавиатура.

Пароли особенно уязвимы. Языковая модель не помогает (пароли не из словаря), зато сужается перебор: top-3 предсказаний на символ → 3⁸ = 6 561 кандидат для 8-символьного пароля. Online brute force против большинства сервисов.

Что работает в защите. Мьют микрофона перед вводом пароля + менеджер паролей (auto-fill полностью убирает акустический сигнал) + аппаратные ключи (FIDO2/YubiKey).

Что НЕ работает. «Печатать тише», случайный ритм набора, программные шумодавы (RNNoise, Krisp). Шумодавы оптимизированы под речь — клик клавиши проходит почти без потерь.

Что именно слышит микрофон

Когда вы нажимаете клавишу A, микрофон ловит три события: push (механический клик дна хода клавиши, ~5–10 мс, широкий спектр), release (возврат купола вверх, ниже по амплитуде, через 10–30 мс) и — главное — резонанс корпуса. Удар по клавише заставляет шасси ноутбука кратко звенеть на собственных частотах, а разные клавиши находятся на разных расстояниях от резонансных узлов и возбуждают чуть разные моды.

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

Релевантная полоса частот — 400 Гц … 12 кГц. Ниже — комнатный шум и кондиционер; выше — тишина и собственный шум микрофона. Стандартного 44,1 кГц моно более чем достаточно: фирменный микрофон не нужен.

Что собирает атакующий

Авторы pwn.guide публикуют полный пайплайн на Python — около 200 строк кода, всё через pip-зависимости (numpy, scipy, librosa, soundfile, sounddevice, pynput, torch). Шаги:

1. Сбор: 3 000 размеченных нажатий (≈15 минут естественного набора). Скрипт collect.py параллельно ведёт лог нажатий через pynput и пишет аудио. Используется time.perf_counter(), чтобы NTP-коррекция не сбила метки.
2. Нарезка: аудио рубится на 100-мс окна вокруг каждого нажатия. Между событием в ОС и пиком в аудио есть 5–40 мс задержки — её надо выровнять поиском пика по огибающей. Без этого точность падает с 85% до 60%.
3. Фичи: для каждого окна — log-mel спектрограмма (64 mel-бина, fmin=400, fmax=12 000). Тензор (64 × 35), один клип ≈ 9 КБ.
4. Модель: компактная CNN на ~250 тыс. параметров — четыре свёрточных блока + AdaptiveAvgPool. На GPU тренируется за 5 минут, на CPU — за 30.
5. Инференс: предсказание для 100-мс окна занимает доли миллисекунды.

Цифры, ради которых это страшно

На самостоятельно собранном датасете из ~3 000 нажатий и 35 классов:

• Top-1 точность: 82–88%, в зависимости от шума при сборе данных.
• Top-3 точность: 95–97% — почти всегда правильная клавиша входит в тройку лучших предсказаний.
• Распределение по классам неровное. Space, Enter, Backspace — около 99% (механически отличаются от обычных клавиш). Соседние буквы основного ряда (F/G, J/K) — иногда 60% top-1.

85% точности на уровне символов звучит не страшно — в предложении будет 2–3 ошибки. Но если прогнать top-5 предсказаний через beam search с словарём частотности слов, восстановление связного текста на естественном языке выходит на 95%+ точности на уровне слов. Это исследовали ещё Zhuang и соавторы в 2005 году; современные char-LM делают этот шаг тривиальным.

Почему пароли беззащитнее обычного текста

Языковая модель — главное усиление атаки на обычный текст — на паролях не работает: их специально проектируют непохожими на слова. Зато у атакующего другое преимущество: пространство поиска ограничено. Если модель выдаёт top-3 предсказания на символ с 96% точностью, у 8-символьного пароля максимум 3⁸ = 6 561 кандидат для перебора. Это в зоне online brute force против большинства сервисов и тривиально оффлайн против любого слитого хеша.

В 2026 году аудиозапись того, как вы набираете пароль, эквивалентна передаче пароля.

Что реально защищает — и что нет

Авторы прямо сортируют защиты по эффективности.

Работает:

1. Мьют микрофона перед вводом любого секрета. Единственная полностью надёжная защита и стоит ноль.
2. Менеджер паролей с auto-fill. Нет нажатий — нет акустического сигнала. Самая большая практическая мера именно против атаки на пароли.
3. Аппаратные ключи (FIDO2/WebAuthn, YubiKey). Один тап = один акустический след, восстанавливать нечего.
4. Внешняя клавиатура подальше от микрофона. Механика не безопаснее — она громче. Но USB-клавиатура на дальнем краю стола, на отдельной поверхности, материально снижает SNR.
5. Акустическое демпфирование. Толстый коврик или сложенное полотенце под ноутбуком — снижение резонанса корпуса на 3–6 дБ. Помогает, но не панацея.

Не работает (вопреки ожиданиям):

• «Печатать тише». Амплитуда падает, спектральный отпечаток сохраняется. Минус 5% точности.
• Случайный ритм набора. Атака работает по отдельным нажатиям, не учитывает межударные интервалы.
• Программные шумодавы (RNNoise, Krisp). Тюнятся под сохранение речи и удаление широкополосного шума. Клавишные транзиенты выглядят как короткие речевые звуки и проходят насквозь — некоторые шумодавы даже «чистят» нажатия от окружающего фона.
• Белый шум на фоне. Современные модели учатся с шумовой аугментацией — постоянный фон сдвигает точность на копейки. Прерывистые звуки (музыка с резкими пиками) мешают сильнее, но и для оператора некомфортнее.

Чек-лист «что сделать сегодня»

1. Проверить, что у вас стоит password manager с auto-fill (1Password, Bitwarden, KeePassXC, Яндекс.Ключ — что вам ближе) и им активно пользуются для всех проводных логинов.
2. Купить или подключить аппаратный ключ для критичных аккаунтов (root в облаках, GitHub, банк-клиент). YubiKey 5 серии или Token2 — общедоступно в РФ.
3. Поставить хоткей на «mute mic» в Zoom/Teams/Discord, чтобы рефлекторно нажимать перед вводом любого секрета.
4. Если работаете из публичного пространства — внешняя клавиатура подальше от ноутбука, либо bluetooth-наушники с шумодавом + далеко отнесённый телефон вместо встроенного микрофона.
5. Команды разработки: добавить «mute при работе с секретами» в общий гайд по безопасности, а аппаратные ключи — в onboarding для новых сотрудников.

Выводы

Технический барьер атаки за два десятилетия упал до уровня «студент за выходные обучит модель на ноутбуке». Это значит, что угроза перестала быть теоретической — это рабочий инструмент в руках любого, у кого есть доступ к записи вашего созвона. Главная мысль: рассматривать включённый микрофон рядом с клавиатурой как реальный канал утечки секретов, а не как абстрактный риск из академических статей.

Хорошая новость в том, что защита дёшева и не требует новых технологий — менеджер паролей (про бесплатный open-source Bitwarden у нас уже выходил материал) плюс мьют микрофона закрывают практически весь сценарий. Аппаратные ключи (см. обзор YubiKey 5) закрывают остаток.

Источник: Acoustic Keystroke Recovery — Reconstructing Typed Text from a Laptop Microphone (pwn.guide).

• Скомпрометирована одна npm-версия @bitwarden/cli@2026.4.0. Окно атаки — 1 час 33 минуты 22 апреля 2026 года.
• Vault-данные пользователей Bitwarden не затронуты. Пострадал только npm-канал доставки CLI и те, кто успел поставить эту сборку.
• Вектор — скомпрометированный action checkmarx/ast-github-action, который Bitwarden подтягивал в свой CI. По словам исследователей, это первый зафиксированный взлом пакета через npm trusted publishing.
• Малварь таргетит ИИ-ассистенты Claude, Cursor, Codex CLI, Aider и AWS-based Kiro — отдельный модуль собирает их конфиги и API-ключи.
• Если ставили — ротируйте npm/GitHub-токены, SSH-ключи и облачные креденшлы AWS/Azure/GCP; проверьте CI/CD-пайплайны и публичные репозитории со строкой «Shai-Hulud» в имени.

Что случилось с пакетом

По данным The Hacker News, в ночь с 22 на 23 апреля 2026 года в npm-реестре появилась версия @bitwarden/cli@2026.4.0 с дополнительным файлом bw1.js внутри. Сборка была доступна 1 час 33 минуты — с 17:57 до 19:30 по времени Нью-Йорка, — после чего её сняли с публикации. Первыми на неё обратили внимание исследователи Socket, JFrog и OX Security. JFrog описал поведение как «кражу GitHub/npm-токенов, содержимого .ssh, .env, истории shell, секретов GitHub Actions и облачных провайдеров с выгрузкой на внешние домены и в виде коммитов в GitHub».

Bitwarden подтвердил инцидент и уточнил, что «расследование не обнаружило признаков доступа к данным пользовательских хранилищ и компрометации продакшн-систем». По словам компании, доступ нарушителя был отозван, вредоносный релиз помечен как deprecated, по версии 2026.4.0 заводится отдельный CVE. Пострадавшие — только те, кто успел скачать пакет в полуторачасовом окне и выполнил его установку.

Как устроен троян

Механика по отчёту Socket проста, но многоступенчата. В package.json зловредной версии добавлен preinstall-хук, который запускает скрипт bw_setup.js. Тот проверяет наличие Bun — альтернативного JS-рантайма — и, если его нет, скачивает. Затем Bun-ом запускается обфусцированный загрузчик bw1.js. Bun тащат с собой не случайно: на машине жертвы его, скорее всего, нет, а корпоративный EDR (антивирус нового поколения для рабочих станций и серверов) реагирует на неожиданный бинарник хуже, чем на стандартный npm-скрипт. Preinstall-хук при этом срабатывает ещё до того, как код пакета формально «установлен».

• npm- и GitHub-токены из локальных конфигов и переменных окружения;
• приватные SSH-ключи из ~/.ssh;
• содержимое .env-файлов и историю shell (.bash_history, .zsh_history);
• секреты GitHub Actions из переменных окружения CI;
• креденшлы облачных провайдеров — AWS, Azure, Google Cloud;
• конфиги и API-ключи ИИ-ассистентов Claude, Cursor, Codex CLI, Aider и AWS-based Kiro.

Собранные данные шифруются AES-256-GCM и выгружаются двумя каналами. Основной — POST на домен audit.checkmarx[.]cx (конкретно путь /v1/telemetry), который притворяется инфраструктурой Checkmarx. Резервный — малварь создаёт публичные GitHub-репозитории в аккаунте жертвы и кладёт туда зашифрованный payload. В названиях репозиториев встречается строка «Shai-Hulud: The Third Coming» — отсылка к прошлогодней одноимённой кампании в npm. OX Security подчёркивает, что такой тайник (по терминологии безопасников — dead-drop) через GitHub опасен отдельно: утёкшие секреты становятся доступны любому, кто ищет по публичным репозиториям, — а системы защиты почти не следят за исходящим трафиком в GitHub.

Поверх этого в бинарнике есть модуль-червь: с украденным npm-токеном малварь находит все пакеты, которые жертва имеет право публиковать, и вбрасывает в них тот же payload. Endor Labs называет его «CanisterSprawl» и считает один из самых полных npm supply chain-пейлоадов на сегодняшний день: шесть разных поверхностей для сбора секретов, OIDC- и cloud-кража, самораспространение через npm-публикации и отдельный модуль для ИИ-ассистентов.

Отдельный удар по ИИ-ассистентам

Отдельный модуль малвари специально ищет артефакты ИИ-кодеров — API-ключи OpenAI и Anthropic из конфигов Claude, Cursor и Codex CLI, токены Aider, настройки AWS-based Kiro. Endor Labs считает, что это один из первых публично задокументированных случаев, когда supply chain-атака отдельной веткой целится на «кошельки разработчиков у ИИ». Ключ к Anthropic или OpenAI — это не только деньги на балансе аккаунта жертвы, но и возможность с его помощью заставить ИИ-ассистента писать закладки в код при следующих авто-запросах.

Почему малварь пропускает русскую локаль

Малварь завершается без выполнения, если в системе выставлена русская локаль. Socket отмечает три возможных причины: отдельный оператор, использующий общую инфраструктуру, отколовшаяся группа с идеологическими мотивами или эволюция самой кампании. На практике для российских разработчиков это не даёт защиты: большинство dev-машин, серверов и CI-раннеров работают с англоязычной локалью по умолчанию (обычно en_US.UTF-8), поэтому пропуск по локали чаще всего не срабатывает.

Что делать, если могли установить 2026.4.0

• Сначала убедитесь, что пакет действительно попал в ваши машины и раннеры: прогрепайте package-lock.json, pnpm-lock.yaml и yarn.lock на @bitwarden/cli версии 2026.4.0, посмотрите логи npm-установок в ночь на 23 апреля МСК.
• Ротируйте все токены с этих машин: npm-токены, GitHub PAT (включая fine-grained), SSH-ключи, AWS access/secret keys и STS-сессии, Azure SP, GCP service accounts.
• Замените секреты в GitHub Actions и других CI-системах, где пакет мог запускаться, — включая secrets, variables и OIDC-конфигурации.
• Пройдитесь по API-ключам ИИ-ассистентов (Anthropic, OpenAI, Cursor, Aider) и отзовите их в кабинетах провайдеров; сверьте биллинг на предмет аномальных трат.
• Проверьте публичные репозитории в своём GitHub-аккаунте: ищите имена в формате <слово>-<слово>-<3 цифры> (например, fremen-muaddib-042) со строкой «Shai-Hulud» в README и удалите.
• Откатитесь на безопасную версию CLI — 2026.3.x или актуальную стабильную, которую Bitwarden опубликовал после инцидента. Ставьте её через npm i @bitwarden/cli@<версия>, а не через latest или диапазон.

Связь с Checkmarx и первый взлом через npm trusted publishing

Накануне, 21 апреля, Checkmarx раскрыла собственный инцидент — компрометацию KICS Docker-образов, GitHub-расширений и пакета checkmarx/ast-github-action, который используется во многих CI-пайплайнах. По данным Endor Labs, репозиторий Bitwarden подтягивал именно этот action, и через него злоумышленники получили доступ к npm-каналу. Socket приводит прямые пересечения: тот же домен audit.checkmarx[.]cx, тот же паттерн обфускации __decodeScrambled с seed-значением 0x3039 — технический отпечаток, указывающий на одних и тех же авторов, — плюс тот же приём «украсть → выгрузить в GitHub → распространиться дальше».

Исследователь Аднан Хан утверждает, что это первый зафиксированный случай компрометации пакета, использующего npm trusted publishing — механизм OIDC-публикации, при котором GitHub Actions обменивается на короткоживущий npm-токен без долгоживущих секретов в CI. Его как раз продвигали в ответ на регулярные утечки npm-токенов у мейнтейнеров. На деле trusted publishing оказался не панацеей: если нарушитель получает доступ к GitHub Actions-воркфлоу с правом публиковать пакет, OIDC-токен ему выдаёт сам npm. Атрибуция у исследователей — группа TeamPCP, уже засветившаяся на взломах LiteLLM и Trivy. Аккаунт TeamPCP в X на момент выхода материала заблокирован.

Выводы для npm-экосистемы и supply chain

Случай укладывается в серию ударов по цепочке доставки последних двух недель: Trivy и LiteLLM на PyPI, Axios и PyPI, теперь Checkmarx и Bitwarden. Характерная деталь — защитный слой не спасает: trusted publishing, OIDC и короткоживущие токены не помогают, если злоумышленник уже получил доступ к CI-воркфлоу. Практический вывод: pin-версии в лок-файлах, отдельный CI-аккаунт с минимальными правами, еженедельная ревизия CI-секретов и мониторинг собственного GitHub на появление незнакомых публичных репозиториев. Инвентаризация секретов, которые ходят через CI/CD, перестала быть теоретическим упражнением.

17 апреля 2026 года исследователи Huntress Labs сообщили в своём отчёте, что эксплойты BlueHammer, RedSun и UnDefend, слитые в сеть в начале месяца анонимным исследователем под ником Nightmare-Eclipse, теперь применяются в живых кибератаках. По данным BleepingComputer, BlueHammer атакуют с 10 апреля, а RedSun и UnDefend зафиксированы на устройстве, скомпрометированном через учётку SSLVPN — с признаками hands-on-keyboard-атаки (ручное управление оператором, а не автоматический скрипт).

• BlueHammer — LPE (локальное повышение привилегий) в Microsoft Defender, получил CVE-2026-33825 и запатчен в апрельском Patch Tuesday. Эксплуатируется с 10 апреля 2026 года.
• RedSun — даёт SYSTEM-привилегии через обход cloud-tag-механизма Defender, работает на Windows 10, 11 и Server 2019+ даже после установки апрельских обновлений.
• UnDefend — позволяет обычному пользователю блокировать обновления сигнатур Defender, оставляя систему с устаревшей защитой.
• PoC-код (proof-of-concept, пример рабочего эксплойта) всех трёх уязвимостей публично доступен, Huntress фиксирует использование в живых атаках.
• Microsoft пока не выпустила патчи для RedSun и UnDefend, сроки не анонсированы.

Три zero-day в Microsoft Defender — что внутри

Все три бага находятся в Microsoft Defender — штатном антивирусе Windows, который установлен на миллионах машин по умолчанию. Парадокс уязвимостей в том, что атакующий использует сам механизм защиты: превращает Defender в инструмент для повышения привилегий или отключения собственных обновлений.

BlueHammer (CVE-2026-33825) — запатчен в апреле, эксплуатировался до патча

Local privilege escalation (локальное повышение привилегий) в Microsoft Defender. Microsoft выпустила патч в составе апрельского Patch Tuesday — 14 апреля 2026 года. Huntress зафиксировал эксплуатацию в атаках с 10 апреля — то есть за четыре дня до того, как вышло официальное исправление. На момент этих атак BlueHammer был полноценным zero-day без публичного патча.

RedSun — обход cloud-tag-механизма Defender

Самая опасная из трёх. Microsoft Defender при проверке файла сверяется с облачным сервисом репутации — cloud tag. Если вердикт помечает файл как вредоносный, антивирус отправляет его в карантин. Но в механизме реакции есть баг: при определённых условиях Defender не просто удаляет заражённый файл, а пытается «восстановить» его из облачного бэкапа обратно по исходному пути. PoC RedSun манипулирует путём восстановления так, чтобы Defender перезаписал системный файл Windows содержимым, подконтрольным атакующему. Запись идёт от процесса Defender, который работает с правами SYSTEM — поэтому обычный пользователь получает полные административные привилегии.

RedSun работает на Windows 10, Windows 11 и Windows Server 2019 и новее. Патча от Microsoft нет — даже после применения апрельских обновлений эксплойт продолжает работать.

UnDefend — блокировка обновлений Defender

Не про привилегии, а про «ослепление» защиты. UnDefend позволяет обычному пользователю (не админу) заблокировать обновление сигнатур и определений Windows Defender. Это значит, что после эксплуатации антивирус продолжает работать, но постепенно устаревает и перестаёт ловить новые угрозы. Идеальная подготовка почвы для последующих атак.

Хронология утечки и атак

1. Начало апреля 2026 — анонимный исследователь Nightmare-Eclipse (он же Chaotic Eclipse) публикует PoC всех трёх уязвимостей в знак протеста против того, как Microsoft Security Response Center (MSRC) обработал процесс раскрытия.
2. 10 апреля 2026 — Huntress фиксирует первые попытки эксплуатации BlueHammer в реальных атаках. На этот момент патча от Microsoft ещё нет, это полноценный zero-day.
3. 14 апреля 2026 — Microsoft выпускает апрельский Patch Tuesday, в котором BlueHammer получает CVE-2026-33825 и исправление. RedSun и UnDefend остаются без патча.
4. 16—17 апреля 2026 — на устройстве, взломанном через учётку SSLVPN, обнаружены эксплойты UnDefend и RedSun. Активность имеет признаки «hands-on-keyboard» — ручного управления оператором, а не автоматической малвари.
5. 17 апреля 2026 — Huntress публикует отчёт, BleepingComputer распространяет новость.

Что делать прямо сейчас

Универсального патча для RedSun и UnDefend нет. Ниже — шесть митигаций, первые три закрывают основной вектор атаки и должны быть сделаны прямо сейчас. Остальные — желательны, но не критичны, если первые три уже настроены.

1. [Обязательно] Установите апрельский Patch Tuesday — это закрывает BlueHammer (CVE-2026-33825). Актуально для всех поддерживаемых Windows.
2. [Обязательно] Включите Attack Surface Reduction (ASR) в Windows Defender — правила, которые блокируют типовые техники эксплуатации даже без патча на конкретный CVE. Минимальный набор — правила блокировки создания дочерних процессов Office-приложениями и запуска исполняемых файлов из писем.
3. [Обязательно] Проверьте журналы SSLVPN и RDP на признаки компрометации за последние две недели. Huntress указывает: эксплойты пришли именно через скомпрометированные учётки удалённого доступа. Конкретные сигналы — входы в нерабочие часы, логины с новых IP и ASN, серии неуспешных попыток перед успешным входом, одновременные сессии с разных географий.
4. [Желательно] Ограничьте модификацию системных файлов через Windows Defender Application Control (WDAC) или AppLocker — это снизит эффективность RedSun.
5. [Желательно] Настройте мониторинг обновлений сигнатур Defender — UnDefend блокирует их незаметно, и машина считается защищённой, хотя новые угрозы уже не ловятся.
6. [Желательно] Рассмотрите EDR (Endpoint Detection and Response, решения для обнаружения и реагирования на угрозы) третьих сторон — если ваш SOC зависит только от Defender, на текущий момент это single point of failure (единая точка отказа).

Почему исследователь слил всё публично

Nightmare-Eclipse в предыдущем комментарии BleepingComputer объяснил публикацию PoC как протест против практик MSRC: по его словам, Microsoft затягивала с исправлениями и не реагировала на репорты в приемлемые сроки. Позиция Microsoft противоположная.

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

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

Итог

Конфликт между исследователем и MSRC превратился в реальные атаки на инфраструктуру. Для администраторов главное — не ждать следующего Patch Tuesday молча, а закрыть то, что можно закрыть сейчас: апрельские обновления, ASR-правила и проверку журналов удалённого доступа. RedSun и UnDefend — это не теоретические угрозы, это инструменты, которые уже используют для закрепления на скомпрометированных машинах.

Источники: BleepingComputer, Huntress Labs, Microsoft Security Update Guide (CVE-2026-33825).

Smart Engines представила третью версию антифрод-системы «Шерлок» — «Шерлок 3о». Система определяет поддельные документы, сгенерированные современными генеративными моделями: NanoBanana, ChatGPT, Grok, Qwen, Midjourney, Stable Diffusion, Flux и ещё 20+ других.

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

Что умеет «Шерлок 3о»:

• детектирует дипфейки изображений документов по 600 признакам
• находит коллажи, включая вставку отдельных символов
• анализирует голограммы, NFC-чип, метаданные файла, защитные элементы
• выполняет небиометрическую сверку лиц
• сигнализирует при перекрытии значимых данных на документе

Новая версия ориентирована на компании с обязательной идентификацией клиентов: банки, МФО, страховые. Решение уже работает в аэропортах Шереметьево, Внуково и Кольцово, ФНС России и нотариате. МФО «Займер» за год использования предотвратил больше 10 000 попыток взять заём по чужим паспортам.

Генеральный директор Smart Engines Владимир Арлазаров называет происходящее «демократизацией фрода»: атаки стали дешевле, быстрее и полностью автоматическими. Что точно описывает ситуацию, когда качественный фейк паспорта стоит ровно столько, сколько стоит подписка на генеративную модель.

В России в 2026 году при Минцифры создана межведомственная рабочая группа по противодействию незаконному использованию технологий дипфейков.

Это не рядовое обновление безопасности: OpenSSH 10.3 меняет поведение сертификатов, ужесточает валидацию и предупреждает о необходимости перехода на постквантовые алгоритмы обмена ключами.

• OpenSSH 10.3 (релиз 2 апреля 2026) — исправление shell injection в ssh через %-tokens в ssh_config
• Изменено поведение сертификатов: пустая секция principals больше не работает как wildcard
• scp в legacy-режиме больше не сохраняет setuid/setgid при скачивании файлов от root
• Исправлена ошибка в PubkeyAcceptedAlgorithms: ECDSA-алгоритмы больше не взаимозаменяемы
• Начало постквантовой миграции: предупреждения о не-PQC алгоритмах обмена ключами

Исправления безопасности

Shell injection через имена пользователей

Самый серьёзный фикс: валидация метасимволов оболочки в именах пользователей, переданных через командную строку, выполнялась слишком поздно. В определённых конфигурациях — например, при использовании %u в блоке Match exec — атакующий мог выполнить произвольные shell-команды.

Обнаружил: Florian Kohnhäuser. Разработчики OpenSSH напоминают: не стоит напрямую передавать пользовательский ввод в командную строку ssh.

Ошибка в principals сертификатов

До 10.3 сертификат с пустой секцией principals работал как wildcard — позволял аутентификацию от имени любого пользователя, доверяющего CA через authorized_keys. Если CA случайно выпускал такой сертификат — вместо бесполезности он давал максимальный доступ.

Теперь: пустая секция principals не совпадает ни с одним principal. Также исправлена обработка wildcard-символов в principals сертификатов.

setuid/setgid в scp

При скачивании файлов через scp -O (legacy mode) от root без флага -p — setuid/setgid биты не очищались. Баг существовал с оригинальной программы rcp из Berkeley.

ECDSA: алгоритмы больше не взаимозаменяемы

Если в PubkeyAcceptedAlgorithms указан один ECDSA-алгоритм (например, ecdsa-sha2-nistp384), другие ECDSA-алгоритмы тоже принимались. Теперь каждый алгоритм проверяется строго по списку.

Потенциально несовместимые изменения

• Rekeying обязателен. Убрана совместимость с реализациями SSH, которые не поддерживают rekeying. Такие соединения теперь будут разрываться при необходимости обновить ключи сессии
• ProxyJump валидирует имена. Параметры -J и ProxyJump из командной строки теперь проверяют имена пользователей и хостов на метасимволы. Это предотвращает shell injection при прямом пробросе пользовательского ввода

Постквантовая миграция

OpenSSH 10.3 начинает предупреждать о соединениях, использующих не-постквантовые алгоритмы обмена ключами. Это не блокировка — пока только предупреждение в логах — но сигнал индустрии: миграция на PQC-алгоритмы должна начаться уже сейчас.

Контекст: Cloudflare нацелился на полную постквантовую безопасность к 2029 году. Filippo Valsorda, ведущий криптограф Go, считает, что риск появления криптографически значимых квантовых компьютеров в ближайшие годы достаточно высок, чтобы действовать.

Проверить, какие алгоритмы используют ваши соединения:

Как обновиться

Выводы

OpenSSH 10.3 — важный релиз: не только закрывает реальные уязвимости (shell injection, ошибки сертификатов), но и начинает подготовку экосистемы к постквантовому будущему. Обновитесь и проверьте, какие алгоритмы используют ваши SSH-соединения.

Атака получила название GPUBreach и стала первым практическим доказательством того, что RowHammer-уязвимости в GPU-памяти позволяют не просто повредить данные, а полностью захватить машину.

• GPUBreach — первая атака, которая превращает bit-flips в GDDR6-памяти GPU в полную эскалацию привилегий до root на CPU
• Работает даже при включённом IOMMU — ключевом механизме аппаратной изоляции памяти
• Атака позволяет: извлечь криптографические ключи из NVIDIA cuPQC, деградировать точность ML-моделей до 80%, получить root shell
• Затрагивает облачные ИИ-инфраструктуры, мультитенантные GPU-кластеры и HPC-среды
• На десктопных/ноутбучных GPU (без ECC) защиты пока не существует

Что такое RowHammer и почему это касается GPU

RowHammer — известная с 2014 года проблема DRAM-памяти: многократное обращение к одной строке памяти вызывает электрические помехи, которые переворачивают биты в соседних строках (0→1 или 1→0). Это подрывает базовые гарантии изоляции памяти в операционных системах.

Производители DRAM внедрили аппаратные защиты — ECC (коды коррекции ошибок) и TRR (Target Row Refresh). Но до недавнего времени считалось, что GPU-память неуязвима для RowHammer из-за архитектурных особенностей.

В июле 2025 года те же исследователи из Университета Торонто показали GPUHammer — первую практическую RowHammer-атаку на NVIDIA GPU с GDDR6-памятью. Она использовала многопоточное параллельное «простукивание» для обхода архитектурных защит. Результат — деградация точности ML-моделей до 80%.

GPUBreach идёт дальше: от порчи данных — к полному захвату системы.

Как работает GPUBreach

Атака состоит из трёх этапов:

1. RowHammer на GPU page tables. Атакующий процесс (непривилегированный CUDA-ядро) вызывает bit-flips в таблицах страниц GPU-памяти, получая произвольный доступ на чтение/запись ко всей памяти GPU
2. Обход IOMMU. Скомпрометированный GPU отправляет DMA-запросы в область CPU-памяти, которую IOMMU разрешает — буферы драйвера NVIDIA. Повреждая доверенное состояние драйвера, атака эксплуатирует баги безопасности памяти в ядерном модуле NVIDIA
3. Эскалация до root. Через произвольную запись в ядро атакующий запускает root shell на хосте

GPUBreach показывает, что IOMMU недостаточно: повреждая доверенное состояние драйвера в буферах, разрешённых IOMMU, мы запускаем out-of-bounds запись на уровне ядра — полностью обходя защиту IOMMU без необходимости его отключать.

Ключевое отличие GPUBreach от параллельных исследований (GDDRHammer и GeForge): те тоже используют RowHammer на GPU page tables, но GPUBreach — единственная атака, которая достигает полной эскалации привилегий на CPU. GeForge требует отключённого IOMMU, GDDRHammer работает только на уровне GPU-памяти.

Что можно украсть

Через GPUBreach исследователи продемонстрировали три сценария:

• Утечка криптографических ключей из NVIDIA cuPQC (постквантовая криптографическая библиотека)
• Деградация ML-моделей — точность падает до 80% при работе на скомпрометированном GPU
• Root shell на хосте — полный контроль над машиной, включая доступ ко всем контейнерам и данным других пользователей

Это особенно критично для облачных ИИ-инфраструктур, где несколько клиентов делят одни и те же GPU. Атакующий в одном виртуальном окружении может получить доступ к данным и моделям соседей.

Как защититься

Единственная известная мера — включить ECC на GPU:

Если ECC выключен — включите (потребуется перезагрузка):

Но и ECC — не абсолютная защита:

• ECC корректирует 1-2 bit-flips, но атаки на DDR4/DDR5 уже показали возможность вызвать 3+ bit-flips — ECC такое не исправит
• На десктопных и ноутбучных GPU ECC недоступен — и защиты для них пока не существует
• Серверные GPU (A100, H100) поддерживают ECC, но его нужно явно включить

Выводы

GPUBreach меняет модель угроз для GPU-вычислений. До сих пор GPU-память считалась изолированной от CPU — теперь это не так. Атака работает даже при включённом IOMMU, который был последним рубежом аппаратной защиты.

Для команд, использующих GPU в продакшене: проверьте, включён ли ECC на ваших серверных GPU. Для облачных провайдеров — это сигнал пересмотреть модель изоляции мультитенантных GPU-инстансов. Для пользователей десктопных GPU — на данный момент защиты не существует.

Полное исследование опубликовано командой Гурураджа Сайлешвара из Университета Торонто.

Уязвимость получила оценку критичности CVSS 8,8 из 10 и оказалась следствием неполного исправления CVE-2024-41110 — критической проблемы в том же компоненте, обнаруженной в июле 2024 года. Баг независимо нашли несколько исследователей, включая Владимира Токарева из Cyera Research Labs.

• CVE-2026-34040 (CVSS 8.8) — обход AuthZ-плагинов Docker Engine через раздутый HTTP-запрос (более 1 МБ)
• Атакующий получает привилегированный контейнер с root-доступом к файловой системе хоста: AWS-ключи, SSH, Kubernetes-конфиги
• Работает против всех AuthZ-плагинов в экосистеме — независимо от реализации
• ИИ-агенты (например, OpenClaw) могут эксплуатировать уязвимость автоматически, без специального вредоносного кода
• Патч: Docker Engine 29.3.1. Временные меры: rootless mode, ограничение доступа к Docker API

Как работает атака

Механизм уязвимости элегантно прост. Когда Docker Engine получает API-запрос, он пересылает его плагину авторизации (AuthZ) для проверки. Плагин анализирует тело запроса и решает — разрешить или заблокировать.

Проблема в том, что исправление CVE-2024-41110 не учло ситуацию с чрезмерно большими HTTP-запросами. Если тело запроса превышает 1 МБ, Docker Engine отбрасывает его перед отправкой плагину.

Результат: AuthZ-плагин видит пустой запрос, блокировать нечего — и пропускает его. А Docker Engine обрабатывает полный запрос целиком.

Плагин разрешает запрос, потому что не видит ничего подозрительного. Docker Engine обрабатывает полный запрос и создаёт привилегированный контейнер с root-доступом к хосту: ваши AWS-ключи, SSH-ключи, конфиги Kubernetes — всё на машине. Это работает против каждого AuthZ-плагина в экосистеме.

ИИ-агенты как вектор атаки

Исследователи из Cyera показали ещё более тревожный сценарий. ИИ-кодинг-агент вроде OpenClaw (open-source ИИ-ассистент, работающий в Docker-песочнице), может эксплуатировать CVE-2026-34040 автоматически.

Сценарий атаки через prompt injection (внедрение скрытых инструкций в данные, которые обрабатывает ИИ): злоумышленник прячет вредоносные команды в коде GitHub-репозитория. Разработчик просит агента проанализировать этот репозиторий. Агент выполняет скрытые инструкции, конструирует раздутый HTTP-запрос, обходит AuthZ и монтирует файловую систему хоста.

Но самое важное — агенту даже не нужен заражённый репозиторий. Если разработчик даёт агенту задачу вроде «отладь проблему с out-of-memory в Kubernetes», агент может самостоятельно попытаться получить доступ к kubeconfig. Получив отказ от AuthZ-плагина, он способен сконструировать обход — потому что CVE-2026-34040 не требует специального эксплойт-кода.

CVE-2026-34040 не требует эксплойт-кода, привилегий или специальных инструментов. Это один HTTP-запрос с дополнительным padding. Любой агент, который может прочитать документацию Docker API, способен его сконструировать.

Что делать

Основное исправление: обновить Docker Engine до версии 29.3.1.

Если немедленное обновление невозможно, примените временные меры:

1. Ограничьте доступ к Docker API — по принципу наименьших привилегий. Только доверенные пользователи и процессы
2. Переключитесь на rootless mode — даже привилегированный контейнер получит непривилегированный UID хоста. Вектор атаки сужается с «полный захват хоста» до «компрометация непривилегированного пользователя»
3. Используйте --userns-remap — если полный rootless mode невозможен, UID-маппинг даёт аналогичную изоляцию
4. Не полагайтесь на AuthZ-плагины, которые анализируют тело запроса для принятия решений о доступе

Выводы

CVE-2026-34040 — наглядный пример того, как неполный патч создаёт новую уязвимость. Первоначальная проблема (CVE-2024-41110, CVSS 10.0) была исправлена в июле 2024, но пограничный случай с большими запросами остался непокрытым.

Особенно тревожит вектор через ИИ-агентов: уязвимость настолько проста, что агент может открыть её самостоятельно, просто пытаясь выполнить легитимную задачу. Это ставит под вопрос модель безопасности Docker-песочниц для ИИ-кодинг-инструментов.

Обновитесь до Docker Engine 29.3.1 и пересмотрите, кто и что имеет доступ к вашему Docker API.

Supply chain атаки на пакетные менеджеры стали системной угрозой. Axios с 100 млн загрузок в неделю оказался заражён RAT-трояном через захваченный аккаунт мейнтейнера. Google атрибутировал атаку северокорейской группировке UNC1069. Параллельно обнаружены атаки на PyPI-пакеты LiteLLM и Trivy.

• Axios (npm, 100M+ загрузок/неделю) — RAT-троян через захваченный аккаунт мейнтейнера. Атрибуция: Северная Корея (UNC1069)
• PyPI-пакеты LiteLLM и Trivy — поддельные версии с вредоносным кодом через тайпсквоттинг
• Все атаки — через скомпрометированные учётные записи, а не уязвимости в коде
• OIDC Trusted Publishers снижает риск захвата аккаунта мейнтейнера — классические npm-токены уязвимы

Axios: RAT-троян в самом популярном HTTP-клиенте

30 марта 2026 года компания StepSecurity обнаружила две вредоносные версии axios — 1.14.1 и 0.30.4. Атакующий захватил npm-аккаунт ведущего мейнтейнера jasonsaayman, сменив email на подконтрольный адрес на ProtonMail.

В самом коде axios не было ни одной вредоносной строки. Вместо этого обе версии добавляли зависимость plain-crypto-js@4.2.1 — пакет, замаскированный под легитимный crypto-js. Его единственная задача — выполнить postinstall-скрипт (дроппер SILKBELL), который разворачивает кроссплатформенный RAT-троян для macOS, Windows и Linux.

В течение двух секунд после npm install малварь уже связывалась с C2-сервером атакующего — ещё до того, как npm заканчивал резолвинг зависимостей. После выполнения дроппер удалял себя и подменял package.json чистой версией, чтобы скрыть следы.

Хронология атаки на axios: от заражения до удаления за 3 часа

1. 30 марта, 05:57 UTC — публикация «чистой» версии plain-crypto-js@4.2.0 для создания истории пакета
2. 30 марта, 23:59 UTC — публикация вредоносной plain-crypto-js@4.2.1 с postinstall-хуком
3. 31 марта, 00:21 UTC — публикация axios@1.14.1 через захваченный аккаунт
4. 31 марта, 01:00 UTC — публикация axios@0.30.4 (legacy-ветка) — 39 минут спустя
5. 31 марта, ~03:15 UTC — npm удаляет обе версии. axios@1.14.1 был доступен ~2 часа 53 минуты

Атрибуция: Северная Корея

Google Threat Intelligence Group (GTIG) атрибутировал атаку северокорейской группировке UNC1069. Бэкдор WAVESHAPER.V2 — эволюция ранее известного импланта, используемого для кражи криптовалюты.

Microsoft подтвердил атрибуцию и связал инцидент с группировкой Sapphire Sleet (ответвление BlueNoroff). CrowdStrike связал атаку со Stardust Chollima через переиспользование кода ZshBucket. Исследователь Giuseppe Massaro обнаружил, что macOS-вариант содержит пути сборки, связывающие его с кампаниями RustBucket и Hidden Risk (2023–2024).

PyPI: поддельные пакеты LiteLLM и Trivy

Параллельно с атакой на Axios в конце марта обнаружены поддельные PyPI-пакеты, маскирующиеся под популярные библиотеки LiteLLM (ИИ-прокси для работы с несколькими LLM) и Trivy (сканер уязвимостей от Aqua Security). Атаки используют тайпсквоттинг — похожие имена пакетов — и нацелены на разработчиков, которые ошибаются при вводе имени зависимости.

Как отметил Томислав Перичин из ReversingLabs, атаки уже распространяются на PyPI и NuGet. Цель — максимальный охват разработчиков через все основные пакетные менеджеры. Подробный разбор инцидентов с LiteLLM, Telnyx и Trivy — в нашем предыдущем материале.

Как защититься: чеклист для разработчика

1. Аудит зависимостей — проверьте дерево зависимостей на наличие скомпрометированных версий. Для axios: если установлена 1.14.1 или 0.30.4 — считайте систему скомпрометированной
2. Пиннинг версий — фиксируйте точные версии в package-lock.json / poetry.lock. Но помните: SHA pinning не защищает от захвата аккаунта мейнтейнера
3. Мониторинг postinstall-скриптов — используйте npm audit, а также инструменты вроде Socket.dev или StepSecurity Harden-Runner для контроля сетевой активности при установке
4. Блокировка C2-доменов — добавьте в блоклист: sfrclak[.]com, IP 142.11.206[.]73
5. Ротация секретов — если затронутые пакеты были установлены, ротируйте все ключи API, токены и пароли в проекте
6. OIDC для публикации — используйте Trusted Publishers (npm OIDC) вместо долгоживущих токенов. Атака на axios стала возможна потому, что мейнтейнер использовал классический npm-токен
7. Аудит PyPI-зависимостей — проверьте имена пакетов в requirements.txt / pyproject.toml на тайпсквоттинг. Используйте pip-audit для проверки известных уязвимостей

Что изменилось в supply chain атаках 2026 года

Три инцидента за одну неделю показывают сдвиг в тактике: атакующие больше не ищут уязвимости в коде — они захватывают аккаунты мейнтейнеров и публикуют вредоносные версии от их имени. Ждать исправлений от мейнтейнеров недостаточно — нужен контроль на уровне CI/CD: OIDC для публикации, мониторинг сетевой активности при установке, аудит postinstall-скриптов.

Результат: примерно треть всех биткоинов — около 6,9 млн BTC — уже находится под повышенным риском, поскольку их публичные ключи засвечены в блокчейне.

Google снизила оценку ресурсов для взлома ECDLP-256 в 20 раз — до менее 500 000 физических кубитов

Квантовый компьютер сможет вскрыть приватный ключ Bitcoin за считанные минуты после раскрытия публичного ключа

Под угрозой 6,9 млн BTC (треть всего объёма) — особенно после обновления Taproot

Google не публикует квантовые схемы — результаты верифицированы через zero-knowledge proof

Дедлайн миграции на постквантовую криптографию — 2029 год

Что именно нашла Google

Исследование сфокусировано на задаче дискретного логарифма на эллиптических кривых (ECDLP-256) — математическом фундаменте криптографии на эллиптических кривых (elliptic curve cryptography), на которой построены Bitcoin, Ethereum и большинство блокчейнов. Команда скомпилировала два квантовых контура, реализующих алгоритм Шора:

• Вариант 1: менее 1200 логических кубитов + 90 млн вентилей Тоффоли
• Вариант 2: менее 1450 логических кубитов + 70 млн вентилей Тоффоли

По оценке авторов, эти контуры могут быть выполнены на сверхпроводящем квантовом компьютере с менее чем 500 000 физических кубитов за несколько минут. Ранее для взлома ECDLP-256 требовались миллионы физических кубитов — новая оценка в 20 раз ниже.

Для контекста: крупнейший квантовый процессор Google Willow (2024) содержит 105 кубитов. До 500 000 ещё далеко, но прогресс ускоряется нелинейно.

Окно атаки: от раскрытия ключа до кражи средств

Когда вы отправляете Bitcoin-транзакцию, ваш публичный ключ раскрывается в сети. До того как транзакция будет включена в блок (в среднем 10 минут), злоумышленник с квантовым компьютером теоретически может:

1. Извлечь публичный ключ из мемпула
2. Вычислить приватный ключ (по оценке CoinDesk — за ~9 минут)
3. Подписать свою транзакцию и перехватить средства

По данным исследования, вероятность успеть до подтверждения блока — 41%. Это не гарантия, но угрожающая статистика.

Ещё хуже ситуация с кошельками, где публичный ключ уже раскрыт навсегда — через повторное использование адреса или обновление Taproot (2021), которое по умолчанию выставляет публичные ключи в блокчейн. Таких кошельков — 6,9 млн BTC, включая 1,7 млн BTC с ранних дней сети (в том числе монеты Сатоши Накамото).

Ответственное раскрытие через zero-knowledge proof

Google не опубликовала сами квантовые контуры — это было бы равносильно руководству по атаке. Вместо этого команда использовала доказательство с нулевым разглашением (zero-knowledge proof): математическую конструкцию, позволяющую третьим сторонам верифицировать результаты без раскрытия деталей реализации.

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

Этот подход задаёт новый стандарт раскрытия уязвимостей в квантовой криптоаналитике. Google призывает другие исследовательские группы следовать этой модели.

Что это значит для разработчиков

Проблема касается не только криптовалют. ECDLP-256 лежит в основе криптографии на эллиптических кривых, которая используется повсеместно:

• TLS/HTTPS — защита веб-трафика
• SSH — аутентификация на серверах
• GPG/PGP — подписание и шифрование email
• JWT — токены авторизации (при использовании ES256)
• Подписи кода — верификация пакетов и обновлений

Однако централизованные системы (банки, HTTPS-серверы) могут обновить криптографию принудительно. Децентрализованные блокчейны — нет, именно поэтому Google сфокусировалась на криптовалютах как на самых хрупких системах.

Банки не ломаются из-за обратного проектирования одного ключа. Блокчейны — ломаются. Они гораздо более хрупкие.

Постквантовая криптография — что уже можно сделать

Стандарты постквантовой криптографии (PQC) уже утверждены NIST:

• ML-KEM (бывший CRYSTALS-Kyber) — для обмена ключами
• ML-DSA (бывший CRYSTALS-Dilithium) — для цифровых подписей
• SLH-DSA (бывший SPHINCS+) — для stateless-подписей

Google уже внедрила PQC в Chrome, Gmail и Cloud. Для разработчиков на практике:

• Go 1.24+ — пакет crypto/mlkem уже в стандартной библиотеке
• OpenSSL 3.5 — поддержка ML-KEM и ML-DSA
• liboqs от Open Quantum Safe — библиотека постквантовых алгоритмов для C/C++/Python
• Cloudflare — уже поддерживает PQC в TLS-соединениях

Реакция индустрии: Ethereum готов, Bitcoin — нет

Ethereum Foundation запустила pq.ethereum.org — портал постквантовой миграции с восемью годами исследований, 10+ клиентскими командами и дорожной картой на несколько хардфорков.

Bitcoin пока отстаёт. BIP 360 — предложение по квантово-устойчивым кошелькам — находится на ранней стадии. Проблема в том, что децентрализованное сообщество не может быстро согласовать обновление протокола.

Сказать, что квантовые компьютеры приближаются — это не FUD. FUD — утверждать, что Bitcoin не может адаптироваться. Он может. Просто нужно начать работать над решениями уже сегодня.

Хасиб Куреши из Dragonfly обратил внимание на необычную деталь: Google не опубликовала квантовые контуры. «Это очень нетипично — показывает, что Google считает угрозу серьёзной.» По его оценке, квантовые компьютеры нужной мощности могут появиться к концу десятилетия, а не к середине 2030-х.

Выводы

Статья Google не означает, что Bitcoin можно взломать прямо сейчас. Но она резко сдвигает временные рамки: с «когда-нибудь после 2035» на «возможно, к концу этого десятилетия». Для разработчиков это означает одно — проектировать с учётом постквантовой криптографии нужно уже сегодня.

Мы больше не смотрим на середину 2030-х. Квантовые компьютеры такого масштаба могут появиться к концу десятилетия. Всем блокчейнам нужен план миграции немедленно. Постквантовая эра — это больше не учебная тревога.

Источники: Google Research | CoinDesk | Bloomberg | Ethereum PQC

Команда безопасности Calif опубликовала разбор того, как Claude (Anthropic) за ~4 часа написал два рабочих эксплоита для CVE-2026-4747 — уязвимости переполнения стека в модуле ядра FreeBSD. Оба эксплоита сработали с первой попытки и дали полный root-доступ к удалённой машине.

Саму уязвимость тоже обнаружил ИИ: в официальном бюллетене FreeBSD указан «Nicholas Carlini using Claude, Anthropic». При этом человек направлял процесс через 44 промпта, но большую часть технической работы — от анализа крэш-дампов до написания ROP-цепочек — Claude выполнял самостоятельно.

— Claude написал полный remote kernel RCE для FreeBSD (CVE-2026-4747) за ~4 часа при минимальном участии человека (44 промпта)

— Уязвимость — переполнение стека в kgssapi.ko (модуль Kerberos-аутентификации для NFS), оценка CVSS 8,8 (HIGH)

— ИИ самостоятельно решил 6 нетривиальных задач: от настройки тестовой среды до перехода из режима ядра в пользовательский

— Оба эксплоита сработали с первой попытки, результат — uid=0 (root)

— FreeBSD уже выпустил патч 26 марта 2026 года (FreeBSD-SA-26:08)

Уязвимость CVE-2026-4747 в ядре FreeBSD

CVE-2026-4747 — переполнение стека (CWE-121) в модуле ядра kgssapi.ko (реализует RPCSEC_GSS — механизм аутентификации NFS-клиентов через Kerberos). Функция gss_validate() копирует данные из входящего сетевого пакета в стековый буфер без проверки границ.

Переполнение буфера происходит до проверки учётных данных NFS-клиента — но для полноценной атаки нужен сетевой доступ к NFS-серверу. Это отражено в оценке CVSS 8,8 (HIGH) по данным NVD: вектор атаки сетевой, сложность низкая, требуются минимальные привилегии (PR:L).

Дополнительный фактор: конкретная функция в kgssapi.ko скомпилирована так, что стековые канарейки (stack canaries — специальные значения для детекции переполнения) не защищают целочисленный буфер в данном случае. Переполнение остаётся незамеченным. Затронуты все версии FreeBSD, патчи доступны для stable/15, stable/14 и stable/13.

Кто стоит за исследованием

Публикация — совместная работа Calif (калифорнийская компания по безопасности, основанная Thai Duong — соавтором атак BEAST и CRIME на TLS) и Nicholas Carlini из Anthropic (PhD UC Berkeley, лауреат best paper на IEEE S&P, USENIX Security и ICML). Уязвимость обнаружил Carlini с помощью Claude, а команда Calif разработала эксплоит тоже с помощью Claude.

Как Claude написал эксплоит: 6 задач за 4 часа

Команда Calif дала Claude доступ к оболочке, отладчику GDB, утилите ROPgadget (поиск «гаджетов» — коротких фрагментов кода в ядре, которые можно использовать для построения цепочки команд) и эмулятору QEMU. Задача: разработать рабочий эксплоит для CVE-2026-4747. За ~4 часа машинного времени Claude решил 6 нетривиальных задач.

1. Настройка тестовой среды

Claude развернул виртуальную машину FreeBSD с NFS, Kerberos и уязвимым модулем ядра. Модель учла, что VM нужно минимум 2 процессора — FreeBSD создаёт 8 NFS-потоков на каждый CPU.

2. Многопакетная доставка шеллкода

Шеллкод (432 байта) не помещается в один сетевой пакет. Claude разработал стратегию из 15 раундов:

1. Первый раунд: сделать область памяти ядра исполняемой через pmap_change_prot
2. 14 следующих раундов: записать шеллкод порциями по несколько десятков байт за пакет
3. Последний пакет запускает записанный шеллкод

3. Чистый выход из потока

Каждое переполнение захватывает один NFS-поток ядра. Claude использовал kthread_exit() для корректного завершения каждого захваченного потока — чтобы сервер оставался работоспособным для следующего раунда.

4. Отладка смещений стека

Начальные смещения из дизассемблера оказались неверными. Claude отправил De Bruijn-паттерны — специальные последовательности, в которых каждая подстрока уникальна, что позволяет по крэш-дампу точно определить, какой байт попал на адрес возврата. Классический приём пентестеров, который Claude применил без подсказки.

5. Переход из ядра в пользовательский режим

NFS-потоки работают в режиме ядра и не могут напрямую запускать пользовательские программы. Claude нашёл решение через цепочку вызовов ядра FreeBSD:

1. Создать новый процесс через kproc_create()
2. Заменить его на /bin/sh через kern_execve()
3. Сбросить внутренний флаг ядра, помечающий процесс как системный, чтобы он мог выполнять пользовательский код

6. Баг аппаратных точек останова

Дочерний процесс падал с debug exception. Claude отследил проблему: регистр DR7 (управляет аппаратными точками останова на x86) содержал устаревшие значения от отладчика DDB. Решение — очистить DR7 перед форком.

Второй эксплоит — альтернативная стратегия

Claude написал и второй эксплоит, использующий принципиально другой подход. Вместо запуска реверс-шелла (что требует многоэтапной доставки шеллкода и сложного перехода в пользовательский режим) — запись публичного SSH-ключа в .ssh/authorized_keys на сервере. Это проще: нужно записать всего ~400 байт текста в файл, без перехода из ядра в userland. Результат: 6 раундов вместо 15. Оба эксплоита дали полный root-доступ:

Почему это важно для индустрии

Компьютеры всегда умели находить баги. Фаззеры вроде AFL и syzkaller обнаруживают уязвимости в ядрах уже больше десяти лет. Но найти баг и написать эксплоит — совершенно разные вещи. Разработка эксплоитов требует понимания внутренностей ОС, создания ROP-цепочек, управления расположением памяти, отладки крэшей и адаптации, когда что-то идёт не так. Это долго считалось рубежом, который могут пересечь только люди.

Ключевое отличие от прошлых демонстраций ИИ в безопасности: Claude не просто сгенерировал код по шаблону. Модель адаптировалась к неожиданным проблемам в реальном времени — исправляла смещения стека через отладочные паттерны, находила баг с аппаратными регистрами, придумала нетривиальный переход из ядра в пользовательский режим. Каждая из этих задач раньше требовала многолетнего опыта в exploit development.

Для защитников это сигнал: окно между раскрытием уязвимости и появлением рабочего эксплоита сжимается с недель до часов. Недавний взлом Axios на npm показал, как быстро атакующие эксплуатируют цепочку поставок. Теперь ИИ может ускорить и разработку эксплоитов для ядер ОС.

Полный лог из 44 промптов и код обоих эксплоитов опубликованы в репозитории califio/publications на GitHub.

MAD Bugs — что дальше

Calif объявил проект MAD Bugs: Month of AI-Discovered Bugs — до конца апреля 2026 года команда планирует опубликовать ещё несколько уязвимостей и эксплоитов, обнаруженных с помощью ИИ. Все находки проходят через ответственное раскрытие — CVE-2026-4747 был запатчен за 5 дней до публикации эксплоита.

Что делать администраторам FreeBSD

Если вы администрируете FreeBSD-серверы с NFS — обновитесь до последних патчей. Проверить, загружен ли уязвимый модуль:

Если модуль не используется — можно выгрузить его до обновления:

Подробности — в бюллетене FreeBSD-SA-26:08.

Если вы работаете с безопасностью — следите за проектом MAD Bugs: граница между возможностями ИИ и задачами для людей продолжает сдвигаться.

curl — одна из самых распространённых программных библиотек в мире. В форме libcurl она работает на десятках миллиардов устройств. При таком масштабе любая компрометация может иметь катастрофические последствия.

— Каждый коммит и каждый релиз open-source проекта — потенциальная точка атаки: от внедрённого контрибьютора до взломанного CI

— curl применяет более 20 мер верификации: от запрета бинарных блобов и Unicode в коде до обязательного фаззинга и torture-тестов

— Внешние пользователи могут и должны верифицировать релизы: проверять подписи, сравнивать содержимое архивов с git-репозиторием

— Это не паранойя — это инженерная дисциплина, которая позволяет проекту оставаться надёжным уже 30 лет

— Стенберг призывает требовать такого же уровня верификации от всех зависимостей в вашем стеке

Атаки на supply chain: 9 сценариев угроз

Supply-chain атака — это компрометация не вашего кода, а кода ваших зависимостей: библиотек, инструментов сборки, CI-систем. С каждым коммитом и каждым релизом софта возникают риски. Даниэль Стенберг перечисляет сценарии, жертвой которых может стать широко используемый проект:

• Внедрённый контрибьютор — как в случае с Jia Tan и xz-utils: внешне добросовестный участник команды, который намеренно маскирует вредоносный код под обычные коммиты
• Скомпрометированный мейнтейнер — авторизованный разработчик, чья учётная запись или машина взломаны. Его коммиты и релизы теперь содержат заражённый код
• «Полезный» баг-фикс от незнакомца — маленький шаг в длинной цепочке крошечных изменений, которые постепенно формируют уязвимость или бэкдор
• Шантаж или давление — существующего участника проекта принуждают вносить изменения, которые иначе были бы отклонены
• Непреднамеренная ошибка — добросовестный разработчик при добавлении фичи или исправлении бага случайно создаёт уязвимость
• Подмена на уровне дистрибуции — сайт, с которого раздаются тарболлы (архивы с исходным кодом для релиза), взломан; вместо оригинальных архивов раздаётся малварь
• Компрометация учётных данных — от имени известного участника проекта распространяется дезинформация через email, соцсети, блоги или даже дипфейк-видео
• Атака через CI-инфраструктуру — инструмент, используемый в CI и размещённый в облаке, взломан и исполняет вредоносный код
• Поддельное зеркало — пока основной git-репозиторий недоступен, кто-то предлагает «временное зеркало» с заражённым кодом

Любой из этих сценариев может произойти в комбинации с другими и в быстрой последовательности.

Верификация релизов: как пользователи могут проверить curl

Люди спрашивают Стенберга, как он спит по ночам, учитывая масштаб curl и количество возможных атак.

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

Если хотя бы несколько независимых пользователей проверят, что релиз curl подписан мейнтейнером, а содержимое совпадает с тем, что есть в git-репозитории, — проект в хорошем состоянии. Достаточно нескольких независимых наблюдателей, чтобы любая аномалия была замечена.

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

Безопасность curl изнутри: более 20 мер верификации

Внешние наблюдатели могут подтвердить, что релизы соответствуют тому, что есть в git. Но обеспечить, чтобы в git попадал только безопасный и корректный код, — это внутренняя работа команды. Вот полный список мер:

Стандарты кода и ограничения

• Единый стиль кода — нарушение стиля вызывает ошибку сборки. Это снижает риск случайных ошибок и упрощает ревью
• Запрет «опасных» C-функций — функции, которые легко использовать неправильно, запрещены. Их использование вызывает ошибку
• Лимит на сложность функций — если функция слишком сложна, это ошибка сборки. Код должен быть читаемым и понятным
• Запрет бинарных блобов в git — никаких способов спрятать зашифрованный вредоносный код. Попытка добавить блоб вызывает ошибку
• Избегание base64-кодированных фрагментов — ещё один способ обфускации, который curl активно исключает
• Ограничение Unicode в коде и документации — большинство использований Unicode запрещено, чтобы предотвратить homoglyph-атаки (подмену символов визуально похожими из другой кодировки, например кириллической «а» вместо латинской «a»)
• Документирование всего — код, API, поведение — всё задокументировано, чтобы не было сюрпризов. Документация тестируется, проверяется спеллчекером и проходит ревью наравне с кодом

Тестирование и непрерывная интеграция

• Обязательное ревью каждого PR — и людьми, и ботами. Коммиты ссылаются на исходный PR
• Тысячи тестов — для каждой функции. Поиск «белых пятен» в покрытии — приоритетная задача
• Более 200 CI-джобов — запускаются для каждого коммита и каждого PR. Без объяснённых провалов тестов мёрж невозможен
• Максимально строгие опции компилятора — все предупреждения трактуются как ошибки через -Werror. Ни одно предупреждение не остаётся без внимания
• Valgrind и санитайзеры — все тесты прогоняются через valgrind и несколько комбинаций санитайзеров для обнаружения проблем с памятью и неопределённого поведения (undefined behavior)
• Torture-тесты — каждый тест перезапускается так, чтобы каждый вызов функции, способной завершиться ошибкой, упал ровно один раз. Это гарантирует: curl не утекает памятью и не падает при любых сбоях
• Непрерывный фаззинг — автоматическое тестирование случайными входными данными для поиска крашей и уязвимостей. Работает без остановки в рамках Google OSS-Fuzz и кратко в CI для каждого коммита

Защита CI-инфраструктуры от компрометации

• CI-джобы не пишут обратно в репозиторий — доступ только на чтение. Даже при компрометации CI код не может быть заражён
• Анализ конфигов CI — инструменты вроде zizmor проверяют скрипты CI на уязвимости
• Обязательная двухфакторная аутентификация — для всех коммиттеров на GitHub

Политика безопасности и стабильность API

• Уязвимости исправляются в следующем релизе — без исключений. Проблемы безопасности не висят после того, как о них сообщили
• Полная документация всех уязвимостей — каждая когда-либо найденная уязвимость curl задокументирована со всеми деталями
• Стабильность ABI и API — curl никогда не ломает обратную совместимость (ABI — бинарный интерфейс приложения, API — программный интерфейс). Это позволяет пользователям легко обновляться до версий с исправленными уязвимостями вместо того, чтобы сидеть на устаревших
• Независимые аудиты — код curl неоднократно проверяли внешние эксперты по безопасности. Все найденные проблемы были немедленно устранены

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

Не паранойя, а инженерная дисциплина

Стенберг планирует на случай, когда кто-то действительно захочет и попытается навредить проекту и его пользователям. Или когда это произойдёт случайно. Успешная атака на curl теоретически может достичь миллиардов устройств.

Это не паранойя. Эта система позволяет нам спокойно спать по ночам. Именно поэтому пользователи до сих пор полагаются на curl спустя тридцать лет разработки.

Недавно Стенберг добавил на сайт curl отдельную страницу верификации, где подробно описано, как проверить целостность релизов.

Безопасность зависимостей: что проверить в вашем проекте

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

Проверка подписей и целостности пакетов

Большинство пакетных менеджеров умеют проверять подписи. Убедитесь, что эта проверка включена:

Аудит зависимостей в CI

Встройте проверку уязвимостей в ваш CI-пайплайн:

Базы уязвимостей OSV и NVD — основные источники данных для этих инструментов.

Оценка практик ваших зависимостей

Прежде чем добавить зависимость, проверьте:

• Есть ли у проекта обязательное ревью PR? Посмотрите историю мёржей
• Есть ли CI с тестами? Проверьте бейджи в README и конфиги в .github/workflows/
• Как быстро закрываются уязвимости? Проверьте security advisories на GitHub
• Сколько активных мейнтейнеров? Один человек — точка отказа
• Используется ли OpenSSF Scorecard — автоматическая оценка безопасности open-source проекта

Выводы: доверяйте коду, а не репутации

Опыт curl показывает: безопасность open source — это не вопрос доверия, а вопрос верификации. За 30 лет разработки проект выстроил систему из более чем 20 конкретных мер — от запрета бинарных блобов до непрерывного фаззинга — которые вместе создают многоуровневую защиту.

Если проект с десятками миллиардов установок может работать полностью открыто и предоставлять инструменты верификации для каждого, то и другие проекты обязаны стремиться к тому же стандарту. Начните с малого: npm audit signatures, pip-audit, проверка security advisories ваших зависимостей.

Не доверяйте — проверяйте.

Источник: Don't trust, verify — блог Даниэля Стенберга

Скомпрометированы версии axios@1.14.1 и axios@0.30.4 — обе ветки, актуальная и легаси. Вредоносный код устанавливает кроссплатформенный RAT, который работает на macOS, Windows и Linux. Пакеты были доступны в npm-реестре около 3 часов, прежде чем npm их удалил.

— Скомпрометированы axios@1.14.1 и axios@0.30.4 через взлом npm-аккаунта мейнтейнера

— Вредоносная зависимость plain-crypto-js устанавливает RAT-троянец на все ОС

— axios — самый популярный HTTP-клиент в JS-экосистеме: более 100 млн загрузок в неделю

— Безопасные версии: 1.14.0 (для 1.x) и 0.30.3 (для 0.x)

— Все секреты на затронутых системах нужно ротировать немедленно

Axios — HTTP-клиент для Node.js и браузеров с более чем 100 миллионами загрузок в неделю. Атаки на цепочки поставок (supply chain attacks) — это компрометация инфраструктуры распространения ПО: вместо атаки на конечную цель злоумышленник внедряет вредоносный код в доверенный пакет, который жертва сама устанавливает.

Как произошла атака

Злоумышленники получили доступ к npm-аккаунту jasonsaayman — основного мейнтейнера axios. Email аккаунта был изменён с легитимного адреса на ifstap@proton.me. Предположительно, был украден долгоживущий классический npm access token.

Легитимные релизы axios публикуются через GitHub Actions с криптографической привязкой npm OIDC Trusted Publisher и содержат SLSA-провенанс (Supply chain Levels for Software Artifacts — стандарт подтверждения целостности сборки). Вредоносные версии были опубликованы вручную через npm CLI — без привязки к GitHub, без SLSA-провенанса, без соответствующего тега в репозитории.

Атака была подготовлена заранее: за 18 часов до компрометации axios в npm был опубликован пакет-приманка plain-crypto-js — клон легитимного crypto-js с тем же описанием и именем автора. Сначала чистая версия 4.2.0, затем вредоносная 4.2.1 с постустановочным скриптом.

Хронология атаки

Все события — по UTC, 30–31 марта 2026 года:

• 30 марта, 05:57 — атакующий публикует чистый plain-crypto-js@4.2.0 для формирования истории публикаций
• 30 марта, 23:59 — выходит вредоносный plain-crypto-js@4.2.1 с постустановочным скриптом
• 31 марта, 00:05 — Socket детектирует вредоносный пакет — через 6 минут после публикации
• 31 марта, 00:21 — публикуется axios@1.14.1 со скомпрометированного аккаунта
• 31 марта, 01:00 — публикуется axios@0.30.4 — обе ветки поражены за 39 минут
• 31 марта, ~03:15 — npm удаляет обе вредоносные версии, dist-tag latest откатывается к 1.14.0
• 31 марта, 04:26 — npm публикует заглушку безопасности для plain-crypto-js — пакет заблокирован

Итого: axios@1.14.1 был доступен около 2 часов 53 минут, axios@0.30.4 — около 2 часов 15 минут.

Что делает вредоносный код

В исходном коде axios изменений нет — добавлена только зависимость plain-crypto-js@^4.2.1. Сам пакет никогда не импортируется в коде; он существует исключительно для запуска postinstall-хука при npm install.

Дроппер setup.js

Файл setup.js весит 4209 байт и использует двухслойную обфускацию: сначала reversed Base64-декодирование (с подстановкой символов), затем XOR-шифр с ключом OrDeR_7077. Дроппер определяет ОС и загружает платформенный payload с C2-сервера.

Payload по платформам

macOS: AppleScript-дроппер скачивает бинарный RAT с C2-сервера и сохраняет его как /Library/Caches/com.apple.act.mond — замаскирован под системный демон Apple. Запускается через /bin/zsh.

Windows: PowerShell копируется в %PROGRAMDATA%\wt.exe (маскировка под Windows Terminal). VBScript-дроппер запускает скрытый PowerShell-скрипт с обходом Execution Policy.

Linux: Python-скрипт RAT скачивается в /tmp/ld.py и запускается через nohup в фоновом режиме.

Возможности RAT

При первом запуске RAT отправляет на C2-сервер «отпечаток» системы: hostname, имя пользователя, версию ОС, архитектуру CPU, часовой пояс, время установки ОС и загрузки, список процессов, а также содержимое директорий /Applications, ~/Library и ~/Application Support. Затем RAT опрашивает C2 каждые 60 секунд. Поддерживаемые команды:

• runscript — выполнение произвольных shell-команд и Python-кода
• peinject — загрузка и запуск дополнительных бинарных payload
• rundir — перечисление содержимого директорий
• kill — самоуничтожение процесса

Антифорензика

После выполнения дроппер удаляет себя (setup.js) и подменяет package.json чистой версией без postinstall-секции. При инспекции node_modules после заражения следов вредоносного скрипта не остаётся.

Это означает, что проверка node_modules постфактум бесполезна. Единственный надёжный способ определить компрометацию — проверить package-lock.json на наличие вредоносных версий и IoC-пути на файловой системе (см. ниже).

Кто обнаружил

Атаку независимо обнаружили несколько компаний: Socket задетектировал вредоносный plain-crypto-js через 6 минут после публикации. StepSecurity подтвердил компрометацию через AI Package Analyst и инструментирование GitHub Actions-раннера. Детальный технический разбор также опубликовала SafeDep.

Индикаторы компрометации (IoC)

Файловая система:

Сеть:

SHA256 хеши:

Что делать прямо сейчас

Быстрая проверка — есть ли вредоносные версии в вашем lockfile:

Если команда ничего не вернула — ваш проект не затронут. Если нашлись совпадения:

1. Откатить axios: npm install axios@1.14.0 (для 1.x) или npm install axios@0.30.3 (для 0.x) — это автоматически удалит plain-crypto-js
2. Проверить IoC-пути на файловой системе для вашей ОС (см. выше)
3. Заблокировать C2 на сетевом уровне: sfrclak[.]com / 142.11.206.73
4. Ротировать все секреты на затронутых системах: npm-токены, SSH-ключи, API-ключи, переменные из .env
5. Проверить CI/CD-логи за 30–31 марта — ротировать все secrets из затронутых пайплайнов
6. Перейти на npm ci --ignore-scripts в CI/CD как постоянную политику

Если обнаружены артефакты RAT — считайте систему полностью скомпрометированной и пересоберите из заведомо чистого состояния.

Защита от транзитивных зависимостей

Если axios используется как транзитивная зависимость (его тянет другой пакет), прямой npm install axios@1.14.0 не поможет — нужно зафиксировать версию через overrides в package.json:

Поле overrides работает в npm 8+, resolutions — в Yarn.

Выводы

Инцидент с axios — один из самых масштабных supply chain атак в npm по потенциальному охвату: при 100 миллионах загрузок в неделю даже 3-часовое окно доступности вредоносных версий критично. Для сравнения: компрометация event-stream в 2018 году затронула пакет с 2 миллионами загрузок в неделю.

Скорость реакции экосистемы впечатляет: Socket обнаружил вредоносный plain-crypto-js через 6 минут, npm отозвал пакеты менее чем за 3 часа. Но сам факт, что атакующему хватило одного украденного токена для публикации от имени доверенного мейнтейнера, ставит вопрос о необходимости обязательного использования OIDC Trusted Publishing для критической инфраструктуры npm.

Проверьте свои зависимости, ротируйте секреты и убедитесь, что ваш CI/CD-пайплайн защищён от автоматической установки непроверенных версий.

Атака затрагивает пользователей множества репозиториев на GitHub — уведомления о «критических уязвимостях» приходят прямо на почту всем подписчикам и участникам проектов.

- Тысячи фейковых security-алертов публикуются в GitHub Discussions по множеству репозиториев - Злоумышленники выдают себя за мейнтейнеров и используют поддельные CVE ID - Ссылки ведут на вредоносные расширения VS Code, размещённые на Google Drive - За фасадом — Traffic Distribution System с JS-разведкой и фильтрацией исследователей - GitHub Discussions автоматически рассылает email-уведомления всем подписчикам репозиториев

Как работает атака

Кампания построена на злоупотреблении функцией GitHub Discussions — раздела для обсуждений внутри репозиториев. Атакующие создают новые аккаунты или используют малоактивные учётные записи и за считаные минуты публикуют тысячи постов с одинаковым шаблоном.

Каждый пост оформлен как срочное предупреждение о безопасности с заголовком вида Severe Vulnerability — Immediate Update Required. В тексте указаны поддельные CVE-идентификаторы (CVE — Common Vulnerabilities and Exposures, стандартная система нумерации известных уязвимостей) и ссылка на «пропатченную» версию расширения. Злоумышленники тщательно имитируют стиль настоящих security advisories и подписываются именами реальных мейнтейнеров или исследователей безопасности.

Ключевой рычаг атаки — механизм уведомлений GitHub. Все пользователи, которые подписаны на репозиторий (watchers) или участвовали в обсуждениях (participants), автоматически получают email с содержимым фейкового алерта. Таким образом, одна публикация в Discussions может охватить сотни и тысячи разработчиков.

Цепочка заражения

Ссылка из фейкового алерта ведёт на Google Drive, где размещён файл, замаскированный под обновлённое расширение VS Code. Далее запускается многоступенчатая цепочка:

1. Жертва переходит по ссылке на Google Drive и скачивает файл
2. Файл инициирует цепочку cookie-driven редиректов, которая приводит на домен drnatashachinn[.]com
3. На этом домене выполняется JavaScript-скрипт разведки — он собирает данные о системе: часовой пояс, локаль, user agent, операционную систему и индикаторы автоматизации
4. Собранные данные отправляются на C2-сервер (Command and Control — управляющий сервер атакующих) через POST-запрос
5. Сервер работает как Traffic Distribution System (TDS) — фильтрует ботов и ИБ-исследователей, пропуская к следующему этапу только реальных пользователей

Исследователям из Socket не удалось перехватить финальную полезную нагрузку (payload — вредоносный код второго этапа) — TDS-система определяла их как аналитиков и блокировала доставку. Важно: сам JS-скрипт разведки не крадёт пароли и не перехватывает учётные данные — он только собирает информацию о системе для фильтрации. Что именно получают прошедшие фильтрацию жертвы — пока неизвестно.

Как распознать фейковый алерт

Разработчикам стоит проявлять бдительность при получении уведомлений о безопасности из GitHub Discussions. Вот чеклист для проверки:

1. Проверьте автора поста — кликните на профиль. Новый аккаунт без активности или с минимальной историей — красный флаг
2. Настоящие security advisories публикуются во вкладке Security репозитория, а не в Discussions
3. Проверьте CVE ID через официальную базу cve.mitre.org или nvd.nist.gov — фейковые идентификаторы там не найдутся
4. Не скачивайте расширения VS Code из Google Drive или любых внешних источников — используйте только официальный VS Code Marketplace
5. Обращайте внимание на язык поста: паникёрские формулировки вроде «Immediate Update Required» нехарактерны для реальных мейнтейнеров
6. Если получили email-уведомление — перейдите в репозиторий и проверьте обсуждение в контексте, а не переходите по ссылкам из письма

Прецеденты: атаки через GitHub в 2024–2025

Это не первый случай использования инфраструктуры GitHub для распространения вредоносного ПО:

• Март 2025 — масштабная кампания затронула более 12 000 репозиториев. Злоумышленники публиковали фейковые security alerts и через них направляли разработчиков на авторизацию вредоносного OAuth-приложения, получая доступ к их аккаунтам
• Июнь 2024 — атакующие использовали спам-комментарии и pull requests для запуска email-уведомлений GitHub, перенаправляя разработчиков на фишинговые страницы

Общий тренд очевиден: злоумышленники всё активнее эксплуатируют доверие разработчиков к платформе GitHub и её встроенные механизмы уведомлений для доставки вредоносного контента.

Как защититься прямо сейчас

Вот конкретные шаги, которые стоит предпринять уже сегодня:

1. Отключите email-уведомления для Discussions: Settings → Notifications → Watching → Custom → снимите галочку с Discussions
2. Включите двухфакторную аутентификацию на GitHub: Settings → Password and authentication → Enable two-factor authentication
3. Проверьте список установленных расширений VS Code: откройте Extensions (Ctrl+Shift+X) → убедитесь, что все расширения установлены из официального VS Code Marketplace
4. Не переходите по ссылкам из email-уведомлений GitHub — открывайте репозиторий напрямую в браузере
5. Сообщайте о подозрительных постах через кнопку Report в GitHub Discussions — это помогает платформе быстрее блокировать вредоносный контент

Выводы

Атака через GitHub Discussions показывает, что даже доверенные платформы могут стать каналом доставки вредоносного ПО. Злоумышленники комбинируют социальную инженерию (срочность, имитация авторитетных фигур), легитимную инфраструктуру (Google Drive, email-уведомления GitHub) и техническую изощрённость (TDS-фильтрация, JS-разведка). Подробности — в отчёте BleepingComputer.

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

Приложение White House (gov.whitehouse.app, версия 47.0.1) — официальный Android-клиент Белого дома, доступный в Google Play. Под капотом — React Native на Expo SDK 54 с движком Hermes. Бэкенд — WordPress, который отдаёт контент через REST API на whitehouse.gov.

— Приложение содержит JavaScript-инжектор, который скрывает cookie-баннеры, GDPR-диалоги, пейволлы и логин-стены на любых сайтах, открытых через встроенный браузер

— В коде заложена инфраструктура GPS-трекинга через OneSignal: опрос координат каждые 4,5 минуты при активном использовании и каждые 9,5 минут в фоне

— YouTube-плеер загружает HTML-страницу с GitHub Pages мейнтейнера сторонней библиотеки — компрометация аккаунта позволит выполнить произвольный код

— В продакшен-сборке остались артефакты разработки: URL localhost, IP разработчика и экспортированная Activity

Что из себя представляет приложение

Приложение Белого дома — по сути, обёртка над WordPress. Весь контент загружается через REST API с эндпоинтами вида /wp-json/whitehouse/v1/*. Вот основные разделы:

• /home — главный экран
• /news/articles — новости
• /wire — лента «The Wire»
• /live — прямые трансляции
• /galleries — фотогалереи
• /issues и /priorities — политические приоритеты
• /achievements — «достижения»
• /media-bias — раздел «предвзятость СМИ»
• /social/x — прокси ленты X/Twitter

Среди контента — разделы «THE TRUMP EFFECT», «Greatest President Ever!», «Text President Trump» (с номером 45470) и ссылки на TrumpRx.gov, TrumpAccounts.gov, а также форма доноса ICE. Конфиг Expo указывает владельца forty-five-press — судя по всему, это медиа-команда, а не государственное агентство.

Инжектор обхода cookie-баннеров и пейволлов

Самая неожиданная находка — JavaScript-код, который инжектируется в каждый сайт, открытый через встроенный WebView приложения. Пейволл (paywall) — это платная стена, блокирующая доступ к контенту для неподписчиков. Скрипт использует механизм injectedJavaScript в React Native WebView.

Что именно скрывает инжектор:

• Cookie-баннеры (по CSS-селекторам *cookie*, *Cookie*)
• GDPR-диалоги согласия (*consent*, *gdpr*, *GDPR*)
• Баннеры OneTrust (*onetrust*)
• Баннеры приватности (*privacy-banner*)
• Логин-стены (*login-wall*, *loginWall*)
• Стены регистрации (*signup-wall*, *signupWall*)
• Апсейл-блоки (*upsell*, *Upsell*)
• CMP-боксы (.cmpboxBtnYes, .cmpbox)
• Любые элементы с aria-label, содержащим «cookie» или «consent»

Скрипт работает в два этапа. Сначала создаёт CSS-правило display: none !important для всех элементов, соответствующих селекторам. Затем устанавливает MutationObserver, который отслеживает любые изменения DOM и скрывает новые элементы с соответствующими классами. Дополнительно принудительно снимает блокировку прокрутки: body { overflow: auto !important }.

По сути, приложение Белого дома обходит GDPR-требования и пейволлы на сторонних сайтах. Для государственного приложения это, мягко говоря, неожиданно.

Инфраструктура GPS-трекинга

В конфиге Expo есть плагин withNoLocation, который, казалось бы, отключает геолокацию. Однако в скомпилированном коде присутствует полноценная инфраструктура трекинга через OneSignal SDK.

Константы опроса координат

В классе LocationConstants жёстко заданы интервалы опроса:

• FOREGROUND_UPDATE_TIME_MS = 270000 — 4,5 минуты при активном использовании
• BACKGROUND_UPDATE_TIME_MS = 570000 — 9,5 минут в фоне
• TIME_FOREGROUND_SEC = 300 — 5-минутный порог для переднего плана
• TIME_BACKGROUND_SEC = 600 — 10-минутный порог для фона

Как работает трекинг

Класс GmsLocationController использует Google Fused Location API. При каждом опросе запрашивает координаты с приоритетом PRIORITY_BALANCED_POWER_ACCURACY (код 102) и устанавливает maxWaitTime в полтора раза больше интервала.

Перехваченные координаты обрабатывает LocationCapturer: широта, долгота, точность, временная метка, флаг фоновой работы и тип (грубый/точный). Всё сохраняется в PropertiesModel и отправляется на серверы OneSignal (api.onesignal.com).

Есть и фоновый сервис LocationBackgroundService, который продолжает собирать координаты даже когда приложение свёрнуто.

Защита — есть, но условная

Формально GPS-трекинг защищён гейтом: флаг _isShared по умолчанию false. Трекинг активируется только после вызова setLocationShared(true). Плагин withNoLocation по идее не должен его включать. Но вся инфраструктура скомпилирована в приложение. Поскольку трекинг реализован в нативном коде (Java), простое OTA-обновление JavaScript-бандла его не активирует. Однако если в приложении есть bridge-вызов к setLocationShared из JS — достаточно серверного конфига для включения без обновления через Google Play.

Риски цепочки поставок

JavaScript с чужого GitHub Pages

Для YouTube-плеера используется библиотека react-native-youtube-iframe, которая загружает HTML-страницу с GitHub Pages пользователя lonelycpp — мейнтейнера этой библиотеки:

Если аккаунт lonelycpp на GitHub будет скомпрометирован, злоумышленник сможет подменить эту страницу и выполнить произвольный JavaScript в WebView приложения Белого дома. Это классическая supply-chain атака (атака через цепочку поставок — компрометация стороннего компонента для проникновения в целевую систему). Хостинг ресурсов на GitHub Pages вместо CDN с Subresource Integrity — плохая практика для любого приложения, тем более государственного.

Виджеты Elfsight

Приложение загружает JavaScript-платформу Elfsight с CDN:

Elfsight — это виджет-платформа для социальных сетей. Никакой песочницы — скрипт исполняется в том же контексте, что и основное приложение.

Сторонние сервисы вместо госинфраструктуры

Ни один из сторонних сервисов не является государственной инфраструктурой:

• Mailchimp (whitehouse.us10.list-manage.com) — обработка email-подписок. Адреса пользователей уходят на серверы Mailchimp
• Uploadcare (ucarecdn.com) — хостинг контентных изображений через 6 захардкоженных UUID
• Truth Social — захардкоженный embed с профилем Трампа, аватаркой со static-assets-1.truthsocial.com и кнопкой «Follow»
• Facebook — плагин страницы через iframe facebook.com/plugins/page.php

Профилирование пользователей через OneSignal

OneSignal SDK в приложении — это не просто пуш-уведомления. Платформа предоставляет широкие возможности для профилирования пользователей:

• addTag — тегирование пользователей для сегментации
• addSms — привязка номеров телефонов к профилям
• addAliases — кросс-девайсная идентификация пользователей
• addOutcomeWithValue / addUniqueOutcome — отслеживание действий и конверсий
• Полный цикл in-app сообщений: WillDisplay, DidDisplay, WillDismiss, DidDismiss, inAppMessageClicked
• Отслеживание изменений состояния: подписки, разрешения, пользовательский профиль

Локальная SQLite-база хранит таблицы notification (с полями notification_id, opened, dismissed, title, message, full_data) и in_app_message (с отслеживанием показов и кликов).

Артефакты разработки в продакшен-сборке

В релизной версии приложения остались следы, которых там быть не должно:

• URL http://localhost:8081/wp-json/whitehouse/v1/galleries?page= — захардкоженный адрес локального дев-сервера
• IP-адрес разработчика 10.4.4.109 — прописан в strings.xml как react_native_dev_server_ip
• Пакеты expo-dev-client, expo-devlauncher, expo-devmenu — средства разработки Expo
• Иконка дев-меню dev_menu_fab_icon.png
• Экспортированная PreviewActivity из Compose UI Tooling — доступна другим приложениям через android:exported="true"

Экспортированная Activity — это потенциальный вектор атаки. Любое приложение на устройстве может запустить PreviewActivity через Intent.

Отсутствие certificate pinning

Certificate pinning (закрепление сертификата) — это метод защиты от атак «человек посередине» (MITM), при котором приложение принимает только заранее известные сертификаты сервера. Приложение Белого дома использует стандартный Android Trust Manager без закрепления сертификатов. Это означает, что при использовании скомпрометированного Wi-Fi или корпоративного прокси трафик между приложением и серверами whitehouse.gov может быть перехвачен и прочитан.

Разрешения и файловый доступ

Манифест запрашивает следующие разрешения:

• INTERNET — доступ к сети
• VIBRATE — вибрация
• ACCESS_NETWORK_STATE — состояние сети
• POST_NOTIFICATIONS — отправка уведомлений
• WAKE_LOCK — предотвращение засыпания
• RECEIVE_BOOT_COMPLETED — автозапуск при загрузке
• C2DM.RECEIVE — облачные пуш-уведомления
• CHECK_LICENSE — проверка лицензии Google Play

Конфигурация FileProvider описывает путь external-path name="shared" path="." — приложение может предоставлять любые файлы из внешнего хранилища другим приложениям через FileProvider. Это не означает чтение чужих данных, но расширяет поверхность атаки при взаимодействии между приложениями.

Полный стек зависимостей

Список SDK внутри приложения впечатляет:

• Фреймворк: React Native, Expo SDK 54, Hermes JS engine
• Пуш/вовлечение: OneSignal, Firebase Cloud Messaging, Firebase Installations
• Аналитика: Firebase Analytics, Google Data Transport, OpenTelemetry
• Сеть: OkHttp 3, Apollo GraphQL, Okio
• Изображения: Fresco, Glide, Coil 3, Uploadcare CDN
• Видео: ExoPlayer (Media3), Expo Video
• ML: Google ML Kit Vision (сканирование штрих-кодов), модель Barhopper
• Криптография: Bouncy Castle
• Хранилище: Expo Secure Store, React Native Async Storage
• WebView: React Native WebView (с инжектором)
• DI: Koin
• Сериализация: GSON, Wire (Protocol Buffers)
• Лицензия: PairIP license check (Google Play Verification)

Что делать пользователям

1. Не открывать ссылки через встроенный браузер приложения — копировать URL и открывать в Chrome/Firefox, где cookie-баннеры отображаются корректно
2. Проверить разрешения приложения в настройках Android: Настройки → Приложения → White House → Разрешения — убедиться, что геолокация отключена
3. Учитывать, что RECEIVE_BOOT_COMPLETED запускает сервисы приложения при каждой загрузке устройства — даже если вы не открывали приложение
4. Для параноиков: использовать отдельный рабочий профиль Android (Настройки → Система → Несколько пользователей) для изоляции

Чеклист для разработчиков: что не должно попадать в прод

Этот случай — хороший повод проверить собственные приложения. Вот что стоит убрать перед релизом:

1. URL localhost и IP-адреса разработчиков — искать в strings.xml, конфигах и коде
2. Дев-пакеты (expo-dev-client, devmenu) — исключать из релизных сборок через build flavors
3. Экспортированные Activity для отладки — убирать android:exported="true" у дев-компонентов
4. Внешние JS-зависимости без SRI — хостить критичные ресурсы на собственном CDN
5. Избыточные SDK-модули — если не используете геолокацию, исключить модуль из сборки, а не просто «отключить» флагом
6. Широкие пути в FileProvider — ограничивать до конкретных директорий вместо path="."
7. Certificate pinning — добавить для всех критичных эндпоинтов через network_security_config.xml

Выводы

Приложение Белого дома — это React Native обёртка над WordPress с инжектором обхода cookie и пейволлов, инфраструктурой GPS-трекинга через OneSignal и JavaScript-зависимостями с GitHub Pages стороннего разработчика. Без certificate pinning.

Этот разбор показывает, что даже государственные приложения могут содержать сомнительные практики: от обхода GDPR-баннеров до supply-chain зависимостей от случайных разработчиков. Полная инфраструктура GPS-трекинга, встроенная в код, но формально «отключённая» — это бомба замедленного действия, которая может быть активирована без обновления приложения.

Оригинальный анализ доступен в блоге thereallo.dev.

А вы проверяли, какие разрешения у государственных приложений на вашем телефоне?

Именно это произошло на неделе 24–28 марта 2026 года. Три популярных пакета на PyPI — LiteLLM, telnyx и Trivy — оказались скомпрометированы одной и той же группировкой. Разбираемся, как это работает, чем грозит и как защититься.

Supply chain атака (атака на цепочку поставок) — это тип кибератаки, при котором злоумышленник внедряет вредоносный код не напрямую в вашу систему, а через доверенную зависимость: библиотеку, инструмент или сервис, который вы уже используете. Вместо того чтобы взламывать ваш сервер, атакующий компрометирует то, что вы сами устанавливаете. Это особенно опасно, потому что такие пакеты проходят через все ваши проверки — они же «легитимные».

Ключевые выводы

— За одну неделю скомпрометированы три крупных пакета: litellm (версии 1.82.7 и 1.82.8), telnyx (версии 4.87.1 и 4.87.2) и Trivy (сканер уязвимостей от Aqua Security).
— Все атаки связаны с группировкой TeamPCP: совпадают RSA-ключ шифрования, схема эксфильтрации и имя архива tpcp.tar.gz.
— Вредоносный код крал SSH-ключи, токены облачных провайдеров (AWS, GCP, Azure), секреты Kubernetes, файлы криптокошельков и переменные окружения.
— LiteLLM — самый агрессивный вариант: латеральное перемещение по кластерам K8s и установка персистентного бэкдора через systemd.
— telnyx использовал стеганографию: вредоносный бинарник был спрятан внутри WAV-файла.
— Вектор первоначальной атаки — компрометация Trivy, через который были украдены PyPI-токены из CI/CD пайплайнов.

Хронология атак

Атаки развивались каскадно — каждая следующая была следствием предыдущей.

1. Март 2026, начало месяца — Trivy. Группировка TeamPCP скомпрометировала apt-репозиторий сканера уязвимостей Trivy от Aqua Security. Отравленный бинарник Trivy, установленный в CI/CD пайплайнах, начал красть секреты раннеров — в том числе токены для публикации на PyPI.
2. 24 марта 2026, 10:52 UTC — LiteLLM. На PyPI появляется версия litellm 1.82.8 с вредоносным .pth-файлом. Пакет крадёт учётные данные, перемещается по кластерам Kubernetes и устанавливает бэкдор. Чуть ранее вышла версия 1.82.7 с менее агрессивным вариантом — без .pth-файла, но с таким же пейлоадом в коде прокси-сервера.
3. 27 марта 2026 — telnyx. Публикуются версии telnyx 4.87.1 и 4.87.2. Вредоносный код внедрён в _client.py. Используется новая техника доставки — стеганография в WAV-файлах. Версия 4.87.1 содержит баг (опечатка в регистре Setup() вместо setup()), версия 4.87.2 исправляет его.

Ни одна из вредоносных версий не имела соответствующего тега или релиза в GitHub-репозитории. Пакеты были загружены напрямую на PyPI с помощью украденных токенов, минуя стандартный CI/CD-процесс.

LiteLLM — подробный разбор

LiteLLM — популярная Python-библиотека от BerriAI, которая предоставляет единый интерфейс к более чем 100 провайдерам LLM: OpenAI, Anthropic, Google, Azure и другим. Она широко используется в AI-стартапах, MCP-плагинах и продакшн-системах. Именно поэтому компрометация этого пакета особенно опасна — он часто оказывается в окружениях с доступом к критическим секретам.

Как работал вредоносный код

Атака использовала малоизвестную особенность Python — файлы .pth (path configuration files). Модуль site обрабатывает их при каждом запуске интерпретатора: строки, начинающиеся с import, передаются в exec(). Это значит, что вредоносный код выполнялся при любом запуске Python в окружении, где был установлен litellm — не только при импорте библиотеки.

Файл litellm_init.pth (34 628 байт) содержал одну строку:

Эта строка запускала фоновый процесс через Popen, который декодировал и выполнял трёхуровневый вредоносный пейлоад.

Три стадии атаки

Стадия 1 — оркестратор (25 844 байта). Содержал захардкоженный RSA-4096 публичный ключ и ещё один base64-закодированный блоб с логикой сбора данных. Управлял шифрованием и отправкой украденных данных.

Стадия 2 — коллектор (17 281 байт). Собирал:

• SSH-ключи всех типов (RSA, Ed25519, ECDSA, DSA) со всех пользователей системы
• Переменные окружения и .env-файлы
• Учётные данные AWS, GCP, Azure — включая активную эксплуатацию через AWS SigV4 для дампа Secrets Manager и SSM Parameter Store
• Конфигурации Kubernetes и секреты из всех namespace
• Файлы криптокошельков: Bitcoin, Ethereum, Solana, Litecoin, Dogecoin, Zcash и другие
• Историю shell, .gitconfig, пароли баз данных

Стадия 3 — персистентность (1 125 байт). Устанавливал бэкдор, замаскированный под «System Telemetry Service»:

Домен checkmarx.zone имитировал известную компанию Checkmarx, работающую в сфере безопасности приложений.

Латеральное перемещение по Kubernetes

Самая агрессивная часть атаки — распространение по кластерам Kubernetes. Если на скомпрометированной машине был доступен токен сервисного аккаунта K8s, вредонос создавал привилегированный pod на каждом узле кластера:

Поды именовались node-setup-* в пространстве имён kube-system, чтобы выглядеть легитимно. Каждый под монтировал корневую файловую систему хоста, получал доступ к PID и сети хоста и через chroot устанавливал персистентный бэкдор непосредственно на узел.

Шифрование и эксфильтрация

Украденные данные шифровались по гибридной схеме: случайный 32-байтный ключ AES-256-CBC для данных, затем сам ключ шифровался RSA-4096 (OAEP). Архив отправлялся POST-запросом на домен models.litellm.cloud — он был зарегистрирован 23 марта 2026 года, за день до публикации вредоносных пакетов, и не является частью легитимной инфраструктуры LiteLLM.

Побочный эффект — из-за того, что .pth-файл срабатывал при каждом запуске интерпретатора, дочерний процесс снова запускал тот же .pth, создавая экспоненциальную fork-бомбу. Именно так компрометацию и обнаружили: один из инженеров FutureSearch заметил, что машина упала после установки litellm как транзитивной зависимости MCP-плагина в Cursor.

telnyx — стеганография в WAV-файлах

telnyx — официальный Python SDK для телекоммуникационной платформы Telnyx, используемый для программной телефонии, SMS и работы с сетью. Пакет загружается более миллиона раз в месяц (~30 000 в день), что делает его компрометацию особенно масштабной.

Вектор атаки

Как и в случае с LiteLLM, GitHub-репозиторий telnyx не был скомпрометирован. Все недавние коммиты принадлежат stainless-app[bot] — боту платформы Stainless, которая генерирует SDK. Ни версия 4.87.1, ни 4.87.2 не имеют соответствующих тегов или релизов в GitHub.

Ключевое доказательство — отпечаток инструмента загрузки. Легитимный CI-пайплайн использует rye publish, а метаданные PyPI для вредоносных версий показывают twine/6.2.0 CPython/3.14.3. Злоумышленник загрузил пакеты вручную, используя украденный API-токен.

Репозиторий не использовал PyPI Trusted Publishers (OIDC), которые привязывают загрузку к конкретному репозиторию и workflow. Без этой защиты украденный токен позволяет загрузить любую версию с любой машины.

Стеганография в WAV-файлах

Главное нововведение этой атаки — доставка пейлоада через аудиофайлы. При импорте модуля telnyx вредоносный код скачивал WAV-файл с C2-сервера и извлекал из аудиоданных скрытый исполняемый файл:

Этот подход позволяет обойти сетевые инструменты инспекции трафика: WAV-файл выглядит как обычный аудиоконтент, а сам пейлоад закодирован в base64 и XOR-шифрован внутри аудиоданных.

Два вектора атаки

Вредоносный код содержал два независимых пути — для Windows и для Linux/macOS.

Windows — функция setup() скачивала WAV-файл hangup.wav, извлекала из него бинарник и сохраняла как msbuild.exe в папку автозагрузки Windows (директория Startup в %APPDATA%). Имя файла имитировало легитимный Microsoft Build Engine. Для предотвращения повторных загрузок использовался скрытый lock-файл с 12-часовым таймаутом.

Linux/macOS — функция FetchAudio() скачивала ringtone.wav, декодировала из base64-переменной _p скрипт сбора учётных данных и запускала его в фоновом процессе. Скрипт собирал те же категории данных, что и в атаке на LiteLLM, шифровал их AES-256-CBC + RSA-4096 и отправлял через HTTP POST.

Любопытная деталь: версия 4.87.1 содержала баг — вызов Setup() с заглавной буквой при определении def setup() со строчной. NameError прерывал выполнение модуля, и ни один из векторов атаки не работал. Версия 4.87.2 исправляла опечатку.

Trivy — когда сканер безопасности сам становится угрозой

Trivy — популярный open source сканер уязвимостей от Aqua Security, который проверяет контейнеры, файловые системы и Git-репозитории. Он широко используется в CI/CD пайплайнах для автоматического поиска уязвимостей перед деплоем.

Именно Trivy стал точкой входа для всей цепочки атак. TeamPCP скомпрометировала apt-репозиторий Trivy и подменила бинарник. Когда CI-раннеры устанавливали Trivy без фиксации версии, они получали отравленную сборку:

Отравленный Trivy с полными привилегиями CI-раннера собирал секреты окружения, включая PYPI_PUBLISH_PASSWORD. Эти украденные токены затем использовались для публикации вредоносных версий LiteLLM и telnyx напрямую на PyPI.

Мейнтейнер LiteLLM подтвердил связь с Trivy на Hacker News. Ирония ситуации в том, что инструмент, призванный защищать от уязвимостей, сам стал вектором атаки.

Кто за этим стоит — группа TeamPCP

Все три атаки атрибутированы одной группировке — TeamPCP. Атрибуция основана на трёх совпадающих индикаторах:

1. Идентичный RSA-4096 публичный ключ. Ключ шифрования в пейлоаде telnyx побайтово совпадает с ключом из litellm 1.82.8. Расшифровать данные может только владелец соответствующего приватного ключа.
2. Имя архива tpcp.tar.gz и HTTP-заголовок X-Filename: tpcp.tar.gz. Используются в обеих атаках при эксфильтрации. «TPCP» — сокращение от TeamPCP.
3. Идентичная схема шифрования. Одинаковая последовательность команд openssl: генерация случайного ключа, шифрование AES-256-CBC, шифрование ключа через RSA OAEP — одни и те же вызовы в обоих пейлоадах.

При этом атакующие активно развивают инструментарий: LiteLLM использовал скомпрометированный домен (models.litellm.cloud) для C2, telnyx — голый IP-адрес (83.142.209.203). Стеганография в WAV-файлах — новая техника, не встречавшаяся в атаке на LiteLLM.

Как защититься

Если вы используете любой из скомпрометированных пакетов — действуйте немедленно. Вот практический чеклист:

1. Проверьте версии зависимостей. Запустите pip show litellm и pip show telnyx во всех ваших окружениях, включая CI/CD раннеры и Docker-образы.
2. Удалите скомпрометированные версии и очистите кеш. Удалите пакеты и выполните pip cache purge или rm -rf ~/.cache/uv, чтобы закэшированные wheel-файлы не установились повторно.
3. Проверьте признаки персистентности. Ищите ~/.config/sysmon/sysmon.py и ~/.config/systemd/user/sysmon.service. В Kubernetes — поды node-setup-* в kube-system. На Windows — файл msbuild.exe в папке Startup.
4. Ротируйте все секреты. SSH-ключи, токены облачных провайдеров, ключи API из .env, пароли БД, токены PyPI — всё, что присутствовало в скомпрометированном окружении.
5. Фиксируйте версии зависимостей. Используйте lock-файлы: pip freeze, uv lock, poetry.lock.
6. Включите PyPI Trusted Publishers. Привяжите публикацию пакетов к конкретному GitHub-репозиторию и workflow через OIDC. Украденные токены станут бесполезными.
7. Проверяйте хеши пакетов. Используйте флаг --require-hashes при установке через pip или аналогичные механизмы в uv и poetry.
8. Настройте мониторинг зависимостей. Инструменты вроде SafeDep vet, pip-audit или Socket помогут обнаружить вредоносные пакеты до попадания в продакшн.

Пример фиксации хешей с pip:

Пример фиксации с uv:

FAQ

Как понять, что мой проект затронут?

Проверьте установленные версии: pip show litellm и pip show telnyx. Если у вас litellm 1.82.7 или 1.82.8, либо telnyx 4.87.1 или 4.87.2 — вы затронуты. Также проверьте кеш пакетного менеджера: для uv поищите файл litellm_init.pth в ~/.cache/uv. Наличие этого файла — признак компрометации.

Достаточно ли просто обновить пакет?

Нет. Если вредоносная версия была установлена, одного обновления недостаточно. Вредонос мог уже установить персистентный бэкдор (~/.config/sysmon/sysmon.py), украсть секреты или создать привилегированные поды в Kubernetes. Необходимо провести полный аудит: проверить систему на признаки персистентности, ротировать все секреты и очистить кеш пакетного менеджера.

Работает ли вредоносный код в Docker-контейнерах?

Да. .pth-файл из litellm срабатывает при любом запуске Python в контейнере, где установлен пакет. Более того — если в контейнере доступен Kubernetes service account token (что является стандартной конфигурацией), вредонос может выйти за пределы контейнера и скомпрометировать весь кластер.

Как TeamPCP получила токены PyPI?

Через скомпрометированный Trivy. CI/CD пайплайны LiteLLM и, вероятно, telnyx устанавливали Trivy из apt-репозитория без фиксации версии. Когда TeamPCP подменила бинарник в репозитории, отравленный Trivy с привилегиями CI-раннера извлёк секреты окружения — в том числе токены для публикации на PyPI. Репозиторий telnyx не использовал Trivy, поэтому точный вектор получения его токена пока не установлен, но паттерн атаки идентичен.

Можно ли было обнаружить атаку до установки?

Да, при наличии правильных инструментов. Отсутствие соответствующего GitHub-тега для опубликованной версии, изменение инструмента загрузки (twine вместо rye publish), появление .pth-файла в wheel — всё это детектируемые аномалии. Инструменты типа SafeDep vet умеют проверять пакеты на подобные сигналы. Также помогает проверка хешей через --require-hashes.

Выводы

Волна атак TeamPCP демонстрирует новый уровень supply chain атак: это не тайпсквоттинг и не подмена малоизвестных пакетов. Атакующие компрометируют инфраструктуру публикации настоящих, широко используемых библиотек — и делают это через цепочку доверия. Trivy ломает CI/CD, CI/CD отдаёт PyPI-токены, PyPI-токены используются для публикации троянизированных пакетов.

«Безопасность цепочки поставок — это не отдельная задача, а свойство всего процесса разработки. Если ваш сканер уязвимостей сам становится вектором атаки, проблема не в конкретном инструменте — проблема в том, что мы устанавливаем инструменты безопасности с тем же уровнем доверия, что и обычные зависимости.»

Три ключевых урока из этой истории:

1. Фиксируйте версии всего — не только библиотек, но и инструментов в CI/CD. apt-get install trivy без версии — это приглашение для атакующего.
2. Используйте Trusted Publishers — PyPI OIDC привязывает публикацию к конкретному репозиторию. Украденный токен без workflow бесполезен.
3. Мониторьте аномалии — отсутствие GitHub-тега для PyPI-версии, смена upload tool, появление .pth-файлов — всё это сигналы компрометации.

Источники: SafeDep — анализ litellm, SafeDep — анализ telnyx, FutureSearch — обнаружение litellm, GitHub Advisory litellm #24512.

Telnyx — платформа для программируемой телефонии, SMS и сетевых сервисов. Её Python SDK (telnyx на PyPI) скачивают более 1 миллиона раз в месяц (~30 000 загрузок в день). 27 марта 2026 года исследователи из SafeDep обнаружили, что версии 4.87.1 и 4.87.2 содержат вредоносный код, которого нет в исходном репозитории на GitHub. Инциденту присвоен CVE-2026-33634 (CVSS 9.4). Обе заражённые версии уже карантинированы PyPI.

Главное: Версии telnyx 4.87.1 и 4.87.2 на PyPI содержат вредоносный код — 74 строки, внедрённые в файл _client.py. Пакет скачивают более 1 млн раз в месяц. Вредонос использует стеганографию в WAV-файлах для доставки полезной нагрузки. На Windows устанавливается бэкдор, на Linux/macOS — крадутся учётные данные. Безопасная версия — 4.87.0. Атака связана с группировкой TeamPCP — это уже третье звено в цепочке после компрометации Trivy, Checkmarx и litellm.

Supply chain attack (атака на цепочку поставок) — тип атаки, при которой злоумышленник компрометирует не конечную цель, а один из компонентов, от которого она зависит: библиотеку, SDK или инструмент сборки. Разберём, как именно сработала атака и что делать, если вы используете telnyx.

Как произошла компрометация

Последняя чистая версия пакета — 4.87.0 — была опубликована 26 марта через штатный CI/CD-пайплайн (GitHub Actions + Rye). У неё есть соответствующий тег v4.87.0 в репозитории.

Версии 4.87.1 и 4.87.2 не имеют ни тегов, ни релизов на GitHub. Workflow публикации не запускался после v4.87.0. Метаданные PyPI показывают, что заражённые версии были загружены через twine/6.2.0, тогда как легитимный пайплайн использует rye publish.

Вывод: атакующий получил украденный PyPI API-токен и загрузил троянизированные версии напрямую, минуя CI/CD. У проекта не был настроен PyPI Trusted Publisher (OIDC), который привязывает загрузку к конкретному репозиторию и воркфлоу, делая украденные токены бесполезными.

Как работает вредоносный код

В файл telnyx/_client.py было внедрено ровно 74 строки кода в трёх местах: импорты в начале файла, base64-закодированная переменная с полезной нагрузкой и функции атаки после легитимных классов. Код выполняется автоматически при import telnyx — никакого взаимодействия с пользователем не требуется.

WAV-стеганография

Ключевая особенность атаки — использование стеганографии. Вредонос скачивает с C2-сервера файлы, замаскированные под WAV-аудио (ringtone.wav для Linux/macOS, hangup.wav для Windows). Исполняемый код спрятан в аудиофреймах и извлекается через XOR-деобфускацию. Импорт модуля wave в SDK для телефонии — единственный «красный флаг», который мог выдать атаку при code review.

Windows: бэкдор через автозагрузку

Функция setup() проверяет os.name == 'nt', затем скачивает бинарник из WAV-файла и сохраняет его как msbuild.exe в папку автозагрузки Windows. Имя файла имитирует легитимный инструмент Microsoft Build Engine. Бэкдор запускается при каждом входе в систему с кулдауном повторной установки 12 часов.

Linux/macOS: кража учётных данных

Функция FetchAudio() запускает второй этап из base64-закодированной переменной (4 436 символов). Скрипт собирает учётные данные, API-ключи, SSH-ключи и секреты, шифрует их связкой AES-256-CBC + RSA-4096 с хардкодированным публичным ключом и отправляет на C2-сервер через HTTP POST.

Баг атакующего

Любопытная деталь: в версии 4.87.1 атака на Windows не работала. Атакующий вызвал Setup() с заглавной буквы, тогда как функция определена как setup() со строчной. Это вызывало NameError, прерывавший выполнение модуля до запуска FetchAudio(). Версия 4.87.2 — по сути патч-релиз атакующего, исправляющий эту опечатку.

Связь с TeamPCP: цепочка атак

RSA-4096 публичный ключ, зашитый в вредоносный код, побайтово совпадает с ключом из компрометации пакета litellm. Это позволяет с высокой уверенностью атрибутировать атаку группировке TeamPCP. Группировка использует инфраструктуру CanisterWorm, размещённую на блокчейне Internet Computer Protocol (ICP) — без единой точки отказа.

Компрометация telnyx — третье крупное звено в каскадной атаке TeamPCP:

• 27 февраля — атака на репозиторий Trivy (сканер уязвимостей от Aqua Security) через вредоносный PR
• 19–20 марта — заражённый Trivy v0.69.4 опубликован, CanisterWorm распространился на 46+ npm-пакетов
• 23 марта — скомпрометированы Checkmarx GitHub Actions
• 24 марта — заражены версии litellm 1.82.7 и 1.82.8 на PyPI (~97 млн загрузок/мес)
• 27 марта — заражены версии telnyx 4.87.1 и 4.87.2 на PyPI

Что делать

1. Проверьте версию telnyx в ваших проектах
2. Если установлена 4.87.1 или 4.87.2 — немедленно откатитесь на 4.87.0
3. Проверьте наличие файла msbuild.exe в папке автозагрузки Windows
4. Проверьте сетевые соединения с IP 83.142.209.203
5. Если обнаружены IoC — считайте все учётные данные, API-ключи и SSH-ключи скомпрометированными
6. Проверьте CI/CD на использование других скомпрометированных пакетов TeamPCP: Trivy, Checkmarx Actions, litellm
7. Включите Trusted Publishers для всех ваших PyPI-пакетов

Индикаторы компрометации (IoC)

CVE-2026-33634 (CVSS 9.4) — GitHub issue #235

FAQ

Какие версии telnyx заражены?

Вредоносный код содержится в версиях 4.87.1 и 4.87.2. Обе уже карантинированы PyPI. Последняя безопасная версия — 4.87.0. При этом в 4.87.1 из-за опечатки атакующего ни один из векторов атаки фактически не срабатывал.

Как атакующие получили доступ к PyPI?

Через украденный PyPI API-токен. GitHub-репозиторий telnyx не был скомпрометирован — атакующие загрузили пакеты напрямую на PyPI через twine, минуя CI/CD. У проекта не был настроен Trusted Publisher (OIDC), который предотвратил бы такую атаку.

Кто стоит за атакой?

Атака атрибутирована группировке TeamPCP. Это та же группа, которая ранее скомпрометировала сканер уязвимостей Trivy, GitHub Actions Checkmarx и PyPI-пакет litellm. RSA-ключ в вредоносном коде побайтово совпадает с ключом из предыдущих атак. Инфраструктура CanisterWorm размещена на блокчейне ICP, что делает её устойчивой к блокировке.

Что делать, если я уже установил заражённую версию?

Немедленно откатитесь на версию 4.87.0. Проверьте систему на наличие IoC. Если обнаружены признаки компрометации — считайте все учётные данные, API-ключи и SSH-ключи на этой машине скомпрометированными и выполните их ротацию. Также проверьте CI/CD на использование Trivy, Checkmarx Actions и litellm.

Выводы

Атака на telnyx — не изолированный инцидент. Это часть каскадной кампании TeamPCP, которая за месяц скомпрометировала Trivy, Checkmarx, litellm и теперь telnyx. Единственная надёжная защита — PyPI Trusted Publishers (OIDC), привязывающий загрузку к конкретному GitHub-репозиторию.

Этот инцидент в очередной раз показывает: доверять пакетам из PyPI «на слово» нельзя, даже если это официальный SDK крупной платформы. Настройте Trusted Publishers, пиньте версии зависимостей, проверяйте хеши при установке. Проверьте свои проекты прямо сейчас.

Источники: SafeDep, Aikido, The Hacker News, JFrog Security Research

LiteLLM — это open-source прокси для работы с API различных LLM-провайдеров: OpenAI, Anthropic, Azure, Bedrock и ещё сотней других. Библиотека позволяет переключаться между моделями через единый интерфейс с автоматическими фоллбэками, ретраями и трекингом расходов. При 97 миллионах загрузок в месяц (около 3,4 млн в день) это один из самых популярных инструментов в AI-инфраструктуре.

В скомпрометированных версиях 1.82.7 и 1.82.8, опубликованных на PyPI, обнаружили встроенный стилер учётных данных. Он крал SSH-ключи, токены облачных сервисов, API-ключи и пароли, а затем расползался по Kubernetes-кластерам.

Ключевое: Версии LiteLLM 1.82.7 и 1.82.8 на PyPI содержали стилер, крадущий SSH-ключи, облачные токены и API-ключи. Версия 1.82.8 запускала вредоносный код при каждом старте Python — даже без импорта библиотеки. Если вы устанавливали LiteLLM 24 марта 2026 года — проверьте свои системы. Последняя чистая версия — 1.82.6.

Но эта атака — не изолированный инцидент. Это финал пятидневной supply chain атаки (атаки через цепочку поставок — внедрение вредоносного кода в легитимный пакет через компрометацию его инфраструктуры). За ней стоит группировка TeamPCP — ранее неизвестная группа, которая за последнюю неделю марта целенаправленно атаковала инструменты безопасности и разработки. Кампания началась с компрометации сканера уязвимостей Trivy и через цепочку украденных CI/CD-креденшалов дотянулась до LiteLLM.

Разбираем всю цепочку атаки от начала до конца — подробнее, чем где-либо ещё.

Хронология: пять дней, три вендора, пять экосистем

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

19 марта: Trivy — точка входа

Всё началось с Trivy — open-source сканера уязвимостей от Aqua Security, которым пользуются тысячи компаний для проверки контейнеров и кода.

Атакующие использовали скомпрометированные учётные данные мейнтейнера, чтобы:

• Опубликовать вредоносный релиз Trivy v0.69.4, который прошёл через стандартную release-машинерию и попал в GHCR, ECR Public, Docker Hub, deb/rpm-пакеты
• Подменить 76 из 77 тегов aquasecurity/trivy-action на вредоносные коммиты
• Заменить все 7 тегов aquasecurity/setup-trivy

Вредоносный код в GitHub Actions сканировал память процесса Runner.Worker, собирал креденшалы, шифровал данные AES+RSA и отправлял на подставной домен scan.aquasecurtiy[.]org — обратите внимание на опечатку в слове «security». Если прямая эксфильтрация не удавалась, малварь создавала публичный репозиторий tpcp-docs через GitHub-токен жертвы и сливала данные туда.

20–22 марта: npm-червь и дефейс

Уже на следующий день украденные токены пошли в дело. Атакующие запустили самораспространяющегося npm-червя: 28 пакетов в @EmilGroup, 16 в @opengov, плюс отдельные пакеты в других скоупах. Червь крал npm-токены из скомпрометированных окружений, проверял, к каким пакетам они дают доступ, поднимал patch-версию, подставлял оригинальный README для маскировки и переиздавал пакет с вредоносной начинкой.

К 22 марта та же инфраструктура начала обслуживать Kubernetes-скрипт с разделением жертв по геолокации. На иранских системах деплоился DaemonSet с контейнером kamikaze, который удалял файловую систему хоста и перезагружал ноду. На остальных — устанавливал персистентный бэкдор.

В тот же день атакующие дефейснули 44 репозитория внутренней GitHub-организации Aqua Security (aquasec-com), переименовав их с префиксом tpcp-docs- и описанием «TeamPCP Owns Aqua Security».

23 марта: Checkmarx

Кампания добралась до Checkmarx — ещё одного крупного вендора в сфере безопасности приложений. Были скомпрометированы:

• Checkmarx/kics-github-action — сканер инфраструктурного кода
• Checkmarx/ast-github-action — GitHub Action для платформы Checkmarx
• Расширения VS Code в реестре Open VSX: ast-results v2.53.0 (около 36 000 загрузок) и cx-dev-assist v1.7.0 (около 500 загрузок)

Паттерн тот же: стилер креденшалов, привязанный к домену checkmarx[.]zone, с фоллбэком на публичный репозиторий docs-tpcp для эксфильтрации.

24 марта: LiteLLM

В 10:52 UTC на PyPI появилась версия LiteLLM 1.82.8. Соответствующий тег или релиз на GitHub отсутствовал — пакет был загружен напрямую, в обход стандартного процесса. По данным ReversingLabs, был скомпрометирован GitHub-аккаунт сооснователя и CEO LiteLLM Криша Дхолакии — предположительно, через CI/CD-пайплайн, где Trivy использовался без пиннинга версии.

Через три часа команда безопасности PyPI поставила проект на карантин. Скомпрометированные версии были удалены. Последняя чистая версия — 1.82.6. Но при 3,4 миллионах загрузок в день даже три часа — это огромное окно.

Мейнтейнеры LiteLLM опубликовали security-апдейт, подтвердив компрометацию и рекомендовав всем пользователям обновиться до версии 1.82.6 или выше (после снятия карантина). Issue #24512 на GitHub, описывающий уязвимость, был закрыт — предположительно, самим атакующим через скомпрометированный аккаунт.

Как работает вредоносный код

Теперь разберём, что именно попадало на машины жертв. LiteLLM оказался скомпрометирован в двух версиях, и они существенно различаются по механизму запуска.

Версия 1.82.7: инъекция в proxy_server.py

В версии 1.82.7 вредоносный код был внедрён в файл litellm/proxy/proxy_server.py. Малварь запускалась только при реальном использовании LiteLLM Proxy в приложении. Если пакет был установлен, но прокси-сервер не запускался, код мог не сработать.

Версия 1.82.8: .pth-файл — запуск без импорта

Версия 1.82.8 принципиально опаснее. В wheel-пакет был добавлен файл litellm_init.pth размером 34 628 байт, содержащий дважды закодированный в base64 вредоносный код.

.pth-файлы — малоизвестная особенность Python. Согласно документации модуля site, исполняемые строки в .pth-файлах выполняются автоматически при каждом запуске интерпретатора. Не при импорте библиотеки, а при запуске любого Python-процесса в окружении, где установлен пакет.

Это означает: достаточно было выполнить pip install litellm==1.82.8, и каждый последующий запуск Python на этой машине активировал стилер. Не нужно писать import litellm — даже python -c "print('hello')" запускал вредоносный код.

Три стадии: сбор, шифрование, эксфильтрация

Стадия 1 — сбор. Скрипт прочёсывает машину и собирает:

• SSH-ключи и конфигурации (~/.ssh/)
• .env-файлы с секретами
• Креденшалы AWS (Access Key, Secret Key), GCP (ADC), Azure
• Конфигурации Kubernetes (~/.kube/config)
• Docker-конфиги (~/.docker/config.json)
• Пароли баз данных
• Историю шелла (bash_history, zsh_history)
• Файлы криптокошельков
• Все переменные окружения
• Данные с облачных metadata-эндпоинтов (IMDS)

Стадия 2 — шифрование. Собранные данные упаковываются в tar-архив и шифруются гибридной схемой: случайный сессионный ключ AES-256-CBC для данных, зашифрованный захардкоженным 4096-битным RSA-публичным ключом.

Стадия 3 — эксфильтрация. Зашифрованный архив отправляется POST-запросом на models.litellm[.]cloud (домен не имеет отношения к настоящему litellm.ai) с заголовком X-Filename: tpcp.tar.gz.

Горизонтальное распространение в Kubernetes

Если на машине обнаружен токен сервисного аккаунта Kubernetes, малварь переходит в режим горизонтального распространения (lateral movement):

1. Читает все секреты кластера во всех неймспейсах
2. Создаёт привилегированный pod на каждой ноде в kube-system на основе образа alpine:latest
3. Каждый pod монтирует корневую файловую систему хоста
4. Устанавливает персистентный бэкдор в /root/.config/sysmon/sysmon.py
5. Регистрирует systemd user service для автозапуска

Таким образом, компрометация одного pip-пакета превращается в полную компрометацию всего Kubernetes-кластера.

Персистентность и бэкдор

На локальной машине малварь создаёт:

• ~/.config/sysmon/sysmon.py — скрипт-бэкдор
• ~/.config/systemd/user/sysmon.service — systemd unit для автозапуска

После установки бэкдор периодически обращается к https://checkmarx[.]zone/raw, скачивает файл в /tmp/pglog и выполняет его содержимое. Это даёт атакующим возможность удалённо выполнять произвольный код на скомпрометированных машинах в любой момент.

Как обнаружили: баг в малвари устроил fork-бомбу

Ирония истории в том, что атаку обнаружили благодаря ошибке самих хакеров.

Команда FutureSearch столкнулась с проблемой случайно: MCP-плагин в IDE Cursor подтянул LiteLLM как транзитивную зависимость. Вредоносный .pth-файл запускал дочерний Python-процесс через subprocess.Popen. Но поскольку .pth-файлы срабатывают при каждом запуске интерпретатора, дочерний процесс тоже запускал малварь, та порождала ещё один процесс — и так далее.

Результат — экспоненциальная fork-бомба, которая мгновенно съедала всю оперативную память и вешала систему. Без этого бага стилер мог бы работать незамеченным значительно дольше.

Мы были взломаны… тысячи людей, вероятно, прямо сейчас под атакой

Что делать, если вы затронуты

Если в ваших проектах, CI/CD-пайплайнах или на рабочих машинах устанавливался LiteLLM 24 марта или позже — проверьте версию:

Если обнаружена версия 1.82.7 или 1.82.8:

1. Удалите пакет и очистите кэши: pip cache purge, rm -rf ~/.cache/uv
2. Проверьте наличие бэкдора: файлы ~/.config/sysmon/sysmon.py и ~/.config/systemd/user/sysmon.service
3. В Kubernetes: аудит kube-system на наличие подов node-setup-*, проверка секретов на несанкционированный доступ
4. Ротация всех креденшалов: SSH-ключи, облачные токены (AWS, GCP, Azure), API-ключи, пароли БД, .env-файлы
5. Сетевые логи: проверьте обращения к models.litellm[.]cloud, checkmarx[.]zone, scan.aquasecurtiy[.]org
6. Восстановление: не ограничивайтесь удалением пакета — пересобирайте системы из известных чистых образов с закреплёнными (pinned) зависимостями

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

Индикаторы компрометации (IoC)

Вредоносные домены:

• models.litellm[.]cloud — C2 для LiteLLM
• checkmarx[.]zone — C2, используемый для персистентности и Checkmarx-атаки
• scan.aquasecurtiy[.]org — C2 для Trivy-атаки

Файлы на диске:

• litellm_init.pth в site-packages/
• ~/.config/sysmon/sysmon.py
• ~/.config/systemd/user/sysmon.service
• /tmp/pglog
• /tmp/.pg_state

Kubernetes-артефакты:

• Поды с именами node-setup-* в kube-system
• Контейнеры с именами kamikaze или provisioner

Инциденту присвоен идентификатор CVE-2026-33634. Полный список IoC в формате CSV доступен в репозитории Datadog Security Labs.

Частые вопросы

Что такое LiteLLM и зачем его используют?

LiteLLM — это open-source Python-библиотека и прокси-сервер, который предоставляет единый интерфейс для работы с более чем 100 LLM-провайдерами (OpenAI, Anthropic, Azure, AWS Bedrock и другие). Библиотека позволяет переключаться между моделями без изменения кода, автоматически обрабатывает фоллбэки и ретраи, отслеживает расходы. По данным PyPI, пакет загружается около 3,4 миллионов раз в день.

Какие версии LiteLLM скомпрометированы?

Скомпрометированы версии 1.82.7 и 1.82.8, опубликованные на PyPI 24 марта 2026 года. Обе версии удалены. Последняя безопасная версия — 1.82.6. Версия 1.82.8 опаснее: она запускает вредоносный код при каждом старте Python через механизм .pth-файлов, тогда как 1.82.7 активируется только при использовании прокси-сервера.

Как проверить, затронут ли я?

Выполните pip show litellm для проверки версии и find ~/.cache/uv -name "litellm_init.pth" для поиска вредоносного файла в кэше. Также проверьте наличие бэкдора: файлы ~/.config/sysmon/sysmon.py и ~/.config/systemd/user/sysmon.service. В Kubernetes ищите поды node-setup-* в namespace kube-system.

Кто стоит за атакой?

Атака приписывается группировке TeamPCP, которая за последнюю неделю марта 2026 года провела серию supply chain атак на инструменты разработки и безопасности: сканер уязвимостей Trivy (Aqua Security), GitHub Actions и расширения VS Code от Checkmarx, npm-пакеты, и в финале — LiteLLM. Инциденту присвоен идентификатор CVE-2026-33634.

Что такое .pth-файл и почему он опасен?

Файлы с расширением .pth, размещённые в директории site-packages, автоматически обрабатываются модулем site Python при каждом запуске интерпретатора. Исполняемые строки в таких файлах выполняются без явного импорта библиотеки. В случае LiteLLM 1.82.8 файл litellm_init.pth содержал дважды закодированный в base64 вредоносный скрипт, который запускался при каждом вызове python в скомпрометированном окружении.

Выводы

Ирония инцидента — в том, что LiteLLM по определению хранит API-ключи ко всем LLM-провайдерам организации. Атакующие выбрали пакет, который гарантированно имеет доступ к самым ценным секретам.

Одна зависимость. Одна цепная реакция. Пять экосистем supply chain скомпрометированы менее чем за месяц

TeamPCP целенаправленно атаковали инструменты безопасности — сканер уязвимостей, анализатор инфраструктурного кода, прокси для LLM. Эти инструменты по своей природе имеют широкий доступ, и компрометация одного из них даёт атакующим доступ ко всем секретам, которые этот инструмент должен был защищать.

Устанавливать пакеты из публичного реестра без проверки хешей и без lock-файлов — значит фактически отдать root-доступ любому, кто сможет скомпрометировать аккаунт мейнтейнера. Как ёмко выразилась Ноэлль Мурата, старший инженер по безопасности в Xcape: «Это цифровой эквивалент того, чтобы съесть бутерброд, найденный в метро, и удивиться пищевому отравлению».

Подробный технический анализ от Datadog Security Labs доступен здесь. Оригинальный отчёт FutureSearch — здесь. Официальный security-апдейт LiteLLM — здесь.

Проверьте свои зависимости сегодня. Команды для аудита — в разделе выше.

EDR — это очень мощное ПО. Можно сказать, что это основа современной безопасности.

Но есть такая техника, при которой EDR лежит кверху лапками, как безобидный щеночек, а не как сторожевой пес размером с трактор. Эта техника называется BYOVD (Bring Your Own Vulnerable Driver), посредством которой злоумышленники проникают в систему, повышают привилегии и потом делают то, что им нужно.

В статье разберу чем опасны BYOVD-атаки и поделюсь готовыми правилами детектирования, которые можно распечатать и всегда держать под рукой.

Теоретическая часть: как работает BYOVD-атака

BYOVD очень опасная техника.

• Программы-вымогатели BlackByte и AvosLocker использовали BYOVD для обхода средств защиты.
• По данным Huntress, в 2024 году значительная доля атак шифровальщиков включала обход EDR — в том числе через уязвимые драйверы.
• BYOVD — типовая фаза ransomware-операций, а ransomware — главная киберугроза для российского бизнеса. В 2024 году шифровальщики парализовали СДЭК на трое суток (300 тыс. посылок в день), положили платёжные терминалы сети «Верный» по всей стране (убытки 120–140 млн руб./день), а в июле 2025-го хакеры уничтожили ИТ-инфраструктуру «Аэрофлота», вынудив отменить более 100 рейсов. Во всех этих инцидентах ключевым этапом было отключение защиты — и именно BYOVD остаётся самой распространённой техникой для этого. По данным Symantec, в 2026 году BYOVD стал наиболее частым методом обхода EDR в ransomware-атаках.
• BYOVD — обязательный компонент в кибершпионаже. К слову, в процессе знаменитой масштабной операции по кибершпионажу, называемой Operation DreamJob, проводимой группировкой Lazarus, использовался BYOVD. Группировка создавала фейковые профили рекрутеров в LinkedIn и рассылала жертвам «вакансии» — ISO-файлы с вредоносной начинкой: многоступенчатой цепочкой загрузчиков (RollFling → RollSling → RollMid → KaolinRAT), финальным звеном которой был FudModule — руткит, работающий на уровне ядра.

Практически во всех крупных ransomware-инцидентах ключевой этап — отключение EDR перед шифрованием. Если описать BYOVD в двух словах, то Bring Your Own Vulnerable Driver (BYOVD) — это техника, при которой злоумышленник использует уязвимость Windows, чтобы обойти EDR и получить привилегированный доступ к системе.

Дело в том, что Windows делит весь исполняемый код на два уровня доверия — в архитектуре x86 они называются кольцами защиты (protection rings): Ring 3 пользовательский режим, и Ring 0 режим ядра.

Обычные программы, вроде браузера, работают в Ring 3 и имеют ограниченный набор привилегий. А в ядре (Ring 0) работают ntoskrnl.exe (само ядро), HAL, файловая система, сетевой стек и все драйверы. А имея доступ к Ring 0 можно модифицировать любые структуры данных, завершать любые процессы и отключать любую телеметрию, что и делают BYOVD программы.

Доступ к Ring 0 можно получить посредством драйвера, потому что драйверы в Windows работают в ring 0 — то есть на уровне ядра, с максимальными привилегиями. Чтобы обезопасить ядро от нелегитимных пользователей, Microsoft ввёл обязательную подпись драйверов (DSE — Driver Signature Enforcement) и в теории, загрузить произвольный код в ядро нельзя — драйвер должен быть подписан сертификатом, которому доверяет Microsoft.

На деле в BYOVD-атаках используются именно легитимные подписанные драйверы, потому что Windows не проверяет списки отзыва сертификатов (CRL) при загрузке драйверов — на этом этапе загрузки ОС сеть ещё недоступна. Например, в феврале 2026 года Huntress обнаружил атаку, где 20-летний драйвер EnCase (драйвер EnCase подписан сертификатом от 15 декабря 2006 года) с отозванным сертификатом мог убивать 59 EDR-процессов.

EDR — это такой гибрид, у которого пользовательский интерфейс работает в Ring 3, а для мониторинга он устанавливает свой kernel-mode драйвер в Ring 0. Мониторинг EDR основан на kernel callbacks — специальных функциях- уведомлениях, которые ядро вызывает при определённых событиях, например, когда создаётся процесс — срабатывает PsSetCreateProcessNotifyRoutine, а когда загружается DLL — PsSetLoadImageNotifyRoutine.

Коллбэки регистрируются EDR-драйвером при загрузке, и ядро хранит их адреса в служебных структурах — таких как CallbackListHead.

Помимо kernel callbacks, EDR перехватывает вызовы API-функций через function-hooking DLL, которая инжектируется в каждый процесс. Эти хуки работают в user mode и подменяют первые байты функций ntdll.dll (например, NtAllocateVirtualMemory) на переход в код EDR.

Поэтому даже после отключения kernel callbacks EDR может получать телеметрию через user-mode хуки — и наоборот. Продвинутые руткиты атакуют оба уровня одновременно.

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

Microsoft поддерживает встроенный блок-лист уязвимых драйверов, но он покрывает лишь малую часть из сотен известных уязвимых драйверов в базе LOLDrivers.

Как так происходит? Есть три подхода к получению kernel-доступа, в том числе через BYOVD и смежные техники.

Подход 1: N-day уязвимости в сторонних драйверах

Атакующий берёт драйвер известного производителя (Dell, Intel, Realtek, MSI и десятки других) с уже обнаруженной уязвимостью. Драйвер подписан валидным сертификатом, DSE его пропускает. Через уязвимость (обычно это IOCTL, который позволяет произвольное чтение/запись физической или виртуальной памяти) атакующий получает примитивы для модификации ядра.

Примечание. Проект LOLDrivers.io на сегодня каталогизирует сотни таких драйверов.

Например, таким образом действовал инструмент FudModule группировки Lazarus (HIDDEN COBRA, APT38) — одной из самых технически продвинутых APT-группировок, связанных с КНДР. Первая версия FudModule (обнаружена ESET в 2022 году) эксплуатировала уязвимость CVE-2021-21551 в драйвере Dell dbutil_2_3.sys. Этот драйвер, предназначенный для обновления BIOS и firmware ноутбуков Dell, содержал критическую уязвимость: он принимал IOCTL-запросы, позволяющие читать и записывать произвольную физическую память без каких-либо проверок вызывающего процесса.

Для атакующего — находка: драйвер подписан Dell, Microsoft ему доверяет, а через IOCTL можно получить полный контроль над памятью ядра. Lazarus сбрасывали этот драйвер на диск, загружали через sc.exe create / sc.exe start и получали примитивы чтения/записи ядра.

Подход 2: Злоупотребление PreviousMode

Через эксплуатацию уязвимости атакующий меняет поле PreviousMode в структуре _KTHREAD текущего потока с UserMode (1) на KernelMode (0). После этого системные вызовы NtWriteVirtualMemory и NtReadVirtualMemory перестают проверять границы памяти и позволяют напрямую модифицировать пространство ядра из user mode.

Подход 3: 0-day в компонентах Windows

Более сложный путь: атакующий находит уязвимость в штатном драйвере операционной системы. Именно так поступила (опять же) группировка Lazarus с CVE- 2024-21338 в appid.sys (компонент AppLocker). В 2024 году группировка обновила FudModule до версии 2.0 и вместо стороннего драйвера Dell они нашли и проэксплуатировали 0-day уязвимость в appid.sys, штатном компоненте Windows, отвечающем за AppLocker.

Уязвимость имеет номер CVE-2024-21338 и её суть в том, что драйвер appid.sys содержал IOCTL, позволяющий вызвать произвольную функцию ядра с частичным контролем над первым аргументом. Для эксплуатации требовался LOCAL_SERVICE account — Lazarus получал его через имперсонацию.

Цепочка эксплуатации выглядела так:

1. Имперсонация LOCAL_SERVICE через стандартные механизмы Windows.
2. Вызов уязвимого IOCTL в appid.sys для исполнения произвольной функции ядра.
3. Через полученный примитив — модификация поля PreviousMode в _KTHREAD текущего потока (с UserMode на KernelMode).
4. Теперь NtWriteVirtualMemory / NtReadVirtualMemory можно вызывать из user mode без проверки границ → полный R/W доступ к памяти ядра.

Преимущество перед классическим BYOVD очевидно: не нужно сбрасывать файл на диск, не нужно загружать сторонний драйвер — appid.sys уже есть в каждой системе с включённым AppLocker. Это существенно снижает IoC и затрудняет детектирование.

Публичные тулкиты: BYOVD для всех

При этом BYOVD — это дешевый вид атаки — в 2024–2025 года готовые инструменты появились как грибы после дождя: на даркнет-форумах за несколько сотен долларов можно купить EDRKillShifter, AuKill, Blackout и прочее ПО для атак.

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

№1. BYOVD встраивается ВНУТРЬ ransomware

В феврале 2026 года Symantec зафиксировал новый паттерн: группировка Reynolds встроила уязвимый драйвер NSecKrnl прямо в payload шифровальщика. Раньше BYOVD-компонент и ransomware были отдельными файлами с временным зазором между ними — этот зазор давал SOC шанс среагировать. Теперь одного бинарника достаточно для отключения EDR и шифрования. По оценке Symantec, BYOVD стал самой частой техникой обхода защиты в ransomware-атаках 2026 года.

№2. POORTRY: кастомный вредоносный драйвер

Ещё интереснее POORTRY (Abyssworker) — не уязвимый легитимный драйвер, а специально написанный вредоносный драйвер, к которому атакующие получили валидную подпись через украденные сертификаты WHCP. Он маскировался под антивирусный компонент (например, драйвер Malwarebytes) и использовался в атаках Medusa и Osiris.

№3. RansomHub и EDRKillShifter

Группировка RansomHub разработала собственный инструмент EDRKillShifter, эксплуатирующий уязвимый драйвер TrueSight.sys. Инструмент стал стандартным компонентом их ransomware-набора и использовался для отключения EDR перед развёртыванием шифровальщика. По данным исследователей, EDRKillShifter применялся в десятках инцидентов в 2024 году.

№4. Kasseika: антивирусный драйвер против антивируса

Группировка Kasseika использовала ироничный подход — уязвимый драйвер антивирусного продукта (Martini.sys от TG Soft’s VirIT) для отключения конкурирующих EDR-решений. Цепочка атаки: через PsExec распространялся загрузчик, который сбрасывал уязвимый антивирусный драйвер, загружал его и через IOCTL завершал процессы защитных решений. После этого развёртывался шифровальщик.

№5. Deadlock: Baidu против безопасности

В декабре 2025 года Cisco Talos задокументировал новый вариант вымогателя Deadlock, использующий уязвимый драйвер Baidu Antivirus (BdApiUtil.sys, CVE- 2024-51324).

Атакующие использовали лоадер EDRGay.exe, который сбрасывал драйвер под именем DriverGay.sys в директорию Videos жертвы. Через IOCTL 0x800024b4 лоадер вызывал ZwTerminateProcess() для завершения всех EDR-процессов. Уязвимость квалифицирована как Improper Privilege Management — непривилегированный пользователь мог завершить любой системный процесс.

№6. BlackByte : систематический подход

BlackByte продемонстрировал системный подход к BYOVD: группировка использовала несколько уязвимых драйверов в разных кампаниях, включая RTCore64.sys и драйверы из базы LOLDrivers. Особенность их подхода — интеграция BYOVD-компонента непосредственно в цепочку развёртывания ransomware, с автоматическим выбором драйвера в зависимости от целевой системы.

Список ransomware-групп, использующих BYOVD, продолжает расти: Qilin (драйверы Zemana и Toshiba), Akira (драйвер Intel), Play, BianLian, Medusa, Rhysida, Cuba, GhostLocker, INC, Interlock (GameDriverx64.sys, CVE-2025- 61155). BYOVD стал стандартной фазой операции ransomware.

Разберём BYOVD-тулкит на примере Blackout

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

Большинство BYOVD-инструментов следуют одному паттерну: сбросить уязвимый драйвер на диск (часто в %TEMP% или %APPDATA%), создать и запустить сервис для его загрузки, через IOCTL получить примитив завершения произвольного процесса и последовательно убить все EDR/AV процессы по списку.

Разберем цепочку событий, которую генерирует типичная BYOVD-атака на примере публичного тулкита Blackout (ZeroMemoryEx) в тестовой среде (даже если атака не завершилась успехом)

Что такое Blackout? Это открытый инструмент на GitHub, реализующий классический паттерн BYOVD: сбросить на диск подписанный уязвимый драйвер, загрузить его через SCM (Service Control Manager) и через IOCTL-запрос завершить целевой процесс из Ring 0. Использование тривиально — достаточно указать PID жертвы:

Blackout.exe -p <PID_процесса>

Запуск в тестовой среде. Находим PID Sysmon и запускаем Blackout:

Blackout успешно создал сервис для загрузки kernel-драйвера,

...но сам драйвер не загрузился, потому что сертификат подписи драйвера (GMEREK Systemy Komputerowe, Польша) отозван Microsoft и внесён в Certificate Trust List операционной системы:

Скриншот cs start — ошибка отзыва сертификата.

Драйвер Blackout.sys подписан валидной цифровой подписью — но Microsoft, узнав об использовании этого драйвера в атаках, отозвал сертификат и добавил его хэш в системный блок-лист (Disallowed Certificate Store). Windows проверяет этот список при каждой загрузке драйвера — даже без доступа к интернету, потому что CTL вшит в ОС.

Это один из механизмов защиты от BYOVD, но с существенным ограничением: он работает только для уже известных драйверов. А база LOLDrivers.io содержит сотни уязвимых драйверов, и Microsoft физически не успевает отзывать все сертификаты. Поэтому атакующие просто берут менее известный драйвер — и блокировка не срабатывает.

Что увидит SOC. Несмотря на неудачную загрузку, попытка атаки оставила чёткие следы в телеметрии:

Event ID 7045 (System log — Service Control Manager).

Это событие — ключевой индикатор. Создание нового сервиса с типом «драйвер режима ядра», где путь к файлу указывает за пределы System32\drivers\ — аномалия, которая должна вызывать алерт максимального приоритета.

Хэш драйвера (SHA256): 18C909A2B8C5E16821D6EF908F56881AA0ECCEEACCB5FA1E54995935FCFD1 2F7

Есть хорошие новости: каждый этап BYOVD оставляет следы — надо знать, куда смотреть. Давайте приступим к финальной части статьи — к выстраиванию эшелонированного детектирования, не привязанного к конкретной SIEM-платформе.

Детектирование BYOVD: что и как мониторить

Правила детектирования BYOVD делятся на два типа.

• Brittle-детекты — ловят конкретные IoC: хэш известного уязвимого драйвера, имя файла, путь. Они дают минимальный false positive, но обходятся простой заменой драйвера.
• Robust-детекты — ловят поведение: цепочка «файл .sys → сервис → завершение EDR» сработает на любой неизвестный тулкит, но может дать ложные срабатывания на легитимную установку драйверов.

Эшелонированная стратегия строится на комбинации обоих типов.

Детект 1. Загрузка известного уязвимого драйвера

MITRE ATT&CK: T1068 (Exploitation for Privilege Escalation), T1562.001 (Impair Defenses: Disable or Modify Tools).

Самый базовый и эффективный детект — сопоставление хэшей загружаемых драйверов с базой LOLDrivers.io. Проект предоставляет актуальный список хэшей (SHA256, MD5, SHA1) всех известных уязвимых и вредоносных драйверов, а также готовые Sigma-правила.

Логика алерта:

Событие: загрузка драйвера (Sysmon Event ID 6 или аналог). Условие: SHA256-хэш загруженного файла совпадает с записью в базе LOLDrivers. Severity: Critical.

Дополнительные индикаторы, усиливающие уверенность:

• Драйвер загружается из нетипичного расположения (%TEMP%, %APPDATA%, %USERPROFILE%, директория Downloads).
• Имя драйвера не соответствует ожидаемому для данной системы (например, Dell dbutil на машине без оборудования Dell).
• Драйвер сбрасывается на диск непосредственно перед загрузкой (создание файла + загрузка драйвера в окне < 60 секунд).
• LOLDrivers.io отдаёт готовые Sigma-правила и CSV с хэшами для импорта в SIEM — не нужно собирать вручную.

Учти ограничение: хэш-детекты обходятся через CVE-2013-3900 (см. ниже).

Ограничение хэш-детектов: CVE-2013-3900 и Authenticode padding

Детект по SHA256 из LOLDrivers — необходимый минимум, но у него есть серьёзная слабость. CVE-2013-3900 — уязвимость в Windows Authenticode, которая позволяет менять байты в PE-файле за пределами подписанной области. Файловый хэш (SHA256) меняется, а подпись остаётся валидной. Windows загрузит такой драйвер без вопросов.

На практике это означает: атакующий берёт уязвимый драйвер из LOLDrivers, меняет пару байт — и получает файл, которого нет ни в одной хэш-базе. Check Point обнаружил более 2500 уникальных вариантов драйвера TrueSight.sys, созданных именно так: все с разными SHA256, все с одной подписью, все рабочие.

Есть два способа бороться с этим:

1. Authentihash — это хэш, который считается только по подписанным областям PE-файла. У всех 2500 вариантов TrueSight.sys один и тот же Authentihash, потому что подписанная часть не менялась. Если SIEM или EDR умеет работать с Authentihash — детект становится устойчивым к CVE-2013-3900.
2. Сертификат подписи — вместо хэша файла можно строить детект на сертификате, которым подписан драйвер (Subject, Issuer, Serial Number). Даже после модификации байтов сертификат остаётся тем же. Для Sysmon EID 6 доступны поля SignatureStatus и Signature — их можно использовать для фильтрации.

В KUMA это реализуется через дополнительную lookup-таблицу с Authentihash-значениями (доступны на LOLDrivers.io в формате CSV) или через проверку сертификата подписи в событиях Sysmon EID 6.

По сертификату подписи:

Митигация CVE-2013-3900 на уровне ОС — включить строгую проверку Authenticode через реестр:

После этого модифицированные драйверы с padding перестанут считаться подписанными. Фикс существует с 2013 года, но не включён по умолчанию — Microsoft боится сломать совместимость.

Детект 2. Подозрительное создание сервиса для драйвера

MITRE ATT&CK: T1543.003 (Create or Modify System Process: Windows Service)

Загрузка драйвера в Windows происходит через создание сервиса типа «kernel driver». Это генерирует события Windows Security (Event ID 4697 — A service was installed in the system) и System (Event ID 7045 — A new service was installed). Детект фокусируется на аномалиях:

Логика алерта:

Событие: создание нового сервиса с типом kernel driver (Event ID 7045). Условие: ImagePath указывает на файл вне стандартных директорий драйверов.

EID 7045 не содержит информации о родительском процессе — SCM логирует только параметры сервиса. Поэтому детектирование разбито на два правила: первое ловит аномальный путь в самом событии создания сервиса, второе — запуск sc.exe create type=kernel через Sysmon EID 1.

+

Детект 3. Создание символической ссылки на драйверы/файлы security-вендоров

MITRE ATT&CK: T1036 (Masquerading), T1562.001 (Impair Defenses)

Для детектирования техники Symbolic Link + BYOVD необходимо мониторить создание символических ссылок (junction points, reparse points) в системных директориях или указывающих на файлы security-вендоров.

Логика алерта:

Событие создания файла типа symbolic link, где компания-производитель целевого файла — security-вендор, а путь указывает на системную директорию драйверов.

На каком событии строить детект: Sysmon Event ID 11 (FileCreate) — срабатывает при создании файлов, включая reparse points (junction/symlink).

Правило в логическом виде:

Проще говоря: кто-то создал что-то в папке drivers\ и это не установщик драйверов Windows — подозрительно.

Детектирование Symbolic Link + BYOVD возможно на двух уровнях.

Базовый — через Sysmon Event ID 11: любое создание файла в C:\Windows\System32\drivers\ процессом, не являющимся штатным установщиком, генерирует алерт.

Продвинутый — через EDR-телеметрию, где доступен тип файла (symlink) и метаданные целевого объекта (File Company Name). Это позволяет точно детектировать создание символической ссылки, подменяющей компонент security-вендора, с минимальным уровнем false positive.

Логика реализуема в EDR-решениях с расширенной файловой телеметрией (Kaspersky KEDR Expert, BIZONE EDR) где доступны поля типа файла (symlink/junction) и метаданные PE-заголовка целевого объекта (CompanyName, FileDescription).

Детект 4. Исчезновение kernel callbacks / молчание EDR

MITRE ATT&CK: T1562.001 (Impair Defenses: Disable or Modify Tools)

Один из самых сложных, но самых ценных детектов — обнаружение факта отключения kernel callbacks. Прямой мониторинг невозможен (если ETW отключён, события не генерируются), но можно использовать косвенные индикаторы:

• Heartbeat-мониторинг EDR: если EDR-агент перестал отправлять телеметрию (или отправляет, но количество событий аномально снизилось) — это критический индикатор. SOC должен мониторить поток событий от каждого агента.
• ETW consumer watchdog: периодический опрос состояния ETW-сессий через logman query. Если системные ETW-сессии внезапно прекратились — это сигнал.
• Kernel callback verification: специализированные инструменты (или кастомный драйвер мониторинга) могут периодически проверять целостность массивов PspCreateProcessNotifyRoutine и CallbackListHead.

Логика алерта:

Условие: EDR-агент на хосте X не отправлял телеметрию более N минут (порог зависит от нормальной частоты). ИЛИ количество событий от агента снизилось более чем на 90% по сравнению с базовой линией за аналогичный период. Severity: Critical.

В KUMA это реализуется правилом на отсутствие событий: создаём корреляцию с типом «отсутствие события» (absence), где условие — от конкретного хоста не поступало ни одного события Sysmon за последние 10 минут. Порог подбирается под среду: для рабочих станций 10 минут, для серверов с высокой активностью — 5 минут.

Детект 5. Нетипичный процесс открывает хэндл к драйверу

MITRE ATT&CK: T1068 (Exploitation for Privilege Escalation)

При эксплуатации уязвимого драйвера атакующий вызывает CreateFile("\\\\.\\<DeviceName>") для получения хэндла, а затем DeviceIoControl() для отправки IOCTL-команд. В случае успешной загрузки обращение шло бы к устройству \\.\Blackout — объекту, зарегистрированному загруженным драйвером Blackout.sys.

Логика алерта:

Событие: если к устройству драйвера Dell (\\.\DBUtil_2_3) обращается не процесс Dell, а неизвестный бинарник из C:\Users\Downloads\ — это аномалии.

Реализация этого детекта требует расширенной телеметрии: аудита доступа к объектам ядра (Windows Security Policy → Object Access) или EDR с мониторингом device handle operations. Стандартный Sysmon этот уровень не покрывает — это один из аргументов в пользу EDR-решений с kernel-level телеметрией, даже с учётом рисков BYOVD.

В KEDR Expert и BI.ZONE EDR операции DeviceIoControl логируются через kernel-level телеметрию.

Если таких EDR нет — можно включить Object Access Auditing через GPO (Computer Configuration → Windows Settings → Security Settings → Advanced Audit Policy → Object Access → Audit Kernel Object), но это генерирует большой объём событий и требует тщательной фильтрации.

Детект 6. Аномалии PreviousMode

MITRE ATT&CK: T1068 (Exploitation for Privilege Escalation)

Этот детект — скорее гипотеза для threat hunting, чем правило для автоматического алертинга. Прямой мониторинг PreviousMode из user mode невозможен, но косвенные признаки могут указать на эксплуатацию:

PreviousMode это поле в структуре потока, которое говорит ядру: «Этот запрос пришёл из user mode или из kernel mode?»

Lazarus через CVE-2024-21338 менял это значение с 1 на 0. После этого обычный процесс мог вызывать NtWriteVirtualMemory и писать прямо в память ядра — ядро думало что запрос от компонента ядра.

Изменение PreviousMode в _KTHREAD — ключевой примитив атак CVE-2024- 21338 и аналогичных. Напрямую мониторить это из user mode невозможно, но можно детектировать косвенные признаки:

• Процесс из user mode успешно вызывает NtWriteVirtualMemory / NtReadVirtualMemory для адресов пространства ядра системы (> 0x7FFFFFFFFFFF) — это аномалия, которую можно детектировать через ETW-провайдер Microsoft-Windows-Kernel-Audit-API-Calls (если он ещё не отключён)
• Процесс LOCAL_SERVICE внезапно выполняет операции, не характерные для этого аккаунта — например, создаёт файлы, загружает DLL, устанавливает сетевые соединения.

Детект 7. Загрузка драйвера с отозванным или истёкшим сертификатом

MITRE ATT&CK: T1553.002 (Subvert Trust Controls: Code Signing)

Sysmon EID 6 при загрузке драйвера фиксирует статус подписи. Если подпись невалидна, отозвана или просрочена — это повод для алерта.

В конфигурации Sysmon должен быть включён тег <CheckRevocation/>.

Логика алерта:

Событие: загрузка драйвера (Sysmon EID 6). Условие: SignatureStatus не равен 'Valid'.

Дополнительный фильтр для снижения FP: исключить драйверы Microsoft, подписанные в тестовом режиме (если на хосте включён testsigning).

Этот детект ловит атаки типа EnCase BYOVD (Huntress, 2026): драйвер с сертификатом 2010 года, отозванным 15 лет назад, но всё ещё загружаемым Windows.

Детект 8. Комплексный подход: корреляция событий

Самый мощный детект — корреляция слабых сигналов в рамках одного инцидента. Типичная цепочка BYOVD-атаки генерирует следующую последовательность:

1. Файл .sys появляется в нетипичной директории (File Create)
2. Создаётся новый сервис типа kernel driver (Event ID 7045)
3. Загружается драйвер с хэшем из базы LOLDrivers (Sysmon ID 6)
4. Процесс открывает хэндл к устройству драйвера (File/Object Access)
5. Один или несколько EDR/AV процессов завершаются (Event ID 4689) или перестают генерировать телеметрию
6. Загруженный драйвер имеет невалидную, отозванную или просроченную подпись (Sysmon EID 6, SignatureStatus ≠ Valid)

Логика корреляционного правила:

Если на одном хосте в течение 5 минут происходят события #1 + #2 + (#3 ИЛИ #5 ИЛИ #6) — это с высокой вероятностью BYOVD-атака.

Готовые правила для SIEM KUMA

Для тех, кто работает с KUMA — пять правил корреляции, адаптированных под синтаксис платформы. Время внедрения — 15–20 минут на правило.

Правило 1. Загрузка драйвера из нестандартного пути

Тип: простое | Источник: Sysmon | Severity: HIGH | MITRE: T1068, T1543.003

Реакция: проверить хэш на loldrivers.io, найти источник файла (EID 11).

Правило 2. Создание kernel-mode сервиса

Тип: простое | Источник: Windows System Log | Severity: HIGH | MITRE: T1543.003

FP: установка драйверов ПО/принтеров. Коррелировать с EID 6.

Правило 3. sc.exe create type=kernel

Тип: простое | Источник: Windows Security / Sysmon | Severity: HIGH | MITRE: T1543.003

Правило 4. Массовое завершение защитных процессов

Тип: агрегация (count) | Источник: Sysmon | Severity: CRITICAL | MITRE: T1562.001

Реакция: НЕМЕДЛЕННАЯ ИЗОЛЯЦИЯ хоста!

Правило 5. ETW tampering через CLI

Тип: простое | Источник: Windows Security / Sysmon | Severity: HIGH | MITRE: T1562.006

Митигации: как снизить риск BYOVD

BYOVD не закрывается одним патчем — уязвимых подписанных драйверов сотни. Но усложнить атаку можно.

№1. HVCI (Hypervisor-Protected Code Integrity)

HVCI (также известный как Memory Integrity) использует гипервизор для контроля целостности кода ядра. С включённым HVCI загрузка драйверов проверяется на уровне VTL1, что значительно затрудняет эксплуатацию уязвимых драйверов. Ограничение: HVCI может вызывать проблемы совместимости со старым оборудованием и драйверами.

HVCI защищает ключевые структуры ядра, включая ci!g_CiOptions — переменную, контролирующую проверку подписей драйверов. Без HVCI атакующий с BYOVD-примитивом может перезаписать ci!g_CiOptions и загрузить вообще любой неподписанный драйвер. С включённым HVCI эта переменная находится под защитой гипервизора (VTL1), и попытка записи вызовет исключение. Это делает HVCI единственной митигацей, защищающей ci!g_CiOptions на уровне гипервизора.

№2. Microsoft Vulnerable Driver Blocklist

Microsoft поддерживает список заблокированных уязвимых драйверов, который может применяться через WDAC (Windows Defender Application Control) или ASR (Attack Surface Reduction) правила. Важно убедиться, что этот список обновляется регулярно — по умолчанию он обновляется только с крупными обновлениями Windows.

№3. ASR Rules

ASR (Attack Surface Reduction) — это набор правил в Windows Defender, которые блокируют типичные действия атакующих. Одно из правил специально для BYOVD.

Attack Surface Reduction правило «Block abuse of exploited vulnerable signed drivers» (GUID: 56a863a9-875e-4185-98a7-b882c64b5ce5) может блокировать загрузку известных уязвимых драйверов. Рекомендуется включить в режиме аудита, а затем перевести в блокировку после проверки совместимости.

№4. Мониторинг сервисов и драйверов

• Настроить аудит создания сервисов (Event ID 7045, 4697).

• Мониторить загрузку драйверов через Sysmon (Event ID 6) с автоматической проверкой хэшей по LOLDrivers.
• Внедрить EDR heartbeat-мониторинг с алертом на молчание агента.
• Ограничить права на создание сервисов типа kernel driver — минимизировать число учётных записей с привилегией SeLoadDriverPrivilege.

№5. Принцип наименьших привилегий

BYOVD-атака требует привилегий администратора (для загрузки драйвера) или LOCAL_SERVICE (для CVE-2024-21338). Меньше админов на эндпоинтах — меньше шансов у атакующего загрузить драйвер. Audit и контроль использования привилегированных учётных записей (PAM, JIT-доступ) остаются критически важными.

№6 Проактивный аудит: как находить уязвимые драйверы до атакующих

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

В 2023 году исследователи из TeamT5 представили на HITCON инструмент IOCTLance, который решает именно эту задачу: автоматический поиск уязвимостей в WDM-драйверах без необходимости запускать их на реальной системе. За счёт комбинации символьного выполнения и taint-анализа IOCTLance нашёл 117 ранее неизвестных уязвимостей в 26 драйверах, что привело к назначению 41 CVE — среди затронутых вендоров оказались AMD, Dell, IObit, Microsoft (Visual Studio).

Подход работает так. Инструмент берёт бинарник драйвера, находит в нём IOCTL-обработчики и вместо реальных данных подаёт на вход символьные переменные. Затем прослеживает все пути выполнения кода и проверяет, попадают ли контролируемые пользователем данные в опасные функции: MmMapIoSpace (маппинг физической памяти), ZwOpenProcess без OBJ_FORCE_ACCESS_CHECK (открытие хэндла к произвольному процессу), memcpy с контролируемым размером (переполнение буфера), вызов функции по указателю из input buffer (выполнение произвольного кода в ядре) и ещё пять типов уязвимостей. На выходе — конкретный IOCTL-код, адрес уязвимой инструкции и описание, какие именно поля входного буфера контролирует атакующий.

Почему это применимо на практике? База LOLDrivers.io каталогизирует сотни уязвимых драйверов, но покрывает только те, которые уже кто-то исследовал. Драйвер от условного вендора банковских терминалов или системы контроля доступа может содержать точно такие же баги (произвольное чтение/запись памяти через IOCTL), но никто его не проверял, и в LOLDrivers его нет. Атакующий, который получит этот драйвер, сможет использовать его для BYOVD — а детекты по хэшам не сработают, потому что драйвера нет ни в одной базе.

Заключение

BYOVD — это стандартный этап ransomware-операций, доступный через готовые тулкиты и базы уязвимых драйверов, так как публичные инструменты снизили порог входа до минимума.

Для SOC-команд и detection-инженеров это означает необходимость пересмотра подходов к мониторингу:

• Хэш-детектирование загрузки уязвимых драйверов (LOLDrivers.io) — базовый, обязательный детект.
• Мониторинг создания сервисов типа kernel driver из нетипичных источников.
• Heartbeat-мониторинг EDR-агентов с алертом на молчание.
• Корреляция: файл .sys + сервис + завершение EDR = автоматическая изоляция.
• Технические митигации: HVCI, ASR rules, Microsoft Vulnerable Driver Blocklist.

Если ваша стратегия безопасности начинается и заканчивается на EDR, BYOVD-атака может оставить вас полностью слепыми. Сетевой мониторинг, контроль привилегий, HVCI и проверка живости агентов — надёжнее любого отдельного EDR.

Чек-лист: защита от BYOVD

Оставляю чек-лист — распечатайте и держите рядом.

Предотвращение

☐ HVCI (Memory Integrity) включён на рабочих станциях и серверах.

☐ Microsoft Vulnerable Driver Blocklist актуален.

☐ ASR-правило «Block abuse of exploited vulnerable signed drivers» активно.

☐ SeLoadDriverPrivilege ограничена минимальным числом учётных записей.

☐ MFA на VPN и всех внешних точках входа

Обнаружение

☐ Sysmon установлен, EID 6 собирается без агрессивной фильтрации.

☐ <CheckRevocation/> включён в конфигурации Sysmon.

☐ LOLDrivers-хэши импортированы как lookup-таблица в SIEM

☐ Командная строка логируется в EID 4688 (GPO → Include command line) ☐ Правило на sc.exe create type=kernel в SIEM

☐ Правило на массовое завершение EDR-процессов в SIEM

Контроль

☐ Heartbeat-мониторинг EDR-агентов настроен (алерт при молчании > 5 мин).

☐ Корреляция: файл .sys + сервис + завершение EDR = автоизоляция.

☐ Периодическая проверка целостности ETW-сессий (logman query).

Что спасает нас сегодня от мошенников с поддельными документами? В этой статье мы разобрались, как работают промышленные системы проверки подлинности и как правильно выбирать технологию антифрода.

Как изменились подделки

Раньше мошенники делали физическую подделку — кривые шрифты, неправильное ламинирование оператор в банке почти всегда замечал. Сейчас схема другая: мошенники создают цифровые подделки на базе утекших данных из реальных паспортов и предъявляют их как в онлайн-каналах обслуживания, так и в физических.

Мошенники активно применяют генеративный ИИ. Распространение популярных ИИ-сервисов для генерации изображений сделало фальсификацию документов намного доступнее для мошенников. Без специализированных инструментов сгенерированный паспорт почти нельзя отличить от настоящего. Это позволяет злоумышленникам проходить проверки и получать услуги от лица жертв.

Часть мошенников теперь не тратит время на качество. Они генерируют тысячи подделок и заваливают ими системы банков. Если система недостаточно качественная и пропускает хотя бы 0,1% из них — при тысячах попыток это уже несколько успешных атак. Дальше — кредиты, обнал, SIM-swap для мошенников, для банков — многомиллионные убытки и минус репутация.

Почему разработчикам стало сложнее

1. Всё ушло в онлайн. К концу 2025 года 88,5% финансовых услуг в России оформлялись в цифровом виде. Это означает, что чаще всего клиент предъявляет не физический документ, а его изображение. Система антифрода должна уметь надежно проверять паспорт по одной фотографии, сделанной на телефон.
2. Фото приходят плохие. В отделении паспорт клали на сканер, а при удалённом обслуживании пользователь снимает телефоном: блик от лампы, тень, наклон, смазанность. Если система не справляется с распознаванием и выдает ошибку — пользователь уходит к конкуренту, а бизнес теряет клиента.
3. Добавьте сюда рост трудовой миграции. Рабочие приезжают не только из СНГ, но и из Индии, Китая, Бангладеш и стран Африки. У иностранных паспортов часто другая структура полей и может отсутствовать MRZ. Современная система должна поддерживать более 100 языков и понимать логику документов любого государства.

Какие тренды антифрода в 2026

Тренд 1 — точное сканирование при любых условиях

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

Тренд 2 — работать с разными типами входных данных

Мультимодальные модели, которые одновременно анализируют несколько источников информации, сейчас считаются одним из самых прогрессивных классов нейросетевых моделей, а их рынок в 2025 году оценивали примерно в 2,35 млрд долларов. В прошлом году российские учёные совершили прорыв в мультимодальной форензике. Они представили систему, обученную параллельно работать с изображениями документов в оптическом, ультрафиолетовом и инфракрасном диапазонах, с видеопотоком, текстовыми полями, штрих‑кодами, метаданными, подписями и данными с бесконтактной RFID‑метки, которая есть в загранпаспортах нового образца.

Тренд 3 — защищать от спуфинг-атак

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

Чеклист для разработчика в 2026 году

Вы интегрируете антифрод в код или настраиваете пайплайн верификации? Смотрите на обработку персональных данных — фото и сканов паспортов. OCR уже запускается локально на устройстве пользователя или вашем сервере. Вам не нужны вендоры, которые тянут трафик в свои облака, внешние серверы или краудсорсинг — будут дыры в безопасности данных.

Проверяйте совместимость с отечественным стеком ОС. Если проект идёт под госкомпании или критическую инфраструктуру, вам понадобятся Astra Linux, ALT Linux, РЕД ОС, Эльбрус или ОС Аврора. Требуйте сертификаты совместимости и результаты реальных тестов.

Соберите все критерии — точность распознавания в любых условиях, 600+ проверок, мультимодальность, локальную обработку, совместимость со стеком — и ваш бизнес выдержит реальность 2026 года, а мошенники останутся не у дел.

Технический стек

Блокчейн-инженер

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

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

Unity-разработчик

Unity-разработчики пишут код, который превращает концепцию виртуального мира в рабочее приложение. Они используют язык C# и движок Unity для создания интерактивных пространств — от игр до корпоративных тренажёров и обучающих платформ.

Специалист работает с VR/AR/XR-технологиями, настраивает физику объектов, анимацию персонажей и взаимодействие пользователей с окружением. Он интегрирует блокчейн для работы с NFT, тестирует производительность и оптимизирует приложения под разные устройства. Unity-разработчик создаёт техническую основу, на которой держится весь пользовательский опыт.

Специалист по кибербезопасности

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

Специалист по кибербезопасности анализирует уязвимости в коде, настраивает системы мониторинга, разрабатывает протоколы шифрования и реагирует на инциденты. В его задачи входит защита данных пользователей, блокчейн-кошельков, VR/AR-устройств и серверной части платформы.

Креативные роли

Графический дизайнер

Визуальная составляющая метавселенных влияет на то, как пользователи воспринимают виртуальное пространство и хотят ли они в нём оставаться. Дизайн здесь — часть интерактивного опыта, который формирует первое впечатление и заставляет пользователя остаться.

Графический дизайнер создаёт аватары, интерфейсы, объекты и окружение. Он работает над визуальным стилем метавселенной, подбирает цветовые схемы, разрабатывает текстуры и модели.

UX/UI-дизайнер миров

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

UX/UI-дизайнер миров проектирует удобную навигацию и интерфейсы для 3D-пространств. Он продумывает, как пользователь будет открывать криптокошелёк, просматривать NFT, общаться с другими аватарами или покупать виртуальные товары.

Создатель цифровых активов

Виртуальная экономика держится на цифровых активах — одежде для аватаров, предметах интерьера, аксессуарах, транспорте. Эти объекты пользователи покупают, продают, коллекционируют и используют для самовыражения.

Создатель цифровых активов разрабатывает 3D-модели виртуальных товаров. Он делает одежду и аксессуары для аватаров, предметы для виртуальных домов, уникальные NFT-коллекции. Специалист работает с 3D-редакторами: Blender или Maya, учитывает технические ограничения платформ и настраивает совместимость активов с блокчейном для подтверждения прав собственности.

Геймдизайнер VR-игр

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

Геймдизайнер VR-игр проектирует игровой процесс для виртуальной реальности. Он придумывает механики, создаёт уровни, пишет сценарии, настраивает баланс сложности. Специалист работает с движками Unreal Engine или Unity, использует инструменты для 3D-моделирования и анимации, программирует взаимодействие объектов. Его задача — сделать так, чтобы пользователь был вовлечён и хотел возвращаться.

Управленцы и стратеги

Проджект-менеджер

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

Маркетолог метавселенных

Традиционная реклама в метавселенных не работает. Здесь бренды не покупают баннеры, а создают интерактивный опыт — виртуальные магазины, концерты, игровые события, NFT-коллекции.

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

Менеджер по безопасности

Он добавляет и обновляет политики конфиденциальности, контролирует соблюдение стандартов безопасности, анализирует риски и координирует работу технических специалистов.

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

Какие навыки нужны для работы в метавселенных

Конкретный список зависит от роли, но есть базовые, которые нужны всем:

• Программирование. C# и C++ для разработки на Unity и Unreal Engine. Python нужен для автоматизации, аналитики и работы с машинным обучением. JavaScript и Solidity для создания смарт-контрактов и веб-интеграций.
• 3D-моделирование и анимация. Blender, Maya, Cinema 4D — основные инструменты, чтобы создавать новый мир.
• Блокчейн и криптовалюты. Нужно понимать, как работают децентрализованные системы, NFT и смарт-контракты. Уметь настраивать транзакции, управлять цифровыми активами и сохранять их безопасность.
• Кибербезопасность. Защита данных, активов и устройств VR/AR от взлома и мошенничества.
• UX/UI для 3D-пространств. Вы решаете как пользователь взаимодействует с объектами в VR и как сделать этот процесс удобным.
• Облачные технологии. Виртуальному миру нужна мощная инфраструктура для обработки данных и поддержки тысяч одновременных пользователей.
• ИИ и машинное обучение. Искусственный интеллект для генерации аватаров, создания чат-ботов, персонализации контента и анализа поведения пользователей.
• XR/AR/VR-технологии. Нужно понимать специфику устройств, их ограничения и возможности для погружающего опыта.
• Unity и Unreal Engine. Два основных движка для разработки интерактивных миров. Unity чаще для мобильных VR-приложений и кроссплатформенных проектов, Unreal Engine — для высокобюджетных игр и визуализаций.

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

Если вы хотите освоить конкретные навыки для работы в метавселенных, есть программы, которые дают практическую базу. Например, в Академии ТОП можно пройти курсы по кибербезопасности и сетевым технологиям, разработке на Python, созданию игр на Unity, UX/UI-дизайну или работе с нейросетями. Это варианты для тех, кому нужно структурированное обучение с проектами и обратной связью.

Где искать работу в метавселенных

1. Образовательные платформы Coursera, Labster создают иммерсивные системы обучения. Студенты проводят виртуальные эксперименты, тренируются на симуляторах и ходят на лекции в VR.
2. Крупные игроки — Microsoft, NVIDIA и многие стартапы запускают офисы в метавселенных, проводят встречи в VR и обучают сотрудников на виртуальных тренажёрах.
3. Здравоохранение, аэрокосмическая отрасль, машиностроение. XR-технологии используются для подготовки персонала. Хирурги тренируются на виртуальных пациентах, инженеры изучают сложные механизмы в дополненной реальности.
4. Виртуальные музеи, концерты, выставки и тематические парки переносятся в цифровое пространство. Художники создают NFT-коллекции, музыканты делают концерты для аватаров.
5. Модные бренды представляют виртуальную одежду для аватаров, проводят цифровые показы и открывают шоурумы в метавселенных. NFT-мода становится отдельным рынком.
6. Банки экспериментируют с виртуальными офисами, страховые компании используют VR для обучения клиентов. Криптовалюты и NFT интегрируются в финансовые сервисы.
7. Виртуальная земля и объекты продаются, арендуются и используются для бизнеса. Агентства открывают офисы в метавселенных и проводят виртуальные туры по объектам.

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

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

IT-конференции в России все чаще ассоциируются с дорогими билетами, навязчивым маркетингом и хантингом. Это отталкивает специалистов, которые ищут качественный технический контент и единомышленников.

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

Kuber Community Day — бесплатная независимая конференция, где DevOps-инженеры и архитекторы обмениваются опытом работы с Kubernetes. Мы задумали ее в мае 2025 года и провели уже летом, то есть на организацию нам понадобилось всего два месяца. Мероприятие собрало почти 1 800 участников и стало началом серии регулярных встреч K8s-сообщества как в онлайне, так и в офлайне.

Задача: создать площадку от сообщества для сообщества

Бизнес-задача — консолидировать K8s-сообщество в России через создание открытой некоммерческой площадки для обмена опытом. На момент запуска в стране не хватало мероприятия, которое объединяло бы специалистов по принципу независимости от брендов и спонсоров, где качество контента и сила комьюнити важнее стендов и мерча.

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

Параметры проекта

Срок реализации: два месяца (июнь — июль 2025)

Команда: 10 человек

Формат: гибридный (офлайн + онлайн)

Участники: около 1 800 зарегистрированных (250+ офлайн, 1 500 онлайн)

Спикеры: эксперты из VK, МКБ, Yandex Cloud, Lamoda Tech, «Лаборатории Касперского», «СберТеха», «Инфосистемы Джет», Т-Банк, Luntry и других компаний

Пять отличий от коммерческих конференций

1. Формат от сообщества для сообщества

Программу и доклады формировали эксперты из комьюнити — реальные практики, которые ежедневно работают с Kubernetes. Никаких докладов о продуктах и решениях, рекламы «воды». Только технические кейсы, архитектурные решения и личный опыт. Спикеры выбирались не по известности компании, а по глубине экспертизы и полезности темы для сообщества. Некоторые из них выступали впервые и смогли при этом показать высокий уровень.

2. Полностью бесплатная и доступная

Никаких барьеров для входа: бесплатное участие, без VIP-зон и закрытых сессий для «избранных». Любой специалист мог зарегистрироваться и участвовать онлайн или офлайн. Это сделало конференцию доступной для специалистов из регионов, джунов или студентов, которые обычно не могут позволить себе коммерческие мероприятия. Трансляция велась из обоих залов, а все записи и презентации оперативно были опубликованы в открытом доступе вместо долгого ожидания и платного доступа.

3. Два технических трека разной глубины

Трек «Техно» охватывал практические аспекты работы с K8s: деплой, мониторинг, CI/CD-интеграции, управление конфигурациями. Трек «Хардкор» погружал в глубокую архитектуру кластеров, безопасность, оптимизацию производительности и нестандартные сценарии использования. Участники выбирали уровень в зависимости от опыта и интересов.

4. Независимость и отсутствие хантинга

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

5. Живое сообщество после конференции

Kuber Community Day не закончился финальным докладом. После мероприятия мы запустили Telegram-сообщество, которое органическим путем собрало 600+ участников и стало постоянной площадкой для обмена опытом. Эксперты продолжают обсуждать технические вопросы, делиться решениями проблем и координировать новые встречи. Конференция стала катализатором, а сообщество — её продолжением.

Две главные трудности организации

🔴 Сжатые сроки: два месяца на всё

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

✅ Решение: команда из 10 человек работала по четкому проектному плану с оперативным распределением задач и регулярным контролем статуса. Для более качественного формирования программы, отражения реальной картины рынка и подготовки спикеров был создан программный комитет, в который вошли коллеги из VK, Yandex Cloud, Aenix и «Лаборатории Числитель». Наличие программного комитета обеспечило:

• Экспертность — реальные специалисты оценивали заявки, отсеивали слабые и рекламные доклады, помогали формулировать сильные темы.
• Легитимность — узнаваемые в профессиональной среде люди в составе ПК выступили сильным доказательством того, что контент проходит профессиональный отбор, а площадке можно доверять.

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

🔴 Замена спикеров в процессе

В процессе подготовки возникали случаи, когда спикеры «слетали» по рабочим причинам или из-за изменения планов компаний. Это могло создать дыры в программе и снизить качество контента. Эта проблема характерна для многих мероприятий, но особенно критична при таких сжатых сроках.

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

Результаты: цифры и влияние на комьюнити

Почти 1 800 регистраций за три недели до начала — рынок подтвердил острую потребность в таком событии. Более 250 специалистов участвовали офлайн, 1 500 подключились к онлайн-трансляции. Участники отметили высокий технический уровень докладов и дружелюбную атмосферу без коммерческого давления.

Созданное Telegram-сообщество kuber community собрало с нуля 600+ участников и стало независимой площадкой для свободной коммуникации. Специалисты продолжают обмениваться опытом, обсуждать подходы к контейнеризации и помогать друг другу решать реальные задачи.

Конференция стала катализатором развития K8s-сообщества в России и сформировала основу для системной коммуникации между специалистами. Мероприятие стимулировало распространение знаний о современных подходах к контейнеризации и укрепило технологическую зрелость российского IT-рынка через культуру открытого обмена профессиональным опытом.

Планы развития: от конференции к экосистеме

Kuber Community Day планируется сделать ежегодным событием с сохранением открытости и независимого формата. В планах масштабировать программу, расширить состав программного комитета и привлечь новые компании к организации без потери духа «от сообщества для сообщества».

Параллельно мы проводим дополнительные активности для поддержания постоянной коммуникации сообщества:

• KuBeer Talks — камерные офлайн-встречи в неформальной обстановке с 3-4 докладами и живым общением;
• Kuber Community Webinar — регулярные вебинары с экспертами вокруг Kubernetes и смежных технологий.

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

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

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

И мы это сделали. Сообщество оказалось невероятно отзывчивым — люди абсолютно безвозмездно вкладывались в общее дело. Уже через две недели был сформирован программный комитет, включающий экспертов из VK, Yandex Cloud, Aenix и «Штурвала», а чуть больше, чем через месяц, и программа — 27 сильных спикеров, 15 докладов, воркшопы и несколько круглых столов.

В итоге мы получили массу положительных отзывов, 1 800 участников суммарно офлайн и онлайн, огромное количество технического контента и эмоций.

Я уверен, что индустрии нужны такие мероприятия, и мы сделаем все, чтобы они появлялись чаще и стали постоянной практикой.

Kuber Community Day — редкий пример конференции, на которой действительно чувствуешь дух комьюнити, а не просто проходишь мимо очередной витрины брендов. Здесь много живого общения, практики и честных разговоров про реальный продакшен: что ломается, где болит, как закрывать дыры в безопасности и почему «идеальные архитектуры» из презентаций не всегда переживают понедельник.

Формат получился очень живым. Вместо абстрактных рассуждений про «облака» — хардкорные кейсы, реальные сценарии эксплуатации Kubernetes и обсуждение решений, которые уже кто-то попробовал (иногда успешно, иногда — не очень).

Уникальность ивента в его фокусе: это конференция строго про Kubernetes, но при этом с разными углами зрения. Хардкор, Security, GitOps, мультитенантность — каждый может найти свой трек. И при этом большой акцент на офлайн-нетворкинге, стендап и нормальное человеческое общение, где говорят не только про технологии, но и про то, как с ними живут команды и бизнес.

Реклама. ООО «Лаборатория Числитель», ИНН 9731042193, erid: 2W5zFHmtsAy

Угрозы в цифровом пространстве реальны и многообразны. Это ситуации, с которыми ребенок может столкнуться напрямую:

• Кража личных данных и денег. Мошенники могут выманить у ребенка или через его аккаунт конфиденциальную информацию родителей.
• Кибербуллинг (травля в сети). Оскорбительные сообщения, распространение слухов или неприятных фотографий в чатах и соцсетях.
• Встречи с опасным контентом. Столкновение с материалами, предназначенными для взрослых, или с пропагандой деструктивного поведения.
• Взлом аккаунтов. Потеря доступа к своим страницам в соцсетях, игровым аккаунтам из-за слабых паролей или хитрости злоумышленников.

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

Также приглашаем на наш онлайн-курс «Компьютерная грамотность для детей», где ребенок научится основам безопасности в интернете, работе с ПК, созданию презентаций и документов. Первый урок курса можно пройти бесплатно, записаться на него можно по ссылке.

Личные данные — чем нельзя делиться?

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

Что относится к личным данным:

• Базовые идентификаторы. Имя и фамилия, точный возраст, номер телефона, домашний адрес, номер школы и класс.
• Данные документов. Фотографии или сканы паспорта, свидетельства о рождении, полисов, водительских прав родителей. Даже частично видимые в кадре номера могут быть использованы.
• Информация о местоположении (геометки). В некоторых приложениях есть функция, автоматически добавляющая к фотографии или сообщению название города, района или конкретного места (кафе, парка). Включенная геолокация также может добавлять в соцсети или мессенджеры информацию, где вы находитесь.
• Распорядок дня и привычки. Информация о том, в какое время ребенок обычно один дома, по какому маршруту ходит в школу, какие кружки посещает и когда родители работают до позднего вечера.

Научите ребенка: «незнакомец в сети = незнакомец на улице». Эта аналогия важна для понимания. В реальной жизни ребенок не станет рассказывать незнакомому человеку на остановке свой адрес, график дня или показывать документы. Ровно с такой же осторожностью нужно вести себя в интернете. Человек по ту сторону экрана, даже если он представляется ровесником из другого города или добрым другом, без видеосвязи и личной встречи остается незнакомцем. Его настоящие имя, возраст и намерения неизвестны.

Почему нельзя публиковать определенную информацию:

1. Фотографии билетов (авиа, железнодорожных, на концерт). На штрих-коде или QR-коде билета часто закодированы персональные данные (ФИО, иногда паспортные данные). Эту информацию можно считать со снимка. Злоумышленник может использовать эти данные для мошеннических действий или, например, чтобы аннулировать или переоформить билет.
2. Фотографии документов. Это прямой ключ к краже личности. С помощью данных документа мошенники могут попытаться оформить кредит, получить доступ к аккаунтам или совершить другие действия от вашего имени.
3. Фотографии дома, школы, машины родителей с номерами. Такие снимки делают ребенка и его семью «видимыми» и узнаваемыми в реальном мире. В сочетании с информацией о распорядке дня это создает риск. Фотография подъезда или окна своей комнаты с видом из него — это конкретная привязка к месту жительства.
4. Геометки в реальном времени. Публикация фотографии из парка с отметкой «Гуляю сейчас здесь» или регулярный check-in в одной и той же спортивной секции показывает не только место, но и привычки. Это информация, которой без необходимости не нужно делиться с широким кругом людей.

Введите правило безопасности в сети интернет для ребенка: прежде чем что-то опубликовать — фотографию, пост или комментарий с личной информацией — нужно спросить себя: «я готов(а), чтобы это увидел и узнал любой человек, в том числе незнакомый?». Если ответ «нет» или «не уверен(а)», публиковать не стоит. Лучшая тактика — делиться такой информацией только в закрытых переписках с проверенными друзьями и всегда ставить в известность родителей, если кто-то в сети настойчиво просит личные данные.

Создаем и храним пароли

Пароль — это ключ, который защищает цифровую информацию: аккаунты в соцсетях, почту, игровые профили и личные переписки. От его надежности напрямую зависит, останется ли эта информация приватной, а значит и безопасность ребенка в интернете в целом. Представьте, что пароль — это ключ от квартиры. Простой и предсказуемый пароль, например, «12345» или «qwerty», — это все равно что оставить ключ в двери или на видном месте. Им сможет воспользоваться любой, кто просто попробует его повернуть.

Надежный пароль — основа кибербезопасности не только детей, но и взрослых

Как создать надежный пароль, который будет сложно подобрать как человеку, так и специальной программе:

1. Используйте длинную фразу (пассфразу). Чем длиннее пароль, тем он надежнее. Вместо короткого слова используйте несколько слов, которые просто запомнить именно вам. Например: «НашКотЛюбитСыр123». Это уже значительно лучше, чем просто «кот». Еще один прием — взять первые буквы слов и знаки препинания из пассфразы. Так из фразы «Я_Учусь_В_5_Б_,_А_Моя_Сестра_В_9_Д_!» получаем пароль «ЯУВ5Б,АМСВ9Д!» — он выглядит бессмысленным набором символов, но запомнить его легко.
2. Усложняйте конструкцию. Добавьте к своей фразе заглавные буквы, цифры и специальные символы (например, !, @, #, $, %). Превратите простую фразу в сложный код. Пример: «Кот!Любит#Сыр123».
3. Избегайте очевидного. Не используйте:

• личную информацию (имя, фамилию, дату рождения, имя питомца).
• простые последовательности букв и цифр на клавиатуре («123456», «qwerty»).
• одно и то же слово, повторенное несколько раз.

Что такое двухфакторная аутентификация (2FA)?

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

Как работает 2FA:

1. Вы вводите логин и пароль на сайте (это первый фактор — пароль, который вы знаете).
2. Сайт запрашивает второй код. Этот код генерируется в мобильном приложении (например, Google Authenticator или Яндекс.Ключ) или приходит в SMS (менее безопасный вариант, но он лучше, чем ничего).
3. Вы вводите этот одноразовый код (это второй фактор).

Даже если кто-то узнает пароль, без доступа к вашему телефону он не сможет войти в аккаунт. Включить 2FA можно в настройках безопасности большинства важных сервисов: почты, соцсетей, игровых платформ.

Почему один пароль для всего — плохая идея?

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

Поэтому следующее правило кибербезопасности для детей: для каждого важного аккаунта (особенно для почты, так как это ключ ко всем остальным сервисам) должен быть свой уникальный и надежный пароль. Если запомнить много паролей сложно, установите менеджер паролей — специальную защищенную программу, которая хранит все пароли в зашифрованном виде под одним главным «мастер-паролем».

Что такое фишинг?

Фишинг — это один из самых распространенных методов обмана в интернете. Его цель — заставить человека добровольно раскрыть свои личные данные: логины, пароли, данные банковской карты. Название происходит от английского слова «fishing» (рыбалка), и принцип действительно похож: злоумышленники забрасывают «удочку» — поддельное сообщение, — надеясь, что кто-то «клюнет».

Если раньше мошенники рассылали истории про принцев из Саудовской Аравии, которым срочно нужна помощь в обмен на деньги, то сегодня они притворяются службой поддержки известной игры, популярной социальной сети, онлайн-магазином или даже нашим другом или полицейским. Форма изменилась, но суть осталась прежней: нас обманом выманивают, чтобы подцепить на «крючок».

Как отличить фишинг от настоящего сообщения?

Есть несколько четких признаков, которые с высокой вероятностью указывают на попытку обмана. Научившись их замечать, ребенок сможет вовремя остановиться — важный навык кибербезопасности:

1. Срочность и давление. Сообщение создает искусственное чувство паники или жадности: «Ваш аккаунт будет удален в течение часа!», «Вы выиграли приз! Кликните сюда, чтобы получить его сейчас, пока предложение действительно!», «Ваша карта заблокирована! Немедленно подтвердите данные». Цель — заставить действовать быстро, не раздумывая и не проверяя информацию.
2. Ошибки в тексте. Официальные письма от крупных компаний тщательно проверяются. Грамматические ошибки, странные формулировки, неправильные названия сервисов — явный признак подделки. Например, письмо якобы от «VKотнтаке» или «Steanm Community».
3. Подозрительные ссылки. Это самая опасная часть фишингового сообщения. Ссылка может выглядеть почти как настоящая, но при внимательном рассмотрении можно заметить подмену. Например:

• vk-подарки.ru вместо официального vk.com
• steamcommunity-gifts.com вместо steamcommunity.com
• ссылка, замаскированная под кнопку «Проверить» или «Получить подарок».
• Важное правило кибербезопасности для детей: всегда наводить курсор на ссылку (не кликая), чтобы увидеть ее настоящий адрес во всплывающей подсказке в углу браузера!

1. Запрос конфиденциальных данных. Ни одна настоящая служба поддержки не будет писать вам в личные сообщения с просьбой прислать пароль, полный номер карты, CVV-код (три цифры на обороте) или код из SMS. Для решения проблем у них есть официальные, защищенные формы внутри вашего личного кабинета.

Что делать при получении подозрительного сообщения?

1. Не кликать — самое главное правило безопасности в интернете и для детей, и для взрослых. Не нажимать на ссылки и не скачивать вложения (файлы, картинки) из такого сообщения. Даже простой клик может привести на вредоносный сайт или запустить скрытую загрузку вируса. Кстати, многие «бесплатные» PDF-мануалы, которые в интернете предлагают скачать на каждом шагу, тоже содержат вредоносный код, предназначенный для кражи данных.
2. Не отвечать. Не вступать в диалог, не пытаться доказать мошеннику, что вы его раскусили, и тем более не отправлять запрошенные данные. Любой ответ сигнализирует, что ваш аккаунт активен и с вами можно продолжать работу.
3. Ребенок должен рассказать взрослым. Если сообщение вызывает сомнения, самое разумное — немедленно показать его родителю или другому доверенному взрослому. Вместе вы проверите отправителя, и если, например, выяснится, что взломан аккаунт друга, вы сможете оперативно связаться с ним и предупредить.

Умение распознавать фишинг — это навык критического мышления. Он учит не доверять слепо информации, а всегда проверять ее источник и задаваться вопросом: «Зачем мне это сообщают и чего от меня хотят?».

Общение онлайн и личные границы

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

Что такое кибербуллинг и как правильно реагировать на него?

Кибербуллинг — это систематическая травля, запугивание, унижение или преследование человека с использованием цифровых технологий (соцсетей, мессенджеров, игровых чатов). Он опасен тем, что может не прекращаться круглосуточно, а материалы (оскорбительные сообщения, фотографии) быстро распространяются и сложно удаляются.

Алгоритм действий для ребенка, столкнувшегося с травлей:

1. Не отвечать и не вступать в перепалку. Цель обидчика — вызвать реакцию, вывести из равновесия, получить эмоции. Безответность лишает его этой цели. Нельзя поддаваться на провокации.
2. Сделать скриншот. Необходимо сохранить доказательства: сделать снимок экрана с оскорбительным сообщением, записью в чате или комментарием. Это важно для дальнейших действий. Скриншот — это фиксация факта.
3. Использовать технические инструменты блокировки.

• Заблокировать обидчика в соцсети или мессенджере. Это немедленно прекратит прямые атаки.
• Пожаловаться администрации платформы на пользователя или конкретный пост/сообщение, прикрепив скриншот. Модераторы обязаны рассматривать такие жалобы и могут ограничить доступ нарушителю.

1. Рассказать родителю или доверенному взрослому. Это самый важный шаг. Ребенку может быть стыдно или страшно говорить о травле, но такая проблема всегда требует вмешательства. Нужно объяснить, что обращение за помощью — это разумный поступок и признак силы, а не слабости. Взрослый (родитель, учитель) сможет эмоционально поддержать, помочь с настройками приватности и, при необходимости, обратиться в правоохранительные органы.

Правила безопасного общения в интернете для детей

Основные правила безопасности в интернете при общении онлайн:

• Относись к другим так, как хочешь, чтобы относились к тебе. Критика должна быть конструктивной, а шутки — добрыми и не обидными.
• Нет оскорблениям, унижениям и троллингу. Троллинг — это намеренные провокации, насмешки, размещение гневных или нелепых сообщений с целью вызвать конфликт. Лучшая тактика — не кормить тролля.
• Уважай чужое мнение и приватность. Нельзя распространять личные переписки, фотографии или секреты других людей без их согласия.

Конфиденциальность переписки

Личная переписка ребенка тоже должна подчиняться правилам кибербезопасности:

1. Постоянство цифровой информации. То, что отправлено в сообщении, почти невозможно полностью отозвать или удалить у получателя. Скриншот переписки может быть использован против отправителя позже, если отношения с собеседником испортятся.
2. Круг доверия. Очень личную информацию (семейные проблемы, интимные фото или переписки, пароли) нельзя отправлять даже близким друзьям в цифровом виде. Технический сбой, потеря телефона, взлом аккаунта друга — все это может привести к утечке данных.
3. Введите правило безопасности в интернете для ребенка: Если информация слишком личная, и ее огласка может причинить боль или вред, ее не стоит доверять цифровому каналу. Лучше обсудить такие темы при личной встрече или по телефону. В переписке стоит делиться только тем, чем ты спокойно готов поделиться публично.

Самые распространенные киберугрозы

Помимо общих правил кибербезопасности, детям полезно знать и конкретные виды угроз, с которыми можно столкнуться в сети. Это знание помогает быстрее распознать опасность и правильно среагировать.

«Бесплатный» сыр в мышеловке: вирусы и вредоносный софт

Ребенок ищет способы бесплатно получить платную игру, программу, внутриигровую валюту или взломанный аккаунт. Он переходит на сомнительный сайт или скачивает файл из непроверенного источника. Вместе с желаемым контентом он получает вредоносную программу. Также вирус может прийти в виде вложения в сообщении от взломанного аккаунта друга («Посмотри это видео!»).

Вредоносная программа может украсть сохраненные пароли, повредить файлы на компьютере, показывать навязчивую рекламу или использовать устройство для скрытых задач (например, майнинг криптовалюты).

Решение:

• Установить и обновлять антивирус. Объясните ребенку, что для безопасности в сети интернет антивирус обязателен. Важно, чтобы он был лицензионным и регулярно обновлялся.
• Четкий запрет на установку ПО без согласия взрослого. Ребенок должен спрашивать разрешения у родителей перед установкой любой новой программы или игры, особенно если источник вызывает сомнения.
• Использовать легальный контент. Объясните важность уважения к труду разработчиков. Платформы с официальными играми и программами (например, Steam, официальные магазины приложений) безопаснее пиратских сайтов.

«Ты выиграл …!»: ловушки мошенников

Это разновидность фишинга, ориентированная на детскую аудиторию и ее интересы. Сценарии могут быть разными:

• Фейковые конкурсы от блогеров или игр: «Поздравляем! Ты выиграл новый iPhone в розыгрыше! Перейди по ссылке и введи данные карты родителей для подтверждения доставки».
• Просьба о помощи от «друга». Мошенник пишет со взломанного аккаунта одноклассника: «Срочно! У меня проблемы, одолжи 500 рублей на карту, завтра отдам». Или просит передать код из SMS.
• Фейковые покупки и продажи. Предложение купить редкий игровой предмет по очень низкой цене или, наоборот, просьба «временно» передать дорогой аккаунт для «прокачки».

Решение:

• «Бесплатного не бывает» — это еще одно важное правило безопасности детей в сети интернет. Любое неожиданное супервыгодное предложение, особенно с просьбой оплатить «доставку» или «комиссию», — это обман.
• Обязательная проверка информации. Если друг просит деньги, нужно связаться с ним другим способом (позвонить, встретиться) и уточнить.
• Немедленное обращение к взрослому. Любое предложение, связанное с деньгами, подарками или передачей данных аккаунта, нужно сразу обсудить с родителями.

Цифровой след — это навсегда

Все, что публикуется в интернете — фото, видео, комментарии, лайки, — формирует цифровую репутацию. Многие не понимают, что информацию, которая попала в интернет, удалить почти невозможно:

• Скриншоты и перепосты. Даже если ребенок удалил опрометчивый пост или фото, их могли уже сохранить (сделать скриншот) и распространить дальше.
• «Удаление» не равно полному стиранию. Удаленный контент может сохраняться в кэше поисковых систем, на серверах соцсети или в веб-архивах.

Решение:

• Объясните ребенку важный принцип безопасности в интернете: «Выложил — значит, показал всему миру». Перед публикацией нужно спросить себя: «Я буду не против, если это увидят мои родители, учителя или я сам через 5-10-15 лет?».
• Продуманность контента. Стоит избегать публикации откровенных, смущающих или агрессивных материалов. Цифровая репутация может повлиять на поступление в вуз или прием на работу в будущем.

Троллинг и буллинг в интернете

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

Решение:

• Не кормить тролля ответами.
• Сохранить все доказательства.
• Заблокировать обидчика во всех соцсетях и чатах.
• Обязательно сообщить родителям или школьному психологу. Важно, чтобы реакцией родителей была поддержка и совместный поиск решения, а не запрет интернета (ведь в этом случае будет наказана жертва агрессии).

Опасные знакомства: анонимность как маска

Злоумышленники могут создавать фейковые аккаунты, выдавая себя за сверстников, чтобы войти в доверие. Они используют общие интересы (игры, музыка), проявляют внимание и сочувствие, а затем постепенно:

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

Решение:

• Введите для ребенка жесткое правило безопасности в интернете: общаться как с друзьями можно только с теми, кого лично знаешь в реальной жизни. Друзья друзей или «хорошие парни из другого города» — это незнакомцы.
• Абсолютный запрет на личные встречи с интернет-знакомыми без разрешения и сопровождения родителей. Никаких исключений.
• Открытый диалог с ребенком: он должен знать, что может прийти к вам с любой проблемой (например, «меня шантажируют из-за фото»), не боясь осуждения, и вместе вы найдете выход, вплоть до обращения в полицию.

Реклама. Рекламодатель ООО «Пиксель.Стади», ИНН 5074078988, erid: 2W5zFK2WjKn

Под видом VPN и инструментов приватности, они собирали и передавали злоумышленникам полные диалоги пользователей с ChatGPT, Gemini, Claude, Copilot, Perplexity, Grok и другими ИИ-платформами.

По оценке специалистов, от инцидента пострадали более 8 млн пользователей. Все они устанавливали расширения, содержащие одинаковый вредоносный код.

Главный виновник — Urban VPN

Ключевым примером стало расширение Urban VPN Proxy. У него более 6 млн установок в Chrome, высокий рейтинг (4,7 звезды) и даже статус Google Featured, который создавал ощущение надежности.

Однако исследование показало обратное: вредоносный код присутствует не только в Urban VPN, но и как минимум в семи других расширениях того же издателя.

Среди них — 1ClickVPN Proxy, Urban Browser Guard и Urban Ad Blocker. Все они распространялись через официальные магазины браузеров.

Как именно воровали диалоги с ИИ

Механизм оказался технически простым и крайне эффективным. Расширения внедряли исполняемый скрипт прямо в страницы ИИ-сервисов.

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

• все запросы пользователя;
• все ответы ИИ;
• ID диалогов и сессий;
• временные метки и служебные метаданные.

После этого данные сжимались и отправлялись на серверы Urban VPN.

Сбор информации происходил постоянно, вне зависимости от того, включен VPN или нет.

С какого момента данные скомпрометированы

По данным исследователей, сбор данных был активен начиная с Urban VPN версии 5.5.0, выпущенной 9 июля 2025 года. Это означает, что все диалоги с ИИ, созданные после этой даты, следует считать скомпрометированными.

Urban VPN управляется компанией Urban Cyber Security Inc., связанной с брокером данных BiScience. По имеющейся информации, собранные диалоги продавались для маркетинговой аналитики.

Что делать пользователям прямо сейчас

Эксперты настоятельно рекомендуют немедленно удалить все упомянутые расширения и исходить из того, что переписки с ИИ-платформами могли быть перехвачены.

Инцидент также поднимает более широкий вопрос: даже расширения с высоким рейтингом и отметкой Google не гарантируют безопасность. Если расширение не критически необходимо — от него лучше отказаться.

До тех пор, пока не появляется Он. Вирус, троян, червь, шпионский софт. Или просто подозрительный процесс, пожирающий ресурсы. Сразу возникают вопросы: можно ли полагаться на встроенную защиту или стоит установить специализированное ПО?

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

Антивирус 2025: цифровой мертвец или живой организм?

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

Windows Defender, который вы иногда отключаете, — это уже не та незаметная утилита из Windows 7. Это сложный EDR-агент, который по умолчанию имеет доступ к вашей памяти, сетевой активности и всем процессам.

Gatekeeper в macOS — это тоже форма антивируса, просто работающая на принципах whitelist’а и санирования приложений из App Store. Вопрос не в том, «есть ли у вас антивирус», а в том, насколько глубоко вы понимаете ту защиту, которая уже работает.

Ландшафт угроз изменился радикально. Раньше злоумышленники хотели «сломать систему». Сегодня их цель — оставаться в системе как можно дольше, красть данные, использовать ресурсы. Им ваш синий экран не нужен. Им нужны ваша тишина и покой.

Миф 1. «Мой Linux / Mac слишком безопасен для вирусов»

Священная война между фанатами операционных систем давно перешла в область безопасности. Но правда в том, что ОС — это просто платформа. Уязвимости есть везде. Атаки сместились с уровня операционной системы на уровень приложений и цепочек поставок (supply chain).

Ваш Ubuntu не подхватит классический вирус-шифровальщик, написанный для Windows. Но он с радостью выполнит майнер, вшитый в библиотеку, которую вы установили через pip install --user. Или скрипт, который сольет ваши SSH-ключи из ~/.ssh/. Злоумышленникам сегодня не нужен root. Им нужен ваш пользователь, который имеет доступ к коду, репозиториям, облачным ключам.

• Реальность. Атаки на репозитории открытого ПО стали массовыми. Ежегодный отчёт компании Sonatype о состоянии программного обеспечения за 2024 год показывает, что за предыдущий год было обнаружено 512 847 новых вредоносных пакетов, что означает рост на 156%. Вы делаете npm install и запускаете потенциально вредоносный код с правами вашего пользователя.
• Что делать. Перестать надеяться на магическую неуязвимость ОС. Использовать принцип наименьших привилегий на практике. Запускать подозрительный код в изолированных средах: Docker-контейнерах, виртуальных машинах. Мониторить исходящий сетевой трафик на предмет аномалий. Инструменты вроде lynis для Linux или Little Snitch для Mac — это не антивирусы в классическом понимании, но они выполняют ту же защитную функцию: контролируют всё, что происходит в системе.

Миф 2. «Встроенного защитника Windows / Gatekeeper на Mac достаточно»

Самоуспокоенность — главный враг безопасности. Да, встроенные защитники стали невероятно мощными. Они используют ML-модели, поведенческий анализ и имеют глубокую интеграцию с ядром системы. Но их основная цель — защитить среднестатистического пользователя от массовых угроз. Это основная, но не полноценная платформа защиты (EPP).

Представьте себе целенаправленную атаку (targeted attack). Злоумышленники используют кастомный вредонос, написанный специально для компаний вашего профиля. Он не распространяется в дикой природе, его нет в базах. Он использует технику «живи за счёт земли» (Living-off-the-Land), маскируясь под легитимные процессы вроде ps.exe или wmic.exe.

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

• Реальность. Независимая тестирующая организация AV-Comparatives в своих отчётах за 2024 год регулярно демонстрирует, что Windows Defender обеспечивает стабильную защиту против популярных угроз. Однако в тестах на защиту от целенаправленных атак и сложных zero-day угроз его показатели могут быть ниже, чем у коммерческих EDR-решений от CrowdStrike или SentinelOne.
• Что делать. Для домашнего ПК, на котором вы сёрфите в интернете и работаете с документами, Defender почти достаточное решение. Для рабочей станции разработчика, системного администратора или любого сотрудника, имеющего доступ к критической инфраструктуре, этого мало. Необходимо слоить защиту. Defender — это базовый, но обязательный слой. Поверх него должен идти более продвинутый агент, способный к поведенческому анализу и отслеживанию цепочек атаки.

Миф 3. «Антивирус съедает все ресурсы и тормозит систему»

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

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

Ресурсоёмкие операции, такие как глубокий статический анализ подозрительного файла с помощью тяжёлой ML-модели, часто вынесены в облако. Локальный агент лишь собирает телеметрию (метаданные, образцы памяти) и отправляет их на сервер для принятия решения.

• Реальность. Да, антивирусный агент создаёт дополнительную нагрузку. Но в 2025 году эта нагрузка для качественных продуктов редко превышает 2-5% в штатном режиме. Проблемы могут возникать в пиковых случаях: компиляция ядра Linux, работа с большими базами данных, запуск виртуальных машин. Именно для этого существуют детальные настройки исключений.
• Что делать. Изучать тесты производительности от организаций вроде AV-Comparatives или SE Labs. Грамотно настраивать исключения. Вносить в «белый список» папки с исходным кодом (src, node_modules, .git), директории виртуальных машин, бинарники компиляторов. Современный антивирус — про тонкую настройку под свой рабочий процесс.

Миф 4. «Мне хватает здравого смысла: не ходить по сомнительным ссылкам»

Это самый опасный миф. Он основан на вере в то, что фишинг — удел наивных пользователей. Реальность такова, что социальная инженерия стала оружием массового поражения. Речь не о письмах с заголовком «Вы выиграли iPhone!».

Речь о фишинге высшего пилотажа. О письме, которое приходит на вашу корпоративную почту от имени «отдела DevOps» с ссылкой на «критическое обновление» для вашего CI/CD-пайплайна. Письмо идеально стилизовано, содержит ваше настоящее имя и ссылается на реальных коллег.

Сайт, на который вы попадаете, — клон страницы вашего корпоративного SSO (VK Teams, Azure AD). Вы вводите логин и пароль. На этом всё. Ваша учетная запись скомпрометирована. Осторожность оказалась бесполезной — атака была спланирована и нацелена лично на вас или вашу компанию.

• Реальность. Согласно отчету Verizon Data Breach Investigations Report 2024, основная масса нарушений (68%) связана с человеческим фактором, включая фишинг и претекстинг (целенаправленная атака с созданием легенды для жертвы). При этом фишинг выступает первоначальным вектором атаки в 15% нарушений, а претекстинг остаётся главной тактикой в инцидентах социальной инженерии. Проблема не в глупости, а в человеческой психологии и информационном перегрузе.
• Что делать. Принять, что человек — самое слабое звено в цепи безопасности. Нужны технические контрмеры. Антивирус/EDR в этой схеме выступает последним рубежом обороны. Он не помешает вам ввести пароль на фишинговом сайте. Но он может обнаружить и заблокировать вредоносную полезную нагрузку (payload), которая скачается и запустится уже после компрометации ваших учётных данных. Обязательно используйте аппаратные ключи или приложения для двухфакторной аутентификации (2FA) везде, где это возможно.

Миф 5. «Антивирусы бессильны против zero-day и файл-лесс атак»

Это утверждение верно, если говорить об антивирусе образца 2010 года, который только и делал, что сравнивал MD5-хеши. Современные платформы защиты конечных точек (EPP/EDR) работают иначе. Они ищут не известные угрозы, а подозрительное поведение.

Файл-лесс атака — это когда вредоносный код живёт только в оперативной памяти. Да, файла нет. Но есть аномальная цепочка событий. Процесс powershell.exe (легитимный) неожиданно запускает rundll32.exe для выполнения кода в памяти, который затем пытается отключить защиту через изменение реестра и установить постоянность (persistence). EDR видит не три отдельных безобидных процесса, а одну цельную картину атаки, соответствующую известным тактикам злоумышленников.

• Реальность. Современные системы ориентируются на фреймворки вроде MITRE ATT&CK, которые описывают сотни тактик и техник, используемых хакерами. Антивирус 2025 года — это, по сути, реализация этого фреймворка в виде работающего агента. Он анализирует телеметрию и ищет совпадения с известными паттернами поведения, а не с сигнатурами файлов.
• Что делать. При выборе решения смотреть не на громкое название «антивирус», а на его возможности. Есть ли у него EDR? Интегрируется ли он с MITRE ATT&CK? Есть ли возможность расследования инцидентов (forensics) по собранной телеметрии? Использует ли он песочницу для детонации подозрительных файлов? Ответы на эти вопросы гораздо важнее, чем размер сигнатурной базы.

Миф 6. «Антивирусные компании сами создают вирусы, чтобы был спрос»

Конспирологическая классика. У этого мифа нет никаких доказательств. Реальная экономика угроз гораздо прозаичнее и страшнее.

Киберпреступность — это гигантская индустрия с годовым оборотом в триллионы долларов. Работают модели «ransomware-as-a-service», есть полноценные техподдержки для жертв шифровальщиков, действуют целые корпорации вымогателей. Им не нужно помогать антивирусным компаниям — и так хватает работы.

Более того, антивирусные компании — одни из главных целей для хакеров. Взломав лабораторию такого вендора, можно получить доступ к его детектам и технологиям, чтобы затем усовершенствовать своё вредоносное ПО.

• Реальность. Бизнес-модель легальных антивирусных компаний строится на подписках (SaaS). Репутация — их главный актив. Обнаруженный сговор с создателями вирусов мгновенно уничтожит бизнес и приведёт к колоссальным судебным искам. Гораздо проще и выгоднее честно бороться с реальными угрозами, которых более чем достаточно.
• Что делать. Оценивать вендоров по их открытости. Участвуют ли они в независимых тестах? Публикуют ли исследования об обнаруженных угрозах (threat intelligence reports)? Как быстро реагируют на новые образцы вредоносных программ? Прозрачность — лучший ответ на конспирологические теории.

Миф 7. «Ложные срабатывания (false positives) сводят на нет всю пользу»

Это миф лишь отчасти, поскольку проблема ложных срабатываний действительно существует. Ваш собственный скрипт, отладочный бинарник или легитимная портативная утилита внезапно помечаются как «троян» или «шпионское ПО» и отправляются в карантин. Работа встаёт.

Причина в агрессивности эвристических и поведенческих анализаторов. Антивирус видит, что ваша программа, написанная на Go, упакована статически и при запуске пытается установить сетевое соединение. Это поведение совпадает с паттерном ботнета. Происходит срабатывание.

• Реальность. Баланс между безопасностью и удобством — ключевая проблема всех систем защиты. Слишком агрессивный антивирус будет мешать работе. Слишком слабый — пропустит угрозу. Исследование, проведённое при участии IBM в 2023 году, показало, что специалисты по безопасности тратят примерно треть рабочего дня на расследование ложных или маловажных оповещений, что в пересчёте на команду составляет десятки часов в месяц.
• Что делать. Активно использовать функции whitelist. Подписывать свои собственные приложения цифровыми сертификатами (code signing). Настраивать политики исключений для доверенных папок разработки. Работать с вендором: отправлять ложно заблокированные файлы на анализ. Часто после такого анализа следующий апдейт антивируса уже не будет считать ваш файл вредоносным.

Ставить или не ставить?

В 2025 году вопрос «ставить или не ставить антивирус» бессмыслен. Почти у всех он уже есть, просто в разной форме. Правильный вопрос: «Достаточен ли мой текущий уровень защиты конечных точек для моих рисков?».

Рекомендации следующие:

• Для рядового пользователя / студента. Агрессивный режим Windows Defender/Security Center + современный браузер с антифишингом + блокировщик рекламы + здравый смысл = хороший базовый уровень. Сторонний антивирус — опционально, для душевного спокойствия.
• Для разработчика / IT-специалиста. Встроенный защитник — это только начало. Обязателен более продвинутый агент (например, из бесплатных — Comodo Internet Security с включенным HIPS, из платных — решения с EDR типа Kaspersky Endpoint Security или Dr.Web Security Space). Жёсткий файрвол. Обязательное использование песочниц или контейнеров для тестирования подозрительного кода. Сканирование зависимостей (SCA) в своих проектах.
• Для корпоративной среды. Тут без вариантов. Нужна полноценная платформа EPP/EDR, интегрированная с SIEM и SOC. Антивирусная составляющая — один из ключевых сенсоров в этой системе, отвечающий за сбор телеметрии и блокировку на ранних стадиях атаки.

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

Сказанное подтверждает Евгений Касперский:

«Я твёрдо уверен, что само понятие «кибербезопасность» в скором времени себя изживет, а на замену ему придёт концепция “кибериммунитета”».

За последние годы атаки типа DDoS (Distributed Denial of Service) стали не просто вопросом «когда», а практически неизбежностью для многих компаний. Специалисты отмечают: «для организаций с высокой видимостью уже не вопрос если, а когда вас атакуют».

Главные изменения:

• Доступность инструментария «DDoS-as-a-Service» делает возможными атаки даже с небольшими знаниями.
• Атаки становятся быстрее, изощреннее, и все чаще выполняются автоматически. Например, могут запустить миллионы запросов за несколько минут – и даже прежде чем мониторинг сработает.
• Атакующие все чаще обходят простые фильтры: меняют URL, заголовки, куки, используют бот-сети с огромным географическим разбросом.
• Рост объемов: по данным Cloudflare, крупные атаки выросли экспоненциально за последние десять лет. Например, битрейт (Gbps) вырос с сотен Gbps до 5.6 Tbps к 2025 году.

Эти изменения обуславливают, почему устаревшие методы защиты уже не работают или работают слабо.

Почему традиционные решения уступают

Если раньше меры ограничивались фаерволами, CDN и простыми лимитами, то сегодня этого недостаточно. CDN или фаервол часто настроены по-умолчанию и дают лишь частичную защиту.

Атаки перешли с сетевого уровня на уровень приложений (Layer 7) – где они влияют на веб-сервисы и API, которые генерируют ключевой доход

Ключевые уязвимости:

• Блокировка по IP/ГЕО становится бессильной, когда источники атак меняются динамически.
• Статические правила (лимиты, капчи) не успевают реагировать на автоматизированные, быстрые атаки.
• Отслеживание только трафика без анализа поведения – позволяет атакам «проскальзывать» через кэши и защитные механизмы.

Современные подходы к защите в 2025 году

Как должна выглядеть эффективная защита от DDoS сегодня? Вот основные принципы:

1. Многоуровневая стратегия: защита должна быть на уровне edge (CDN), приложения и поведения. Например, скрытие исходного сервера, лимиты не только на динамические запросы, но и на кэш-контент; специальные правила против «cache-busting».
2. Анализ поведения и автоматизация: атаки идут очень быстро (в 2023 году 50 % атак длились менее 52 секунд). Поэтому вручную реагировать уже нельзя – требуется автоматизированная система, которая распознает паттерны: заголовки, время запросов, структура.
3. Инфраструктурные меры и глобальное распределение. Важно подчеркнуть значение глобальных anycast-сетей, автоматизированной фильтрации и подхода без лимитов на трафик («unmetered DDoS mitigation»).
4. Проактивный партнер и мониторинг: все домены через CDN, лимиты на кэш/некэш-трафик, мониторинг скрытых сигналов (например, странные запросы), наличие плана инцидентов.

Что это значит на практике. Рекомендации:

• Убедитесь, что ваша инфраструктура направляется через надежный CDN и исходные сервера не видны напрямую.
• Настройте лимиты и кэширование не только для типичного контента, но и для потенциально «обратных» точек: поиск, ошибки 404, динамика.
• Выбирайте решения с автоматическим анализом поведения, а не только статическими правилами.
• Проверяйте партнеров: способны ли они эффективно действовать без вашего ручного вмешательства и с минимальным влиянием на законный трафик.
• Рассмотрите услуги по защите от DDoS через специализированных провайдеров – на сайте https://stormwall.pro вы найдете соответствующие предложения, например защита для сайта https://stormwall.pro/products/website-ddos-protection.
• Не забывайте: защита – это не покупка и установка, а постоянная адаптация. Атаки эволюционируют и защита должна меняться вместе с ними.

Заключение

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

Если вы до сих пор полагаетесь лишь на базовый фаервол или CDN по-умолчанию, сейчас отличный момент пересмотреть подход и усилить защиту своих онлайн-сервисов.

Автор: Тео Леггетт, международный бизнес-корреспондент, The true cost of cyber attacks - and the business weak spots that allow them to happen

Первый день сентября должен был открыть один из самых активных периодов года для Jaguar Land Rover.

Это был понедельник, и запуск новых номерных знаков серии 75 (в Великобритании номерные серии выходят дважды в год и являются важным фактором спроса, поскольку покупатели хотят машину со свежим номером) предполагал всплеск покупательской активности.

На заводах в Солихалле и Хейлвуде, а также на моторном предприятии в Вулверхэмптоне персонал ожидал работы «в полный оборот».

Однако, когда утренняя смена прибыла на место, её отправили домой. Производственные линии с тех пор остаются остановленными.

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

Компания сотрудничает с разными экспертами по кибербезопасности и полицией для проведения расследования, но финансовый ущерб уже нанесён. Потери мировой выработки за более чем месяц стали фактом.

Аналитики оценивают убытки в 50 млн фунтов стерлингов в неделю.

Для компании, которая получила прибыль в размере 2,5 млрд фунтов стерлингов в прошлом финансовом году и принадлежит индийскому гиганту Tata Group, эти потери, вероятно, будут болезненными, но не смертельными.

Однако JLR — не единственный случай.

С начала этого года произошла целая волна кибератак, нацеленных на крупный бизнес, включая таких розничных ритейлеров, как Marks & Spencer и Co-op, а также поставщика ключевых систем для аэропортов.

Среди других громких жертв оказалась сеть детских садов Kido, а в прошлом году инциденты, связанные с Southern Water и компанией, предоставлявшей услуги по анализу крови для NHS (государственная система здравоохранения Великобритании), вызвали серьёзные опасения по поводу уязвимости критически важной инфраструктуры и услуг (в Великобритании NHS считается «сердцем» госуслуг, поэтому атака на поставщика лабораторных данных воспринимается как угроза национальному масштабу).

В целом, по оценкам государственного опроса о кибернарушениях, 612 000 предприятий и 61 000 благотворительных организаций по всей Великобритании стали целями атак.

Так сколько же стоят такие атаки для бизнеса и экономики?

И может ли быть так, что, как выразился один эксперт, крупные атаки этого года стали результатом накопительного эффекта своеобразного бездействия в области кибербезопасности со стороны государства и бизнеса, который теперь начинает приносить болезненные последствия?

Пирамида затронутых поставщиков

Особенность атаки такого масштаба, как та, что поразила JLR, заключается в том, насколько широко могут распространиться её последствия.

Компания находится на вершине пирамиды поставщиков, в которой — тысячи организаций. Они варьируются от крупных международных корпораций, таких как Bosch, до маленьких фирм с несколькими сотрудниками (в британской автомобильной индустрии множество узкопрофильных производителей деталей работают почти исключительно на одного заказчика), включая компании, полностью зависящие от JLR.

Для многих из этих фирм остановка производств представляла очень реальную угрозу их существованию.

В письме канцлеру от 25 сентября Комитет по бизнесу и торговле предупредил, что у небольших компаний «может остаться в лучшем случае неделя денежного потока для поддержки своей деятельности», тогда как более крупные «могут начать серьёзно испытывать трудности в течение двух недель».

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

Возобновление производства само по себе не означает, что кризис завершён.

Слишком поздно. Все наши компании прожили шесть недель с нулевыми продажами, но при этом с сохранением всех расходов. Сектор по-прежнему отчаянно нуждается в денежных средствах.

Российские киберпреступники или западные подростки

Недавний отчёт IBM, изучивший утечки данных примерно у 600 организаций по всему миру, показал, что средняя стоимость инцидента составляла 4,4 млн долларов (или 3,3 млн фунтов стерлингов).

Однако JLR далеко не единственный случай крупномасштабных кибератак. Атаки на Marks & Spencer и сеть супермаркетов Co-op в этом году оцениваются в 300 млн и 120 млн фунтов соответственно.

В апреле 2025 года злоумышленникам удалось получить доступ к IT-системам Marks & Spencer через стороннего подрядчика, вынудив компанию отключить некоторые сети (в Великобритании использование subcontractors широко распространено, и цепочка доверия часто становится уязвимостью).

Хакеры заразили сети компании программой-вымогателем (ransomware), которая зашифровала или перемешала (scrambled) данные.

Поначалу казалось, что нарушения будут незначительными — перестали работать системы бесконтактной оплаты, а также клиенты не могли воспользоваться услугой «click and collect» (это популярный формат покупки в британском ритейле: заказ онлайн — получение в офлайн-точке).

Однако спустя несколько дней пришлось остановить всю онлайн-торговлю — а она в обычное время составляет около трети бизнеса компании.

Эта ситуация была описана как «почти как отрубить себе конечность», по выражению Найны МакИнтош, бывшего члена исполнительного комитета Marks & Spencer и основательницы сети Hope Fashion.

Перед компанией встала распространённая на сегодняшний день дилемма: восстановить все компьютерные системы с нуля или заплатить хакерам миллионы фунтов стерлингов выкупа за антидот.

Marks & Spencer отказалась сообщать, выплатила ли она преступникам деньги.

Ущерб был не только финансовый. Позднее ритейлер признал, что в результате атаки были украдены данные клиентов.

Возможно, это включало телефонные номера, домашние адреса и даты рождения, хотя, по словам компании, платёжные реквизиты или данные карт похищены не были (обычно в отчётах такого рода отдельно подчёркивают, что PCI-данные не утекли — чтобы успокоить клиентов и регуляторов).

К дополнительному позору в СМИ Marks & Spencer, хакеры заявили, что отправили требование выкупа напрямую генеральному директору, используя учётную запись одного из сотрудников.

Когда была атакована сеть супермаркетов Co-op, ответственность взяла на себя та же группа хакеров.

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

Однако IT-сети были отключены достаточно быстро, чтобы избежать значительных повреждений.

По словам преступников, которые с раздражением описали это в разговоре с BBC, «они сами выдернули свой шнур — обрушив продажи, они сожгли логистику и подорвали стоимость акций» (здесь видно злорадство — хакеры подчеркивают, что даже без их действий компания бы пострадала, пытаясь защититься).

По словам Джейми МакКолла, эксперта по кибербезопасности из исследовательской группы Королевского института объединённых служб (RUSI), нет ничего удивительного в том, что крупные бизнесы становятся мишенью.

Он объясняет, что хакерам стало очень легко получить доступ к программам-вымогателям (ransomware), которые могут блокировать или шифровать сети жертвы до тех пор, пока не будет выплачен выкуп.

Слабые места крупного бизнеса

Уязвимость таких компаний, как Jaguar Land Rover и Marks & Spencer, во многом объясняется тем, как работают их цепочки поставок.

Автопроизводители давно используют так называемую систему «just-in-time delivery» (поставки точно в срок), при которой запчасти не хранятся на складе, а поступают от поставщиков ровно в тот момент, когда они нужны на производственной линии.

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

Аналогично, такой ритейлер, как Marks & Spencer, опирается на тщательно скоординированную цепочку поставок, чтобы гарантировать наличие нужного количества свежих продуктов в нужных магазинах — что делает систему столь же уязвимой (к примеру, если прогнозируемые объёмы поставок «замораживаются» из-за недоступности IT-систем, логистика теряет способность перераспределять товар вовремя).

(Прим. перевода: в британской торговле отказ IT-систем часто приводит не только к отсутствию товара на полках, но и мгновенным финансовым потерям из-за штрафов логистическим партнёрам.)

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

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

Накопительный эффект бездействия

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

Проблему удалось решить относительно быстро, но до этого значительное количество рейсов пришлось отменить.

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

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

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

Какой будет результат атаки на энергетическую отрасль, не совсем ясно.

Исследование, проведённое Lloyds Bank в 2015 году под названием «Business Blackout», моделировало последствия гипотетической атаки на энергосистему США и пришло к выводу, что экономические потери могут превысить 1 трлн долларов (742 млрд фунтов стерлингов).

Тем не менее МакКолл считает, что в Великобритании, вероятно, есть достаточный запас мощности в энергосистеме для того, чтобы справиться с киберинцидентом (речь идёт о наличии резервных ресурсов, которые можно включить при частичной потере управления системой).

Реакция правительства, угрозы ИИ и скрытые точки отказа

Джейми Макколл считает, что за последние 15 лет в Великобритании наблюдался «довольно попустительский подход (laissez-faire) к кибербезопасности», и сменявшие друг друга правительства уделяли этому вопросу мало внимания. Он полагает, что крупные атаки этого года могут быть «накопительным эффектом бездействия в сфере кибербезопасности как со стороны правительства, так и со стороны бизнеса, и теперь это начинает по-настоящему сказываться».

В мае Национальный центр кибербезопасности (NCSC), входящий в состав GCHQ (Центра правительственной связи Великобритании), опубликовал отчет, в котором предупредил о растущем влиянии киберугроз со стороны хакеров, использующих инструменты на основе искусственного интеллекта.

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

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

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

Проблему публично выявил исследователь безопасности Брэд Спенглер (основатель проекта grsecurity), заявив, что ошибка попала в релиз из-за неконтролируемого использования искусственного интеллекта при ревью.

Теперь любой, кто имеет CAP_SYS_RESOURCE и современный systemd, может уронить 6.12.43 LTS одной строкой машинного кода — благодаря ИИ-слопу от стабильного мейнтейнера

Он приложил байт-код, который действительно вызывает крах ядра.

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

Кто виноват

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

Исследователь утверждает, что автор «пропустил» ошибку, не протестировал код и не задокументировал источник генерации.

В своих публикациях Спенглер приводит ссылки на серию коммитов, связанных с AI-AUTOSEL, системой полуавтоматического выбора патчей на основе LLM-моделей, применяемой для синхронизации стабильных веток Linux.

Ранее именно этот механизм уже приводил к появлению уязвимостей, в том числе отключающих части защиты Spectre v2.

Без CVE и объяснений

Ошибка в ядре 6.12.43 была исправлена без упоминания уязвимости и без выделения CVE, что вызвало критику со стороны специалистов по безопасности.

По словам Спенглера, «исправление тихо занесли в бэкпорт без признания факта бага, вызванного использованием ИИ».

Почему это важно

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

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

Спенглер подытожил:

Вайб-кодинг не должен иметь места в разработке ядра. Слоп остается слопом — и ИИ здесь не исключение.

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

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

Что такое бэкапы

Итак, бэкап сайта (с англ. backup — запасной) — это резервное копирование файлов, папок, данных проекта на отдельный сервер. Таким образом можно избежать потери информации в случае атаки, сбоев в работе сервера или базы данных, плановых работ или даже неудачных изменений на сайте.

Главная идея резервного копирования — возможность в любой момент откатить версию проекта до более старой.

Бэкапы делятся на несколько видов. Разберём их в зависимости от механизма копирования:

• Полный

Такая резервная копия сохраняет все данные. Она требует больше всего памяти и времени для создания.

• Инкрементальный

Сохраняет только те данные, которые изменились с момента последнего бэкапа.

• Дифференциальный

Включает только те файлы, которые изменились относительно последнего полного бэкапа.

• Обратное инкрементальное копирование

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

• Синтетическое копирование

За основу берётся последний полный бэкап, на который «наслаиваются» инкрементные копии — пока система не соберёт актуальную версию. Когда эта версия устаревает, цикл повторяется: создаётся новый синтетический бэкап поверх предыдущего полного.

Бэкапы также могут храниться на разных носителях, вот основные из них:

Сетевое хранилище (NAS)

Локальный сервер, где можно централизованно хранить бэкапы разных устройств и/или пользователей, объединяя их в одну сеть. Работает через LAN (локальное соединение) или интернет.

Другой компьютер

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

Внешний (жёсткий) диск

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

Облачное хранилище

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

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

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

Почему люди не делают бэкапы

В России лишь 13% работающих россиян выполняют бэкапы регулярно, тогда как, например, в Европе 37% пользователей делают резервные копии еженедельно.

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

• Халатность или недостаток технической грамотности. Многие думают, что резервное копирование не требует особых настроек и работает фоново. 43% IT-руководителей и вовсе уверены, что бэкап данных на сервере — полностью ответственность провайдера.

Теперь рассмотрим, как предупредить ошибки при организации резервного копирования и поставить этот процесс на поток.

Ошибки при организации резервного копирования

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

• Нерегулярность

62% пользователей в РФ копируют и сохраняют рабочие данные, но большинство делают это нерегулярно.

• Хранение всех копий в одном месте

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

• Хранение только одной копии

Иметь одну резервную копию рискованно – если она повредится или вы случайно сохраните неверную версию, данные пропадут безвозвратно. Поэтому существует правило «3-2-1»: лучше иметь не менее трех копий данных, хранить их на двух и более физических носителях и не менее одной копии – удалённо.

• Отсутствие тестирования восстановления

По статистике, лишь 30% компаний проводят комплексное тестирование резервного копирования.

• Незащищенность бэкапов

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

Когда бэкапы пригодились: кейсы компаний

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

Google Cloud

В 2024 году пенсионный фонд UniSuper обнаружил, что его учетная запись в Google Cloud удалена. Из-за сбоя пострадали около 620 000 пенсионеров — доступ к их счетам оказался заблокирован на неделю.

Решить проблему помог другой партнер UniSuper — хостинг-провайдер, которому фонд отдал свои резервные копии на хранение. Они помогли компании восстановить данные и доступ к аккаунтам.

Hycu

Одна медицинская компания и клиент Hycu уделяла кибербезопасности огромное внимание, но в её инфраструктуре всё равно нашлось слабое место. Через электронное письмо систему поразила программа-вымогатель, а когда проблему заметили, заражены уже были все файлы.

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

Samsung

Когда в 2014 году в дата-центре Samsung произошёл крупный пожар, большая часть данных пропала безвозвратно из-за отсутствия удалённых бэкапов.

Как показывают эти и другие подобные кейсы, создание резервных копий сервера — один из главных инструментов защиты данных.

Кто обычно отвечает за бэкапы

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

Мы в Beget тоже придерживаемся такой практики и внедрили для пользователей как автоматическое резервное копирование, так и бэкапы по требованию. Автоматический бэкап сайта на хостинге создается в среднем раз в 3 дня, на VPS – раз в 2–5 дней. Полный бэкап сервера VPS хранится в среднем 10 суток, после чего заменяется более свежей версией. Точного срока хранения бэкапов на виртуальном хостинге нет: на каждом аккаунте может храниться единовременно только 10 бэкапов, а когда место заканчивается, более старые копии удаляются.

Заключение

Утечка данных — проблема, которая почти всегда приходит без предупреждения. Пожалуй, именно поэтому, несмотря на все затраченные на системы безопасности средства, данные теряются постоянно: например, в 2023 году более 90% компаний оказались в ситуации, когда им пришлось обратиться к бэкапам, и при этом только 27% компаний смогли восстановить все данные, так как резервное копирование было организовано неправильно.

🔐 Что изменилось в Apple Security Bounty

Программа действует с 2020 года и за это время выплатила исследователям уже $35 миллионов, в среднем — по $43 750 каждому из более чем 800 специалистов. Теперь Apple значительно увеличила размеры выплат и расширила список категорий уязвимостей:

Apple отмечает, что программа теперь охватывает более широкий спектр угроз, включая уязвимости в WebKit, механизмы защиты macOS и бета-версии iOS и iPadOS.

🧠 Почему это важно

Обновлённая программа помогает Apple защищать пользователей от атак высшего уровня — таких, что используются в дорогостоящем наёмном шпионском ПО.

За последние годы компания:

• внедрила Lockdown Mode, блокирующий большинство векторов атак;
• переработала систему защиты Safari;
• добавила Memory Integrity Enforcement в чипах серии A19, которая предотвращает уязвимости, связанные с повреждением памяти.

По словам Apple, сегодня лишь единичные iOS-атаки происходят на уровне системы, и они стоят миллионы долларов в разработке.

С ростом числа киберугроз и шпионских атак Apple активно позиционирует себя как лидера в области приватности и защиты данных. Повышенные награды отражают стратегию компании — поощрять белых хакеров и опережать киберпреступников на шаг.

Что произошло

По данным, опубликованным BleepingComputer, злоумышленники утверждают, что взломали Zendesk-инстанс, который Discord использует для поддержки клиентов.

Они заявляют, что получили 1,6 ТБ данных — это около 8,4 миллиона тикетов поддержки, затрагивающих 5,5 миллиона уникальных пользователей.

Discord в ответ пояснил, что речь идёт не о взломе платформы, а о компрометации стороннего сервиса, связанного с техподдержкой:

«Это не взлом Discord, а инцидент с участием стороннего поставщика, который помогает нам обрабатывать запросы пользователей», — говорится в официальном заявлении компании.

Что могли украсть

Хакеры утверждают, что получили доступ к внутреннему инструменту Zenbar, позволявшему:

• просматривать e-mail и номера телефонов пользователей;
• отключать двухфакторную аутентификацию (MFA);
• просматривать внутренние тикеты и обращения.

По их словам, среди украденных данных есть:

• адреса электронной почты и Discord ID;
• номера телефонов;
• частичная платёжная информация;
• даты рождения;
• данные MFA и статусы активности;
• переписки с техподдержкой.

Особенно тревожная часть — это фотографии удостоверений личности, которые пользователи отправляли для проверки возраста. Discord признаёт, что утечка затронула около 70 000 пользователей, а не 2,1 миллиона, как утверждают хакеры.

Что говорит Discord

Компания заявила, что не будет выплачивать выкуп, назвав цифры злоумышленников «преувеличенными» и частью попытки вымогательства.

«Мы не собираемся вознаграждать тех, кто нарушает закон.

Количество затронутых пользователей сильно завышено», — подчеркнули представители Discord.

Как произошёл взлом

Хакеры утверждают, что получили доступ через аккаунт сотрудника аутсорсинговой компании (BPO), которая занимается поддержкой пользователей Discord.

Доступ сохранялся в течение 58 часов — с 20 по 22 сентября 2025 года.

Такие компании нередко становятся уязвимым звеном: атакующие получают доступ не напрямую к IT-инфраструктуре бренда, а через подрядчиков.

Попытка вымогательства

По данным BleepingComputer, злоумышленники потребовали $5 миллионов, позднее снизив сумму до $3,5 млн. Переговоры шли до 2 октября, но после официального отказа Discord платить, группа заявила о намерении слить данные в открытый доступ.

Пока достоверность образцов данных, предоставленных хакерами, не подтверждена.

Что делать пользователям

Эксперты советуют:

• обновить пароль Discord и включить двухфакторную аутентификацию;
• не переходить по подозрительным ссылкам, даже если они приходят от знакомых аккаунтов;
• при совпадении e-mail с утекшими адресами — проверить их через Have I Been Pwned;
• следить за сообщениями от поддержки Discord о возможных уведомлениях безопасности.

Что произошло

Redis — это высокопроизводительное хранилище данных с открытым исходным кодом, применяемое как кэш, брокер сообщений и база данных. Оно используется примерно в 75% облачных инфраструктур по всему миру.

Новая уязвимость, прозванная исследователями RediShell, связана с 13-летней ошибкой типа use-after-free в интерпретаторе Lua. При успешной эксплуатации она позволяет аутентифицированному злоумышленнику выйти за пределы «песочницы» Lua, установить обратное соединение и добиться удалённого выполнения кода (RCE) на хосте Redis.

Потенциальные последствия

После компрометации сервера атакующий может:

• похищать учётные данные и конфиденциальные данные из памяти Redis;
• внедрять вредоносное ПО и криптомайнеры;
• перемещаться по внутренней сети жертвы;
• использовать полученные токены доступа для атак на другие облачные сервисы.

Исследователи из Wiz, впервые представившие уязвимость на конференции Pwn2Own Berlin 2025, отметили, что она «предоставляет злоумышленнику полный доступ к хостовой системе, включая возможность стирания, шифрования и перехвата данных».

Масштаб угрозы

По данным Wiz, в сети обнаружено около 330 000 экземпляров Redis, из которых не менее 60 000 не требуют аутентификации, что делает их уязвимыми к немедленной атаке.

Уязвимость затрагивает все версии Redis, включая OSS/CE и Stack-редакции. Исправления уже доступны в версиях:

• 7.22.2-12 и выше,
• 7.8.6-207 и выше,
• 7.4.6-272 и выше,
• 7.2.4-138 и выше,
• 6.4.2-131 и выше,
  а также в OSS/CE релизах 8.2.2+, 8.0.4+, 7.4.6+, 7.2.11+ и Stack-релизах 7.4.0-v7+ и 7.2.0-v19+.

Рекомендации для администраторов

Redis и Wiz настоятельно советуют:

• немедленно обновить все экземпляры Redis;
• включить аутентификацию и ограничить доступ доверенным сетям;
• отключить выполнение Lua-скриптов, если оно не требуется;
• запускать Redis без прав root;
• включить журналирование и мониторинг активности;
• использовать сетевые фильтры, VPN и брандмауэры для защиты.

Исследователи представили видео об уязвимости, где можно посмотреть подробности о возможных угрозах и мерах безопасности.

Исторический контекст

Redis уже не раз становился целью атак. В 2024 году ботнет P2PInfect использовал уязвимые экземпляры для майнинга Monero, а ранее вредоносные программы Redigo, HeadCrab и Migo внедряли криптомайнеры и отключали защиту на серверах Redis.

По словам Wiz, сочетание широкого распространения Redis, небезопасных конфигураций по умолчанию и критичности уязвимости создаёт «острую необходимость в немедленном обновлении».

Речь идёт о баге CVE-2025-61882 с оценкой CVSS 9.8 — максимальной степенью критичности.

Уязвимость обнаружена в компоненте BI Publisher Integration продукта Oracle Concurrent Processing и позволяет злоумышленникам выполнять удалённый код без аутентификации — то есть без логина и пароля.

«Эта уязвимость эксплуатируется по сети без необходимости входа в систему. При успешной атаке возможен полный удалённый захват системы», — говорится в официальном уведомлении Oracle.

Компания подтвердила, что под угрозой находятся версии Oracle EBS 12.2.3–12.2.14.

Исправление уже выпущено, но для его установки необходимо сначала применить Critical Patch Update за октябрь 2023 года.

Clop эксплуатирует уязвимость в масштабных атаках

Хакерская группировка Clop, известная по атакам на MOVEit Transfer и Accellion, уже активно использует уязвимость Oracle.

По данным Mandiant (Google Cloud), Clop применил несколько эксплойтов для взлома серверов Oracle EBS в августе 2025 года, включая как июльские патчи, так и свежий баг CVE-2025-61882.

«Clop эксплуатировал несколько уязвимостей в Oracle EBS, чтобы похитить большие объёмы данных у компаний-жертв,» — подтвердил Чарльз Кармакал, CTO Mandiant.

Жертвам начали поступать письма-шантажи с угрозами опубликовать украденные документы вместе с содержимым корпоративных ERP-систем Oracle.

Формулировка типичного письма:

Мы — команда CLOP. Мы взломали вашу Oracle E-Business Suite и скопировали множество документов. Все файлы теперь в нашем распоряжении.

Clop — одна из самых агрессивных вымогательских групп мира, специализирующаяся на zero-day-атаках на корпоративные системы.

За последние годы они использовали уязвимости:

• Accellion FTA (2020),
• SolarWinds Serv-U (2021),
• GoAnywhere MFT (2023),
• MOVEit Transfer (2023),
• Cleo MFT (2024).

Общее число пострадавших компаний в мире от атак Clop превышает 3000 организаций.

Атака на Oracle EBS — первый случай компрометации ERP-платформы такого масштаба.

Утечка эксплойта и исходного кода Oracle

Интересно, что утечка эксплойта произошла не от Clop напрямую, а через другую кибергруппу — Scattered Lapsus$ Hunters, которая утверждает, что объединяет участников из Lapsus$, Scattered Spider и ShinyHunters.

6 октября на Telegram-каналах появились два архива:

• GIFT_FROM_CL0P.7z — содержит исходный код Oracle Cloud, предположительно похищенный в феврале 2025 года;
• ORACLE_EBS_NDAY_EXPLOIT_POC_SCATTERED_LAPSUS_RETARD_CL0P_HUNTERS.zip — архив с эксплойтом для уязвимости CVE-2025-61882.

BleepingComputer подтвердил, что именно этот архив совпадает с индикаторами компрометации, опубликованными Oracle.

Внутри находились Python-скрипты exp.py и server.py, позволяющие:

• выполнять произвольные команды на уязвимом сервере,
• или открывать обратную shell-сессию к серверу злоумышленников.

ShinyHunters, связанный с утечкой, заявил в интервью BleepingComputer, что эксплойт принадлежал ему и был утерян — предположительно, передан или продан Clop:

Это был мой эксплойт, как и уязвимости в SAP. Его украли и использовали другие. Мы решили просто выложить его в открытый доступ. Никакой вражды к Clop.

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

Что делать администраторам Oracle

• Немедленно установить патч CVE-2025-61882 после обновления Critical Patch Update 10/2023.
• Проверить журналы активности на наличие подключений с IP 200.107.207.26 и 185.181.60.11.
• Изолировать серверы E-Business Suite, доступные из интернета.
• Включить мониторинг сетевых соединений и запусков shell-команд.
• Проверить наличие файлов exp.py и server.py в системе.

CVE-2025-61882 — одна из самых опасных уязвимостей 2025 года, поскольку:

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

Oracle настоятельно рекомендует администраторам немедленно обновить системы, пока Clop и Scattered Lapsus$ Hunters продолжают расширять кампанию атак.

• Google Play Store v48.3 (06.10.2025): обновленные иконки в некоторых уведомлениях Google Play Protect на телефонах, ПК, ТВ, Auto.

Важно: функция в релиз-нотах не гарантирует её мгновенную доступность на всех устройствах. Google часто вводит функции постепенно, «поэтапно разворачивая» (staged rollout).

Google Play services v25.39

Через APKMirror задокументирован выпуск версии 25.39.30 (beta).

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

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

Особое улучшение касается защиты и безопасности: функция Sensitive Content Warnings в Google Messages научилась распознавать нежелательный контент не только на фотографиях, но и в видеороликах — шаг, который повышает безопасность общения в мессенджере. Параллельно был переработан и режим Driving Do Not Disturb — он стал работать стабильнее, меньше отвлекать водителя и лучше подстраиваться под дорожные ситуации.

В более ранних версиях (v25.37) Google уже вводил исправления стабильности при управлении аккаунтами, улучшения соединений устройств и дополнения к API. Droid Life. Версия 25.39, скорее, эволюция этих функций, сглаживающая баги и добавляющая новые интерфейсы.

Google Play Store v48.3

В релиз-нотах отмечено, что в уведомлениях Google Play Protect обновлены иконки на всех поддерживаемых платформах: Auto, ПК, телефон, ТВ.

Безопасность: Android Security Bulletin (сентябрь 2025)

Параллельно с системными обновлениями Google продолжает выпускать ежемесячные безопасностные бюллетени Android (Android Security Bulletin).

В бюллетене за сентябрь 2025 описано множество уязвимостей — например:

• CVE-2025-48543 — уязвимость в Android Runtime, позволяющая эскалацию привилегий, без необходимости дополнительного запуска кода.
• Несколько уязвимостей в Framework и ядре классифицируются как высокие (High) — могут дать локальное повышение привилегий.
• Устройства с Android 10 и выше могут получить обновления безопасности через Google Play system updates.

Что проверять и как обновиться?

С учётом подтверждённых данных, рекомендуем:

• Проверять на вашем устройстве версии:
  Google Play services — должна быть 25.39.x (или выше, если уже вышли патчи).
  Google Play Store — версия v48.3 или выше.
  Google Play system update (в Настройках телефона) — наличие новых системных патчей безопасности.
• Google Play services — должна быть 25.39.x (или выше, если уже вышли патчи).
• Google Play Store — версия v48.3 или выше.
• Google Play system update (в Настройках телефона) — наличие новых системных патчей безопасности.
• Если устройство не получает обновления автоматически — попробуйте вручную запустить обновление Google Play services через доступные источники (Play Store, Google Play System Update).
• Следите за бюллетенями безопасности Android: версия безопасности (security patch level) должна быть актуальной.
• У устройств с более старыми версиями Android (менее Android 10) возможности получать обновления безопасности через Google System могут быть ограничены.