نقش ELAM ویندوز و ترند در بارگذاری درایور ها هنگام بوت

کی چی به عهده داره و چرا به روز بودن ترند و کلا EDR و XDR ها مهم هستند




مقوله ELAM و یکپارچگی مایکروسافت، ویندوز و Trend Micro Vision One XDR

ویژگی Early Launch Anti‑Malware با ویندوز 8 توسط مایکروسافت معرفی شد تا اولین خط دفاعی در برابر بدافزارهای سطح کرنل باشد. مایکروسافت در این مکانیزم نقش سازنده چارچوب را بر عهده دارد: ویندوز تضمین می‌کند که ELAM Driver، پیش از هر درایور دیگری در مراحل بوت اجرا شود و API لازم برای بررسی امضاهای درایورهای بوت‌استارت را ارائه می‌دهد. با این حال، ویندوز خود حاوی دیتابیس تشخیص نیست.

در این میان، Trend Micro Vision One XDR نقش تأمین‌کننده هوش تشخیصی را دارد. این محصول یک ELAM Driver اختصاصی نصب می‌کند که شامل دیتابیس امضاها، هش‌ها و قوانین طبقه‌بندی است.

هنگام بوت، این درایور هر درایور کرنلی را در یکی از چهار گروه Good، Bad، Bad but Required for Boot یا Unknown جای می‌دهد. اطلاعات تصمیم و گزارش به ماژول XDR ارسال می‌شود تا پس از بوت، تحلیل کامل و پاسخ خودکار، مانند قرنطینه یا هشدار، انجام گیرد.

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


#یاد_بدهیم
#بااخلاق_باشیم

مجوز اخلاقی (Moral Licensing)

بارها هم در جمع دوستان هم در بحث کلان کشور و یا همین لینکدین دیده میشه افرادی از فساد گلایه میکنند و خود را فردی اخلاقی می‌دانند و خیلی ها رو دارای فساد می‌پندارند. اما در عمل دیده میشه در گوشه و کنار بی اخلاقی ها و فسادی رو در کارنامه دارند یا مشغول هستند . اومدم در موردش تحقیق کردم در نهایت به بحث "مجوز اخلاقی" رسیدم . منبع:
Merritt, Anna C., Daniel A. Effron, and Benoît Monin.
“Moral self-licensing: When being good frees us to be bad.”
Social and Personality Psychology Compass

مجوز اخلاقی پدیده‌ای روانشناختی است که در آن، انجام یک کار اخلاقی یا حتی ابراز یک موضع مثبت، باعث شکل‌گیری «اعتبار اخلاقی» در ذهن فرد می‌شود. این اعتبار ناخودآگاه، مقاومت او را در برابر رفتارهای بی‌اخلاقانه بعدی کاهش می‌دهد؛ زیرا فرد چنین استدلال می‌کند: «من آدم درستکاری هستم، پس این خطای کوچک به حساب نمی‌آید.»

فرآیند معمول آن چنین است: فرد ابتدا با گفتار یا رفتار، خود را به ارزش‌های اخلاقی متصل می‌کند. سپس در مواجهه با موقعیتی وسوسه‌برانگیز، احساس می‌کند که «سابقه مثبت» به او اجازه می‌دهد کمی از اصول فاصله بگیرد. همین چرخه، در بلندمدت می‌تواند باعث فاصله گرفتن از معیارهای اخلاقی واقعی شود.

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


پس هرکسی که صحبت از مبارزه با بی اخلاقی و فساد میکند و دائم همه جا را غرق در فساد نشان می‌دهد الزاما خودش درستکار نمیتواند باشد و شاید به لغزش هایی مشغول باشد.

خداوند در قرآن می‌فرماید:

يَا أَيُّهَا الَّذِينَ آمَنُوا لِمَ تَقُولُونَ مَا لَا تَفْعَلُونَ ۝ كَبُرَ مَقْتًا عِندَ اللَّهِ أَنْ تَقُولُوا مَا لَا تَفْعَلُونَ

(سوره الصف، آیات ۲–۳)

ترجمه:

«ای کسانی که ایمان آورده‌اید، چرا چیزی می‌گویید که انجامش نمی‌دهید؟ نزد خدا بسیار ناپسند است که چیزی را بگویید و خود عمل نکنید.»

لاگ همه‌چیز نیست؛
جایگاه پاورشل در تحلیل امنیتی

در تیم‌های امنیتی، به‌ویژه SOC؛ در Splunk و سایر SIEMها منبع اصلی تحلیل رویدادها هستند. اما باید به دانشجویان یاد داد که لاگ‌ها همیشه داستان کامل را نمی‌گویند.

سه محدودیت رایج لاگ‌ها:

نبود رویداد: اگر لاگینگ پیشاپیش فعال نشده باشد، بسیاری از فعالیت‌ها (مثل اجرای اسکریپت یا تغییرات رجیستری) ثبت نمی‌شوند و شما باید از رد پاها منابع لازم برای تحلیل رو جمع آوری کنی مانند مثال پایان این پست .
تاخیر انتقال: لاگ‌ها اغلب با تأخیر به Splunk می‌رسند، که در واکنش سریع به حمله مشکل‌ساز است.
حذف یا فیلتر شدن: در شبکه‌های بزرگ، به دلیل محدودیت منابع، ارسال همه رویدادها ممکن نیست.

در چنین شرایطی، PowerShell وارد عمل می‌شود: برای جمع‌آوری داده زنده، بررسی سیستم آلوده پیش از نابودی شواهد، و ایجاد مانیتور موقت برای رویدادهایی که امکان لاگ‌گیری دائم ندارند.

در مقیاس بزرگ، اجرای پاورشل از طریق PowerShell Remoting، SCCM یا EDRهای پیشرفته امکان جمع‌آوری هم‌زمان از صدها یا هزاران سیستم را فراهم می‌کند. با اسکریپت استاندارد، اجرای موازی و ذخیره‌سازی منظم، می‌توان این فرآیند را قابل اطمینان کرد.

پیام مهم: لاگ‌ها پایه تحلیل‌اند، ولی تنها منبع نیستند؛ داده زنده از سیستم می‌تواند حلقه گمشده کشف و پاسخ امنیتی باشد.


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




<#
جمع‌آوری داده‌های کلیدی سیستم وقتی لاگ نیست
استفاده: اجرای محلی یا ریموت با PowerShell Remoting
خروجی: فولدر Evidence روی دسکتاپ کاربر اجراکننده
#>

# مسیر ذخیره‌سازی شواهد
$EvidenceDir = "$env:USERPROFILE\Desktop\Evidence"
New-Item -ItemType Directory -Force -Path $EvidenceDir | Out-Null

# ۱. پردازش‌ها و ماژول‌ها
Get-Process |
Select-Object Name, Id, StartTime, Path |
Export-Csv "$EvidenceDir\Processes.csv" -NoTypeInformation

# ۲. اتصالات شبکه
Get-NetTCPConnection |
Select-Object LocalAddress, LocalPort, RemoteAddress, RemotePort, State |
Export-Csv "$EvidenceDir\NetworkConnections.csv" -NoTypeInformation

# ۳. کلیدهای رجیستری حساس (نمونه Autorun)
Get-ItemProperty -Path "HKLM:\Software\Microsoft\Windows\CurrentVersion\Run" |
Export-Clixml "$EvidenceDir\Autoruns_HKLM.xml"

Get-ItemProperty -Path "HKCU:\Software\Microsoft\Windows\CurrentVersion\Run" |
Export-Clixml "$EvidenceDir\Autoruns_HKCU.xml"

# ۴. Prefetch فایل‌ها (اگر فعال باشد)
$PrefetchDir = "$env:SystemRoot\Prefetch"
If (Test-Path $PrefetchDir) {
Copy-Item "$PrefetchDir\*" -Destination "$EvidenceDir\Prefetch" -Recurse -Force
}


# ۵.و Amcache (لیست برنامه‌های اجراشده)
$AmcachePath = "$env:SystemRoot\AppCompat\Programs\Amcache.hve"
If (Test-Path $AmcachePath) {
Copy-Item $AmcachePath -Destination "$EvidenceDir\Amcache.hve" -Force
}

Write-Output "✅ Collect completed. Evidence saved at: $EvidenceDir"

تلاشی برای دور زدن Secure Boot و ELAM در ویندوز

گروه‌های APT مانند Lazarus (کره شمالی) و Scattered Spider به طور گسترده از تکنیک BYOVD برای غیرفعال کردن ابزارهای امنیتی پیشرفته و استقرار بدافزارهای خود استفاده می‌کنند.


۱- پیدا کردن یک درایور آسیب‌پذیر: مهاجم یک درایور قانونی و دارای امضای دیجیتال معتبر (مثلاً از مایکروسافت) را پیدا می‌کند که حاوی یک آسیب‌پذیری شناخته‌شده است (مثلاً یک درایور قدیمی از یک کارت گرافیک یا نرم‌افزار آنتی‌چیت بازی).
۲-نصب درایور قانونی: مهاجم که قبلاً دسترسی ادمین را در سیستم به دست آورده، این درایور قانونی اما آسیب‌پذیر را روی سیستم قربانی نصب می‌کند.
۳-تأیید توسط ELAM: از آنجایی که این درایور دارای امضای دیجیتال معتبر است، Secure Boot و درایور ELAM آن را به عنوان یک درایور قابل اعتماد شناسایی کرده و اجازه بارگذاری آن را می‌دهند.
۴-بهره‌برداری از آسیب‌پذیری: پس از اینکه درایور معتبر در حافظه (سطح کرنل) بارگذاری شد، مهاجم از آسیب‌پذیری موجود در آن استفاده می‌کند تا کد مخرب خود را در سطح کرنل اجرا کند.
۵-غیرفعال کردن امنیت از درون: از آنجایی که کد مهاجم اکنون در سطح کرنل در حال اجراست، می‌تواند به راحتی درایور ELAM یا سایر نرم‌افزارهای امنیتی (EDR، آنتی‌ویروس) را از درون غیرفعال کند.

تبصره : باید گفت ELAM همیشه درگیر نیست، بیشتر نقش بررسی اولیه بوت را دارد


#خوب_بخوانیم

حادثه روی رایانه و سرور ، اقدام یا بی‌عملی
معمای پاسخ به حوادث در سیستم‌های Live


در مدیریت حوادث امنیتی، همواره این بحث مطرح است که آیا باید به صورت زنده روی سیستم آلوده اقدام کرد یا با تهیه یک نسخه کامل از هارد دیسک، تحلیل را به صورت آفلاین (Postmortem) انجام داد.
بسیاری نگران‌اند که اقدامات زنده، وضعیت سیستم را تغییر داده و شواهد را مخدوش کند. اما نکته‌ای حیاتی که اغلب نادیده گرفته می‌شود این است که بی‌عملی نیز به همان اندازه سیستم را تغییر می‌دهد.
یک سیستم کامپیوتری، حتی در حالت بیکار، دائماً در حال فعالیت است. پردازش‌ها اجرا می‌شوند و اقدامات پس‌زمینه به طور خودکار رخ می‌دهند. برای مثال:
احتمالا ویندوز پس از ۲۴ ساعت به طور خودکار یک نقطه بازیابی (System Restore Point) ایجاد می‌کند.
پس از چند روز، ممکن است عملیات یکپارچه‌سازی دیسک (Defragmentation) به صورت محدود اجرا شود.
سیستم‌عامل می‌تواند به روزرسانی‌های جدید را دانلود و نصب کند.

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

بنابراین، سوال اصلی برای یک تیم پاسخ به حادثه این نیست که “آیا اقدامی انجام دهیم یا نه؟” بلکه این است:
۱. آیا هیچ کاری نکنیم و ریسک از دست رفتن شواهد و سرقت بیشتر داده‌ها را بپذیریم؟
۲. یا با توجه به شرایط، بهترین اقدامات ممکن را برای محافظت از سازمان خود انجام دهیم؟

در نهایت، بی‌عملی یک استراتژی منفعلانه نیست، بلکه تصمیمی فعال با عواقب بالقوه ویرانگر است.


بخشی از درس سنز 608

درگیری امروز من در SOC

کلید رجیستری
HKLM\SYSTEM\CurrentControlSet\Services\SgrmBroker\Parameters\ServiceDll


این کلید مسیر DLL سرویس امنیتی SgrmBroker (System Guard Runtime Monitor Broker) را تعیین می‌کند. این سرویس بخشی حیاتی از Windows Defender System Guard است و در Context SYSTEM اجرا می‌شود تا تمامیت کرنل و زنجیره بوت را بررسی کند. مقدار پیش‌فرض ServiceDll باید به %SystemRoot%\System32\sgrm.dll اشاره کند.

دستکاری این مسیر به مهاجم اجازه می‌دهد DLL مخرب خود را با دسترسی SYSTEM لود کرده و Privilege Escalation، Persistence و حتی EDR Bypass انجام دهد. به دلیل مشروعیت سرویس، فعالیت مخرب می‌تواند پنهان بماند.

روش رایج حمله شامل تغییر مستقیم مقدار رجیستری با پاورشل (Set-ItemProperty) یا جایگزینی فایل اصلی DLL است. این نقطه حساس به‌سختی مانیتور می‌شود و هدفی جذاب است، بنابراین بررسی و محافظت آن برای تیم‌های SOC و Blue Team حیاتی است.

توجه کنید که اگر EDR خودتون رو خوب تنظیم کنید در حفاظت از این مقوله نقش مهمی بازی میکند.


#یاد_بدهیم
با آموزش رقیب نمی‌تراشیم بلکه بیشتر یادمیگیر یم

حکمرانی امنیت در هر حالت

در حوزه حکمرانی امنیت، این آسیب‌پذیری در لینک زیر نشان می‌دهد که باید اصل کمترین اختیار در تمام ابزارهای هوش مصنوعی توسعه‌دهنده پیاده‌سازی شود. لیست مجاز پیش‌فرض (Allowlist) باید محدود و به‌طور دوره‌ای بازبینی شود. سیاست رسمی برای مقابله با Prompt Injection ضروری است، زیرا این حمله می‌تواند از کد، Pull Request یا جستجوهای وب منشاء بگیرد. ایجاد یک Playbook پاسخ‌گویی به رخدادهای AI، مشابه SOC، و کنترل امنیت زنجیره تأمین نرم‌افزار نیز حیاتی است.

در طراحی نرم‌افزار امن، حذف فرمان‌های پرخطر مانند ping, nslookup, dig, host از اجرا بدون تأیید انسانی ضروری است. اجرای AI مشابه این سناریو باید در sandbox باشد و دسترسی محدود به فایل و شبکه داشته باشد. فیلترکردن دامنه‌های خروجی و تعریف لیست سفید برای درخواست‌ها، شناسایی رفتار غیرعادی (مثل جاسازی داده حساس در نام دامنه)، و تشخیص تکنیک‌های Obfuscation برای دورزدن فیلترها باید لحاظ شود.

ترکیب این نکات می‌تواند تبدیل به یک چک‌لیست مشترک SOC و DevSecOps شود تا ورود داده ناامن به مدل‌ها کنترل، رصد شبکه تقویت، و فرآیند تأیید انسانی قبل از اجرای هر فرمان بالقوه خطرناک تضمین شود. این رویکرد، ریسک AI‑assisted Data Exfiltration را به‌طور چشمگیر کاهش می‌دهد.



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


https://embracethered.com/blog/posts/2025/claude-code-exfiltration-via-dns-requests/

روش‌های سنتی جمع‌آوری اطلاعات از Active Directory، مانند استفاده از پروتکل LDAP, بسیار پُر سر و صدا هستند و به راحتی توسط ابزارهای امنیتی مدرن مانند EDR (Endpoint Detection and Response) و SIEM (Security Information and Event Management) شناسایی می‌شوند.

راه حل پیشنهادی ، استفاده از یک سرویس داخلی و کمتر شناخته‌شده ویندوز به نام Active Directory Web Services (ADWS) است. از آنجایی که ADWS از طریق پروتکل‌های وب استاندارد (HTTP/HTTPS) کار می‌کند، ترافیک آن شبیه به ترافیک عادی وب به نظر می‌رسد و شناسایی آن برای تیم‌های امنیتی بسیار دشوارتر است. ابزاری به نام Soapy را برای تسهیل میتوانید در وب ببینید


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

مقوله Risk Appetite یا «اشتهای ریسک» میزان ریسکی است که یک سازمان حاضر به پذیرش آن پیش از اقدام به کنترل یا کاهش است. این مفهوم نشان می‌دهد که کجا می‌توان منابع را صرف کنترل کرد و کجا پذیرش ریسک به‌صرفه‌تر است.
در پیاده‌سازی ISO/IEC 27001، تعیین Risk Appetite نقش کلیدی در فاز Risk Assessment دارد؛ چون چارچوب تصمیم‌گیری برای انتخاب کنترل‌ها را مشخص می‌کند. اگر اشتهای ریسک پایین باشد، سازمان کنترل‌های بیشتری اعمال می‌کند و انطباق سخت‌گیرانه‌تری خواهد داشت. اگر بالا باشد، برخی ریسک‌ها پذیرفته می‌شوند و مستندسازی آن به عنوان بخشی از Risk Treatment Plan الزامی است.
این شفافیت از دوباره‌کاری و هدررفت منابع جلوگیری می‌کند.



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

بررسی یکی از آرتیفکت های DFIR

میتوانید با من ۳۰ ساعت DFIR رو همگام باشید در کلاس سنز ۶۰۸

واتس اپ و بله 09902857290

چرا چک‌لیست "ذهنیت امنیتی" در مصاحبه استخدامی در حوزه امنیت سایبری ضروری است؟ Security mindset

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

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


چند مثال از سوالات مصاحبه:

۱، توجه به جزئیات (Attention to Detail)

تشخیص ناهماهنگی ظریف در آدرس IP یا آدرس URL.
مشاهده تفاوت جزئی در زمان‌بندی لاگ‌ها و توضیح احتمال منبع آن.
کشف تغییر کوچک در رکوردهای DNS یا تنظیمات فایروال.

۲. تفکر بدخواهانه محور (Adversarial Thinking)

تصور مسیر حرکت یک مهاجم پس از نفوذ اولیه.
تشخیص نشانه‌های اولیه Command & Control در ترافیک.
پیش‌بینی مراحل بعدی حمله بر اساس رفتار فعلی سیستم.

۳. تحلیل نشانه‌های غیرمستقیم (Indirect Evidence)

شناسایی ارتباط مشکوک بدون لاگ واضح از ابزار اصلی.
بررسی الگوهای غیرعادی مصرف CPU و RAM به‌عنوان شاخص نفوذ.

۴. مهارت پرسش‌گری و صحت‌سنجی (Critical Questioning)

پرسیدن «چه اگر»های امنیتی پیش از ارائه پاسخ نهایی.
طراحی چند فرضیه همزمان برای یک رویداد مشکوک.

۵. بدبینی سازنده (Healthy Paranoia)

فرض تقلب پیش‌فرض: وقتی کاربر یا سرویس رفتار «خیلی بی‌نقص» دارد، احتمال سناریوی ساختگی یا تست مهاجم داخلی را در نظر بگیرد.
اعتماد صفر (Zero Trust): حتی به منابع داخلی فقط در صورت احراز دقیق اعتماد کند.
تفسیر دوباره علائم ظاهراً بی‌ضرر: شناسایی اینکه یک فایل «readme.txt» می‌تواند بخشی از مکانیزم Command & Control باشد.
شک به الگوهای بیش‌ازحد نرمال: زمانی که همه سیستم‌ها برای مدت طولانی بدون گزارش خطا کار می‌کنند، احتمال پاک‌سازی لاگ‌ها را بررسی کند.



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

دوره مبانی امنیت AI


https://learn.microsoft.com/api/achievements/share/en-us/MahmoudSaad-9459/JUPSHM8T?sharingId=4C0CE74D1D73DAB8

گزارش VB2021-Slowik با عنوان The Baffling Berserk Bear به بررسی بیش از یک دهه فعالیت گروه Berserk Bear (شناخته‌شده با نام‌هایی مانند Dragonfly و Energetic Bear) می‌پردازد. این گروه از حدود سال ۲۰۱۰ تاکنون به زیرساخت‌های حیاتی در اروپا و آمریکای شمالی نفوذ کرده است. برخلاف گروه‌هایی مانند Sandworm، تمرکز Berserk Bear بیشتر بر جمع‌آوری اطلاعات، دسترسی بلندمدت و آماده‌سازی برای بحران‌های آینده بوده و کمتر شواهدی از خرابکاری مستقیم وجود دارد.
در موج اول (۲۰۱۰–۲۰۱۴)، آن‌ها با فیشینگ، حملات زنجیره تأمین و exploit kits، بدافزار Havex را منتشر کردند که قابلیت نقشه‌برداری شبکه‌های صنعتی (ICS) و اسکن پروتکل‌های صنعتی مانند Modbus را داشت. در برخی موارد، این فعالیت‌ها باعث اختلال ناخواسته در سیستم‌های صنعتی شد. در دوره دوم (۲۰۱۵–۲۰۱۹)، تمرکز بر سرقت اعتبارنامه‌ها و استفاده از حملات watering hole بود که بیشتر بخش انرژی اروپا، ترکیه، آمریکا و بریتانیا را هدف گرفت.
از ۲۰۱۹ به بعد، حملات این گروه به حوزه‌های جدید مانند رسانه‌ها و زیرساخت‌های مرتبط با انتخابات در اوکراین و آمریکا گسترش یافت، با هدف جاسوسی و نظارت، نه تخریب. دولت‌های غربی این گروه را به روسیه و به‌ویژه FSB مرتبط می‌دانند. در مجموع، Berserk Bear نمونه‌ای از تهدیدات پایدار دولتی است که بدون سروصدا، زیرساخت‌های حیاتی را برای نفوذ بلندمدت و سناریوهای احتمالی آینده آماده می‌کند.

https://vblocalhost.com/uploads/VB2021-Slowik.pdf

آنجا که نمیتوان به EDR اعتماد کرد
بیایید با محدودیت های EDR آشنا شویم


همه EDRها (چه CrowdStrike چه Defender ATP یا SentinelOne چه محصولات ایرانی) ذاتاً نیاز دارند OS حداقل تا کرنل بیاد بالا تا بتونند Agent/Driver خودشون رو لود کنند.
مکانیزم‌های مقابله در Pre-OS خودشون EDR نیستند، بلکه:

✳️ مساله Secure Boot + Measured Boot + ELAM
✳️ ترکیب با Remote Attestation via TPM (ارسال PCR Values به Server امن)
✳️ و Off-Host Scanning (مثل استفاده از یک محیط Boot امن برای بررسی EFI و دیسک)

اگر این مکانیزم‌ها فعال/به‌روز نباشن، EDR به‌تنهایی نمی‌تونه جلوی Bootkit رو بگیره.

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

#جدید

کتابچه شکار تهدید

کمک به شکارچیان تهدید و حتی دانشمندان داده برای اجرای سریع جستجوها و تحلیل‌ها با کوئری‌های از پیش آماده در محیط‌هایی مثل Splunk.

ویژگی‌ها و نکات:

بخشی از مجموعه #SURGe (تیم تحقیقاتی Splunk) است.
بر پایه‌ی چارچوب PEAK Threat Hunting ساخته شده.
حاوی «دستورالعمل‌ها» یا SPL Recipes آماده برای وظایف متداول تحلیل و Threat Hunting است.

#ThreatHunting

#آکادمی_روزبه

#امنیت_به_زبان_ساده
جدول MITRE ATT&CK یک پایگاه دانش جهانی است که تاکتیک‌ها و تکنیک‌های حملات سایبری که تاکنون به سطح زمین آمده اند ( از دارک وب ) را دسته‌بندی می‌کند.

ایده‌اش ساده است: مثل یک جدول تناوبی عناصر، ولی برای هکرها!

ستون‌ها: تاکتیک‌ها (Tactics) یعنی هدف مرحله‌ای مهاجم — مثل دسترسی اولیه، اجرای کد، جمع‌آوری اطلاعات، یا خروج داده.
ردیف‌ها: تکنیک‌ها (Techniques) که روش عملی انجام هر تاکتیک را نشان می‌دهند؛ مثلا برای اجرای کد می‌تواند از PowerShell، نفوذ در کرنل یا بدافزار استفاده شود.
هر تکنیک گاهی زیرتکنیک دارد با جزئیات دقیق‌تر.
در کنار آن‌ها، اطلاعاتی مثل نمونه‌های واقعی، ابزارهای معروف، و روش‌های شناسایی/دفاع هم ارائه می‌شود.

کاربردش برای SOC و تیم امنیت این است که بتوانند:

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

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



🟣و اما نکته ای برای افراد کهنه کار :

حرکت هکر لازم نیست کاملا برای اساس جدول مایتره باشد .
فرض کنید در پالایشگاه تیم SOC یک سناریوی حمله بر اساس MITRE ATT&CK ترسیم کرده:

ستون‌ها را به شکل مرتب می‌چینند:

Initial Access >> ایمیل Phishing به حساب کاربری پیمانکار.
Execution >> اجرای ماکرو مخرب روی لپ‌تاپ پیمانکار در شبکه IT.
Lateral Movement >> دسترسی به سرور OT Gateway.
Impact >> تغییر تنظیمات کنترل فشار.

اما مهاجم واقعی ممکن است پس از مرحله Lateral Movement دوباره برگردد به Discovery، برای شناسایی سیستم‌های کنترلی حساس، یا حتی به Credential Access برای سرقت دسترسی ادمین PLC.

اگر SOC فقط خطی نگاه کند (“گام بعدی حتماً Impact است”)، این برگشت مهاجم را نمی‌بیند.

نتیجه چیست؟
مهاجم می‌تواند چند روز در شبکه بماند، مسیرهای جانبی برود و چندین نقطه حساس را بدون آشکار شدن کنترل کند.

برای پالایشگاه، یعنی باید برای هر تکنیک پوشش نظارتی مستقل گذاشت، حتی اگر فکر می‌کنیم “از آن مرحله گذشته‌ایم.”


🔆امیدوارم برایتان جالب بوده باشد


🔰سه شنبه سطح ۱ رو شروع میکنم و پنج شنبه CISSP
واتس اپ برای ملحق شدن به من و سایر دانشجویان 09902857290 گپی خودمانی به ساده‌ترین روش و زبان برای بیان مسائل پیچیده دنیای امنیت

آنجا که نگهبان صنعتی کور می‌شود: حملات DMA در محیط‌های کنترل صنعتی


در قسمت قبل دیدیم که حتی قوی‌ترین EDRها در برابر حملات سطح پایین مثل Bootkit یا Firmware در ابتدای راه‌اندازی سیستم، بسیار آسیب‌پذیرند. این‌بار، به دنیای کنترل صنعتی (ICS/SCADA) می‌رویم و بررسی می‌کنیم که چگونه حملات سخت‌افزاری Direct Memory Access (DMA) می‌توانند در بطن یک کارخانه یا پالایشگاه، بی‌سروصدا امنیت را دور بزنند.

مقولهDMA چیست و چرا خطرناک است؟
این DMA قابلیتی در معماری سیستم‌های مدرن است که به قطعات جانبی (مثل کارت شبکه، کنترلر ذخیره‌سازی یا حتی پورت Thunderbolt) اجازه می‌دهد مستقیماً به حافظه سیستم (RAM) دسترسی داشته باشند، بدون عبور از CPU و سیستم‌عامل. این یعنی:
مهاجم می‌تواند محتویات حساس RAM را بخواند (رمزها، کلیدهای رمزنگاری، داده‌های فرآیندی).
یا کد مخرب را مستقیم به حافظه یک فرآیند معتبر تزریق کند، بدون اینکه EDR حتی متوجه شود.

چرا محیط‌های صنعتی آسیب‌پذیرترند؟

برخلاف دیتاسنترها که کنترل فیزیکی بسیار سخت‌گیرانه دارند، محیط‌های ICS ویژگی‌هایی دارند که DMA را از یک تهدید نظری به یک تهدید عملیاتی تبدیل می‌کند:
1. دسترسی فیزیکی آسان‌تر
تجهیزات OT (HMI‌ها، ایستگاه‌های مهندسی، سرورهای Historian) معمولاً نزدیک خط تولید یا در اتاق‌های کنترل قرار دارند.
پیمانکاران، اپراتورها و تیم تعمیرات، به این سیستم‌ها دسترسی فیزیکی موقت یا دائم دارند.
2. وجود پورت‌های مناسب حمله
بسیاری از HMIها یا ایستگاه‌های مهندسی، لپ‌تاپ صنعتی یا ورک‌استیشن هستند که پورت USB‑C با حالت Alternate Mode، USB 3.x، یا حتی اسلات PCIe خارجی دارند.
برخی PLCها یا کنترلرهای مدرن نیز کارت‌های توسعه Mini‑PCIe یا PCIe دارند که در دسترس فیزیکی هستند.
3. دفاع نرم‌افزاری ضعیف‌تر
سیستم‌عامل‌های قدیمی (Windows 7، XP Embedded، Linux‌های قدیمی) که Kernel DMA Protection یا IOMMU فعال ندارند، هنوز فراگیرند.
بروزرسانی‌های امنیتی سال‌ها عقب افتاده‌اند، چون تغییر نرم‌افزار در ICS ریسک توقف تولید دارد.
4. سناریوی پیمانکار آلوده
مهاجم می‌تواند با لپ‌تاپ خود یا یک دانگل “خدماتی” به سیستم متصل شود (برای آپلود تنظیمات PLC یا مانیتورینگ)، اما در پس‌زمینه حمله DMA انجام دهد.
ریسک‌ها و پیامدها
وقتی کد مخرب از طریق DMA تزریق شد:
دستکاری فرآیندهای کنترلی بدون شناسایی توسط EDR یا آنتی‌ویروس
تغییر مقادیر Setpoint یا مقادیر حسگرها به شکل مخفیانه
جمع‌آوری داده‌های حساس فرآیندی یا مالکیتی بدون ایجاد هرگونه Log

راهکارهای دفاعی پیشنهادی برای ICS

غیرفعال‌سازی پورت‌های پرسرعت بلااستفاده از طریق BIOS/UEFI.
استفاده از کیس‌ها و رک‌های قفل‌دار با برچسب‌های Tamper-Evident.
اجرای سیاست فیزیکی سخت‌گیرانه برای اتصال هر گونه دستگاه پیمانکار.
به‌روزرسانی تدریجی سیستم‌عامل‌ها به نسخه‌هایی که IOMMU و Kernel DMA Protection را پشتیبانی کنند.
آموزش به پرسنل درباره ریسک تجهیزات جانبی ناشناس (USB Drives, Dongles, Adapters).

این هفته دوره های سطح ۱ و CISSP رو شروع میکنم