Nt authority система что за пользователь
Перейти к содержимому

Nt authority система что за пользователь

  • автор:

Nt authority система что за пользователь

Добрый день! Уважаемые читатели и гости одного из популярнейших блогов по системному администрированию Pyatilistnik.org. В прошлый раз мы с вами подробно рассмотрели командлет Restart-Computer и научились с его помощью производить локальную или удаленную перезагрузку компьютера или сервера, это полезный навык. В сегодняшней публикации я бы хотел вас научить запускать оболочку PowerShell с максимальными правами от имени системной учетной записи «СИСТЕМА (NT AUTHORITY\SYSTEM)» или ее еще иногда называют Local System. Это то же полезный скил, который вас может сильно выручить в разных обстоятельствах. Давайте от слов к практике.

Что можно делать с PowerShell от имени SYSTEM

Я не буду расписывать, что из себя представляет локальная, системная учетная запись, напомню лишь, что из под нее работает подавляющее количество сервисов Windows и она имеет максимальные права на все в вашей ОС (Папки, файлы, кусты реестра, тома). Имея запущенное окно PowerShell от системной учетной записи вы можете абсолютно все в этой системе, например можете отключать службы, которые были ограничены, или подключаться к чужой RDP сессии, поправить защищенные ветки реестра, например, как в случае с ошибкой 10016.

Методы запуска PowerShell от имени системной учетной записи

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

  1. Классический метод использование утилиты PSexec
  2. Через планировщик событий
  3. Через скрипт choco

Запуск PowerShell от учетной записи NT AUTHORITY\SYSTEM из PSexec

PSexec — это одна из утилит легендарного набора SysInternals Марка Руссиновича. Я ее уже использовал при открытии CMD от имени системы, тут принцип будет такой же. Первое, что вы должны сделать, это скачать PSexec либо у меня, либо по ссылке ниже:

Далее вам необходимо ваш архив извлечь, дабы получить папку с утилитами. У вас есть два варианта запуска PSexec, из командной строки или же из свой PowerShell. Давайте опробуем командную строку, которую вы должны ОБЯЗАТЕЛЬНО открыть от имени администратора, далее вы должны перейти в cmd в расположение с утилитой PSexec. Делается это командой:

После чего вы пишите команду, которая запустит окно PowerShell от имени системы:

В результате у вас откроется дополнительное окно PowerShell в режиме администратора и от имени «nt authority\система«. Проверить, это можно командой whoami.

Запуск PowerShell от учетной записи NT AUTHORITY\SYSTEM из PSexec

То же самое можно сделать и из самой PowerShell(), тут вам нужно будет так же открыть PowerShell от имени администратора и ввести команды:

запуск PowerShell из под системы

Чтобы удаленно получить окно PowerShell через PSexec, вам необходимо выполнить:

Где svt2019s01, это имя моего сервера с Windows Server 2019. Как видим идет попытка подключения, где на удаленном компьютере запускается служба PSexec, вам будут необходимы права локального администратора там. Если подключение не проходит, то у вас блокируется брандмауэром, убедитесь, что порт WinRM (TCP 5985) у вас разрешен.

Подключение к удаленному окну PowerShell

После успешного подключения можно ввести команду hostname, чтобы посмотреть, правильно ли вы подключились, ну и посмотреть командой whoami, из под кого запущен PowerShell, как видно из скриншота, это учетная запись nt authority\система.

Удаленный запуск PowerShell из под системы

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

Она так же все запустит, единственное поменяйте в ней путь до утилиты PSexec на свой.

Starting PowerShell as NT AUTHORITY-SYSTEM

Запуск PowerShell от учетной записи NT AUTHORITY\SYSTEM из планировщика заданий

Данный метод более изощренный нежели использование внешней утилиты PSexec, но я уверен, что его так же полезно знать. В окне выполнить введите команду taskschd.msc.

Открываем планировщик задач

Открываем библиотеку планировщика заданий и щелкаем по нему правым кликом, из контекстного меню выберите пункт «Создать простую задачу«

Создание новой задачи в планировщике для открытия PowerShell от системной учетной записи

Задаем ее имя у меня оно будет «Запуск PowerShell NT».

Указание имени нового задания в планировщике Windows

В настройках тригера выставим запуск задачи «Однократно«.

запуск PowerShell из под системы из планировщика

Задаем время запуска.

Настройка времени запуска задания в планировщике

Оставляем пункт «Запустить программу» и нажимаем далее.

Атрибуты запуска PowerShell из под системы

Тут нам необходимо заполнить два пункта:

  1. Поле программы или сценария
  2. Аргумент

Заполнение атрибутов запуска задания планировщика Windows

В поле программы вам нужно вписать строку в зависимости от разрядности вашей архитектуры:

  • x86 : %SystemRoot%\system32\WindowsPowerShell\v1.0\powershell.exe
  • x64 : %SystemRoot%\syswow64\WindowsPowerShell\v1.0\powershell.exe

В качестве аргумента, вам необходимо указать путь до нашего скрипта, расположенного по пути C:\Scripts\Get-CurrentUser.ps1

запуск скрипта PowerShell из под системы

ExecutionPolicy, это команда позволяющая выполнять не подписанные скрипты.

заканчиваем создание простого задания, обязательно выставите галку «Открыть окно «Свойств» для этой задачи после нажатия кнопки «Готово«.

Свойства задания в планировщике

заканчиваем создание простого задания, обязательно выставите галку «открыть окно «Свойств» для этой задачи после нажатия кнопки «Готово». Далее у вас откроется окно свойств данной задачи, вы можете заметить, что она по умолчанию выполняется от того пользователя, кто ее создал, в моем примере, это ROOT\Администратор, это нужно поменять. Нажмите кнопку изменить.

Задаем учетную запись SYSTEM для запуска PowerShell

Если у вас русская Windows, то в окне поиска введите «СИСТЕМА», если английская версия, то введите SYSTEM.

запуск PowerShell из под SYSTEM

В результате вы увидите, что задача запускается от системной учетной записи (nt authority\система).

NT NTHORITY \SYSTEM — это пользователь или группа?

В Windows пользовательская System отображается с символом группы: , (Использование внутреннего Win32 API LookupAccountSid также показывает, что это, похоже, группа SidTypeGroup.)

С другой стороны, процессы могут выполняться в system context как в user context . Также документы Microsoft описывают его как «системный пользователь» или «системная учетная запись», а не как «системная группа».

Это пользователь, который для каких-либо устаревших целей отображается как группа?

(Или это было бы интересно для Вернера Гейзенберга ?)

Примечание. Что такое пользователь NT AUTHORITY\SYSTEM? похож, но не отвечает на вопрос, почему он отображается как группа и ведет себя как пользователь.

2 ответа 2

Во-первых, токен доступа содержит гораздо больше, чем идентификатор безопасности (SID). Нужно только «запустить от имени администратора» программу, чтобы увидеть в диспетчере задач, что ее пользователь является самим собой, а не администратором, и это чудо достигается просто путем изменения токена доступа, а не путем замены SID.

Во-вторых, NT-AUTHORITY и SYSTEM не являются ни учетными записями, ни группами, несмотря на то, что говорят различные другие источники (даже внутри Microsoft). У SID обычно есть имя, которое отображается при необходимости. Учетная запись пользователя будет предоставлять свой SID в качестве основного SID для маркера доступа, который также будет определять имя, отображаемое различными утилитами. Но маркер доступа может содержать дополнительные SID, например, для всех групп, к которым принадлежит эта учетная запись пользователя. При проверке разрешений Windows будет искать любой SID в маркере доступа, который имеет это разрешение.

Некоторые известные Windows SID будут иметь имена, сообщаемые Windows, хотя на самом деле они не принадлежат какой-либо учетной записи.

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

SID не должен даже определять учетную запись пользователя или группу. Он просто определяет набор разрешений. Приведенная выше статья в Википедии добавляет:

Windows предоставляет или запрещает доступ и привилегии к ресурсам на основе списков контроля доступа (ACL), которые используют SID для уникальной идентификации пользователей и их членства в группах. Когда пользователь входит в компьютер, создается токен доступа, который содержит SID пользователя и группы и уровень привилегий пользователя. Когда пользователь запрашивает доступ к ресурсу, токен доступа сравнивается с ACL, чтобы разрешить или запретить конкретное действие с конкретным объектом.

SID NT-AUTHORITY\SYSTEM может быть добавлен к другим учетным записям. Например, это сказано об учетной записи LocalSystem:

Учетная запись LocalSystem является предопределенной локальной учетной записью, используемой диспетчером управления службами. [. ] Его токен включает идентификаторы NT AUTHORITY\SYSTEM и BUILTIN\Administrators; эти учетные записи имеют доступ к большинству системных объектов.

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

В статье Microsoft « Известные идентификаторы безопасности в операционных системах Windows» подробно описаны все системные идентификаторы безопасности, некоторые из которых я приведу ниже:

образ

Вывод: NT-AUTHORITY\SYSTEM — это имя идентификатора безопасности, который не является ни группой, ни учетной записью. Он отображается в диспетчере задач как СИСТЕМА, когда он является основным SID программы. Максимум, что я бы назвал, это «псевдо-счет».

Is "NT AUTHORITY\SYSTEM" a user or a group?

In Windows the user System is displayed with the group symbol: enter image description here. (Using the internal Win32 API LookupAccountSid also reveals that it seems to be a group SidTypeGroup.)

On the other hand processes can run in the system context like in a user context . Also Microsoft documents describe it as «system user» or «system account», and not as «system group».

Is it a user which is for any legacy purposes displayed as group?

(Or is it something Werner Heisenberg would have been interested in?)

Note: What is the NT AUTHORITY\SYSTEM user? is similar but doesn’t answer the question why it is displayed as group and behaves like an user.

harrymc's user avatar

2 Answers 2

First, access token contains much more than the security identifier (SID). One only has to «Run as administrator» a program to see in the Task Manager that its user is oneself and not Administrator, and this miracle is achieved just by the modification of the access token, not by replacing the SID.

Second, NT-AUTHORITY and SYSTEM are neither accounts nor groups, in spite of what say various other sources (even inside Microsoft). An SID usually has a name that is displayed whenever required. A user account will contribute its SID as principal SID to the access token, which will also determine the name displayed by various utilities. But the access token may contain additional SIDs, for example for all the groups to which belongs that user account. When checking permissions, Windows will look for any SID in the access token that has that permission.

Some well-known Windows SIDs will have names reported by Windows, although they do not really belong to any account.

A Security Identifier is defined by Wikipedia as :

a unique, immutable identifier of a user, user group, or other security principal.

The SID does not need to even define a user account or a group. It just defines a set of permissions. The above Wikipedia article adds:

Windows grants or denies access and privileges to resources based on access control lists (ACLs), which use SIDs to uniquely identify users and their group memberships. When a user logs into a computer, an access token is generated that contains user and group SIDs and user privilege level. When a user requests access to a resource, the access token is checked against the ACL to permit or deny particular action on a particular object.

The SID of NT-AUTHORITY\SYSTEM can be added to other accounts. For example, this is said about the LocalSystem Account:

The LocalSystem account is a predefined local account used by the service control manager. [. ] Its token includes the NT AUTHORITY\SYSTEM and BUILTIN\Administrators SIDs; these accounts have access to most system objects.

One can already see in the above text the confusion that reigns even in Microsoft documentation as regarding system SIDs, which are not exactly accounts nor groups — which are just a set of permissions. This confusion further extends to other utilities and articles, so any returned information should be carefully examined.

The Microsoft article Well-known security identifiers in Windows operating systems details all system SIDs, some of whom I include below:

image

Conclusion: NT-AUTHORITY\SYSTEM is the name of a Security ID, which is neither a group nor an account. It is displayed in Task Manager as SYSTEM when it is the principal SID of a program. The most I would call it is «a pseudo account».

NT Authority System

The LocalSystem account NT AUTHORITY\SYSTEM is a built-in account in Windows operating systems, used by the service control manager. It has the highest level of access in the OS (and can be made even more powerful with Trusted Installer privileges). This account has more privileges than a local administrator account and is used to run most Windows services. It is also very common for third-party services to run in the context of this account by default. The SYSTEM account has thist privileges:

SE_ASSIGNPRIMARYTOKEN_NAME, SE_AUDIT_NAME, SE_BACKUP_NAME, SE_CHANGE_NOTIFY_NAME, SE_CREATE_GLOBAL_NAME, SE_CREATE_PAGEFILE_NAME, SE_CREATE_PERMANENT_NAME, SE_CREATE_TOKEN_NAME, SE_DEBUG_NAME, SE_IMPERSONATE_NAME, SE_INC_BASE_PRIORITY_NAME, SE_INCREASE_QUOTA_NAME, SE_LOAD_DRIVER_NAME, SE_LOCK_MEMORY_NAME, SE_MANAGE_VOLUME_NAME, SE_PROF_SINGLE_PROCESS_NAME, SE_RESTORE_NAME, SE_SECURITY_NAME, SE_SHUTDOWN_NAME, SE_SYSTEM_ENVIRONMENT_NAME, SE_SYSTEMTIME_NAME, SE_TAKE_OWNERSHIP_NAME, SE_TCB_NAME, SE_UNDOCK_NAME

The SYSTEM account on a domain-joined host can enumerate Active Directory by impersonating the computer account, which is essentially a special user account. If you land on a domain-joined host with SYSTEM privileges during an assessment and cannot find any useful credentials in memory or other data on the machine, there are still many things you can do. Having SYSTEM-level access within a domain environment is nearly equivalent to having a domain user account. The only real limitation is not being able to perform cross-trust Kerberos attacks such as Kerberoasting.

There are several ways to gain SYSTEM-level access on a host, including but not limited to:

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *