وقتی یک «در» را می‌بندیم، مهاجم از دیوار می‌آید!

مایکروسافت wmic.exe را بازنشسته کرد. آیا مهاجم‌ها دیگر نمی‌توانند از WMI سوءاستفاده کنند؟

❌ خیر! فقط آچارشان عوض شده.

دیروز:



bash

wmic process call create "calc.exe"

امروز:


powershell

Invoke-WmiMethod -Class Win32_Process -Name Create -ArgumentList "calc.exe"

📌 واقعیت: WMI سرویس و API هنوز فعال است. PowerShell، VBScript، C# یا حتی Python همچنان می‌توانند همان عملیات را انجام دهند — حتی بهتر و بی‌سروصداتر.

🚨 تهدید را حذف نکردیم، فقط شکلش را عوض کردیم. پایش (Monitoring) WMI API هنوز از نان شب واجب‌تر است.

#Security #ThreatDetection #آکادمی_روزبه #EDR #CyberSecurity #WMI

مرجع:
https://lnkd.in/gUSGHkmc
https://lnkd.in/p/gyZxuf_

ابزار Auditd؛ ابزار ممیزی امنیتی در لینوکس

ابزار Auditd سرویس اصلی ممیزی امنیتی در لینوکس است که رویدادها را از Linux Audit Framework در سطح Kernel دریافت و ثبت می‌کند. این ابزار کمک می‌کند مشخص شود چه کاربری، در چه زمانی، با کدام پردازش و شناسه کاربری، چه عملی را روی کدام منبع انجام داده است.

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

ابزار auditctl برای مشاهده و اعمال موقت قواعد به‌کار می‌رود؛ اما قواعد پایدار معمولاً در مسیر /etc/audit/rules.d/ تعریف و هنگام راه‌اندازی بارگذاری می‌شوند. همچنین ausearch برای جست‌وجوی رخدادها و aureport برای تهیه گزارش‌های خلاصه کاربرد دارد.

برای نمونه، نظارت بر /etc/passwd می‌تواند تغییر حساب‌های کاربری را آشکار کند. البته یک رخداد ممکن است در چند رکورد مانند SYSCALL، EXECVE، PATH و CWD ثبت شود که با شناسه مشترک به یکدیگر مرتبط‌اند.

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

#Auditd #LinuxAudit #LinuxSecurity #LinuxForensics #DigitalForensics #DFIR #IncidentResponse #SecurityMonitoring #SIEM #SOC #CyberSecurity #ThreatDetection #فارنزیک_دیجیتال #فارنزیک_لینوکس #امنیت_لینوکس #ممیزی_امنیتی #پاسخگویی_به_حادثه #مرکز_عملیات_امنیت #مهندسی_کشف #امنیت_سایبری

چرا ممکن است از Auditd ناامید شویم؟

ابزار Auditd یکی از مهم‌ترین ابزارهای ممیزی امنیتی در لینوکس است؛ اما اگر با انتظار یک EDR کامل یا نسخه لینوکسی Sysmon به سراغ آن برویم، احتمالاً ناامید خواهیم شد.

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

مشکل دیگر، حجم و پیچیدگی داده‌هاست. فعال‌کردن قواعد گسترده، به‌ویژه برای System Callها، می‌تواند میلیون‌ها رویداد ایجاد کند. از طرف دیگر، یک فعالیت ساده ممکن است در چند رکورد مانند SYSCALL، EXECVE، PATH و CWD پراکنده شود. تبدیل این اطلاعات خام به یک روایت قابل‌فهم، به Parsing، Normalization و Correlation نیاز دارد.

پرشدن Backlog، کمبود فضای دیسک یا تنظیمات نامناسب Log Rotation نیز ممکن است باعث ازدست‌رفتن رویدادها شود. مهاجمی که به سطح Root دست یافته است نیز احتمالاً تلاش می‌کند سرویس را متوقف، Rules را تغییر یا لاگ‌ها را پاک کند.

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

#Auditd #LinuxAudit #LinuxSecurity #LinuxLogging #SecurityMonitoring #ThreatDetection #DetectionEngineering #DigitalForensics #LinuxForensics #IncidentResponse #DFIR #SIEM #SOC #CyberSecurity #امنیت_لینوکس #ممیزی_امنیتی #فارنزیک_لینوکس #مهندسی_کشف #پایش_امنیتی #پاسخگویی_به_حادثه #امنیت_سایبری

آیا مهاجم دارای دسترسی Root می‌تواند Immutable Rules را تغییر دهد؟

یکی از قابلیت‌های مهم Auditd در لینوکس، قفل‌کردن تنظیمات ممیزی با دستور -e 2 است. پس از فعال‌شدن این وضعیت، قوانین Audit موجود در Kernel به حالت Immutable درمی‌آیند؛ یعنی تا زمان راه‌اندازی مجدد سیستم، حتی کاربر root نیز نمی‌تواند از طریق روش‌های معمول Rule جدیدی اضافه کند، قوانین موجود را حذف کند یا Audit را غیرفعال سازد.

در این وضعیت، فرمان‌هایی مانند auditctl -D یا auditctl -e 0 توسط Kernel رد می‌شوند. این قابلیت مانع مهمی در برابر مهاجمی است که پس از دسترسی ممتاز، قصد دارد ثبت فعالیت‌های خود را متوقف کند. بااین‌حال، Immutable Rules به معنی مصونیت کامل Auditd در برابر مهاجم Root نیست.

مهاجم همچنان ممکن است فایل‌های موجود در /etc/audit/rules.d/ را تغییر دهد تا پس از Reboot، قوانین ضعیف‌تر یا ناقصی بارگذاری شوند. او همچنین می‌تواند تنظیمات Boot را هدف قرار دهد، فضای دیسک را پر کند، به Audit Backlog فشار وارد سازد یا فایل‌های لاگ محلی را حذف کند. در صورت تسلط بر Kernel یا Boot Chain نیز امکان دورزدن کنترل‌های ممیزی افزایش می‌یابد.

بنابراین Immutable Rules صرفاً پیکربندی فعال Audit در Kernel را طی Boot جاری قفل می‌کنند؛ نه اینکه تمام اجزای ثبت و نگهداری شواهد را غیرقابل‌دست‌کاری سازند.

برای ایجاد دفاع مؤثر، باید این قابلیت با ارسال فوری لاگ‌ها به SIEM یا سامانه راه دور، Secure Boot، حفاظت از Bootloader، کنترل دسترسی Root، پایش تغییر فایل‌های Audit و هشدار درباره Reboot، توقف سرویس، پرشدن Backlog و Lost Events ترکیب شود. Immutable Rules یک لایه دفاعی ارزشمند است، نه راهکاری مستقل و شکست‌ناپذیر.

**فشار به Audit Backlog یعنی رویدادهای ممیزی با سرعتی بیشتر از توان پردازش Auditd تولید شوند و صف موقت آن در Kernel پر شود.

#Auditd #ImmutableRules #LinuxAudit #LinuxSecurity #LinuxForensics #DigitalForensics #DFIR #IncidentResponse #SecurityMonitoring #DetectionEngineering #SIEM #SOC #CyberSecurity #امنیت_لینوکس #ممیزی_امنیتی #فارنزیک_لینوکس #مهندسی_کشف #پاسخگویی_به_حادثه #امنیت_سایبری

4️⃣مقاله چهارم و پایان : CiliumHound چگونه مسیرهای حمله را آشکار می‌کند؟

در یک Cluster بزرگ، بررسی دستی فایل‌های Network Policy نمی‌تواند به‌سادگی نشان دهد که پس از تسخیر یک Pod چه مسیرهایی در اختیار مهاجم قرار می‌گیرد.

این CiliumHound اطلاعات Kubernetes و سیاست‌های شبکه Cilium را جمع‌آوری و در قالب BloodHound OpenGraph نمایش می‌دهد. در این گراف، اجزایی مانند Workloadها و Namespaceها به‌صورت Node و دسترسی‌های میان آن‌ها به‌صورت Edge دیده می‌شوند.

فرض کنید Web Pod اجازه ارتباط با API Pod را دارد و API نیز می‌تواند به Database و Admin Service متصل شود. مهاجمی که Web Pod را تصرف کرده است، شاید مستقیماً به پایگاه‌داده دسترسی نداشته باشد؛ اما گراف مسیر زیر را آشکار می‌کند:

Web Pod → API Pod → Database

این زنجیره یک Attack Path است. CiliumHound کمک می‌کند سیاست‌های بیش‌ازحد باز، ارتباطات ناخواسته میان Namespaceها و مسیرهای احتمالی حرکت جانبی شناسایی شوند.

تفاوت مهم آن با Hubble این است که Hubble ترافیک مشاهده‌شده را نمایش می‌دهد، اما CiliumHound روی مسیرهایی تمرکز دارد که براساس Policyها امکان‌پذیرند؛ حتی اگر هنوز استفاده نشده باشند.

این CiliumHound جلوی حمله را نمی‌گیرد؛ بلکه نشان می‌دهد طراحی Microsegmentation کجا ممکن است برای مهاجم یک مسیر پنهان ساخته باشد.

#Kubernetes #KubernetesSecurity #Cilium #CiliumHound #BloodHound #OpenGraph #NetworkPolicy #Microsegmentation #eBPF #ContainerSecurity #CloudNativeSecurity #AttackPath #LateralMovement #ZeroTrust #DevSecOps #CyberSecurity #امنیت_کوبرنتیز #امنیت_کانتینر #ریزتقسیم‌بندی #مسیر_حمله #حرکت_جانبی #امنیت_ابری #امنیت_سایبری #مهندسی_کشف

آنچه که بعنوان MZ در امنیت گفته میشود چیست و چرا در تحلیل بدافزار اهمیت دارد؟

عبارت "MZ" دو بایت ابتدایی بسیاری از فایل‌های اجرایی ویندوز است و در مبنای هگزادسیمال به‌صورت "4D 5A" نمایش داده می‌شود. این حروف از نام Mark Zbikowski، یکی از مهندسان مایکروسافت و طراح قالب اجرایی DOS، گرفته شده‌اند.

فایل‌های اجرایی با ساختار PE، مانند فایل‌های "EXE"، "DLL"، "SYS" و برخی "SCR"ها، معمولاً با امضای MZ آغاز می‌شوند. بخش ابتدایی فایل، "DOS Header" نام دارد. درون این Header، فیلدی به نام "e_lfanew" وجود دارد که محل قرارگیری امضای "PE" و ساختار اصلی فایل اجرایی ویندوز را مشخص می‌کند.

اهمیت MZ زمانی آشکار می‌شود که مهاجم پسوند واقعی فایل را پنهان کرده باشد. برای مثال ممکن است فایلی با نام "update.dat"، "invoice.jpg" یا "document.pdf" دریافت شود، اما بررسی محتوای آن نشان دهد که دو بایت ابتدایی فایل "MZ" است. این وضعیت نشان می‌دهد فایل احتمالاً یک برنامه اجرایی ویندوز است، نه تصویر یا سند معمولی.

در تحلیل PCAP می‌توان فایل منتقل‌شده را از جریان HTTP یا SMB استخراج و Header آن را بررسی کرد. بااین‌حال، مشاهده MZ به‌تنهایی اثبات بدافزاربودن فایل نیست؛ زیرا برنامه‌های سالم ویندوز نیز همین امضا را دارند. تحلیلگر باید Hash، امضای دیجیتال، Importها، رشته‌ها، رفتار اجرایی و نتایج Sandbox را نیز بررسی کند.



#MZ #PEFile #PortableExecutable #MalwareAnalysis #DigitalForensics #MemoryForensics #NetworkForensics #PCAP #Wireshark #ThreatHunting #IncidentResponse #ReverseEngineering #SOC #CyberSecurity #تحلیل_بدافزار #فارنزیک_دیجیتال #تحلیل_ترافیک #امنیت_سایبری #مرکز_عملیات_امنیت #آکادمی_روزبه

مقوله DevSecOps؛ امنیت به‌عنوان بخشی از فرایند توسعه

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

در این رویکرد، Pipeline می‌تواند به‌صورت خودکار کد، کتابخانه‌ها، Container Image، تنظیمات زیرساخت و Secretها را ارزیابی کند. ابزارهایی مانند SAST، DAST، SCA، IaC Scanning و Secret Scanning به شناسایی زودهنگام ضعف‌ها کمک می‌کنند؛ اما DevSecOps صرفاً مجموعه‌ای از ابزارها نیست. فرهنگ همکاری میان توسعه‌دهندگان، تیم عملیات و متخصصان امنیت، هسته اصلی آن را تشکیل می‌دهد.

یکی از نقاط حساس، اجرای کد متعلق به Pull Requestهای تأییدنشده است. چنین کدی نباید در محیطی اجرا شود که به Token، Cloud Credential، Registry یا Runnerهای عملیاتی دسترسی دارد. تفکیک Pipelineهای غیرقابل‌اعتماد، اعمال Least Privilege، استفاده از Runnerهای موقت و فعال‌سازی Approval پیش از Deployment از کنترل‌های ضروری هستند.

هدف DevSecOps متوقف‌کردن توسعه نیست؛ بلکه تولید نرم‌افزار امن‌تر با سرعتی پایدار است. امنیت زمانی مؤثر خواهد بود که در معماری، کد، Pipeline و عملیات روزانه حضور داشته باشد، نه اینکه فقط پیش از انتشار بررسی شود.



#DevSecOps #DevOps #CyberSecurity #ApplicationSecurity #SecureCoding #SoftwareSecurity #CICD #SecurityAutomation #ShiftLeftSecurity #CloudSecurity #PipelineSecurity #SupplyChainSecurity #SAST #DAST #SCA #امنیت_سایبری #امنیت_نرم_افزار #توسعه_امن #مهندسی_امنیت #آکادمی_روزبه

مقوله SOC as a Service؛ وقتی مرکز عملیات امنیت تبدیل به «سرویس» می‌شود

بحث SOC as a Service (SOCaaS) مدلی است که در آن سازمان به‌جای ساخت و اداره کامل یک Security Operations Center در داخل مجموعه، بخشی یا تمام قابلیت‌های SOC را از یک ارائه‌دهنده تخصصی دریافت می‌کند.

در این مدل، موضوع صرفاً خرید SIEM یا مانیتورینگ چند داشبورد نیست؛ بلکه مجموعه‌ای از People + Process + Technology به‌صورت یک سرویس مستمر ارائه می‌شود.

یک SOCaaS بالغ معمولاً شامل جمع‌آوری و پایش Log و Telemetry، مدیریت SIEM، تحلیل Alert، Triage توسط L1، تحلیل عمیق‌تر توسط L2/L3، Threat Intelligence، Detection Engineering، Threat Hunting، مدیریت Use Caseها، گزارش‌دهی و Escalation است.

بسته به قرارداد، Incident Response نیز می‌تواند بخشی از سرویس باشد.

مزیت مهم SOCaaS، دسترسی سازمان به تیم متخصص بدون نیاز به ایجاد کامل یک SOC داخلی 24×7 است. هزینه جذب و نگهداری Analyst، Detection Engineer و Threat Hunter کاهش می‌یابد و ارائه‌دهنده می‌تواند تجربه حاصل از مشاهده محیط‌های متعدد را وارد عملیات کند.

اما SOCaaS مساوی برون‌سپاری مسئولیت امنیت نیست. مالکیت Risk، تصمیمات حساس، پذیرش ریسک و Governance همچنان باید در سازمان باقی بماند. همچنین SLA، زمان تشخیص و Escalation، مالکیت داده، سطح دسترسی ارائه‌دهنده، Data Retention، محرمانگی و نحوه خروج از قرارداد باید دقیقاً مشخص شوند.

از نظر معماری نیز SOCaaS الزاماً Cloud SOC نیست. SIEM و داده‌ها می‌توانند کاملاً On-Premise نزد مشتری باقی بمانند، در حالی که تیم MSSP از راه دور عملیات SOC را انجام دهد.

بهترین نگاه به SOCaaS این است:

ما «SOC ایجاد نمیکنیم ؛ قابلیت مستمر کشف، تحلیل و مدیریت تهدید را به‌عنوان سرویس دریافت می‌کنیم.»


برای دریافت این سرویس با شرکت #هامون تماس حاصل فرمایید

Www.haumoun.com

#SOCaaS #SOC #MSSP #SIEM #DetectionEngineering #ThreatHunting #CyberSecurity #SecurityOperations #IncidentDetection #BlueTeam

ویدئوی آموزشی من در صفحه لینکدین شرکت #هامون در مورد دزدی اطلاعات با ابزار های خودمان

https://www.linkedin.com/posts/haumoun_aepaetaeuahyaes-cybersecurity-threatdetection-ugcPost-7512849075617173504-0OcV?utm_source=share&utm_medium=member_android&rcm=ACoAAAoOfTcB5k1E_hg69jDwmxkGWzsBxqx6B9s

ویدئوی من از BITS در صفحه شرکت هامون

https://www.linkedin.com/posts/haumoun_aepaetaeuahyaes-cybersecurity-threatdetection-activity-7512849219372843008-rsyJ?utm_source=share&utm_medium=member_android&rcm=ACoAAAoOfTcB5k1E_hg69jDwmxkGWzsBxqx6B9s

👆👆کیفیت آموزش : دوره 100 دلاری آکادمی روزبه در مقابل دوره های 3000 دلاری سایر موسسات خارجی

✳️قبولی در CISSP؛ مسیری فراتر از ۳۰ ساعت کلاس
⬅️تعهد به این مسیر است ضامن قبولی

قبولی یکی از دانشجویان مقیم خارج آکادمی روزبه در آزمون رسمی CISSP، خبری خوش و فرصتی برای توضیح یک نکته مهم است: موفقیت در این آزمون، حاصل ترکیب آموزش، تمرین، همفکری و تلاش مستمر دانشجوست.

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

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

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

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

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

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


#CISSP #آکادمی_روزبه #امنیت_اطلاعات #امنیت_سایبری #آموزش_CISSP #آموزش_امنیت #یادگیری_مستمر #توسعه_حرفه‌ای #منتورینگ #CyberSecurity #InformationSecurity #ISC2

#امنیت_به_زبان_ساده

سرویس WinRM (Windows Remote Management) سرویس مدیریت از راه دور ویندوز است؛ به ادمین اجازه می‌دهد از طریق شبکه، روی سیستم‌های دیگر فرمان اجرا کند، اطلاعات بگیرد و تنظیمات را مدیریت کند. PowerShell Remoting معمولاً از WinRM استفاده می‌کند.

پورت‌های پیش‌فرض آن عبارت‌اند از:

- TCP 5985: ارتباط HTTP
- TCP 5986: ارتباط HTTPS

هکر با آن چه می‌کند؟ اگر مهاجم اعتبارنامه معتبر و مجوز لازم برای اتصال داشته باشد، می‌تواند از WinRM برای این کارها استفاده کند:

- حرکت جانبی: از سیستم اولیه به سرورها و سیستم‌های دیگر متصل شود.
- اجرای فرمان از راه دور: فرمان‌ها و اسکریپت‌های خود را روی مقصد اجرا کند.
- شناسایی محیط: کاربران، سرویس‌ها، پردازش‌ها و تنظیمات سیستم را بررسی کند.
- اجرای ابزار یا بدافزار: با سطح دسترسی حسابی که در اختیار دارد.
- استفاده از ابزارهای بومی ویندوز: فعالیت مخرب را میان عملیات عادی مدیریت سیستم پنهان کند؛ نمونه‌ای از رویکرد Living off the Land.

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

نکته برای SOC: در بسیاری از اجرای‌های PowerShell Remoting، پردازش wsmprovhost.exe در مقصد دیده می‌شود. بررسی فرمان‌ها و پردازش‌های مرتبط با آن، همراه با مبدأ اتصال و حساب استفاده‌شده، ارزشمند است؛ وجود این پردازش به‌تنهایی نشانه حمله نیست.

فعال بودن WinRM به‌خودی‌خود یعنی هک شدن سیستم نیست؛ خطر اصلی، دسترسی شبکه‌ای گسترده و سوءاستفاده از حساب‌های مجاز است.


#WinRM #PowerShell #WindowsSecurity #CyberSecurity #SOC #ThreatHunting #LateralMovement #LivingOffTheLand #BlueTeam #امنیت_سایبری #امنیت_ویندوز #مرکز_عملیات_امنیت #شکار_تهدید #آکادمی_روزبه

👆👆ترجمه نوشته جناب مهدی رضایی در لینکدین :

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

من نخستین بار از طریق او با ISC2 و CISSP آشنا شدم؛ اما آنچه بیش از همه در ذهنم ماند، رویکرد او به امنیت بود.

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

پیش از شرکت در آزمون، دوره‌ای را با او گذراندم. در آن دوره، درسی را به‌خوبی در ذهنم جا انداخت که همچنان همراه من است: به هر سؤال از دریچه ریسک و با ذهنیت یک مشاور سیاست‌گذاری نگاه کنید.

همین نگاه، راهگشا شد.

روزبه،
سپاسگزارم که مرا نه‌فقط با ISC2 و CISSP، بلکه با شیوه‌ای از تفکر درباره امنیت آشنا کردی که در سراسر مسیر حرفه‌ای‌ام همراه من بوده است.

همچنین مفتخرم اعلام کنم که اکنون رسماً به جمع جامعه دارندگان CISSP در ISC2 پیوسته‌ام.

#Cybersecurity #CISSP #ISC2 #RiskBasedSecurity