ФЕВРАЛЬ. Service accounts: как забытая учётная запись превращается в путь по сети

Сервисная учётная запись редко привлекает внимание, пока приложение работает. Пароль не спрашивает пользователь, MFA обычно не всплывает на экране, а смена секрета может казаться риском для стабильности. Именно поэтому такие аккаунты живут годами, получают лишние права и переходят из проекта в проект. Для атакующего это удобная точка опоры: учётная запись выглядит штатно и часто уже имеет доступ к нескольким системам.

 

Начните с одного аккаунта

Выберите один привилегированный service account. Не пытайтесь сразу почистить весь каталог. Ответьте на пять вопросов: кто владелец, какое приложение использует учётку, где хранится секрет, какие у неё права и когда секрет менялся в последний раз. Если хотя бы на два вопроса ответа нет, перед вами не техническая мелочь, а управленческий долг.

 

Пароль — не единственный риск

Сильный пароль важен, но недостаточен. Проблемой становятся общий секрет между сотрудниками, хранение в скриптах, невозможность быстро отозвать доступ, отсутствие ротации, интерактивный вход там, где он не нужен, членство в лишних группах и отсутствие контроля за использованием. Где возможно, лучше переходить к управляемым сервисным учётным записям или автоматической ротации секретов.

 

Что показал Sinobi

В одном из расследований Cisco Talos IR за Q2 2026 операторы Sinobi ransomware получили слабый пароль service account из дампа ntds.dit. После подбора пароля учётная запись использовалась для бокового перемещения через RDP и WinRM. Дальше злоумышленники развернули ransomware по домену через GPO. Урок не в том, что RDP плох, а в том, что забытая сервисная учётка с широкими правами превращает компрометацию домена в маршрут.

 

Проверка пройдена, если

Учётная запись имеет конкретного владельца и назначение, секрет не разделяется между людьми, права минимальны, интерактивный вход запрещён или обоснован, использование логируется, а смена секрета не требует ручного поиска по десятку конфигурационных файлов. Для критичных учёток определён способ аварийного отзыва.

 

Что мониторить

Важно видеть входы в нетипичное время, с нетипичного хоста, интерактивные сессии сервисной учётки, неожиданное использование RDP/WinRM/SMB, новые сервисы и изменения групп. Даже без сложной аналитики такой набор даёт шанс заметить, что аккаунт перестал вести себя как сервисный.

 

Как это связано с решениями Смарт-Софт

Основная работа с service-аккаунтами — это процесс учёта, ротации и контроля прав, который не сводится к одному продукту. Если в инфраструктуре используется Pereluk, его естественная роль — корреляция нетипичного использования учётных записей с другими событиями безопасности. Это позволяет заметить, что сервисный аккаунт перестал вести себя как сервисный.

 

Что сделать сегодня

• Выбрать один привилегированный service account.
• Зафиксировать владельца, права, места использования и возраст секрета.
• Проверить, можно ли запретить интерактивный вход и включить ротацию.

  

Источники

• Cisco Talos Incident Response. IR Trends Q2 2026. Кейс Sinobi ransomware.
• Microsoft Learn. Managed Service Accounts / group Managed Service Accounts.

 

Последняя техническая проверка: 14.10.2026.