Патч установлен. Инцидент завершён?
Исправление уязвимости закрывает путь для будущих атак, но не отвечает на вопрос, использовали ли его раньше.
Читать разборНовые разборы: от сигнала к проверке
Доступ запрещён. Но защищены ли чужие данные?
Код 403 полезен, но проверка авторизации требует контекста владельца, роли и фактического состояния данных.
Читать разборНовые разборы: от сигнала к проверке
PHP2Shell: как проверить парк PHP и не перепутать версию с уязвимостью
Два критических бюллетеня PHP требуют быстрой инвентаризации, но проверка одной версии в терминале не описывает всю инфраструктуру.
Читать разборЛокальная ИИ-модель в компании: что защищать кроме весов
Локальное размещение даёт контроль над инфраструктурой, но переносит на команду ответственность за данные, доступы и проверку результата.
Читать разборНовые разборы: от сигнала к проверке
Гостиничный Wi-Fi как точка риска: что показала кампания CaptiveCrunch
Открытая сеть в поездке не обязательно опасна, но страница подключения не должна становиться каналом установки программ и передачи рабочих паролей.
Читать разборФишинг как инфраструктура: почему блокировки одного домена недостаточно
Исследование Microsoft показывает, как связанные сервисы помогают масштабировать фишинг. Разбираем защиту без сенсаций.
Читать разборНовые разборы: от сигнала к проверке
Атака на обновления длилась минуты: почему разовой проверки недостаточно
Вредоносное обновление может появляться лишь на короткое время. Разбираем расследование Mandiant и то, как защитить цепочку поставки.
Читать разборИИ-агенты в цепочках атак: как защитить инструменты и доступы
Агентные инструменты ускоряют рутинные действия, но требуют строгих границ полномочий, журналирования и контроля человека.
Читать разборНовые разборы: от сигнала к проверке
PoeLLM: когда сервер для ИИ становится добычей майнеров
Открытые сервисы ИИ ценны не только данными: их вычислительные ресурсы тоже интересуют злоумышленников. Разбираем кампанию и защитные меры.
Читать разборПочтовый шлюз под ударом: что важно знать о CVE-2026-76519
Cisco сообщила об эксплуатации уязвимости в Secure Email Gateway. Объясняем условия риска и действия команды защиты.
Читать разборНовые разборы: от сигнала к проверке
RedFlick: расследовать не вложение, а то, что произошло после клика
Почему знакомый отправитель и обычный системный процесс не доказывают безопасность. Разбираем защитную логику: письмо, запуск, закрепление, проверка результата.
Читать разборПостквантовые сертификаты: сначала испытать цепочку доверия
Криптография меняется, но чаще ломается совместимость. Как подготовить проверяемый пилот и не превратить обновление защиты в недоступность сервиса.
Читать разборНовые разборы: от сигнала к проверке
Угроз стало больше. Какие цифры действительно помогают защищать бизнес?
Свежая статистика фишинга и GenAI полезна, если превращать её в проверяемые действия. Разбираем, где заканчиваются наблюдения исследователей и начинается ваша оценка риска.
Читать разборAI-агенты приходят на рабочий ПК: кто ограничит их полномочия?
Локальная модель и изоляция исполнения решают разные задачи. Что проверить перед тем, как дать агенту доступ к файлам, сети и рабочим приложениям.
Читать разборНовые разборы: от сигнала к проверке
Удалённая поддержка как точка входа: зачем атакующему два RMM-агента
Подписанный установщик ещё не означает согласованный доступ. Разбираем, как отличить работу поддержки от чужого присутствия и не закрыть инцидент слишком рано.
Читать разборСкачали привычную программу, получили заражение: как проверять доверие к установщикам
Поддельная страница загрузки атакует привычку, а не только компьютер. Практический разбор для пользователей, IT-поддержки и расследователей.
Читать разборОдна учётная запись до облака: почему CI/CD нужно защищать как доступ к production
Связь между входом пользователя, репозиторием и развёртыванием часто важнее отдельной настройки. Как проверить границы доверия и не оставить восстановленный аккаунт с прежними рисками.
Читать разбор// новая волна Virusologia
AI-агенты, checkout и supply-chain доверие
Две новые заметки про практическую защиту: как меняется риск skimmer-атак в e-commerce и почему AI-memory зависимости нужно считать частью доверенной границы.
AI SKIMMERSCHECKOUTSUPPLY CHAINAI MEMORY
AI-агенты и skimmer-атаки: checkout теперь нужно защищать как production-код
Agentic-подход меняет экономику атак на интернет-магазины. Разбираем, какие источники checkout-кода нужно контролировать и почему простое удаление скрипта не закрывает инцидент.
читать разбор →AI-memory пакеты как новая граница supply-chain: токены, prompts и CI под ударом
Memory-плагин для AI-агента может видеть prompt-контекст и наследовать секреты среды. Это уже privileged software, а не обычная библиотека.
читать разбор →// новая волна Virusologia
Ransomware, supply chain и операционная устойчивость
Две новые заметки: как производственный ransomware превращается в простой цепочки поставок и почему supply-chain защита начинается с управляемого отзыва credentials.
RANSOMWAREOTSUPPLY CHAINCREDENTIALS
Ransomware в производстве: риск теперь измеряется простоем цепочки поставок
Разбираем, почему производственный инцидент нужно оценивать через простой, зависимые сервисы, подрядчиков и восстановимость, а не только через список заражённых машин.
читать разбор →Supply-chain атаки: защита начинается с отзыва украденных credentials
Вредоносный пакет — это только видимая часть. Настоящий ответ строится вокруг token inventory, revocation, CI/CD evidence и пересборки доверенной цепочки.
читать разбор →// свежая волна Virusologia
Malware, supply chain и patch-governance: что важно проверить сейчас
Новая подборка собрана вокруг практических рисков: вредоносные npm-пакеты, browser storage, критичные DevSecOps-платформы, AI-assisted malware и управляемое обновление рабочих станций.
NPM STEALERGITLAB KEVAI MALWAREPATCH RINGS
WeaselBiscuit и вредоносные npm-пакеты: почему browser storage стал целью
Новая волна вредоносных npm-пакетов показывает неприятный сдвиг: атакующим всё чаще нужны не только файлы проекта, а данные браузерных расширений, токены разработчика и контекст рабочей станции.
читать разбор →GitLab KEV: патчить мало, если не проверены CI-секреты и журналы доступа
Критические уязвимости в DevSecOps-платформах требуют не только обновления версии. После патча нужна проверка секретов, runners и audit trail.
читать разбор →PhantomRaven: когда AI снижает порог входа для supply-chain malware
История с AI-assisted malware в open-source пакетах важна не из-за магии модели, а из-за экономической схемы: компромисс через зависимость превращается в доказательство для баг-баунти или давления.
читать разбор →Patch Tuesday на тысячу исправлений: почему скорость без rollback-плана опасна
Крупные обновления закрывают реальные риски, но сами могут ломать рабочие сценарии. Зрелость patch-management измеряется кольцами, метриками и откатом.
читать разбор →// новая редакционная волна
Что сейчас реально отличает инженерный security-аудит от скан-дампа
В выпуске собраны темы из практики web/API, SOC, DFIR, AI-assisted pentest и edge-hardening. Логика одна: сначала проблема, затем проверяемое доказательство, контроль и ретест.
API ROLE REPLAYSOC BUDGETDOCKER EXPOSUREAI TOOL LEDGERSESSION DFIRVPN EDGE
BOLA больше не ловится одиночным сканером: нужен multi-identity replay
Современная API-уязвимость часто выглядит как полностью легитимный GET-запрос. Чтобы отличить нормальный доступ от утечки объекта, нужны две контролируемые роли, inventory из HAR/OpenAPI и воспроизводимый differential-proof.
читать разбор →SOC без alert budget превращается в шум: detection надо мерить как продукт
Сообщество всё чаще обсуждает не количество правил, а способность команды обработать сигнал. Хорошее правило имеет owner, гипотезу, источник телеметрии, ожидаемую частоту, false-positive budget и ретест.
читать разбор →Docker может обойти UFW: почему lab/staging нельзя просто публиковать наружу
Уязвимые стенды, dev-панели и временные контейнеры часто открываются через Docker proxy раньше, чем firewall-политика успевает их закрыть. Проверять надо не только ufw status, но и реальные iptables/nftables цепочки.
читать разбор →AI-пентестер должен вести tool ledger, а не просто писать красивый отчёт
Локальные LLM-ассистенты и агентные фреймворки показали полезный паттерн: модель предлагает следующий шаг, но исполняет его только trusted adapter. В production это превращается в action catalog, policy decision и signed evidence.
читать разбор →Infostealer-инцидент заканчивается не сменой пароля, а проверкой сессий
Кража cookies, OAuth grants и refresh tokens меняет логику реагирования. Если команда сбросила пароль, но не отозвала сессии, устройства, почтовые правила и интеграции, атакующий может остаться внутри.
читать разбор →Remote access остаётся Tier-0: VPN надо проверять как identity-систему
VPN, reverse proxy и панели управления больше нельзя считать сетевой периферией. Это точка входа к админским действиям, поэтому нужны MFA, key-only access, экспозиция по allowlist, логи и быстрый cert/config drift контроль.
читать разбор →// новый разбор
Linux privilege escalation: признак vs подтверждённая уязвимость
SUID, cron, sudo misconfig — сканер находит паттерн, аудит обязан подтвердить эксплуатируемость.
Linux privilege escalation: почему сканер находит признак, а не уязвимость
SUID-бит, cron-задача от root, строка в sudoers — сканер видит паттерн и останавливается. Реальный аудит должен подтвердить, что паттерн действительно даёт эскалацию именно на этой системе.
Читать разбор ->// новый разбор
ROP и egghunter'ы: почему один mitigation почти всегда обходится
DEP, ASLR и CFG закрывают конкретные техники, а не эксплуатацию в целом — оценивать нужно их комбинацию на бинаре.
ROP-цепочки и egghunter'ы: почему один mitigation почти всегда обходится
DEP блокирует исполнение со стека — но не мешает ROP. ASLR рандомизирует адреса — но одного не-ASLR модуля достаточно, чтобы найти гаджеты.
Читать разбор ->// новый разбор
AD attack surface: чек-лист аудита по фазам атаки
Enumeration, ACL abuse, Kerberoasting, DCSync как единая цепочка, а не отдельные находки.
Active Directory attack surface: чек-лист аудита по фазам атаки
Enumeration, ACL abuse, Kerberoasting и DCSync почти никогда не встречаются в отчёте по отдельности — на практике это стадии одной цепочки от рядового пользователя до контроллера домена.
Читать разбор ->// новый разбор
Cloud IAM: разрешения читаем как граф, а не как список
Как реально выглядит privilege escalation в AWS IAM и что проверять при аудите облачных прав доступа.
AWS IAM privilege escalation: почему список политик — это ещё не аудит прав
Плоский список IAM-политик не показывает, что реально может сделать скомпрометированный принципал. Реальный риск — в графе достижимости: PassRole, AssumeRole и wildcard-политики складываются в путь до admin.
Читать разбор ->// PDF -> Virusologia
OSCP/OSED разборы: от cheat-sheet к инженерной методологии
Материалы из PDF переработаны в прикладные заметки Virusologia. Фокус: scope, evidence, дисциплина лаборатории, memory-safety, mitigations и критерии ретеста.
01 OSCP METHOD02 EVIDENCE03 WINDBG04 MEMORY SAFETY05 RETEST
OSCP Survival Guide для инженера: от шпаргалки к методологии
Cheat-sheet полезен только тогда, когда превращается в систему работы: область проверки, инвентаризация, заметки по сервисам, доказательства, ретест и аккуратный cleanup.
Читать разбор ->Windows exploit development: карта защитного анализа
Разработка эксплойтов здесь разобрана с defensive-стороны: crash triage, mitigations, compiler flags, debugger evidence и выводы для укрепления продукта.
Читать разбор ->// свежая исследовательская подборка
Что проверять в инфраструктуре сейчас
Новая волна материалов 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.
Читать разбор ->// security newsroom
Новости и аналитика
Свежая повестка кибербезопасности без перепечаток и сенсационного шума: что произошло, почему это важно и какие действия действительно снижают риск.
// текущий production security issue
Четыре точки давления: edge, recovery, parsers и AI governance
Этот выпуск собран вокруг простой логики: сначала называем операционную проблему, затем показываем контроль, evidence и ретест. Материалы связывают edge telemetry, recovery denial, parser differentials и AI-assisted vulnerability management.
EDGE RETENTIONRECOVERY DENIALPARSER DIFFAI POLICY
Edge telemetry: как пережить exploit-window до патча
VPN, routers и reverse proxies требуют long retention, config evidence, trust rotation и monitored recovery, потому что часто живут вне обычной EDR-видимости.
читать разбор →Recovery denial: backup без identity-drill не спасает
Современное ransomware-давление бьет по backup, identity и virtualization trust; recovery нужно доказывать технической проверкой, а не слайдом.
читать разбор →Parser differential: когда verify и consume видят разные данные
Authorization слабеет, когда validation и business logic парсят разные реальности. Исправление начинается с parse-once и same-node contract.
читать разбор →AI-assisted triage: модель предлагает, evidence решает
AI полезен для hypotheses и prioritization только там, где redaction, policy gates, deterministic validators и QA остаются жесткими границами.
читать разбор →// текущий инженерный выпуск
Семь контрольных точек для ускорившегося и более враждебного security-цикла
Новый выпуск связывает incident timing, восстановление identity, поведение malware, parser consistency в SSO, install-time trust, Kubernetes policy anchoring и оценку AI-агентов. Каждый разбор заканчивается evidence и критерием ретеста.
01 SOC WINDOW02 SESSION DFIR03 MALWARE GRAPH04 SAML05 NPM TRUST06 K8S POLICY07 AGENT EVAL
SOC без запаса времени: response под hand-off за секунды
Актуальные incident-данные меняют operating model: low-severity сигнал может оказаться последней дешевой точкой containment до подключения следующего оператора.
читать разбор →Украденная сессия: смена пароля не равна containment
Token, mailbox, OAuth, MFA enrollment, device trust и business actions нужно расследовать и перепроверять как один identity incident.
читать разбор →STOCKSTAY: ищите контракты между компонентами, а не только filenames
Process roles, IPC, доступ к конфигурации и secure WebSocket дают более устойчивый behavior graph, чем короткоживущий IOC-list.
читать разбор →SAML parser consistency: verify и consume должны видеть один assertion
Ключевой invariant архитектурный: signature verification и application logic должны работать с одним и тем же parsed node.
читать разбор →npm v12: safer defaults все равно требуют явного trust review
Opt-in scripts и запрет git/remote dependencies превращают каждое исключение в reviewable change с owner, evidence и clean-build retest.
читать разбор →Policy anchor: защитите admission control от удаления
Manifest-based admission закрывает bootstrap и self-protection gaps, но production-внедрение требует digest drift checks и отрепетированного recovery path.
читать разбор →AI-agent security: оценивайте весь action path
Prompt score не является assurance. Нужно вместе тестировать untrusted content, memory, policy, tool adapters, denied actions, secret egress и deterministic degradation.
читать разбор →Предыдущий current briefing
// current security briefing
Пять сигналов, которые меняют defensive-приоритеты
Этот briefing связывает актуальные сигналы из первичных источников с конкретной инженерной работой: AI-speed vulnerability discovery, инцидентами management plane, границами доверия CI, восстановлением edge и machine-readable supply-chain evidence.
01 AI VALIDATION02 SD-WAN03 ACTIONS/OIDC04 EDGE RECOVERY05 CRA EVIDENCE
AI ускоряет discovery: защите нужен более короткий proof loop
Модель может ранжировать гипотезы и показывать coverage gaps, но границей между сигналом и finding должны оставаться policy и детерминированная validation.
читать разбор →Cisco SD-WAN: риск management plane — это incident, а не только patch
Известная эксплуатация и root-level impact требуют version inventory, проверки privileged access, preservation evidence и проверяемого recovery path.
читать разбор →GitHub Actions: отделите untrusted code от release authority
OIDC, trusted publishing и read-only cache снижают риск только тогда, когда custom workflows также используют least privilege и immutable dependencies.
читать разбор →Если persistence переживает upgrade, recovery должен восстанавливать доверие
Патч удаляет уязвимый код. Clean recovery дополнительно сохраняет evidence, ротирует trust material, проверяет baseline и открывает monitoring window.
читать разбор →CRA readiness должна строиться из continuous evidence
SBOM, provenance и vulnerability feeds полезны только тогда, когда связаны с owner, решением, deadline и retest evidence.
читать разбор →Предыдущие выпуски Virusologia
// выпуск
Новый большой выпуск: perimeter drift, identity, visibility, Kubernetes, hunting, hardening и DFIR
Этот пакет материалов собран как авторская defensive knowledge issue: где у инфраструктуры ломается boundary, как не перегрузить telemetry, почему passkeys не отменяют session engineering, как измерять detection quality и зачем release trust считать частью security perimeter.
01 SHADOW API02 PASSKEYS03 VISIBILITY04 K8S POLICY
05 HUNTFLOW06 HARDENING07 ATTESTATIONS08 DFIR
Shadow API: когда HAR знает больше, чем OpenAPI
Самая неприятная API-проблема не всегда выглядит как уязвимость. Часто это просто несоответствие между документацией, релизом и реальным трафиком: старый endpoint живёт, новый не описан, а ограничения доступа различаются.
читать разбор →Passkeys не чинят сессию сами по себе
Passkeys отлично убирают часть password risk, но они не решают автоматически вопросы session fixation, recovery bypass, weak step-up и долгоживущих cookies. После WebAuthn всё равно остаётся инженерия доверия.
читать разбор →Osquery/Fleet: видимость должна быть безопасной для хоста
Visibility-инструменты ценны, пока не начинают вредить целевой машине. Osquery и Fleet хороши там, где есть query budget, ownership, интервал, label targeting и понимание цены каждой таблицы.
читать разбор →Kubernetes security: posture, admission и runtime должны говорить вместе
Cluster scan сам по себе не закрывает риск. Если posture показывает проблему, admission её не блокирует, а runtime ничего не замечает, команда получает красивый отчёт, но не получает контроль над дрейфом.
читать разбор →Threat hunting: гипотеза должна переживать смену инструментов
Когда hunting завязан на один SIEM-запрос или одну ручную заметку, он не переживает смену источника логов. Намного полезнее описывать hunt как reusable hypothesis flow: сущности, шаги, enrichment и критерий остановки.
читать разбор →Linux hardening: гайд полезен только там, где есть проверка
Даже сильный hardening-guide бесполезен, если он не превращается в проверяемое состояние. Зрелая инфраструктура не спорит, 'достаточно ли secure', а регулярно проверяет конкретные свойства системы.
читать разбор →SBOM без provenance оставляет слепую зону релиза
Компонентный состав важен, но сам по себе не отвечает на вопрос, откуда взялся артефакт и кто подтвердил его сборку. Поэтому разговор о release trust неизбежно приходит к attestations, digest pinning и verification gate.
читать разбор →Detection engineering: считайте не только правила, но и шум
Количество rule files почти ничего не говорит о зрелости detection program. Намного важнее coverage intent, false positive burn rate, скорость правки и способность превратить red-team/pentest lessons в стабильные сигналы.
читать разбор →Memory triage: первый час важнее красивой полной картины
В реальной incident-практике память часто становится не 'финальным артефактом для отчёта', а способом быстро решить, где сейчас риск: интерактивный доступ, незакрытая сессия, токен, инжектированный процесс или уже пустой след.
читать разбор →// выпуск
Практическая безопасность: API, secrets, SBOM, SOC, containers и AI policy
Свежий большой выпуск Virusologia собран вокруг одной идеи: сначала формулируем проблему, затем показываем безопасную проверку, evidence, remediation и критерий ретеста. Материалы вдохновлены открытой инженерной практикой GitHub/OWASP/SOC-сообщества, но переписаны как авторские defensive-разборы.
01 API/BOLA02 SECRETS03 SBOM04 SOC05 CONTAINERS06 AI
API/BOLA: почему две роли важнее ещё одного сканера
IDOR/BOLA редко находится красивым payload. Чаще он проявляется там, где у API есть object id, две роли, разные владельцы данных и слабая проверка на уровне объекта.
читать разбор →Secrets scanning: находка без ротации не закрывает риск
Gitleaks и TruffleHog полезны не потому, что умеют находить строки, похожие на секреты, а потому что помогают построить процесс: найти, подтвердить, отозвать, заменить и доказать, что секрет больше не работает.
читать разбор →SBOM и vulnerability triage: почему CVE без контекста шумит
Syft, Grype и Trivy помогают увидеть состав приложения, но ценность появляется только после связывания CVE с exposure, reachability, asset role и окном исправления.
читать разбор →Detection-as-code: Sigma как язык между пентестом и SOC
Хороший пентест должен оставлять после себя не только PDF, но и идеи детектирования. Sigma помогает описать сигнал один раз и затем переводить его в SIEM-запросы.
читать разбор →Container security: образ, IaC и runtime нужно смотреть вместе
Trivy-подобные проверки полезны, когда не ограничиваются CVE. Реальный риск часто живёт в Dockerfile, Kubernetes/IaC, секретах и runtime-поведении.
читать разбор →LLM security: агенту нужен policy layer, а не доверие
OWASP LLM Top 10 сделал очевидным то, что видно на практике: prompt injection, insecure plugin design и excessive agency опасны, когда модель напрямую влияет на действия системы.
читать разбор →Edge/VPN hardening: внешний периметр надо проверять как живой организм
VPN, reverse proxy, панели и SSH меняются чаще, чем кажется. Именно edge-слой первым получает сканирование, credential stuffing и попытки найти забытые админки.
читать разбор →Malware triage: хороший разбор заканчивается детектом
Разбор образца не должен заканчиваться фразой 'вредоносный'. Полезный результат - timeline, IOC, YARA/Sigma-кандидаты, что сбросить, что искать в EDR и что проверить в сети.
читать разбор →// выпуск
AI security, prompt injection и evidence-first validation
Новый выпуск о том, как безопасно использовать LLM в assisted pentesting: AI-план как гипотеза, target content как untrusted data, risk taxonomy до planner-а и отчёты, которые доказывают findings evidence-ом.
01 AI GUARD02 PROMPT INJECTION03 POLICY04 EVIDENCE05 QA06 RETEST
AI skill risk guard: почему пентест-платформе нужен предохранитель перед LLM-планом
AI-агент может быть полезным аналитиком, но если дать ему методологические playbooks без policy-gate, он начнёт смешивать разрешённую проверку, рискованные техники и недопустимые действия. Нормальная assisted-платформа должна сначала классифицировать намерение, а уже потом строить план.
читать анализ →Prompt injection в security automation: target content всегда untrusted
В пентесте модель постоянно видит HTML, JavaScript, headers, error pages, README, OpenAPI и логи. Всё это может содержать инструкции, которые выглядят как команды для агента, но на самом деле являются данными цели.
читать анализ →Evidence-first validation: почему отчёт должен доказывать, а не убеждать
Коммерческий пентест-отчёт всё чаще оценивают не по количеству находок, а по качеству доказательств: можно ли воспроизвести, понять impact, назначить владельца и провести ретест.
читать анализ →// knowledge base
Практические лаборатории: от основ до advanced security engineering
Новый самостоятельный раздел сайта собирает прикладные темы: HTTP/DNS/TLS, инвентаризация портов, secrets scanning, API security, Docker audit, SIEM, SBOM, honeypots, AI threat detection и управление ключами. Формат — объяснение, риск, ручная проверка, типичные ошибки и defensive-чеклист.
01 NETWORK02 WEB/API03 SOC04 SECRETS05 CONTAINERS06 CRYPTO
Cyber Labs: безопасный маршрут изучения кибербезопасности
Отдельный раздел с уровнями Foundations, Beginner, Intermediate и Advanced. Каждая тема написана как практический defensive-разбор без вредоносных инструкций.
открыть раздел →кодовые примеры →API, secrets, containers и SBOM: где чаще всего появляется реальный риск
Инженерные лаборатории помогают перейти от абстрактной теории к проверкам, которые полезны командам разработки и эксплуатации.
intermediate track →Honeypots, AI detection и HSM: сложные темы без магического мышления
Advanced-блок объясняет архитектурные решения через threat model, evidence, ограничения и реальные ошибки внедрения.
advanced track →// выпуск
Defensive-повестка: privilege escalation, AD attack paths, KEV и supply chain
Новый выпуск собран из приложенных материалов и текущей security-повестки. Я намеренно перевёл технические заметки в защитный формат: без паролей, команд обхода защит и эксплуатационных последовательностей, но с понятными выводами для hardening, SOC и SecMon Pro.
01 LINUX02 ACTIVE DIRECTORY03 KEV04 SUPPLY CHAIN05 SECMON06 DEFENSE
Linux privilege escalation: как превратить чеклист атакующего в план защиты
Из PDF по Linux privilege escalation вынесена безопасная defensive-версия: SUID/SGID, sudoers, cron, сервисы от root, секреты и baseline-подход для регулярного аудита.
читать анализ →AD attack paths: что полезного защитнику в заметках CRTP
Сырые команды, пароли и обходы защит не опубликованы. Вместо этого — безопасная карта рисков AD: delegation, GPO, ADCS, сервисные аккаунты, CI/CD и локальные админы.
читать анализ →KEV-first triage: почему самый высокий CVSS не всегда первый
Очередь исправлений должна начинаться с активной эксплуатации, внешней доступности и роли актива для бизнеса. CVSS важен, но сам по себе не строит план реагирования.
читать анализ →Supply chain: реальный риск живёт в CI/CD, токенах и lifecycle scripts
Lockfile и SCA уже недостаточны. Нужно смотреть, что видит runner, где лежат publish-токены, как запускаются lifecycle scripts и как подтверждается provenance.
читать анализ →// выпуск
Новая граница риска проходит через edge, supply chain и AI-агентов
В этом выпуске: утечка учётных данных Fortinet, активно эксплуатируемая уязвимость Splunk, RCE через страницу для AI-агента, компрометация npm-цепочки и новое поколение автоматизированной валидации.
01 EDGE02 KEV03 AI SECURITY04 SUPPLY CHAIN05 MALWARE06 VALIDATION
FortiBleed: почему одной смены пароля после утечки недостаточно
CISA сообщает о скомпрометированных учётных данных примерно 74 000 интернет-доступных устройств Fortinet. Разбираем правильный порядок локализации: завершение сессий, ротация секретов, проверка конфигурации и поиск следов доступа.
читать анализ →AutoJack: одна веб-страница как путь к RCE на машине AI-агента
Когда браузерный агент видит untrusted content и одновременно доверяет localhost, привычная граница безопасности исчезает. Разбираем цепочку и архитектурные меры защиты.
читать анализ →Mastra npm: postinstall превратил зависимость в канал компрометации
Скрытая нагрузка затронула более 140 проектов. Главный урок кампании — lockfile и сканер зависимостей не заменяют контроль publish-токенов, lifecycle scripts и поведения сборки.
читать анализ →Crypto Clipper: Tor, подмена кошельков и червеобразное распространение
Кампания совмещает кражу транзакций с устойчивым доступом. Это уже не одиночный clipper, а компактная платформа для развития атаки.
читать анализ →CVE-2026-20253: Splunk попал в каталог активно эксплуатируемых уязвимостей
Missing authentication for critical function — особенно опасный класс для систем, где хранятся журналы, расследования и данные мониторинга.
читать анализ →Vulnerability harness: как автоматизация перестаёт генерировать шум
Cloudflare описала многоступенчатую систему поиска и проверки уязвимостей. Самая ценная часть — не LLM, а управление состоянием, adversarial review и отсечение ложных срабатываний.
читать анализ →// archive
Практические заметки
Предыдущие материалы сохранены без изменений.
Пентест больше не продается как "нашли 50 дыр"
Клиент покупает не список страшных слов, а снижение риска. Хороший отчет сегодня должен показывать, что реально достижимо из интернета, какие цепочки атаки правдоподобны, кто отвечает за исправление и как будет выглядеть ретест.
SecMon ProAI в пентесте: усилитель аналитика, а не автопилот
Модель полезна там, где человеку скучно и дорого: сжать evidence, сгруппировать находки, объяснить бизнес-эффект, подготовить письмо разработчикам. Но право запускать опасные проверки должно оставаться у человека и только в подтвержденном scope.
readinessEdge-first hardening
VPN, SSH, reverse proxy, панели управления, GitLab, почтовые шлюзы и админки мониторинга нужно считать главным фронтом. Там меньше пользователей, зато больше привилегий, и ошибка конфигурации часто превращается в прямой вход в сеть.
сводкаПочему KEV важнее голого CVSS
CVSS показывает потенциальную тяжесть, но не отвечает на вопрос "что ломают прямо сейчас". Поэтому нормальная очередь патчей начинается с известных эксплуатаций, внешней доступности и критичности актива для бизнеса.
источникSupply chain: тихая зона, где рождаются громкие инциденты
Зависимости, контейнеры, CI/CD, токены и release scripts стали частью attack surface. Если их не описывать в отчете, пентест получается красивым, но неполным: веб-форма защищена, а деплой-цепочка все еще доверяет всему подряд.
обсужденияMalware triage для бизнеса
Разбор вредоносного ПО должен отвечать не только "как оно работает", но и "как быстро понять, что это было у нас". Поэтому нужны IOC, timeline, сетевые следы, идеи Sigma/YARA и понятные действия для SOC.
Virus LabРусскоязычная безопасность взрослеет
В RU-сообществе все больше практики: как закрыть SSH, как читать журналы, как не потерять доступ после hardening, как объяснить владельцу сайта, что "просто поставить сканер" недостаточно.
ХабрОтчет, который хочется исправлять
Я люблю отчеты, где finding сразу превращается в задачу: риск, доказательство, affected asset, владелец, SLA, критерий ретеста. Такой документ не лежит мертвым PDF, а двигает команду к исправлению.
reportsContinuous validation вместо ежегодного ритуала
Один пентест в год хорош только для галочки. Реальная защита живет в цикле: обнаружили, приоритизировали, исправили, перепроверили, сохранили evidence и снова посмотрели на внешний периметр.
платформа// updated
Отдельные потоки: SOC, malware/DFIR и web/API
Вместо одной длинной ленты материалы теперь собираются ещё и в узкие направления. Это удобнее для тех, кто хочет читать сайт как рабочую базу знаний по своей зоне ответственности.
SOC Research
Отдельный исследовательский поток о том, как строить detection program без самообмана: telemetry contracts, Sigma validation, query budgets, hunt-flow design, KPI шума и нормальная передача lessons learned из пентеста и DFIR обратно в SOC.
Открыть поток →Malware & DFIR
Поток для controlled malware-analysis и incident response без романтизации. Здесь главное не 'поймать красивое семейство', а быстро понять active risk, собрать пригодное evidence, сбросить доверие там, где нужно, и передать SOC детектируемые артефакты.
Открыть поток →Web/API Pentest
Вертикаль про реальный web/API-пентест, где важны не только surface и payload, но и authenticated coverage, role/state matrix, lifecycle объекта, session trust, evidence packs и честные coverage gaps. Это уже не сканер, а проверяемая методология.
Открыть поток →