فایلهایی که با تکنیک Polyglot ساخته میشوند، در سالهای اخیر بیش از پیش در حملات سایبری دیده شدهاند. این فایلها به مهاجمان اجازه میدهند بدافزار را از فیلترهای ایمیل و اسکنرهای فایل عبور دهند، قربانیان را در حملات فیشینگ فریب دهند و بررسی رخدادهای امنیتی را پیچیدهتر کنند.
برای اجرای این روش، مهاجمان عمداً فایلی میسازند که بسته به برنامهای که آن را باز میکند، سیستم بتواند آن را بهعنوان فرمتهای مختلف تفسیر کند. نمونه کلاسیک آن، فایلی است که میتواند هم بهعنوان یک تصویر PNG و هم بهعنوان یک آرشیو ZIP پردازش شود. کافی است پسوند فایل تغییر کند یا فایل با برنامه متفاوتی باز شود.
در ادامه بررسی میکنیم چرا اساساً ساخت چنین فایلهایی امکانپذیر است، چه ترکیبهایی از فرمتها در حملات واقعی مشاهده شدهاند و سازمانها چگونه میتوانند از خود در برابر این تهدید محافظت کنند.
چرا ساخت فایلهای Polyglot امکانپذیر است؟
فرمتهای دادهای مورد استفاده در فایلهای Polyglot معمولاً عجیب یا خاص نیستند. همهچیز به ترکیب هوشمندانه فرمتهای رایجی برمیگردد که از نظر ساختاری با یکدیگر سازگارند.
Polyglotها از دستکم یکی از ویژگیهای زیر در برخی فرمتهای فایل سوءاستفاده میکنند:
- بیشتر فرمتهای فایل باید از نخستین Byte خوانده شوند، اما برخی از انتهای فایل خوانده میشوند. واضحترین نمونه، آرشیو ZIP است. حتی اگر ابتدای فایل خراب یا ناقص باشد، برنامهها همچنان میتوانند آن را بخوانند، زیرا Headerهای موردنیاز در انتهای فایل قرار دارند. این ویژگی به مهاجمان اجازه میدهد دو فایل را بهسادگی به یکدیگر متصل کنند؛ برای مثال، یک PNG و یک ZIP. ابتدای فایل بهعنوان یک تصویر PNG معتبر خوانده میشود، در حالی که انتهای آن یک آرشیو ZIP معتبر است.
- بسیاری از فرمتها مانند عروسکهای روسی Matryoshka عمل میکنند. فایل در ظاهر پسوندی مشخص و متناسب با کاربرد خود دارد، اما درون آن در واقع یک آرشیو ZIP شامل دادههای لازم قرار گرفته است. اسناد مدرن Office مانند DOCX، XLSX و PPTX، بستههای نصب Android با فرمت APK، فایلهای Library جاوا با فرمت JAR و بسیاری موارد دیگر در این دسته قرار میگیرند.
- برخی فرمتها ساختار سختگیرانهای ندارند یا قواعد آنها بهاندازهای انعطافپذیر است که برنامه پردازشکننده میتواند بخش موردنیاز خود را حتی زمانی که در ابتدای فایل قرار ندارد، پیدا کند.
Repository موسوم به Polydet در GitHub نمونههای متعددی از ترکیبهای ممکن برای ساخت فایلهای Polyglot را معرفی کرده است.
در طبقهبندی MITRE، این تکنیک در دسته Masquerading و با شناسه T1036.008 – Masquerade File Type قرار میگیرد.
نمونههایی از فایلهای Polyglot در حملات سایبری شناختهشده
تحلیلهای عمومی کمپینهای بدافزاری، انواع مختلفی از Polyglotها را نشان میدهند. مهاجمان کل سناریوی حمله را بر اساس ترکیب مشخصی از فرمتهای فایل طراحی میکنند.
گروه Head Mare بدافزار PhantomPyramid را بهصورت یک پیوست ZIP توزیع کرد. این فایل از کد اجرایی Windows با فرمت EXE تشکیل شده بود که یک آرشیو کوچک ZIP به انتهای آن متصل شده بود.
وقتی قربانی آرشیو را باز میکرد، داخل آن فایلی با پسوند PDF.LNK قرار داشت. این فایل Shortcut همان پیوست Polyglot را دوباره اجرا میکرد، اما این بار بهعنوان یک فایل اجرایی.
در حملهای که توسط JPCERT مستند شد، مهاجمان فایلی ساختند که ابتدای آن ساختار PDF داشت و بیشتر اسکنرها آن را PDF شناسایی میکردند، اما فایل پسوند DOC داشت و در برنامههای Office بهعنوان یک سند DOC معتبر حاوی Macroهای مخرب باز میشد.
در حملات توزیعکننده Trojanهای StrRAT و Ratty، از یک Polyglot متشکل از بسته نصب امضاشده Windows با فرمت MSI استفاده شد که کد مخرب Java با فرمت JAR به انتهای آن اضافه شده بود.
حملات StrelaStealer نیز از یک Polyglot با پسوند HTML استفاده کردند: یک Library ویندوز با فرمت DLL که یک سند HTML فریبدهنده به انتهای آن متصل شده بود.
یک Shortcut داخل Archive فایل را دو بار اجرا میکرد: یک بار از طریق دستور start، که معادل Double-click بود و مرورگر را باز کرده و سند HTML را نمایش میداد، و بار دیگر از طریق rundll32 که DLL مخرب را اجرا میکرد.
در یک حمله شبیهسازیشده اما هوشمندانه، پژوهشگران دو فایل ZIP معمولی را به یکدیگر متصل کردند و متوجه شدند نرمافزارهای محبوب مدیریت Archive، فایل ترکیبی را به شکلهای مختلف نمایش میدهند.
برخی فقط Archive اول را نشان میدادند، برخی فقط دومی را و برخی هر دو را همزمان، بهگونهای که گویی یک Archive واحد با محتوای مشترک هستند.
اگر مهاجم زیرساخت قربانی را بشناسد و بداند چه نرمافزاری روی سیستم او نصب شده است، میتواند از چنین ترکیبی استفاده کند تا یک فایل را به ابزار امنیتی نشان دهد و فایل دیگری را به قربانی.
در کمپینی که بدافزار سرقت اطلاعات IcedID را توزیع میکرد، مهاجمان از یک Matryoshka پیچیده بدافزاری استفاده کردند.
آنها یک آرشیو ZIP را به ایمیلهای فیشینگ پیوست میکردند. پس از Extract شدن، یک فایل ISO به دست میآمد. داخل آن نیز یک فایل CHM یا Windows Help قرار داشت که با تکنیک Polyglot ساخته شده بود.
وقتی قربانی فایل را با ابزار استاندارد Windows Help باز میکرد، فایل یک Script جاوااسکریپت Embedشده در محتوای Help را اجرا میکرد. این Script برنامه استاندارد mshta یا Microsoft HTML Application Host را اجرا کرده و همان فایل CHM را به آن معرفی میکرد.
نویسندگان کمپین یک برنامه HTA را بهگونهای داخل فایل CHM قرار داده بودند که حضور آن مانع خوانده شدن فایل بهعنوان یک سند Help عادی نمیشد.
Handler مربوط به HTA نیز تمام دادههای اضافی ابتدای فایل را نادیده میگرفت تا به Script مربوط به HTA برسد.
ابزارهای امنیتی چگونه با فایلهای Polyglot برخورد میکنند؟
نمونههای بالا نشان میدهند که این روش «خوانش دوگانه» چگونه به مهاجمان اجازه میدهد بدافزار را روی سیستم قربانی اجرا کنند.
اما فیلترهای ایمیل و سیستمهای EDR چنین فایلهایی را چگونه تفسیر میکنند؟
پاسخ کاملاً به راهکار امنیتی مورد استفاده بستگی دارد و باید یا با بررسی مستندات فنی Vendor یا از طریق اجرای آزمایشی کنترلشده در زیرساخت سازمانی و با رعایت تمام ملاحظات لازم بررسی شود.
با این حال، بهطور کلی دو نکته در بیشتر راهکارها صدق میکند:
- بیشتر راهکارهای امنیتی صرفاً به پسوند اعلامشده فایل اعتماد نمیکنند، بلکه ابتدای آن را بررسی میکنند تا ساختار واقعی فایل مشخص شود. به همین دلیل، در حملهای که پیشتر توضیح داده شد، فایل PDF با پسوند DOC بهعنوان یک PDF بیخطر تحلیل شد، در حالی که Macro مخرب در بخش DOC متصلشده به انتهای فایل قرار داشت.
- اگر فایل با محتوایی بیخطر مانند تصویر شروع شود و پسوند آن نیز با همان محتوا مطابقت داشته باشد، احتمالاً تحلیلهای پیشرفتهتر روی آن انجام نمیشود. مهاجمان میتوانند از این موضوع سوءاستفاده کنند و در دستورالعملهای همراه فایل از قربانی بخواهند پسوند آن را تغییر دهد تا رفتار سیستم بهجای تصویر، به Payload دوم وابسته شود.
چگونه از سازمان در برابر حملات مبتنی بر فایلهای Polyglot محافظت کنیم؟
مقابله با فایلهای Polyglot به راهکارهای فنی یا سازمانی بسیار پیچیده نیاز ندارد؛ آنچه اهمیت دارد، رعایت منظم و جدی اصول امنیتی در سراسر سازمان است:
- برای برنامههایی که اجازه اجرا روی Workstationهای کارکنان دارند، Allowlist بسته و مشخص تعریف کنید. برنامههای قدیمی Windows، ابزارهای مدیریتی Microsoft که استفاده نمیشوند، نرمافزارهای Remote Access و انتقال فایل و هر ابزار دیگری را که بالقوه خطرناک یا منسوخ تشخیص داده میشود، از فهرست مجاز حذف کنید.
- از راهکارهای پیشرفته امنیت ایمیل مجهز به CDR و Detonation استفاده کنید. فناوری Content Disarm and Reconstruction یا CDR پیوستهای مشکوک را خنثی کرده و نسخهای امنتر از آنها بازسازی میکند. Detonation نیز فایلهای مشکوک را برای تحلیل در محیطی ایزوله اجرا میکند. برای پیوستهایی که نشانههای ظاهری Polyglot بودن دارند، مانند تمام فایلهای Archive و Office، فایلهایی با پسوندهای غیرمعمول و موارد مشابه، تحلیل عمیق را فعال کنید.
- راهکار EDR را نیز برای تحلیل عمیق فایلهای احتمالی Polyglot پیکربندی کنید.
- قوانین کنترلی ایجاد کنید که ترکیبهای غیرعادی میان Process و فایلهایی را که برای پردازش به آن تحویل داده میشوند شناسایی کنند؛ برای مثال، اجرای فایل CHM از طریق mshta یا اجرای فایل HTML از طریق rundll32، همانطور که در نمونههای بالا مشاهده شد.
- اطلاعات پایه درباره فایلهای Polyglot را به برنامه آموزش آگاهی امنیتی کارکنان اضافه کنید تا کاربران زمانی که از آنها خواسته میشود پسوند یک فایل را تغییر دهند یا فایل را به شکل غیرعادی، مثلاً با یک برنامه خاص، باز کنند، هوشیار باشند.