Если разложить типичный сценарий шифровальщика, конфигурации всплывают на каждом шаге.
↖️ Разведка и планирование
Избыточно доступные извне порты и сервисы, некорректные ограничения доступа к служебным директориям веб‑сервера или настройки параметров его ответов позволяют более тщательно планировать атаки.
↖️ Начальный доступ
Открытые наружу RDP, VPN без нормальной аутентификации, неограниченный доступ к панелям администрирования. Часто это не уязвимость в коде, а "так удобно было настроить".
↖️ Закрепление
Автозагрузка, службы, планировщик задач. Где то нет контроля целостности, где то никто не смотрит на новые сервисы, где то можно поднять что угодно от имени системного аккаунта.
↖️ Перемещение по сети
Избыточные права, общие учетные записи, отсутствие сегментации, SMB и прочие радости, открытые куда не надо. Конфиги сетевых устройств и хостов тут играют не меньшую роль, чем сами протоколы.
↖️ Сбор данных и уничтожение резервных копий
Доступ к бэкапам из тех же учеток, что и к бою, отсутствие разделения ролей, хранилища резервов, стоящие в той же сети, что и прод.
↖️ Шифрование и вынос
Конфигурации, которые позволяют шифровальщику быстро видеть все сетевые ресурсы, подключать диски, писать логи куда угодно, не вызывая алертов.
Если смотреть через эту призму, становится ясно, что "минимально приличный" харденинг, особенно по сетевым сервисам и настройкам доступа, сильно режет возможности злоумышленника. Не отменяет угрозы вообще, но ломает сценарий.
Отсюда логичный вопрос: если ресурсов мало, что хотя бы проверить в первую очередь, чтобы срезать львиную долю риска.