📌 از کجا بفهمیم SOC ما بالغ شده؟

بالغ بودن یک SOC فقط به تعداد نیروها، ابزارها یا تعداد Alertها بستگی نداره.

یک SOC زمانی داره بالغ‌تر میشه که کارها وابسته به افراد نباشن و بر اساس فرآیند مشخص انجام بشن.

مثلاً:

🔹 وظایف هر Tier مشخص باشه
🔹باید یکسری Runbook و Playbookهای قابل استفاده داشته باشه
🔹️ باید Log Sourceها و Coverage به‌صورت مداوم بررسی بشن
🔹 فرآیند Escalation مشخص باشه
🔹باید Incidentها درست مستند و قابل پیگیری باشن
🔹 سلامت SIEM و زیرساخت مانیتور بشه
🔹 باید Threat Hunting و Detection Engineering وجود داشته باشه
🔹 شاخص‌هایی مثل MTTD و MTTR اندازه‌گیری بشن
🔹 بعد از Incident، تیم بررسی کنه چه چیزی باید بهتر بشه


یک تست ساده:

اگر فردا یکی از افراد کلیدی SOC شما نباشه، آیا نفر بعدی می‌تونه کار رو بدون سردرگمی ادامه بده؟

اگر جواب «بله» باشه، یعنی بخشی از بلوغ عملیاتی رو به دست آوردید.

⚠️ و SOC بالغ یعنی فقط ابزار بیشتر نداشته باشیم؛
یعنی بتوانیم امنیت را به شکل قابل تکرار، قابل اندازه‌گیری و مستقل از افراد اجرا کنیم.

@Socroot

سلام👀

این چند روزه تا گردن درگیر کار بودم و به شدت مغزم خستس
ایشالا از امروز دوباره کارو شروع میکنیم❤️‍🔥

📌 الان داشتم دنبال یکسری سوال مصاحبه برای SOC میگشتم که یه ریپازیتوری جالب پیدا کردم .
سوالت خیلی خوبی داره و اومده سطح بندی کرده .
چک کردنش خالی از لطف نیست 👌🏻

https://github.com/soheilsec/Blue-Team-Interview


@Socroot

صبحت بخیر و شادی 🥛

@Socroot

📌 امروز توی شرکت به یه مشکل جالب در Splunk برخوردم...

لاگ‌های FortiGate وارد Splunk می‌شدن، اما بعضی وقت‌ها چندین Log به‌صورت یک String پیوسته وارد می‌شدن و Splunk همه‌شون رو به‌عنوان یک Event شناسایی می‌کرد.

مثلاً:

<188>date=...<189>date=...<189>date=...

در حالی که هرکدوم از این‌ها یک Log مستقل بودن.

🔎 بعد از بررسی مشخص شد LINE_BREAKER فعلی فقط بر اساس newline , Event ها رو جدا می‌کنه:


SHOULD_LINEMERGE = true
LINE_BREAKER = ([\r\n]+)


اما وقتی چند Log بدون newline به هم چسبیده باشن، Splunk نقطه‌ای برای شکستن Event نداره.

🔧 راهکار این بود که Event Breaking رو بر اساس ساختار خود Logهای FortiGate انجام بدیم:


SHOULD_LINEMERGE = false
LINE_BREAKER = ([\r\n]*)(?=<[^>]+>date=)


با این تغییر، Splunk شروع هر رکورد <...>date= رو به‌عنوان مرز یک Event جدید تشخیص می‌ده.

📌 نتیجه:

چند Log چسبیده → چند Event مستقل

این یکی از اون مشکلاتیه که شاید در نگاه اول به نظر برسه «Splunk لاگ رو درست Parse نمی‌کنه»، اما در واقع باید ببینی Splunk دقیقاً چه چیزی رو به‌عنوان مرز Event در نظر گرفته.


@Socroot

خب راجب این ...
منم خودم نظرم با اون ۴۸ نفری که گفتن (حداقل چندسال در زمینه نفوذ فعالیت کرده باشه) یکی هستش .
برای T1 و T2 بنظرم واقعا نیازه که حمله رو درک کرده باشه یا به قولی یه مدت تو این حوزه فعالیت کرده باشه .

📌 خلاصه که شما هرچقدر دانش offensive رو تقویت کنی قطعا عملکرد خیلی بهتری توی defensive داری.

@Socroot

یه جلسه دیگه از دوره +Security گذشت
خداروشکر فعلا با بچه هایی که هستن دوره خوبی رو بردیم جلو .🔥
ایشالا بشه یه دوره برای همین کانال برگذار کنم .
ولی ازبس توضیح دادم الان رسما کف کردم😂

کسی تو CTF راوین شرکت کرده؟

یسری از چلنج هایی که داده بود یجوری سخت بود که انگار تقصیر منه .

بعد از ۴ روز سخت ...
بعضی وقتا یسری اتفاقات که هیچکدوم بهم دیگه ربطی ندارن بصورت زنجیر وار واسط پیش میاد . ولی با این حال که بهم ربطی ندارن ، کاملا بهم مرتبط هستن .
درکل امیدوارم اگر کسی هر گیر و گوری تو زندگیش هست باز بشه .
بریم ادامه کارمون رو ببریم جلو ❤️‍🔥


@Socroot

🛡️ به عنوان یک SOC Analyst باید چه حملاتی رو بشناسیم؟

به عنوان یک SOC Analyst باید یک دید کلی و نسبتاً خوب به این حملات داشته باشید.

نه اینکه لزوماً بتونید همه‌شون رو Exploit کنید؛ ولی وقتی یه Alert جلوتون قرار گرفت، باید بدونید چه اتفاقی ممکنه افتاده باشه، چه Logهایی باید دنبالش بگردید و چطور بفهمید حمله فقط یه Attempt بوده یا واقعاً موفق شده.

بریم دسته‌بندی‌شون کنیم 👇

🌐 1. Web

سطح موردنیاز: متوسط

• SQL Injection
• XSS
• Command Injection
• LFI / RFI
• Path Traversal
• SSRF
• XXE
• File Upload
• Authentication Bypass
• Broken Access Control
• Deserialization
• RCE
• Directory Traversal
• Web Shell

اینجا باید بدونید مثلاً یه SQL Injection چه شکلی اتفاق میفته، چه چیزی داخل Web Server Log ثبت میشه و بعدش چطور بررسی کنیم که آیا مهاجم فقط Payload فرستاده یا واقعاً به Database دسترسی پیدا کرده.

------------------------

🌐 2. Network

سطح موردنیاز: متوسط تا خوب

• Port Scanning
• Network Service Exploitation
• SMB Vulnerabilities
• RDP Vulnerabilities
• SSH Vulnerabilities
• DNS Attacks
• ARP Spoofing
• MITM
• NTLM Relay
• SMB Relay
• VPN Vulnerabilities
• TLS/SSL Weaknesses
• DoS / DDoS
• Exploitation of Network Devices
• ضعف‌های Firewall / VPN / Router

چون بخش زیادی از Alertهایی که توی SOC می‌بینید از Network میاد، باید بتونید یه دید مناسب نسبت به Traffic داشته باشید.

مثلاً:

🔹 چه IPای به چه سیستمی وصل شده؟
🔹 روی چه Portی؟
🔹 آیا رفتار شبیه Scanning هست؟
🔹 آیا بعد از Exploitation اتفاق مشکوک دیگه‌ای افتاده؟


------------------------

💻 3. Endpoint

اینجا هم باید روی Windows و Linux یه دید مناسب داشته باشید.

🪟 Windows

• RCE
• Local Privilege Escalation
• Remote Privilege Escalation
• DLL Hijacking
• Service Exploitation
• UAC Bypass
• Credential Theft
• Token Impersonation
• LSASS-related Attacks
• Windows / AD Vulnerabilities
• Office Vulnerabilities
• PowerShell-related Exploitation

🐧 Linux

• Kernel Vulnerabilities
• Sudo Vulnerabilities
• SUID / SGID Abuse
• Service Exploitation
• SSH Vulnerabilities
• Local Privilege Escalation

اینجا دیگه فقط دیدن یه Process مشکوک کافی نیست.

باید بتونید اتفاقات رو کنار هم بذارید.

مثلاً:

Web Exploitation → اجرای Command → PowerShell → Credential Access → Lateral Movement

اینجاست که مشخص میشه یه Alert ساده داریم یا بخشی از یه Attack Chain بزرگ‌تره.



🎯 در نهایت قرار نیست یه SOC Analyst متخصص همه حوزه‌ها باشه.

ولی باید اون‌قدر از Web، Network و Endpoint Attackها بدونید که وقتی یه Alert وارد SIEM شد، بتونید بفهمید:

چی شده؟
از کجا شروع شده؟
هدف چی بوده؟
موفق شده یا نه؟
بعدش چه اتفاقی افتاده؟

این دقیقاً همون چیزیه که قراره توی Detection Engineering یاد بگیریم.

یعنی هر حمله رو فقط از دید مهاجم بررسی نمی‌کنیم؛

از دید SOC هم نگاهش می‌کنیم. 🔎


@Socroot

⚠️ یکی از ایرادهای رایج SOCها: فرآیند نامشخص Triage و Escalation

خیلی از SOCها Alert تولید می‌کنن، اما مشخص نیست بعدش چه اتفاقی باید بیفته:

🔹 چه کسی Alert رو بررسی کنه؟
🔹 چه لاگ‌هایی باید بررسی بشن؟
🔹 چه زمانی Alert به Incident تبدیل بشه؟
🔹 چه زمانی موضوع به Tier 2 یا تیم زیرساخت Escalate بشه؟

وقتی این مسیر مشخص نباشه، هر Analyst بر اساس تجربه شخصی خودش تصمیم می‌گیره؛ در نتیجه بعضی Alertها اشتباه بسته می‌شن و بعضی موارد مهم هم دیر بررسی می‌شن.

برای هر سناریو باید یک مسیر مشخص وجود داشته باشه:

Alert → Triage → Investigation → Decision → Escalation یا Closure

همچنین باید معلوم باشه در هر مرحله چه چیزی بررسی بشه، چه شواهدی ثبت بشه و مسئول ادامه کار چه کسیه.

🎯درضمن SOC حرفه‌ای فقط Alert تولید نمی‌کنه؛ برای هر Alert، مسیر مشخصی از تشخیص تا تصمیم‌گیری داره.


@Socroot

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

🔹️نوع حمله
🔹️تحلیل حمله
🔹️روند حمله مهاجم
🔹️چه لاگی برای هر حمله تولید میشه
🔹️کجاها این لاگ رو میشه گرفت
🔹️روند پیگیری لاگ ها از سورس های مختلف
🔹️روش دیتکشن حمله
🔹️Sigma Rule
🔹️Splunk Query
🔹️ELK Query

این موارد به شدت به درد بچه های SOC Tier 1 میخوره و برای مرور هم مفیده .
اینجا هم براتون میفرستم امیدوارم به کارتون بیاد ❤️


@Socroot

🧠 همیشه یه سوال بین بچه‌های SOC وجود داره:

«کارفرما دقیقاً از یه SOC Analyst چی می‌خواد؟»

خیلی‌ها فکر می‌کنن قراره فقط بشینی جلوی SIEM و Alertها رو یکی‌یکی بررسی کنی 🫪
ولی واقعیت خیلی بیشتر از این حرفاست.

کارفرما معمولاً ازت انتظار داره که:

🔹 وقتی یه Alert میاد، بدونی از کجا شروع کنی
🔹 بتونی تشخیص بدی یه Alert واقعاً Incident هست یا False Positive
🔹 لاگ‌های مختلف رو کنار هم بذاری و ازشون داستان بسازی
🔹 با Windows، Linux، Network و سرویس‌های مختلف آشنا باشی
🔹 بتونی رفتار مشکوک رو از رفتار عادی تشخیص بدی
🔹 با ابزارهایی مثل SIEM، EDR، Firewall، IDS/IPS کار کنی
🔹 مفهوم‌های MITRE ATT&CK رو بفهمی و فقط اسم تکنیک‌ها رو حفظ نکرده باشی
🔹 وقتی چیزی رو نمی‌دونی، بتونی درست Search و Investigate کنی
🔹 Incident رو درست Document و Escalate کنی
🔹 و مهم‌تر از همه، بتونی توضیح بدی:

««چرا فکر می‌کنم این Alert مشکوکه؟» 🤔»

نه اینکه فقط بگی:

❌ «این Alert Critical هست.»

بلکه بتونی بگی:

✅ «این Alert به دلیل این رفتارها مشکوکه، این لاگ‌ها شواهدش هستن، احتمالاً با فلان تکنیک MITRE مرتبطه و برای بررسی بیشتر باید این موارد رو چک کنیم.»

📌 در واقع کارفرما دنبال کسی نیست که فقط Alert بخونه؛
دنبال کسیه که بتونه از بین حجم زیادی از لاگ و Alert، مسئله امنیتی واقعی رو پیدا کنه.

پس اگه هدفت اینه که وارد SOC بشی، فقط روی کار با SIEM تمرکز نکن.

Network + Windows + Linux + Logs + Detection + Investigation

این‌ها چیزایی هستن که کم‌کم ازت یه SOC Analyst واقعی می‌سازن. 🔥



@Socroot

📌 یه جایی شنیده بودم می‌گفتن: «نمیشه لاگ کامندهایی که داخل PowerShell اجرا می‌شن رو گرفت.»

الان داشتم مبحث "Windows Log Analysis" رو می‌خوندم که رسیدم به این بخش و گفتم این موضوع رو با شما هم به اشتراک بذارم. 😄

برای تحلیل اجرای PowerShell، چندتا لاگ مهم داریم:

🔹 Event ID 4104 — Script Block Logging
محتوای Command یا Script اجراشده رو ثبت می‌کنه. برای فهمیدن اینکه دقیقاً چه دستوری اجرا شده، خیلی مهمه.

🔹 Event ID 4103 — Module Logging
اجرای Commandها و Moduleهای PowerShell رو ثبت می‌کنه و می‌تونه جزئیات بیشتری از فعالیت PowerShell بده.

🔹 Event ID 4688 — Process Creation
ایجاد پردازش "powershell.exe" رو ثبت می‌کنه. این لاگ به‌تنهایی محتوای کامل Command رو نشون نمی‌ده، اما برای فهمیدن اینکه چه پردازشی اجرا شده و چه کسی اون رو اجرا کرده، کاربردیه.

مثلاً:

powershell.exe -ExecutionPolicy Bypass -Command "Get-Process"

در این سناریو:

- "4688" --> ایجاد پردازش PowerShell
- "4104" --> محتوای Script یا Command اجراشده
- "4103" --> جزئیات اجرای Command و Moduleها

🎯 پس وقتی می‌گیم «لاگ کامندها رو می‌گیریم»، منظور این نیست که فقط با "4688" همه‌چیز رو می‌بینیم؛ باید Logging مناسب PowerShell فعال باشه.

⚠️ برای یک SOC Analyst، دیدن "powershell.exe" فقط شروع ماجراست؛ مهم اینه که بفهمیم داخلش چه چیزی اجرا شده.

@Socroot

#خارج_از_امنیت

📌 چند ابزار کاربردی برای دانشجوها و محقق‌ها 🎓

اگه زیاد با مقاله، تحقیق، یادداشت و ارائه سروکار داری، این چند ابزار می‌تونن واقعاً کارت رو راحت‌تر کنن:

🔹 Zotero
برای مدیریت منابع و مقاله‌ها؛ می‌تونی منابع رو دسته‌بندی کنی و هنگام نوشتن، Citation اضافه کنی.

🔹 Connected Papers
یک مقاله رو بهش می‌دی و مقالات مرتبط رو به شکل یک نمودار نشون می‌ده؛ برای پیدا کردن منابع جدید خیلی جالبه.

🔹 Excalidraw
برای کشیدن دیاگرام، فلوچارت و توضیح تصویری مطالب، بدون اینکه درگیر طراحی پیچیده بشی.

🔹 Obsidian
برای یادداشت‌برداری و وصل‌کردن مطالب به هم؛ مخصوصاً وقتی داری یک موضوع رو عمیق یاد می‌گیری.

🔹 Google Scholar
برای پیدا کردن مقاله و بررسی منابع علمی، به‌جای اینکه فقط به نتایج معمولی گوگل تکیه کنی.

ابزار خوب قرار نیست جای یادگیری رو بگیره؛ باید کمک کنه بهتر یاد بگیری و منظم‌تر کار کنی.

@Socroot

🛡اولین آسیب پذیری از دسته بندی آسیب پذیری های Web با عنوان Sql Injection تکمیل شد .
تا مطالعش نکنید متوجه جذابیت کار نمیشید 🩸
(با Obsidian بازش کنید)

@Socroot