Короткий ответ

Подозрительный вход — это факт сессии, а не спор с Иваном в мессенджере. На WS-042 и контроллере снимите Event ID 4624/4625 (Logon Type, Source Network Address, TargetUserName, Logon ID). На host.example — last, lastb, journalctl -u ssh. Запишите IP (10.0.10.55 как плейсхолдер источника), время UTC и локальное, Logon ID. Затем блокируйте учётку ivan.petrov и отзовите живые сессии. Журналы не чистите, ПК не «лечите», пока не снята копия.

Если учётка привилегированная — сразу компрометация администратора. Первые минуты — чеклист 15 минут.

Симптомы и как отличить

Типичная картина:

  • SIEM/Defender: «unfamiliar sign-in», «impossible travel», ночной 4624 Type 10 на WS-042;
  • сам ivan.petrov клянётся, что ноут был закрыт;
  • на Linux host.example в last есть accepted password с 10.0.10.55;
  • параллельно открыт Outlook или VPN с другого ASN.
Что видноСкорее не компрометацияКуда смотреть
4624 Type 7 (unlock) с консоликоллега разбудил ПКфизический доступ, не сеть
4624 Type 3 с файлового сервералегитимный SMBlateral movement только если шара admin$
Failed 4625 пачкой, Success нетbrute без успехаbrute force
Success + чужой IP + новые правила почтысессия живаящик взломан

Возможные причины

От частых к редким:

  1. Украден пароль (reuse, фишинг, слив) и вход по RDP/VPN/SSH без MFA.
  2. Легитимный вход с нового кафе/LTE, который сработал как алерт.
  3. Сохранённая сессия RDP/SSH, которую перехватили на общем jump.
  4. Service account с интерактивным логоном: скрипт, а не человек.
  5. Компрометация самой рабочей станции: логон локальный, а «чужой» уже внутри.
  6. Редко: ошибка часов/репликации DC, из‑за которой SIEM склеивает чужие события.

Не выдумывайте CVE на winlogon.exe как обязательную причину. Пока нет хеша и дерева процессов — это инцидент учётки, не 0-day.

Диагностика

Работайте с чистой админ-станции, не с того же WS-042, если он под подозрением. Подставьте свои имена вместо плейсхолдеров.

1. Карточка события на Windows

$start = (Get-Date).AddHours(-48)
Get-WinEvent -ComputerName 'WS-042' -FilterHashtable @{
  LogName = 'Security'
  Id = 4624, 4625, 4648, 4672
  StartTime = $start
} | Where-Object { $_.Message -match 'ivan\.petrov' } |
  Select-Object TimeCreated, Id, @{n='Xml';e={$_.ToXml()}} |
  Out-File -FilePath C:\IR\WS-042-logon.txt -Encoding utf8

В XML 4624 смотрите: TargetUserName, LogonType (2 интерактив, 3 сеть, 8 network-cleartext, 10 RemoteInteractive), IpAddress / Source Network Address, LogonId, Elevated Token / 4672 рядом.

На DC (учётные логоны Kerberos):

Get-WinEvent -ComputerName 'DC01' -FilterHashtable @{
  LogName = 'Security'
  Id = 4768, 4769, 4771, 4776
  StartTime = $start
} | Where-Object { $_.Message -match 'ivan\.petrov' } |
  Select-Object TimeCreated, Id -First 40

2. Linux SSH на host.example

sudo last -F ivan.petrov
sudo lastb -F | head
sudo journalctl -u ssh --since '48 hours ago' | grep -E 'ivan.petrov|10.0.10.55'
ss -tnp | grep -E 'sshd|10.0.10.55' || true
who

Accepted publickey с неизвестного ключа — не «просто VPN». Снимайте authorized_keys.

3. Живые сессии

query user /server:WS-042
Get-RDUserSession -ErrorAction SilentlyContinue
sudo loginctl list-sessions
sudo w

4. Что сделали после входа

Коротко: новые 4688, 4698, 4728 на Windows; sudo, scp, правки /etc на Linux. Это уже неизвестный процесс и смена учёток, но таймлайн начните здесь. Копии журналов — сохранение артефактов.

Решение

Сценарий A. Вход подтверждён как чужой

  1. Отзовите сессии: logoff на WS-042, loginctl terminate-user ivan.petrov на host.example, обрыв VPN.
  2. Заблокируйте учётку:
Disable-ADAccount -Identity 'ivan.petrov'
Get-ADUser 'ivan.petrov' -Properties Enabled, LockedOut, LastLogonDate, PasswordLastSet
sudo passwd -l ivan.petrov
sudo usermod -L ivan.petrov
  1. Смените пароль/ключ из другого канала (звонок, второй фактор helpdesk), не письмом на тот же ящик.
  2. Проверьте почтовые правила и MFA — ящик.
  3. Если были права админа — привилегированная учётка.

Сценарий B. Похоже на ложное срабатывание

Не разблокируйте «на глаз». Сверьте: устройство пользователя, DHCP-аренда его ноутбука, VPN-учётка, MFA success. Если Иван был в офисе, а IP — хостинг-провайдер, это не «Wi‑Fi кафе». Оставьте блок до сверки с человеком по телефону из кадровой карточки, не из подписи письма.

Сценарий C. Сервисная учётка

Интерактивный логон svc-* с 10.0.10.55 — инцидент. Заблокируйте, найдите расписание задания, не возвращайте пароль в тот же скрипт в открытом виде.

Как проверить, что проблема устранена

  • Get-ADUser ivan.petrov показывает Enabled : False (или сознательно включён после смены секрета и проверки).
  • Нет новых 4624/Accepted с того же чужого IP после блока.
  • query user / who без сессии атакующего.
  • Журналы на месте: Security не 1102, journalctl не пустой.
  • Пользователь входит только после выдачи нового пароля/ключа по регламенту и с MFA, если она была включена.
Get-WinEvent -ComputerName 'WS-042' -FilterHashtable @{ LogName='Security'; Id=4624; StartTime=(Get-Date).AddHours(-2) } |
  Where-Object { $_.Message -match 'ivan\.petrov' }

Если не помогло

  • Учётка снова Enabled без вашей заявки — ищите, кто в Domain Admins сбросил флаг, это уже админ скомпрометирован.
  • После Disable всё равно SMB Type 3 — жив NTLM-хеш/билет; нужны смена пароля, репликация DC и проверка Kerberos.
  • Linux: passwd -l не трогает ключ в ~/.ssh/authorized_keys — уберите чужие ключи.
  • Hybrid Entra: on-prem Disable не отзывает облачный refresh token — нужен revoke в тенанте.
  • Нет 4624 вообще — аудит логонов выключен; фиксируйте это как пробел, не как «инцидента не было».

Профилактика

  • MFA на VPN, RDP-шлюз и SSH по ключу, не пароль на WAN.
  • Алерт: 4624 Type 10 с не-корпоративного ASN; Accepted password на host.example.
  • Разделение daily-drive и admin-ID: повседневный вход не Domain Admin.
  • Централизация Security и journal, иначе ночной логон перетрётся.
  • Запрет интерактивного логона для служебных учёток.

FAQ

Можно ли сразу сменить пароль, не блокируя?

Блок быстрее отрезает параллельные сессии. Смена без Disable оставляет окно, пока DC реплицируют хеш. Делайте оба шага, блок — первым, если атака активна.

Стоит ли выключать WS-042?

Нет, пока не сняли память и журналы. Сеть отключают, питание оставляют — изоляция.

IP из той же подсети 10.0.10.0/24 — это свой?

Это только «кто-то в LAN или с VPN». Снимите DHCP lease и MAC. Внутренний IP не делает вход легитимным.

Нужно ли сразу krbtgt?

Нет, для рядового ivan.petrov достаточно блока и смены пароля. krbtgt — если есть признаки подделки билетов привилегированных учёток.

Пользователь просит «просто разблокировать, мне работать»

Работайте через временную новую учётку или после смены секрета и проверки логов. Возврат старого пароля — повтор инцидента.