В плагин Quick Page/Post Redirect, установленный более чем на 70 000 сайтах WordPress, пять лет назад был добавлен бэкдор, позволяющий внедрять произвольный код на сайты пользователей.
Вредоносная ПО была обнаружена Остином Гиндером, основателем WordPress Anchor, который нашел ее после того, как 12 зараженных сайтов в его сети вызвали срабатывание систем безопасности.
Quick Page/Post Redirect, доступный на WordPress.org уже несколько лет, представляет собой базовый вспомогательный плагин, используемый для создания перенаправлений в записях, страницах и пользовательских URL-адресах.
К настоящему времени WordPress временно удалил плагин из каталога до завершения проверки. Неясно, создал ли автор плагина бэкдор или же он был взломан третьей стороной.
Гиндер пояснил, что официальные версии плагина 5.2.1 и 5.2.2, выпущенные в период с 2020 по 2021 год, включали скрытый механизм самообновления, указывающий на сторонний домен anadnet[.]com, что позволяло распространять произвольный код вне контроля WordPress.
В феврале 2021 года вредоносный самообновляющийся модуль был удален из последующих версий плагина на WordPress до того, как у рецензентов появилась возможность его тщательно изучить.
В марте 2021 года сайты, использующие Quick Page/Post Redirect 5.2.1 и 5.2.2, незаметно получили модифицированную сборку 5.2.3 с внешнего сервера, которая внедрила пассивный бэкдор.
Однако сборка с сервера w.anadnet[.]com с дополнительным кодом бэкдора имела другой хеш, чем та же версия плагина, полученная с WordPress.
Пассивный бэкдор срабатывает только для неавторизованных пользователей, чтобы скрыть свою активность от администраторов. Он подключен к the_content и получает данные с сервера anadnet, вероятно, используемого для SEO-спама.
Однако реальная опасность для затронутых веб-сайтов исходит от самого механизма обновления, который позволял выполнять произвольный код по запросу.
Он по-прежнему присутствует на сайтах, использующих плагин, но находится в спящем режиме, поскольку вредоносный внешний поддомен управления не разрешается. Тем не менее, сам домен активен.
Решение для пострадавших пользователей - удалить плагин и заменить его чистой копией версии 5.2.4, загруженной с WordPress.org, когда она снова станет доступна.
Исследователь предупреждает, что у Quick Page/Post Redirect по-прежнему 70 000 установок, а проверка обновлений указывает на сервер anadnet.
Вредоносная ПО была обнаружена Остином Гиндером, основателем WordPress Anchor, который нашел ее после того, как 12 зараженных сайтов в его сети вызвали срабатывание систем безопасности.
Quick Page/Post Redirect, доступный на WordPress.org уже несколько лет, представляет собой базовый вспомогательный плагин, используемый для создания перенаправлений в записях, страницах и пользовательских URL-адресах.
К настоящему времени WordPress временно удалил плагин из каталога до завершения проверки. Неясно, создал ли автор плагина бэкдор или же он был взломан третьей стороной.
Гиндер пояснил, что официальные версии плагина 5.2.1 и 5.2.2, выпущенные в период с 2020 по 2021 год, включали скрытый механизм самообновления, указывающий на сторонний домен anadnet[.]com, что позволяло распространять произвольный код вне контроля WordPress.
В феврале 2021 года вредоносный самообновляющийся модуль был удален из последующих версий плагина на WordPress до того, как у рецензентов появилась возможность его тщательно изучить.
В марте 2021 года сайты, использующие Quick Page/Post Redirect 5.2.1 и 5.2.2, незаметно получили модифицированную сборку 5.2.3 с внешнего сервера, которая внедрила пассивный бэкдор.
Однако сборка с сервера w.anadnet[.]com с дополнительным кодом бэкдора имела другой хеш, чем та же версия плагина, полученная с WordPress.
Пассивный бэкдор срабатывает только для неавторизованных пользователей, чтобы скрыть свою активность от администраторов. Он подключен к the_content и получает данные с сервера anadnet, вероятно, используемого для SEO-спама.
Однако реальная опасность для затронутых веб-сайтов исходит от самого механизма обновления, который позволял выполнять произвольный код по запросу.
Он по-прежнему присутствует на сайтах, использующих плагин, но находится в спящем режиме, поскольку вредоносный внешний поддомен управления не разрешается. Тем не менее, сам домен активен.
Решение для пострадавших пользователей - удалить плагин и заменить его чистой копией версии 5.2.4, загруженной с WordPress.org, когда она снова станет доступна.
Исследователь предупреждает, что у Quick Page/Post Redirect по-прежнему 70 000 установок, а проверка обновлений указывает на сервер anadnet.
Anchor Hosting
WordPress Plugin Hijacked in 2020 Hid a Dormant Backdoor for Years
Twelve sites in our fleet were running a tampered version 5.2.3 of Quick Page/Post Redirect Plugin. The file hash did not match anything on wordpress.org. The SVN log showed the plugin author committed the supply chain mechanism themselves.
Не можем не отметить в продолжение нашего предыдущего материала, что в течение нескольких месяцев хакеры уже активно использовали критическую уязвимость обхода аутентификации в платформе управления сервером и сайтом cPanel & WHM (WebHost Manager).
CVE-2026-41940 (CVSS 9,8) была обнаружена 28 апреля и, как утверждают на Reddit от хостинг-провайдера KnownHost, уязвимость используется злоумышленниками с 23 февраля 2026 года.
Тогда же сразу после получения уведомления о проблеме KnownHost, HostPapa, InMotion, Namecheap и другие хостинг-провайдеры заблокировали доступ к портам cPanel и WHM для безопасного развертывания обновлений.
Анализируя CVE-2026-41940, WatchTowr обнаружила, что при неудачной попытке входа в систему демон службы cPanel записывает на диск файл предварительной аутентификации, и что злоумышленник может манипулировать cookie-файлом таким образом, чтобы в него в открытом виде записывались учетные данные, контролируемые злоумышленником.
По сути, эта ошибка позволяет злоумышленнику внедрить определенные символы через заголовок авторизации для записи конкретных параметров в файл сессии, а затем инициировать перезагрузку файла для аутентификации с использованием внедренных учетных данных.
cPanel опубликовала скрипт обнаружения, а WatchTowr выпустила генератор артефактов обнаружения, чтобы помочь администраторам выявлять признаки компрометации.
В целом, телеметрия Shodan показывает около 1,5 млн. доступных через интернет экземпляров cPanel, которые могут быть подвержены атакам.
CVE-2026-41940 (CVSS 9,8) была обнаружена 28 апреля и, как утверждают на Reddit от хостинг-провайдера KnownHost, уязвимость используется злоумышленниками с 23 февраля 2026 года.
Тогда же сразу после получения уведомления о проблеме KnownHost, HostPapa, InMotion, Namecheap и другие хостинг-провайдеры заблокировали доступ к портам cPanel и WHM для безопасного развертывания обновлений.
Анализируя CVE-2026-41940, WatchTowr обнаружила, что при неудачной попытке входа в систему демон службы cPanel записывает на диск файл предварительной аутентификации, и что злоумышленник может манипулировать cookie-файлом таким образом, чтобы в него в открытом виде записывались учетные данные, контролируемые злоумышленником.
По сути, эта ошибка позволяет злоумышленнику внедрить определенные символы через заголовок авторизации для записи конкретных параметров в файл сессии, а затем инициировать перезагрузку файла для аутентификации с использованием внедренных учетных данных.
cPanel опубликовала скрипт обнаружения, а WatchTowr выпустила генератор артефактов обнаружения, чтобы помочь администраторам выявлять признаки компрометации.
В целом, телеметрия Shodan показывает около 1,5 млн. доступных через интернет экземпляров cPanel, которые могут быть подвержены атакам.
Reddit
KH-DanielP's comment on "Massive cPanel 0-day auth bypass hits web hosting industry; exploits confirmed in the wild"
Explore this conversation and more from the cpanel community
Forwarded from Social Engineering
• Большинство знает, что в начале 2000-х провайдеры предоставляли доступ в интернет с оплатой по карточкам. Тарифы операторов были разными и отличались друг от друга, но у провайдера РОЛ была безлимитка! Безлимитка эта была только ночная, но по тем временам это было пределом фантастики. Покупка карточки доступа за 300 рублей давала целых 20 часов интернета и безлимитку с 2-х ночи до 9 утра по выходным, а карточка стоимостью 500 рублей несла в себе 50 часов интернета и безлимитку с 2-х ночи до 9-ти утра каждый день. Естественно, многие этим пользовались. Сидеть за компом по ночам – конечно, можно, но не для всех подходит.
• Многие шли на хитрость. Силами "Планировщика Windows" и стороннего софта, система конфигурировалась так, чтобы в 2 часа ночи компьютер "просыпался" и начинал дозвон на модемный пул провайдера. У провайдера было 3 номера дозвона, и, естественно, приходилось довольно долгое время дозваниваться, потому что, как правило, по ночам линии были забиты полностью. В итоге рано или поздно соединение устанавливалось, а дальше начиналось скачивание. Например, можно было надобавлять разного софта или mp3 файлов в download manager.
• При хороших условиях за ночь можно было скачать около 100 мегабайт. Также были популярны так называемые offline-браузеры, которым можно было скормить URL, а они "грабили" веб-сервер, переходя по всем ресурсам и ссылкам с заданной глубиной вложенности, в результате чего на жестком диске получалась практически полная локальная копия страниц сайта.
• Как-то раз случилась забавная история. После переустановки Windows необходимо было заново настроить софт, который автоматически дозванивался до оператора. Пару дней всё было неплохо, пока не начались выходные. В один из дней раздался телефонный звонок. Разъяренный мужик на другом конце провода в очень грубых выражениях допытывался – на кой хрен мы звоним ему на мобилу по ночам и молчим в трубку?!
• А соль была в том, что настраивая заново софт для дозвона, была сделана опечатка в одном из номеров, и в итоге вместо провайдера модем звонил на другой номер, который по счастливой случайности оказался прямым городским номером мобильного телефона этого мужика. Модем начинал попытки дозвона, перебирая номера, которые были заняты, дозванивался до мужика, мужик брал трубку, модем через какое-то время рвал соединение, потом снова пытался дозвониться до провайдера, было занято, потом снова подходила очередь мужика... Такое вот было интересное время...
S.E. ▪️ infosec.work ▪️ VT
• Многие шли на хитрость. Силами "Планировщика Windows" и стороннего софта, система конфигурировалась так, чтобы в 2 часа ночи компьютер "просыпался" и начинал дозвон на модемный пул провайдера. У провайдера было 3 номера дозвона, и, естественно, приходилось довольно долгое время дозваниваться, потому что, как правило, по ночам линии были забиты полностью. В итоге рано или поздно соединение устанавливалось, а дальше начиналось скачивание. Например, можно было надобавлять разного софта или mp3 файлов в download manager.
• При хороших условиях за ночь можно было скачать около 100 мегабайт. Также были популярны так называемые offline-браузеры, которым можно было скормить URL, а они "грабили" веб-сервер, переходя по всем ресурсам и ссылкам с заданной глубиной вложенности, в результате чего на жестком диске получалась практически полная локальная копия страниц сайта.
• Как-то раз случилась забавная история. После переустановки Windows необходимо было заново настроить софт, который автоматически дозванивался до оператора. Пару дней всё было неплохо, пока не начались выходные. В один из дней раздался телефонный звонок. Разъяренный мужик на другом конце провода в очень грубых выражениях допытывался – на кой хрен мы звоним ему на мобилу по ночам и молчим в трубку?!
• А соль была в том, что настраивая заново софт для дозвона, была сделана опечатка в одном из номеров, и в итоге вместо провайдера модем звонил на другой номер, который по счастливой случайности оказался прямым городским номером мобильного телефона этого мужика. Модем начинал попытки дозвона, перебирая номера, которые были заняты, дозванивался до мужика, мужик брал трубку, модем через какое-то время рвал соединение, потом снова пытался дозвониться до провайдера, было занято, потом снова подходила очередь мужика... Такое вот было интересное время...
S.E. ▪️ infosec.work ▪️ VT
Подкатили новые подробности с атаками, нацеленными на недавно исправленную 0-day обхода аутентификации в cPanel & WebHost Manager (WHM), CVE-2026-41940, обеспечивающую административный доступ.
По всей видимости, более 40 000 серверов были скомпрометированы в рамках масштабной кампании, как сообщает Shadowserver Foundation.
Раскрытая 28 апреля уязвимость предоставляет неавторизованным злоумышленникам административный доступ к cPanel, позволяя захватить контроль над хост-системой и скомпрометировать все конфигурации, базы данных и сайты, которыми управляет платформа.
Уязвимость может быть использована с помощью специальных символов в заголовках авторизации для записи параметров в файл сессии, а затем для запуска перезагрузки файла сессии с целью аутентификации с использованием внедренных административных учетных данных.
Причем CVE-2026-41940, вероятно, использовалась злоумышленниками в качестве 0-day еще с конца февраля, при этом активность резко возросла после публичного раскрытия информации и того, как компания WatchTowr опубликовала технические подробности.
На прошлой неделе Rapid7 предупредила, что в интернете доступно около 1,5 млн. экземпляров cPanel, а в пятницу Shadowserver Foundation выявила десятки тысяч потенциально скомпрометированных систем.
В частности, в ходе продолжающихся атак были скомпрометированы как минимум 44 000 IP, на которых работает cPanel.
По данным Shadowserver Foundation, по состоянию на 3 мая это число значительно сократилось. Большинство затронутых систем находятся в США, а Франция и Нидерланды замыкают тройку лидеров.
При этом сообщается, что хакеры используют уязвимость cPanel с четверга для взлома серверов и развертывания основанного на Go Linux шифратора для программы-вымогателя Sorry (VirusTotal).
Зафиксировано множество сообщений от пострадавших, где одна из жертв поделилась образцами зашифрованных файлов и содержимым записки с требованием выкупа.
Программа-вымогатель использует потоковый шифр ChaCha20 для шифрования файлов, при этом ключ шифрования защищен с помощью встроенного открытого ключа RSA-2048.
В каждой папке создается записка с требованием выкупа под названием README.md, в которой жертве предлагается связаться с злоумышленником в Tox для обсуждения суммы выкупа.
Поскольку все версии cPanel, начиная с 11.40, уязвимы, пользователям рекомендуется как можно скорее обновить систему до версии с исправлением и следовать инструкциям cPanel по выявлению и устранению потенциальных угроз.
Согласно обновленному уведомлению cPanel, исправления содержатся в версиях cPanel & WHM 11.86.0.41, 11.110.0.97, 11.118.0.63, 11.124.0.35, 11.126.0.54, 11.130.0.19, 11.132.0.29, 11.134.0.20 и 11.136.0.5, а также в версии WP Squared 136.1.7.
Исследователи полагают, что в ближайшие дни и недели будет наблюдаться лишь усиление эксплуатации уязвимости. Но будем посмотреть.
По всей видимости, более 40 000 серверов были скомпрометированы в рамках масштабной кампании, как сообщает Shadowserver Foundation.
Раскрытая 28 апреля уязвимость предоставляет неавторизованным злоумышленникам административный доступ к cPanel, позволяя захватить контроль над хост-системой и скомпрометировать все конфигурации, базы данных и сайты, которыми управляет платформа.
Уязвимость может быть использована с помощью специальных символов в заголовках авторизации для записи параметров в файл сессии, а затем для запуска перезагрузки файла сессии с целью аутентификации с использованием внедренных административных учетных данных.
Причем CVE-2026-41940, вероятно, использовалась злоумышленниками в качестве 0-day еще с конца февраля, при этом активность резко возросла после публичного раскрытия информации и того, как компания WatchTowr опубликовала технические подробности.
На прошлой неделе Rapid7 предупредила, что в интернете доступно около 1,5 млн. экземпляров cPanel, а в пятницу Shadowserver Foundation выявила десятки тысяч потенциально скомпрометированных систем.
В частности, в ходе продолжающихся атак были скомпрометированы как минимум 44 000 IP, на которых работает cPanel.
По данным Shadowserver Foundation, по состоянию на 3 мая это число значительно сократилось. Большинство затронутых систем находятся в США, а Франция и Нидерланды замыкают тройку лидеров.
При этом сообщается, что хакеры используют уязвимость cPanel с четверга для взлома серверов и развертывания основанного на Go Linux шифратора для программы-вымогателя Sorry (VirusTotal).
Зафиксировано множество сообщений от пострадавших, где одна из жертв поделилась образцами зашифрованных файлов и содержимым записки с требованием выкупа.
Программа-вымогатель использует потоковый шифр ChaCha20 для шифрования файлов, при этом ключ шифрования защищен с помощью встроенного открытого ключа RSA-2048.
В каждой папке создается записка с требованием выкупа под названием README.md, в которой жертве предлагается связаться с злоумышленником в Tox для обсуждения суммы выкупа.
Поскольку все версии cPanel, начиная с 11.40, уязвимы, пользователям рекомендуется как можно скорее обновить систему до версии с исправлением и следовать инструкциям cPanel по выявлению и устранению потенциальных угроз.
Согласно обновленному уведомлению cPanel, исправления содержатся в версиях cPanel & WHM 11.86.0.41, 11.110.0.97, 11.118.0.63, 11.124.0.35, 11.126.0.54, 11.130.0.19, 11.132.0.29, 11.134.0.20 и 11.136.0.5, а также в версии WP Squared 136.1.7.
Исследователи полагают, что в ближайшие дни и недели будет наблюдаться лишь усиление эксплуатации уязвимости. Но будем посмотреть.
X (formerly Twitter)
The Shadowserver Foundation (@Shadowserver) on X
44K unique IP number is based on cPanel spike of devices seen scanning/running exploits/brute force attacks against our honeypot sensors.
https://t.co/SINYf136HI
https://t.co/SINYf136HI
Исследователи Лаборатории Касперского оперативно представили рекомендации, помогающие задетектить вредоносную активность с использованием уязвимости Copy Fail компаниям, использующим SIEM Kaspersky Unified Monitoring and Analysis Platform (KUMA).
Кроме того, конечно же, выкатили технические подробности с разбором сути проблемы с неофициальным названием Copy Fail, опубликованной 29 апреля, а также того, как работает эксплойт.
Предположительно, корень проблемы – коммит 72548b093ee3, добавленный в ядро Linux в 2017 году, который внедрил поддержку операций in-place для AEAD-шифрования в модуле algif_aead, что привело к дефекту обработки буферов.
Таким образом, уязвимость затрагивает ядра, выпущенные в период с 2017 по 2026 гг.
Под угрозой находятся как устаревшие серверные конфигурации, так и актуальные дистрибутивы: Ubuntu, RHEL, отдельные сборки WSL2 и другие системы с загруженным модулем algif_aead.
Рабочий эксплойт на Python (позже появились и на других языках) реализуется примерно десятью строками кода и использует штатные системные вызовы, которые неотличимы от нормального функционирования системы.
Минималистичный Python-скрипт (732 байта) через интерфейс AF_ALG и системный вызов splice() записывает четыре контролируемых байта в кэш, например, исполняемого файла с битом setuid.
В результате код программы изменяется непосредственно в оперативной памяти: при следующем запуске она выполняет вредоносные действия с правами суперпользователя.
При этом сам файл на диске остается неизменным, что позволяет обойти средства контроля целостности.
При этом уязвимость нельзя использовать удаленно – атакующему нужен локальный доступ к системе, однако этот дефект может быть использован в цепочке атаки, после получения RCE, или, например, внутренним злоумышленником.
Особую значимость уязвимость приобретает в контексте контейнерных сред.
По умолчанию технологии Docker, LXC и Kubernetes предоставляют процессам внутри контейнера доступ к подсистеме AF_ALG, если модуль algif_aead загружен в ядре хоста.
Таким образом, Copy Fail создает риск нарушения изоляции контейнера и получения контроля над физической машиной.
При этом эксплуатация не требует применения сложных техник, таких как race condition или подбор адресов в памяти, что снижает порог входа для потенциального атакующего.
Детектирование атаки затруднено тем, что эксплойт использует исключительно легитимные системные вызовы, которые сложно отличить от штатной работы приложений.
Исправление уже включено в стабильные ветки ядра Linux (коммит a664bf3d603d): разработчики устранили некорректную валидацию буферов при обработке криптографических операций in-place.
В случаях, когда оперативное обновление ядра невозможно, рекомендуется временно заблокировать загрузку модуля algif_aead.
Исследователи отмечают, что для уязвимости Copy Fail появляются новые эксплойты: помимо первоначальной реализации на языке Python, в открытых репозиториях уже зафиксированы рабочие варианты на языках Go и Rust.
Данные реализации могут использовать иные техники обхода защитных механизмов и варьировать последовательность системных вызовов, что требует адаптации правил детектирования, о которых подробно специалисты ЛК рассказали в отчете.
Кроме того, конечно же, выкатили технические подробности с разбором сути проблемы с неофициальным названием Copy Fail, опубликованной 29 апреля, а также того, как работает эксплойт.
Предположительно, корень проблемы – коммит 72548b093ee3, добавленный в ядро Linux в 2017 году, который внедрил поддержку операций in-place для AEAD-шифрования в модуле algif_aead, что привело к дефекту обработки буферов.
Таким образом, уязвимость затрагивает ядра, выпущенные в период с 2017 по 2026 гг.
Под угрозой находятся как устаревшие серверные конфигурации, так и актуальные дистрибутивы: Ubuntu, RHEL, отдельные сборки WSL2 и другие системы с загруженным модулем algif_aead.
Рабочий эксплойт на Python (позже появились и на других языках) реализуется примерно десятью строками кода и использует штатные системные вызовы, которые неотличимы от нормального функционирования системы.
Минималистичный Python-скрипт (732 байта) через интерфейс AF_ALG и системный вызов splice() записывает четыре контролируемых байта в кэш, например, исполняемого файла с битом setuid.
В результате код программы изменяется непосредственно в оперативной памяти: при следующем запуске она выполняет вредоносные действия с правами суперпользователя.
При этом сам файл на диске остается неизменным, что позволяет обойти средства контроля целостности.
При этом уязвимость нельзя использовать удаленно – атакующему нужен локальный доступ к системе, однако этот дефект может быть использован в цепочке атаки, после получения RCE, или, например, внутренним злоумышленником.
Особую значимость уязвимость приобретает в контексте контейнерных сред.
По умолчанию технологии Docker, LXC и Kubernetes предоставляют процессам внутри контейнера доступ к подсистеме AF_ALG, если модуль algif_aead загружен в ядре хоста.
Таким образом, Copy Fail создает риск нарушения изоляции контейнера и получения контроля над физической машиной.
При этом эксплуатация не требует применения сложных техник, таких как race condition или подбор адресов в памяти, что снижает порог входа для потенциального атакующего.
Детектирование атаки затруднено тем, что эксплойт использует исключительно легитимные системные вызовы, которые сложно отличить от штатной работы приложений.
Исправление уже включено в стабильные ветки ядра Linux (коммит a664bf3d603d): разработчики устранили некорректную валидацию буферов при обработке криптографических операций in-place.
В случаях, когда оперативное обновление ядра невозможно, рекомендуется временно заблокировать загрузку модуля algif_aead.
Исследователи отмечают, что для уязвимости Copy Fail появляются новые эксплойты: помимо первоначальной реализации на языке Python, в открытых репозиториях уже зафиксированы рабочие варианты на языках Go и Rust.
Данные реализации могут использовать иные техники обхода защитных механизмов и варьировать последовательность системных вызовов, что требует адаптации правил детектирования, о которых подробно специалисты ЛК рассказали в отчете.
Тем временем Trellix заявила о взломе, в результате которого был реализован несанкционированный доступ, как сообщается, к «части» ее исходного кода.
Trellix, принадлежащая Symphony Technology Group, была основана в январе 2022 года после слияния McAfee Enterprise и FireEye. Примерно в то же время Mandiant, принадлежавшая FireEye, была приобретена Google в рамках сделки стоимостью 5,4 миллиарда долларов.
В заявлении отмечается, что компания «недавно выявила» факт взлома своего репозитория исходного кода и приступила к сотрудничеству с «ведущими экспертами в области криминалистики» для немедленного решения проблемы, уведомив также правоохранительные органы.
Trellix не раскрыла точный характер данных, к которым могли получить доступ злоумышленники.
Однако заявила, что в результате предварительного расследования в Trellix не обнаружили никаких доказательств того, что процесс выпуска или распространения исходного кода был затронут или что наш исходный код был использован злоумышленниками.
Вместе с тем, компания не предоставила никаких подробностей о том, кто мог стоять за инцидентом и как долго злоумышленники имели доступ к ее системам. Trellix лишь заверила, что дополнительная информация будет предоставлена по мере необходимости после завершения расследования.
В ответ на запрос о комментариях представители Trellix подтвердили факт утечки и предоставили ровно те же официальные объяснения, которые были размещены на сайте компании. Но будем следить.
Trellix, принадлежащая Symphony Technology Group, была основана в январе 2022 года после слияния McAfee Enterprise и FireEye. Примерно в то же время Mandiant, принадлежавшая FireEye, была приобретена Google в рамках сделки стоимостью 5,4 миллиарда долларов.
В заявлении отмечается, что компания «недавно выявила» факт взлома своего репозитория исходного кода и приступила к сотрудничеству с «ведущими экспертами в области криминалистики» для немедленного решения проблемы, уведомив также правоохранительные органы.
Trellix не раскрыла точный характер данных, к которым могли получить доступ злоумышленники.
Однако заявила, что в результате предварительного расследования в Trellix не обнаружили никаких доказательств того, что процесс выпуска или распространения исходного кода был затронут или что наш исходный код был использован злоумышленниками.
Вместе с тем, компания не предоставила никаких подробностей о том, кто мог стоять за инцидентом и как долго злоумышленники имели доступ к ее системам. Trellix лишь заверила, что дополнительная информация будет предоставлена по мере необходимости после завершения расследования.
В ответ на запрос о комментариях представители Trellix подтвердили факт утечки и предоставили ровно те же официальные объяснения, которые были размещены на сайте компании. Но будем следить.
Trellix
Important Update From Trellix
Раскрыты подробности нового типа атаки ConsentFix v3, позиционируемый в киберподполье как усовершенствованная методика автоматизации атак на Microsoft Azure.
Первая версия ConsentFix была представлена Push Security в декабре прошлого года как вариант ClickFix для фишинговых атак OAuth, который обманом заставляет жертв пройти легитимный процесс входа в систему Microsoft через Azure CLI.
Используя методы социнженерии, злоумышленник обманом заставил жертв вставить URL-адрес localhost, содержащий код авторизации OAuth, который можно использовать для получения токенов и взлома учетной записи без паролей, несмотря на MFA.
ConsentFix v2 был разработан исследователем Джоном Хаммондом как усовершенствованная версия оригинального решения Push Security, заменяющая ручное копирование/вставку перетаскиванием URL-адреса localhost, что делает фишинговый процесс более плавным и убедительным.
При этом ConsentFix v3 сохраняет основную идею злоупотребления потоком авторизационного кода OAuth2 и нацелен на собственные приложения Microsoft, которые уже получили предварительное доверие и согласие, что оказалось лучше за счет внедрения автоматизации и масштабируемости.
Атака начинается с проверки наличия Azure в целевой среде путем проверки наличия действительных идентификаторов арендаторов. Затем следует сбор данных о сотрудниках, включая имена, должности и адреса электронной почты, для подтверждения возможности выдачи себя за другое лицо.
Далее злоумышленники создают множество учетных записей в таких сервисах, как Outlook, Tutanota, Cloudflare, DocSend, Hunter.io и Pipedream, для проведения фишинговых атак, размещения контента, сбора данных и эксфильтрации информации.
Исследователи Push Security объясняют, что Pipedream, платформа для бессерверной интеграции, выполняет центральную роль в автоматизации атаки, выполняя критически важные функции.
На следующем этапе злоумышленник развертывает фишинговую страницу на Cloudflare Pages, которая имитирует легитимный интерфейс Microsoft/Azure и инициирует реальный поток аутентификации OAuth через конечную точку входа Microsoft.
Когда жертва взаимодействует со страницей, перенаправляется на локальный URL-адрес, содержащий код авторизации OAuth, который её обманом заставляют вставить или перетащить обратно на фишинговую страницу.
Это позволяет запустить конвейер по извлечению данных, в рамках которого страница отправляет захваченный URL-адрес на веб-перехватчик Pipedream, а автоматизация на бэкэнде немедленно обменивает код авторизации на токены.
Фишинговые электронные письма могут быть очень персонализированными, генерироваться на основе собранных данных и содержать вредоносные ссылки, встроенные в PDF-файл, размещенный на DocSend, для повышения доверия и обхода спам-фильтров.
На этапе после взлома полученные токены импортируются в Specter Portal, что позволяет злоумышленнику взаимодействовать со скомпрометированными средами Microsoft и получать доступ к ресурсам, разрешенным токеном, таким как электронная почта, файлы и другие службы, связанные с учетной записью.
Push Security отметила, что тестирование ConsentFix v3 проводилось с использованием личных учетных записей Microsoft. Так что в результате сложно в полной мере оценить влияние, которое зависит от разрешений, служб и настроек клиента, а также от других факторов.
Хотя атаки ConsentFix используются в реальных кампаниях, неясно, получила ли версия v3 уже какое-либо реальное распространение среди киберпреступников.
Первая версия ConsentFix была представлена Push Security в декабре прошлого года как вариант ClickFix для фишинговых атак OAuth, который обманом заставляет жертв пройти легитимный процесс входа в систему Microsoft через Azure CLI.
Используя методы социнженерии, злоумышленник обманом заставил жертв вставить URL-адрес localhost, содержащий код авторизации OAuth, который можно использовать для получения токенов и взлома учетной записи без паролей, несмотря на MFA.
ConsentFix v2 был разработан исследователем Джоном Хаммондом как усовершенствованная версия оригинального решения Push Security, заменяющая ручное копирование/вставку перетаскиванием URL-адреса localhost, что делает фишинговый процесс более плавным и убедительным.
При этом ConsentFix v3 сохраняет основную идею злоупотребления потоком авторизационного кода OAuth2 и нацелен на собственные приложения Microsoft, которые уже получили предварительное доверие и согласие, что оказалось лучше за счет внедрения автоматизации и масштабируемости.
Атака начинается с проверки наличия Azure в целевой среде путем проверки наличия действительных идентификаторов арендаторов. Затем следует сбор данных о сотрудниках, включая имена, должности и адреса электронной почты, для подтверждения возможности выдачи себя за другое лицо.
Далее злоумышленники создают множество учетных записей в таких сервисах, как Outlook, Tutanota, Cloudflare, DocSend, Hunter.io и Pipedream, для проведения фишинговых атак, размещения контента, сбора данных и эксфильтрации информации.
Исследователи Push Security объясняют, что Pipedream, платформа для бессерверной интеграции, выполняет центральную роль в автоматизации атаки, выполняя критически важные функции.
На следующем этапе злоумышленник развертывает фишинговую страницу на Cloudflare Pages, которая имитирует легитимный интерфейс Microsoft/Azure и инициирует реальный поток аутентификации OAuth через конечную точку входа Microsoft.
Когда жертва взаимодействует со страницей, перенаправляется на локальный URL-адрес, содержащий код авторизации OAuth, который её обманом заставляют вставить или перетащить обратно на фишинговую страницу.
Это позволяет запустить конвейер по извлечению данных, в рамках которого страница отправляет захваченный URL-адрес на веб-перехватчик Pipedream, а автоматизация на бэкэнде немедленно обменивает код авторизации на токены.
Фишинговые электронные письма могут быть очень персонализированными, генерироваться на основе собранных данных и содержать вредоносные ссылки, встроенные в PDF-файл, размещенный на DocSend, для повышения доверия и обхода спам-фильтров.
На этапе после взлома полученные токены импортируются в Specter Portal, что позволяет злоумышленнику взаимодействовать со скомпрометированными средами Microsoft и получать доступ к ресурсам, разрешенным токеном, таким как электронная почта, файлы и другие службы, связанные с учетной записью.
Push Security отметила, что тестирование ConsentFix v3 проводилось с использованием личных учетных записей Microsoft. Так что в результате сложно в полной мере оценить влияние, которое зависит от разрешений, служб и настроек клиента, а также от других факторов.
Хотя атаки ConsentFix используются в реальных кампаниях, неясно, получила ли версия v3 уже какое-либо реальное распространение среди киберпреступников.
Push Security
Investigating a new criminal toolkit for ConsentFix
Investigating a new criminal toolkit for ConsentFix being promoted on criminal forums.
Репортеры Известий продолжают выдавать всем известные явления за невъебенные новости, а админы канала Банкста по прежнему не умеют в фактчекинг, узнал SecAtor.
Эксперты нашего канала предупреждают об активизации у журналистов шишковидной железы, открывающий третий (нижний) глаз, позволяющий им смотреть незамутненно на окружающий мир.
Эксперты нашего канала предупреждают об активизации у журналистов шишковидной железы, открывающий третий (нижний) глаз, позволяющий им смотреть незамутненно на окружающий мир.
Telegram
Банкста
В даркнете начали продавать доступ к платформе для фишинговых рассылок под ключ, узнали «Известия». Инструмент предлагает услугу «полного цикла»: от создания и редактирования шаблонов писем до управления настройками почтового аккаунта и проверки на попадание…
Forwarded from Russian OSINT
Компания Google предоставила Министерству обороны США доступ к своему ИИ для работы в секретных сетях, по сути разрешив все законные способы его использования.
Ранее генеральный директор Anthropic Дарио Амодеи отказался предоставить правительству беспрепятственный доступ к своим ИИ-моделям и настоял на внедрении защитных механизмов, чтобы предотвратить их использование для создания смертоносного автономного оружия и массовой слежки внутри страны. В ответ Anthropic была признана «угрозой цепочке поставок», а президент Дональд Трамп приказал всем правительственным ведомствам прекратить использование чат-бота Claude. Anthropic оспорила это решение в суде.
Компания OpenAI подписала соглашение с Министерством обороны, как это сделала и xAI. Google стала третьей ИИ-компанией, которая попыталась обратить ситуацию с Anthropic в свою пользу. Google заключила эту сделку даже несмотря на то, что 950 ее сотрудников подписали открытое письмо с призывом последовать примеру Anthropic и не продавать ИИ Министерству обороны без аналогичных ограничений.
«Мы хотим видеть, как ИИ приносит пользу человечеству, а не используется в бесчеловечных или крайне вредных целях»
— говорится в письме, которое было отправлено сотрудниками генеральному директору Пичаи в понедельник.
Письмо подписали более 18 высокопоставленных сотрудников, включая руководителей направлений, директоров и вице-президентов.
👆Приметателен тот факт, что Google отказалась от участия в конкурсе Пентагона с призовым фондом в $100 млн на создание технологии для
OpenAI, Palantir и xAI входят в число компаний, отобранных для участия в конкурсе, который будет проходить в несколько этапов в течение шести месяцев. На более поздних этапах конкурса требуется разработать решения для «обмена данными и осведомленности о целях», а также концепцию полного цикла от «запуска до уничтожения».
Компания Anthropic PBC также подала заявку на участие в конкурсе, но не прошла отбор.
Please open Telegram to view this post
VIEW IN TELEGRAM
Критическая ошибка, получившая название Bleeding Llama, подвергает более 300 000 развертываний Ollama краже информации и может быть реализована удалённо, без аутентификации.
Ollama - это решение с открытым исходным кодом для запуска программ LLM на локальных машинах, пользующееся большой популярностью среди в качестве саморазмещаемого механизма вывода результатов ИИ.
По данным Cyera, уязвимость чтения за пределами допустимого диапазона в Ollama может быть использована для доступа к конфиденциальной информации, хранящейся в куче, включая подсказки, сообщения и переменные среды, в том числе ключи API, токены и секреты.
Уязвимость отслеживается как CVE-2026-7482 (CVSS 9.3) и затрагивает загрузчик моделей GGUF, который принимает предоставленный злоумышленником файл GGUF, содержащий объявленное смещение тензора и размер, превышающие длину файла.
При обработке файла датчик считывает данные за пределы выделенного буфера в куче, обращаясь к памяти, которая может содержать конфиденциальную информацию.
Затем злоумышленник может использовать встроенную в Ollama функцию отправки моделей для извлечения полученного файла - вместе с украденными данными из кучи - на сервер, контролируемый злоумышленником. Для всей атаки требуется всего три неаутентифицированных вызова API.
В Cyera пояснили, что Ollama запускается по умолчанию без аутентификации и отслеживает все сетевые интерфейсы, а это значит, что все доступные через Интернет экземпляры подвержены атакам.
Учитывая, что в открытом доступе в интернете находится около 300 000 серверов Ollama, эта уязвимость может быть оперативно и широко использована - без необходимости ввода учетных данных.
В зависимости от способа использования Ollama, успешная эксплуатация Bleeding Llama может привести к раскрытию взаимодействий пользователей, кода разработки, маршрутизируемых выходных данных инструментов и запросов, содержащих персональные данные и другую конфиденциальную информацию.
По данным Cyera, «любое развертывание, при котором Ollama доступна по сети без брандмауэра или прокси-сервера аутентификации перед ней», подвержено риску эксплуатации.
Уязвимость была устранена в версии Ollama 0.17.1, рекомендуется как можно скорее применить исправление и ограничить сетевой доступ к своим развертываниям. Развертывание прокси-сервера аутентификации и сегментация сети должны повысить безопасность.
Организациям также следует проводить аудит работающих экземпляров на предмет доступности из интернета и считать любой экземпляр, доступный из интернета, а также переменные среды и данные, проходящие через него, скомпрометированными.
Ollama - это решение с открытым исходным кодом для запуска программ LLM на локальных машинах, пользующееся большой популярностью среди в качестве саморазмещаемого механизма вывода результатов ИИ.
По данным Cyera, уязвимость чтения за пределами допустимого диапазона в Ollama может быть использована для доступа к конфиденциальной информации, хранящейся в куче, включая подсказки, сообщения и переменные среды, в том числе ключи API, токены и секреты.
Уязвимость отслеживается как CVE-2026-7482 (CVSS 9.3) и затрагивает загрузчик моделей GGUF, который принимает предоставленный злоумышленником файл GGUF, содержащий объявленное смещение тензора и размер, превышающие длину файла.
При обработке файла датчик считывает данные за пределы выделенного буфера в куче, обращаясь к памяти, которая может содержать конфиденциальную информацию.
Затем злоумышленник может использовать встроенную в Ollama функцию отправки моделей для извлечения полученного файла - вместе с украденными данными из кучи - на сервер, контролируемый злоумышленником. Для всей атаки требуется всего три неаутентифицированных вызова API.
В Cyera пояснили, что Ollama запускается по умолчанию без аутентификации и отслеживает все сетевые интерфейсы, а это значит, что все доступные через Интернет экземпляры подвержены атакам.
Учитывая, что в открытом доступе в интернете находится около 300 000 серверов Ollama, эта уязвимость может быть оперативно и широко использована - без необходимости ввода учетных данных.
В зависимости от способа использования Ollama, успешная эксплуатация Bleeding Llama может привести к раскрытию взаимодействий пользователей, кода разработки, маршрутизируемых выходных данных инструментов и запросов, содержащих персональные данные и другую конфиденциальную информацию.
По данным Cyera, «любое развертывание, при котором Ollama доступна по сети без брандмауэра или прокси-сервера аутентификации перед ней», подвержено риску эксплуатации.
Уязвимость была устранена в версии Ollama 0.17.1, рекомендуется как можно скорее применить исправление и ограничить сетевой доступ к своим развертываниям. Развертывание прокси-сервера аутентификации и сегментация сети должны повысить безопасность.
Организациям также следует проводить аудит работающих экземпляров на предмет доступности из интернета и считать любой экземпляр, доступный из интернета, а также переменные среды и данные, проходящие через него, скомпрометированными.
Cyera
Bleeding Llama: Critical Unauthenticated Memory Leak in Ollama
Cyera's research team discovered a critical memory-leak vulnerability in Ollama, the world's most popular platform for running large language models (LLMs) locally.
Исследователи Лаборатории Касперского предупреждают, что программное обеспечение DAEMON Tools заражено в результате широкомасштабной атаки на цепочку поставок.
Как отмечают исследователи, основываясь на многолетнем опыте анализа атак через цепочку поставок, злоумышленники организовали взлом DAEMON Tools весьма искусно.
В начале мая 2026 года в ЛК обнаружили, что установщики DAEMON Tools (в версиях с 12.5.0.2421 до 12.5.0.2434) для монтирования образов дисков заражены вредоносным кодом.
Анализ показал, что троянизированные версии распространяются с 8 апреля 2026 года. С разработчиками DAEMON Tools из компании AVB Disc Soft оперативно связались для принятия дальнейших мер по устранению последствий атаки.
Однако выявленная атака на цепочку поставок все еще продолжается. В обнаруженных вредоносных имплантах нашлись артефакты, указывающие на то, что злоумышленник, стоящий за этой атакой, говорит по-китайски.
Согласно телеметрии ЛК, с начала апреля произошло несколько тысяч попыток заражения через DAEMON Tools, затронувших частных лиц и организации более чем в 100 странах: большинство - в России, Бразилии, Турции, Испании, Германии, Франции, Италии и Китае.
Однако дальнейшее развертывание вредоносной нагрузки наблюдалось лишь на десятке зараженных машин, принадлежащих организациям из сферы торговли, науки, госуправления и производства, что указывает на целенаправленный характер атаки.
Злоумышленникам удалось скомпрометировать DTHelper.exe, DiscSoftBusServiceLite.exe и DTShellHlp.exe, которые находятся в каталоге, где установлено ПО DAEMON Tools. Примечательно, что все они имеют цифровую подпись AVB Disc Soft.
Бинарные файлы запускаются при старте компьютера и каждый раз активируется бэкдор, который встроен в код автозапуска, отвечающий за инициализацию среды CRT. Бэкдор работает в отдельном потоке, который используется для отправки GET-запросов на сервер злоумышленника.
Вредоносный сервер использует адрес, созданный 27 марта за неделю до начала атаки при помощи тайпсквоттинга легитимного доменного имени daemon-tools[.]cc, используемого для загрузки DAEMON Tools.
В ответ на отправленные запросы сервер может возвращать команду оболочки для выполнения через процесс cmd.exe. Данные shell-команды используются для загрузки и запуска исполняемой вредоносной нагрузки. В целом, обнаружено несколько типов таких нагрузок.
Первая нагрузка, которую развертывают злоумышленники, - это сборщик информации (Information collector), представляющий собой исполняемый файл .NET, используемый для сбора расширенной системной информации и профилирования зараженных машин.
Злоумышленники пытались также доставить другую вредоносную нагрузку на небольшое количество машин (около десятка) - минималистичный бэкдор. Его функциональность включает возможность загрузки файлов, выполнения shell-команд и запуска шеллкод-модулей в памяти.
Изучив способы использования минималистичного бэкдора злоумышленниками, в ЛК выяснили, что он применялся для развертывания более сложного импланта, который исследователи назвали QUIC RAT.
Он написан на C++, обфусцирован с помощью техники control flow flattening и статически линкован с библиотекой WolfSSL. Также в его секции data содержится тело легитимной библиотеки msquic.dll.
Поддерживает множество протоколов коммуникации с C2, включая HTTP, UDP, TCP, WSS, QUIC, DNS и HTTP/3. Его анализ всё ещё продолжается, однако в ЛК установили, что QUIC RAT способен внедрять вредоносные нагрузки в процессы notepad.exe и conhost.exe.
Все дополнительные подробности - в отчете.
Как отмечают исследователи, основываясь на многолетнем опыте анализа атак через цепочку поставок, злоумышленники организовали взлом DAEMON Tools весьма искусно.
В начале мая 2026 года в ЛК обнаружили, что установщики DAEMON Tools (в версиях с 12.5.0.2421 до 12.5.0.2434) для монтирования образов дисков заражены вредоносным кодом.
Анализ показал, что троянизированные версии распространяются с 8 апреля 2026 года. С разработчиками DAEMON Tools из компании AVB Disc Soft оперативно связались для принятия дальнейших мер по устранению последствий атаки.
Однако выявленная атака на цепочку поставок все еще продолжается. В обнаруженных вредоносных имплантах нашлись артефакты, указывающие на то, что злоумышленник, стоящий за этой атакой, говорит по-китайски.
Согласно телеметрии ЛК, с начала апреля произошло несколько тысяч попыток заражения через DAEMON Tools, затронувших частных лиц и организации более чем в 100 странах: большинство - в России, Бразилии, Турции, Испании, Германии, Франции, Италии и Китае.
Однако дальнейшее развертывание вредоносной нагрузки наблюдалось лишь на десятке зараженных машин, принадлежащих организациям из сферы торговли, науки, госуправления и производства, что указывает на целенаправленный характер атаки.
Злоумышленникам удалось скомпрометировать DTHelper.exe, DiscSoftBusServiceLite.exe и DTShellHlp.exe, которые находятся в каталоге, где установлено ПО DAEMON Tools. Примечательно, что все они имеют цифровую подпись AVB Disc Soft.
Бинарные файлы запускаются при старте компьютера и каждый раз активируется бэкдор, который встроен в код автозапуска, отвечающий за инициализацию среды CRT. Бэкдор работает в отдельном потоке, который используется для отправки GET-запросов на сервер злоумышленника.
Вредоносный сервер использует адрес, созданный 27 марта за неделю до начала атаки при помощи тайпсквоттинга легитимного доменного имени daemon-tools[.]cc, используемого для загрузки DAEMON Tools.
В ответ на отправленные запросы сервер может возвращать команду оболочки для выполнения через процесс cmd.exe. Данные shell-команды используются для загрузки и запуска исполняемой вредоносной нагрузки. В целом, обнаружено несколько типов таких нагрузок.
Первая нагрузка, которую развертывают злоумышленники, - это сборщик информации (Information collector), представляющий собой исполняемый файл .NET, используемый для сбора расширенной системной информации и профилирования зараженных машин.
Злоумышленники пытались также доставить другую вредоносную нагрузку на небольшое количество машин (около десятка) - минималистичный бэкдор. Его функциональность включает возможность загрузки файлов, выполнения shell-команд и запуска шеллкод-модулей в памяти.
Изучив способы использования минималистичного бэкдора злоумышленниками, в ЛК выяснили, что он применялся для развертывания более сложного импланта, который исследователи назвали QUIC RAT.
Он написан на C++, обфусцирован с помощью техники control flow flattening и статически линкован с библиотекой WolfSSL. Также в его секции data содержится тело легитимной библиотеки msquic.dll.
Поддерживает множество протоколов коммуникации с C2, включая HTTP, UDP, TCP, WSS, QUIC, DNS и HTTP/3. Его анализ всё ещё продолжается, однако в ЛК установили, что QUIC RAT способен внедрять вредоносные нагрузки в процессы notepad.exe и conhost.exe.
Все дополнительные подробности - в отчете.
Команда Positive Education из Positive Technologies совместно с SuperJob и the Edgers провели исследование, отследив трансформацию роли директора по ИБ.
Опросив CEO, CTO/CIO и CISO из разных отраслей - от финтеха до промышленности - аналитики выяснили, почему бизнес и кибербезопасность до сих пор говорят на разных языках.
Останавливаться в подробностях не будем, но отметим ключевые выводы:
- CISO оценивают собственную зрелость гораздо выше, чем их CEO
Как оказалось, более 40% CISO поставили себе 8-9 баллов из 10, некоторые считают, что уже переросли эту должность, и лишь 13,4% показали умеренную самокритику.
В свою очередь, только 25% CEO высоко оценивают компетенции коллег (7-10 баллов). 75% опрошенных поставили CISO низкие баллы или вообще не смогли их оценить.
- В каждой третьей компании не выстроен диалог между CEO и CISO
37,5% CEO отметили, что не взаимодействуют с CISO напрямую. Бизнес воспринимает ИБ как техническую функцию: 62,5% опрошенных CEO не ожидают от CISO активного участия в принятии стратегических решений.
- Инфобез и бизнес говорят на разных языках
CISO привыкли описывать риски с точки зрения уязвимостей и технических метрик. Топ-менеджмент же больше интересуют финансовые показатели и непрерывность процессов, поэтому 50% CEO отметили важность «понимания бизнеса» у ИБ-директоров.
- Диалогу мешает отсутствие понятных метрик
У каждого CISO свой формат отчета и логика презентации. Одни считают ROI и влияние на P&L, другие сравнивают ИБ-зрелость компании с конкурентами, третьи акцентируют внимание на покрытии инфраструктуры. Рынок еще не выработал единого формата измерения безопасности, который будет понятен бизнесу.
- Система образования не успевает за рынком
100% опрошенных сходятся в одном: существующие программы обучения не помогают решить наболевшие проблемы. Программы для CISO фокусируются на нормативке и отдельных продуктах, но не учат интегрировать ИБ в стратегию компании и ясно доносить ценность кибербеза до совета директоров.
В целом, аналитики резюмировали: роль CISO проходит точку невозврата. Рынку требуется новый тип CISO - руководитель, способный перевести риски ИБ на язык бизнеса и интегрировать кибербез в стратегию компании.
Причем запрос на изменения поступает сразу с двух сторон: топы хотят видеть в ИБ-директоре бизнес-партнера, а сами CISO чувствуют, что переросли «техническую функцию». Но трансформация потребует новых компетенций.
Все детали - в отчете.
Опросив CEO, CTO/CIO и CISO из разных отраслей - от финтеха до промышленности - аналитики выяснили, почему бизнес и кибербезопасность до сих пор говорят на разных языках.
Останавливаться в подробностях не будем, но отметим ключевые выводы:
- CISO оценивают собственную зрелость гораздо выше, чем их CEO
Как оказалось, более 40% CISO поставили себе 8-9 баллов из 10, некоторые считают, что уже переросли эту должность, и лишь 13,4% показали умеренную самокритику.
В свою очередь, только 25% CEO высоко оценивают компетенции коллег (7-10 баллов). 75% опрошенных поставили CISO низкие баллы или вообще не смогли их оценить.
- В каждой третьей компании не выстроен диалог между CEO и CISO
37,5% CEO отметили, что не взаимодействуют с CISO напрямую. Бизнес воспринимает ИБ как техническую функцию: 62,5% опрошенных CEO не ожидают от CISO активного участия в принятии стратегических решений.
- Инфобез и бизнес говорят на разных языках
CISO привыкли описывать риски с точки зрения уязвимостей и технических метрик. Топ-менеджмент же больше интересуют финансовые показатели и непрерывность процессов, поэтому 50% CEO отметили важность «понимания бизнеса» у ИБ-директоров.
- Диалогу мешает отсутствие понятных метрик
У каждого CISO свой формат отчета и логика презентации. Одни считают ROI и влияние на P&L, другие сравнивают ИБ-зрелость компании с конкурентами, третьи акцентируют внимание на покрытии инфраструктуры. Рынок еще не выработал единого формата измерения безопасности, который будет понятен бизнесу.
- Система образования не успевает за рынком
100% опрошенных сходятся в одном: существующие программы обучения не помогают решить наболевшие проблемы. Программы для CISO фокусируются на нормативке и отдельных продуктах, но не учат интегрировать ИБ в стратегию компании и ясно доносить ценность кибербеза до совета директоров.
В целом, аналитики резюмировали: роль CISO проходит точку невозврата. Рынку требуется новый тип CISO - руководитель, способный перевести риски ИБ на язык бизнеса и интегрировать кибербез в стратегию компании.
Причем запрос на изменения поступает сразу с двух сторон: топы хотят видеть в ИБ-директоре бизнес-партнера, а сами CISO чувствуют, что переросли «техническую функцию». Но трансформация потребует новых компетенций.
Все детали - в отчете.
Forwarded from Russian OSINT
Компания Progress Software раскрыла информацию об уязвимости обхода аутентификации CVE-2026-4670 в MOVEit Automation — компоненте для планирования и оркестровки рабочих процессов в семействе продуктов для управляемой передачи файлов MOVEit. Progress описывает эту проблему и сопутствующую уязвимость CVE-2026-5174 совместно: «Критическая и высокая уязвимости в MOVEit Automation могут позволить обойти аутентификацию и повысить привилегии через интерфейсы командного порта бэкенда сервиса». Согласно NVD, Progress присваивает уязвимости CVE-2026-4670 базовую оценку CVSS v3.1
Обе уязвимости CVE объединены в бюллетене, но Progress не заявляет прямо, что одна ошибка позволяет эксплуатировать другую.
Мы не видели публичных доказательств концепции (Proof of Concept), демонстрирующих их использование в цепочке.
— пишет Сensys.
На момент раскрытия информации об активной эксплуатации не сообщалось. Уязвимость отсутствует в каталоге CISA KEV.
Please open Telegram to view this post
VIEW IN TELEGRAM
Palo Alto Networks предупреждает клиентов о критической, до настоящего времени неисправленной уязвимости в портале аутентификации пользователей PAN-OS, которая активно при этом используется в атаках.
User-ID Authentication Portal, также известный как Captive Portal, обеспечивает функцию безопасности PAN-OS, которая аутентифицирует пользователей, чьи идентификаторы не могут быть автоматически сопоставлены межсетевым экраном.
Упомянутая 0-day, CVE-2026-0300, связана с переполнением буфера и позволяет неавторизованным злоумышленникам выполнять произвольный код с правами root на межсетевых экранах PA-Series и VM-Series, доступных из Интернета, с помощью специально сформированных пакетов.
Согласно сообщению Palo Alto Networks, зафиксированы ограниченные случаи эксплуатации уязвимостей в порталах аутентификации пользователей Palo Alto Networks User-ID, которые используют ненадежные IP-адреса и/или общедоступный интернет.
Клиенты, соблюдающие стандартные рекомендации по обеспечению безопасности, такие как ограничение доступа к конфиденциальным порталам только для доверенных внутренних сетей, не подвергаются значительному риску.
В настоящий момент Shadowserver фиксирует более 5800 межсетевых экранов серии PAN-OS VM в глобальной сети, большинство из которых расположены в Азии (2466) и Северной Америке (1998).
Palo Alto Networks также присвоила уязвимости наивысшую возможную степень серьезности и работает над ее устранением.
До появления патча настоятельно рекомендует клиентам защитить портал аутентификации пользователей, ограничив доступ только к доверенным зонам или отключив портал, если это невозможно.
Стоит отметить, что межсетевые экраны PAN-OS часто становились мишенью атак, зачастую с использованием 0-day.
Как например, в ноябре 2024 года, когда Shadowserver сообщала о взломе тысяч межсетевых экранов (компания заявила, что атаки затронули лишь «очень небольшое количество устройств») в результате атак с использованием двух 0-day в межсетевых экранах PAN-OS.
Тогда месяц спустя Palo Alto Networks предупредила, что хакеры используют еще одну уязвимость DoS в PAN-OS для атаки на межсетевые экраны серий PA, VM и CN, вынуждая их перезагружать и отключать защиту межсетевого экрана.
Вскоре после этого, в феврале, злоумышленники переключились на использование трех других уязвимостей PAN-OS для компрометации межсетевых экранов Palo Alto Networks с интерфейсами управления, доступными из интернета.
Впрочем, неудивительно, ведь среди любителей PAN-OS’а более 70 000 клиентов по всему миру, включая 90% компаний из списка Fortune 10 и большинство крупнейших банков США.
User-ID Authentication Portal, также известный как Captive Portal, обеспечивает функцию безопасности PAN-OS, которая аутентифицирует пользователей, чьи идентификаторы не могут быть автоматически сопоставлены межсетевым экраном.
Упомянутая 0-day, CVE-2026-0300, связана с переполнением буфера и позволяет неавторизованным злоумышленникам выполнять произвольный код с правами root на межсетевых экранах PA-Series и VM-Series, доступных из Интернета, с помощью специально сформированных пакетов.
Согласно сообщению Palo Alto Networks, зафиксированы ограниченные случаи эксплуатации уязвимостей в порталах аутентификации пользователей Palo Alto Networks User-ID, которые используют ненадежные IP-адреса и/или общедоступный интернет.
Клиенты, соблюдающие стандартные рекомендации по обеспечению безопасности, такие как ограничение доступа к конфиденциальным порталам только для доверенных внутренних сетей, не подвергаются значительному риску.
В настоящий момент Shadowserver фиксирует более 5800 межсетевых экранов серии PAN-OS VM в глобальной сети, большинство из которых расположены в Азии (2466) и Северной Америке (1998).
Palo Alto Networks также присвоила уязвимости наивысшую возможную степень серьезности и работает над ее устранением.
До появления патча настоятельно рекомендует клиентам защитить портал аутентификации пользователей, ограничив доступ только к доверенным зонам или отключив портал, если это невозможно.
Стоит отметить, что межсетевые экраны PAN-OS часто становились мишенью атак, зачастую с использованием 0-day.
Как например, в ноябре 2024 года, когда Shadowserver сообщала о взломе тысяч межсетевых экранов (компания заявила, что атаки затронули лишь «очень небольшое количество устройств») в результате атак с использованием двух 0-day в межсетевых экранах PAN-OS.
Тогда месяц спустя Palo Alto Networks предупредила, что хакеры используют еще одну уязвимость DoS в PAN-OS для атаки на межсетевые экраны серий PA, VM и CN, вынуждая их перезагружать и отключать защиту межсетевого экрана.
Вскоре после этого, в феврале, злоумышленники переключились на использование трех других уязвимостей PAN-OS для компрометации межсетевых экранов Palo Alto Networks с интерфейсами управления, доступными из интернета.
Впрочем, неудивительно, ведь среди любителей PAN-OS’а более 70 000 клиентов по всему миру, включая 90% компаний из списка Fortune 10 и большинство крупнейших банков США.
Palo Alto Networks Product Security Assurance
CVE-2026-0300 PAN-OS: Unauthenticated user initiated Buffer Overflow Vulnerability in User-ID™ Authentication Portal
A buffer overflow vulnerability in the User-ID™ Authentication Portal (aka Captive Portal) service of Palo Alto Networks PAN-OS software allows an unauthenticated attacker to execute arbitrary code wi...
Ранее недокуметированная вредоносная ПО для Linux под названием Quasar Linux (QLNX) нацелена на системы разработчиков и использует сочетание руткита, бэкдора и возможностей кражи учетных данных.
Набор вредоносных ПО развертывается в средах разработки и DevOps на платформах npm, PyPI, GitHub, AWS, Docker и Kubernetes, что позволяет осуществлять атаки на цепочки поставок.
Исследователи Trend Micro проанализировали имплантат QLNX и обнаружили, что «он динамически компилирует разделяемые объекты руткитов и модули бэкдора PAM на целевом хосте с помощью GNU Compiler Collection.
Согласно отчету, QLNX был разработан для скрытного доступа и долговременного сохранения данных, поскольку работает в оперативной памяти, удаляет исходный исполняемый файл, чистит журналы, подменяет имена процессов и сбрасывает переменные среды для криминалистического анализа.
Вредоносная ПО использует семь различных механизмов обеспечения постоянного присутствия в системе, включая LD_PRELOAD, systemd, crontab, скрипты init.d, автозапуск XDG и внедрение .bashrc, гарантируя, что загрузку в каждый динамически связанный процесс и перезапуск после его завершения.
QLNX включает в себя множество функциональных блоков, предназначенных для выполнения конкретных задач, что делает его полноценным инструментом для атак. Основные компоненты можно описать следующим образом:
- RAT core - центральный компонент управления, построенный на основе структуры из 58 команд, обеспечивающий интерактивный доступ к командной оболочке, управление файлами и процессами, управление системой и сетевые операции, при этом поддерживая постоянную связь с C2 по пользовательским каналам TCP/TLS или HTTP/S.
- Руткит - двухуровневый механизм скрытности, сочетающий в себе руткит пользовательского пространства LD_PRELOAD и компонент eBPF на уровне ядра.
Пользовательский слой перехватывает функции libc для скрытия файлов, процессов и артефактов вредоносного ПО, в то время как слой eBPF скрывает PID, пути к файлам и сетевые порты на уровне ядра. Оба компонента развертываются динамически, при этом руткит пользовательского пространства компилируется в целевой системе.
- Доступ к учетным данным - сочетает в себе сбор учетных данных (SSH-ключи, браузеры, облачные и пользовательские конфигурации, /etc/shadow, буфер обмена) с бэкдорами на основе PAM, которые перехватывают и записывают в журнал данные аутентификации в открытом виде.
- Модуль наблюдения - перехват нажатий клавиш, создание скриншотов и мониторинг буфера обмена.
- Сетевые технологии и горизонтальное перемещение - туннелирование TCP, прокси SOCKS, сканирование портов, горизонтальное перемещение на основе SSH и одноранговые ячеистые сети.
- Механизм выполнения и внедрения - внедрение процессов (ptrace, /proc/pid/mem) и выполнение полезных нагрузок в оперативной памяти (разделяемые объекты, BOF/COFF).
- Мониторинг файловой системы - отслеживание активности файлов в реальном времени с помощью inotify.
После первоначального доступа QLNX создает бесфайловую базу, развертывает механизмы обеспечения постоянного присутствия и скрытности, а затем собирает учетные данные разработчиков и облачных сервисов.
Атакуя рабочие станции разработчиков, злоумышленники могут обойти корпоративные средства защиты и получить доступ к учетным данным, лежащим в основе конвейеров доставки ПО.
Trend Micro не предоставила подробностей по конкретным атакам или автору QLNX, но отметила IOCs.
Набор вредоносных ПО развертывается в средах разработки и DevOps на платформах npm, PyPI, GitHub, AWS, Docker и Kubernetes, что позволяет осуществлять атаки на цепочки поставок.
Исследователи Trend Micro проанализировали имплантат QLNX и обнаружили, что «он динамически компилирует разделяемые объекты руткитов и модули бэкдора PAM на целевом хосте с помощью GNU Compiler Collection.
Согласно отчету, QLNX был разработан для скрытного доступа и долговременного сохранения данных, поскольку работает в оперативной памяти, удаляет исходный исполняемый файл, чистит журналы, подменяет имена процессов и сбрасывает переменные среды для криминалистического анализа.
Вредоносная ПО использует семь различных механизмов обеспечения постоянного присутствия в системе, включая LD_PRELOAD, systemd, crontab, скрипты init.d, автозапуск XDG и внедрение .bashrc, гарантируя, что загрузку в каждый динамически связанный процесс и перезапуск после его завершения.
QLNX включает в себя множество функциональных блоков, предназначенных для выполнения конкретных задач, что делает его полноценным инструментом для атак. Основные компоненты можно описать следующим образом:
- RAT core - центральный компонент управления, построенный на основе структуры из 58 команд, обеспечивающий интерактивный доступ к командной оболочке, управление файлами и процессами, управление системой и сетевые операции, при этом поддерживая постоянную связь с C2 по пользовательским каналам TCP/TLS или HTTP/S.
- Руткит - двухуровневый механизм скрытности, сочетающий в себе руткит пользовательского пространства LD_PRELOAD и компонент eBPF на уровне ядра.
Пользовательский слой перехватывает функции libc для скрытия файлов, процессов и артефактов вредоносного ПО, в то время как слой eBPF скрывает PID, пути к файлам и сетевые порты на уровне ядра. Оба компонента развертываются динамически, при этом руткит пользовательского пространства компилируется в целевой системе.
- Доступ к учетным данным - сочетает в себе сбор учетных данных (SSH-ключи, браузеры, облачные и пользовательские конфигурации, /etc/shadow, буфер обмена) с бэкдорами на основе PAM, которые перехватывают и записывают в журнал данные аутентификации в открытом виде.
- Модуль наблюдения - перехват нажатий клавиш, создание скриншотов и мониторинг буфера обмена.
- Сетевые технологии и горизонтальное перемещение - туннелирование TCP, прокси SOCKS, сканирование портов, горизонтальное перемещение на основе SSH и одноранговые ячеистые сети.
- Механизм выполнения и внедрения - внедрение процессов (ptrace, /proc/pid/mem) и выполнение полезных нагрузок в оперативной памяти (разделяемые объекты, BOF/COFF).
- Мониторинг файловой системы - отслеживание активности файлов в реальном времени с помощью inotify.
После первоначального доступа QLNX создает бесфайловую базу, развертывает механизмы обеспечения постоянного присутствия и скрытности, а затем собирает учетные данные разработчиков и облачных сервисов.
Атакуя рабочие станции разработчиков, злоумышленники могут обойти корпоративные средства защиты и получить доступ к учетным данным, лежащим в основе конвейеров доставки ПО.
Trend Micro не предоставила подробностей по конкретным атакам или автору QLNX, но отметила IOCs.
Trend Micro
Quasar Linux (QLNX) – A Silent Foothold in the Supply Chain: Inside a Full-Featured Linux RAT With Rootkit, PAM Backdoor, Credential…
TrendAI™ Research breaks down Quasar Linux (QLNX), a previously undocumented sophisticated Linux RAT with low detection rates. In this blog, we examine a full-featured Linux threat incorporating a rootkit, a PAM backdoor, credential harvesting, and more,…
Китайская Silver Fox (Monarch, SwimSnake, The Great Thief of Valley, UTG-Q-1000 и Void Arachne) связана с новой кампанией, нацеленной на организаций в России и Индии с использованием нового вредоносного ПО ABCDoor.
В рамках нее задействовались фишинговые письма, имитирующие переписку с Налоговым управлением Индии в декабре 2025 года, за которыми последовала аналогичная кампания, направленная на российские организации уже в январе 2026 года.
Активность задетектили исследователи Лаборатории Касперского, отметившие, что обе волны атак имели практически идентичную структуру: фишинговые письма были оформлены как официальные уведомления о налоговых проверках или предлагали пользователям загрузить архив, содержащий «список налоговых нарушений».
Внутри архива находился модифицированный загрузчик на основе Rust из общедоступного репозитория, который загружал и запускал хорошо известный бэкдор ValleyRAT.
Кампания затронула организации в промышленном, консалтинговом, розничном и транспортном секторах. В период с начала января по начало февраля было выявлено более 1600 писем.
На этот раз был замечен новый плагин ValleyRAT, который функционирует как загрузчик для ранее недокументированного бэкдора на основе Python под названием ABCDoor, который находится в арсенале злоумышленников как минимум с 19 декабря 2024 года и использовался в кибератаках начиная с февраля или марта 2025 года.
Цепочка атак начинается фишингового письма с PDF-файлом и двумя кликабельными ссылками, ведущими к загрузке ZIP или RAR с abc.haijing88[.]com. В кампании от декабря 2025, вредоносный код был внедрен непосредственно в файлы из электронного письма.
В архиве находится исполняемый файл, имитирующий PDF. Бинарный файл представляет собой модифицированную версию открытого загрузчика шеллкода и фреймворка для обхода антивирусов RustSL. Его первое использование Silver Fox относится к концу декабря 2025.
Конечная цель варианта Silver Fox RustSL - расшифровать вредоносный код, а также реализовать геозонирование по странам и проверку среды для обнаружения виртуальных машин и песочниц.
В то время как вариант GitHub включает в свой список стран только Китай, в специализированной версии присутствуют Индия, Индонезия, Южная Африка, Россия и Камбоджа.
Один из вариантов загрузчика использует новый метод, называемый «фантомным сохранением», для обеспечения постоянного присутствия на скомпрометированном хосте. Впервые он был задокументирован в июне 2025 года.
Метод полагается на функциональность, предназначенную для обеспечения корректного завершения процесса установки приложений, требующих перезагрузки для обновления.
Зашифрованная полезная нагрузка приводит к загрузке зашифрованного вредоносного ПО ValleyRAT (Winos 4.0), основной компонент которого (login-module.dll_bin) отвечает за связь с C2, выполнение команд, а также получение и выполнение дополнительных модулей.
Один из них, развернутых после второй проверки геозонирования, - это ABCDoor, который связывается с внешним сервером по протоколу HTTPS и обрабатывает входящие сообщения для постоянного присутствия в системе, обработки обновлений и удаления бэкдоров, сбора данных, выполнения операций с файлами, управления мышью и клавиатурой, системными процессами и извлечения содержимого буфера.
Еще в ноябре 2025 года Silver Fox использовала JavaScript-загрузчик для распространения ABCDoor, причём загрузчик распространялся через SFX архивы, упакованные в ZIP, предположительно ,рассылаемые в фишинговых письмах. Более новые версии RustSL с тех пор расширили географический охват, включив в него Японию.
Наибольшее количество атак зафиксировано в Индии, России и Индонезии, за которыми следуют Южная Африка и Япония. В большинстве обнаруженных образцов вредоносного ПО использовались приманки, связанные с налогами, для имитации последовательности заражения.
Все технические подробности - в отчете.
В рамках нее задействовались фишинговые письма, имитирующие переписку с Налоговым управлением Индии в декабре 2025 года, за которыми последовала аналогичная кампания, направленная на российские организации уже в январе 2026 года.
Активность задетектили исследователи Лаборатории Касперского, отметившие, что обе волны атак имели практически идентичную структуру: фишинговые письма были оформлены как официальные уведомления о налоговых проверках или предлагали пользователям загрузить архив, содержащий «список налоговых нарушений».
Внутри архива находился модифицированный загрузчик на основе Rust из общедоступного репозитория, который загружал и запускал хорошо известный бэкдор ValleyRAT.
Кампания затронула организации в промышленном, консалтинговом, розничном и транспортном секторах. В период с начала января по начало февраля было выявлено более 1600 писем.
На этот раз был замечен новый плагин ValleyRAT, который функционирует как загрузчик для ранее недокументированного бэкдора на основе Python под названием ABCDoor, который находится в арсенале злоумышленников как минимум с 19 декабря 2024 года и использовался в кибератаках начиная с февраля или марта 2025 года.
Цепочка атак начинается фишингового письма с PDF-файлом и двумя кликабельными ссылками, ведущими к загрузке ZIP или RAR с abc.haijing88[.]com. В кампании от декабря 2025, вредоносный код был внедрен непосредственно в файлы из электронного письма.
В архиве находится исполняемый файл, имитирующий PDF. Бинарный файл представляет собой модифицированную версию открытого загрузчика шеллкода и фреймворка для обхода антивирусов RustSL. Его первое использование Silver Fox относится к концу декабря 2025.
Конечная цель варианта Silver Fox RustSL - расшифровать вредоносный код, а также реализовать геозонирование по странам и проверку среды для обнаружения виртуальных машин и песочниц.
В то время как вариант GitHub включает в свой список стран только Китай, в специализированной версии присутствуют Индия, Индонезия, Южная Африка, Россия и Камбоджа.
Один из вариантов загрузчика использует новый метод, называемый «фантомным сохранением», для обеспечения постоянного присутствия на скомпрометированном хосте. Впервые он был задокументирован в июне 2025 года.
Метод полагается на функциональность, предназначенную для обеспечения корректного завершения процесса установки приложений, требующих перезагрузки для обновления.
Зашифрованная полезная нагрузка приводит к загрузке зашифрованного вредоносного ПО ValleyRAT (Winos 4.0), основной компонент которого (login-module.dll_bin) отвечает за связь с C2, выполнение команд, а также получение и выполнение дополнительных модулей.
Один из них, развернутых после второй проверки геозонирования, - это ABCDoor, который связывается с внешним сервером по протоколу HTTPS и обрабатывает входящие сообщения для постоянного присутствия в системе, обработки обновлений и удаления бэкдоров, сбора данных, выполнения операций с файлами, управления мышью и клавиатурой, системными процессами и извлечения содержимого буфера.
Еще в ноябре 2025 года Silver Fox использовала JavaScript-загрузчик для распространения ABCDoor, причём загрузчик распространялся через SFX архивы, упакованные в ZIP, предположительно ,рассылаемые в фишинговых письмах. Более новые версии RustSL с тех пор расширили географический охват, включив в него Японию.
Наибольшее количество атак зафиксировано в Индии, России и Индонезии, за которыми следуют Южная Африка и Япония. В большинстве обнаруженных образцов вредоносного ПО использовались приманки, связанные с налогами, для имитации последовательности заражения.
Все технические подробности - в отчете.
Продолжаем отслеживать наиболее важные уязвимости и связанные с ними угрозы, на текущий момент ситуация следующая:
1. В Android исправлена критическая RCE-уязвимость, CVE-2026-0073, которая затрагивает системный компонент ОС и может быть использована для выполнения кода от имени пользователя командной оболочки без дополнительных привилегий на выполнение без взаимодействия с пользователем.
Проблема затрагивает adbd (Android Debug Bridge daemon), фоновый процесс, работающий на устройствах Android и управляющий связью между устройством и компьютером, обеспечивая отладку и доступ к командной оболочке.
Пока каких-либо признаков того, что уязвимость CVE-2026-0073 использовалась в вредоносных атаках нет, но это только пока.
2. Apache выпустила исправления для более чем десятка уязвимостей в HTTP Server и MINA, включая критические и серьезные проблемы, которые могли быть использованы для RCE.
В Apache HTTP Server 2.4.67 исправлено для 11 уязвимостей, 10 из которых затрагивают все предыдущие версии.
Первая уязвимость - CVE-2026-23918, представляет собой ошибку двойного освобождения памяти и потенциальное удаленное выполнение кода в протоколе HTTP/2. Инициируя преждевременное сброс, злоумышленник может вызвать DoS и потенциально выполнить произвольный код.
Другая, CVE-2026-28780, проблема переполнения буфера в куче, которая может позволить удаленным злоумышленникам отправлять специально сформированные AJP-сообщения, вызывая DoS и выполняя код.
Три других уязвимости безопасности, CVE-2026-29168, CVE-2026-29169 и CVE-2026-33007, могут привести к DoS, а еще четыре (CVE-2026-24072, CVE-2026-33857, CVE-2026-34032 и CVE-2026-34059) - могут привести к раскрытию информации.
Обновление также устраняет проблему некорректной нейтрализации последовательностей CRLF (CVE-2026-33523), которая позволяет манипулировать HTTP-ответами, и уязвимость, связанную с использованием побочных каналов по времени (CVE-2026-33006), которая может привести к обходу аутентификации Digest.
Кроме того, Apache объявила о выпуске обновлений MINA 2.2.7 и MINA 2.1.12, содержащих исправления для двух критических уязвимостей - CVE-2026-42778 и CVE-2026-42779.
Первая - это неполное исправление для CVE-2026-41409, которая, в свою очередь, является неполным исправлением для CVE-2024-52046, небезопасной десериализации данных, которая может быть использована для RCE.
Вторая - неполное исправление для CVE-2026-41635, представляющей собой некорректную ошибку проверки, приводящую к обходу списка разрешенных объектов и выполнению кода.
3. VulnCheck сообщает, что злоумышленники активно используют критическую CVE-2026-29014 (CVSS: 9,8) в CMS с открытым исходным кодом MetInfo.
Она затрагивает MetInfo CMS 7.9, 8.0 и 8.1 и позволяет удаленным злоумышленникам выполнять произвольный код, отправляя специально сформированные запросы со вредоносным PHP-кодом.
Злоумышленники могут использовать недостаточную нейтрализацию входных данных в процессе выполнения кода для RCE и получения полного контроля над затронутым сервером.
1. В Android исправлена критическая RCE-уязвимость, CVE-2026-0073, которая затрагивает системный компонент ОС и может быть использована для выполнения кода от имени пользователя командной оболочки без дополнительных привилегий на выполнение без взаимодействия с пользователем.
Проблема затрагивает adbd (Android Debug Bridge daemon), фоновый процесс, работающий на устройствах Android и управляющий связью между устройством и компьютером, обеспечивая отладку и доступ к командной оболочке.
Пока каких-либо признаков того, что уязвимость CVE-2026-0073 использовалась в вредоносных атаках нет, но это только пока.
2. Apache выпустила исправления для более чем десятка уязвимостей в HTTP Server и MINA, включая критические и серьезные проблемы, которые могли быть использованы для RCE.
В Apache HTTP Server 2.4.67 исправлено для 11 уязвимостей, 10 из которых затрагивают все предыдущие версии.
Первая уязвимость - CVE-2026-23918, представляет собой ошибку двойного освобождения памяти и потенциальное удаленное выполнение кода в протоколе HTTP/2. Инициируя преждевременное сброс, злоумышленник может вызвать DoS и потенциально выполнить произвольный код.
Другая, CVE-2026-28780, проблема переполнения буфера в куче, которая может позволить удаленным злоумышленникам отправлять специально сформированные AJP-сообщения, вызывая DoS и выполняя код.
Три других уязвимости безопасности, CVE-2026-29168, CVE-2026-29169 и CVE-2026-33007, могут привести к DoS, а еще четыре (CVE-2026-24072, CVE-2026-33857, CVE-2026-34032 и CVE-2026-34059) - могут привести к раскрытию информации.
Обновление также устраняет проблему некорректной нейтрализации последовательностей CRLF (CVE-2026-33523), которая позволяет манипулировать HTTP-ответами, и уязвимость, связанную с использованием побочных каналов по времени (CVE-2026-33006), которая может привести к обходу аутентификации Digest.
Кроме того, Apache объявила о выпуске обновлений MINA 2.2.7 и MINA 2.1.12, содержащих исправления для двух критических уязвимостей - CVE-2026-42778 и CVE-2026-42779.
Первая - это неполное исправление для CVE-2026-41409, которая, в свою очередь, является неполным исправлением для CVE-2024-52046, небезопасной десериализации данных, которая может быть использована для RCE.
Вторая - неполное исправление для CVE-2026-41635, представляющей собой некорректную ошибку проверки, приводящую к обходу списка разрешенных объектов и выполнению кода.
3. VulnCheck сообщает, что злоумышленники активно используют критическую CVE-2026-29014 (CVSS: 9,8) в CMS с открытым исходным кодом MetInfo.
Она затрагивает MetInfo CMS 7.9, 8.0 и 8.1 и позволяет удаленным злоумышленникам выполнять произвольный код, отправляя специально сформированные запросы со вредоносным PHP-кодом.
Злоумышленники могут использовать недостаточную нейтрализацию входных данных в процессе выполнения кода для RCE и получения полного контроля над затронутым сервером.
httpd.apache.org
Apache HTTP Server 2.4 vulnerabilities - The Apache HTTP Server Project
Disc Soft Limited, разработчик DAEMON Tools Lite, подтвердила заражение программного обеспечения трояном в результате атаки на цепочку поставок, выпустив чистую версию 12.6.
Как отметили в компании, менее чем через 12 часов после выявления проблемы удалось внедрить решение. Проблема затрагивала только бесплатную версию DAEMON Tools Lite и не повлияла ни на один из других продуктов.
В Disc Soft Limited не обнаружили доказательств того, что все пользователи DAEMON Tools пострадали, а также опровергли какое-либо влияние на пользователей платных версий DAEMON Tools Lite, DAEMON Tools Ultra и DAEMON Tools Pro.
В отдельном заявлении Disc Soft также сообщила, что в результате внутреннего расследования выявила несанкционированное вмешательство в инфраструктуру, в следствие чего некоторые установочные пакеты были выпущены в скомпрометированном состоянии.
Тем не менее, пока не связала атаку с конкретным злоумышленником и не предоставила никакой дополнительной информации о взломе, расследование инцидента продолжается.
Пользователям, которые установили DAEMON Tools Lite версии 12.5.1 (бесплатная версия) после 8 апреля, рекомендуется удалить приложение, выполнить полное сканирование системы с помощью антивирусного ПО и установить DAEMON Tools Lite 12.6 с официального сайта.
Disc Soft Limited удалила троянизированную версию, которая больше не поддерживается, и теперь отображает предупреждение, предлагающее пользователям установить последнюю версию DAEMON Tools Lite.
Disc Soft Limited выразила благодарность исследователям Лаборатории Касперского, которые первыми обнаружили атаку и оперативно проинформировали разработчиков.
Собственно, в отчете ЛК можно ознакомиться со всеми техническими подробностями.
Как отметили в компании, менее чем через 12 часов после выявления проблемы удалось внедрить решение. Проблема затрагивала только бесплатную версию DAEMON Tools Lite и не повлияла ни на один из других продуктов.
В Disc Soft Limited не обнаружили доказательств того, что все пользователи DAEMON Tools пострадали, а также опровергли какое-либо влияние на пользователей платных версий DAEMON Tools Lite, DAEMON Tools Ultra и DAEMON Tools Pro.
В отдельном заявлении Disc Soft также сообщила, что в результате внутреннего расследования выявила несанкционированное вмешательство в инфраструктуру, в следствие чего некоторые установочные пакеты были выпущены в скомпрометированном состоянии.
Тем не менее, пока не связала атаку с конкретным злоумышленником и не предоставила никакой дополнительной информации о взломе, расследование инцидента продолжается.
Пользователям, которые установили DAEMON Tools Lite версии 12.5.1 (бесплатная версия) после 8 апреля, рекомендуется удалить приложение, выполнить полное сканирование системы с помощью антивирусного ПО и установить DAEMON Tools Lite 12.6 с официального сайта.
Disc Soft Limited удалила троянизированную версию, которая больше не поддерживается, и теперь отображает предупреждение, предлагающее пользователям установить последнюю версию DAEMON Tools Lite.
Disc Soft Limited выразила благодарность исследователям Лаборатории Касперского, которые первыми обнаружили атаку и оперативно проинформировали разработчиков.
Собственно, в отчете ЛК можно ознакомиться со всеми техническими подробностями.
Разработчики GrapheneOS устранили уязвимость обхода VPN в Android, которая могла привести к утечке реального IP пользователя, однако в Google отказались ее испоавлять.
Утечка происходит даже при включенных в Android функциях защиты «постоянно включенный VPN» и «блокировка подключений без VPN».
Проблема была обнаружена на прошлой неделе исследователем lowlevel/Yusuf и затрагивает Android 16. Она связана с недавно внедренной функцией разрыва соединения QUIC в сетевом стеке Android.
В своей последней версии GrapheneOS заявляет, что «отключила оптимизацию registerQuicConnectionClosePayload для устранения утечки VPN», эффективно нейтрализовав вектор атаки на поддерживаемых устройствах Pixel.
Согласно исследованию, уязвимый API позволял обычным приложениям, имеющим только автоматически предоставленные разрешения INTERNET и ACCESS_NETWORK_STATE, регистрировать произвольные UDP-данные на system_server.
Когда UDP-сокет приложения нейтрализуется, привилегированный процесс system_server в Android передает сохраненную полезную нагрузку напрямую через физический сетевой интерфейс устройства, а не через VPN-туннель.
Поскольку system_server работает с расширенными сетевыми привилегиями и не подпадает под ограничения маршрутизации VPN, пакет полностью обходит защиту от блокировки VPN в Android.
Исследователь продемонстрировал уязвимость на Pixel 8 под управлением Android 16 с включенным VPN Proton и режимом блокировки. При этом приложение передало фактический публичный IP устройства на удаленный сервер, несмотря включенную защиту VPN.
Google представила функцию, позволяющую приложениям корректно завершать сеансы QUIC при неожиданном разрыве соединения. Однако эта реализация принимала произвольные данные без проверки на легитимность кадров QUIC CONNECTION_CLOSE и не проверяла, использует ли исходное приложение только VPN-трафик.
Исследователь сообщил о проблеме команде безопасности Android, но та классифицировала её как «не подлежающую исправлению (нецелесообразно)» и «NSBC» (не относится к категории бюллетеней безопасности), ссылаясь на не соответствие критериям для включения в рекомендации по безопасности Android.
Исследователь обжаловал это решение, утверждая, что любое приложение может допустить утечку идентифицирующей сетевой информации, используя только стандартные разрешения, но Google осталась при своём мнении, разрешив публичное раскрытие информации 29 апреля.
В ответ на это GrapheneOS полностью отключила базовую оптимизацию в версии 2026050400.
Помимо исправления этой уязвимости, последний релиз также включает в себя полный уровень патча безопасности Android за май 2026 года, улучшения hardened_malloc, обновления ядра Linux для веток Android 6.1, 6.6 и 6.12, а также исправление CVE-2026-33636 в libpng.
Кроме того, обновление включает в себя более новые сборки браузера Vanadium и расширенные ограничения динамической загрузки кода.
Исследователь отметил, что пользователи стандартной версии Android могут временно решить проблему вручную через ADB, отключив флаг DeviceConfig close_quic_connection.
Однако это обходное решение требует доступа для разработчиков и может не сохраниться надолго, если Google удалит этот флаг в будущих обновлениях (по приказу товарища майора).
Утечка происходит даже при включенных в Android функциях защиты «постоянно включенный VPN» и «блокировка подключений без VPN».
Проблема была обнаружена на прошлой неделе исследователем lowlevel/Yusuf и затрагивает Android 16. Она связана с недавно внедренной функцией разрыва соединения QUIC в сетевом стеке Android.
В своей последней версии GrapheneOS заявляет, что «отключила оптимизацию registerQuicConnectionClosePayload для устранения утечки VPN», эффективно нейтрализовав вектор атаки на поддерживаемых устройствах Pixel.
Согласно исследованию, уязвимый API позволял обычным приложениям, имеющим только автоматически предоставленные разрешения INTERNET и ACCESS_NETWORK_STATE, регистрировать произвольные UDP-данные на system_server.
Когда UDP-сокет приложения нейтрализуется, привилегированный процесс system_server в Android передает сохраненную полезную нагрузку напрямую через физический сетевой интерфейс устройства, а не через VPN-туннель.
Поскольку system_server работает с расширенными сетевыми привилегиями и не подпадает под ограничения маршрутизации VPN, пакет полностью обходит защиту от блокировки VPN в Android.
Исследователь продемонстрировал уязвимость на Pixel 8 под управлением Android 16 с включенным VPN Proton и режимом блокировки. При этом приложение передало фактический публичный IP устройства на удаленный сервер, несмотря включенную защиту VPN.
Google представила функцию, позволяющую приложениям корректно завершать сеансы QUIC при неожиданном разрыве соединения. Однако эта реализация принимала произвольные данные без проверки на легитимность кадров QUIC CONNECTION_CLOSE и не проверяла, использует ли исходное приложение только VPN-трафик.
Исследователь сообщил о проблеме команде безопасности Android, но та классифицировала её как «не подлежающую исправлению (нецелесообразно)» и «NSBC» (не относится к категории бюллетеней безопасности), ссылаясь на не соответствие критериям для включения в рекомендации по безопасности Android.
Исследователь обжаловал это решение, утверждая, что любое приложение может допустить утечку идентифицирующей сетевой информации, используя только стандартные разрешения, но Google осталась при своём мнении, разрешив публичное раскрытие информации 29 апреля.
В ответ на это GrapheneOS полностью отключила базовую оптимизацию в версии 2026050400.
Помимо исправления этой уязвимости, последний релиз также включает в себя полный уровень патча безопасности Android за май 2026 года, улучшения hardened_malloc, обновления ядра Linux для веток Android 6.1, 6.6 и 6.12, а также исправление CVE-2026-33636 в libpng.
Кроме того, обновление включает в себя более новые сборки браузера Vanadium и расширенные ограничения динамической загрузки кода.
Исследователь отметил, что пользователи стандартной версии Android могут временно решить проблему вручную через ADB, отключив флаг DeviceConfig close_quic_connection.
Однако это обходное решение требует доступа для разработчиков и может не сохраниться надолго, если Google удалит этот флаг в будущих обновлениях (по приказу товарища майора).
lowlevel.fun
The Tiny UDP Cannon: An Android VPN Bypass
An unprivileged Android app can leak the user's real IP past Always-On VPN + lockdown by handing system_server a UDP payload to fire on its behalf.
Исследователи Лаборатории Касперского обнаружили в репозитории Python Package Index (PyPI) три пакета, предназначенные для скрытой доставки ранее неизвестного семейства вредоносных ПО под названием ZiChatBot на системы Windows и Linux.
Несмотря на то, что эти пакеты wheel и реализуют функции, описанные на веб-страницах PyPI, их истинное предназначение - скрытая доставка вредоносных файлов.
В отличие от традиционного вредоносного ПО, ZiChatBot не взаимодействует с выделенным сервером C2, а вместо этого использует ряд REST API из общедоступного приложения для командного чата Zulip в качестве своей инфраструктуры C2.
Исследователи охарактеризовали эту деятельность как «тщательно спланированную и осуществленную атаку на цепочку поставок PyPI», затронувшую следующие пакеты (впоследствии были удалены): uuid32-utils (1479 загрузок), colorinal (614) и termncolor (387).
Все три пакета были загружены в PyPI в течение короткого периода времени с 16 по 22 июля 2025 года. При этом uuid32-utils и colorinal используют аналогичные вредоносные программы, termncolor - указывает colorinal в качестве зависимости.
В системах Windows после установки любого из первых двух пакетов вредоносный код извлекает DLL-файл-дроппер (terminate.dll) и записывает его на диск.
В момент импорта библиотеки в проект загружается DLL-файл, выступающий в качестве дроппера для ZiChatBot, после чего он создает запись автозапуска в реестре Windows и выполняет код для удаления себя с хоста.
Linux-версия дроппера разделяемых объектов (terminate.so) размещает вредоносное ПО в пути /tmp/obsHub/obs-check-update и настраивает запись в crontab.
Независимо от операционной системы, ZiChatBot предназначен для выполнения шеллкода, полученного от его C2-сервера. После выполнения команды вредоносное ПО отправляет в ответ эмодзи в виде сердца, сигнализируя серверу об успешном завершении операции.
Кто именно стоит за этой кампанией, пока неясно. Однако в ЛК отметили, что этот дроппер на 64% схож с другим дроппером, используемым APT OceanLotus (она же APT32), связанной с Вьетнамом.
Исследователи Лаборатори Касперского полагают, что если кампания по атаке на цепочку поставок PyPI действительно является операцией OceanLotus, то это отражает стратегию злоумышленников по расширению масштабов своих атак.
Хотя фишинговые электронные письма по-прежнему являются распространенным методом первоначального заражения OceanLotus, группа, по всей видимости, также активно изучает новые способы компрометации жертв посредством атак на различные цепочки поставок.
Несмотря на то, что эти пакеты wheel и реализуют функции, описанные на веб-страницах PyPI, их истинное предназначение - скрытая доставка вредоносных файлов.
В отличие от традиционного вредоносного ПО, ZiChatBot не взаимодействует с выделенным сервером C2, а вместо этого использует ряд REST API из общедоступного приложения для командного чата Zulip в качестве своей инфраструктуры C2.
Исследователи охарактеризовали эту деятельность как «тщательно спланированную и осуществленную атаку на цепочку поставок PyPI», затронувшую следующие пакеты (впоследствии были удалены): uuid32-utils (1479 загрузок), colorinal (614) и termncolor (387).
Все три пакета были загружены в PyPI в течение короткого периода времени с 16 по 22 июля 2025 года. При этом uuid32-utils и colorinal используют аналогичные вредоносные программы, termncolor - указывает colorinal в качестве зависимости.
В системах Windows после установки любого из первых двух пакетов вредоносный код извлекает DLL-файл-дроппер (terminate.dll) и записывает его на диск.
В момент импорта библиотеки в проект загружается DLL-файл, выступающий в качестве дроппера для ZiChatBot, после чего он создает запись автозапуска в реестре Windows и выполняет код для удаления себя с хоста.
Linux-версия дроппера разделяемых объектов (terminate.so) размещает вредоносное ПО в пути /tmp/obsHub/obs-check-update и настраивает запись в crontab.
Независимо от операционной системы, ZiChatBot предназначен для выполнения шеллкода, полученного от его C2-сервера. После выполнения команды вредоносное ПО отправляет в ответ эмодзи в виде сердца, сигнализируя серверу об успешном завершении операции.
Кто именно стоит за этой кампанией, пока неясно. Однако в ЛК отметили, что этот дроппер на 64% схож с другим дроппером, используемым APT OceanLotus (она же APT32), связанной с Вьетнамом.
Исследователи Лаборатори Касперского полагают, что если кампания по атаке на цепочку поставок PyPI действительно является операцией OceanLotus, то это отражает стратегию злоумышленников по расширению масштабов своих атак.
Хотя фишинговые электронные письма по-прежнему являются распространенным методом первоначального заражения OceanLotus, группа, по всей видимости, также активно изучает новые способы компрометации жертв посредством атак на различные цепочки поставок.
Солары выкатили отчет с обзором обнаруженных сетевых уязвимостей и эксплойтов в первом квартале 2026 года, продолжая отслеживать и информировать в отношении актуальных изменений на ландшафте угроз этого типа.
Отметим ключевые выводы:
- Количество обнаруженных уязвимостей в первом квартале 2026 года по сравнению с четвертым кварталом 2025 года выросло на 7% - с 397 до 426. В основном рост обусловлен тем фактом, что многие уязвимости, сообщения о которых в публичном доступе появились в 2026 году, были обнаружены еще в 2025 году.
- Сетевой вектор имели 83,84% обнаруженных уязвимостей. В четвертом квартале 2025 года этот показатель составлял 81%.
- Средний уровень критичности обнаруженных сетевых уязвимостей составил 8,1 балла. В четвертом квартале - 7,8, а годом ранее, по итогам первого квартала 2025 года, - 7,3.
- 91,62% всех обнаруженных сетевых уязвимостей эксплуатируются через HTTP. Ближайший «преследователь» - TCP (3,07%).
- На уязвимости уровня Critical и High в совокупности пришлось 72,06% - это заметно выше показателя четвертого квартала 2025 года (69,3%), но лишь не намного выше, чем было в первом квартале (71,5%).
- Самым уязвимым продуктом уже несколько кварталов подряд остается WordPress и плагины для него (18,13%).
Доля таких уязвимостей в общем объеме выросла на 4,7 процентных пункта в сравнении с четвертым кварталом. Однако в сравнении с первым кварталом, когда на WordPress приходилось 22,4% уязвимостей, она упала.
- После спада в четвертом квартале вновь вернулась к росту доля уязвимостей в ИИ-сервисах.
На них пришлось 4,83%. Примечательно, что в среднем уровень критичности уязвимостей в таких продуктах - 9,2 балла. Это самый высокий показатель среди продуктов-лидеров по количеству обнаруживаемых уязвимостей. Их находят сравнительно редко, но большинство из таких брешей имеют высокий уровень критичности.
Общим трендом первого квартала является появление сканеров уязвимостей для популярных ИИ-сервисов. Так, например, по данным одного из них, на март 2026 г. в AI-агенте OpenClaw содержится более 522 CVE, и еженедельные обновления базы продолжаются, что говорит о кризисе безопасности OpenClaw. ClawJacked - это новый вектор атаки на AI-агент.
В 1-м квартале 2026 г. рейтинг самых популярных уязвимостей исходя из количества опубликованных эксплойтов выглядит следующим образом: CVE-2025-2304 (Camaleon CMS), CVE-2026-23744 (MCPJam Inspector), CVE-2026-21858 (n8n), CVE-2026-29000 (pac4j-jwt) и CVE-2026-21962 (Oracle Fusion Middleware).
Подробная инфографика и аналитика - в отчете.
Отметим ключевые выводы:
- Количество обнаруженных уязвимостей в первом квартале 2026 года по сравнению с четвертым кварталом 2025 года выросло на 7% - с 397 до 426. В основном рост обусловлен тем фактом, что многие уязвимости, сообщения о которых в публичном доступе появились в 2026 году, были обнаружены еще в 2025 году.
- Сетевой вектор имели 83,84% обнаруженных уязвимостей. В четвертом квартале 2025 года этот показатель составлял 81%.
- Средний уровень критичности обнаруженных сетевых уязвимостей составил 8,1 балла. В четвертом квартале - 7,8, а годом ранее, по итогам первого квартала 2025 года, - 7,3.
- 91,62% всех обнаруженных сетевых уязвимостей эксплуатируются через HTTP. Ближайший «преследователь» - TCP (3,07%).
- На уязвимости уровня Critical и High в совокупности пришлось 72,06% - это заметно выше показателя четвертого квартала 2025 года (69,3%), но лишь не намного выше, чем было в первом квартале (71,5%).
- Самым уязвимым продуктом уже несколько кварталов подряд остается WordPress и плагины для него (18,13%).
Доля таких уязвимостей в общем объеме выросла на 4,7 процентных пункта в сравнении с четвертым кварталом. Однако в сравнении с первым кварталом, когда на WordPress приходилось 22,4% уязвимостей, она упала.
- После спада в четвертом квартале вновь вернулась к росту доля уязвимостей в ИИ-сервисах.
На них пришлось 4,83%. Примечательно, что в среднем уровень критичности уязвимостей в таких продуктах - 9,2 балла. Это самый высокий показатель среди продуктов-лидеров по количеству обнаруживаемых уязвимостей. Их находят сравнительно редко, но большинство из таких брешей имеют высокий уровень критичности.
Общим трендом первого квартала является появление сканеров уязвимостей для популярных ИИ-сервисов. Так, например, по данным одного из них, на март 2026 г. в AI-агенте OpenClaw содержится более 522 CVE, и еженедельные обновления базы продолжаются, что говорит о кризисе безопасности OpenClaw. ClawJacked - это новый вектор атаки на AI-агент.
В 1-м квартале 2026 г. рейтинг самых популярных уязвимостей исходя из количества опубликованных эксплойтов выглядит следующим образом: CVE-2025-2304 (Camaleon CMS), CVE-2026-23744 (MCPJam Inspector), CVE-2026-21858 (n8n), CVE-2026-29000 (pac4j-jwt) и CVE-2026-21962 (Oracle Fusion Middleware).
Подробная инфографика и аналитика - в отчете.