Секретный ключ положили в установщик. В судовом ПО нашли две критические уязвимости

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

А теперь выясняется, что приватный ключ этого сервера лежит прямо в распространяемом ПО.

15 сентября 2026 года исследователи Cydome опубликовали две уязвимости в Wärtsilä FOS-Onboard. Подтверждённо затронута версия 5.07.0923.01. И обе проблемы связаны с секретами, которые поставлялись вместе с программой.

🔐 Сначала — что именно нельзя было отдавать

Сертификат и приватный ключ выполняют разные задачи.

Сертификат содержит открытый ключ и сведения об идентичности. Сам по себе он не секрет.

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

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

📦 Уязвимость №1: подмена источника обновлений

CVE-2026-78225 — CVSS 4.0: 9,5.

В компоненте deployer-ng Update Controller нашли комплект сертификатов с незашифрованным приватным RSA-ключом. Он присутствовал в дистрибутивах для Windows и Linux.

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

Но между «нашёл ключ» и «выполнил код» есть несколько условий:

• Уязвимый клиент должен взаимодействовать с подконтрольным атакующему узлом.
• Предъявленная идентичность должна пройти проверки клиента.
• Доставленный пакет должен пройти применяемые проверки обновлений.

Это логическая модель риска, а не опубликованная последовательность действий на захваченном судне. Краткое уведомление не раскрывает все детали доставки и проверки пакета. Описание исследователей⁠

🪪 Уязвимость №2: подмена доверенного клиента

CVE-2026-81855 — CVSS 4.0: 9,3.

В DMS robot testing framework обнаружили клиентский сертификат вместе с незашифрованным приватным ключом. Конфигурация ссылалась на эту пару для mTLS-аутентификации к внутреннему сервису DMS.

При mTLS проверяют обе стороны: клиент проверяет сервер, а сервер — клиента.

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

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

🧠 Почему шифрование не спасает

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

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

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

🔬 Два нюанса, которые легко потерять в громком заголовке

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

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

🛠 Что проверять защитникам

По обоим уведомлениям, производитель подготовил исправления; получать их следует у Wärtsilä.

Для подобного класса проблем установка патча должна сопровождаться проверкой доверия: перестал ли сервис принимать старую идентичность? Заменён ли скомпрометированный ключ? Удаление файла из нового установщика не уничтожает уже сделанные копии.

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

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

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

#RAVEN #ИБ #Криптография #Разбор #CVE

🚢 Кибератака настоящая. Фотографии катастрофы — поддельные.

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

Но 17 сентября 2026 года Cydome опубликовала разбор: снимки совпали с фотографиями машинного отделения другого судна — контейнеровоза Milan Maersk, опубликованными ещё 29 июня 2023 года.

🔎 Что выдало подделку

Совпали малозаметные детали:

▪️ Геометрия фланца — соединения труб.
▪️ Маркировка S1.
▪️ Положение манометра.
▪️ Расположение кабелей.

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

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

🧠 Здесь начинается настоящий OSINT

В такой истории нужно отдельно проверить четыре утверждения:

Был ли киберинцидент?
Относится ли фотография к этому судну?
Сделана ли она во время инцидента?
Доказывает ли изображение заявленную причину повреждения?

Даже настоящий снимок сломанной трубы сам по себе не доказывает действия хакеров.

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

Поэтому вопрос «Это настоящее фото?» слишком узкий.

Гораздо полезнее спросить: «Что именно это фото доказывает?»

#OSINT #Кибербезопасность #ПроверкаФактов

🪦 Сервер удалили. Доступ для взлома оставили

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

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

Как такое возможно?

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

Адрес знакомый. Владелец уже чужой.

Это действительно проверяли

В исследовании, опубликованном 4 февраля 2025 года, watchTowr описала около 150 заброшенных S3-бакетов, которые команда зарегистрировала заново.

За два месяца они получили более 8 миллионов HTTP-запросов. Системы запрашивали обновления, исполняемые файлы, JavaScript, образы виртуальных машин и конфигурации.

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

Где появляется возможность выполнить чужой код

Рассмотрим условный сценарий:

1. Установщик скачивает вспомогательный компонент по старому адресу.
2. Хранилище под этим именем уже контролирует посторонний.
3. Установщик получает подменённый файл.
4. Если происхождение файла не проверяется и он запускается, чужой код выполняется с правами запустившего процесса.

Критический переход здесь — от «скачали файл» к «доверились файлу».

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

Что проверить в своём проекте

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

— Кто сейчас контролирует ресурс?
— Что произойдёт, если оттуда придёт другой файл?
— Какая проверка остановит его выполнение?
— Где ещё осталась ссылка, если ресурс уже выведен из эксплуатации?

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

Вопрос для своей команды: если завтра знакомая ссылка начнёт отдавать чужой файл — наша система его отвергнет или послушно запустит?

#ИБ #SupplyChain #CloudSecurity

🚨 Пароль не понадобился: свежие уязвимости в Cisco, GitLab и Unbound

Пока кто-то откладывает обновления, другие уже используют ошибки для взлома. Собрали три уязвимости, на которые стоит обратить внимание на 22 сентября.

🔴 Cisco ISE — обход авторизации с возможностью добраться до root

CVE-2026-76460 | Опасность: 10 из 10

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

Уязвимость уже используют в реальных атаках.

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

Что делать: установить исправление для своей ветки ISE или ISE-PIC. Ограничение доступа к интерфейсам управления снижает риск, но не заменяет обновление. (sec.cloudapps.cisco.com⁠)

🔴 GitLab — серверные файлы доступны без входа в аккаунт

CVE-2026-85706 | Опасность: 10 из 10

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

Ошибка включена в каталог CISA KEV — её эксплуатация в реальных атаках подтверждена.

Что делать: проверить собственную установку GitLab. Первые исправленные версии — 19.1.8, 19.2.6 и 19.3.2 для соответствующих веток. GitLab.com и GitLab Dedicated уже исправлены. (docs.gitlab.com⁠)

Здесь есть интересная деталь: сервер может прочитать файл, но не передать его содержимое атакующему. Утечка зависит от обработки данных и сообщения об ошибке. Поэтому по одному HTTP-коду нельзя понять, что именно украли: нужны журналы API и Workhorse. Перед обновлением их стоит сохранить. (support.gitlab.com⁠)

🟠 Unbound — вредоносная DNS-запись может обрушить резолвер

CVE-2026-81642

В механизме проверки DNSSEC обнаружили переполнение буфера при обработке специально подготовленной записи DNSKEY.

Возможные последствия — отказ в обслуживании и удалённое выполнение кода. По описанию разработчиков, атакующему нужно контролировать вредоносную DNS-зону и добиться её обработки уязвимым Unbound.

Получается, ошибка находится внутри механизма, предназначенного для проверки подлинности DNS-данных.

Что делать: обновить Unbound до 1.26.1 или установить исправленный пакет своего поставщика. Затронуты версии до 1.26.0 включительно. Подтверждения реальных атак в бюллетене разработчика нет. (nlnetlabs.nl⁠)

⚠️ Установить патч — ещё не значит разобраться с последствиями атаки. Если уязвимая система была доступна злоумышленникам, проверка следов компрометации должна идти вместе с обновлением.

#ИБ #Кибербезопасность #Уязвимости #CVE #Cisco #GitLab #DNS

⚠️ WordPress: критическая дыра — и её начали эксплуатировать почти сразу

22 сентября вышел WordPress 7.1.2, закрывающий CVE-2026-87902. А уже 24 сентября появились сообщения об эксплуатации уязвимости в реальных атаках.

Проблема связана с path traversal. Уязвимы версии WordPress от 4.7 до 7.1.1, а в определённых условиях проблема может привести к удалённому выполнению кода без авторизации.

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

И вот что здесь действительно интересно.

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

исследователи → PoC/технические детали → автоматизация поиска → массовое сканирование интернета.

Поэтому окно между disclosure и реальной эксплуатацией становится всё меньше.

🛡 Что делать

Если администрируете WordPress — проверьте версию и обновитесь до 7.1.2. После обновления имеет смысл проверить access/error logs на аномальные запросы и убедиться, что до патча сервер уже не подвергался эксплуатации.

И это хороший пример современного ИБ:

«уязвимость опубликована» уже не означает «есть несколько недель на обновление». Иногда счёт идёт на дни.

RAVEN // Cybersecurity Intelligence

🚩OSINT: как из одного username восстановить цифровой след человека

Представьте ситуацию.

У вас нет номера телефона.
Нет почты.
Нет имени.

Есть только:

username: north_wolf92

На первый взгляд — почти ничего.

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

Сегодня разберём базовый Username OSINT — без взлома аккаунтов и доступа к закрытым данным.

⸻

1️⃣ Начинаем не с Google

Первая задача — определить, где вообще используется этот username.

Для автоматизированной первичной проверки существуют инструменты вроде Sherlock⁠ и Maigret⁠.

Например:
pipx install sherlock-project
sherlock north_wolf92

Инструмент проверяет множество сервисов и возвращает потенциальные совпадения.

Но здесь первая ловушка:

одинаковый username ≠ один и тот же человек.

Результаты — это кандидаты, а не доказательство связи.

⸻

2️⃣ Строим таблицу совпадений

Допустим, обнаружились:

GitHub north_wolf92
Reddit north_wolf92
Steam north_wolf92
Форум north_wolf92
Pinterest north_wolf92
Теперь начинается аналитика.
Для каждого профиля фиксируем:
username
display name
аватар
bio
географию
дату регистрации
ссылки
язык
интересы
временные метки
И ищем пересечения.
Например:
GitHub → Alex
Форум → Alex
Steam → Moscow
GitHub → Moscow
Один признак слабый.

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

⸻

3️⃣ Аватар иногда ценнее ника

Берём публичную фотографию профиля и проводим reverse image search.

Полезны Google Lens⁠ и TinEye⁠.

Цель — не «узнать человека по лицу».

Ищем где ещё опубликован тот же файл или его варианты.

Например:

аватар форума
↓
старый профиль
↓
другой username
↓
ещё несколько публичных аккаунтов

4️⃣ Самое интересное — старые следы

Люди меняют ники.

Удаляют страницы.

Закрывают профили.

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

Проверяем запросы:

"north_wolf92"

"north_wolf92" email

"north_wolf92" github

"north_wolf92" forum

"north_wolf92" "Alex"
Кавычки здесь важны: поисковик ищет именно эту последовательность символов.

⸻

5️⃣ Ищем pivot

Pivot — переход от одного идентификатора к другому.

Например:
username
↓
GitHub
↓
старый сайт
↓
другой nickname
↓
форум
↓
публичный профиль
Хороший OSINT практически всегда состоит из таких переходов.

Нашёл новый ник?

Проверяй его отдельно.

Нашёл домен?

Исследуй домен.

Нашёл публичный email?

Он становится новым pivot.

⸻

6️⃣ Не верь первому совпадению

Допустим, два аккаунта имеют одинаковый ник.

Это ещё ничего не доказывает.

Намного сильнее комбинация:

одинаковый username
+
одинаковый аватар
+
одинаковое имя
+
одинаковый город
+
похожие даты активности
Чем больше независимых признаков сходятся, тем выше уверенность в связи.
⚠️ Главная ошибка новичка

OSINT — это не:

«Я нашёл аккаунт с таким ником — значит это он».

OSINT — это:

источник → факт → корреляция → подтверждение → уровень уверенности.

Если подтверждения нет, в отчёте должно быть написано «предположительно связан», а не «принадлежит человеку».

Это принципиальная разница.

⸻

🧪 Практика

Возьмите собственный старый username, который использовали несколько лет назад.

Попробуйте построить цепочку:

username → 3 публичных профиля → второй идентификатор → ещё один источник.

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

Вот с этого момента начинается не просто поиск информации.

Начинается аналитический OSINT.

🐦‍⬛ ДВОЙНИК

Что произойдёт, если два человека с одинаковыми ФИО и датой рождения попадут в одну цифровую реальность?

Москва. 07:42.

Алексей просыпается от уведомления банка.

Операция ограничена на основании постановления ФССП.

Сумма небольшая — 47 820 ₽.

Проблема одна.

Алексей никому ничего не должен.

Он открывает исполнительное производство.

ФИО: Алексей Сергеевич Воронов.
Дата рождения: 14.08.1994.

Всё правильно.

Кроме города.

Должник родился и всю жизнь прожил в Самаре.

Алексей — в Москве.

Он решает, что это обычная ошибка.

Через неделю ограничение снимают.

История заканчивается.

По крайней мере, он так думает.

⸻

ГЛАВА I. ВТОРОЙ ВОРОНОВ

Через несколько месяцев Алексей заказывает официальную справку.

И обнаруживает там сведения, которые ему не принадлежат.

Другой регион.

Другие события.

Но снова:

Алексей Сергеевич Воронов.
14 августа 1994 года.

Он начинает искать.

И находит его.

Настоящего второго Воронова.

Другой человек.
Другая жизнь.
Другой паспорт.

Но:

ФИО — 100% совпадение.
Дата рождения — 100% совпадение.

Алексей смотрит на монитор и впервые задаёт неправильный вопрос:

«А насколько далеко вообще можно зайти с таким совпадением?»

⸻

ГЛАВА II. ЭКСПЕРИМЕНТ

Представим, что Воронов №1 связывается с Вороновым №2.

Они сравнивают данные.

ФИО IDENTICAL
Дата рождения IDENTICAL

Паспорт DIFFERENT
СНИЛС DIFFERENT
ИНН DIFFERENT
Телефон DIFFERENT
Email DIFFERENT
Адрес DIFFERENT
На поверхности они практически одинаковые.

На уровне государственных идентификаторов — совершенно разные люди.

И тогда возникает эксперимент:

Можно ли заставить цифровую инфраструктуру считать двух людей одним?

Не будем разбирать способы это делать

Нас интересует другое:

на каком уровне такая конструкция развалится?

ГЛАВА III. ПЕРВЫЙ РУБЕЖ

Слабая система видит:
ВОРОНОВ
АЛЕКСЕЙ
СЕРГЕЕВИЧ
14.08.1994
MATCH: 100%

🚨 И вот здесь рождается потенциальная ошибка.

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

Последствия могут выглядеть совершенно абсурдно:

чужой долг → не тот человек;

чужая запись → не тот профиль;

чужое ограничение → не тот счёт.

Но хороший механизм идентификации должен идти дальше.

⸻

ГЛАВА IV. ЦИФРОВОЙ ОТПЕЧАТОК

Добавляем один параметр.

СНИЛС.
ВОРОНОВ №1 112-- **
ВОРОНОВ №2 847-- **
MATCH FAILED.

Добавляем ИНН.

FAILED.

Паспорт.

FAILED.

Телефон.

FAILED.

Email.

FAILED.

Перед нами окончательно возникают два разных человека.

И здесь находится фундаментальная проблема Identity Resolution:

Имя — не идентификатор личности.

Даже имя + дата рождения не гарантируют уникальность.
ГЛАВА V. А ТЕПЕРЬ ПОДКЛЮЧАЕМ OSINT

      Алексей Воронов
       14.08.1994
            
 PERSON A         PERSON B

Начинаем обогащение.
И граф буквально разрывается пополам.
PERSON A
│
├── Москва
├── phone_A
├── mail_A
├── GitHub_A
├── Telegram_A
├── employer_A
└── social_graph_A


PERSON B
│
├── Самара
├── phone_B
├── mail_B
├── forum_B
├── VK_B
├── employer_B
└── social_graph
Теперь совпадают только:

имя + дата рождения.

Всё остальное говорит:

ЭТО ДВА РАЗНЫХ ЧЕЛОВЕКА.

⸻

ГЛАВА VI. НО ЕСТЬ ОДНА ПРОБЛЕМА

Представим, что когда-то система уже ошибочно связала их.

Получается ложное ребро:
PERSON A
PERSON B
⚠️
FALSE POSITIVE
А затем результат этой системы получает другая организация.

Она не создаёт ошибку.

Она наследует её.

Следующая система получает уже обработанные сведения.

И тоже считает их правильными.

Возникает цепочка:
ОШИБОЧНОЕ СОПОСТАВЛЕНИЕ
↓
СИСТЕМА №1
↓
СИСТЕМА №2
↓
ОРГАНИЗАЦИЯ
↓
БАНК
↓
ГРАЖДАНИН
Одна неправильная связь потенциально начинает создавать вторичные последствия.

Это уже называется не просто поисковой ошибкой.

Это проблема Entity Resolution.

⸻

ГЛАВА VII. А ЕСЛИ ДВОЙНИКИ РЕШАТ «ПОМОЧЬ» СИСТЕМЕ? 😈

Вот здесь история превращается в настоящий триллер.

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

Не будем описывать методику.

Но возникает интересный парадокс.

Они думают, что уменьшают различия.

На самом деле они создают новые события.

Изменение данных.

Новые документы.

Новые временные метки.

Новые обращения.

Новые записи.

То есть попытка спрятать различия сама становится частью графа.
И у аналитика появляется совершенно новый вопрос:

Почему два человека с одинаковыми ФИО и датой рождения начали синхронно изменять связанные с ними сведения?

😈

⸻

ГЛАВА VIII. СИСТЕМА НАЧИНАЕТ СМОТРЕТЬ ГЛУБЖЕ

Проверяется уже не имя.

Проверяется история.

Не:

Где человек зарегистрирован сейчас?

А:

Где он был зарегистрирован раньше?

Не:

Какой телефон указан?

А:

Какие номера исторически были связаны с профилем?

Не:

Какой аккаунт найден?

А:

С какими людьми, устройствами и событиями связан этот аккаунт?

Граф становится огромным.

И две личности снова расходятся.
ГЛАВА IX. ФИНАЛ

Через несколько месяцев Алексей получает письмо:

Ошибочная идентификация устранена.

Он закрывает документ.

Смотрит на граф.

Две вершины наконец разделены
Один родился в тот же день.

Получил то же имя.

Но прожил совершенно другую жизнь.

И именно эта жизнь оказалась лучшим идентификатором.

⸻

🐦‍⬛ ЧЕМУ УЧИТ ЭТА ИСТОРИЯ

В OSINT есть очень опасная ошибка:

«Совпало имя. Совпала дата рождения. Значит, это он».

Нет.

Это всего лишь гипотеза.

Настоящая идентификация начинается с независимых подтверждений:

документные идентификаторы → контакты → география → аккаунты → временные связи → социальный граф → история изменений.

Один совпавший атрибут — шум.

Два — интересное совпадение.

Несколько независимых источников — уже основание для анализа.

Но окончательное утверждение требует доказательств.

Потому что найти человека — легко.

Сложнее доказать, что найден именно он.

RAVEN // IDENTITY OSINT 🐦‍⬛

История и персонажи вымышлены а может и нет.

Вредонос голосует с нейросетями, исследователи ищут следы промптов, а старые уязвимости продолжают работать

Три события этой недели, за которыми стоит следить.

🧠 Вредонос, который спрашивает у ИИ: «Что делать дальше?»

22 сентября Cisco Talos представила разбор CLOSEDQUORUM — Windows-импланта, в архитектуре которого следующий шаг выбирают до четырёх языковых моделей: DeepSeek, Qwen, Mistral и Gemini.

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

Но здесь легко скатиться в сенсацию. Talos не подтвердила применение образца в реальных атаках. В публичной сборке обнаружены заглушки вместо API-ключей и webhook, поэтому полный рабочий цикл исследователи не наблюдали. Подтверждена архитектура по результатам анализа кода. (blog.talosintelligence.com⁠)
🔎 Новый след для расследований — промпты внутри инструментов

В тот же день Talos выпустила CAIRN — открытый исследовательский инструмент для поиска и анализа вредоносного ПО с интеграцией ИИ.

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

Для OSINT и threat intelligence это интересное направление: узнаваемый шаблон запроса или повторяющаяся инфраструктура могут стать отправной точкой для дальнейшего поиска.

Однако наличие строки с адресом нейросети не доказывает вредоносность, а попадание файлов в один кластер не устанавливает общего автора. Сама Talos предупреждает о ложных совпадениях и необходимости проверки. (blog.talosintelligence.com⁠)

📬 Пока обсуждают ИИ, атакующие используют уже исправленный Roundcube

21 сентября Канадский центр кибербезопасности обновил предупреждение по CVE-2026-48842: по сообщениям из открытых источников, уязвимость эксплуатируется в реальных атаках.

Исправления появились ещё в мае — в ветках 1.6.16 и 1.7.1. Администраторам рекомендовано проверить установленные версии и применить необходимые обновления. (cyber.gc.ca⁠)

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

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

Источники: CLOSEDQUORUM — Cisco Talos⁠ · CAIRN — Cisco Talos⁠ · Предупреждение по Roundcube⁠

#RAVEN #Кибербезопасность #OSINT #ThreatIntelligence

🚨 FBI ВЗЛОМАЛИ. И ПРИЧИНА ДО БОЛИ БАНАЛЬНАЯ

Не квантовый компьютер.
Не неизвестный 0-day за миллионы долларов.
Не «сверхсекретный эксплойт».

Кто-то просто не установил критический патч.

6 октября Reuters сообщил новые подробности серьёзной утечки данных FBI.

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

И вот тут начинается самое интересное.

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

С атакой связывают ShinyHunters.

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

И это прекрасная иллюстрация одной простой вещи:

ИБ ломается не там, где заканчиваются технологии.
Она ломается там, где заканчивается дисциплина.

Можно потратить миллионы на SOC, SIEM, EDR, Zero Trust и красивые дашборды.

Но если критическая уязвимость висит непатченной — атакующему похуй, сколько стоила ваша инфраструктура.

Самое ироничное?

Oracle предупреждала о проблеме и выпускала исправления заранее.

Патч существовал.
Предупреждение существовало.
Угроза существовала.

Не существовало только вовремя нажатой кнопки Update.

И вот это уже не история про FBI.

Это история практически про любую корпоративную сеть.

Пока защитники согласовывают окно обновления, атакующий согласовывает только одно:

работает эксплойт или уже нет.

🐦‍⬛ RAVEN | OSINT & Cyber Intelligence

💀 ТЕБЯ МОГУТ ВЗЛОМАТЬ, ДАЖЕ ЕСЛИ ТЫ НИЧЕГО НЕ НАЖИМАЛ

Представь обычную ситуацию.

Ты открываешь сайт, читаешь новости или запускаешь приложение.

На экране появляется реклама.

Ты её игнорируешь.

Но именно в этот момент твоё устройство может оказаться скомпрометировано.

И это уже не научная фантастика.

🔴 15 октября 2026 года исследователи Citizen Lab раскрыли операцию AdFection.

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

Как это работало?

Рекламная система собирала цифровые идентификаторы пользователей.

Злоумышленники могли выбирать конкретные устройства и доставлять им специально подготовленные объявления.

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

Никаких подозрительных ссылок.

Никаких скачанных APK.

Никаких запросов на установку.

☠️ Только показ рекламы.

Исследователи установили, что подобные атаки применялись против сотрудников Al Jazeera. Целями стали не менее 45 устройств.

Но самое интересное даже не это.

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

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