April 24, 2018 9:46 am | Published by |

По запросу Bitdefender мы провели тест защиты того типа, который мы использовали ( https://www.avcomparatives.org/retrospective-test/ ), чтобы оценить, как продукты защищают от неизвестных вредоносных программ в средах, которые отключены от Интернета.

Для этого теста мы заморозили определения вредоносных программ продуктов 14-го ноября 2017 года и протестировали продукты против 1000 новых образцов вредоносных программ, которые появились на неделе после даты замораживания. Все образцы были подтверждены данными телеметрии как неизвестные до даты замораживания.

Чтобы убедиться, что продукты не просто блокируют все, используя параноидальные обнаружения, был выполнен тест ложной тревоги с 1000 чистыми файлами.

PowerShell-based File-less Attacks and File-based Exploits Test

Файловое вредоносное ПО и вымогательство, такие как макросы VBS, JS или MS Office, могут устанавливать бэкдор в системах жертв и создавать контрольный канал (C2) злоумышленнику, который обычно находится в другом физическом месте, даже в другой стране. Помимо этих известных сценариев, можно поставлять файловое вредоносное ПО с использованием эксплойтов, удаленных вызовов (PSexec, wmic), планировщика задач, записей реестра, аппаратных средств Arduino (USB RubberDucky) и вызовов WMI. Это можно сделать со встроенными инструментами Windows, такими как PowerShell. Эти команды загружают фактическое вредоносное ПО непосредственно из Интернета в память жертвы и продолжают расширяться дальше в локальную сеть с помощью собственных средств ОС или могут даже стать постоянными на машинах таким образом.

В ручных тестах мы видим, что в таких файловых сценариях многие популярные AV-продукты по-прежнему обеспечивают недостаточную защиту.

Некоторые новые продукты для обеспечения безопасности бизнеса, похоже, сейчас сосредоточены на этой проблемной области и закрывают пробел в некоторых сценариях.

В следующих тестах мы сосредоточились на нескольких стеках командной строки, командах CMD / PS, которые загружают вредоносное ПО из сети напрямую в ОЗУ или закодированные в base64 вызовы. Таким образом, мы полностью избегаем доступа к диску, который обычно (хорошо) защищен продуктами AV.

После того, как вредоносная программа загрузила свой второй этап, будет установлено http / https соединение с атакующим. Преимущество этого механизма наименьшего изъятия заключается в том, что злоумышленник (http / https) обнаруживает канал C2 за пределами большинства продуктов NAT и брандмауэра. Как только туннель C2 будет установлен, злоумышленник может использовать все известные функции общих продуктов C2 (Meterpreter, PowerShell Empire). К ним относятся, например, upload / download файлов, скриншоты, кейлоггеры, оболочки Windows и моментальные снимки веб-камеры.

Если бы мы могли установить такой C2-канал в этих тестовых сценариях, мы оценили «P». Если программное обеспечение AV предотвратило эту инфекцию, мы дали «O». Если AV-клиент обычно блокирует удаленный доступ через WMI или PSexec на брандмауэре клиента, мы назначаем «shield». Наши C2 ресиверы прослушивали один и тот же IP-адрес, но разные порты с различными продуктами на этих портах.

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

Ниже приведены результаты для 25 сценариев:

У Cylance в качестве политики по умолчанию была активирована «глобальная блокировка скриптов», из-за которой большинство случаев (кроме тестового сценария 14) были заблокированы (оценка: 24). Обратите внимание, что, активировав «глобальную блокировку сценариев», все чистые / невинные сценарии блокируются по умолчанию (мы протестировали его с 25 чистыми сценариями от Microsoft – только Cylance заблокировал их все). Поскольку это не делает различия между чистыми и вредоносными сценариями, они не включены в таблицу выше.

Используемые тестовые сценарии

Ниже кратко описаны 25 тестовых сценариев:

 

1) Ручной запуск mshta Meterpreter
Mshta запускает приложение HTML, в данном случае JavaScript-код, который затем пытается запустить PowerShell с помощью Windows Scripting Host (WScript). PowerShell-Command загружает еще один PowerShellStager для Meterpreter с сетевого хоста и загружает его в память.

2) Ручной запуск PowerShell> поэтапный и не поэтапныйНезависимо от того, какой процесс / эксплоит запускает команду PowerShell в реальной атаке (скрипты Office, эксплойты PDF, вызываемые другими скриптами, вкладкой Rubber Ducky Keyboard Input и т. Д.), Все векторы атаки имеют одну общую черту: они выполняют PS в какой-то момент. Мы тестируем команду непосредственно в командной строке, которая получает версию, закодированную в base64, с помощью Meterpreter-stager. Этот “stager” загружает второй этап с нашего C2-сервера и создает соединение C2 с атакующим. Кроме того, мы попробовали один и тот же скрипт, но тоже поэтапно, т. е. мы также загрузили первый этап с веб-сайта, чтобы максимально сократить максимально возможную нагрузку.

3) Удаленный WMI Meterpreter
Удаленный доступ к машине Windows через вызовы WMIC и полезную нагрузку, используемые в поэтапном сценарии 2.

4) Удаленный psexec Meterpreter
Используя интерфейс psexec, удаленный вызов полезной нагрузки PowerShell, используемой в поэтапном сценарии 2.

5) Удаленный WMI pse
Другая удаленная полезная нагрузка WMI, аналогичная той, что приведена в сценарии 3. Здесь, однако, запущен туннель к серверу Empire PowerShell вместо использования инфраструктуры Metasploit.

6) PowerLurk (событие WMI)
PowerLurk – это бесплатный инструмент для создания событий WMI, которые, в свою очередь, инициируют загрузчик PowerShell Payload Stager. Этот параметр персистентности очень трудно обнаружить, но работает только с привилегиями локального администратора. Здесь мы создаем событие WMI, которое запускает процесс, называемый «notepad.exe», и, например, полезную нагрузку из поэтапного сценария 2.

7) PowerSploit Tasksched Persistence
Задания планировщика также являются объектами популярных атак. Таким образом, полезная нагрузка требует только минимальных прав пользователя для сохранения в системах. Это похоже на вызов автозапуска реестра.

8) Подписка на WMI (PowerSploit)
В этом тесте пакетный файл запускает команду PowerShell, которая загружает первый этап теста, который является командой PowerShell для повышения привилегий для второго этапа (который также является скриптом PowerShell), содержащего основной тестовый код. Invoke-WmiCommand выполняет сценарий PowerShell ScriptBlock на целевом компьютере с использованием WMI. Это делается с помощью методов поставщика реестра StdRegProv WMI для хранения полезной нагрузки в значении реестра. Затем команда выполняется в системе-жертве, а выход сохраняется в другом значении реестра, которое затем извлекается.

9) Подписка на WMI (PowerLurk)                                                                                                                                                                                            В этом тесте пакетный файл запускает команду PowerShell, которая загружает первый этап теста, который является командой PowerShell для повышения привилегий для второго этапа (который также является скриптом PowerShell), содержащий сам основной тестовый код (PowerLurk). Он принимает команду как действие и событие для запуска этого действия, а затем создает элемент WMI, чтобы иметь полностью функциональную постоянную подписку на события WMI.

10) Запланированная задача (вручную)
В этом тесте мы объединили планировщик задач и Pupy. Pupy является открытым исходным кодом, кросс-платформенным (Windows, Linux, OSX, Android) удаленным администрированием и пост-эксплуатационным инструментом, главным образом написанным на Python.

 11) Запланированная задача (доставка с использованием Firefox)
Этот тест очень похож на предыдущий, с той лишь разницей, что выполнение команды вызвано эксплойтом в Firefox 31.0. Чтобы использовать известную уязвимость в этом браузере, мы использовали Metasploit.

12) Скрипт PowerShell (Doc, PowerSploit ReflectivePEinjection)
Мы создали файл документа Microsoft Word с автоматическим открытием макроса. Когда документ открывается, сценарий VBS запускает команду PowerShell, которая загружает первый этап теста, также PowerShell, чтобы повысить привилегии для второго этапа, другого скрипта PowerShell содержащего PowerSploit ReflectivePEinjection. Этот скрипт также загружает DLL с кодировкой base64 (декодируется во время выполнения). Эта DLL была построена через Metasploit.

13) Скрипт PowerShell (Doc, Pupy PowerShell)
Этот тест очень похож на предыдущий, единственная разница – это полезная нагрузка Pupy stager.

14) Eternalblue FuzzyBunch
В этом тесте мы атакуем тестовую машину с помощью FuzzyBunch (просочившийся набор инструментов NSA) через сеть (TCP / порт 445). После успешного использования тестовой машины компонент Peddlecheap.dll загружается, а затем подключается к новой эксплуатируемой машине с помощью Peddlecheap.

15) Ручной запуск: mshta (команда exec)
В этом тесте mshta запускает приложение HTML – в данном случае код VBS – затем пытается запустить PowerShell с помощью Windows Scripting Host (WScript). PowerShell-Command получает еще один PowerShell-Stager для повышенных привилегий и затем выполняет некоторые вредоносные команды.

16) Ручной запуск: LNK (команда exec)
Файл .lnk содержит PowerShell-Command, чтобы получить еще один PowerShell-Stager для повышенных привилегий, а затем выполняет некоторые вредоносные команды

17) Ручной запуск: скрипт (команда exec)
Файл скрипта (например, JS / VBS) содержит крошечный код VBS для выполнения PowerShell-Command с помощью Windows Scripting Host (WScript), чтобы получить еще один PowerShell-Stager для повышения привилегий, а затем выполнить некоторые вредоносные команды

18) Meterpreter (макро)
Мы создали файл Microsoft Word .doc с автоматическим открытием макроса. Когда документ открывается, сценарий VBS запускает команду PowerShell, которая является стартером Meterpreter.

19) Meterpreter (Firefox 31.0 использует firefox_proxy_prototype)
Чтобы использовать известную уязвимость в Firefox 31.0, мы использовали Metasploit с полезной нагрузкой для подключения к нашему серверу C2.

20) Meterpreter (Silverlight)
Чтобы использовать известную уязвимость Silverlight ActiveX в IE, мы использовали Metasploit с полезной нагрузкой для подключения к нашему серверу C2.

21) ) PowerShell Empire (Firefox 31.0 использует firefox_proxy_prototype)
PowerShell Empire – это чистый пост-эксплуатационный агент PowerShell, обычно используемый пентэстером и красными командами, однако он также может использоваться кибер-преступниками с таким же эффектом. В этом тестовом случае мы использовали ту же самую методику доставки, что и в случаях Meterpreter, но мы заменяем полезную нагрузку на одну из версий EmpireStar PowerShell.

22) PowerShell Empire (пакет данных stager)
Мы использовали пакетную версию эмулятора PowerShell (которая является однострочной командой), чтобы установить соединение с сервером C2 и получить дополнительные этапы инструмента.

23) PowerShell Empire (doc with macro stager)
В этом тесте мы использовали PowerShell «doc with macro» stager. В результате мы получили файл Microsoft Word .doc с открытым макросом в нем. Когда документ открывается, скрипт VBS запускает и выполняет однострочную команду PowerShell, которая запускает сеанс империи PowerShell с сервером C2.

24) PowerShell Empire (зашифрованный Firefox эксплойт (ECDH IronSquirrel)
В этом тесте мы использовали тот же самый эксплойт Firefox, что и в предыдущем тесте, а также использовали одну и ту же полезную нагрузку для PowerShell Empire. Однако, используя IronSquirrel в фразе доставки, мы скрываем фактический эксплойт, который мы используем против Firefox.

25) PowerShell Empire (SCT-файл )
В этом тесте мы использовали SCT-stager PowerShell Empire. Это комбинация выполнения команды на локальном хосте и неправильной эксплуатации regsvr32.dll и scrobj.dll, которые являются законными компонентами ОС Windows. Скрипт Launcher содержит код JavaScript, который выполняет первый этап PowerShell Empire.

Тест защиты в реальном времени

Ниже приведенные результаты основаны на тестовом наборе из 300 тестовых примеров, то есть вредоносных URL-адресов, которые были протестированы с использованием нашей Real-World Testing Framework между 10 ноября 2017 года и 30 ноября 2017 года. Кроме того, 10 вредоносных тестовых случаев пришли из электронного письма (электронные письма со вредоносными вложениями и сообщениями, содержащие ссылки на вредоносные сайты). Использовались те же инфекционные векторы, что и у обычного пользователя в повседневной жизни. Используемые тестовые примеры охватывают широкий спектр существующих вредоносных сайтов и предоставляют информацию о защите, предоставляемой различными продуктами (используя все их функции защиты) во время работы в Интернете. Используя ту же методологию, был выполнен тест ложной тревоги с 300 чистыми тестовыми случаями.

 

Тест Ransomware

Чтобы измерить, насколько хорошо продукты обнаруживают и блокируют вирусы-вымогатели, мы протестировали против множества новых образцов данных вирусов, в общей сложности 300 тестовых случаев, с 22 ноября 2017 года и 16 декабря 2017 года