Forwarded from Russian OSINT
Исследователи SentinelOne пишут про новую малварь
fast16.sys. Он искажает 1️⃣ Начало 2000-х: 🇮🇷Иран якобы активно развивал свой секретный ядерный проект AMAD. Иранские специалисты использовали западное программное обеспечение для высокоточного физического моделирования. Применение пакета LS-DYNA позволяло инженерам рассчитывать свойства взрывчатых веществ и параметры ядерных боеголовок.
2️⃣ Разработка кибероружия (до 2005 года): Спецслужбы (предположительно США или их союзников) разрабатывают сложнейшую архитектуру для скрытого киберсаботажа. Наличие в коде старых артефактов UNIX (RCS/SCCS) указывает на то, что это была высокопрофессиональная
3️⃣ Создание и внедрение Fast16 (2005 год): Завершена компиляция ключевых компонентов вируса (включая драйвер
fast16.sys и носитель svcmgmt.exe). Fast16 становится первым в истории сетевым «червем» на базе движка Lua, предназначенным для точечного саботажа, опередив появление Stuxnet как минимум на 5 лет.4️⃣ Уникальный механизм саботажа (2005): Fast16 кардинально отличалась от обычных вирусов для шпионажа. Вредоносный код очень глубоко внедрялся на уровень системного ядра операционной системы. Там он незаметно изменял инструкции сопроцессора для вычислений с плавающей запятой в инженерных комплексах LS-DYNA, PKPM и MOHID. Математические ошибки приводили к необратимому
5️⃣ Смена тактики на более агрессивную (2007 год): 🇺🇸США и 🇮🇱Израиль развертывают Stuxnet (операция «Олимпийские игры») для физического уничтожения иранских центрифуг. Fast16, вероятно, был более ранним и скрытным предшественником этой операции, нацеленным на срыв ядерной программы еще на этапе расчетов.
Please open Telegram to view this post
VIEW IN TELEGRAM
Forwarded from Russian OSINT
6️⃣ Первый след (апрель 2017 года): артефакты Fast16 былb обнаружен в апреле 2017 года после утечки данных. Хакерская группировка Shadow Brokers опубликовала в открытом доступе секретные инструменты 🇺🇸АНБ США. Документ содержал упоминание драйвера fast16 и прямое указание для американских операторов игнорировать этот компонент. В инструкции была написана фраза «*** Здесь не на что смотреть, продолжайте работу ***». Подобный маркер подтверждает принадлежность вредоносного кода к союзным правительственным структурам.
7️⃣ Обнаружение кода: Аналитики компании обнаружили в архивах безобидный на первый взгляд файл svcmgmt.exe. Неизвестный пользователь загрузил этот образец на платформу VirusTotal около 10 лет назад. Долгое время файл не привлекал внимания ИБ-специалистов. Анализ показал скрытое наличие внутри этого носителя скомпилированного вредоносного драйвера из 2005 года.
8️⃣ Годы невидимости: На протяжении десятилетия Fast16 успешно обходила проверки антивирусных систем и оставалась невидимой. Платформа VirusTotal до сих пор демонстрирует почти нулевой уровень обнаружения этого кода. Лишь один поисковый механизм классифицирует файл как подозрительный с крайне низкой степенью уверенности. Разработанный фреймворк оказался на голову выше обычных шпионских руткитов своего времени.
9️⃣ Начало 2026 года: Исследователи SentinelLabs проводят глубокий реверс-инжиниринг кода и выясняют истинную цель программы. Исследователи обнаружили наличие 101 правила для динамической модификации кода прямо в оперативной памяти компьютера. Данные алгоритмы были целенаправленно написаны для точечного искажения критически важных чисел и расчетов в симуляторах физических процессов.
🔟 Публикация отчета: SentinelLabs публикует полное исследование 23 апреля 2026 года.
Авторы отчета выражают обоснованную тревогу по поводу успешного сокрытия программы на протяжении нескольких десятилетий. Подобный прецедент вынуждает полностью пересмотреть историческое понимание эволюции киберсаботажа. Экспертный анализ подтверждает факт полноценного развертывания сложнейших государственных киберопераций против физических целей еще в середине двухтысячных годов. Результаты компьютерного моделирования на десятках стратегических объектов могли подвергаться тайным искажениям на протяжении долгих лет.
✋ Сколько сейчас таких объектов заражено по всему миру? — только одному Богу известно.
✋ @Russian_OSINT
7️⃣ Обнаружение кода: Аналитики компании обнаружили в архивах безобидный на первый взгляд файл svcmgmt.exe. Неизвестный пользователь загрузил этот образец на платформу VirusTotal около 10 лет назад. Долгое время файл не привлекал внимания ИБ-специалистов. Анализ показал скрытое наличие внутри этого носителя скомпилированного вредоносного драйвера из 2005 года.
8️⃣ Годы невидимости: На протяжении десятилетия Fast16 успешно обходила проверки антивирусных систем и оставалась невидимой. Платформа VirusTotal до сих пор демонстрирует почти нулевой уровень обнаружения этого кода. Лишь один поисковый механизм классифицирует файл как подозрительный с крайне низкой степенью уверенности. Разработанный фреймворк оказался на голову выше обычных шпионских руткитов своего времени.
9️⃣ Начало 2026 года: Исследователи SentinelLabs проводят глубокий реверс-инжиниринг кода и выясняют истинную цель программы. Исследователи обнаружили наличие 101 правила для динамической модификации кода прямо в оперативной памяти компьютера. Данные алгоритмы были целенаправленно написаны для точечного искажения критически важных чисел и расчетов в симуляторах физических процессов.
🔟 Публикация отчета: SentinelLabs публикует полное исследование 23 апреля 2026 года.
Авторы отчета выражают обоснованную тревогу по поводу успешного сокрытия программы на протяжении нескольких десятилетий. Подобный прецедент вынуждает полностью пересмотреть историческое понимание эволюции киберсаботажа. Экспертный анализ подтверждает факт полноценного развертывания сложнейших государственных киберопераций против физических целей еще в середине двухтысячных годов. Результаты компьютерного моделирования на десятках стратегических объектов могли подвергаться тайным искажениям на протяжении долгих лет.
Please open Telegram to view this post
VIEW IN TELEGRAM
Пользователям браузеров Firefox и Tor рекомендуется установить последние обновления для устранения ошибки, которая позволяет злоумышленникам отслеживать действия в интернете.
Уязвимость проявляется в обычном режиме просмотра веб-страниц, в окнах приватного просмотра и, в случае Tor, в разных сессиях Tor.
Проблема обнаружена командой FingerprintJS и затрагивает IndexedDB, API Firefox, который позволяет сайтам сохранять данные в браузере пользователя для последующих посещений.
Она позволяет злоумышленнику создать базу данных IndexedDB в браузере пользователя при посещении вредоносного веб-сайта или просмотре вредоносной рекламы.
Суть ошибки заключается в том, что IndexedDB каждый раз возвращает содержимое этой базы данных в одном и том же порядке, что создает универсальный фингерпринт, идеально подходящий для отслеживания.
Оператор сайта или сети сайтов сможет различать пользователей и отслеживать их, запрашивая контент из IndexedDB и сопоставляя «порядок в базе данных» с известным идентификатором.
Уязвимость была исправлена в Firefox 150, Firefox ESR 140.10 и Tor Browser 15.0.10, выпущенных на прошлой неделе, и отслеживается как CVE-2026-6770.
FingerprintJS утверждает, что ошибка затрагивает как Firefox, так и браузер Tor, поскольку содержится в ядре Firefox, Gecko и обусловлена тем, как реализована база данных IndexedDB.
Mozilla не сообщила, как именно была устранена эта проблема, но исследователи утверждают, что IndexedDB не должна раскрывать свой внутренний порядок хранения данных или должна возвращать контент в соответствии с заранее заданным порядком.
Ошибка довольно серьёзная, но осталась практически незамеченной, потому что на прошлой неделе все были слишком взволнованы новостью о том, что компания, занимающаяся разработкой ИИ, обнаружила 271 уязвимость в Firefox, которых даже нет в примечаниях к патчу и которые, веротяноя, на самом дел не так уж и важны.
Уязвимость проявляется в обычном режиме просмотра веб-страниц, в окнах приватного просмотра и, в случае Tor, в разных сессиях Tor.
Проблема обнаружена командой FingerprintJS и затрагивает IndexedDB, API Firefox, который позволяет сайтам сохранять данные в браузере пользователя для последующих посещений.
Она позволяет злоумышленнику создать базу данных IndexedDB в браузере пользователя при посещении вредоносного веб-сайта или просмотре вредоносной рекламы.
Суть ошибки заключается в том, что IndexedDB каждый раз возвращает содержимое этой базы данных в одном и том же порядке, что создает универсальный фингерпринт, идеально подходящий для отслеживания.
Оператор сайта или сети сайтов сможет различать пользователей и отслеживать их, запрашивая контент из IndexedDB и сопоставляя «порядок в базе данных» с известным идентификатором.
Уязвимость была исправлена в Firefox 150, Firefox ESR 140.10 и Tor Browser 15.0.10, выпущенных на прошлой неделе, и отслеживается как CVE-2026-6770.
FingerprintJS утверждает, что ошибка затрагивает как Firefox, так и браузер Tor, поскольку содержится в ядре Firefox, Gecko и обусловлена тем, как реализована база данных IndexedDB.
Mozilla не сообщила, как именно была устранена эта проблема, но исследователи утверждают, что IndexedDB не должна раскрывать свой внутренний порядок хранения данных или должна возвращать контент в соответствии с заранее заданным порядком.
Ошибка довольно серьёзная, но осталась практически незамеченной, потому что на прошлой неделе все были слишком взволнованы новостью о том, что компания, занимающаяся разработкой ИИ, обнаружила 271 уязвимость в Firefox, которых даже нет в примечаниях к патчу и которые, веротяноя, на самом дел не так уж и важны.
Fingerprint
We Found a Stable Firefox Identifier Linking All Your Private Tor Identities
We discovered a privacy vulnerability in Firefox Private Browsing and Tor Browser that allows websites to fingerprint and track users across origins using IndexedDB database ordering, even after closing all private windows.
По данным Shadowserver более 10 000 экземпляров Zimbra Collaboration Suite (ZCS) в сети уязвимы для продолжающихся атак, использующих уязвимость межсайтового скриптинга (XSS).
Zimbra - это популярный пакет программного обеспечения для электронной почты и совместной работы, которым пользуются сотни миллионов пользователей по всему миру, включая госучреждения и предприятия.
Уязвимость отслеживается как CVE-2025-48700 и затрагивает ZCS 8.8.15, 9.0, 10.0 и 10.1, позволяя неавторизованным злоумышленникам получить доступ к конфиденциальной информации после выполнения произвольного JavaScript-кода в рамках пользовательской сессии.
В июне 2025 года Synacor выпустила обновления для ее устранения, предупредив, что эксплойты не требуют взаимодействия с пользователем и могут быть активированы при просмотре пользователем специально созданного вредоносного электронного письма в пользовательском интерфейсе Zimbra Classic.
На этой неделе CISA отметила CVE-2025-48700 как активно используемую злоумышленниками и добавила в свой каталог KEV, полагаясь на доказательства активной эксплуатации.
В Shadowserver также предупредили, что более 10 500 серверов Zimbra, оказавшихся в открытом доступе, остаются без обновлений, большинство из них находятся в Азии (3794) и Европе (3793).
При этом, как показывает практика, уязвимости в Zimbra часто использовались в атаках и за последние годы для взлома тысяч уязвимых почтовых серверов. Так что избежать новой атаки на цепочку мудаков вряд ли получится и на этот раз. Но будем посмотреть.
Zimbra - это популярный пакет программного обеспечения для электронной почты и совместной работы, которым пользуются сотни миллионов пользователей по всему миру, включая госучреждения и предприятия.
Уязвимость отслеживается как CVE-2025-48700 и затрагивает ZCS 8.8.15, 9.0, 10.0 и 10.1, позволяя неавторизованным злоумышленникам получить доступ к конфиденциальной информации после выполнения произвольного JavaScript-кода в рамках пользовательской сессии.
В июне 2025 года Synacor выпустила обновления для ее устранения, предупредив, что эксплойты не требуют взаимодействия с пользователем и могут быть активированы при просмотре пользователем специально созданного вредоносного электронного письма в пользовательском интерфейсе Zimbra Classic.
На этой неделе CISA отметила CVE-2025-48700 как активно используемую злоумышленниками и добавила в свой каталог KEV, полагаясь на доказательства активной эксплуатации.
В Shadowserver также предупредили, что более 10 500 серверов Zimbra, оказавшихся в открытом доступе, остаются без обновлений, большинство из них находятся в Азии (3794) и Европе (3793).
При этом, как показывает практика, уязвимости в Zimbra часто использовались в атаках и за последние годы для взлома тысяч уязвимых почтовых серверов. Так что избежать новой атаки на цепочку мудаков вряд ли получится и на этот раз. Но будем посмотреть.
Cybersecurity and Infrastructure Security Agency CISA
Known Exploited Vulnerabilities Catalog | CISA
For the benefit of the cybersecurity community and network defenders—and to help every organization better manage vulnerabilities and keep pace with threat activity—CISA maintains the authoritative source of vulnerabilities that have been exploited in the…
В демоне PackageKit обнаружена новая уязвимость, получившая название Pack2TheRoot, которая позволяет локальным пользователям Linux устанавливать или удалять системные пакеты и получать права root.
Уязвимость отслеживается как CVE-2026-41651 (CVSS 8,8 из 10) и сохраняется в демоне PackageKit уже почти 12 лет.
Ранее некоторая информация об уязвимости была опубличена вместе с PackageKit 1.3.5, устраняющей ее. Однако технические подробности и PoC до сих пор не раскрыты, оставляя временной лаг для распространения исправлений.
Согласно расследованию Deutsche Telekom, причиной ошибки является механизм, используемый PackageKit для обработки запросов на управление пакетами.
В частности, исследователи обнаружили, что команды типа pkcon install могут выполняться без аутентификации при определенных условиях в системе Fedora, что позволяет им устанавливать системный пакет.
Используя Claude Opus, исследователи дополнительно изучили потенциал использования этого поведения и, собственно, обнаружили уязвимость CVE-2026-41651.
Red Team компании Deutsche Telekom сообщила о своих выводах разработчикам Red Hat и PackageKit 8 апреля, заявив с уверенностью, что все дистрибутивы, в которых PackageKit предустановлен и включен по умолчанию, уязвимы для CVE-2026-41651.
Согласно уведомлению по безопасности, уязвимость присутствовала в версии PackageKit 1.0.2, выпущенной еще в ноябре 2014 года, и затрагивает все версии вплоть до 1.3.4.
Проведенные исследователями тесты подтвердили, что злоумышленник может использовать CVE-2026-41651 в следующих дистрибутивах: Ubuntu Desktop 18.04 (EOL), 24.04.4 (LTS), 26.04 (LTS beta); Ubuntu Server 22.04 – 24.04 (LTS); Debian Desktop Trixie 13.4; RockyLinux Desktop 10.1; • Fedora 43 Desktop и Fedora 43 Server.
Однако этот список не является исчерпывающим, и любой дистрибутив Linux с PackageKit, следует рассматривать как потенциально уязвимый для атак.
Пользователям следует как можно скорее обновить PackageKit до версии 1.3.5 и убедиться, что любое другое ПО, использующее этот пакет в качестве зависимости, переведено в безопасную версию.
Несмотря на то, что подробности о характере эксплуатации не разглашаются, исследователи отметили наличие явных признаков компрометации, поскольку эксплуатация приводит к ошибке утверждения в демоне PackageKit и его сбою. Даже если systemd восстановит работу демона, сбой будет виден в системных журналах.
Уязвимость отслеживается как CVE-2026-41651 (CVSS 8,8 из 10) и сохраняется в демоне PackageKit уже почти 12 лет.
Ранее некоторая информация об уязвимости была опубличена вместе с PackageKit 1.3.5, устраняющей ее. Однако технические подробности и PoC до сих пор не раскрыты, оставляя временной лаг для распространения исправлений.
Согласно расследованию Deutsche Telekom, причиной ошибки является механизм, используемый PackageKit для обработки запросов на управление пакетами.
В частности, исследователи обнаружили, что команды типа pkcon install могут выполняться без аутентификации при определенных условиях в системе Fedora, что позволяет им устанавливать системный пакет.
Используя Claude Opus, исследователи дополнительно изучили потенциал использования этого поведения и, собственно, обнаружили уязвимость CVE-2026-41651.
Red Team компании Deutsche Telekom сообщила о своих выводах разработчикам Red Hat и PackageKit 8 апреля, заявив с уверенностью, что все дистрибутивы, в которых PackageKit предустановлен и включен по умолчанию, уязвимы для CVE-2026-41651.
Согласно уведомлению по безопасности, уязвимость присутствовала в версии PackageKit 1.0.2, выпущенной еще в ноябре 2014 года, и затрагивает все версии вплоть до 1.3.4.
Проведенные исследователями тесты подтвердили, что злоумышленник может использовать CVE-2026-41651 в следующих дистрибутивах: Ubuntu Desktop 18.04 (EOL), 24.04.4 (LTS), 26.04 (LTS beta); Ubuntu Server 22.04 – 24.04 (LTS); Debian Desktop Trixie 13.4; RockyLinux Desktop 10.1; • Fedora 43 Desktop и Fedora 43 Server.
Однако этот список не является исчерпывающим, и любой дистрибутив Linux с PackageKit, следует рассматривать как потенциально уязвимый для атак.
Пользователям следует как можно скорее обновить PackageKit до версии 1.3.5 и убедиться, что любое другое ПО, использующее этот пакет в качестве зависимости, переведено в безопасную версию.
Несмотря на то, что подробности о характере эксплуатации не разглашаются, исследователи отметили наличие явных признаков компрометации, поскольку эксплуатация приводит к ошибке утверждения в демоне PackageKit и его сбою. Даже если systemd восстановит работу демона, сбой будет виден в системных журналах.
GitHub
Release v1.3.5 · PackageKit/PackageKit
Release 1.3.5
Исследователи Cyera сообщают, что все версии OpenSSH, выпущенные за последние 15 лет, подвержены уязвимости, приводящей к получению полного доступа к корневой оболочке, а атаки невозможно обнаружить с помощью анализа логов.
Уязвимость отслеживается как CVE-2026-35414 (CVSS 8.1) и описывается как некорректная обработка параметра authorized_keys principals в определенных сценариях, связанных с центрами сертификации (CA), использующими символы запятой.
По данным Cyera, из-за этой ошибки запятая в имени основного сертификата SSH приводит к обходу контроля доступа OpenSSH, позволяя пользователям аутентифицироваться как root на уязвимом сервере, при условии наличия у них действительного сертификата от доверенного центра сертификации.
Уязвимость заключается в ошибке повторного использования кода, из-за которой простая запятая в основном сертификате была случайно интерпретирована парсером как разделитель списка, в результате чего учетная запись с низкими привилегиями превратилась в корневые учетные данные.
Сервер считает аутентификацию легитимной, а это значит, что данная атака не регистрирует сбой аутентификации в журналах, что делает обнаружение на основе журналов крайне ненадежным.
Как поясняет Cyera, CVE-2026-35414 затрагивает список субъектов, который включает имена пользователей, под которыми владелец сертификата может проходить аутентификацию, и субъекты authorized_keys, содержащие ключи, используемые серверами для подтверждения доверия к сертификатам.
Проблема заключается в том, что функция, обрабатывающая согласование списков шифров и ключей для обмена, сравнивает разделенные запятыми списки шифров во время обмена ключами, разделяет их по запятой и включает аутентификацию, если хотя бы один из фрагментов совпадает со значением субъекта.
Так что если сертификат содержит имя principaldeploy, root, OpenSSH разделяет запятую и предоставляет полный доступ с правами root.
Вторая функция, которая также проверяет авторизацию, рассматривает тот же субъект как единую строку и запрещает доступ. Однако, если строка совпадает, последующие параметры приводят к тому, что проверка субъекта полностью пропускается.
По данным Cyera, успешная эксплуатация уязвимости может предоставить злоумышленнику корневой доступ ко всем серверам организации, если на них запущен уязвимый протокол.
CVE-2026-35414 была устранена в начале апреля в версии OpenSSH 10.3, в связи с чем рекомендуется провести аудит сред и как можно скорее обновиться до исправленной версии.
Уязвимость отслеживается как CVE-2026-35414 (CVSS 8.1) и описывается как некорректная обработка параметра authorized_keys principals в определенных сценариях, связанных с центрами сертификации (CA), использующими символы запятой.
По данным Cyera, из-за этой ошибки запятая в имени основного сертификата SSH приводит к обходу контроля доступа OpenSSH, позволяя пользователям аутентифицироваться как root на уязвимом сервере, при условии наличия у них действительного сертификата от доверенного центра сертификации.
Уязвимость заключается в ошибке повторного использования кода, из-за которой простая запятая в основном сертификате была случайно интерпретирована парсером как разделитель списка, в результате чего учетная запись с низкими привилегиями превратилась в корневые учетные данные.
Сервер считает аутентификацию легитимной, а это значит, что данная атака не регистрирует сбой аутентификации в журналах, что делает обнаружение на основе журналов крайне ненадежным.
Как поясняет Cyera, CVE-2026-35414 затрагивает список субъектов, который включает имена пользователей, под которыми владелец сертификата может проходить аутентификацию, и субъекты authorized_keys, содержащие ключи, используемые серверами для подтверждения доверия к сертификатам.
Проблема заключается в том, что функция, обрабатывающая согласование списков шифров и ключей для обмена, сравнивает разделенные запятыми списки шифров во время обмена ключами, разделяет их по запятой и включает аутентификацию, если хотя бы один из фрагментов совпадает со значением субъекта.
Так что если сертификат содержит имя principaldeploy, root, OpenSSH разделяет запятую и предоставляет полный доступ с правами root.
Вторая функция, которая также проверяет авторизацию, рассматривает тот же субъект как единую строку и запрещает доступ. Однако, если строка совпадает, последующие параметры приводят к тому, что проверка субъекта полностью пропускается.
По данным Cyera, успешная эксплуатация уязвимости может предоставить злоумышленнику корневой доступ ко всем серверам организации, если на них запущен уязвимый протокол.
CVE-2026-35414 была устранена в начале апреля в версии OpenSSH 10.3, в связи с чем рекомендуется провести аудит сред и как можно скорее обновиться до исправленной версии.
Популярный пакет PyPI elementary-data с 1,1 млн ежемесячных загрузок был взломан, вредоносная версия была нацелена на кражу конфиденциальных данных разработчиков и криптоошельков, действуя в качестве стилера.
Вредоносным релизом была признана версия 0.23.3, которая распространилась на образ Docker из-за особенностей рабочего процесса пакета, который создает образ из кода и загружает его в реестр контейнеров для развертывания.
Обнаружил вредоносную загрузку crisperik и в субботу направил заявку в GitHub проекта, предупредив сопровождающего и значительно сократив период, в течение которого вредоносная ПО могла быть раскрыта.
Пользователям оперативно была предоставлена «стерильная» замена, elementary-data 0.23.4, однако пользователи, скачавшие вредоносный вариант, остались под угрозой.
Пакет elementary-data представляет собой инструмент с открытым исходным кодом для мониторинга данных в рамках dbt (Data Build Tool), используемый в основном инженерами по аналитике данных, которые работают с конвейерами обработки данных. В экосистеме его ежемесячно скачивают более 1,1 млн. на PyPI.
Согласно анализу исследователяй StepSecurity, злоумышленник использовал уязвимость в рабочем процессе проекта, но не взламывал учетные записи сопровождающих, как это чаще происходит при несанкционированных обновлениях.
Злоумышленник оставил вредоносный комментарий к запросу на слияние, используя уязвимость внедрения скриптов в GitHub Actions, в результате чего рабочий процесс выполнил управляемый злоумышленником шелл-код.
Это позволило выявить GITHUB_TOKEN рабочего процесса, который затем был использован для подделки подписанного коммита и тега (v0.23.3) и запуска легитимного конвейера выпуска проекта.
Конвейер сборки создал и опубликовал пакет с бэкдором в PyPI, а также вредоносный образ в GitHub Container Registry, создав видимость официального релиза.
Вредоносная ПО содержала файл elementary.pth, который автоматически запускался при загрузке системы для кражи:
- SSH-ключей, учетных данных Git и облачных сервисов (AWS/GCP/Azure);
- секретов Kubernetes, Docker и CI;
- файлов .env и токенов разработчика;
- файлов криптокошельков (Bitcoin, Litecoin, Dogecoin, Zcash, Dash, Monero, Ripple);
- системных данных (/etc/passwd, журналы, история командной оболочки).
Исследователи полагают, что тот же самый полезный «груз» достиг образа Docker проекта, потому что «рабочий процесс выпуска пакетов, загружаемых в PyPI, также включает в себя задачу сборки и отправки образа Docker».
По данным StepSecurity, системы, которые не использовали закреплённые версии, автоматически загружали сборку с бэкдором.
Всем, кто скачал вредоносную версию elementary-data 0.23.3 и образы с тегами ghcr.io/elementary-data/elementary:0.23.3 и :latest, следует сменить все секретные ключи и восстановить свои среды из известной безопасной точки.
Вредоносным релизом была признана версия 0.23.3, которая распространилась на образ Docker из-за особенностей рабочего процесса пакета, который создает образ из кода и загружает его в реестр контейнеров для развертывания.
Обнаружил вредоносную загрузку crisperik и в субботу направил заявку в GitHub проекта, предупредив сопровождающего и значительно сократив период, в течение которого вредоносная ПО могла быть раскрыта.
Пользователям оперативно была предоставлена «стерильная» замена, elementary-data 0.23.4, однако пользователи, скачавшие вредоносный вариант, остались под угрозой.
Пакет elementary-data представляет собой инструмент с открытым исходным кодом для мониторинга данных в рамках dbt (Data Build Tool), используемый в основном инженерами по аналитике данных, которые работают с конвейерами обработки данных. В экосистеме его ежемесячно скачивают более 1,1 млн. на PyPI.
Согласно анализу исследователяй StepSecurity, злоумышленник использовал уязвимость в рабочем процессе проекта, но не взламывал учетные записи сопровождающих, как это чаще происходит при несанкционированных обновлениях.
Злоумышленник оставил вредоносный комментарий к запросу на слияние, используя уязвимость внедрения скриптов в GitHub Actions, в результате чего рабочий процесс выполнил управляемый злоумышленником шелл-код.
Это позволило выявить GITHUB_TOKEN рабочего процесса, который затем был использован для подделки подписанного коммита и тега (v0.23.3) и запуска легитимного конвейера выпуска проекта.
Конвейер сборки создал и опубликовал пакет с бэкдором в PyPI, а также вредоносный образ в GitHub Container Registry, создав видимость официального релиза.
Вредоносная ПО содержала файл elementary.pth, который автоматически запускался при загрузке системы для кражи:
- SSH-ключей, учетных данных Git и облачных сервисов (AWS/GCP/Azure);
- секретов Kubernetes, Docker и CI;
- файлов .env и токенов разработчика;
- файлов криптокошельков (Bitcoin, Litecoin, Dogecoin, Zcash, Dash, Monero, Ripple);
- системных данных (/etc/passwd, журналы, история командной оболочки).
Исследователи полагают, что тот же самый полезный «груз» достиг образа Docker проекта, потому что «рабочий процесс выпуска пакетов, загружаемых в PyPI, также включает в себя задачу сборки и отправки образа Docker».
По данным StepSecurity, системы, которые не использовали закреплённые версии, автоматически загружали сборку с бэкдором.
Всем, кто скачал вредоносную версию elementary-data 0.23.3 и образы с тегами ghcr.io/elementary-data/elementary:0.23.3 и :latest, следует сменить все секретные ключи и восстановить свои среды из известной безопасной точки.
GitHub
GitHub is where people build software. More than 150 million people use GitHub to discover, fork, and contribute to over 420 million projects.
Новая волна кампании Glassworm накрыла экосистему OpenVSX через 73 «скрытых» расширения, которые становятся вредоносными после обновления.
Шесть из этих расширений активировались и уже распространяют вредоносное ПО, в то время как исследователи с высокой степенью уверенности считают, что остальные находятся в спящем режиме.
При первоначальной загрузке расширения кажутся безобидными, но на более позднем этапе доставляют вредоносный код, раскрывая истинные намерения злоумышленника.
Как отмечают в Socket, число вредоносных расширений может измениться по мере появления новых обновлений, но закономерность соответствует предыдущим волнам GlassWorm.
Напомним, GlassWorm - это кампания по атакам на цепочку поставок, впервые обнаруженная в октябре. Первоначально она полагалась на невидимые символы Unicode для сокрытия вредоносного кода, который компрометирует криптокошельки и крадет учетные данные разрабов.
С тех пор GlassWorm распространилась по множеству экосистем, включая GitHub, npm, а также Visual Studio Code Marketplace и OpenVSX. Также было замечено, что они нацелены на пользователей macOS, используя троянизированные клиенты для криптокошельков.
Недавняя волна атак, наблюдавшаяся в середине марта 2026 года, продемонстрировала значительные масштабы, затронув сотни репозиториев и десятки расширений.
Однако операции такого масштаба могут сопровождаться шумом и оставлять многочисленные следы, поскольку несколько различных исследовательских групп обнаружили активность еще на ранней стадии и помогли ее нейтрализовать.
Последняя волна атак указывает на то, что злоумышленники намерены адаптировать свою стратегию, размещая безобидные расширения в рамках одной экосистемы и внедряя вредоносную нагрузку в последующем обновлении, а не встраивая её в сами расширения.
Socket обнаружила, что 73 расширения из последней кампании GlassWorm, являются клонами легитимных объявлений, призванных обмануть разработчиков, которые не обращают особого внимания ни на что, кроме визуального оформления.
В одном случае злоумышленник использовал ту же иконку, что и легитимное расширение, а также схожее название и описание. Хотя есть незначительные различия, главными индикаторами являются название издателя и уникальный идентификатор.
Вместо переноса вредоносного ПО, расширения теперь выступают в роли тонких загрузчиков, которые загружают его одним из следующих способов:
В первом случае, расширение во время выполнения загружает дополнительный VSIX-пакет с GitHub и устанавливает его с помощью команд командной строки.
В другом расширения загружают специфичные для платформы скомпилированные модули (.node-файлы), содержащие основную логику, включая загрузку дополнительных данных и выполнение процедур установки во всех поддерживаемых редакторах.
И, наконец, некоторые варианты полностью полагаются на сильно обфусцированный JavaScript, который декодируется во время выполнения для загрузки и установки вредоносных расширений, иногда включая зашифрованные или резервные URL-адреса для получения полезной нагрузки.
Socket пока не предоставила технических подробностей в отношении новой полезной нагрузки. Ранее подобные атаки были направлены на кражу данных криптокошельков, учетных данных, токенов доступа, SSH-ключей и данных среды разработки.
Полный список из 73 расширений, предположительно входящих в последнюю волну GlassWorm, доступен в отчете Socket. Разработчикам, установившим любое из них, рекомендуется ротировать все секретные ключи и очистить свою среду.
Шесть из этих расширений активировались и уже распространяют вредоносное ПО, в то время как исследователи с высокой степенью уверенности считают, что остальные находятся в спящем режиме.
При первоначальной загрузке расширения кажутся безобидными, но на более позднем этапе доставляют вредоносный код, раскрывая истинные намерения злоумышленника.
Как отмечают в Socket, число вредоносных расширений может измениться по мере появления новых обновлений, но закономерность соответствует предыдущим волнам GlassWorm.
Напомним, GlassWorm - это кампания по атакам на цепочку поставок, впервые обнаруженная в октябре. Первоначально она полагалась на невидимые символы Unicode для сокрытия вредоносного кода, который компрометирует криптокошельки и крадет учетные данные разрабов.
С тех пор GlassWorm распространилась по множеству экосистем, включая GitHub, npm, а также Visual Studio Code Marketplace и OpenVSX. Также было замечено, что они нацелены на пользователей macOS, используя троянизированные клиенты для криптокошельков.
Недавняя волна атак, наблюдавшаяся в середине марта 2026 года, продемонстрировала значительные масштабы, затронув сотни репозиториев и десятки расширений.
Однако операции такого масштаба могут сопровождаться шумом и оставлять многочисленные следы, поскольку несколько различных исследовательских групп обнаружили активность еще на ранней стадии и помогли ее нейтрализовать.
Последняя волна атак указывает на то, что злоумышленники намерены адаптировать свою стратегию, размещая безобидные расширения в рамках одной экосистемы и внедряя вредоносную нагрузку в последующем обновлении, а не встраивая её в сами расширения.
Socket обнаружила, что 73 расширения из последней кампании GlassWorm, являются клонами легитимных объявлений, призванных обмануть разработчиков, которые не обращают особого внимания ни на что, кроме визуального оформления.
В одном случае злоумышленник использовал ту же иконку, что и легитимное расширение, а также схожее название и описание. Хотя есть незначительные различия, главными индикаторами являются название издателя и уникальный идентификатор.
Вместо переноса вредоносного ПО, расширения теперь выступают в роли тонких загрузчиков, которые загружают его одним из следующих способов:
В первом случае, расширение во время выполнения загружает дополнительный VSIX-пакет с GitHub и устанавливает его с помощью команд командной строки.
В другом расширения загружают специфичные для платформы скомпилированные модули (.node-файлы), содержащие основную логику, включая загрузку дополнительных данных и выполнение процедур установки во всех поддерживаемых редакторах.
И, наконец, некоторые варианты полностью полагаются на сильно обфусцированный JavaScript, который декодируется во время выполнения для загрузки и установки вредоносных расширений, иногда включая зашифрованные или резервные URL-адреса для получения полезной нагрузки.
Socket пока не предоставила технических подробностей в отношении новой полезной нагрузки. Ранее подобные атаки были направлены на кражу данных криптокошельков, учетных данных, токенов доступа, SSH-ключей и данных среды разработки.
Полный список из 73 расширений, предположительно входящих в последнюю волну GlassWorm, доступен в отчете Socket. Разработчикам, установившим любое из них, рекомендуется ротировать все секретные ключи и очистить свою среду.
Socket
73 Open VSX Sleeper Extensions Linked to GlassWorm Show New ...
Socket is tracking cloned Open VSX extensions tied to GlassWorm, with several updated from benign-looking sleepers into malware delivery vehicles.
Исследователи Лаборатории Касперского расчехлили APT-группу Geo Likho, которая реализует атаки на организаций в России и в Республике Беларусь как минимум с июля 2024 года.
Ранее в ЛК отследили вредоносную кампанию с применением шпионского ПО Batavia, жертвами которой стали российские промышленные предприятия. Новые артефакты позволили приписать эту активность Geo Likho, отличающуюся тщательно спланированными целевыми атаками.
Выявлены достоверные сходства между кодом начальных VBE-загрузчиков предыдущих и актуальных кампаний, кодом функций импланта первого этапа атаки и сходства в расшифрованных строках полезных нагрузок.
Злоумышленники создают уникальные вредоносные файлы для каждой конкретной жертвы. В их поле зрения - машиностроительные предприятия, госструктуры и образовательные учреждения, но главный интерес представляют организации авиационной отрасли и судоходные компании.
Злоумышленники используют спирфишинг в качестве вектора первоначального доступа: когда пользователь переходит по ссылке, которая выглядит как путь к официальному документу, на машину жертвы загружается вредоносный скрипт, запускающий трехступенчатое заражение.
Основная цель APT - кража данных. Все вредоносные инструменты, которые они используют, заточены именно под хищение информации.
Geo Likho крадет у своих жертв не только документы, но и любую другую дополнительную информацию - например, список установленных программ, драйверов и компонентов ОС.
В ходе исследования на основании данных телеметрии в ЛК смогли идентифицировать порядка 260 жертв в России, примерно 20 жертв в Республике Беларусь, а также отдельные заражения в Германии, Сербии и Гонконге (жертвы, вероятнее всего, случайны).
Почти все спирфишинговые письма, а также фейковые документы, отвлекающие внимание пользователя, задействованные в кампаниях Geo Likho, написаны на русском языке. Лингвистическая улика и телеметрия привели ЛК к выводу, что основные цели группы расположены в РФ и РБ.
Злоумышленники используют тот же набор инструментов, что и в предыдущих кампаниях, включая VBE-загрузчик, имплант первого этапа атаки на языке Delphi и вредоносный файл второго этапа атаки на C++.
Кроме того, в ЛК также обнаружили, что злоумышленники стали создавать отдельные вредоносные утилиты под конкретную инфраструктуру жертвы.
В недавних кампаниях ресерчеры выявили большое количество вредоносных доменов Geo Likho. Злоумышленники продолжают активную деятельность и по сей день.
Все имеющиеся данные свидетельствуют о том, что операторы вкладывают значительные ресурсы в разработку своих инструментов, стремясь повторно использовать проверенные вредоносные утилиты.
В целом атаки группы характеризуются тщательной подготовкой, ориентацией на конкретные страны (Россию и Беларусь) и использованием уникальных образцов вредоносного ПО для отдельных жертв, что затрудняет обнаружение заражения.
Технические подробности по недавним находкам с обзором изменений в инфраструктуре и утилитах группы, а также разбором всей цепочки заражения до этапа эксфильтрации - в отчете ЛК.
Ранее в ЛК отследили вредоносную кампанию с применением шпионского ПО Batavia, жертвами которой стали российские промышленные предприятия. Новые артефакты позволили приписать эту активность Geo Likho, отличающуюся тщательно спланированными целевыми атаками.
Выявлены достоверные сходства между кодом начальных VBE-загрузчиков предыдущих и актуальных кампаний, кодом функций импланта первого этапа атаки и сходства в расшифрованных строках полезных нагрузок.
Злоумышленники создают уникальные вредоносные файлы для каждой конкретной жертвы. В их поле зрения - машиностроительные предприятия, госструктуры и образовательные учреждения, но главный интерес представляют организации авиационной отрасли и судоходные компании.
Злоумышленники используют спирфишинг в качестве вектора первоначального доступа: когда пользователь переходит по ссылке, которая выглядит как путь к официальному документу, на машину жертвы загружается вредоносный скрипт, запускающий трехступенчатое заражение.
Основная цель APT - кража данных. Все вредоносные инструменты, которые они используют, заточены именно под хищение информации.
Geo Likho крадет у своих жертв не только документы, но и любую другую дополнительную информацию - например, список установленных программ, драйверов и компонентов ОС.
В ходе исследования на основании данных телеметрии в ЛК смогли идентифицировать порядка 260 жертв в России, примерно 20 жертв в Республике Беларусь, а также отдельные заражения в Германии, Сербии и Гонконге (жертвы, вероятнее всего, случайны).
Почти все спирфишинговые письма, а также фейковые документы, отвлекающие внимание пользователя, задействованные в кампаниях Geo Likho, написаны на русском языке. Лингвистическая улика и телеметрия привели ЛК к выводу, что основные цели группы расположены в РФ и РБ.
Злоумышленники используют тот же набор инструментов, что и в предыдущих кампаниях, включая VBE-загрузчик, имплант первого этапа атаки на языке Delphi и вредоносный файл второго этапа атаки на C++.
Кроме того, в ЛК также обнаружили, что злоумышленники стали создавать отдельные вредоносные утилиты под конкретную инфраструктуру жертвы.
В недавних кампаниях ресерчеры выявили большое количество вредоносных доменов Geo Likho. Злоумышленники продолжают активную деятельность и по сей день.
Все имеющиеся данные свидетельствуют о том, что операторы вкладывают значительные ресурсы в разработку своих инструментов, стремясь повторно использовать проверенные вредоносные утилиты.
В целом атаки группы характеризуются тщательной подготовкой, ориентацией на конкретные страны (Россию и Беларусь) и использованием уникальных образцов вредоносного ПО для отдельных жертв, что затрудняет обнаружение заражения.
Технические подробности по недавним находкам с обзором изменений в инфраструктуре и утилитах группы, а также разбором всей цепочки заражения до этапа эксфильтрации - в отчете ЛК.
Исследователи раскрыли подробности критической уязвимости, затрагивающей LeRobot, открытую робототехническую платформу от Hugging Face,
имеющую почти 24 000 звезд на GitHub, которая может быть использована для RCE.
Речь идёт о CVE-2026-25874 (CVSS: 9,3), которая связана с ненадёжной десериализации данных, вызванный использованием небезопасного формата pickle.
Как отмечается, LeRobot содержит уязвимость небезопасной десериализации в асинхронном конвейере вывода, где pickle.loads() используется для десериализации данных, полученных по неаутентифицированным каналам gRPC без TLS в компонентах сервера политик и клиента робота.
Неавторизованный злоумышленник, имеющий доступ к сети, может добиться выполнения произвольного кода на сервере или клиенте, отправив специально сформированную полезную нагрузку pickle через вызовы gRPC SendPolicyInstructions, SendObservations или GetActions.
По данным Resecurity, проблема затрагивает компонент PolicyServer, использующий асинхронный вывод команд, что позволяет неавторизованному злоумышленнику, имеющему доступ к сетевому порту PolicyServer, отправлять вредоносную сериализованную полезную нагрузку и выполнять произвольные команды операционной системы на хост-машине, на которой запущена эта служба.
Исследователи характеризуют уязвимость как «опасную», поскольку сервис предназначен для систем вывода ИИ, которые, как правило, работают с повышенными привилегиями для доступа к внутренним сетям, наборам данных и дорогостоящим вычислительным ресурсам.
В случае реализации этой уязвимости, злоумышленник сможет совершить широкий спектр действий, включая: RCE, компрометацию хоста PolicyServer, подключенных роботов, кражу конфиденциальных данных (включая ключи API, учетные данные SSH и файлы моделей), горизонтальное перемещение, DoS в работе сервисов, искажение моделей или угрозы физической безопасности.
Обнаруживший проблему исследователь VulnCheck опубликовал дополнительные подробности об этой уязвимости на прошлой неделе, заявляя, что она была успешно апробирована на LeRobot 0.4.3.
В настоящее время проблема остается неустраненной, исправление запланировано в рамках версии 0.6.0.
Интересно, что аналогичный недостаток был независимо был обнаружен также и другим исследователем chenpinji, примерно в декабре 2025 года.
Разработчики LeRobot отреагировали в начале января, признав риск безопасности и отметив, что «эта часть кода нуждается в почти полной переработке, поскольку ее первоначальная реализация была экспериментальной».
Как заявляется, LeRobot до сих пор был в основном инструментом для исследований и прототипирования, поэтому вопросам безопасности при развертывании до настоящего времени не уделялось особого внимания.
По мере того, как LeRobot будет внедряться и развертываться в производственной среде, разработчики заверяют, что будут уделять гораздо больше внимания подобным проблемам. К счастью, будучи проектом с открытым исходным кодом, сообщество также может помочь в этом вопросе.
Полученные результаты еще раз демонстрируют опасность использования формата pickle, поскольку он открывает путь для атак с произвольным выполнением кода путем простой загрузки специально созданного файла.
Ирония в том, что Hugging Face создала Safetensors - формат сериализации, разработанный специально потому, что pickle опасен для данных машинного обучения.
И тем не менее, их собственная роботизированная платформа десериализует управляемые злоумышленниками сетевые входные данные с помощью pickle.loads().
имеющую почти 24 000 звезд на GitHub, которая может быть использована для RCE.
Речь идёт о CVE-2026-25874 (CVSS: 9,3), которая связана с ненадёжной десериализации данных, вызванный использованием небезопасного формата pickle.
Как отмечается, LeRobot содержит уязвимость небезопасной десериализации в асинхронном конвейере вывода, где pickle.loads() используется для десериализации данных, полученных по неаутентифицированным каналам gRPC без TLS в компонентах сервера политик и клиента робота.
Неавторизованный злоумышленник, имеющий доступ к сети, может добиться выполнения произвольного кода на сервере или клиенте, отправив специально сформированную полезную нагрузку pickle через вызовы gRPC SendPolicyInstructions, SendObservations или GetActions.
По данным Resecurity, проблема затрагивает компонент PolicyServer, использующий асинхронный вывод команд, что позволяет неавторизованному злоумышленнику, имеющему доступ к сетевому порту PolicyServer, отправлять вредоносную сериализованную полезную нагрузку и выполнять произвольные команды операционной системы на хост-машине, на которой запущена эта служба.
Исследователи характеризуют уязвимость как «опасную», поскольку сервис предназначен для систем вывода ИИ, которые, как правило, работают с повышенными привилегиями для доступа к внутренним сетям, наборам данных и дорогостоящим вычислительным ресурсам.
В случае реализации этой уязвимости, злоумышленник сможет совершить широкий спектр действий, включая: RCE, компрометацию хоста PolicyServer, подключенных роботов, кражу конфиденциальных данных (включая ключи API, учетные данные SSH и файлы моделей), горизонтальное перемещение, DoS в работе сервисов, искажение моделей или угрозы физической безопасности.
Обнаруживший проблему исследователь VulnCheck опубликовал дополнительные подробности об этой уязвимости на прошлой неделе, заявляя, что она была успешно апробирована на LeRobot 0.4.3.
В настоящее время проблема остается неустраненной, исправление запланировано в рамках версии 0.6.0.
Интересно, что аналогичный недостаток был независимо был обнаружен также и другим исследователем chenpinji, примерно в декабре 2025 года.
Разработчики LeRobot отреагировали в начале января, признав риск безопасности и отметив, что «эта часть кода нуждается в почти полной переработке, поскольку ее первоначальная реализация была экспериментальной».
Как заявляется, LeRobot до сих пор был в основном инструментом для исследований и прототипирования, поэтому вопросам безопасности при развертывании до настоящего времени не уделялось особого внимания.
По мере того, как LeRobot будет внедряться и развертываться в производственной среде, разработчики заверяют, что будут уделять гораздо больше внимания подобным проблемам. К счастью, будучи проектом с открытым исходным кодом, сообщество также может помочь в этом вопросе.
Полученные результаты еще раз демонстрируют опасность использования формата pickle, поскольку он открывает путь для атак с произвольным выполнением кода путем простой загрузки специально созданного файла.
Ирония в том, что Hugging Face создала Safetensors - формат сериализации, разработанный специально потому, что pickle опасен для данных машинного обучения.
И тем не менее, их собственная роботизированная платформа десериализует управляемые злоумышленниками сетевые входные данные с помощью pickle.loads().
GitHub
CVE-2026-25874 - GitHub Advisory Database
LeRobot contains an unsafe deserialization vulnerability...
Forwarded from Social Engineering
• Как думаете, какую инфу можно вытащить из списанных корпоративных жестких дисков, которые продаются на торгах по банкротству и онлайн-барахолках? Может пароли от учетных записей? Базы клиентов? Сканы документов и другие перс. данные? А может все сразу?
• У ребят из Бастион есть хорошая статья, в которой они ответили на все вышеперечисленные вопросы! С помощью бесплатной опенсорс тулзы эксперты смогли вытащить тонну информации, которая принадлежит реальным компаниям (от небольшой транспортной фирмы до гигантской корпорации). Однозначно к прочтению:
➡ https://habr.com/ru/post/967914
S.E. ▪️ infosec.work ▪️ VT
• У ребят из Бастион есть хорошая статья, в которой они ответили на все вышеперечисленные вопросы! С помощью бесплатной опенсорс тулзы эксперты смогли вытащить тонну информации, которая принадлежит реальным компаниям (от небольшой транспортной фирмы до гигантской корпорации). Однозначно к прочтению:
S.E. ▪️ infosec.work ▪️ VT
Please open Telegram to view this post
VIEW IN TELEGRAM
GitHub устранила критическую RCE-уязвимость (CVE-2026-3854), которая позволяла злоумышленникам получить доступ к миллионам частных репозиториев.
Об уязвимости стало известно еще 4 марта 2026 года от исследователей Wiz в рамках программы вознаграждения за обнаружение ошибок GitHub.
Как отметили в GitHub, команде безопасности удалось воспроизвести и подтвердить уязвимость в течение 40 минут, после чего развернуть исправление на GitHub.com менее чем через два часа после получения сообщения.
CVE-2026-3854 затрагивает GitHub.com, GitHub Enterprise Cloud, GitHub Enterprise Cloud с размещением данных, GitHub Enterprise Cloud с управляемыми пользователями предприятия и GitHub Enterprise Server.
Для успешной эксплуатации достаточно одной специально созданной вредоносной команды git push, которая предоставляет злоумышленникам с правами на отправку изменений полный доступ на чтение и запись к частным репозиториям на GitHub.com или уязвимым серверам GitHub Enterprise.
Уязвимость обусловлена тем, как GitHub обрабатывает параметры, предоставляемые пользователями во время операций git push: значения, передаваемые пользователями, включаются во внутренние метаданные сервера без достаточной проверки, что позволяет злоумышленникам внедрять дополнительные поля, которым доверяет нижестоящий сервис.
Злоумышленник может обойти защиту «песочницы» и выполнить произвольный код на сервере, обрабатывающем push-уведомление, путем объединения нескольких внедренных значений в цепочку.
Как заявили исследователи Wiz, реализация на практике этой уязвимости может привести к утечке кода практически всех крупнейших мировых компаний, что делает её одной из самых серьёзных уязвимостей в сфере SaaS, когда-либо обнаруженных.
На GitHub.com эта уязвимость позволяла удаленно выполнять код на узлах общего хранилища. Исследователи Wiz также смогли подтвердить, что миллионы общедоступных и частных репозиториев были доступны на затронутых узлах.
На GitHub Enterprise Server та же уязвимость позволяет полностью скомпрометировать сервер, включая доступ ко всем размещенным репозиториям и внутренним секретам.
Несмотря на то, что GitHub устранила эту серьезную проблему безопасности на GitHub.com в течение 6 часов, администраторам GitHub Enterprise Server (GHES) следует немедленно обновиться, поскольку около 88% доступных экземпляров GHES остаются уязвимыми.
Вместе с тем, расследование не выявило никаких доказательств эксплуатации до публикации информации о ней Wiz, а GitHub заявила, что данные телеметрии подтверждают, что каждый случай аномального пути выполнения кода, вызванного уязвимостью, был обусловлен исключительно тестированием, проведенным исследователями Wiz.
Никакие другие пользователи или учетные записи не активировали код, использованный для эксплуатации этой уязвимости.
Так что, как утверждается, в результате эксплуатации CVE-2026-3854 до развертывания исправлений на GitHub.com не был получен доступ к данным клиентов, их изменение или утечка.
Для GitHub Enterprise Server доступны патчи для всех поддерживаемых версий (3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, 3.20.0 и более поздних), всем клиентам GHES настоятельно рекомендуется немедленно обновиться.
Об уязвимости стало известно еще 4 марта 2026 года от исследователей Wiz в рамках программы вознаграждения за обнаружение ошибок GitHub.
Как отметили в GitHub, команде безопасности удалось воспроизвести и подтвердить уязвимость в течение 40 минут, после чего развернуть исправление на GitHub.com менее чем через два часа после получения сообщения.
CVE-2026-3854 затрагивает GitHub.com, GitHub Enterprise Cloud, GitHub Enterprise Cloud с размещением данных, GitHub Enterprise Cloud с управляемыми пользователями предприятия и GitHub Enterprise Server.
Для успешной эксплуатации достаточно одной специально созданной вредоносной команды git push, которая предоставляет злоумышленникам с правами на отправку изменений полный доступ на чтение и запись к частным репозиториям на GitHub.com или уязвимым серверам GitHub Enterprise.
Уязвимость обусловлена тем, как GitHub обрабатывает параметры, предоставляемые пользователями во время операций git push: значения, передаваемые пользователями, включаются во внутренние метаданные сервера без достаточной проверки, что позволяет злоумышленникам внедрять дополнительные поля, которым доверяет нижестоящий сервис.
Злоумышленник может обойти защиту «песочницы» и выполнить произвольный код на сервере, обрабатывающем push-уведомление, путем объединения нескольких внедренных значений в цепочку.
Как заявили исследователи Wiz, реализация на практике этой уязвимости может привести к утечке кода практически всех крупнейших мировых компаний, что делает её одной из самых серьёзных уязвимостей в сфере SaaS, когда-либо обнаруженных.
На GitHub.com эта уязвимость позволяла удаленно выполнять код на узлах общего хранилища. Исследователи Wiz также смогли подтвердить, что миллионы общедоступных и частных репозиториев были доступны на затронутых узлах.
На GitHub Enterprise Server та же уязвимость позволяет полностью скомпрометировать сервер, включая доступ ко всем размещенным репозиториям и внутренним секретам.
Несмотря на то, что GitHub устранила эту серьезную проблему безопасности на GitHub.com в течение 6 часов, администраторам GitHub Enterprise Server (GHES) следует немедленно обновиться, поскольку около 88% доступных экземпляров GHES остаются уязвимыми.
Вместе с тем, расследование не выявило никаких доказательств эксплуатации до публикации информации о ней Wiz, а GitHub заявила, что данные телеметрии подтверждают, что каждый случай аномального пути выполнения кода, вызванного уязвимостью, был обусловлен исключительно тестированием, проведенным исследователями Wiz.
Никакие другие пользователи или учетные записи не активировали код, использованный для эксплуатации этой уязвимости.
Так что, как утверждается, в результате эксплуатации CVE-2026-3854 до развертывания исправлений на GitHub.com не был получен доступ к данным клиентов, их изменение или утечка.
Для GitHub Enterprise Server доступны патчи для всех поддерживаемых версий (3.14.25, 3.15.20, 3.16.16, 3.17.13, 3.18.8, 3.19.4, 3.20.0 и более поздних), всем клиентам GHES настоятельно рекомендуется немедленно обновиться.
The GitHub Blog
Securing the git push pipeline: Responding to a critical remote code execution vulnerability
How we validated, fixed, and investigated a critical vulnerability in under two hours, and confirmed no exploitation.
Исследователи Лаборатории Касперского раскрыли детали новой уязвимости в архитектуре RPC, позволяющей реализовать ранее неизвестную технику локального повышения привилегий, предположительно, во всех версиях Windows.
Межпроцессное взаимодействие (IPC) - это одна из наиболее сложных технологий в Windows, в основе которой лежит механизм удаленного вызова процедур (RPC), который может функционировать как самостоятельный канал связи или выступать базовым транспортным уровнем для более продвинутых технологий межпроцессного взаимодействия.
В виду своей сложности и широкой распространенности RPC всегда был источником множества проблем безопасности. За прошедшие годы исследователи обнаружили многочисленные уязвимости в службах, использующих RPC, - от локального повышения привилегий до полноценного RCE.
Обнаруженная ЛК техника позволяет процессам с привилегиями имперсонации повышать свои права до SYSTEM и фундаментально отличается от методов, используемых в известном семействе эксплойтов Potato. Хотя Microsoft известно об этой уязвимости, на момент публикации патча нет.
После обнаружения уязвимости команда ЛК подготовила десятистраничный технический отчет с описанием проблемы и ранее рассмотренные сценарии эксплуатации.
Отчет был направлен в Центр реагирования Microsoft (MSRC) 19 сентября 2025 года в порядке уведомления с запросом исправления.
Спустя 20 дней Microsoft ответила, что не считает уязвимость критической. Проблеме присвоили среднюю степень серьезности, в связи с чем немедленное исправление запланировано не было, а CVE не назначен, при этом само обращение микромягкие просто закрыли.
В обосновании своей оценки Microsoft указала, что для эксплуатации требуется наличие привилегии SeImpersonatePrivilege у исходного процесса. Поскольку без этого зачастую невозможно провести успешную атаку, компания сочла, что проблема не требует срочного устранения.
Команда ЛК отнеслась к оценкам Microsoft с уважением и выкатила результаты уже по завершении периода эмбарго. В соответствии с принципами координированного раскрытия из отчета исключены любые детали, которые могут способствовать массовой эксплуатации или ускорить ее.
В новом отчете ЛК исследователи продемонстрировали пять векторов эксплуатации, позволяющих повышать привилегии из контекста различных локальных или сетевых служб до SYSTEM или высокопривилегированных пользователей. Некоторые основаны на принуждении, другие требуют пользовательских действий, а третьи задействуют фоновые службы.
Поскольку в основе лежит косяк в самой архитектуре, количество потенциальных векторов атак не ограничено: любой новый процесс или служба, зависящие от RPC, могут стать дополнительным путем повышения привилегий.
В связи с этим исследователи решили описать саму методику выявления потенциальных уязвимых мест, а также рассмотрели стратегии обнаружения, включая защитные меры, позволяющие снизить риски и смягчить последствия атак.
Как отмечалось ранее, данная уязвимость обусловлена особенностями архитектуры, и для ее полного устранения требуется исправление со стороны Microsoft, затрагивающее первопричину проблемы.
Тем не менее, в ЛК отметили, что организации могут принять меры для обнаружения и снижения рисков эксплуатации. Мониторинг на базе ETW с применением описанного процесса позволяет выявить RPC-исключения в своих средах, в частности случаи, когда RPC-клиенты пытаются подключиться к недоступным серверам.
В некоторых случаях поверхность атаки можно уменьшить, включив соответствующие службы и обеспечив доступность легитимного RPC-сервера. Это снижает риск развертывания поддельных RPC-серверов, имитирующих легитимные конечные точки.
Кроме того, опубликованы инструменты, позволяющие проверить среды на наличие подобного поведения. Проверочные эксплойты доступны также в репозитории.
Все эксплойты протестированы в Windows Server 2022 и Windows Server 2025 с последними обновлениями.
Тем не менее высока вероятность, что данная уязвимость актуальна и для других версий Windows.
Межпроцессное взаимодействие (IPC) - это одна из наиболее сложных технологий в Windows, в основе которой лежит механизм удаленного вызова процедур (RPC), который может функционировать как самостоятельный канал связи или выступать базовым транспортным уровнем для более продвинутых технологий межпроцессного взаимодействия.
В виду своей сложности и широкой распространенности RPC всегда был источником множества проблем безопасности. За прошедшие годы исследователи обнаружили многочисленные уязвимости в службах, использующих RPC, - от локального повышения привилегий до полноценного RCE.
Обнаруженная ЛК техника позволяет процессам с привилегиями имперсонации повышать свои права до SYSTEM и фундаментально отличается от методов, используемых в известном семействе эксплойтов Potato. Хотя Microsoft известно об этой уязвимости, на момент публикации патча нет.
После обнаружения уязвимости команда ЛК подготовила десятистраничный технический отчет с описанием проблемы и ранее рассмотренные сценарии эксплуатации.
Отчет был направлен в Центр реагирования Microsoft (MSRC) 19 сентября 2025 года в порядке уведомления с запросом исправления.
Спустя 20 дней Microsoft ответила, что не считает уязвимость критической. Проблеме присвоили среднюю степень серьезности, в связи с чем немедленное исправление запланировано не было, а CVE не назначен, при этом само обращение микромягкие просто закрыли.
В обосновании своей оценки Microsoft указала, что для эксплуатации требуется наличие привилегии SeImpersonatePrivilege у исходного процесса. Поскольку без этого зачастую невозможно провести успешную атаку, компания сочла, что проблема не требует срочного устранения.
Команда ЛК отнеслась к оценкам Microsoft с уважением и выкатила результаты уже по завершении периода эмбарго. В соответствии с принципами координированного раскрытия из отчета исключены любые детали, которые могут способствовать массовой эксплуатации или ускорить ее.
В новом отчете ЛК исследователи продемонстрировали пять векторов эксплуатации, позволяющих повышать привилегии из контекста различных локальных или сетевых служб до SYSTEM или высокопривилегированных пользователей. Некоторые основаны на принуждении, другие требуют пользовательских действий, а третьи задействуют фоновые службы.
Поскольку в основе лежит косяк в самой архитектуре, количество потенциальных векторов атак не ограничено: любой новый процесс или служба, зависящие от RPC, могут стать дополнительным путем повышения привилегий.
В связи с этим исследователи решили описать саму методику выявления потенциальных уязвимых мест, а также рассмотрели стратегии обнаружения, включая защитные меры, позволяющие снизить риски и смягчить последствия атак.
Как отмечалось ранее, данная уязвимость обусловлена особенностями архитектуры, и для ее полного устранения требуется исправление со стороны Microsoft, затрагивающее первопричину проблемы.
Тем не менее, в ЛК отметили, что организации могут принять меры для обнаружения и снижения рисков эксплуатации. Мониторинг на базе ETW с применением описанного процесса позволяет выявить RPC-исключения в своих средах, в частности случаи, когда RPC-клиенты пытаются подключиться к недоступным серверам.
В некоторых случаях поверхность атаки можно уменьшить, включив соответствующие службы и обеспечив доступность легитимного RPC-сервера. Это снижает риск развертывания поддельных RPC-серверов, имитирующих легитимные конечные точки.
Кроме того, опубликованы инструменты, позволяющие проверить среды на наличие подобного поведения. Проверочные эксплойты доступны также в репозитории.
Все эксплойты протестированы в Windows Server 2022 и Windows Server 2025 с последними обновлениями.
Тем не менее высока вероятность, что данная уязвимость актуальна и для других версий Windows.
GitHub
GitHub - klsecservices/PhantomRPC
Contribute to klsecservices/PhantomRPC development by creating an account on GitHub.
В киберподполье свой движ: хакеры продолжают оттачивать свои TTPs и инструментарий, а также совершать дерзкие нападения.
Исследователи предупреждают, что у программы-вымогателя VECT 2.0 обнаружилась проблема с обработкой одноразовых чисел шифрования, которая приводит к безвозвратному уничтожению любых файлов размером более 128 КБ вместо их шифрования.
Хотя это задуманное хакерами призвано повысить скорость шифрования больших файлов, поскольку при шифровании фрагментов используется один и тот же буфер памяти для вывода nonce, каждый новый nonce перезаписывает предыдущий.
После обработки всех фрагментов в памяти остается только последний сгенерированный одноразовый код, и только он записывается на диск.
В результате, восстанавливается только последняя 25% файла, а предыдущие три части расшифровать невозможно, поскольку одноразовые числа (nonce) были утеряны.
Утерянные одноразовые коды (nonce) также не передаются злоумышленнику, поэтому даже если операторы VECT захотят расшифровать файлы для жертв, платящих выкуп, они не смогут этого сделать.
Занимались вопросом исследователи Check Point и JUMPSEC (1 и 2), которые предостерегают потенциальных жертв от выплаты выкупа, требуемого этой группировкой.
Исследователи обнаружили, что одна и та же уязвимость в обработке одноразовых чисел присутствует во всех вариантах программы-вымогателя VECT 2.0, включая Windows, Linux и ESXi, поэтому во всех случаях применяется один и тот же механизм удаления данных.
VECT рекламировалась на одной из последних версий BreachForums, приглашая зарегистрированных пользователей стать партнерами и рассылая ключи доступа через личные сообщения тем, кто проявил интерес.
При этом согласно недавним сообщениям, банда Vect активно сотрудничает с группой TeamPCP, вымогая кеш у компаний, пострадавших от недавних атак Trivy и Checkmarx на цепочку поставок KICS.
А коллеги по цеху из банды Kyber потрудились и разработали программу-вымогатель, которая, как утверждается, поддерживает криптографию, устойчивую к квантовым атакам.
В этом есть доля правды, но только для некоторых её версий.
Участники из ShinyHunters ничего не придумали нового, но зато успешно препарировали видеохостинговую платформу Vimeo, угрожая опубликовать данные, если не будет выплачен выкуп.
Группа похитила данные из облачного хранилища Snowflake компании после взлома инструмента мониторинга облачных затрат Anodot в начале этого месяца.
Теперь ведут медленную и методичную кампанию по вымогательству денег у клиентов.
Среди предыдущих жертв также были GTA Rockstar Games, Zara и Payoneer.
На Ближнем Востоке иранская Handala слила личные данные почти 2400 морпехов США, дислоцированных в регионе Персидского залива, включая информацию о семьях, домашних адресах, базах и пр. Пока неясно, откуда были получены эти данные.
Продолжаем наблюдение.
Исследователи предупреждают, что у программы-вымогателя VECT 2.0 обнаружилась проблема с обработкой одноразовых чисел шифрования, которая приводит к безвозвратному уничтожению любых файлов размером более 128 КБ вместо их шифрования.
Хотя это задуманное хакерами призвано повысить скорость шифрования больших файлов, поскольку при шифровании фрагментов используется один и тот же буфер памяти для вывода nonce, каждый новый nonce перезаписывает предыдущий.
После обработки всех фрагментов в памяти остается только последний сгенерированный одноразовый код, и только он записывается на диск.
В результате, восстанавливается только последняя 25% файла, а предыдущие три части расшифровать невозможно, поскольку одноразовые числа (nonce) были утеряны.
Утерянные одноразовые коды (nonce) также не передаются злоумышленнику, поэтому даже если операторы VECT захотят расшифровать файлы для жертв, платящих выкуп, они не смогут этого сделать.
Занимались вопросом исследователи Check Point и JUMPSEC (1 и 2), которые предостерегают потенциальных жертв от выплаты выкупа, требуемого этой группировкой.
Исследователи обнаружили, что одна и та же уязвимость в обработке одноразовых чисел присутствует во всех вариантах программы-вымогателя VECT 2.0, включая Windows, Linux и ESXi, поэтому во всех случаях применяется один и тот же механизм удаления данных.
VECT рекламировалась на одной из последних версий BreachForums, приглашая зарегистрированных пользователей стать партнерами и рассылая ключи доступа через личные сообщения тем, кто проявил интерес.
При этом согласно недавним сообщениям, банда Vect активно сотрудничает с группой TeamPCP, вымогая кеш у компаний, пострадавших от недавних атак Trivy и Checkmarx на цепочку поставок KICS.
А коллеги по цеху из банды Kyber потрудились и разработали программу-вымогатель, которая, как утверждается, поддерживает криптографию, устойчивую к квантовым атакам.
В этом есть доля правды, но только для некоторых её версий.
Участники из ShinyHunters ничего не придумали нового, но зато успешно препарировали видеохостинговую платформу Vimeo, угрожая опубликовать данные, если не будет выплачен выкуп.
Группа похитила данные из облачного хранилища Snowflake компании после взлома инструмента мониторинга облачных затрат Anodot в начале этого месяца.
Теперь ведут медленную и методичную кампанию по вымогательству денег у клиентов.
Среди предыдущих жертв также были GTA Rockstar Games, Zara и Payoneer.
На Ближнем Востоке иранская Handala слила личные данные почти 2400 морпехов США, дислоцированных в регионе Персидского залива, включая информацию о семьях, домашних адресах, базах и пр. Пока неясно, откуда были получены эти данные.
Продолжаем наблюдение.
JUMPSEC
Bugs & Betrayal - Vect Analysis | JUMPSEC
Vect is a newly observed RaaS operation that emerged in December of 2025, with affiliate recruitment and victim postings following shortly after in January 2026
Исследователи Forescout предупреждают, что миллионы серверов удаленного доступа RDP и VNC подключены к интернету, а сотни из них могут предоставлять доступ к промышленным системам управления (ICS) и другим операционным технологиям (OT).
Протоколы RDP (Remote Desktop Protocol) и VNC (Virtual Network Computing), как известно, широко используются для удаленного доступа, и еще более понятно, что точно их не следует напрямую подключать к открытому интернету без защищенного шлюза.
Тем не менее, телеметрия Shodan позволяет задетектить примерно 1,8 миллиона RDP-серверов и 1,6 миллиона VNC-серверов, находящихся в открытом доступе в интернете, большинство из которых расположены в Китае и США.
Forescout полагает, что большинство из них являются ханипотами, интернет-провайдерами и хостинг-провайдерами, однако исследователям все же удалось обнаружить 91 000 RDP-серверов и 29 000 VNC-серверов, которые могут быть связаны с конкретными отраслями.
Значительная часть доступных серверов размещена в организациях, работающих в секторах розничной торговли, образования, услуг, производства и здравоохранения.
Анализ показал, что на многих из уязвимых серверов установлены версии Windows, срок поддержки которых истек или которые больше не поддерживаются. Более 19 000 RDP-серверов уязвимы к старой уязвимости BlueKeep, которую в свое время использовали многие злоумышленники.
Кроме того, почти на 60 000 VNC-серверах не включена аутентификация. Один из наиболее тревожных выводов заключается в том, что 670 из этих VNC-серверов предоставляют прямой доступ к панелям ICS/OT без аутентификации.
Доступ к таким киберфизическим системам может быть чрезвычайно ценным для злоумышленников, и угроза носит вовсе не теоретический характер.
В частности, в киберподполье недавно просочился инструмент, предназначенный для сканирования протоколов RDP, VNC и OT, который на практике применялся для взлома насосной станции для откачки грунтовых вод в Израиле и системы SCADA в Турции и Чехии.
Помимо этих атак Forescout отметила, что киберпреступники, движимые жаждой наживы, используют RDP для распространения программ-вымогателей, а ботнет Redheberg с февраля заразил почти 40 000 незащищенных серверов VNC.
Но, как мы уже не раз наблюдали, такие атаки на цепочку мудаков практически невозможно остановить. Но будем посмотреть.
Протоколы RDP (Remote Desktop Protocol) и VNC (Virtual Network Computing), как известно, широко используются для удаленного доступа, и еще более понятно, что точно их не следует напрямую подключать к открытому интернету без защищенного шлюза.
Тем не менее, телеметрия Shodan позволяет задетектить примерно 1,8 миллиона RDP-серверов и 1,6 миллиона VNC-серверов, находящихся в открытом доступе в интернете, большинство из которых расположены в Китае и США.
Forescout полагает, что большинство из них являются ханипотами, интернет-провайдерами и хостинг-провайдерами, однако исследователям все же удалось обнаружить 91 000 RDP-серверов и 29 000 VNC-серверов, которые могут быть связаны с конкретными отраслями.
Значительная часть доступных серверов размещена в организациях, работающих в секторах розничной торговли, образования, услуг, производства и здравоохранения.
Анализ показал, что на многих из уязвимых серверов установлены версии Windows, срок поддержки которых истек или которые больше не поддерживаются. Более 19 000 RDP-серверов уязвимы к старой уязвимости BlueKeep, которую в свое время использовали многие злоумышленники.
Кроме того, почти на 60 000 VNC-серверах не включена аутентификация. Один из наиболее тревожных выводов заключается в том, что 670 из этих VNC-серверов предоставляют прямой доступ к панелям ICS/OT без аутентификации.
Доступ к таким киберфизическим системам может быть чрезвычайно ценным для злоумышленников, и угроза носит вовсе не теоретический характер.
В частности, в киберподполье недавно просочился инструмент, предназначенный для сканирования протоколов RDP, VNC и OT, который на практике применялся для взлома насосной станции для откачки грунтовых вод в Израиле и системы SCADA в Турции и Чехии.
Помимо этих атак Forescout отметила, что киберпреступники, движимые жаждой наживы, используют RDP для распространения программ-вымогателей, а ботнет Redheberg с февраля заразил почти 40 000 незащищенных серверов VNC.
Но, как мы уже не раз наблюдали, такие атаки на цепочку мудаков практически невозможно остановить. Но будем посмотреть.
Forescout
RDP Security: CPS Threats Spark Need for Secure Remote Access
RDP security and VNC servers are weak and exposed across industries, per research from Forescout’s Vedere Labs. See the segments most affected.
Исследователи раскрыли подробности LPE-уязвимости в Linux, которая позволяет непривилегированному локальному пользователю получить права root.
Она отслеживается как CVE-2026-31431 (CVSS: 7,8 и была названа Xint.io и Theori - Copy Fail. Как отмечают исследователи, непривилегированный пользователь может записать четыре управляемых байта в кэш страниц любого читаемого файла в системе Linux для получения root.
Фактически уязвимость связана с логической ошибкой в криптографической подсистеме ядра Linux, а именно в модуле algif_aead. Проблема была обнаружена в коммите исходного кода от августа 2017 года.
Успешная эксплуатация позволяет простому скрипту на Python размером 732 байта редактировать исполняемый файл с флагом setuid и получать права root практически во всех дистрибутивах Linux, выпущенных с 2017 года, включая Amazon Linux, RHEL, SUSE и Ubuntu.
Сам эксплойт на Python реализуется через сокет AF_ALG в связке с authencesn(hmac(sha256),cbc(aes)) путем запуска операции записи в кэшированной копии ядра /usr/bin/su и вызова execve("/usr/bin/su") для загрузки внедренного шеллкода и запуска его от имени root.
Несмотря на то, что сама по себе эта уязвимость не может быть использована удаленно, локальный непривилегированный пользователь может получить root-права, просто повредив кэш страниц исполняемого файла с установленным флагом setuid.
Эта же уязвимость также имеет последствия для других контейнеров, поскольку кэш страниц используется всеми процессами в системе.
В свою очередь, в ответ на раскрытие разработчики различных дистрибутивов Linux выпустили собственные предупреждения (Amazon Linux, Debian, Red Hat Enterprise Linux, SUSE и Ubuntu)
Примечсательно, что Copy Fail перекликается с Dirty Pipe (CVE-2022-0847), другой уязвимостью LPE в ядре Linux, которая позволяет непривилегированным пользователям внедрять данные в кэш страниц файлов, доступных только для чтения, и в конечном итоге перезаписывать конфиденциальные файлы в системе для выполнения кода.
Как отметили в Bugcrowd, ошибка копирования - это примитив того же класса, но в другой подсистеме. Оптимизация на месте 2017 года в algif_aead позволяет странице кэша страниц попасть в список доступных для записи целевых файлов ядра для операции AEAD, отправленной через сокет AF_ALG.
Непривилегированный процесс затем может запустить splice() в этом сокете и выполнить небольшую целевую запись в кэш страниц файла, которым он не владеет».
Опасность этой уязвимости заключается в том, что она может быть четко активирована и не требует наличия состояний гонки или смещения ядра. Более того, один и тот же эксплойт работает во всех дистрибутивах.
В целом, в Xint.io ее считают уникальной, поскольку она обладает четырьмя свойствами, которые почти никогда не встречаются вместе: портативна, миниатюрна, скрытна и совместима с различными контейнерами.
Она позволяет любой учетной записи пользователя, независимо от уровня ее доступа, повысить свои привилегии до полного административного доступа. Она также позволяет обходить песочницу и работает во всех версиях и дистрибутивах Linux.
Она отслеживается как CVE-2026-31431 (CVSS: 7,8 и была названа Xint.io и Theori - Copy Fail. Как отмечают исследователи, непривилегированный пользователь может записать четыре управляемых байта в кэш страниц любого читаемого файла в системе Linux для получения root.
Фактически уязвимость связана с логической ошибкой в криптографической подсистеме ядра Linux, а именно в модуле algif_aead. Проблема была обнаружена в коммите исходного кода от августа 2017 года.
Успешная эксплуатация позволяет простому скрипту на Python размером 732 байта редактировать исполняемый файл с флагом setuid и получать права root практически во всех дистрибутивах Linux, выпущенных с 2017 года, включая Amazon Linux, RHEL, SUSE и Ubuntu.
Сам эксплойт на Python реализуется через сокет AF_ALG в связке с authencesn(hmac(sha256),cbc(aes)) путем запуска операции записи в кэшированной копии ядра /usr/bin/su и вызова execve("/usr/bin/su") для загрузки внедренного шеллкода и запуска его от имени root.
Несмотря на то, что сама по себе эта уязвимость не может быть использована удаленно, локальный непривилегированный пользователь может получить root-права, просто повредив кэш страниц исполняемого файла с установленным флагом setuid.
Эта же уязвимость также имеет последствия для других контейнеров, поскольку кэш страниц используется всеми процессами в системе.
В свою очередь, в ответ на раскрытие разработчики различных дистрибутивов Linux выпустили собственные предупреждения (Amazon Linux, Debian, Red Hat Enterprise Linux, SUSE и Ubuntu)
Примечсательно, что Copy Fail перекликается с Dirty Pipe (CVE-2022-0847), другой уязвимостью LPE в ядре Linux, которая позволяет непривилегированным пользователям внедрять данные в кэш страниц файлов, доступных только для чтения, и в конечном итоге перезаписывать конфиденциальные файлы в системе для выполнения кода.
Как отметили в Bugcrowd, ошибка копирования - это примитив того же класса, но в другой подсистеме. Оптимизация на месте 2017 года в algif_aead позволяет странице кэша страниц попасть в список доступных для записи целевых файлов ядра для операции AEAD, отправленной через сокет AF_ALG.
Непривилегированный процесс затем может запустить splice() в этом сокете и выполнить небольшую целевую запись в кэш страниц файла, которым он не владеет».
Опасность этой уязвимости заключается в том, что она может быть четко активирована и не требует наличия состояний гонки или смещения ядра. Более того, один и тот же эксплойт работает во всех дистрибутивах.
В целом, в Xint.io ее считают уникальной, поскольку она обладает четырьмя свойствами, которые почти никогда не встречаются вместе: портативна, миниатюрна, скрытна и совместима с различными контейнерами.
Она позволяет любой учетной записи пользователя, независимо от уровня ее доступа, повысить свои привилегии до полного административного доступа. Она также позволяет обходить песочницу и работает во всех версиях и дистрибутивах Linux.
Xint
Copy Fail — 732 Bytes to Root
CVE-2026-31431. 100% Reliable Linux LPE — no race, no per-distro offsets, page-cache write that bypasses on-disk file-integrity tools and crosses containers. Found by Xint Code.
В результате атаки на цепочку поставок, по всей видимости, группой TeamPCP были скомпрометированы официальные пакеты SAP npm с целью кражи учетных данных и токенов аутентификации из систем разработчиков.
Исследователи в области безопасности сообщают, что в результате взлома пострадали четыре пакета в NPM: cap-js/sqlite – v2.2.2, cap-js/postgres – v2.2.2, cap-js/db-service – v2.10.1 и mbt – v1.2.48.
Все они поддерживают модель программирования облачных приложений SAP (CAP) и Cloud MTA, которые широко используются в корпоративной разработке.
По лданным Aikido и Socket (1 и 2), в скомпрометированные пакеты был внесены изменения, включающие вредоносный скрипт preinstall, который автоматически запускается при установке пакета npm.
Он запускает загрузчик с именем setup.mjs, который загружает среду выполнения JavaScript Bun с GitHub и использует её для выполнения сильно обфусцированного полезного кода execution.js.
Данная вредоносная ПО представляет собой стилер, используемый для хищения самых разнообразных учетных данных как с компьютеров разработчиков, так и из сред CI/CD, включая: токены аутентификации npm и GitHub, SSH-ключи и учетные данные разработчика, учетные данные для облачных сервисов AWS, Azure и Google Cloud, конфигурацию и секреты Kubernetes, секреты и переменные среды конвейера CI/CD.
Вредоносная ПО также пытается извлечь секреты непосредственно из памяти исполнителя CI, аналогично тому, как TeamPCP извлекала учетные данные в ходе ранее задокументированных атака на цепочки поставок.
На CI-раннерах полезная нагрузка выполняет встроенный скрипт на Python, который считывает файлы /proc/<pid>/maps и /proc/<pid>/mem для процесса Runner.Worker, чтобы извлечь каждый секрет, соответствующий "key" :{ "value": "...", "isSecret":true}, непосредственно из памяти раннера, минуя все маскировки логов, применяемые платформой CI.
Причем этот сканер памяти для поиска секретов структурно идентичен тому, который был описан в инцидентах с Bitwarden и Checkmarx.
После сбора данные шифруются и загружаются в общедоступные репозитории GitHub под учетной записью жертвы. Они содержат описание «Появился мини-Shai-Hulud», которое также похоже на строку «Shai-Hulud: Третье пришествие», обнаруженную в атаке на цепочку поставок Bitwarden.
Вредоносная ПО также использует поиск по коммитам GitHub в качестве механизма для извлечения токенов и получения дальнейшего доступа.
Сообщения коммитов, соответствующие OhNoWhatsGoingOnWithGitHub:<base64>, декодируются в токены GitHub и проверяются на наличие доступа к репозиторию. Как и в предыдущих атаках, развернутая полезная нагрузка также включает код для самораспространения на другие пакеты.
Используя украденные учетные данные npm или GitHub, злоумышленник пытается модифицировать другие пакеты и репозитории, к которым получает доступ, и внедряет тот же вредоносный код для дальнейшего распространения.
Исследователи со средней степенью уверенности связали эту атаку с группой TeamPCP, которые использовали аналогичный код и тактику в предыдущих атаках на цепочки поставок против Trivy, Checkmarx и Bitwarden.
Пока неясно, каким образом злоумышленники скомпрометировали процесс публикации npm в SAP, сообщается, что токен NPM мог быть раскрыт из-за неправильно настроенного задания CircleCI. В SAP пока ничего не комментируют.
Исследователи в области безопасности сообщают, что в результате взлома пострадали четыре пакета в NPM: cap-js/sqlite – v2.2.2, cap-js/postgres – v2.2.2, cap-js/db-service – v2.10.1 и mbt – v1.2.48.
Все они поддерживают модель программирования облачных приложений SAP (CAP) и Cloud MTA, которые широко используются в корпоративной разработке.
По лданным Aikido и Socket (1 и 2), в скомпрометированные пакеты был внесены изменения, включающие вредоносный скрипт preinstall, который автоматически запускается при установке пакета npm.
Он запускает загрузчик с именем setup.mjs, который загружает среду выполнения JavaScript Bun с GitHub и использует её для выполнения сильно обфусцированного полезного кода execution.js.
Данная вредоносная ПО представляет собой стилер, используемый для хищения самых разнообразных учетных данных как с компьютеров разработчиков, так и из сред CI/CD, включая: токены аутентификации npm и GitHub, SSH-ключи и учетные данные разработчика, учетные данные для облачных сервисов AWS, Azure и Google Cloud, конфигурацию и секреты Kubernetes, секреты и переменные среды конвейера CI/CD.
Вредоносная ПО также пытается извлечь секреты непосредственно из памяти исполнителя CI, аналогично тому, как TeamPCP извлекала учетные данные в ходе ранее задокументированных атака на цепочки поставок.
На CI-раннерах полезная нагрузка выполняет встроенный скрипт на Python, который считывает файлы /proc/<pid>/maps и /proc/<pid>/mem для процесса Runner.Worker, чтобы извлечь каждый секрет, соответствующий "key" :{ "value": "...", "isSecret":true}, непосредственно из памяти раннера, минуя все маскировки логов, применяемые платформой CI.
Причем этот сканер памяти для поиска секретов структурно идентичен тому, который был описан в инцидентах с Bitwarden и Checkmarx.
После сбора данные шифруются и загружаются в общедоступные репозитории GitHub под учетной записью жертвы. Они содержат описание «Появился мини-Shai-Hulud», которое также похоже на строку «Shai-Hulud: Третье пришествие», обнаруженную в атаке на цепочку поставок Bitwarden.
Вредоносная ПО также использует поиск по коммитам GitHub в качестве механизма для извлечения токенов и получения дальнейшего доступа.
Сообщения коммитов, соответствующие OhNoWhatsGoingOnWithGitHub:<base64>, декодируются в токены GitHub и проверяются на наличие доступа к репозиторию. Как и в предыдущих атаках, развернутая полезная нагрузка также включает код для самораспространения на другие пакеты.
Используя украденные учетные данные npm или GitHub, злоумышленник пытается модифицировать другие пакеты и репозитории, к которым получает доступ, и внедряет тот же вредоносный код для дальнейшего распространения.
Исследователи со средней степенью уверенности связали эту атаку с группой TeamPCP, которые использовали аналогичный код и тактику в предыдущих атаках на цепочки поставок против Trivy, Checkmarx и Bitwarden.
Пока неясно, каким образом злоумышленники скомпрометировали процесс публикации npm в SAP, сообщается, что токен NPM мог быть раскрыт из-за неправильно настроенного задания CircleCI. В SAP пока ничего не комментируют.
www.aikido.dev
Mini Shai-Hulud Targets SAP npm Packages With a Bun-Based Secret Stealer
Compromised SAP npm packages use a Bun-based preinstall payload to steal GitHub, npm, cloud, and CI secrets, then spread via GitHub using OhNoWhatsGoingOnWithGitHub.
Критическая уязвимость затрагивает все версии cPanel, кроме последних, а также панель управления WebHost Manager (WHM), позволяя реализовать получение доступа к панели управления без аутентификации.
Уязвимость в настоящее время идентифицирована как CVE-2026-41940 и имеет оценку серьезности 9,8. Она была устранена в экстренном обновлении, однако для получения исправленной версии ПО требуется выполнить команду вручную.
WHM и cPanel, принадлежащие WebPros International, представляют собой панели управления хостингом на базе Linux и обеспечивают управление сервером и сайтом.
WHM обеспечивает управление на уровне сервера, а cPanel предоставляет административный доступ к административной панели сайта, почте и базам данных.
Оба продукта входят в число наиболее распространенных панелей управления хостингом, популярных среди многих хостинг-провайдеров благодаря стандартизированным интерфейсам, простоте использования для нетехнических пользователей и глубокой интеграции с распространенными платформами хостинга.
Технические подробности публично не разглашались, но серьезность проблемы представляется значительной, поскольку Namecheap временно заблокировала доступ к портам 2083 и 2087, используемым для WHM и cPanel, дабы защитить клиентов до выхода обновлений.
Хостинг-провайдер заявил, что уязвимость связана с эксплойтом аутентификации при входе в систему, который обеспечивает несанкционированный доступ к панели управления.
Через несколько часов после уведомления от Namecheap, cPanel выкатила бюллетень по безопасности, в котором сообщила, что проблема была устранена в версиях: 11.110.0.97, 11.118.0.63, 11.126.0.54, 11.132.0.29, 11.136.0.5 и 11.134.0.20.
Для установки безопасной версии поставщик рекомендует администраторам выполнить команду /scripts/upcp –force, которая запускает процесс обновления cPanel и принудительно выполняет его, даже если система считает, что уже работает на последней версии.
Серверы, работающие под управлением неподдерживаемой версии cPanel, не имеют возможности получения обновлений безопасности. В этом случае администраторам рекомендуется как можно скорее обновить cPanel до поддерживаемой версии.
Злоумышленник, получивший доступ к cPanel, сможет контролировать всё, что находится в учетной записи хостинга, от веб-сайтов и данных до электронной почты.
Кроме того, он получит возможность использовать этот доступ для внедрения бэкдоров или веб-оболочек, перенаправления пользователей на вредоносные ресурсы, кражи конфиденциальных файлов, рассылки спама или фишинга, а также сбора паролей из конфигурационных файлов.
WHM предоставляет доступ ко всему серверу и всем размещенным на нем веб-сайтам, так что злоумышленник сможет создавать и удалять учетные записи cPanel, иметь постоянный доступ к машине и использовать ее для различных вредоносных действий (например, прокси-трафик, спам, распространение вредоносного ПО, ботнет).
Владельцам веб-сайтов, использующим затронутые интерфейсы управления, следует убедиться, что они обновились до исправленной версии.
Уязвимость в настоящее время идентифицирована как CVE-2026-41940 и имеет оценку серьезности 9,8. Она была устранена в экстренном обновлении, однако для получения исправленной версии ПО требуется выполнить команду вручную.
WHM и cPanel, принадлежащие WebPros International, представляют собой панели управления хостингом на базе Linux и обеспечивают управление сервером и сайтом.
WHM обеспечивает управление на уровне сервера, а cPanel предоставляет административный доступ к административной панели сайта, почте и базам данных.
Оба продукта входят в число наиболее распространенных панелей управления хостингом, популярных среди многих хостинг-провайдеров благодаря стандартизированным интерфейсам, простоте использования для нетехнических пользователей и глубокой интеграции с распространенными платформами хостинга.
Технические подробности публично не разглашались, но серьезность проблемы представляется значительной, поскольку Namecheap временно заблокировала доступ к портам 2083 и 2087, используемым для WHM и cPanel, дабы защитить клиентов до выхода обновлений.
Хостинг-провайдер заявил, что уязвимость связана с эксплойтом аутентификации при входе в систему, который обеспечивает несанкционированный доступ к панели управления.
Через несколько часов после уведомления от Namecheap, cPanel выкатила бюллетень по безопасности, в котором сообщила, что проблема была устранена в версиях: 11.110.0.97, 11.118.0.63, 11.126.0.54, 11.132.0.29, 11.136.0.5 и 11.134.0.20.
Для установки безопасной версии поставщик рекомендует администраторам выполнить команду /scripts/upcp –force, которая запускает процесс обновления cPanel и принудительно выполняет его, даже если система считает, что уже работает на последней версии.
Серверы, работающие под управлением неподдерживаемой версии cPanel, не имеют возможности получения обновлений безопасности. В этом случае администраторам рекомендуется как можно скорее обновить cPanel до поддерживаемой версии.
Злоумышленник, получивший доступ к cPanel, сможет контролировать всё, что находится в учетной записи хостинга, от веб-сайтов и данных до электронной почты.
Кроме того, он получит возможность использовать этот доступ для внедрения бэкдоров или веб-оболочек, перенаправления пользователей на вредоносные ресурсы, кражи конфиденциальных файлов, рассылки спама или фишинга, а также сбора паролей из конфигурационных файлов.
WHM предоставляет доступ ко всему серверу и всем размещенным на нем веб-сайтам, так что злоумышленник сможет создавать и удалять учетные записи cPanel, иметь постоянный доступ к машине и использовать ее для различных вредоносных действий (например, прокси-трафик, спам, распространение вредоносного ПО, ботнет).
Владельцам веб-сайтов, использующим затронутые интерфейсы управления, следует убедиться, что они обновились до исправленной версии.
Namecheap Status
[RESOLVED] CRITICAL SECURITY VULNERABILITY WITH CPANEL/WHM, APRIL 28, 2026 - Namecheap Status
Dear Customers, We regret to inform you that a critical security vulnerability has been identified in cPanel software affecting all currently supported versions. This vulnerability relates to an authentication login exploit that could allow unauthorized access…
В плагин 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