Как защитить Windows: системный подход

В прошлой статье мы провели анализ подозрительного файла и даже выявили некоторые паттерны, при помощи которых можно усилить систему защиты информации. В этой статье мы рассмотрим два важных вопроса:

• Каким образом можно структурировать меры защиты для более эффективного внедрения?
• Как настроить выбранные меры защиты?

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

Теперь рассмотрим исходные данные. Файл прилетает по почте пользователю со следующими характеристиками:

• ОС Windows 7 (в реальности это было именно так)
• Антивирус или отсутствует (печально, но факт), или его влияние незначительно.
• Сетевые механизмы безопасности у пользователя также не настроены.

Отметим, что такая конфигурация не редкость в некоторых компаниях, поэтому её мы будем использовать на практике для тестирования. Какие меры защиты мы выбрали ранее:

• Обязательно установить обновления для защиты от уязвимости  CVE-2017-0199, так как файл использует эксплойт для данной уязвимости при реализации атаки. 
• Запрет запуска ps1-файлов на стороне пользователя средствами групповой политики.
• Запрет запуска объекта с хэшем 5cf04fda03eb24218ea06356cbb76a1581ebdf20121255832c614937378108eb, это файл SystemHD.exe. Запрет можно сделать средствами групповой политики (или applocker)

Кроме того, стоит обратить внимание на определённые возможности антивируса:

• Планово сканировать каталог C:\Users\%USERNAME%\AppData\Local.
• Запускать все подозрительные файлы в «песочнице» — эту технологию поддерживают некоторые антивирусы.
• Сканирование почтовых файлов. Как — зависит от антивируса.
• Запретить доступ к следующим URL: office-archive-input.com, paste.ee, pastecode.xyz.

Также учтём два важных фактора.

Вредоносное ПО, которое мы рассматривали, является только средством доставки для более мощных по воздействиям файлов. Поэтому атаку с использованием подобных средств проще всего заблокировать на начальном этапе, чем бороться с последствием после запуска эксплойта.

Если не удастся защитить систему и эксплойт выполнится, то надо не дать ему выполнить максимально разрушительный сценарий. Например, использовать  HIPS (host intrusion prevention system) для ограничения действий пользователей.

При желании можно выбрать довольно много мер защиты, но лучше их систематизировать. Для этого можно использовать концепцию kill chain. Согласно ей, можно выделить некие условные «фазы» реализации условной атаки, на каждой из которых злоумышленником будут выполнены определённые действия. Для большей реалистичности можно использовать глобальную базу знаний, в которую сведены все известные тактики и техники, используемые для практической реализации некоторых атак. Для каждого начального воздействия (англ. «initial access») в данной схеме предусмотрен некий общий сценарий развития атаки.

В предыдущем случае мы выявили следующий сценарий атаки:

Для планирования защиты можно использовать ряд решений, которые условно можно сгруппировать по категориям:

• Detect. Чем будем «ловить» потенциально опасное воздействие. Как правило, все меры в рамках данного этапа сводятся к выявлению неких признаков, которые могут быть использованы для идентификации «подозрительной» активности, связанной с той или иной атакой.
• Deny. Чем будем «запрещать» потенциально опасное воздействие. Меры, используемые на данном этапе, позволят предотвратить получение той информации, которая позволит злоумышленнику реализовать атаку.
• Disrupt. Меры, которые позволят «сорвать» атаку. 
• Degrade. Как ослабить последствия от реализации атаки.  
• Deceive. Как «ввести в заблуждение» злоумышленника. Меры можно использовать для того, чтобы у злоумышленника создалось впечатление о том, что атака не может быть реализована.

Рассмотрим, как наложить эти стратегии на нашу цепочку (при желании мер можно указать значительно больше):

Чем полезен такой подход к планированию механизмов защиты?

• Таблица выше помогает понять, какими мерами защиты мы можем оперировать на практике. 
• Мы всегда сможем понять, насколько эффективно остановится атака. Типичной ошибкой является выстраивание защиты только на этапе Execution, игнорируя остальные этапы атаки.
• Возможно, нам придётся что-то добавить в качестве мер или убрать лишние. В этом случае таблица пригодится для выбора места мер в системе защиты — становится понятно где стоит усилить защиту а где набор мер является избыточным. 

В качестве примера практических мер рассмотрим настройку политики ограниченного использования программ. Для примера мы используем локальную политику на ПК с ОС Windows 7, но указанные меры можно использовать и в Windows более поздних версий.

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

Во втором случае мы разрешаем всё и настраиваем список того, что надо запретить к запуску. При этом надо использовать уровень Unrestricted как уровень по умолчанию.

Мы будем придерживаться второго подхода (разрешено всё, что явно не запрещено). Для примера настроим запрет запуска файлов “*.exe” из каталога AppData:

Тут надо отметить, что переменная %appdata% ссылается на каталог appdata\roaming, это надо учитывать:

После настройки групповой политики её надо примерить. Для этого можно использовать команду gpupdate /force.

Теперь после попытки запуска exe-файл будет заблокирован

Далее заблокируем запуск скриптов powershell. Тут есть два варианта. Если использовать политику whitelist (уровень «disallowed» как уровень по умолчанию) то можно просто добавить в список расширений «ps1».

При этом запуск объектов с расширением «ps1» будет заблокирован как часть политики по умолчанию. Таким образом, если использовать уровень «Disallowed» по умолчанию, то необходимо:

• Задать список разрешённых для запуска сущностей.
• Задать список расширений, которые явно будут заблокированы.

Напомню, что мы используем политику «blacklist» (уровень «unrestricted» как уровень по умолчанию), поэтому если в системе не используются сценарии powershell, то проще всего заблокировать использование именно powershell.exe. Сделать это проще всего по хешу — плюс в том, что файл не запустится, даже если его переименовать.

Для этого добавим новое правило по хешу. Выберем файл, хеш которого вычислит система (для powershell.exe это C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe):

В итоге получим такое правило:

Теперь если запустить файл «ps1», то политика его заблокирует т. к. запуск powershell.exe, который запускает такие скрипты запрещён.

Второй вариант — использовать список расширений для блокирования объектов из определённого каталога. Для этого надо добавить правило для каталога (к примеру, appdata) следующего вида:

Далее для данного каталога будет применён список расширений, который мы указали ранее, и запуск файлов с настроенными расширениями будет запрещён для каталога appdata:

Отметим, что политика содержит довольно большой объём расширений для блокировки, который при желании также можно дополнить.

В целом, построение системы защиты с использованием SRP требует серьёзного планирования. Как минимум надо ответить на следующие вопросы:

• Какова будет логика работы (белый или чёрный список)?
• Каким образом будут разрешены к запуску легитимные приложения и утилиты?
• Как будет осуществляться управление политикой?
• Как будет отслеживаться срабатывание политики? 

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

Что можно почитать по теме:

• Фишинг с помощью вредоносных офисных документов
• Отчёт об анализе поведения вредоносного docx файла
• Ещё один отчёт об анализе поведения вредоносного docx-файла, менее подробный
• Советы по отключению powershell и усилению безопасности
• Инструкция по настройке политики SRP в Windows Server 2016
• Ещё один гайд по настройке SRP-политики, более целостный, на мой взгляд.