Как посмотреть кто подключался к компьютеру по rdp

Удалённый доступ по протоколу RDP (Remote Desktop Protocol) – один из самых частых каналов компрометации рабочих станций и серверов под управлением Windows. Если к компьютеру уже получили доступ злоумышленники, следы почти всегда остаются в системных журналах: там фиксируются IP‑адреса, имена учётных записей, время входа и способ аутентификации. Анализ этих данных позволяет точно установить, кто, когда и с какого узла подключался, даже если сессия была короткой или уже завершена.

Ключевой источник информации – журнал Security и ветка Microsoft-Windows-TerminalServices-RemoteConnectionManager в Event Viewer. События с идентификаторами 4624, 4625, 4634 и 4778 показывают успешные и неудачные попытки входа, отключения и повторные подключения по RDP. Сравнивая эти записи с сетевыми логами и временными зонами, можно определить, использовалась ли локальная учётная запись, доменная или сохранённые учётные данные, а также выявить автоматизированные переборы паролей.

Практический результат такого анализа – не просто список подключений, а основа для принятия мер защиты. Если обнаружен вход с неизвестного IP или в нерабочее время, стоит немедленно сбросить пароли, включить Network Level Authentication, ограничить доступ по брандмауэру и активировать двухфакторную аутентификацию. Дополнительно полезно сохранить логи и экспортировать их в SIEM или хотя бы в отдельный файл, чтобы иметь доказательную базу при расследовании инцидента.

Где в Windows найти журнал входов пользователей по RDP

Основной источник данных о RDP‑входах – журнал событий Windows: откройте «Просмотр событий» → «Журналы Windows» → «Безопасность» и отфильтруйте события с идентификаторами 4624 (успешный вход) и 4634 (выход), обращая внимание на поле «Тип входа = 10», которое однозначно указывает на сеанс удалённого рабочего стола; дополнительно полезны 4778 (переподключение к сеансу) и 4779 (отключение), позволяющие восстановить точное время активности пользователя.

Ветка «Приложения и службы журналов» → «Microsoft» → «Windows» → «TerminalServices‑RemoteConnectionManager» → «Operational» фиксирует установление и разрыв RDP‑соединений на уровне службы, где события 1149 и 1150 содержат имя учётной записи и IP‑адрес клиента; для корреляции с аутентификацией сопоставляйте их с записями из «Безопасности», чтобы отличить неудачные попытки от реальных входов и выявить подмену учётных данных.

В «Microsoft» → «Windows» → «TerminalServices‑LocalSessionManager» → «Operational» находятся события 21, 24 и 25, отражающие создание, вход и выход из локальных RDP‑сеансов, что особенно важно на серверах с несколькими одновременными подключениями; если журналы пусты, включите их через «Включить журнал» в контекстном меню раздела, после чего перезапустите службу RDP для немедленного начала записи.

Какие события Event Viewer показывают успешные и неудачные RDP-подключения

Внутри 4624 ориентируйтесь на поля Account Name, Account Domain, Source Network Address и Workstation Name: первый блок покажет учетную запись, второй – из какой сети пришли, а пара Process Name и Authentication Package (обычно Negotiate или Kerberos) поможет отличить вход через RDP‑службу от прокси‑переадресаций.

События 4625 дополнительно содержат Status и Sub Status, по которым определяется причина отказа: например, 0xC000006A указывает на неверный пароль, 0xC0000064 – несуществующего пользователя, 0xC0000234 – заблокированную учетную запись; массовые повторения с одного IP – явный признак перебора.

Для детализации сессий используйте журналы Applications and Services Logs → Microsoft → Windows → TerminalServices‑LocalSessionManager и … → TerminalServices‑RemoteConnectionManager: здесь Event ID 21 и 25 фиксируют начало интерактивной RDP‑сессии, 24 – разрыв, а 1149 в RemoteConnectionManager подтверждает успешную аутентификацию до открытия сеанса.

Практический фильтр выглядит так: в Security включите XPath или обычный фильтр по (EventID=4624 or EventID=4625) и LogonType=10, затем в терминальных журналах добавьте EventID=21,24,25,1149 для сопоставления факта входа с жизненным циклом RDP‑сеанса.

При расследовании инцидентов выстраивайте цепочку по времени: 4625 → 1149 → 4624 → 21 → 24, чтобы увидеть попытки, успешную аутентификацию, старт и завершение сессии; если 4624 есть без 21, проверяйте NLA и шлюзы, а отсутствие 1149 при наличии 4624 часто указывает на вход через локальные политики или проброс портов.

Как по Event ID 4624 определить учетную запись и IP-адрес входа

IP‑адрес источника берется из блока Network Information: поле Source Network Address и, при наличии, Source Port. Для IPv6 проверяй, не преобразован ли адрес в IPv4‑mapped (::ffff:). Если адрес пустой, значит вход локальный или через переадресацию – ищи связанное событие 4624 с тем же Logon ID и заполненным IP, либо смотри Event ID 4778 (переподключение RDP). Для фильтрации в Event Viewer используй запрос по Event ID = 4624 и Logon Type = 10, затем сортируй по времени и экспортируй нужные записи в XML, чтобы сохранить связки Account Name ↔ Source Network Address без потерь.

Как отличить локальный вход от удаленного сеанса RDP в логах

Для подтверждения источника используйте поля Source Network Address и Workstation Name. При локальном входе IP часто пустой, - или 127.0.0.1, а имя станции совпадает с именем хоста; при RDP будет внешний или внутренний IP клиента и имя его компьютера, что сразу отличает удалённый доступ.

Сверяйте Account Name и Target Logon ID с событиями 4672 (выдача привилегий) и 4634/4647 (выход). Связка одинаковых Logon ID позволяет проследить полный жизненный цикл конкретного сеанса и увидеть, был ли он инициирован удалённо.

• 4624 с Logon Type 2 → физический пользователь за консолью.
• 4624 с Logon Type 10 → удалённый сеанс.
• 4778 → переподключение к существующему RDP-сеансу.
• 4779 → корректное отключение RDP-сеанса.

Обращайте внимание на поля Authentication Package и Logon Process: для RDP типичны Negotiate/Kerberos и процесс User32, тогда как локальный вход чаще проходит через Winlogon. Несоответствие этих значений с Logon Type – индикатор нестандартной схемы доступа.

Если используется NLA, дополнительно появятся события 1149 в журнале TerminalServices-RemoteConnectionManager с именем пользователя и IP ещё до создания сеанса – это ускоряет атрибуцию попыток удалённого входа, даже если аутентификация затем провалилась.

1. Сначала отфильтруйте 4624 по дате и пользователю.
2. Отсортируйте по Logon Type и исключите тип 3.
3. Сопоставьте IP и имя рабочей станции.
4. Проверьте 4778/4779 и 1149 для RDP.
5. Закройте цепочку событиями выхода по Logon ID.

Для массового анализа выгружайте логи в CSV и строите сводку по столбцам Logon Type, Source Network Address и Account Name: пики по типу 10 с повторяющимися IP быстро выявляют удалённых операторов, а тип 2 без IP подтверждает физическое присутствие за ПК.

Как получить список всех RDP-сеансов за выбранный период

Для точного отбора RDP‑подключений за нужные даты используется журнал безопасности Windows, где события входа фиксируются с типом Logon Type 10 (RemoteInteractive); в Event Viewer путь выглядит как Windows Logs → Security, а фильтр по Event ID 4624 позволяет оставить только успешные входы, после чего временной диапазон задаётся встроенными полями «From» и «To» с точностью до секунды.

Если требуется видеть не только факты входа, но и корректные завершения сеансов, добавляют Event ID 4634 и 4647, что помогает вычислить длительность каждой сессии путём сопоставления Logon ID; связав эти события в таблицу, можно получить время начала и конца для каждого пользователя без сторонних утилит.

В инфраструктуре домена фильтрация делается централизованно через сбор логов на контроллере домена или SIEM, где ключевыми полями служат Account Name, Workstation Name и Source Network Address; это позволяет за один запрос вывести список всех RDP‑подключений по группе серверов за неделю или месяц.

Для серверов с ролью Remote Desktop Services дополнительно просматривается журнал Applications and Services Logs → Microsoft → Windows → TerminalServices‑LocalSessionManager → Operational, в котором Event ID 21 фиксирует успешное подключение, а Event ID 23 – отключение, что удобно для сверки с Security‑логом и выявления «висящих» сессий.

При необходимости визуального анализа применяются средства вроде Event Log Explorer или отчёты в Microsoft Defender for Endpoint, которые автоматически агрегируют RDP‑входы по пользователям и IP‑адресам, показывая пики активности и аномалии в выбранном периоде.

Для соответствия требованиям аудита журнал безопасности должен храниться не менее 90 дней с включённой политикой Audit Logon Events; увеличение размера лога до 1–2 ГБ предотвращает перезапись и гарантирует, что полный список RDP‑сеансов за квартал будет доступен без потерь.

Как выявить подозрительные попытки входа через RDP

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

Помимо анализа логов, рекомендуется использовать блокировку учетных записей после нескольких неудачных попыток и внедрять двухфакторную аутентификацию для критичных учетных записей. Настройка уведомлений о входах с новых IP или необычных географических локаций позволит оперативно реагировать на потенциальные угрозы. Периодическая проверка событий с помощью PowerShell-скриптов или SIEM-систем повышает точность выявления подозрительных попыток.

Как включить аудит входов, если журналы не сохранялись

Если на сервере с Windows аудит был отключён и события RDP не писались, восстановить прошлые подключения невозможно, но можно зафиксировать все будущие входы. Откройте «Локальную политику безопасности» (secpol.msc) → «Локальные политики» → «Политика аудита» и включите «Аудит входа в систему» для успехов и отказов; дополнительно активируйте «Аудит входа в учётную запись», чтобы фиксировать доменные и локальные аутентификации. Эти параметры начнут создавать события 4624 и 4625 в журнале «Безопасность», позволяя различать успешные и неудачные RDP-попытки по полям Logon Type=10 и Source Network Address.

В доменной среде используйте групповую политику: в редакторе GPMC создайте или измените объект, применяемый к серверам RDP, и включите «Advanced Audit Policy Configuration» → «Logon/Logoff» → «Audit Logon» и «Audit Account Logon» с режимом Success/Failure, после чего выполните gpupdate /force. Чтобы избежать потери данных, увеличьте размер журнала «Security» до 256–512 МБ и установите режим «Overwrite events as needed»; это предотвратит преждевременную перезапись при высокой частоте подключений.

Параллельно настройте аудит служб терминалов: в «Политиках расширенного аудита» включите «Audit Other Logon/Logoff Events» и «Audit Special Logon», что добавит события 4778/4779 (переподключение и отключение сессий) и 4672 (вход с повышенными привилегиями), позволяя связать RDP‑сессию с конкретным пользователем и временем. Для мгновенных оповещений создайте задачу в Планировщике по триггеру события 4624 с фильтром Logon Type=10 и отправкой email или запуском скрипта, чтобы фиксировать каждое новое подключение без ожидания ручной проверки.

Если сервер подключён к SIEM или центральному сборщику, перенаправляйте журнал «Security» через Windows Event Forwarding, чтобы логи не исчезали при очистке локального хранилища и были доступны для корреляции по IP и учётным записям; добавьте контроль целостности (например, подпись событий) и ограничьте доступ к журналам, иначе злоумышленник с правами администратора сможет удалить следы даже при включённом аудите.

Как выгрузить и сохранить историю RDP-подключений для отчета

Основным источником данных служит журнал Security в Windows: события 4624 (успешный вход) и 4634/4647 (выход), где LogonType=10 указывает на RDP-сеанс; дополнительно полезны 1149 из журнала Microsoft‑Windows‑TerminalServices‑RemoteConnectionManager/Operational, фиксирующие факт подключения еще до аутентификации. Для выгрузки откройте «Просмотр событий», примените фильтр по указанным ID и интервалу дат, затем экспортируйте отобранные записи в .evtx для сохранения всех атрибутов.

Для отчетности удобнее преобразовать события в табличный формат: из «Просмотра событий» выберите «Сохранить отфильтрованные события как…» → CSV, после чего в Excel добавьте столбцы Account Name, Workstation Name и IP Address, что позволяет быстро отследить, с какого адреса и под какой учетной записью выполнялся вход.

Для корреляции подключений с пользовательскими сессиями выгрузите также журнал Microsoft‑Windows‑TerminalServices‑LocalSessionManager/Operational (ID 21 – логон, 23 – логофф), объедините его с Security по Session ID и получите точные временные рамки каждого RDP‑сеанса.

Перед архивацией проверьте целостность: сравните количество событий 4624 и 4634, чтобы исключить оборванные записи, и зафиксируйте хеш‑сумму выгруженных файлов (например, SHA‑256) – это повышает доверие к отчету при внутреннем расследовании.

Храните исходные .evtx и рабочие CSV в неизменяемом хранилище, а в итоговый отчет включайте только агрегированные поля (пользователь, IP, дата/время входа и выхода), чтобы сократить объем и упростить проверку без потери доказательной базы.

Вопрос-ответ:

Где на компьютере посмотреть, кто подключался по RDP и в какое время?

Все подключения по RDP пишутся в системные журналы. Открой «Просмотр событий» и перейди в раздел «Журналы Windows → Безопасность». Там ищут записи с идентификаторами входа, где указан тип входа 10 — он соответствует удалённому рабочему столу. В строке события видно имя учётной записи, дату, время и IP‑адрес источника. По этим данным легко понять, кто именно заходил и откуда.

Можно ли определить IP‑адрес удалённого пользователя, если он входил по RDP?

Да, в событиях входа фиксируется сетевой адрес. В «Просмотре событий» открой запись о входе с типом 10 и найди поле «Сетевой адрес» или «Source Network Address». Там будет IP компьютера, с которого установили сессию. Если адрес внутренний, значит подключение шло из той же сети, если внешний — через интернет.

Почему в журнале есть записи входа, но я не вижу RDP‑сессий?

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

Как отличить обычный вход за компьютером от подключения по удалённому рабочему столу?

В журнале безопасности есть поле «Тип входа». Для локального входа обычно указывается 2, для сетевых служб — другие значения, а для удалённого рабочего стола используется 10. Сравнив эти цифры, можно понять, сидел ли человек за клавиатурой или работал через сеть.

Что делать, если я обнаружил неизвестные RDP‑подключения?

Сначала смени пароли всех учётных записей с доступом к удалённому рабочему столу и проверь, какие пользователи входят в группу разрешённых. Затем включи блокировку по числу неудачных попыток и, если возможно, ограничь доступ по IP‑адресам через брандмауэр. После этого снова посмотри журналы — так видно, прекратились ли посторонние входы.