PURP

@Pr0xProw намек понят! Отправим тебя в командировку на какой-нибудь объект в Сибири. Будешь там хекать автокормушки для тюленей или сертифицированных 🐧 поднимать на закрытых предприятиях.

Коллега пентестер из Бастиона @thxpluxury очень постарался и выдал на Хабр статью по грамотному использованию ИИ в пентесте. Я всегда говорил, говорю и буду говорить, что ИИ — это инструмент. Хорошо, когда вы его с умом используете. Плохо, когда используете без ума. Как и, собственно, любой инструмент. Вилкой можно лапшу есть, а можно нельзя в розетку сунуть... И в обоих случаях инструмент не отвечает за то, что делает его владелец. Отказываться от удобных инструментов и вернуться к поеданию лапши руками — не очень перспективная затея. Короче, если отойти от лирики, статья про то как не задолбаться с расхлебыванием слоповых репортов от ИИ и повысть качество нейровыдачи, как настраивать и вот это все. ➡️ https://habr.com/ru/companies/bastion/articles/1057486/ #red_team #AI

Вы здесь? Я вернулся. Так еще и не с пустыми руками. Поговаривают, что последний год на багбаунти какие-то искусственные разумы какие-то уязвимости ищут. Пока у ИИ нету собственного счета чтоб получать баунти и покупать себе токены - прослойкой выбрал исследователь. А ввиду отсутствия мотивации у самого агента, при поиске багов часто появляются отчеты уровня "Мы нашли клиентский ключ - это токен - токены открыто хранить нельзя - утечка секретов и влияние на доступность и конфиденциальность, значит крит" К счастью или к сожалению - вендоры так не считают. То есть часто итогом такого багхантинга является потраченные токены и информативы. Короче не круто. При этом если подходить с головой и разбираться, то окажется что процент верных отчетов все больше и больше стремится к 0. Но это не результат того, что условный Claude Code решил что он не хочет работать и будет вам присылать бесполезные отчеты. ИИ часто просто не имеет представления о бизнес-процессах, о том что является уязвимостью в контексте конкретной программы, а также не имеет хороших инструментов для проверки. Вот о каком-то своем опыте в юзинге ИИ я и хотел написать. Короче вот статья - https://habr.com/ru/companies/bastion/articles/1057486/ Вы заходите и дочитываете до конца. Ставите плюсик на статью - мне приятно будет:) Ну и можете задавать вопросы. Под статьей. Тут в комментариях. Или ЛС. ps: shout-out @slonser_notes

Победители розыгрыша: 1. Алексей 2. Виктор Глебов 3. Богатырь 4. n1Mp 5. L Грац всем! Вам напишет @ancotir в ближайшее время чтобы по доставке уточнить инфу. Всем кто не выиграл (или выиграл но хочет еще) — ждем августа, там будет розыгрыш точно такой же второго выпуска, а потом в сентябре розыгрыш третьего. Тоже по пять штук.

пс, там это, во вторник уже журналы дарить будем, еще есть возможность поучаствовать 🏃‍♀️

Судя по вашим ответам я щас дичайше вкину на вентилятор 😂 Если какие проблемы к автору вопроса идем в канал @architect_insights и беседуем 👊 ➡️ Итак, правильный вариант — третий. Но я не сомневался, что вы ответите как ответили. Тот случай, когда обе стороны говорят по делу, просто спорят о разном. Обезличивание — это не бинарное суждение «данные защищены / не защищены». У него есть уровни, и разница между ними принципиальная: ▶️ Псевдонимизация — например, заменили ФИО на «сотрудник №1247». Данные всё ещё связаны между собой, и по связям возможно восстановить человека; ▶️ Анонимизация — связи разорваны так, что восстановить исходную личность невозможно; ▶️ Синтетика — данные полностью сгенерированы, примерно отображают реальные данные, но ими не являются. В нашем кейсе инженер сделал именно псевдонимизацию, а называет это обезличиванием. Это не одно и то же — и вот тут безопасник прав, потому что матрица прав — это не просто табличка, это целая карта организации. По ней читается, сколько у вас отделов, кто с чем работает, где узкие места, у кого концентрируются критичные доступы. ФИО убрали, а структура осталась — для того, кто будет планировать атаку, это намного ценнее списка фамилий. В части состава данных безопасник прав, но и инженер не выдумывает. Полгода ручного разбора — это реальные деньги и упущенное время, а ролевую модель строить все равно надо. Отказ от инструмента не решает задачу, он ее откладывает. Так почему третий вариант, а не четвертый? Потому что вводных данных здесь достаточно — нам известно и что уходит в модель (матрица прав), и в каком виде (псевдонимизированном), и зачем. Не хватает не данных, а правильно поставленного вопроса. Спор «пускать ИИ или не пускать» ложный. Настоящий вопрос — как пускать: ▶️ локально развернутая модель, из которой наружу не уходит ничего; ▶️ выборка вместо всего массива — открытая модель предлагает подход на фрагменте, а вся дальнейшая обработка выполняется вручную. Два варианта, при которых инженер получает свой каркас, а безопасник — свой периметр.

Вы действительно решили спросить у народа, кто прав — разрабы или безопасники? Ставьте ❤️ если вы за iOS и 🔥 если за Android, посмотрим сколько нас!

🏃‍♀️ Ну чо народ, погнали с новой задачкой? Придумали вам тут с Александром @architect_insights ситуацию. @Lobrigate просьба не подсказывать, я и так знаю что ты вкинешь. Крупная компания внедряет IDM. В системе, по-классике, несколько тысяч сотрудников, у каждого свой ворох прав, в том числе лишних, о ролевых моделях вообще не слышали что это такое. Полный беспорядок короче. Инженер предлагает ускорить разбор всего этого через выгрузку обезличенной матрицы прав (без ФИО, без реальных логинов — только «сотрудник №1247, отдел, набор доступов») и скормить ее LLM, чтобы та помогла выявить паттерны и предложить черновик ролевой модели. Дальше все делается руками, глазами, через ревью там всякие и прочее. Но стартовать хочется не с чистого листа, а с предложенного иишкой каркаса. Безопасник резко против, поскольку наружу уходит структура прав компании. Хоть и обезличенная, но это карта того, кто к чему имеет доступ. Инженер заверяет, что без ИИ разбор займет полгода ручной работы, а бизнес ждет результат уже вчера. Данные обезличены, ничего страшного нет, инфы не хватит чтобы что-то плохое сделать. ➡️ Товарищи знатоки, внимание, вопрос. Кто прав? Вариант 1 Инженер. Безопасник для перестраховки перебарщивает с запретами и ограничениями, что сильно тормозит процессы разработки. Вариант 2 Безопасник. Структура прав — слишком важная информация даже в обезличенном виде. Желание инженера ускориться создает слишком много рисков для компании. Вариант 3 Оба правы, с оговорками. Вариант 4 Данных недостаточно для однозначного ответа. — 🔥 — если правильный первый вариант, — ❤️ — второй, — 👍 — третий, — 🤔 — четвертый. Завтра дадим вам правильный ответ. ⏳

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

Ну все, теперь короче все хорошие ибешники объединятся в одного большого ибешника и победят всех нехороших ибешников хакеров и мошенников и наступит мир и благодать на Земле. Запомните этот твит.

GhostApproval: как AI-ассистенты пробивают модель доверия через симлинки Техника GhostApproval позволяет вредоносному репозиторию вынудить AI-ассистента незаметно для разработчика записать данные в чувствительные файлы вне проекта, вплоть до ~/.ssh/authorized_keys. В результате подтверждение на изменение, которое выглядит как правка обычного файла проекта, может дать злоумышленнику постоянную возможность входа по SSH. 🥺 Атака строится на старом трюке с симлинками по CWE‑61 с вишенкой на торте в виде CWE-451. Файл вроде project_settings.json или другой конфигурации, упомянутой в README, оказывается симлинком на чувствительный путь, например ~/.ssh/authorized_keys или shell-startup файл. При выполнении инструкций вроде «настрой рабочее окружение» агент следует по симлинку и записывает, например, SSH-ключ атакующего, тогда как разработчик видит подтверждение на изменение обычного файла проекта. Пошагово: ▶️Добавляем в репозиторий конфиг вроде project_settings.json, который на самом деле является симлинком на ~/.ssh/authorized_keys. ▶️В README пишем: «обновите конфигурацию и добавьте этот SSH-ключ» — все выглядит как легитимная настройка проекта. ▶️Разработчик клонирует репозиторий и просит AI «подготовить окружение» или «выполнить шаги из README». ▶️Агент показывает окно подтверждения с безопасным именем файла внутри проекта. Реальный путь ~/.ssh/authorized_keys не отображается. ▶️Разработчик думает, что разрешает изменение локальной конфигурации проекта, и подтверждает операцию. ▶️Агент следует по симлинку и дописывает SSH-ключ атакующего в ~/.ssh/authorized_keys. Вот и все ⏳ ➡️ Подробности #GhostApproval #AI #symlink #red_team

Коллеги из Бастиона наконец-то закончили пошаговый подробный гайд по созданию РБПО в случаях когда бюджет на ИБ поставляет 50 апельсинок на карте Пятерочки. Это не прям чтобы совсем «без бюджета» история, как заявляет автор цикла, скорее с минимальными затратами по сравнению с тем, каких денег могут стоить зрелые проработанные пайплайны. РБПО итоговый базовые нужды закрывает. В любом случае, это гораздо лучше, чем когда у вас совсем ничего нет. Читаем и берем на вооружение. ➡️ Что такое РБПО, зачем нужна и как выглядит минимальный конвейер. ➡️ Про создание виртуальных машин в VirtualBox для сервисов безопасной разработки ПО. ➡️ Про разворачивание самих сервисов. ➡️ Базовую конфигурацию: настройку GitLab и GitLab Runner, подготовку Nexus к приему артефактов и т.д. ➡️ Написание GitLab CI/CD-конвейера, автоматизирующего сборку приложения и проверки безопасности. ➡️ Подготовку диска для хранения бэкапов и автоматизацию создания резервных копий виртуальных машин. ➡️ Проверку уязвимого приложения Reactvulna через собранный пайплайн. #blue_team

Итак, правильный вариант — четвертый. ⭐️ И @glinkinivan оч подробно объяснил, почему. Мотаем на ус.

Есть 4 варианта работы с рисками: — Принять риски (оставить как есть), — Уменьшить риски (митигация) — оставить риск, но внедрить, например мониторинг, — Отказ от риска (полное его исключение), — Передача риска (например, в страховую компанию). В описательной части у нас не достаточно вводных данных. Так, СКС может быть установлена между разрозненными группами одного отдела. Кроме того, указанная СКС может быть старой и не нужной и осталась как рудимент (Риск принимается). Вместе с тем, данный формат может продолжить функционировать, но установлен мониторинг (как указано в описательной части). В там случае у нас митигация. Вместе с тем, не редки случаи, когда заказчик не хочет показывать свои пробелы перед руководством и специально говорит, что так и задумано. Поэтому, необходимо более детально подойти к вопросу и задать Заказчику правильные вопросы для принятия им окончательного решения.

Если понравилась такая тема, ставь ❤️, будем с @Lobrigate еще подобные истории искать. Не стесняйтесь свои задачки мне или @Lobrigate в лс присылать, тоже будем в канал закидывать на саморазвитие. #red_team

Мы тут вместе с @glinkinivan сидели за чаечком и решили, что вам слишком скучно живется. 😁 Решили немного погрузить в нашу работу и подкинуть тему на обмозговать из собственной практики. ➡️➡️➡️ Ситуация Представьте, что вы проводите тестирование на проникновение и оценку защищенности среднего размера компании. В ходе работы вы обнаружили неправильную настройку (с вашей точки зрения) СКС, которая позволяет любому пользователю из одного VLAN беспрепятственного общаться с другим VLAN: видеть хосты и их открытые порты, заходить на внутренние ресурсы и т.д. Межсетевой экран (firewall) отсутствует, сетевой доступ никак не ограничен и сеть, по факту, является плоской. Исследователи доложили Заказчику о найденной уязвимости, подкрепили это PoC и рисками, которая несет данная уязвимость. Вместе с тем, Заказчик подтвердил, что ему известно о данной особенности сети, он не считает это уязвимостью и исправлять не планирует. Исследователи же со своей стороны настаивают на необходимости внесения защитный мер. Вот вам четыре варианта ответов. ➡️➡️➡️ Вопрос: при изложенных обстоятельствах, как вы думаете, кто прав в данной ситуации: Вариант 1

Исполнитель. Найденная уязвимость противоречит Best Practice, ее наличие компрометирует другие подразделения, эксплуатация может привести к утечке данных. Указание заказчика, что ему известно о данной уязвимости — клевета и нежелание платить за работу.

Вариант 2

Заказчик — ему известно о данной особенности СКС, а данная сеть специально так настроена для удобства, оперативности работы и прибыли. ИБ осуществляет мониторинг всего трафика и держит его под контролем. Указание исполнителя на необходимость срочного исправления является желанием показать свою работу и получить «легкие» деньги.

Вариант 3

Оба варианта являются верными с небольшими оговорками.

Вариант 4

Недостаточно данных для дачи правильного ответа.

В лимиты телеги они не влезают, так что вместо опроса голосуем эмодзами: — 🔥 — если правильный первый вариант, — ❤️ — второй, — 👍 — третий, — 🤔 — четвертый. Завтра дадим вам правильный ответ. ⏳

Я говорил, что придумаем, как раздать вам журналы. Начинаем с первого выпуска, после будем второй и третий дарить по той же схеме) А там может еще чего интересного придумаем. #red_team

🚨 Дарим пять журналов «Бастион» выпуск №1 Для участия: 1️⃣ Подписываемся на @purp_sec и @bastiontech 2️⃣ Жмем на «Участвую» 3️⃣ Ждем 31.07 Рассылаем только по РФ. Так что если живете в другой стране, вам самим надо найти связного которому мы ваш журнал отправим, а он уже вам. В августе будет розыгрыш выпуска №2. Всем удачи! 🌹 Картинка сгенерирована нейросетью и не является публичной офертой. Отпуск к журналу не прилагается. Да и сам отпуск — маркетинговый миф. Все знают, что его не существует. ⭐️ Участников: 0 Призовых мест: 5 Дата розыгрыша: 12:00, 21.07.2026 MSK (18 дней)

Мы тут вместе с ребятами разбираемся с одной крайне интересной вещью. Надеюсь скоро сможем уже поделиться подробностями по этой штуке. Все на Хабре будет, ссылку дам. Пока можете у Лунохода в комментах погадать что это за артефакт такой. Я думаю он старше даже части наших подписчиков. 😁 #red_team