Плохой пароль для учетной записи Domain Admin с неизвестной рабочей станции.

Вопрос или проблема

Я пытаюсь найти компьютер/устройство, которое использует неправильный пароль для одной из наших учетных записей доменных администраторов, используемых в качестве общей/серверной учетной записи.

Единственные данные, которые у меня есть, это повторяющееся событие в просмотрике событий на наших контроллерах домена. Оно повторяется каждые 30-32 минуты.

Безопасность, 11/04/2018, 14:38:46
PM, Microsoft-Windows-Security-Auditing, 4776, Информация, Неудачная
аудит, Проверка
учетных данных, ADMINDUDE, DC01.mydomain.com, IP: 10.1.1.90, 4776, Компьютер
попытался проверить учетные данные для учетной записи. Пакет аутентификации: MICROSOFT_AUTHENTICATION_PACKAGE_V1_0 Учетная запись для входа:
ADMINDUDE Исходная рабочая станция: GS-821450430543CV Код ошибки: 0xc000006a

Эта рабочая станция, GS-821450430543CV, не существует в DNS, DHCP, Active Directory.
Это реальное имя рабочей станции в журнале событий – я надеюсь, что кто-то уже сталкивался с этим и сможет сказать, что это за устройство.

На одном из наших контроллеров домена:
Я запустил Wireshark и искал это имя через Правка > Найти пакет > строку.
Я запустил Sysinternals ProcMon и искал в файле захвата.
У меня открыт захват в MS Message Analyser, но пока я не разобрался, как сделать поиск по ключевым словам.

Обзор окружения: контроллеры домена Windows 2008R2, в основном клиенты/серверы Windows, несколько серверов приложений на Linux, примерно 200 серверов, 300 рабочих станций, 20 терминальных серверов.

Когда ADMINDUDE был в Запланированных задачах на Windows-серверах, реальное имя рабочей станции или IP появлялось в журнале событий. Даже когда его использовали в качестве учетной записи аутентификации LDAP на Linux-устройстве, событие давало нам больше деталей.

Есть ли советы по поиску этого «блуждающего» компьютера?
Есть ли советы по поиску в захватах, которые у меня уже есть?

Обновление: Запустил отладку Netlogon (как предложил JoeQwerty), и теперь у меня есть больше информации. Теперь я снова собираюсь запустить все тесты из Exchange.

04/13 13:47:14 [LOGON] ДОМЕН: SamLogon: Транзитивная сетевая аутентификация
domain\ADMINDUDE из GS-821450430543CV (через EXCHANGE) Вошел

04/13 13:47:14 [LOGON] ДОМЕН: SamLogon: Транзитивная сетевая аутентификация
domain\ADMINDUDE из GS-821450430543CV (через EXCHANGE) Возврат
0xC000006A

Обновление 2: НАШЕЛ! Поиск в журнале событий по Неудачной аудиторской записи на Exchange в то же время показал его IP в сетевой информации события. Это был Polycom, который не был в сети несколько месяцев, и кто-то, должно быть, недавно снова его подключил.

Я нашел ответ на этот вопрос здесь https://windowsreport.com/0xc000006a/

При следующем коде ошибки “состояние “4776” записывается, когда контроллер домена пытается проверить учетные данные для учетной записи, используя NTLM (Windows Challenge/Response). Чаще всего это также может появиться в журнале из-за возврата к NTLM.

Ответ или решение

Проблема с неправильным паролем для учетной записи администратора домена может быть достаточно серьезной, особенно если учетная запись используется как общая или сервисная. Рассмотрим несколько шагов и рекомендаций для поиска источника этой проблемы.

Шаги для поиска "неизвестного" устройства

  1. Анализ журналов событий:

    • Продолжайте анализировать журналы событий на контроллерах домена, особенно обратите внимание на события с кодом ошибки 0xc000006a. Это указывает на ситуацию, когда система не смогла подтвердить учетные данные пользователя.
    • Используйте фильтры для поиска по времени, связанному с возникающими ошибками, чтобы выявить возможные паттерны или повторяющиеся IP-адреса.
  2. Сетевой анализ:

    • Используйте инструменты, такие как Wireshark, для захвата сетевого трафика и анализа отправляемых пакетов. Обратите внимание на запросы DNS, которые могут дать подсказки о неверных попытках аутентификации.
    • Также настройте фильтрацию для захвата только трафика, связанного с вашим доменом и проблемной учетной записью ADMINDUDE.
  3. Участие системы Exchange:

    • В вашем случае, изучение журналов событий Exchange дало информацию о реальном IP-адресе устройства. Продолжайте исследовать журналы Exchange, так как многие устройства, включая принтеры и IP-телефоны, могут использовать эту систему для аутентификации.
  4. Использование команд PowerShell:

    • Для сбора данных о подключенных устройствах вы можете использовать команды PowerShell, такие как:
      Get-EventLog -LogName Security | Where-Object { $_.EventID -eq 4776 }
    • Это поможет вам получить более подробную информацию о событиях аутентификации.
  5. Опрос пользователей:

    • Если возможно, пообщайтесь с пользователями, которые могли подключить или использовать проблемное устройство. Ваша информация о Polycom указывает на то, что устройство после длительного отключения было вновь подключено; возможно, стоит проверить другие подобные устройства.

Рекомендации по предотвращению подобных проблем в будущем

  • Документирование и аудит устройств: Ведите учет всех устройств, подключаемых к сети, и их назначение. Регулярное обновление информации поможет избежать путаницы в будущем.

  • Автоматизация мониторинга: Рассмотрите возможность использования инструментов для автоматизации мониторинга событий безопасности и аутентификации. Это может облегчить идентификацию подозрительных действий в реальном времени.

  • Безопасные пароли: Убедитесь, что используемые пароли сложные и регулярно обновляемые. Использование менеджера паролей также может помочь избежать проблем с устаревшими паролями.

  • Обучение пользователей: Регулярно проводите обучение персонала по вопросам безопасности, чтобы повысить осведомленность о возможностях использования учетных записей и устройствах.

Заключение

Нахождение источника проблемы с неверной аутентификацией требует комплексного подхода, включая анализ журналов, сетевую слежку и взаимодействие с пользователями. Вы уже на правильном пути, и использование инструмента Netlogon выводит вас на нужный путь. Ваша находка о Polycom демонстрирует важность проверки физических подключений и их истории. Удачи в дальнейшем расследовании и устранении проблем!

Оцените материал
Добавить комментарий

Капча загружается...