Учетная запись LocalSystem — предопределенная локальная учетная запись, используемая диспетчером управления службами. Эта учетная запись не распознается подсистемой обеспечения безопасности. Она имеет обширные привилегии на локальном компьютере и действует как компьютер в сети. Его маркер права доступа включает в себя идентификаторы безопасности (SID) NT AUTHORITY\SYSTEM и BUILTIN\Administrators ; эти учетные записи имеют доступ к большинству системных объектов. Имя учетной записи во всех местах действия — «.\LocalSystem«. Название, «LocalSystem» или » ComputerName\LocalSystem» может также использоваться. Эта учетная запись не имеет пароля. Если Вы определяете учетную запись как LocalSystem при вызове к функции CreateService, любая информация о пароле, которую Вы предоставляете, игнорируется.
Служба, которая запускается в контексте учетной записи LocalSystem , наследует контекст обеспечения безопасности Диспетчера управления службами (SCM). Пользовательский идентификатор безопасности (SID) создается из значения SECURITY_LOCAL_SYSTEM_RID . Учетная запись не связывается с учетной записью любого пользователя, который начал работу. Она имеет несколько значений:
Ключ реестра HKEY_CURRENT_USER связан с пользователем по умолчанию, а не текущим пользователем. Чтобы обратиться к профилю другого пользователя, имитируйте этого пользователя, а затем обратитесь к HKEY_CURRENT_USER.
Служба может открыть ключ реестра HKEY_LOCAL_MACHINE\SECURITY .
Служба представляет мандат компьютера для удаленного сервера.
Если служба открывает командное окно (на экране дисплея) и запускает командный файл, пользователь должен нажать CTRL+C, чтобы закончить работу командного файла и получить доступ к окну команды с привилегиями LocalSystem .
Учетная запись LocalSystem имеет следующие привилегии:
SE_ASSIGNPRIMARYTOKEN_NAME
SE_AUDIT_NAME
SE_BACKUP_NAME
SE_CHANGE_NOTIFY_NAME
SE_CREATE_PAGEFILE_NAME
SE_CREATE_PERMANENT_NAME
SE_CREATE_TOKEN_NAME
SE_DEBUG_NAME
SE_INC_BASE_PRIORITY_NAME
SE_INCREASE_QUOTA_NAME
SE_LOAD_DRIVER_NAME
SE_LOCK_MEMORY_NAME
SE_PROF_SINGLE_PROCESS_NAME
SE_RESTORE_NAME
SE_SECURITY_NAME
SE_SHUTDOWN_NAME
SE_SYSTEM_ENVIRONMENT_NAME
SE_SYSTEM_PROFILE_NAME
SE_SYSTEMTIME_NAME
SE_TAKE_OWNERSHIP_NAME
SE_TCB_NAME
SE_UNDOCK_NAME
Большинство служб не нуждается в таком высоком уровне привилегии. Если ваша служба не нуждается в этих привилегиях, и это не диалоговая служба, рассмотрите использование учетной записи LocalService или учетной записи NetworkService. Дополнительную информацию смотри в статье Защита службы и права доступа.
Windows NT: Служба имеет ограничение доступа к сетевым ресурсам, типа совместно используемых ресурсов и каналов, потому что она не имеет мандата и должна присоединится к использованию пустой сессии. Следующий ключ реестра включает в себя значения NullSessionPipes и NullSessionShares , которые используются, чтобы определить каналы и совместно используемые ресурсы, с которыми могут соединиться пустые сессии:
Альтернативно, Вы можете добавить значение RestrictNullSessAccess к ключу и установить его в 0, чтобы позволить всем пустым сессиям обращаться ко всем каналам и совместно используемым ресурсам, созданным на этом компьютере.
Windows service local system user
Добрый день! Уважаемые читатели и гости одного из крупнейших IT блогов России Pyatilistnik.org. В прошлый раз мы с вами разобрали способы выключения компьютера средствами командной строки, в сегодняшней публикации мы рассмотрим задачу, как вызвать cmd от имени системной учетной записи Local System, рассмотрим варианты применения данной задачи. Думаю, что многим коллегам данная статья будет весьма познавательна и каждый найдет применение данному лайвхаку.
Какого назначение системной учетной записи Local System
Системная учетная запись (Local System) – это специальная встроенная, локальная учетная запись, созданная Windows в момент установки, для использования в системе и запуска из под нее различных служб Windows. В Windows огромное количество служб и процессов для своего запуска и работы используют именно системную запись. Посмотреть это можно в оснастке «Службы», которую можно открыть из окна «Выполнить» введя в нем services.msc.
Учетная запись Ststem не отображается среди других учетных записей в диспетчере пользователей, но зато вы ее легко можете увидеть на вкладке «Безопасность» у любого системного диска, файла. куста реестра или папки. По умолчанию для учетной записи «Система (System)» предоставлены права полного доступа.
Служба, которая запускается в контексте учетной записи LocalSystem, наследует контекст обеспечения безопасности Диспетчера управления службами (SCM). Пользовательский идентификатор безопасности (SID) создается из значения SECURITY_LOCAL_SYSTEM_RID. Учетная запись не связывается с учетной записью любого пользователя, который начал работу. Она имеет несколько значений:
Ключ реестра HKEY_CURRENT_USER связан с пользователем по умолчанию, а не текущим пользователем. Чтобы обратиться к профилю другого пользователя, имитируйте этого пользователя, а затем обратитесь к HKEY_CURRENT_USER.
Служба может открыть ключ реестра HKEY_LOCAL_MACHINE\SECURITY.
Служба представляет мандат компьютера для удаленного сервера. Если служба открывает командное окно (на экране дисплея) и запускает командный файл, пользователь должен нажать CTRL+C, чтобы закончить работу командного файла и получить доступ к окну команды с привилегиями LocalSystem.
Привилегии LocalSystem
SE_ASSIGNPRIMARYTOKEN_NAME
SE_AUDIT_NAME
SE_BACKUP_NAME
SE_CHANGE_NOTIFY_NAME
SE_CREATE_PAGEFILE_NAME
SE_CREATE_PERMANENT_NAME
SE_CREATE_TOKEN_NAME
SE_DEBUG_NAME
SE_INC_BASE_PRIORITY_NAME
SE_INCREASE_QUOTA_NAME
SE_LOAD_DRIVER_NAME
SE_LOCK_MEMORY_NAME
SE_PROF_SINGLE_PROCESS_NAME
SE_RESTORE_NAME
SE_SECURITY_NAME
SE_SHUTDOWN_NAME
SE_SYSTEM_ENVIRONMENT_NAME
SE_SYSTEM_PROFILE_NAME
SE_SYSTEMTIME_NAME
SE_TAKE_OWNERSHIP_NAME
SE_TCB_NAME
SE_UNDOCK_NAME
Сценарии вызова командной строки из под System
Давайте приведу интересную задачку по нашей теме. Предположим у вас есть доменная среда Active Directory. Вы с помощью инструмента групповой политики или SCCM развернули специализированное ПО, под названием StaffCop, или что-то другое. В момент развертывания или последующей настройки вы задали так, что пользователь даже при наличии прав локального администратора в своей системе не может останавливать службу и менять ее тип запуска, вопрос может ли локальный администратор это поправить и выключить службу?
Способы вызвать командную строку от имени системы
Я очень давно занимаюсь системным администрированием и уяснил давно принцип, если у вас есть права локального администратора, то вы можете все. Обойти любые ограничения и политики. Напоминаю. что я для тестирования развернул агента StaffCop, это такая программа для слежки, которую используют всякие шарашкины конторы. Агент по умолчанию запрещает выключение службы и изменение ее типа. Выглядит, это вот таким образом. Служба работает, имеет имя StaffCop Scheduler, но вот сделать с ней ничего не получается, все не активно.
Для того, чтобы вызвать cmd от имени системы, вам необходимо скачать замечательный набор утилит PSTools, а конкретно нам будет нужна утилита PsExec.exe или PsExec64.exe. Если вы мой постоянный читатель, то вы помните, что я их использовал, чтобы удаленно включить RDP доступ на сервере. Скачать сборник PSTools можно с официального сайта по ссылке ниже, или же у меня с сайта.
Далее вам необходимо распаковать zip архив, в результате чего будет вот такой список утилит.
Теперь когда подготовительный этап готов, то можно продолжать. Откройте обязательно командную строку от имени администратора и введите команду:
Мой пример: cd C:\Дистрибутивы\PSTools
Командой dir я проверил, что это та папка и я вижу нужные мне утилиты PsExec.exe или PsExec64.exe.
Последним шагом мы текущее окно командной строки из под текущего пользователя перезапустим от имени Local System. Пишем:
В итоге я вижу, что у меня открылось новое окно командной строки и оно уже работает в контексте «C:\Windows\system32>«, это и означает учетную запись Local System (Системная учетная запись)
Теперь давайте из под нее попробуем остановить нашу службу StaffCop Scheduler. Для этого есть ряд команд:
Далее вам необходимо изменить тип запуска и поменять с автоматического на отключена. Для этого пишем команду:
Как видим все успешно отработало. Если посмотреть оснастку «Службы», то видим вот такую картину.
Так, что имея права локального администратора и утилиту PsExec.exe, можно делать что угодно. Надеюсь, что вы теперь будите чаще вызывать окно командной строки от имени учетной записи системы. Давайте с вами напишем небольшой батник, который будет из ярлыка вызывать cmd от имени Local System. Создадим тестовый файл, поменяем ему сразу расширение с txt на cmd и откроем его текстовым редактором. Пропишем код:
Щелкаем по файлу правым кликом и выбираем пункт «Запуск от имени администратора». В результате чего у вас сразу будет запущено окно cmd с правами учетной записи SYSTEM. Проверить, это можно введя команду whoami. Ответ NT AUTORITY\СИСТЕМА.
Если нужно запустить удаленно командную строку от имени NT AUTORITY\СИСТЕМА, то выполните такую конструкцию
Service User Accounts
Each service executes in the security context of a user account. The user name and password of an account are specified by the CreateService function at the time the service is installed. The user name and password can be changed by using the ChangeServiceConfig function. You can use the QueryServiceConfig function to get the user name (but not the password) associated with a service object. The service control manager (SCM) automatically loads the user profile.
When starting a service, the SCM logs on to the account associated with the service. If the log on is successful, the system produces an access token and attaches it to the new service process. This token identifies the service process in all subsequent interactions with securable objects (objects that have a security descriptor associated with them). For example, if the service tries to open a handle to a pipe, the system compares the service’s access token to the pipe’s security descriptor before granting access.
The SCM does not maintain the passwords of service user accounts. If a password is expired, the logon fails and the service fails to start. The system administrator who assigns accounts to services can create accounts with passwords that never expire. The administrator can also manage accounts with passwords that expire by using a service configuration program to periodically change the passwords.
If a service needs to recognize another service before sharing its information, the second service can either use the same account as the first service, or it can run in an account belonging to an alias that is recognized by the first service. Services that need to run in a distributed manner across the network should run in domain-wide accounts.
You can specify one of the following special accounts instead of specifying a user account for the service:
Using the LocalSystem Account as a Service Logon Account
One advantage of running under the LocalSystem account is that the service has complete unrestricted access to local resources. This is also the disadvantage of LocalSystem because a LocalSystem service can do things that would bring down the entire system. In particular, a service running as LocalSystem on a domain controller (DC) has unrestricted access to Active Directory Domain Services. This means that bugs in the service, or security attacks on the service, can damage the system or, if the service is on a DC, damage the entire enterprise network.
For these reasons, domain administrators at sensitive installations will be cautious about allowing services to run as LocalSystem. In fact, they may have policies against it, especially on DCs. If your service must run as LocalSystem, the documentation for your service should justify to domain administrators the reasons for granting the service the right to run at elevated privileges. Services should never run as LocalSystem on a domain controller. For more information and a code example that shows how a service or service installer can determine if it is running on a domain controller, see Testing Whether Running on a Domain Controller.
When a service runs under the LocalSystem account on a computer that is a domain member, the service has whatever network access is granted to the computer account, or to any groups of which the computer account is a member. Be aware that in WindowsВ 2000, a domain computer account is a service principal, similar to a user account. This means that a computer account can be in a security group, and an ACE in a security descriptor can grant access to a computer account. Be aware that adding computer accounts to groups is not recommended for two reasons:
Computer accounts are subject to deletion and re-creation if the computer leaves and then rejoins the domain.
If you add a computer account to a group, all services running as LocalSystem on that computer are permitted the access rights of the group. This is because all LocalSystem services share the computer account of their host server. For this reason, it is particularly important that computer accounts not be made members of any domain administrator groups.
Computer accounts typically have few privileges and do not belong to groups. The default ACL protection in Active Directory Domain Services permits minimal access for computer accounts. Consequently, services running as LocalSystem, on computers other than DCs, have only minimal access to Active Directory Domain Services.
If your service runs under LocalSystem, you must test your service on a member server to ensure that your service has sufficient rights to read/write to Active Directory Domain Controllers. A domain controller should not be the only Windows computer on which you test your service. Be aware that a service running under LocalSystem on a Windows domain controller has complete access to Active Directory Domain Services and that a member server runs in the context of the computer account which has substantially fewer rights.
