Понедельник, 9:15. Аудит AD-инфраструктуры среднего банка - 12 контроллеров домена, 4 000 пользователей, позиция заказчика: «у нас всё под контролем». Через два часа работы с PowerShell и BloodHound граф показал 847 сервисных аккаунтов. Из них 312 с зарегистрированным SPN, 94 сидят в Domain Admins, а у 23 пароль не менялся более пяти лет. Каждый такой аккаунт - готовая мишень для Kerberoasting с последующим lateral movement через Pass The Hash(T1550.002). Контролировало их ноль человек: аккаунты создавали подрядчики, уволившиеся инженеры и «временные» интеграции, ставшие постоянными. В одном постмортеме по похожей инфраструктуре скомпрометированный сервисный аккаунт с правами Domain Admins дал атакующему полный доступ к базам клиентов - а это уже не просто инцидент, а риск оборотных штрафов по 152-ФЗ.
Service account sprawl Active Directory: масштаб проблемы
Service account sprawl - неконтролируемое разрастание учётных записей служб. Организация теряет видимость: кто создал аккаунт, зачем он нужен, какие привилегии ему реально требуются и используется ли он вообще. По данным Obsidian Security, типичная организация имеет в 10–20 раз больше сервисных аккаунтов, чем пользовательских, и у большинства ИБ-команд нет полной картины этого зоопарка.
Сервисные аккаунты в Active Directory делятся на типы с принципиально разным профилем риска:
| Тип аккаунта | Область действия | Ротация пароля | Типичная проблема |
|---|---|---|---|
| Локальный сервисный | Один сервер | Ручная (часто никогда) | Локальные admin-права, foothold для privesc |
| Доменный сервисный | Весь домен AD | Ручная (часто никогда) | Избыточные привилегии, Kerberoasting |
| sMSA (Standalone MSA) | Один сервер | Автоматическая (30 дней) | Ограничение: один сервер на аккаунт |
| gMSA (Group MSA) | Группа серверов | Автоматическая (30 дней) | Низкий adoption, legacy не поддерживает |
Jerry из Microsoft в серии AD Hardening формулирует прямо: «Placing service accounts in the Domain Admins group is a textbook example of not adhering to the principle of least privilege. This was sometimes done out of convenience and other times due to a lack of clarity regarding the application's true requirements.»«Размещение служебных учетных записей в группе администраторов домена — это классический пример несоблюдения принципа минимальных привилегий. Иногда это делалось из соображений удобства, а иногда из-за недостаточной ясности в отношении истинных требований приложения». Знакомо, правда? После развёртывания приложения «right-size» привилегии его сервисного аккаунта - задача из категории «все знают, что надо, но никто не делает». Но делать придётся.
С точки зрения MITRE ATT&CK, компрометация сервисного аккаунта - Valid Accounts (T1078 / Persistence / Privilege Escalation / Defense Evasion). Почему именно сервисные аккаунты так опасны: у них нет рабочих часов, географических паттернов, отпусков. Поведенческие алерты, заточенные под людей, на них не срабатывают. Активность атакующего через скомпрометированный сервисный аккаунт неотличима от легитимной автоматизации.
И вот что особенно неприятно: любой аутентифицированный доменный пользователь может перечислить все SPN в домене стандартными средствами - без каких-либо повышенных привилегий. Сервисный аккаунт с Domain Admins и паролем пятилетней давности - находка не только для внешнего атакующего, но и для обиженного сотрудника.
По данным ALP ITSM (Habr), 39% инцидентов ИБ связаны с привилегированными учётными записями - администраторов доменов, сервисных аккаунтов, администраторов прикладного ПО. Сервисные аккаунты в этой статистике - самая «тихая» категория, потому что их компрометацию обнаруживают позже всех.
Инвентаризация сервисных аккаунтов AD
Первый шаг аудита - ответить на вопрос «сколько их и что каждый делает». Без этого ответа никакой least privilege для сервисных аккаунтов невозможен.Требования к окружению
- ОС: Windows Server 2016+ или Windows 10/11 с модулем ActiveDirectory PowerShell (входит в RSAT)
- RAM: минимум 4 ГБ для PowerShell-инвентаризации; 8 ГБ если планируется BloodHound CE с импортом данных домена 4 000+ объектов
- Права: минимум Domain User для запроса SPN; для полного аудита атрибутов
PasswordLastSet,LastLogonTimestampи членства в группах - учётная запись с правами чтения на целевые OU - Инструменты: PowerShell модуль
ActiveDirectory, BloodHound CE + SharpHound (коллектор, последний стабильный релиз) - Сеть: доступ к контроллеру домена по LDAP (TCP 389/636)
Код:
Get-ADUser -Filter {ServicePrincipalName -ne "$null"} -Properties `
ServicePrincipalName, PasswordLastSet, Enabled, MemberOf |
Select-Object Name, Enabled,
@{N='PasswordAgeDays';E={if($_.PasswordLastSet){(New-TimeSpan -Start $_.PasswordLastSet).Days}else{'N/A'}}},
@{N='SPN';E={$_.ServicePrincipalName -join '; '}},
@{N='InDomainAdmins';E={($_.MemberOf -match 'Domain Admins').Count -gt 0}} |
Sort-Object PasswordAgeDays -Descending |
Export-Csv -Path .\svc_accounts_audit.csv -NoTypeInformationPasswordAgeDays > 365 и InDomainAdmins = True - критические находки, с которых начинается ремедиация.Для обнаружения заброшенных сервисных аккаунтов проверяем
LastLogonTimestamp. Аккаунт, не аутентифицировавшийся 90+ дней, с высокой вероятностью никому не нужен - но перед отключением стоит проверить, не привязан ли он к задачам в планировщике или пулам IIS, которые запускаются раз в квартал. Был случай: отключили «мёртвый» аккаунт, а он дёргал бэкап SAP раз в 90 дней. Неприятно.Для визуализации путей эскалации через сервисные аккаунты - BloodHound CE с коллектором SharpHound. Запуск:
SharpHound.exe --CollectionMethods All --OutputDirectory C:\BH --Domain corp.local. В интерфейсе BloodHound Cypher-запрос MATCH (u:User {hasspn:true})-[:MemberOf*1..]->(g:Group) WHERE g.name CONTAINS 'ADMIN' RETURN u,g покажет все SPN-аккаунты с путём до административных групп. Именно эти аккаунты - приоритет номер один.Grey box: приоритеты с выданными кредами
В реальных пентестах grey box - стандартный сценарий. Если выданы low-privileged учётные данные, полная инвентаризация сервисных аккаунтов всё равно доступна: SPN-запросы в AD открыты любому аутентифицированному пользователю домена. На этом и строится Kerberoasting - никаких повышенных привилегий для запроса TGS-билета не нужно.Что проверить первым с low-priv кредами:
- Запрос всех SPN в домене через
setspn -Q [I]/[/I]или LDAP-фильтр - Анализ членства SPN-аккаунтов в привилегированных группах (через
net group "Domain Admins" /domainили BloodHound) - Проверка поддержки RC4 в Kerberos-билетах - если аккаунт принимает RC4, он уязвим для офлайн-перебора
msDS-SupportedEncryptionTypes для каждого SPN-аккаунта, аудит SACL на критические OU, и ревизия User Rights Assignment на контроллерах домена. Последнее - отдельная история: там часто валяются делегации дефункт-аккаунтов, накопленные с момента первого промоушена DC. Годами никто не чистит.Kerberoasting и привилегированные сервисные аккаунты
Kerberoasting - одна из самых результативных техник постэксплуатации в AD. Механика простая: любой аутентифицированный пользователь запрашивает TGS-билет для произвольного SPN, билет шифруется хешем пароля сервисного аккаунта. Пароль слабый - атакующий ломает его офлайн. Место в kill chain: Valid Accounts (T1078, Initial Access) -> Kerberoasting -> получение пароля сервисного аккаунта -> Pass the Hash (T1550.002, Lateral Movement) при наличии NTLM-хеша или прямое использование учётных данных.Detection: правила корреляции для SIEM
Ключевой EventID - 4769 (A Kerberos service ticket was requested) с типом шифрования 0x17 (RC4-HMAC). Массовый запрос TGS-билетов с одного аккаунта за короткий период - аномалия, которая должна генерировать алерт.В репозитории SigmaHQ (github.com/SigmaHQ/sigma) для техники T1550.002 доступно 6 правил детекции, включая
win_security_potential_pass_the_hash.yml и win_security_pass_the_hash_2.yml. Для T1078 (Valid Accounts) - 116 правил, среди которых proc_creation_win_net_use_password_plaintext.yml для обнаружения передачи паролей в открытом виде.Базовая логика корреляции для обнаружения Kerberoasting:
Код:
# Псевдоправило для SIEM (Sigma-style)
title: Potential Kerberoasting - Mass TGS Request
detection:
selection:
EventID: 4769
TicketEncryptionType: '0x17' # RC4-HMAC
Status: '0x0' # Success
timeframe: 5m
condition: selection | count(ServiceName) by IpAddress > 10
level: highЕщё один момент: стоит мониторить LOLBAS-утилиту
Cmdkey.exe (категория Credentials, маппинг на T1078 в проекте LOLBAS) - она управляет сохранёнными учётными данными и может использоваться атакующим для перечисления кэшированных кредов на скомпрометированном хосте.gMSA managed service accounts: путь к автоматической ротации
Group Managed Service Accounts - ответ Microsoft на проблему статических паролей. Пароль gMSA генерируется автоматически (120 символов / 240 байт), ротируется каждые 30 дней, ни один человек его не знает. Аккаунт привязывается к группе серверов, которым разрешено его извлекать.
| Критерий | Традиционный аккаунт | gMSA | Облачный (Azure SP) |
|---|---|---|---|
| Ротация пароля | Ручная (часто никогда) | Автоматическая (30 дней) | Автоматическая (сертификаты) или ручная (секреты) |
| Длина пароля | Зависит от политики (8–16 символов) | 120 символов (240 байт) | N/A (токены/сертификаты) |
| Kerberoasting risk | Высокий при RC4 | Минимальный | Неприменимо |
| Legacy-совместимость | Полная | Частичная | Нет (другая среда) |
| Минимальный функц. уровень домена | Любой | Windows Server 2012 | N/A |
Ограничения gMSA, о которых стоит знать до миграции:
- Не все приложения поддерживают gMSA. Классика из аудитов: ERP-системы с собственным механизмом аутентификации, требующие пароль в конфигурационном файле. Для таких случаев - длинный пароль (25+ символов), принудительное AES и мониторинг через SIEM. Не идеально, но хотя бы управляемо.
- Требуется KDS Root Key. Проверка:
Get-KdsRootKey. Создание в тестовой среде:Add-KdsRootKey -EffectiveTime ((Get-Date).AddHours(-10)). - Один gMSA - одна служба. Не объединяйте несколько приложений под одним gMSA: это нарушает принцип минимальных привилегий AD. Соблазн велик, но потом разгребать дороже.
Код:
New-ADServiceAccount -Name 'gMSA_SQLBackup' `
-DNSHostName 'gMSA_SQLBackup.corp.local' `
-PrincipalsAllowedToRetrieveManagedPassword 'SQLServers_Group'
# На целевом сервере:
Install-ADServiceAccount -Identity 'gMSA_SQLBackup'Управление сервисными аккаунтами в облаке: Azure AD и AWS IAM
Sprawl сервисных аккаунтов не ограничивается AD. В гибридных инфраструктурах появляются дополнительные классы IAM-идентичностей, и там свой зоопарк.Сервисные аккаунты Azure AD (Entra ID Service Principals) - типичная ошибка: client secret с многолетним сроком действия, де-факто постоянный пароль. Аудит через Microsoft Graph API: запрос
/applications с проверкой поля passwordCredentials[].endDateTime. Секреты со сроком более 6 месяцев - кандидаты на замену сертификатной аутентификацией.AWS IAM Users с access keys - AWS даёт STS для временных credentials, но на практике остаются IAM-пользователи с постоянными access key, созданными годы назад. AWS IAM Access Analyzer помогает обнаружить unused permissions. Помогает - если его кто-то запустит.
OAuth-токены между SaaS-приложениями - наименее видимый слой. По данным Obsidian Security, эти токены «created by business users, invisible to security teams» и представляют вектор, через который атакующий может оперировать от имени критичных интеграций. Refresh-токены OAuth существуют бессрочно, работая независимо от SSO и MFA. Вдумайтесь: MFA включили, SSO настроили, а токен, созданный маркетологом для интеграции CRM с рассылкой, живёт своей жизнью.
Ключевое отличие облачного аудита от AD: в облаке нет единого
Get-ADUser, каждая платформа требует свой инструмент. Для Azure - Get-AzADServicePrincipal или Graph API. Для AWS - aws iam list-users в связке с aws iam list-access-keys. Первый аудит почти всегда делается руками, унификация через CSPM-решения - следующий этап.Чеклист аудита сервисных аккаунтов для передачи в эксплуатацию
Каждый пункт - конкретное действие с командой или настройкой. Формат рассчитан на передачу сисадмину или включение в отчёт по аудиту.- Полная инвентаризация SPN-аккаунтов:
Get-ADUser -Filter {ServicePrincipalName -ne "$null"}, сохранить результат. Повторять ежемесячно. - Выявить аккаунты с паролем старше 365 дней: фильтр
PasswordLastSet< (текущая дата - 365). Каждый такой аккаунт - критическая находка. - Проверить членство SPN-аккаунтов в Domain Admins, Enterprise Admins, Schema Admins: ни один сервисный аккаунт не должен входить в эти группы без документированного обоснования.
- Перевести совместимые службы на gMSA: приоритет - аккаунты с SPN и членством в привилегированных группах. Для несовместимых - пароль 25+ символов и AES:
Set-ADUser -Identity svc_account -KerberosEncryptionType AES256. - Отключить RC4 для Kerberos где возможно: в контексте плана Microsoft по отказу от RC4 (advisories 2024–2026) рекомендуется миграция на AES. Проверка: атрибут
msDS-SupportedEncryptionTypes. - Настроить мониторинг EventID 4769 с TicketEncryptionType 0x17: пороговый алерт - более 10 уникальных SPN-запросов с одного IP за 5 минут.
- Отключить неиспользуемые аккаунты:
LastLogonTimestamp> 90 дней. Перед отключением - проверить привязку к задачам планировщика, пулам IIS и периодическим процессам. - Документировать каждый сервисный аккаунт: владелец, приложение, необходимые привилегии, дата последнего review. Без документации sprawl вернётся через полгода.
- Облачные среды: Azure AD Service Principals с client secret > 6 месяцев, AWS IAM Users с access keys > 90 дней - мигрировать на сертификатную аутентификацию и STS.
- Периодический review: раз в квартал - повторная инвентаризация по пунктам 1–9 с фиксацией delta.
Каждый аудит сервисных аккаунтов, который я проводил за последние несколько лет, начинался с одной и той же фразы заказчика: «Мы точно знаем все наши сервисные аккаунты». И каждый раз реальное количество превышало ожидаемое в 3–5 раз. Часть создавали подрядчики, которые давно ушли. Часть - инженеры, тестировавшие интеграцию, которая не пошла в прод. Часть - «временные» решения, пережившие три реорганизации.
В кампании SolarWinds (Nobelium/UNC2452), по данным CISA и Mandiant, использовались техники Golden SAML и компрометация service principals в Azure AD для persistent access и lateral movement - без срабатывания алертов, рассчитанных на поведение людей. D3FEND-фреймворк (MITRE) рекомендует для противодействия T1078 комбинацию Domain Account Monitoring (D3-DAM) и Access Modeling (D3-AM) - построение baseline нормального поведения каждой сервисной идентичности. Без этого baseline любой привилегированный сервисный аккаунт - blind spot, который атакующий найдёт раньше, чем SOC.
Организации, которые начинают наводить порядок в сервисных аккаунтах только после инцидента, платят в разы дороже - и деньгами, и репутацией. На codeby.net есть тред по мониторингу аномалий сервисных аккаунтов в AD, где обсуждают пороговые значения для EventID 4769 под разную плотность SPN в домене - полезно сверить подходы, если калибруете правила под свою среду.
Последнее редактирование модератором:
