خصوصیات امنیتی جدید اندروید


https://blog.google/security/whats-new-in-android-security-privacy-2026/

چرا در مورد فورتی وب مینویسم ؟

آره کار من با فورتی وب به حدود ۱۳ تا ۱۰ سال پیش برمیگرده ؛ از نصب تا تیونینگ و بررسی لاگ.

اما چیزی که این روزها دغدغه من شده ، کانفیگ نامناسب برای تعداد بالای وف هایی هست که میبینم. لذا کشف و مقابله درستی نداریم و دیتا سورس SOC های ما هم ناکامله.

دوستان

وف قرار هست حملات رو کشف کنه و مقابله ، لاگش هم در SOC خیلی حیاتیه
اما
ما با عدم تنظیم مناسب ، اونو از یه بنز به پراید تقلیل دادیم !!


این روزها وف هایی میبینم که باید به حال مالکان اونها ناراحت شد . اونچه من میبینم اینه که تنظیمات وف به یه عنصر لاکچری در کشور بدل شده درحالی‌که یکی از اقلام ضروری کالابرگ!! سازمانیه

لذا
یه دپارتمان در شرکت هامون تشکیل دادم که یکی از کاراش فقط تیونینگ وف هست. پس یکی از اقلام کاتالوگ خدمات شرکت هامون شده "ارتقای عملیاتی وف"
اینجوری هم کنترل مهمی چون وف درست در مدار هست هم SOC شما میتونه یه قدم ارتقا پیدا کنه

لذا کمکی لازم بود با واحد فروش شرکت هامون در تماس باشید .


#خدمت_اختصاصی

وبینار عوامل موثر بر ارتقای کشف و بهروری در SOC های موجود - تجربه ی زیسته

اطلاعات بیشتر را در بخش توضیحات لینک زیر بخوانید
https://eseminar.tv/wb176454


دوشنبه 4 خرداد ماه در ایسمینار ساعت 20

ثبت نام زود هنگام با 40 درصد تخفیف

تخفیف ثبت نام تا 31 اردیبهشت برقرار است

شهود انسانی در برابر سرعت هوش مصنوعی؛ آینده جدید Threat Hunting

مقوله Threat Hunting مدرن وارد مرحله‌ای جدید و پیچیده شده است. سال‌ها، موفق‌ترین عملیات‌های هانت وابسته به تجربه، شهود و درک انسانی تحلیلگران بود. یک Threat Hunter حرفه‌ای می‌توانست رفتارهای غیرعادی مهاجم را از میان حجم عظیمی از داده‌ها تشخیص دهد، سیگنال‌های ضعیف را به هم متصل کند و فرضیات اشتباه را به چالش بکشد. به همین دلیل هنوز بسیاری معتقدند که «Threat Hunting ذاتاً انسان‌محور است.»

اما ظهور تهدیدات مبتنی بر هوش مصنوعی، معادله را تغییر داده است. مهاجمان اکنون می‌توانند با سرعت ماشین، عملیات Reconnaissance، فیشینگ، تولید بدافزار، تحلیل هدف و حتی حملات تطبیقی انجام دهند. در چنین شرایطی، مدل‌های سنتی هانت که کاملاً متکی به انسان هستند، دیگر سرعت کافی ندارند. اینجاست که یک سؤال مهم مطرح می‌شود: چگونه می‌توان عمق تحلیل انسانی را با سرعت AI ترکیب کرد؟

پاسخ در حذف انسان نیست، بلکه در تقویت اوست. هوش مصنوعی می‌تواند تحلیل حجم عظیم telemetry، correlation، anomaly detection و triage اولیه را انجام دهد، در حالی که تحلیلگر انسانی روی hypothesis building، تفسیر رفتار مهاجم و تصمیم‌گیری نهایی تمرکز می‌کند.

آینده Threat Hunting نه کاملاً انسانی خواهد بود و نه کاملاً خودکار؛ بلکه متعلق به تیم‌هایی است که بتوانند قضاوت انسانی را با سرعت پردازش AI ترکیب کنند.

اگر همه چیز فانی است ، چرا تلاش کنیم ؟!

آیهٔ «كُلُّ مَنْ عَلَيْهَا فَانٍ» از سوره الرحمن، یکی از عمیق‌ترین آیات قرآن درباره ناپایداری جهان است. این آیه یادآوری می‌کند که همه چیز در دنیا ، انسان‌ها، قدرت، ثروت و حتی تمدن‌ها ، روزی از بین می‌روند و تنها حقیقت پایدار، ذات الهی است. در نگاه عرفانی، این آیه فقط درباره مرگ نیست؛ بلکه درباره فانی بودن غرور، تعلقات و هویت‌های ظاهری انسان نیز سخن می‌گوید. پیام اصلی آیه این است که انسان نباید تمام وجود خود را به چیزهای موقتی گره بزند، بلکه باید به دنبال معنا، آگاهی، عشق و ارزش‌های عمیق‌تر در زندگی باشد.
اگر ما این موضوع را درک کنیم ، از بسیاری حسادت ها ، تعلقات ، تکبر ها، دروغ ها و تلاش های ظاهری کاسته میشود و ما "انسان" می‌شویم.

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

https://vrgl.ir/jYTXy

وقتی مهاجم قبض هوش مصنوعی را به قربانی می‌دهد

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

در این سناریوی جدید، مهاجم از همان AI موجود در سازمان یا روی دستگاه کاربر سوءاستفاده می‌کند. به‌جای مصرف GPU، API Token یا زیرساخت خودش، بار پردازش و هزینه را به قربانی منتقل می‌کند. این موضوع می‌تواند اشکال مختلفی داشته باشد: سوءاستفاده از Copilotها، Agentهای داخلی، مدل‌های متصل به داده‌های سازمان، یا حتی تزریق Prompt برای وادار کردن سیستم‌های AI به انجام تحلیل، تولید کد یا استخراج اطلاعات.

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

در آینده، دفاع سایبری فقط محافظت از endpoint و network نخواهد بود؛ بلکه شامل کنترل «رفتار عامل‌های هوشمند» نیز می‌شود. سازمان‌ها باید telemetry مربوط به AI، مصرف token، رفتار agentها و زنجیره تصمیم‌گیری مدل‌ها را همان‌قدر جدی بگیرند که امروز لاگ‌های SIEM و EDR را جدی می‌گیرند.

بررسی سرعت در SOC

مقوله Red Teaming یکی از مؤثرترین روش‌ها برای افزایش بلوغ SOC و بهبود سرعت کشف تهدیدات است. بسیاری از SOCها دارای Rule و Alert هستند، اما تنها در زمان شبیه‌سازی حملات واقعی مشخص می‌شود که Detectionها تا چه حد کارآمدند. Red Team با اجرای تکنیک‌های واقعی مهاجمان، ضعف‌های Visibility، کمبود Telemetry، ضعف Correlation و Blind Spotهای سازمان را آشکار می‌کند. این فرآیند باعث بهبود Detection Engineering، کاهش False Negative و افزایش دقت Threat Hunting می‌شود. همچنین تحلیلگران SOC با مشاهده رفتار واقعی مهاجم، درک عمیق‌تری از Attack Chain، رفتارهای مشکوک و روش‌های سریع‌تر شناسایی و پاسخ به حوادث پیدا می‌کنند.

در روز دوشنبه در ایسمینار از تجربه ۱۵ سال کار فنی بنده به نتایج خوبی خواهیم رسید .

👆دستورالعمل برپایی معماری Detection Engineering و مدیریت Detection مبتنی بر Git در SOC

تهیه شده توسط واحد MSSP شرکت هامون

جزئیات در لینک زیر

#MSSP #SOC #SOC_as_a_Service

لینک مقاله رو میتونید اینجا ببینید
https://vrgl.ir/F6Cif

پروژه جاری که با اسپلانک مدیریت میکنم رو سوئیچ کردم رو مبحث Detection as code . ترند بازار جهانی هست ، لذا گفتم منم اونو در پروژه های کشور پیاده کنم
#تجربه

براتون در دو بخش توضیح میدم

بخش اول :Detection as Code در Splunk: از مدیریت دستی تا مدیریت مهندسی‌شده

در بسیاری از SOCها، Ruleها، Correlation Searchها و Dashboardهای Splunk مستقیماً از طریق GUI ساخته و ویرایش می‌شوند. این روش هنوز رایج است، اما در محیط‌های بزرگ می‌تواند مشکلاتی مانند دشواری در ردگیری تغییرات، Rollback، کنترل کیفیت و انتقال منظم بین محیط‌های Dev، Test و Prod ایجاد کند.

در SOCهای بالغ‌تر، رویکرد Detection as Code به‌تدریج استفاده می‌شود. در این مدل، محتوای تشخیص مانند یک دارایی نرم‌افزاری مدیریت می‌شود. SPL Queryها، Metadata، Severity، Data Source، Mapping به MITRE ATT&CK و Response Action می‌توانند در Git Repository نگهداری شوند.

این کار باعث می‌شود تغییرات قابل بررسی، قابل بازگشت و قابل ممیزی باشند. همچنین تیم‌ها می‌توانند قبل از اعمال تغییرات در محیط عملیاتی، آن‌ها را Peer Review و Test کنند.

استفاده از Sigma نیز می‌تواند کمک کند Detectionها تا حدی مستقل‌تر از Vendor طراحی شوند، هرچند تبدیل Sigma به SPL همیشه نیازمند بررسی، تنظیم و اعتبارسنجی انسانی است.
اینو در سه هفته ی اخیر شروع کردم

اگر #تجربه ای بود به اشتراک میگذارم

✅در ادامه تجربه ام با اسپلانک در Detection as code بخش دوم تجربه رو مینویسم.


بخش دوم : Detection Testing و CI/CD در Splunk

در SOCهای پیشرفته، نوشتن Detection پایان کار نیست. هر Detection باید از نظر منطق، کیفیت داده، کارایی، نرخ خطای مثبت و قابلیت اجرا در محیط واقعی بررسی شود. به همین دلیل، برخی تیم‌ها از روش‌هایی الهام‌گرفته از مهندسی نرم‌افزار مانند Testing و CI/CD استفاده می‌کنند.

در این رویکرد، وقتی Detection جدیدی در Git ثبت می‌شود، می‌توان مراحلی مانند Lint Check، بررسی ساختار Rule، اعتبارسنجی Metadata، بررسی Mapping به ATT&CK و تست SPL را اجرا کرد. سپس Rule ابتدا در محیط Dev یا Test Splunk بررسی و پس از تأیید به Production منتقل می‌شود.

ابزارهایی مانند Atomic Red Team، Caldera و Prelude Operator نیز می‌توانند برای شبیه‌سازی رفتار مهاجم و ارزیابی عملکرد Detectionها استفاده شوند. البته این تست‌ها معادل کامل Unit Test نرم‌افزار نیستند، چون کیفیت Telemetry و رفتار واقعی مهاجم همیشه متغیر است.

بنابراین، Detection as Code یک جایگزین کامل برای تحلیلگر نیست؛ بلکه روشی برای استانداردسازی، کنترل کیفیت و بهبود مستمر عملیات SOC است.
با این حال در اجرا فعلا به مشکلاتی بر خوردم که کل پایپ لاین هنوز فول عملیاتی نشده

در هفته های آینده از #تجربه ام در Detection as code بیشتر مینویسم .

به امید بالغ شدن SOC های کشور

ابزار OpenClaw یک Agent مبتنی بر هوش مصنوعی است که برخلاف Chatbotهای سنتی، فقط پاسخ تولید نمی‌کند بلکه می‌تواند «عمل» نیز انجام دهد. به بیان ساده، اگر ChatGPT شبیه یک مشاور باشد، OpenClaw بیشتر شبیه یک دستیار اجرایی است که می‌تواند فایل‌ها را بخواند، دستورات اجرا کند، مرورگر را کنترل کند، APIها را فراخوانی کند و وظایف چندمرحله‌ای را به‌صورت خودکار انجام دهد.

معماری OpenClaw معمولاً از چند بخش تشکیل می‌شود: مدل زبانی (LLM)، موتور تصمیم‌گیری، حافظه بلندمدت، ابزارها (Tools) و محیط اجرا. این ساختار باعث می‌شود Agent بتواند وظایف پیچیده را برنامه‌ریزی و اجرا کند.

اهمیت OpenClaw صرفاً به‌دلیل قابلیت‌های آن نیست؛ بلکه به‌دلیل ریسک‌های امنیتی آن نیز مورد توجه قرار گرفته است. وقتی یک Agent به فایل‌ها، Shell، ایمیل، مرورگر و سرویس‌های مختلف دسترسی دارد، حملاتی مانند Prompt Injection، Memory Poisoning و Tool Abuse می‌توانند از یک پاسخ اشتباه فراتر رفته و به اقدامات اشتباه منجر شوند.

به همین دلیل، در طراحی Agentهای مدرن، مفاهیمی مانند Least Privilege، Human Approval، Logging، Monitoring و Sandbox اهمیت بسیار زیادی پیدا می‌کنند.

نکته ای در کانفیگ UTM هایی چون فورتی گیت
برای ارتقای عملکرد SOC

چرا Context و Performance در تنظیم IPS مهم‌تر از فعال‌سازی ساده هستند؟


یکی از اشتباهات رایج در پیاده‌سازی IPS این است که سازمان‌ها تصور می‌کنند فعال‌سازی تعداد بیشتری Signature به معنای امنیت بیشتر است، درحالی‌که Context محیط اهمیت بسیار بالاتری دارد. به‌عنوان مثال، اگر سازمان هیچ Linux Server نداشته باشد، فعال‌سازی Signatureهای Exploit مرتبط با Linux ممکن است صرفاً باعث افزایش مصرف منابع و تولید Alertهای غیرضروری شود. IPS باید متناسب با دارایی‌ها، سرویس‌ها، سیستم‌عامل‌ها و معماری واقعی سازمان طراحی شود.

از طرف دیگر، Performance یکی از مهم‌ترین چالش‌های عملیاتی IPS است. IPS به‌صورت ذاتی پردازش‌بر است و ترکیب آن با SSL Inspection، Antivirus و Application Control می‌تواند فشار قابل‌توجهی بر تجهیزات وارد کند. همچنین تفاوت Flow Mode و Proxy Mode می‌تواند تأثیر مستقیمی بر Latency و Throughput داشته باشد. به همین دلیل، Sizing صحیح، Capacity Planning و طراحی Profile مناسب، نقش کلیدی در موفقیت عملیاتی IPS دارند.

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

چرا TOGAF برای طراحی SOC و MSSP اهمیت دارد؟

#تجربه

بسیاری از سازمان‌ها تصور می‌کنند ساخت SOC صرفاً به خرید SIEM، استقرار EDR و استخدام تحلیلگر محدود می‌شود؛ درحالی‌که مشکل اصلی بسیاری از SOCها، نبود معماری و هم‌راستایی با کسب‌وکار است. TOGAF به‌عنوان یک Enterprise Architecture Framework کمک می‌کند SOC صرفاً به‌عنوان مجموعه‌ای از ابزارها دیده نشود، بلکه به‌عنوان یک Capability سازمانی طراحی شود.

استاندارد TOGAF باعث می‌شود طراحی SOC از چهار زاویه Business، Data، Application و Technology انجام شود. این رویکرد کمک می‌کند نیازهای کسب‌وکار، الزامات امنیتی، جریان داده‌ها، فرآیندها و فناوری‌ها به‌صورت یکپارچه طراحی شوند.

همچنین TOGAF در Capability Mapping، طراحی Roadmap بلوغ، تعریف Target Architecture و جلوگیری از ساخت SOCهای جزیره‌ای بسیار مؤثر است. اگرچه TOGAF ابزار Detection Engineering یا Framework عملیاتی SOC نیست، اما برای معماران امنیت، طراحان MSSP، مدیران امنیت و مشاوران، یک ابزار ارزشمند برای طراحی صحیح و مقیاس‌پذیر SOC محسوب می‌شود.

مشکلات شایع Parsing لاگ‌های ویندوز در اسپلانک
بسیاری از مشکلات SOCها از مرحله Detection شروع نمی‌شود؛ بلکه از Data Quality و Parsing اشتباه لاگ‌ها آغاز می‌شود. یکی از رایج‌ترین مشکلات، تنظیم نادرست Sourcetype است که باعث می‌شود Field Extraction و Detectionها به‌درستی کار نکنند. انتخاب بین فرمت XML و Classic Event Format نیز اهمیت زیادی دارد؛ XML معمولاً ساختاریافته‌تر است و برای Detection مناسب‌تر عمل می‌کند.
یکی دیگر از مشکلات رایج، شکست در استخراج فیلدها است؛ به‌طوری‌که اطلاعاتی مانند User، Process Name یا Logon Type ممکن است به‌درستی Parse نشوند. مشکلات Timestamp نیز می‌توانند زمان واقعی رخداد را با زمان نمایش داده‌شده در Dashboard متفاوت کنند.
در محیط‌های چندزبانه، Localization نیز چالش مهمی است؛ زیرا تغییر زبان سیستم‌ها می‌تواند Regexها و Detection Content را خراب کند. همچنین Event Loss ناشی از Queue Full، مشکلات Forwarder یا Permissionها می‌تواند باعث از دست رفتن لاگ‌های حیاتی شود.
#MSSP #تجربه #هامون
👇👇

برخی Eventها نیز حجم زیادی از داده تولید می‌کنند و باعث افزایش EPS و هزینه لایسنس می‌شوند. به همین دلیل، رویکرد صحیح معمولاً این است:
Collection > Parsing > Validation >CIM > Detection
زیرا در SOC، کیفیت داده تقریباً نیمی از موفقیت Detection است.

خبر امروز
دوستانی که از اینترنت قطع بودید و یا سیستم وصله کردن ندارید بدانید:

چندین آسیب‌پذیری جدید در 7-Zip کشف شده که می‌توانند به مهاجم اجازه دهند از طریق فایل‌های فشرده دستکاری‌شده، کد مخرب اجرا کند. این ضعف‌ها عمدتاً به نحوه پردازش Symbolic Linkها، Parsing فایل‌های ZIP و Handlerهای آرشیو مربوط هستند. در برخی سناریوها، تنها باز کردن یا Extract کردن یک فایل آلوده می‌تواند منجر به نوشتن فایل خارج از مسیر مورد انتظار و در نهایت Remote Code Execution شود. مشکل بزرگ‌تر این است که 7-Zip مکانیزم Auto Update ندارد و بسیاری از سیستم‌ها هنوز نسخه‌های آسیب‌پذیر را اجرا می‌کنند. توصیه اصلی، به‌روزرسانی فوری به نسخه‌های جدید و اجتناب از باز کردن فایل‌های فشرده ناشناس است

🔴نکته: با حضور هوش مصنوعی ، این آسیب پذیری بسرعت دارای اکسپلویت شده و خیلی سریعتر از آنچه تصورش را بکنید علیه شما استفاده خواهد شد.


راهکار: راه اندازی مدیریت وصله به کمک Desktop central

https://gbhackers.com/multiple-7-zip-vulnerabilities-arbitrary-code-execution/

ثبت نام فقط از طریق بله به شماره 09902857290

🔴خطر و راهکار کشف
روش کشف استفاده از آسیب پذیری مطرح در لینک زیر

در صورت استفاده مهاجم از آسیب پذیری لینک زیر ، اینها رو در SOC خواهیم دید
✴️
Many CLDAP Requests
High Volume UDP/389
Unknown Source → DC
✴️
lsass.exe crash
Unexpected reboot
Netlogon failure
✴️
DC reboot
Service interruption
Authentication failures
✅️
index=network dest_port=389 protocol=udp
| stats count by src_ip dest_ip
| where count > 100

⚫️اولویت دفاع
Patch Domain Controllerها
مانیتور UDP/389
مانیتور Crash / Reboot DC
Network Segmentation
انجام Hunt روی Netlogon anomalies

این از آن دسته CVEهاست که اگر سازمان Splunk ES، SOC یا MSSP دارد، نباید صرفاً Vulnerability Management بماند؛ باید Detection Use Case هم داشته باشد.

#MSSP #هامون


https://github.com/0xABCD01/CVE-2026-41089

آیا EDR مرده است؟

هر چند وقت یک‌بار با ظهور فناوری‌های جدید، این سؤال دوباره مطرح می‌شود: آیا EDR دیگر کارایی ندارد؟ پاسخ کوتاه این است: خیر؛ اما نقش آن تغییر کرده است.

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

مشکل اصلی این نیست که EDR ضعیف شده؛ مشکل این است که بسیاری انتظار دارند EDR به‌تنهایی امنیت ایجاد کند.

امروز EDR بیشتر شبیه یک Sensor قدرتمند است؛ نه یک راهکار کامل. Detection Engineering، Hardening، Threat Hunting، Telemetry مناسب و Incident Response سریع، همان بخش‌هایی هستند که EDR را ارزشمند می‌کنند.

بنابراین EDR نمرده است؛ بلکه از قهرمان اصلی به "بخشی از یک اکوسیستم دفاعی" تبدیل شده است.

تماس در بله 09902857290