Try Hack Box
Відкрити в Telegram
1 Nov 2020 1399/08/11 🔴 THB | Offensive Security آموزش، تحقیق و تجربه عملی در امنیت تهاجمی Penetration Testing · Red Teaming · AI Security 🎯 یاد بگیر. آزمایش کن. حرفهای شو.
Показати більше6 462
Підписники
+1624 години
+597 днів
+10930 день
Архів дописів
6 461
Repost from
ا🎫 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
6 461
🔍 Enum Subdomain از Wayback با Bash
میخوای subdomainهای پنهان archived در طول زمان رو کشف کنی؟ این function bash مفید subdomainها رو از Wayback Machine میکشه و به recon عمیق کمک میکنه.
➕ این رو به ~/.bashrcت اضافه کن:
function wayback() {
curl -sk "http://web.archive.org/cdx/search/cdx?url=*.$1&output=txt&fl=original&collapse=urlkey&page=" | awk -F/ '{gsub(/:.*/, "", $3); print $3}' | sort -u
}
🧪 استفاده:
wayback target.comاین subdomainها رو از URLهای archived فیلتر میکنه و unique سورت میکنه.
کدوم subdomain قدیمی رو با wayback function شکار کردی که vuln جدیدی باز کرد؟ تجربت رو کامنت کن،@TryHackBox #باگ_بانتی
6 461
Repost from رادیو زیرو پاد
⭕️ قسمت دوازدهم رادیو زیرو تاک
📌 موضوع جلسه :
آشنایی با DFIR
🎙 مهمان برنامه : مهندس عماد عابدینی
منتظر جلسه بعدی باشید.
🎤 راهبر گفتگوی امنیتی : حسین نائیجی
🆔 @RadioZeroPod
🆔 @TryHackBox
🆔 @TryHackBoxOfficial
🆔 @AiTHB
6 461
Repost from RedTeamAPT Academy
RedTeam 🔴 vs 🔵 BlueTeam
بخشی از دوره Windows Internal فصل 3
Early Bird
Asynchronous Procedure Call
APC Queue
دوره های آموزشی (بدون VPN)
دوره آموزشی Windows Internal (بدون VPN)
راهنمایی و شرکت در دوره ها : @RedTeamAdmin1
@RedTeamAcademy
6 461
📌 SAML SECURITY SERIES | PART 01
اSAML؛ وقتی یک Login ساده، پای XML وسط می آید!
اگر تا حالا با SSO کار کرده باشید، احتمالاً اسم SAML به گوشتون خورده.
اSAML یا Security Assertion Markup Language یکی از فناوری هایی هست که برای Authentication و پیاده سازی SSO استفاده میشه.
اما یک نکته جالب وجود داره:
اSAML بهشدت به XML وابسته است؛ و همین XML میتونه بخشی از سطح حمله رو تشکیل بده.
در یک SAML Implementation، مشکلات مختلفی ممکنه به وجود بیان؛ از اشتباه در بررسی Signature گرفته تا Replay شدن Assertion یا حتی مشکلات مربوط به XML Processing.
چند مورد مهمی که باید بشناسیم:
🔹 Signature Wrapping (XSW)
🔹 XML Attacks
🔹 SAML Message Integrity Abuse
🔹 Missing / Invalid Signature
🔹 SAML Message Replay
🔹 CSRF
🔹 XML Comment Handling
🔹 XSLT
🔹 Token Recipient Confusion
اما قرار نیست همه اینها رو یکجا بررسی کنیم.
در این سری، یکی یکی سراغشون میریم و از دید یک Security Tester بررسی میکنیم که هرکدوم چه مفهومی دارن و چرا باید موقع بررسی SAML بهشون توجه کرد.
🎯 یک سؤال برای شروع:
اگر بخواید یک SAML Implementation رو بررسی کنید، حدس می زنید اولین چیزی که ارزش بررسی داره کدومه؟
Signature؟
XML Processing؟
Replay؟
یا ....؟
دلیل انتخابتون رو هم بنویسید. 👇
@TRYHACKBOX
#امنیت_سایبری #تست_نفوذ
6 461
دعوت به همکاری | UI/UX Designer
برای توسعه و تکمیل یک پروژه واقعی و در حال رشد در حوزه امنیت سایبری (Cyber Security)، به یک نیروی UI/UX Designer خلاق، مسئولیت پذیر و علاقهمند به کار تیمی دعوت به همکاری میکنیم.
اگر در زمینه طراحی UI/UX فعالیت دارید و علاقهمند هستید روی یک محصول واقعی و قابل ارائه در رزومه و Portfolio کار کنید، خوشحال میشویم با شما آشنا شویم.
مزایای همکاری
🔹 فعالیت روی یک پروژه واقعی و قابل ارائه در رزومه
🔹 امکان ثبت تجربه همکاری در Portfolio
🔹 فرصت ارائه ایده و مشارکت در تصمیم های طراحی محصول
🔹 تجربه همکاری با اعضای تیم در حوزههای Cyber Security و Software Development
🔹 فرصت یادگیری و توسعه مهارت های تخصصی در یک محیط فنی
🔹 امکان ادامه همکاری و ایجاد فرصت های بیشتر در صورت موفقیت همکاری
🔹 فضای کاری دوستانه، حرفهای و تیممحور
شرایط موردنظر
آشنایی با Figma و اصول طراحی UI/UX، طراحی Responsive، User Flow و طراحی محصول از مهارتهای موردنظر ماست.
تسلط کامل بر تمام موارد الزامی نیست؛ انگیزه، مسئولیتپذیری، خلاقیت و علاقه به یادگیری برای ما اهمیت زیادی دارد.
📩 اگر علاقهمند به همکاری هستید، از آیدی زیر با ما در ارتباط باشید:
@ThbxSupport
در صورت امکان، نمونهکارها یا Portfolio خود را نیز ارسال کنید.
اگر به دنبال فرصتی برای تجربه کار روی یک محصول واقعی و رشد در کنار یک تیم فنی هستید، خوشحال میشویم شما را در تیم خود داشته باشیم.
6 461
🎯 Bug Bounty Lab
یک Workspace جامع برای باگ بانتی
اگر در حوزه باگ بانتی فعالیت میکنید، مدیریت Scope، Recon، ابزارها، یافته ها و گزارش ها میتواند به مرور زمان پیچیده و پراکنده شود.
باگ بانتی Lab یک پروژه متن باز است که با هدف ایجاد یک Workspace یکپارچه برای مدیریت فرآیند باگ بانتی توسعه داده شده و بخش های مختلف این فرآیند را در یک محیط واحد ترکیب میکند.
🔍 برخی از قابلیت های پروژه:
• مدیریت و بررسی Scope ا• Workflow از Recon تا Vulnerability Discovery و Reporting • 🤖 قابلیتهای AI-assisted برای فرآیند تحقیق • 🧰 دسترسی به بیش از ۴۰۰ ابزار امنیتی و Recon ا• 📝 Templateهای گزارش نویسی با ساختار مشابه HackerOne • 🖥️ لابراتوار محلی برای تمرین و یادگیری • ⚡ ابزارهای Automated Recon و Enumeration • 📚 منابع آموزشی و راهنماهای Methodology🔗 GitHub: https://github.com/DevCop95/bugbounty-lab101 اگر در زمینه باگ بانتی، امنیت وب یا Security Research فعالیت میکنید، بررسی این پروژه میتواند جالب باشد. @TryHackBox #باگ_بانتی
6 461
Repost from Try Hack Box
یک نظرسنجی برای شروع یک دوره جدید
اگر یک دوره کاملاً عملی درباره نگارش حرفهای گزارش های تست نفوذ و Red Team برگزار کنیم، چقدر براتون کاربردیه؟
🎯 اگر حداقل ۱۰ نفر علاقهمند جدی باشن، دوره رو شروع میکنیم. نظرتون چیه؟
6 461
وقتی یک Chrome Extension روی سیستم نصب میشه، فایل ها و منابع اون بهصورت Local در دسترس قرار میگیرن. همین موضوع باعث میشه در یک Authorized Security Assessment امکان بررسی ساختار، Source Code و رفتار Extension وجود داشته باشه.
گاهی داخل همین فایل ها میشه چیزهای جالبی پیدا کرد؛ مثلاً:
🔹 API Key 🔹 Token 🔹 Endpointهای داخلی 🔹 اطلاعات حساس 🔹 Permissionهای غیرضروری 🔹 ضعف های موجود در منطق Extension اما نکته مهم اینجاست: صرفاً پیدا کردن یک API Key یا Token به معنی وجود آسیب پذیری نیست. باید ببینیم این اطلاعات دقیقاً چه سطحی از دسترسی ایجاد میکنن و آیا واقعاً قابل سوءاستفاده هستن یا نه. 🔎 حتی برای پیدا کردن Extensionهای مرتبط با یک شرکت مشخص، میشه از Google Dork استفاده کرد. مثلاً:
site:chromewebstore.google.com "nasa.gov"کافیه
nasa.gov رو با Domain موردنظر جایگزین کنید.
بعد از پیدا کردن Extension، مرحله جالبتر شروع میشه:
Source Code → Permissions → Endpoints → Secrets → Impact 🎯 ذهنیت باگ هانتر به جای اینکه فقط بپرسیم: «چه چیزی پیدا کردم؟» باید بپرسیم: واقعاً با این چیزی که پیدا کردم، چه کاری میتونم انجام بدم همین تغییر نگاه، یک Recon ساده رو به مسیر واقعی Vulnerability Discovery تبدیل میکنه. 💬 حالا سؤال: اگر در Source Code یک Chrome Extension به یک API Key یا Token برخورد کنید، اولین چیزی که بررسی میکنید چیه؟ 🔹 API Key 🔹 Endpoint 🔹 Permissions 🔹 Token Usage
انتخابتون رو بنویسید و بگید چرا. 👇@TryHackBox #باگ_بانتی #امنیت_سایبری #نکات_باگ_بانتی #امنیت_وب #امنیت_اپلیکیشن #تست_نفوذ #امنیت_اطلاعات
6 461
وقتی Windows Event Log تبدیل به منبع Recon میشه
معمولاً وقتی اسم Windows Event Log میاد، یاد Detection و Incident Response می افتیم.
ولی از دید مهاجم، همین Logها میتونن پر از اطلاعات مفید باشن.
مثلاً بعضی Eventها اطلاعاتی درباره User، IP و زمان Login در اختیار میذارن.
یکی از Logهایی که ارزش بررسی داره:
Microsoft-Windows-TerminalServices-LocalSessionManager/Operationalبرای مثال میشه Event ID 21 رو بررسی کرد:
Get-WinEvent -LogName 'Microsoft-Windows-TerminalServices-LocalSessionManager/Operational' | Where-Object {$_.Id -eq 21}
چیزی که مهاجم ممکنه از این اطلاعات بسازه:
User → IP → Login Timeیعنی به جای اینکه فقط دنبال سرویس و پورت جدید بگرده، از اطلاعاتی که همین الان روی سیستم ثبت شده برای شناخت بهتر محیط استفاده میکنه. 🔎 از دید Detection اجرای PowerShell برای خواندن Event Logهای مرتبط با Terminal Services میتونه ارزش بررسی داشته باشه. مثلاً:
powershell.exe + Get-WinEvent + TerminalServices-LocalSessionMaagerالبته این الگو به تنهایی به معنی حمله نیست. ا Context همیشه مهمه. 🎯 ذهنیت ردتیمر مهاجم همیشه دنبال Exploit جدید نیست. گاهی بهترین اطلاعات، جاییه که همه فکر میکنن فقط برای Logging ساخته شده.
Logs → Information → Context → Intelligenceپس یک سؤال ساده از خودت بپرس: اگر من مهاجم بودم، از همین Logهای موجود چه چیزی میتوانستم بفهمم؟ @TryHackBox #امنیت_سایبری #ردتیم #بلو_تیم #پاورشل #ویندوز #ThreatHunting #DFIR #SIEM #EDR #ThreatDetection
6 461
🔥 Firebase Config Exposed ≠ Vulnerability
یکی از اشتباهات رایج در باگ بانتی اینه که وقتی داخل JavaScript با چیزهایی مثل firebaseConfig یا apiKey مواجه میشیم، سریع فکر کنیم یک آسیب پذیری پیدا کردیم.
اما اینطور نیست.
ا Firebase configuration معمولاً Secret محسوب نمیشه.
چیزی که واقعاً باید بررسی کنیم، Database Security Rules و سطح دسترسی واقعی Backend هست.
🔎 در مرحله Recon میتونید دنبال مواردی مثل این باشید:
firebaseConfig apiKey projectId databaseURL firebaseio.comاما اگر databaseURL پیدا کردید، سؤال اصلی این نیست: «آیا Firebase Config لو رفته؟» سؤال مهم تر اینه: ❓ آیا Backend بدون Authentication اجازهی Read یا Write میده؟ 🧪 Safe PoC فقط روی Assetهایی که صراحتاً اجازهی تستشون رو دارید، میتونید یک Path اختصاصی برای PoC در نظر بگیرید:
curl -X PUT \
"https://YOUR-PROJECT.firebaseio.com/thb-poc.json" \
-H "Content-Type: application/json" \
-d '{"poc":"authorized-security-test"}'
اگر Database این درخواست رو بدون Authentication قبول کنه، حالا با یک Finding واقعی تر رو به رو هستیم:
Unauthenticated Database Write
نه صرفاً:
Firebase Config Exposed
💥 Potential Impact
بسته به Security Rules و نحوه استفاده Application، ممکنه مواردی مثل این اتفاق بیفته:
• Unauthorized Data Modification
• Data Poisoning
• Application Data Tampering
• Stored XSS در صورت مصرف ناامن داده
• Business Logic Abuse
• Unauthorized Data Disclosure در صورت وجود Read Access
ا ⚠️ Impact رو فقط بر اساس Permission واقعی تعیین کنید، نه صرفاً بر اساس چیزی که در ریکان پیدا کردید.
🛡️ Developer Fix
ا Security Rules رو با اصل Deny by Default طراحی کنید.
همچنین Authentication و Authorization رو درست پیاده سازی کنید و دسترسی ها رو فقط به منابعی که واقعاً لازم هستند محدود کنید.
🎯 ذهنیت باگ هانتر
وقتی در Recon با چیزهایی مثل این مواجه میشید:
Firebase S3 MongoDB Elasticsearch Supabase GraphQLفقط نپرسید: «آیا این سرویس وجود داره؟» سؤال مهمتر اینه: «واقعاً باهاش چه کارهایی میتونم انجام بدم؟» Configuration → Access → Permission → Impact اینجاست که ریکان از یک جمع آوری ساده اطلاعات، تبدیل میشه به Vulnerability Discovery. ⚠️ این مطالب صرفاً برای آموزش و Authorized Security Assessments هستند. 🆔 @TryHackBox 🆔 @TryHackBoxOfficial 🆔 @RadioZeroPod 🆔 @AiTHB #نکات_باگ_بانتی #باگ_بانتی #امنیت_وب #تست_نفوذ #امنیت_سایبری #امنیت_اطلاعات
6 461
🔥 Firebase Config Exposed ≠ Vulnerability
یکی از اشتباهات رایج در باگ بانتی اینه که وقتی داخل JavaScript با چیزهایی مثل
firebaseConfig یا apiKey مواجه میشیم، سریع فکر کنیم یک آسیب پذیری پیدا کردیم.
اما اینطور نیست.
ا Firebase configuration معمولاً Secret محسوب نمیشه.
چیزی که واقعاً باید بررسی کنیم، Database Security Rules و سطح دسترسی واقعی Backend هست.
🔎 در مرحله Recon میتونید دنبال مواردی مثل این باشید:
firebaseConfig
apiKey
projectId
databaseURL
firebaseio.com
اما اگر databaseURL پیدا کردید، سؤال اصلی این نیست:
«آیا Firebase Config لو رفته؟»
سؤال مهم تر اینه:
❓ آیا Backend بدون Authentication اجازهی Read یا Write میده؟
🧪 Safe PoC
فقط روی Assetهایی که صراحتاً اجازهی تستشون رو دارید، میتونید یک Path اختصاصی برای PoC در نظر بگیرید:
curl -X PUT \
"https://YOUR-PROJECT.firebaseio.com/thb-poc.json" \
-H "Content-Type: application/json" \
-d '{"poc":"authorized-security-test"}'
اگر Database این درخواست رو بدون Authentication قبول کنه، حالا با یک Finding واقعی تر رو به رو هستیم:
Unauthenticated Database Write
نه صرفاً:
Firebase Config Exposed
💥 Potential Impact
بسته به Security Rules و نحوه استفاده Application، ممکنه مواردی مثل این اتفاق بیفته:
• Unauthorized Data Modification
• Data Poisoning
• Application Data Tampering
• Stored XSS در صورت مصرف ناامن داده
• Business Logic Abuse
• Unauthorized Data Disclosure در صورت وجود Read Access
ا ⚠️ Impact رو فقط بر اساس Permission واقعی تعیین کنید، نه صرفاً بر اساس چیزی که در ریکان پیدا کردید.
🛡️ Developer Fix
ا Security Rules رو با اصل Deny by Default طراحی کنید.
همچنین Authentication و Authorization رو درست پیاده سازی کنید و دسترسی ها رو فقط به منابعی که واقعاً لازم هستند محدود کنید.
🎯 ذهنیت باگ هانتر
وقتی در Recon با چیزهایی مثل این مواجه میشید:
Firebase
S3
MongoDB
Elasticsearch
Supabase
GraphQL
فقط نپرسید: «آیا این سرویس وجود داره؟» سؤال مهمتر اینه:
«واقعاً باهاش چه کارهایی میتونم انجام بدم؟»
Configuration → Access → Permission → Impact
اینجاست که ریکان از یک جمع آوری ساده اطلاعات، تبدیل میشه به Vulnerability Discovery.
⚠️ این مطالب صرفاً برای آموزش و Authorized Security Assessments هستند.
🆔 @TryHackBox
🆔 @TryHackBoxOfficial
🆔 @RadioZeroPod
🆔 @AiTHB
#نکات_باگ_بانتی #باگ_بانتی #امنیت_وب #تست_نفوذ #امنیت_سایبری #امنیت_اطلاعات6 461
Repost from RedTeamAPT Academy
RedTeam 🔴 vs 🔵 BlueTeam
دوستانی که دنبال مباحث پیشرفته (APT) هستند میتوانند این ویدیو رو که بخشی از فصل سوم دوره Windows Internal هست رو مشاهده کنند .
@RedTeamAcademy
6 461
📌 RECONNAISSANCE SERIES | PART 1
ا 🎯 Reconnaissance چیست و چرا برای یک ردتیمر اهمیت دارد؟
هر عملیات Red Team موفق، قبل از هرگونه Exploitation یا تلاش برای Initial Access، با شناخت دقیق هدف آغاز میشود.
یک ردتیمر حرفهای ابتدا باید بداند با چه محیطی رو به رو است؛ چه دارایی هایی در اختیار سازمان قرار دارد، چه فناوری هایی استفاده می شوند، چه سرویس هایی در معرض دید هستند و چه اطلاعاتی از سازمان بهصورت عمومی قابل دسترسی است.
این مرحله همان Reconnaissance یا شناسایی است.
ا Reconnaissance به فرآیند جمعآوری، بررسی و تحلیل اطلاعات درباره یک Target گفته میشود. هدف این مرحله صرفاً جمع آوری حجم زیادی از داده نیست؛ بلکه تبدیل داده های پراکنده به اطلاعاتی است که بتوان از آنها برای تصمیم گیری و برنامه ریزی عملیات استفاده کرد.
به چنین اطلاعاتی Actionable Intelligence گفته میشود.
🔹 در یک Recon حرفهای ممکن است موارد زیر شناسایی شوند:
• Domain و Subdomainها • IP Addressها • سرویس های قابل دسترس • Technology Stack • اطلاعات DNS • ساختار سازمانی • افراد و نقش های کلیدی • اطلاعات عمومی کارکنان • نرمافزارها و فناوری های مورد استفاده • اسناد و اطلاعات عمومی • نقاط ورود احتمالی •ا Misconfigurationها و ضعفهای احتمالیاما یک نکته اساسی وجود دارد: ریکان خوب، به معنی جمعآوری بیشترین اطلاعات ممکن نیست. اگر صدها داده جمع کنیم اما نتوانیم ارتباط میان آنها را درک کنیم، در واقع Recon مؤثری انجام ندادهایم. هدف این است که از میان اطلاعات موجود، سرنخهایی پیدا کنیم که بتوانند مسیر بررسی بعدی را مشخص کنند. برای مثال، ممکن است کار با یک Domain شروع شود:
Domain ⬇️ Subdomainها ⬇️ IP Addressها ⬇️ Portها و Serviceها ⬇️ Technology Stack ⬇️ نقاط قابل بررسی ⬇️ Attack Surfaceدر اینجا اطلاعات مختلف به یکدیگر متصل میشوند و تصویری از سطح حمله سازمان شکل میگیرد. 🧠 یک ردتیمر حرفهای قبل از اینکه بپرسد: «چطور وارد این سیستم شوم؟» ابتدا سؤال های دیگری مطرح میکند: «چه دارایی هایی در اختیار Target است؟» «کدام دارایی ها برای سازمان اهمیت بیشتری دارند؟» «چه چیزهایی از بیرون قابل مشاهده است؟» «چه فناوری هایی در محیط استفاده میشوند؟» «چه مسیرهایی ارزش بررسی بیشتری دارند؟» و شاید مهم تر از همه: «چه چیزی را هنوز نمیدانم؟» همین سؤال آخر یکی از مهمترین بخش های Recon است. چون Recon یک فرآیند خطی و یکباره نیست. هر اطلاعات جدید میتواند سؤال تازهای ایجاد کند و هر سؤال تازه میتواند ما را به اطلاعات بیشتری برساند. به همین دلیل، Reconnaissance ترکیبی از ابزار، تحقیق دستی، OSINT، تحلیل و خلاقیت است. ابزارها میتوانند اطلاعات را جمعآوری کنند؛ اما این تحلیلگر است که باید ارتباط میان آن اطلاعات را پیدا کند و تشخیص دهد کدام سرنخ ارزش دنبال کردن دارد. در نهایت، هدف Recon این نیست که فقط بدانیم Target چه چیزی دارد. هدف این است که بفهمیم: تارگت چگونه ساخته شده، چه چیزی برای آن ارزشمند است و سطح حمله آن از کجا شکل میگیرد. ⚠️ نکته : تمام تکنیک ها و ابزارهای این مجموعه باید صرفاً روی سیستم ها، دامنه ها و دارایی هایی استفاده شوند که برای بررسی آنها مجوز قانونی دارید. اگر به این دسته پست ها علاقه مند هستید ، علاقه خود را با 🔥 نشان دهید. تا ادامه بدهیم.
💬 به نظر شما، اگر قرار باشد Recon یک Target را از صفر شروع کنید، اولین چیزی که بررسی میکنید چیست و چرا؟@TryHackBox #RedTeam
6 461
Repost from RedTeamAPT Academy
بخشی از دوره Windows Internal فصل 3
به جرات میتونم بگم فصل 3 پر از نکته های این شکلی هست
دوستان BlueTeam , Red Team , Soc این ویدیو رو از دست ندید
فصل 1 و 2 دوره منتشر شده است
@RedTeamAcademy
6 461
یک نظرسنجی برای شروع یک دوره جدید
اگر یک دوره کاملاً عملی درباره نگارش حرفهای گزارش های تست نفوذ و Red Team برگزار کنیم، چقدر براتون کاربردیه؟
🎯 اگر حداقل ۱۰ نفر علاقهمند جدی باشن، دوره رو شروع میکنیم. نظرتون چیه؟
6 461
🔖 دوره : تسلط بر نگارش گزارش های تست نفوذ و ردتیم
این دوره برای پنتسترها، اپراتورهای ردتیم و مشاوران امنیتی طراحی شده است که میخواهند گزارش نویسی خود را از فهرست های ساده آسیب پذیری به روایت های امنیتی متقاعدکننده و عملی ارتقا دهند. چه در حال نوشتن اولین گزارش تست نفوذ خود باشید و چه به دنبال خودکارسازی خط لوله گزارشنویسی با استفاده از مدلهای زبانی بزرگ (LLM) هستید،این دوره همه نیازهای شما را پوشش میدهد.
آنچه خواهید آموخت
▫️نوشتن گزارش های حرفهای تست نفوذ که باعث بهبود امنیت شوند
◾️تدوین خلاصه های اجرایی جذاب که با مخاطبان C-level (مدیران ارشد) همخوانی داشته باشد
▫️مستندسازی عملیات ردتیم با گزارشنویسی مبتنی بر روایت
◾️بهرهگیری از مدلهای زبانی بزرگ (مانند Claude، ChatGPT و غیره) برای تسریع و ارتقای کیفیت گزارشنویسی
▫️ساخت گزارش نویسی خودکار که ساعت ها زمان در هر پروژه صرفه جویی کند
▪️ ایجاد قالب های قابل استفاده مجدد، پایگاه داده یافتهها و جریان های کاری تیمی
@TryHackBox
6 461
🎯 چلنچ
فرض کنید یک Registry Run Key ناشناس پیدا کردید.
قبل از اینکه بگید «این Malicious هست»، اولین چیزی که بررسی میکنید چیه؟
📌 File Path
📌 Parent Process
📌 Creation Time
📌 User Context
یکی رو انتخاب کنید و بگید چرا اول سراغ اون میرید؟ کامنت کنید2/2 @TryHackBox #CyberSecurity #Persistence #Windows #Registry #RedTeam
6 461
🛡️ Registry Run Keys
یکی از مسیرهای Persistence در ویندوز
فرض کنید در یک Security Assessment متوجه میشید بعد از Login، یک برنامه خاص بهصورت خودکار اجرا میشه.
یکی از جاهایی که ارزش بررسی داره، Registry Run Keys هست.
بعضی از Registry Keyها میتونن باعث اجرای خودکار یک برنامه هنگام ورود کاربر به ویندوز بشن. به همین دلیل، اگر یک Entry ناشناس یا غیرمنتظره ببینیم، نمیتونیم بهسادگی از کنارش رد بشیم.
اما یک نکته مهم:
هر Entry ناشناسی لزوماً Malicious نیست.
برای اینکه بفهمیم واقعاً با یک رفتار مشکوک طرف هستیم یا نه، باید چند سرنخ رو کنار هم بذاریم:
🔹 چه برنامهای اجرا میشه؟
🔹 فایل دقیقاً کجا قرار داره؟
🔹 چه Userای اون رو ایجاد کرده؟
🔹 چه زمانی ایجاد شده؟
🔹 فایل Digital Signature داره؟
🔹 رفتارش با فعالیت عادی سیستم همخوانی داره؟
یک Defender معمولاً فقط خود Registry Entry رو نگاه نمیکنه؛ بلکه اون رو در کنار Processها، Eventها و سایر شواهد Endpoint بررسی میکنه.
1/2
@TryHackBox
#CyberSecurity #Persistence #Windows #Registry #RedTeam
