📌 توی مصاحبه 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

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

📌یک بار برای همیشه ؛ SOC و NOC یکی نیستن؛ حتی اگر بعضی وظایفشون به هم نزدیک باشه.

توی بعضی مجموعه‌ها به‌خاطر کمبود نیرو، وظایف NOC و SOC با هم ترکیب میشن و یک نفر باید همزمان چندین کار متفاوت انجام بده.

اما این موضوع می‌تونه روی کیفیت هر دو تیم تأثیر بذاره.

وظیفه اصلی NOC بیشتر روی دسترس‌پذیری و عملکرد زیرساخت متمرکزه؛ مثل:

- بررسی وضعیت تجهیزات شبکه
- بررسی قطعی سرویس‌ها
- Monitoring زیرساخت
- بررسی Performance
- پیگیری مشکلات ارتباطی و سرویس‌ها

در مقابل، SOC روی امنیت تمرکز داره؛
مثل:

- بررسی رخدادهای امنیتی
- تحلیل لاگ‌ها
- Triage و Investigation
- بررسی رفتارهای مشکوک
- Incident Response
- Threat Intelligence

🔹️ مشکل از جایی شروع میشه که کارهای عملیاتی NOC باعث بشن تمرکز تحلیلگر SOC از وظایف امنیتی خودش خارج بشه.

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

⚠️ البته بین این دو تیم ارتباط و همکاری کاملاً ضروریه.


📌 در نهایت:

NOC → پایداری و عملکرد زیرساخت

SOC → امنیت و شناسایی و پاسخ به تهدیدها

همکاری لازم است؛
اختلاط وظایف نه.

@Socroot

📌 از هر Asset توی شبکه چه لاگی باید بگیریم؟ 🤔

یکی از اشتباهات رایج توی SOC اینه که فکر کنیم:

«هرچی لاگ بیشتر، بهتر!»

نه لزوماً.
مهم اینه بدونیم از هر دارایی چه لاگی و برای چه Use Caseای نیاز داریم.

مثلاً:

🖥️ Windows Endpoint

- Login / Logout
- Process Creation
- PowerShell
- File & Registry Changes
- USB Events
- Windows Security Events
- Network Connections

🐧 Linux

- Authentication
- SSH
- sudo
- Process Execution
- System Events
- Network Connections
- Audit Logs

🌐 Firewall

- Allowed / Denied Traffic
- VPN
- NAT
- Admin Login
- Configuration Changes
- IPS/AV Events
- Web Filtering

🔀 Switch / Router

- Authentication
- Configuration Changes
- Interface Status
- Routing Changes
- ACL Events
- DHCP / DNS Events
- NetFlow

🌍 Web Server

- Access Logs
- Error Logs
- Authentication
- HTTP Methods
- Status Codes
- Client IP
- User-Agent

🗄️ Database

- Login / Logout
- Failed Authentication
- Query Activity
- Privilege Changes
- Account Changes
- Audit Logs

📧 Email Server

- Login
- Mail Send/Receive
- Attachment Events
- URL Clicks
- Authentication Failures
- Admin Changes

اما یه نکته مهم‌تر:

قبل از جمع کردن هر لاگ، باید بدونیم قراره باهاش چه چیزی رو Detect کنیم.

مثلاً اگر Use Case ما تشخیص اجرای مشکوک PowerShell باشه، فقط داشتن Windows Event Log کافی نیست؛ باید Eventهای مرتبط با Process و PowerShell رو هم درست Collect کنیم.

🎯 پس سؤال درست این نیست:

❌ «از این Asset چه لاگ‌هایی بگیریم؟»

بلکه:

✅ «برای این Asset چه Threatهایی مهمه و برای Detect کردنشون چه لاگ‌هایی لازم داریم؟»

این دیدگاه باعث میشه هم حجم لاگ‌های اضافی کمتر بشه، هم Visibility واقعی SOC بیشتر بشه.

@Socroot

📌درکل Runbook و Playbook توی SOC چه فرقی دارن؟

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

در اصل Playbook میگه وقتی با یک سناریوی امنیتی مواجه شدیم، کلاً چه مسیری رو طی کنیم.

مثلاً برای یک Ransomware مشخص می‌کنه:

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


اما Runbook میگه هر کدوم از این کارها رو دقیقاً چطور انجام بدیم.

مثلاً:

چطور Endpoint رو ایزوله کنیم؟
چطور لاگ جمع کنیم؟
چطور Process Tree رو بررسی کنیم؟
چطور Hash یک فایل رو بررسی کنیم؟


⚠️ پس خیلی خلاصه:

Playbook = مسیر کلی کار

Runbook = روش انجام یک کار مشخص

در یک SOC درست‌وحسابی، این دوتا کنار هم استفاده میشن تا تحلیلگر وسط یک Incident ندونه «خب حالا باید چیکار کنم؟»


@Socroot

❓ چه زمانی یک Log Source تبدیل به نقطه کور می‌شود؟

فقط اینکه یک Log Source داخل SIEM اضافه شده، به این معنی نیست که همیشه داریم اطلاعاتش رو دریافت می‌کنیم.

ممکنه یک سرور قبلاً لاگ ارسال می‌کرده، اما بعداً:

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


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

برای همین باید وضعیت Log Sourceها دائماً بررسی بشه:

آخرین لاگ چه زمانی دریافت شده؟
حجم لاگ طبیعی هست؟
ایا Agent سالمه؟
آیا Eventهای موردنیاز هنوز ارسال میشن؟


📌 یک Log Source وقتی خطرناک میشه که فکر کنیم داریم می‌بینیمش، ولی در واقع دیگه چیزی ازش دریافت نمی‌کنیم.

⚠️ به همین دلیل، Monitoring سلامت Log Sourceها خودش یکی از بخش‌های مهم عملیات SOC محسوب میشه.


@Socroot

📌 یک SOC Tier 1 باید با چه تکنولوژی‌هایی کار کرده باشه؟

برای Tier 1 لازم نیست متخصص همه ابزارهای امنیتی باشی؛ اما باید با تکنولوژی‌هایی که هر روز در محیط SOC باهاشون سروکار داری، کار عملی کرده باشی.

مثلاً:

🖥️ SIEM
مثل Splunk یا Elastic
باید بتونی لاگ‌ها رو Search کنی، Query بنویسی، Eventها رو بررسی کنی و Dashboard و Ruleها رو درک کنی.

🛡️ EDR / Endpoint Security
مثل Microsoft Defender
باید Process، Process Tree، Command Line، File و رفتار Endpoint رو بررسی کنی.

📊 Windows Event Logs و Sysmon
باید Eventهای مهم ویندوز رو بشناسی و بتونی از روی لاگ‌ها بفهمی روی سیستم چه اتفاقی افتاده.

🌐 Network Monitoring
مفاهیمی مثل DNS، HTTP، TCP، VPN و Firewall رو باید در عمل درک کنی و بتونی ارتباطات شبکه رو بررسی کنی.

🐧 Linux
حداقل باید با Terminal، Processها، Serviceها، Permissionها و لاگ‌های سیستم کار کرده باشی.

🔐 Active Directory
ساختار Domain، User، Group، GPO، Kerberos و رویدادهای مهم Authentication رو باید بشناسی.

📋 Ticketing / Case Management
باید بدونی Case چطور ایجاد، مستند، پیگیری و در صورت نیاز Escalate میشه.

🔎 Threat Intelligence
ابزارها و منابعی مثل VirusTotal، IOCها، Threat Feedها و فرمت‌هایی مثل Sigma رو باید در حد کاری بشناسی.


⚠️ نکته مهم:

قرار نیست Tier 1 روی همه این تکنولوژی‌ها متخصص باشه.

اما وقتی وارد یک SOC میشه، نباید اولین بارش باشه که با SIEM، EDR، Windows Logs، Network Logs یا Ticketing System کار می‌کنه.

پس Tier 1 باید بتونه با ابزارها کار کنه، داده جمع کنه، تحلیل اولیه انجام بده و نتیجه رو درست به نفر بعدی منتقل کنه.


@Socroot

اقا این پرامپت رو بدید به Gpt خروجی جالبی بهتون میده 😂

> Based on everything you know about me from our conversations, roast me — brutally and honestly — by generating a single satirical illustration of me in WOJAK meme art style.

Instructions:
- Analyze my personality, interests, habits, and quirks from what you actually know about me, and translate them into exaggerated visual details in the scene (objects on my desk/room, posters on the wall, what's on my screen, my facial expression, clothing, etc).
- The humor should be specific to ME, not generic — reference actual things I've talked about, my hobbies, my flaws, my running jokes, whatever you've picked up on.
- Use the classic Wojak art style: flat cel-shaded lines, exaggerated crying/rage/despair facial expression, simple bold colors, a slightly pathetic "terminally online" aesthetic.
- Feel free to add background characters, memes, or symbolic clutter in the room that reference my personality ironically.
- Don't hold back — be savage, funny, and merciless, but keep it satire, not genuinely cruel or targeting anything sensitive like appearance, health, or identity.
- Output just the image, plus a one-line caption underneath summarizing the roast

@Socroot

اینم خروجیش :)

اخرشم گفت :.
«تنها چیزی که بین تو و فروپاشی کامل مونده، یه NTP سروره که هنوز سینک نشده.»