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

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

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

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 быстро превращается в компрометацию всей организации.… Читать далее…

В 2024 году Akamai зафиксировала реальную эксплуатацию IP-камер AVTECH AVM1203.

Через уязвимость CVE-2024-7029 злоумышленники выполняли команды на камере, загружали вредоносный код и заражали устройство вариантом ботнета Mirai. После запуска камера подключалась к другим устройствам по Telnet и пыталась распространять заражение дальше.

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

Поэтому камеры и видеорегистраторы нельзя держать в одной сети с компьютерами и серверами.

Для видеонаблюдения нужен отдельный VLAN. Камерам разрешается обращаться только к видеорегистратору. Доступ к управлению — только из административного сегмента.… Читать далее…

Во время недавнего пентеста специалисты Sprocket Security нашли Canon imageRUNNER с открытым VNC без пароля.

Через экран управления они изменили адрес FTP-сервера и запустили проверку подключения. МФУ отправило на сервер пентестеров сохранённые логин и пароль доменной учётной записи.

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

Это не единичный случай. Rapid7 изучила результаты 136 пентестов: в 97 случаях специалисты получили административный доступ к МФУ, а в 31 успешно забрали учётные данные через pass-back-атаку и получили доступ к Active Directory.… Читать далее…