🥇سناریوی امشب : کشف نفوذ آرام با ماندگاری طولانی
✅یک سناریوی پیچیده و جذاب برای کشف نفوذ با کمک از Splunk براتون آماده کردم که ترکیبی از تکنیکهای فرار از شناسایی (Evasion)، حرکت جانبی (Lateral Movement) و دسترسی مداوم (Persistence) است.
🟧یک مهاجم موفق شده است از طریق یک حمله فیشینگ هوشمند و اجرای ماکرو مخرب در Excel، کنترل اولیه را روی یک سیستم کاربر در شبکه به دست بگیرد. سپس با استفاده از Cobalt Strike و تکنیکهای Living off the Land (LOLBins)، در شبکه حرکت جانبی انجام داده و یک حساب کاربری جعلی در اکتیو دایرکتوری ایجاد میکند تا دسترسی دائمی داشته باشد.
🔰جزئیات حمله:
✔️ دریافت شل اولیه:
حمله فیشینگ با ارسال یک فایل Excel حاوی ماکروی مخرب به کاربر.
اجرای ماکرو باعث دانلود و اجرای یک PowerShell reverse shell میشود که به یک C2 Server متصل است.
ارتباط بهصورت Encoded PowerShell ارسال میشود تا از SIEM و آنتیویروس فرار کند.
✔️ حرکت جانبی و افزایش دسترسی:
مهاجم از Mimikatz برای استخراج کردنشیالهای ذخیرهشده استفاده میکند.
از طریق Pass-the-Hash (PtH) به یک سرور داخلی متصل میشود.
با استفاده از PsExec یا WMI روی یک سیستم دیگر کد اجرا میکند.
استفاده از ابزارهای ذاتی ویندوز (LOLBins) برای فرار از شناسایی:
اجرای کدهای مخرب با MSBuild.exe و CertUtil.exe برای دور زدن ابزارهای امنیتی.
استفاده از Rundll32.exe برای اجرای فایل DLL مخرب بدون ایجاد پروسس جدید مشکوک.
✔️ ماندگاری و دسترسی مداوم:
ایجاد یک حساب جعلی در Active Directory با نامی شبیه به ادمینهای واقعی.
تنظیم یک Scheduled Task که در هر ریبوت، یک ریکانکت به C2 برقرار میکند.
ذخیره Web Shell در IIS روی یک سرور حساس برای دسترسی آینده.
🔮 بررسی کامل و انجام تحلیل در Splunk:
بحث کامل تحلیل و حل مساله را در پست های آینده بخوانید
🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer
✅یک سناریوی پیچیده و جذاب برای کشف نفوذ با کمک از Splunk براتون آماده کردم که ترکیبی از تکنیکهای فرار از شناسایی (Evasion)، حرکت جانبی (Lateral Movement) و دسترسی مداوم (Persistence) است.
🟧یک مهاجم موفق شده است از طریق یک حمله فیشینگ هوشمند و اجرای ماکرو مخرب در Excel، کنترل اولیه را روی یک سیستم کاربر در شبکه به دست بگیرد. سپس با استفاده از Cobalt Strike و تکنیکهای Living off the Land (LOLBins)، در شبکه حرکت جانبی انجام داده و یک حساب کاربری جعلی در اکتیو دایرکتوری ایجاد میکند تا دسترسی دائمی داشته باشد.
🔰جزئیات حمله:
✔️ دریافت شل اولیه:
حمله فیشینگ با ارسال یک فایل Excel حاوی ماکروی مخرب به کاربر.
اجرای ماکرو باعث دانلود و اجرای یک PowerShell reverse shell میشود که به یک C2 Server متصل است.
ارتباط بهصورت Encoded PowerShell ارسال میشود تا از SIEM و آنتیویروس فرار کند.
✔️ حرکت جانبی و افزایش دسترسی:
مهاجم از Mimikatz برای استخراج کردنشیالهای ذخیرهشده استفاده میکند.
از طریق Pass-the-Hash (PtH) به یک سرور داخلی متصل میشود.
با استفاده از PsExec یا WMI روی یک سیستم دیگر کد اجرا میکند.
استفاده از ابزارهای ذاتی ویندوز (LOLBins) برای فرار از شناسایی:
اجرای کدهای مخرب با MSBuild.exe و CertUtil.exe برای دور زدن ابزارهای امنیتی.
استفاده از Rundll32.exe برای اجرای فایل DLL مخرب بدون ایجاد پروسس جدید مشکوک.
✔️ ماندگاری و دسترسی مداوم:
ایجاد یک حساب جعلی در Active Directory با نامی شبیه به ادمینهای واقعی.
تنظیم یک Scheduled Task که در هر ریبوت، یک ریکانکت به C2 برقرار میکند.
ذخیره Web Shell در IIS روی یک سرور حساس برای دسترسی آینده.
🔮 بررسی کامل و انجام تحلیل در Splunk:
بحث کامل تحلیل و حل مساله را در پست های آینده بخوانید
Please open Telegram to view this post
VIEW IN TELEGRAM
Linux Persistence - systemd.pdf
682 KB
مکانیسم های حضور دائمی هکر در لینوکس
فارسی از جناب ملکی
🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer
فارسی از جناب ملکی
Please open Telegram to view this post
VIEW IN TELEGRAM
Please open Telegram to view this post
VIEW IN TELEGRAM
Network Security Channel
🥇سناریوی امشب : کشف نفوذ آرام با ماندگاری طولانی ✅یک سناریوی پیچیده و جذاب برای کشف نفوذ با کمک از Splunk براتون آماده کردم که ترکیبی از تکنیکهای فرار از شناسایی (Evasion)، حرکت جانبی (Lateral Movement) و دسترسی مداوم (Persistence) است. 🟧یک مهاجم موفق…
تحلیل سناریوی فوق در Splunk:
۱. کشف ارتباط اولیه (PowerShell Reverse Shell)
جستجوی دستورات مشکوک در لاگهای PowerShell که ممکن است ارتباط C2 برقرار کند:
index=windows EventCode=4104 ScriptBlockText="*IEX*(New-Object Net.WebClient).DownloadString*"
یا استفاده از Base64 encoded PowerShell:
index=windows EventCode=4104 ScriptBlockText="*FromBase64String*"
۲. کشف حرکت جانبی (Mimikatz و Pass-the-Hash)
index=windows EventCode=4624 LogonType=9 OR LogonType=3 Account_Name!=”Administrator” Account_Name!=”Service”
Logon Type 9: نشاندهنده استفاده از مکانیزمهای احراز هویت غیرمعمول است.
Logon Type 3: اتصال از راه دور، اما بدون نام کاربری ادمین، که مشکوک است.
۳. کشف اجرای ابزارهای LOLBins (مانند MSBuild و CertUtil)
index=windows EventCode=4688 New_Process_Name="*MSBuild.exe" OR New_Process_Name="*CertUtil.exe"
این پردازشها معمولاً در شبکه سازمانی استفاده نمیشوند، مگر در شرایط خاص.
۴. کشف ماندگاری (Scheduled Task و Web Shell در IIS)
index=windows EventCode=4698 OR EventCode=4700 Task_Name="*Update*"
بسیاری از مهاجمان برای فرار از شناسایی، نامهای مشابه آپدیتهای ویندوز برای Scheduled Task میگذارند.
و برای کشف Web Shell در IIS:
index=webserver sourcetype="iis" cs_uri_stem="*.asp" OR cs_uri_stem="*.aspx" cs_method="POST"
درخواستهای POST غیرعادی به صفحات ASPX ممکن است نشاندهنده یک Web Shell باشد.
🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer
۱. کشف ارتباط اولیه (PowerShell Reverse Shell)
جستجوی دستورات مشکوک در لاگهای PowerShell که ممکن است ارتباط C2 برقرار کند:
index=windows EventCode=4104 ScriptBlockText="*IEX*(New-Object Net.WebClient).DownloadString*"
یا استفاده از Base64 encoded PowerShell:
index=windows EventCode=4104 ScriptBlockText="*FromBase64String*"
۲. کشف حرکت جانبی (Mimikatz و Pass-the-Hash)
index=windows EventCode=4624 LogonType=9 OR LogonType=3 Account_Name!=”Administrator” Account_Name!=”Service”
Logon Type 9: نشاندهنده استفاده از مکانیزمهای احراز هویت غیرمعمول است.
Logon Type 3: اتصال از راه دور، اما بدون نام کاربری ادمین، که مشکوک است.
۳. کشف اجرای ابزارهای LOLBins (مانند MSBuild و CertUtil)
index=windows EventCode=4688 New_Process_Name="*MSBuild.exe" OR New_Process_Name="*CertUtil.exe"
این پردازشها معمولاً در شبکه سازمانی استفاده نمیشوند، مگر در شرایط خاص.
۴. کشف ماندگاری (Scheduled Task و Web Shell در IIS)
index=windows EventCode=4698 OR EventCode=4700 Task_Name="*Update*"
بسیاری از مهاجمان برای فرار از شناسایی، نامهای مشابه آپدیتهای ویندوز برای Scheduled Task میگذارند.
و برای کشف Web Shell در IIS:
index=webserver sourcetype="iis" cs_uri_stem="*.asp" OR cs_uri_stem="*.aspx" cs_method="POST"
درخواستهای POST غیرعادی به صفحات ASPX ممکن است نشاندهنده یک Web Shell باشد.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1👍1
تکنیک های بدافزارها علیه کشف
👿ضد مهندسی معکوس
در دنیای امنیت سایبری و تحلیل بدافزار، یکی از مهمترین چالشها برای هکر شناسایی و مقابله با تکنیکهای دیباگینگ و نقاط توقف (breakpoints) است که برای بررسی و تجزیه و تحلیل برنامههای آلوده به کار میروند. یکی از تکنیکهای رایج برای ایجاد نقاط توقف در فرآیند دیباگینگ، استفاده از پرچم ترپ (Trap Flag) در رجیستر EFLAGS است. این پرچم به دیباگرها این امکان را میدهد که بهصورت گامبهگام دستورات برنامه را اجرا کنند و تغییرات حافظه و رجیسترها را بررسی نمایند. با این حال، شناسایی استفاده از پرچم ترپ برای نقاط توقف میتواند چالشبرانگیز باشد، زیرا بهراحتی نمیتوان این پرچم را خواند و بررسی کرد.
🤡پرچم ترپ (Trap Flag) چیست؟
این Trap Flag (TF) یک پرچم خاص در رجیستر EFLAGS در معماری پردازندههای x86 است که برای فعال کردن Single-Stepping یا گامبهگام اجرا کردن دستورات برنامه به کار میرود. هنگامی که دیباگر بهطور گام به گام یک برنامه را تحلیل میکند، این پرچم در رجیستر EFLAGS تنظیم میشود تا پس از اجرای هر دستور، پردازنده یک Interrupt 1 (خطای دیباگ) ایجاد کند و کنترل را به دیباگر بازگرداند.
این ویژگی به دیباگر اجازه میدهد تا بتواند پس از اجرای هر دستور، وضعیت حافظه و مقادیر رجیسترها را بررسی کرده و تغییرات آنها را نظارت کند. بنابراین، Trap Flag یک ابزار بسیار مفید برای تحلیل و بررسی دقیق عملکرد برنامهها در سطح اسمبلی است.
👻چالشهای شناسایی Trap Flag:
هرچند استفاده از Trap Flag برای گام به گام اجرا کردن برنامه بسیار مفید است، اما شناسایی و تشخیص آن از بیرون (یعنی توسط خود برنامه یا ابزارهای شناسایی بدافزار) کار دشواری است. دلایل این مشکل عبارتند از:
✔️این EFLAGS بهطور مستقیم قابل خواندن نیست:
این EFLAGS که شامل Trap Flag میباشد، بهطور مستقیم از طریق دستوراتی مانند mov قابل خواندن نیست. برای خواندن وضعیت این رجیستر باید از دستور pushf استفاده کرد، که وضعیت EFLAGS را در استک ذخیره میکند.
✔️پرچم Trap Flag بهطور خودکار غیرفعال میشود:
پس از هر بار برگشت از دیباگر، Trap Flag بهطور خودکار به حالت False (غیرفعال) تغییر میکند. این ویژگی باعث میشود که بررسی وضعیت این پرچم برای شناسایی نقاط توقف در برنامه سخت باشد.
👽روشهای شناسایی رفتار دیباگینگ با استفاده از Trap Flag:
با وجود اینکه Trap Flag بهطور مستقیم قابل شناسایی نیست، روشهایی برای شناسایی رفتار دیباگرها و نقاط توقف وجود دارد. برخی از این روشها عبارتند از:
✔️ بررسی استک با استفاده از دستور pushf:
همانطور که اشاره شد، تنها راه دسترسی به وضعیت EFLAGS استفاده از دستور pushf است که وضعیت EFLAGS را در استک ذخیره میکند. بدافزار میتواند بهطور پیوسته وضعیت استک را بررسی کرده و در صورتی که تغییرات غیرمنتظرهای در آن مشاهده شود، به وجود یک دیباگر مشکوک شود.
✔️ تحلیل زمانبندی دستورات:
اجرای گام به گام دستورات توسط دیباگر باعث تغییرات در زمانبندی اجرای دستورات میشود. این زمانبندی ممکن است برای برنامه قابل شناسایی باشد. بهعنوان مثال، اگر برنامه بین هر دستور وقفههای کوچکی داشته باشد (که ناشی از فعال بودن Trap Flag است)، این تفاوتها میتوانند بهعنوان علائم رفتاری دیباگر شناسایی شوند.
🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer
👿ضد مهندسی معکوس
در دنیای امنیت سایبری و تحلیل بدافزار، یکی از مهمترین چالشها برای هکر شناسایی و مقابله با تکنیکهای دیباگینگ و نقاط توقف (breakpoints) است که برای بررسی و تجزیه و تحلیل برنامههای آلوده به کار میروند. یکی از تکنیکهای رایج برای ایجاد نقاط توقف در فرآیند دیباگینگ، استفاده از پرچم ترپ (Trap Flag) در رجیستر EFLAGS است. این پرچم به دیباگرها این امکان را میدهد که بهصورت گامبهگام دستورات برنامه را اجرا کنند و تغییرات حافظه و رجیسترها را بررسی نمایند. با این حال، شناسایی استفاده از پرچم ترپ برای نقاط توقف میتواند چالشبرانگیز باشد، زیرا بهراحتی نمیتوان این پرچم را خواند و بررسی کرد.
🤡پرچم ترپ (Trap Flag) چیست؟
این Trap Flag (TF) یک پرچم خاص در رجیستر EFLAGS در معماری پردازندههای x86 است که برای فعال کردن Single-Stepping یا گامبهگام اجرا کردن دستورات برنامه به کار میرود. هنگامی که دیباگر بهطور گام به گام یک برنامه را تحلیل میکند، این پرچم در رجیستر EFLAGS تنظیم میشود تا پس از اجرای هر دستور، پردازنده یک Interrupt 1 (خطای دیباگ) ایجاد کند و کنترل را به دیباگر بازگرداند.
این ویژگی به دیباگر اجازه میدهد تا بتواند پس از اجرای هر دستور، وضعیت حافظه و مقادیر رجیسترها را بررسی کرده و تغییرات آنها را نظارت کند. بنابراین، Trap Flag یک ابزار بسیار مفید برای تحلیل و بررسی دقیق عملکرد برنامهها در سطح اسمبلی است.
👻چالشهای شناسایی Trap Flag:
هرچند استفاده از Trap Flag برای گام به گام اجرا کردن برنامه بسیار مفید است، اما شناسایی و تشخیص آن از بیرون (یعنی توسط خود برنامه یا ابزارهای شناسایی بدافزار) کار دشواری است. دلایل این مشکل عبارتند از:
✔️این EFLAGS بهطور مستقیم قابل خواندن نیست:
این EFLAGS که شامل Trap Flag میباشد، بهطور مستقیم از طریق دستوراتی مانند mov قابل خواندن نیست. برای خواندن وضعیت این رجیستر باید از دستور pushf استفاده کرد، که وضعیت EFLAGS را در استک ذخیره میکند.
✔️پرچم Trap Flag بهطور خودکار غیرفعال میشود:
پس از هر بار برگشت از دیباگر، Trap Flag بهطور خودکار به حالت False (غیرفعال) تغییر میکند. این ویژگی باعث میشود که بررسی وضعیت این پرچم برای شناسایی نقاط توقف در برنامه سخت باشد.
👽روشهای شناسایی رفتار دیباگینگ با استفاده از Trap Flag:
با وجود اینکه Trap Flag بهطور مستقیم قابل شناسایی نیست، روشهایی برای شناسایی رفتار دیباگرها و نقاط توقف وجود دارد. برخی از این روشها عبارتند از:
✔️ بررسی استک با استفاده از دستور pushf:
همانطور که اشاره شد، تنها راه دسترسی به وضعیت EFLAGS استفاده از دستور pushf است که وضعیت EFLAGS را در استک ذخیره میکند. بدافزار میتواند بهطور پیوسته وضعیت استک را بررسی کرده و در صورتی که تغییرات غیرمنتظرهای در آن مشاهده شود، به وجود یک دیباگر مشکوک شود.
✔️ تحلیل زمانبندی دستورات:
اجرای گام به گام دستورات توسط دیباگر باعث تغییرات در زمانبندی اجرای دستورات میشود. این زمانبندی ممکن است برای برنامه قابل شناسایی باشد. بهعنوان مثال، اگر برنامه بین هر دستور وقفههای کوچکی داشته باشد (که ناشی از فعال بودن Trap Flag است)، این تفاوتها میتوانند بهعنوان علائم رفتاری دیباگر شناسایی شوند.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤1👍1
#تجربه
پایش تجهیزات شبکه
کشف نفوذ هایی که ندیده ایم
یکی از مواردی که در SOC هایی که مواجه میشم میبینم کم توجهی به لاگ های تجهیزات شبکه ای است.
🔴این لاگها معمولا مشکلات زیر را دارند:
- اصلا جمع نمیشوند
- میزان Granularity لازم را ندارند
- تمام و کمال پارس نمیشوند
- رولهای کشفی مناسب برای آنها در SIEM نوشته نشده است
- به میزان مناسب در پریود زمانی نگهداری نمیشوند
- توجه چندانی به آلرت های آنها وجود ندارد
⚠️این مسائل میتواند مسبب نفوذ های پیچیده و ماندگاری در شبکه های ما باشد. مخصوصا در شبکه هایی که به سمت نرم افزار محور شدن رفته اند یا شبکه هایی که ادمین آنها در مورد فریم ور دقت کافی ندارد
یک گرا بدهم😈 : گزارش این حمله گروه هکری روسی Grizzly Steppe رو بخونید تا به اهمیت موضوع پی ببرید
پی نوشت :راه اندازی سرور AAA یکی از ضروریات برای تجهیزات شبکه است.
https://cloud.google.com/blog/topics/threat-intelligence/synful-knock-acis
🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer
پایش تجهیزات شبکه
کشف نفوذ هایی که ندیده ایم
یکی از مواردی که در SOC هایی که مواجه میشم میبینم کم توجهی به لاگ های تجهیزات شبکه ای است.
🔴این لاگها معمولا مشکلات زیر را دارند:
- اصلا جمع نمیشوند
- میزان Granularity لازم را ندارند
- تمام و کمال پارس نمیشوند
- رولهای کشفی مناسب برای آنها در SIEM نوشته نشده است
- به میزان مناسب در پریود زمانی نگهداری نمیشوند
- توجه چندانی به آلرت های آنها وجود ندارد
⚠️این مسائل میتواند مسبب نفوذ های پیچیده و ماندگاری در شبکه های ما باشد. مخصوصا در شبکه هایی که به سمت نرم افزار محور شدن رفته اند یا شبکه هایی که ادمین آنها در مورد فریم ور دقت کافی ندارد
یک گرا بدهم😈 : گزارش این حمله گروه هکری روسی Grizzly Steppe رو بخونید تا به اهمیت موضوع پی ببرید
پی نوشت :راه اندازی سرور AAA یکی از ضروریات برای تجهیزات شبکه است.
https://cloud.google.com/blog/topics/threat-intelligence/synful-knock-acis
Please open Telegram to view this post
VIEW IN TELEGRAM
Google Cloud Blog
SYNful Knock - A Cisco router implant - Part I | Mandiant | Google Cloud Blog
❤1👍1
تکنیکهای ضد مهندسی معکوس
فاصله زمانی
در مهندسی معکوس و تحلیل بدافزار ما از اجرای single-stepping یا به تعبیری اجرای خط به خط برای رفتار شناسی قطعه کد مشکوک استفاده میکنیم.
هکر دنبال آن است که این حرکت ما را شناسایی کند تا بتواند خود را از این آنالیز برهاند.
یک راهکار استفاده از تکنیکهای زمانبندی برای شناسایی "single-stepping" در فرآیند دیباگ یا مهندسی معکوس است. در این روش، زمان دقیق (با دقت میلیثانیه) از لحظه شروع سیستم تا اجرای دستور خاصی اندازهگیری میشود. دستور rdtsc در معماری x86 برای این منظور استفاده میشود، که زمان سیستمی را در دو رجیستر EDX و EAX ذخیره میکند.
در فرآیند شبیهسازی دیباگ یا مهندسی معکوس (reverse engineering)، وقتی یک متخصص امنیت در حال اجرای کد است، ممکن است از تکنیکهایی مانند "single-stepping" استفاده کند. این به معنای اجرای کد خط به خط و بررسی هر دستور است. اما این کار باعث تأخیرهای زمانی میشود، چون در این فرآیند، پردازش کد به صورت تدریجی انجام میشود. اگر بتوان زمان دقیق قبل و بعد از اجرای یک دستور را محاسبه کرد، تأخیر ناشی از این فرآیند به وضوح قابل مشاهده خواهد بود.
با استفاده از دستور rdtsc، تفاوت زمانی بین دو نقطه (قبل و بعد از اجرای یک دستور) محاسبه میشود. اگر تأخیری در اجرای دستور مشاهده شود، این به احتمال زیاد نشاندهنده این است که یک دیباگر در حال "single-stepping" در کد است و این تکنیک میتواند برای شناسایی و مقابله با مهندسی معکوس استفاده شود.
دستور rdtsc (Read Time-Stamp Counter) یک دستور در معماری x86 است که برای خواندن شمارنده زمانسنج (Timestamp Counter) استفاده میشود. این شمارنده یک شمارنده 64 بیتی است که از زمان بوت شدن سیستم شروع به افزایش میکند و به صورت پیوسته از آن زمان افزایش مییابد. هدف اصلی این دستور دسترسی به این شمارنده است که برای اندازهگیری زمان و انجام محاسبات زمانی دقیق (با دقت بسیار بالا) کاربرد دارد.
پی نوشت:
زمانی که دستور rdtsc اجرا میشود، مقدار شمارنده زمانسنج سیستم (که زمان از شروع سیستم تا آن لحظه را نشان میدهد) در دو رجیستر EDX و EAX ذخیره میشود. EAX نیمی از شمارنده (کمتر از 32 بیت) و EDX نیمه دیگر را نگه میدارد
🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer
فاصله زمانی
در مهندسی معکوس و تحلیل بدافزار ما از اجرای single-stepping یا به تعبیری اجرای خط به خط برای رفتار شناسی قطعه کد مشکوک استفاده میکنیم.
هکر دنبال آن است که این حرکت ما را شناسایی کند تا بتواند خود را از این آنالیز برهاند.
یک راهکار استفاده از تکنیکهای زمانبندی برای شناسایی "single-stepping" در فرآیند دیباگ یا مهندسی معکوس است. در این روش، زمان دقیق (با دقت میلیثانیه) از لحظه شروع سیستم تا اجرای دستور خاصی اندازهگیری میشود. دستور rdtsc در معماری x86 برای این منظور استفاده میشود، که زمان سیستمی را در دو رجیستر EDX و EAX ذخیره میکند.
در فرآیند شبیهسازی دیباگ یا مهندسی معکوس (reverse engineering)، وقتی یک متخصص امنیت در حال اجرای کد است، ممکن است از تکنیکهایی مانند "single-stepping" استفاده کند. این به معنای اجرای کد خط به خط و بررسی هر دستور است. اما این کار باعث تأخیرهای زمانی میشود، چون در این فرآیند، پردازش کد به صورت تدریجی انجام میشود. اگر بتوان زمان دقیق قبل و بعد از اجرای یک دستور را محاسبه کرد، تأخیر ناشی از این فرآیند به وضوح قابل مشاهده خواهد بود.
با استفاده از دستور rdtsc، تفاوت زمانی بین دو نقطه (قبل و بعد از اجرای یک دستور) محاسبه میشود. اگر تأخیری در اجرای دستور مشاهده شود، این به احتمال زیاد نشاندهنده این است که یک دیباگر در حال "single-stepping" در کد است و این تکنیک میتواند برای شناسایی و مقابله با مهندسی معکوس استفاده شود.
دستور rdtsc (Read Time-Stamp Counter) یک دستور در معماری x86 است که برای خواندن شمارنده زمانسنج (Timestamp Counter) استفاده میشود. این شمارنده یک شمارنده 64 بیتی است که از زمان بوت شدن سیستم شروع به افزایش میکند و به صورت پیوسته از آن زمان افزایش مییابد. هدف اصلی این دستور دسترسی به این شمارنده است که برای اندازهگیری زمان و انجام محاسبات زمانی دقیق (با دقت بسیار بالا) کاربرد دارد.
پی نوشت:
زمانی که دستور rdtsc اجرا میشود، مقدار شمارنده زمانسنج سیستم (که زمان از شروع سیستم تا آن لحظه را نشان میدهد) در دو رجیستر EDX و EAX ذخیره میشود. EAX نیمی از شمارنده (کمتر از 32 بیت) و EDX نیمه دیگر را نگه میدارد
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍1
به دور از تمام مقدمات و تعاریف اولیه ؛ زیرو تراست رو ببینیم و انواع ش رو
https://www.ibm.com/think/insights/the-evolution-of-zero-trust-and-the-frameworks-that-guide-it
🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer
https://www.ibm.com/think/insights/the-evolution-of-zero-trust-and-the-frameworks-that-guide-it
Please open Telegram to view this post
VIEW IN TELEGRAM
Ibm
The Evolution of Zero Trust and the Frameworks that Guide It | IBM
Discover the evolution of Zero Trust security, its development, models, and framework, and learn how it can protect your organization from modern threats.
❤3👍1
Zeek.pdf
1.2 MB
یک راهنمای خوب برای یادگیری و تحلیل لاگ های Zeek
تو SOC خیلی به کارتون میاد
🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer
تو SOC خیلی به کارتون میاد
Please open Telegram to view this post
VIEW IN TELEGRAM
❤3👍1
Windows_Security_Event_Logs_Cheatsheet.pdf
524 KB
یه راهنمای خوب از لاگ های security channel ویندوز. تقریبا میشه گفت کامله
🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍1
Windows Commands Abused by Attackers (1).pdf
384.8 KB
یه cheat sheet خوب ازwindows commnad هایی که توسط Attacker ها مورد استفاده قرار میگیره
🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍1🔥1👏1
Pentesting_APIs.pdf
21.8 MB
Techbook
Pentesting APIs: A practical guide to discovering, fingerprinting, and exploiting APIs 2024.
🔹 Share & Support Us 🔹
📱 Channel : @Engineer_Computer
Pentesting APIs: A practical guide to discovering, fingerprinting, and exploiting APIs 2024.
Please open Telegram to view this post
VIEW IN TELEGRAM
❤2👍1👎1🔥1