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

ESXi, iDRAC/iLO, IPMI, гипервизоры, СХД, коммутаторы, UPS — всё доступно из обычной корпоративной сети.

Пока ничего не произошло, это удобно.

А теперь представим, что злоумышленник получил доступ к одному из серверов и начал двигаться по сети. Если с этого же сегмента доступны интерфейсы управления гипервизорами, СХД и железом, то взлом одного сервера постепенно может превратиться во взлом всей инфраструктуры.

Поэтому интерфейсы управления лучше вообще вынести в отдельный сетевой контур.… Читать далее…

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

Если исключение нужно только отдельному серверу или приложению, оно должно действовать только там. В Kaspersky Security Center это можно реализовать через профиль политики и теги.

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

Антивирус установлен.

Резервные копии выполняются.

Уязвимости сканируются.

События поступают в SIEM.

Доступы согласованы.

В отчёте везде зелёный цвет.

А потом начинается атака — и выясняется:

антивирус годами работал в режиме аудита;

бэкапы никто не восстанавливал;

критические события утонули среди тысяч ложных срабатываний;

учётная запись уволенного администратора всё ещё активна;

а план реагирования существует только в файле, который никто не открывал.

Средства защиты могут быть куплены, установлены и даже сертифицированы.

Но пока их эффективность не проверили атакой, сбоем и реальным восстановлением — это не безопасность.

Это вера.

Самая опасная ложь в ИБ — зелёная галочка напротив контроля, который никогда не проверяли.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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, не запуском сканера и не красивым скриншотом. Пентест заканчивается отчётом, по которому заказчик должен понять:

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

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

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

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

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