Они начинаются раньше.

Когда ИБ уже нашла проблему.

Когда уже написала письмо.

Когда уже предупредила о риске.

Когда получила ответ:

— Сейчас не до этого.
— Система критичная, трогать нельзя.
— Вернёмся в следующем квартале.
— Риск принимаем.

А потом происходит атака.

И внезапно все начинают спрашивать:

— Как это допустили?

Но инцидент допустили не в тот день, когда злоумышленник вошёл в сеть.

Его допустили в тот день, когда известный риск решили оставить жить.

Самая страшная уязвимость — не та, о которой никто не знает.

Самая страшная — та, о которой знают все, но исправлять её некому.

Можно проводить учения, рассылать памятки и ежегодно обучать персонал.

Но в организации из тысячи человек всегда найдётся тот, кто откроет письмо, введёт пароль или запустит вложение.

И это нормально.

Ненормально другое: когда одна ошибка обычного сотрудника позволяет злоумышленнику пройти путь от почты до контроллера домена, резервных копий и всей инфраструктуры.

Фишинг нельзя победить обучением.

Можно лишь построить инфраструктуру, в которой один клик не становится приговором для всего предприятия.

Если безопасность держится на том, что никто никогда не ошибётся, — безопасности уже нет.

Шифровальщик хотя бы хочет денег.

Поэтому он оставляет записку, требует выкуп и иногда даже предоставляет расшифровщик.

Но что делать, если злоумышленнику не нужны деньги?

11 марта 2026 года кибератака нарушила работу Stryker — одного из крупнейших производителей медицинского оборудования. Пострадала глобальная Microsoft-инфраструктура компании, были нарушены обработка заказов, производство и поставки. Сотрудники сообщали об удалённом стирании корпоративных ноутбуков и телефонов. При этом компания заявила, что не обнаружила признаков шифровальщика.

Никаких переговоров.

Никакого выкупа.

Никакого ключа расшифрования.

Только уничтоженная инфраструктура.

Большинство организаций проверяют, есть ли у них резервные копии.

Но почти никто не проверяет, сможет ли предприятие восстановиться, если одновременно исчезнут Active Directory, почта, MDM, административные компьютеры и сама инструкция по восстановлению.… Читать далее…

Большинство крупных атак развиваются не потому, что злоумышленник постоянно находит новые уязвимости.

Они развиваются потому, что инфраструктура уже доверяет скомпрометированной системе.

Пример — атака группировки DragonForce через SimpleHelp в мае 2025 года.

Злоумышленники скомпрометировали RMM-систему IT-провайдера, через которую удалённо администрировались компьютеры его клиентов. После этого им не пришлось взламывать каждую организацию отдельно.

Через легитимную инфраструктуру SimpleHelp они получили сведения о клиентских сетях, развернули вредоносное ПО и запустили шифровальщик сразу в нескольких организациях. Часть клиентов столкнулась с шифрованием систем и кражей данных.

Самое опасное здесь то, что вредоносные действия выполнялись через систему, которой компьютеры уже доверяли и от которой привыкли принимать команды.… Читать далее…

Во многих организациях Active Directory воспринимается как последний рубеж обороны.

Логика простая: если защитили Domain Admin, значит защитили всё предприятие.

На практике это опасная иллюзия.

Если злоумышленник уже закрепился во внутренней сети, получил доступ к рабочим станциям, нашёл сервисные учётные записи и начал перемещаться между серверами, компрометация домена часто становится лишь вопросом времени.

Поэтому главный вопрос должен звучать не так:

Как сделать так, чтобы Domain Admin никогда не взломали?

А так:

Что останется у организации, если Domain Admin уже скомпрометирован?

Domain Admin не должен означать доступ ко всему

Администратор домена нужен для управления Active Directory.… Читать далее…

Отдельная головная боль любой инфраструктуры — сервисные учётные записи.

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

У каждого самостоятельного сервиса должна быть собственная учётная запись. Это позволяет выдать только необходимые права, нормально контролировать её действия и ограничить последствия компрометации.

Но это не означает, что для каждой службы нужно вручную менять пароль.

Если сервису нужен доступ к ресурсам домена, в Windows-инфраструктуре лучше использовать gMSA.… Читать далее…

Пентест заканчивается не получением Domain Admin, не запуском сканера и не красивым скриншотом. Пентест заканчивается отчётом, по которому заказчик должен понять:

• что именно проверили;
• что удалось взломать;
• почему это стало возможным;
• к каким последствиям может привести атака;
• что и в каком порядке необходимо исправлять.

Можно качественно провести техническую часть и полностью испортить результат плохим отчётом. Например, оставить в документе комментарии вроде «добавить скрин», не указать охват инфраструктуры, смешать все площадки в один список и приложить скриншоты без дат и контекста.

Именно такие проблемы превращают результат пентеста в недоказуемый набор утверждений.

В первую очередь — соответствие техническому заданию

Отчёт как минимум должен подтверждать выполнение ТЗ.… Читать далее…

Одна из постоянных проблем информационной безопасности — учётные записи уволившихся сотрудников.

Сотрудник может не работать в организации уже несколько месяцев, а его учётная запись в домене, VPN или информационной системе всё ещё остаётся активной. Иногда кадровая служба не передала информацию, иногда администратор забыл заблокировать доступ, а иногда вообще непонятно, кто за это отвечает.

Процесс увольнения должен запускать автоматическое отключение доступов. Источником события должна быть кадровая система, а не письмо или устная просьба администратору.

При увольнении необходимо не просто заблокировать учётную запись в Active Directory, но и закрыть VPN, почту, SSO, облачные сервисы, сертификаты, токены, мобильные сессии и доступ к отдельным информационным системам.… Читать далее…

Её ломают исключения.

Антивирус есть — но на этом сервере отключили.

MFA есть — но для этой учётной записи неудобно.

Сегментация есть — но подрядчику открыли доступ «временно».

Пароли меняются — кроме сервисных.

Резервные копии изолированы — но сервер бэкапов всё-таки в домене.

У каждого исключения всегда есть нормальное объяснение.

А потом злоумышленник собирает все эти «нормальные объяснения» в один маршрут до контроллера домена.

ИБ строит защиту по правилам.

А атакующий идёт по исключениям.

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

У вас инструкция по обходу собственной защиты.

Из моего опыта пентестов и общения с пентестерами: если атакующий проник во внутреннюю сеть, закрепился и получил локальные административные права, путь до полной компрометации Active Directory часто оказывается неожиданно коротким.

Причём ему необязательно узнать пароль администратора предприятия. Хеша пароля, Kerberos-билета, прав репликации или другой привилегированной учётной записи может быть вполне достаточно.

И вот здесь начинается главный вопрос: что произойдёт после компрометации домена?

Если все серверы находятся в одном домене, администраторы используют одни и те же учётные записи, а сервер резервного копирования доступен из общей сети, то компрометация AD быстро превращается в компрометацию всей организации.… Читать далее…