Форензики есть?

Вышла таблица сравнения инструментов форензики за 2026 - тринадцать продуктов, от нуля до миллиона с лишним.

Autopsy, Velociraptor и KAPE закрывают почти всё, за что просят деньги остальные. Разница - в скорости и отчётах.

Чем пользуетесь? И где бесплатный стек у вас упёрся так, что пришлось брать лицензию.

1️⃣Сравнение CyberTriage 🔗 https://www.cybertriage.com/blog/computer-forensic-tools-comparison-chart-2026/

2️⃣ Каталог SANS https://www.sans.org/tools?refinementList%5Bfacets.focusArea%5D%5B0%5D=Digital%20Forensics%20and%20Incident%20Response

3️⃣ Awesome list https://github.com/meirwah/awesome-incident-response#windows-evidence-collection

❗️ Критическая уязвимость Account Takeover в Keycloak
(CVE-2026-18963)

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

➖Уязвимость возникает в потоке сброса пароля reset-credentials, в методе ResetCredentialEmail.action(). По замыслу он завершает шаг подтверждения по e-mail только после того, как пользователь перешёл по ссылке из письма и обработчик action-токена записал в сессию ACTION_TOKEN_USER_ID.

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

    @Override
    public void action(AuthenticationFlowContext context) {
        context.getUser().setEmailVerified(true);
        context.success();
    }

Дотянуться до этого шага напрямую позволяет то, как хранится состояние экрана выбора способа входа: Keycloak держит его как «залипающий» атрибут сессии (AUTHENTICATION_SELECTOR_SCREEN_DISPLAYED), из-за чего исполнение шага с подтверждением по e-mail остается доступным и после отправки письма.

Алгоритм атаки 🤩

1️⃣ Атакующий инициирует сброс пароля для жертвы (жертве уходит штатное письмо, переходить по ссылке не требуется)
2️⃣ Через tryAnotherWay=on и повторный запрос к reset-credentials атакующий возвращается на шаг подтверждения e-mail и напрямую вызывает его action(), минуя authenticate().
3️⃣ Метод помечает почту подтверждённой, поток уходит на UPDATE_PASSWORD
4️⃣ Атакующий ставит новый пароль без доступа к почте жертвы и без единого клика по ссылке

Патч чинит обе причины: ResetCredentialEmail.action() теперь требует совпадения пользователя из сессии с ACTION_TOKEN_USER_ID (записывается только при переходе по ссылке из письма), а состояние экрана выбора способа входа больше не «залипает» на весь поток - оно привязано к конкретному шагу.

Условия эксплуатации:
⏺В realm включена функция Forgot Password

💬 К тому же доступен публичный PoC , в котором есть флаг --safe-check для безопасной проверки наличия уязвимости. Он шлет несуществующий юзернейм и смотрит, обходится ли email-gate в reset-потоке.

🔺 Критичность - 9.1 CVSS 3.1 (Critical)

⏺CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
⏺CWE-640 (Weak Password Recovery Mechanism)

Затронутые версии:
⏺Upstream Keycloak: <=26.7.1
⏺Red Hat build of Keycloak: 26.4.x < 26.4.15, 26.6.x < 26.6.6

Рекомендации:
⏺Обновиться до пропатченной версии
⏺Проверить логи на следы эксплуатации (аномальные reset-credentials)

Патч:

✅26.7.2 - основная ветка
✅26.6.6 / 26.4.15 - бэкпорты (RHBK)

➖В качестве временной компенсирующей меры рекомендуется выключить функцию Forgot password во всех realm-ах.

🔗 CVE - https://nvd.nist.gov/vuln/detail/CVE-2026-18963
🔗 Эксплоит: https://github.com/Snizi/CVE-2026-18963-Exploit
🔗 GitHub: https://github.com/keycloak/keycloak/issues/51833
🔗 Подробный ресерч: https://www.pruva.dev/reproductions/REPRO-2026-00337