Kerberos Delegation: নেটওয়ার্ক পারমিশনের অপব্যবহার করে সিস্টেমে অননুমোদিত প্রবেশ!

Kerberos অথেনটিকেশনে একটি Service Ticket নির্দিষ্ট সার্ভিসের জন্য ইস্যু করা হয়। যদি সেই সার্ভিস তার কাজ সম্পন্ন করতে আরেকটি সার্ভিসের সাহায্য নেয়, এবং সেই দ্বিতীয় সার্ভিসেরও ব্যবহারকারীর পরিচয় প্রয়োজন হয়, তাহলে কী হবে? এই Double Hop সমস্যার সমাধান হিসেবে Kerberos Delegation আবিষ্কৃত হয়েছে।

ক্লাসিক উদাহরণ—একটি Intranet ওয়েব অ্যাপ্লিকেশনে ব্যবহারকারী লগইন করেন (IIS server)। সেই অ্যাপ্লিকেশন ব্যবহারকারীর হয়ে SQL Server-এ ডেটা কোয়েরি করতে চায়, এবং SQL Server-এর ভিতরে রো-লেভেল সিকিউরিটি বা ভিউ থাকতে পারে যা ব্যবহারকারী-নির্দিষ্ট। এই কাজের জন্য IIS-কে SQL Server-এ ব্যবহারকারীর হয়ে অথেন্টিকেট করতে হবে।

Microsoft তিন ধরনের Delegation মেকানিজম প্রদান করেছে। Unconstrained Delegation সবচেয়ে পুরোনো, Windows 2000 থেকে; Constrained Delegation Windows 2003-এ এসেছে; এবং Resource-Based Constrained Delegation Windows 2012-এ আধুনিক বিকল্প হিসেবে যুক্ত হয়েছে।

Unconstrained Delegation-এ যখন একজন ব্যবহারকারী একটি Delegation-চিহ্নিত সার্ভারে অথেনটিকেট করেন, তখন সেই সার্ভারে ব্যবহারকারীর TGT-এর একটি কপি পাঠানো হয়। সার্ভার এই TGT ব্যবহার করে পরে যেকোনো অন্য সার্ভিসে ব্যবহারকারীর হয়ে অ্যাক্সেস করতে পারে—কোনো সীমাবদ্ধতা ছাড়াই।

এই "Unconstrained" শব্দটিই বিপদের সংকেত। যদি একটি সার্ভারে Unconstrained Delegation সক্রিয় থাকে এবং সেই সার্ভার কোনোভাবে compromised হয়, তাহলে আক্রমণকারী সেই সার্ভারে লগইন করা যেকোনো ব্যবহারকারীর TGT মেমোরি থেকে এক্সট্রাক্ট করতে পারেন।

আক্রমণের ক্লাসিক পরিস্থিতি—আক্রমণকারী একটি Unconstrained Delegation সক্ষম সার্ভারে অ্যাক্সেস পেলেন। তারা SpoolSample বা Printerbug (MS-RPRN) ব্যবহার করে একটি Domain Controller-কে সেই সার্ভারে অথেন্টিকেট করতে বাধ্য করেন। DC-এর TGT সার্ভারের LSASS মেমোরিতে চলে আসে। Mimikatz দিয়ে সেই TGT এক্সট্রাক্ট করে, আক্রমণকারী এখন DC-এর হয়ে যেকোনো কাজ করতে পারেন—DCSync থেকে Golden Ticket।

ডিটেকশন এবং প্রতিরক্ষা—কোন কোন কম্পিউটার ও ইউজার অ্যাকাউন্টে Unconstrained Delegation সক্রিয় তা জানতে PowerView বা LDAP কোয়েরি ব্যবহার করুন। যেখানে সম্ভব এটি অক্ষম করুন। Domain Admin এবং অন্যান্য সংবেদনশীল অ্যাকাউন্টকে Protected Users গ্রুপে যুক্ত করুন এবং "Account is sensitive and cannot be delegated" পতাকা সেট করুন।

Constrained Delegation Unconstrained-এর সীমাবদ্ধতা সমাধানের জন্য এসেছে। এখানে একটি সার্ভিস শুধু নির্দিষ্ট তালিকার সার্ভিসগুলোতে delegation করতে পারে। কনফিগারেশনে msDS-AllowedToDelegateTo অ্যাট্রিবিউটে অনুমোদিত SPN-গুলোর তালিকা থাকে।

দুটি মোড রয়েছে—"Use Kerberos only" এবং "Use any authentication protocol" (Protocol Transition)। দ্বিতীয়টি বিশেষভাবে আক্রমণযোগ্য কারণ এতে S4U2Self extension সক্রিয় হয়, যা সার্ভিসকে যেকোনো ব্যবহারকারীর হয়ে নিজের জন্য একটি TGS অনুরোধ করতে দেয়।

S4U2Self এবং S4U2Proxy দুটি Kerberos extension Constrained Delegation-এর ভিত্তি। আক্রমণের পরিস্থিতি—যদি একজন আক্রমণকারী একটি Protocol Transition সক্ষম অ্যাকাউন্টের ক্রেডেনশিয়াল পান, তারা S4U2Self ব্যবহার করে যেকোনো ব্যবহারকারীর (Domain Admin সহ) জন্য নিজের সার্ভিসে TGS তৈরি করতে পারেন, এবং তারপর S4U2Proxy দিয়ে অনুমোদিত target সার্ভিসে delegate করতে পারেন।

impacket-এর getST.py এই আক্রমণের জন্য জনপ্রিয় টুল। উদাহরণ—getST.py -spn cifs/dc.domain.local -impersonate Administrator domain.local/svc_account:password। এর ফলে CIFS সার্ভিসে Administrator হিসেবে অ্যাক্সেস পাওয়া যায়।

প্রতিরক্ষা—Protocol Transition শুধু একান্ত প্রয়োজনে এবং সাবধানে ব্যবহার করুন। যেসব অ্যাকাউন্টে এটি সক্রিয় তাদের অডিট করুন। Sensitive অ্যাকাউন্টে "Account is sensitive and cannot be delegated" সেট করুন—এই পতাকা S4U2Self-কে ব্লক করে।

Resource-Based Constrained Delegation বা RBCD Windows 2012-এ আধুনিক বিকল্প হিসেবে যুক্ত হয়েছে। এর মূল পার্থক্য—Classical Constrained Delegation-এ delegation-এর অনুমতি utility (source) সার্ভিসে কনফিগার করা হয়, কিন্তু RBCD-তে এটি resource (target) সার্ভিসে কনফিগার করা হয়।

এর সুবিধা—Forest-এর সীমানা পার হয়ে কাজ করে, এবং Domain Admin-এর পরিবর্তে resource-এর owner নিজেই delegation অনুমোদন করতে পারেন। কিন্তু এই নমনীয়তাই বিপদের কারণ হতে পারে।

RBCD আক্রমণের ক্লাসিক পরিস্থিতি—Elad Shamir-এর "Wagging the Dog" গবেষণা থেকে। যদি একজন আক্রমণকারী একটি কম্পিউটার অ্যাকাউন্টের msDS-AllowedToActOnBehalfOfOtherIdentity প্রপার্টি লিখতে পারেন, তবে তারা সেই কম্পিউটারে যেকোনো ব্যবহারকারী হিসেবে অ্যাক্সেস তৈরি করতে পারেন।

আক্রমণের ধাপ—প্রথমে একটি কম্পিউটার অ্যাকাউন্ট তৈরি করুন (ডিফল্টভাবে যেকোনো ডোমেইন ব্যবহারকারী এটি করতে পারেন, MS-DS-Machine-Account-Quota=10)। তারপর PowerView বা Set-RBCD স্ক্রিপ্ট ব্যবহার করে target কম্পিউটারের অ্যাকাউন্টে আপনার নতুন কম্পিউটার অ্যাকাউন্টের অনুমতি লিখুন। অবশেষে S4U2Self এবং S4U2Proxy ব্যবহার করে target-এ Domain Admin হিসেবে অ্যাক্সেস।

impacket দিয়ে—addcomputer.py -computer-name 'ATTACKER$' -computer-pass 'Password123!' domain.local/user:pass, তারপর rbcd.py -delegate-from 'ATTACKER$' -delegate-to 'TARGET$' -action 'write' domain.local/user:pass, এবং সবশেষে getST.py -spn cifs/target.domain.local -impersonate Administrator domain.local/ATTACKER\$:password।

ms-DS-MachineAccountQuota হলো ডিফল্টভাবে ১০ সেট করা একটি অ্যাট্রিবিউট, যা প্রতিটি ব্যবহারকারীকে ১০টি পর্যন্ত কম্পিউটার অ্যাকাউন্ট তৈরি করতে দেয়। এই ফিচার Active Directory-র প্রথম দিন থেকে রয়েছে, কিন্তু আধুনিক আক্রমণের প্রেক্ষাপটে এটি একটি বড় ঝুঁকি।

RBCD আক্রমণ ছাড়াও, এই কম্পিউটার অ্যাকাউন্টগুলো বিভিন্ন অন্য আক্রমণে কাজে আসে—NTLM Relay, Resource-Based Constrained Delegation, এবং কাস্টম প্রিভিলেজ এসকেলেশনে। প্রতিরক্ষা—ms-DS-MachineAccountQuota শূন্য সেট করুন এবং কম্পিউটার যোগের অনুমতি শুধু নির্দিষ্ট IT অ্যাডমিন গ্রুপের কাছে দিন।

আধুনিক আক্রমণে NTLM Relay এবং Kerberos Delegation প্রায়ই চেইন করা হয়। যদি আক্রমণকারী একটি ক্লায়েন্টকে অথেন্টিকেট করতে বাধ্য করতে পারেন (LLMNR/NBT-NS poisoning, Printerbug, PetitPotam), তবে তারা সেই অথেনটিকেশন একটি LDAP সার্ভারে relay করতে পারেন।

LDAP রিলে-এর মাধ্যমে আক্রমণকারী target কম্পিউটার অ্যাকাউন্টে RBCD প্রপার্টি লিখতে পারেন, এবং তারপর সেই অ্যাকাউন্টে Domain Admin হিসেবে অ্যাক্সেস তৈরি করতে পারেন। PetitPotam (CVE-2021-36942) এই চেইনে গুরুত্বপূর্ণ ভূমিকা পালন করে—এটি একটি unauthenticated forced authentication যা Domain Controller-কে বাধ্য করতে পারে।

Kerberos Delegation আক্রমণ সনাক্তকরণে কয়েকটি মূল ইভেন্ট মনিটর করতে হয়। Event ID 4769 (Kerberos Service Ticket request) অস্বাভাবিক প্যাটার্নে—একই উৎস থেকে অনেক ভিন্ন সার্ভিসের জন্য টিকেট, বা S4U2Self-এর প্রমাণ। Event ID 4768 (TGT request) এবং 4624 (logon)।

Microsoft Defender for Identity বিশেষভাবে delegation-সম্পর্কিত আক্রমণ সনাক্তে সক্ষম। BloodHound delegation-ভিত্তিক attack path দৃশ্যমান করে—Kerberoasting, RBCD, এবং Unconstrained Delegation সবগুলো এজ হিসেবে দেখায়।

কাস্টম PowerShell স্ক্রিপ্ট দিয়ে নিয়মিত অডিট চালান—কোন অ্যাকাউন্টে delegation সেট করা, msDS-AllowedToActOnBehalfOfOtherIdentity-এ কারা লিখতে পারে, ইত্যাদি। PingCastle, Purple Knight-এর মতো বিনামূল্যের টুল AD নিরাপত্তা মূল্যায়নে সাহায্য করে।

Kerberos Delegation সুরক্ষায় বহু-স্তরের পদ্ধতি প্রয়োজন। প্রথম, Unconstrained Delegation মুছে ফেলুন যেখানে সম্ভব। দ্বিতীয়, সংবেদনশীল অ্যাকাউন্ট (Domain Admin, Service Account) Protected Users গ্রুপে যুক্ত করুন। তৃতীয়, "Account is sensitive and cannot be delegated" পতাকা সেট করুন।

চতুর্থ, ms-DS-MachineAccountQuota শূন্য সেট করুন। পঞ্চম, KrbtgtKeyDistributionCenterAccountLogonRestrictions পলিসি ব্যবহার করে delegation চেইনে ব্যবহারকারী restrict করুন। ষষ্ঠ, Privileged Access Management সলিউশন (CyberArk, BeyondTrust) ব্যবহার করে privileged account এর ব্যবহার নিয়ন্ত্রণ ও লগ করুন।

সপ্তম, gMSA ব্যবহার করুন service account-এর জন্য, যা স্বয়ংক্রিয় পাসওয়ার্ড রোটেশন এবং কম attack surface প্রদান করে। অষ্টম, Print Spooler সার্ভিস বন্ধ করুন Domain Controller এবং Member Server-এ যেখানে এটির প্রয়োজন নেই—এটি Printerbug attack বন্ধ করে।

নবম, EDR এবং XDR সলিউশন ডিপ্লয় করুন যা Mimikatz এবং Rubeus-এর মতো টুলের behavior সনাক্ত করতে পারে। দশম, নিয়মিত Red Team অনুশীলন এবং Purple Team এক্সারসাইজ চালান।