RedFlick: расследовать не вложение, а то, что произошло после клика
Почему знакомый отправитель и обычный системный процесс не доказывают безопасность. Разбираем защитную логику: письмо, запуск, закрепление, проверка результата.
Читать разборНовые разборы: от сигнала к проверке
Постквантовые сертификаты: сначала испытать цепочку доверия
Криптография меняется, но чаще ломается совместимость. Как подготовить проверяемый пилот и не превратить обновление защиты в недоступность сервиса.
Читать разборНовые разборы: от сигнала к проверке
Угроз стало больше. Какие цифры действительно помогают защищать бизнес?
Свежая статистика фишинга и GenAI полезна, если превращать её в проверяемые действия. Разбираем, где заканчиваются наблюдения исследователей и начинается ваша оценка риска.
Читать разборAI-агенты приходят на рабочий ПК: кто ограничит их полномочия?
Локальная модель и изоляция исполнения решают разные задачи. Что проверить перед тем, как дать агенту доступ к файлам, сети и рабочим приложениям.
Читать разборНовые разборы: от сигнала к проверке
Удалённая поддержка как точка входа: зачем атакующему два RMM-агента
Подписанный установщик ещё не означает согласованный доступ. Разбираем, как отличить работу поддержки от чужого присутствия и не закрыть инцидент слишком рано.
Читать разборСкачали привычную программу, получили заражение: как проверять доверие к установщикам
Поддельная страница загрузки атакует привычку, а не только компьютер. Практический разбор для пользователей, IT-поддержки и расследователей.
Читать разборОдна учётная запись до облака: почему CI/CD нужно защищать как доступ к production
Связь между входом пользователя, репозиторием и развёртыванием часто важнее отдельной настройки. Как проверить границы доверия и не оставить восстановленный аккаунт с прежними рисками.
Читать разбор// threat-informed practice
Новые фокусы threat-informed аудита
Remote access остаётся Tier-0: VPN надо проверять как identity-систему
VPN, reverse proxy и панели управления больше нельзя считать сетевой периферией. Это точка входа к админским действиям, поэтому нужны MFA, key-only access, экспозиция по allowlist, логи и быстрый cert/config drift контроль.
читать разбор →SOC без alert budget превращается в шум: detection надо мерить как продукт
Сообщество всё чаще обсуждает не количество правил, а способность команды обработать сигнал. Хорошее правило имеет owner, гипотезу, источник телеметрии, ожидаемую частоту, false-positive budget и ретест.
читать разбор →Infostealer-инцидент заканчивается не сменой пароля, а проверкой сессий
Кража cookies, OAuth grants и refresh tokens меняет логику реагирования. Если команда сбросила пароль, но не отозвала сессии, устройства, почтовые правила и интеграции, атакующий может остаться внутри.
читать разбор →// свежая исследовательская подборка
Что проверять в инфраструктуре сейчас
Новая волна материалов Virusologia собрана вокруг практических проблем: management plane, почтовые zero-click риски, cloud identity, AI-tool boundary и проверяемое восстановление после инцидента.
KEV и management plane: короткий путь к приоритетам
Уязвимости на VPN, edge и identity-узлах нельзя оценивать только по CVSS. Нужна связка: доступность из интернета, роль актива, наличие эксплойта, журналирование и план срочного rollback.
Читать разбор ->Zimbra zero-click: почта как ранний сигнал компрометации
Почтовая инфраструктура требует отдельной готовности: telemetry, изоляция учетных записей, быстрый сбор артефактов и критерии восстановления доверия.
Читать разбор ->Cloud identity: forensic readiness важнее красивого dashboard
В облаке расследование ломается не из-за отсутствия графиков, а из-за пробелов в логах, ролях, federation trust, service accounts и storage access.
Читать разбор ->AI и composite attack paths: почему нужен policy layer
AI может хорошо собирать гипотезы, но каждая техника должна проходить policy check, evidence binding и независимый validator. Иначе automation превращается в источник шума.
Читать разбор ->Recovery-denial: когда резервные копии не спасают
Главный тест resilience - не наличие backup, а доказанный restore drill: кто запускает, сколько длится, какие данные теряются и что считается успешным восстановлением.
Читать разбор ->Open WebUI и agentic tools: граница между помощником и executor
Любой AI-инструмент с доступом к файлам, браузеру или API должен иметь каталог разрешенных действий, аудит, redaction и kill switch.
Читать разбор ->// threat intel feed
Свежая повестка безопасности
Короткие аналитические заметки: что произошло, чем опасно, что проверить в инфраструктуре и как это превратить в понятный action plan.
// intelligence -> control
Сигналы, которые стоит превратить в controls уже сейчас
Текущая threat-картина меньше похожа на одну громкую уязвимость и больше на набор границ доверия, которые ломаются под давлением: edge devices, recovery workflows, parsers и AI agents.
EDGE LOGSBACKUP TRUSTSSO PARSERSAI FACT-PACK
Exploit-window короче patch-ceremony
Edge response требует central logs, config diffs, identity context и trust rotation до заявления о recovery.
читать →Recovery - security control, а не только IT-процесс
Backup-план нужно проверять против stolen sessions, backup-policy edits и потери hypervisor trust.
читать →Parser disagreement - запах authorization-проблемы
Когда proxies, SSO libraries и application code интерпретируют один вход по-разному, безопасный invariant уже сломан.
читать →AI triage должен давать hypotheses, а не authority
Модель может ускорять reasoning, но evidence, policy и validators решают, что становится confirmed finding.
читать →// текущие сигналы -> action plan
Defensive-цикл ускоряется на каждой границе доверия
Самые сильные текущие сигналы — не отдельные CVE. Это сокращение response window, злоупотребление session после валидного входа, install-time execution, self-protection gaps в policy, modular malware и переносимый AI-agent hijacking.
22s HAND-OFFTOKEN REPLAYNPM V12K8S 1.36MODULAR C2AGENT HIJACK
Hand-off за 22 секунды меняет экономику triage
Рутинный alert может быть последней дешевой точкой containment до интерактивного доступа и подготовленного second-stage оператора.
читать →После token theft расследуйте весь authenticated workflow
Mailbox rules, OAuth grants, MFA methods, devices и business actions переживают простую смену пароля.
читать →Modular malware оставляет behavioral contracts
Роли компонентов, IPC, доступ к конфигурации и network rhythm устойчивее одного filename.
читать →Install-time execution становится явным trust decision
npm v12 safer defaults уменьшают скрытое выполнение, а исключения требуют ownership и воспроизводимых clean builds.
читать →У admission policy появился разговор о self-protection
Static policy anchors могут закрыть bootstrap gaps, но alpha-внедрение требует drift metrics и проверенного recovery.
читать →У каждой протестированной frontier model нашли хотя бы один hijack path
Полезный ответ — system-level evaluation для content, policy, memory, connectors, tools и action evidence.
читать →Предыдущий intelligence briefing
// update
Privilege escalation и attack paths как язык защиты
Новые материалы на этой неделе связаны одной идеей: зрелая безопасность смотрит не только на CVE, но и на путь атаки. Linux hardening, Active Directory graph, KEV-first patching и supply-chain контроль должны сходиться в один remediation roadmap.
LINUXADKEVCI/CDSECRETSRETEST
Linux privilege escalation: defensive checklist
Проверка SUID/SGID, sudoers, cron, root-сервисов, writable scripts и секретов должна быть регулярным baseline, а не реакцией после инцидента.
читать> linux / hardeningActive Directory attack paths для защитников
Сервисные аккаунты, delegation, ADCS, GPO и CI/CD-узлы нужно рассматривать как граф движения к Tier 0, а не как разрозненные настройки.
читать> active-directoryKEV-first triage
Патчи нужно сортировать по эксплуатации, exposure и бизнес-роли актива. CVSS остаётся полезным, но не должен быть единственным рулём.
читать> kev / patchingSupply chain и CI/CD secrets
Главная зона риска - не только зависимость, но и runner, который видит publish-токены, cloud credentials и внутренние артефакты.
читать> supply-chainEdge-устройства снова стали первой линией атаки
По обсуждениям в профессиональных сообществах видно одно: атакующие все чаще начинают не с домена Windows, а с VPN, шлюзов, панелей управления и забытых reverse proxy. Поэтому внешний периметр нужно проверять как живой организм: версия, экспозиция, MFA, журналы входа, странные страны и внезапные ночные сессии.
источник > kev / edge-securityAI-пентест стал полезным, когда у него есть границы
Тренд из LinkedIn и AppSec-дискуссий: бизнесу нужен не автономный "робот-хакер", а помощник, который объясняет риск, убирает шум, связывает evidence с remediation и не выходит за подтвержденный scope. SecMon должен развиваться именно так: AI как аналитик, а не бесконтрольный исполнитель.
источник > ai-security / aptsБраузерный стек требует отдельного SLA
Chrome, Chromium-браузеры, Electron-приложения и расширения живут быстрее классического patch management. Если рабочая станция администратора отстает на несколько релизов, это уже не мелочь, а полноценная точка входа в инфраструктуру.
источник > browser-securityPatch Tuesday без ретеста оставляет слепую зону
Обновить систему мало. После патчей нужно переснять внешний профиль: какие порты остались открыты, не вернулись ли RDP/SMB наружу, не изменились ли TLS-настройки, не появился ли новый сервис после установки "временного" агента.
источник > patch-managementSupply chain обсуждают уже не как редкость, а как рабочую угрозу
На Reddit и в инженерных чатах все чаще спорят не о том, "бывают ли" атаки через зависимости, а о том, как быстро заметить подмену пакета, токена, CI-секрета или контейнерного образа. Практический вывод простой: SBOM, pinning, секреты вне репозитория и контроль release pipeline становятся базовой гигиеной.
источник > supply-chainРусскоязычная повестка сместилась к практичной защите
На Хабре и в русскоязычных security-обсуждениях хорошо видно взросление темы: меньше магии вокруг "сканера уязвимостей", больше разговоров про инвентаризацию, журналы, расследования, hardening, понятные отчеты и ответственность за исправления.
источник > ru-infosec// defensive checklist
Что проверить на этой неделе
KEV-first очередь: сначала CVE, которые уже эксплуатируют
VPN, reverse proxy, панели управления и SSH только по allowlist
Chrome/Chromium/Electron обновлять отдельным SLA
SBOM, pinning зависимостей и проверка CI/CD секретов
Ретест публичных доменов после каждого крупного обновления
Журналы входов: страны, ASN, время, user-agent, неудачные MFA
// source radar
Как я читаю повестку
Смотрю, что обсуждают CISO, AppSec и продавцы PTaaS: где боль бизнеса, какие формулировки покупают, какие функции требуют в enterprise security review.
Reddit / форумы
Ищу живые споры практиков: какие уязвимости реально ломают инфраструктуру, где сканеры шумят, а где дают полезный сигнал.
Хабр / RU-сообщество
Отдельно отмечаю русскоязычный контекст: администрирование, импортозамещение, VPN, SOC-практика, Windows/Linux hardening и доступный язык для читателя.
// ai security update
AI skill risk guard
Новая заметка в блоге разбирает, почему LLM-планировщик в security automation должен проходить через risk taxonomy, verified scope, allowlisted catalog и validation layer. AI-предложения остаются гипотезами до подтверждения evidence.
// обновлено
Threat Intel как action plan
Раздел дополнен свежими прикладными темами: edge/VPN hardening, 404 bursts, secrets response, SBOM triage и detection-as-code. Фокус не на сенсациях, а на том, что проверить в инфраструктуре и как превратить сигнал в задачу.
// обновлено
Threat Intel и detection engineering: меньше шума, больше решений
Threat Intel полезен, когда превращается в action plan: какие hunt hypotheses проверить, какие rules шумят, где не хватает provenance, какой telemetry layer опасно перегружать и почему release trust надо считать частью perimeter.
Detection engineering: считайте не только правила, но и шум
Количество rule files почти ничего не говорит о зрелости detection program. Намного важнее coverage intent, false positive burn rate, скорость правки и способность превратить red-team/pentest lessons в стабильные сигналы.
читать разбор →Threat hunting: гипотеза должна переживать смену инструментов
Когда hunting завязан на один SIEM-запрос или одну ручную заметку, он не переживает смену источника логов. Намного полезнее описывать hunt как reusable hypothesis flow: сущности, шаги, enrichment и критерий остановки.
читать разбор →SBOM без provenance оставляет слепую зону релиза
Компонентный состав важен, но сам по себе не отвечает на вопрос, откуда взялся артефакт и кто подтвердил его сборку. Поэтому разговор о release trust неизбежно приходит к attestations, digest pinning и verification gate.
читать разбор →// updated
SOC-поток как отдельная рабочая лента
Threat Intel теперь связан с отдельным SOC Research stream: telemetry contracts, Sigma validation, hunt-flow design, query budgets и шум как измеряемая инженерная проблема.
Detection-as-code: Sigma как язык между пентестом и SOC
Хороший пентест должен оставлять после себя не только PDF, но и идеи детектирования. Sigma помогает описать сигнал один раз и затем переводить его в SIEM-запросы.
читать разбор →Osquery/Fleet: видимость должна быть безопасной для хоста
Visibility-инструменты ценны, пока не начинают вредить целевой машине. Osquery и Fleet хороши там, где есть query budget, ownership, интервал, label targeting и понимание цены каждой таблицы.
читать разбор →Threat hunting: гипотеза должна переживать смену инструментов
Когда hunting завязан на один SIEM-запрос или одну ручную заметку, он не переживает смену источника логов. Намного полезнее описывать hunt как reusable hypothesis flow: сущности, шаги, enrichment и критерий остановки.
читать разбор →SOC Research
Отдельный исследовательский поток о том, как строить detection program без самообмана: telemetry contracts, Sigma validation, query budgets, hunt-flow design, KPI шума и нормальная передача lessons learned из пентеста и DFIR обратно в SOC.
Открыть поток →// current watch
Актуальные сигналы и что проверять
Текущий watch организован не по громкости заголовка, а по defensive decision: локализовать management plane, восстановить доверие к edge, убрать reusable CI secrets и превратить supply-chain signals в owned evidence.
Zero-day management plane: patch плюс incident review
Известная эксплуатация и root impact требуют asset inventory, проверки privileged access и verified recovery.
читать →Persistence, переживающая upgrade, меняет recovery
Успешного обновления недостаточно, если доверие уже потеряно: evidence, rebuild и monitoring становятся частью remediation.
читать →Граница доверия CI: OIDC, cache и release authority
Untrusted triggers не должны наследовать writable shared state или долгоживущую publishing authority.
читать →Due diligence становится continuous evidence graph
SBOM и provenance ценны, когда создают owned, time-bound и retestable decisions.
читать →