Недавно в форуме всплыл вопрос о предотвращении установки Teams в Windows 11. Если бы его автор читал мое руководство, то все прошло бы без сучка и задоринки. Но он следовал другим материалам. В итоге не вышло импортировать параметр в реестр, потому что владельцем раздела является TrustedInstaller!

В таких случаях я давно рекомендую не менять разрешения в реестре или файловой системе, а вносить изменения с правами служебных учетных записей SYSTEM или TrustedInstaller (TI). И у меня в блоге накопилась уже солидная подборка утилит для запуска программ с такими правами. Сегодня для разнообразия мы обойдемся без сторонних средств.

[+] Сегодня в программе

Метод

Вкратце, с полными правами создается самое обычное задание планировщика, запускаемое от имени любого пользователя. А затем оно вызывается от имени служебного аккаунта TrustedInstaller с помощью метода IRegisteredTask::RunEx из COM API планировщика заданий. В результате процесс невидимо выполняется от имени SYSTEM с токеном доступа TrustedInstaller.

Этот подход несколько лет назад описал в своем блоге James Forshaw aka Tyranid, исследователь безопасности из команды Google Project Zero. И я хочу сделать репост, потому что решение как влитое встает в ряд публикаций моего блога:

• Как выполнять задачи с полными правами обычным пользователем без ввода пароля администратора
• Как выполнять команды и скрипты от имени системы средствами Windows
• Как внести изменения в реестр от имени TrustedInstaller с помощью сторонних утилит
• Как запустить невидимое приложение

Скрипт

Скачать RunAsTI.zip.

В оригинале автор остановился на демонстрации запуска исполняемого файла. Я лишь развил идею до выполнения скрипта.

#https://www.outsidethebox.ms/21899
#Параметры задания
$taskname = 'RunAsTI'
$execute = 'powershell'
#Запись в раздел реестра, которым владеет TI (предотвращение установки Teams), и вывод whoami в текстовый файл
$argument = '-ExecutionPolicy Bypass -Noprofile -Command "& {
	New-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Communications -Name ConfigureChatAutoInstall -Value 0 -Type Dword -Force | 
	Tee-Object -FilePath $env:WINDIR\temp\TI.txt
	whoami | Out-File -FilePath $env:WINDIR\temp\TI.txt -Append 
}"'
$action = New-ScheduledTaskAction -Execute $execute -Argument $argument
#Создание задание в планировщике
Register-ScheduledTask -TaskName $taskname -Action $action
#Запуск задания от имени TrustedInstaller
$svc = New-Object -ComObject 'Schedule.Service'
$svc.Connect()
$user = 'NT SERVICE\TrustedInstaller'
$folder = $svc.GetFolder('\')
$task = $folder.GetTask('RunAsTI')
$task.RunEx($null, 0, 0, $user)
#Удаление задания
#Unregister-ScheduledTask -TaskName $taskname -Confirm:$false

Приложению powershell.exe с помощью параметра -Command передается скриптблок. Нередко достаточно одной команды, но скрипт — более глобальный пример. Первая команда вносит изменения в раздел реестра, владельцем которого является TI. Вторая просто создает файл во временной папке. Там должна фигурировать учетная запись nt authority\system, от имени которой отработало задание.

В скобках замечу, что ранее я показывал создание запланированного задания для запуска от имени NT AUTHORITY\SYSTEM. Однако с помощью командлета New-ScheduledTaskPrincipal не получится провернуть то же самое для NT SERVICE\TrustedInstaller, поскольку TI — это служба. И хотя у нее есть SID, сопоставление с помощью параметра -UserId не предусмотрено схемой планировщика заданий, на которую опирается командлет. Наконец, в графическом интерфейсе планировщика тоже невозможно задать выполнение задания от имени TI.

Литература

Обе ссылки ведут в блог James Forshaw:

• The Art of Becoming TrustedInstaller – под капотом TI, SID службы, олицетворение токена — все то, что используют используют сторонние утилиты.
• The Art of Becoming TrustedInstaller — Task Scheduler Edition – описанный выше метод.