На DEF CON в этом году провели семинар по обходам интерфейса сканирования антивирусного ПО Windows (AMSI) и обходам песочницы Как и в любом классе, предполагающем свободное использование виртуальных машин (ВМ), у нас было несколько технических проблем, с которыми столкнулись студенты, но одна из них была для нас особенно странной. Большинство сценариев, которые мы написали, чтобы намеренно помечать их AMSI, выполнялись полностью незамеченными. Первоначально мы думали, что либо студенты забыли повторно включить Defender, либо команда, которую мы им дали, не работает. Однако мы убедились, что команда re-enable правильно работает на нашей собственной виртуальной машине и что скрипты помечаются. Затем студенты повторно запустили команду enable и убедились, что Защитник действительно включен. Однако очень странные флаги никто не получал. Мы двинулись дальше, потому что у класса было мало времени.
После того, как DEF CON закончился (и у нас наконец появилось немного свободного времени), мы хотели выяснить, почему у некоторых из наших студентов были проблемы с помеченными скриптами. Мы решили использовать обход AMSI Мэтта Грэбера в качестве сценария управления (на слайдах семинара показано, как скрыть его после AMSI). Мы загрузили ноутбук, запустили скрипт, и он не был отмечен!
Обычно ключевые слова amsiInitFailed и System.Management.Automation.AmsiUtils вызывают срабатывание триггера и помечаются.
Во время семинара мы раздали три скрипта, которые должны были быть отмечены на каждом компьютере. Только один из этих скриптов постоянно отмечался, а другие нет. Мы протестировали его, чтобы убедиться, что наша машина теперь демонстрирует те же проблемы, с которыми столкнулись наши ученики. Этот скрипт действительно был помечен, и тот факт, что обход AMSI не был включен, указывает на то, что проблема связана с сигнатурами вредоносных программ AMSI и Defender, а не с тем, что они полностью отключены.
Мы знали, что наша тестовая виртуальная машина сигнализирует об обходе Graeber во время семинара, поэтому мы попробовали это снова. Успех! Наконец-то мы получили флаг от AMSI на байпасе.
На этом этапе вы, возможно, заметили разницу между машиной с голым железом и виртуальной машиной. При использовании нашей виртуальной машины для тестирования обфускации мы устанавливаем виртуальную машину только для размещения и отключаем облачную интеграцию для Защитника. Сигнатуры Защитника виртуальной машины последний раз обновлялись 4 августа, а на «голом железе» были последние обновления от 12 и 13 августа. Мы сделали снимок нашей виртуальной машины с обновлениями от 4 августа, а затем обновили подписи Защитника, чтобы проверить нашу теорию. Мгновенно объездная дорога Гребера перестала отмечаться. Теперь мы были уверены, что обновление между 5 и 8 августа сломало AMSI, но мы хотели знать, насколько испорчены определения.
Мы большие поклонники Powershell Empire и решили протестировать дефектные подписи против него. Сначала мы протестировали необфусцированную полезную нагрузку в кодировке Base64.
Как и ожидалось, в подписи от 4 августа он был отмечен как вредоносный. Однако… новых определений не было.
При некоторой легкой обфускации исходная полезная нагрузка Powershell Empire пройдет мимо AMSI, однако с определениями от 4 августа другой провайдер событий Защитника Windows отметит строку «Invoke-Empire» (предположительно, путем сканирования строк в памяти) и завершит процесс. Он идентифицирует вредоносный процесс как Powershell Empire:
Помимо того, что AMSI не смог идентифицировать вредоносную полезную нагрузку, определения от 12/13 августа также не помечают строку в памяти.
Defender может быть немного неудачником при идентификации строки Invoke-Empire, но Invoke-Mimikatz в значительной степени верный способ быть пойманным. Определения 4 августа все еще находят Invoke-Mimikatz в памяти, а затем убивают процесс и маяк.
Определения от 12/13 августа не идентифицируют Mimikatz и позволяют ему работать до конца.
Powershell Empire практически невидима для Defender с определениями от 12/13 августа. Что было бы здорово, если бы мы проходили оценку, а не проводили семинар, когда это произошло.
В конце концов, мы смогли определить плохое обновление где-то между вечером 4 августа и утром 5 августа. Мы уведомили Microsoft о проблемах, и они исправили проблему по состоянию на 16 августа, но чуть больше недели Powershell Empire всё ещё работает.
Для этого тестирования мы использовали Kali 2019.2 и Powershell Empire, загруженные из ветки разработки GitHub.
После того, как DEF CON закончился (и у нас наконец появилось немного свободного времени), мы хотели выяснить, почему у некоторых из наших студентов были проблемы с помеченными скриптами. Мы решили использовать обход AMSI Мэтта Грэбера в качестве сценария управления (на слайдах семинара показано, как скрыть его после AMSI). Мы загрузили ноутбук, запустили скрипт, и он не был отмечен!
Код:
$ReF=[Ref].Assembly.GetType('System.Management.Automation.AmsiUtils^' );
$REF.GetField('amsiInitFailed','NonPublic,Static').SetValue($null,$True);Во время семинара мы раздали три скрипта, которые должны были быть отмечены на каждом компьютере. Только один из этих скриптов постоянно отмечался, а другие нет. Мы протестировали его, чтобы убедиться, что наша машина теперь демонстрирует те же проблемы, с которыми столкнулись наши ученики. Этот скрипт действительно был помечен, и тот факт, что обход AMSI не был включен, указывает на то, что проблема связана с сигнатурами вредоносных программ AMSI и Defender, а не с тем, что они полностью отключены.
Мы знали, что наша тестовая виртуальная машина сигнализирует об обходе Graeber во время семинара, поэтому мы попробовали это снова. Успех! Наконец-то мы получили флаг от AMSI на байпасе.
На этом этапе вы, возможно, заметили разницу между машиной с голым железом и виртуальной машиной. При использовании нашей виртуальной машины для тестирования обфускации мы устанавливаем виртуальную машину только для размещения и отключаем облачную интеграцию для Защитника. Сигнатуры Защитника виртуальной машины последний раз обновлялись 4 августа, а на «голом железе» были последние обновления от 12 и 13 августа. Мы сделали снимок нашей виртуальной машины с обновлениями от 4 августа, а затем обновили подписи Защитника, чтобы проверить нашу теорию. Мгновенно объездная дорога Гребера перестала отмечаться. Теперь мы были уверены, что обновление между 5 и 8 августа сломало AMSI, но мы хотели знать, насколько испорчены определения.
Мы большие поклонники Powershell Empire и решили протестировать дефектные подписи против него. Сначала мы протестировали необфусцированную полезную нагрузку в кодировке Base64.
Как и ожидалось, в подписи от 4 августа он был отмечен как вредоносный. Однако… новых определений не было.
При некоторой легкой обфускации исходная полезная нагрузка Powershell Empire пройдет мимо AMSI, однако с определениями от 4 августа другой провайдер событий Защитника Windows отметит строку «Invoke-Empire» (предположительно, путем сканирования строк в памяти) и завершит процесс. Он идентифицирует вредоносный процесс как Powershell Empire:
Помимо того, что AMSI не смог идентифицировать вредоносную полезную нагрузку, определения от 12/13 августа также не помечают строку в памяти.
Defender может быть немного неудачником при идентификации строки Invoke-Empire, но Invoke-Mimikatz в значительной степени верный способ быть пойманным. Определения 4 августа все еще находят Invoke-Mimikatz в памяти, а затем убивают процесс и маяк.
Определения от 12/13 августа не идентифицируют Mimikatz и позволяют ему работать до конца.
Powershell Empire практически невидима для Defender с определениями от 12/13 августа. Что было бы здорово, если бы мы проходили оценку, а не проводили семинар, когда это произошло.
В конце концов, мы смогли определить плохое обновление где-то между вечером 4 августа и утром 5 августа. Мы уведомили Microsoft о проблемах, и они исправили проблему по состоянию на 16 августа, но чуть больше недели Powershell Empire всё ещё работает.
Для этого тестирования мы использовали Kali 2019.2 и Powershell Empire, загруженные из ветки разработки GitHub.