📌 بررسی دلیل ایجاد 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

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

📌 یه سایت برای پیدا کردن APIهای آماده

🔗 Public APIs

اگر برای پروژه‌ات دنبال API هستی ولی نمی‌خوای از صفر یک سرویس بسازی، این سایت مجموعه‌ای از APIهای عمومی رو دسته‌بندی کرده.

از آب‌وهوا و داده‌های جغرافیایی گرفته تا بازی، فیلم، داده‌های علمی و سرویس‌های مختلف.

برای پیدا کردن ایده برای پروژه‌های برنامه‌نویسی هم جالبه.

@Socroot

📌 گاهی یک حساب کاربری، از یک Malware خطرناک‌تره

فرض کن یک مهاجم به Credential یک کاربر دسترسی پیدا کرده.

لازم نیست فوراً Malware اجرا کنه.

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

اینجاست که بررسی رفتار حساب‌های کاربری اهمیت پیدا می‌کنه.

مثلاً:

ورود از یک سیستم جدید
⬇️
دسترسی به یک سرور غیرمعمول
⬇️
تلاش برای دسترسی به منابع حساس
⬇️
تغییر سطح دسترسی

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

📌 به همین دلیل در امنیت، فقط دنبال فایل و Malware نباش.

گاهی خودِ Account تبدیل به مسیر حرکت مهاجم در شبکه میشه.


@Socroot

بالاخره تموم شد .

📌 یک نکته مهم درباره دسترسی‌ها

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

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

با گذشت زمان، این دسترسی‌های اضافی جمع میشن و سطح ریسک رو بالا می‌برن.

برای همین باید به‌صورت دوره‌ای بررسی بشه:

چه کسی به چه چیزی دسترسی داره؟
آیا این دسترسی هنوز لازمه؟
آخرین استفاده از این دسترسی چه زمانی بوده؟
آیا سطح دسترسی با وظیفه فعلی کاربر متناسبه؟

⚠️ اصل ساده‌ای وجود داره:

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

این همون مفهوم Least Privilege هست.


@Socroot

یه PDF با عنوان ۴۰۰ نکته کاربردی +Security همراه با یکی از اساتیدم براتون آماده کردیم
سعی شده تمام موارد داخل این ۴۰۰ نکته پوشش داده بشه .
یکم دیگه همینجا ارسال میکنم براتون و امیدوارم براتون مفید باشه ❤️🙏🏻

📘 ۴۰۰ نکته +Security تکمیل شد! 🛡
مجموعه‌ای از مهم‌ترین مفاهیم و نکات کلیدی امنیت سایبری برای مرور سریع و یادگیری بهتر.
پایان این کتاب، شروع مسیر یادگیری عمیق‌تر در دنیای Cyber Security است.

@Socroot

در کنار اینکه اینو مطالعه میکنید یه همتی کنید بشیم ۵۰۰ نفر ❤️😂