پاورشل قسمت ۳


تحلیل فنی مسدودسازی PowerShell: یک استراتژی منسوخ و پرخطر

قسمت دوم از مقاله ام در زمینه پاورشل

رویکرد مسدودسازی فایل اجرایی powershell.exe به عنوان یک راهکار امنیتی، مبتنی بر درک ناقصی از معماری این فریم‌ورک است و یک نقطه‌ی کور امنیتی (Security Blind Spot) خطرناک ایجاد می‌کند. PowerShell صرفاً یک برنامه نیست، بلکه یک Automation Engine است که هسته‌ی آن در اسمبلی .NET به نام System.Management.Automation.dll قرار دارد. این DLL می‌تواند توسط هر فرآیندی که قابلیت میزبانی (Hosting) از Common Language Runtime (CLR) را داشته باشد، بارگذاری و اجرا شود.

مهاجمان با بهره‌گیری از این معماری، سیاست‌های مسدودسازی را به سادگی دور می‌زنند. تکنیک‌هایی مانند:

استفاده از میزبان‌های جایگزین (Alternative Hosts): با استفاده از باینری‌های قانونی ویندوز (LotL Bins) مانند InstallUtil.exe یا MSBuild.exe، مهاجمان یک Runspace پاورشل را درون یک فرآیند معتبر ایجاد می‌کنند.
و PowerShell بدون مدیریت (Unmanaged PowerShell): با تزریق مستقیم System.Management.Automation.dll به یک فرآیند دلخواه از طریق کدهای غیرمدیریتی (مانند C++), حمله را از دید مکانیزم‌های نظارتی مبتنی بر .NET پنهان می‌کنند.

فاجعه‌ی اصلی در این سناریو، از دست رفتن داده‌های تله‌متری حیاتی است. قابلیت‌های امنیتی قدرتمندی مانند Script Block Logging (Event ID 4104) و PowerShell Transcription که برای ثبت دقیق دستورات و فعالیت‌ها طراحی شده‌اند، به طور پیش‌فرض برای powershell.exe بهینه شده‌اند. هنگامی که مهاجم از یک میزبان جایگزین استفاده می‌کند، این لاگ‌های حیاتی تولید نشده و تیم امنیتی در برابر یک حمله‌ی کاملاً نامرئی قرار می‌گیرد.

رویکرد مدرن و مؤثر، Hardening به جای Blocking است؛ یعنی با استفاده از WDAC/AppLocker برای اعمال Constrained Language Mode و پیاده‌سازی Just Enough Administration (JEA)، ما PowerShell را از یک وکتور حمله به یک سنسور شناسایی با قابلیت اعتماد بالا (High-Fidelity Detection Sensor) تبدیل می‌کنیم


این مطلب بخشی از دوره CISSP است.


دوره های آکادمی روزبه درحال ثبت نام
از سطح ۱ تا هانت و CISSP