Abusing Internet Explorer COM Object
مقاله
  • ۳۰ بهمن ۱۴۰۲
  • Learning Road Map
  • ۶ دقیقه خواندن

Abusing Internet Explorer COM Object

جدول محتوا

بدافزارها از تکنیک‌های مختلفی برای انجام فعالیت‌های خود استفاده می‌کنند که استفاده از COM، یکی از متداول‌ترین این روش‌ها است. در این مقاله و مقاله‌های آتی، به بررسی چند تکنیکی که از COM بهره می‌برند، می‌پردازم.

COM 101

COM توسط مایکروسافت ایجاد شد تا componentهای مختلف سیستم، راهی برای ارتباط و انتقال دیتا داشته باشند. COM اجازه می‌دهد برنامه‌های کاربردی که توسط شرکت‌های مختلف و در زبان‌های مختلف نوشته شده‌اند، با هم و بدون مشکل از طریق یک interface استاندارد ارتباط داشته باشند. (در واقع می‌توانید کدی از نرم‌افزار دیگر را فراخوانی کنید بدون اینکه از جزییات آن اطلاع داشته باشید.) COM به صورت client/server پیاده‌سازی شده است.  Clientها برنامه‌هایی هستند که از  COM Objectها استفاده می‌کنند و serverها این Objectها را، برای بقیه‌ی سیستم، فراهم می‌کنند. Objectها در واقع یک instance از یک class[۱] هستند و دسترسی به این کلاس‌ها از طریق یک CLSID[۲] اتفاق می‌افتد. هر کلاس، مجموعه‌ای از قابلیت‌ها را از طریق interface[۳]ها به بقیه‌ی سیستم می‌دهد. این interfaceها به وسیله‌ی یک IID[۴] شناخته می‌شوند. یکی از راه‌هایی که محصولات امنیتی بدافزار را شناسایی می‌کنند، بررسی پروسس‌هایی است که به طور معمول نباید با اینترنت ارتباطی برقرار کنند؛ و یا پروسس‌هایی که برای ارتباط با اینترنت مورد اطمینان نیستند. در اینجا ما با استفاده از یک COM Object[۵] که توسط Internet Explorer در اختیار سیستم قرار می‌گیرد، با C&C[۶] خود ارتباط برقرار می‌کنیم. ابتدا استفاده از این تکنیک توسط APT15 را بررسی می‌کنم و راهکارهایی برای آسان‌تر کردن مهندسی معکوس کدهایی که از COM استفاده می‌کنند، ارایه می‌دهم.

Reverse Engineering COM Usage in Malware

برای دسترسی به COM معمولا از CoCreateInstance[۷] استفاده می‌شود.

Figure 1: CoCreateInstance in APT15's sample

اما از کجا متوجه شویم که CLSID مربوط به Internet Explorer و IID مربوط به IWebBrowser2 خواهد بود ؟ خوشبختانه James Forshaw ابزاری برای بررسی COM نوشته است. چند کاراکتر اول  CLSID را در Registry → CLSIDs سرچ می‌کنیم و متوجه می‌شویم که Internet Explorer است.  

Figure 2: InternetExplorer CLSID

حالا باید Interface استفاده شده را پیدا کنیم. مانند بالاتر، چند کاراکتر اول را در  Registry → Interfaces سرچ می‌کنیم و IWebBrowser2 را مشاهده می‌کنیم.  

Figure 3: IWebBrowser2 IID

در نهایت، پارامتر آخر  CoCreateInstance را به IWebBrowser2 تغییر می‌دهیم[۸]. برای انجام این کار در IDA از set lvar type (کلید y) استفاده می‌کنیم.

Figure 4: IDA Pro - Type Declaration

بعد از آن، بدافزار از Navigate2 و get_outerText  برای گرفتن دیتای مورد نیازش استفاده می‌کند.

IE COM for C2 and Operations Security (OPSEC)[۹] Improvement

این کار یک مشکل جدی دارد. در history مرورگر، URL مورد استفاده توسط بدافزار وجود دارد. می‌توانیم از اینترفیس IUrlHistoryStg2  استفاده کنیم. این interface دارای یک متد به اسم ClearHistory است و اجازه می‌دهد تمام historyهای مرورگر را پاک کنیم.[۱۰]

Figure 5: C++ Implementation for Red Team Engagement

IE COM for Bypassing Parent/Child Relationship-Based Detection

یکی دیگر از راه‌هایی که محصولات امنیتی رفتار مخرب را شناسایی می‌کنند، بررسی رابطه parent/child پروسس‌ها است. به طور مثال اگر powershell توسط ورد/اکسل spawn  شود، رفتاری مخرب در نظر گرفته می‌شود. به این علت که در اینجا از COM استفاده می‌کنیم، parent process ما svchost است  و می‌توانیم از این روش برای بایپس استفاده کنیم.

Figure 6: IE COM - Parent Process

Office ASR Rule Bypass with IE COM

در مواقعی که سیستم با استفاده از ASR (Attack Surface Reduction) کانفیگ شده باشد، این تکنیک می‌تواند موثر واقع شود. معمولا برای جلوگیری از فیشینگ‌هایی که با استفاده از office – مثل ورد/اکسل – اتفاق می افتند، از ASR برای جلوگیری از inject کردن code به پروسس دیگر یا به وجود آوردن پروسه child استفاده می‌شود.

Figure 7: ASR Rule - Block Office Applications From Injecting Code Into Other Processes

Figure 8: ASR Rule - Block All Office Applications From Creating Child Processes

در این مواقع می‌توان از IE COM برای بایپس استفاده کرد.

IE COM Detection

برای تشخیص این متد، می‌توان پروسس‌هایی که ieproxy.dll را لود می‌کنند و اسم آن ها iexplorer.exe نیست را مانیتور کرد. با استفاده از Event ID 7 در Sysmon می‌توانیم این کار را انجام دهیم.

Figure 9 - Sysmon - Detection

Elastic هم، یک rule برای تشخیص این تکنیک فراهم کرده است. استفاده از این تکنیک به همراه Graph API پتاسیل بایپس کردن detection فراهم شده توسط elastic را دارد.

sequence by host.id, user.id with maxspan = 5s [library where dll.name : "IEProxy.dll" and process.name : ("rundll32.exe", "regsvr32.exe")] [process where event.type == "start" and process.parent.name : "iexplore.exe" and process.parent.args : "-Embedding"] /* IE started via COM in normal conditions makes few connections, mainly to Microsoft and OCSP related domains, add FPs here */ [network where network.protocol == "dns" and process.name : "iexplore.exe" and not dns.question.name : ( "*.microsoft.com", "*.digicert.com", "*.msocsp.com", "*.windowsupdate.com", "*.bing.com", "*.identrust.com", "*.sharepoint.com", "*.office365.com", "*.office.com" )

Figure 10 - Elastic Rule Query

APT15 usage of IE COM

APT15 که تمرکز آن بر روی نهاد های وابسته به حوزه دفاعی/نظامی و نهاد های دیپلماتیک است، از این تکنیک در بدافزارهایش استفاده می‌کند. منابع این مقاله: نویسنده‌ی این مقاله: «علی طباطبایی» پاورقی:

[۱] Class مجموعه‌ای از method هاست که در کنار attribute های مرتبط قرار گرفته‌اند.

[۲] CLSID (Class Identifier) یک GUID (Globally Unique Identifier) است.

[۳] Interface فقط از virtual function تشکیل شده است.

[۴] Interface Identifier

[۵] به این علت که می‌شود Host header را تغییر داد، از این COM Object می‌توان برای Domain Fronting استفاده کرد.

[۶] Valid TLS Certificate یا HTTP

[۷] CoCreateInstance در‌واقع یک Wrapper برای CoGetClassObject و IClassFactory است.

[۸] در‌واقع می‌توانید مستقیم Interface را پیدا کنید و این تغییرات را انجام دهید. نیازی به بررسی CLSID در بیشتر مواقع نیست.

[۹] احتمالاً بعضی از خواننده‌ها می‌گویند Operational Security (OPSEC) درست هست. در واقع این پروسه توسط آمریکا در 1966 به وجود آمده است و Operations Security نامیده می‌شود. پیشنهاد می‌شود این پست را درباره OPSEC بخوانید.

[۱۰] همچنین می‌توانید از متد DeleteUrl در اینترفیس IUrlHistoryStg استفاده کنید.