وقتی 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

وقتی یک 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 → Impac

t

🎯 ذهنیت باگ هانتر

به‌ جای اینکه فقط بپرسیم:
«چه چیزی پیدا کردم؟»
باید بپرسیم:

واقعاً با این چیزی که پیدا کردم، چه کاری میتونم انجام بدم

همین تغییر نگاه، یک Recon ساده رو به مسیر واقعی Vulnerability Discovery تبدیل می‌کنه.

💬 حالا سؤال:

اگر در Source Code یک Chrome Extension به یک API Key یا Token برخورد کنید، اولین چیزی که بررسی میکنید چیه؟

🔹 API Key
🔹 Endpoint
🔹 Permissions
🔹 Token Usage

انتخابتون رو بنویسید و بگید چرا. 👇

@TryHackBox

#باگ_بانتی #امنیت_سایبری #نکات_باگ_بانتی #امنیت_وب #امنیت_اپلیکیشن #تست_نفوذ #امنیت_اطلاعات

🎯 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
#باگ_بانتی

دعوت به همکاری | UI/UX Designer

برای توسعه و تکمیل یک پروژه واقعی و در حال رشد در حوزه امنیت سایبری (Cyber Security)، به یک نیروی UI/UX Designer خلاق، مسئولیت‌ پذیر و علاقه‌مند به کار تیمی دعوت به همکاری میکنیم.

اگر در زمینه طراحی UI/UX فعالیت دارید و علاقه‌مند هستید روی یک محصول واقعی و قابل ارائه در رزومه و Portfolio کار کنید، خوشحال میشویم با شما آشنا شویم.

مزایای همکاری

🔹 فعالیت روی یک پروژه واقعی و قابل ارائه در رزومه
🔹 امکان ثبت تجربه همکاری در Portfolio
🔹 فرصت ارائه ایده و مشارکت در تصمیم‌ های طراحی محصول
🔹 تجربه همکاری با اعضای تیم در حوزه‌های Cyber Security و Software Development
🔹 فرصت یادگیری و توسعه مهارت‌ های تخصصی در یک محیط فنی
🔹 امکان ادامه همکاری و ایجاد فرصت‌ های بیشتر در صورت موفقیت همکاری
🔹 فضای کاری دوستانه، حرفه‌ای و تیم‌محور

شرایط موردنظر

آشنایی با Figma و اصول طراحی UI/UX، طراحی Responsive، User Flow و طراحی محصول از مهارت‌های موردنظر ماست.

تسلط کامل بر تمام موارد الزامی نیست؛ انگیزه، مسئولیت‌پذیری، خلاقیت و علاقه به یادگیری برای ما اهمیت زیادی دارد.

📩 اگر علاقه‌مند به همکاری هستید، از آیدی زیر با ما در ارتباط باشید:
@ThbxSupport

در صورت امکان، نمونه‌کارها یا Portfolio خود را نیز ارسال کنید.

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

📌 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
#امنیت_سایبری #تست_نفوذ

🔍 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
#باگ_بانتی

ا🎫 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