Вже доступно! Дослідження Telegram за 2025 — головні інсайти року 
PURP
Відкрити в Telegram
Red and blue team, два эксперта, две стороны кибербезопасности: инсайды и инсайты из мира этичного хакинга и бизнес-ориентированной защиты от специалистов Бастион. https://bastion-tech.ru/ Мнение авторов может не совпадать с позицией компании.
Показати більше3 131
Підписники
+224 години
-317 днів
+330 день
Триває завантаження даних...
Схожі канали
Немає даних
Виникли проблеми? Будь ласка, оновіть сторінку або зверніться до нашого support-менеджера.
Хмара тегів
Вхідні та вихідні згадування
---
---
---
---
---
---
Залучення підписників
червень '26
червень '26
+59
в 1 каналах
травень '26
+53
в 0 каналах
Get PRO
квітень '26
+168
в 3 каналах
Get PRO
березень '26
+239
в 1 каналах
Get PRO
лютий '26
+312
в 1 каналах
Get PRO
січень '26
+112
в 0 каналах
Get PRO
грудень '25
+154
в 0 каналах
Get PRO
листопад '25
+147
в 2 каналах
Get PRO
жовтень '25
+128
в 0 каналах
Get PRO
вересень '25
+143
в 0 каналах
Get PRO
серпень '25
+291
в 1 каналах
Get PRO
липень '25
+227
в 1 каналах
Get PRO
червень '25
+527
в 3 каналах
Get PRO
травень '25
+226
в 5 каналах
Get PRO
квітень '25
+534
в 9 каналах
Get PRO
березень '25
+160
в 4 каналах
Get PRO
лютий '25
+190
в 0 каналах
Get PRO
січень '250
в 2 каналах
Get PRO
грудень '24
+110
в 1 каналах
| Дата | Залучення підписників | Згадування | Канали | |
| 25 червня | +1 | |||
| 24 червня | +2 | |||
| 23 червня | +1 | |||
| 22 червня | +4 | |||
| 21 червня | +1 | |||
| 20 червня | 0 | |||
| 19 червня | +3 | |||
| 18 червня | +3 | |||
| 17 червня | +3 | |||
| 16 червня | +1 | |||
| 15 червня | +6 | |||
| 14 червня | +1 | |||
| 13 червня | 0 | |||
| 12 червня | +3 | |||
| 11 червня | 0 | |||
| 10 червня | +1 | |||
| 09 червня | +1 | |||
| 08 червня | +7 | |||
| 07 червня | +3 | |||
| 06 червня | +2 | |||
| 05 червня | +4 | |||
| 04 червня | +8 | |||
| 03 червня | 0 | |||
| 02 червня | +3 | |||
| 01 червня | +1 |
Дописи каналу
| 2 | Ну да, в следующий раз когда твой лид будет жаловаться, что PURP тебя от работы отвлекает, скажу ему что ты не лентяй и самодур, а блогер и премированный киберпросветитель. Все сразу на свои места встанет. 😁
#blue_team | 294 |
| 3 | Ну да, в следующий раз когда твой лид пожалуется, что PURP тебя от работы отвлекает, скажу ему что ты не лентяй, а премированный блогер и киберпросветитель. Сразу все станет понятно. 😁
#blue_team | 1 |
| 4 | @Lobrigate наш с тобой труд оценили ребята из Cyber Media. Теперь имеем право ходить с очень важными лицами по офису!
#red_team #какнеожиданноиприятнаааа | 301 |
| 5 | Если нет ты знаешь, что делать) | 595 |
| 6 |  Грабители в Великобритании при помощи украденного экскаватора вырвали из стены банкомат, погрузили в багажник (интересно, как далеко он с таким перегрузом уехал) и унеслись в закат.
А ЭТО есть в вашей модели угроз? 😂
Старые добрые методы формата «лом и чья-то родительница» все еще работают)))
#red_team #memes | 642 |
| 7 | Ловите новую use-after-free в SVGA-подсистеме VirtualBox 🏃♀️
Как выяснилось, контекстная таблица объектов (COTable) продолжает держать указатель на MOB (guest-backed memory object) после его уничтожения. Ссылка попросту не инвалидируется при free(). Это создает висячий указатель, который можно переиспользовать через heap-grooming.
Атака требует выполнения кода в гостевой ОС (не удаленная, требуется включенная 3D-акселерация/VMSVGA). Зато при успешной эксплуатации позволяет выполнить код в процессе VirtualBox на хосте без взаимодействия пользователя. Особенно актуально для инфраструктур, где VirtualBox используется как песочница.
Эксплуатация проходит в четыре этапа:
▶️ Через SVGA-команды создаем графический объект MOB, привязываем его к COTable, затем уничтожаем MOB. COTable продолжает хранить на него указатель.
▶️Дальнейшим heap-grooming добиваемся, чтобы на месте старого MOB или его буфера оказались другие важные структуры — новый DX-контекст и соседние MOB, на которые все еще ссылается COTable.
▶️ Через DX-команды эксплуатируем зомби-COTable. Сначала получаем контролируемое повреждение полей DX-контекста и MOB-структур, затем расширяем возможности воздействия на память и добиваемся примитивов arbitrary read/write в адресном пространстве процесса VirtualBox.
▶️ С помощью инфодискложера находим базу модуля устройства VirtualBox (например, VBoxDD.so на Linux) и перехватываем критический function pointer, после чего вызываем соответствующую SVGA-команду. Управление уходит в ROP-цепочку, которая вызывает mprotect (или аналогичный механизм) для получения исполняемой памяти и передает выполнение полезной нагрузке из гостя. При этом цикл обработчика SVGA аккуратно восстанавливается, чтобы процесс гипервизора не завершился аварийно.
➡️ Подробности
#red_team | 622 |
| 8 | MAD Bugs: 21‑летний use-after-free в PHP unserialize() и первый публичный удаленный UAF‑RCE на PHP 8.5.5
Исследователи из Calif обнаружили в PHP use-after-free в unserialize(). Баг живет с PHP 5.1 и затрагивает путь через Serializable. Коллеги создали локальный эксплойт, обходящий disable_functions без зависимости от /proc и жестких оффсетов, а также добились RCE на актуальной PHP 8.5.5.
Авторитетно заявляется, что значительную часть аудита кода и генерации эксплойта выполнила Claude, а исследователи занимались архитектурой атаки и верификацией.
Суть бага 🔽
Для пользовательских классов, реализующих Serializable::unserialize(), не инкрементируется BG(serialize_lock). Из‑за этого рекурсивный вызов unserialize() делит один и тот же var_hash между внешним и внутренним разбором. При изменении структуры свойств это приводит к use-after-free таблицы свойств: старая arData освобождается, но остается в var_hash и может быть переиспользована под данные атакующего.
Эксплуатация 🔽
Локальная цепочка (около 30 срабатываний UAF):
▶️ Задается класс с Serializable::unserialize(), который рекурсивно вызывает unserialize() и меняет свойства, вызывая resize таблицы.
▶️ Формируется пейлоад, многократно триггерящий UAF и дающий контролируемое перезаписывание освобожденной структуры.
▶️ Строятся примитивы: утечка адресов кучи, произвольное чтение (uaf_read).
▶️ Подделывается структура Closure, чтобы через поддельный func.handler (из таблицы функций модуля) вызвать zif_system, обходя disable_functions.
Удаленный эксплойт использует тот же UAF в эндпоинте вида unserialize($_REQUEST['cook']); echo serialize(...). Он опирается на Apache prefork (краши воркеров как оракул), на лету парсит ELF libphp (PT_DYNAMIC, .gnu.hash, GOT), находит базу libc и адрес system(). Затем подделывает stdClass, чтобы при serialize() / get_properties_for() вызывался system() с командой из байтов объекта.
Импакт 🔽
В итоге memory corruption в unserialize() дает RCE даже при disable_functions и в типичных Docker‑окружениях. При этом эксплуатация требует специфического паттерна кода (класс с Serializable, рекурсивный unserialize() и рост таблицы свойств), что ограничивает практическое применение.
Тем не менее, это прикольная демонстрация надежной эксплуатации UAF в PHP 8.x с использованием ИИ для автоматизации низкоуровневой части атаки.
Специально выбрал вам картинку из статьи посложнее, чтобы мозг еще больше запутался. 👊
➡️ Источник
#red_team #php #MADBugs #memorycorruption | 928 |
| 9 |  Жизненно, эксперты | 866 |
| 10 |  #red_team #memes | 1 224 |
| 11 | @Pr0xProw ты у нас уже звезда или еще нет?
Доступы тебе что ли подрезать для профилактики...
#blue_team #memes | 1 077 |
| 12 | 1-click угон GitHub-токенов через github.dev и баг VS Code Webview 😮
В browser-версии VS Code (github.dev) обнаружена цепочка, позволяющая украсть GitHub OAuth-токен одним переходом по ссылке на специально подготовленный репозиторий. Техника угона строится на комбинации из широких OAuth-прав токена, который GitHub выдает github.dev, бага/особенности VS Code Webview и возможности установки расширения через синтетические keyboard events.
Суть бага 🔽
При открытии github.dev GitHub автоматически прокидывает в web-IDE OAuth-токен, чтобы редактор мог работать с GitHub API от имени пользователя. Этот токен не ограничен текущим репозиторием и дает доступ ко всем репозиториям, к которым у пользователя уже есть доступ, включая приватные и organization-репозитории.
Webview внутри VS Code умеют пересылать keyboard events в основное окно редактора через message passing, чтобы горячие клавиши работали даже внутри iframe/webview. Эти события можно синтетически подделывать из JavaScript внутри webview. В PoC использовался Jupyter notebook (.ipynb) внутри github.dev.
Атака выглядит так 🔽
▶️ пользователь открывает ссылку вида https://github.dev/...
▶️ вредоносный notebook/webview запускает JavaScript
▶️ JS генерирует цепочку synthetic keyboard events
▶️ через них инициируется установка malicious VS Code extension
▶️ расширение получает доступ к GitHub auth/session context внутри github.dev
▶️ дальше атакующий может читать приватные репозитории, вытаскивать код и пушить изменения от имени жертвы.
Если пользователь уже ранее логинился в github.dev и browser storage не очищен, атака укладывается в один клик.
➡️ Подробности и PoC
#red_team | 5 435 |
| 13 |  Под строгим CSP безопасно? Пфф... нет 🤣
Как выяснилось, даже при запрете скриптов и внешних ресурсов HTML-инъекция все еще позволяет добавить собственную веб-форму на странице логина. Если инъекция происходит в том же origin, где у пользователя сохранены креды, браузерный менеджер паролей может попытаться автозаполнить поля. В Chrome это поведение проявляется особенно ярко, Firefox и Safari ведут себя строже и сильнее зависят от структуры формы и взаимодействия с юзером.
Как работает атака 🔽
Форма отправляет данные методом GET, поэтому после клика пользователя логин и пароль могут оказаться в query-строке URL. Сам CSP при этом не блокирует обычную навигацию браузера и не предотвращает утечку URL через Referer, если это допускает referrer policy.
▶️Через HTML-инъекцию добавляется форма с полями email/password на той же странице логина. Менеджер паролей распознает знакомую структуру полей и может подставить сохраненные креды.
▶️Форма отправляется методом GET, поэтому после клика пользователя email/пароль попадают в query-параметры URL.
▶️CSP блокирует скрипты и загрузку внешних ресурсов, но не мешает переходам на другие сайты. Через HTML-инъекцию можно попытаться навязать referrer-policy (<meta name="referrer" content="unsafe-url">) и добавить <meta http-equiv="refresh"> для автоматического перехода на внешний домен.
В один клик 🔽
Чтобы уложить атаку в один клик, инжектированная форма должна менять значение уязвимого параметра так, чтобы при следующем запросе он уже интерпретировался как HTML с meta referrer и meta refresh. Пользователь нажимает кнопку один раз, остальное происходит автоматически. Если CSP разрешает inline-CSS, submit-элемент можно растянуть поверх страницы, чтобы практически любой клик пользователя отправлял форму и запускал утечку.
➡️ Подробности
#red_team | 1 137 |
| 14 | Так много LPE для Linux в последнее время, что не знаешь, за какую хвататься в первую очередь.
Надо было ставить... альт астру ред ос винду! 👊
#red_team | 917 |
| 15 | OpenAI и Anthropic на этот репорт о баге отреагировали крайне флегматично, так что я даже не знаю.
В целом банальная:
🔵Жестко фильтруйте входящий JSON от клиентов: удаляйте все несанкционированные поля (reasoning.*, encrypted_content и т.п.).
🔵Не раскрывайте конечным пользователям сырую статистику (reasoning_tokens, точный размер encrypted-блобов).
🔵Добавляйте искусственный jitter (шум) ко времени ответа API для защиты от timing-атак.
🔵Избегайте размещения критичных секретов в system prompt, если они могут влиять на ветвление скрытых рассуждений модели.
#blue_team | 1 003 |
| 16 | Зашифрованное мышление LLM: реплей reasoning-блобов и утечки через side-channel
Нашелся интересный (хоть и муторный в целом) побочный канал утечки информации из внутреннего состояния модели и вашего промпта через объем скрытого рассуждения (reasoning) и время ответа в секрет-зависимых вычислениях.
Как отмечает автор сего труда, современные LLM (OpenAI, Anthropic и другие) при использовании API возвращают «скрытый» Chain-of-Thought (CoT) в виде reasoning-блобов — JSON-структур с зашифрованным содержимым в формате base64. Эти блобы предназначены для stateless-режимов: приложение должно просто пересылать их обратно провайдеру в следующих запросах.
Блобы представляют собой аутентифицированный шифртекст:
▶️размер зависит от глубины и сложности рассуждений;
▶️любая модификация приводит к ошибке API;
▶️неизменннные блобы успешно реплеятся даже в другой сессии, под другим аккаунтом, а у OpenAI — еще и между разными моделями. Это указывает на использование глобального ключа шифрования/аутентификации.
В теории атака может выглядеть следующим образом 🔽
▶️ Захват — атакующий получает валидный reasoning-блоб, например, из предыдущего ответа API, через утечку логов или путем принудительной генерации через контролируемый запрос.
▶️Инъекция — через пользовательский ввод (например, чат-интерфейс) подается специально сформированный JSON, содержащий захваченный блоб в поле reasoning (или его аналогах), что позволяет обойти клиентскую валидацию.
▶️Реплей — бэкенд-приложение пересылает блоб в следующий запрос к LLM-провайдеру как часть состояния сессии (контекста диалога).
▶️Эксплуатация — провайдер принимает блоб как легитимное продолжение скрытого состояния. Это позволяет манипулировать внутренним контекстом рассуждений модели, выполнять контролируемые тайминг-атаки, измеряя время ответа в зависимости от секретных данных в промпте, а также проводить межсессионные и кросс-пользовательские атаки на приложения с общей (разделяемой) инфраструктурой.
Импакт 🔽
Если злоумышленник может внедрять произвольный JSON во входные сообщения (например, через чат-интерфейс), он потенциально способен инжектировать чужие reasoning-блобы, которые провайдер примет как валидные. Это заставит модель продолжить чужое рассуждение в контексте ваших данных.
➡️Источник
#red_team #LLM | 881 |
| 17 | Тут внезапно @poxek_ai закинул статью на Habr про Zero Trust для AI-агентов
По опыту скажу, у многих сейчас архитектура выглядит так: «давайте дадим LLM доступ к CRM, почте, базе и продовым API, а потом попросим ее вести себя нормально». Да-да, очень взрослый security design, все как любит @Lobrigate)) Это почти как хранить ключи под ковриком и называть это UX.
В тексте как раз про то, почему агент с инструментами — это уже не просто чатик, а отдельный полноценный участник инфраструктуры со всеми вытекающими. Ему нужны своя идентификация, короткоживущие креды, deny-by-default, allowlist tools, песочница, нормальные логи tool calls и человек на опасных действиях.
Короче, если ваш AI-агент может прочитать внутреннюю wiki, дернуть API, отправить наружу файл и никто потом не поймет, кто это сделал, проблема не в том, что модель тупанула, а в том, что вы ей выдали полные права как стажеру в первый день (или как выдали обезьяне автомат). Только на стажера хотя бы можно повесить ответственность, а на агента нет))
➡️ Читаем.
#red_team #AI | 812 |
| 18 | На LinuxBlog.io вышло практическое руководство по использованию Nmap в Linux-средах
Прям очень хорошая высушенная шпаргалка с консольными командами, покрывающая большинство повседневных задач + упор на инвентаризацию и профилирование систем.
Например:
🔵 Быстрое обнаружение активных устройств
🔵 Различные техники сканирования портов, включая скрытое SYN-сканирование и работу с UDP-сервисами
🔵 Определение версий ПО и ОС (OS/Service Detection) для аудита инфраструктуры
🔵 Использование NSE для автоматического поиска уязвимостей, проверки анонимного доступа к FTP и анализа HTTP-заголовков
🔵 Оптимизация скорости сканирования и работа с форматами вывода для последующего парсинга.
#blue_team | 960 |
| 19 | С этими и другими printer stack багами чаще всего нужно не ждать патча, а сужать поверхность атаки.
🔵 Ограничьте локальный доступ к системам с USB-принтерами, особенно к терминальным серверам, киоскам и общим рабочим станциям. Ключевое условие эксплуатации таких багов — доступ к интерфейсу устройства принтера.
🔵 Отключите или уберите из эксплуатации все ненужные USB-принтеры и связанные с ними device interfaces на серверах и чувствительных хостах.
🔵 Переведите печать там, где это возможно, с локальных USB-устройств на централизованные сетевые принтеры или отдельные print-серверы, чтобы пользовательские сессии не имели прямого контакта с уязвимым USB printer stack.
🔵 Включите application control, например AppLocker или WDAC, чтобы обычные пользователи не могли запускать произвольные утилиты и PoC-код, способные отправлять нестандартные DeviceIoControl в драйверы ядра.
Настройте мониторинг на аномалии вокруг подсистемы печати, будут как маркеры грядущего DoS: внезапные BSOD с SYSTEM_SERVICE_EXCEPTION, нестабильность на хостах с USB-принтерами, подозрительные обращения к printer device path из пользовательских процессов.
#blue_team | 1 015 |
| 20 | Разбираем классический IOCTL-баг в usbprint.sys
Printer stack в Windows — неиссякаемый источник развлечений. В этот раз отличился штатный драйвер Microsoft для USB-принтеров usbprint.sys. Исследователь опубликовал разбор уязвимости, позволяющей из user-mode отправить ядро в DoS через обычный DeviceIoControl.
Отлично подойдет для crash-on-demand на терминальных серверах или киосках, где расшарены USB-принтеры.
Суть бага
Проблема находится в обработчике USBPRINT_ProcessIOCTL. Как минимум несколько IOCTL (SET_PROTOCOL, SET_PORT_NUMBER и другие) принимают данные из user-mode, но не проверяют SystemBuffer и длину буфера перед чтением.
Для METHOD_BUFFERED запросов I/O-менеджер может оставить Irp->AssociatedIrp.SystemBuffer == NULL, если входной и выходной буферы имеют нулевую длину. Однако usbprint.sys продолжает работать с указателем без валидации.
В результате при lpInBuffer = NULL и nInBufferSize = 0 драйвер разыменовывает NULL-указатель в kernel-mode. На современных версиях Windows это приводит к STATUS_ACCESS_VIOLATION (0xC0000005) и обычно заканчивается BSOD с SYSTEM_SERVICE_EXCEPTION (0x3B).
Самое ироничное в том, что автор драйвера знал, как правильно. В том же диспетчере соседний case 8 делает все по науке (проверяет буфер и возвращает STATUS_INVALID_PARAMETER). Но в трех других кейсах антипаттерн с прямым чтением оставили как есть. ⏳
Microsoft кстати баг не исправила. В компании признали его несрочным и отложили в бэклог для исправления в будущих версиях.
➡️ Подробности
#red_team #Windows #DoS | 902 |
