حملات Client-Side در عملیات Red Team

مقدمه

در عملیات Red Team، هرگاه مسیرهای نفوذ مستقیم به شبکه — مانند بهره‌برداری از سرویس‌های اینترنت‌محور — با فایروال، مدیریت وصله‌های امنیتی (Patch Management) قوی، یا سطح حمله‌ی محدود بسته شوند، تمرکز تیم حمله به لایه‌ی کاربر می‌رسد. حملات Client-Side یعنی به‌جای هدف قرار دادن سرور یا سرویس، مستقیماً روی endpoint کاربر و نحوه‌ی تعامل او با فایل، ایمیل یا مرورگر کار کنیم. اثربخشی این دسته از تکنیک‌ها به سه دلیل است:

1. شکاف در پوشش امنیتی: بسیاری از این فرمت‌ها (LNK، WSF، SVG) در اصل برای کاربردهای بی‌خطر طراحی شده‌اند و امضاهای آنتی‌ویروس و قوانین Email Gateway معمولاً دیرتر از ظهور تکنیک‌های جدید به‌روز می‌شوند.
2. وابستگی به رفتار کاربر: کاربر نهایی اغلب ضعیف‌ترین حلقه‌ی دفاعی است؛ یک کلیک روی یک shortcut یا باز کردن یک پیوست، دروازه‌ی ورود را می‌گشاید.
3. سوءاستفاده از LOLBins: بسیاری از این تکنیک‌ها به‌جای اجرای فایل‌های اجرایی مشکوک، از باینری‌های امضاشده و بومی ویندوز (مانند cscript.exe، wscript.exe، mshta.exe) بهره می‌برند که شناسایی مبتنی بر Signature را دشوار می‌کند.

در ادامه، مهم‌ترین زیرشاخه‌های حملات Client-Side را از منظر مکانیزم، اثر تهاجمی، و راهکارهای شناسایی و مقابله بررسی می‌کنیم — نه به‌عنوان راهنمای ساخت payload، بلکه به‌عنوان تحلیل تهدید برای تیم‌های آموزشی و Blue Team.

LNK Weaponisation

مکانیزم

فایل‌های shortcut ویندوز (.lnk) از دیرباز هدف سوءاستفاده بوده‌اند؛ به دو دلیل: ساختار باینری آن‌ها (Shell Link Binary File Format) شامل فیلدهای فراداده‌ی (metadata) فراوانی است — از جمله فیلد آیکون (IconEnvironmentDataBlock) — که می‌توان در آن‌ها اطلاعات غیرمنتظره جاسازی کرد؛ و آنتی‌ویروس به‌طور سنتی فایل LNK را کم‌خطرتر از یک فایل اجرایی مستقیم می‌داند، چون LNK صرفاً یک اشاره‌گر (pointer) به یک هدف است.

از منظر MITRE ATT&CK، این رفتار زیرمجموعه‌ی T1027.012 – LNK Icon Smuggling و T1204.002 – User Execution: Malicious File است. تکنیک‌های پیشرفته‌تر تلاش می‌کنند حجم بیشتری از داده را در ساختار LNK جای دهند تا نیاز به یک Dropper جداگانه کاهش یابد — اما این کار به‌طور طبیعی حجم فایل را از اندازه‌ی معمول (چند کیلوبایت) خارج می‌کند.

نشانه‌های شناسایی (Detection)

• اندازه‌ی فایل: یک .lnk معمولی چند کیلوبایت است. هر LNK با حجم غیرعادی (چند صد کیلوبایت به بالا) یک شاخص هشداردهنده‌ی قوی است.
• Sysmon Event ID 15 (FileCreateStreamHash) برای ردیابی فایل‌های دریافتی همراه با Zone.Identifier (Mark of the Web).
• Sysmon Event ID 1 با تمرکز بر زنجیره‌ی Parent-Child: اجرای powershell.exe، cmd.exe، mshta.exe یا rundll32.exe با explorer.exe به‌عنوان فرایند والد، در بازه‌ی زمانی نزدیک به باز شدن فایلی از پوشه‌ی Downloads.
• بررسی فیلدهای فراداده‌ی LNK (Target Path، Icon Location، Working Directory، Command Line Arguments) با ابزارهایی مانند LECmd برای شناسایی مسیرهای غیرعادی یا کدگذاری‌شده.

راهکارهای مقابله (Mitigation)

• مسدودسازی یا هشداردهی برای پیوست‌های .lnk در Email Gateway، به‌ویژه هنگامی که درون بایگانی (.zip، .rar) ارسال شده باشند.
• فعال‌سازی قانون Attack Surface Reduction (ASR): Block execution of potentially obfuscated scripts.
• اطمینان از اعمال درست Mark of the Web (MOTW) روی فایل‌های استخراج‌شده از بایگانی.
• آموزش کاربران درباره‌ی خطر باز کردن shortcut های ناشناس، به‌ویژه در پیوست ایمیل یا دریافت از منابع نامعتبر.

Windows Script Host (WSH) Abuse

مکانیزم

فایل‌های .wsf (Windows Script File) یک container قانونی هستند که اجازه می‌دهند چند زبان اسکریپتی (مانند JScript و VBScript) در یک فایل XML واحد ترکیب شوند و توسط cscript.exe یا wscript.exe — دو باینری بومی و امضاشده‌ی ویندوز — اجرا شوند. همین ویژگی، WSH را به یک LOLBin ارزشمند برای اجرای کد بدون نیاز به فایل اجرایی مستقل تبدیل می‌کند. این رفتار در چارچوب MITRE با T1059.005 (Visual Basic) و T1059.007 (JavaScript) زیر تاکتیک T1059 – Command and Scripting Interpreter دسته‌بندی می‌شود.

روش‌های رایج برای دشوارتر کردن تحلیل ایستا و رفتاری این اسکریپت‌ها — مصداق T1027 – Obfuscated Files or Information و T1140 – Deobfuscate/Decode Files or Information — در چند دسته‌ی مفهومی جای می‌گیرند:

نشانه‌های شناسایی (Detection)

• Sysmon Event ID 1: اجرای cscript.exe یا wscript.exe که فرزند آن یک shell (cmd.exe) یا powershell.exe باشد.
• PowerShell Script Block Logging (Event ID 4104) و AMSI برای ثبت محتوای واقعی اسکریپت پس از رمزگشایی در حافظه.
• الگوهای زمانی غیرعادی در Process Creation، نشانه‌ی وجود Sleep عمدی.
• شناسایی command-line هایی با تعداد بالای caret (^) یا quote درون‌خطی، قابل پوشش با Sigma rule های عمومی.

راهکارهای مقابله (Mitigation)

• غیرفعال‌سازی WSH از طریق Group Policy (HKLM\Software\Microsoft\Windows Script Host\Settings\Enabled = 0).
• فعال‌سازی قانون ASR: Block JavaScript or VBScript from launching downloaded executable content.
• فعال‌سازی AMSI برای PowerShell/VBScript/JScript.
• استفاده از Constrained Language Mode و Application Whitelisting (AppLocker یا WDAC).
• مسدودسازی پیوست‌های .wsf، .js، .vbs، .hta در Email Gateway.

VBA Stomping

مکانیزم

فایل‌های آفیس مبتنی بر ماکرو (.docm، .xlsm) از فرمت Compound File Binary Format (CFBF) بهره می‌برند که در آن، کد VBA به دو شکل موازی ذخیره می‌شود: کد منبع (Source Code) قابل‌خواندن در VBA Editor، و p-code — نسخه‌ی کامپایل‌شده‌ای که آفیس در زمان اجرا مستقیماً از آن استفاده می‌کند.

VBA Stomping از این شکاف بهره می‌برد: مهاجم p-code مخرب را در فایل جاسازی می‌کند اما کد منبع نمایش‌داده‌شده در ویرایشگر VBA را با متنی بی‌ضرر جایگزین می‌کند. نتیجه این است که تحلیل‌گری که فایل را در VBA Editor باز می‌کند هیچ کد مخربی نمی‌بیند، درحالی‌که آفیس در عمل p-code مخرب را اجرا می‌کند. ابزار متن‌باز شناخته‌شده‌ای به نام EvilClippy این تکنیک را خودکار می‌کند.

این رفتار زیرمجموعه‌ی T1564.007 – Hide Artifacts: VBA Stomping و T1137 – Office Application Startup است.

نشانه‌های شناسایی (Detection)

• تحلیل ایستای فایل با ابزارهایی مانند oletools / olevba برای آشکارسازی ناهمخوانی میان p-code و کد منبع (مثلاً با pcodedmp).
• Sysmon Event ID 1: زنجیره‌ی winword.exe/excel.exe → cmd.exe/powershell.exe/mshta.exe/wscript.exe.
• فعال‌سازی Group Policy Macro Runtime Scan Scope برای پویش محتوای ماکرو از طریق AMSI.
• بررسی Mark of the Web روی فایل‌های آفیس دریافتی از اینترنت.

راهکارهای مقابله (Mitigation)

• مسدودسازی اجرای ماکرو به‌صورت پیش‌فرض برای فایل‌های دارای MOTW.
• فعال‌سازی قانون ASR: Block Office applications from creating child processes و Block Win32 API calls from Office macros.
• استفاده از Protected View و پرهیز از غیرفعال‌سازی آن.
• پویش دوره‌ای فایل‌های آفیس داخلی با oletools به‌عنوان کنترل Threat Hunting.

HTML Smuggling

مکانیزم

مرورگرهای مدرن با پشتیبانی از HTML5 امکان ساخت یک JavaScript Blob — شیء باینری تغییرناپذیر در حافظه‌ی مرورگر — و سپس فعال‌سازی دریافت خودکار آن با attribute download یا API هایی مانند msSaveBlob را دارند. نکته‌ی کلیدی این است که فایل نهایی هرگز به‌صورت کامل روی شبکه منتقل نمی‌شود؛ داده به‌شکل رمزگذاری‌شده (Base64/Hex) درون خود صفحه‌ی HTML جاسازی شده و تنها در سمت کلاینت به فایل واقعی تبدیل می‌شود. این تکنیک با شناسه‌ی T1027.006 – HTML Smuggling ثبت شده و در کمپین‌های شناخته‌شده‌ای مانند NOBELIUM مشاهده شده است.

تفاوت فرمت‌های تصویری Raster و Vector

SVG Smuggling

تصاویر وکتور SVG می‌توانند کد JavaScript را مستقیماً در خود جای دهند. هنگامی که کاربر یک فایل SVG را در مرورگر باز می‌کند، اسکریپت جاسازی‌شده اجرا شده و می‌تواند همان مکانیزم Blob-based smuggling را برای ساخت فایل ثانویه فعال کند. این رفتار به‌عنوان T1027.017 – SVG Smuggling ثبت شده است.

نشانه‌های شناسایی (Detection)

• Sysmon Event ID 15 / 11 برای رصد فایل‌های ایجادشده در Downloads بلافاصله پس از بازدید از یک صفحه‌ی HTML.
• بازرسی محتوای HTML/SVG در سطح Gateway برای رشته‌های کلیدی مانند Blob(، atob(، msSaveBlob.
• پایش زنجیره‌ی فرایند به‌دنبال باز شدن فایل توسط explorer.exe و اجرای بعدی یک اسکریپت.
• بررسی ناهمخوانی میان پسوند اعلام‌شده در Content-Type و محتوای واقعی decode‌شده در Sandbox ایمیل.

راهکارهای مقابله (Mitigation)

• مسدودسازی یا Sandbox اجباری برای پیوست‌های .html، .htm، .svg.
• استفاده از Remote Browser Isolation (RBI) برای پیوست‌ها و پیوندهای ناشناس.
• اجرای قوانین ASR برای جلوگیری از دریافت محتوای اجراپذیر از طریق مرورگر.
• اطمینان از اعمال درست Mark of the Web روی فایل‌های ساخته‌شده از طریق Blob.

Chain Client-Side Attack (زنجیره‌ی چندمرحله‌ای)

مکانیزم

در عملیات واقعی Red Team و حملات مشاهده‌شده‌ی APT، تکنیک‌های بالا به‌ندرت به‌تنهایی به‌کار می‌روند. رویکرد رایج، بسته‌بندی چند مرحله در یک container واحد (معمولاً .zip) است:

• یک فایل Decoy (مثلاً یک PDF بی‌ضرر) برای حفظ باور کاربر.
• یک PowerShell launcher که مرحله‌ی بعد را واکشی یا اجرا می‌کند.
• یک LNK که هم Decoy و هم launcher را در پس‌زمینه فعال می‌کند.

در نمونه‌های macro-based، معادل این زنجیره یک Macro Dropper با رویداد Auto_Open است. این Dropper ها معمولاً به مسیرهای قابل‌نوشتن توسط کاربر عادی نیاز دارند — علاوه بر %TEMP%، مسیر C:\Windows\Tasks\ نیز به‌طور پیش‌فرض توسط کاربران استاندارد قابل‌نوشتن است.

این الگو معمولاً ترکیبی از T1566 – Phishing، T1204 – User Execution، T1027، و T1053/T1547 (در صورت persistence) است.

نشانه‌های شناسایی (Detection)

• پایش نوشتن فایل در C:\Windows\Tasks\ توسط فرایندهای non-system (Sysmon Event ID 11).
• تحلیل زنجیره‌ی کامل Process Tree: مثلاً outlook.exe/winword.exe → استخراج از .zip → explorer.exe → pay.lnk → powershell.exe.
• بررسی محتوای بایگانی‌های دریافتی برای وجود همزمان چند نوع فایل با نقش‌های متفاوت.
• هشداردهی EDR روی shortcut های جدید پین‌شده که از طریق اسکریپت ایجاد شده‌اند.

راهکارهای مقابله (Mitigation)

• کنترل دسترسی سخت‌گیرانه‌تر روی مسیرهای قابل‌نوشتن مانند %TEMP% و C:\Windows\Tasks\ با AppLocker/WDAC.
• Sandbox کردن پیوست‌های بایگانی‌شده پیش از تحویل به کاربر نهایی.
• هشدار EDR مبتنی بر Process Tree برای الگوهای چندمرحله‌ای.
• آموزش کاربران در قالب تمرین‌های Phishing Simulation با سناریوهای زنجیره‌ای.

جمع‌بندی: نگاشت به MITRE ATT&CK

نکته‌ی کلیدی برای Blue Team

مخرج مشترک همه‌ی این تکنیک‌ها یک ایده‌ی واحد است: سوءاستفاده از یک فرمت یا کانال که به‌طور پیش‌فرض «کم‌خطر» طبقه‌بندی شده است. به همین دلیل، دفاع مؤثر نباید صرفاً به Signature های شناخته‌شده‌ی هر تکنیک تکیه کند، بلکه باید بر سه محور پایدار استوار باشد:

1. همبستگی زنجیره‌ی Process به‌جای رویدادهای مجزا.
2. اعمال درست Mark of the Web در تمام مراحل استخراج و دریافت.
3. محدودسازی اجرای محتوای اسکریپتی/LNK از مسیرهای کاربرمحور (Downloads، Temp، Tasks) از طریق ASR و AppLocker/WDAC.

این مقاله با رویکرد تحلیلی و دفاعی نوشته شده و برای اهداف آموزشی Red Team/Blue Team در نظر گرفته شده است؛ هدف آن درک مکانیزم تهدید برای طراحی کنترل‌های شناسایی و مقابله‌ی مؤثرتر است.