IPImen ، Firewall ، NGFirewall-UTM، آیپی ایمن، فایروال ایرانی ، فایروال بومی، یوتی ام بومی، یوتی ام ایرانی، فایروال نسل بعدی ایرانی، فایروال نسل بعدی بومی

پژوهشگران امنیت سایبری از یک تکنیک پس از نفوذ (Post-Exploitation) پرده برداشته‌اند که می‌تواند با فعال‌سازی داخلی Chrome DevTools Protocol یا CDP در یک نمونه در حال اجرای Google Chrome یا Microsoft Edge، کنترل گسترده‌ای بر نشست احراز‌شده کاربر ایجاد کند.

این تکنیک که توسط شرکت SpecterOps بررسی شده، به مهاجم اجازه می‌دهد پس از آنکه به هر نحوی روی یک سیستم ویندوزی کد اجرا کرد، از مرورگر در حال اجرای قربانی برای دسترسی به کوکی‌ها، داده‌های مرورگر، اطلاعات احراز هویت و حتی نشست‌های فعال استفاده کند.

نکته مهم این است که این روش یک آسیب‌پذیری جدید در Chrome یا Edge محسوب نمی‌شود و برای اجرای آن، مهاجم باید پیش از هر چیز به سیستم قربانی نفوذ کرده و توانایی اجرای کد روی دستگاه را به دست آورده باشد. با این حال، این تکنیک می‌تواند مرحله پس از نفوذ را به‌طور قابل توجهی خطرناک‌تر کند، زیرا مهاجم به‌جای استخراج مستقیم داده‌های مرورگر از روی دیسک، می‌تواند از خود مرورگر احراز‌شده برای انجام عملیات استفاده کند.

Chrome DevTools Protocol چیست؟

Chrome DevTools Protocol یا CDP رابطی است که برای کنترل و اشکال‌زدایی مرورگرهای مبتنی بر Chromium طراحی شده است.

این پروتکل به ابزارهای توسعه‌دهندگان اجازه می‌دهد به بخش‌های مختلف مرورگر دسترسی داشته باشند و عملیاتی مانند مشاهده صفحات، اجرای JavaScript، مدیریت تب‌ها، دریافت اطلاعات ذخیره‌شده و کنترل رفتار مرورگر را انجام دهند.

در حالت عادی، قابلیت‌های Remote Debugging باید برای اهداف توسعه و تست استفاده شوند. مشکل زمانی ایجاد می‌شود که یک مهاجم بتواند این قابلیت را درون همان پردازش مرورگری که کاربر در حال استفاده از آن است فعال کند.

در این حالت، مهاجم دیگر صرفاً با یک مرورگر جدید و محیط جداگانه روبه‌رو نیست؛ بلکه می‌تواند به همان محیطی متصل شود که کاربر قبلاً در آن وارد حساب‌های مختلف شده است.

تفاوت مهم با حملات قدیمی سرقت کوکی

اهمیت این روش زمانی بیشتر مشخص می‌شود که آن را با تغییرات امنیتی اخیر Chrome مقایسه کنیم.

گوگل از Chrome 136 رفتار Remote Debugging را تغییر داد. این مرورگر دیگر سوئیچ‌های --remote-debugging-port و --remote-debugging-pipe را هنگامی که به پوشه پیش‌فرض داده‌های Chrome اشاره می‌کنند، نادیده می‌گیرد؛ مگر اینکه از یک --user-data-dir غیرپیش‌فرض استفاده شود.

این تغییر پس از افزایش استفاده مهاجمان از Remote Debugging برای استخراج کوکی‌ها و در شرایطی که App-Bound Encryption نیز برای محافظت از داده‌های حساس مرورگر معرفی شده بود، انجام شد.

هدف این تغییر آن بود که مهاجم نتواند صرفاً با اجرای Chrome با یک گزینه خط فرمان، به داده‌های پروفایل اصلی کاربر دسترسی پیدا کند.

اما تکنیک جدید SpecterOps مسیر متفاوتی را دنبال می‌کند.

به‌جای اجرای یک نمونه جدید از Chrome با تنظیمات Debugging، این روش CDP را از داخل همان پردازش فعال Chrome یا Edge راه‌اندازی می‌کند.

فعال‌سازی CDP داخل پردازش مرورگر

ابزار مورد بررسی SpecterOps با نام CDP-Enable-BOF یک فایل Beacon Object File است که برای فعال کردن سرور DevTools در یک پردازش در حال اجرای Chrome یا Edge طراحی شده است.

در سطح کلی، ابزار ابتدا پردازش مناسب مرورگر را پیدا می‌کند و سپس ماژول chrome.dll یا msedge.dll را در حافظه شناسایی می‌کند.

پس از آن، با استفاده از الگوهای باینری و Symbolهای داخلی Chromium، مسیر لازم برای فراخوانی تابع داخلی مربوط به فعال‌سازی Remote Debugging را پیدا می‌کند.

این ابزار در ادامه حافظه‌ای را در پردازش هدف اختصاص داده و کدهای مورد نیاز خود را در آن قرار می‌دهد.

یکی از بخش‌های مهم این روش، اجرای فراخوانی نهایی روی Thread رابط کاربری مرورگر است. طبق توضیحات SpecterOps، این کار برای افزایش قابلیت اطمینان تکنیک در محیط‌هایی که مکانیزم‌هایی مانند Control Flow Guard، TLS و Control-flow Enforcement Technology فعال هستند، انجام می‌شود.

در نتیجه، سرور CDP بدون آنکه مهاجم مجبور باشد یک نمونه جدید از مرورگر با پروفایل جداگانه ایجاد کند، در همان پردازش موجود فعال می‌شود.

چرا این روش برای مهاجم جذاب است؟

مهم‌ترین مزیت این تکنیک این است که مرورگر از قبل توسط کاربر احراز هویت شده است.

کاربر ممکن است هم‌زمان در Microsoft 365، Gmail، Slack، GitHub، سامانه‌های سازمانی و ده‌ها سرویس دیگر وارد حساب خود شده باشد.

اگر مهاجم بتواند از طریق CDP به همان Browser Context دسترسی پیدا کند، دیگر لزوماً نیازی ندارد رمز عبور همه این سرویس‌ها را سرقت کند.

در بسیاری از موارد، مرورگر خودش وضعیت احراز هویت را در اختیار دارد.

به همین دلیل، حمله می‌تواند از «سرقت اطلاعات مرورگر» به «استفاده از مرورگر قربانی به‌عنوان یک عامل احراز هویت» تبدیل شود.

سرقت Cookie بدون خواندن فایل پایگاه داده

یکی از قابلیت‌های مورد استفاده در این تکنیک، API مربوط به Storage است.

ابزار CDP می‌تواند از Storage.getCookies برای درخواست وضعیت Cookieهای مرورگر استفاده کند.

در نتیجه، مهاجم می‌تواند بدون آنکه مستقیماً فایل پایگاه داده Cookieهای Chrome را از روی دیسک استخراج کند، اطلاعات Cookie را از خود Browser Context دریافت کند.

این تفاوت مهم است، زیرا برخی از مکانیزم‌های حفاظتی جدید مرورگرها با هدف جلوگیری از استخراج مستقیم اطلاعات حساس از فایل‌های محلی طراحی شده‌اند.

در این سناریو، مهاجم از مسیر دیگری استفاده می‌کند: از مرورگر می‌خواهد اطلاعاتی را که خودش در اختیار دارد ارائه کند.

دسترسی به داده‌های مختلف مرورگر

SpecterOps نشان داده است که پس از برقراری ارتباط با CDP، طیف قابل توجهی از داده‌های مرورگر می‌تواند در دسترس قرار گیرد.

این موارد شامل:

• Cookieها
• History
• Bookmarkها
• Extensionهای نصب‌شده
• Screenshot از صفحات
• اطلاعات مربوط به Passwordهای ذخیره‌شده
• داده‌های Browser Storage
• وضعیت احراز هویت سرویس‌های مختلف

است.

البته میزان دسترسی دقیق به شرایط محیط، نسخه مرورگر و مجوزهای موجود بستگی دارد.

حتی Passwordهای ذخیره‌شده نیز می‌توانند هدف قرار بگیرند

یکی از بخش‌های قابل توجه این تکنیک، سوءاستفاده از قابلیت Autofill مرورگر است.

به‌جای تلاش برای خواندن مستقیم پایگاه داده Password Manager، ابزار می‌تواند فرآیند Autofill مرورگر را در یک Origin منطبق فعال کند و سپس مقادیر Username و Password واردشده در فیلدهای صفحه را از طریق CDP دریافت کند.

این موضوع نشان می‌دهد که حتی زمانی که Passwordها در حالت عادی به‌صورت رمزنگاری‌شده روی سیستم نگهداری می‌شوند، دسترسی به محیط اجرای مرورگر می‌تواند مسیر متفاوتی برای استفاده از آن‌ها ایجاد کند.

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

تبدیل مرورگر قربانی به یک Proxy برای حمله

یکی دیگر از قابلیت‌های مهم، استفاده از مرورگر قربانی برای ارسال درخواست‌های HTTP و HTTPS است.

در این حالت، مهاجم می‌تواند درخواست‌ها را از طریق Browser Target ایجاد کند.

مزیت این روش برای مهاجم این است که درخواست‌ها از محیط مرورگر قربانی خارج می‌شوند و Cookieها و وضعیت احراز هویت موجود در همان Browser Context می‌توانند در درخواست‌ها مورد استفاده قرار گیرند.

در نتیجه، مهاجم می‌تواند به سرویس‌هایی دسترسی پیدا کند که قربانی قبلاً در آن‌ها احراز هویت کرده است، بدون اینکه الزاماً همان نشست را روی دستگاه خودش بازسازی کند.

این قابلیت عملاً مرورگر را به یک نقطه واسط برای دسترسی به سرویس‌های مورد اعتماد تبدیل می‌کند.

کنترل تعاملی مرورگر

CDP تنها برای استخراج اطلاعات استفاده نمی‌شود.

SpecterOps نشان داده است که می‌توان از Browser Target برای ایجاد یک محیط تعاملی و حتی Screencasting استفاده کرد.

در چنین شرایطی، فعالیت‌های مرورگر، Cookieها، Storage، وضعیت احراز هویت، WebAuthn و رفتار JavaScript همچنان در همان نمونه Chrome یا Edge قربانی باقی می‌مانند.

این موضوع از نظر دفاعی اهمیت زیادی دارد، زیرا مهاجم می‌تواند به‌جای انتقال تمام داده‌های احراز هویت به سیستم خودش، عملیات را در همان مرورگر قربانی انجام دهد.

به عبارت ساده‌تر، مهاجم به‌جای اینکه بگوید «اطلاعات ورود را برای من بفرست»، می‌تواند از مرورگر قربانی بخواهد «خودت این درخواست احراز‌شده را ارسال کن».

App-Bound Encryption جلوی همه سناریوها را نمی‌گیرد

Chrome در سال‌های اخیر مکانیزم‌های مختلفی برای دشوارتر کردن سرقت Cookie و داده‌های احراز هویت معرفی کرده است.

یکی از آن‌ها App-Bound Encryption است که با هدف محدود کردن امکان سرقت داده‌های رمزنگاری‌شده مرورگر توسط بدافزار طراحی شده است.

اما تکنیک CDP-Enable-BOF الزاماً تلاش نمی‌کند کلیدهای رمزنگاری یا فایل‌های رمزنگاری‌شده را استخراج کند.

در عوض، مهاجم از خود مرورگر در حال اجرا استفاده می‌کند.

این تفاوت معماری بسیار مهم است: اگر اطلاعات حساس در داخل یک برنامه مورد اعتماد قابل استفاده باشد، مهاجمی که بتواند کنترل کافی روی همان برنامه به دست آورد ممکن است بتواند از آن اطلاعات بدون نیاز به شکستن رمزنگاری استفاده کند.

Device Bound Session Credentials چه می‌شود؟

گوگل قابلیت دیگری به نام Device Bound Session Credentials یا DBSC را نیز برای کاهش خطر سرقت و استفاده مجدد از Session Cookieها معرفی کرده است.

DBSC برای اتصال Refresh شدن نشست به یک کلید سخت‌افزاری طراحی شده و در نسخه‌های جدید Chrome روی ویندوز در دسترس قرار گرفته است.

اما SpecterOps کلید خصوصی مربوط به DBSC را استخراج نمی‌کند.

در عوض، مهاجم با استفاده از Browser Context احراز‌شده روی همان دستگاه، عملیات خود را از طریق مرورگر قربانی انجام می‌دهد.

بنابراین این تکنیک را نباید صرفاً به‌عنوان یک روش جدید برای «دزدیدن Cookie» در نظر گرفت؛ بلکه مسئله اصلی، سوءاستفاده از یک نشست احراز‌شده و فعال روی Endpoint آلوده است.

این تکنیک به آسیب‌پذیری Chrome نیاز ندارد

یکی از مهم‌ترین نکات این گزارش آن است که Chrome یا Edge برای اجرای این حمله لزوماً آسیب‌پذیر نیستند.

مهاجم باید ابتدا به سیستم قربانی دسترسی پیدا کرده و امکان اجرای کد داشته باشد.

بنابراین مسیر کلی حمله را می‌توان به این شکل خلاصه کرد:

نفوذ اولیه → اجرای کد روی ویندوز → دستکاری پردازش Chrome/Edge → فعال‌سازی CDP → دسترسی به Browser Context → سوءاستفاده از نشست‌های احراز‌شده

به همین دلیل، تکنیک مذکور بیشتر یک ابزار Post-Exploitation محسوب می‌شود تا یک Browser Exploit مستقل.

این تفاوت برای تیم‌های امنیتی اهمیت زیادی دارد؛ زیرا صرفاً به‌روزرسانی Chrome یا Edge الزاماً این زنجیره را متوقف نمی‌کند.

شناسایی حمله چگونه ممکن است؟

SpecterOps و منابع مرتبط پیشنهاد کرده‌اند که تیم‌های دفاعی رفتار پردازش‌های Chrome و Edge را با دقت بیشتری بررسی کنند.

یکی از شاخص‌های مهم، تلاش یک پردازش غیرعادی برای دسترسی یا تزریق کد به chrome.exe یا msedge.exe است.

در Windows Sysmon، رویدادهای زیر می‌توانند برای شکار چنین فعالیت‌هایی مورد استفاده قرار گیرند:

• Event ID 8 – CreateRemoteThread
• Event ID 10 – ProcessAccess

Event ID 8 می‌تواند نشانه‌ای از Code Injection باشد و Event ID 10 نیز زمانی ثبت می‌شود که یک پردازش به پردازش دیگری دسترسی پیدا می‌کند.

البته این رویدادها به‌تنهایی نشان‌دهنده حمله نیستند و در محیط‌هایی که ابزارهای Automation، مدیریت Endpoint یا نرم‌افزارهای سازمانی با مرورگر تعامل دارند، می‌توانند رویدادهای مشروع زیادی ایجاد کنند.

به همین دلیل، باید Parent Process، Command Line، User Context، زمان اجرا و ارتباطات شبکه نیز در کنار این Eventها بررسی شوند.

نسخه مرورگر اهمیت دارد

یکی دیگر از نکات قابل توجه، وابستگی تکنیک به نسخه مرورگر است.

مخزن عمومی ابزار در زمان بررسی، Chrome نسخه 147.0.7727.102 و Edge نسخه 147.0.3912.98 را به‌عنوان نسخه‌های آزمایش‌شده معرفی کرده و Signatureهای مورد استفاده برای شناسایی Symbolهای داخلی نیز به نسخه مرورگر وابسته هستند.

به همین دلیل، به‌روزرسانی مرورگر می‌تواند باعث شود Signatureهای موجود دیگر به‌درستی عمل نکنند.

با این حال، وجود اسکریپت‌هایی برای تولید Signatureهای جدید نشان می‌دهد که تغییر نسخه مرورگر الزاماً به معنای حذف دائمی تکنیک نیست.

این روش چه تفاوتی با یک سرقت ساده Cookie دارد؟

تفاوت اصلی در این است که در سرقت سنتی Cookie، مهاجم تلاش می‌کند داده احراز هویت را از سیستم قربانی استخراج کرده و سپس روی دستگاه خودش استفاده کند.

اما در این تکنیک، مهاجم می‌تواند Browser Context قربانی را مستقیماً کنترل کند.

این مسئله در برابر مکانیزم‌هایی که برای جلوگیری از Replay شدن Credential روی یک دستگاه دیگر طراحی شده‌اند، اهمیت ویژه‌ای دارد.

در چنین شرایطی، مهاجم ممکن است اصلاً نیازی به انتقال Credential به سیستم خودش نداشته باشد.

او می‌تواند همان مرورگر روی همان Endpoint را وادار کند درخواست را ارسال کند.

پیشینه استفاده مهاجمان از CDP

استفاده مخرب از Chrome DevTools Protocol موضوع جدیدی نیست.

گوگل در سال ۲۰۲۵ نیز درباره افزایش استفاده مهاجمان از Remote Debugging برای استخراج Cookieها هشدار داده بود.

پژوهش‌های قبلی نیز نشان داده بودند که امکان تزریق CDP به یک نمونه در حال اجرای Edge وجود دارد.

تکنیک جدید SpecterOps این مسیر را یک گام جلوتر می‌برد و نشان می‌دهد چگونه می‌توان CDP را مستقیماً در پردازش موجود مرورگر فعال کرد تا از Browser Context فعلی استفاده شود.

ارتباط این تکنیک با بدافزارهای مدرن

این روش همچنین نشان‌دهنده یک روند مهم در حملات Endpoint است.

مهاجمان به‌طور فزاینده‌ای تلاش می‌کنند به‌جای ایجاد ارتباطات شبکه‌ای کاملاً جدید، از برنامه‌های مورد اعتماد نصب‌شده روی سیستم قربانی برای اجرای عملیات خود استفاده کنند.

در چنین رویکردی، Browser می‌تواند به یک ابزار Living-off-the-Land تبدیل شود.

این مسئله قبلاً نیز در حملات مختلف مشاهده شده است؛ برای مثال، گروه Chaos در نمونه‌ای از بدافزار msaRAT از Chrome و Edge در حالت Headless و CDP برای انتقال ارتباطات C2 استفاده کرده بود. در آن حمله نیز ارتباطات خارجی از طریق مرورگر انجام می‌شد و بدافزار تلاش می‌کرد ترافیک خود را در میان ارتباطات مشروع مرورگر پنهان کند.

جمع‌بندی

تکنیک جدید SpecterOps یک آسیب‌پذیری Remote Code Execution در Chrome یا Edge نیست، اما نشان می‌دهد پس از نفوذ به یک سیستم ویندوزی، مرورگر احراز‌شده کاربر می‌تواند به یک هدف بسیار ارزشمند تبدیل شود.

فعال‌سازی Chrome DevTools Protocol در پردازش موجود مرورگر می‌تواند به مهاجم امکان دهد Cookieها، داده‌های مرورگر، اطلاعات مربوط به Passwordها و نشست‌های احراز‌شده را هدف قرار دهد و حتی درخواست‌های اینترنتی را از طریق Browser Context قربانی ارسال کند.

از نگاه دفاعی، این یافته یک پیام مهم دارد: امنیت مرورگر تنها به جلوگیری از Exploitهای مرورگر محدود نمی‌شود؛ سلامت پردازش مرورگر و رفتار سایر پردازش‌هایی که با آن تعامل دارند نیز باید تحت نظارت باشد.

برای تیم‌های امنیتی، نظارت بر Process Injection، دسترسی غیرعادی به chrome.exe و msedge.exe، فعال شدن Remote Debugging، Command Lineهای غیرمعمول و ارتباطات شبکه‌ای ناشی از مرورگر می‌تواند به شناسایی چنین فعالیت‌هایی در مرحله Post-Exploitation کمک کند.