Golden Ticket: Active Directory-তে অ্যাডমিন অ্যাক্সেস নিয়ে নেটওয়ার্কের স্থায়ী নিয়ন্ত্রণ!

Golden Ticket বুঝতে হলে প্রথমে Kerberos প্রটোকলের কাজের প্রক্রিয়া বুঝতে হবে। Kerberos হলো Microsoft Active Directory-র ডিফল্ট অথেনটিকেশন প্রটোকল, যা MIT-তে ১৯৮০-এর দশকে তৈরি হয়েছিল। এই প্রটোকল তিনটি প্রধান উপাদান নিয়ে গঠিত: Client, Service, এবং Key Distribution Center (KDC)—যা একটি Domain Controller-এ চলে।

KDC-এর দুটি মূল উপাদান রয়েছে: Authentication Service (AS) এবং Ticket Granting Service (TGS)। Kerberos অথেনটিকেশনে তিনটি ধাপ থাকে। প্রথম ধাপে ক্লায়েন্ট AS-এ পাসওয়ার্ড-ভিত্তিক প্রমাণ পাঠিয়ে একটি Ticket Granting Ticket (TGT) সংগ্রহ করে। দ্বিতীয় ধাপে ক্লায়েন্ট সেই TGT-এর সাথে TGS-এ যায় এবং নির্দিষ্ট পরিষেবার জন্য একটি Service Ticket (TGS Ticket) পায়। তৃতীয় ধাপে ক্লায়েন্ট সেই Service Ticket দিয়ে কাঙ্ক্ষিত পরিষেবায় লগইন করে।

এই পুরো প্রক্রিয়ায় সবচেয়ে গুরুত্বপূর্ণ উপাদান হলো TGT, যা KDC একটি বিশেষ অ্যাকাউন্ট—krbtgt-এর পাসওয়ার্ড হ্যাশ দিয়ে এনক্রিপ্ট ও সাইন করে। krbtgt একটি Built-in অ্যাকাউন্ট যা প্রতিটি AD ডোমেইনে স্বয়ংক্রিয়ভাবে তৈরি হয় এবং ডিজেবল অবস্থায় থাকে; এর একমাত্র কাজ হলো TGT এনক্রিপ্ট করা।

Golden Ticket Attack-এর মূল ভিত্তি হলো krbtgt অ্যাকাউন্টের NTLM হ্যাশ চুরি করা। যখন অ্যাটাকার এই হ্যাশ পেয়ে যায়, তখন সে KDC-এর সম্মতি ছাড়াই নিজে থেকেই বৈধ দেখতে যেকোনো TGT তৈরি করতে পারে। কারণ Kerberos-এ TGT-এর বৈধতা যাচাই হয় শুধুমাত্র krbtgt হ্যাশ দিয়ে এনক্রিপ্ট করা সিগনেচার দেখে।

একটি জাল TGT-তে অ্যাটাকার যা কিছু চায় তা ঢোকাতে পারে: যেকোনো ব্যবহারকারীর নাম (এমনকি অস্তিত্বহীন কেউ), Domain Admins বা Enterprise Admins গ্রুপের সদস্যপদ, এবং অস্বাভাবিক দীর্ঘ মেয়াদ (ডিফল্ট ১০ ঘণ্টার পরিবর্তে ১০ বছর পর্যন্ত)। এই TGT যেহেতু সঠিক ক্রিপ্টোগ্রাফিক সিগনেচার বহন করে, Domain Controller সেটিকে বৈধ বলে গ্রহণ করে এবং পরবর্তী Service Ticket ইস্যু করে।

আক্রমণের ক্রম সাধারণত এরকম: অ্যাটাকার প্রথমে কোনো একটি সিস্টেমে Initial Access পায় (Phishing, Vulnerable Service, Stolen Credential ইত্যাদির মাধ্যমে)। তারপর Lateral Movement করে Domain Controller-এ পৌঁছায় বা DCSync অধিকার পায়। DCSync হলো একটি বৈধ AD প্রোটোকল যা Replication-এর জন্য ব্যবহৃত হয়; কিন্তু অপব্যবহার করলে এটি krbtgt-সহ সমস্ত অ্যাকাউন্টের হ্যাশ ফাঁস করে দেয়।

হ্যাশ পাওয়ার পর Mimikatz-এর lsadump::dcsync কমান্ড দিয়ে অ্যাটাকার krbtgt-এর Hash বের করে। এরপর kerberos::golden কমান্ডে SID, Domain Name, এবং Username নির্দিষ্ট করে Forged TGT তৈরি করে। এই TGT তখন মেমোরিতে ইনজেক্ট করা হয় kerberos::ptt দিয়ে, এবং অ্যাটাকার তৎক্ষণাৎ সর্বোচ্চ প্রিভিলেজে যেকোনো সিস্টেমে অ্যাক্সেস পেয়ে যায়।

Golden Ticket-এর বিপজ্জনকতা বেশ কয়েকটি কারণে অসাধারণ। প্রথমত, এটি Persistence-এর একটি অত্যন্ত স্থিতিশীল পদ্ধতি। সাধারণ Password Reset, Account Lockout, কিংবা MFA Enforcement-এর মাধ্যমে এই অ্যাক্সেস বন্ধ করা যায় না। শুধুমাত্র krbtgt-এর পাসওয়ার্ড দুবার রিসেট করলেই এই টিকেট অকার্যকর হয়।

দ্বিতীয়ত, এটি প্রায় অদৃশ্য। যেহেতু TGT KDC দ্বারা ইস্যু হয়নি, Event Log 4768 (TGT Request) তৈরি হয় না। শুধুমাত্র Service Ticket Request (Event ID 4769) লগ হয়, যা সাধারণত প্রতিদিন হাজার হাজার তৈরি হয় এবং সন্দেহজনক বলে চিহ্নিত করা কঠিন।

তৃতীয়ত, Golden Ticket Cross-Domain এবং Cross-Forest Trust-এও ব্যবহার করা যায় (Diamond Ticket এবং Sapphire Ticket-এর মতো ভেরিয়েন্টে)। অর্থাৎ একটি ডোমেইনের নিয়ন্ত্রণ থেকে পুরো Forest-এ ছড়িয়ে পড়া সম্ভব।

চতুর্থত, একবার তৈরি হলে এই টিকেট অফলাইনেও বৈধ। অ্যাটাকার ইন্টারনেট সংযোগ ছাড়াই বহু পরে এটি ব্যবহার করতে পারে, যতক্ষণ না টিকেটের নিজস্ব মেয়াদ শেষ হয়।

বাস্তব জগতে Golden Ticket Attack-এর ব্যবহার ব্যাপক। ২০১৪ সালে Sony Pictures Entertainment-এর বিরুদ্ধে চালানো বিখ্যাত আক্রমণে অ্যাটাকাররা AD-তে দীর্ঘ-মেয়াদী Persistence স্থাপন করেছিল, যেখানে Golden Ticket-এর মতো কৌশল ব্যবহৃত হয়েছে বলে গবেষকরা দাবি করেছেন।

NotPetya র‍্যানসমওয়্যার ২০১৭ সালে যে গতিতে বিশ্বব্যাপী ছড়িয়েছিল তার পেছনে ছিল Mimikatz-ভিত্তিক ক্রেডেনশিয়াল হার্ভেস্টিং এবং Active Directory অপব্যবহার। Maersk-এর মতো বহুজাতিক প্রতিষ্ঠানকে পুরো গ্লোবাল AD অবকাঠামো নতুন করে তৈরি করতে হয়েছিল কারণ তারা নিশ্চিত হতে পারছিল না যে অ্যাটাকার Golden Ticket ছাড়িয়ে গেছে কিনা।

SolarWinds Sunburst অপারেশনে Russian Threat Actor APT29 (Cozy Bear) Active Directory-তে গভীর Persistence স্থাপন করেছিল এবং SAML Token Forging-এর সাথে সাথে Kerberos-ভিত্তিক কৌশলও ব্যবহার করেছিল। তাদের Golden SAML আক্রমণ Golden Ticket-এর ক্লাউড সংস্করণ হিসেবে বিবেচিত হয়।

Ryuk, Conti, এবং LockBit-এর মতো র‍্যানসমওয়্যার গ্রুপগুলো নিয়মিত Domain Controller-এ পৌঁছানোর পর Golden Ticket তৈরি করে পুরো এন্টারপ্রাইজে দ্রুত ছড়িয়ে পড়ে। কোম্পানিগুলো প্রায়ই দেখে যে Backup Server, Hypervisor, এবং Cloud Sync-সহ সবকিছুতেই অ্যাটাকারের অ্যাক্সেস রয়েছে।

Golden Ticket Detection কঠিন হলেও অসম্ভব নয়। প্রথম সংকেত হতে পারে Anomalous Kerberos Activity—যেমন এমন কোনো ব্যবহারকারীর নামে TGS Request যা ডোমেইনে অস্তিত্বহীন। Event ID 4769-এর Pre-Authentication Type যাচাই করলে অনেক সময় অস্বাভাবিকতা ধরা পড়ে।

ডিফল্টের চেয়ে অনেক বেশি Lifetime (যেমন ১০ বছর) সহ টিকেট অত্যন্ত সন্দেহজনক। Microsoft Defender for Identity, CrowdStrike Falcon Identity Protection, এবং Vectra-এর মতো প্ল্যাটফর্ম এই ধরনের অস্বাভাবিকতা স্বয়ংক্রিয়ভাবে শনাক্ত করতে পারে।

DCSync Detection আরেকটি প্রবেশদ্বার। যদি কোনো কম্পিউটার বা ব্যবহারকারী Replication Permission ব্যবহার করে ডেটা টানতে চায়, এবং সেটি কোনো Domain Controller না, তবে এটি সন্দেহজনক। Event ID 4662 ("An operation was performed on an object") থেকে DRSR Object Access ট্র্যাক করা যায়।

User Behavior Analytics (UBA) এর মাধ্যমে অস্বাভাবিক লগইন প্যাটার্ন, যেমন ভোর রাতে Domain Admin অ্যাকাউন্ট দিয়ে দূরবর্তী লোকেশন থেকে লগইন, শনাক্ত করা যায়। Honey Account তৈরি করে রাখলে—যেগুলো কেউ কখনো ব্যবহার করে না—সেগুলোতে অ্যাক্সেস চেষ্টা মাত্রই অ্যালার্ট পাঠানো যায়।

Golden Ticket থেকে সুরক্ষার জন্য সবচেয়ে গুরুত্বপূর্ণ পদক্ষেপ হলো নিয়মিত krbtgt পাসওয়ার্ড রিসেট। Microsoft সুপারিশ করে কমপক্ষে বছরে দুবার krbtgt পাসওয়ার্ড পরিবর্তন করা—দুটি রিসেট মাঝখানে কয়েক ঘণ্টা ব্যবধানে। প্রথম রিসেট পুরাতন TGT-এর জন্য আংশিকভাবে কার্যকর রাখে; দ্বিতীয় রিসেট পুরোপুরি বাতিল করে। New-KrbtgtKeys.ps1 স্ক্রিপ্ট এই কাজে সহায়ক।

দ্বিতীয়ত, Tier 0 Asset Protection প্রয়োগ করতে হবে। Domain Controller, ADCS Server, Identity Federation Server—এদের কেবলমাত্র Privileged Access Workstation (PAW) থেকে অ্যাক্সেস করা উচিত। Tier 0 অ্যাকাউন্ট কখনো সাধারণ ওয়ার্কস্টেশনে লগইন করবে না, যাতে ক্রেডেনশিয়াল থেফ্ট প্রতিরোধ হয়।

তৃতীয়ত, Protected Users গ্রুপ এবং Authentication Policy Silos ব্যবহার করতে হবে। Protected Users গ্রুপের সদস্যদের TGT মাত্র ৪ ঘণ্টার জন্য বৈধ থাকে এবং তাদের ক্রেডেনশিয়াল ক্যাশে হয় না। এটি Pass-the-Hash এবং Golden Ticket উভয়ের বিরুদ্ধে কার্যকর।

চতুর্থত, LSASS Memory Protection অপরিহার্য। Credential Guard, Hypervisor-Based Security, এবং RunAsPPL সেটিং চালু করলে Mimikatz-এর মতো টুলের পক্ষে মেমোরি থেকে হ্যাশ চুরি করা অনেক কঠিন হয়ে যায়।

পঞ্চমত, Privilege Audit এবং Cleanup নিয়মিত করতে হবে। অপ্রয়োজনীয় Domain Admins, অব্যবহৃত Service Account, এবং Stale Privileged Group Membership অপসারণ করতে হবে। BloodHound-এর মতো টুল দিয়ে নিজেদের Attack Path ম্যাপ করে দেখলে কোথায় Privilege Escalation সম্ভব তা স্পষ্ট হয়।

ষষ্ঠত, Tiered Administration Model কঠোরভাবে প্রয়োগ করা উচিত। Domain Admin দিয়ে SQL Server বা Web Server ম্যানেজ করা উচিত নয়। আলাদা Server Admin এবং Workstation Admin অ্যাকাউন্ট ব্যবহার করতে হবে।

সপ্তমত, EDR ও SIEM মোতায়েন করতে হবে যেগুলো Kerberos Anomaly শনাক্ত করতে সক্ষম। Microsoft Defender for Identity বিশেষভাবে Golden Ticket-এর জন্য টিউনড অ্যালগরিদম প্রদান করে।

অষ্টমত, যদি Compromise সন্দেহ হয়, তবে Forest Recovery প্রক্রিয়া অনুসরণ করতে হবে। কিছু ক্ষেত্রে নতুন Active Directory Forest তৈরি করে Phased Migration করাই একমাত্র নিরাপদ সমাধান, কারণ Persistence এতটাই গভীর হতে পারে যে আংশিক Cleanup যথেষ্ট নয়।