Привет, Хабр!
Сегодня мы хотим рассказать о возможных вариантах обхода контроля учётных записей пользователей (UAC) и способах их детектирования.
Если коротко, 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
User Account Control (UAC) – контроль учётных записей пользователей, который является одним из механизмов безопасности ОС Windows.
При отсутствии данного механизма, если пользователь запустит вредоносное программное обеспечение из-под своей сессии, то оно получит административные привилегии. В тоже время, при наличии включенного UAC в системе, пользователь по-прежнему будет обладать административными привилегиями, но его основной токен будет пользовательским. Поэтому все процессы, включая вредоносное ПО, запустятся с токеном обычного пользователя. По крайней мере в теории это выглядит так.
Единственный, по изначальной задумке разработчиков, способ получить административный токен – выполнить функцию "Запустить от имени администратора", а затем во всплывающем окне подтвердить необходимость выполнения действия или действий с административными привилегиями нажатием на кнопку "Да". Либо ввести учетные данные пользователя, обладающего административными привилегиями. При этом выполнить данную операцию пользователь может только интерактивно.
Данный механизм впервые появился в Windows Vista, как способ смягчить переход от подхода "Чтобы пользоваться ПК, нужно быть администратором" к подходу "Чтобы пользоваться ПК, можно быть обычным пользователем". До этого момента практически любому пользователю для комфортной работы в ОС Windows необходимо было обладать правами администратора. И, как следствие, зачастую это приводило к быстрой компрометации ОС, так как не соблюдалось базовое правило ИБ – принцип минимальных привилегий. Поэтому разработчики ОС Windows взяли курс на упрощение работы из-под обычного пользователя.
Настройки 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 имеет встроенный функционал запуска других программ, которые будут наследовать его высокие привилегии.
На картинке выше показано, что с помощью msconfig.exe можно перейти во вкладку Tools и выбрать запуск cmd.exe. Запущенный от msconfig.exe, cmd.exe будет иметь полные административные права, хотя сам msconfig.exe запускался из-под процесса с низкими правами.
Проверить наличие свойства можно с помощью утилиты sigcheck из стандартного набора SysInternals. Помимо явного запуска исполняемых файлов, также используются DLL Hijacking, подмена переменных, аргументов и другие способы, чтобы выполнить произвольный код от имени исполняемых файлов такого рода.
COM-интерфейсы со свойством Auto-Elevate
Второй способ, позволяющий повысить права до административных – COM-интерфейсы. Для каждого интерфейса в реестре содержится запись: может ли он автоматически повышать права до административных.
Каждый COM-интерфейс имеет уникальный CLSID. На рисунке выше мы видим запись в реестре для интерфейса IFileOperation. Наличие записи Enabled со значением 1 в ключе Elevation подсказывает нам, что такой COM-интерфейс может запускаться с административными правами даже без UAC Prompt.
Комбинируя несколько COM-интерфейсов с разным функционалом, мы можем выполнять действия как администратор. Например, перемещать файлы в системные директории. Это предоставит нам возможность выполнить в дальнейшем DLL Hijacking и автоматически повысить свои привилегии.
Отметим, что не каждый процесс способен повысить свои права через COM-интерфейс: ОС выполняет проверку Command Line процесса, который вызывает этот интерфейс и повышает привилегии, только если он является доверенным. Тем не менее, данный момент достаточно легко обойти, если процесс решит изменить собственную переменную и представиться, например, explorer.exe. Для этого используется способ под названием Masquerade PEB, который олицетворяет изменение PEB (Process Environment Block) структуры, содержащий информацию о процессе.
Модификация реестра
Еще одна возможность внедрения в процесс исполнения кода auto-elevate программ заключается в модификации веток реестра, доступных для записи обычному пользователю. Некоторые из которых могут проверяться на наличие в них записей динамически подгружаемых библиотек, необходимых для импорта.
Возьмём fodhelper.exe. Исполняемый файл проверяет при запуске следующие ветки реестра:
HKCU\Software\Classes\ms-settings\shell\open\command
HKCR\ms-settings\shell\open\command
Как можно увидеть, HKCR\ms-settings\shell\open\command содержит ссылку на другую ветку реестра:
А она уже содержит путь до DLL, которая будет подгружена fodhelper.exe.
Так как у пользователя есть права на запись первой (HKCU) ветки реестра, то можно подделать запись, которая ведёт на другую ветку и заставить fodhelper.exe загрузить зловредную DLL.
Заметим, что в текущем примере можно увидеть, что модификация реестра является промежуточным этапом для выполнения атаки DLL Hijacking. Эту ситуацию можно и нужно детектировать с помощью событий, отражающих изменение реестра. Но существуют способы, которые не опираются ни на что кроме подмены библиотек.
Категории для детектирования UAC Bypass
После проведенного анализа большого числа рабочих методов UAC Bypass мы выделили следующие категории с точки зрения их характера атаки и последующего детектирования:
1. Подмена DLL (DLL Hijacking)
2. Использование COM интерфейсов (COM)
3. Модификация реестра (Registry)
В качестве базы для анализа методов нами был использован ресурс UACMe, который содержит информацию по 70+ методам обхода UAC. Многие из которых комбинируют несколько способов обхода, поэтому могут входить в две группы. Чтобы легче было разобраться приведем визуальную картинку в виде диаграммы по количеству методов в разных или смежных группах:
Проводя классификацию, мы постарались обобщить все методы, присутствующие в 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
У каждого из этих источников есть особенности, выражающиеся как в плюсах, так и в минусах. Рассмотрим подробнее:
Журналы 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-объектов.
Эта категория была выбрана нами не случайно. В отличие от других способов UAC Bypass, COM-объекты являются одними из корневых объектов системы и применяются практически везде. В свою очередь методы UAC Bypass опирающиеся на COM-интерфейсы так же имеют общие черты указывающие на атаку. Таким образом, при логировании вызовов COM- объектов можно найти и выделить универсальную логику возможного детектирования, применимую ко всем методов из группы COM.
Итак, при запросе на использование COM-интерфейса, исполняемый файл обычно выполняет запрос к реестру, используя путь HKCR\CLSID\{COM_GUID} для определения местоположения динамической библиотеки (DLL). Библиотека содержит информацию о COM-интерфейсе и другие вспомогательные данные. Зная этот факт, мы можем выявить 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.
Импорт происходит только в случае вызова 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.
Первый атрибут появляется у процессов, которые автоматически повышают права, а второй наследуется дочерними процессами с такими же правами. Это может быть полезно для того, чтобы не составлять список всех возможных дочерних процессов для каждого auto-elevate исполняемого файла.
Машинное обучение
Еще одним помощником в обнаружении может стать поведенческий анализ, механизмы которого используются в специализированных платформах для выявления аномальных активностей.
Основная проблема UAC Bypass заключается в борьбе с ложными срабатываниями, появляющимися при легитимной работе auto-elevate исполняемых файлов. Использование машинного обучения удобно для того, чтобы показать полную картину того, насколько часто процессы, требующие повышенных привилегий, запускались в системе. И, следовательно, при наличии отклонения формировать соответствующее оповещение.
В этой статье мы рассмотрели примеры UAC Bypass, привели категории методов и выявили возможные способы обхода UAC и его детектирования. В следующем материале мы попробуем сделать более углубленный разбор нескольких, выбранных нами методов обхода UAC и предложить свой возможный вариант их детектирования.
Если у вас появились вопросы по статье, пишите нам в комментариях!