چگونه در سال 2023 یک زیرساخت تیم قرمز بسازیم

چگونه در سال 2023 یک زیرساخت تیم قرمز بسازیم

مقدمه زیرساخت تیم قرمز

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

مبحث ساخت زیرساخت یک تیم قرمز چیز جدیدی نیست و مقالات زیادی در رابطه با این موضوع تهیه و منتشر شده اند؛ دراین مقاله سعی کرده‌ام به نقطه نظرات و چالش‌هایی که خودم در رابطه این مساله مواجه شده‌ام بپردازم، که امیدوارم به شما کمک کند تا تصمیمات بهتری بگیرید و از دام‌های بالقوه این مسیر آگاه باشید.

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

  • چه الزاماتی را باید درنظر بگیریم؟
  • زیرساخت تیم قرمز از چه کامپوننت هایی تشکیل شده است؟
  • از چه نرم افزارهایی می توان استفاده کرد؟
  • این کامپوننت ها چگونه راه اندازی می‌شوند؟

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

موارد موردنیاز

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

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

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

بررسی اجمالی کامپوننت ها

خب، چه مولفه هایی برای برآوردن این الزامات ذکر شده ضروری است؟ در نمودار زیر، شبکه‌ای که دربرگیرنده کامپوننت ها و اتصالات است به تصویر کشیده شده است.

نمای کلی شبکه نمونه

کامپوننت هایی که در ادامه آمده‌اند بخشی از زیرساخت هستند:

  • سرور پی‌لود / فیشینگ: برای ایجاد و اجرای کمپین‌های فیشینگ و ذخیره سازی کد های پی‌لود برای حمله مورد استفاده قرار می‌گیرد.
  • Server c2-Team-: مرکز ارتباطات و فرمان برای اپراتورهای تیم قرمز.
  • ریدایرکتورها: برای ترافیک ایمیل، HTTPs و DNS. سروری به عنوان پروکسی برای ترافیک و حفاظت از دارایی های هسته.
  • [اختیاری] Vaultwarden: یک راه حل امن برای ذخیره سازی داده در طول زمان تعامل را نشان می‌دهد، به عنوان مثال، برای اسناد محرمانه یا اطلاعات ورود به حساب جمع آوری شده.
  • [اختیاری] Red ELK: اساسا یک SOC به تیم‌های قرمز، در نظارت بر زیرساخت‌های شما و شناسایی تیم آبی که در اطراف دارایی‌های شما جاسوسی می‌کنند کمک می‌کند.

در ادامه به توضیح دقیق هریک از موارد گفته شده پرداخته ایم.

تفکیک شبکه

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

دارایی های اصلی مانند C2-team-server یا سرور فیشینگ و پی‌لود باید در یک شبکه محافظت شده یا داخلی چرخانده شوند. اگر قادر به وجود آوردن چنین شرایطی نیستید، حداقل باید از این نکته مطمئن شوید که پورت های باز این ماشین ها فقط در دسترس کاربران قانونی و مجاز باشند. این شرایط را می توان از طریق محدود کردن اتصالات به آدرس های IP یا گواهی های خاص انجام داد. علاوه براین پورت های ضروری مثل SSH یا VPN بایستی به صورت خارجی در دسترس قرار بگیرند.

ارائه دهندگان سرویس های ابری

دررابطه با انتخاب سرویس ابری، سرویس دهنده ای که با آن بیشتر احساس راحتی می‌کنید را انتخاب کنید. مثلا، می‌توانید برای ریدایرکتورها از AWS  استفاده کنید یا بخاطر اینکه پیاده سازی اپلیکیشن ها در Azure بسیار آسان است برای نمونه OutLook از Azure می‌تواند استفاده کنید. دراین راستا CloudFront یا Digital Ocean هم می توانند کاربردی باشند. نکته بسیار مهم این است که به ارائه‌دهنده اطلاع دهید که در حال اجرای یک عملیات تیم حرفه‌ای قرمز (قانونی) هستید، در غیر این صورت هر ارائه‌دهنده سرویس ابری دستگاه‌های شما را بدون اطلاع غیرفعال می‌کند.

زیرساخت – C2

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

سرور تیم C2

برای اپراتورهای تیم قرمز سرورهای نمونه-C2 به عنوان نقطه مرکزی اتصالات و فرمان عمل می‌کنند. ترافیک از این نقطه کنترل می‌شود، همچنین می‌توان آن را از نحوه برقراری ارتباط تا دستورات ارسالی برای اجرا در رایانه هدف تغییر داد. چارچوب های C2 همچنین طیف گسترده ای از ابزارهای یکپارچه را ارائه می دهند که به اجرای یک حمله موفق کمک می کنند.

تصمیم مهمی که باید گرفته شود این است که آیا می خواهید (یا بهتر بگوییم می توانید) هزینه یک C2 پولی را بپردازید یا خیر. برای تیم‌های قرمز برای سال‌های متمادی Cobalt Strike استاندارد صنعتی بود، اما در طول سال‌های اخیر گزینه‌های بسیار دیگری به وجود آمد که میتوانند جایگزین این استاندارد شوند. چارچوب‌های متن‌باز به‌ویژه برای عوامل تهدید از محبوبیت بیشتری برخوردار هستند. دلیل استفاده عوامل تهدید از این فریم ورک‌ها بسیارساده است: این C2 ها به اندازه Cobalt Strike یا سایر چارچوب های استاندارد صنعت پولی C2 گسترده نیستند و به علت اینکه رفتار آنها هنوز شناسایی نشده است، مکانیسم های دفاعی اغلب به راحتی قادر به گرفتن آنها نیستند. این حتی تا آنجا پیش رفت که درسال گذشته حتی Windows Defender موفق به گرفتن اولین پیلودهای تولید شده توسط Havoc نشد.

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

  • آیا قرار است برای یک C2 پول خرج کنم؟
  • به چه کانال های ارتباطی‌ای نیاز دارم؟
  • آیا به یک GUI نیاز دارم؟
  • آیا برای برقراری ارتباط با C2 به اپراتور نیاز دارم؟
  • برای راه اندازی C2 به چه سیستم عاملی نیاز دارم؟
  • به چه ویژگی های evasion  نیاز دارم؟

همچنین می توانید نگاهی به C2 Matrix بیندازید، اما توجه داشته باشید که ممکن است برخی از اطلاعات کاملا به روز نباشند. با این وجود، دید کلی خوبی از چارچوب های موجود C2 ارائه می دهد. هنگام تصمیم گیری برای یک چارچوب متن باز، همیشه آخرین نسخه ها را بررسی کنید تا مطمئن شوید که واقعا نسخه های به روز رسانی شده باشند. و از همه مهمتر، تست کنید و با C2 انتخابی خود بازی کنید. اگر نمی توانید تصمیم بگیرید، همیشه این گزینه وجود دارد که دو یا چند C2 را پیاده سازی کنید و از آنها به صورت موازی استفاده کنید.

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

زیرساخت تیم قرمز
مزایا و معایب Silver C2

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

ریدایرکتورهای-C2

ریدایرکتورها را می توان بر اساس ترافیکی که هدایت می کنند به انواع مختلفی تقسیم کرد که در ادامه به آنها پرداخته‌ایم:

  • ترافیک ایمیل (فیشینگ)
  • ترافیک HTTPS (کوتاه مدت)
  • ترافیک DNS (دراز مدت)

یک نمای کلی از ریدایرکتورهای مربوط به ترافیک C2 را می توانید در ادامه مشاهده کنید. ریدایرکتورهای ایمیل در پاراگراف بعدی پوشش داده خواهد شد.

زیرساخت تیم قرمز
نمای کلی ریدایرکتورهای ترافیک C2

وظایف اصلی یک ریدایرکتور محافظت از دارایی های اصلی مربوطه و پروکسی کردن تمام ترافیکی است که برای آن نمونه ها انتخاب شده و ارسال می شود (اینجا: سرور(های) تیم C2). اگر ترافیک یک beacon توسط تیم آبی هدف کشف شود، فقط IP یا دامنه ریدایرکتور از بین می رود. در این شرایط ریدایرکتور فقط باید تعویض شود، شاید حتی یک ریدایرکتور پشتیبان هم آنجا وجود داشته باشد. در نتیجه، به جای تنظیم مجدد کل زیرساخت، فقط ترافیک باید به یک ریدایرکتور دیگر هدایت شود. به دلیل وجود افزونگی دو کانال ترافیکی مختلف برای C2 وجود دارد. درصورت کشف شدن کانال HTTPS، هنوز کانال DNS موجود و در دسترس است. دراکثرشرکت ها، نظارتی روی ترافیک DNS وجود ندارد و بنابراین اغلب این ترافیک زیر رادار پرواز می کند:)

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

ریدایرکتور HTTPS

دو نوع رویکرد برای ریدایرکت برای ترافیک HTTPS وجود دارد. ترافیک را می توان از طریق یک گذرگاه ساده یا از طریق یک پروکسی وب معکوس هدایت کرد. اولین گزینه، که از طریق socat یا قانون جداول IP به دست می‌آید، به‌طور کورکورانه ترافیک ورودی را به یک پورت خاص هدایت می‌کند. این رویکرد اساسا عملکردی که انتظار می‌رود یک ریدایرکتور از خود نشان دهد را توصیف می کند. در مقابل، یک پروکسی وب معکوس امکان فیلتر کردن بازدیدکنندگان ناخواسته را بر اساس عواملی مانند موقعیت جغرافیایی یا عامل کاربر اضافه می کند. این ویژگی به شما امکان می دهد تا ترافیک پیلود را به سرور C2 خود هدایت کنید و به سایر بازدیدکنندگان یک وب سایت مشترک نشان دهید. این اصل در تصویر زیر نیز نشان داده شده است.

زیر
جریان ترافیک ریدایرکتور

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

ویژگی های نرم افزار

در مورد نرم افزار پروکسی، سه گزینه اصلی وجود دارد: Apache، Nginx یا Caddy. تمام این گزینه ها اپلیکیشن های منبع باز هستند. البته، در صورت داشتن شرایطی که قبلا ذکر شد، می توانید از وب سرور دیگری نیز استفاده کنید.

Apache و Nginx گزینه های شناخته شده ای هستند و آموزش های زیادی برای راه اندازی آنها موجود است. این گزینه ها تقریبا خارج از جعبه کار می کنند و ماژول های زیادی برای مسدود کردن مهمانان یا IP های ناخواسته بر اساس موقعیت جغرافیایی مربوطه دارند. همچنین، از آنجایی که این موارد به طور گسترده مورد استفاده قرار می گیرند، از نظر خود محصول تفاوت زیادی بین آنها وجود ندارد.

یک گزینه کمتر شناخته شده ‌ی مورد استفاده، Caddy است. من هنوز این اپلیکیشن را امتحان نکرده‌ام، اما نوید راه‌اندازی آسان با پشتیبانی خودکار HTTPS (از طریق ZeroSSL یا Let’s Encrypt) برای دامنه‌های عمومی را می‌دهد. همچنین یک مزیت بزرگ این اپلیکیشن این است که شما فقط به یک فایل به نام “Caddyfile” نیاز دارید که تمام تنظیمات را انجام می دهد. در Go نوشته شده است و وابستگی بیشتری ندارد. همچنین نشان داده شده است که Caddy می تواند به طور خاص به عنوان یک ریدایرکتور برای ترافیک C2 استفاده شود [2].

فرآیند راه‌اندازی/ مقاوم‌سازی

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

اول از همه، تمام ترافیک به و از طرف ریدایرکتور باید از طریق HTTPS رمزگذاری شود. در غیر این صورت، SOC به راحتی پیلود شما را انتخاب می کند، زیرا تمام داده های ارسال شده قابل خواندن هستند. از منظر OPSEC شما نمی خواهید یک اتصال رمزگذاری نشده به شبکه مشتری داشته باشید، زیرا هر کسی می تواند ترافیک را شنود کند. علاوه براین، ترافیک رمزگذاری نشده همیشه برجسته است زیرا می تواند نشانگر فعالیت مشکوک باشد.

چیزی که به نکته بعدی منتهی می شود: از گواهی نامه های self-sign استفاده نکنید. یک راه آسان برای تولید گواهی‌های معتبر، استفاده از Let’s Encrypt و دریافت گواهی‌های تولید خودکار برای دامنه است. همچنین می‌توانید این گواهی را خودتان تولید کنید یا از Certbot که یک وب سرور را در پورت 80:IP شما باز می‌کند، استفاده کنید (برای اطمینان از اینکه مالک دامنه قانونی هستید) و همه کارها را انجام می‌دهد. اگر سرویس دیگری (به عنوان مثال Nginx) را روی پورت 80 اجرا می کنید، این سرویس باید تا زمانی که Certbot در حال اجرا است متوقف شود. از آنجایی که گواهینامه‌های Let’s Encrypt رایگان هستند، افراد زیادی از آن‌ها استفاده می‌کنند – این آمار تعداد زیادی از افراد مشکوک و کلاهبردار را نیز دربرمی‌گیرد. در نتیجه، اگر از لحاظ مالی می توانید هزینه این گواهینامه ها را پرداخت کنید، برخی ازاین گواهینامه ها را از هر مرجع  دلخواهی خریداری کنید(شرکت یا مرجع آن زیاد مهم نیست).

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

اگر وقت دارید، قطعا باید یک وب سایت ساده، اما متقاعد کننده ایجاد کنید. این کار به شدت باعث افزایش اعتبار سایت شده و به پنهان کردن هدف واقعی وب سرور (به منظور تونل کردن ترافیک پیلود) کمک می کند.

برای مسدود کردن بازدیدکنندگان ناخواسته به تنظیمات خاص تر بپردازید. و بازدیدکنندهای مشکوک را به وب‌سایت دیگری (مانند google.com) هدایت می‌کند، این کار بسیار ساده است. 🙂

سخت ترین قسمت این مرحله، پنهان کردن ترافیک پیلود به C2 است. این بخش معمولا با ساختن کوئری پیلود یک دایرکتوری یا فایل خاص در وب سرور انجام می شود. سپس وب سرور تمام ترافیک را به سرور C2 ارسال می کند.

برای اینکه فقط ترافیک مورد نظر به سرور C2 برسد، بر اساس عوامل متعدد (مانند user-agent، آدرس IP یا دامنه در صورت وجود) یک لایه محدودیت و پاسخ دادن با کد خطا برای جستجوهایی که با الگوی مورد نیاز مطابقت ندارند، پیاده‌سازی می‌شود.

در این مثال من Nginx را به عنوان یک ریدایرکتور انتخاب کردم، از این رو در بخش های بعدی روی این ریدایرکتور کار کرده ایم. با این وجود، در Apache یا Caddy توابع مشابه وجود دارد.

برای Nginx هنگامی که مکان خاصی درخواست می شود، می توانید ویژگی proxy_pass  را تنظیم کنید. بر اساس مکان درخواستی می تواند به راحتی شناسایی شود به عنوان یک محدودیت، عامل دیگری مورد نیاز است. در این مثال، عامل کاربر خواهد بود. قطعه زیر از default.conf Nginx است.

# map useragents to proxypasses
map $http_user_agent $goodagent {                                                                                                                                        
    default 0;           
    "Supersecretuseragent" 1;
}

[...]

server {

[...]

# C2 route
  location /supersecretlocation/ {
      proxy_ssl_certificate /etc/nginx/https-cert.pem;
      proxy_ssl_certificate_key /etc/nginx/https-key.pem;
      proxy_ssl_verify off;
      proxy_ssl_server_name      on;
      proxy_set_header Host $host;
      proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
      proxy_pass https://localhost:5443;
      if ($goodagent = 0) {
      return 404;
 }
  }
 }

در مرحله اول، User-Agent مختلف باید دسته بندی شوند. همانطور که می بینید، متغیر $goodagent  برای هر عامل کاربری به غیر از Supersecretuseragent روی false  تنظیم شده است. در بلاک سرور، proxy_pass  برای supersecretlocation  مسیر تعریف شده است. این مسیری است که beacon  با عامل کاربر Supersecretuseragent درخواست خواهد کرد. خود پروکسی اتصال به https://localhost:5443 هدایت می شود. دلیل این امر، همانطور که در ادامه خواهید دید، این است که اتصال از C2 به ریدایرکتور، از طریق ssh و هدایت پورت از راه دور حل می شود. اگر درخواست همراه با یک عامل کاربر باشد که به عنوان $goodagent  دسته بندی نشده باشد، خطای 404 نمایش داده می شود.

بر اساس موقعیت های جغرافیایی محدودیت دیگری را می توان اعمال کرد. از این رو از پایگاه داده MaxMind استفاده می‌کنیم که آدرس های IP را به کشورها ترسیم می کند. در پیکربندی Nginx، این کشورها را می‌توان به پاسخ‌های سرور مختلف ارجاع و نسبت داد [3]. این فرآیند محدودیت مشابه محدودیت عوامل کاربر است.

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

  • از به روزبودن نسخه پیاده سازی شده مطمئن شوید.
  • تمام نمونه های نسخه های قبلی را حذف کنید.
  • کلمات عبور و نام های کاربری پیش فرض را تغییر دهید (درصورت امکان)
  • تمام فایل های غیرضروری را حذف کنید (مانند گزارش تغییرات، Publisher Notes و …)
  • تمام فراداده‌ها (metadata) را از فایل ها و رسانه ها حذف کنید
  • کامنت های کدها را پاک کنید
  • تمام داده های گواهی‌نامه ها را بررسی و پاک کنید

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

ریدایرکتور DNS

برای یک ریدایرکتور  DNS، هیچ سرویس DNS خاصی روی خود ریدایرکتور لازم نیست. از آنجایی که ترافیک فقط ارسال می شود و پردازش نمی شود، دو گزینه اصلی وجود دارد: socat یا iptables. Iptables ممکن است گزینه‌های بیشتری ارائه دهد، چراکه با آن می‌توانید محدوده IP ترافیک ورودی را مشخص کرده و قوانین ارسال را برای IPهایی که از آن محدوده نمی‌آیند پیاده‌سازی کنید. از سوی دیگر، راه اندازی socat کمی سریعتر و آسان تر است[4].

همچنین با نگاهی به اینکه سرور C2 شما چگونه درخواست‌های DNS را مدیریت می‌کند و اینکه آیا می‌توان از طریق آن انگشت نگاری کرد، نقش سودمندی ایفا می‌کند[5].

برای اینکه ریدایرکتور بتواند به درستی کار کند، چند مرحله دیگر باید طی شود. این مراحل بر اساس C2 مربوطه متفاوت است. اساسا، شما باید یک رکورد A و همچنین یک رکورد NS برای (زیر) دامنه ریدایرکتور خود ثبت کنید. برای Sliver یک آموزش جامع در ویکی رسمی وجود دارد [6].

زیرساخت پی‌لود/ فیشینگ

این بخش از زیرساخت از سه کامپوننت تشکیل شده است: سرور فیشینگ/پی‌لود کنونی، یک ریدایرکتور  Postfix و یک نمونه از Outlook درفضای ابری Azure. سرور فیشینگ/پی‌لود حاوی نرم افزار فیشینگ فعلی است و به عنوان ذخیره ساز برای پی‌لودهای مرحله 1 عمل می کند (پی‌لودهای طبقه بندی شده شامل یک قطعه کوچک کد، مرحله 0، که توسط هدف اجرا می شود و پی‌لود فعلی را بارگذاری می کند، است، پی‌لود مرحله 1 نامیده می‌شود). ریدایرکتور  Postfix برای تغییر یا حذف هدر نامه های مشکوک استفاده می شود و نمونه Outlook برای قابل اعتمادتر کردن نامه ها ضروری است. علاوه بر این، اگر پاسخی به نامه‌ها از طرف هدف ارسال شود، می‌توان ارتباط را از طرف صندوق ورودی Outlook انجام داد.

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

بازبینی کلی زیرساخت فیشینگ

سرور پی‌لود/فیشینگ

از نظر نرم‌افزار فیشینگ، Gophish سال‌هاست که به عنوان یک نرم افزار استاندارد شناخته شده است. این نرم افزار به ایجاد وب سایت های جعلی کمک می کند، می تواند بر کلیک ها نظارت کرده یا پیوندها را با شناسه شخصی سازی کند تا بتواند رفتار کاربران خاص را شناسایی کند. علاوه براین Gophish با یک وب سرور برای وب سایت های جعلی یا پی‌لودهای مرحله 1 ارائه می شود. بنابراین، اگر یک HTTPS-redirector در جلوی نمونه Gophish قرار بگیرد، می‌تواند به عنوان یک سرویس فیشینگ و بارگذاری ترکیبی استفاده شود. جدای از آن، GoPhish کار خود را به خوبی انجام می دهد. برخی از سفارشی‌سازی‌های کوچک OPSEC باید انجام شوند، به این دلیل که GoPhish فقط برای تعاملات فیشینگ طراحی شده است و هدرهای نه چندان مخفی حاوی مقادیر پیش‌فرض “gophish” را برای متمایز کردن آنها از ایمیل‌های فیشینگ واقعی پیاده‌سازی می‌کند. از آنجایی که این یک شاخص واضح برای مکانیسم های دفاعی است، این هدرها باید حذف شوند (این کار توسط ریدایرکتور  Postfix انجام می شود).

فرآیند راه‌اندازی

اول از همه، بایستی دامنه خود را روی یک سرویس DNS ثبت کنید و سپس تمام تنظیمات ضروری رکوردهای DNS را راه‌اندازی کنید. دراین مورد من از Route 53 استفاده کردم، چراکه با Terraform به راحتی قابل راه اندازی است، اما بازهم اشاره میکنم که هر سرویس DNS دیگری هم برای این کار مناسب است (مثل deSEC خود SSE ). رکوردهایی که در ادامه آمده باید تنظیم شوند: A، MX، SPF، DMARC، DKIM. اگر تا امروز اینکار را انجام نداده اید، اکنون یک لایسنس MS Office365 یا Outlook خریداری کنید. سپس نمونه Outlook را در Azure راه اندازی و مراحل زیر را برای اتصال کامپوننت‌ها دنبال کنید.

فرآیند استفاده از Office365 به عنوان یک رله SMTP در این لینک گام به گام توضیح داده شده است. درادامه این فرایند را به صورت مختصر و مفید جمع بندی و اطلاعات مربوط به فیشینگ را به آن اضافه کرده ایم. ابتدا، هاست  MS365 را پیاده سازی می‌کنیم. سپس، بایستی با Office365  یک باکس Azure راه اندازی کرده و برای یک حساب های کاربری احراز هویت SMTP را فعال سازی کنیم (حساب کاربری‌ای که از آن برای ارسال استفاده خواهید کرد).

سپس بایستی نمونه‌ی Postfix را روی سرور داخلی راه اندازی کنیم. پس از نصب این نمونه (در Ubuntu فقط کافیست دستور apt-get را اجرا کنید)، تعدادی فایل پیکربندی بایستی ایجاد و هش شوند. در حال حاضر، Gophish نمی داند که از ریدایرکتوراستفاده کرده ایم. این را می توان ازطریق “Sending Profiles” تغییر داد، که می توان آن را از طریق Gophish UI ایجاد و فقط باید مقادیر سرور Postfix خود را اضافه کنیم [7].

سپس، هدرهایی که Gophish به همراه یک ایمیل ارسال می کند را باید حذف کنیم، در غیر این صورت ایمیل های فیشینگ فورا توسط سرورهای ایمیل شناسایی و مسدود می شوند. تمیز کردن هدرهای نامه عمدتا با ادغام فایلی به نام “header_checks” در Postfix انجام می شود. این فایل به Postfix می گوید که چگونه هدرهای خاص را مدیریت کند. در مورد مثال ما، این به این معنی است که هدرهای خاصی را پیدا کنید، آنها را حذف یا مقادیرشان را بازنویسی کنید. به غیر از هدرهایی که حاوی IP و نام هاست یا دامنه شما هستند، فایل باید هدر “X-Mailer” نیز داشته باشد، زیرا مخصوص Gophish است و یک نشانگر واضح برای فیشینگ است. علاوه بر این، در فایل پیکربندی اصلی Postfix (main.cf) متغیر myhostname باید روی چیزی غیر مشکوک مانند یک زیر دامنه دامنه فیشینگ شما تنظیم شود (به عنوان مثال چیزی مانند mail.domain.com)

در زیر نمونه ای از ظاهر فایل header_checks.cf  Postfix آمده است:

      /^Received:/ IGNORE
      /^X-Mailer:/ IGNORE
      /^Message-ID:/ IGNORE
      /^User-Agent:/ IGNORE
      /^X-Originating-IP:/    IGNORE
      /^Mime-Version:/        IGNORE
      /^In-Reply-To:/ IGNORE
      /^References:/ IGNORE

پس از راه اندازی سرور Gophish، چند mail آزمایشی ارسال کنید و هدرهای سفارشی یا مشکوک را تجزیه و تحلیل کنید.  جستجوی عباراتی مانند “فیش (phish)” و هر چیزی که مربوط به آدرس IP یا نام هاست سرور Gophish باشد، ممکن است به جستجوی نام هاست استفاده شده کمک کند.

اتصالات

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

در زیرساختی که در حال حاضر درحال بررسی آن هستیم، 3 اتصال بین سرورها بایستی برقرار شود:

  • C2-team-server به ریدایرکتور HTTPSا (implant communication)
  • C2-team-server به ریدایرکتور DNSا(implant communication)
  • سرور پی‌لود به ریدایرکتورHTTPS (پی‌لود مرحله 1)

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

به علت پایداری، ایجاد Autossh به عنوان یک سرویس منطقی است. در قطعه کد زیر اتصال به ریدایرکتور DNS نشان داده شده است:

[Unit]
Description=AutoSSH tunnel to DNS-Redirector
After=network.target
[Service]
Environment="AUTOSSH_GATETIME=0"
ExecStart=/usr/bin/autossh -M 0 -q -N -o "ServerAliveInterval 60" -o "ServerAliveCountMax 3" -R 5353:localhost:53 -i <SSH-KEY> <USER>@<DNS_Redirector_IP>
[Install]
WantedBy=multi-user.target

البته از سرویس ها یا متدهای دیگری که بتوانند شرایط اتصال پایدار و اتصال مجدد خودکار را فراهم کنند هم میتوانیم استفاده کنیم. Wireguard مثال خوبی برای این جایگزینی می‌تاوند باشد[8].

فرایند راه‌اندازی خودکار

از آنجاییکه هیچ کس دوست ندارد هر هاستی را به صورت دستی تک به تک راه اندازی کند، اتومیشن کردن این فرایند یک باید است. اینکار به میزان قابل توجهی از بروز اشتباهات می‌کاهد و اگر به درستی انجام شود به غیر از زمان‌هایی که قسمتی از زیرساخت باید عوض شود(که اغلب برای هر تعاملی ممکن است اتفاق بیفتد)، در زمان هم صرفه جویی می‌کند. به منظور انجام این کار ترکیبی از Terraform، Vagrant و Ansible را می توان استفاده کرد.

من از این موارد به روش زیر استفاده کردم:

Terraform برای راه اندازی جعبه های AWS، Vagrant برای راه اندازی جعبه ها در شبکه داخلی و Ansible برای اتومیشن نصب نرم افزار و هر چیز دیگری که پس از نصب سیستم عامل دستگاه دنبال می شود. این شامل سرورهای وب، اتصالات ssh، گواهینامه ها، جابجایی فایل ها و موارد دیگر بود. علاوه بر این، این سه ابزار می توانند به طور یکپارچه در هم تنیده شوند و مانند یک عصای جادویی با هم کار کنند. بسته به اندازه زیرساخت، منطقی است که اسکریپت های اتومیشن را به صورت ماژولار ایجاد کنید، به عنوان مثال نقش های Ansible برای هر میزبان ایجاد کنید. نمونه ای برای خودکارسازی یک تیم قرمز با Terraform و Digital Ocean را می توانید در این لینک پیدا کنید.

خلاصه

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

چه مواردی برای فراهم کردن شرایط مطلوب باید رعایت شوند؟

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

زیرساخت تیم قرمز از چه کامپوننت هایی تشکیل شده است؟

زیرساخت اصلی را می توانیم به زیرساخت فیشینگ و زیرساخت C2 تقسیم کنیم. هر قسمت دربرگیرنده کامپوننت اصلی (سرور فیشینگ/پی‌لود یا سرور C2) و تعدادی ریدایرکتور است.

برای زیرساخت C2، اینها ریدایرکتورهایی هستند که برای هدایت ترافیک beacon و محافظت از سرور اصلی C2 استفاده می شوند. توصیه می‌شود که حداقل از 2 ریدایرکتور مختلف استفاده کنید، یکی برای ترافیک beacon  اصلی با استفاده از یک پروتکل سریع مانند HTTPS و یک کانال پشتیبان با استفاده از یک پروتکل ظریف تر مانند DNS.

زیرساخت mail از دو ریدایرکتور پشت سر هم استفاده می کند، یک ریدایرکتور Postfix برای پاکسازی ترافیک نامه های خروجی و پس از آن از یک نمونه MS Office365 تا ترافیک ایمیل قابل اعتمادتر به نظر برسد و همچنین یک صندوق ورودی برای پاسخ های احتمالی فراهم کند.

از چه نرم افزارهایی می‌توانیم استفاده کنیم؟

این سوال پاسخ مشخصی ندارد، پاسخ این سوال به منابع و بودجه شخصی افراد وابسته است. درباره زیرساخت mail کم و بیش می توان پاسخ مشخصی برای این سوال پیدا کرد، مثلا Gophish که امروزه استاندارد صنعتی de-facto است. استفاده از یک ریدایرکتور Postfix و یک نمونه Microsoft Outlook درکنارهم به عنوان یک mail relay به نظر من می‌تواند یک انتخاب عالی باشد.

انتخاب یک چارچوب C2 امکانات بیشتری را در اختیار شما قرار می‌دهد، چراکه باید بین چارچوب های پولی و متن‌باز انتخاب کنید. از میان چارچوب های پولی ترجیح من Cobalt Strike، Brute Ratel یا Nighthawk است. درمیان چارچوب های رایگان، من فعلا Sliver، Havoc یا Mythic را انتخاب می‌کنم.

در انتخاب ریدایرکتور برای C2 بین Apache، Nginx یا Caddy برای ریدایرکتور HTTPS و برای ریدایرکتور DNS بین Socat یا IPtables یکی را می توانید انتخاب کنید.

نتیجه‌گیری

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

لینک ها

[1]: https://github.com/bluscreenofjeff/Red-Team-Infrastructure-Wiki
[2]: https://medium.com/geekculture/an-nginx-apache-alternative-for-c2-redirecting-61e92a917101
[3]: https://medium.com/@maxime.durand.54/add-the-geoip2-module-to-nginx-f0b56e015763
[4]: https://www.cobaltstrike.com/blog/simple-dns-redirectors-for-cobalt-strike/
[5]: https://labs.withsecure.com/publications/detecting-exposed-cobalt-strike-dns-redirectors
[6]: https://github.com/BishopFox/sliver/wiki/DNS-C2
[7]: https://docs.getgophish.com/user-guide/documentation/sending-profiles
[8]: https://www.wireguard.com/

[9]: https://medium.com/sse-blog/building-a-red-team-infrastructure-in-2023-4eaef5414d92

دیدگاهتان را بنویسید

نشانی ایمیل شما منتشر نخواهد شد. بخش‌های موردنیاز علامت‌گذاری شده‌اند *