Shadow Credentials: Active Directory-তে মূল পাসওয়ার্ড পরিবর্তন না করেই ব্যাকডোর তৈরি!

Shadow Credentials আক্রমণ বোঝার জন্য প্রথমে PKINIT (Public Key Cryptography for Initial Authentication) সম্পর্কে জানা প্রয়োজন। PKINIT হলো Kerberos প্রোটোকলের একটি এক্সটেনশন যা পাবলিক কী ক্রিপ্টোগ্রাফি ব্যবহার করে প্রাথমিক প্রমাণীকরণ সম্ভব করে। অর্থাৎ পাসওয়ার্ড না জেনেও কেউ Kerberos TGT (Ticket Granting Ticket) পেতে পারে যদি তার কাছে সংশ্লিষ্ট প্রাইভেট কী এবং Active Directory-তে সংরক্ষিত পাবলিক কী থাকে।

Windows Hello for Business (WHfB) এই প্রযুক্তি ব্যবহার করেই কাজ করে। যখন একজন ব্যবহারকারী WHfB সেটআপ করেন, তখন তার ডিভাইসে একটি কী জোড়া তৈরি হয় এবং পাবলিক কী Active Directory-তে ব্যবহারকারীর অবজেক্টের msDS-KeyCredentialLink অ্যাট্রিবিউটে সংরক্ষিত হয়। পরবর্তীতে ব্যবহারকারী যখন বায়োমেট্রিক বা PIN দিয়ে লগইন করেন, তখন ডিভাইস সেই প্রাইভেট কী ব্যবহার করে PKINIT-এর মাধ্যমে Kerberos টিকিট অর্জন করে।

msDS-KeyCredentialLink অ্যাট্রিবিউটটি Multi-valued, অর্থাৎ একটি অবজেক্টে একাধিক পাবলিক কী যুক্ত থাকতে পারে—যেমন একজন ব্যবহারকারীর একাধিক ডিভাইস থাকতে পারে। এই বৈশিষ্ট্যটিই আক্রমণকারীরা অপব্যবহার করেন।

আক্রমণের ধারণাটি সরল কিন্তু চতুর: আক্রমণকারী যদি কোনো ব্যবহারকারী বা কম্পিউটার অবজেক্টের msDS-KeyCredentialLink অ্যাট্রিবিউট লিখতে পারেন, তবে তারা সেখানে নিজের নিয়ন্ত্রণাধীন একটি পাবলিক কী যুক্ত করতে পারেন। এরপর সেই কী জোড়ার প্রাইভেট কী ব্যবহার করে PKINIT-এর মাধ্যমে যেকোনো সময় সেই অ্যাকাউন্টের জন্য বৈধ Kerberos TGT অর্জন করতে পারেন—এবং এর জন্য পাসওয়ার্ড জানার বা পরিবর্তন করার কোনো প্রয়োজন নেই।

এই আক্রমণ সফল হওয়ার জন্য প্রয়োজন—

1. লক্ষ্যবস্তু অবজেক্টের উপর GenericWrite, GenericAll, WriteProperty, অথবা WriteDacl অনুমতি
2. Domain Controller-এর Windows Server 2016 বা পরবর্তী সংস্করণে চলা
3. Domain Functional Level Windows Server 2016 বা উপরে
4. PKINIT সমর্থিত পরিবেশ (Enterprise CA বা Read-Only DC-তে যথাযথ কনফিগারেশন)

১. Reconnaissance এবং Privilege Discovery

প্রথম ধাপে আক্রমণকারী BloodHound, ADRecon বা PowerView-এর মতো টুল ব্যবহার করে চিহ্নিত করেন কোন অ্যাকাউন্টে কোন অবজেক্টের উপর GenericWrite বা সমতুল্য অনুমতি রয়েছে। বিশেষ করে নিম্নলিখিত পাথগুলো গুরুত্বপূর্ণ:

• Standard user → High-value user (Domain Admin, Enterprise Admin)
• Standard user → Computer object (যেমন Domain Controller)
• Service Account → Server অবজেক্ট

BloodHound-এ "Shadow Credentials" এজ স্পষ্টভাবে দৃশ্যমান হয় এবং সুনির্দিষ্ট অ্যাটাক পাথ চিহ্নিত করা যায়।

২. Key Pair Generation এবং Certificate Construction

পরবর্তী ধাপে আক্রমণকারী একটি RSA কী জোড়া তৈরি করেন এবং একটি স্ব-স্বাক্ষরিত X.509 সার্টিফিকেট নির্মাণ করেন। এই কাজের জন্য সবচেয়ে জনপ্রিয় টুল হলো Whisker (C#) এবং pyWhisker (Python)। উদাহরণস্বরূপ, Whisker-এর একটি সাধারণ কমান্ড:

Whisker.exe add /target:targetuser /domain:contoso.local /dc:dc01.contoso.local

এই কমান্ড টার্গেট ব্যবহারকারীর msDS-KeyCredentialLink অ্যাট্রিবিউটে নতুন পাবলিক কী যুক্ত করে এবং সংশ্লিষ্ট প্রাইভেট কী লোকাল ফাইল হিসেবে সংরক্ষণ করে।

৩. PKINIT-এর মাধ্যমে TGT অর্জন

কী যুক্ত করার পর আক্রমণকারী Rubeus বা gettgtpkinit.py (PKINITtools থেকে) ব্যবহার করে PKINIT-এর মাধ্যমে TGT অনুরোধ করেন:

Rubeus.exe asktgt /user:targetuser /certificate:cert.pfx /password:pfxpassword /domain:contoso.local

ফলস্বরূপ একটি বৈধ Kerberos TGT প্রাপ্ত হয় যা ব্যবহার করে আক্রমণকারী লক্ষ্যবস্তু অ্যাকাউন্টের পরিচয়ে নেটওয়ার্কের যেকোনো রিসোর্সে অ্যাক্সেস নিতে পারেন।

৪. NT Hash Extraction (UnPAC-the-Hash)

PKINIT-এর একটি বিশেষ ফিচার হলো TGT-এর Privilege Attribute Certificate (PAC)-এর মধ্যে ব্যবহারকারীর NT Hash অন্তর্ভুক্ত থাকে (যাকে PAC_CREDENTIAL_INFO বলা হয়)। getnthash.py টুল ব্যবহার করে আক্রমণকারী এই NT Hash বের করতে পারেন। ফলে এখন তাদের কাছে কেবল PKINIT অ্যাক্সেসই নয়, বরং প্রকৃত NT Hash-ও রয়েছে যা Pass-the-Hash আক্রমণে ব্যবহার করা যায়।

Shadow Credentials-এর সবচেয়ে গুরুত্বপূর্ণ ব্যবহার হলো Persistence বজায় রাখা। ঐতিহ্যবাহী Persistence কৌশলগুলো যেমন—

• AdminSDHolder পরিবর্তন
• DCSync অধিকার প্রদান
• Golden Ticket
• DSRM অ্যাকাউন্ট পুনর্ব্যবহার

—এগুলো সাধারণত SOC-এর Detection Rule-এ ধরা পড়ে। কিন্তু Shadow Credentials কৌশল একটি বৈধ অ্যাট্রিবিউট পরিবর্তন করে যা Windows Hello for Business সেটআপের সাথে সমার্থক। যদি প্রতিষ্ঠান WHfB ব্যবহার করে, তবে এই অ্যাট্রিবিউট পরিবর্তন স্বাভাবিক ট্রাফিকের মধ্যে মিশে যায়।

এমনকি আক্রমণকারী যদি Domain Admin অ্যাক্সেস হারিয়ে ফেলেন এবং সমস্ত অ্যাডমিন পাসওয়ার্ড রিসেট হয়, তবুও তারা পূর্বে যুক্ত করা Shadow Credentials দিয়ে যেকোনো অ্যাকাউন্টে পুনরায় প্রবেশ করতে পারেন।

পরিস্থিতি ১: একটি Red Team অপারেশনে আক্রমণকারী একটি সাধারণ ব্যবহারকারীর অ্যাকাউন্ট কম্প্রোমাইজ করলেন। BloodHound বিশ্লেষণে দেখা গেল এই ব্যবহারকারীর গ্রুপের GenericWrite অধিকার রয়েছে একটি Tier 1 সার্ভারের কম্পিউটার অবজেক্টে। আক্রমণকারী Shadow Credentials যুক্ত করলেন এবং সার্ভারের Machine Account দিয়ে S4U2Self প্রোটোকল ব্যবহার করে লোকাল অ্যাডমিন হিসেবে অ্যাক্সেস পেলেন।

পরিস্থিতি ২: একটি ইনসিডেন্টে আক্রমণকারী Domain Admin অ্যাক্সেস পেয়ে গেলেন। ধরা পড়ার আগে তারা সমস্ত গুরুত্বপূর্ণ অ্যাকাউন্টে (krbtgt, Domain Admins, Service Accounts) Shadow Credentials যুক্ত করে রাখলেন। ইনসিডেন্ট রেসপন্স টিম পাসওয়ার্ড রিসেট করেও আক্রমণকারীর অ্যাক্সেস বন্ধ করতে পারলেন না, কারণ Shadow Credentials অপরিবর্তিত রইল।

Event Log Monitoring

msDS-KeyCredentialLink অ্যাট্রিবিউট পরিবর্তন Domain Controller-এ Event ID 5136 (Directory Service Object Modification) জেনারেট করে। SIEM-এ এই ইভেন্টের জন্য নির্দিষ্ট রুল তৈরি করা যেতে পারে:

• যেকোনো msDS-KeyCredentialLink পরিবর্তন লগ করা
• কোন অ্যাকাউন্ট পরিবর্তন করল তা চিহ্নিত করা
• WHfB ব্যবহার না করা পরিবেশে যেকোনো পরিবর্তন সন্দেহজনক হিসেবে গণ্য করা

PKINIT Authentication Monitoring

Event ID 4768 (Kerberos TGT Request)-এ যদি Certificate Information ফিল্ড থাকে, তবে এটি PKINIT-ভিত্তিক প্রমাণীকরণ নির্দেশ করে। অস্বাভাবিক উৎস (যেমন কোনো ব্যবহারকারীর সাধারণত যে ওয়ার্কস্টেশন থেকে লগইন করেন না সেই উৎস) থেকে PKINIT লগইন সন্দেহজনক।

Sigma Rules এবং SIEM Detection

কমিউনিটিতে ইতিমধ্যে Shadow Credentials শনাক্তকরণের জন্য Sigma Rule রয়েছে যা Splunk, Sentinel, Elastic-এ সহজেই ডিপ্লয় করা যায়।

BloodHound Continuous Assessment

প্রতিষ্ঠানে নিয়মিত BloodHound স্ক্যান চালিয়ে নতুন কোনো Shadow Credentials এজ চিহ্নিত করুন। এটি প্রোঅ্যাকটিভ ডিফেন্সের একটি কার্যকর অংশ।

১. Least Privilege Enforcement

Active Directory-তে কোনো অবজেক্টের উপর GenericWrite, GenericAll বা WriteProperty অনুমতি যেন কেবল প্রয়োজনীয় অ্যাকাউন্টের কাছেই থাকে তা নিশ্চিত করুন। অপ্রয়োজনীয় ACL এন্ট্রি নিয়মিত অডিট করে সরাতে হবে।

২. Tiered Administration Model

Microsoft-এর Enterprise Access Model অনুসরণ করুন। Tier 0 (Domain Controller, AD CS, ADFS) অবজেক্টগুলো শুধুমাত্র Tier 0 অ্যাকাউন্ট থেকেই পরিচালনা করুন। কোনো নিম্ন Tier-এর অ্যাকাউন্ট যেন Tier 0-তে লিখতে না পারে।

৩. Protected Users Group

Domain Admin এবং অন্যান্য Privileged Account-গুলোকে Protected Users গ্রুপে যুক্ত করুন। এই গ্রুপের সদস্যদের জন্য NTLM, Kerberos Delegation এবং অন্যান্য দুর্বল প্রোটোকল নিষ্ক্রিয় থাকে এবং নির্দিষ্ট কিছু আক্রমণ কঠিন হয়ে যায়।

৪. msDS-KeyCredentialLink Audit

SACL কনফিগার করে এই অ্যাট্রিবিউটের যেকোনো পরিবর্তনে স্বয়ংক্রিয় লগিং নিশ্চিত করুন। প্রতিটি পরিবর্তন রিভিউ করার একটি প্রক্রিয়া স্থাপন করুন।

৫. WHfB Hybrid Deployment Hardening

WHfB ব্যবহারকারীদের জন্য নির্দিষ্ট নিরাপত্তা গোষ্ঠী তৈরি করুন এবং শুধুমাত্র সেই গোষ্ঠীর সদস্যদেরকেই নিজ অবজেক্টে কী যুক্ত করার অনুমতি দিন।

৬. Microsoft Defender for Identity

MDI-এর মতো ITDR (Identity Threat Detection and Response) সলিউশন Shadow Credentials সহ অন্যান্য AD আক্রমণ রিয়েল-টাইমে শনাক্ত করতে পারে।

৭. Regular Cleanup এবং Auditing

কর্মী চলে যাওয়ার পর তাদের msDS-KeyCredentialLink এন্ট্রি পরিষ্কার করার একটি প্রক্রিয়া স্থাপন করুন। প্রতি ত্রৈমাসিকে সকল Privileged Account-এর কী এন্ট্রি অডিট করুন।