LSA Protection: উইন্ডোজের ক্রেডেনশিয়াল চুরি রোধে লোকাল সিকিউরিটি অথরিটি সুরক্ষা!

Local Security Authority Subsystem Service বা LSASS হলো Windows অপারেটিং সিস্টেমের একটি Core Process, যা lsass.exe নামে চলে। এর কাজ হলো User Authentication পরিচালনা করা, Security Policy প্রয়োগ করা, এবং Audit Log তৈরি করা। যখন একজন ব্যবহারকারী Windows-এ Log In করেন, তখন তাদের Credential LSASS-এর মেমোরিতে সংরক্ষিত হয় যাতে পরবর্তী Single Sign-On বা SSO কার্যক্রম সম্পন্ন করা যায়।

এই মেমোরিতে NTLM Hash, Kerberos TGT (Ticket Granting Ticket), DPAPI Master Key, এবং কখনও কখনও Plaintext Password পর্যন্ত থাকতে পারে। Mimikatz, ProcDump এবং Cobalt Strike-এর মতো Tools এই মেমোরি Dump করে এসব Credential বের করতে পারে। এই কারণেই LSASS প্রক্রিয়াটি Red Teamer এবং APT গ্রুপগুলোর প্রিয় লক্ষ্য।

LSA Protection-এর মূল ধারণা হলো LSASS-কে একটি Protected Process Light বা PPL হিসেবে চালানো। এই অবস্থায় শুধুমাত্র Microsoft-Signed কোড এবং বিশেষভাবে অনুমোদিত প্রক্রিয়া LSASS-এর সাথে Interact করতে পারে। Unsigned Driver বা Untrusted Process LSASS-এর মেমোরি Read করতে বা Code Inject করতে পারে না।

Windows Vista থেকে Microsoft Protected Process নামে একটি ফিচার চালু করেছিল মূলত DRM সুরক্ষার জন্য। Windows 8.1-এ এটি সম্প্রসারিত হয়ে Protected Process Light বা PPL-এ পরিণত হয়, যা Anti-Malware এবং Authentication Process-এর জন্য ব্যবহার করা যায়। PPL একটি Hierarchical Trust Model অনুসরণ করে, যেখানে প্রতিটি Protected Process-এর একটি Signer Level এবং একটি Protection Level থাকে।

Signer Level-এর মধ্যে রয়েছে WinSystem, WinTcb, Windows, Antimalware, LSA, এবং অন্যান্য। প্রতিটি Level-এর নির্দিষ্ট Trust Hierarchy আছে - উচ্চতর Level-এর Process নিম্নতর Level-এর Process-কে Access করতে পারে, কিন্তু উল্টোটা সম্ভব নয়। যখন LSASS PPL হিসেবে চলে, তখন এটি LSA Signer Level-এ থাকে, যার মানে শুধুমাত্র Microsoft দ্বারা Sign করা এবং LSA-Compatible Driver বা Process-ই এটিকে Access করতে পারে।

এই সুরক্ষা Kernel Level-এ প্রয়োগ করা হয়। Windows Kernel যখনই কোনো Process LSASS-এ Handle খোলার চেষ্টা করে, তখন এটি Signer Level যাচাই করে। যদি যাচাই ব্যর্থ হয়, তাহলে Access Denied Error দেয়। এমনকি Local Administrator-ও সরাসরি Protected LSASS-এ Inject করতে পারে না, যা একটি বড় নিরাপত্তা উন্নতি।

LSA Protection সক্রিয় করার জন্য Windows Registry-তে একটি নির্দিষ্ট মান সেট করতে হয়। Path হলো HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa এবং Value-এর নাম হলো RunAsPPL। এর মান DWORD হিসেবে 1 সেট করলে LSA Protection সক্রিয় হয় এবং পরবর্তী Reboot-এর পর কার্যকর হয়।

Windows 11 22H2 এবং পরবর্তী সংস্করণে LSA Protection by Default সক্রিয় থাকে নতুন Installation-এর ক্ষেত্রে। তবে Enterprise Environment-এ Group Policy ব্যবহার করে এটি Centrally Deploy করা যায়। Group Policy Object বা GPO-এর মধ্যে Computer Configuration > Administrative Templates > System > Local Security Authority পথে গিয়ে "Configure LSASS to run as a protected process" সেটিংটি Enable করতে হয়।

সক্রিয় করার আগে Compatibility পরীক্ষা করা অত্যন্ত গুরুত্বপূর্ণ। কিছু Legacy Smart Card Reader Driver, Third-Party Authentication Provider, এবং Custom Security Support Provider বা SSP LSA Protection-এর সাথে কাজ নাও করতে পারে। Microsoft একটি Audit Mode সরবরাহ করে যা Production-এ Enable করার আগে সমস্যা শনাক্ত করতে সাহায্য করে।

LSA Protection প্রাথমিকভাবে Credential Dumping Attack-এর বিরুদ্ধে কার্যকর। Mimikatz-এর sekurlsa::logonpasswords কমান্ড, যা Standard LSASS থেকে সহজেই Credential বের করতে পারে, Protected LSASS-এর সামনে ব্যর্থ হয়। আক্রমণকারী হয়তো Administrator Privilege-ও পেয়েছে, কিন্তু LSASS-এ Handle খুলতে পারবে না।

ProcDump এবং Task Manager-এর মাধ্যমে Memory Dump করার চেষ্টাও Block হয়। এটি Cobalt Strike এবং Metasploit-এর Mimikatz Module-কেও অকার্যকর করে দেয়। তবে এটি মনে রাখা গুরুত্বপূর্ণ যে LSA Protection একটি Defense-in-Depth Layer, এটি Silver Bullet নয়। এটি আক্রমণকারীর কাজ কঠিন করে, কিন্তু সম্পূর্ণ অসম্ভব করে না।

বাস্তব দৃষ্টিকোণ থেকে দেখলে, একটি Compromised Workstation-এ যদি LSA Protection সক্রিয় থাকে, তাহলে Attacker-কে Lateral Movement-এর জন্য বিকল্প পদ্ধতি খুঁজতে হবে। তারা হয়তো Kerberoasting, AS-REP Roasting, বা DCSync-এর মতো Attack-এ ঝুঁকবে, যা Domain Controller থেকে সরাসরি তথ্য সংগ্রহ করে। তাই LSA Protection-এর পাশাপাশি Credential Guard এবং Privileged Access Management বা PAM মোতায়েন করা প্রয়োজন।

যদিও LSA Protection একটি শক্তিশালী সুরক্ষা স্তর, নিরাপত্তা গবেষকরা একাধিক Bypass পদ্ধতি প্রকাশ করেছেন। সবচেয়ে বিখ্যাত Bypass হলো Mimikatz-এর mimidrv.sys নামক একটি Signed Driver ব্যবহার করা, যা Kernel Mode-এ চলে এবং PPL সুরক্ষা Override করতে পারে। তবে এর জন্য Local Administrator Privilege এবং Driver Loading ক্ষমতা প্রয়োজন।

আরেকটি জনপ্রিয় কৌশল হলো PPLDump এবং PPLBlade-এর মতো Tools, যা Vulnerable Signed Driver বা Bring Your Own Vulnerable Driver বা BYOVD পদ্ধতি ব্যবহার করে। আক্রমণকারী একটি পুরানো কিন্তু Microsoft-Signed Driver Load করে, যার মধ্যে পরিচিত Vulnerability আছে, এবং সেই Vulnerability Exploit করে Kernel-এ Arbitrary Code চালায়।

উদাহরণস্বরূপ, RTCore64.sys, dbutil_2_3.sys, এবং ProcExp152.sys-এর মতো Driver-গুলো অতীতে BYOVD আক্রমণে ব্যবহৃত হয়েছে। Microsoft এদের বিরুদ্ধে Vulnerable Driver Blocklist প্রকাশ করেছে, যা Windows 11 এবং Windows Defender-এ Default-এ Enabled থাকে। তবে নতুন Vulnerable Driver খুঁজে বের করা একটি চলমান প্রক্রিয়া।

আরও একটি গবেষণা ক্ষেত্র হলো Userland Bypass, যেখানে Attacker LSASS-এর সাথে সরাসরি Interact না করে Authentication Flow-কে Hijack করার চেষ্টা করে। যেমন SSP DLL Hijacking, যেখানে একটি Malicious SSP Register করে Credential Capture করা হয়। এ ক্ষেত্রে LSA Protection-এর পাশাপাশি AppLocker এবং Windows Defender Application Control বা WDAC-ও প্রয়োজন।

অনেকেই LSA Protection এবং Windows Defender Credential Guard-কে গুলিয়ে ফেলেন, কিন্তু এদের কার্যকারিতা ভিন্ন। LSA Protection LSASS-কে PPL হিসেবে চালায়, কিন্তু এটি একই Operating System-এর মধ্যেই চলে। অন্যদিকে Credential Guard Virtualization-Based Security বা VBS ব্যবহার করে LSASS-এর সংবেদনশীল অংশকে একটি Isolated Virtual Machine-এ স্থানান্তরিত করে।

Credential Guard সক্রিয় থাকলে NTLM Hash এবং Kerberos TGT একটি Isolated LSA Process বা LSAIso-তে থাকে, যা Hypervisor-এর সুরক্ষায় থাকে। মূল Operating System Compromised হলেও Attacker সেই Credential-এ Access পায় না। তবে Credential Guard-এর কিছু সীমাবদ্ধতা রয়েছে - এটি Hardware Support প্রয়োজন (TPM, UEFI Secure Boot, Hyper-V) এবং কিছু Legacy Application-এর সাথে Compatible নয়।

আদর্শ Enterprise Configuration হলো LSA Protection এবং Credential Guard উভয়ই একসাথে Deploy করা। LSA Protection LSASS Process-কে সাধারণ Code Injection থেকে রক্ষা করে, আর Credential Guard সবচেয়ে সংবেদনশীল Secret-গুলোকে Hardware-Level Isolation দেয়। এই Multi-Layer Defense আধুনিক Credential Theft Attack-এর বিরুদ্ধে শক্তিশালী সুরক্ষা প্রদান করে।

LSA Protection সক্রিয় থাকলেও Continuous Monitoring গুরুত্বপূর্ণ। Windows Event Log-এ Event ID 3033 এবং 3063 মনিটর করা উচিত, যা LSA-এর সাথে Unsigned বা Untrusted Code-এর Interaction-এর প্রচেষ্টা নির্দেশ করে। এই Event-গুলো একটি SIEM Platform-এ Forward করা উচিত যাতে রিয়েল-টাইম Alert তৈরি করা যায়।

Sysmon-এর Process Access Event বা Event ID 10-ও LSASS-এর সাথে সন্দেহজনক Access Pattern শনাক্ত করতে সাহায্য করে। যদি কোনো Unusual Process LSASS-এ Handle খোলার চেষ্টা করে এবং বিশেষত যদি GrantedAccess মান 0x1010 বা 0x1410 হয়, তাহলে এটি Mimikatz-এর মতো Activity-এর Indicator হতে পারে।

EDR বা Endpoint Detection and Response সমাধান যেমন Microsoft Defender for Endpoint, CrowdStrike Falcon, এবং SentinelOne LSASS-এর সাথে অস্বাভাবিক Interaction স্বয়ংক্রিয়ভাবে শনাক্ত করতে পারে। এগুলো Behavioral Analysis ব্যবহার করে, যা Signature-Based Detection-এর চেয়ে অনেক বেশি কার্যকর।

কর্পোরেট পরিবেশে LSA Protection কার্যকরভাবে Deploy করতে কয়েকটি Best Practice অনুসরণ করা উচিত। প্রথমত, Pilot Group-এ Audit Mode-এ Test করা প্রয়োজন, যাতে Compatibility সমস্যা আগেই শনাক্ত হয়। দ্বিতীয়ত, Group Policy-এর মাধ্যমে Phased Rollout পরিকল্পনা করা উচিত - প্রথমে Workstation, তারপর Server, এবং সবশেষে Domain Controller।

Microsoft Vulnerable Driver Blocklist Update করা এবং WDAC Policy Apply করা একটি গুরুত্বপূর্ণ পদক্ষেপ। এটি BYOVD আক্রমণের ঝুঁকি উল্লেখযোগ্যভাবে কমায়। পাশাপাশি Local Administrator Privilege Strictly সীমিত করা, Just-in-Time Administration ব্যবহার করা, এবং Tier 0 Asset যেমন Domain Controller-এ আলাদা Hardened Workstation থেকে Access করা উচিত।

Multi-Factor Authentication বা MFA এবং Smart Card-Based Authentication প্রয়োগ করা হলে এমনকি Credential চুরি হলেও Attacker সেগুলো ব্যবহার করতে পারবে না। Passwordless Authentication যেমন Windows Hello for Business এবং FIDO2 Key এই দিকে একটি বড় অগ্রগতি।

নিয়মিত Penetration Testing এবং Purple Team Exercise পরিচালনা করা উচিত যাতে LSA Protection এবং অন্যান্য নিরাপত্তা নিয়ন্ত্রণের কার্যকারিতা যাচাই করা যায়। Atomic Red Team-এর মতো Open Source Framework ব্যবহার করে নিয়ন্ত্রিত পরিবেশে Credential Dumping সিমুলেট করা সম্ভব।