کد خبر: ۱۱۵۳

۰۹:۱۳

۱۴۰۵/۰۷/۰۴

هکرها دوباره سراغ Oracle PeopleSoft رفتند؛ ShinyHunters چگونه از WAF عبور کرد؟

ShinyHunters دوباره از آسیب‌پذیری CVE-2026-35273 در Oracle PeopleSoft سوءاستفاده کرده و با تغییر شکل درخواست، برخی Ruleهای WAF را دور زده است.

نویسنده:

بهراد یوسفی

در این مقاله می‌خوانید

حمله جدید ShinyHunters به PeopleSoft چیست؟
CVE-2026-35273 چه خطری دارد؟
مهاجمان چگونه WAF را دور زدند؟
بعد از نفوذ چه ابزارهایی مستقر شد؟
SIDEEYE چیست؟
ادعای نفوذ به FBI چه ارتباطی با این ماجرا دارد؟
سازمان‌های استفاده‌کننده از PeopleSoft چه اقداماتی باید انجام دهند؟

حمله جدید ShinyHunters به Oracle PeopleSoft چیست؟

بر اساس گزارش تازه Mandiant و Google Threat Intelligence Group در ۲۵ سپتامبر ۲۰۲۶، گروه منتسب به UNC6240 / ShinyHunters بار دیگر از آسیب‌پذیری CVE-2026-35273 در Oracle PeopleSoft سوءاستفاده کرده است.

تفاوت مهم این کمپین با حملات قبلی، تغییر در شیوه ارسال درخواست برای عبور از برخی کنترل‌های دفاعی، به‌ویژه Ruleهای مبتنی بر مسیر در Web Application Firewall یا WAF است.

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

CVE-2026-35273 چیست؟

CVE-2026-35273 یک آسیب‌پذیری بحرانی در بخش Environment Management Hub یا PSEMHUB در Oracle PeopleSoft است.

این نقص در کمپین اولیه امکان Remote Code Execution یا RCE را فراهم می‌کرد و مهاجم می‌توانست بدون احراز هویت مناسب، کد دلخواه خود را روی سامانه آسیب‌پذیر اجرا کند.

طبق گزارش Mandiant، فعالیت مهاجمان در کمپین اولیه بین ۲۷ مه تا ۹ ژوئن ۲۰۲۶ مشاهده شد و بیش از ۱۰۰ سازمان دارای Endpointهای بالقوه آسیب‌پذیر شناسایی و مطلع شدند.

چرا این CVE مهم است؟

چون یک آسیب‌پذیری RCE در یک سامانه سازمانی می‌تواند از یک نقص نرم‌افزاری به نقطه ورود مهاجم به زیرساخت سازمان تبدیل شود.

در چنین شرایطی، مسئله فقط اجرای یک دستور روی سرور نیست؛ مهاجم ممکن است پس از دسترسی اولیه به دنبال Web Shell، سرقت اعتبارنامه، تونل‌سازی، Persistence و حرکت جانبی باشد.

ShinyHunters چگونه WAF را دور زد؟

یکی از مهم‌ترین بخش‌های گزارش جدید، تغییر شکل درخواست برای عبور از برخی Ruleهای WAF است.

برخی سازمان‌ها پس از حملات قبلی، مسیر آسیب‌پذیر زیر را روی WAF مسدود کرده بودند:

/PSEMHUB/

اما مهاجمان در کمپین جدید یکی از حروف این مسیر را با URL Encoding جایگزین کردند:

/%50SEMHUB/

در URL Encoding، %50 معادل حرف P است.

بنابراین یک WAF ممکن است در مرحله بررسی اولیه، این درخواست را با رشته /PSEMHUB/ یکسان تشخیص ندهد؛ در حالی که Application Server پس از Decode کردن، آن را به مسیر اصلی هدایت می‌کند.

به زبان ساده

WAF:
«من دقیقاً /PSEMHUB/ را مسدود کرده‌ام.»

درخواست مهاجم:
/%50SEMHUB/

Application Server:
«بعد از Decode، این همان /PSEMHUB/ است.»

در نتیجه، یک Rule ساده مبتنی بر رشته ممکن است نتواند درخواست را متوقف کند.

WAF چرا جای Patch را نمی‌گیرد؟

این حادثه یک نکته مهم برای تیم‌های امنیتی دارد:

WAF جای Patch را نمی‌گیرد.

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

گزارش Mandiant نیز تأکید دارد که سازمان‌ها نباید Ruleهای WAF یا Path-based Blocking را جایگزین وصله امنیتی CVE-2026-35273 کنند.

بعد از نفوذ چه اتفاقی افتاد؟

بر اساس تحلیل Mandiant، عملیات پس از Exploit متوقف نشده است.

در برخی سیستم‌ها، مهاجمان:

Web Shellهای JSP مستقر کردند.
فایل‌های مخرب را در مسیر مربوط به PSEMHUB.war قرار دادند.
از Neo-reGeorg برای تونل‌سازی استفاده کردند.
فایل مخرب Ple64.exe را مستقر کردند.
از آن برای اجرای Backdoor موسوم به SIDEEYE استفاده کردند.
در برخی محیط‌ها از MeshCentral برای دسترسی و مدیریت از راه دور استفاده کردند.

این زنجیره نشان می‌دهد که Exploit اولیه می‌تواند به مرحله‌ای برای ایجاد دسترسی ماندگارتر و حرکت در شبکه داخلی تبدیل شود.

SIDEEYE چیست؟

SIDEEYE یک Backdoor مشاهده‌شده در این کمپین است.

طبق تحلیل Google/Mandiant، این بدافزار قابلیت‌هایی مانند موارد زیر دارد:

سرقت Credentialهای مرورگر و برنامه‌های دسکتاپ
مدیریت فایل
مدیریت Process
اجرای Shell تعاملی
Reverse Proxy

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

Neo-reGeorg چه نقشی دارد؟

Neo-reGeorg ابزاری برای Proxy کردن ترافیک از طریق ارتباطات HTTP/HTTPS است.

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

MeshCentral چرا مهم است؟

MeshCentral یک ابزار قانونی و متن‌باز برای مدیریت از راه دور سیستم‌هاست.

اما مانند سایر ابزارهای Remote Management، امکان سوءاستفاده از آن در عملیات مخرب نیز وجود دارد.

Mandiant مشاهده کرده که UNC6240 از MeshCentral برای حفظ دسترسی و مدیریت سیستم قربانی استفاده کرده است.

این موضوع نمونه‌ای از Living off the Land / Abuse of Legitimate Tools است؛ یعنی مهاجم همیشه به یک بدافزار ناشناخته احتیاج ندارد و می‌تواند از ابزارهای مشروع موجود در محیط استفاده کند.

آیا ShinyHunters واقعاً FBI را هک کرده است؟

هم‌زمان با گزارش جدید PeopleSoft، ادعای دیگری نیز درباره FBIJobs.gov مطرح شده است.

ShinyHunters مدعی شده که به سامانه مرتبط با FBIJobs.gov دسترسی پیدا کرده و اطلاعاتی از کارکنان و متقاضیان استخدام FBI را سرقت کرده است.

اما طبق اطلاعات موجود در گزارش، FBI این ادعا را تأیید نکرده و موضوع را در حال بررسی اعلام کرده است.

Reuters نیز گزارش کرده بخشی از فایل‌هایی که ShinyHunters به‌عنوان داده‌های سرقت‌شده معرفی کرده، با اطلاعات واقعی مطابقت داشته‌اند؛ اما این موضوع به‌تنهایی مسیر یا علت نفوذ را اثبات نمی‌کند.

ارتباط حمله PeopleSoft با ادعای نفوذ به FBI چیست؟

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

گزارش Mandiant درباره استفاده مجدد از CVE-2026-35273 در PeopleSoft است؛ در مقابل، موضوع FBIJobs.gov بر اساس ادعای ShinyHunters و بررسی FBI مطرح شده است.

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

این حمله چه درسی برای تیم‌های امنیتی دارد؟

۱. WAF را با Patch اشتباه نگیرید

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

۲. شکل‌های مختلف درخواست را بررسی کنید

در Threat Hunting نباید فقط دنبال رشته خام زیر بود:

/PSEMHUB/

بلکه نمونه‌های URL-encoded مانند:

/%50SEMHUB/

نیز باید در نظر گرفته شوند.

۳. Web Shellها را جدی بگیرید

وجود JSPهای غیرمنتظره در مسیرهای Application می‌تواند یک نشانه مهم برای بررسی Incident باشد.

۴. ابزارهای قانونی را هم پایش کنید

وجود MeshCentral یا سایر ابزارهای Remote Management لزوماً به معنی حمله نیست؛ اما استفاده غیرمنتظره یا خارج از الگوی معمول آنها می‌تواند نیازمند بررسی باشد.

۵. Credentialها را بررسی کنید

پس از Exploit موفق، باید بررسی شود مهاجم به چه Credentialهایی دسترسی پیدا کرده و آیا نیاز به Rotation آنها وجود دارد یا خیر.

اگر سازمانی Oracle PeopleSoft دارد، چه کار کند؟

اقدامات پیشنهادی بر اساس گزارش Mandiant:

وصله امنیتی Oracle مربوط به CVE-2026-35273 نصب شود.
صرفاً به WAF Rule اکتفا نشود.
در صورت امکان Environment Management Hub غیرفعال یا PSEMHUB حذف شود.
لاگ‌های WebLogic برای /PSEMHUB/ و نمونه‌های URL-encoded مانند /%50SEMHUB/ بررسی شوند.
فایل‌های JSP غیرمنتظره و فایل‌هایی مانند Ple64.exe در مسیرهای مرتبط بررسی شوند.
Credentialهای در دسترس حساب سرویس PeopleSoft بررسی و در صورت نیاز Rotate شوند.
ارتباطات خروجی غیرعادی و نشانه‌های استفاده از MeshCentral پایش شوند.

آیا این حمله مستقیماً به ایران مرتبط است؟

خیر.

در گزارش جدید Google/Mandiant ارتباط مستقیمی میان این کمپین و ایران یا یک سازمان ایرانی اعلام نشده است.

بنابراین این رویداد نباید به‌عنوان «حمله سایبری علیه ایران» معرفی شود.

اهمیت آن برای سازمان‌های ایرانی از منظر دیگری است: هر سازمانی که از نسخه آسیب‌پذیر Oracle PeopleSoft استفاده می‌کند باید بداند که WAF Rule به‌تنهایی جایگزین Patch نیست.

جمع‌بندی

بازگشت ShinyHunters به Oracle PeopleSoft نمونه‌ای از سازگاری مهاجم با کنترل‌های دفاعی سازمان‌هاست.

در حملات اولیه، CVE-2026-35273 امکان RCE را فراهم کرد. پس از ایجاد برخی Ruleهای دفاعی، مهاجمان با تغییر شکل درخواست و استفاده از URL Encoding تلاش کردند بخشی از این کنترل‌ها را دور بزنند.

پس از دسترسی نیز زنجیره حمله می‌تواند از Exploit به Web Shell، Tunnel، Remote Management و Backdoor گسترش پیدا کند.

اتاق تحلیل ۲۴ نیوز | دیدگاه تحلیلی بهراد یوسفی

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

وقتی سازمان یک مسیر مشخص را روی WAF مسدود می‌کند، مهاجم می‌تواند منطق همان دفاع را بررسی کرده و شکل درخواست را تغییر دهد. در اینجا URL Encoding تکنیک پیچیده‌ای نیست، اما تفاوت در نحوه پردازش درخواست میان WAF و Application Server می‌تواند یک کنترل امنیتی را کم‌اثر کند.

برای تیم‌های امنیتی، این حادثه یک اصل مهم را یادآوری می‌کند:

کاهش Exposure با حذف آسیب‌پذیری یکسان نیست.

WAF، EDR، SIEM و IDS باید در کنار Patch Management و Hardening عمل کنند، نه به جای آنها.

از طرف دیگر، زنجیره‌ای که از RCE به Web Shell، Tunnel، Remote Management و Backdoor می‌رسد نشان می‌دهد بررسی Incident نباید فقط به لحظه Exploit محدود شود. پس از شناسایی Exploit موفق، باید احتمال Persistence، Credential Access، Lateral Movement و Command & Control نیز بررسی شود.