Reverse Shell — شل معکوس

Reverse Shell چیست و چرا هدف مهاجم است؟

پوسته‌ی معکوس (Reverse Shell) یعنی اجرای یک فرمان روی سرورِ در معرض خطر که باعث می‌شود خودِ سرور یک اتصال شبکه‌ای به سمت ماشینِ مهاجم برقرار کند و ورودی/خروجی یک پوسته‌ی فرمان را روی آن اتصال بفرستد. این با پوسته‌ی مستقیم (Bind Shell) فرق دارد؛ در پوسته‌ی مستقیم مهاجم به سرور وصل می‌شود، اما فایروال‌ها معمولاً اتصال ورودی را می‌بندند. پوسته‌ی معکوس دقیقاً برای دور زدن همین محدودیت طراحی شده: اتصالِ خروجی اغلب باز است.

در زنجیره‌ی حمله، پوسته‌ی معکوس معمولاً گامِ بلافاصله پس از RCE است. مهاجم با یک آسیب‌پذیری کد اجرا می‌کند، اما یک اجرای تک‌دستوری ناکارآمد است؛ او یک پوسته‌ی تعاملی می‌خواهد تا کاوش کند، امتیاز بالا ببرد و حرکت جانبی کند. این صفحه با نگاهِ مدافع نوشته شده: هدف، شناختِ رفتار برای تشخیص است، نه آموزش حمله.

روی شبکه چه شکلی دارد

پوسته‌ی معکوس چند اثر مشخص روی شبکه می‌گذارد که همگی قابل تشخیص‌اند:

• اتصال خروجیِ غیرمنتظره از سمت سرور: یک وب‌سرور که وظیفه‌اش پاسخ به درخواست است، معمولاً نباید خودش اتصال خروجی به یک IP ناشناس روی پورت دلخواه بزند.
• پورت یا مقصد غیرعادی: اتصال به پورت‌های نامتعارف، یا به یک IP بدون سابقه‌ی ارتباطی.
• ترافیک تعاملیِ پایدار: برخلاف درخواست‌های کوتاه HTTP، یک پوسته اتصال طولانی و دوطرفه دارد.
• الگوهای فرار: مهاجمان غالباً پوسته را روی پورت‌های رایج مثل 443 یا داخل تونل DNS/HTTPS پنهان می‌کنند تا شبیه ترافیک عادی شوند.

چطور مدافعان تشخیص و مسدود می‌کنند

دفاع در چند لایه:

• فیلتر خروجی (Egress Filtering): مهم‌ترین اقدام. سرورها فقط باید به مقصدها و پورت‌های مشخصِ لازم اتصال خروجی بزنند؛ همه‌چیز دیگر مسدود. این به‌تنهایی بسیاری از پوسته‌های ساده را از کار می‌اندازد.
• پایش DNS: پوسته‌ها و کانال‌های فرمان‌ودهیِ مبتنی بر DNS، پرس‌وجوهای غیرعادی تولید می‌کنند؛ رصد دامنه‌های تازه‌ثبت و حجم بالای پرس‌وجو به یک دامنه، نشانه‌ی قوی است.
• EDR روی میزبان: ابزار تشخیص و پاسخِ نقطه‌ی پایانی، ایجادِ فرزندِ پوسته توسط فرایند وب‌سرور (مثلاً وب‌سرور که bash یا cmd صدا می‌زند) را به‌عنوان رفتار مشکوک علامت می‌زند.
• تحلیل ترافیک: با ابزارهایی مثل Wireshark یا NDR می‌توان اتصال‌های تعاملیِ طولانی و ناهمخوان با نقشِ سرور را شناسایی کرد.
• ثبت و هشدار: این همان دسته‌ی A09:2025 (ثبت رخداد و هشداردهی) است؛ بدون لاگ خروجی، پوسته‌ی معکوس نامرئی می‌ماند.

سناریوی واقعی

یک برنامه‌ی PHP آپلود فایل بدون اعتبارسنجی دارد. مهاجم یک وب‌شل آپلود می‌کند و از راه آن یک پوسته‌ی معکوس اجرا می‌کند تا سرور به سمت او وصل شود. اما تیم امنیت، فیلتر خروجی روی لایه‌ی برنامه دارد: سرور اجازه‌ی اتصال خروجی جز به چند سرویس داخلی مشخص را ندارد. اتصالِ پوسته در فایروال خروجی مسدود و یک هشدار تولید می‌شود. EDR هم‌زمان می‌بیند که فرایند PHP یک پوسته را spawn کرده و رخداد را بالا می‌برد. همان آپلودِ آسیب‌پذیر باید در کد رفع شود، اما دفاع لایه‌ای، حمله را در همان گام مهار کرد.

نمونه‌ی فنی (شکل حداقلی)

برای درک مدافع، تنها شکلِ مفهومی و حداقلی را نشان می‌دهیم — نه فهرستی از بارِ آماده‌ی اجرا. سمتِ شنونده‌ی مدافع/تستر معمولاً چنین است:

# listener (سمت تستر مجاز)
nc -lvnp 4444

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

ارتباط با OWASP و چارچوب دفاعی

پوسته‌ی معکوس یک آسیب‌پذیری نیست، یک تکنیک پساـبهره‌برداری است؛ بنابراین جایی در فهرست OWASP ندارد اما به چند دسته گره می‌خورد: آسیب‌پذیریِ اولیه معمولاً از A05 (تزریق) یا A08 (نقص یکپارچگی/Deserialization) می‌آید، و تشخیصش مستقیماً به A09:2025 (ثبت رخداد و هشداردهی) بستگی دارد. در چارچوب MITRE ATT&CK این رفتار زیر تاکتیک‌های Command and Control و Execution قرار می‌گیرد.

پرسش‌های متداول