Потому что там всё на самом деле запутано.Для начала вам нужно быть понять, что существуют типы входа в систему (типы сессий). И процессы не конвертируются между ними и не могут получить доступ друг к другу без RPC ну или как минимум порта/сокета.
Этого всего нету в unix-подобных ОС, там PAM вместо аутентификации, который выдаёт одни и те же права удаленному пользователю, интерактивному пользователю, демонам и слыхом не слыхивал про Kerberos. PAM-у пофиг, его проектировали в 80-е годы и тащат до сих пор.
Интерактивная сессия в WinNT никогда не превращается в служебную. Если у вас есть пользователь MYWINPC\vasya от лица которого вы вошли в систему и вот решили запустить службу от лица пользователя MYWINPC\vasya, предоставив этой учетной записи соответствующие привилегии, которых у нее по умолчанию не было, то в этом случае службы запущенные от лица Васи и процессы запущенные Васей окажутся физически в разных сессиях.
Суть в том, что вы не обратитесь к такому процессу напрямую.
Local System - это пользователь, который может запускать что бы то ни было только в специальной сессии и только аутентифицировавшись как служба или пакетное задание. Интерактивный пользователь не станет службой.
Лучшее что может сделать интерактивный пользователь - это получить права на создание специально оформленного пакетного задания (нужно как минимум интерактивное повышение привилегий), которое он может поставить в планировщик и выполнить от лица Local System. Еще раз, напрямую не из какой оболочки вы не получите эти права, это не su и тем более не sudo.
Дальше, когда вы создали пакетное задание, которое что-то делает и запустили его от имени Local System, это не значит что у процесса, который вы запустили есть все необходимые привилегии в дескрипторе безопасности, для того чтобы выполнять нужный вам код. Банально, чтобы сменить владельца файла на ФС, в неинтерактивном режиме ваш процесс должен обладать правами, дающими ему возможность выдать самому себе привилегию на смену владельцев (SeTakeOwnershipPrivilege). Для того чтобы выдать себе эти привилегии, вам нужно обратиться не куда-нибудь, а к юзерспейсной части ядра, в частности, к библиотеке advapi32.dll. И вот на этом этапе вас ждут сюрпризы, потому что по-умолчанию ни один сценарий никакой оболочки не может к ней обратиться, блочат все возможные антивирусы включая Defender. Чтобы это обойти вам нужно написать собственное приложение, которое будет обращаться к ядру и что-то там себе повышать.
То есть вы запускаете уже не то что команду в оболочке, не то что скрипт в планировщике, а приложение .NET, дабы скрыть вызовы P/Invoke к этой библиотеке ядра. Ну вот вы после этого что-то там можете выполнить, но не всё. Даже для доступа к хранилищу ключей, вам нужно выдать себе отладочные привилегии (если нету ни виртуализации, ни TPM, если они есть, то всё вообще грустно). Без предварительной настройки своей сессии вы их себе по-тихому не дадите. Орать и вопить будет всё вплоть до ватермарков на картинке рабочего стола.
Ну вот вы всё это написали и хотите поменять... что? Загрузчик? Максимум можно именно сломать загрузчик но незаметно подсунуть свой код, когда включен Secure Boot там не получится, подписи нужны. И вот суть в том, что если вы ваше приложение попытаетесь где-то кому-то распространить, то его внесут в антивирусные сигнатуры быстрее, чем вы получите сертификаты на подпись кода.
P.S. Чтобы окончательно не "путать" вас я умышленно писал только про обычные службы (по сути как демоны) и не упоминаю ни про фоновые процессы магазина ни про специально оформленные user-services, запускаемые как экземпляры внутри интерактивной сессии, с еще более низкими привилегиями от лица других SID, с пониженными профилями энергопотребления и сразу в swap-е... А вообще давайте так, сядьте и получите права Local System из оболочки напрямую, без всяких слов и путаницы, отпишитесь об успехах, может я узнаю что-то новое =)
