«Сетевой диск — это не просто папка, это точка синхронизации для атаки. Запрет исполнения на нём — не просто галочка в политике, а перекрытие кислорода для целого класса угроз, которые обходят периметр и антивирусы.»
Почему сетевые диски становятся точкой входа для атак
Сетевое хранилище — это общий ресурс, но с точки зрения безопасности он работает как усилитель. Одна компрометация на уровне файлового сервера или даже одной рабочей станции с доступом к нему приводит не к локальному инциденту, а к синхронному заражению десятков узлов. Механизм прост: вредоносный код, запущенный с сетевого пути, выполняется в контексте пользователя, который имеет доступ к этому же ресурсу с других компьютеров.
Атакующие эксплуатируют эту архитектурную особенность несколькими способами:
- Подмена документов. Файлы с двойным расширением (например,
Договор.docx.exe) или скрипты, маскирующиеся под документы (Инструкция.bat), размещаются в часто посещаемых общих папках. Windows по умолчанию скрывает известные расширения, делая подмену визуально незаметной. - Использование доверенных путей. Такие системные сетевые папки, как NETLOGON и SYSVOL в домене Active Directory, по умолчанию доверяются системой и пользователями. Размещение в них вредоносного скрипта гарантирует его выполнение на всех машинах в домене при следующем входе или обновлении политик.
- Эксплуатация сетевых протоколов. Некорректно настроенные серверы WebDAV или устаревшие версии SMB могут позволить выполнить код удалённо без необходимости прямого запуска файла пользователем.
Традиционные средства защиты, такие как антивирус на конечных точках, часто бессильны против легитимно выглядящих скриптов, запущенных из доверенной сетевой локации с правами самого пользователя.
Как настроить запрет исполнения на сетевых ресурсах через AppLocker
AppLocker — это механизм контроля приложений в Windows, который позволяет задавать политики выполнения на основе путей, подписей издателей или хэшей. Для блокировки запуска с сетевых дисков используется подход на основе путей.
Основная логика: разрешить выполнение только из строго определённых локальных системных каталогов и явно запретить всё, что находится на сетевых путях. Правила применяются сверху вниз, и первое совпавшее правило определяет судьбу файла.
| Тип правила | Путь или условие | Действие | Назначение |
|---|---|---|---|
| Разрешающие правила (создаются первыми) | %WINDIR%*%PROGRAMFILES%*%PROGRAMFILES(X86)%* |
Разрешить | Позволить работать операционной системе и установленным в стандартные пути приложениям. |
| Запрещающие правила для сетевых путей | \** (или конкретные имена серверов)*NETLOGON**SYSVOL* |
Запретить | Блокировать запуск любых исполняемых файлов с сетевых дисков и из критических доменных папок. |
| Запрет по расширениям (опционально) | Для скриптов: .ps1, .bat, .cmd, .vbs, .jsДля исполняемых файлов: .exe, .scr, .pif, .com |
Запретить | Дополнительный контроль для специфических типов файлов, где это необходимо. |
Ключевой момент — порядок. Если сначала создать глобальный запрет на \**, то даже правило, разрешающее %WINDIR%*, не сработает, так как путь к системным файлам также технически может быть представлен как UNC-путь. Поэтому разрешения для локальных путей всегда должны быть выше в списке приоритетов.
Блокировка командной строки и PowerShell
Запрет запуска файлов с сетевых дисков бесполезен, если атакующий может запустить интерактивный интерпретатор и выполнить код напрямую из памяти или командной строки. Ограничение доступа к самим интерпретаторам создаёт дополнительный барьер.
- Для cmd.exe: Используется групповая политика «Конфигурация компьютера» → «Административные шаблоны» → «Система» → «Запретить доступ к командной строке». Включение этой политики также блокирует обработку файлов .bat и .cmd.
- Для PowerShell: Через политику «Конфигурация пользователя» → «Административные шаблоны» → «Система» → «Не запускать указанные приложения Windows». В список добавляются
powershell.exe,powershell_ise.exe, а также, при необходимости,pwsh.exe(PowerShell Core).
Для администраторов и ИТ-специалистов, которым эти инструменты нужны для работы, создаются исключения. Это можно сделать через отдельную групповую политику, которая применяется только к группе безопасности «ИТ-Администраторы» с использованием фильтров безопасности WMI или прямого назначения GPO на OU.
Защита от изменения политик через реестр
Стандартный метод обхода программных ограничений — их отключение через реестр. Ключи политик AppLocker и ограничений на запуск приложений хранятся в реестре, и их изменение может свести настройки к нулю.
- Блокировка regedit.exe: Через политику «Конфигурация пользователя» → «Административные шаблоны» → «Система» → «Запретить доступ к средствам редактирования реестра».
- Блокировка reg.exe: Этот консольный инструмент также позволяет вносить изменения. Его нужно добавить в тот же список «Не запускать указанные приложения Windows», что и PowerShell.
Перед блокировкой необходимо провести аудит: некоторые легитимные корпоративные приложения (например, установщики или системы управления) могут использовать reg.exe для настройки параметров. Их пути выполнения нужно внести в исключения до глобального запрета.
Реальный инцидент: как вредоносное ПО уничтожило данные за 17 минут
В одной из производственных компаний общий сетевой накопитель использовался как центральное хранилище для чертежей, спецификаций и отчётов. Доступ был у всех 120 сотрудников. Через фишинговое письмо в отдел закупок был доставлен файл Счет_на_оплату_№784321.pdf.exe.
После его запуска обычным пользователем произошла следующая последовательность событий:
- Вредоносное ПО, не требуя прав администратора, получило доступ ко всем сетевым дискам, отображённым на скомпрометированной рабочей станции.
- Было инициировано быстрое сканирование доступных сетевых ресурсов на предмет файлов определённых расширений (чертежи, документы, базы данных).
- Запустился процесс шифрования данных. Использовались многопоточные алгоритмы, что позволило обработать 47 ТБ информации за 17 минут.
- Сразу после шифрования, используя встроенную утилиту
vssadmin.exe, вредонос удалил все теневые копии Volume Shadow Copy на атакованных сетевых дисках, чтобы исключить простое восстановление.
Итог: полная остановка производственного цикла на 5 дней, восстановление данных из резервных копий с потерей информации за последние 12 часов, прямые и косвенные убытки составили несколько миллионов рублей.
Анализ показал, что если бы была активна политика AppLocker, запрещающая выполнение файлов с расширением .exe с сетевых путей (\fileserver*), то вредоносный код просто не был бы запущен. Антивирус на конечной точке его пропустил, так как файл был новым и не имел известной сигнатуры на момент атаки.
Пошаговый план внедрения защиты
Резкое внедрение таких ограничений может парализовать работу. Необходим последовательный и тестовый подход.
- Аудит и инвентаризация. Определите все используемые сетевые пути (UNC), общие папки. Выясните, запускаются ли с них какие-либо легитимные приложения (устаревшее ПО, портативные утилиты).
- Создание базовых разрешающих правил. В AppLocker создайте правила, разрешающие выполнение из
%WINDIR%*,%PROGRAMFILES%*. Это основа. - Создание и тестирование запрещающих правил в режиме аудита. Настройте правила запрета для сетевых путей (
\**) и, при необходимости, для опасных расширений. Установите для них режим «Аудит». В этом режиме AppLocker не блокирует, а только записывает события в журнал Windows (Event Viewer). Тестовый период должен составлять не менее двух рабочих недель, чтобы охватить все бизнес-процессы. - Анализ логов и корректировка. Проанализируйте события AppLocker (ID 8003 для блокировки, 8004 для разрешения). Если в логах появляются попытки запуска легитимных приложений с сетевых путей, вам нужно либо переместить эти приложения в разрешённые локальные пути, либо создать для них исключения — правила разрешения на основе издателя или хэша, которые будут иметь более высокий приоритет, чем глобальный запрет.
- Принудительное применение. Только после того, как в режиме аудита не останется легитимных срабатываний, переведите политики AppLocker в режим «Принудительно». Начните с пилотной группы пользователей или отдела.
- Параллельная настройка дополнительных ограничений. После стабилизации работы AppLocker можно приступать к тонкой настройке ограничений на PowerShell, командную строку и редактор реестра, также начиная с режима аудита или пилотных групп.
Этот метод позволяет построить эффективную защиту от выполнения кода с сетевых ресурсов, не нарушая рабочие процессы и минимизируриску ложных срабатываний.