Що Може Сказати Подія 4624

Вступ

Кожен соківець знає про подію Security/4624 - успішний вхід в обліковий запис. Ця подія незамінна для аналізу більшості інцидентів, проте також і досить складна: не всі поля відповідають документації, і не всі значення мають сенс. У цьому пості я розповім про деякі особливості цього івент коду та постараюсь описати як отримати максимум контексту від 4624.

Корисні Поля 4624

Подія 4624 генерується на пристрої куди був здійснений вхід, логується за замовчуванням, та записується в реальному часі в Security Event Logs. Якщо ви віддалено зайшли на сервер, то логи аутентифікації потрібно шукати саме на сервері, а не на вашому ПК. Кожна подія містить багато полів, ключовими з яких є:

• New Logon > Security ID:
  Вказує на того хто здійснив вхід на систему у форматі DOMAIN\USER. Якщо DOMAIN збігається з назвою хоста, тоді USER це локальний акаунт.

• New Logon > Logon ID:
  Ідентифікує створену сесію, по якій можна взнати подальші дії користувача. Поле Logon ID також містять багато інших подій, в тому числі й Sysmon.

• Logon Type та Logon Process:
  Вказують на тип входу (2 - інтерактивний, 3 - мережевий, 5 - сервісний, 10 - RDP) та протокол (NTLM, Kerberos). Деталі можна знайти тут.

• Source IP та Workstation:
  Айпі та хостнейм клієнта, що здійснив вхід на систему. Дуже корисні, проте часто оманливі поля. Саме про них ми й поговоримо в наступному розділі.

NLA та Вхід по RDP

Скріншот нижче це результат єдиного входу по RDP з машини SOURCE (10.200.8.42) на машину TARGET (10.200.2.16) на локального адміністратора. Чому ж тоді в логах цілих три події? Відповідь - NLA, механізм безпеки що спочатку аутентифікує вас на рівні мережі, а вже потім пускає на сам хост. NLA увімкнено за замовчуванням, тому раджу розуміти RDP логіни як:

1. Ви передаєте свій логін та пароль з SOURCE до TARGET через мережу (Logon Type 3)
2. На мережевий логін чомусь завжди утворюються дві ідентичні події (Logon Type 3)
3. TARGET валідує ваші дані. Якщо все ОК, передає їх до сервісу RDP (Logon Type 10)

Вхід в Домені

Якщо ж ви входите на доменного, а не локального користувача - будьте готові до п’яти (!) подій на один вхід. Проте, якщо пригадати як працює аутентифікація в домені, тоді послідовність на скріншоті має сенс:

1. Ви передаєте свій логін та пароль з SOURCE до TARGET через мережу (Logon Type 3)
2. TARGET передає дані до домен контролера ADDC, який валідує їх (Logon Type 3)
3. TARGET отримує добро від ADDC, передає управління сервісу RDP (Logon Type 10)

Вхід через Kerberos

Два попередні приклади описували аутентифікацію по NTLM, проте якщо вхід відбувається через Kerberos - послідовність подій буде трошки іншою, як на скріншоті нижче. Зверність увагу на поле src_host (Workstation Name): при аутентифікації через Kerberos ви побачите справжнього хостнейма клієнта (SOURCE), а при Logon Type 10 хостнеймом буде TARGET, а не SOURCE, що не має сенсу з погляду простих користувачів. На жаль, кожен Logon Process сам визначає як йому логувати ваші входи, звідси і розбіжність у вигляді подій 4624.

Поле Workstation

З попередньої секції ви побачили як логується (або не логується) поле Workstation Name. Однак, для аутентифікацій через NTLM це поле може стати ключовим, давайте розберемо як саме.

Ідентифікація Хоста

Уявімо ситуацію: адреса 10.10.10.113, нехай з VPN підмережі, заходить на корпоративний сервер під користувачем Administrator. ІТ команда не признається - потрібно дослідити хто власник IP. Якщо VPN чи DHCP логів немає - перевірка по Workstation Name може стати ледь не єдиним індикатором. З цікавого, якщо у вас в мережі вже є політика найменування хостів - можна навіть зробити правило по типу:

# Або через вайтліст, якщо всі вже дотримуються політики найменування
index=windows EventCode IN(4624, 4625) NOT Workstation_Name IN(CORP-SRV-*, LPT-*, "-")

# Або через блекліст: менш надійно, проте і менше False Positive
index=windows EventCode IN(4624, 4625) Workstation_Name IN(kali, hacker, WIN-*, DESKTOP-*)

Пошук Зловмисника

Якщо ви досліджуєте скомпрометовану мережу де зловмисник використовував тунелювання, як от через Chisel, і через тунельований RDP логінився на хости - тоді зловмисний хостейм пройде скрізь весь тунель та попаде вам в логи, в поле Workstation Name (). В найкращому сценарії ви в один запит index=* hacker-workstation знайдете усі зловмисні входи, незалежно куди і з якої айпі відбувався вхід чи як побудований тунель. Приклади:

# Сценарій 1: Хакер взламав сервер SRV-A з свого хоста під назвою kali.
# Далі він налаштував тунель, та зайшов на SRV-A через тунельований RDP:
Computer: SRV-A
Logon Type: 3
User: Alice
Source Network Address: "::"          # Індикатор: вхід з локалхоста або ::
Workstation Name: kali                # Індикатор: хостнейм не відповідає айпі

# Сценарій 2: Тепер, через тунель на SRV-A (192.168.5.30), хакер заходить на SRV-B.
# Неважливо чи на мережеву теку чи по RDP, індикатор має зберегтись:
Computer: SRV-B
Logon Type: 3
User: Bob
Source Network Address: 192.168.5.30  # Індикатор: вхід з скомпрометованого SRV-A
Workstation Name: kali                # Індикатор: хостнейм знову не відповідає айпі

У Підсумку

Подія 4624 досить цікава: ледь не кожне поле має свої секрети, на один логін може прийти 5 подій, і логування залежить від протоколу аутентифікації. З усім тим, ця подія залишається ключовою для пошуку точки входу та розуміння ланцюжка атаки. Якщо вам цікаво дізнатись більше, рекомендую наступні матеріали:

• Чому також важливо звертати увагу на поле Linked Logon ID
• Чому 4624 на Anonymous Logon - це не завжди привід для паніки
• Як переглянути історію RDP входів навіть без Security логів (!)
• Що означає і як відтворити кожен Logon Type

Цікаві Факти

• Якщо вашу RDP сесію переб’ють з іншої айпі - утвориться подія 4624 з Logon Type 7, проте більшість джерел, в тому числі й Sysmon, можуть далі логувати події вказуючи ваш старий Logon ID.
• За замовчуванням, аутентифікація по айпі адресі працює через NTLM, оскільки Kerberos вимагає вказувати хостнейм. Адміни зазвичай логіняться по хостнеймам, а ось хакери навпаки по айпі - тому аналіз NTLM логінів це гарна ідея для трет хантінгу.