قسمت سوم از مقاله فوق


چالش‌ها و فرصت‌ها در تحلیل لاگ‌های فرعی

۱. حجم و پیچیدگی:

برخلاف System/Security که تقریباً همه با فرمت و ساختارشان آشنا هستند، لاگ‌های Operational دارای رویدادهای خاص و بعضاً مستندسازی ناقص‌اند. این مسأله فرآیند Query نویسی و Hunting را دشوار می‌کند و نیاز به دانش پیش‌زمینه یا تمرین عملی دارد.

۲. نبود ابزار تخصصی:

ابزارهایی مانند SIEMها یا EDRهای آماده عموماً Query و Detection پیش‌ساخته برای این منابع ندارند، پس تحلیلگر باید خود الگو و KQL/Splunk Query اختصاصی بنویسد.

۳. ارزش عملیاتی:

وقتی سیستم هدف تحت لاگ‌گیری مینیمال یا کانفیگ پیش‌فرض است، داشتن حتی یک سرنخ در این لاگ‌ها می‌تواند بازی را عوض کند. فضای فکری مهم: “دنبال چی بگردیم”، و “این لاگ خاص، سرنخ کدام رفتار مهاجم است؟”


توصیه‌های عملی برای بهره‌برداری بهتر در SOC/DFIR

۱. مطالعه، مستندسازی و جمع آوری لیست Event IDهای مهم هر لاگ فرعی. این داده را با فعال‌سازی lab یا ساخت سناریوهای Red Team/Blue Team توسعه بدهید.

۲. ایجاد Query و تقاطع زمانی میان این لاگ‌ها با لاگ‌های اصلی. مثلاً تطبیق WinINet Proxy Change با اجرای مشکوک، یا محاسبه gap بین EID 9707 و 9708 برای کشف اجرای بدافزار زمانبر.

۳. تهیه Alert Template سفارشی بر اساس Use Case سازمان؛ مثلاً لاگ Run/RunOnce فقط در سرور خاص اصلاً نباید رخ دهد، پس آن‌را Alert کنید.

۴. مطالعه لاگ‌های ناشناخته، تمرین تحلیل Event Raw و ساخت نمودار Correlation در کلاس، بدیهی است دانشجویان علاوه بر Detection Engineering، ذهنیت Forensic تفکیکی و کاربردی پیدا کنند.

۵. ساخت سناریو برای Incident Response که در آن فقط به این لاگ‌ها دسترسی دارند (Fail-Safe Labs) تا قدرت تحلیل عمیق در شرایط کمبود داده افزایش یابد.


#آکادمی_روزبه
مرکز تخصصی CISSP

😢🔴
#آکادمی_روزبه
مرکز تخصصی CISSP

علاقمندان به SOC و هانت

میتونید برای رزرو دوره به واتس اپ زیر پیام بدین و پس از دوره سریع مشغول به کار شوید

واتس اپ 09902857290

از زبان انیسا

نقش و مهارت امنیت سایبری برای NIS2

#آکادمی_روزبه
مرکز تخصصی CISSP

#موقت
فکر می‌کنید استاندارد ها برای گذاشتن در کتابخانه ها هستند ؟

استاندارد ها ؛ چراغ راهِ پیاده سازی آمال و آرزوهای ما در تحقق امنیت است .

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

یکی از بزرگترین ریشه شکست های حفاظتی و نفوذ ، کارهای هر دمبیل !! (Ad hoc) و بدون نگاه به استاندارد است

تحول مدیریت امنیت با Policy/Change as Code


در عصر تحول دیجیتال و رشد سریع معماری‌های ابری و زیرساخت‌های نرم‌افزارمحور (SDN/SD-WAN)، اتکا به روش‌های سنتی مدیریت پالیسی و تغییر (Policy/Change Management) باعث افزایش ریسک خطاهای انسانی و حملات داخلی می‌شود. دو مفهوم کلیدی Policy as Code و Change as Code، مسیر مدیریت امنیت شبکه و اطلاعات را به‌طور بنیادین تغییر داده‌اند.

مساله Policy as Code (PaC) به معنای تعریف سیاست‌های دسترسی، امنیتی و اعتبارسنجی در قالب کد (مانند YAML, JSON یا DSL) است.

برخلاف گذشته که پالیسی‌ها در فایل‌های متنی یا Word ذخیره می‌شدند یا بر روی تجهیزات بصورت دستی تنظیم می‌گشتند، در این رویکرد سیاست‌ها بخشی از چرخه DevOps و GitOps می‌شوند: قابل نسخه‌بندی (version control)، تست خودکار (Automatic Validation) و مجاز بودن (Approval) پیش از اعمال در محیط اجرایی. ابزارهایی مانند Open Policy Agent (OPA)، HashiCorp Sentinel و Terraform بستری انعطاف‌پذیر جهت تعریف، بررسی و پیاده‌سازی این سیاست‌ها فراهم می‌کنند.

بحثChange as Code حتی یک قدم جلوتر است: هر گونه تغییر زیرساختی یا امنیتی – از تعویض یک قانون فایروال تا تغییر دسترسی کاربران – تنها از طریق commit به مخزن کد (Git) و طی مسیر بررسی، تست و approval انجام می‌شود (Pipeline-driven Change). این مدل، شفافیت (Audit)، ردیابی همه تغییرات (Traceability)، کاهش حملات داخلی و ساده‌سازی عملیات Rollback را به همراه دارد.
در مجموع، مهاجرت به PaC و Change as Code نه تنها امنیت را ارتقا می‌بخشد، بلکه توسعه پایدار، دسترس‌پذیر، و قابل مانیتورینگ زیرساخت را نیز تضمین می‌کند ـ یک الزام برای SOCهای مدرن و تیم‌های امنیتی آینده‌نگر



#آکادمی_روزبه
مرکز تخصصی CISSP
همیشه بخوان

لاگ‌های SASL: سپر دفاعی SOC در برابر حملات Credential-based و BEC


در دنیای امروز که تهدیدات سایبری علیه زیرساخت‌های حیاتی و سرویس‌های ایمیل سازمانی رشد فزاینده‌ای داشته‌اند، اتکا به لاگ‌های authentication، به‌ویژه لاگ‌های SASL (Simple Authentication and Security Layer)، به یک ضرورت امنیتی بدل شده است. حملات مبتنی بر اعتبارنامه (Credential-based) شامل password spraying، credential stuffing و نهایتاً Business Email Compromise (BEC) در سال‌های اخیر موجب سرقت اطلاعات، نفوذ به ایمیل و خسارت‌های مالی چشم‌گیر شده‌اند.



این SASL به عنوان چارچوب احراز هویت استاندارد در پروتکل‌هایی مانند SMTP، IMAP و LDAP این قابلیت را ایجاد می‌کند که تمامی تلاش‌های موفق و ناموفق برای لاگین، همراه با مشخصاتی نظیر مکانیزم احراز هویت (PLAIN, LOGIN, NTLM…)، زمان، نام کاربری و IP در لاگ ثبت شوند. این لاگ‌ها با جمع‌آوری توسط پلتفرم‌هایی چون Splunk، قابلیت تحلیلی بی‌نظیری برای SOC فراهم می‌کنند؛ به‌گونه‌ای که می‌توان به آسانی سناریوهای حمله‌ای مانند:
تکرار تلاش‌های ناموفق بر روی یک حساب،
تلاش برای ورود با مکانیزم‌های ضعیف یا مشکوک،
تغییر ناگهانی الگوی احراز هویت کاربر،
تهاجم از یک IP مشکوک
را به سرعت شناسایی و با آستانه‌بندی (thresholding) مناسب، هشدار لحظه‌ای صادر کرد.

نکته ‌مهم : در تعداد قابل توجهی از حملات موفق password spraying یا BEC روی سرویس‌هایی مانند O365، تحقیقات Incident Response نشان داده که سازمان‌هایی که SASL/SMTP logs نداشتند، اغلب ماه‌ها بعد و در زمانی که کاربر هدف به طور کامل compromise شده بود متوجه حادثه شدند، در حالی که آن دسته که SASL logging فعال داشته‌اند، حمله را در همان روز اول آشکار کرده‌اند.
در نتیجه، فعال‌سازی و مانیتورینگ هوشمند لاگ‌های SASL/SMTP نه‌فقط یک پیشنهاد فنی، که یک الزام حیاتی برای هر SOC مدرن محسوب می‌شود.


پی نوشت :مساله BEC نوعی حمله پیچیده و هدفمند است که مهاجم با نفوذ به حساب ایمیل سازمانی (یا جعل آن)، سعی می‌کند از طریق مهندسی اجتماعی، جعل مکاتبات یا ارسال دستور پرداخت، منابع مالی یا اطلاعات حساسی را سرقت کند.


#آکادمی_روزبه
مرکز تخصصی CISSP

نقش DMARC در مدیریت بحران و روابط عمومی سازمان
(سند راهبردی برای SOC، IR و PR)
مقدمه
در دنیای امروز، حملات جعل ایمیل (Email Spoofing) و فیشینگ (Phishing) جزو تهدیدات اصلی برای اعتبار برند، اعتماد مشتریان و امنیت اطلاعات سازمانی به شمار می‌روند. در این میان، DMARC یکی از موثرترین ابزارهایی است که سازمان را قادر می‌سازد علاوه بر کاهش ریسک حملات، مدیریت بحران‌های رسانه‌ای و ارتباطی را نیز ارتقاء دهد.

چرا DMARC کلید طلایی مدیریت بحران است؟

۱. پیشگیری بهتر از درمان:
استقرار سیاست سختگیرانه DMARC (مانند quarantine یا reject)، باعث می‌شود مهاجمان نتوانند از دامین رسمی سازمان برای ارسال ایمیل‌های فیشینگ یا باج‌گیری علیه مشتریان یا پرسنل استفاده کنند. این موضوع، حجم بحران‌های ارتباطی ناشی از انتشار اخبار حمله یا نقض داده را به شدت کاهش می‌دهد.
۲. هشدار و شناسایی سریع حمله:
گزارش‌های Aggregated و Forensic DMARC به تیم امنیتی کمک می‌کند در لحظات آغازین وقوع حمله متوجه شوند چه کسی، از کجا و در چه حجمی در تلاش برای سوءاستفاده از دامنه بوده است—حتی قبل از وقوع آسیب جدی.
۳. اطلاع‌رسانی دقیق و هدفمند به ذینفعان:
در صورت وقوع حمله، با اتکا به داده‌های DMARC، می‌توان لیست دقیقی از سازمان‌ها یا کاربران هدف را استخراج و فرایند اطلاع‌رسانی (Notification) را به طور متمرکز، سریع و مطمئن انجام داد. این امر باعث می‌شود PR (روابط عمومی )بتواند روایت بحران را کنترل کند و از انتشار اخبار “غافل‌گیرانه” در رسانه‌ها پیشگیری شود.
۴. شفاف‌سازی و حفظ اعتماد پس از حادثه:
حتی اگر حمله‌ای موفق به جعل هویت شود، سازمان می‌تواند با استناد به سیاست و لاگ‌های DMARC، به صورت مستند به رسانه‌ها، قوانین یا مراجع پاسخ دهد و نشان دهد موضوع را کنترل و پیگیری کرده است. این شفافیت در روابط عمومی “اعتماد” مخاطبان را پس از بحران تقویت می‌کند.


سناریو:
تصور کنید در یک بانک، مهاجمان با جعل دامنه اقدام به ارسال ایمیل فیشینگ برای مشتریان می‌کنند و برخی رسانه‌ها خبر آن را منتشر می‌کنند:
اگر DMARC به صورت reject پیاده‌سازی شده باشد:اکثر ایمیل‌های فیشینگ هرگز به اینباکس مشتریان نمی‌رسد.
تیم امنیت از طریق گزارش‌های روزانه، بلافاصله متوجه موج حملات می‌شود و اطلاعات کلیدی (IP مهاجم، حجم ارسال، هدف‌ها) را برای مدیریت PR آماده می‌کند.
روابط عمومی سازمان می‌تواند بیانیه رسمی منتشر کند و ادله فنی ارائه دهد که عملاً ایمیل تقلبی به دست مشتری نرسیده است یا فقط معدود موارد با خطای پیکربندی گیرنده تحویل شده‌اند.
در صورت مطالبه قانون یا رسانه، مستندات تحلیلی DMARC آماده و شفاف‌سازی بدون تاخیر انجام می‌شود.



#آکادمی_روزبه
مرکز تخصصی CISSP

فورتی نت هم که باشی ....بازم ممکنه اصول امنیت رو رعایت نکنی :

هاردکد کردن کردنشیال !!


#آکادمی_روزبه
مرکز تخصصی CISSP

https://cybersecuritynews.com/fortinet-fortios-hard-coded-credentials-vulnerability/

تفاوت‌های فارنزیکی بین ویندوز 10 و ویندوز

بخش اول

ویندوز، توسط مایکروسافت توسعه یافته، از زمان اولین ارائه خود در سال 1985، ستون فقرات رایانش شخصی و حرفه‌ای بوده است.

تا مارس 2022، ویندوز با سهم بازار جهانی 75.7 درصد، پراستفاده‌ترین سیستم‌عامل جهان است. از بین این نصب‌ها، 74.82 درصد روی ویندوز 10 و 8.45 درصد به ویندوز 11 مهاجرت کرده‌اند. مایکروسافت گزارش می‌دهد که بیش از 1.4 میلیارد دستگاه در جهان از ویندوز 10 یا 11 استفاده می‌کنند (Microsoft, 2022a).

مایکروسافت قصد دارد حداقل یک نسخه از ویندوز 10 را تا 14 اکتبر 2025 پشتیبانی کند. با نزدیک شدن به پایان پشتیبانی از ویندوز 10، انتظار می‌رود استفاده از ویندوز 11 به شکل قابل توجهی رشد کند. این تغییر، اهمیت درک تفاوت‌ها و شباهت‌های این دو سیستم‌عامل را برای کارشناسان فارنزیک دیجیتال، به ویژه از نظر آرتیفکت‌ها و قابلیت‌های امنیتی، افزایش می‌دهد.

مطلب خوبی از Andrew Rathbun نوشته شده است که می‌توانید آن را هم مطالعه کنید:

https://www.sans.org/white-papers/windows-10-vs-windows-11-what-has-changed/

آرتیفکت‌های فارنزیکی

این بخش بررسی می‌کند که آیا آرتیفکت‌های کلیدی ویندوز 10 در ویندوز 11 نیز حضور دارند و تفاوت‌های فارنزیکی احتمالی چیست. تحلیلی از آرتیفکت‌های برجسته را در ادامه می‌بینید:
فایل های LNK و Jump Lists

فرمت فایل باینری Shell Link (.LNK) در ژوئن 2021 بازنگری شد، اما هیچ تغییر قابل توجه فارنزیکی شناسایی نشده است. به همین صورت، Jump Listها، که مجموعه‌ای از فایل‌های .LNK مرتبط با برنامه‌ها هستند، میان ویندوز 10 و 11 تغییری نکرده‌اند.
فایل‌های متادیتای $Recycle_Bin

فایل‌های متادیتا در Recycle Bin ($I30) هیچ تفاوت چشمگیری میان ویندوز 10 و 11 نشان نمی‌دهند.
Amcache

آرتیفکت Amcache در هر دو ویندوز 10 و 11 یکسان است.
رجیستری هیو‌ها (Registry Hives)

رجیستری هیوها در ویندوز 11 تغییرات قابل توجهی دارند؛ بیش از 35 هزار کلید جدید یا تغییر یافته وجود دارد. این تغییرات عمدتاً مربوط به قابلیت‌های امنیتی جدید و پشتیبانی از سخت‌افزار و تنظیمات رابط کاربری است.

برای کارشناسان فارنزیک و تحلیلگران امنیتی، بررسی این تغییرات ضروری است، چرا که ممکن است ردپای پایداری (Persistence)، اجرای مخرب، یا تنظیمات مخفی در این موقعیت‌ها شکل گیرد.
Prefetch

فرمت و مکان Prefetch مشابه ویندوز 10 باقی مانده، اما با توجه به فعال بودن ماژول‌های امنیتی مانند TPM و Secure Boot، در برخی دستگاه‌ها Prefetch به طور پیش فرض غیرفعال است.

#آکادمی_روزبه
مرکز تخصصی CISSP


ادامه دارد ...

بخش دوم


Windows Timeline

آرتیفکت‌های Timeline در ویندوز 11 (مثل ActivitiesCache.db) حذف یا غیرفعال شده‌اند، که بازیابی تاریخچه فعالیت کاربر را دشوارتر می‌کند.
Event Logs

ساختار کلی Event Logها حفظ شده، اما EventIDها و کانال‌های جدیدی که مرتبط با امنیت، مدیریت و ویژگی‌های جدید ویندوز هستند، اضافه شده‌اند—به ویژه برای پشتیبانی از TPM، Secure Boot و Virtualization-Based Security (VBS).
ردیابی فرایندها (Process Tracking - Sysmon و ETW)

ابزارها و سرویس‌هایی مانند Sysmon و ETW همچنان برای مانیتورینگ دقیق رفتار فرآیندها مورد استفاده قرار می‌گیرند. در ویندوز 11، سیستم لاگ‌دهی بهبود یافته است و برخی کانال‌های جدید را نمی‌توان غیر فعال کرد.
حافظه (Memory) و Pagefile/SWAP

در ویندوز 11 به دلیل پیش‌فرض شدن برخی قابلیت‌های امنیتی مبتنی بر مجازی‌سازی (VBS)، بخش‌هایی از حافظه ممکن است رمزگذاری یا غیرقابل دسترس شود که استخراج برخی آرتیفکت‌های معمول حافظه را محدود می‌کند.
قابلیت‌های جدید امنیتی

و TPM 2.0 و Secure Boot:در بسیاری از دستگاه‌ها، برای نصب ویندوز 11 اجرا الزامی است.
و VBS و HVCI:امنیت مبتنی بر مجازی‌سازی و بررسی صحت در سطح کرنل، امکان بسیاری از حملات کلاسیک و بعضاً استخراج فارنزیک قدیمی را کاهش داده یا غیرممکن می‌سازد.

جمع‌بندی

بیشتر آرتیفکت‌های کلیدی میان نسخه‌های 10 و 11 یکسان باقی مانده‌اند؛ اما رجیستری و قابلیت‌های امنیت سخت‌افزاری تغییر چشمگیر داشته و نیازمند به‌روزرسانی دانش و ابزارهای تخصصی است.

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


#آکادمی_روزبه
مرکز تخصصی CISSP

تأثیر Virtualization-Based Security (VBS) ویندوز ۱۱ بر فارنزیک حافظه: چالش‌ها و راهکارها

مقدمه

با مهاجرت تدریجی سازمان‌ها و کاربران نهایی به ویندوز ۱۱، شاهد دگرگونی جدی در لایه‌های امنیتی این سیستم‌عامل، به‌ویژه در حوزه حفاظت از حافظه RAM هستیم. مهم‌ترین عامل این تغییر، فناوری امنیتی مبتنی بر مجازی‎‌سازی (Virtualization-Based Security – VBS) است؛ قابلیتی که به‌صورت پیش‌فرض در بسیاری از سیستم‌های جدید ویندوز ۱۱ فعال است و رفتار جرم‌شناسانه با حافظه را به‌کلی مختل می‌کند. در این مقاله، مروری تحلیلی بر این تغییر و راهکارهای عملیاتی برای مقابله با محدودیت‌های فارنزیک حافظه در ویندوز ۱۱ خواهیم داشت.

مقوله VBS و HVCI چیست و چگونه عمل می‌کنند؟
Virtualization-Based Security (VBS)

با VBS با بهره‌گیری از سخت‌افزار مجازی‌سازی (مثلاً Hyper-V یا AMD-V/Intel VT-x)، فضایی ایزوله به نام Virtual Trust Level (VTL1) در حافظه ایجاد می‌کند که کاملاً از فضای حافظه اصلی (VTL0) جداست. داده‌های حیاتی امنیتی (مانند رمزها، هویت‌ها، برخی ساختارهای کرنل) به این بخش منتقل شده و دسترسی پردازه‌های عادی یا حتی بسیاری ابزارهای تخصصی فارنزیک به این قسمت مسدود می‌شود.
Hypervisor-Protected Code Integrity (HVCI)

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

مشکل جدید: محدودیت شدید فارنزیک حافظه در ویندوز ۱۱

چالش‌های اصلی

غیرقابل دسترس‌شدن یا رمزنگاری بخش‌های کلیدی حافظه RAM
عدم امکان استخراج رمزهای عبور، هش‌ها، Kerberos TGT، و بسیاری داده‌های زنده مرتبط با سشن‌های امنیتی.
حافظه پردازه‌هایی نظیر LSASS، Credential Guard و برخی بخش‌های کرنل به Hypervisor ایزوله شده و دیگر ابزارهایی مانند Mimikatz، Procdump یا حتی بسیاری Memory Imagerها نمی‌توانند آنها را به‌طور کامل Dump یا تحلیل کنند.

ابزارهای کلاسیک Memory Forensics ناکارآمد می‌شوند
حتی با دسترسی SYSTEM یا سطح کرنل، برداشتن رم یا Analyzing Dump، عملاً Artifactها یا غایب هستند یا رمز شده‌اند.
این امر بررسی سناریوهایی همچون استخراج داده‌های سرقتی، تحلیل Rootkit، بررسی حملات Fileless Malware یا احراز صحت امنیتی سیستم را با مشکل روبرو می‌کند.

اثرات در تیم‌های Incident Response و SOC
کاهش توانایی شناسایی نفوذگر، Root Cause، کشف تکنیک‌های Living-off-the-Land و حتی بازسازی وقایع امنیتی بر اساس حافظه.
افزایش اتکا به Artifactهای دیسک، رجیستری و رویداد‌لاگ‌ها (در حالی که بسیاری شواهد حساس فقط در حافظه زنده نگهداری می‌شوند).

راهکارها و توصیه‌های عملیاتی

۱. شناسایی تنظیمات امنیتی پیش از Memory Acquisition

قبل از هرگونه عملیات Memory Dump یا Incident Handling روی سیستم‌های ویندوز ۱۱، تنظیمات VBS/HVCI و Credential Guard را بررسی و ثبت کنید.

بهترین روش:

اجرای
msinfo32.exe

در بخش “Device Security” نگاه کنید آیا Virtualization-based Security فعال است یا خیر.

۲. استفاده از ابزارهای به‌روز و سازگار با Windows 11

ابزارهایی مانند Magnet RAM Capture v2.x، Belkasoft RAM Capturer نسخه‌های جدید و Volatility نسخه ۳ به بعد، برخی سطوح تعامل با ساختارهای جدید حافظه را دارند ولی هنوز کاملاً Bulletproof نیستند.
برای محیط‌های مجازی، Snapshot گرفتن در سطح Hypervisor (مثلاً VMware, Hyper-V) راهکاری است که می‌تواند بعضی دسترسی‌ها را ممکن سازد.

۳. تغییر رویکرد: تمرکز بر Artifactهای غیر حافظه (Disk/Registry/Logs)

تحلیل رجیستری (NTUSER.DAT/SAM/SECURITY/SYSTEM)، رکوردهای لاگ‌ها (Event Log, ETW, Sysmon)، و جدول‌های دیتابیس (مانند Amcache, SRUM, LNK, JumpList, Shellbags و …) اهمیت بیشتری پیدا کرده است.
تحلیل شبکه، بررسی اثرات عملیات مشکوک و آثار جانبی مهاجمان در هارد (Persistence, گیاوه‌های باقی‌مانده، آثار تغییر فایل‌ها و…) را جایگزین تحلیل مستقیم RAM کنید.

۴. آموزش تیم‌ها و به‌روزرسانی دانش

انتقال دانش به تیم‌های SOC و IR درباره محدودیت‌های Memory Forensics روی سیستم‌های VBS/HVCI-enabled و آموزاندن تکنیک‌های جایگزین استخراج شواهد.
استفاده از تمرین‌های عملی با Sampleهایی که این حالت فعال است—تا بتوان ضعف‌های قدیمی و نقاط قوت رویکردهای جدید را لمس کرد.

۵. تماس با تامین‌کنندگان ابزار و رصد مستمر آپدیت‌های تخصصی

توصیه می‌شود تیم‌های امنیتی عضو mailing listها، خبرنامه‌ها و مستندات بازار (مثلاً SANS، Magnet Forensics Blog، CrowdStrike و غیره) باشند تا با هر آپدیت ابزارها و تاکتیک‌های جدید آشنا بمانند


#آکادمی_روزبه
مرکز تخصصی CISSP

پس همانطور که می‌بینیم یا باید دائم مطالعه کنیم یا هر چند وقت یکبار با آموزش و کلاس ؛ دانش خود را به روز کنیم

این دنیای امنیت سایبری است

مواظب باشید چون ممکن است زود قدیمی !!شوید

شناسایی افراد مهم که حتی موبایل هوشمند ندارند
ردپای اوسینت ؛ مساله ای قابل تذکر


سناریوی واقعی با تاکید بر OSINT بدون ردپای مستقیم دیجیتال فرد هدف:

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

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

چطور OSINT می‌تواند او را لو بدهد؟

۱. ردپای غیرمستقیم (Social Graph Leakage):

خانواده، دوستان، راننده، تیم حفاظتی یا حتی کارمندان (مثلاً منشی یا خدمتکار) این شخص، ممکن است موقعیت یا عکسی از محل (هتل، دفتر، جلسه) منتشر کنند. با بررسی عکس‌ها و چک-این‌های آن‌ها در شبکه‌های اجتماعی یا حتی اپلیکیشن‌های ورزشی ، هر بار نزدیک فرد موردنظر هستند، موقعیت مکانی تقریباً لو می‌رود.
مثال واقعی: در سال ۲۰۱۸ پایگاه‌های نظامی آمریکا به‌واسطه داده‌های Strava از سربازانی که دویدن می‌کردند، روی نقشه جهانی لو رفت.

۲. افشای تصادفی در رسانه‌ها و رویدادها:

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

داده‌های مکانی از منابع جانبی (Venue OSINT):
بررسی سامانه‌های رزرواسیون پرواز/هتل، اسناد افشاشده حوادث، ایمیل‌های فیشینگ هدفمند یا دعوت‌نامه‌های رسمی (که گاهی لو می‌روند یا در سایت یک اداره یا کنفرانس درج می‌شوند).

وOSINT بر اساس نقشه‌های شهری و تغییرات محیطی:
اگر تیم اسکورت یا خودروی او دائماً در منطقه خاصی رفت‌وآمد دارد (شناسه پلاک یا حتی الگوی حرکت)، از تصاویر Google Street View، داده‌های ترافیکی شهری، یا ویدئوهای افراد دیگر می‌توان مسیر تردد معمول را بازسازی کرد.

نتیجه:

فرد حتی بدون “نماد حضور دیجیتال”، قربانی افشای غیرمستقیم بقیه، اشتباهات اطرافیان یا داده‌های عمومی می‌شود. این همان خطری است که ضرورت آموزش OPSEC برای خانواده، تیم حفاظت و حتی مهمانان و اخبار را دوچندان نشان می‌دهد.


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


مرجع برای مطالعه : دوره
SANS SEC497: Practical Open-Source Intelligence (OSINT)™

#آکادمی_روزبه
مرکز تخصصی CISSP

❌️❌❌❌️👆👆❌️❌️❌️❌️

بی سوادی موج میزنه

والله متخصص نیستین حداقل بروید یک کلاس تحلیل نقادانه بگذرانید بعد دست به قلم بشین

عیبه اینطوری چی رو به چی ربط میدین !!

یه نوشته حداقل گزاره های خودش باید دیگری رو تایید کنه.
چون در تصویر فوق؛ چی چیو تایید میکنه ؟

**نمیگم اصلا امکان نداره . میگم این طرز استنتاج و نوشتن ضایعه!!
ضمنا اگر میخوای تبلیغ کنی هم تابلو هست

دوره های رایگان


https://redteamleaders.coursestack.com/courses/4cc576dd-934b-4289-a100-8a233fe07ef2

https://redteamleaders.coursestack.com/courses/1390aba4-3ad7-4ae2-8e2a-4575a821b0f7

عوامل روانی مثل استرس، خودکم‌بینی و ترس از قضاوت در عدم توجه به پست‌های علمی بسیار مؤثرند.

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

کاربرانی که دچار اضطراب اجتماعی یا احساس حقارت هستند، ممکن است از دیده شدن لایک یا نظرشان روی یک پست علمی واهمه داشته باشند و نگران قضاوت دیگران یا اشتباه علمی خود باشند.
۲. کمبود اعتماد به نفس علمی

افرادی که درک یا اطلاعات کمی نسبت به موضوعات علمی دارند، ممکن است فکر کنند که بحث یا اظهار نظر آنها “در سطح نیست”. نگران هستند که مورد تمسخر یا بی‌توجهی قرار بگیرند (اثر دانینگ-کروگر: هم افراد بی‌دانش و هم باسوادها دچار این تله شناختی می‌شوند).
۳. ترس از قضاوت یا همرنگ جماعت نبودن

خیلی‌ها نگران‌اند اگر پست‌های علمی را لایک یا منتشر کنند، توسط جمع دوستان، فالوورها یا خانواده “غیرجذاب” یا “خوره علم” به نظر بیایند. پس ترجیح می‌دهند همرنگ جمع بمانند تا انگ جدی یا خشک بودن نخورند.
۴. استرس و خستگی ذهنی

محیط شلوغ، اخبار منفی، مطالب سرگرم کننده، و حجم بالای محتوا باعث می‌شود مغز دنبال آرامش و محتوای سبک برود. پس پست‌های علمی که تمرکز و فکر می‌خواهند، بیشتر نادیده گرفته می‌شوند.
۵. اثر گله (Herd Mentality)

اگر دیگران واکنش کمی نشان دهند، این رفتار بین عموم پخش می‌شود و حتی کاربران علاقمند هم تمایل‌شان را ابراز نمی‌کنند تا از اکثریت جدا نشوند.

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


#آکادمی_روزبه
مرکز تخصصی CISSP

هشدار: آسیب‌پذیری zero-click در اپل؛ تهدیدی جدی برای همه، نه فقط اندروید!

سال‌هاست که بسیاری از کاربران و حتی برخی متخصصان امنیت تصور می‌کنند فقط سیستم‌عامل اندروید “آسیب‌پذیر” است و iOS بسیار ایمن‌تر و غیرقابل نفوذ باقی می‌ماند. اما شناسایی و افشای آسیب‌پذیری جدید و بسیار خطرناک zero-click در محصولات اپل (CVE-2025-43200) این باور غلط را زیر سؤال برده است.

در این نوع حمله، هکرها بدون هیچ دخالت یا کلیک کاربر، می‌توانند تنها با ارسال عکس یا مدیای آلوده از طریق iCloud Link یا iMessage، دستگاه قربانی را به طور کامل تحت کنترل خود قرار دهند. تفاوت اساسی این حمله با تهدیدات قبلی، اجرای خودکار کد مخرب بدون نیاز به تعامل کاربر است؛ به این معنی که حتی کاربران حرفه‌ای هم متوجه آلودگی نمی‌شوند.

این آسیب‌پذیری عمدتاً برای جاسوسی هدفمند علیه روزنامه‌نگاران و افراد کلیدی استفاده شد و خطر آن به مراتب فراتر از حملات رایج اندروید است. بنابراین، هرگز امنیت اپل را بدیهی فرض نکنید؛ به‌روزرسانی سریع و مراقبت مداوم، تنها سپر دفاع واقعی شماست. اپل هم برابر حملات سایبری مصون نیست!


#آکادمی_روزبه
مرکز تخصصی CISSP

https://cybersecuritynews.com/cisa-warns-of-ios-0-click-vulnerability/

💔نکنید بخدا

تحلیلگر SOC میگیری واسه عسلویه ؛ رزومه در جیمیل ؟؟

اینکه میگم امنیت نصفش سواد هست نصفش " دید" امنیتی چیز درستیه

فقط نباید سواد داشت؛
باید امنیتی بود
وگرنه جان و مال مردم رو هوا است !