AppLocker против CryptoLocker: whitelist-модель в реальных условиях

Неделю назад мы описали первый инцидент с CryptoLocker у одного из клиентов. На этой неделе расскажем что сделали дальше - потому что «установить антивирус» и «провести беседу с сотрудниками» явно не казалось достаточным ответом на шифровальщик, который лёг на несколько сотен документов за сорок минут.

Где живёт CryptoLocker

Механика распространения оказалась довольно прямолинейной, и это одновременно успокаивало и злило. Вредоносный исполняемый файл попадает на машину через письмо или заражённый документ, сохраняется в %AppData% или %Temp% - директории, куда у обычного пользователя есть право записи без всяких UAC-запросов - и оттуда запускается. Никаких прав администратора, никакого повышения привилегий. Просто запись файла в пользовательскую папку и его исполнение.

Первая реакция - «почему вообще можно запускать что-то из %AppData%?». Хороший вопрос. Ответ: потому что по умолчанию Windows это разрешает, и многие легитимные программы этим пользуются. Но то, что это исторически сложилось именно так, не значит, что с этим нельзя ничего сделать.

SRP vs AppLocker

У Microsoft есть два инструмента для ограничения запуска программ: Software Restriction Policies, которые работают начиная с Windows XP/2003, и AppLocker, появившийся в Windows 7/2008 R2. Мы смотрели на оба.

SRP старше, проще в настройке и работает на более широком спектре систем. AppLocker требует Windows 7 Enterprise или Ultimate на клиентах и 2008 R2 на серверах - у нашего клиента инфраструктура как раз такая, так что выбор был очевиден в пользу AppLocker. Плюс AppLocker даёт более гибкую модель правил: можно разрешать по имени издателя (подпись), по пути, по хешу. И главное - ведёт журнал всех заблокированных попыток, что для нас не менее важно, чем само блокирование.

Как строили whitelist-модель

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

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

• Системные бинарники из %SystemRoot% и %ProgramFiles% - разрешены по умолчанию, там всё подписано и относительно понятно.
• Корпоративный софт - отдельные правила по пути или по подписи издателя, в зависимости от того, как установлено.
• Пользовательские директории - запрет на запуск .exe, .com, .bat, .cmd, .vbs, .js из %AppData%, %LocalAppData%, %Temp% и %UserProfile%\Downloads. Без исключений.

Именно последний пункт и является защитой от CryptoLocker-подобной механики. Файл попадёт в %AppData% - но не запустится. AppLocker его заблокирует и запишет событие в журнал.

Что сломалось при включении

Честно - несколько вещей.

Первое - обновляторы. Некоторые программы хранят свои апдейтеры в %AppData% и запускают их оттуда. Dropbox, например, делал именно так. Пришлось делать исключение по подписи издателя - не по пути, чтобы не открыть дыру.

Второе - скрипты. Несколько рабочих скриптов в VBScript лежали в домашних директориях пользователей. Часть перенесли на сетевой диск с правилом разрешения по UNC-пути, часть переписали в PowerShell и выложили в GPO.

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

Всё это заняло ещё примерно неделю работы после первоначального включения. Не быстро, но терпимо.

Что получили в итоге

С момента включения политики в production-режиме прошло около двух недель. Шифровальщиков - ноль. Заблокированных попыток запустить что-то из %Temp% в логах AppLocker - несколько штук, все оказались безобидными вещами типа установщиков, которые пользователи скачивали сами. Их перехватили, разобрались, куда перенести установку.

Мониторинг в рамках managed-обслуживания теперь включает просмотр логов AppLocker: если что-то блокируется чаще обычного или из нетипичного места - это повод разобраться. Пока это скорее источник данных об инфраструктуре, чем источник тревог.

Оговорка

AppLocker не серебряная пуля. Атака через легитимный процесс - через Word с макросом, через браузер, через PowerShell - может обойти запрет на запуск .exe из %AppData%. Это отдельный разговор про ограничение скриптовых движков и контроль PowerShell. Но CryptoLocker в том виде, в котором мы его видели, этот барьер не преодолевает - и уже это неплохой результат за несколько дней настройки.

Кроме того, SRP остаётся вариантом для тех, у кого на клиентах Windows 7 Professional или Home - там AppLocker не работает, а SRP с теми же правилами по путям даёт схожий эффект, пусть и без нормального журналирования. Для разнородного парка это важно учитывать.