Hkey local machine software microsoft windows nt currentversion winlogon cachedlogonscount

Прочитано: 3 980

Если у Вас в организации сотрудники часто бывают в пределах офиса и соответственно при входе на свой ноутбук пользователь получает следующее сообщение – “Не удалось установить связь с сервером и получить параметры входа в систему. Вход выполнен с помощью локально сохранённой информации об учетной записи. Если информация учетной записи была изменена со времени последнего входа в систему, эти изменения не отразятся в этом сеансе” .  Если контроллер домена недоступен и учётных данных пользователя в кэше нет, пользователь получает следующее сообщение. Из ходя из этого пользователь должен хоть, раз успешно зайти в свою систему в сети домена.

Не удалось выполнить вход в систему, поскольку домен <ИМЯ_ДОМЕНА> недоступен

По умолчанию в домене, число входов на рабочую станцию в отсутствии связи с домен контроллером равно 10 раз вне зависимости, какая  у Вас используется операционная система (Windows XP, Windows 7 и более старшие модели)

HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\Current Version\Winlogon\

ValueName: CachedLogonsCount

REG_SZ: 10

Запущенный редактор реестра (Win + R и набрать regedit) для просмотра текущего значения:

По умолчанию количество закэшированных входов в системе вне домена равно 10.

Специально для таких сотрудников  рекомендую создать отдельное подразделение (OU) в домене и поместить в неё имена компьютеров. И увеличить это значение до максимально возможного, т.е. пятидесяти (50).

Заходим на домен контроллер (dc1.polygon.local) под учётной записью ekzorchik (входит в группу Domain Admins).

Запускаем оснастку управления групповыми политиками – Group Policy Management:

«Start» – «Control Panel» – «Administrative Tools» – «Group Policy Management», далее  развернём узел «Group Policy Objects» (Объекты групповой политики)

В моём случае это будет подразделение IT (в Вашем случаем создавайте/выбирайте нужное Вам).

Создадим групповую политику и назовём её:  GPO_CacheLogonCount.

И так у нас создан шаблон, который по умолчанию привязан к контейнеру IT и применяем на всех пользователей прошедших проверку (Authenticated Users), но т.к. у нас отдельное подразделение добавим конкретно те имена компьютеров, которые работает вне домена с ноутбуками.

Должно получиться вот так:

Location: IT

Security Filtering: WXP86.polygon.local – станция которая обладаем возможности работать вне домена (ноутбук).

Заметка: Для удобства рабочие станции можно объединять в группы.

Приводим политику к виду: назначаем на контейнер IT и привязываем на имена компьютеров.

Т.к. политика будет распространяться на компьютеры, то редактируем соответствующий раздел:

«Computer Configuration» –«Policies» – «Windows Settings» – «Security Settings» – «Local Policies» – «Security Options» – «Interactive Logon: Number of previous logons to cache (in case domain controller is not available)» (Интерактивный вход в систему: количество предыдущих подключений к кэшу (в случае отсутствия доступа к контроллеру домена)

Увеличиваем количество входов вне домена до 50.

Все политика настроена. Чтобы все изменения применились, следует перезагрузить компьютер, чтобы изменения вступили в силу.

Значение поменялось:

И так, что мы имеем, увеличено количество входа в рабочую станцию вне офиса. А политикой мы разграничиваем тем сотрудникам, которые имеют согласование начальства работать удалённо или в командировках. Надеюсь, данный материал будет полезен всем заинтересованным лицам. На этом всё, удачи!!!

Когда доменный пользователь входит в Windows, по умолчанию его учетные данные (Cached Credentials: имя пользователя и хэш пароля) сохраняются на локальном компьютере. Благодаря этому, пользователь сможет войти на локальный компьютер, даже если контроллеры домена AD недоступны, выключены или на компьютере отключен сетевой кабель. Функционал кэширования учетных данных доменных аккаунтов удобен для пользователей ноутбуков, которые могут получить доступ к своим локальным данным на компьютере, когда нет доступа к корпоративной сети.

Содержание:

  • Сохраненный кэш доменной учетной записи в Windows
  • Настройка Cached Credentials с помощью групповых политик
  • Безопасность кэшированных учетных данных в Windows

Сохраненный кэш доменной учетной записи в Windows

Вход на компьютер под кэшированными данными для пользователя доступен, если он ранее хотя бы один раз авторизовался на этом компьютере, и пароль в домене не был сменен с момента входа. Пароль пользователя в cashed credentials никогда не истекает. Если доменная политика паролей вынудит пользователя изменить пароль, сохраненный пароль пользователя в локальном кэше компьютера не изменится, пока пользователь не войдет на компьютер под новым паролем. Т.е. если пароль пользователя в AD был изменен после последнего входа на компьютер, и компьютер находился все время в офлайн режиме без доступа в сеть, то пользователь сможет войти на этот компьютер под старым паролем.

Если домен Active Directory недоступен, Windows проверяет, что введенные имя пользователя и пароль соответствуют сохраненному локальному хэшу и разрешает локальный вход на компьютер.

Сохраненные пароли хранятся в ветке реестра HKEY_LOCAL_MACHINE\Security\Cache (файл %systemroot%\System32\config\SECURITY). Каждый сохранённый хэш содержится в Reg_Binary параметре NL$x (где x – индекс кэшированных данных). По умолчанию даже у администратора нет прав на просмотр содержимого этой ветки реестра, но при желании их можно легко получить.

В реестр сохраняет хэш пароля, модифицированный с помощь salt, созданной на основе имени пользователя.

HKEY_LOCAL_MACHINE\Security\Cache сохраненный хэш пароля в реестре

Очистка значения параметра NL$x приведет к удалению кэшированных данных.

Если в локальном кэше для пользователя нет сохранённых учетных данных, то при входе на офлайн компьютер, появится сообщение:

There are currently no logon servers available to service the logon request.
Отсутствуют серверы, которые могли бы обработать запрос на вход в сеть.

Отсутствуют серверы, которые могли бы обработать запрос на вход в сеть.

Настройка Cached Credentials с помощью групповых политик

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

По-умолчанию в Windows 10 /Windows Server 2016 сохраняются учетные данные для 10 пользователей. Чтобы изменить это количество, используется параметр GPO Interactive logon: Number of previous logons to cache (in case domain controller is not available) (Интерактивный вход в систему: количество предыдущих подключений к кэшу в случае отсутствия доступа к контроллеру домена), который находится в разделе Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Local Policies -> Security Options. Можно задать значение от 0 до 50.

групповая политика Интерактивный вход в систему: количество предыдущих подключений к кэшу в случае отсутствия доступа к контроллеру домена

Этот параметр также можно настроить с помощью REG_SZ параметра реестра CashedLogonsCount из ветки HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon

При входе под сохраненными данными, пользователь не видит, что контроллер домена не доступен. С помощью GPO можно вывести уведомление о входе под кэшированными данными. Для этого нужно включить политику Report when logon server was not available during user logon (Сообщать, когда сервер входа недоступен при входе пользователя) в разделе Compute configuration -> Policies -> Administrative templates -> Windows Components -> Windows Logon Options.

политика Сообщать, когда сервер входа недоступен при входе пользователя

В этом случае при входе пользователя в трее будет появляться уведомление:

Не удается подключиться к серверу входа (контроллеру домена). Вход выполнен с помощью ранее сохраненных сведений об учетной записи.
A domain controller for your domain could not be contacted. You have been logged on using cached account information. Changes to your profile since you last logged on might not be available.

Эту настройку можно включить через реестр:
HKEY_LOCAL_MACHINE/SOFTWARE/Microsoft/Windows NT/Current Version/Winlogon

  • ValueName: ReportControllerMissing
  • Data Type: REG_SZ
  • Values: TRUE

Безопасность кэшированных учетных данных в Windows

Локальное кэширование учетных данных несет ряд рисков безопасности. Злоумышленник, получив физический доступ к компьютеру/ноутбуку с кэшированными данными, может с помощью брутфорса расшифровать хэш пароля (тут все зависит от сложности и длины пароля, для сложных паролей время подбора огромное). Поэтому не рекомендуется использовать кеширование для учетных записей с правами локального администратора (или, тем более, доменного администратора).

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

Для доменов с функциональным уровнем Windows Server 2012 R2 или выше можно добавить учетные записи администраторов домена в группу Protected Users. Для таких пользователей запрещено локальное сохранение кэшированных данных для входа.

Можно создать в домене отдельные политики по использованию кэшированных учетных данных для разных устройств и категорий пользователей (например, с помощью GPO Security filters, WMI фильтров, или распространению настроек параметра реестра CashedLogonsCount через GPP Item level targeting).

Для мобильных пользователей –
CashedLogonsCount = 1

Для обычных компьютеров –
CashedLogonsCount = 0

Такие политики снизят вероятность получения хэша привелигированных пользователей с персональных компьютеров.

Microsoft Windows 7 Registry – CachedLogonsCount

Windows 7 Registry – CachedLogonsCount

A security hack sounds like an oxymoron.  However, I once had a client who wanted to improve their laptop security, for them, minimizing cached logons was the answer. 

The default number of cached logons for a client such as Windows 7 is 50 (10 in Vista).  With a quick registry edit of CachedLogonsCount, we can reduce this to value zero.  My client had laptops which operated on an Active Directory domain, and they did not want users (or hackers) to logon unless the laptop could authenticate with a domain controller.  Since there is no GUI to reset the cached logons, this is a job for a registry tweak.

Topics for Windows 7 CachedLogonsCount

  • First Objective to Reach the Winlogon Registry Folder
  • Second Objective to set the CachedLogonsCount value = 0
  • Key Learning Points
  • See CachedLogonsCount in Vista
  • Windows 8 Registry Hacks

 ♦

First Objective to Reach the Winlogon Registry Folder

I have divided our task into two parts.  Our first task is to find the correct part of the registry; our second task is to edit the actual registry value.

Method 1) Flashy.  Launch Regedit, click on the Edit menu and then select ‘Find’.  Now type Winlogon in the ‘Find what:’ dialog box.  Put a tick in only the ‘Keys’ box, see screenshot to the right.  The purpose of this technique is to navigate to the folder containing CachedLogonsCount as quickly as possible.

Note: If you don’t tick ‘Match whole string only’, you may have to press F3 two or three times until you see the following path at the very bottom of the regedit screen:
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\winlogon

Method 2) Safe and sure.  If Method 1 fails, then here is an alternative method, launch regedit and manually drill down to:
HKLM**\Software\Microsoft\Windows NT\CurrentVersion\winlogon.

** HKLM is an abbreviation of HKEY_LOCAL_MACHINE, and HKCU is shorthand for HKEY_CURRENT_USER.  These acronyms are so well-known that you can even use them in .reg files, Vista will understand and obey the registry instruction.

Second Objective to Set the CachedLogonsCount value = 0

The default value for the cached logons count is 50.  Our job is to edit this REG_SZ value from 50 to zero.  Before you go any further, check the path; there are at least four instances of ‘Winlogon’ in the registry.

Let us assume that you have reached: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\winlogon.  The next task is to double-click CachedLogonsCount.  If this setting is not present, no worries, just right-click in the right hand pane, and create a new REG_SZ called CachedLogonsCount.

For greater security, double-click and change the value for CachedLogonsCount to 0 (zero).  Alternatively, to give a laptop the maximum cached logons when it is away from its domain controller, set the value = 50 (maximum number)

CachedLogonsCount

Key Learning Points

  • Were you able to master: Find – ‘Keys’?
  • Do you find the CachedLogonsCount value in HKCU** or HKLM?
    Answer: HKLM
  • Do you have to add a value, or modify an existing setting? 
    Answer: Modify changing 50 –> 0. 
  • Is it a String Value or a DWORD?
    Answer: REG_SZ (String value).
  • Do you need to Restart, or merely Logoff / Logon?
    Answer: Restart
  • This example merely edits an existing value.
  • Tip: F3 speeds up searching when using ‘Find’.

** HKLM is an abbreviation of HKEY_LOCAL_MACHINE, and HKCU is shorthand for HKEY_CURRENT_USER.  These acronyms are so well-known that you can even use them in .reg files, Vista will understand and obey the registry instruction.

»

Windows 7 CashedLogonsCount Summary

The default number of cached logons for Windows 7 is fifty.  With a quick registry edit of CachedLogonsCount, we can reduce this to value zero.  Because there is no convenient GUI to reset the cached logons, this is a job for a registry tweak.

If you like this page then please share it with your friends


More Windows 7 Registry Tweaks

  • Gpedit – Local Group Policy Editor
  • Editing the Windows 7 Registry with PowerShell
  • PaintDesktopVersion (Build Number)
  • Change the Name of a Windows 7 Computer
    with LocalizedString
  • Hide User From Welcome Screen
  • RegisteredOwner – Windows 7 Registry Hack
  • NoDriveTypeAutoRun
  • Delete Roaming Profile Cache
  • Windows 7 .Reg Files Examples
  • Performance Monitoring
  • Windows Version 7 Home
  • Windows 7 Registry Tweaks
  • Windows 7 Auto Logon
  • Windows 7 AutoPlay
  • Windows 7 Remove Shortcut Arrow
  • Free Tool: Permissions Monitor

About The Author

Guy Thomas

Компьютер под управлением Windows по умолчанию кэширует данные 10-ти последних удачных регистрации. Это число может изменяться в пределах от 0 до 50.

  1.  Запустите редактор системного реестра (REGEDIT.EXE).

  2.  Перейдите в раздел HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon.

  3.  В меню Правка (Edit) выберите команду Создать > Строковый параметр (New > String Value).

  4.  Введите имя записи CachedLogonsCount и нажмите клавишу <Enter>.

  5.  Дважды щелкните на новой записи и введите значение от 0 до 50. Значение 0 означает, что кэширование регистраций не производится, а 50 — что будут кэшированы 50 последних удачных регистраций. Щелкните на кнопке OK.

  6.  Закройте редактор системного реестра.

  7.  Перезагрузите компьютер.

Если кто-либо попытается зарегистрироваться на недоступном контроллере домена, и данные об этой регистрации будут кэшированы, появится следующее сообщение:

A domain controller for your domain could not be contacted. You have been logged on using cached account information. Changes to your profile since your last logged on may not be available.

Тем не менее, пользователь будет успешно зарегистрирован. Если же информация о пользователе не кэшируется, на экран будет выведено такое сообщение:

The system cannot log you on now because the domain <домен> is not available.

При этом в регистрации будет отказано.

npikhovkin.jpg

Николай Пиховкин

В этой статье мы рассмотрим основные типы атак на Active Directory, которые часто используются хакерами для взлома корпоративных сетей, и рекомендации для защиты от них.

Credential dumping — метод, при котором хакеры извлекают учетные данные из памяти системы или из файловой системы. Он часто используется для получения хеш-сумм паролей, токенов аутентификации и других учетных данных, которые могут быть применены в ходе дальнейших атак, таких как pass-the-hash, pass-the-ticket и др. Как правило, credential dumping выполняется с использованием специальных инструментов (например, mimikatz), которые позволяют извлекать учетные данные из памяти LSASS, ветвей реестра и других источников.
Примеры источников получения учетных данных:

  1. LSASS (Local Security Authority Subsystem Service). Это процесс в Windows, который управляет политиками безопасности и хранит в памяти различные аутентификационные данные.
  2. SAM и SYSTEM. В Windows учетные данные могут храниться в ветках реестра SAM (Security Account Manager) и SYSTEM. Получив доступ к этим веткам, хакер может извлечь хеш-суммы паролей и подобрать их.
  3. Cached credentials. Windows хранит кэшированные учетные данные, которые хакер также может извлечь. Учетные данные кэшируются для того, чтобы мы имели доступ к нашим компьютерам даже без постоянного подключения к сети.

Рекомендации:

  • Минимизируйте права доступа учетных записей, имеющих доступ к процессу LSASS, предоставляя административные права только тем сотрудникам, которым это действительно необходимо для выполнения рабочих задач.
  • Внедрите политику использования сложных паролей и требуйте их регулярной смены, уделяя особое внимание административным учетным записям.
  • Защитите ветки реестра SAM и SYSTEM, ограничив доступ к ним только доверенными учетными записями. Это поможет предотвратить извлечение хеш-сумм паролей и их подбор.
  • Отключите сохранение паролей пользователей в системе LSA. Для этого параметру реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\disabledomaincreds присвойте значение 1.
  • Рассмотрите возможность запрета использования кэшированных данных для доступа к узлам домена. Для этого параметру реестра HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\CachedLogonsCount присвойте значение 0.
  • Осуществляйте мониторинг обращений к следующим разделам реестра: HKEY_LOCAL_MACHINE\SAM, HKEY_LOCAL_MACHINE\SECURITY, HKEY_LOCAL_MACHINE\SECURITY\Policy\Secrets (включая подразделы) и HKEY_LOCAL_MACHINE\SYSTEM. При настройке мониторинга через групповые политики Active Directory, при обращении к ветви реестра на контроллере домена будут регистрироваться события 4656 (A handle to an object was requested).
  • Отслеживайте запуск процессов и использование аргументов командной строки для выполнения утилит, которые могут указывать на извлечение учетных данных.

Kerberos — это протокол, который используется для безопасной аутентификации пользователей и служб в Active Directory (AD). Он основан на использовании секретных ключей и билетной системе. Когда пользователь хочет получить доступ к какому-либо ресурсу, он сначала проходит аутентификацию на сервере, который выдает ему билет. Затем этот билет используется для доступа к ресурсу без необходимости повторной аутентификации.
Kerberoasting — это атака на протокол аутентификации Kerberos, которая позволяет получить пароли доменных пользователей. Она состоит из нескольких шагов:

  1. Сбор информации об учетных записях, обладающих доступом к целевому ресурсу. Это могут быть учетные записи сервисов, приложений и т. д.
  2. Запрос билетов для сервисных учетных записей. Хакер отправляет запрос на выдачу билета для сервисной учетной записи. В ответ он получает билет, который зашифрован с использованием хеш-суммы пароля этой учетной записи.
  3. Локальный взлом хеш-суммы и получение пароля. Хакер экспортирует полученный билет на локальный компьютер, взламывает хеш-сумму и получает пароль.

Рекомендации:

  • Реализуйте строгую парольную политику и смените используемые словарные пароли. Используйте двухфакторную аутентификацию для привилегированных пользователей домена Active Directory. Для сервисных учетных записей применяйте сложные и длинные пароли (не менее 25 символов) и регулярно меняйте их.
  • Внедрите механизм «Групповых управляемых учетных записей служб» (group managed service accounts, gMSA). Этот механизм поддерживает основные сервисы и службы, используемые в корпоративной инфраструктуре, такие как IIS, AD LDS, SQL Server, MS Exchange. gMSA автоматически меняет пароли, генерируя сложные случайные пароли длиной до 240 символов, что значительно затрудняет их подбор. Пароли меняются по умолчанию каждые 30 дней — их подбор практически невозможен.
  • Используйте механизм flexible authentication secure tunneling (FAST, Kerberos armoring) для усиления защиты аутентификации и обмена TGS-билетами. Этот механизм обеспечивает защищенный канал связи между клиентом Kerberos и центром распространения ключей (key distribution center, KDC).
  • Придерживайтесь принципа минимальных привилегий для сервисных учетных записей, включая привилегии, получаемые в результате членства в группах (таких, как группа администраторов домена).
  • Настройте использование алгоритма шифрования AES (или другого надежного алгоритма) для протокола Kerberos вместо RC4.
  • Для обнаружения атак в инфраструктуре включите в Active Directory мониторинг запрашиваемых билетов Kerberos (Audit Kerberos Service Ticket Operations) и ищите пользователей с избыточными событиями 4769 (A Kerberos service ticket was requested). Используйте метод SPN honeypot, который заключается в создании учетной записи и SPN, которые никогда не будут использоваться (SPN не связан ни с одним реальным приложением). Появление в журнале безопасности контроллера домена события 4769 будет свидетельствовать о попытке проведения атаки типа Kerberoasting.
  • Проводите регулярный аудит безопасности домена с помощью ПО PingCastle.

DCSync — это атака, которая применяется хакерами для получения учетных данных из базы данных домена Active Directory. Она использует возможности протокола репликации AD, который предназначен для синхронизации данных между контроллерами домена. Хакеры могут имитировать контроллер домена и запросить у настоящего контроллера домена информацию об учетных записях.
Основные этапы атаки:

  1. Получение привилегированного доступа. Для проведения атаки хакеру нужно получить привилегированную учетную запись.
  2. Имитация контроллера домена. Могут использоваться инструменты типа mimikatz, чтобы отправить команды репликации на контроллер домена.
  3. Получение учетных данных. Контроллер домена отправляет учетные данные (включая хеш-суммы паролей) хакеру.

Таким образом, DCSync позволяет атакующему получить доступ к хеш-суммам паролей всех пользователей домена, включая учетные записи с высокими привилегиями. Злоумышленник может использовать эти хеш-суммы для проведения других атак, таких как pass-the-hash или golden ticket, чтобы обеспечить себе неограниченный доступ к ресурсам домена.
Рекомендации:

  • Осуществляйте мониторинг запросов протокола DRSUAPI с операцией DsGetNCChanges (opcode 3) от серверов, не являющихся легитимными участниками процесса репликации. В журнале Security на контроллерах домена и в событиях аудита 4662 (An operation was performed on an object) необходимо отслеживать использование привилегий Replicating Directory Changes, Replicating Directory Changes All и Replicating Directory Changes In Filtered Set. Для обнаружения источника атаки следует коррелировать события 4662 и 4624 (An account was successfully logged on) с одинаковыми идентификаторами входа.
  • Вы можете включить в Active Directory мониторинг событий 4932 (Synchronization of a replica of an Active Directory naming context has begun) и 4937 (Replication failure begins) для обнаружения атак типа DCSync.
  • Дополнительно вы можете проводить аудит безопасности домена с помощью ПО PingCastle.

Атака DCShadow позволяет злоумышленникам регистрировать новый контроллер домена в AD и использовать его для внесения скрытых изменений в конфигурацию AD. В обычных условиях только легитимные контроллеры домена могут вносить изменения в конфигурацию AD, но DCShadow позволяет обойти этот механизм. Хакеры могут зарегистрировать свой собственный контроллер домена и использовать его для изменения данных в AD (например, для изменения атрибутов учетных записей пользователей или групп).
Основные этапы атаки:

  1. Получение привилегированного доступа. Для проведения атаки хакеру нужно получить привилегированную учетную запись.
  2. Имитация контроллера домена. Хакер создает и регистрирует в инфраструктуре AD поддельный контроллер домена.
  3. Внесение и синхронизация изменений в AD. Хакер, используя поддельный контроллер домена, вносит изменения в AD, которые затем распространяются на остальные контроллеры домена. Эти изменения могут включать в себя добавление новых пользователей, повышение привилегий существующих пользователей, создание новых групп или изменение политик безопасности. Поскольку механизм репликации AD доверяет всем зарегистрированным контроллерам домена, то изменения, внесенные поддельным контроллером домена, быстро распространятся по всей инфраструктуре.

Рекомендации:

  • Отслеживайте события регистрации новых контроллеров домена — 5137 (A directory service object was created) и 5141 (A directory service object was deleted).
  • В журнале Security на контроллерах домена и в событиях аудита 4662 (An operation was performed on an object) отслеживайте операции с привилегиями Domain Admin или Enterprise Admin, а также изменения в конфигурации домена. Для выявления источника атаки необходимо коррелировать события 5137 и 4662 с одинаковыми идентификаторами входа и временем.
  • Дополнительно рекомендуется включить мониторинг событий 4929 (An Active Directory replica source naming context was established) и 4930 (An Active Directory replica source naming context was removed) для отслеживания изменений в конфигурации репликации.
  • Также рекомендуется регулярно проводить аудит безопасности домена с помощью ПО PingCastle.

Pass-the-hash (PtH) — это техника, используемая хакерами для получения несанкционированного доступа к сетевым ресурсам. Основа техники заключается в том, что вместо пароля злоумышленник использует для аутентификации хеш-сумму этого пароля.
Когда пользователь входит в систему, его пароль преобразуется в хеш-сумму. Эта хеш-сумма используется для аутентификации, чтобы доказать, что пользователь знает пароль, не передавая его напрямую. Если хакер получает доступ к этим хеш-суммам, он может использовать их для аутентификации без необходимости вводить исходный пароль.
Overpass-the-hash (pass-the-key) — атака, при которой хакер использует хеш-сумму пароля для создания билета Kerberos и последующей аутентификации по нему.
Если overpass-the-hash (pass-the-key) использует хеш-сумму пароля для создания новых билетов Kerberos, то pass-the-ticket использует для аутентификации ранее сгенерированные Kerberos билеты.

Рекомендации:

  • Включите мониторинг событий аутентификации. В журнале Security на контроллерах домена и серверах следует отслеживать события 4624 (An account was successfully logged on) и 4625 (An account failed to log on) с целью выявления подозрительных попыток входа. Особое внимание следует уделять событиям, связанным с использованием NTLM и Kerberos.
  • Отслеживайте события 4768 (A Kerberos authentication ticket was requested), 4769 (A Kerberos service ticket was requested) и 4770 (A Kerberos service ticket was renewed) для выявления аномалий в запросах билетов Kerberos. Корреляция этих событий с одинаковыми идентификаторами входа и IP-адресами может помочь обнаружить источник атаки.
  • Ограничьте использование NTLM, по возможности отключите его и используйте Kerberos для аутентификации.
  • Используйте двухфакторную аутентификацию для доступа к критически важным системам.
  • Регулярно проводите аудит безопасности домена с помощью ПО PingCastle.

Golden ticket — это атака, при которой злоумышленник создает поддельный билет Kerberos (TGT) с целью получения неограниченного доступа к ресурсам домена. Проведение атаки возможно благодаря получению хеш-суммы пароля учетной записи krbtgt, которая является учетной записью службы Kerberos ticket-granting service.
Основные этапы атаки:

  1. Получение хеш-суммы пароля учетной записи krbtgt. Это специальная учетная запись в Active Directory, которая отвечает за выдачу и проверку билетов Kerberos.
  2. Создание поддельного билета Kerberos. Для этого хакер использует хеш-сумму пароля krbtgt.
  3. Получение доступа ко всем ресурсам домена с использованием TGT.

Golden ticket — одна из самых мощных атак на Active Directory: она предоставляет злоумышленнику практически неограниченный доступ к ресурсам домена. Хакер может аутентифицироваться от имени любой учетной записи, включая учетные записи с самыми высокими привилегиями.

Рекомендации:

  • Настройте для протокола Kerberos использование алгоритма шифрования AES (или другого надежного алгоритма) вместо RC4.
  • Ограничьте привилегии администратора домена, предоставив их только контроллерам домена и отдельным серверам. Для остальных административных функций создайте отдельные учетные записи.
  • Осуществляйте мониторинг подозрительной активности, такой как использование шифрования RC4 внутри TGT (ticket-granting ticket), а также запросы TGS (ticket-granting service) без предшествующего запроса TGT.
  • Отслеживайте время жизни билетов TGT для выявления отклонений от значений, установленных по умолчанию в домене.
  • Осуществляйте мониторинг аномальных событий Kerberos-аутентификации, содержащих вредоносные или пустые поля. Для этого рекомендуется отслеживать события 4624 (An account was successfully logged on), 4634 (An account was logged off) и 4672 (Special privileges assigned to new logon).
  • В случае если атака golden ticket была осуществлена, для предотвращения ее последствий рекомендуется дважды сбросить пароль служебной учетной записи krbtgt. Это приведет к аннулированию всех существующих «золотых билетов», полученных с использованием хеш-суммы NT учетной записи krbtgt, а также остальных билетов, полученных на ее основе. Кроме того, следует установить максимально возможную частоту смены пароля для учетной записи krbtgt.

Silver ticket — это атака, при которой злоумышленник создает поддельный билет на конкретную службу, а не на весь домен. В отличие от golden ticket, который предоставляет доступ ко всему домену, silver ticket позволяет атакующему получить доступ только к конкретным сервисам, например к файловым серверам или веб-приложениям. Эта атака менее заметна, чем golden ticket, так как нацелена на конкретные службы и может оставаться незамеченной стандартными средствами мониторинга.
Основные этапы атаки:

  1. Получение хеш-суммы пароля учетной записи службы. Сначала хакер получает хеш-сумму пароля учетной записи службы (service account).
  2. Создание поддельного service ticket. Используя полученную хеш-сумму, злоумышленник создает поддельный service ticket. Он содержит имя пользователя, список групп и другие атрибуты, которые определяют уровень доступа к ресурсу. Поддельный билет подписывается хеш-суммой пароля учетной записи службы.
  3. Получение доступа к целевой службе. Злоумышленник отправляет поддельный service ticket на сервер службы, который считает этот билет легитимным и предоставляет хакеру доступ к запрашиваемому ресурсу.

Рекомендации:

  • Использование сервисных билетов является легитимным действием в системе, поэтому в первую очередь необходимо выполнить действия, рекомендованные для предотвращения или усложнения получения учетных данных пользователей доменов, от имени которых возможен запрос сервисных билетов к значимым узлам и ресурсам.
  • Не применяйте в инфраструктуре устаревшие версии операционных систем и программного обеспечения, не поддерживающие современные методы аутентификации.
  • Настройте для протокола Kerberos использование алгоритма шифрования AES вместо RC4.
  • Осуществляйте проверку подлинности сертификата атрибутов привилегий (Privilege Attribute Certificate, PAC) для билетов TGS.
  • Используйте сложные и длинные (не менее 25 символов) пароли для сервисных учетных записей для защиты от подбора, а также регулярно производите их смену.
  • Используйте механизм «Управляемых учетных записей служб» (Managed Service Accounts). MSA поддерживает основные сервисы и службы, применяемые в корпоративной инфраструктуре (например, IIS, AD LDS, SQL Server, MS Exchange). Этот механизм автоматически производит смену паролей, генерирует комплексный случайный пароль из 240 символов, что значительно повышает сложность подбора пароля, а с учетом смены пароля по умолчанию раз в 30 дней — делает подбор практически невозможным.
  • Придерживайтесь принципа минимальных привилегий для сервисных учетных записей, включая привилегии, получаемые в результате членства в группах, например в группе администраторов домена.
  • Осуществляйте мониторинг аномальных событий Kerberos-аутентификации, содержащих вредоносные или пустые поля. Для этого рекомендуется отслеживать события 4624 (An account was successfully logged on), 4634 (An account was logged off) и 4672 (Special privileges assigned to new logon).
  • Осуществляйте мониторинг аномальных обращений к процессу lsass.exe на рабочих станциях и серверах. Общедоступные инструменты, предназначенные для снятия дампа учетных записей (например, ПО mimikatz), позволяют злоумышленнику, получившему доступ к процессу LSASS (Local Security Authority Subsystem Service), узнать секретный ключ LSA и расшифровать разделы памяти, где хранится информация об учетных записях, в том числе билеты Kerberos.

AS-REP roasting представляет собой атаку на протокол аутентификации Kerberos, направленную на получение хеш-сумм паролей учетных записей, которые не защищены предварительной аутентификацией (pre-authentication). Этот тип атаки позволяет злоумышленникам извлекать хеш-суммы паролей учетных записей и использовать их для дальнейших атак на систему.
Центральным компонентом в Kerberos является центр распространения ключей (key distribution center, KDC), который состоит из двух основных служб — authentication service (AS) и ticket-granting service (TGS). Процесс аутентификации пользователя включает следующие этапы:

  1. Authentication service request (AS-REQ). Пользователь отправляет запрос на аутентификацию, содержащий его имя и метку времени, зашифрованную с использованием его пароля.
  2. Authentication service response (AS-REP). KDC проверяет учетные данные пользователя и возвращает зашифрованный ticket-granting ticket (TGT), который пользователь может использовать для получения доступа к другим ресурсам.

В обычных условиях процесс предварительной аутентификации (pre-authentication) требует, чтобы пользователь предоставил доказательства своей «подлинности» перед выдачей TGT. Однако, если предварительная аутентификация отключена, KDC сразу и без дополнительной проверки отправляет AS-REP, содержащий зашифрованный TGT.
Основные этапы атаки:

  1. Поиск уязвимых учетных записей. Для этого хакер отправляет LDAP-запросы к контроллерам домена, чтобы выявить учетные записи, не защищенные предварительной аутентификацией.
  2. Отправка запроса AS-REQ. Злоумышленник отправляет AS-REQ к KDC от имени уязвимой учетной записи.
  3. Получение AS-REP. KDC отвечает сообщением AS-REP, содержащим зашифрованный TGT.
  4. Взлом хеш-суммы. Хакер извлекает зашифрованную часть AS-REP, взламывает хеш-сумму и получает пароль.

Рекомендации:

  • Используйте двухфакторную аутентификацию для привилегированных пользователей домена Active Directory. Для сервисных учетных записей используйте сложные и длинные пароли (не менее 25 символов), а также регулярно меняйте их.
  • Применяйте механизм «Управляемых учетных записей служб» (managed service accounts, MSA). MSA поддерживает ряд основных сервисов и служб, используемых в корпоративной инфраструктуре (например, IIS, AD LDS, SQL Server, MS Exchange). Этот механизм автоматически меняет пароли, генерируя сложные случайные пароли длиной до 240 символов, что значительно усложняет подбор пароля. Смена пароля по умолчанию раз в 30 дней делает подбор практически невозможным.
  • Определите учетные записи, для которых отключена предварительная аутентификация, и, если возможно, активируйте ее.
  • Настройте для протокола Kerberos использование алгоритма шифрования AES (или другого надежного алгоритма) вместо RC4.
  • Осуществляйте мониторинг событий изменения значения UAC, которые отражают отключение предварительной аутентификации. Для этого следует отслеживать события 4738 (A user account was changed) и 5136 (A directory service object was modified).
  • Проводите мониторинг запрашиваемых билетов Kerberos (Audit Kerberos Service Ticket Operations) и определяйте учетные записи с избыточными событиями 4768 (A Kerberos authentication ticket (TGT) was requested) и 4769 (A Kerberos service ticket was requested), в дополнительных параметрах которых указан тип шифрования RC4 (ticket encryption type — 0x17) и не требуется предварительная аутентификация (pre-authentication type — 0x0).
  • Проводите аудит безопасности домена с помощью ПО PingCastle.

NTLM relay — это атака, при которой злоумышленник перехватывает и перенаправляет учетные данные для аутентификации на другом сервере. Эта атака эксплуатирует уязвимости в протоколе NTLM, который позволяет передавать учетные данные на другой сервер без их расшифрования.
Когда пользователь пытается получить доступ к ресурсу (например, файлу или принтеру) в сети, NTLM использует серию сообщений между клиентом (устройством пользователя) и сервером для проверки подлинности. Этот процесс включает в себя три основные шага:

  1. Negotiate. Клиент отправляет запрос на сервер на установление соединения по протоколу NTLM.
  2. Challenge. Сервер отвечает случайным числом.
  3. Authenticate. Клиент хеширует это случайное число вместе с хешированным паролем пользователя и отправляет обратно серверу.

Основные этапы атаки:

  1. Перехват трафика. Хакер перехватывает сетевой трафик, содержащий учетные данные.
  2. Передача аутентификационных данных. Вместо взлома аутентификационных данных злоумышленник просто перенаправляет их на целевой сервер. Таким образом, он использует легитимные аутентификационные данные для получения доступа к другому ресурсу.
  3. Доступ к целевому ресурсу. Если атака прошла успешно, то хакер получает доступ к целевому ресурсу.

Рекомендации:

  • Отключите протокол WPAD. Для этого измените значение параметра Start с 3 на 4 в ветке реестра HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WinHttpAutoProxySvc. Если необходима автоматическая настройка параметров прокси, укажите полный путь к конфигурационному PAC-файлу.
  • Обеспечьте подпись SMB-пакетов как со стороны серверов, так и со стороны клиентов во всей доменной инфраструктуре.
  • Обеспечьте подпись LDAP-пакетов и настройте безопасную аутентификацию протокола LDAP.
  • Заблокируйте протоколы LAN Manager и NTLMv1 на уровне групповых политик.
  • Используйте механизм Extended Protection for Authentication (EPA).
  • Для уменьшения площади атаки добавьте пользователей с правами администратора в группу Protected Users и (или) установите для них атрибут Account is sensitive and cannot be delegated, что предотвратит делегирование полномочий. Также рекомендуется рассмотреть возможность перехода с NTLM-аутентификации на Kerberos-аутентификацию на всех узлах инфраструктуры.

Атрибут sAMAccountName — это имя учетной записи пользователя или компьютера в Active Directory. Оно должно быть уникальным в пределах домена и служит для идентификации пользователя при входе в систему. Однако злоумышленник может провести атаку sAMAccountName spoofing, во время которой создаст учетную запись с таким же именем. В результате он сможет использовать эту учетную запись для получения несанкционированного доступа к ресурсу.
Рекомендации:

  • Установите последние обновления безопасности KB5008380 и KB5008102.
  • Для выявления атак включите мониторинг ошибок objectClass и UserAccountControl, а также ошибок проверки имени учетной записи SAM. Важно отслеживать событие 4741 (a computer account was created) и проверять наличие символа «$» в атрибуте sAMAccountName, а также событие 4742 (a computer account was changed) с аналогичной проверкой. Также следует мониторить событие 4743 (a computer account was deleted).
  • Следует включить мониторинг запрашиваемых билетов Kerberos (Audit Kerberos Service Ticket Operations). Отслеживайте события, указывающие на то, что служба KDC обнаружила сервисный билет, не содержащий PAC, или билет с противоречивой информацией об учетной записи.
  • Проводите аудит безопасности домена с помощью ПО PingCastle.

Shadow credentials — это атака, которая позволяет хакеру изменить значения атрибута msDS-KeyCredentialLink атакуемой учетной записи. В результате проведения атаки хакер может добавить свой ключ в этот атрибут и использовать его для выпуска сертификата или запроса TGT, что обеспечит злоумышленнику легитимный доступ к целевым ресурсам.
Основные этапы атаки: хакер получает административный доступ к системе, после чего модифицирует атрибут msDS-KeyCredentialLink атакуемой учетной записи, добавляя свои ключи или сертификаты для дальнейшей аутентификации под этой учетной записью.

Рекомендации:

  • Запретите участникам группы Everyone изменять атрибут msDS-KeyCredentialLink для любой учетной записи в домене. Если по какой-либо причине это невозможно, необходимо организовать такой запрет для привилегированных учетных записей.
  • Настройте аудит всех операций с объектами для учетных записей с высоким уровнем привилегий.
  • Дополнительно проводите аудит безопасности домена с помощью ПО PingCastle.
  • Если в инфраструктуре (или для определенных пользователей) не используется механизм аутентификации PKINIT, следует осуществлять мониторинг события 4768 (A Kerberos authentication ticket was requested) для выявления инцидентов, когда в атрибуты сертификата была внесена информация.
  • Если список управления доступом к объектам (system access control list, SACL) настроен на аудит изменений объектов Active Directory для целевой учетной записи, событие 5136 (A directory service object was modified) позволяет выявлять изменение атрибута msDS-KeyCredentialLink. Важно отметить, что если это действие будет выполняться от имени учетной записи Azure AD Connect synchronization или службы AD FS, то оно не будет зафиксировано как инцидент, поскольку данные типы пользователей имеют легитимные права на изменение этого атрибута.

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

Существует несколько типов атак:

  • Modifiable SAN (ESC1). Хакер использует возможность изменения параметра SAN в шаблоне сертификата для создания сертификата с правами другого пользователя, включая администраторов.
  • Any or none purpose attack (ESC2). Злоумышленник использует шаблон с универсальными правами для получения сертификатов, которые могут аутентифицировать любого пользователя. Эти шаблоны не требуют специфической цели использования (extended key usage), что позволяет использовать их для аутентификации любых пользователей, включая администраторов.
  • Enrollment agent (ESC3). Атака через шаблон, который позволяет выпускать сертификаты от имени других пользователей. Злоумышленник получает сертификат Request Agent и затем использует его для создания сертификатов от имени учетных записей с высокими привилегиями.
  • Certificate ACL abuse (ESC4). Хакер использует слабую настройку ACL (списков контроля доступа) для захвата прав на шаблоны сертификатов. Они позволяют изменять параметры шаблона, чтобы сделать его уязвимым для других атак, таких как ESC1, что позволит получить привилегированные сертификаты.
  • Vulnerable PKI object access control (ESC5). Атака на другие объекты в инфраструктуре AD CS с уязвимыми параметрами доступа, которые могут позволить злоумышленнику компрометировать систему. Например, недостатки в конфигурации доступа к серверу CA могут быть использованы для выполнения операций с повышенными привилегиями.
  • Everything and for everyone (EDITF_ATTRIBUTESUBJECTALTNAME2). Хакеры используют флаг EDITF_ATTRIBUTESUBJECTALTNAME2 для добавления произвольных значений в поле SAN, чтобы аутентифицироваться от имени любого пользователя, включая администраторов домена.
  • ManageCA & managecertificate (ESC7). Злоумышленник может использовать права ManageCA для изменения параметров CA, что может включать активацию флага EDITF_ATTRIBUTESUBJECTALTNAME2 или других параметров, создающих уязвимости.
  • Relay на AD CS Web Enrollment (ESC8). Хакер может перенаправить NTLM-аутентификацию на уязвимый HTTP-эндпойнт, чтобы получить сертификат для клиентской аутентификации и использовать его для получения TGT (ticket-granting ticket) доменного контроллера.
  • No Security Extension (ESC9). Хакер использует значение CT_FLAG_NO_SECURITY_EXTENSION (0x80000) в атрибуте msPKI-Enrollment-Flag, чтобы предотвратить добавление расширения безопасности szOID_NTDS_CA_SECURITY_EXT в сертификат. Это позволяет обойти ограничения маппинга сертификатов, заданные значением 1 ключа реестра StrongCertificateBindingEnforcement, и использовать userPrincipalName (UPN) при аутентификации.
  • Weak Certificate Mappings (ESC10). Эта атака использует небезопасную конфигурацию маппинга сертификатов на контроллере домена, которая связана с параметрами CertificateMappingMethods со значением 0x18 (или содержащим флаг UPN) и StrongCertificateBindingEnforcement со значением 0. Эти настройки позволяют злоумышленнику, обладающему правом GenericWrite, получать сертификаты от имени других учетных записей.
  • Relaying NTLM to ICPR (ESC11). Хакер использует отсутствие атрибута IF_ENFORCEENCRYPTICERTREQUEST на сервере CA для выполнения ретрансляции NTLM (NTML relay) без подписи через службу RPC. Это позволяет запрашивать сертификаты через уязвимый сервер CA, используя учетные данные администратора домена.
  • Shell Access to ADCS CA with YubiHSM (ESC12). Эта атака предполагает, что частный ключ CA хранится на внешнем устройстве YubiHSM2, подключенном к серверу CA. Если злоумышленник получает доступ к реестру, где хранится пароль к YubiHSM, он может использовать этот пароль для доступа к закрытому ключу и подделки сертификатов через CA.
  • OID Group Link Abuse (ESC13). Шаблон сертификата может содержать политику выдачи, которая является OID в атрибуте msPKI-Certificate-Policy. Политика выдачи содержит атрибут msDS-OIDToGroupLink, который позволяет привязать политику к группе AD для того, чтобы пользователь мог авторизоваться в системе в качестве ее члена. Если злоумышленник обладает правами на выпуск сертификата по уязвимому шаблону, он может получить привилегии группы, связанной с этой политикой, и таким образом получить доступ к целевым ресурсам.
  • Weak Explicit Mapping (ESC14). Эта атака основана на небезопасной конфигурации явного маппинга сертификатов. Злоумышленник, скомпрометировавший атакуемую учетную запись и обладающий возможностью запрашивать сертификаты, может использовать небезопасную конфигурацию сопоставления для аутентификации от имени целевой учетной записи.

Рекомендации (зависят от типа атаки на службы сертификатов):

  • Отслеживайте события 4899 (A Certificate Services template was updated), в котором отображаются измененные атрибуты, и 4900 (Certificate Services template security was updated), в котором отображаются изменения разрешений безопасности. Стоит отметить, что эти события срабатывают не в момент внесения изменений в шаблон, а только при запросе сертификата с новыми свойствами.
  • Для выявления подозрительных запросов на получение сертификата следует отслеживать событие 4898 (Certificate Services loaded a template), в котором содержатся свойства шаблона выпускаемого сертификата. Наличие в этом событии флага ct_flag_enrollee_supplies_subject указывает на то, что пользователю разрешено указывать альтернативное имя субъекта в запросе. Также нужно отслеживать события 4886 (Certificate Services received a certificate request), 4887 (Certificate Services approved a certificate request and issued a certificate) и 4888 (Certificate Services denied a certificate request), в которых содержатся сведения о пользователе, запросившем сертификат, и узле, с которого запрос получен, а также время создания запроса.
  • Выполняйте мониторинг события 4768 (A Kerberos authentication ticket was requested) для выявления использования нелегитимных сертификатов по их серийному номеру при аутентификации.

В системе Windows есть служба Volume Shadow Copy Service (VSS), предназначенная для создания теневых копий файлов и томов. VSS позволяет выполнять резервное копирование системных файлов, не прерывая работу приложений и пользователей. Атака ShadowCoerce использует уязвимости протокола MS-FSRVP службы VSS и позволяет принудить учетную запись контроллера домена Active Directory авторизоваться на узле, подконтрольном злоумышленнику. В результате проведения атаки он сможет получить учетную запись контроллера домена.

Рекомендации:

  • Отключите на контроллерах домена службу теневого копирования (VSS) с помощью консоли управления.
  • Используйте механизм Extended Protection for Authentication (EPA).
  • Настройте обязательную подпись SMB-пакетов как на серверах, так и на клиентах.
  • Вы можете проводить регулярный аудит безопасности домена с помощью ПО PingCastle.

Следующие статьи

Понравилась статья? Поделить с друзьями:
0 0 голоса
Рейтинг статьи
Подписаться
Уведомить о
guest

0 комментариев
Старые
Новые Популярные
Межтекстовые Отзывы
Посмотреть все комментарии
  • Как закрепить bluetooth в панели задач windows 10
  • Тинькофф банк на windows phone
  • Как починить загрузчик windows xp
  • Как выглядит окно windows
  • Windows server 2016 минимальная длина пароля