fa
Feedback

فریب کلاهبرداران را نخورید! تل‌متریو این کانال‌ها را شناسایی و برچسب‌گذاری می‌کند 👉 برای مشاهده برچسب، اشتراک تهیه کنید





رفتن به کانال در Telegram

Red Team ( Network ) , with Kaveh

نمایش بیشتر
1 216
مشترکین
-124 ساعت
-17 روز
+930 روز
آرشیو پست ها

1 216
📚 بازخورد یکی از خواننده‌های «Kerberos For Pentesters» ممنون از اعتمادتون ❤️ هدف TryHackBox اینه که محتوا واقعاً در مسیر یاد
📚 بازخورد یکی از خواننده‌های «Kerberos For Pentesters» ممنون از اعتمادتون ❤️ هدف TryHackBox اینه که محتوا واقعاً در مسیر یادگیری و کار عملی به دردتون بخوره.


1 216
📚 بازخورد یکی از خواننده‌های «Kerberos For Pentesters» ممنون از اعتمادتون ❤️ هدف TryHackBox اینه که محتوا واقعاً در مسیر یاد
📚 بازخورد یکی از خواننده‌های «Kerberos For Pentesters» ممنون از اعتمادتون ❤️ هدف TryHackBox اینه که محتوا واقعاً در مسیر یادگیری و کار عملی به دردتون بخوره.


1 216
ا 🔴 DCSync؛ وقتی مهاجم از خود Domain Controller Credential میگیره یکی از چیزهایی که توی Active Directory باید خیلی خوب درکش کنی، DCSync هست. اسمش ممکنه اولش یکم گمراه کننده باشه. مهاجم قرار نیست واقعاً خودش رو به شکل یک Domain Controller در بیاره. ماجرا اینه که از قابلیت Replication خود Active Directory سوء استفاده میشه. اActive Directory بین Domain Controllerها اطلاعات رو Replicate می کنه. حالا اگر یک Account دسترسی های لازم برای Replication رو داشته باشه، میتونه از DC اطلاعاتی رو درخواست کنه که نباید در اختیار یک سیستم یا کاربر عادی باشه. و اینجا DCSync شکل می گیره. سناریو رو خیلی ساده ببینیم: دسترسی به یک Account با Replication Rights ⬇️ ارسال درخواست Replication به DC ⬇️ دریافت اطلاعات Credential از AD ⬇️ NTLM Hash و Kerberos Key ⬇️ امکان دسترسی به Credentialهای مهم Domain یکی از خطرناک ترین بخش های این حمله اینه که مهاجم برای به دست آوردن این اطلاعات الزاماً نیازی نداره فایل NTDS.dit رو مستقیم از روی Disk بخونه. اطلاعات از طریق مکانیزم Replication خود AD درخواست میشه. حالا این یعنی چی؟ یعنی اگر مهاجم به اندازه کافی Privilege داشته باشه، میتونه از یک DC بخواد اطلاعات Credential رو در اختیارش قرار بده. و اینجا دیگه موضوع فقط یک User نیست. ممکنه Credentialهای Accountهای مهم Domain هم درگیر بشن. حتی KRBTGT و اگر KRBTGT Key هم به دست مهاجم برسه، مسیر برای حمله هایی مثل Golden Ticket باز میشه. اما یک سؤال مهم: از کجا بفهمیم DCSync اتفاق افتاده؟ یکی از Eventهای مهم اینجا 4662 هست. البته به شرطی که Directory Service Access Auditing و SACL درست تنظیم شده باشن. در این Event میتونیم دنبال Replication Rights مشخصی بگردیم. مثلاً: DS-Replication-Get-Changes و DS-Replication-Get-Changes-All حالا اگر دیدیم یک Account از یک Workstation معمولی داره از DC درخواست های Replication انجام میده، باید جدی تر بررسیش کنیم. مخصوصاً اگر اون Account قبلاً چنین کاری انجام نمی داده. چون Replication عادی بین DCها اتفاق می افته. همچنین بعضی سرویس های واقعی مثل Backup، Sync و Identity Management هم ممکنه Replication Rights داشته باشن. پس: 4662 = DCSync نه. این برداشت اشتباهه. باید ببینیم چه Accountی، از کجا، با چه دسترسی ای و برای چه هدفی این درخواست رو انجام داده. از دید یک Red Teamer، چیزی که واقعاً مهمه اینه: اگر جایی دیدی یک User یا Service Account دسترسی Replication داره، سریع از کنارش رد نشو. بپرس: این دسترسی چرا وجود داره؟ چه کسی بهش داده؟ از کجا میتونه استفاده بشه؟ آیا واقعاً لازم داره؟ و مهم تر از همه: اگر Credential این Account لو بره، مهاجم تا کجا می تونه پیش بره؟ چون گاهی یک ACE کوچک روی Active Directory می تونه خیلی بیشتر از چیزی که روی کاغذ به نظر میاد خطرناک باشه. اDCSync از همون حمله هاییه که نشون میده در Active Directory فقط داشتن Administrator مهم نیست. گاهی یک Permission اشتباه، مسیر رسیدن به کل Domain رو باز می کنه. #ActiveDirectory #DCSync #RedTeam #Kerberos #CyberSecurity


1 216
📚 کتابچه Kerberos For Pentesters 📌 یک راهنمای تخصصی برای شناخت Kerberos و نحوه استفاده از آن در تست نفوذ و Red Team محیط‌ها
+4
📚 کتابچه Kerberos For Pentesters 📌 یک راهنمای تخصصی برای شناخت Kerberos و نحوه استفاده از آن در تست نفوذ و Red Team محیط‌های Active Directory. این کتاب از مبانی شروع می‌کند و تلاش می‌کند قبل از ورود به تکنیک‌های حمله، ساختار و منطق Kerberos را برای خواننده روشن کند. در ابتدا با تاریخچه و تکامل Kerberos، معماری Kerberos v5 و اجزای اصلی آن آشنا می‌شوید و سپس نحوه پیاده‌سازی این پروتکل در Active Directory بررسی می‌شود. در بخش Active Directory، موضوعاتی مانند نقش Domain Controller به‌عنوان KDC، ارتباط Kerberos با حساب‌های کاربری و سرویس‌ها، TGT و Service Ticket و مکانیزم Pre-authentication مورد بررسی قرار می‌گیرند. 📌 توضیحات تکمیلی 📕 نمونه کتاب 📄 صفحات : ۱۷۷ 💰 قیمت اصلی : ۲۶۹,۰۰۰ هزارتومان 🔥 برای ۳ نفر اول : ۱۹۹,۰۰۰ هزارتومان 📌 جهت خرید به ایدی زیر پیام دهید: @THBxSupport @KavehOffSec @TryHackBox


1 216
🔥 جشن شهریورگان / ۳۰ امرداد 💠 شهریورگان، جشنی به پاس شهریور امشاسپند است. شهریور، فروزه‌ی توانایی و شهریاری اهورامزدا بوده و از دید لغوی به معنی «شهریاری آرزوشده» می‌باشد. هم از این روست که از اهورامزدا در اوستا با نام «به شهریاری برازنده‌ترین» یاد شده است. درست به همین چرایی نیز شاهنشاهان هخامنشی و ساسانی، شهریاری خود بر ایرانشهر را بخشش اهورامزدا به خود می‌خواندند؛ زیرا بُن یا سرچشمه‌ی شهریاری نیک را شهریاری اهورامزدا می‌دانستند. با این همه، بر پایه‌ی جهان‌بینی زرتشتی، اهورامزدا هر انسانی را شهریار تن خویش آفریده است. پس این مفهوم صرفاً دارای بُعدی سیاسی نیست؛ بلکه معنایی بس گسترده‌تر و عام‌تر هم دارد. 💠 شهریاری‌ ای که استوار بر نیکی باشد، در فرهنگ زرتشتی، «نیک‌خدایی (نیکی‌سالاری، شهریاری نیک، نیکوپادشاهی)» نام دارد. این مفهوم، شالوده‌ی اصلی اندیشه‌ی سیاسی ایرانشهری را برمی‌سازد. گفتنی‌ست که نماد مادی شهریور نیز فلزات هستند. 📌 یک نکته برای اصلاح یک اشتباه رایج دوستان، دلیل اینکه این پست را منتشر کردیم این است که متأسفانه تاریخ شهریورگان در برخی صفحات و مطالب، با تاریخ‌ های دیگر اشتباه گرفته می‌شود. بنابراین اگر در این زمینه محتوا تولید می‌ کنید، مخصوصاً دوستانی که در اینستاگرام صفحه تاریخی دارند، لطفاً پیش از انتشار، تاریخ و منبع را بررسی کنید تا یک اشتباه بارها و بارها تکرار نشود. ما نمی‌گوییم گرامی‌ داشت این روز کار نادرستی است؛ برعکس، زنده نگه داشتن یاد و فرهنگ ایران باستان ارزشمند است. اما در کنار علاقه به تاریخ، دقت تاریخی هم اهمیت دارد. گاهی حتی یک تاریخ اشتباه، وقتی بارها بازنشر شود، تبدیل به یک «واقعیت رایج» می‌ شود؛ در حالی که رایج بودن یک ادعا، دلیل درست بودن آن نیست. یاد تاریخ و بزرگان ایران را گرامی بداریم؛ اما دقیق و مسئولانه. ✍ کاوه برگی از تاریخ @TryHackBox #تاریخ #تاریخ_ایران


1 216
۴ شهریور؛ سالروز کوروش بزرگ من فرزند ایرانم؛ از تبار مردمانی که تاریخ را با شکوه خود نوشتند. فرزند کوروش، فرزند این خاک، و وارث نامی که هیچ‌ گاه از یاد نمی‌ رود. به ریشه‌ هایم افتخار میکنم؛ به ایران، به تاریخم، به کوروش بزرگ. تا وقتی ایران هست، نام کوروش زنده است. @KavehOffSec #کوروش #ایران #آریایی


1 216
ا🎫 Silver Ticket تفاوتش با Golden Ticket چیه؟
خیلی وقت‌ ها اسم Golden Ticket و Silver Ticket رو کنار هم میشنویم. ولی این دوتا دقیقاً یک چیز نیستن ، تفاوت اصلیشون توی اینه که مهاجم با چه Keyای Ticket رو جعل میکنه و در نهایت قراره به کجا دسترسی بگیره. در Golden Ticket: KRBTGT Key ⬇️ Forged TGT ⬇️ Service Tickets یعنی مهاجم به Key مربوط به KRBTGT دسترسی داره و میتونه یک TGT جعلی بسازه.
 اما در Silver Ticket داستان فرق میکنه:
Service / Computer Account Key ⬇️ Forged TGS ⬇️ Target Service اینجا مهاجم TGT رو جعل نمیکنه. مستقیماً یک Service Ticket یا همون TGS جعلی برای یک سرویس مشخص میسازه. مثلاً سرویس‌هایی مثل: 🔹 CIFS 🔹 HTTP 🔹 HOST 🔹 MSSQLSvc بعد Ticket برای همون Target Service استفاده میشه. حالا از دید Detection یک نکته جالب داریم. فرض کن روی یک Server یک Kerberos Logon در Event ID 4624 میبینیم. ولی وقتی میریم سراغ Domain Controller، برای همون User، Source و Service یک 4769 منطقی پیدا نمیکنیم ،این میتونه مشکوک باشه.
ولی هنوز نمیتونیم بگیم: «خب، پس حتماً Silver Ticket داریم.» چرا؟ چون ممکنه Ticket قبلاً صادر شده باشه و از Cache استفاده شده باشه ، یا اصلاً Logها کامل نباشن. پس بهتره فقط روی یک Event تمرکز نکنیم. باید ببینیم بعد از Authentication چه اتفاقی افتاده. مثلاً:
4624 ⬇️ 4672 ⬇️ 5140 / 5145 ⬇️ 4688 ⬇️ WinRM / RDP / WMI / SQL / Service Activity
حالا یک قدم هم برگردیم عقب ، خود Service Account رو بررسی کنیم.
چندتا SPN داره؟ چه Privilegeهایی داره؟ اPassword یا Credential اون چقدر امنه؟ آیا همین Account برای چند Service استفاده شده؟
📌 این قسمت مهمه چون یک Service Account ضعیف، مخصوصاً اگر Privilege بالایی هم داشته باشه، میتونه تبدیل به یک نقطه خیلی جدی برای ادامه Attack Chain بشه. اگر بخوام خیلی خلاصه تفاوت این دوتا رو بگم:
🎫 Golden Ticket KRBTGT Key → TGT → Domain-wide potential 🎫 Silver Ticket Service Key → TGS → Specific Service
و از سمت دفاع هم داستان فقط Detection نیست. اService Accountها باید تا جای ممکن Passwordهای طولانی و تصادفی داشته باشن. استفاده از gMSA میتونه کمک بزرگی باشه. اPrivilegeهای اضافه هم باید از این Accountها گرفته بشه. و روی Target Serverها هم باید Telemetry مناسبی داشته باشیم تا بتونیم رفتار مشکوک بعد از Authentication رو ببینیم. در Active Directory خیلی وقتها خود Ticket مشکل اصلی نیست. مشکل اینه که پشت اون Ticket چه Keyای قرار داره و اون Key به چه سرویس‌ هایی دسترسی میده. @KavehOffSec #ActiveDirectory #SilverTicket #Kerberos #RedTeam


1 216
🎫 Golden Ticket یکی از خطرناک‌ ترین سناریوهای Kerberos فرض کن مهاجم somehow به Key مربوط به KRBTGT دسترسی پیدا کرده. از اینجا به بعد، داستان دیگه مثل Kerberoasting نیست که دنبال Password یک Service Account باشیم. اینجا مهاجم میتونه یک TGT جعلی بسازه و خودش تعیین کنه این Ticket با چه Identity و چه Privilegeهایی مورد استفاده قرار بگیره. اگر بخوایم خیلی ساده ببینیم: 🔴 KRBTGT Key ⬇️ 🎫 Forged TGT ⬇️ 🔑 Service Tickets ⬇️ 🌐 Domain Services یعنی اگر KRBTGT واقعاً compromise شده باشه، پتانسیل Impersonation در سطح Domain وجود داره. اما سؤال مهم‌تر برای Defender اینه: چطور متوجه Golden Ticket بشیم؟ یکی از مواردی که میشه بررسی کرد، ارتباط بین Eventهای: 4768 → TGT Request و 4769 → TGS Request مثلاً اگر برای یک User و Source مشخص، فعالیت TGS داشته باشیم اما TGT منطقی قبل از اون در لاگ‌ها دیده نشه، میتونه یک Signal مشکوک باشه. ولی اینجا یک نکته خیلی مهم وجود داره: ❌ نبودن Event 4768 به‌تنهایی یعنی Golden Ticket نداریم یا داریم؟ هیچ‌کدوم. ا TGTها Cache میشن، لاگ‌ها ممکنه کامل نباشن و سناریوهایی مثل Cross-Domain Authentication هم میتونن تحلیل رو پیچیده‌تر کنن. برای همین Detection واقعی باید چند نشونه رو کنار هم بذاره: 🔹 User & Source IP 🔹 Events 4768 / 4769 🔹 Events 4624 / 4672 on the Target System 🔹 Actual Account Status 🔹 Ticket Lifetime 🔹 Encryption Type 🔹 Normal & Abnormal User Behavior 🔹 Evidence of DCSync or Credential Dumping و اگر در نهایت مشخص بشه که KRBTGT واقعاً compromise شده، دیگه با یک Incident معمولی طرف نیستیم. باید باهاش مثل یک Tier-0 / Domain Compromise برخورد کرد. در مرحله Recovery هم، بعد از Containment و بررسی دقیق، یکی از اقدامات اصلی Reset کنترل‌ شده Password حساب KRBTGT در دو مرحله است؛ با توجه جدی به Replication بین Domain Controllerها و وضعیت کل محیط. به نظرم این دقیقاً یکی از جاهاییه که نشون میده: فهمیدن Kerberos خیلی مهم‌ تر از حفظ کردن چندتا کامنده. وقتی بفهمی Ticketها چطور کار میکنن، بهتر متوجه میشی چرا compromise شدن KRBTGT میتونه کل Domain رو تحت تأثیر قرار بده. @KavehOffSec #ActiveDirectory #GoldenTicket #Kerberos #RedTeam


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


1 216
من ایران را دوست دارم چون شعر دارد ، هنر دارد ، تاریخ دارد ، وسوسه ماندن دارد . میهن در دل آدمی باید باشد . 18/19 ...🕊🖤🥀


1 216
🔴 Kerberoasting 📌 یک Service Account چقدر میتونه خطرناک باشه؟
یکی از چیزهایی که توی تست Active Directory همیشه باید بررسی بشه، Service Accountها و SPNها هستن. چرا؟ چون برای درخواست یک Kerberos Service Ticket معمولاً لازم نیست Administrator باشی. یک Domain User احراز هویت‌ شده میتونه برای Serviceهایی که SPN دارن Ticket بگیره. حالا مهاجم چی به دست میاره؟ یک Ticket رمزنگاری‌ شده که میتونه خارج از DC و به‌صورت Offline برای Password Guessing بررسی بشه. اینجا اگر Password مربوط به Service Account ضعیف باشه، داستان جالب میشه. مثلاً تصور کن:
 ◾ در عکس بالا 📌 نکته مهم:
ا RC4 با Encryption Type 0x17 میتونه یک Signal مهم باشه، اما دیدن RC4 به‌ تنهایی یعنی «Kerberoasting قطعی» نیست. ممکنه سیستم‌ های Legacy یا Service Accountهای قدیمی واقعاً از RC4 استفاده کنن.
برای Detection بهتره دنبال ترکیب چند Signal باشیم:
🔹 یک سیستم که در مدت کوتاه برای SPNهای مختلف Ticket می‌گیره ا 🔹 Requester غیرعادی ا 🔹 LDAP Enumeration مربوط به servicePrincipalName قبل از TGS Burst ا 🔹 Service Account با Privilege بالا 🔹 استفاده غیرمعمول از RC4 در محیطی که معمولاً AES استفاده میشه
 و از دید دفاعی؟
بهترین کار فقط این نیست که دنبال Kerberoasting بگردیم. سرویس اکانتهای قدیمی رو بررسی کنیم، Passwordهای قوی و تصادفی داشته باشیم، تا جای ممکن از gMSA استفاده کنیم، SPNهای غیرضروری رو حذف کنیم و Privilege اضافی رو از Service Accountها بگیریم. ا Kerberoasting شاید با یک User معمولی شروع بشه. ولی اینکه به کجا ختم بشه، کاملاً به وضعیت همون Service Account بستگی داره.
 @KavehOffSec


1 216
Kerberoasting یک Service Account چقدر میتونه خطرناک باشه؟ مطلب در پایین 👇👇 @KavehOffSec #ActiveDirectory #RedTeam #Kerberoa
Kerberoasting یک Service Account چقدر میتونه خطرناک باشه؟ مطلب در پایین 👇👇 @KavehOffSec #ActiveDirectory #RedTeam #Kerberoasting #CyberSecurity


1 216


1 216
🧠 ذهنیت یک ردتیمر #RedTeam
یک ردتیمر فقط ابزار یاد نمیگیرد. مهم‌ترین مهارت، نوع تفکر است.
چند اصل مهم:
🔹 همیشه مثل مهاجم فکر کن. ا🔹 TTPهای گروه‌های مهاجم را مطالعه کن. 🔹 همیشه در حال یادگیری باش. 🔹 فقط به آسیب‌ پذیری نگاه نکن؛ به کل مسیر حمله فکر کن. 🔹 امنیت فقط تکنولوژی نیست؛ انسان و فرآیند هم مهم هستند.
یک هکر که بداند چگونه سیستم را بشکند، بهتر میداند چگونه آن را امن کند. این تفاوت یک ردتیمر واقعی است. @KavehOffSec


1 216
برچسب وطن‌ فروشی رو خوب بلدن، فقط ظاهراً موقع استفاده ازش کمی گزینشی عمل میکنن. #کاسپین


1 216


1 216


1 216
Repost from Try Hack Box
❗ تخفیف ویژه ❗ 📚 کتابچه "Mimikatz: تسلط عملی بر تکنیک‌های پیشرفته حملات Active Directory" از مقدماتی تا پیشرفته. 📕 جزئیات ب
❗ تخفیف ویژه ❗ 📚 کتابچه "Mimikatz: تسلط عملی بر تکنیک‌های پیشرفته حملات Active Directory" از مقدماتی تا پیشرفته. 📕 جزئیات بیشتر کتاب 💰 قیمت : ۲۵۰,۰۰۰ تومان 💰 تخفیف : ۱۹۰,۰۰۰ تومان 📖 وایرشارک برای ردتیمرها: از پایه تا پیشرفته 📕 جزئیات بیشتر کتاب 💰 قیمت : ۲۵۰,۰۰۰ تومان 💰 تخفیف : ۱۸۰,۰۰۰ تومان 📖 شکار عملی باگ بانتی : از Recon تا Bounty واقعی : متدولوژی و شناسایی و آسیب پذیری های دنیای واقعی 📕 جزئیات بیشتر کتاب 💰 قیمت : ۳۶۰,۰۰۰ تومان 💰تخفیف : ۲۸۰,۰۰۰ تومان ‼️ مهلت تخفیف : 3 روز 📌 جهت خرید به ایدی زیر پیام دهید: @THBxSupport


1 216
03 : پورت ۲۱: FTP : پروتکل انتقال فایل ورود ناشناس، حملات Bounce و اعتبارنامه‌ های Cleartext https://x.com/i/status/2072205908319285705