Признаки компрометации через уязвимости в протоколе Remote Desktop Protocol (RDP)

Если вы админ и заметили, что сервер стал странно себя вести, или в журналах появились непонятные подключения — возможно, кто-то уже пролез через RDP. Важно понять, какие признаки компрометации связаны именно с уязвимостями Remote Desktop Protocol (RDP), а не с обычным взломом пароля. «Обычный» брутфорс и эксплойт — это два разных следа.

Я расскажу, что искать в логах, трафике и поведении системы, чтобы вовремя понять: вас взломали через уязвимость RDP, а не просто подобрали пароль.

Как на самом деле компрометируют RDP

Remote Desktop Protocol (RDP) — удобный, но часто неправильно настроенный инструмент. Основные векторы:

• Брутфорс и открытый порт 3389 в интернет. Это база, но к уязвимостям протокола часто не имеет отношения.
• Известные уязвимости самого RDP (BlueKeep, DejaBlue и др.). Позволяют 执行ть код без аутентификации.
• Уязвимости в реализации клиента/сервера (RDP), например CVE-2019-0887, CVE-2020-0668.
• Проблемы в CredSSP, утечки сессий, ошибки в настройке Network Level Authentication (NLA).

Если вас взломали через эксплойт RDP, признаки компрометации будут отличаться от «классического» входа с паролем. Часто нет массы неудачных попыток залогиниться — сессия появляется «из ниоткуда», с уже корректным токеном.

Где искать следы атаки через уязвимости RDP

1. Журналы Windows Event Logs

Первое место, куда смотрят. Но важно знать, именно искать, а не просто «просмотреть Security». При атаках через уязвимость Remote Desktop Protocol (RDP) часто видны аномалии в последовательности событий.

На что обращать внимание:

• Event ID 4624 (успешный вход) — тип входа 10 (RemoteInteractive). Если время странное (ночь, выходные), IP необычный — подозрительно.
• Event ID 4625 (неудачный вход) — одиночные записи после «чистой» сессии могут указывать на попытку использовать уязвимость, а не брутфорс.
• Event ID 4648 (явные учётные данные) — может свидетельствовать о попытке использовать CredSSP или перенаправление сессий.
• Event ID 4776 (проверка учётных данных) — если идёт с необычного хоста, возможно, используется уязвимость в процессе NLA.
• Event ID 1149 (Microsoft-Windows-TerminalServices-LocalSessionManager) — параметры подключения, версия клиента, странные имена устройств.

При атаках через BlueKeep (CVE-2019-0708) или аналогичные уязвимости в RDP часто можно заметить странные сбои службы TermService и перезапуски:

• 7031/7034 — аварийное завершение службы управления службой, критическая остановка контроллера домена.
• Event ID 56 — сбой в терминальном подключении, особенно если повторяется массово.

2. Сетевой трафик: что покажет анализатор

Если вы подозреваете эксплойт, ловите трафик на порту 3389 (RDP, TPKT). Признаки компрометации через уязвимости Remote Desktop Protocol:

• Аномальные сессии без полной последовательности инициализации RDP.
• Срабатывание IDS/IPS: например, сигнатуры на BlueKeep, DejaBlue или необычные паттерны в каналах RDP.
• Подключение с IP, который никогда не был в белом списке, но при этом в логах нет признаков брутфорса.
• Могут наблюдаться признаки RCE, когда после успешной аутентификации или даже без неё идёт необычная активность.

Типичный пример: вы видите полноценную интерактивную сессию в логах, а в логах аутентификации никаких предшествующих попыток. Для уязвимости RDP без аутентификации — это нормально, для брутфорса — нет.

3. Поведение системы после атаки

Если атакующий пролез через уязвимость Remote Desktop Protocol, после проникновения он обычно действует быстрее и агрессивнее, чем при классическом входе с паролем:

• Установка бэкдоров, в том числе через schtasks, reg add для автозапуска.
• Массовое сканирование локальной сети с сервера (кобальт, nmap, net view).
• Попытки дампить пароли (mimikatz, обращение к LSASS).
• Создание скрытых учётных записей или добавление себя в группы админов.
• Резкий рост исходящего трафика — возможен эксфильтрация.

Основные признаки: сравнение сценариев

Чтобы вам было проще понять, что именно произошло, собрал сравнение двух типичных сценариев: классический брутфорс и атака через уязвимость RDP.

Типичные уязвимости в RDP и их следы

1. BlueKeep (CVE-2019-0708)

позволяет выполнить код без аутентификации через уязвимость в каналах RDP. Признаки:

• Крэш или перезапуск службы TermService.
• В логах могут быть ошибки, связанные с терминальным сервисом, ещё до появления записей о входе.
• Срабатывание детектов на аномальное использование определённых RDP-каналов.

2. DejaBlue (CVE-2019-1181 / CVE-2019-1182, CVE-2019-1225 и др.)

Затрагивают более новые версии Windows, также позволяют выполнить код удалённо. Следы похожи на BlueKeep, но могут затрагивать и клиентские подключения.

• Аномальная активность в серверной роли RDP.
• Сессия появляется без ожидаемой последовательности событий.

3. Уязвимости в CredSSP / NLA

Если атакующий использует уязвимость в механизме CredSSP, которая используется RDP, можно заметить:

• Аномальные 4648 и 4776 события.
• Подозрительные IP, с которых идёт аутентификация по RDP.
• Подключения ранее не виденных клиентов с необычными версиями RDP.

Пошаговый чек-лист: что проверить в первую очередь

Если вам кажется, что сервер компрометирован через уязвимость Remote Desktop Protocol, действуйте по алгоритму:

1. Отключите сервер от сети, но не выключайте (чтобы не потерять данные в памяти).
2. Снимите дамп сетевого трафика, если атака продолжается.
3. Откройте логи Security и TerminalServices-LocalSessionManager, отфильтруйте по последним суткам.
4. Найдите все 4624 с типом 10 и необычным IP.
5. Проверьте, есть ли 7031/7034 в System — умирали ли службы управления и контроллер домена.
6. Посмотрите события 56 (TerminalCONNECT) — могут указывать на аномальный handshake RDP.
7. Проверьте трафик на порту 3389: есть ли паттерны, характерные для эксплойтов.
8. Найдите подозрительные процессы (mimikatz, сетевые сканеры) и новые учётки.
9. Если нашли следы пост-эксплуатации — считайте сервер полностью скомпрометированным.

Частые ошибки когда ищут следы RDP-компрометации

• Смотреть только « Failed logon». При эксплойте неудачных попыток может не быть, а вход будет успешным.
• Проверять только один сервер. Атака через уязвимость RDP часто не ограничивается одним хостом. Нужно проверить все машины с открытым 3389.
• Игнорировать версию RDP и ОС. Если у вас до сих пор Windows Server 2008 R2 без патчей — вы почти гарантированно под BlueKeep.
• Не смотреть на TermService. Сбои этой службы часто первый звоночек эксплойта.
• Считать, что если нет brute-force, то атаки не было. Уязвимости RDP могут не оставлять следов в виде брутфорса.

Что делать в зависимости от ситуации

Сценарий 1: вы только подозреваете атаку

Проверьте RDP на всех серверах по чек-листу выше. Если нашли аномальные сессии, но нет признаков пост-эксплуатации (нет новых процессов, нет бэкдоров) — всё равно патчите RDP и блокируйте вход извне.

Сценарий 2: нашли краш TermService + вход с чужого IP

Отключите сервер. Соберите логи и дамп памяти как улики. Обновите всё, что касается Remote Desktop Protocol. Параллельно проверьте соседние сервера — возможно, двигаются по сети.

сценарий 3: нашли следы пост-эксплуатации

Сервер почти наверняка стоит перестраивать. На время расследования изолируйте его, но не используйте в боевой среде. Запишите все найденные артефакты, чтобы передать инцидент-респондеру.

Как защитить RDP, чтобы не было эксплойтов

Если не хотите регулярно разбираться с компрометацией через уязвимости Remote Desktop Protocol, сделайте базовые вещи:

• Закрываете порт 3389 для интернета. Точка.
• Используйте VPN для админ-подключений по RDP.
• Включите Network Level Authentication (NLA).
• Своевременно ставите обновления ОС, особенно патчи для Remote Desktop Protocol.
• Если у вас старые версии Windows и их нельзя обновить — минимум ограничьте доступ по IP и мониторьте логи.

Параллельно — настройте мониторинг и оповещения на аномальные входы по RDP. Без адекватного SIEM или хотя бы регулярного просмотра логов вы узнаете о компрометации, когда будет уже поздно.

Итог что вам с этим делать

Если вы подозреваете компрометацию через уязвимости Remote Desktop Protocol, не ищите только брутфорс. Смотрите на аномалии в самом процессе RDP, на сбои служб, на необычные успешные сессии.

Проверьте: логи, трафик, срабатывания IDS, службу TermService. Если нашли следы пост-эксплуатации — сервер, скорее всего, придётся перестраивать.

Проще закрыть порт 3389 и нажаться NLA, чем потом разбирать последствия. Но если уже «прилетело», действуйте по чек-листу, фиксивайте доказательства и сразу отключайте подозрительный сервер от сети. Чем быстрее вы это сделаете, тем меньше шанс, что атакующий успеет закрепиться.

Информация в этой статье носит ознакомительный характер. При реальном инциденте безопасности рекомендуется обратиться к профильным специалистам по кибербезопасности.