Mimikatz هیچ مرزی را نمیشکند؛ فقط نشان میدهد مرز کجا تمام شده است
چرا قدرتمندترین ابزار استخراج Credential در ویندوز، نه یک Exploit، بلکه یک طراحی است
هر چند سال یکبار، یک ابزار امنیتی جدید معرفی میشود که وعده میدهد محافظت در برابر mimikatz را حل کرده است. هر بار، چند ماه بعد، یک تکنیک bypass جدید منتشر میشود و چرخه از نو شروع میشود. این الگوی تکرارشونده یک سوال عمیقتر را مطرح میکند: آیا واقعاً در تلاش برای رفع یک باگ هستیم، یا داریم سعی میکنیم چیزی را اصلاح کنیم که از همان ابتدا بخشی از طراحی بوده؟
پاسخ این مقاله، دومی است. و فهم این تفاوت، نهفقط یک نکتهی فنی، بلکه یک تغییر زاویهی دید استراتژیک در معماری امنیت سازمانی است.
Mimikatz چه کاری انجام نمیدهد
نقطهی شروع درست، نه این است که mimikatz چه میکند، بلکه این است که چه کاری نمیکند. Mimikatz هیچ آسیبپذیری نرمافزاری (CVE) را exploit نمیکند. هیچ buffer overflow یا memory corruption ای در کار نیست. کاری که این ابزار انجام میدهد، خواندن دادهای است که سیستمعامل، با اجازهی خودش، آن را در حافظه نگه داشته است.
پروسهی LSASS (Local Security Authority Subsystem Service) در ویندوز، وظیفه دارد credential کاربران (هش پسورد NTLM، Kerberos ticket، و در شرایطی پسورد بهصورت reversibly-encrypted) را برای پشتیبانی از Single Sign-On نگه دارد. این یک ویژگی است، نه یک عیب: بدون آن، کاربر باید در هر اتصال به هر منبع شبکه دوباره احراز هویت کند. mimikatz صرفاً این حافظه را - وقتی مجوز کافی برای خوانش آن وجود دارد - میخواند.
این جمله کلید کل بحث است: mimikatz نیاز به همان سطح دسترسیای دارد که خود ویندوز برای این کار تعریف کرده است.
مرزی که مایکروسافت رسماً اعلام کرده وجود ندارد
اینجاست که میرسیم به سوال اصلی این مقاله: چرا مایکروسافت تلاش جدی برای بستن کامل این مسیر نمیکند؟
پاسخ رسمی، و شاید برای بسیاری غیرمنتظره، این است: مایکروسافت بهطور رسمی اعلام کرده که هیچ مرز امنیتی (Security Boundary) بین سطح Administrator و سطح SYSTEM در ویندوز وجود ندارد. این یعنی از نگاه معماری ویندوز، لحظهای که یک مهاجم به دسترسی Local Administrator میرسد، از نظر مایکروسافت بازی از قبل تمام شده است - نه به این معنا که سیستم دیگر قابل دفاع نیست، بلکه به این معنا که از این نقطه به بعد، هر کاری که مهاجم انجام دهد (از جمله خواندن حافظهی LSASS) دیگر یک نقض مرز محسوب نمیشود، چون خود مرز، دقیقاً همانجا کشیده شده بود.
به زبان سادهتر: مرزی که ویندوز واقعاً از آن دفاع میکند، مرز بین کاربر عادی و Administrator است؛ نه مرز بین Administrator و همهی دانشی که سیستم دربارهی هویتها دارد. وقتی مهاجم از مرز اول عبور کرد، مرز دوم - از نگاه طراحی - دیگر وجود ندارد که نقض شود.
این دقیقاً همان دلیلی است که توضیح میدهد چرا، صرفنظر از اینکه Credential Guard یا LSA Protection چقدر قویتر شوند، تکنیکهای جایگزین (مثل DCSync، Golden Ticket، یا حمله به درایورهای آسیبپذیر برای دور زدن این محافظتها) همیشه راهی پیدا میکنند. این محافظتها مرز را سختتر میکنند، اما مرزی که از نظر طراحی اصلاً تعریف نشده را نمیتوان واقعاً بسته کرد.
چرا این طراحی، یک انتخاب آگاهانه بود - نه یک خطا
این طراحی محصول یک trade-off قدیمی و آگاهانه است که از دوران NTLM و معماری دامنهی ویندوز (Active Directory) به ارث رسیده:
کارایی در برابر ایزولاسیون کامل: اگر هر درخواست احراز هویت نیاز به ارتباط مستقیم با Domain Controller داشت (بدون cache کردن credential در سطح local)، عملکرد شبکه بهشدت کند میشد.
سازگاری با گذشته (Backward Compatibility): میلیونها سیستم و اپلیکیشن سازمانی روی این مدل اعتماد بنا شدهاند؛ تغییر بنیادی آن یعنی شکستن سازگاری با دههها زیرساخت موجود.
فرض بنیادی امنیت ویندوز کلاسیک: فرض اصلی این بود که اگر کسی به Administrator رسیده، او دیگر دشمن نیست، بلکه مدیر سیستم است. این فرض در دنیای امروز (با ransomware، APT، و insider threat) دیگر معتبر نیست، اما معماری پایهای هنوز همان است.
به بیان دیگر، mimikatz محصول جانبی یک تصمیم معماری است که سالها قبل از وجود mimikatz گرفته شده بود؛ بنژامین دلپی فقط این تصمیم را قابلمشاهده کرد، آن را نساخت.
پیامد استراتژیک: جنگیدن با نتیجه بهجای جنگیدن با علت
این درک، یک تغییر مهم در اولویتبندی دفاعی ایجاد میکند. اگر فرض کنیم mimikatz یک «باگ» است، استراتژی منطقی این میشود: محصول بهتر بخریم تا mimikatz را تشخیص دهد و بلاک کند. اما اگر بپذیریم mimikatz نتیجهی یک مرز اعتماد است که از قبل تعریف شده، استراتژی درست تغییر میکند: تمرکز باید روی این باشد که مهاجم هرگز به آن مرز (دسترسی Administrator) نرسد، یا اگر رسید، شعاع آسیب (Blast Radius) محدود بماند.
این یعنی در عمل:
مدل سرپرستی لایهبندیشده (Tiered Administration): هیچ Administrator سطح Domain نباید روی سیستمهای کاربر عادی لاگین کند - این دقیقاً همان مسیری است که credential dumping را به یک تهدید سراسری تبدیل میکند.
Just-in-Time و Just-Enough Administration: دسترسی Admin باید موقت، محدود به وظیفه، و قابل audit باشد - نه یک حالت دائمی.
Privileged Access Management (PAM): جداسازی کامل حسابهای privileged از فعالیت روزمره.
Credential Guard بهعنوان یک لایهی تکمیلی، نه راهحل نهایی: این ابزار هزینهی حمله را بالا میبرد، اما مرز بنیادی را تغییر نمیدهد.
فرض «Assume Breach»: بهجای امیدواری به اینکه هیچوقت مهاجم به Admin نمیرسد، باید معماری بهگونهای طراحی شود که حتی در صورت رسیدن، lateral movement و privilege escalation به سرعت محدود و شناسایی شود.
جمعبندی
Mimikatz از بین نمیرود، چون چیزی نیست که بتوان «از بین برد». این ابزار، آینهای است که یک حقیقت معماری قدیمی در ویندوز را نشان میدهد: مرز امنیتی واقعی، جایی است که مایکروسافت رسماً آن را تعریف کرده - یعنی مرز ورود به سطح Administrator - نه جایی که کاربران یا فروشندگان امنیتی فکر میکنند باید باشد. تا زمانی که سازمانها این مرز را بهعنوان نقطهی اصلی دفاع نبینند و منابع را بهجای «شکار mimikatz» به «جلوگیری از رسیدن به آن مرز» تخصیص ندهند، این چرخهی بیپایان تشخیص و bypass ادامه خواهد داشت.
سوال درست هرگز «چگونه mimikatz را متوقف کنیم؟» نبوده است؛ سوال درست همیشه این بوده: «چرا اجازه دادیم مهاجم به نقطهای برسد که اصلاً نیازی به مهارت خاصی برای دیدن همهچیز نداشته باشد؟»
