Windows & AD: Охота на Kerberoasting. Находим "слабые" сервисные учетки

Один из самых опасных векторов атаки на Active Directory — Kerberoasting. Злоумышленник запрашивает TGS-билет для сервисной учетной записи (SPN) с "простым" паролем, брутфорсит его в оффлайне и получает доступ.

Архитектор безопасности не ждет, пока это произойдет. Он проактивно охотится на уязвимые учетные записи. Этот PowerShell-скрипт покажет вам все учетные записи в домене, которые могут быть целью для Kerberoasting.

Что делает скрипт:

Находит в AD всех пользователей, у которых задан ServicePrincipalName (SPN).
Отсекает "белый шум" (компьютеры и встроенные учетки, которые обычно имеют сложные пароли).
Выводит список пользовательских учетных записей с SPN — это ваши главные кандидаты на проверку.

Код скрипта (требуется модуль ActiveDirectory):

PowerShell

Import-Module ActiveDirectory

Write-Host "--- Начинаю поиск учетных записей, уязвимых для Kerberoasting ---" -ForegroundColor Cyan

# Находим всех пользователей, у которых есть SPN,
# и которые не являются отключенными или компьютерами.
$PotentialTargets = Get-ADUser -Filter {
    ServicePrincipalName -like "*" -and
    Enabled -eq $true
} -Properties ServicePrincipalName, SamAccountName, PasswordLastSet

if (-not $PotentialTargets) {
    Write-Host "[OK] Пользовательских учетных записей с SPN не найдено." -ForegroundColor Green
    exit
}

Write-Host "[!!!] ОБНАРУЖЕНЫ ПОТЕНЦИАЛЬНЫЕ ЦЕЛИ ДЛЯ KERBEROASTING:" -ForegroundColor Red
Write-Host "Эти учетные записи ДОЛЖНЫ иметь пароль из 25+ символов или управляться через gMSA."

$PotentialTargets | Format-Table -AutoSize @(
    @{Name="User"; Expression={$_.SamAccountName}},
    @{Name="ServicePrincipalName"; Expression={$_.ServicePrincipalName -join ','}},
    @{Name="PasswordLastSet"; Expression={$_.PasswordLastSet}}
)

Write-Host "`nРекомендация: Проверьте пароли этих УЗ или переведите их на gMSA."

Взгляд архитектора: Обнаружение — это полдела. Правильное решение — не просто "сделать пароль сложнее". Архитектурное решение — полностью убрать пароли из конфигов и перевести сервисы на gMSA (group Managed Service Accounts), где Windows сама управляет 240-символьными паролями.

#windows #security #activedirectory #kerberos #powershell #cybersecurity #скрипты #musthave

Windows: Защита «второго прыжка». Что такое Resource-Based Constrained Delegation?

Вам нужно, чтобы веб-сервис (Frontend) мог обращаться к базе данных (Backend) от имени пользователя. Старое решение (KCD): Вы настраиваете делегирование на Frontend-сервисе, давая ему право «притворяться» пользователем при обращении к Backend. Это сложно, требует прав Domain Admin и создает мощную «учетку», которую любят атаковать.

Новое решение: Resource-Based Constrained Delegation (RBCD) Это «делегирование наоборот», представленное в Windows Server 2012.

Как работает: Вы настраиваете Backend-сервис (например, файловый сервер или SQL) и говорите ему: «Я разрешаю вот этому Frontend-сервису присылать мне пользователей».

Право делегирования хранится на ресурсе, а не на учетной записи-посреднике.

Как настроить (PowerShell):
PowerShell

# 1. Получаем учетку Frontend-сервиса (кто будет делегировать)
$FrontendService = Get-ADComputer -Identity "WEB-SRV-01"

# 2. Настраиваем Backend-сервис (кому делегируют)
# Мы "разрешаем" WEB-SRV-01 действовать от имени других
Set-ADComputer -Identity "SQL-SRV-01" -PrincipalsAllowedToDelegateToAccount $FrontendService

Взгляд архитектора: Это фундаментальный сдвиг к модели Zero Trust. Вы больше не создаете «супер-учетки» с широкими правами. Вместо этого, каждый ресурс сам определяет, кому он доверяет. Это безопаснее, проще в аудите и работает между разными доменами и лесами.

#windows #security #activedirectory #kerberos #architect #гайд

AD Security: Kerberoasting — это "вход". Pass-the-Ticket — это "движение"

Боль: Мы уже говорили, как хакеры "вытаскивают" хэши сервисных учеток (Kerberoasting). Но что они делают дальше?

Реакция админа: "Я просто сменю пароль уязвимой учетке SQL-Service". Реакция архитектора: "Я пойму, куда он мог с ней пойти, и закрою этот путь".

Pass-the-Ticket (PtT) — это техника Lateral Movement (бокового смещения).

Как это работает:
1. Атакующий (через Kerberoasting) получил Kerberos-билет (TGS) для службы SQL-Service. Пароль ему не нужен.
2. Он "инжектит" этот билет в свою сессию (mimikatz, Rubeus).
3. Теперь он — SQL-Service.
4. Он смотрит, куда SQL-Service имеет права (например, SQL-Service — локальный админ на FILE-SRV-01).
5. Он "прыгает" на FILE-SRV-01 (через PsExec или WMI) с правами SQL-Service и повторяет цикл.

Взгляд архитектора: Это доказывает, почему Admin Tier Model и Принцип Наименьших Привилегий (PoLP) — это не "бюрократия", а фундамент защиты.
* Ваша SQL-Service (Tier 1) не должна быть админом на FILE-SRV-01 (Tier 1).
* Ваша HelpDesk (Tier 2) не должна иметь прав на серверах (Tier 1).

Компрометация одной учетки не должна приводить к компрометации всего домена.

#security #windows #activedirectory #kerberos #cybersecurity #architect #гайд

Windows (Security): "Крепость" внутри AD. Внедряем Authentication Silos

Боль: Ваш Domain Admin залогинился на ноутбук HelpDesk ( Tier 2 ), чтобы "быстро что-то поправить".
Хакер, сидящий на этом ноутбуке, ворует его Kerberos-билет и через 5 минут захватывает Контроллер Домена (атака Pass-the-Ticket ).

Реакция админа: "Я больше так не буду".
Реакция архитектора: "Я сделаю так, чтобы этот билет был бесполезен".

Authentication Silos (Хранилища Аутентификации) — это ваш "ядерный бункер" внутри AD.
Это контейнер, который привязывает высокопривилегированные учетки (как Domain Admins ) только к высокопривилегированным хостам (как Domain Controllers ).

Как это работает:
1. Вы создаете "Silo" (Хранилище) и "Policy" (Политику).
2. Вы помещаете в "Silo" своих Domain Admins и свои Domain Controllers.
3. Kerberos (KDC) теперь выдает непередаваемые (non-forwardable) билеты. TGT (билет), выданный для Domain Admin'а, не может быть использован для доступа ни к чему, кроме хостов из этого же "Silo" (то есть, к другим DC).

Взгляд архитектора: Это реальное, техническое принуждение для вашей Admin Tier Model. Вы не "надеетесь", что админ не залогинится на ПК. Вы гарантируете, что если он это сделает, его украденный билет будет просто бесполезным мусором для хакера.

#windows #security #activedirectory #kerberos #zerotrust #architect #гайд #musthave

🎟️ Windows: "Доступ дал, а не пускает!" (Kerberos Purge)

Классика: Вы добавили пользователя в группу "Бухгалтерия", чтобы он открыл сетевую папку. Он пробует — "Отказано в доступе". Вы говорите: "Перезагрузись" или "Выйди и зайди". Это работает, но это долго и бесит юзера, у которого открыто 20 вкладок.

Причина: Windows использует Kerberos. При входе пользователь получает TGT (Ticket Granting Ticket), в котором "зашиты" его группы. Тикет живет 10 часов. Пока он не обновится, система не знает про новую группу.

Решение без перезагрузки: Очистите кэш тикетов прямо в сеансе пользователя.

Команда (в CMD/PowerShell пользователя):

klist purge

После этого при следующей попытке открыть папку Windows запросит новый тикет у контроллера домена, уже с новыми правами. Магия!

#windows #kerberos #ad #troubleshooting #access #cmd #lifehack

🪟 Windows: dMSA в Server 2025 — Microsoft дала нам инструмент и сразу два способа им порезаться

Коллеги, поговорим о ситуации, которую я называю "security feature, meet security incident". Windows Server 2025 принёс delegated Managed Service Accounts (dMSA) — красивая замена старым сервисным учёткам с паролем "Service2019!" в Confluence. dMSA привязывает аутентификацию к идентичности конкретной машины: только явно указанные машины в AD могут получить доступ к учётной записи, что закрывает классический Kerberoasting.

Звучит хорошо. Но есть нюанс.

Исследователи из Akamai нашли атаку BadSuccessor: злоумышленник с минимальными правами на любой OU в домене может создать вредоносный dMSA, который имитирует процесс миграции и наследует все права любого пользователя — вплоть до Domain Admin. При этом права над целевой учёткой не нужны вообще. Patch до сих пор в разработке.

Что делать прямо сейчас — аудит и ограничение прав на создание dMSA:

# Akamai выпустили скрипт для аудита — запускаем и смотрим кто может создавать dMSA
# Скачиваем с их GitHub:
# https://github.com/akamai/BadSuccessor

# Ручная проверка — кто имеет право создавать объекты типа msDS-DelegatedServiceAccount в OU
Import-Module ActiveDirectory

$OUs = Get-ADOrganizationalUnit -Filter * -Properties nTSecurityDescriptor

foreach ($OU in $OUs) {
    $acl = Get-Acl "AD:$($OU.DistinguishedName)"
    $acl.Access | Where-Object {
        $_.ActiveDirectoryRights -match "CreateChild" -and
        $_.ObjectType -eq [guid]"ce206244-5827-4a86-ba1c-1c0c386c1b64"
        # ObjectType для msDS-DelegatedServiceAccount
    } | Select-Object IdentityReference, ActiveDirectoryRights |
    ForEach-Object {
        [PSCustomObject]@{
            OU       = $OU.Name
            Identity = $_.IdentityReference
            Rights   = $_.ActiveDirectoryRights
        }
    }
} | Format-Table -AutoSize | Export-Csv "dMSA_create_rights_audit.csv" -NoTypeInformation

# Включаем аудит событий dMSA — чтобы хотя бы видеть атаку
auditpol /set /subcategory:"Directory Service Changes" /success:enable /failure:enable

# Мониторим Event ID 5136 — изменения атрибута msDS-DelegatedMSAState
# и Event ID 4662 — изменения msDS-ManagedAccountPrecededByLink
# Эти два события вместе = сигнал возможной BadSuccessor-атаки
Get-WinEvent -LogName "Security" -FilterXPath `
  "*[System[EventID=5136] and EventData[Data[@Name='AttributeLDAPDisplayName']='msDS-DelegatedMSAState']]" |
  Select TimeCreated, Message | Format-List

Зачем это нужно:
По данным Akamai, в 91% исследованных сред нашлись пользователи за пределами группы Domain Admins, у которых были права для проведения этой атаки. Если у вас Server 2025 DC в домене — проверьте, кто может создавать dMSA объекты, прямо сегодня. Это займёт 10 минут.

Итог: Microsoft сделала dMSA для защиты от Kerberoasting — и это правильно. Но разворачивать новую фичу в продакшн без аудита прав — всё равно что поставить бронедверь и забыть закрыть окно. Следите за патчем.

#windows #activedirectory #security #dmsa #kerberos #sysadmin #admin_future

🪟 Windows: Kerberos RC4 enforcement уже включился — что сломалось и что делать

Коллеги, апрельский Patch Tuesday принёс не только патчи, но и тихое изменение, которое уже ломает аутентификацию в тех средах, где не подготовились.

Начиная с апреля 2026 года, апрельское накопительное обновление меняет дефолтное поведение Kerberos KDC: для учётных записей без явно заданного msDS-SupportedEncryptionTypes теперь выдаются только AES-SHA1-билеты. RC4 больше не используется по умолчанию.

Что это значит практически: сервисные учётки, NAS-устройства, принтеры, старые приложения и любая учётка без явного атрибута шифрования — потенциальная жертва. Симптомы: ошибки "KDC has no support for encryption type", сервисы не стартуют, авторизация в приложениях падает.

В июле 2026 поведение зафиксируется окончательно и откат в режим аудита станет невозможен. Времени мало.

# ШАГ 1: Ищем учётки БЕЗ AES-ключей
# Скрипт от Microsoft (GitHub: microsoft/Kerberos-Crypto):
# List-AccountKeys.ps1 — находит аккаунты с RC4 но без AES

# Ручная проверка: смотрим Event ID 201, 202 в System Log DC
Get-WinEvent -LogName System -ComputerName (hostname) |
    Where-Object {$_.Id -in @(201,202,206,207)} |
    Select-Object TimeCreated, Id, Message |
    Format-List

# ШАГ 2: Для сервисных учёток — сбрасываем пароль (генерирует AES-ключи)
Set-ADAccountPassword -Identity "svc_sql" -Reset `
    -NewPassword (ConvertTo-SecureString "NewP@ssw0rd!" -AsPlainText -Force)

# ШАГ 3: Явно задаём шифрование для проблемных учёток
# 0x18 = AES128 + AES256, 0x1C = AES128 + AES256 + RC4 (временно)
Set-ADUser -Identity "svc_legacy_app" `
    -KerberosEncryptionType AES128,AES256

# ШАГ 4: Временный откат если уже всё сломалось
# Возвращаем DC в режим аудита (работает ДО июля 2026):
Set-ItemProperty `
    -Path "HKLM:\SYSTEM\CurrentControlSet\Services\Kdc" `
    -Name "RC4DefaultDisablementPhase" -Value 1

# ШАГ 5: Проверяем krbtgt — если пароль не менялся с 2008 года, AES-ключей нет
Get-ADUser krbtgt -Properties msDS-SupportedEncryptionTypes,PasswordLastSet |
    Select-Object Name, PasswordLastSet, msDS-SupportedEncryptionTypes
# Если PasswordLastSet старше 2012 — сбрасываем ДВАЖДЫ с репликацией между сбросами

Зачем это нужно:
RC4 позволяет Kerberoasting: атакующий запрашивает билет, зашифрованный RC4, и взламывает его оффлайн. Современные GPU делают это за минуты. Microsoft убирает RC4 принудительно — и это правильно.

Итог: аудит уже три месяца доступен через Event ID 201-202. Если ты не смотрел — посмотри сегодня. Июль ждать не будет.

#windows #kerberos #activedirectory #security #sysadmin #admin_future

🪟 Windows: RC4 в Kerberos — июль финализирует, а у тебя ещё не готово

Коллеги, сегодня последний день Windows Server Summit 2026. И главная тема которая звучала все три дня — RC4 в Kerberos. Не потому что новая. Потому что июль близко, а большинство до сих пор не закончили аудит.

Хронология жёсткая: январь 2026 — аудит-режим, предупреждающие события в логах DC. Апрель 2026 — enforcement: AES-SHA1 по умолчанию для учёток без явного msDS-SupportedEncryptionTypes. Июль 2026 — финал: RC4 убирается из протокольного пути полностью, ключ реестра RC4DefaultDisablementPhase игнорируется.

Что реально сломается если не подготовиться: сервисные учётки, NAS-устройства, принтеры, старые приложения, любая учётка без явного атрибута шифрования. Симптом: ошибка «KDC has no support for encryption type», сервисы не стартуют, авторизация в приложениях падает.

# ШАГ 1: Смотрим Event ID 201-209 на DC — кто ещё использует RC4
Get-WinEvent -LogName System -ComputerName (hostname) |
    Where-Object {$_.Id -in @(201,202,203,206,207)} |
    Select-Object TimeCreated, Id, Message |
    Format-List | Select-Object -First 20

# Что означают ID:
# 201 — RC4 использован (клиент только RC4, у сервиса нет msDS-SET)
# 202 — RC4 использован (у учётки нет AES-ключей)
# 203 — RC4 ЗАБЛОКИРОВАН (это уже ошибка в апрельском enforcement)

# ШАГ 2: Ищем учётки без AES-ключей
Get-ADUser -Filter {Enabled -eq $true} `
    -Properties msDS-SupportedEncryptionTypes, PasswordLastSet,
    ServicePrincipalNames |
    Where-Object {$_.ServicePrincipalNames -ne $null} |
    Select-Object Name, PasswordLastSet, msDS-SupportedEncryptionTypes |
    Where-Object {$_.msDS-SupportedEncryptionTypes -eq $null -or
                  $_."msDS-SupportedEncryptionTypes" -eq 0}

# ШАГ 3: Генерируем AES-ключи для сервисных учёток
# Сброс пароля генерирует новые ключи автоматически:
Set-ADAccountPassword -Identity "svc_app01" -Reset `
    -NewPassword (ConvertTo-SecureString "NewP@ss2026!" -AsPlainText -Force)

# Явно задаём поддерживаемое шифрование:
Set-ADUser -Identity "svc_app01" `
    -KerberosEncryptionType AES128,AES256

# ШАГ 4: Проверяем krbtgt — если старый, AES-ключей нет:
Get-ADUser krbtgt -Properties PasswordLastSet,
    msDS-SupportedEncryptionTypes |
    Select-Object Name, PasswordLastSet, msDS-SupportedEncryptionTypes
# Если PasswordLastSet до 2012 — сбрасываем ДВАЖДЫ с репликацией

# ШАГ 5: Проверяем Event 4768/4769 на RC4-тикеты:
Get-WinEvent -LogName Security |
    Where-Object {$_.Id -in @(4768,4769)} |
    ForEach-Object {
        if ($_.Message -match "0x17") {
            Write-Host "RC4 ticket: $($_.TimeCreated) - $($_.Message)" `
                -ForegroundColor Red
        }
    } | Select-Object -First 10

Зачем это срочно именно сейчас: после июля 2026 аудит-режим убирается и реестровый ключ игнорируется. Единственный откат — вручную включить RC4 для конкретной учётки. Это не план, это последний шанс перед аварией.

Итог: Event ID 201/202 на DC — смотри прямо сейчас. Каждое событие это учётка или сервис, который упадёт в июле. У тебя меньше двух месяцев.

#windows #kerberos #activedirectory #rc4 #security #sysadmin #admin_future

🪟 Windows: Пятничный дайджест — что закрыть до выходных по майским дедлайнам

Коллеги, конец рабочей недели — самое время для быстрой проверки: что из майских задач закрыто, а что уйдёт в понедельник с риском стать проблемой.

Три критических дедлайна ближайших недель — статус на сегодня:

Secure Boot — истечение в июне (осталось ~5 недель):
Системы без обновлённых сертификатов Secure Boot потеряют возможность получать security updates для Secure Boot после июня 2026, не будут доверять стороннему ПО подписанному новыми сертификатами, и не получат исправлений для Windows Boot Manager после октября 2026.

Entra hard match — дедлайн 1 июня (осталось 10 дней):
С 1 июня блокируется возможность синхронизировать cloud-privileged учётки через Entra Connect. Если не проверено — проверь прямо сейчас.

Kerberos RC4 — финал в июле (осталось ~6 недель):
После июля реестровый ключ RC4DefaultDisablementPhase игнорируется. Если не провёл аудит Event 201/202 — время поджимает.

# ПЯТНИЧНЫЙ ЧЕКЛИСТ — 3 команды, 5 минут:

# 1. Secure Boot статус (топ-10 серверов по риску):
Get-ADComputer -Filter {OperatingSystem -like "*Server*"} |
    Select-Object -First 10 Name |
    ForEach-Object {
        Invoke-Command -ComputerName $_.Name -ScriptBlock {
            $sb = Get-ItemProperty `
                "HKLM:\SYSTEM\CurrentControlSet\Control\SecureBoot\Servicing\" `
                -Name "UEFICA2023Status" -EA SilentlyContinue
            "$env:COMPUTERNAME : $(if($sb){$sb.UEFICA2023Status}else{'NOT_STARTED'})"
        } -EA SilentlyContinue
    }

# 2. RC4 — сколько событий за эту неделю (если много — срочно):
Get-WinEvent -LogName System -ComputerName (hostname) |
    Where-Object {$_.Id -in @(201,202,203) -and
        $_.TimeCreated -gt (Get-Date).AddDays(-7)} |
    Group-Object Id | Select-Object Name, Count

# 3. Entra hard match — есть ли привилегированные sync'd учётки:
# (быстрая проверка без Graph модуля)
Get-ADUser -Filter {Enabled -eq $true} `
    -Properties MemberOf, adminCount |
    Where-Object {$_.adminCount -eq 1} |
    Select-Object SamAccountName, DistinguishedName |
    Export-Csv "friday_privcheck.csv" -NoTypeInformation
Write-Host "Привилегированных учёток: $((Import-Csv friday_privcheck.csv).Count)"
# Если > 20 — стоит пересмотреть список до понедельника

Что реально можно сделать за пятницу:

ЧТО МОЖНО ЗАКРЫТЬ ЗА 30 МИНУТ:
  - Запустить Secure Boot update task на 5-10 серверах
  - Посмотреть RC4 events за неделю
  - Сохранить список NOT_STARTED серверов для понедельника

ЧТО НЕ ТРОГАТЬ В ПЯТНИЦУ ВЕЧЕРОМ:
  - Не менять пароли krbtgt без подготовки
  - Не обновлять DC в конце недели без снапшота
  - Не применять Kerberos-политики без тестовой группы

Итог: пятница — для аудита и планирования, не для опасных изменений. Три команды выше покажут где ты стоишь. Остальное — в понедельник с холодной головой.

#windows #secureboot #kerberos #security #patchmanagement #sysadmin #admin_future

🪟 Windows: Июльский Patch Tuesday — рекорд 622 CVE, RoguePlanet закрыт, и новый LegacyHive

Коллеги, вчера вышел July Patch Tuesday. Держитесь.

Microsoft опубликовал 622 уязвимости в июльском Patch Tuesday, включая рекордные 416 уязвимостей Windows. Microsoft известно об эксплуатации в дикой природе двух из сегодняшних уязвимостей, обе добавлены в CISA KEV.

Хорошая новость: RoguePlanet закрыт. Патч вышел через Malware Protection Engine версии 1.1.26060.3008 — OOB-обновление 8-9 июля, до регулярного Patch Tuesday.

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

И сразу же после вчерашнего PT: появился новый PoC LegacyHive — позволяет непривилегированному пользователю монтировать чужой user hive.

Три приоритета на сегодня:

# 1. КРИТИЧНО: CVE-2026-55040 — SharePoint Authentication Bypass
# Rapid7 нашли цепочку: этот баг + второй (August PT) = unauthenticated RCE
# SharePoint Server Subscription Edition, 2019, 2016 — патчить немедленно
Get-HotFix | Where-Object {$_.InstalledOn -ge "2026-07-13"} |
    Select-Object HotFixID, InstalledOn | Sort-Object InstalledOn -Descending

# 2. КРИТИЧНО: CVE-2025-47981 — SPNEGO NEGOEX buffer overflow CVSS 9.8
# Wormable, no auth, no interaction, все Windows с Server 2008R2
# Уже в прошлом месяце был в preview — проверяем что закрыт:
$spnego = Get-HotFix | Where-Object {$_.HotFixID -like "*KB509*"}
$spnego | Format-Table

# 3. RoguePlanet — проверяем версию Defender Engine:
Get-MpComputerStatus | Select-Object AMEngineVersion
# Нужна >= 1.1.26060.3008

# Для air-gapped систем — принудительное обновление:
Update-MpSignature -UpdateSource InternalDefinitionUpdateServer

# 4. ДЕДЛАЙН который пришёл сегодня — Kerberos RC4 ФИНАЛ:
# Реестровый ключ RC4DefaultDisablementPhase больше не существует
# Проверяем нет ли RC4-only учёток которые теперь упадут:
Get-WinEvent -LogName System -ComputerName (hostname) |
    Where-Object {$_.Id -eq 205} |
    Select-Object TimeCreated, Message | Format-List | Select-Object -First 5
# Event 205 = RC4 ticket запрошен — эти учётки теперь не аутентифицируются

# 5. SQL Server 2016 — сегодня EOL extended support
# Переходит в платный ESU с 15 июля 2026
# SharePoint 2016 и 2019 — вчера последний день поддержки (нет ESU!)

Примечательное изменение в Patch Tuesday: Security Update Guide Microsoft больше не перечисляет отдельные уязвимости — только сводную таблицу количества по семействам продуктов и секцию "Notable CVEs". Это прямое следствие экспоненциального роста объёмов: при 622 CVE детальный listing становится неуправляемым.

Итог: 622 CVE — это не читать, это триажировать. SPNEGO NEGOEX (wormable 9.8) и SharePoint RCE — патчить сегодня. Kerberos RC4 — проверяй Event 205 прямо сейчас.

#windows #patchtuesday #sharepoint #kerberos #security #sysadmin #admin_future

🧠 Skills: RC4 в Kerberos окончательно похоронен. Если в AD что-то «само сломалось» с лета — проверяйте это первым

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

📌 ФАКТЫ (CVE-2026-20833, этапы выпиливания RC4)
Январь 2026 — Режим аудита: включен мониторинг событий KDCSVC с кодами 201–209 в журнале System без блокировки трафика.

Апрель 2026 — Дефолтный AES: для всех аккаунтов без явно заданных алгоритмов шифрования дефолтом стал AES. Фолбэк на устаревший RC4 был практически отключен.

Июль 2026 — Полный отказ: режим аудита окончательно удален из кода. Параметр реестра RC4DefaultDisablementPhase больше не учитывается операционной системой, а фолбэк на RC4 вырезан из протокола на уровне KDC.

Что ломается: любые учетные записи, у которых атрибут msDS-SupportedEncryptionTypes равен 0x4 / 0x7 (только RC4/DES) или вообще не задан, если клиент или сервис не умеют согласовывать AES.

💥 КТО В ЗОНЕ РИСКА
Сервисные учетки (gMSA / sMSA / обычные пользователи с SPN) с древними паролями: в базе NTDS банально отсутствуют AES-ключи до тех пор, пока учетке не сбросят пароль.

Linux-интеграции и демоны с устаревшими keytab: Samba, прокси-серверы, Java-бэкенды, Tomcat, веб-SSO, где keytab нарезался сто лет назад под RC4 (rc4-hmac).

Legacy-железо: древние СХД, прошивки принтеров/МФУ и сетевые сканеры с доменной авторизацией.

🛠 ДИАГНОСТИКА ЧЕРЕЗ POWERSHELL
Выполняем на контроллере домена или рабочей станции с RSAT:

PowerShell

# 1. Поиск сервисных учеток (с SPN) без явного AES или застрявших на RC4
Get-ADUser -LDAPFilter '(&(servicePrincipalName=*)(|(!(msDS-SupportedEncryptionTypes=*))(msDS-SupportedEncryptionTypes=4)(msDS-SupportedEncryptionTypes=7)))' `
  -Properties servicePrincipalName, msDS-SupportedEncryptionTypes, PasswordLastSet |
  Select SamAccountName, msDS-SupportedEncryptionTypes, PasswordLastSet

# 2. Мониторинг запросов билетов с шифрованием RC4 (TicketEncryptionType = 0x17)
Get-WinEvent -LogName Security -MaxEvents 2000 -FilterXPath `
  "*[System[EventID=4769] and EventData[Data[@Name='TicketEncryptionType']='0x17']]" |
  ForEach-Object { ([xml]$_.ToXml()).Event.EventData.Data |
    Where-Object { $_.Name -in 'TargetUserName','ServiceName','IpAddress' } |
    ForEach-Object { "$($_.Name)=$($_.'#text')" } } | Select-Object -First 60

# 3. Проверка событий KDC в журнале System (ошибки согласования типов шифрования)
Get-WinEvent -FilterHashtable @{
    LogName      = 'System'; 
    ProviderName = 'Microsoft-Windows-Kerberos-Key-Distribution-Center'; 
    Id           = 201..209
} -MaxEvents 50 -ErrorAction SilentlyContinue

🔧 РЕШЕНИЕ ПРОБЛЕМЫ
Включить флаг в реестре для возврата к RC4 больше нельзя — лазейку закрыли. Выход только один: планомерно переводить всё на AES.

PowerShell

# Шаг 1. Явно разрешаем использование современных типов шифрования
Set-ADUser svc_app -KerberosEncryptionType AES128,AES256

# Шаг 2. ОБЯЗАТЕЛЬНО меняем пароль (только в этот момент генерируются хеши AES!)
Set-ADAccountPassword svc_app -Reset

# Шаг 3. Перевыпускаем keytab для Linux-хостов с поддержкой AES256
# Через ktpass:
# ktpass /princ HTTP/app.corp.local@CORP.LOCAL /pass * /crypto AES256-SHA1 /ptype KRB5_NT_PRINCIPAL /out app.keytab
# Либо через msktutil:
# msktutil --enctypes 0x18 --auto-update

💡 В ЧЁМ СУТЬ

Времени на плавную раскатку больше нет — фолбэка нет физически. Отдельный маркер при ревизии: колонка

PasswordLastSet

. Если у сервисной учетки пароль не трогали с 2012 года, то помимо отсутствия AES-ключей вы получаете готовую дыру для атак Kerberoasting с мгновенным подбором слабого хеша в офлайне.

План на смену: выгрузить сервисные аккаунты без AES, запланировать смену паролей с владельцами сервисов и пересобрать ключевые keytab-файлы. Это час спокойной работы, который избавит вас от ночного дежурства при падении SSO.

#skills #activedirectory #kerberos #rc4 #aes #security #windows #powershell #sysadmin #admin_future

⏱️ Ubuntu 27.04 переходит на ntpd-rs. Повод проверить, кто вообще задаёт время в вашей сети

Коллеги, среда. Время — сервис, о котором вспоминают, только когда внезапно разваливается аутентификация в Kerberos.

📌 ФАКТЫ
Планы Canonical: в релизе Ubuntu 26.10 пакет ntpd-rs включён в архив для открытого тестирования, а начиная с Ubuntu 27.04 он станет системной службой времени по умолчанию.

Архитектурная причина: переход на memory-safe реализацию протокола NTP на языке Rust со встроенной поддержкой NTS (Network Time Security).

Критичность точного времени: от стабильности часов напрямую зависят валидация цепочек TLS-сертификатов, работа тикетов Kerberos, корреляция меток в журналах SIEM и сквозной аудит событий.

🛠 ПРОВЕРКА ЗА МИНУТУ
1. Хосты под управлением Linux
Bash

# Общий статус службы времени и синхронизации
timedatectl

# Текущее смещение, стратум и активный источник (chrony)
chronyc tracking

# Детальный список апстрим-серверов и их состояние
chronyc sources -v

2. Инфраструктура Windows / Active Directory
PowerShell

# Общий статус службы Windows Time и текущее смещение
w32tm /query /status

# Фактический источник синхронизации для хоста
w32tm /query /source

# Замер расхождения времени с контроллером домена в реальном времени
w32tm /stripchart /computer:dc01 /samples:5 /dataonly

⚠️ ТИПОВЫЕ ОШИБКИ В СЕТЯХ
Неверный источник на контроллере: источник у DC определяется как Local CMOS Clock или VM IC Time Synchronization Provider — в итоге время всего домена задаётся батарейкой BIOS материнской платы либо дрейфующими часами гипервизора.

Нарушение иерархии FSMO: внешний стратум NTP настроен не на держателе роли PDC Emulator, а на произвольном контроллере домена.

Конфликт синхронизации на виртуальных DC: на виртуальных машинах контроллеров домена оставлена включённой интеграция времени с хостом виртуализации (Integration Services / VMware Tools Time Sync).

💡 В ЧЁМ СУТЬ

Протокол Kerberos по умолчанию допускает расхождение часов не более 5 минут.

Иерархия времени в инфраструктуре должна быть строго монолитной:

Внешний доверенный NTP-пул → PDC Emulator → остальные DC домена → рядовые серверы и клиенты.

Любая самодеятельность в этой цепочке превращается в причину «плавающих» и трудноуловимых сбоев входа в домен.

#skills #ntp #time #activedirectory #kerberos #ubuntu #linux #sysadmin #admin_future