Всем привет!

В предыдущей части мы рассмотрели основные способы обхода UAC, которые используют в своей основе DLL Hijacking, Registry, COM, привели небольшой обзор источников событий и возможный вариант по детектированию UAC Bypass, который базируется на базе COM.

В этой части мы разберем методы обхода UAC в более прикладном ключе. Для этого мы выделили 7 разных методов, которые считаем наиболее интересными. В первой части статьи мы увидели, что не все способы покрываются классификацией, которая была представлена, в частности методы 38, 55 и 59. Ранее о них уже также было упоминание. Поэтому здесь мы рассмотрим как и те методы, которые попали в нашу классификацию, так и те, которые не попали.

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

* - Есть события в Windows EventLog

Со своей стороны напомним, что:

• Если метод использует COM объекты, то есть потенциальная возможность его детектировать с помощью ETW или реестра

• Если метод использует DLL Hijacking или Registry, то его потенциально можно детектировать с помощью событий Sysmon

Метод #38 (APPINFO command line spoofing)

Метод использует особенности функции AicLaunchAdminProcess, которая неверно обрабатывает командную строку.
При передаче в mmc.exe пути до .msc файла, присутствующий в белом списке auto-elevate (например, eventvwr.msc и wf.msc), он поднимет собственные привилегии без отображения окна UAC Prompt. В свою очередь, msc файлы не из белого списка будут запрашивать права у пользователя.
Если мы обратимся напрямую к сервису AppInfo, отвечающему за повышение привилегий и попросим его запустить определённую команду, то функция AicLaunchAdminProcess обработает нашу команду (к примеру, такую: lzx32, wf.msc kmkze.msc) и ошибочно посчитает запятую за разделитель. После чего она обратится к белому списку .msc файлов и автоматически повысит привилегии mmc.exe, к которому будет передана эта команда. Де-факто запятая – это не разделитель, и mmc.exe запустит kmkze.msc или любой другой с повышенными привилегиями.

Шаги выполнения

1. Метод создаёт 3 файла в любой доступной на запись директории osk.exe, readme.html, kmkze.msc

2. Далее он вызывает функцию AicLaunchAdminProcess, передавая ей как аргумент для запуска:
   C:\Windows\system32\mmc.exe lzx32,wf.msc “C:\Users\Rucker\AppData\Local\Temp\kmkze.msc”

3. После чего mmc.exe запускает нагрузку содержащуюся в kmkze.msc.

Возможный вариант детектирования

Команда, которая приходит в mmc.exe очень интересна:
lzx32,wf.msc "C:\Users\kchernyh\AppData\Local\Temp\2\kmkze.msc"

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

Для возможного построения детектирования можно воспользоваться событиями 4688 (A new process has been created) или 1 (Sysmon: Process Creation):
process_command_line == "*,*.msc*"

Метод #52 (AipNormalizePath parsing abuse)

Метод базируется на способе обхода DLL Hijacking. В качестве основного инструмента используется символическая ссылка для подмены легитимной директории C:\Windows\ на подконтрольную атакующему. Для этого создаётся символическая ссылка в корне диска с названием Windows и дополнительным пробелом в имени ссылки.

Сервис AppInfo повышает привилегии auto-elevate исполняемых файлов, которые расположены в доверенных директориях (например, C:\Windows\system32). Сам AppInfo при проверке пути до исполняемого файла использует функцию GetLongPathName, которая проверит символическую ссылку, удалит пробел и таким образом процесс будет запущен, как привилегированный. Новый процесс подгрузит свои библиотеки DLL, расположенные в той же папке, что и целевой исполняемый файл.

Шаги выполнения

1. Метод создаёт ложную директорию system32 в любой подконтрольном атакующему месте.

2. Далее он создаёт зловредную winmm.dll в директорию, которая была создана на первом шаге.

3. Копирует исполняемый файл winsat.exe из system32 в фальшивую system32

4. Создаёт символическую ссылку "C:\Windows \" (важно обратить внимание на пробел в конце), который направляет на фальшивую system32.

5. Из ложной директории system32 вызывается winsat.exe, который импортирует библиотеку winmm.dll.

Возможный вариант детектирования

Ключевым моментом для данного метода является импорт библиотеки DLL из любой директории system32, которая при этом не расположена в C:\Windows. Исполняемый файл со свойством Auto-Elevate также должен находиться в той же папке.

Для возможного детектирования рекомендуется смотреть событие с Event ID 7 (Sysmon: Image loaded)

Image!="C:\\Windows*" && Image=="*\\system32\\*.exe"
&&
ImageLoaded!="C:\\Windows*" && ImageLoaded=="*\\system32\\*.dll"

Метод #55 (UIPI bypass with token modification)

Несколько экстравагантный метод, который основан на UIAccess токене. Он позволяет приложениям эмулировать действия мыши и клавиатуры. Данный метод вызывает msconfig.exe и эмулирует нажатия. Выбрав, тем самым, в графическом меню запуск cmd.exe, который запустится с высокими правами и выполнит в нем произвольные команды.

Шаги выполнения

1. Запуск osk.exe;

2. Получение хендла с полными правами к osk.exe и кража UIAccess токена;

3. Резапуск эксплоита с применением токена UIAccess;

4. Запуск msconfig.exe и получение хендла на него эксплоитом;

5. Манипуляция msconfig.exe для запуска cmd.exe.

Возможный вариант детектирования

Автор UACMe предлагает детектировать все процессы с уровнем доверия Medium и при этом имеющие UIAccess токен. Обычно процессы с этим токеном имеют уровень доверия Medium+, который стоит выше Medium, но ниже High по иерархии. Medium+ был разработан для отсутствия возможности получения UiAccess токена из-под процессов с уровнем доверия Medium, то есть обычным пользователям. Мы в целом согласны с этим, но у нас нет событий, которые бы показывали наличие UIAccess токена у процесса. Поэтому нами будут использоваться события запроса хендла к osk.exe и к msconfig.exe.

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

Если все процессы с токеном UIAccess имеют уровень доверия Medium+ и выше, то почему эксплоит может запросить к нему хендл как процесс уровня доверия Medium?
Эксплоит использует COM интерфейс Shell и его метод ShellExecuteEx для запуска osk.exe, который возвращает хендл с полными правами в ситуации если запускается процесс без UIAccess токена. При UAC Bypass эксплоиту возвращается хендл с правами 0x121101 (Query limited information, Set quotas, Terminate, Synchronize, Read control). Этих прав хватает для создания дубликата токена процесса. 

Если мы не можем удостовериться, что вызывается именно процесс с UIAccess токеном, то почему атакующему нельзя скопировать, переместить и переименовать osk.exe?
Приложению выдаётся UIAccess токен при соблюдении нескольких условий. Одно из них – запуск из доверенной директории. Поэтому если переместить osk.exe, то ему не будут предоставлен как уровень доверия Medium+, так и UIAccess токен.

Выдержка из MSDN: If the UI automation application that requests UIAccess meets the UIAccess setting requirements, then Windows Vista launches the application with the ability to bypass most of the UIPI restrictions. If the UI automation application does not meet the security restrictions, the application will be launched without UIAccess rights and can interact only with applications at the same or lower privilege level.

 Ниже приведены логи запуска процесса – эксплоита и запрос хендла на процесс osk.exe.

<Event
    xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
    <System>
        <Provider Name='Microsoft-Windows-Sysmon' Guid='{5770385f-c22a-43e0-bf4c-06f5698ffbd9}'/>
        <EventID>1</EventID>
        <Version>5</Version>
        <Level>4</Level>
        <Task>1</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime='2022-06-08T11:03:13.0652056Z'/>
        <EventRecordID>3094227</EventRecordID>
        <Correlation/>
        <Execution ProcessID='2980' ThreadID='3868'/>
        <Channel>Microsoft-Windows-Sysmon/Operational</Channel>
        <Computer>cvm01.sea.land</Computer>
        <Security UserID='S-1-5-18'/>
    </System>
    <EventData>
        <Data Name='RuleName'>-</Data>
        <Data Name='UtcTime'>2022-06-08 11:03:13.064</Data>
        <Data Name='ProcessGuid'>{137e180b-81f1-62a0-9c2b-000000001a00}</Data>
        <Data Name='ProcessId'>5820</Data>
        <Data Name='Image'>C:\Users\kchernyh\Desktop\Akagi64.exe</Data>
        <Data Name='FileVersion'>3.5.8.2201</Data>
        <Data Name='Description'>Pentesting utility</Data>
        <Data Name='Product'>UACMe</Data>
        <Data Name='Company'>APT 92</Data>
        <Data Name='OriginalFileName'>Akagi.exe</Data>
        <Data Name='CommandLine'>"C:\Users\kchernyh\Desktop\Akagi64.exe" 55</Data>
        <Data Name='CurrentDirectory'>C:\Users\kchernyh\Desktop\</Data>
        <Data Name='User'>SEA\kchernyh</Data>
        <Data Name='LogonGuid'>{137e180b-326b-629f-d159-0d0000000000}</Data>
        <Data Name='LogonId'>0xd59d1</Data>
        <Data Name='TerminalSessionId'>2</Data>
        <Data Name='IntegrityLevel'>Medium</Data>
        <Data Name='Hashes'>MD5=61B42EF363134B6A62E0149FEB06D66D,SHA256=03BAAC87E26B615642A14E48E6F6B8B66E16DA23AE898A051A3780B232E554C2,IMPHASH=14C4E4C72BA075E9069EE67F39188AD8</Data>
        <Data Name='ParentProcessGuid'>{137e180b-3284-629f-e100-000000001a00}</Data>
        <Data Name='ParentProcessId'>7724</Data>
        <Data Name='ParentImage'>C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe</Data>
        <Data Name='ParentCommandLine'>"C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe" </Data>
        <Data Name='ParentUser'>SEA\kchernyh</Data>
    </EventData>
</Event>

<Event
    xmlns='http://schemas.microsoft.com/win/2004/08/events/event'>
    <System>
        <Provider Name='Microsoft-Windows-Sysmon' Guid='{5770385f-c22a-43e0-bf4c-06f5698ffbd9}'/>
        <EventID>10</EventID>
        <Version>3</Version>
        <Level>4</Level>
        <Task>10</Task>
        <Opcode>0</Opcode>
        <Keywords>0x8000000000000000</Keywords>
        <TimeCreated SystemTime='2022-06-08T11:03:13.1431252Z'/>
        <EventRecordID>3094247</EventRecordID>
        <Correlation/>
        <Execution ProcessID='2980' ThreadID='3868'/>
        <Channel>Microsoft-Windows-Sysmon/Operational</Channel>
        <Computer>cvm01.sea.land</Computer>
        <Security UserID='S-1-5-18'/>
    </System>
    <EventData>
        <Data Name='RuleName'>-</Data>
        <Data Name='UtcTime'>2022-06-08 11:03:13.132</Data>
        <Data Name='SourceProcessGUID'>{137e180b-81f1-62a0-9c2b-000000001a00}</Data>
        <Data Name='SourceProcessId'>5820</Data>
        <Data Name='SourceThreadId'>5920</Data>
        <Data Name='SourceImage'>C:\Windows\explorer.exe</Data>
        <Data Name='TargetProcessGUID'>{137e180b-81f1-62a0-9d2b-000000001a00}</Data>
        <Data Name='TargetProcessId'>844</Data>
        <Data Name='TargetImage'>C:\Windows\system32\osk.exe</Data>
        <Data Name='GrantedAccess'>0x1fffff</Data>
        <Data Name='CallTrace'>C:\Windows\SYSTEM32\ntdll.dll+9e634|C:\Windows\System32\KERNELBASE.dll+8e73|C:\Windows\System32\KERNELBASE.dll+71a6|C:\Windows\System32\KERNEL32.DLL+1cbb4|C:\Windows\SYSTEM32\windows.storage.dll+1a152d|C:\Windows\SYSTEM32\windows.storage.dll+136722|C:\Windows\SYSTEM32\windows.storage.dll+19a75c|C:\Windows\SYSTEM32\windows.storage.dll+19a583|C:\Windows\SYSTEM32\windows.storage.dll+19a46d|C:\Windows\SYSTEM32\windows.storage.dll+1d9dc4|C:\Windows\SYSTEM32\windows.storage.dll+c1d87|C:\Windows\SYSTEM32\windows.storage.dll+135787|C:\Windows\System32\SHELL32.dll+6d1d1|C:\Windows\System32\SHELL32.dll+7d5f9|C:\Windows\System32\SHELL32.dll+5c32d|C:\Windows\System32\SHCORE.dll+2c3f9|C:\Windows\System32\KERNEL32.DLL+17034|C:\Windows\SYSTEM32\ntdll.dll+52651</Data>
        <Data Name='SourceUser'>SEA\kchernyh</Data>
        <Data Name='TargetUser'>SEA\kchernyh</Data>
    </EventData>
</Event>

Второй лог сообщает о запросе хендла с полными правами на бинарник osk.exe. Вы спросите: Но как же так? Ведь эксплоит запрашивает права 0x121101, почему Sysmon говорит о полных правах?
Всё просто – Sysmon «врёт». Так, например, Process Hacker показывает истинные права.

Также обратите внимание на то, что в полях SourceImage у логов запроса хендла указан explorer.exe. На самом деле, это Akagi – то есть эксплоит, который изменил свой путь процесса с помощью Masquerade PEB. Конкретно в этом методе это необязательно, но такой трюк можно использовать, чтобы запутать события Sysmon.

У нас есть 2 пути чтобы противостоять этому:

1. Мы дополнительно наблюдаем за логом создания процесса: 4688 (A new process has been created) или 1 (Sysmon: Process Creation), запоминаем его PID\GUID и в дальнейшем сравниваем именно PID\GUID

2. Мы наблюдаем за всеми процессами, которые получают хендл с полными правами к osk.exe

Рекомендуем использовать первый вариант для точности.

Совмещая детект вызова ShellExecuteEx и запроса хендла к osk.exe программами не из доверенных дирректорий, мы можем детектировать этот метод.
Для возможного детектирования рекомендуется смотреть события Sysmon 1 (Process Creation) и Sysmon 10 (ProcessAccess):

TargetImage==”C:\\Windows\\System32\\osk.exe” && GrantedAccess==”0x1fffff”
&&
CallTrace==”*SHELL32.dll*” && SourceProcessGUID==(EventID==1 && Image!==”C:\\Windows\\*”)

Метод #59 (RAiLaunchAdminProcess and DebugObject)

Это метод, который опирается на сервис AppInfo. Он может запускать auto-elevate исполняемые файлы и с обычными правами, а также создаёт процессы из одного и того же треда.

Уязвимость состоит в том, что DebugObject будет один и тот же, если процессы были рождены от одного и того же треда (в нашем случае это тред сервиса AppInfo). Для начала вызывается не привилегированный процесс с флагом DEBUG_PROCESS напрямую через AppInfo сервис. После этого, в TEB поле новосозданного процесса будет храниться хендл к DebugObject этого же процесса.

Атакующий может без проблем скопировать хендл себе, «отцепить» DebugObject от процесса и завершить его. Теперь, если атакующий вызовет процесс с повышенными привилегиями через сервис AppInfo с флагом DEBUG_PROCESS, то у нового процесса будет тот же DebugObject на который хендл уже получен. И после прослушивания DebugEvents можно наткнуться на хендл процесса с повышенными привилегиями, к которому есть DebugObject. При этом хендл на процесс будет с низкими правами 0x40, что означает PROCESS_DUP_HANDLE.

Хендл с правами PROCESS_DUP_HANDLE можно превратить в хендл с PROCESS_ALL_ACCESS если применить функцию DuplicateHandle, но указывая "самого себя" в качестве цели. После получения хендла с полными правами на процесс с повышенными привилегиями, можно сделать множество вещей.  UACMe использует его чтобы запустить произвольный процесс с флагом PROC_THREAD_ATTRIBUTE_PARENT_PROCESS, в котором будет указание на процесс с повышенными привилегиями. Таким образом, новый процесс будет иметь высокопривилегированный процесс в качестве родителя и наследовать его права.

Шаги выполнения

1. Эксплоит запускает любой не Auto-Elevate исполняемый файл с флагом DEBUG_PROCESS;

2. Копирует хендл на DebugObject новосозданного процесса и завершает его;

3. Запускает любой Auto-Elevate бинарник с флагом DEBUG_PROCESS;

4. Читает DebugEvents повышенного процесса и забирает хендл с правами PROCESS_DUP_HANDLE;

5. Создаёт новый хендл через DuplicateHandle с правами PROCESS_ALL_ACCESS;

6. Запускает cmd.exe указывая повышенный процесс, как родителя.

Возможный вариант детектирования

Если быть честным, то мы пока что не смогли сделать хороший способ детектирования на основе EventLog, Sysmon или ETW.

Все события, которые удалось найти, не говорят о чем-то специфичном для атаки. Наше мнение заключается в том, что стоит использовать логирование LRPC вызовов к AppInfo и наблюдать за порядком вызова сначала непривилегированного, а затем привилегированного процесса с флагом DEBUG_PROCESS. Также, если в распоряжении есть события EDR, которые сообщают о вызовах тех или иных NT* функций с аргументами, то это становится вполне выполнимой задачей.

Метод #61 (Shell API)

Этот метод использует путь к динамически подгружаемой библиотеке у Auto-Elevate исполняемого файла slui.exe, который прописан в ветке реестра, куда есть доступ у обычного пользователя.

Шаги выполнения

1. Создаётся ключ в реестре с пустым значением, который расположен по следующему пути HKU\Software\Classes\{GUID}\DelegateExecute;

2. Создается ключ Default в реестре HKU\Software\Classes\{GUID};

3. Метод обновляет в этой ветке параметр default и записывает туда исполняемый файл (это может быть, как .dll, так и .exe);

4. Далее создается ключ, распложённый по следующему пути HKU\Software\Classes\Launcher.SystemSettings\shell\open\command, который содержит симлинк на новосозданную в прошлых шагах ветку реестра;

5. Запускается slui.exe (Windows Activation Client).

Возможный вариант детектирования

Так как этот метод использует симлинки для обхода сигнатур Windows Defender, нам необходимо запоминать ветку реестра, в которой были созданы ключи DelegateExecute и (default). На следующем этапе необходимо проверить где будет расположен симлинк на эти ключи.

• Sysmon 10 (ProcessAccess), Sysmon 1 (ProcessCreation)

RegistryBranch=="HKU\*\Launcher.SystemSettings\shell\open\command\SymbolicLinkValue"
&&
RegistryValue==(RegistryBranch=HKU\*Classes\{*}\(Default) && RegistryValue=="C:\*")
||
(RegistryBranch==HKU\*Classes\{*}\delegateExecute && RegistryValue=="(Empty)")

Кроме того, нужно применять правило, если эксплоит будет изменять ключи напрямую, без симлинка:

(Object=="HKU\*\Launcher.SystemSettings\shell\open\command (Default)" && RegistryValue=="C:\*")
||
(Object=="HKU\*\Launcher.SystemSettings\shell\open\command\DelegateExecute"
&& RegistryValue=="(Empty)")

Данный метод можно детектировать с помощью EventLog. В этом случае мы сможем лишь видеть в событиях единственный лог самого факта выставления ключа реестра в ветку ms-settings, что является сигналом о возможном выставлении символической ссылки или замены библиотеки, чего обычно не происходит.

• EventLog 4663 (An attempt was made to access an object.)

ObjectName=="\\REGISTRY\\USER\\*\\ms-settings\\shell\\open\\command"
&&
Accesses=="Set key value"

Метод #64 (IIEAxiAdminInstaller, IIEAxiInstaller2, IFileOperation)

Данный метод использует установщик аддонов для Internet Explorer: установщик запускается с административными правами и впоследствии запускает поддельный аддон. Во время установки аддон сохраняется в кэше, но с помощью COM интерфейса IFileOperation его можно заменить на вредоносный файл. После перемещения файла вызывается функция RunSetupCommand, запускающая аддон от имени установщика аддонов Internet Explorer.

Шаги выполнения

1. Запуск WinVerifyTrust с легитимным файлом для установки и помещения его в кэш.

2. Удаление легитимного файла из папки %temp%\IDC1.tmp\ и замена его на зловредный файл.

3. Запуск RunSetupCommand, который запускает ieinstall.exe и который в свою очередь запускает зловредный аддон.

Возможный вариант детектирования

Возможная логика для обнаружения данного метода может базироваться на том, что при выполнении процесса установки аддона никто не должен вмешиваться в данный процесс (кроме установщика аддонов), поэтому один из вариантов – это проведение мониторинга обращений к папке, где расположен кэш. Для этого нужно выставить SACL на локальную Temp папку пользователя.

• EventLog 4663 (An attempt was made to access an object.)

Object_Name=="C:\\Users\\*\\AppData\\Local\\Temp\\IDC1.tmp*" && Accesses=="*WriteData*"
&&
Process_Name!="C:\\Program Files\\Internet Explorer\\ieinstal.exe"

Метод #67 (Shell API)

Метод использует функционал UserChoice, который позволяет подменять значения протоколов. Метод не вызывает COM интерфейсы, вместо этого он регистрирует свой собственный протокол ms-settings, который используется auto-elevate исполняемым файлом fodhelper.exe.

Шаги выполнения

1. Метод создает ключ реестра по следующему пути HKU\software\classes\ms-settings\URL Protocol с нулевым значением;

2. Создаётся ключ реестра HKU\Software\Classes\{GUID}\shell\open\command\Default со значением произвольного исполняемого файла;

3. Создаётся ключ реестра HKU\software\Microsoft\Windows\Shell\Associations\UrlAssociations\ms-settings\UserChoice\ProgId со значением {GUID};

4. Создаётся ключ реестра HKU\software\Microsoft\Windows\Shell\Associations\UrlAssociations\ms-settings\UserChoice\Hash co значением хеша ассоциации;

5. Запускается fodhelper.exe.

Возможный вариант детектирования

Этот метод очень похож на метод №61 как по логике, так и по действиям. Отличие заключается в изменении не DLL библиотеки, которую импортирует fodhelper.exe, а самого протокола ms-settings. Поэтому в детекте мы будем наблюдать именно за изменением ветки UserChoice. Замечу, что данный способ, в отличие от метода №61, не рекомендуется детектировать с помощью EventLog, так как он не даёт информации о новых значениях ключей реестра, что будет порождать ложные срабатывания если легитимный пользователь изменит этот протокол.

• Sysmon 12 & 13 & 14 (Registry Modification)

(RegistryBranch=="HKU\*SOFTWARE\Microsoft\Windows\Shell\Associations\UrlAssociations\ms-settings\UserChoice\ProgId"
&&
RegistryValueRegistryValue==(RegistryBranch==HKU\*Classes\{*}\shell\open\command\(Default)
&&
RegistryValueRegistryValue=="C:\*")) || (RegistryBranch=="HKU\*\ms-settings\URL Protocol")
||
(RegistryBranch=="HKU\*Microsoft\Windows\Shell\Associations\UrlAssociations\ms-settings\UserChoice\Hash")

Вместо итогов

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

Если у вас остались вопросы по статье, то мы с радостью ответим на них в комментариях!