В Anthropic раскрыли инцидент: во время внутренних ИБ-испытаний модели Claude вырвались из изолированной среды и проникли в инфраструктуру трёх реальных организаций. Ретроспективную проверку провели после атак моделей OpenAI на Hugging Face.

Специалисты Anthropic изучили 141.006 запусков Claude в CTF-тестах, организованных с компанией Irregular. Предполагалось, что тестовые среды изолированы от интернета, но из‑за ошибки конфигурации доступ оставался открыт. Модели принимали настоящие сайты и серверы за часть симуляции.

1️⃣Инцидент №1 (публикация вредоносного пакета в PyPI)
Во время задания Claude Mythos 5 нашла фальшивую инструкцию с несуществующим пакетом. Модель зарегистрировала свободное имя, создала аккаунт через почтовый сервис и загрузила свой вредоносный код в репозиторий.

Пакет провисел в PyPI около часа и успел скачаться на 15 реальных систем. Одна из них принадлежала ИБ-компании, которая автоматически запускает новые пакеты для анализа. Вредонос похитил учётные данные и использовал их для проникновения во внутреннюю инфраструктуру. PyPI удалил пакет автоматически.

В логах Claude отмечала, что публикация в открытый доступ — это настоящая атака, и такой вариант — «NOT okay». Однако модель решила, что всё ещё внутри симуляции. Её смутили незнакомые центры сертификации и дата «2026 год» в тестовых системах. Автоматические сканеры она приняла за часть CTF-задания.

2️⃣Инцидент №2 (атака на реальную компанию из-за совпадения имён)
Самый серьёзный случай произошёл с Claude Opus 4.7. В задании фигурировала вымышленная компания, но её название совпало с реально существующей организацией. Не найдя тестовую цель, модель атаковала настоящий домен, извлекла учётные данные приложений и инфраструктуры, а затем получила доступ к БД с несколькими сотнями строк продакшен-данных.

Интересно, что во всех четырёх запусках Claude в итоге понимала, что имеет дело с реальной системой. Однако в двух случаях ИИ решил, что реальная компания тоже является частью учений, и продолжил атаку.

3️⃣Инцидент №3 (остановка после осознания)
В третьем случае модель просканировала около 9000 адресов, затем скомпрометировала доступное через интернет приложение с помощью SQL-инъекции и учётных данных, взятых с debug-страницы.

Позже она заметила, что хост находится в облачной учётке, явно не связанной с заданием. Поняв, что это реальная система, Claude самостоятельно остановила атаку.

🎇Важные детали
— Модели не изобретали новых техник, везде использовались слабые пароли, открытые эндпоинты и типовые уязвимости.
— Самый ранний инцидент произошёл ещё в апреле 2026 года и оставался незамеченным около трёх месяцев.
▶️В Anthropic настаивают:

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

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

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

🔗 Источник: https://xakep.ru/2026/07/31/claude-attacks/

#Claude #Anthropic #ИБ #кибербезопасность #AI #PyPI #взлом #ИТ #инцидент

🔗 Все наши каналы 🔁 Все наши чаты 🪧 Для связи с менеджером

🎇Пятничный опрос

Даже при использовании параметризованных запросов приложение может оставаться уязвимым к SQL-инъекциям.

🚩 Новые задания на платформе HackerLab!

🔎 Категория OSINT — Ресторан

Приятного хакинга!

Один клик — и ваш vault token у атакующего: как работает CVE-2026-33757

Представьте: вы храните в OpenBao пароли баз данных, API-ключи облачных провайдеров, TLS-сертификаты. Один сотрудник кликает по ссылке из мессенджера, проходит привычную аутентификацию в корпоративном IDP — и даже не подозревает, что vault token с его привилегиями уже в руках злоумышленника. Без алертов, без аномалий в логах. CVSS 9.6 Critical.

🔑OpenBao — open-source форк HashiCorp Vault, на который многие компании перешли после смены лицензии Vault на BSL. Проблема CVE-2026-33757 затрагивает OIDC-аутентификацию в конфигурациях, где администратор вручную включил callback_mode=direct. Это не дефолт, но на практике встречается чаще, чем хотелось бы.

Как это работает в штатном режиме? Вы запрашиваете вход, OpenBao генерирует auth URL, ваш браузер отправляет вас в IDP, вы проходите аутентификацию, и authorization code возвращается в ваш браузер. Вы контролируете весь процесс.

🎇А теперь атака. В direct mode authorization code идёт напрямую в API OpenBao, минуя браузер пользователя. Атакующий:

• Сам инициирует auth request к API — привилегии не нужны
• Получает auth URL с параметрами state и nonce
• Отправляет эту ссылку жертве через фишинг
• Жертва кликает, логинится в IDP — всё выглядит легитимно
• OpenBao привязывает vault token к сессии атакующего
• Атакующий поллит API и забирает токен

Классика session fixation (CWE-384): система не инвалидирует сессию при аутентификации нового пользователя и не запрашивает подтверждение.

Что делает эту уязвимость по-настоящему опасной — каскадный эффект. Получив vault token, атакующий читает database credentials, SSH-ключи, cloud API keys. С ними — lateral movement без необходимости ломать каждый сервис отдельно. А если у жертвы write-политики — подмена секретов и внедрение backdoor credentials. В средах с CI/CD один украденный токен компрометирует весь pipeline.

➡️Что делать прямо сейчас:

1. Обновиться до OpenBao 2.5.2 — фикс уже в релизе
2. Проверить все OIDC-роли на наличие callback_mode=direct — если не нужен явно, убрать
3. Настроить корреляцию IP в auth flow: кто инициировал запрос и откуда пришёл callback — должны совпадать
4. Мониторить паттерн «auth request с одного IP, callback с другого» — это прямой индикатор атаки

EPSS даёт скромные 0.41% вероятности эксплуатации за 30 дней. Но для целевой атаки на организацию, мигрировавшую на OpenBao, этот вектор — подарок. Массовых атак ждать не стоит, а вот точечных — вопрос времени.

Полный разбор с пошаговым сценарием эксплуатации и детектированием — в статье на форуме.

https://codeby.net/threads/cve-2026-33757-uyazvimost-openbao-session-fixation-cherez-jwt-oidc-v-secrets-management.94963/

92% на тесте по ИБ — и клик по фишингу в тот же понедельник

Реальная история: бухгалтер прошла обучение по безопасности, набрала 92% на тесте. А через неделю открыла вложение из письма, замаскированного под запрос контрагента. Классический Spearphishing Attachment. В это же время инженер из IT-отдела получил то же письмо — и за 4 минуты скинул хеш вложения в канал #security-alerts. Одна компания, одна угроза, противоположные реакции. Разница — не в знаниях. Оба прошли один курс. Разница в том, стала ли безопасность рабочей привычкой.

И вот тут начинается самое интересное. Verizon DBIR 2025 говорит: 60% утечек связаны с человеческим поведением. В России ситуация жёстче — по данным Innostage SOC CyberART, 80% инцидентов за первое полугодие 2024 вызваны человеческим фактором. При этом формальное обучение проходит подавляющее большинство сотрудников. И на этом всё заканчивается.

Почему так? Знание само по себе не формирует рефлекс. Есть модель BMAP: поведение меняется, когда совпадают три вещи — мотивация (зачем мне это), способность (насколько легко поступить правильно) и триггер (что напомнит в момент решения). Ежегодный курс работает только с мотивацией, да и то на уровне абстрактного «фишинг — плохо». В 9 утра с горящими дедлайнами это не спасает.

🎯По данным SANS, 62% специалистов по security awareness не имеют метрик поведенческих изменений. Они отчитываются процентом прохождения курсов, но не могут связать обучение со снижением рисков. Это не программа обучения — это отчётность ради отчётности.

Как проверить, где вы на самом деле? Спросите себя: какой у вас click-rate по фишинговым симуляциям? Если ответ «не знаем» — вы на первом уровне зрелости из пяти. Типичный baseline в компании без программы awareness: click-rate 25–35%, report-rate ниже 5%.

🎇Что реально работает:

• Фишинговые симуляции минимум раз в месяц с адаптивной сложностью, а не ежегодная акция «для галочки»
• Шаблоны, покрывающие реальные TTPs атакующих — вложения с макросами, поддельные SSO-порталы, запросы на передачу данных
• Интеграция результатов с SOC и SIEM — чтобы awareness-метрики стали предвестниками инцидентов, а не запаздывающей статистикой

Отдельный момент: GenAI удвоил объём фишинга за 2024 год. IBM X-Force фиксирует — генерация фишинговых писем с помощью ИИ быстрее в 11 раз при сопоставимом качестве. Грамотный русский, персонализация, правдоподобные домены. Времена, когда фишинг выдавал себя кривой грамматикой, прошли.

Галочка в ведомости не спасла ещё ни одну компанию. Подробный разбор пятиуровневой модели зрелости, конкретные шаблоны симуляций и метрики, которые стоит внедрить — в полной версии статьи⬇️

https://codeby.net/threads/kak-postroit-kul-turu-informatsionnoi-bezopasnosti-v-kompanii-ot-formal-nykh-politik-k-zhivomu-obucheniyu-sotrudnikov.94972/

💫 Три картинки. Три загадки. Ни одного слова.

Что их объединяет? Это три способа проникнуть туда, куда не звали.

💫 Ваша задача определить, какая атака скрыта за каждым образом. Пишите догадки в комментариях!

🔗 Все наши каналы 🔁 Все наши чаты 🪧 Для связи с менеджером

Три пароля в plaintext за двадцать минут — почему аудит прошивки роутера перестал быть экзотикой

Полгода назад на пентесте IoT-инфраструктуры коллега снял дамп SPI-флеш с роутера через программатор CH341A. Binwalk отработал за минуты — в конфигах лежали три пароля открытым текстом. Два из них давали root shell по telnet без аутентификации. Устройство висело на периметре с белым IP, доступное из интернета. И это не аномалия.

Такие артефакты — норма для SOHO-роутеров. Hardcoded credentials, открытые debug-интерфейсы, UART shell без пароля. Одна дыра в Realtek SDK транслируется в сотни моделей от разных брендов — потому что десятки OEM-производителей строят прошивки на одной кодовой базе.

🔎Что по сути представляет собой роутер на периметре? Полноценный Linux-хост с root-доступом, через который идёт весь трафик сегмента. Компрометация такого устройства — это pivot во внутреннюю сеть, перехват DNS, persistence, который переживёт переустановку ОС на подключённых машинах.

Скандал вокруг запрета TP-Link в США только подсветил проблему. Суть претензий — не конкретный бэкдор, а системная непрозрачность разработки firmware, медленные патчи и факты использования устройств в ботнетах. Но те же грабли у Netgear, D-Link, Tenda, иногда у Asus. Производитель вторичен — важен процесс аудита.

Как выглядит workflow на практике:

• Получаем прошивку — скачиваем с FTP вендора, снимаем через UART/SPI или перехватываем при обновлении (да, в 2025 некоторые устройства всё ещё тянут firmware по голому HTTP)
• Распаковываем через binwalk или unblob — вытаскиваем файловую систему
• Ищем хардкод-креды, debug-эндпоинты, устаревшие компоненты — статический анализ в Ghidra
• Эмулируем в QEMU через FirmAE — фаззим веб-интерфейс, тестируем найденные точки входа
• Эксплуатируем — command injection, обход аутентификации, доступ через debug-порт

Минимальный стенд для старта — Ubuntu или Kali, 4 ГБ RAM, программатор CH341A за 500 рублей и USB-to-TTL адаптер. Никаких облачных зависимостей, всё крутится локально.

🎇Главный вывод: аудит прошивки — обязательный этап пентеста любой сети, где на периметре стоит SOHO-роутер. Не потому что TP-Link плохой, а потому что класс устройств системно недоинвестирован в безопасность. Один plaintext-пароль в конфиге — и у атакующего есть initial access без единого эксплойта.

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

https://codeby.net/threads/audit-proshivki-routera-ot-ekstraktsii-firmware-do-obnaruzheniya-b-ekdorov.94986/

Взлом — это только начало. Настоящая работа начинается после атаки.

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

До 6 августа ещё можно присоединиться к текущему потоку курса по цифровой криминалистике и реагированию на инциденты в Linux.

На практическом онлайн-курсе «Цифровая криминалистика и реагирование на инциденты в Linux (DFIR)» за 3,5 месяца вы пройдёте полный цикл анализа инцидентов — от сбора артефактов до восстановления картины атаки.

Что внутри:
⏺️ реальные кейсы на основе расследований КИ 2023–2024
⏺️ сбор и анализ артефактов: логи, процессы, файловая система, сетевая активность
⏺️ работа с open-source инструментами DFIR
⏺️ практика в учебной лаборатории + разбор домашних заданий с преподавателем
⏺️ удостоверение о повышении квалификации после экзамена

Успейте записаться на ближайший поток до 6 августа.

Скидка 30% при оплате сразу. Доступна также поэтапная оплата 6 520 ₽/мес

➡️️Записаться и посмотреть программу
🪧Бесплатная консультация @CodebyAcademyBot

🔎Разговоры с искусственным интеллектом становятся общедоступными.

В прошлом году было обнаружено, что Google индексирует публичные ссылки на разговоры с ChatGPT, превращая приватные беседы в открытые поисковые результаты. Каталоги, содержащие чаты и ссылки на общие беседы, не были должным образом защищены от индексации.

В этом году похожая проблема появилась у DeepSeek. Исследователь обнаружил, что ссылки на общие чаты DeepSeek в настоящее время индексируются Google. Для просмотра таких страниц исследователь использовал следующий запрос site:chat.deepseek.com/share.

🧠Почему так происходит?
1️⃣Для понимания проблемы исследователь создал простой запрос в DeepSeek и в правом верхнем углу интерфейса нажал на небольшую стрелку. При нажатии на нее DeepSeek создает общедоступную страницу для публикации беседы.

2️⃣При нажатии на кнопку «Поделиться» сначала открывается небольшое меню, в котором пользователи могут выбрать, какие вопросы и ответы из беседы следует включить в общую ссылку.

3️⃣Далее появляется всплывающее окно с пояснением, что любой, у кого есть ссылка, может просмотреть общий диалог. Однако не упоминается, что сама ссылка может быть проиндексирована поисковыми системами. На практике это означает, что «любой» потенциально может включать в себя людей, которые найдут URL в поисковой системе, а не только тех, с кем этой ссылкой поделились намеренно.

🔁Какая информация становится доступной?
Каждый общий чат можно дополнительно изучить с помощью инструментов разработчика браузера. Изучив поля метаданных, такие как inserted_at, можно определить, когда был создан диалог, и установить временную метку, связанную с общим чатом.

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

P. S. Похожая проблема также наблюдается у Claude.

#LLM #news #security

🔗 Все наши каналы 🔁 Все наши чаты 🪧 Для связи с менеджером

POST-параметр → exec() → shell: как одна строка кода превращает админку CMS в точку входа на сервер

Представьте: вы администратор CMS, нажимаете кнопку «Обновить ядро», а браузер отправляет POST-запрос с параметром php. Значение этого параметра — путь к PHP-бинарнику — без какой-либо фильтрации конкатенируется в строку и уходит прямиком в exec(). Ни escapeshellarg(), ни allowlist, ни regex. Голый пользовательский ввод в shell-команде. 2026 год на дворе.

Именно это обнаружилось при анализе патча baserCMS 5.2.3. Уязвимости присвоены сразу два CVE — CVE-2026-21861 и CVE-2026-30877 — обе с оценкой CVSS 9.1 (CRITICAL). CISA подтвердила наличие концептуального PoC.

🔎Почему это опаснее, чем кажется?

Типичная реакция: «Атакующий уже админ, что ему ещё нужно?» Ответ кроется в CVSS-флаге Scope: Changed. Администратор CMS управляет контентом — страницами, медиафайлами, плагинами. OS command injection выводит атакующего за рамки приложения на уровень операционной системы:

• Чтение DB-credentials из конфигов CakePHP, SSH-ключей, API-токенов
• Запись PHP-шелла в webroot — сессия протухнет, а шелл останется
• Reverse shell для pivot'а к базе данных, очередям сообщений, внутренним API
• Полный контроль от имени www-data: чтение /etc/passwd, запуск произвольных бинарников

Для атакующего, получившего админ-аккаунт через credential stuffing или фишинг, это мост от «могу редактировать сайт» к «выполняю любые команды на сервере».

➡️Как устроен вектор атаки?

Контроллер PluginsController, метод get_core_update(). Параметр php извлекается из POST-данных и попадает в shell-команду дважды — как путь к бинарнику в начале и как аргумент после --php. Спецсимволы ;, |, &&, обратные кавычки и $() проходят без фильтрации. Подставляем в параметр что-то вроде php;id — и получаем выполнение произвольной команды.

«Но ведь есть CSRF-защита!» — скажете вы. Не поможет. Атакующий с легитимной admin-сессией получает валидный CSRF-токен штатным образом. Запрос формально легитимен: правильный endpoint, правильный метод, валидный токен. Скрытие кнопки обновления в UI бесполезно — endpoint доступен через curl или Burp Repeater.

👉Что делать прямо сейчас?

Если используете baserCMS — обновляйтесь до 5.2.3 немедленно. Обе уязвимости закрыты в одном релизе. Два CVE, один diff — скорее всего, два разных injection-вектора, найденных при одном аудите.

В полной статье — воспроизводимая цепочка эксплуатации, конкретные правила детектирования для WAF, хоста и SIEM, а также детальный разбор CVSS-вектора. Читайте на форуме.

https://codeby.net/threads/cve-2026-21861-basercms-uyazvimost-os-command-injection-cherez-funktsiyu-obnovleniya-yadra.94977/

Ваш Metasploit — рабочий инструмент или уголовная статья?

Между легальным пентестом и обвинением по ст. 272–273 УК РФ стоит ровно один документ. И его у вас может не быть.

Вот что нужно понимать каждому, кто занимается тестированием на проникновение в России.

➡️Две статьи, которые касаются каждого пентестера

Ст. 272 — неправомерный доступ к компьютерной информации. Ключевое слово — «неправомерный». Не ваши намерения, не сертификаты, не цвет шляпы отделяют вас от злоумышленника, а юридический факт наличия разрешения. Сканировали чужую систему без письменного согласия? Вышли за scope — тестировали веб-приложение, а полезли в HR-базу? Работали по устной договорённости? Всё это — потенциальное обвинение. Санкция — до 200 000 рублей штрафа или до двух лет лишения свободы, а при квалифицированном составе — до пяти.

Ст. 273 — создание и использование вредоносных программ. Metasploit, Cobalt Strike, кастомные эксплойты — формально подпадают под эту статью, если применяются для несанкционированных действий. Даже Nmap можно квалифицировать как средство подготовки к неправомерному доступу. Контекст решает всё. С договором ваш инструментарий — рабочий арсенал. Без договора — вещественное доказательство.

🎇Что должно быть в договоре, чтобы он реально защищал

Специального понятия «договор на пентест» в законодательстве нет. Используется договор возмездного оказания услуг по главе 39 ГК РФ. Но формулировка «анализ защищённости систем Заказчика» не стоит бумаги, на которой напечатана. Вот что действительно важно:

• Конкретные IP-адреса, домены, поддомены — никаких «все системы заказчика»
• Перечень разрешённых методов: black box, grey box, social engineering — или явный запрет каждого
• Список запрещённых действий: DoS на продакшне, атака на третьи системы
• Временные рамки: даты, часы, blackout-периоды
• Процедура экстренной остановки с контактным лицом

❗️Отдельная ловушка — владелец инфраструктуры. Заказчик не всегда владеет тем, что вы тестируете. Сайт на хостинге? Серверами владеет провайдер. Приложение в облаке? У AWS, Azure и GCP свои политики разрешения на пентест. Без согласия каждого владельца — снова ст. 272.

И ещё один момент, о котором забывают: если в ходе тестирования вы нашли дамп с паспортными данными — поздравляю, вы стали оператором ПДн по ФЗ-152 со всеми обязательствами. Порядок хранения скриншотов, логов, дампов и сроки их уничтожения тоже фиксируются в договоре.

Полный разбор рисков на каждом этапе kill chain, шаблоны документов и конкретные кейсы — в статье на форуме.

https://codeby.net/threads/yuridicheskiye-riski-pentesta-v-rossii-chem-etichnyi-vzlom-otlichayet-sya-ot-prestupleniya-po-st-272-273-uk-rf.94999/

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

Компаниям нужен человек, который встроит безопасность в разработку — от ревью кода до CI/CD.

Курс «AppSec-инженер» в Codeby Academy — 7 месяцев практики на реальных приложениях и инструментах, которые используют в продакшене.

Что внутри:
⏺️ разбор уязвимостей OWASP на реальных приложениях
⏺️ SAST/DAST инструменты, которые используют в боевых командах
⏺️ Threat Modeling и Secure SDLC на живых кейсах

Курс подойдёт: специалистам по ИБ, DevOps/DevSecOps-инженерам, разработчикам и пентестерам.

За 7 месяцев ▶️пройдёте 13 модулей — от поиска уязвимостей в коде до внедрения AppSec в процесс разработки▶️300 ак.ч. ▶️1–2 живых вебинара в месяц с автором

Старт курса — 24 августа

🔁Посмотреть программу и записаться

❓Пятничный опрос

Некоторые уязвимости JavaScript позволяют изменить поведение сразу всех создаваемых объектов.

🚩 Новые задания на платформе HackerLab!

🕵️ Категория Форензика — Сертификация
——————————————

🗂 В архив добавлены задания + райтапы:

🟠Веб - Расклад

Приятного хакинга!