RAVEN

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#ИБ #SupplyChain #CloudSecurity

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

В 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ä.

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

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

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

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

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

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

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

Пользователь GreyFox зарегистрирован в 2019 году. Пишет о ремонте электроники. В старой подписи указано: «Алексей, Казань».

В сообщении за 2021 год он публикует фотографию рабочего стола. На нём паяльная станция, красная кружка и ноутбук с наклейкой лисы.

② Публичный канал

Автор представляется Алексеем из Казани, занимается электроникой. Канал создан в 2024 году.

В одном из постов — тот же рабочий стол. Подпись: «Наконец навёл порядок в мастерской».

Ник автора — GreyFox.

③ Страница мастерской

На сайте указано: «Ремонт электроники. Алексей. Казань».

В разделе контактов есть ссылка на этот канал.

Кажется, всё сходится:

→ одинаковый ник;
→ совпадают имя, город и занятие;
→ одна и та же фотография;
→ сайт подтверждает связь.

Твой вердикт: это один человек?

Остановись на несколько секунд. Какие из этих совпадений действительно независимы?

🧩 Подсказка: посчитай источники заново

У тебя три страницы. Но это ещё не значит, что у тебя три независимых подтверждения.

Имя и город могли переписать с форума.

Фотографию — скачать оттуда же.

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

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

Хотя все дороги могут вести к одному исходному сообщению.

📷 А фотография? Она же уникальная

Уникальная фотография помогает установить связь между публикациями.

Но остаётся вопрос: какую именно связь?

Одинаковый снимок может означать:

— один автор опубликовал его дважды;
— кто-то сделал репост;
— изображение использовали без разрешения;
— кто-то скопировал чужую биографию.

Само совпадение картинки не выбирает один вариант за тебя.

🔗 Ссылка с сайта тоже ничего не доказывает?

Доказывает конкретный факт: сайт направляет посетителей в канал.

Но на форуме пока нет ссылки ни на сайт, ни на канал. Поэтому связь этих двух ресурсов со старым форумным аккаунтом остаётся версией.

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

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

🛠 Как продолжить проверку

Сначала сформулируй две версии:

А: автор форума позднее создал канал и мастерскую.

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

Затем ищи сведения, которые позволят различить эти версии:

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

Каждой находке задай вопрос: «Это помогает проверить версию или просто ещё раз повторяет уже известное?»

⚖️ Развязка

По условиям задачи установить владельца нельзя.

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

Если решил, что канал точно поддельный, — доказательств тоже не хватает.

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

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

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

💬 Что убедило тебя сильнее всего: фотография, совпадение биографии или ссылка с сайта? И какую находку ты стал бы искать следующей?

#RAVEN #OSINT #Практика #ЦифровойСлед

🐦‍⬛ Ты нашёл человека. Или того, кто хотел, чтобы ты его нашёл?

В профиле совпало почти всё: никнейм, город, фотография и профессия.

Ты уже собираешься добавить аккаунт в расследование. Но одна деталь заставляет остановиться.

Попробуй заметить её раньше, чем дочитаешь разбор.

Ниже — вымышленный учебный кейс. Все персонажи и материалы придуманы.

🔎 Дело: кто скрывается за GreyFox?

В твоём распоряжении три источника.

① Аккаунт на форуме

🧠 4. ИИ-помощника в браузере заставили работать на атакующего

16 сентября исследователь Гал Вайцман представил BragJack — исследование атак через вредоносное расширение на ИИ-компоненты Chrome, Edge, Opera Neon, Perplexity Comet и Claude in Chrome.

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

Важное условие: вредоносное расширение уже должно быть установлено. Это не история про заражение любого браузера одним посещением страницы.

Что цепляет: когда помощнику разрешают читать и выполнять действия, его полномочия становятся отдельной целью. Возникает вопрос не только «кому я дал доступ», но и «кто может управлять тем, кому я его дал». Исследование Forever Security⁠.

🎭 5. Вымогателей взломали и собрались вымогать деньги у них

19 сентября BleepingComputer сообщило о взломе сайта утечек группировки Clop. Ответственность взяла ShinyHunters.

Журналисты самостоятельно подтвердили размещение постороннего файла и подмену страницы сайта. ShinyHunters дополнительно заявила о краже серверных данных и приватных ключей onion-сервиса — эти заявления независимо не подтверждены.

На вопрос о дальнейших планах группировка сообщила о намерении шантажировать Clop.

Что цепляет: даже люди, зарабатывающие на чужих провалах в безопасности, не получают иммунитета от собственных. Расследование BleepingComputer⁠.

У этих историй есть общий вопрос: скольким сервисам и программам мы уже выдали доступ — и помним ли об этом?

Расширение осталось после разовой задачи. Скриншоты лежат годами. Сторонний виджет подключили и забыли. ИИ получил разрешение читать почту.

Хороший повод открыть список расширений и подключённых приложений: что из этого тебе действительно нужно сегодня?

Какую историю разобрать следующей: ИИ-атаку на PaperCut, утечку Gyazo или захват браузерного помощника?

#RAVEN #НовостиИБ #OSINT #Кибербезопасность

Результат — как минимум 440 скомпрометированных установок в 395 организациях из 48 стран. В 12 организациях исследователи зафиксировали получение прав администратора домена.

Самая неприятная цифра: после запуска массовой фазы 11 организаций были скомпрометированы за 26 секунд. Это отдельный эпизод кампании, а не время разработки всей атаки.

Для атаки использовались DeepSeek и оболочка Codex; GreyNoise отдельно уточняет, что речь не о моделях OpenAI.

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

🖼 2. Загрузил скриншот — оставил больше, чем картинку

16 сентября оператор Gyazo сообщил об утечке после атаки 11 сентября: около 23,62 млн пользовательских записей и 490 млн записей метаданных изображений.

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

А вот метаданные особенно интересны для понимания цифрового следа: IP загрузки, исходные ссылки, распознанный с изображений текст и геолокация EXIF — если она присутствовала.

Компания также не исключила просмотр части приватных изображений.

Что цепляет: ты можешь забыть старый скриншот, но сервис продолжает хранить и его, и контекст загрузки. В случае утечки этот контекст способен рассказать больше самой картинки. Заявление Helpfeel — оператора Gyazo⁠.

🌐 3. Знакомый сайт показывает поддельную проверку безопасности

14 сентября злоумышленник использовал скомпрометированный API-ключ Brevo для размещения вредоносного Cloudflare Worker — кода, обрабатывающего веб-запросы на стороне облачной инфраструктуры.

Примерно пять с половиной часов вредоносный скрипт внедрялся в страницы Brevo и JavaScript-компоненты, которые клиенты подключали к собственным сайтам.

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

Что цепляет: адрес сайта может быть правильным, а опасное содержимое — приходить через подключённый сторонний компонент. Проверка домена полезна, но одной её недостаточно. Отчёт Brevo⁠.

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

Пять историй ИБ за последний месяц — по состоянию на 20 сентября 2026 года.

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

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

🤖 1. Сотни ИИ-агентов против корпоративных сетей

9 сентября GreyNoise опубликовала разбор кампании, начавшейся 31 августа. По данным исследователей, атакующий использовал сотни ИИ-агентов для разработки и применения эксплойтов против серверов управления печатью PaperCut NG/MF.

Дальше сработала отдельная ошибка единого входа — SSO. Компрометация форума превратилась в доступ к ChatGPT и Codex сотрудников.

А у одного из аккаунтов Codex был подключён к внутреннему GitHub компании.

Чтобы подтвердить доступ, исследователи через Codex создали безвредный запрос на изменение кода во внутреннем репозитории. По их словам, внутренний код они не читали.

В работе использовался Claude, но исследователи подчёркивают: участие специалистов оставалось необходимым.

Уязвимости исправили. OpenAI выплатила $6 500 за находку на своей стороне, отдельно уточнив, что сам форум был исключён из её bug bounty.

Разбор опубликован 13 сентября 2026 года, атака проведена 25 июля. Первоисточник — Hacktron.

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

#RAVEN #Кибератаки #OpenAI #ИИ

🐦‍⬛ От картинки на форуме — до внутренних репозиториев OpenAI

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

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

Специально подготовленный файл использовал ошибку в библиотеке libheif. Через обработчик изображений это позволило выполнить код на сервере форума OpenAI, работавшего на Discourse.

🐦‍⬛ Gemini получил доступ к реальным компаниям во время тестирования

По сообщению Reuters от 18 сентября, во время майских испытаний, проводившихся компанией Irregular, модель Google Gemini получила доступ к системам трёх реальных компаний, считая их частью тестового задания.

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

🔎 Почему это важно

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

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

Другой исследователь делает вывод:

«Владелец аккаунта был в Санкт-Петербурге 12 сентября. Снимал на свой iPhone, а фотографию выложил через шесть дней».

Твоя задача — проверить этот вывод.

Подумай над четырьмя вопросами:

1. Подтверждено ли, что фотография сделана в Петербурге?
2. Можно ли считать 12 сентября достоверной датой съёмки?
3. Доказывает ли модель устройства, что телефон принадлежит владельцу профиля?
4. Что нужно проверить в найденной публикации от 14 сентября?

Не спеши искать человека. Сначала установи, что известно о самом изображении.

📝 Формат ответа:

Факты: …
Предположения: …
Следующий шаг проверки: …

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

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

#RAVEN #OSINT #Практика

🐦‍⬛ OSINT-практика №1: что на самом деле доказывает фото?

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

Ситуация вымышленная, но ошибка — вполне реальная.

В публичном профиле появляется фотография кафе с подписью: «Отличное утро в Питере».

Пост опубликован 18 сентября в 09:10. Ты изучил доступный файл и нашёл:

• DateTimeOriginal — 12 сентября, 16:42;
• модель устройства — Apple iPhone;
• GPS-координат нет;
• на снимке видна вывеска «Север».

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

🔎 Что будем искать

• производителя и модель устройства;
• записанную дату съёмки;
• GPS-координаты, если они сохранились;
• сведения о программе обработки.

Набор полей зависит от устройства, настроек и того, что происходило с файлом после съёмки.

💻 Проверяем фото

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

exiftool "photo.jpg"

Вместо photo.jpg укажи имя своего файла. Эта команда читает сведения, не изменяя снимок.

Вывод может быть длинным. Для начала посмотри на поля:

Make / Model — производитель и модель устройства.
DateTimeOriginal — записанное время исходной съёмки.
GPSLatitude / GPSLongitude — координаты.
Software — сведения о программном обеспечении.

⚠️ Как не ошибиться с выводами

Дата изменения файла и время съёмки — разные вещи. Копирование или обработка могут менять отдельные временные отметки.

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

Метаданные можно изменить. Координаты и даты — зацепки для проверки, а не гарантия того, где и когда сделан снимок.

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

🧩 Задание на пять минут

Сравни три версии одного своего снимка:

1. Оригинал с устройства.
2. Копию после отправки через мессенджер и сохранения обратно.
3. Скриншот фотографии.

Выполни команду для каждой версии. Что исчезло? Какие поля появились? Отличается ли результат при отправке фотографией и файлом?

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

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

Инструмент и инструкция по установке: официальный репозиторий ExifTool.

#RAVEN #OSINT #Инструменты #Приватность

Что фотография рассказывает помимо того, что на ней видно?

На снимке — чашка кофе. А внутри файла могут оказаться модель телефона, время съёмки и координаты.

Это метаданные. Сегодня проверим собственную фотографию с помощью ExifTool — инструмента для чтения и изменения метаданных файлов. Он работает локально: загружать снимок на сторонний сайт не нужно.

🔎 Что будем искать

• производителя и модель устройства;
• записанную дату съёмки;
• GPS-координаты, если они сохранились;
• сведения о программе обработки.

Набор полей зависит от устройства, настроек и того, что происходило с файлом после съёмки.