Статья Identity-based атаки: как атакующие используют легитимные учётные записи и как их детектировать

Полгода назад я разбирал инцидент в финансовой компании: lateral movement через 14 хостов, эксфильтрация 2 ТБ данных, время пребывания - 19 дней. CrowdStrike Falcon на endpoint'ах не сгенерировал ни одного алерта. Ноль. Причина: атакующий угнал сервисный аккаунт с domain admin привилегиями и ходил через штатный SMB с легитимными Kerberos-тикетами. Ни вредоносного бинаря, ни C2-канала - чистая identity-based атака. EDR смотрел и молчал, потому что с его точки зрения всё было «нормально».

По данным CrowdStrike Global Threat Report 2025, 75% вторжений в 2024 году опирались на действительные учётные данные. IBM X-Force фиксирует рост credential abuse на 71% год к году. Verizon DBIR 2025 подтверждает: 38% утечек связаны с кражей учётных записей. Три независимых отчёта - одна картина: атакующие не ломают, а входят.

Место identity-based атак в цепочке атаки​

Identity-based атаки - не отдельный этап kill chain, а сквозной вектор, который пронизывает всю цепочку от initial access до exfiltration. Вот как это выглядит на реальных инцидентах:

1. Credential Acquisition - infostealer на personal device сотрудника → credentials попадают на dark web → access broker продаёт готовый доступ
2. Initial Access - Valid Accounts (T1078): атакующий логинится через VPN, OWA или Citrix с валидными credentials
3. Persistence - тот же T1078 работает и как persistence: нет артефактов бэкдоров, аккаунт «просто используется»
4. Lateral Movement - Pass-the-Hash (T1550.002), Pass-the-Ticket (T1550.003), Application Access Token (T1550.001): перемещение под видом легитимного пользователя
5. Privilege Escalation - Kerberoasting, Account Manipulation (T1098): повышение привилегий через AD-механизмы, без эксплуатации уязвимостей ОС
6. Defense Evasion - вся цепочка выполняется штатными инструментами (living off the land), EDR молчит

Forensic-отпечаток минимален. Нет вредоносных хэшей, нет C2-доменов на начальном этапе, нет аномалий в network baseline. По данным CrowdStrike, среднее время lateral movement после initial access - 62 минуты (рекорд - 51 секунда). Чтобы ловить боковое перемещение в таких условиях, нужно смещаться из плоскости сигнатур в плоскость поведенческого анализа. Сигнатуры тут бесполезны - атакующий пользуется теми же инструментами, что и админ.

Откуда берутся credentials: конвейер от infostealer до пентеста​

Прежде чем разбирать техники злоупотребления учётными данными, разберёмся с supply chain украденных credentials. По данным IBM X-Force Threat Intelligence Index 2025, infostealers стали самым распространённым типом malware в 2024 году - 32%, обогнав ransomware. Ежедневно на dark web появляется более 6000 свежих учётных записей (оценка IBM).

Цепочка работает так: Raccoon, RedLine или Lumma заражают personal device сотрудника через пиратский софт или фишинг. Собранные credentials упаковываются в «логи» и выставляются на торговых площадках. Access broker покупает логи и перепродаёт initial access в корпоративные сети. По данным Zero Networks, объявления access brokers выросли на 50% за год, а 54% жертв на ransomware extortion сайтах ранее фигурировали в infostealer-логах. То есть путь от заражённого домашнего ноутбука до ransomware в продакшене - это конвейер, а не случайность.

Три кейса компрометации учётных записей из 2024 года (по данным Push Security) наглядно показывают масштаб:

Snowflake - 165 организаций пострадали от атак с credentials, собранными infostealers начиная с 2020 года. Учётные записи не были защищены MFA. Среди жертв - AT&T и Ticketmaster.

Change Healthcare - атакующий зашёл через Citrix-портал без MFA с украденными credentials. Результат: 6 ТБ украденных данных, нарушение работы системы здравоохранения США, финансовый ущерб - $872 млн, скомпрометированы данные более 100 млн клиентов. Один аккаунт без MFA - и вся медицинская система встала.

Microsoft - APT29 провела password spray по тестовому тенанту без MFA, скомпрометировала тестовое OAuth-приложение с elevated permissions и через него добралась до почтовых ящиков сотрудников. Атаки продолжались весь год с нарастающей интенсивностью. Тестовый тенант. У Microsoft.

Медианное время устранения exposed credentials в GitHub-репозиториях - 94 дня (Verizon DBIR 2025, цитируется по Zero Networks). Три месяца, в течение которых любой может забрать API-ключ или пароль service account. Просто найти и забрать.

Ключевые credential abuse techniques: MITRE ATT&CK mapping и evasion​

Valid Accounts (T1078): credential stuffing и password spraying​

Применимость: внешний пентест - credential stuffing через OWA, VPN-порталы, Citrix. Внутренний пентест - password spraying по AD. Работает на legacy и modern инфраструктуре.

T1078 охватывает четыре подтехники: Default Accounts (.001), Domain Accounts (.002), Local Accounts (.003) и Cloud Accounts (.004). Разграничение по платформе: T1078.004 (Cloud Accounts) - основной вектор initial access в облачных средах (Entra ID, AWS IAM, GCP IAM); платформы - Azure AD, GCP, Google Workspace (подтверждено Atomic Red Team). Для on-premise AD актуальны .002 (Domain) и .003 (Local).

Evasion: password spraying держит количество попыток ниже порога блокировки (обычно 3–5 на аккаунт). Smart lockout в Entra ID частично решает проблему, но on-premise AD с дефолтными lockout policies - лёгкая цель. На практике я встречал домены, где lockout threshold вообще не настроен - бери и спрейся сколько влезет.

Что детектировать:

• Event ID 4625 (неудачный вход) - паттерн «один пароль, много аккаунтов» = password spraying
• Event ID 4624 (успешный вход) после серии 4625 - вероятная компрометация
• В Entra ID: SignInLogs с ResultType != 0 для нескольких UPN с одного IP

Из SigmaHQ: правило proc_creation_win_net_use_password_plaintext.yml детектирует передачу пароля в открытом виде через net use - индикатор использования украденных credentials в on-premise среде.

Pass-the-Hash и Pass-the-Ticket: боковое перемещение без пароля​

Применимость: внутренний пентест. PtH - legacy-инфраструктура с NTLM. PtT - любой AD с Kerberos. На modern-инфрах с отключённым NTLM и Credential Guard PtH значительно затруднён.

Pass-the-Hash: атакующий извлекает NTLM-хэш через LSASS dump или SAM и аутентифицируется без знания пароля. Расшифровка хэша не требуется - хэш и есть аутентификатор. Пароль может быть 40-символьным - не имеет значения.

Pass-the-Ticket включает Golden Ticket (подделка TGT через компрометацию хэша KRBTGT) и Silver Ticket (подделка TGS для конкретного сервиса).

Evasion: PtH через NTLM - операция в памяти, файлов на диске не остаётся. Golden Ticket вообще не обращается к DC для получения TGT (TGT подделан offline), что делает его невидимым для Event ID 4768 на контроллере домена. Но при использовании Golden Ticket для запроса TGS генерируется Event ID 4769 на DC - это и есть основная точка детекта.

Что искать в логах:

• PtH: Logon Type 9 (NewCredentials) - высокоспецифичный артефакт Mimikatz sekurlsa::pth (использует runas /netonly внутри). Более общий индикатор - Event ID 4624 с Logon Type 3 (Network), NTLM authentication package и аномальным source workstation name (Impacket и CrackMapExec любят подставлять случайные строки)
• Golden Ticket: не генерирует Event ID 4768 на DC (TGT подделан offline). Детектируется через Event ID 4769 (TGS Request), для которого отсутствует соответствующий 4768, а также через аномалии в PAC и TicketEncryptionType
• Silver Ticket: не предъявляется DC - Event ID 4769 на контроллере домена не появляется. Детектируется через корреляцию: Event ID 4624 (logon) на целевом сервисе без соответствующих 4768/4769 на DC за тот же интервал, плюс PAC validation

KQL-запрос для Microsoft Sentinel - детект аномального Kerberos TGT lifetime:

SecurityEvent
| where EventID == 4768
| extend TicketLifetime = datetime_diff('hour', TicketExpiration, TimeGenerated)
| where TicketLifetime > 12
| project TimeGenerated, Account, ClientIPAddress, TicketLifetime

Оговорка: аудит Kerberos должен быть включён - Advanced Audit Policy → Account Logon → Audit Kerberos Authentication Service. По умолчанию во многих доменах этот аудит выключен. Это первое, что стоит проверить, и именно тут я чаще всего вижу проблему - правила написаны, а логов для них нет.

Kerberoasting: добыча хэшей сервисных аккаунтов​

Применимость: внутренний пентест, AD любого возраста. Работает с любым доменным аккаунтом без повышенных привилегий.

Атакующий запрашивает TGS для сервисов с SPN, получает зашифрованный тикет и ломает хэш offline. Сервисные аккаунты с паролями уровня Summer2023! - главная цель. И таких аккаунтов в среднем AD десятки, если не сотни.

Evasion: единичный TGS-запрос - легитимная операция Kerberos. Детектируется только по совокупности: массовые запросы + шифрование RC4 (0x17) вместо AES.

SecurityEvent
| where EventID == 4769
| where TicketEncryptionType == "0x17"
| summarize SPNCount = dcount(ServiceName), SPNList = make_set(ServiceName) by Account, ClientIPAddress, bin(TimeGenerated, 5m)
| where SPNCount > 5

Один аккаунт, 5 минут, больше 5 RC4-запросов к разным SPN - Kerberoasting с высокой вероятностью. Легитимный пользователь так себя не ведёт. Никогда.

Контрмера (D3FEND): D3-DAM (Domain Account Monitoring) - мониторинг аномальных паттернов запросов от доменных аккаунтов.

MFA fatigue - Multi-Factor Authentication Request Generation (T1621)​

Применимость: внешний вектор, облачная инфраструктура с push-based MFA (Microsoft Authenticator, Duo без number matching). Против FIDO2/WebAuthn и number matching - не работает.

Атакующий с valid credentials генерирует поток MFA push-уведомлений. Жертва в 3 часа ночи нажимает «Approve», чтобы звонок прекратился. Банально, но работает. По данным Push Security, этот паттерн использовала APT29 при атаке на Microsoft в январе 2024 - пусть и в связке с password spray на тестовый тенант без MFA.

Что детектировать: в Entra ID - SignInLogs с множественными MFA denied/timeout для одного UPN за короткий период. Порог: более 5 MFA-запросов за 10 минут от одного аккаунта.

Golden SAML (T1606.002) и OAuth token abuse (T1550.001)​

Golden SAML - применимость: гибридная инфраструктура с AD FS federation + Azure AD. Платформа: Azure AD - подтверждено тестом Atomic Red Team (тест «Golden SAML», executor: PowerShell, platforms: azure-ad). Компрометация AD FS signing certificate происходит на Windows-сервере, но сама техника T1606.002 эксплуатирует федерацию с облаком; Atomic Red Team тестирует её именно на платформе Azure AD, а не Windows. Для чисто on-premise AD без федерации - техника неприменима.

При компрометации AD FS signing certificate атакующий подделывает SAML-токен для любого пользователя федерации, включая Global Admin. Токен выглядит легитимным, подписан валидным сертификатом. Стандартные средства Entra ID не отличают его от настоящего - детекция возможна только по косвенным признакам: SAML-аутентификация с IP, не принадлежащего AD FS серверу, или аномальные claims. По сути, это master key к облаку, и обнаружить его использование - отдельная головная боль.

Контрмеры (D3FEND): D3-CCSA (Credential Compromise Scope Analysis), D3-CR (Credential Revocation) - ротация AD FS signing certificate, D3-DUC (Decoy User Credential) - ханипот-аккаунты для раннего обнаружения.

OAuth token abuse (T1550.001): атакующий получает OAuth-токен через consent phishing или компрометацию приложения и использует его для доступа к облачным API без повторной MFA. Кейс Microsoft 2024 - именно этот вектор: скомпрометированное тестовое OAuth-приложение с elevated permissions стало мостом к почтовым ящикам.

Account Manipulation (T1098): добавление credentials к service principal, создание federation trusts, добавление в привилегированные роли. Atomic Red Team предоставляет три теста: Admin Account Manipulate, Domain Account and Group Manipulate, Password Change on DSRM Account (все - PowerShell/cmd, Windows).

Sigma-правила из SigmaHQ: azure_tap_added.yml - добавление Temporary Access Pass к аккаунту, azure_pim_change_settings.yml - изменение настроек Privileged Identity Management.

Практическое детектирование: UEBA и слепые зоны SIEM​

Требования к окружению​

📚 Часть контента скрыта. Этот материал доступен участникам сообщества с рангом One Level или выше
Получить доступ просто — достаточно зарегистрироваться и проявить активность на форуме

Зарегистрироваться или Войти

Пункт 5 - моя любимая слепая зона. Сервисные аккаунты, которые создали три года назад «на время», забыли, а они до сих пор имеют domain admin. Таких в среднем домене - штук пять-десять.

Поведенческая аналитика пользователей: что покрывает UEBA​

Сигнатурные правила ловят известные паттерны. Но identity-based атаки тем и опасны, что атакующий действует «как пользователь». UEBA - поведенческая аналитика - закрывает этот разрыв.

Baseline должен покрывать: типичное время входа для каждого пользователя, обычные рабочие станции и IP-адреса, стандартный набор запрашиваемых ресурсов (SPN, файловые шары, приложения), объём и направление передачи данных. Любое отклонение от baseline генерирует аномалию, которую SOC-аналитик оценивает в контексте. Вход в нерабочее время с нового IP - средний приоритет. Тот же вход + bulk TGS-запросы через 10 минут - тут уже пора звонить дежурному.

Чеклист для security engineer​

Что проверить в своей инфраструктуре прямо сейчас:

1. Включён ли Audit Kerberos Authentication Service (GPO → Advanced Audit Policy → Account Logon)
2. Включён ли Audit Kerberos Service Ticket Operations - без этого Kerberoasting невидим
3. Настроен ли сбор AADServicePrincipalSignInLogs в Sentinel (Entra ID → Diagnostic Settings)
4. Есть ли baseline нормального поведения сервисных аккаунтов (время работы, целевые хосты, SPN)
5. Работает ли detection rule на Logon Type 3 с NTLM + аномальный source host (общий индикатор PtH) и Logon Type 9 (Mimikatz-специфичный)
6. Настроен ли алерт на MFA denial rate > 5 за 10 минут для одного UPN
7. Отключён ли RC4 для Kerberos где возможно (AES-only policy через GPO)
8. Используются ли gMSA вместо обычных сервисных аккаунтов с SPN
9. Ротируется ли пароль KRBTGT каждые 180 дней (двойная ротация для инвалидации Golden Ticket)
10. Включён ли number matching для MFA push в Entra ID → Authentication Methods

Три отчёта - CrowdStrike, IBM X-Force, Verizon DBIR - рисуют одинаковую картину: identity стал главным вектором. 75% вторжений, 38% утечек, рост на 71% за год. Но SOC-команды, с которыми я сталкиваюсь на расследованиях, по-прежнему строят детекшн вокруг сигнатур малваря и network anomalies. Десятки правил на Cobalt Strike beacon - и нередко ноль на аномальный Kerberos TGT lifetime. EDR-вендоры рекламируют «identity protection» как фичу, но по факту ловят только самые шумные паттерны - credential stuffing с тысяч IP. Тихий lateral movement через pass-the-ticket с легитимного хоста в рабочее время - слепая зона у большинства SOC.

Разрыв между identity-атаками и identity-детектом будет расти. Machine identities - service accounts, API tokens - уже составляют более 70% networked identities (по данным Zero Networks), при этом 51% workload identities полностью неактивны, а мониторят их единицы. Атакующие это знают. Следующая волна инцидентов уровня Snowflake придёт не через user accounts, а через забытые service principals с избыточными permissions и паролями, которые не менялись с момента создания. Если в вашем SIEM нет ни одного правила из этого материала - начните с двух: Kerberoasting (RC4 TGS bulk requests, Event ID 4769) и аномальный TGT lifetime (Event ID 4768, порог 12 часов). Это 20 минут на настройку и два закрытых blind spot. Проверьте пункты 1 и 2 из чеклиста прямо сейчас - если аудит Kerberos выключен, все остальные правила бессмысленны.