За каждой службой, которую Windows 11 запускает на компьютере, стоит конкретная учётная запись. От её имени зависит, какие файлы служба вправе читать, способна ли она трогать память чужих процессов и как её видят соседние машины в сети. Разбираем три встроенные учётные записи служб, их привилегии, профили и способы узнать, от кого на самом деле работает любой фоновый процесс.
Три встроенные учётные записи, от которых запускаются все службы Windows 11
Службы устроены иначе, чем обычные программы. Их запускает не пользователь, а диспетчер служб, компонент с аббревиатурой SCM. Во время загрузки он читает базу служб и для каждой открывает процесс от имени учётной записи, записанной в её настройках. Экран входа и пароль здесь не участвуют: служба входит в систему сама, тихо и до появления рабочего стола.
Встроенных учётных записей для этого в Windows 11 три: LocalSystem, NetworkService и LocalService. В настройках службы их полные имена выглядят как NT AUTHORITY\LocalSystem, NT AUTHORITY\NetworkService и NT AUTHORITY\LocalService. Пароля у всех трёх нет, и поля пароля при их указании система просто игнорирует, поэтому подбор пароля здесь ничего не даст, защита построена на другом.
Другое – это идентификатор безопасности, SID. LocalSystem носит S-1-5-18, LocalService – S-1-5-19, NetworkService – S-1-5-20. Значения фиксированы и одинаковы на любом компьютере с Windows, поэтому система различает эти учётные записи именно по SID. В оснастке "Локальные пользователи и группы" все три не видны: их нельзя удалить, переименовать, заблокировать или добавить в группу. Обслуживают они саму систему, а не людей за клавиатурой.
LocalSystem, учётная запись с почти неограниченной властью над системой
LocalSystem, она же SYSTEM, стоит на вершине местной иерархии. В её токен входят группы NT AUTHORITY\SYSTEM и BUILTIN\Administrators, а на файловой системе NTFS эта пара по умолчанию получает полный доступ ко всему диску. Служба от LocalSystem читает ветку реестра HKEY_LOCAL_MACHINE\SECURITY с самыми чувствительными данными системы и открывает память любого процесса.
Набор привилегий соответствующий. Включены права SE_DEBUG_NAME для работы с чужими процессами, SE_TCB_NAME, дающее статус части операционной системы, SE_IMPERSONATE_NAME для работы от имени других учётных записей, SE_AUDIT_NAME для записей аудита, а также SE_LOCK_MEMORY_NAME, SE_CREATE_PAGEFILE_NAME, SE_CREATE_PERMANENT_NAME, SE_CREATE_GLOBAL_NAME, SE_CHANGE_NOTIFY_NAME и SE_INC_BASE_PRIORITY_NAME. Часть прав, например SE_BACKUP_NAME, SE_RESTORE_NAME, SE_LOAD_DRIVER_NAME и SE_TAKE_OWNERSHIP_NAME, в токене присутствует в отключённом виде, но служба может включить их в любой момент: право уже выдано, просто не активно.
Парадокс в том, что именно эту учётную запись Windows раздаёт службам щедрее всего: от LocalSystem работают Центр обновления Windows с именем wuauserv, Диспетчер печати со служебным именем Spooler, журнал событий EventLog и десятки других компонентов. Она же достаётся любой новой службе, если установщик не указал другую учётную запись явно.
У LocalSystem собственный профиль. Ключ HKEY_CURRENT_USER в её сеансе указывает на HKEY_USERS\.DEFAULT, а файлы настроек лежат в C:\Windows\System32\config\systemprofile.
В сети LocalSystem выступает самим компьютером: к удалённым ресурсам она ходит от имени учётной записи компьютера, в домене это имя вида DOMEN\PC01$. В домашней сети без домена это почти ничего не меняет, зато в домене даёт доступ туда, куда разрешено самому компьютеру.
Итог прост: компрометация одной службы под LocalSystem означает компрометацию всего компьютера.
NetworkService и LocalService, близнецы с минимальными правами и разной репутацией в сети
Локальные права у NetworkService и LocalService одинаковы и скромны. Включены только привилегии SE_CHANGE_NOTIFY_NAME для чтения списков папок, SE_CREATE_GLOBAL_NAME и SE_IMPERSONATE_NAME. В токене нет ни SE_DEBUG_NAME, ни SE_TCB_NAME, ни группы BUILTIN\Administrators, поэтому ветка HKEY_LOCAL_MACHINE\SECURITY закрыта, чужую память не прочитать, системное время не перевести, драйвер не загрузить. Всё, что назначено обычным пользователям и группе "Прошедшие проверку", эти учётные записи тоже получают, но не больше.
Разница между ними проявляется только в сети. NetworkService представляется удалённым серверам от имени компьютера, а её сетевой токен несёт группы Everyone и Authenticated Users. LocalService выходит в сеть анонимно, без имени. Для доступа к доменным ресурсам первая подходит, перед второй многие серверы закроют дверь. Отсюда и распределение в Windows 11: DHCP-клиент Dhcp и Служба центра обеспечения безопасности wscsvc работают от LocalService, а DNS-клиент Dnscache – от NetworkService.
Профили у этих двоих раздельные и лежат в C:\Windows\ServiceProfiles\LocalService и C:\Windows\ServiceProfiles\NetworkService. В реестре каждому заведена своя ветка в HKEY_USERS: S-1-5-19 и S-1-5-20. Ключ HKEY_CURRENT_USER в их сеансах указывает именно туда, а не в профиль какого-то пользователя, поэтому настройки служб не перемешиваются между собой и не попадают в чужие папки.
Изоляция сеанса 0 и отдельные профили служб в systemprofile и ServiceProfiles
Все службы Windows 11, независимо от учётной записи, живут в изолированном сеансе с номером 0. Пользовательские сеансы нумеруются с единицы, и на границе между ними стоит стена: начиная с Windows Vista служба не может показать своё окно на рабочем столе пользователя. За жёсткость правила отвечает параметр NoInteractiveServices в разделе реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Windows, по умолчанию равный единице.
Практический смысл такой: даже всемогущий LocalSystem не видит ваш экран и не может щёлкать по окнам. Программа, запущенная службой, появится в Диспетчере задач, но останется невидимой. Разглядеть распределение по учётным записям и сеансам можно так: нажмите Ctrl+Shift+Esc, откройте вкладку "Подробности", щёлкните правой кнопкой по заголовку любого столбца, выберите пункт "Выбрать столбцы" и отметьте строки "Имя пользователя" и "Сеанс". У служб в столбце "Сеанс" стоит 0, а в столбце "Имя пользователя" – SYSTEM, LOCAL SERVICE или NETWORK SERVICE.
На той же вкладке "Вход в систему" есть флажок "Разрешить взаимодействие с рабочим столом", но при значении NoInteractiveServices равном 1 окнам службы всё равно не дадут показаться.
Раздельные профили дополняют картину. Служба от LocalSystem складывает файлы в systemprofile внутри каталога C:\Windows\System32\config, остальные двое – в собственные папки внутри C:\Windows\ServiceProfiles. Поэтому смена учётной записи службы почти всегда означает переезд настроек: старые файлы остались в профиле прежней учётной записи, и новая о них не знает.
Где посмотреть, от чьего имени работает конкретная служба
Графический путь короткий. Нажмите Win+R, введите services.msc, нажмите Enter, найдите нужную строку и откройте её двойным щелчком. Вкладка "Вход в систему" покажет всё: переключатель "С системной учётной записью" означает LocalSystem, а второй переключатель, с полем имени учётной записи, – остальные варианты, от NT AUTHORITY\LocalService до обычной учётной записи.
Командная строка отвечает одной строкой. Откройте "Терминал Windows" из меню Win+X и выполните:
sc qc SpoolerСтрока SERVICE_START_NAME в выводе назовёт учётную запись: для Spooler это LocalSystem, для Dhcp – NT AUTHORITY\LocalService, для Dnscache – NT AUTHORITY\NetworkService. Запрос выполняется и без прав администратора.
Заодно в том же выводе видно поле BINARY_PATH_NAME с путём к исполняемому файлу. Служба с подозрительным именем от LocalSystem? Первым делом смотрите, что за файл она запускает.
PowerShell удобнее, когда служб много. Команда ниже выведет таблицу со всеми службами, их состоянием и учётными записями:
Get-CimInstance Win32_Service | Select-Object Name, State, StartMode, StartNameА так получится сводка о том, кто держит сколько служб:
Get-CimInstance Win32_Service | Group-Object StartName | Sort-Object Count -Descending | Format-Table Name, CountПервая строка такой сводки почти всегда принадлежит LocalSystem. Данные о выбранной учётной записи хранятся и в реестре, в параметре ObjectName раздела HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ИмяСлужбы, рядом с зашифрованным параметром Password, который защищает подсистема LSASS.
Смена учётной записи службы в services.msc и командой sc config
Причины для смены существуют. Сторонняя программа поставила свою службу под LocalSystem, хотя ей хватает прав обычного пользователя. Или наоборот: службе нужен доступ к сетевой папке, и работать ей положено под выделенной учётной записью домена, а не под компьютером.
В графическом интерфейсе порядок выглядит так:
- Нажмите Win+R, введите services.msc и откройте список служб;
- Откройте свойства нужной службы двойным щелчком и перейдите на вкладку "Вход в систему";
- Переключите режим на второй пункт, с полем имени, нажмите "Обзор..." и выберите учётную запись;
- Введите пароль в поля "Пароль" и "Подтверждение", нажмите "ОК" и перезапустите службу.
Тот же результат из консоли администратора:
sc config ИмяСлужбы obj= "DOMEN\svc-app" password= "S3cret!"Пробел после obj= и password= обязателен, это часть синтаксиса утилиты sc, а не опечатка. Возврат на встроенные учётные записи выглядит ещё проще:
sc config ИмяСлужбы obj= NT AUTHORITY\NetworkService password= ""
sc config ИмяСлужбы obj= LocalSystemПосле смены проверьте результат командой sc qc ИмяСлужбы и перезапустите службу командами sc stop и sc start, потому что новая учётная запись подхватывается только при следующем запуске.
Ошибки проявляются сразу: служба не стартует, а в журнале "Система" появляется запись источника Service Control Manager с кодом 7000 или ошибка 1069 о неудачном входе. Типовые причины: опечатка в пароле, заблокированная учётная запись и отсутствие права "Вход в качестве службы". Назначается оно в оснастке локальной политики безопасности: Win+R, secpol.msc, раздел "Локальные политики", подраздел "Назначение прав пользователя", политика "Вход в качестве службы". Учётную запись нужно добавить в список и сохранить.
Учётные записи системных служб Windows 11 трогать почти никогда не нужно: разработчики уже распределили их по принципу наименьших прав, и перевод DHCP-клиента под LocalSystem ничего не улучшит, а лишь расширит площадь возможного ущерба.
Меньше привилегий, меньше ущерба, принцип наименьших прав для служб
Служба с сетевым портом под LocalSystem – желанная цель: взломав её, злоумышленник получает права SYSTEM без единой дополнительной уязвимости. Перевод такой службы под LocalService или NetworkService не отменяет сам взлом, зато обрезает последствия: нет доступа к SAM и ветке HKEY_LOCAL_MACHINE\SECURITY, нет SE_DEBUG_NAME, нет полного контроля над файлами других пользователей.
Глубже идут собственные идентификаторы служб. У каждой службы Windows есть SID вида NT SERVICE\ИмяСлужбы, и права в списках доступа можно выдавать не учётной записи, а конкретной службе. Показывает его команда:
sc showsid ИмяСлужбыКоманда sc sidtype ИмяСлужбы restricted переводит службу в ограниченный режим, когда в её токене остаётся только собственный SID. Есть и виртуальные учётные записи: если указать в настройках службы локальную учётную запись без пароля, Windows создаст для неё отдельную запись NT SERVICE\ИмяСлужбы с правами обычного пользователя локально и с правами компьютера в сети.
В доменной среде вместо обычной учётной записи с паролем службе лучше подходит управляемая учётная запись службы: одиночная MSA обслуживает один компьютер, групповая gMSA – несколько, а пароль обеим создаёт и регулярно меняет контроллер домена, так что людям его знать не требуется. Механизм появился в Windows Server 2008 R2 и Windows 7 и с тех пор доступен во всех новых версиях.
Перед экспериментами не помешает точка восстановления: Win+R, SystemPropertiesProtection, кнопка "Создать". И загляните на вкладку "Зависимости" в свойствах службы, чтобы не обрушить соседей, которые от неё зависят.
Спокойный вечер со сводкой из PowerShell по списку служб меняет картину быстрее, чем кажется: лишние LocalSystem у сторонних программ видны сразу, а пара команд sc config сужает пути для возможной атаки надёжнее многих настроек безопасности.