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

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

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

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

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

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

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

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

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

این همون مفهوم 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 سروره که هنوز سینک نشده.»

📌 از کجا بفهمیم 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