گروهمون 👇🏻

https://t.me/socroot_group

📌 یه نکته ساده ولی خیلی مهم در تحلیل Alertها
وقتی یک Alert می‌بینی، سریع نرو سراغ اینکه «این حمله هست یا نه؟»

اول بپرس:
«این سیستم معمولاً چه رفتاری داره؟»
مثلاً روی یک سرور، اجرای PowerShell ممکنه کاملاً عادی باشه.
اما اگر همون PowerShell روی یک Domain Controller اجرا بشه، توسط یک User غیرمعمول و با یک Command Line عجیب، ارزش بررسی خیلی بیشتری پیدا می‌کنه.


یعنی یک Event ثابت، روی سیستم‌های مختلف می‌تونه Risk متفاوتی داشته باشه.
پس همیشه این سه مورد رو کنار هم ببین:

Event + Asset + User

📌 تحلیل خوب فقط بررسی کردن اینکه «چه اتفاقی افتاده» نیست؛
باید بدونی کجا، توسط چه کسی و در چه شرایطی اتفاق افتاده.


@Socroot

📌 وقتی یه URL مشکوک می‌بینی، مستقیم بازش نکن.

اول بندازش توی urlscan.io.

صفحه رو بررسی می‌کنه و اطلاعاتی مثل IPهای مقصد، Domainها، Redirectها، Requestها و Screenshot صفحه رو در اختیارت میذاره.

مثلاً می‌تونی متوجه بشی یک لینک ظاهراً ساده، در پشت صحنه به چه سرویس‌ها و آدرس‌هایی ارتباط برقرار می‌کنه.

⚠️ برای بررسی اولیه Phishing URLها و استخراج IOC، ابزار کاربردی‌ایه.

🔗 urlscan


@Socroot

📌 وظایف یک کارشناس SOC Tier 1 چیه؟

کارشناس سطح یک معمولاً اولین نفریه که با هشدارهای امنیتی سروکار داره.

کار اصلیش اینه که هشدارها رو بررسی کنه، اطلاعات لازم رو جمع کنه و مشخص کنه کدوم مورد نیاز به بررسی بیشتر داره.

🔹 بررسی هشدارهای جدید در سامانه مدیریت رخدادها

🔹 بررسی دلیل ایجاد هر هشدار و جمع‌آوری اطلاعات مرتبط

🔹 بررسی کاربر، سیستم، آدرس IP، پردازش و زمان رخداد

🔹 بررسی لاگ‌های مرتبط و ساختن خط زمانی اتفاقات

🔹 بررسی آدرس IP، دامنه، فایل و سایر شاخص‌های مشکوک

🔹 تشخیص موارد عادی، مثبت کاذب و فعالیت‌های مشکوک

🔹 اولویت‌بندی هشدارها بر اساس شدت و میزان ریسک

🔹 ثبت نتیجه بررسی در سامانه تیکتینگ

🔹 ارجاع موارد مهم به کارشناس سطح دو

🔹 پیگیری هشدارها و تیکت‌های باز

🔹 بررسی وضعیت دریافت لاگ از تجهیزات و سامانه‌های مختلف

🔹 بررسی سلامت خود سامانه مدیریت رخدادها


📌 در واقع کارشناس سطح یک قرار نیست همه رخدادها رو از ابتدا تا انتها حل کنه.

⚠️ وظیفه اصلیش اینه که هشدار رو درست بررسی کنه، شواهد لازم رو جمع کنه و تصمیم بگیره که مورد باید بسته بشه یا برای بررسی بیشتر ارجاع داده بشه.

یک روند ساده برای کار روزانه:

"Alert" → "Triage" → "Investigation" → "Decision" → "Documentation" → "Escalation"

@Socroot

سعی میکنم تو چندتا پست یه Mind Map برای هرکدوم از این وظایف براتون ایجاد کنم تا شاید درک هر بخش چه برای خودم و چه برای شما راحتر باشه .

📌 بررسی هشدارهای جدید در سامانه مدیریت رخدادها

🎯 دیدگاه T1

وقتی یه Alert میاد، قرار نیست فقط اسمش رو ببینیم و سریع بگیم «خب، حمله شده!»

مثلاً اگه Alert نوشته باشه:

"Brute Force Detected"

اول باید ببینیم دقیقاً چه اتفاقی افتاده.

🔹 این Alert با چه Ruleای ایجاد شده؟

🔹 چه زمانی اتفاق افتاده؟

🔹 روی کدوم سیستم بوده؟

🔹 مربوط به چه کاربریه؟

🔹 چند بار این اتفاق تکرار شده؟

🔹 Source و Destination کجا هستن؟

🔹 Alert مشابه یا مرتبط دیگه‌ای هم داریم؟

🧠 نقشه ذهنی ساده:

Alert
│
├── اسم Alert
├── Severity
├── Detection Rule
├── زمان رخداد
│
├── Source
│ ├── IP
│ ├── Host
│ └── User
│
├── Destination
│ ├── IP
│ ├── Host
│ └── Service
│
├── تعداد رخداد
│
└── Alertهای مرتبط

⚙️ کاری که T1 باید انجام بده:

قبل از اینکه بره سراغ Investigation، باید یه تصویر اولیه از Alert داشته باشه.

یعنی:

Alert
↓
Context
↓
Initial Understanding


به زبان ساده، T1 باید اول بفهمه:

«دقیقاً چه اتفاقی افتاده و این Alert چرا ایجاد شده؟»

بعد بره سراغ بررسی‌های عمیق‌تر.


@Socroot

📌 بررسی دلیل ایجاد Alert و جمع‌آوری اطلاعات مرتبط

🎯 دیدگاه T1

حالا که فهمیدیم Alert چیه، قدم بعدی اینه که بفهمیم:

«اصلاً چرا این Alert ایجاد شده؟»

مثلاً یه Alert داریم با عنوان:

"Suspicious PowerShell Execution"

قرار نیست فقط به همین عنوان اکتفا کنیم.

باید بریم ببینیم چه Event یا چه رفتاری باعث شده Rule فعال بشه.

🔹 کدوم Event باعث ایجاد Alert شده؟

🔹 Rule دقیقاً دنبال چه رفتاری بوده؟

🔹 چه Command یا Processی اجرا شده؟

🔹 این رفتار قبل از Alert هم اتفاق افتاده؟

🔹 بعد از Alert چه اتفاقی افتاده؟

🔹 Eventهای مرتبط دیگه‌ای داریم؟

🔹 این رفتار برای این سیستم یا کاربر عادیه یا نه؟


🧠 نقشه ذهنی ساده:

Alert
│
├── Detection Rule
│
├── Trigger Event
│
├── Related Events
│
├── Before
│ ├── Login
│ ├── Process
│ └── Network
│
├── Alert
│
└── After
├── Process
├── File
└── Network

⚙️ کاری که T1 باید انجام بده:

اینجا باید از خود Alert عبور کنه و برسه به شواهد.

یعنی:

Alert
↓
Why?
↓
Evidence
↓
Context


در واقع T1 باید بتونه جواب این سؤال رو بده:

«چه اتفاقی افتاد که این Rule تصمیم گرفت Alert ایجاد کنه؟»

هرچی این قسمت دقیق‌تر بررسی بشه، تصمیم نهایی T1 هم قابل‌اعتمادتر میشه.


@Socroot

این عدم حمایت واقعا از برو بچه های دنیای سایبری بعیده 🙄

بیخوابی کشیدن خیلی بهتر از رویا دیدن واسه هدفته.


@Socroot

📌 بررسی User، System، IP، Process و زمان رخداد

🎯 دیدگاه T1

حالا که فهمیدیم Alert چرا ایجاد شده، باید بفهمیم چه کسی، روی چه سیستمی و دقیقاً چه کاری انجام داده.

اینجا نباید فقط به یک لاگ نگاه کنیم. باید قطعات مختلف رو کنار هم بذاریم تا بفهمیم واقعاً چه اتفاقی افتاده.

مثلاً برای یه Alert مربوط به اجرای مشکوک PowerShell، باید ببینیم:

🔹 چه کاربری PowerShell رو اجرا کرده؟

🔹 روی کدوم سیستم اجرا شده؟

🔹 Source IP چی بوده؟

🔹 مقصد کجا بوده؟

🔹 چه Processی اجرا شده؟

🔹 Command Line چی بوده؟

🔹 این اتفاق دقیقاً چه زمانی رخ داده؟


🧠 نقشه ذهنی ساده:

Event
│
├── User
│ └── چه کسی؟
│
├── Host
│ └── روی کدام سیستم؟
│
├── Source
│ └── از کجا؟
│
├── Destination
│ └── به کجا؟
│
├── Process
│ ├── Process Name
│ ├── Parent Process
│ └── Command Line
│
└── Time
├── Start
└── End

⚙️ کاری که T1 باید انجام بده:

اینجا باید بتونه از بین اطلاعات مختلف، یه تصویر ساده از رخداد بسازه:

WHO?
↓
WHAT?
↓
WHERE?
↓
WHEN?
↓
HOW?

مثلاً در نهایت بتونه بگه:

«کاربر X روی سیستم Y، در ساعت Z، پردازش PowerShell رو با این Command Line اجرا کرده و با IP مقصد ارتباط داشته.»

⚠️ این اطلاعات پایه‌ی Investigation هستن.

🔹️ چون تا وقتی ندونی چه کسی، کجا، کی و دقیقاً چه کاری انجام داده، نمی‌تونی درباره مشکوک یا عادی بودن رفتار تصمیم درستی بگیری.

@Socroot

📌 انواع لاگ‌هایی که یک SOC Analyst باید بشناسه

در SOC برای بررسی یک اتفاق امنیتی معمولاً به یک نوع لاگ اکتفا نمی‌کنیم. هر منبع، بخشی از اتفاق رو به ما نشون میده.

🔹️ لاگ‌های شبکه

اطلاعات مربوط به ارتباطات شبکه مثل مبدأ، مقصد، پورت و پروتکل.

برای بررسی ارتباطات مشکوک، اسکن و ترافیک غیرعادی استفاده میشه.

🔹️ لاگ‌های Endpoint

اطلاعات مربوط به سیستم‌های کاربران و سرورها؛ مثل اجرای Process، ایجاد فایل، سرویس‌ها و تغییرات سیستم.

برای بررسی رفتار مشکوک روی سیستم خیلی مهمه.

🔹️ لاگ‌های احراز هویت

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

برای بررسی حملاتی مثل Brute Force و استفاده غیرعادی از حساب‌ها کاربرد داره.

🔹️ لاگ‌های Windows

رویدادهای ثبت‌شده توسط ویندوز، مثل ورود کاربران، اجرای Process، تغییرات حساب‌ها و دسترسی‌ها.

Event Log و Sysmon از منابع مهم این بخش هستن.

🔹️ لاگ‌های Firewall

ترافیک مجاز و مسدودشده توسط فایروال رو ثبت می‌کنن و برای بررسی ارتباطات ورودی و خروجی کاربرد دارن.

🔹️ لاگ‌های Web و Proxy

اطلاعات مربوط به درخواست‌های وب و سایت‌هایی که کاربران بهشون دسترسی داشتن.

برای بررسی URLهای مشکوک، دانلود فایل و فعالیت‌های غیرعادی مفیدن.

🔹️ لاگ‌های Email

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

برای بررسی حملات فیشینگ کاربرد زیادی دارن.

🔹️ لاگ‌های Cloud

فعالیت کاربران و سرویس‌ها در محیط‌های ابری؛ مثل ورود، تغییر تنظیمات و تغییر سطح دسترسی.


📌 نکته مهم:

برای تحلیل یک Incident معمولاً باید چند منبع لاگ رو کنار هم قرار بدیم.

مثلاً:

"Network Log" → ارتباط مشکوک رو پیدا می‌کنیم.

"Endpoint Log" → می‌فهمیم چه Processی این ارتباط رو ایجاد کرده.

"Authentication Log" → مشخص می‌کنیم چه کاربری درگیر بوده.


در واقع هر لاگ فقط یک بخش از ماجرا رو نشون میده.


@Socroot

به شدت مراقب خودتون باشید
این ویروس جدیده بدجور تو مخیه

📌معادل ابزار های Sysinternals در Linux

اگر با مجموعه ابزارهای Sysinternals کار کرده باشید، احتمالاً موقع کار با Linux دنبال معادل بعضی از این ابزارها می‌گردید.

در این تصویر، تعدادی از ابزارهای پرکاربرد Sysinternals در کنار معادل Linux و کاربرد هرکدوم قرار گرفته.

از بررسی Process و ارتباطات شبکه گرفته تا لاگ‌های سیستم، Permission و تحلیل فایل‌ها.

یک مرجع کوتاه برای زمانی که بین Windows و Linux جابه‌جا می‌شید.

@Socroot

📌 توی مصاحبه SOC فقط جواب درست مهم نیست؛ نحوه فکر کردنت مهمه.

ممکنه ازت بپرسن:

«اگر یک Alert مربوط به Brute Force ببینی، چیکار می‌کنی؟»

لازم نیست سریع بگی:

«IP رو بلاک می‌کنم.»

بهتره روند فکریت رو توضیح بدی:

اول بررسی می‌کنم Alert چرا ایجاد شده.

بعد مبدأ تلاش‌ها، کاربر، مقصد و بازه زمانی رو بررسی می‌کنم.

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

بعد لاگ‌های مرتبط رو بررسی می‌کنم تا ببینم این فعالیت فقط یک مورد بوده یا بخشی از یک الگوی بزرگ‌تر.

در نهایت بر اساس شواهد تصمیم می‌گیرم که False Positive هست، فعالیت مشکوکه یا نیاز به Escalation داره.

📌 چیزی که مصاحبه‌کننده می‌خواد ببینه اینه که:

وقتی یک Alert جلوت قرار می‌گیره، آیا چارچوب مشخصی برای تحلیل داری یا نه.

پس برای مصاحبه SOC، فقط حفظ کردن تعریف‌ها کافی نیست؛ تمرین کن که طرز فکرت رو مرحله‌به‌مرحله توضیح بدی.


@Socroot

سخت تر از برسی و تحلیل Soc ، برنامه ریزی برای انتخاب واحد دانشگاهِ .

🔴 حدودا نیم ساعت پیش داشتم یه مطلبی رو مطالعه میکردم رسیدم به یه نکته خوب و جالب :

هر موردی که داخل Powershell درحال لود شدن هست به طور مستقیم روی Memory میشینه .
@Socroot

📌 یک نکته مهم برای هر تیم SOC: همه چیز نباید از صفر ساخته بشه.

اگر یک تحلیلگر برای بررسی هر اتفاق، دوباره از اول دنبال Query، لاگ و روش بررسی بگرده، زمان زیادی از تیم گرفته میشه.

بهتره برای موارد پرتکرار، یک سری Runbook داشته باشید.

مثلاً برای:

- بررسی Brute Force
- بررسی Login مشکوک
- بررسی اجرای PowerShell
- بررسی ارتباط با IP مشکوک
- بررسی Malware روی Endpoint
- بررسی Account مشکوک


🔹️ داخل هر Runbook مشخص باشه:

چه چیزهایی باید بررسی بشه؟
چه لاگ‌هایی لازمه؟
چه Queryهایی باید اجرا بشه؟
چه زمانی مورد بسته بشه؟
چه زمانی باید به Tier 2 ارجاع داده بشه؟


📌 اینطوری تحلیلگر به جای اینکه هر بار روش کار رو از خودش بسازه، یک مسیر مشخص برای بررسی داره.

و Runbook خوب، تجربه یک تحلیلگر رو تبدیل به یک فرآیند قابل استفاده برای کل تیم می‌کنه.


@Socroot

📌 اگر مهاجم بودی، اول کجا رو هدف می‌گرفتی؟

فرض کن وارد یک شبکه شدی.

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

حالا باید بفهمی:

چه کاربرهایی روی این سیستم هستن؟
این سیستم به کجاها دسترسی داره؟
چه سرویس‌هایی فعال هستن؟
چه سیستم‌های دیگه‌ای باهاش ارتباط دارن؟
آیا Credential یا فایل حساسی روی سیستم وجود داره؟

⚠️ اینجا چیزی که برای مهاجم مهمه، فقط اجرای یک ابزار نیست؛ جمع‌آوری اطلاعات و پیدا کردن مسیر بعدیه.

از طرف SOC هم دقیقاً همین رفتارها ارزش بررسی دارن.

مثلاً ترکیب:

"whoami"
"ipconfig"
"net user"
"netstat"
"nltest"

اگر این دستورات پشت سر هم و در شرایط غیرعادی اجرا بشن، می‌تونه نشون بده کسی داره محیط رو می‌شناسه.


📌 نکته جالب اینجاست:

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

پس گاهی برای پیدا کردن یک حمله، لازم نیست منتظر خرابکاری بمونی؛
مرحله شناخت محیط هم می‌تونه سرنخ مهمی باشه.


@Socroot

📌 چطور بفهمم یک SOC Tier 1 واقعاً چطور کار می‌کنه؟

یکی از مشکلات رایج اینه که خیلی چیزها رو درباره SOC یاد می‌گیری، ولی وقتی وارد محیط واقعی می‌شی نمی‌دونی دقیقاً باید چه کاری انجام بدی.

برای اینکه روند کاری Tier 1 رو یاد بگیری، فقط مطالعه کافی نیست؛ باید فرآیند عملیاتی رو تمرین کنی.

مثلاً باید بدونی:

🔹 Alert چطور ایجاد میشه و چرا ایجاد شده
🔹 چطور Alert رو Triage کنی
🔹 چه لاگ‌هایی رو برای بررسی پیدا کنی
🔹 چطور User، Host، IP و Process رو بررسی کنی
🔹 چطور Timeline بسازی
🔹 چطور IOC رو بررسی کنی
🔹 چطور False Positive رو تشخیص بدی
🔹 چطور Severity و Priority رو تعیین کنی
🔹 چطور Case یا Ticket ایجاد و مستند کنی
🔹 چه زمانی باید موضوع رو به Tier 2 Escalate کنی
🔹 بعد از Escalation چه اطلاعاتی باید تحویل بدی
🔹 چطور وضعیت Log Sourceها و Agentها رو بررسی کنی
🔹 چطور Pending Caseها و Incidentهای باز رو پیگیری کنی


📌 برای تمرین هم می‌تونی سناریوهای واقعی برای خودت بسازی:

Brute Force → بررسی → جمع‌آوری شواهد → تصمیم → ثبت → Escalation

PowerShell مشکوک → بررسی Process Tree → بررسی Command Line → Timeline → تصمیم

ارتباط با IP مشکوک → پیدا کردن Host → پیدا کردن Process → بررسی User → مستندسازی

وقتی چند بار این سناریوها رو از ابتدا تا انتها انجام بدی، کم‌کم متوجه می‌شی که کار Tier 1 فقط «دیدن Alert» نیست.

پس Tier 1 یعنی یک فرآیند مشخص برای تشخیص، بررسی، مستندسازی و ارجاع رخدادها.

@Socroot

پیاده سازی این موضوع هم واقعا کاری نداره
یه vm لازمه
یه SIEM که روی سیستم اصلی بالا هستش
حالا حتما نیاز نیست SIEM باشه ، شما با Sysmon هم میتونی کارتو انجام بدی‌.
ولی SIEM باشه بهتره .


@Socroot