Silver Ticket: উইন্ডোজ সার্ভারের নির্দিষ্ট সার্ভিসের অ্যাক্সেস নিতে ফেক টোকেন তৈরি করার সাইবার কৌশল!

Silver Ticket বুঝতে হলে আগে Kerberos-এর মৌলিক প্রবাহ বুঝতে হবে। সরলীকৃতভাবে—

1. ব্যবহারকারী Domain Controller-এর KDC (Key Distribution Center)-এর AS (Authentication Service)-এ প্রমাণীকরণ করেন এবং একটি TGT (Ticket Granting Ticket) পান।
2. কোনো সার্ভিস অ্যাক্সেস করতে হলে ব্যবহারকারী TGT উপস্থাপন করে TGS (Ticket Granting Service)-এর কাছ থেকে নির্দিষ্ট সার্ভিসের জন্য একটি Service Ticket (TGS Ticket) চান।
3. ব্যবহারকারী এই Service Ticket নিয়ে সরাসরি সার্ভিসের কাছে যান এবং অ্যাক্সেস পান।

প্রতিটি Service Ticket এমন একটি কী দিয়ে এনক্রিপ্ট করা থাকে যা শুধুমাত্র সংশ্লিষ্ট সার্ভিস অ্যাকাউন্ট জানে—সেই কী আসলে সার্ভিস অ্যাকাউন্টের পাসওয়ার্ড হ্যাশ (NTLM বা AES কী)। সার্ভিস টিকেট পেলে সেটি নিজের কী দিয়ে ডিক্রিপ্ট করে যাচাই করে, এবং PAC (Privilege Attribute Certificate)-এর তথ্যের ভিত্তিতে অ্যাক্সেস প্রদান করে।

এই ক্রিপ্টোগ্রাফিক যাচাই-ই Silver Ticket আক্রমণের মূল লক্ষ্য।

Silver Ticket হলো একটি ফোর্জড Service Ticket যা আক্রমণকারী ম্যানুয়ালি তৈরি করেন—সম্পূর্ণরূপে Domain Controller-এর সাথে যোগাযোগ ছাড়াই। এই টিকেট তৈরির জন্য আক্রমণকারীর প্রয়োজন—

• সংশ্লিষ্ট সার্ভিস অ্যাকাউন্টের NTLM বা AES কী
• সার্ভিসের SPN (Service Principal Name)
• ডোমেইন নাম এবং SID
• যে ব্যবহারকারীর পরিচয়ে অভিনয় করতে চান, তার তথ্য (নাম, RID)

এই তথ্যগুলো পেলে Mimikatz, Rubeus বা impacket-এর ticketer.py-এর মতো টুল দিয়ে একটি সম্পূর্ণ Service Ticket তৈরি করা যায় যা বৈধ দেখাবে এবং সংশ্লিষ্ট সার্ভিসে অ্যাক্সেস প্রদান করবে।

দুটি আক্রমণই Kerberos টিকেট ফোর্জ করে, কিন্তু গুরুত্বপূর্ণ পার্থক্য রয়েছে:

এই তুলনা থেকে স্পষ্ট, Silver Ticket আক্রমণকারীর জন্য একটি কম-গোলযোগের কিন্তু কার্যকর কৌশল।

১. Service Account Hash সংগ্রহ

প্রথম এবং সবচেয়ে গুরুত্বপূর্ণ ধাপ হলো সার্ভিস অ্যাকাউন্টের পাসওয়ার্ড হ্যাশ সংগ্রহ। এর জন্য সাধারণত নিম্নলিখিত পদ্ধতি ব্যবহৃত হয়:

Kerberoasting: সার্ভিস অ্যাকাউন্টের SPN টিকেট অনুরোধ করে তা অফলাইনে ক্র্যাক করা। দুর্বল পাসওয়ার্ডযুক্ত সার্ভিস অ্যাকাউন্ট এই কৌশলে সহজে কম্প্রোমাইজ হয়।

Local Admin Access: সংশ্লিষ্ট সার্ভার যেখানে সার্ভিস চলে, সেখানে লোকাল অ্যাডমিন অ্যাক্সেস থাকলে SAM, LSASS বা ক্যাশড ক্রেডেনশিয়াল থেকে হ্যাশ বের করা।

DCSync: যদি আক্রমণকারী Domain Controller থেকে রেপ্লিকেশন অধিকার পান, তবে DCSync ব্যবহার করে যেকোনো অ্যাকাউন্টের হ্যাশ সংগ্রহ।

Memory Extraction: চলমান সার্ভারের মেমোরি থেকে Mimikatz দিয়ে credential dump।

২. SPN ও Domain Information সংগ্রহ

PowerView, BloodHound, ldapsearch বা সরাসরি setspn কমান্ড দিয়ে—

• লক্ষ্যবস্তু সার্ভিসের SPN (যেমন MSSQLSvc/server01.contoso.local:1433)
• ডোমেইনের নাম এবং SID
• যে ব্যবহারকারীর পরিচয়ে অ্যাক্সেস নিতে চান তার RID

৩. Ticket Forging

সংগৃহীত তথ্য ব্যবহার করে Mimikatz-এ Silver Ticket তৈরি:

kerberos::golden /user:Administrator /domain:contoso.local /sid:S-1-5-21-xxxx /target:server01.contoso.local /service:cifs /rc4:<NTLM hash> /ptt

এখানে গুরুত্বপূর্ণ ফ্ল্যাগ:

• /service: কোন সার্ভিসের জন্য টিকেট (cifs, mssqlsvc, host, http, ldap, time)
• /target: সার্ভিসটি চলছে কোন সার্ভারে
• /rc4 বা /aes256: সার্ভিস অ্যাকাউন্টের হ্যাশ
• /ptt: pass-the-ticket—সরাসরি বর্তমান সেশনে ইনজেক্ট করে

৪. সার্ভিসে অ্যাক্সেস

টিকেট ইনজেক্ট হলে আক্রমণকারী এখন সেই সার্ভিসে নির্দিষ্ট ব্যবহারকারীর (এমনকি Domain Administrator-এর) পরিচয়ে অ্যাক্সেস নিতে পারেন। উদাহরণস্বরূপ, MS-SQL সার্ভিসে Domain Admin হিসেবে কোয়েরি চালানো বা CIFS-এর মাধ্যমে রিমোট ফাইল সিস্টেমে অ্যাক্সেস।

প্রতিটি সার্ভিস টাইপ ভিন্ন ভিন্ন অ্যাক্সেস স্কোপ প্রদান করে:

• cifs/server: সার্ভারের ফাইল শেয়ার অ্যাক্সেস (admin$, c$ ইত্যাদি)
• host/server: WMI, Scheduled Task, Service কন্ট্রোল
• rpcss/server: DCOM-এর মাধ্যমে remote execution
• mssqlsvc: SQL Server-এর সম্পূর্ণ নিয়ন্ত্রণ
• http/server: SharePoint বা IIS ওয়েব অ্যাপ্লিকেশন
• ldap/server: LDAP-ভিত্তিক ডিরেক্টরি অ্যাক্সেস

লক্ষণীয়, একই টিকেট একাধিক সার্ভিসে কাজ করে না; প্রতিটি সার্ভিসের জন্য পৃথক টিকেট প্রয়োজন।

Silver Ticket তৈরির সময় আক্রমণকারী PAC ফিল্ড ম্যানিপুলেট করেন—যেকোনো গ্রুপ মেম্বারশিপ (Domain Admins, Enterprise Admins) ফোর্জ করা যায়। সার্ভিসটি এই PAC বিশ্বাস করে অ্যাক্সেস প্রদান করবে।

তবে গুরুত্বপূর্ণ একটি বিবেচনা—PAC Validation। যদি লক্ষ্যবস্তু সার্ভিসে PAC Validation সক্রিয় থাকে (যা ডিফল্ট নয়), তবে সার্ভিস Domain Controller-এর কাছে PAC যাচাই করতে যাবে এবং Silver Ticket ব্যর্থ হবে। বাস্তবে অধিকাংশ Windows সার্ভিস PAC Validation নিষ্ক্রিয় রাখে কর্মক্ষমতার জন্য, ফলে আক্রমণ সফল হয়।

পরিস্থিতি ১: একজন Red Team অপারেটর Kerberoasting-এর মাধ্যমে MSSQL সার্ভিস অ্যাকাউন্টের পাসওয়ার্ড ক্র্যাক করলেন। এরপর Silver Ticket তৈরি করে নিজেকে sa privilege দিয়ে SQL সার্ভারে অ্যাক্সেস নিলেন এবং xp_cmdshell দিয়ে কোড এক্সিকিউশন পেলেন—Domain Controller-এর সাথে কোনো যোগাযোগ ছাড়াই।

পরিস্থিতি ২: একটি Persistence-এর পরিকল্পনায় আক্রমণকারী একটি গুরুত্বপূর্ণ ফাইল সার্ভারের কম্পিউটার অ্যাকাউন্ট হ্যাশ সংগ্রহ করলেন। এরপর যেকোনো সময় তারা cifs Silver Ticket তৈরি করে Domain Admin-এর পরিচয়ে সেই সার্ভারের admin$ শেয়ারে অ্যাক্সেস নিতে পারেন।

পরিস্থিতি ৩: একটি ব্যাংকিং পরিবেশে আক্রমণকারী একটি Web Application-এর IIS apppool অ্যাকাউন্টের হ্যাশ পেলেন। http Silver Ticket তৈরি করে তারা Web Application-এ Domain Admin-এর পরিচয়ে লগইন করলেন এবং সংবেদনশীল লেনদেন তথ্য অ্যাক্সেস করলেন।

Silver Ticket শনাক্তকরণ ঐতিহ্যবাহীভাবে কঠিন কারণ Domain Controller-এ কোনো অস্বাভাবিক ইভেন্ট জেনারেট হয় না। তবে কিছু পদ্ধতি কার্যকর:

Sysmon Event ID 11 ও 4624

লক্ষ্যবস্তু সার্ভারে অস্বাভাবিক authentication event বিশ্লেষণ। বিশেষ করে—

• Event ID 4624 (Successful Logon) যেখানে Logon Type 3 (Network) এবং Authentication Package Kerberos
• কিন্তু সংশ্লিষ্ট Domain Controller-এ কোনো 4769 (TGS Service Ticket Request) নেই

Suspicious Account Mismatch

PAC-এ থাকা ব্যবহারকারী এবং প্রকৃত অ্যাক্সেস প্যাটার্নে অমিল। যেমন—একজন সাধারণ কর্মচারী হঠাৎ একটি গুরুত্বপূর্ণ সার্ভারে Domain Admin অ্যাক্সেস নিচ্ছেন কিন্তু DC-তে কোনো গ্রুপ পরিবর্তনের রেকর্ড নেই।

Honeytokens

ভুয়া SPN এবং honey service account স্থাপন করা। কেউ যদি সেই SPN-এর জন্য টিকেট তৈরির চেষ্টা করেন, তবে অ্যালার্ট জেনারেট হবে।

Ticket Time Skew

Silver Ticket-এ সাধারণত ১০ বছর বা তার বেশি জীবনকাল সেট করা হয়। স্বাভাবিক Kerberos টিকেট ১০ ঘণ্টার বেশি স্থায়ী হয় না। অস্বাভাবিক টিকেট জীবনকাল একটি শক্তিশালী সংকেত।

Unconstrained Group Membership

যদি Event Log-এ দেখা যায় একজন ব্যবহারকারী এমন গ্রুপে আছেন (যেমন Enterprise Admins) যা প্রকৃতপক্ষে Domain Controller-এ তার অ্যাকাউন্টে নেই, তবে এটি ফোর্জড PAC-এর চিহ্ন।

১. Service Account Hardening

• দীর্ঘ (৩০+ অক্ষর), জটিল এবং র্যান্ডম পাসওয়ার্ড
• Managed Service Account (MSA) এবং gMSA (Group Managed Service Account) ব্যবহার যেখানে পাসওয়ার্ড স্বয়ংক্রিয়ভাবে পরিবর্তিত হয়
• নিয়মিত (অন্তত প্রতি ৬ মাসে) সার্ভিস অ্যাকাউন্ট পাসওয়ার্ড পরিবর্তন
• AES কী জেনারেশন সক্ষম করা এবং RC4 নিষ্ক্রিয় করা

২. PAC Validation সক্রিয়করণ

সংবেদনশীল সার্ভিসগুলোতে PAC Validation সক্রিয় করে DC-এর সাথে যাচাই বাধ্যতামূলক করা।

৩. Kerberos Encryption Type Enforcement

Group Policy-তে শুধুমাত্র AES256 এনক্রিপশন অনুমোদন করা; RC4-HMAC সম্পূর্ণভাবে নিষ্ক্রিয়। RC4 কী ক্র্যাক করা AES-এর চেয়ে অনেক সহজ।

৪. Tier 0 Service Account Protection

Domain Controller এবং অন্যান্য Tier 0 সম্পদের সার্ভিস অ্যাকাউন্টগুলোকে Protected Users গ্রুপে রাখা এবং কোনোভাবেই কম-নিরাপদ সার্ভারে চালু না করা।

৫. Kerberoasting Detection

SPN টিকেট অনুরোধের অস্বাভাবিক প্যাটার্ন (Event ID 4769) মনিটর করা—একজন ব্যবহারকারী যদি একই সময়ে অনেক ভিন্ন SPN-এর টিকেট চান, এটি Kerberoasting-এর শক্তিশালী চিহ্ন।

৬. Microsoft Defender for Identity

MDI এর মতো ITDR সলিউশন Silver Ticket সহ অন্যান্য Kerberos আক্রমণ behavioral analysis-এর মাধ্যমে শনাক্ত করতে পারে।

৭. Authentication Policies and Silos

Authentication Policy Silo ব্যবহার করে সার্ভিস অ্যাকাউন্ট কোথা থেকে এবং কীভাবে authentication করতে পারে তা সীমিত করা।

৮. Honey SPN Deployment

সাজানো honey SPN স্থাপন এবং সেগুলোর জন্য যেকোনো টিকেট অনুরোধ instantly অ্যালার্ট জেনারেট।