غیرفعال‌سازی RC4 در Kerberos: راهنما (۲۰۲۶)

مقدمه: چرا باید RC4 رو در Kerberos غیرفعال کنیم؟

خب، احتمالاً تا الان خبرش به گوشتون رسیده: مایکروسافت از ژانویه ۲۰۲۶ شروع کرده به حذف تدریجی الگوریتم رمزگذاری RC4 از پروتکل احراز هویت Kerberos. این تغییر در قالب آسیب‌پذیری CVE-2026-20833 مستند شده و هدفش مقابله با حملات Kerberoasting هست — یعنی حملاتی که توشون مهاجم از ضعف الگوریتم RC4 سوءاستفاده می‌کنه، هش رمز عبور سرویس اکانت‌ها رو می‌کشه بیرون و بعد آفلاین کرکشون می‌کنه.

حالا چرا این موضوع برای ما تکنسین‌های هلپ دسک مهمه؟ راستش خیلی ساده‌ست. وقتی فاز اجرایی (Enforcement) بیاد، هر سرویس و اپلیکیشنی که هنوز به RC4 وابسته باشه از کار می‌افته. و حدس بزنید تیکت‌هاش کجا می‌ریزه؟ بله، دقیقاً — هلپ دسک. از تجربه می‌گم، اگه از الان آماده نباشید، اون هفته اول بعد از آپدیت آوریل واقعاً کابوس می‌شه. این راهنما قراره شما رو برای شناسایی، عیب‌یابی و رفع این مشکلات آماده کنه.

آسیب‌پذیری CVE-2026-20833 چیست؟

CVE-2026-20833 یک آسیب‌پذیری افشای اطلاعات (Information Disclosure) در Windows Kerberos هست با امتیاز CVSS 5.5. به زبون ساده، این آسیب‌پذیری به مهاجمانی که قبلاً احراز هویت شدن اجازه می‌ده تیکت‌های سرویس Kerberos رو با رمزگذاری ضعیف RC4 بگیرن و بعد با حملات brute-force آفلاین، رمز عبور سرویس اکانت‌ها رو بازیابی کنن.

شاید بگید ۵.۵ که خیلی بالا نیست. ولی مسئله اینه که اکسپلویت کردنش خیلی راحته و نتیجه‌ش می‌تونه فاجعه‌بار باشه.

حمله Kerberoasting چطوری کار می‌کنه؟

مهاجم با یک حساب کاربری عادی دامین وارد شبکه می‌شه (همین‌قدر کافیه!)
تیکت سرویس (TGS) برای سرویس اکانت‌های دارای SPN درخواست می‌کنه
اگه تیکت با RC4 رمزگذاری شده باشه، هش اون رو استخراج می‌کنه
هش رو به‌صورت آفلاین با ابزارهایی مثل Hashcat کرک می‌کنه
با رمز عبوری که به دست آورده، به سرویس‌ها و منابع حساس دسترسی پیدا می‌کنه

یه نکته کلیدی: هش‌های RC4 به‌مراتب سریع‌تر از هش‌های AES کرک می‌شن. یعنی واقعاً فرقش زمین تا آسمونه. به همین دلیله که مایکروسافت تصمیم گرفته RC4 رو به‌عنوان الگوریتم پیش‌فرض حذف کنه.

فازهای اجرایی مایکروسافت برای حذف RC4

بیایید ببینیم مایکروسافت چه برنامه‌ای چیده. فرایند حذف RC4 در سه فاز اجرا می‌شه:

فاز ۱ — حالت بازرسی (Audit Mode) — ژانویه ۲۰۲۶

با نصب آپدیت‌های امنیتی ۱۳ ژانویه ۲۰۲۶ به بعد، Domain Controllerها شروع می‌کنن به ثبت رویدادهای هشداری جدید. نکته خوبش اینه که در این فاز هیچ سرویسی مختل نمی‌شه. فقط Event IDهای جدیدی توی لاگ ثبت می‌شن که باید حتماً بهشون توجه کنید:

Event ID 201: استفاده از RC4 برای صدور تیکت سرویس شناسایی شده
Event ID 202: اکانتی بدون تنظیم صریح نوع رمزگذاری پیدا شده
Event ID 206: استفاده از RC4 در TGT شناسایی شده
Event ID 207: هشدار سازگاری برای فاز اجرایی

این فاز فرصت طلایی شماست. جدی می‌گم، اگه این دوره رو از دست بدید بعداً پشیمون می‌شید.

فاز ۲ — حالت اجرایی (Enforcement Mode) — آوریل ۲۰۲۶

خب اینجاست که اوضاع جدی می‌شه. با نصب آپدیت‌های آوریل ۲۰۲۶، مقدار پیش‌فرض DefaultDomainSupportedEncTypes به 0x18 (فقط AES-SHA1) تغییر می‌کنه. از این به بعد:

Domain Controllerها دیگه تیکت‌های RC4 صادر نمی‌کنن (مگه اینکه صراحتاً تنظیم شده باشه)
اپلیکیشن‌ها و سرویس‌هایی که به RC4 وابسته‌ان از کار می‌افتن
کاربران با خطاهای احراز هویت مواجه می‌شن

فاز ۳ — اجرای کامل — جولای ۲۰۲۶

آپدیت‌های جولای ۲۰۲۶ کلید رجیستری RC4DefaultDisablementPhase رو کلاً حذف می‌کنن. حالت بازرسی دیگه در دسترس نخواهد بود و RC4 فقط در صورت پیکربندی صریح روی اکانت‌ها قابل استفاده‌ست. یعنی دیگه راه برگشتی نیست.

چه سرویس‌هایی ممکنه مختل بشن؟

وقتی RC4 غیرفعال بشه، یه سری چیزا ممکنه به مشکل بخورن. بیایید یه نگاهی بندازیم:

۱. سیستم‌عامل‌های قدیمی

Windows XP، Windows Server 2003 و نسخه‌های قدیمی‌تر اصلاً از AES پشتیبانی نمی‌کنن. اگه هنوز (بله، می‌دونم، ولی بعضی سازمان‌ها هنوز دارن) این سیستم‌ها توی شبکه‌تون فعالن، بعد از اجرای Enforcement احراز هویتشون کاملاً می‌خوابه.

۲. سرویس اکانت‌های دارای SPN

این مورد از تجربه بگم، رایج‌ترین مشکلیه که باهاش مواجه می‌شید. سرویس اکانت‌هایی که msDS-SupportedEncryptionTypes روشون تنظیم نشده و رمز عبورشون از قبل از مهاجرت به AES تغییر نکرده، فقط کلیدهای RC4 دارن و نمی‌تونن تیکت AES دریافت کنن.

۳. فایل‌های Keytab

اپلیکیشن‌های لینوکسی و سرویس‌هایی که از فایل‌های Keytab برای احراز هویت استفاده می‌کنن، بعد از غیرفعال‌سازی RC4 نیاز به تولید مجدد Keytab با الگوریتم AES دارن. این یکی رو خیلی‌ها یادشون می‌ره.

۴. Trust Relationships بین دامین‌ها

اگه Trust بین دو دامین با AES پیکربندی نشده باشه، احراز هویت بین‌دامینی با شکست مواجه می‌شه. مخصوصاً توی محیط‌هایی که چند دامین دارن این می‌تونه خیلی دردسرساز بشه.

۵. اپلیکیشن‌های Third-Party

نرم‌افزارهای قدیمی ERP، سیستم‌های بایگانی، و اپلیکیشن‌های سازمانی که بدون پشتیبانی از AES طراحی شدن. راستش بعضی از این نرم‌افزارها سال‌هاست آپدیت نشدن و vendor‌شون هم ممکنه دیگه ساپورتشون نکنه.

راهنمای عملی: شناسایی استفاده از RC4 در محیط شما

روش ۱: بررسی Event Log در Domain Controller

بعد از نصب آپدیت ژانویه ۲۰۲۶، اولین کاری که باید بکنید اینه که رویدادهای زیر رو توی Event Viewer بررسی کنید:

# باز کردن Event Viewer و فیلتر بر روی رویدادهای KDCSVC
Get-WinEvent -FilterHashtable @{
    LogName = "System"
    Id = 201, 202, 206, 207
} | Format-Table TimeCreated, Id, Message -AutoSize

روش ۲: بررسی Event ID 4769 در Security Log

Event ID 4769 هر بار که یه تیکت سرویس Kerberos صادر می‌شه ثبت می‌شه. حالا اگه مقدار Ticket Encryption Type برابر 0x17 باشه، یعنی از RC4 استفاده شده. این دستور کمکتون می‌کنه پیداشون کنید:

# جستجوی تیکت‌های سرویس RC4 در Security Log
Get-WinEvent -FilterHashtable @{
    LogName = "Security"
    Id = 4769
} | Where-Object {
    $_.Message -match "0x17"
} | Select-Object TimeCreated,
    @{N="Account";E={($_.Message -split "`n" | Select-String "Account Name").ToString().Split(":")[1].Trim()}},
    @{N="Service";E={($_.Message -split "`n" | Select-String "Service Name").ToString().Split(":")[1].Trim()}} |
    Format-Table -AutoSize

روش ۳: بررسی اکانت‌های بدون تنظیم نوع رمزگذاری

این روش خیلی مهمه چون اکانت‌هایی که اصلاً نوع رمزگذاری براشون مشخص نشده، همون‌هایی هستن که بعداً مشکل‌ساز می‌شن:

# یافتن اکانت‌هایی که msDS-SupportedEncryptionTypes تنظیم نشده
Get-ADUser -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_."msDS-SupportedEncryptionTypes" -eq $null -or
                   $_."msDS-SupportedEncryptionTypes" -eq 0 } |
    Select-Object Name, SamAccountName, Enabled |
    Format-Table -AutoSize

# همین بررسی برای سرویس اکانت‌ها
Get-ADServiceAccount -Filter * -Properties msDS-SupportedEncryptionTypes |
    Where-Object { $_."msDS-SupportedEncryptionTypes" -eq $null -or
                   $_."msDS-SupportedEncryptionTypes" -eq 0 } |
    Select-Object Name, SamAccountName |
    Format-Table -AutoSize

روش ۴: استفاده از اسکریپت‌های رسمی مایکروسافت

مایکروسافت خودش دو تا اسکریپت PowerShell توی مخزن GitHub منتشر کرده که کارتون رو راحت‌تر می‌کنه:

List-AccountKeys.ps1: کلیدهای رمزگذاری موجود برای هر اکانت رو لیست می‌کنه
Get-KerbEncryptionUsage.ps1: نوع رمزگذاری Kerberos در حال استفاده رو شناسایی می‌کنه

پیشنهاد می‌کنم حتماً از اینا استفاده کنید. خروجیشون خیلی تمیز و قابل فهمه.

راهنمای رفع مشکل: وقتی کاربران بعد از آپدیت نمی‌تونن احراز هویت کنن

سناریوی ۱: خطای «The encryption type requested is not supported by the KDC»

این رایج‌ترین خطاییه که بعد از اجرای Enforcement می‌بینید. من خودم توی محیط تست اولین چیزی بود که باهاش مواجه شدم.

اقدامات فوری:

اکانت سرویس مربوطه رو شناسایی کنید
نوع رمزگذاری فعلیش رو بررسی کنید:

# بررسی نوع رمزگذاری اکانت
Get-ADUser -Identity "serviceaccount" -Properties msDS-SupportedEncryptionTypes |
    Select-Object Name, msDS-SupportedEncryptionTypes

AES رو فعال کنید:

# تنظیم AES128 + AES256 برای اکانت
Set-ADUser -Identity "serviceaccount" -Replace @{
    "msDS-SupportedEncryptionTypes" = 24
}

# مقدار 24 = AES128 (8) + AES256 (16)
# مقدار 28 = AES128 (8) + AES256 (16) + RC4 (4) — اگر نیاز به سازگاری موقت دارید

رمز عبور سرویس اکانت رو ریست کنید تا کلیدهای AES جدید تولید بشن:

# ریست رمز عبور برای تولید کلیدهای AES
Set-ADAccountPassword -Identity "serviceaccount" -Reset -NewPassword (ConvertTo-SecureString "P@ssw0rd!NewStr0ng2026" -AsPlainText -Force)

یه نکته مهم: ریست رمز عبور رو یادتون نره! خیلی‌ها فقط Attribute رو عوض می‌کنن ولی پسوورد رو ریست نمی‌کنن و بعد تعجب می‌کنن چرا هنوز کار نمی‌کنه. دلیلش اینه که کلیدهای AES فقط موقع تغییر رمز عبور ساخته می‌شن.

سناریوی ۲: شکست SSO در اپلیکیشن‌های وب

اگه بعد از آپدیت، Single Sign-On اپلیکیشن‌های وب (مثل SharePoint، IIS) از کار افتاد، نگران نباشید — قابل حله:

SPN مربوطه رو بررسی کنید:

# لیست SPNهای ثبت‌شده برای اکانت سرویس
setspn -L serviceaccount

اکانت Application Pool رو به AES ارتقا بدید
Keytab جدید تولید کنید (در صورت استفاده):

# تولید Keytab جدید با AES256
ktpass /out service.keytab /princ HTTP/[email protected] /mapuser serviceaccount /crypto AES256-SHA1 /pass * /ptype KRB5_NT_PRINCIPAL

سناریوی ۳: شکست احراز هویت بین دامین‌ها (Cross-Domain)

برای Trust Relationships این دستور رو اجرا کنید تا ببینید وضعیت رمزگذاریشون چطوریه:

# بررسی نوع رمزگذاری Trust
Get-ADTrust -Filter * | Select-Object Name, Direction,
    @{N="EncType";E={
        $t = Get-ADObject -Identity $_.DistinguishedName -Properties msDS-SupportedEncryptionTypes
        $t."msDS-SupportedEncryptionTypes"
    }} | Format-Table -AutoSize

اگه مقدار EncType برابر null هست یا شامل RC4 می‌شه، باید AES رو فعال کنید:

# فعال‌سازی AES روی Trust
Set-ADObject -Identity "CN=trustname,CN=System,DC=domain,DC=com" -Replace @{
    "msDS-SupportedEncryptionTypes" = 24
}

تنظیمات رجیستری مهم

خب بیایید ببینیم کلید رجیستری اصلی برای کنترل فازهای اجرایی چیه و چطوری باهاش کار کنیم:

Windows Registry Editor Version 5.00

; مسیر: HKLM\Software\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters
; نام مقدار: RC4DefaultDisablementPhase (REG_DWORD)
; مقادیر:
;   0 = بدون تغییر (بدون بازرسی و بدون اجرا)
;   1 = حالت بازرسی — فقط ثبت رویداد (پیش‌فرض فاز ۱)
;   2 = حالت اجرایی — RC4 پیش‌فرض غیرفعال

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters]
"RC4DefaultDisablementPhase"=dword:00000001

توجه: تغییر این مقدار نیاز به ری‌استارت Domain Controller داره. این رو جدی بگیرید — بدون ری‌استارت تغییرات اعمال نمی‌شه.

چک‌لیست آمادگی برای تیم هلپ دسک

قبل از رسیدن فاز اجرایی آوریل ۲۰۲۶، این کارها رو حتماً انجام بدید. من اینا رو بر اساس اولویت مرتب کردم:

آپدیت ژانویه ۲۰۲۶ رو نصب کنید — فاز بازرسی فعال بشه
Event IDهای 201-209 رو مانیتور کنید — هر اکانت یا سرویسی که هنوز RC4 استفاده می‌کنه شناسایی بشه
لیست اکانت‌های آسیب‌پذیر رو تهیه کنید — اکانت‌هایی که msDS-SupportedEncryptionTypes ندارن
رمز عبور سرویس اکانت‌ها رو ریست کنید — تا کلیدهای AES تولید بشن
Keytab‌ها رو بازسازی کنید — با الگوریتم AES256
Trust Relationships رو بررسی و ارتقا بدید
اپلیکیشن‌های Third-Party رو تست کنید — با فعال‌سازی دستی Enforcement روی یه DC تستی
مستندات Runbook بنویسید — برای رفع سریع مشکلات احتمالی بعد از اجرا

راستش مورد ۸ رو خیلی‌ها نادیده می‌گیرن ولی وقتی ساعت ۲ شب یه سرویس حیاتی خوابیده و شما باید سریع عکس‌العمل نشون بدید، داشتن یه Runbook آماده نجاتتون می‌ده.

فعال‌سازی دستی Enforcement برای تست

اگه می‌خواید قبل از آوریل ۲۰۲۶ ببینید تأثیر تغییرات توی محیط تست چطوریه (که خب، شدیداً توصیه می‌کنم این کار رو بکنید):

# فعال‌سازی Enforcement Mode روی DC تستی
Set-ItemProperty -Path "HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\Kerberos\Parameters" `
    -Name "RC4DefaultDisablementPhase" `
    -Value 2 `
    -Type DWord

# ری‌استارت DC برای اعمال تغییرات
Restart-Computer -Force

هشدار: این کار رو فقط در محیط تست انجام بدید. جدی می‌گم. فعال‌سازی Enforcement توی محیط Production بدون آمادگی کامل می‌تونه باعث اختلال گسترده بشه و اون روز خیلی خیلی بد می‌شه براتون.

پرسش‌های متداول

آیا غیرفعال کردن RC4 باعث از کار افتادن تمام سرویس‌ها می‌شه؟

نه، نگران نباشید. فقط سرویس‌هایی که صراحتاً یا به‌صورت پیش‌فرض از RC4 استفاده می‌کنن تحت تأثیر قرار می‌گیرن. اکثر سیستم‌های مدرن (Windows Server 2008 به بعد) از AES پشتیبانی می‌کنن. مشکل اصلی مربوط به اکانت‌هاییه که Attribute مربوط به نوع رمزگذاری (msDS-SupportedEncryptionTypes) روشون تنظیم نشده.

تفاوت حالت بازرسی (Audit) و اجرایی (Enforcement) چیه؟

در حالت بازرسی، Domain Controller فقط رویدادهای هشداری ثبت می‌کنه ولی همچنان تیکت‌های RC4 صادر می‌کنه — یعنی هیچی نمی‌شکنه. در حالت اجرایی، صدور تیکت RC4 برای اکانت‌های بدون تنظیم صریح متوقف می‌شه و سرویس‌های وابسته با خطا مواجه می‌شن. خلاصه: Audit فقط نگاه می‌کنه، Enforcement عمل می‌کنه.

آیا بعد از جولای ۲۰۲۶ هنوز می‌شه از RC4 استفاده کرد؟

بله، ولی فقط اگه صراحتاً توی Attribute مربوطه (msDS-SupportedEncryptionTypes) اکانت یا تنظیمات KDC فعال شده باشه. حالت بازرسی حذف می‌شه و دیگه امکان بازگشت به رفتار قبلی وجود نداره. پس اگه واقعاً به RC4 نیاز دارید (مثلاً یه نرم‌افزار قدیمی که جایگزینی نداره)، باید صریحاً اون رو فعال نگه دارید.

چطوری بدون اختلال در سرویس‌ها، RC4 رو غیرفعال کنم؟

اول آپدیت ژانویه ۲۰۲۶ رو نصب کنید و Event IDهای جدید رو حداقل ۲ تا ۴ هفته مانیتور کنید. تمام اکانت‌های شناسایی‌شده رو به AES ارتقا بدید، رمز عبورشون رو ریست کنید، و بعد توی محیط تست Enforcement رو فعال کنید. بعد از تأیید عملکرد صحیح، Enforcement رو در محیط Production فعال کنید. عجله نکنید — ۲ تا ۴ هفته مانیتورینگ واقعاً لازمه.

حساب KRBTGT چه نقشی توی این تغییرات داره؟

حساب KRBTGT برای رمزگذاری تمام Ticket Granting Ticketها (TGT) استفاده می‌شه. از Windows Server 2008 به بعد و در سطح عملکردی دامین ۲۰۰۸، حساب KRBTGT همیشه از AES استفاده می‌کنه. با این حال، توصیه می‌شه قبل از غیرفعال‌سازی RC4، رمز عبور KRBTGT رو دو بار ریست کنید (بار دوم حداقل ۱۱ ساعت بعد) تا هرگونه Golden Ticket قبلی باطل بشه. این یکی از اون کارهاییه که خیلی‌ها فراموشش می‌کنن ولی از نظر امنیتی فوق‌العاده مهمه.