Из-за чего произошла замена dll в реестре?

Ссылка скопирована
1 ответ

По вводным: на хосте есть запись в реестре с CLSID "{fcc2867c-69ea-4d85-8058-7c214e611c97}". "HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{fcc2867c-69ea-4d85-8058-7c214e611c97}\"

По вводным: в пути "LocalServer32" должен быть указан системный файл "C:\Windows\System32\tssessionux.dll" (нам так ЛК сказали)

По вводным: а на нашем одном конкретном хосте, вместо tssessionux.dll указан "%SystemRoot%\system32\authui.dll"

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

По вводным: сам хост, на котором это произошло - терминальник, на котором работают два сотрудника.
Как я понимаю
По вводным: tssessionux.dll - интерфейс аутентификации для удалённых (RDP/Terminal Services) сессий.
По вводным: authui.dll - интерфейс аутентификации для локальной консоли пользователя (экран входа).

Нужно понять: в каких ситуациях одна dll может в ветке реестра замениться на другую.?

Нужно решить такую задачу?

Опишите проблему, и специалист поможет с настройкой, исправлением ошибки или доработкой сайта. Подберём понятный план работ без лишней переписки.

Заказать помощь
Лучший ответ
1
Backend-редакция Ответ

CLSID {fcc2867c-69ea-4d85-8058-7c214e611c97} и ветка LocalServer32 относятся к COM-регистрации. Если вместо ожидаемого tssessionux.dll указан authui.dll, это не обязательно вредоносная замена. Но для терминального сервера такое изменение нужно проверить: кто изменил ключ, когда, и соответствует ли это версии Windows/ролям RDS.

Сначала зафиксируйте текущее значение и права на ключ:

reg query "HKLMSOFTWAREClassesCLSID{fcc2867c-69ea-4d85-8058-7c214e611c97}" /s
Get-Acl "Registry::HKEY_LOCAL_MACHINESOFTWAREClassesCLSID{fcc2867c-69ea-4d85-8058-7c214e611c97}" | Format-List

reg query "HKLMSOFTWAREClassesCLSID{fcc2867c-69ea-4d85-8058-7c214e611c97}" /s Get-Acl "Registry::HKEY_LOCAL_MACHINESOFTWAREClassesCLSID{fcc2867c-69ea-4d85-8058-7c214e611c97}" | Format-List

Дальше посмотрите журнал событий вокруг времени изменения, если оно известно. Интересуют установка обновлений, RDS-компоненты, GPO, антивирус/EDR, действия администраторов:

Get-WinEvent -LogName System -MaxEvents 200
Get-WinEvent -LogName Application -MaxEvents 200
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 20

Get-WinEvent -LogName System -MaxEvents 200 Get-WinEvent -LogName Application -MaxEvents 200 Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 20

Если аудит реестра заранее не был включён, точно узнать процесс, который поменял ключ, может быть невозможно. На будущее можно включить auditing на ветку реестра и смотреть Security events 4657.

Проверьте системные файлы:

sfc /scannow
DISM /Online /Cleanup-Image /RestoreHealth

sfc /scannow DISM /Online /Cleanup-Image /RestoreHealth

Сравните значение CLSID на аналогичном сервере с той же версией Windows и установленными ролями. Важно сравнивать не с “как сказали в ЛК”, а с машиной той же сборки и конфигурации.

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

  • обновление Windows/RDS изменило COM-регистрацию;
  • GPO или hardening script переписал ключ;
  • программа удалённого доступа/безопасности внесла изменение;
  • ручное изменение администратором;
  • повреждение регистрации COM;
  • вредоносная активность, даже если сам файл системный.

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

Другие ответы (0)

Пока нет других ответов. Будьте первым, кто поможет автору.

Ответить на вопрос

комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Вам также может быть интересно