Известный расовый румынский инфосек журналист Каталин Чимпану 19 декабря написал, что c 20 числа (🫡) уходит на зимние каникулы аккурат до 12 января.
Спалился гэбешник кровавый!
Спалился гэбешник кровавый!
Risky.Biz
Risky Bulletin: Belarus deploys spyware on journalists' phones
Suspect arrested for installing malware on ferry boat; France arrests Interior Ministry hacker; and new Cisco and SonicWall zero-days.
Исследователи из Лаборатории Касперского сообщает о новой кампании, связанной с распространением вредоносной ПО WebRAT через репозитории GitHub, которые, как утверждается, содержат PoC-эксплойты для недавно обнаруженных уязвимостей.
Ранее распространявшийся через пиратское ПО и читы для таких игр, как Roblox, Counter Strike и Rust, WebRAT представляет собой бэкдор с возможностями кражи информации, появившийся в начале уходящего года.
Согласно майскому отчету Solar 4RAYS, WebRAT способен красть учетные данные для аккаунтов Steam, Discord и Telegram, а также данные криптокошельков, а также шпионить за жертвами через веб-камеры и делать скрины.
По меньшей мере с сентября операторы начали распространять вредоносное ПО через тщательно созданные репозитории, которые якобы включали эксплойты для ряда уязвимостей.
Среди заявленных следующие:
- CVE-2025-59295: уязвимость переполнения буфера в куче в компоненте Windows MSHTML/Internet Explorer, позволяющая выполнять произвольный код с помощью специально сформированных данных, передаваемых по сети.
- CVE-2025-10294: критическая уязвимость, позволяющая обойти систему аутентификации в плагине OwnID Passwordless Login для WordPress и входить в систему под любыми учетными данными, включая администраторов.
- CVE-2025-59230: уязвимость в службе диспетчера подключений удаленного доступа Windows (RasMan), которая позволяет прошедшему локальную аутентификацию злоумышленнику повысить свои привилегии до уровня SYSTEM в затронутых установках Windows.
В общей сложности исследователям ЛК удалось выявить 15 репозиториев, распространяющих WebRAT.
Во всех содержится общая ориентирующая информация об ошибке и доступных способах её устранения.
Судя по структуре изложения, в Лаборатории Касперского полагают, что текст был сгенерирован с помощью модели искусственного интеллекта.
Вредоносная ПО задействует несколько методов для обеспечения своего постоянного присутствия, включая модификацию реестра Windows, использование планировщика задач и внедрение в случайные системные каталоги.
Исследователи утверждают, что фейковые эксплойты распространяются в виде защищенного паролем ZIP-архива с пустым файлом, в имени которого содержится пароль, поврежденным DLL-файлом, выступающим в роли приманки, а также включает пакетный файл, используемый в цепочке выполнения, и основной дроппер под названием rasmanesc.exe.
По данным аналитиков, вредоносная ПО повышает привилегии, отключает Windows Defender, а затем загружает и запускает WebRAT по жестко закодированному URL-адресу.
При этом вариант WebRAT, использованный в этой кампании, ничем не отличается от ранее задокументированных образцов и обладает теми же возможностями, что были описаны в предыдущих отчетах.
Использование фейковых эксплойтов на GitHub для - уже не новая тактика, поскольку она широко использовалась в прошлом. Совсем недавно злоумышленники продвигали фейковый эксплойт LDAPNightmare на GitHub для распространения инфокрада.
Все вредоносные репозитории GitHub, связанные с WebRAT, по наводке ЛК были удалены.
Однако разработчикам и ИБ-специалистам следует быть осторожными, поскольку злоумышленники, вероятно, будут размещать новые приманки под разными именами издателей.
Ранее распространявшийся через пиратское ПО и читы для таких игр, как Roblox, Counter Strike и Rust, WebRAT представляет собой бэкдор с возможностями кражи информации, появившийся в начале уходящего года.
Согласно майскому отчету Solar 4RAYS, WebRAT способен красть учетные данные для аккаунтов Steam, Discord и Telegram, а также данные криптокошельков, а также шпионить за жертвами через веб-камеры и делать скрины.
По меньшей мере с сентября операторы начали распространять вредоносное ПО через тщательно созданные репозитории, которые якобы включали эксплойты для ряда уязвимостей.
Среди заявленных следующие:
- CVE-2025-59295: уязвимость переполнения буфера в куче в компоненте Windows MSHTML/Internet Explorer, позволяющая выполнять произвольный код с помощью специально сформированных данных, передаваемых по сети.
- CVE-2025-10294: критическая уязвимость, позволяющая обойти систему аутентификации в плагине OwnID Passwordless Login для WordPress и входить в систему под любыми учетными данными, включая администраторов.
- CVE-2025-59230: уязвимость в службе диспетчера подключений удаленного доступа Windows (RasMan), которая позволяет прошедшему локальную аутентификацию злоумышленнику повысить свои привилегии до уровня SYSTEM в затронутых установках Windows.
В общей сложности исследователям ЛК удалось выявить 15 репозиториев, распространяющих WebRAT.
Во всех содержится общая ориентирующая информация об ошибке и доступных способах её устранения.
Судя по структуре изложения, в Лаборатории Касперского полагают, что текст был сгенерирован с помощью модели искусственного интеллекта.
Вредоносная ПО задействует несколько методов для обеспечения своего постоянного присутствия, включая модификацию реестра Windows, использование планировщика задач и внедрение в случайные системные каталоги.
Исследователи утверждают, что фейковые эксплойты распространяются в виде защищенного паролем ZIP-архива с пустым файлом, в имени которого содержится пароль, поврежденным DLL-файлом, выступающим в роли приманки, а также включает пакетный файл, используемый в цепочке выполнения, и основной дроппер под названием rasmanesc.exe.
По данным аналитиков, вредоносная ПО повышает привилегии, отключает Windows Defender, а затем загружает и запускает WebRAT по жестко закодированному URL-адресу.
При этом вариант WebRAT, использованный в этой кампании, ничем не отличается от ранее задокументированных образцов и обладает теми же возможностями, что были описаны в предыдущих отчетах.
Использование фейковых эксплойтов на GitHub для - уже не новая тактика, поскольку она широко использовалась в прошлом. Совсем недавно злоумышленники продвигали фейковый эксплойт LDAPNightmare на GitHub для распространения инфокрада.
Все вредоносные репозитории GitHub, связанные с WebRAT, по наводке ЛК были удалены.
Однако разработчикам и ИБ-специалистам следует быть осторожными, поскольку злоумышленники, вероятно, будут размещать новые приманки под разными именами издателей.
Securelist
Webrat, disguised as exploits, is spreading via GitHub repositories
We dissect the new Webrat campaign where the Trojan spreads via GitHub repositories, masquerading as critical vulnerability exploits to target cybersecurity researchers.
Исследователи BI.ZONE DFIR и BI.ZONE Compromise Assessment подвели итоги, рассказав об актуальных тенденциях по части того, как российские компании справлялись с кибератаками в 2025 году.
По данным исследователей, 2025 год подтвердил главную тенденцию последних лет: количество кибератак на российские компании продолжает расти, а инциденты становятся все более сложными и разрушительными.
Кибератаки постоянно эволюционируют, но базовые мотивы и методы злоумышленников остаются прежними: финансовая выгода доминирует, а фишинг - самый распространенный способ проникновения.
Тем не менее каждый год выделяется всплесками активности в отдельных направлениях:
- 2022: Россия столкнулась с заметным ростом дефейсов и хактивистских кампаний.
- 2023: акцент сместился на публикации утечек и массовые сливы данных.
- 2024: злоумышленники активно шифровали инфраструктуры организаций.
- 2025: все чаще использовались вайперы, полностью уничтожающие как данные, так даже и сетевое оборудование.
Современные атаки становятся многоэтапными, злоумышленники присутствуют в инфраструктуре все дольше и используют легитимные инструменты администрирования в комбинации с самописным вредоносным ПО.
В таких условиях ключевым фактором устойчивости становится не только защита периметра, но и скорость реагирования, глубина анализа и готовность к восстановлению.
Из ключевых метрик 2025 года (среднее значение):
- Зафиксированы публичные упоминания о компрометации более чем 40 российских компаний. В ряде инцидентов последствия распространялись за пределы инфраструктуры и затрагивали работу сервисов, с которыми взаимодействуют обычные пользователи.
- Срок присутствия злоумышленника в инфраструктуре - 42 дня (12,5 минуты - 181 день), время восстановления основной функциональности бизнес‑процессов - 3 дня, а полной - 14 дней.
- Количество хостов в инфраструктуре, с которой работали команды DFIR и CA - 3484 (в самом крупном инциденте - до 50 000), число пользователей - 18 159 (в крупных - до 200 000), число хостов-точек закрепления атакующих - 5 (максимум - 14).
- Распределение инцидентов по отраслям: ритейл - 31%, IT - 26%, транспорт, госсектор и телеком - по 11%, образование и ТЭК - по 5%.
Из ключевых тенденций атак и новых угроз 2025 года:
- Если раньше основной целью было получение выкупа, то в этом году все чаще встречаются случаи, когда злоумышленники сразу переходят к уничтожению инфраструктуры.
- В инцидентах с классическим шифрованием по‑прежнему популярны известные инструменты - Babuk, LockBit и Rancoz.
- Атакующие продолжают вести публичные телеграм‑каналы, в которых регулярно публикуют данные, даже если фактический ущерб компании был минимален.
- Злоумышленники стремятся устойчиво закрепиться в инфраструктуре и организовать туннели удаленного доступа. В Linux безальтернативным вариантом остается gsocket, а в среде Windows - все чаще отдается предпочтение Localtonet.
- Число атак через подрядчиков существенно выросло: в 2025 году около 30% всех инцидентов (ранее - 15%).
По данным исследователей, 2025 год подтвердил главную тенденцию последних лет: количество кибератак на российские компании продолжает расти, а инциденты становятся все более сложными и разрушительными.
Кибератаки постоянно эволюционируют, но базовые мотивы и методы злоумышленников остаются прежними: финансовая выгода доминирует, а фишинг - самый распространенный способ проникновения.
Тем не менее каждый год выделяется всплесками активности в отдельных направлениях:
- 2022: Россия столкнулась с заметным ростом дефейсов и хактивистских кампаний.
- 2023: акцент сместился на публикации утечек и массовые сливы данных.
- 2024: злоумышленники активно шифровали инфраструктуры организаций.
- 2025: все чаще использовались вайперы, полностью уничтожающие как данные, так даже и сетевое оборудование.
Современные атаки становятся многоэтапными, злоумышленники присутствуют в инфраструктуре все дольше и используют легитимные инструменты администрирования в комбинации с самописным вредоносным ПО.
В таких условиях ключевым фактором устойчивости становится не только защита периметра, но и скорость реагирования, глубина анализа и готовность к восстановлению.
Из ключевых метрик 2025 года (среднее значение):
- Зафиксированы публичные упоминания о компрометации более чем 40 российских компаний. В ряде инцидентов последствия распространялись за пределы инфраструктуры и затрагивали работу сервисов, с которыми взаимодействуют обычные пользователи.
- Срок присутствия злоумышленника в инфраструктуре - 42 дня (12,5 минуты - 181 день), время восстановления основной функциональности бизнес‑процессов - 3 дня, а полной - 14 дней.
- Количество хостов в инфраструктуре, с которой работали команды DFIR и CA - 3484 (в самом крупном инциденте - до 50 000), число пользователей - 18 159 (в крупных - до 200 000), число хостов-точек закрепления атакующих - 5 (максимум - 14).
- Распределение инцидентов по отраслям: ритейл - 31%, IT - 26%, транспорт, госсектор и телеком - по 11%, образование и ТЭК - по 5%.
Из ключевых тенденций атак и новых угроз 2025 года:
- Если раньше основной целью было получение выкупа, то в этом году все чаще встречаются случаи, когда злоумышленники сразу переходят к уничтожению инфраструктуры.
- В инцидентах с классическим шифрованием по‑прежнему популярны известные инструменты - Babuk, LockBit и Rancoz.
- Атакующие продолжают вести публичные телеграм‑каналы, в которых регулярно публикуют данные, даже если фактический ущерб компании был минимален.
- Злоумышленники стремятся устойчиво закрепиться в инфраструктуре и организовать туннели удаленного доступа. В Linux безальтернативным вариантом остается gsocket, а в среде Windows - все чаще отдается предпочтение Localtonet.
- Число атак через подрядчиков существенно выросло: в 2025 году около 30% всех инцидентов (ранее - 15%).
BI.ZONE
От выявления компрометации до реагирования: как российские компании справлялись с кибератаками в 2025 году
Специалисты BI.ZONE DFIR и BI.ZONE Compromise Assessment рассказали об актуальных тенденциях
Очень странные дела с ASUS Live Update: активно обсуждается уязвимость CVE-2025-59374 (CVSS 9,3), при этом некоторые заголовки в специализированных ИБ-изданиях указывают на недавнюю или продолжающуюся ее эксплуатацию.
При этом в пояснениях к CVE фигурирует задокументирована несколько лет назад атака на цепочку поставок программного продукта, снятого с поддержки (EoL).
В недавних публикациях по CVE-2025-59374 проблема была представлена как новый актуальный риск безопасности после включения в каталог известных эксплуатируемых уязвимостей (KEV) CISA.
Однако при более внимательном изучении этого кейса становится ясно, что в реальности все гораздо сложнее.
Представленная в описании атака на цепочку поставок была обнаружена и задюокументована командой GReAT Лаборатории Касперского в 2018-2019 гг. и получила название Operation ShadowHammer.
Тогда в результате сложной APT-кампании на серверы Live Update в небольшое количество устройств был внедрен вредоносный код, а вредоносные модифицированные бинарные файлы выборочно доставлялись на узкую категорию целевых систем.
В общей сложности затронула более миллиона пользователей, загрузивших утилиту ASUS Live Update на свои компьютеры, в том числе более чем 57 000 пользователей решений ЛК.
Кроме того, исследователи ЛК также нашли взаимосвязи ShadowHammer с атакой на CCleaner и цепочку поставок ПО NetSarang в 2017 году.
Возвращаясь к пояснениям CVE основное уведомление от производителя, на которое дана ссылка в записи CVE, датируется 2019 годом.
Причем уведомление также содержит ссылку на раздел FAQ (этот) с датой последнего обновления: 06.12.2025 20:09.
Однако ссылка с номером 1018727 существовала еще в 2019 году, когда это уведомление было впервые опубликовано.
На самой странице FAQ отсутствует метаданные о времени первой публикации. Вместо этого, она просто была обновлена и отображает упомянутую выше дату 6 декабря.
Собственно, это временная страница ASUS, периодически обновляемая для предоставления информации о пути обновления, включая последнюю версию, которую пользователям следует использовать для утилиты Live Update от производителя.
Но на странице по-прежнему отображаются (более старые) инструкции по устранению неполадок со скриншотами, на которых указаны даты 2019 года.
Но странно еще и другое.
Согласно записи CVE, поддержка затронутого ASUS Live Update прекратилась в октябре 2021 года, и «ни одно из поддерживаемых в настоящее время устройств или продуктов не затронуто этой проблемой».
Однако обновленная страница часто задаваемых вопросов ASUS за этот месяц противоречит этой формулировке, подразумевая, что поддержка окончательно прекратилась 4 декабря 2025 года и последняя версия - 3.6.15.
В более ранних вариациях (2019-2022 гг.) этого раздела FAQ рекомендовалось обновиться до версии 3.6.8 (последней на тот момент).
Теперь же 3.6.15 теперь указана как «последняя версия». И, судя по всему, она существовала еще в марте 2024 года, если не раньше.
В общем, в совокупности все имеющиеся данные свидетельствуют о том, что присвоение статуса CVE отражает ретроспективную попытку классификации, формально документирующую известную атаку, которая произошла до присвоения статуса CVE, а не для устранения новой.
Но кто знает, может с того времени, что-то и продолжалось?
А кто знает - молчат: в ASUS и CISA по поводу всего этого от комментариев отказались.
При этом в пояснениях к CVE фигурирует задокументирована несколько лет назад атака на цепочку поставок программного продукта, снятого с поддержки (EoL).
В недавних публикациях по CVE-2025-59374 проблема была представлена как новый актуальный риск безопасности после включения в каталог известных эксплуатируемых уязвимостей (KEV) CISA.
Однако при более внимательном изучении этого кейса становится ясно, что в реальности все гораздо сложнее.
Представленная в описании атака на цепочку поставок была обнаружена и задюокументована командой GReAT Лаборатории Касперского в 2018-2019 гг. и получила название Operation ShadowHammer.
Тогда в результате сложной APT-кампании на серверы Live Update в небольшое количество устройств был внедрен вредоносный код, а вредоносные модифицированные бинарные файлы выборочно доставлялись на узкую категорию целевых систем.
В общей сложности затронула более миллиона пользователей, загрузивших утилиту ASUS Live Update на свои компьютеры, в том числе более чем 57 000 пользователей решений ЛК.
Кроме того, исследователи ЛК также нашли взаимосвязи ShadowHammer с атакой на CCleaner и цепочку поставок ПО NetSarang в 2017 году.
Возвращаясь к пояснениям CVE основное уведомление от производителя, на которое дана ссылка в записи CVE, датируется 2019 годом.
Причем уведомление также содержит ссылку на раздел FAQ (этот) с датой последнего обновления: 06.12.2025 20:09.
Однако ссылка с номером 1018727 существовала еще в 2019 году, когда это уведомление было впервые опубликовано.
На самой странице FAQ отсутствует метаданные о времени первой публикации. Вместо этого, она просто была обновлена и отображает упомянутую выше дату 6 декабря.
Собственно, это временная страница ASUS, периодически обновляемая для предоставления информации о пути обновления, включая последнюю версию, которую пользователям следует использовать для утилиты Live Update от производителя.
Но на странице по-прежнему отображаются (более старые) инструкции по устранению неполадок со скриншотами, на которых указаны даты 2019 года.
Но странно еще и другое.
Согласно записи CVE, поддержка затронутого ASUS Live Update прекратилась в октябре 2021 года, и «ни одно из поддерживаемых в настоящее время устройств или продуктов не затронуто этой проблемой».
Однако обновленная страница часто задаваемых вопросов ASUS за этот месяц противоречит этой формулировке, подразумевая, что поддержка окончательно прекратилась 4 декабря 2025 года и последняя версия - 3.6.15.
В более ранних вариациях (2019-2022 гг.) этого раздела FAQ рекомендовалось обновиться до версии 3.6.8 (последней на тот момент).
Теперь же 3.6.15 теперь указана как «последняя версия». И, судя по всему, она существовала еще в марте 2024 года, если не раньше.
В общем, в совокупности все имеющиеся данные свидетельствуют о том, что присвоение статуса CVE отражает ретроспективную попытку классификации, формально документирующую известную атаку, которая произошла до присвоения статуса CVE, а не для устранения новой.
Но кто знает, может с того времени, что-то и продолжалось?
А кто знает - молчат: в ASUS и CISA по поводу всего этого от комментариев отказались.
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…
Исследователи из Positive Technologies продолжают подводить киберитоги 2025 года и делятся прогнозами на ближайшее будущее.
В новом отчете - решили заглянуть в госучреждения и нормативку. Отметим основное:
1. Киберсреда и мотивация массовых взломщиков изменились
В 2022 году госсектор был объектом почти каждой шестой успешной кибератаки: всего 403 инцидента, а около половины нападений были направлены на официальные веб-ресурсы органов власти.
Затем атаки приобрели яркий хактивистский характер.
Причем помимо политического манифеста в 2025 году хактивисты стали преследовать финансовую выгоду и совершать более дерзкие разрушительные киберпреступления, дестабилизируя работу госучреждений и КИИ.
2. Первые серьезные требования ИБ к работе с подрядчиками и интеграции ИИ
В 2025 году приказ ФСТЭК от 11.04.2025 № 117 значительно расширил меры по защите информации, сформировав новую регуляторную рамку, в которой госструктуры должны использовать ИИ осознанно, прозрачно и под управлением, исключая риски искажения решений, утечки данных и неконтролируемого влияния алгоритмов на критически важные функции.
3. Безопасность объектов КИИ будет контролироваться жестче
Федеральный закон от 07.04.2025 № 58-ФЗ (вступил в силу 1 сентября 2025 года) вводит новую обязанность для субъектов КИИ: теперь они должны информировать НКЦКИ не только о зафиксированных инцидентах, но и о компьютерных атаках.
В ближайшее время также будут определены и утверждены перечни типовых отраслевых объектов КИИ с подробным описанием их инфраструктуры и особенностей ее категорирования.
4. Отраслевые центры ГосСОПКА на подходе
Стало известно, что готовится нормативно-правовой акт об аккредитации центров ГосСОПКА.
Кроме того, прорабатываются концепции создания отраслевых центров компетенций по кибербезу, которые одновременно будут являться и отраслевыми центрами ГосСОПКА.
5. Две стороны одной медали: почти полное импортозамещение СЗИ и нехватка экспертов
Уровень импортозамещения решений для кибербезопасности в госсекторе достиг 95–98% (под данным ФСТЭК).
Однако основной проблемой на объектах КИИ и в госучреждениях остается нехватка квалифицированных кадров под высокотехнологичное ПО.
6. Интерес злоумышленников к отечественному софту не угасает
Госорганы (и, частично, бизнес) следуют курсу импортозамещения, вследствие чего российские ОС и ПО постоянно находятся в фокусе внимания атакующих, причем эта тенденция сохраняется с 2022 года и останется актуальной в 2026.
7. Острые проблемы регионов и пути их решения
На рынке не хватает около 50 тысяч специалистов в области ИБ, тогда как образовательная система ежегодно готовит лишь 8-10 тысяч профильных выпускников, и до 46% вакансий в госсекторе остаются незакрытыми месяцами, что сказывается прежде всего, на регионах.
8. Старт непрерывного обучения
Программы обучения сотрудников госучреждений станут регулярными: повышать уровень киберграмотности будут не только рядовые госслужащие, но и ИТ-специалисты.
9. Оценка устойчивости госсектора на практике, с наглядным результатом
В новом отчете - решили заглянуть в госучреждения и нормативку. Отметим основное:
1. Киберсреда и мотивация массовых взломщиков изменились
В 2022 году госсектор был объектом почти каждой шестой успешной кибератаки: всего 403 инцидента, а около половины нападений были направлены на официальные веб-ресурсы органов власти.
Затем атаки приобрели яркий хактивистский характер.
Причем помимо политического манифеста в 2025 году хактивисты стали преследовать финансовую выгоду и совершать более дерзкие разрушительные киберпреступления, дестабилизируя работу госучреждений и КИИ.
2. Первые серьезные требования ИБ к работе с подрядчиками и интеграции ИИ
В 2025 году приказ ФСТЭК от 11.04.2025 № 117 значительно расширил меры по защите информации, сформировав новую регуляторную рамку, в которой госструктуры должны использовать ИИ осознанно, прозрачно и под управлением, исключая риски искажения решений, утечки данных и неконтролируемого влияния алгоритмов на критически важные функции.
3. Безопасность объектов КИИ будет контролироваться жестче
Федеральный закон от 07.04.2025 № 58-ФЗ (вступил в силу 1 сентября 2025 года) вводит новую обязанность для субъектов КИИ: теперь они должны информировать НКЦКИ не только о зафиксированных инцидентах, но и о компьютерных атаках.
В ближайшее время также будут определены и утверждены перечни типовых отраслевых объектов КИИ с подробным описанием их инфраструктуры и особенностей ее категорирования.
4. Отраслевые центры ГосСОПКА на подходе
Стало известно, что готовится нормативно-правовой акт об аккредитации центров ГосСОПКА.
Кроме того, прорабатываются концепции создания отраслевых центров компетенций по кибербезу, которые одновременно будут являться и отраслевыми центрами ГосСОПКА.
5. Две стороны одной медали: почти полное импортозамещение СЗИ и нехватка экспертов
Уровень импортозамещения решений для кибербезопасности в госсекторе достиг 95–98% (под данным ФСТЭК).
Однако основной проблемой на объектах КИИ и в госучреждениях остается нехватка квалифицированных кадров под высокотехнологичное ПО.
6. Интерес злоумышленников к отечественному софту не угасает
Госорганы (и, частично, бизнес) следуют курсу импортозамещения, вследствие чего российские ОС и ПО постоянно находятся в фокусе внимания атакующих, причем эта тенденция сохраняется с 2022 года и останется актуальной в 2026.
7. Острые проблемы регионов и пути их решения
На рынке не хватает около 50 тысяч специалистов в области ИБ, тогда как образовательная система ежегодно готовит лишь 8-10 тысяч профильных выпускников, и до 46% вакансий в госсекторе остаются незакрытыми месяцами, что сказывается прежде всего, на регионах.
8. Старт непрерывного обучения
Программы обучения сотрудников госучреждений станут регулярными: повышать уровень киберграмотности будут не только рядовые госслужащие, но и ИТ-специалисты.
9. Оценка устойчивости госсектора на практике, с наглядным результатом
Хабр
Киберустойчивость госсектора: ужесточение законов и еще больше ИИ
На дворе конец 2025 года, и мы продолжаем украшать нашу киберёлку подводить киберитоги и делиться киберпрогнозами. Мы уже вглядывались в кибершторм, оценили ландшафт киберугроз , направленных на...
Forwarded from Social Engineering
• На сайте hacktricks есть очень объемная Wiki по безопасной настройке Docker. Крайне много информации по Socket, Capabilities, Escape from Containers и т.д. Рекомендую к изучению:
• Basic Docker Engine Security:
• Containers Security Features:
• К слову, в канале есть еще тонна дополнительного материала по Docker:
S.E. ▪️ infosec.work ▪️ VT
Please open Telegram to view this post
VIEW IN TELEGRAM
MongoDB предупреждает о необходимости немедленного устранения серьезной уязвимости, которая может быть использована для атак с удаленным выполнением кода, направленных на уязвимые серверы.
MongoDB - популярная нереляционная система управления базами данных, которая, в отличие от реляционных баз данных, таких как PostgreSQL и MySQL, хранит данные в документах BSON (Binary JSON), а не в таблицах.
Программное обеспечение для работы с базами данных используется более чем 62 500 клиентами по всему миру, включая десятки компаний из списка Fortune 500.
Уязвимость отслеживается как CVE-2025-14847 и затрагивает сразу несколько версий MongoDB и MongoDB Server.
Она может быть использована неаутентифицированными злоумышленниками в атаках низкой сложности, не требующих взаимодействия с пользователем.
Проблема связана с некорректной обработкой несоответствия параметра длины, что может позволить злоумышленникам выполнить произвольный код и потенциально получить контроль над целевыми устройствами.
Уязвимость на стороне клиента в реализации zlib сервера может привести к возврату неинициализированной памяти кучи без аутентификации на сервере.
Уязвимость затрагивает следующие версии MongoDB: 8.2.0-8.2.3, 8.0.0-8.0.16, 7.0.0-7.0.26, 6.0.0-6.0.26, 5.0.0-5.0.31, 4.4.0-4.4.29, а также все версии MongoDB Server v4.2, v4.0 и v3.6.
Для устранения уязвимости в системе безопасности и блокировки потенциальных атак администраторам рекомендуется немедленно обновить MongoDB до версий 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 или 4.4.30.
В MongoDB настоятельно рекомендуют немедленно обновить систему.
В противном случае хотя бы отключить сжатие zlib на сервере MongoDB, запустив mongod или mongos с параметром networkMessageCompressors или net.compression.compressors.
MongoDB - популярная нереляционная система управления базами данных, которая, в отличие от реляционных баз данных, таких как PostgreSQL и MySQL, хранит данные в документах BSON (Binary JSON), а не в таблицах.
Программное обеспечение для работы с базами данных используется более чем 62 500 клиентами по всему миру, включая десятки компаний из списка Fortune 500.
Уязвимость отслеживается как CVE-2025-14847 и затрагивает сразу несколько версий MongoDB и MongoDB Server.
Она может быть использована неаутентифицированными злоумышленниками в атаках низкой сложности, не требующих взаимодействия с пользователем.
Проблема связана с некорректной обработкой несоответствия параметра длины, что может позволить злоумышленникам выполнить произвольный код и потенциально получить контроль над целевыми устройствами.
Уязвимость на стороне клиента в реализации zlib сервера может привести к возврату неинициализированной памяти кучи без аутентификации на сервере.
Уязвимость затрагивает следующие версии MongoDB: 8.2.0-8.2.3, 8.0.0-8.0.16, 7.0.0-7.0.26, 6.0.0-6.0.26, 5.0.0-5.0.31, 4.4.0-4.4.29, а также все версии MongoDB Server v4.2, v4.0 и v3.6.
Для устранения уязвимости в системе безопасности и блокировки потенциальных атак администраторам рекомендуется немедленно обновить MongoDB до версий 8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 или 4.4.30.
В MongoDB настоятельно рекомендуют немедленно обновить систему.
В противном случае хотя бы отключить сжатие zlib на сервере MongoDB, запустив mongod или mongos с параметром networkMessageCompressors или net.compression.compressors.
Исследователи из Лаборатории Касперского под конец года не на шутку разошлись и, пожалуй, активнее всех делятся новыми исследованиями.
Среди последних отчетов специалистам по тестированию будет интересно взглянуть на разбор ранее не описанного DCOM-объекта, который может использоваться как для выполнения команд, так и для потенциального закрепления в системе.
Ведь горизонтальное перемещение в сети становится все более трудной задачей, особенно в хорошо защищенных средах, а одна из распространенных техник перемещения полагается на DCOM-объекты.
За прошедшие годы было обнаружено множество разных DCOM-объектов. Некоторые опираются на системные компоненты Windows, другие зависят от стороннего ПО, например Microsoft Office, а некоторые объекты и вовсе являются недокументированными.
Новая задокументированная ЛК техника обращается к известным методам получения первоначального доступа и закрепления в системе через элементы панели управления.
Изменение значений реестра для регистрации вредоносных CPL-файлов - плохая практика с точки зрения этики red teaming.
Однако апплеты панели управления могут быть зарегистрированы в разных ключах реестра, что оставляет потенциальные возможности для эксплуатации.
Другое исследование позволяет комплексно понять, что происходит с украденными данными после фишинговой атаки.
Обычно фишинговая атака заключается в том, что пользователь переходит по мошеннической ссылке и вводит свои учетные данные на мошенническом ресурсе.
Но кража информации - это только начало.
В тот момент, когда конфиденциальные сведения попадают в руки злоумышленников, они превращаются в товар и отправляются на конвейер теневого рынка.
Собственно, в ЛК проследили путь украденных данных, начиная от их сбора через различные инструменты, такие как Telegram-боты и продвинутые панели управления, и заканчивая продажей и последующим многоразовым использованием в новых атаках.
Кроме того, исследователи обратили внимание на то, как однажды утекшие логин и пароль становятся частью объемного цифрового досье и почему злоумышленники могут использовать даже старые утечки для целевых атак спустя годы после компрометации данных.
И, наконец, оценка эффективности использования SIEM.
Как многим известно, SIEM - довольно сложная система, предоставляющая широкие и гибкие возможности по детектированию угроз.
В силу сложности эффективность ее работы сильно зависит от того, как она настроена и какие источники к ней подключены.
Однократной настройки SIEM при внедрении недостаточно: с течением времени меняется как инфраструктура организации, так и методы злоумышленников. Для эффективной работы, SIEM-система должна учитывать актуальное положение дел.
Ресерчеры ЛК в своей статье рассматривают типичные ошибки при эксплуатации SIEM, одновременно указавая, как их можно исправить. Для каждого случая также приводят способы самостоятельной проверки.
Материал основан на оценке эффективности Kaspersky Unified Monitoring and Analysis Platform (KUMA), соответственно, все конкретные примеры, команды и названия полей взяты из этого решения.
Однако, как отмечает в ЛК, методику проверки, выявленные проблемы и способы повышения эффективности системы несложно экстраполировать на любые другие SIEM.
Среди последних отчетов специалистам по тестированию будет интересно взглянуть на разбор ранее не описанного DCOM-объекта, который может использоваться как для выполнения команд, так и для потенциального закрепления в системе.
Ведь горизонтальное перемещение в сети становится все более трудной задачей, особенно в хорошо защищенных средах, а одна из распространенных техник перемещения полагается на DCOM-объекты.
За прошедшие годы было обнаружено множество разных DCOM-объектов. Некоторые опираются на системные компоненты Windows, другие зависят от стороннего ПО, например Microsoft Office, а некоторые объекты и вовсе являются недокументированными.
Новая задокументированная ЛК техника обращается к известным методам получения первоначального доступа и закрепления в системе через элементы панели управления.
Изменение значений реестра для регистрации вредоносных CPL-файлов - плохая практика с точки зрения этики red teaming.
Однако апплеты панели управления могут быть зарегистрированы в разных ключах реестра, что оставляет потенциальные возможности для эксплуатации.
Другое исследование позволяет комплексно понять, что происходит с украденными данными после фишинговой атаки.
Обычно фишинговая атака заключается в том, что пользователь переходит по мошеннической ссылке и вводит свои учетные данные на мошенническом ресурсе.
Но кража информации - это только начало.
В тот момент, когда конфиденциальные сведения попадают в руки злоумышленников, они превращаются в товар и отправляются на конвейер теневого рынка.
Собственно, в ЛК проследили путь украденных данных, начиная от их сбора через различные инструменты, такие как Telegram-боты и продвинутые панели управления, и заканчивая продажей и последующим многоразовым использованием в новых атаках.
Кроме того, исследователи обратили внимание на то, как однажды утекшие логин и пароль становятся частью объемного цифрового досье и почему злоумышленники могут использовать даже старые утечки для целевых атак спустя годы после компрометации данных.
И, наконец, оценка эффективности использования SIEM.
Как многим известно, SIEM - довольно сложная система, предоставляющая широкие и гибкие возможности по детектированию угроз.
В силу сложности эффективность ее работы сильно зависит от того, как она настроена и какие источники к ней подключены.
Однократной настройки SIEM при внедрении недостаточно: с течением времени меняется как инфраструктура организации, так и методы злоумышленников. Для эффективной работы, SIEM-система должна учитывать актуальное положение дел.
Ресерчеры ЛК в своей статье рассматривают типичные ошибки при эксплуатации SIEM, одновременно указавая, как их можно исправить. Для каждого случая также приводят способы самостоятельной проверки.
Материал основан на оценке эффективности Kaspersky Unified Monitoring and Analysis Platform (KUMA), соответственно, все конкретные примеры, команды и названия полей взяты из этого решения.
Однако, как отмечает в ЛК, методику проверки, выявленные проблемы и способы повышения эффективности системы несложно экстраполировать на любые другие SIEM.
Securelist
Удаленное выполнение команд с помощью DCOM-объектов
Эксперт «Лаборатории Касперского» описывает, как злоумышленники могут использовать DCOM-интерфейсы для загрузки вредоносных DLL в память с помощью реестра и панели управления Windows.
Fortinet сообщает о новой волне эксплуатации пятилетней уязвимости SSL VPN в FortiOS, которая реализуется при определенных конфигурациях.
Речь идёт о CVE-2020-12812 (CVSS: 5.2), представляющей собой уязвимость некорректной аутентификации в SSL VPN на FortiOS, которая позволяет успешно войти в систему без запроса второго фактора аутентификации, если регистр имени пользователя был изменён.
Как упоминалось в 2020 году, это возможно, если в настройках «локальная аутентификация пользователя» включена 2Fa, а тип аутентификации пользователя установлен на удаленный метод аутентификации (например, LDAP).
Проблема возникает из-за непоследовательного сопоставления данных с учетом регистра между локальной и удаленной аутентификацией.
С тех пор на этой уязвимости различные злоумышленники неплохо набили руку, а в 2021 году она вошла в перечень наиболее эксплуатируемых в атаках на устройства периметра.
В новом вчерашнем уведомлении Fortinet отметила, что для успешного срабатывания CVE-2020-12812 необходима следующая конфигурация:
- Локальные записи пользователей на FortiGate с 2Fa, ссылающиеся на LDAP.
- Эти же пользователи должны состоять в группе на LDAP-сервере.
- На устройстве FortiGate необходимо настроить как минимум одну группу LDAP, в которую входят пользователи 2Fa, и она должна использоваться в политике аутентификации, которая может включать, например, административных пользователей, SSL или IPSEC VPN.
Если условия выполнены, уязвимость приводит к тому, что пользователи LDAP с настроенной 2Fa проходят аутентификацию непосредственно в LDAP, поскольку FortiGate обрабатывает имена пользователей с учетом регистра, в то время как каталог LDAP этого не делает.
В частности, если пользователь входит в систему с именем Jsmith, jSmith, JSmith, jsmiTh или любым другим именем, которое не является точным совпадением с jsmith, FortiGate не будет сопоставлять данные входа с локальным пользователем.
Такая конфигурация заставляет FortiGate рассматривать другие варианты аутентификации. FortiGate будет проверять другие настроенные политики аутентификации брандмауэра.
После неудачной попытки сопоставления с jsmith, FortiGate обнаруживает дополнительную настроенную группу Auth-Group, а оттуда - LDAP-сервер, и при условии корректности учетных данных аутентификация будет успешной независимо от настроек локальной политики пользователя (2Fa и отключенные учетные записи).
В результате уязвимость позволяет авторизовать администраторов или пользователей VPN без 2Fa.
Fortinet выпустила FortiOS 6.0.10, 6.2.4 и 6.4.1 в июле 2020 года для устранения этой проблемы.
Кроме того, для предотвращения проблемы с обходом аутентификации следует отключить чувствительность к регистру имени пользователя (а для FortiOS версий 6.0.13, 6.2.10, 6.4.7, 7.0.1 и более поздних - чувствительность к имени пользователя).
В качестве дополнительной меры защиты стоит рассмотреть возможность удаления вторичной группы LDAP, если она не требуется, поскольку это полностью исключает линию атаки.
При этом в недавно опубликованных рекомендациях не содержится никакой конкретной информации о характере атак, нацеленных эту уязвимость, а также о том, были ли какие-либо из этих инцидентов успешными.
Fortinet также посоветовала пострадавшим клиентам связаться со службой поддержки и сбросить все учетные данные в случае обнаружения признаков аутентификации администраторов или пользователей VPN без 2Fa.
Речь идёт о CVE-2020-12812 (CVSS: 5.2), представляющей собой уязвимость некорректной аутентификации в SSL VPN на FortiOS, которая позволяет успешно войти в систему без запроса второго фактора аутентификации, если регистр имени пользователя был изменён.
Как упоминалось в 2020 году, это возможно, если в настройках «локальная аутентификация пользователя» включена 2Fa, а тип аутентификации пользователя установлен на удаленный метод аутентификации (например, LDAP).
Проблема возникает из-за непоследовательного сопоставления данных с учетом регистра между локальной и удаленной аутентификацией.
С тех пор на этой уязвимости различные злоумышленники неплохо набили руку, а в 2021 году она вошла в перечень наиболее эксплуатируемых в атаках на устройства периметра.
В новом вчерашнем уведомлении Fortinet отметила, что для успешного срабатывания CVE-2020-12812 необходима следующая конфигурация:
- Локальные записи пользователей на FortiGate с 2Fa, ссылающиеся на LDAP.
- Эти же пользователи должны состоять в группе на LDAP-сервере.
- На устройстве FortiGate необходимо настроить как минимум одну группу LDAP, в которую входят пользователи 2Fa, и она должна использоваться в политике аутентификации, которая может включать, например, административных пользователей, SSL или IPSEC VPN.
Если условия выполнены, уязвимость приводит к тому, что пользователи LDAP с настроенной 2Fa проходят аутентификацию непосредственно в LDAP, поскольку FortiGate обрабатывает имена пользователей с учетом регистра, в то время как каталог LDAP этого не делает.
В частности, если пользователь входит в систему с именем Jsmith, jSmith, JSmith, jsmiTh или любым другим именем, которое не является точным совпадением с jsmith, FortiGate не будет сопоставлять данные входа с локальным пользователем.
Такая конфигурация заставляет FortiGate рассматривать другие варианты аутентификации. FortiGate будет проверять другие настроенные политики аутентификации брандмауэра.
После неудачной попытки сопоставления с jsmith, FortiGate обнаруживает дополнительную настроенную группу Auth-Group, а оттуда - LDAP-сервер, и при условии корректности учетных данных аутентификация будет успешной независимо от настроек локальной политики пользователя (2Fa и отключенные учетные записи).
В результате уязвимость позволяет авторизовать администраторов или пользователей VPN без 2Fa.
Fortinet выпустила FortiOS 6.0.10, 6.2.4 и 6.4.1 в июле 2020 года для устранения этой проблемы.
Кроме того, для предотвращения проблемы с обходом аутентификации следует отключить чувствительность к регистру имени пользователя (а для FortiOS версий 6.0.13, 6.2.10, 6.4.7, 7.0.1 и более поздних - чувствительность к имени пользователя).
В качестве дополнительной меры защиты стоит рассмотреть возможность удаления вторичной группы LDAP, если она не требуется, поскольку это полностью исключает линию атаки.
При этом в недавно опубликованных рекомендациях не содержится никакой конкретной информации о характере атак, нацеленных эту уязвимость, а также о том, были ли какие-либо из этих инцидентов успешными.
Fortinet также посоветовала пострадавшим клиентам связаться со службой поддержки и сбросить все учетные данные в случае обнаружения признаков аутентификации администраторов или пользователей VPN без 2Fa.
Fortinet Blog
Product Security Advisory and Analysis: Observed Abuse of FG-IR-19-283
This blog analysis describes the observed abuse and provides additional context so that administrators can confirm that they are not impacted and guidance based on Fortinet observations to prevent …
Серьезный инцидент затронул пользователей расширения Trust Wallet для Chrome, некоторые из которых после установки скомпрометированных обновлений лишились своих криптосбережений, а потенциальный ущерб оценивается в более чем 6 миллионов долларов.
Trust Wallet - это широко используемый криптокошелек, позволяющий пользователям хранить, управлять и взаимодействовать с цифровыми активами в различных блокчейнах.
Он доступен в виде мобильного приложения и расширения для браузера Chrome, используемого для взаимодействия с децентрализованными приложениями (dApps).
Первые сообщения жертв криптоограблений начали поступать 24 декабря.
Пользователи жаловались на то, что деньги исчезают из их расширений для браузера сразу после простой авторизации.
Причем Trust Wallet выпустила версию 2.68.0 своего расширения для Chrome 24 декабря, незадолго до того, как начали появляться сообщения об инцидентах с выводом средств из кошелька.
По мере того, как росло количество жалоб и предупреждений, в Chrome Web Store незаметно была выпущена версия 2.69 расширения Trust Wallet для Chrome.
В общем, спустя несколько часов после инцидента исследователи обнаружили подозрительный код в версии 2.68.0 расширения Trust Wallet для Chrome.
Пользователи мобильных устройств и всех остальных версий расширений для браузеров, как оказалось, остались не затронуты.
По данным Akinator, подозрительная логика содержится в файле JavaScript под названием 4482.js, который содержит плотно упакованный код, предназначенный для передачи конфиденциальных данных кошелька на внешний сервер.
Мимикрируя под аналитику, он отслеживает активность кошелька и срабатывает при импорте сид-фразы. Данные были отправлены на metrics-trustwallet[.]com, сам домен был зарегистрирован несколько дней назад и теперь недоступен.
Наличие недавно зарегистрированной внешней точки доступа к "метрикам" внутри расширения браузерного кошелька является крайне необычным, учитывая привилегированный доступ расширения к операциям кошелька и конфиденциальным данным.
Как впоследствии подтвердили исследователи, именно эта конечная точка и была связана с утечкой секретной информации.
Вчера вечером Trust Wallet, в свою очередь, подтвердила инцидент безопасности, отмечая затронутую версию 2.68.0 расширения для Chrome, посоветовав пользователям немедленно обновиться до версии 2.69 для решения проблемы.
Тем не менее, в Trust Wallet пока не ответили, будут ли пострадавшим пользователям выплачены компенсации или предложены какие-то варианты возмещения ущерба.
Причем в ходе развития этого инцидента параллельно раскручивалась другая фишинговая кампания, подстроенная под кейс с вредоносным расширением Trust Wallet.
Ряд аккаунтв в X [1, 2] перенаправляли обеспокоенных пользователей на веб-сайт: fix-trustwallet[.]com, который очень точно имитировал бренд Trust Wallet и якобы включал исправления для недавней «уязвимости безопасности».
Однако после нажатия кнопки «Обновить» пользователям отображалась всплывающая форма с запросом фразы восстановления кошелька.
Данные WHOIS указывают на то, что домен fix-trustwallet[.]com был зарегистрирован ранее в этом месяце у того же регистратора, что и metrics-trustwallet[.]com.
Веротяно, оба домена могут быть связаны и потенциально управляться одним и тем же злоумышленником или группой, стоящей за более масштабной атакой.
Но будем посмотреть.
Trust Wallet - это широко используемый криптокошелек, позволяющий пользователям хранить, управлять и взаимодействовать с цифровыми активами в различных блокчейнах.
Он доступен в виде мобильного приложения и расширения для браузера Chrome, используемого для взаимодействия с децентрализованными приложениями (dApps).
Первые сообщения жертв криптоограблений начали поступать 24 декабря.
Пользователи жаловались на то, что деньги исчезают из их расширений для браузера сразу после простой авторизации.
Причем Trust Wallet выпустила версию 2.68.0 своего расширения для Chrome 24 декабря, незадолго до того, как начали появляться сообщения об инцидентах с выводом средств из кошелька.
По мере того, как росло количество жалоб и предупреждений, в Chrome Web Store незаметно была выпущена версия 2.69 расширения Trust Wallet для Chrome.
В общем, спустя несколько часов после инцидента исследователи обнаружили подозрительный код в версии 2.68.0 расширения Trust Wallet для Chrome.
Пользователи мобильных устройств и всех остальных версий расширений для браузеров, как оказалось, остались не затронуты.
По данным Akinator, подозрительная логика содержится в файле JavaScript под названием 4482.js, который содержит плотно упакованный код, предназначенный для передачи конфиденциальных данных кошелька на внешний сервер.
Мимикрируя под аналитику, он отслеживает активность кошелька и срабатывает при импорте сид-фразы. Данные были отправлены на metrics-trustwallet[.]com, сам домен был зарегистрирован несколько дней назад и теперь недоступен.
Наличие недавно зарегистрированной внешней точки доступа к "метрикам" внутри расширения браузерного кошелька является крайне необычным, учитывая привилегированный доступ расширения к операциям кошелька и конфиденциальным данным.
Как впоследствии подтвердили исследователи, именно эта конечная точка и была связана с утечкой секретной информации.
Вчера вечером Trust Wallet, в свою очередь, подтвердила инцидент безопасности, отмечая затронутую версию 2.68.0 расширения для Chrome, посоветовав пользователям немедленно обновиться до версии 2.69 для решения проблемы.
Тем не менее, в Trust Wallet пока не ответили, будут ли пострадавшим пользователям выплачены компенсации или предложены какие-то варианты возмещения ущерба.
Причем в ходе развития этого инцидента параллельно раскручивалась другая фишинговая кампания, подстроенная под кейс с вредоносным расширением Trust Wallet.
Ряд аккаунтв в X [1, 2] перенаправляли обеспокоенных пользователей на веб-сайт: fix-trustwallet[.]com, который очень точно имитировал бренд Trust Wallet и якобы включал исправления для недавней «уязвимости безопасности».
Однако после нажатия кнопки «Обновить» пользователям отображалась всплывающая форма с запросом фразы восстановления кошелька.
Данные WHOIS указывают на то, что домен fix-trustwallet[.]com был зарегистрирован ранее в этом месяце у того же регистратора, что и metrics-trustwallet[.]com.
Веротяно, оба домена могут быть связаны и потенциально управляться одним и тем же злоумышленником или группой, стоящей за более масштабной атакой.
Но будем посмотреть.
X (formerly Twitter)
PeckShieldAlert (@PeckShieldAlert) on X
#PeckShieldAlert The @TrustWallet exploit has drained >$6M worth of cryptos from victims.
While ~$2.8M of the stolen funds remain in the hacker's wallets (#Bitcoin/#EVM/#Solana), the bulk - >$4M in cryptos - has been sent to #CEXs: ~$3.3M to @ChangeNOW_io…
While ~$2.8M of the stolen funds remain in the hacker's wallets (#Bitcoin/#EVM/#Solana), the bulk - >$4M in cryptos - has been sent to #CEXs: ~$3.3M to @ChangeNOW_io…
Исследователи Solar 4RAYS выкатили свой прогноз в отношении киберугроз на 2026 год, отмечая, что ранняя инфомированность об угрозах, которые вот-вот станут актуальными, - это первый шаг к построению надежной защиты.
С чем мы не можем не согласиться, так что выделим главное по предстоящим трендам:
1. Ландшафт угроз и тактика атакующих:
- APT-группировки. Их активность будет напрямую зависеть от геополитической обстановки. Снижение активности после публичного разоблачения некоторых группировок - временная мера для перевооружения.
- Цели атак. Усилится давление на критические отрасли: промышленность, ТЭК, логистику, госсектор и другие социально и экономически значимые отрасли.
- «Кинетический» хактивизм. Хактивизм превратился в инструмент профессионалов, способных наносить реальный физический ущерб инфраструктуре.
- Усложнение атрибуции. Атакующие активно маскируются под других, используя чужие инструменты и инфраструктуру, что затрудняет определение истинного виновника.
- Атаки через подрядчиков (Trusted Relationship Attacks). Это один из основных путей проникновения в крупные компании, безопасность которых усилилась.
2. Уязвимости и целевые платформы:
- Российское ПО. Будет расти эксплуатация уязвимостей в отечественном ПО (почтовые серверы, CMS, мессенджеры) из-за недостаточного внимания к безопасности на этапе разработки.
- Windows 10. Станет главной мишенью из-за прекращения поддержки; уязвимости от Windows 11 будут работать и на 10-й версии, но патчи - выходить реже.
- Панель предпросмотра MS Office. Ожидается волна фишинговых атак с использованием RCE-уязвимостей в этом компоненте.
- Небезопасная десериализация. Будет основным вектором RCE-атак в средах PHP, Java, Python, ASP.NET.
- Атаки на репозитории Open Source. Популярные репозитории (Nuget, Maven и др.) станут целью для внедрения бэкдоров в доверенный код.
3. Вредоносное ПО и техники:
- Банковские трояны с NFC. Будет расти эффективность вредоносов, перехватывающих бесконтактные платежи (например, NFCGate).
- Zero-click атаки на Android. Ожидается увеличение числа эксплойтов для Android, не требующих взаимодействия с пользователем.
- Фишинг ClickFix. Будут нарастать атаки, где жертву через социнженерию вынуждают вручную запускать вредоносные команды, например, в PowerShell.
- Атаки на Linux. Рост числа атак, включая использование руткитов (Puma, Kitsune и др.), из-за импортозамещения и слабой защиты.
- Атаки на macOS. В фокусе злоумышленников будут ключевые компоненты защиты macOS (Keychain, TCC, SIP), так как устройства Apple активно используются в корпоративной среде.
- Маскировка вредоносного трафика. Ожидается усложнение маскировки вредоносного трафика, он будет все больше похож на легитимный трафик атакованной организации. Злоумышленники стремятся использовать те же протоколы, порты, время работы и т.п.
4. ИИ в атаках:
- Вайб-кодинг в вредоносах. Низкоквалифицированные злоумышленники будут массово использовать ИИ (вайб-кодинг) для генерации простого вредоносного ПО.
- Профессиональные группировки (APT). Будут применять LLM для оркестрации сложных атак (пример, фреймворк Hexstrike-AI).
5. Киберпреступность:
- Снижение «порога входа». Растет число группировок, покупающих готовые доступы и инструменты.
- Мошеннические атаки через мессенджеры. Продолжатся атаки, использующие социальную инженерию через популярные мессенджеры и госсервисы.
С чем мы не можем не согласиться, так что выделим главное по предстоящим трендам:
1. Ландшафт угроз и тактика атакующих:
- APT-группировки. Их активность будет напрямую зависеть от геополитической обстановки. Снижение активности после публичного разоблачения некоторых группировок - временная мера для перевооружения.
- Цели атак. Усилится давление на критические отрасли: промышленность, ТЭК, логистику, госсектор и другие социально и экономически значимые отрасли.
- «Кинетический» хактивизм. Хактивизм превратился в инструмент профессионалов, способных наносить реальный физический ущерб инфраструктуре.
- Усложнение атрибуции. Атакующие активно маскируются под других, используя чужие инструменты и инфраструктуру, что затрудняет определение истинного виновника.
- Атаки через подрядчиков (Trusted Relationship Attacks). Это один из основных путей проникновения в крупные компании, безопасность которых усилилась.
2. Уязвимости и целевые платформы:
- Российское ПО. Будет расти эксплуатация уязвимостей в отечественном ПО (почтовые серверы, CMS, мессенджеры) из-за недостаточного внимания к безопасности на этапе разработки.
- Windows 10. Станет главной мишенью из-за прекращения поддержки; уязвимости от Windows 11 будут работать и на 10-й версии, но патчи - выходить реже.
- Панель предпросмотра MS Office. Ожидается волна фишинговых атак с использованием RCE-уязвимостей в этом компоненте.
- Небезопасная десериализация. Будет основным вектором RCE-атак в средах PHP, Java, Python, ASP.NET.
- Атаки на репозитории Open Source. Популярные репозитории (Nuget, Maven и др.) станут целью для внедрения бэкдоров в доверенный код.
3. Вредоносное ПО и техники:
- Банковские трояны с NFC. Будет расти эффективность вредоносов, перехватывающих бесконтактные платежи (например, NFCGate).
- Zero-click атаки на Android. Ожидается увеличение числа эксплойтов для Android, не требующих взаимодействия с пользователем.
- Фишинг ClickFix. Будут нарастать атаки, где жертву через социнженерию вынуждают вручную запускать вредоносные команды, например, в PowerShell.
- Атаки на Linux. Рост числа атак, включая использование руткитов (Puma, Kitsune и др.), из-за импортозамещения и слабой защиты.
- Атаки на macOS. В фокусе злоумышленников будут ключевые компоненты защиты macOS (Keychain, TCC, SIP), так как устройства Apple активно используются в корпоративной среде.
- Маскировка вредоносного трафика. Ожидается усложнение маскировки вредоносного трафика, он будет все больше похож на легитимный трафик атакованной организации. Злоумышленники стремятся использовать те же протоколы, порты, время работы и т.п.
4. ИИ в атаках:
- Вайб-кодинг в вредоносах. Низкоквалифицированные злоумышленники будут массово использовать ИИ (вайб-кодинг) для генерации простого вредоносного ПО.
- Профессиональные группировки (APT). Будут применять LLM для оркестрации сложных атак (пример, фреймворк Hexstrike-AI).
5. Киберпреступность:
- Снижение «порога входа». Растет число группировок, покупающих готовые доступы и инструменты.
- Мошеннические атаки через мессенджеры. Продолжатся атаки, использующие социальную инженерию через популярные мессенджеры и госсервисы.
rt-solar.ru
Киберугрозы 2026: прогноз от Solar 4RAYS. Атаки на Windows 10, ИИ и РФ ПО
Прогноз киберугроз на 2026 год: атаки на Windows 10, рост угроз для российского ПО, ИИ-оружие, фишинг ClickFix и атаки через подрядчиков. Анализ трендов от экспертов Solar 4RAYS
Исследователи из Лаборатории Касперского продолжают анализировать ландшафт угроз для систем промышленной автоматизации, в новом отчете - данные за третий квартал 2025 года.
В третьем квартале 2025 года доля компьютеров АСУ, на которых были заблокированы вредоносные объекты, по сравнению с предыдущим кварталом уменьшилась на 0,4 п.п. и составила 20,1%, а это минимальный показатель за исследуемый период.
В регионах доля компьютеров АСУ, на которых в третьем квартале 2025 года были заблокированы вредоносные объекты, варьируется от 9,2% в Северной Европе до 27,4% в Африке.
Показатель за квартал увеличился в пяти регионах, больше всего - в Восточной Азии, где был отмечен резкий рост доли компьютеров АСУ, связанный с локальным распространением вредоносных скриптов в OT-инфраструктуре организаций в сфере инжиниринга и интеграции АСУ.
Рейтинг исследуемых отраслей и типов ОT-инфраструктур по доле компьютеров АСУ, на которых были заблокированы вредоносные объекты, традиционно возглавили биометрические системы.
В четырех из семи исследуемых отраслей доля компьютеров АСУ, на которых были заблокированы вредоносные объекты, в третьем квартале 2025 года увеличилась.
Больше всего показатель вырос в следующих отраслях инжиниринга и интеграторов АСУ, а также в производстве.
В третьем квартале 2025 года защитные решения Лаборатории Касперского позволили заблокировать в системах промышленной автоматизации вредоносное ПО из 11 356 семейств, относящихся к различным категориям.
В третьем квартале 2025 года доля компьютеров АСУ, на которых были заблокированы ресурсы в интернете из списка запрещенных, уменьшилась до 4,01%. Это наименьший квартальный показатель с начала 2022 года.
Доля компьютеров АСУ, на которых были обнаружены вредоносные документы, после снижения в конце 2024 года растет третий квартал подряд. В третьем квартале 2025 года показатель составил 1,98%.
Показатель вырос в четырех регионах - в Южной Америке, Восточной Азии, Юго-Восточной Азии и в Австралии и Новой Зеландии.
Наибольший рост отмечен в Южной Америке - в связи с масштабной фишинговой кампанией, в ходе которой использовались новые эксплойты для CVE-2017-11882 в Microsoft Office Equation Editor для доставки на компьютеры жертв различного шпионского ПО.
Примечательно, что в этой волне фишинга злоумышленники использовали локализованные письма на испанском языке, содержание которых похоже на деловую переписку.
Выросла и доля компьютеров АСУ, на которых были заблокированы вредоносные скрипты и фишинговые страницы, — в третьем квартале 2025 года показатель составил 6,79%.
В целом, третьем квартале 2025 года показатели всех источников угроз, включая интернет, почтовые клиенты и съемные носители, в среднем по миру уменьшились.
Доля компьютеров АСУ, на которых были заблокированы шпионские ПО и ransopmware, выросла и составила: 4,04% (рост 0,20 п.п.) и 0,17% (рост 0,03 п.п.) соответственно. А вот показатель майнеров уменьшился.
При этом доля компьютеров АСУ, на которых были заблокированы черви и вирусы, увеличилась до 1,26% (на 0,04 п. п.) и 1,40% (на 0,11 п. п.) соответственно, также незначительно увеличилась доля компьютеров АСУ с вредоносным ПО для AutoCAD - до 0,30% (на 0,01 п. п.).
Более подробная инфографика и цифры - в отчете.
В третьем квартале 2025 года доля компьютеров АСУ, на которых были заблокированы вредоносные объекты, по сравнению с предыдущим кварталом уменьшилась на 0,4 п.п. и составила 20,1%, а это минимальный показатель за исследуемый период.
В регионах доля компьютеров АСУ, на которых в третьем квартале 2025 года были заблокированы вредоносные объекты, варьируется от 9,2% в Северной Европе до 27,4% в Африке.
Показатель за квартал увеличился в пяти регионах, больше всего - в Восточной Азии, где был отмечен резкий рост доли компьютеров АСУ, связанный с локальным распространением вредоносных скриптов в OT-инфраструктуре организаций в сфере инжиниринга и интеграции АСУ.
Рейтинг исследуемых отраслей и типов ОT-инфраструктур по доле компьютеров АСУ, на которых были заблокированы вредоносные объекты, традиционно возглавили биометрические системы.
В четырех из семи исследуемых отраслей доля компьютеров АСУ, на которых были заблокированы вредоносные объекты, в третьем квартале 2025 года увеличилась.
Больше всего показатель вырос в следующих отраслях инжиниринга и интеграторов АСУ, а также в производстве.
В третьем квартале 2025 года защитные решения Лаборатории Касперского позволили заблокировать в системах промышленной автоматизации вредоносное ПО из 11 356 семейств, относящихся к различным категориям.
В третьем квартале 2025 года доля компьютеров АСУ, на которых были заблокированы ресурсы в интернете из списка запрещенных, уменьшилась до 4,01%. Это наименьший квартальный показатель с начала 2022 года.
Доля компьютеров АСУ, на которых были обнаружены вредоносные документы, после снижения в конце 2024 года растет третий квартал подряд. В третьем квартале 2025 года показатель составил 1,98%.
Показатель вырос в четырех регионах - в Южной Америке, Восточной Азии, Юго-Восточной Азии и в Австралии и Новой Зеландии.
Наибольший рост отмечен в Южной Америке - в связи с масштабной фишинговой кампанией, в ходе которой использовались новые эксплойты для CVE-2017-11882 в Microsoft Office Equation Editor для доставки на компьютеры жертв различного шпионского ПО.
Примечательно, что в этой волне фишинга злоумышленники использовали локализованные письма на испанском языке, содержание которых похоже на деловую переписку.
Выросла и доля компьютеров АСУ, на которых были заблокированы вредоносные скрипты и фишинговые страницы, — в третьем квартале 2025 года показатель составил 6,79%.
В целом, третьем квартале 2025 года показатели всех источников угроз, включая интернет, почтовые клиенты и съемные носители, в среднем по миру уменьшились.
Доля компьютеров АСУ, на которых были заблокированы шпионские ПО и ransopmware, выросла и составила: 4,04% (рост 0,20 п.п.) и 0,17% (рост 0,03 п.п.) соответственно. А вот показатель майнеров уменьшился.
При этом доля компьютеров АСУ, на которых были заблокированы черви и вирусы, увеличилась до 1,26% (на 0,04 п. п.) и 1,40% (на 0,11 п. п.) соответственно, также незначительно увеличилась доля компьютеров АСУ с вредоносным ПО для AutoCAD - до 0,30% (на 0,01 п. п.).
Более подробная инфографика и цифры - в отчете.
Securelist
Ландшафт угроз для систем промышленной автоматизации. Третий квартал 2025 года
Отчет содержит статистику по угрозам, обнаруженным и заблокированным на компьютерах АСУ в третьем квартале 2025 года, в том числе по майнерам, шифровальщикам, шпионскому ПО и т. д.
Хьюстон! У NASA проблема.
В киберподполье c 22 декабря реализуется дамп данных, предположительно, полученный с официального сервера Национального управления по аэронавтике и исследованию космического пространства (NASA).
Согласно заявлениям селлера, утечка связана с совместными проектами NASA и испанской службой телерадиологии, включает: исходники, данные PACS, модули системы управления, внутреннюю документацию и прочие конфиденциальные данные.
В киберподполье c 22 декабря реализуется дамп данных, предположительно, полученный с официального сервера Национального управления по аэронавтике и исследованию космического пространства (NASA).
Согласно заявлениям селлера, утечка связана с совместными проектами NASA и испанской службой телерадиологии, включает: исходники, данные PACS, модули системы управления, внутреннюю документацию и прочие конфиденциальные данные.
Последние обновления по Trust Wallet.
Компания официально подтвердила, что в результате взлома обновления для расширения Chrome, выпущенного 24 декабря, было украдено 7 миллионов долларов.
Похищенные средства будут компенсированы.
Тем временем, расследование продолжается, еще не ясно, как хакерам удалось выпустить новую вредоносную версию.
Будем следить.
Компания официально подтвердила, что в результате взлома обновления для расширения Chrome, выпущенного 24 декабря, было украдено 7 миллионов долларов.
Похищенные средства будут компенсированы.
Тем временем, расследование продолжается, еще не ясно, как хакерам удалось выпустить новую вредоносную версию.
Будем следить.
X (formerly Twitter)
CZ 🔶 BNB (@cz_binance) on X
So far, $7m affected by this hack. @TrustWallet will cover. User funds are SAFU. Appreciate your understanding for any inconveniences caused. 🙏
The team is still investigating how hackers were able to submit a new version.
The team is still investigating how hackers were able to submit a new version.
This media is not supported in your browser
VIEW IN TELEGRAM
И вообще, хорош работать, пятница же!
Под конец года подкатили не очень утешительные новости: cерьезная уязвимость MongoDB под названием MongoBleed (CVE-2025-14847) активно эксплуатируется и затрагивает более 80 000 потенциально уязвимых серверов в открытом доступе в сети Интернет.
Доступен PoC и все сопутствующие технические подробности, как можно прикрутить уязвимость для удаленного извлечения секретов, учетных данных и других конфиденциальных данных с незащищенного сервера MongoDB.
MongoBleed связана с тем, как сервер MongoDB обрабатывает сетевые пакеты, используемые библиотекой zlib для сжатия данных без потерь.
Исследователи из Ox Security объясняют, что проблема вызвана тем, что MongoDB возвращает объем выделенной памяти при обработке сетевых сообщений вместо длины распакованных данных.
Злоумышленник может отправить некорректно сформированное сообщение, заявив о большем размере после декомпрессии, что заставит сервер выделить больший буфер памяти и передать клиенту данные из оперативной памяти, содержащие конфиденциальную информацию.
Утечка секретов таким образом может включать в себя учетные данные, ключи API и/или облачных сервисов, токены сессий, персональные данные, внутренние журналы, конфигурации, пути и данные, связанные с клиентами.
Поскольку декомпрессия сетевых сообщений происходит до этапа аутентификации, злоумышленнику, использующему MongoBleed, не требуются действительные учетные данные.
При этом выпущенный исследователями Elastic общедоступный PoC специально создан для кражи конфиденциальных данных из памяти.
В свою очередь, Кевин Бомонт утверждает, что PoC является эффективным и требует лишь IP-адреса экземпляра MongoDB, чтобы начать извлекать из памяти такие данные, как пароли к базам данных (которые представляют собой открытый текст), секретные ключи AWS и т.д.
Согласно телеметрии Censys, по состоянию на 27 декабря в открытом доступе в Интернете находилось более 87 000 потенциально уязвимых экземпляров MongoDB.
Наибольшее число - в США, где выявлено 20 000 серверов MongoDB, за ними Китай с 17 000 и Германия с 8 000.
В России - почти 2000.
Влияние на всю облачную среду оценивается как значительное.
В, частности, как отмечают в Wiz, 42% видимых систем имеют как минимум один экземпляр MongoDB в версии, уязвимой для CVE-2025-14847.
При этом ими уже фиксируется активная эксплуатация MongoBleed в реальных условиях.
Предполагается, что злоумышленники умело препарировали MongoBleed в рамках недавнего взлома онлайн-платформы Range Six Siege от Ubisoft.
MongoDB устранила MongoBleed десять дней назад, настоятельно рекомендовав администраторам обновиться до безопасной версии (8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 или 4.4.30).
Но Recon InfoSec предупреждает, что установка патчей - это лишь часть решения проблемы MongoBleed, советуя организациям также проверять наличие признаков компрометации.
Исследователи, что радует, уже разработали MongoBleed Detector, инструмент, который анализирует журналы MongoDB и выявляет потенциальные возможности эксплуатации уязвимости CVE-2025-14847.
В основу лег метод обнаружения от исследователя Капуано который был имплементирован Флорианом Ротом в полноценную утилиту.
Обходного пути для этой уязвимости нет.
Если переход на новую версию невозможен, поставщик рекомендует клиентам отключить сжатие zlib на сервере и предоставляет инструкции по этому поводу.
К безопасным альтернативам для сжатия данных без потерь относятся Zstandard (zstd) и Snappy (ранее Zippy).
Доступен PoC и все сопутствующие технические подробности, как можно прикрутить уязвимость для удаленного извлечения секретов, учетных данных и других конфиденциальных данных с незащищенного сервера MongoDB.
MongoBleed связана с тем, как сервер MongoDB обрабатывает сетевые пакеты, используемые библиотекой zlib для сжатия данных без потерь.
Исследователи из Ox Security объясняют, что проблема вызвана тем, что MongoDB возвращает объем выделенной памяти при обработке сетевых сообщений вместо длины распакованных данных.
Злоумышленник может отправить некорректно сформированное сообщение, заявив о большем размере после декомпрессии, что заставит сервер выделить больший буфер памяти и передать клиенту данные из оперативной памяти, содержащие конфиденциальную информацию.
Утечка секретов таким образом может включать в себя учетные данные, ключи API и/или облачных сервисов, токены сессий, персональные данные, внутренние журналы, конфигурации, пути и данные, связанные с клиентами.
Поскольку декомпрессия сетевых сообщений происходит до этапа аутентификации, злоумышленнику, использующему MongoBleed, не требуются действительные учетные данные.
При этом выпущенный исследователями Elastic общедоступный PoC специально создан для кражи конфиденциальных данных из памяти.
В свою очередь, Кевин Бомонт утверждает, что PoC является эффективным и требует лишь IP-адреса экземпляра MongoDB, чтобы начать извлекать из памяти такие данные, как пароли к базам данных (которые представляют собой открытый текст), секретные ключи AWS и т.д.
Согласно телеметрии Censys, по состоянию на 27 декабря в открытом доступе в Интернете находилось более 87 000 потенциально уязвимых экземпляров MongoDB.
Наибольшее число - в США, где выявлено 20 000 серверов MongoDB, за ними Китай с 17 000 и Германия с 8 000.
В России - почти 2000.
Влияние на всю облачную среду оценивается как значительное.
В, частности, как отмечают в Wiz, 42% видимых систем имеют как минимум один экземпляр MongoDB в версии, уязвимой для CVE-2025-14847.
При этом ими уже фиксируется активная эксплуатация MongoBleed в реальных условиях.
Предполагается, что злоумышленники умело препарировали MongoBleed в рамках недавнего взлома онлайн-платформы Range Six Siege от Ubisoft.
MongoDB устранила MongoBleed десять дней назад, настоятельно рекомендовав администраторам обновиться до безопасной версии (8.2.3, 8.0.17, 7.0.28, 6.0.27, 5.0.32 или 4.4.30).
Но Recon InfoSec предупреждает, что установка патчей - это лишь часть решения проблемы MongoBleed, советуя организациям также проверять наличие признаков компрометации.
Исследователи, что радует, уже разработали MongoBleed Detector, инструмент, который анализирует журналы MongoDB и выявляет потенциальные возможности эксплуатации уязвимости CVE-2025-14847.
В основу лег метод обнаружения от исследователя Капуано который был имплементирован Флорианом Ротом в полноценную утилиту.
Обходного пути для этой уязвимости нет.
Если переход на новую версию невозможен, поставщик рекомендует клиентам отключить сжатие zlib на сервере и предоставляет инструкции по этому поводу.
К безопасным альтернативам для сжатия данных без потерь относятся Zstandard (zstd) и Snappy (ранее Zippy).
OX Security
MongoDB Unauthenticated Attacker Sensitive Memory Leak - OX Security
This post by OX Research team was published on Dec 24, 2025 Attackers Could Exploit Zlib To Exfiltrate Data. CVE-2025-14847 Attackers Could Exploit Zlib To Exfiltrate Data TL;DR Critical MongoDB Memory Leak The Situation: A major vulnerability allows unauthenticated…
Forwarded from Russian OSINT
This media is not supported in your browser
VIEW IN TELEGRAM
Весьма неприятный инцидент произошел с компанией Ubisoft, которая известна по линейке игры Tom Clancy’s Rainbow Six Siege. Дело в том, что, согласно многочисленным сообщениям игроков и скриншотам, опубликованным в сети, хакеры каким-то образом получили возможность:
Похоже, R6 пришёл полный конец. Просто нереально, насколько всё плохо.🥷 Хакеры сделали следующее:↘️ Забанили и разбанили тысячи людей.↘️ Захватили ленту уведомлений о банах и могут писать туда что угодно.↘️ Выдали каждому по 2 миллиарда кредитов и очков славы.↘️ Открыли каждому все скины, включая скины разработчиков.
— жалуется пользователь KingGeorge, чей пост набрал 1.7 млн просмотров (28.12).
В результате атаки игроки по всему миру неожиданно обнаружили на своих аккаунтах гигантские суммы внутриигровой валюты, а также редкие предметы.
Кредиты в игре R6 — это премиальная внутриигровая валюта, продаваемая за реальные деньги в магазине Ubisoft.
Исходя из официальных расценок (15 000 кредитов за 99,99 доллара США), стоимость 2 миллиардов кредитов, бесплатно розданных каждому игроку, эквивалентна примерно $13,33 млн.
В субботу официальный аккаунт Rainbow Six Siege в социальной сети X (ранее Twitter) подтвердил факт инцидента, заявив, что Ubisoft осведомлена о "проблеме", затрагивающей игру, и специалисты уже работают над её устранением.
Вскоре после этого Ubisoft отключила серверы Rainbow Six Siege и внутриигровую торговую площадку, сообщив о продолжении работ по устранению уязвимости.
Ubisoft уточнила, что к игрокам не будут применяться штрафные санкции за использование начисленных кредитов, однако компания проведет откат всех транзакций. Иными словами, игрокам не грозит бан за то, что они потратили “подаренные” хакерами средства. Официальных комментариев о возможной утечке персональных данных или компрометации внутренних систем Ubisoft также не последовало.
По одной из версий, злоумышленники могли получить доступ к серверам Ubisoft через недавно обнаруженную уязвимость в MongoDB, которая получила название «MongoBleed» — CVE-2025-14847.
Please open Telegram to view this post
VIEW IN TELEGRAM
В киберподполье засветились новые новогодние подарки: предположительно, взломана база данных Condé Nast и слита база данных WIRED с более 2,3 млн. записей, ожидается слив еще до 40 млн. записей в отношении других ресурсов Condé Nast.
20 декабря некто Lovely вывалил в даркнет базу данных, предложив доступ к ней за 2,30 доллара и обвинив Condé Nast в игнорировании сообщений об уязвимостях. Якобы почти месяц хакер пытался убедить администраторов устранить уязвимости на своих сайтах.
Но, терпение закончилось (или не договорились), так что пришлось переходить к методу кнута.
Lovely также поделился другими украденными данными по изданиям Condé Nast, включая, судя по аббревиатурам, The New Yorker, Epicurious, SELF, Vogue, Allure, Vanity Fair, Glamour, Men's Journal, Architectural Digest, Golf Digest, Teen Vogue, Style.com и Condé Nast Traveler.
Condé Nast пока не подтвердила факт взлома, но анализ утечки указывает на то, что ряд записей принадлежат подлинным подписчикам WIRED.
Набор данных содержит 2 366 576 записей и 2 366 574 уникальных адреса электронной почты с временными метками от 26 апреля 1996 года до 9 сентября 2025 года.
Каждая запись содержит уникальный внутренний идентификатор подписчика, адрес электронной почты и другие регданные, такие как имя и фамилия, номер телефона, физический адрес, пол и дата рождения.
В записях также содержатся отметки времени создания и обновления учетной записи, информация о последней сессии, а также поля, специфичные для WIRED, такие как отображаемое имя пользователя и даты создания и обновления учетной записи.
Приблизительно 284 196 записей (12,01%) содержат как имя, так и фамилию, 194 361 запись (8,21%) содержит физический адрес, 67 223 записи (2,84%) содержат дату рождения, и 32 438 записей (1,37%) содержат номер телефона.
Значительно меньшая часть включает более полные профили, содержащие 1529 записей (0,06%), в которых указаны полное имя, дата рождения, номер телефона, адрес и пол.
Исследователи Hudson Rock также подтвердили подлинность записей пользователей wired.com, используя журналы вредоносного ПО, содержащие ранее скомпрометированные учетные данные.
Примечательно, что до утечки Lovely позиционировал себя исследователем и даже обращался к Dissent Doe из DataBreaches.net за помощью в ответственном раскрытии уязвимостей изданию Condé Nast.
Согласно данным DataBreaches, в конце ноября этот человек действительно обратился к ним за помощью в установлении контакта со службой безопасности Condé Nast по поводу уязвимостей, которые, предположительно, позволяли злоумышленникам просматривать и изменять информацию об учетных записях пользователей.
Первоначально Lovely заявил, что скачал лишь небольшое количество записей, чтобы предоставить доказательства изданию Condé Nast, включая записи, которые, как подтверждено, принадлежат DataBreaches.net и сотруднику WIRED.
Однако, не получив ответа от Condé Nast, Lovely позже сообщил Dissent Doe, что скачал всю базу данных и угрожал ее опубликовать.
В DataBreaches расценили это как игру и пришли к выводу, что злоумышленник действовал, намереваясь слить украденные данные вместо того, чтобы ответственно раскрыть информацию.
В Condé Nast пока отмалчиваются и не дают комментариев. По всей видимости, подарки им не зашли.
20 декабря некто Lovely вывалил в даркнет базу данных, предложив доступ к ней за 2,30 доллара и обвинив Condé Nast в игнорировании сообщений об уязвимостях. Якобы почти месяц хакер пытался убедить администраторов устранить уязвимости на своих сайтах.
Но, терпение закончилось (или не договорились), так что пришлось переходить к методу кнута.
Lovely также поделился другими украденными данными по изданиям Condé Nast, включая, судя по аббревиатурам, The New Yorker, Epicurious, SELF, Vogue, Allure, Vanity Fair, Glamour, Men's Journal, Architectural Digest, Golf Digest, Teen Vogue, Style.com и Condé Nast Traveler.
Condé Nast пока не подтвердила факт взлома, но анализ утечки указывает на то, что ряд записей принадлежат подлинным подписчикам WIRED.
Набор данных содержит 2 366 576 записей и 2 366 574 уникальных адреса электронной почты с временными метками от 26 апреля 1996 года до 9 сентября 2025 года.
Каждая запись содержит уникальный внутренний идентификатор подписчика, адрес электронной почты и другие регданные, такие как имя и фамилия, номер телефона, физический адрес, пол и дата рождения.
В записях также содержатся отметки времени создания и обновления учетной записи, информация о последней сессии, а также поля, специфичные для WIRED, такие как отображаемое имя пользователя и даты создания и обновления учетной записи.
Приблизительно 284 196 записей (12,01%) содержат как имя, так и фамилию, 194 361 запись (8,21%) содержит физический адрес, 67 223 записи (2,84%) содержат дату рождения, и 32 438 записей (1,37%) содержат номер телефона.
Значительно меньшая часть включает более полные профили, содержащие 1529 записей (0,06%), в которых указаны полное имя, дата рождения, номер телефона, адрес и пол.
Исследователи Hudson Rock также подтвердили подлинность записей пользователей wired.com, используя журналы вредоносного ПО, содержащие ранее скомпрометированные учетные данные.
Примечательно, что до утечки Lovely позиционировал себя исследователем и даже обращался к Dissent Doe из DataBreaches.net за помощью в ответственном раскрытии уязвимостей изданию Condé Nast.
Согласно данным DataBreaches, в конце ноября этот человек действительно обратился к ним за помощью в установлении контакта со службой безопасности Condé Nast по поводу уязвимостей, которые, предположительно, позволяли злоумышленникам просматривать и изменять информацию об учетных записях пользователей.
Первоначально Lovely заявил, что скачал лишь небольшое количество записей, чтобы предоставить доказательства изданию Condé Nast, включая записи, которые, как подтверждено, принадлежат DataBreaches.net и сотруднику WIRED.
Однако, не получив ответа от Condé Nast, Lovely позже сообщил Dissent Doe, что скачал всю базу данных и угрожал ее опубликовать.
В DataBreaches расценили это как игру и пришли к выводу, что злоумышленник действовал, намереваясь слить украденные данные вместо того, чтобы ответственно раскрыть информацию.
В Condé Nast пока отмалчиваются и не дают комментариев. По всей видимости, подарки им не зашли.
InfoStealers
WIRED Database Leaked: 40 Million Record Threat Looms for Condé Nast
WIRED Database Leaked: 40 Million Record Threat Looms for Condé NastA comprehensive investigation into the current WIRED database leak and the threat of an imminent, much larger compromise targeting the Condé Nast portfolio.
Forwarded from Social Engineering
• Есть старое правило: если можно сделать быстро и удобно, кто‑то обязательно сделает это в ущерб безопасности. В инфраструктурных командах это особенно заметно. Сетевики часто решают задачи «с лёту», и это прекрасно. Пока речь не заходит про пароли. Один из таких случаев стал для автора данного материала хорошим уроком...
• В этой статье описана ситуация, когда сотрудники сопровождения передавали пароль по SSH. В открытом виде.
• Почему это проблема:
/proc/[PID]/cmdline, Task Manager.• В итоге получить пароль можно даже не трогая сам SSH, что может привести к утечке. Подробности по ссылке ниже:
• P.S. Рекомендую обратить внимание на комментарии, там можно найти полезные советы и рекомендации.
S.E. ▪️ infosec.work ▪️ VT
Please open Telegram to view this post
VIEW IN TELEGRAM
Исследователи из Лаборатории Касперского сообщают о кампании шпионажа с использованием уязвимостей высокого уровня, в ходе которой китайская APT отключала DNS-запросы для доставки бэкдора MgBot жертвам в Турции, Китае и Индии.
Активность фиксировалась в период с ноября 2022 по ноябрь 2024 и была связана с Evasive Panda (Bronze Highland, Daggerfly и StormBamboo).
Группа активна с 2012 года и в основном реализует AitM-атаки в отношении конкретных жертв, полагаясь на размещение загрузчиков в определенных местах и хранение зашифрованных частей вредоносного ПО на серверах, которые расшифровывались в ответ на DNS-запросы с конкретных сайтов.
В атаках, замеченных ЛК, использовались приманки под обновления стороннего ПО, включая SohuVA, сервис потокового видео от китайской Sohu, которые распространялись с «p2p.hd.sohu.com[.]cn», что указывает на DNS poisoning.
Исследователям также удалось выявить другие кампании, в которых Evasive Panda задействовала фейковые обновления для iQIYI Video от Baidu, а также IObit Smart Defrag и Tencent QQ.
Атака открывает путь для развертывания начального загрузчика, запускающего шеллкод, который, в свою очередь, загружает зашифрованный шеллкод второго этапа в виде файла изображения PNG, опять же посредством DNS poisoning с легитимного веб-сайта dictionary[.]com.
Evasive Panda манипулировала IP-адресом, связанным с dictionary[.]com, в результате чего системы жертв перенаправляли трафик на сайт по IP-адресу, контролируемому злоумышленником, на основе их местоположения и провайдера.
В настоящее время неизвестно, каким образом злоумышленник злоупотребляет DNS-ответами.
Предполагаются два сценария: либо провайдеры, используемые жертвами, были выборочно скомпрометированы для установки какого-либо сетевого имплантата на периферийные устройства, либо маршрутизатор или межсетевой экран, используемые жертвами, были взломаны с этой целью.
HTTP-запрос для получения шеллкода второго этапа также содержит текущий номер версии Windows для более четкого нацеливания и адаптирования стратегии в зависимости от ОС.
Стоит отметить, что Evasive Panda ранее использовала атаки типа watering hole для распространения вредоносного ПО для Apple macOS под названием MACMA.
Точная природа вредоносного ПО второго этапа неясна, но анализ ЛК показывает, что шеллкод первого этапа расшифровывает и запускает полученную полезную нагрузку.
Предполагается, что злоумышленники генерируют уникальный зашифрованный второй файл шеллкода для каждой жертвы.
Ключевым аспектом операций является использование вторичного загрузчика (libpython2.4.dll), который использует переименованную, более старую версию python.exe, загружаемую из сторонних источников.
После запуска он загружает и расшифровывает вредоносное ПО следующего этапа, считывая содержимое файла с именем C:\ProgramData\Microsoft\eHome\perf.dat. Он содержит расшифрованную полезную нагрузку, загруженную на предыдущем шаге.
По всей видимости, злоумышленник использовал сложный процесс для получения этого этапа из ресурса, где он изначально был зашифрован с помощью XOR-шифрования.
Затем злоумышленник расшифровал этот этап с помощью XOR-шифрования, а впоследствии зашифровал и сохранил его в файл perf.dat, используя собственную гибридную архитектуру интерфейса программирования приложений для защиты данных (DPAPI) от Microsoft и RC5.
Использование собственного алгоритма шифрования - это попытка усложнить анализ, гарантирующая, что зашифрованные данные могут быть расшифрованы только в той системе, где шифрование было изначально выполнено.
Расшифрованный код представляет собой вариант MgBot, внедряемый вторичным загрузчиком в svchost.exe.
Модульный имплант MgBot способен собирать файлы, данные из буфера и браузеров, логировать нажатия клавиш, записывать аудио.
Как отмечает ЛК, Evasive Panda в очередной раз показала передовые возможности, обходя меры безопасности с помощью новых методов и инструментов, сохраняя при этом длительное присутствие в целевых системах.
Активность фиксировалась в период с ноября 2022 по ноябрь 2024 и была связана с Evasive Panda (Bronze Highland, Daggerfly и StormBamboo).
Группа активна с 2012 года и в основном реализует AitM-атаки в отношении конкретных жертв, полагаясь на размещение загрузчиков в определенных местах и хранение зашифрованных частей вредоносного ПО на серверах, которые расшифровывались в ответ на DNS-запросы с конкретных сайтов.
В атаках, замеченных ЛК, использовались приманки под обновления стороннего ПО, включая SohuVA, сервис потокового видео от китайской Sohu, которые распространялись с «p2p.hd.sohu.com[.]cn», что указывает на DNS poisoning.
Исследователям также удалось выявить другие кампании, в которых Evasive Panda задействовала фейковые обновления для iQIYI Video от Baidu, а также IObit Smart Defrag и Tencent QQ.
Атака открывает путь для развертывания начального загрузчика, запускающего шеллкод, который, в свою очередь, загружает зашифрованный шеллкод второго этапа в виде файла изображения PNG, опять же посредством DNS poisoning с легитимного веб-сайта dictionary[.]com.
Evasive Panda манипулировала IP-адресом, связанным с dictionary[.]com, в результате чего системы жертв перенаправляли трафик на сайт по IP-адресу, контролируемому злоумышленником, на основе их местоположения и провайдера.
В настоящее время неизвестно, каким образом злоумышленник злоупотребляет DNS-ответами.
Предполагаются два сценария: либо провайдеры, используемые жертвами, были выборочно скомпрометированы для установки какого-либо сетевого имплантата на периферийные устройства, либо маршрутизатор или межсетевой экран, используемые жертвами, были взломаны с этой целью.
HTTP-запрос для получения шеллкода второго этапа также содержит текущий номер версии Windows для более четкого нацеливания и адаптирования стратегии в зависимости от ОС.
Стоит отметить, что Evasive Panda ранее использовала атаки типа watering hole для распространения вредоносного ПО для Apple macOS под названием MACMA.
Точная природа вредоносного ПО второго этапа неясна, но анализ ЛК показывает, что шеллкод первого этапа расшифровывает и запускает полученную полезную нагрузку.
Предполагается, что злоумышленники генерируют уникальный зашифрованный второй файл шеллкода для каждой жертвы.
Ключевым аспектом операций является использование вторичного загрузчика (libpython2.4.dll), который использует переименованную, более старую версию python.exe, загружаемую из сторонних источников.
После запуска он загружает и расшифровывает вредоносное ПО следующего этапа, считывая содержимое файла с именем C:\ProgramData\Microsoft\eHome\perf.dat. Он содержит расшифрованную полезную нагрузку, загруженную на предыдущем шаге.
По всей видимости, злоумышленник использовал сложный процесс для получения этого этапа из ресурса, где он изначально был зашифрован с помощью XOR-шифрования.
Затем злоумышленник расшифровал этот этап с помощью XOR-шифрования, а впоследствии зашифровал и сохранил его в файл perf.dat, используя собственную гибридную архитектуру интерфейса программирования приложений для защиты данных (DPAPI) от Microsoft и RC5.
Использование собственного алгоритма шифрования - это попытка усложнить анализ, гарантирующая, что зашифрованные данные могут быть расшифрованы только в той системе, где шифрование было изначально выполнено.
Расшифрованный код представляет собой вариант MgBot, внедряемый вторичным загрузчиком в svchost.exe.
Модульный имплант MgBot способен собирать файлы, данные из буфера и браузеров, логировать нажатия клавиш, записывать аудио.
Как отмечает ЛК, Evasive Panda в очередной раз показала передовые возможности, обходя меры безопасности с помощью новых методов и инструментов, сохраняя при этом длительное присутствие в целевых системах.
Securelist
Evasive Panda APT campaign overview
Kaspersky GReAT experts analyze the Evasive Panda APT's infection chain, including shellcode encrypted with DPAPI and RC5, as well as the MgBot implant.
Последние обновления по инциденту с расширением Trust Wallet для браузера: хакеры похитили около 7 млн. долл. с почти 3000 адресов криптовалютных кошельков.
Напомним, инцидент 24 декабря привел к краже активов из скомпрометированных кошельков после того, как была взломана версия 2.68.0 расширения Chrome, в которую злоумышленники добавили вредоносный JavaScript-файл.
Trust Wallet подтвердила факт взлома и посоветовала пользователям немедленно обновить систему до версии 2.69, чтобы заблокировать дальнейшие попытки кражи криптовалюты.
Рабочая гипотеза (все еще находится на стадии расследования): хакер использовал утекший ключ API Chrome Web Store для отправки вредоносного расширения версии 2.68.
Оно успешно прошло проверку Chrome Web Store и было выпущено 24 декабря 2025 года в 12:32 UTC.
В ответ на инцидент Trust Wallet приостановила поддержку всех API для выпуска новых версий, чтобы заблокировать любые попытки выпуска новых версий в течение следующих двух недель.
Кроме того, компания предотвратила кражу дополнительных данных хакерами, сообщив о вредоносном домене, используемом для утечки данных, регистратору NiceNIC, который незамедлительно заблокировал его.
Однако злоумышленники пошли еще дальше, запустив фишинговую кампанию, в ходе которой, пользуясь возникшей паникой и фейковым сайтом брендом Trust Wallet, запрашивали у пользователей фразу восстановления для получения «важного планового обновления с улучшениями безопасности».
С тех пор Trust Wallet сообщила, что злоумышленники украли криптовалюту из 2596 кошельков идентифицированных жертв, и заявила о планах возместить убытки всем пострадавшим пользователям. При этом компанией было получено более 5000 обращений о взломе.
Для инициирования процесса получения компенсации пострадавшим пользователям следует заполнить эту форму: https://be-support.trustwallet.com, с указанием: контактных данных, адресов опустошенных кошельков, хэши транзакций.
Trust Wallet также предупреждает, что в настоящее время злоумышленники выдают себя за службу поддержки, реализуя мошеннические схемы через рекламу в Telegram и распространяют фейковые формы для получения компенсации.
Напомним, инцидент 24 декабря привел к краже активов из скомпрометированных кошельков после того, как была взломана версия 2.68.0 расширения Chrome, в которую злоумышленники добавили вредоносный JavaScript-файл.
Trust Wallet подтвердила факт взлома и посоветовала пользователям немедленно обновить систему до версии 2.69, чтобы заблокировать дальнейшие попытки кражи криптовалюты.
Рабочая гипотеза (все еще находится на стадии расследования): хакер использовал утекший ключ API Chrome Web Store для отправки вредоносного расширения версии 2.68.
Оно успешно прошло проверку Chrome Web Store и было выпущено 24 декабря 2025 года в 12:32 UTC.
В ответ на инцидент Trust Wallet приостановила поддержку всех API для выпуска новых версий, чтобы заблокировать любые попытки выпуска новых версий в течение следующих двух недель.
Кроме того, компания предотвратила кражу дополнительных данных хакерами, сообщив о вредоносном домене, используемом для утечки данных, регистратору NiceNIC, который незамедлительно заблокировал его.
Однако злоумышленники пошли еще дальше, запустив фишинговую кампанию, в ходе которой, пользуясь возникшей паникой и фейковым сайтом брендом Trust Wallet, запрашивали у пользователей фразу восстановления для получения «важного планового обновления с улучшениями безопасности».
С тех пор Trust Wallet сообщила, что злоумышленники украли криптовалюту из 2596 кошельков идентифицированных жертв, и заявила о планах возместить убытки всем пострадавшим пользователям. При этом компанией было получено более 5000 обращений о взломе.
Для инициирования процесса получения компенсации пострадавшим пользователям следует заполнить эту форму: https://be-support.trustwallet.com, с указанием: контактных данных, адресов опустошенных кошельков, хэши транзакций.
Trust Wallet также предупреждает, что в настоящее время злоумышленники выдают себя за службу поддержки, реализуя мошеннические схемы через рекламу в Telegram и распространяют фейковые формы для получения компенсации.
X (formerly Twitter)
Eowync.eth (@EowynChen) on X
What we know:
The malicious extension v2.68 was NOT released through our internal manual process. Our current findings suggest it was most likely published externally through Chrome Web Store API key, bypassing our standard release checks.
A working hypothesis…
The malicious extension v2.68 was NOT released through our internal manual process. Our current findings suggest it was most likely published externally through Chrome Web Store API key, bypassing our standard release checks.
A working hypothesis…