AS-REP Roasting: পাসওয়ার্ড ছাড়াই Kerberos অ্যাকাউন্টের অ্যাক্সেস নেওয়ার হ্যাকিং কৌশল!

AS-REP Roasting বুঝতে গেলে প্রথমে Kerberos authentication flow-এর basic বুঝতে হবে। Kerberos একটি ticket-based authentication protocol যা Microsoft Active Directory-এর default authentication mechanism। এতে তিনটি প্রধান party থাকে: Client, Key Distribution Center (KDC, যা Domain Controller-এ চলে), এবং Service Server।

Kerberos-এ প্রথম step হলো Authentication Service (AS) Request। যখন একজন user প্রথম login করেন, তাদের machine KDC-তে AS-REQ পাঠায়, এবং KDC থেকে একটি Ticket Granting Ticket (TGT) পায়। এই TGT পরে Ticket Granting Service (TGS)-এ ব্যবহার করে specific service-এর জন্য Service Ticket নেওয়া হয়।

স্বাভাবিক AS-REQ-এ থাকে "pre-authentication data" বা PA-DATA—এটি একটি timestamp যা user-এর password hash দিয়ে encrypted। KDC এই encrypted timestamp decrypt করার চেষ্টা করে; যদি সফল হয়, এর মানে user-এর কাছে সঠিক password আছে। এই pre-authentication ছিল Kerberos v5-এ যোগ করা একটি গুরুত্বপূর্ণ security feature, কারণ এটি ছাড়া যেকোনো ব্যক্তি যেকোনো username-এর জন্য AS-REQ পাঠিয়ে encrypted material পেতে পারতেন।

কিছু account-এর জন্য Kerberos pre-authentication disabled থাকে। AD-তে এটি UserAccountControl flag-এ DONT_REQ_PREAUTH (0x400000) দ্বারা চিহ্নিত। এই configuration-এ KDC pre-authentication check ছাড়াই AS-REP পাঠিয়ে দেয়।

AS-REP response-এ থাকে user-এর encrypted session key, যা user-এর password hash দিয়ে encrypted। এই encrypted material attacker offline-এ password cracking tool যেমন Hashcat বা John the Ripper দিয়ে crack করতে পারেন। যদি password weak হয়, কয়েক ঘণ্টা বা দিনের মধ্যেই plaintext password recover করা সম্ভব।

আক্রমণের জন্য আক্রমণকারীর কোনো valid credential প্রয়োজন নেই—শুধু domain-এ network connectivity এবং কিছু username knowledge দরকার। এমনকি একটি unauthenticated guest network থেকেও এই attack চালানো সম্ভব যদি domain controller reachable হয়।

বাস্তবে AS-REP Roasting কয়েক ধাপে সম্পন্ন হয়। প্রথমে username discovery—target domain-এর valid username list তৈরি করা। এর জন্য কয়েকটি technique আছে: LDAP enumeration (যদি anonymous bind allowed হয়), Kerberos username enumeration (KRB5-এর error response-এর মাধ্যমে valid/invalid username distinguish করা), open-source intelligence (LinkedIn, company website থেকে নাম collect করে username format generate করা)।

দ্বিতীয় ধাপে actual roasting। Rubeus হলো C# দিয়ে লেখা সবচেয়ে জনপ্রিয় tool এই কাজের জন্য। Command syntax:

Rubeus.exe asreproast /format:hashcat /outfile:hashes.txt

এটি current domain-এ pre-auth disabled সব account খুঁজে এবং তাদের AS-REP hash extract করে। Format:hashcat ব্যবহার করলে output সরাসরি Hashcat-এ ব্যবহারযোগ্য।

Impacket-এর GetNPUsers.py Linux/Mac থেকে চালানোর জন্য:

GetNPUsers.py domain.local/ -usersfile users.txt -format hashcat -outputfile hashes.txt

-no-pass flag-এর সঙ্গে এটি anonymous-ই চালানো যায়—কোনো credential ছাড়া।

তৃতীয় ধাপে cracking। Hashcat-এ Kerberos 5 AS-REP etype 23 (RC4-HMAC)-এর জন্য hash mode 18200:

hashcat -m 18200 hashes.txt rockyou.txt -O

RC4-HMAC encryption-এর কারণে cracking relatively fast। Modern GPU-তে billion-এর বেশি hash per second test করা সম্ভব।

প্রশ্ন আসতে পারে—কেন কোনো organization-এ pre-authentication disable করা থাকবে? কয়েকটি কারণ আছে।

প্রথমত, legacy application compatibility। কিছু পুরনো application Kerberos pre-authentication সঠিকভাবে handle করতে পারে না, বিশেষ করে যারা DES বা older encryption ব্যবহার করে। এই application-এর জন্য নির্দিষ্ট account-এ pre-auth disable করা হত।

দ্বিতীয়ত, service account misconfiguration। কখনো administrator service account তৈরির সময় ভুলে এই flag set করে দেন, না বুঝে এর security implication।

তৃতীয়ত, third-party integration। কিছু non-Microsoft Kerberos client বা Unix-based system Microsoft-এর pre-auth implementation-এর সঙ্গে compatibility issue থাকতে পারে। সমস্যা solve করতে quick fix হিসেবে pre-auth disable করা হয়।

চতুর্থত, accidental policy। GPO বা administrative template-এ ভুল configuration-এর কারণে large-scale-এ pre-auth disable হয়ে যেতে পারে।

প্রতিটি ক্ষেত্রেই—কারণ যাই হোক—এই configuration একটি security risk এবং remediate করা উচিত।

বিভিন্ন red team engagement-এ AS-REP Roasting অত্যন্ত effective প্রমাণিত হয়েছে। SpecterOps, TrustedSec, এবং অন্যান্য offensive security firm-এর published case study-তে এই technique বারবার দেখা যায়।

একটি typical scenario: একটি penetration tester একটি domain-এ unauthenticated access পেয়েছেন (হয়তো একটি conference room-এ Ethernet jack-এ plug in করে)। প্রথমে nmap বা responder দিয়ে domain controller discover করেন। তারপর LDAP enumeration বা SMB null session দিয়ে username list তৈরি করেন। GetNPUsers.py দিয়ে AS-REP roastable account identify করেন। ১০-২০টি account থেকে hash পান, তার মধ্যে ২-৩টা weak password-এ crack হয়। এই credential দিয়ে initial foothold পেয়ে আরও sophisticated attack চালান।

Real-world incident-এ Maersk shipping company-এর ২০১৭ NotPetya outbreak-এর pre-incident reconnaissance-এ এই ধরনের technique ব্যবহার হয়েছে বলে রিপোর্ট আছে। আরও সাম্প্রতিক APT campaign-এ এই attack initial credential gathering phase-এ ব্যবহৃত হয়েছে।

AS-REP Roasting-এর সঙ্গে প্রায়ই Kerberoasting-এর মিল আছে বলে confusion হয়। দুটোই Kerberos-related offline cracking attack, কিন্তু target এবং method ভিন্ন।

Kerberoasting target করে user account যাদের Service Principal Name (SPN) registered আছে—সাধারণত service account। এতে valid domain credential প্রয়োজন। Attacker একটি valid TGT-এর সঙ্গে TGS-REQ পাঠান specific SPN-এর জন্য, এবং KDC একটি TGS ticket return করে যা service account-এর password hash দিয়ে encrypted।

AS-REP Roasting target করে pre-authentication disabled account, কোনো credential প্রয়োজন নেই। AS-REQ পাঠিয়ে AS-REP-এ encrypted material পাওয়া যায়।

Hashcat-এর জন্য hash mode-ও আলাদা: AS-REP-এর জন্য 18200, Kerberoast-এর জন্য 13100।

দুটি attack-ই complementary—একটি well-prepared red team উভয়ই করবেন প্রতিটি engagement-এ।

AS-REP Roasting থেকে রক্ষা পেতে কয়েকটি specific step নিতে হয়। প্রথমত এবং সবচেয়ে গুরুত্বপূর্ণ, pre-authentication disabled account audit করা। PowerShell দিয়ে এই query চালানো যায়:

Get-ADUser -Filter {DoesNotRequirePreAuth -eq $true} -Properties DoesNotRequirePreAuth

প্রতিটি identified account review করে দেখুন—সত্যিই প্রয়োজন কিনা। যদি না হয়, immediately pre-auth enable করুন।

দ্বিতীয়ত, যদি কোনো account-এ pre-auth disable রাখতেই হয়, তবে তার password অত্যন্ত শক্তিশালী এবং long (২৫+ characters, random) হতে হবে। Password rotation policy strict করুন।

তৃতীয়ত, AES encryption ব্যবহার করুন RC4-এর পরিবর্তে। AES-256 অনেক slower to crack RC4-এর তুলনায়। GPO-তে "Network security: Configure encryption types allowed for Kerberos" setting-এ শুধু AES allow করুন।

চতুর্থত, monitoring এবং alerting। Windows Event Log-এ Event ID 4768 (Kerberos AS Ticket requested) monitor করুন। যদি একই source থেকে multiple accounts-এর জন্য pre-auth ছাড়া request আসে, এটি একটি strong indicator। SIEM-এ এই pattern-এর জন্য correlation rule তৈরি করুন।

SIEM (Splunk, ELK, Sentinel)-এ AS-REP Roasting detect করার জন্য কিছু specific detection rule design করা যায়। Microsoft Sentinel-এর জন্য example KQL query:

SecurityEvent
| where EventID == 4768
| where TicketEncryptionType == "0x17"  // RC4
| where TicketOptions contains "0x40810010"  // Pre-auth not required
| summarize count() by Account, SourceIP, bin(TimeGenerated, 5m)
| where count_ > 5

এই query specifically RC4-encrypted AS ticket request-এ pre-auth ছাড়া trigger হয়, যা typical attack pattern।

Sysmon-এর সঙ্গে honeypot account-ও কার্যকর। একটি account তৈরি করুন pre-auth disabled, কিন্তু কোনো legitimate use নেই। যদি কখনো এই account-এর জন্য AS-REQ আসে, এটি certain malicious activity।

Domain Controller-এ Account Logon audit policy-তে success এবং failure দুটোই enabled থাকতে হবে। এটি comprehensive monitoring-এর foundation।

Realistic attack scenario-তে AS-REP Roasting সাধারণত একটি broader kill chain-এর অংশ। MITRE ATT&CK-এ এটি T1558.004 (Steal or Forge Kerberos Tickets: AS-REP Roasting) হিসেবে catalogued।

Typical sequence: Initial Access (T1078 - Valid Accounts বা T1190 - Exploit Public-Facing Application) → Discovery (T1087 - Account Discovery) → Credential Access (T1558.004 - AS-REP Roasting) → Lateral Movement (T1021 - Remote Services) → Privilege Escalation (T1078.002 - Domain Accounts) → Impact।

এই context-এ AS-REP Roasting-এর effectiveness নির্ভর করে কয়েকটি factor-এ: কতগুলো account roastable, তাদের password strength, এবং compromised account-এর privilege। একটি domain admin account যদি pre-auth disabled থাকে এবং weak password থাকে, পুরো domain compromise কয়েক ঘণ্টায় সম্ভব।