یه اتفاق عجیب توی دنیای هوش مصنوعی افتاده که به نظرم خیلی‌ها هنوز عمقش رو درک نکردن...

توی یک تست امنیتی، یک عامل هوش مصنوعی (AI Agent) به جای اینکه مسئله‌ای که بهش داده شده بود رو حل کنه، تصمیم گرفت میانبر بزنه!

اول از محیط آزمایشی خارج شد، بعد به چند سرویس مختلف نفوذ کرد و در نهایت بیش از ۱۷٬۶۰۰ اقدام مختلف انجام داد تا به جواب موردنظرش برسه.

چیزی که این اتفاق رو ترسناک می‌کنه، فقط هک کردن نیست...

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

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

به نظرم این اتفاق یه پیام مهم داره...

ما دیگه فقط با «چت‌بات» طرف نیستیم.

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

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

#هوش_مصنوعی
#امنیت_سایبری
#عامل_هوش_مصنوعی
#فناوری
#نوآوری

#AI
#AIAgents
#CyberSecurity
#LLM
#OpenAI
#ArtificialIntelligence
#Tech

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

همین فاصله، کل دلیلِ نفوذه. Strix این شکاف رو می‌بنده. pentest رو از تقویمی درمیاره، مداومش می‌کنه.

این scanner نیست که flag احتمالی بده. agentهاش مثل مهاجم واقعی رفتار می‌کنن: اپلیکیشن شما رو داینامیک اجرا می‌کنن، آسیب‌پذیری‌ها رو chain می‌زنن، هر یافتی رو با exploit کارکردنی ثابت می‌کنن. PoC نداری، ticket نداری.

تنها هم کار نمی‌کنه. چندتا agent تخصصی به صورت موازی recon، exploitation و post-exploitation رو اجرا می‌کنن. یافته‌ها رو share می‌زنن و chain می‌کنن، دقیقاً مثل یه red team واقعی.

یه repo بهش بدین، یه اپلیکیشن لایو، یا حتی یه spec OpenAPI/Postman. خودش همه endpointها رو تست می‌کنه، نه اینکه بی‌هدف crawl کنه.


curl -sSL strix.ai/install | bash


سؤال من اینه: وقتی مهاجم هر روز تمرین می‌کنه، چرا تیم امنیتی هنوز داره برای یه بار توی سال برنامه‌ریزی می‌کنه؟


#امنیت_سایبری
#پنتست
#DevSecOps
#RedTeam
#AppSec
#CyberSecurity
#Strix

این OpenAI یک ابزار امنیتی جدید معرفی کرده؛ البته معرفی رسمی نه

اسم این ابزار Codex Security CLIـه و برای پیدا کردن آسیب‌پذیری‌های امنیتی داخل Repositoryها طراحی شده.

ایده‌اش نسبتاً ساده‌ست:

🔹 مخزن رو بررسی می‌کنه

🔹 آسیب‌پذیری‌های احتمالی رو پیدا می‌کنه

🔹 نتایج رو تحلیل می‌کنه

🔹 در نهایت یک گزارش امنیتی ارائه می‌ده

این پروژه فعلاً در مرحله Preliminary Launch قرار داره و به‌صورت Open Source منتشر شده.

چیزی که برای من جالبه، ترکیب Coding Agent با Security Analysis؛ یعنی به‌جای اینکه فقط از AI برای نوشتن کد استفاده کنیم، ازش برای پیدا کردن مشکلات امنیتی داخل کدی که قبلاً نوشته شده هم استفاده کنیم.

اگر این مسیر درست پیش بره، می‌تونه برای Security Review و Code Auditing خیلی جالب باشه.

لینک : مخزن

#هوش_مصنوعی
#امنیت_سایبری
#امنیت_نرم_افزار
#برنامه_نویسی
#کدنویسی
#آسیب_پذیری

#AI
#CyberSecurity
#SoftwareSecurity
#Coding
#CodeSecurity
#AIEngineering
#Codex
#OpenAI

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

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

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

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

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

🔸 دفاع از زنجیره تامین نرم‌افزار
حملات مبتنی بر هوش مصنوعی روز به روز بیشتر ش pipelinesهای CI/CD، وابستگی‌های متن‌باز و مخازن کد رو هدف می‌گیرن. سازمان‌ها به محافظت‌های زمان اجرا، اعتبارسنجی یکپارچگی کد و اعمال خودکار سیاست‌ها نیاز دارن تا جلوی رسیدن کدهای دستکاری شده به محیط پروداکشن رو بگیرن.

🔸 محدود کردن شعاع انفجار
معماری صفر اعتماد (Zero Trust) تو فضای تهدیدهای مبتنی بر هوش مصنوعی به شدت حیاتی‌تر می‌شه. میکروسگمنتیشن، بازرسی مداوم و تحلیل‌های رفتاری کمک می‌کنه تا بعد از دسترسی اولیه، جلوی حرکت جانبی مهاجمن تو محیط‌های مختلف گرفته بشه.

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

#امنیت_سایبری
#هوش_مصنوعی

#ZeroTrust
#CyberSecurity
#AITools
#Infosec

یه تحقیق جدید از HiddenLayer منتشر شده که دوباره یک نکته مهم درباره امنیت LLMها رو یادآوری می‌کنه:

حتی مدل‌های خیلی قوی هم در برابر Prompt Injection و Jailbreak صددرصد امن نیستند.
اسم این تکنیک رو گذاشتن:
آقا یا خانم Policy Puppetry

ایده اصلیش اینه که مهاجم چند تکنیک ساده رو با هم ترکیب می‌کنه تا مدل رو گمراه کنه.

مثلاً:
یک متن شبیه فایل تنظیمات یا Policy جعلی می‌سازه تا مدل فکر کنه این دستور رسمی سیستمه.

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

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

مدل‌هایی از شرکت‌های مختلف مثل OpenAI، Google، Anthropic، Meta، DeepSeek و دیگران بررسی شدند.
اما نکته مهم برای مهندس‌های AI اینه:
امنیت LLM فقط با یک System Prompt قوی حل نمی‌شه.
چند لایه دفاع لازم داریم:
- ورودی کاربر نباید با دستورهای سیستمی قاطی شود.
- برای کارهای حساس باید Permission و Approval وجود داشته باشد.
- از Sandbox برای اجرای کد یا تغییرات مهم استفاده شود.
- تست‌های Red Team و Jailbreak باید همیشه به‌روز شوند.

یک اشتباه رایج اینه که فکر کنیم:
مدل قوی‌تر = امنیت کامل‌تر
در واقع هرچه مدل توانمندتر شود، نیاز به معماری امنیتی بهتر هم بیشتر می‌شود.

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

#AI
#LLM
#CyberSecurity
#PromptInjection
#AIsecurity
#MachineLearning
#AIAgents

یه چیزی که این روزها بیشتر بهش فکر می‌کنم اینه که:
ما وقتی درباره امنیت AI صحبت می‌کنیم، خیلی وقت‌ها فقط خود مدل رو می‌بینیم.
مثلاً می‌گیم:
این مدل قویه؟

آیا Guardrail داره؟
آیا Prompt خوب براش نوشتیم؟

ولی واقعیت اینه که یک سیستم AI فقط یک مدل نیست.
پشت یک سیستم واقعی کلی بخش مختلف وجود داره:
مورد اول : Prompt
مورد دوم : Data
مورد سوم : RAG و Vector Database
مورد چهارم :Memory
مورد پنجم :Tool
مورد ششم :API

و دسترسی‌هایی که Agentها دارند.

هر کدوم از این بخش‌ها می‌تونه یک نقطه ورود برای مشکل امنیتی باشه.

یکی از چیزهایی که برای من جالب بود اینه که خیلی از حملات جدید اصلاً شبیه حملات سنتی نیستند.

گاهی فقط یک Document آلوده وارد سیستم میشه.
یا یک داده‌ای که از بیرون بازیابی شده، باعث میشه مدل رفتار متفاوتی داشته باشه.

یا یک Agent دسترسی بیشتری از چیزی که نیاز داره داشته باشه و همین تبدیل به یک ریسک بزرگ بشه.
به نظرم یکی از مهم‌ترین نکات در امنیت LLM اینه:
یک System Prompt قوی به تنهایی امنیت ایجاد نمی‌کنه.
باید معماری درست داشته باشیم.

چند تا اصل ساده ولی مهم:
🔹 هر داده خارجی را به چشم ورودی غیرقابل اعتماد ببینیم.
🔹 دسترسی Agentها را محدود کنیم.
🔹 برای عملیات حساس تأیید انسانی داشته باشیم.
🔹 خروجی مدل را قبل از استفاده بررسی کنیم.
🔹 تغییرات Prompt و Pipeline را مرتب تست امنیتی کنیم.
دنیای AI خیلی سریع در حال رشد است و همزمان با قابلیت‌های جدید، ریسک‌های جدید هم ایجاد می‌شوند.
به نظرم آینده امنیت AI فقط در ساخت مدل‌های قوی‌تر نیست.

بخش مهم‌تر اینه که یاد بگیریم چطور این مدل‌ها را در یک معماری امن و قابل اعتماد استفاده کنیم.

#AI
#LLM
#AIsecurity
#CyberSecurity
#AIAgents
#MachineLearning
#PromptInjection

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

نسل جدید فیشینگ فقط دنبال فرستادن یک پیام نیست؛ دنبال ساختن یک تعامل واقعی با قربانیه.
اینجا جاییه که AI Agentها وارد بازی میشن.

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


این تغییر باعث میشه روش‌های سنتی دفاع هم کافی نباشند.
قبلاً شاید بررسی Link یا Attachment تا حد زیادی کمک می‌کرد.

اما وقتی تهدید تبدیل به یک مکالمه طبیعی میشه، باید چیزهای دیگری بررسی شوند:

رفتار فرستنده
الگوی گفتگو
تغییر ناگهانی درخواست‌ها
درخواست‌های حساس مثل انتقال پول یا دسترسی
به نظرم یکی از مهم‌ترین تغییرات امنیت در عصر Agentها اینه که دیگر فقط نباید بپرسیم:

این پیام مخرب است یا نه؟
باید بپرسیم:
آیا این رفتار با الگوی معمول این فرد یا سیستم هماهنگ است؟
در آینده احتمالاً دفاع هم باید Agent محور شود.

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

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

دسترسی محدود، ثبت رویدادها، تأیید انسانی برای عملیات حساس و طراحی امن، بخش مهم این مسیر هستند.

به نظرم Phishing 3.0 بیشتر از اینکه یک مشکل ایمیل باشد، یک مسئله اعتماد در دنیای Agentهاست.

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

#CyberSecurity
#AI
#AIAgents
#Phishing
#AIsecurity
#EmailSecurity
#AgenticAI

یه اتفاق جالب توی دنیای AI افتاده که به نظرم خیلی‌ها هنوز جدی نگرفتن.
استارتاپ AIR به‌تازگی ۵۰ میلیون دلار سرمایه جذب کرده؛ برای چی؟

برای امنیت AI Agentها.

شاید در نگاه اول خیلی معمولی به نظر برسه، ولی اگر یکم عمیق‌تر نگاه کنیم، داستان خیلی مهم‌تره.

ما داریم وارد دوره‌ای می‌شیم که شرکت‌ها فقط چندتا مدل AI ندارند.

ده‌ها و صدها Agent دارن که به ابزارهای مختلف وصل می‌شن.

حالا سؤال مهم اینه:

از کجا بدونیم چیزی که Agent بهش دسترسی داره امنه؟
اگر یک Skill مخرب باشه چی؟
اگر یک MCP Server آلوده باشه چی؟
اگر Plugin دسترسی بیشتری از چیزی که باید داشته باشه بگیره چی؟

اینجاست که یک مفهوم جدید داره جدی می‌شه:

آقای Agent Security!

تقریباً شبیه همون چیزی که سال‌ها در Software Supply Chain Security داشتیم، ولی این بار برای اکوسیستم Agentها.

به نظرم این یکی از بازارهای جدی چند سال آینده‌ست.

چون هرچقدر Agentها قدرتمندتر بشن، سطح دسترسی‌شون هم بیشتر می‌شه.
و هرچقدر دسترسی بیشتر بشه، امنیت مهم‌تر می‌شه.

حالا دوست دارم نظر شما رو بدونم.

به نظرتون بزرگ‌ترین تهدید برای AI Agentها چیه؟

خود مدل؟
دسترسی به سیستم و Terminal؟
یا اشتباهات انسانی در زمان استفاده؟
بیاید اینجا درباره‌ش حرف بزنیم.
اگر تجربه‌ای در کار با Agentها، MCP یا امنیت این سیستم‌ها دارید، حتماً بنویسید.

احتمالاً تجربه شما می‌تونه برای خیلی‌های دیگه هم مفید باشه.

#AI
#AIAgents
#CyberSecurity
#AgentSecurity
#MCP
#DevOps
#SoftwareDevelopment

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

بخش قابل‌توجهی از این هایپ هم به نظرم از سمت اینفلوئنسرها و خبرنگارهای حوزه Cybersecurity میاد که شاید تجربه زیادی در Pentest داشته باشن یا صرفاً در حد سطحی باهاش برخورد کرده باشن، ولی تجربه عملی جدی در Red Team ندارن. طبیعتاً وقتی چنین فضایی شکل می‌گیره، فاصله بین چیزی که واقعاً وجود داره و چیزی که درباره‌ش گفته می‌شه می‌تونه خیلی زیاد بشه.

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

در این مرحله بیشتر از اینکه AI Revolution باشه، برای من شبیه AI-Milking هس.

استفاده از اسم AI برای داغ کردن دوباره چیزهایی که شاید به‌اندازه هایپ اطرافشون جدید نباشن.

#Mythos
#AI
#Cybersecurity
#Pentesting
#RedTeam
#Infosec
#CyberSecurity
#ArtificialIntelligence
#AITools
#Security

دیدگاه من اینه که بیشتر ابزارهای AI برای Pentest که تا الان دیدم، در بهترین حالت می‌تونن یه Nmap اجرا کنن، چندتا ابزار آماده رو صدا بزنن و یه چیزی شبیه Metasploit رو اجرا کنن. اما وقتی از این مرحله فاصله می‌گیری و وارد چیزی می‌شی که واقعاً به Tradecraft و تجربه عملی نیاز داره، خیلی‌هاشون عملاً از کار می‌افتن.

به نظرم بخش واقعاً جذاب ماجرا الان جای دیگه‌ست. به‌جای اینکه صرفاً یک LLM رو روی ابزارهای قدیمی Pentest سوار کنیم و اسمش رو AI Pentesting بذاریم، تحقیق روی خود مدل‌ها و روش‌های Adversarial علیه اون‌ها خیلی جالب‌تره.

اینکه چطور می‌شه مدل‌ها رو تحت تأثیر قرار داد، محدودیت‌هاشون رو بررسی کرد و نقاط ضعفشون رو پیدا کرد، به نظرم از این جهت ارزش تحقیقاتی بیشتری داره که واقعاً یک لایه جدید به مسئله اضافه می‌کنه، نه اینکه فقط یک Wrapper هوشمند دور ابزارهای موجود بسازیم.

#AI
#Cybersecurity
#Pentesting
#RedTeam
#AdversarialAI
#LLM
#AIsecurity
#Infosec

من توی هر Red Team Engagement معمولاً قبل از اینکه چیزی رو روی محیط مشتری اجرا کنم، یه Local Environment جدا دارم که سناریوها، Exploitها، Injectionها و Executionها رو اول اونجا شبیه‌سازی و تست می‌کنم.

هدفش هم خیلی ساده‌ هست.
نمی‌خوام محیط مشتری تبدیل به محیط آزمایش من بشه. قبل از اینکه چیزی وارد Target Environment بشه، ترجیح می‌دم تا جای ممکن بدونم دقیقاً چه رفتاری داره و چه اثری روی سیستم می‌ذاره.

ولی اخیراً متوجه شدم ظاهراً خیلی‌ها این روال رو ندارن و مستقیم روی محیط مشتری تست می‌کنن. برام جالبه که چرا. واقعاً این حجم از YOLO کردن توی Red Team طبیعیه یا من زیادی محتاطم؟

به نظرم داشتن یک Lab مشابه Target قبل از اجرای سناریوهای حساس، بیشتر از اینکه کار اضافه باشه، بخشی از Professional Tradecraft محسوب می‌شه. مخصوصاً وقتی پای محیط واقعی مشتری وسطه.

#RedTeam
#Pentesting
#Cybersecurity
#Infosec
#SecurityTesting
#EthicalHacking
#OffensiveSecurity
#Tradecraft

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

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

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

برای همین فکر می‌کنم تفاوت بین یک پروژه معمولی و یک ابزار واقعاً کاربردی، اغلب نه در تعداد Lines of Code، بلکه در میزان فکر، تحقیق و Testing پشت اون مشخص می‌شه.

در نهایت Coding شاید فقط ۱۰ درصد نتیجه باشه. ۹۰ درصد دیگه مربوط به طرز فکر، Research و تست بی‌پایانه.

#Programming
#Cybersecurity
#RedTeam
#C2
#OpenSource
#OffensiveSecurity
#Pentesting
#SoftwareEngineering
#Research
#ProblemSolving

یک موضوع دلی رو بگم بهتون دوستان.

امروز داشتم با یکی از دوستام صحبت می‌کردم و یاد یه عادت قدیمی افتادم. سال ۲۰۱۸، وقتی تازه شروع کرده بودم Windows Internals رو یاد بگیرم، من و چندتا از دوستام یه عادت نسبتاً ساده برای خودمون ساخته بودیم.

هر روز ۱۰ تا فایل EXE یا DLL از System32 انتخاب می‌کردیم و فقط درباره‌شون می‌خوندیم. نه خبری از Hack خاصی بود، نه Reversing و نه کار عجیب‌وغریبی. اسم فایل، کاربردش، اینکه چرا وجود داره، چه کاری انجام می‌ده و هر چیزی که می‌شد درباره‌ش پیدا کرد.

این کار رو تقریباً ۶۰ روز ادامه دادیم و حجم دانشی که فقط با Google کردن و خوندن به دست آوردیم واقعاً عجیب بود.

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

خیلی‌ها با دیدن مباحث Advanced از همون اول می‌ترسن، در حالی که چیزی که واقعاً تفاوت ایجاد می‌کنه، کیفیت Fundamentals هست.

اگر پایه‌هات رو واقعاً خوب بفهمی، مباحث پیچیده‌تر دیگه اون‌قدر ترسناک نیستن. خیلی از چیزهایی که در ابتدا Advanced به نظر می‌رسن، در نهایت فقط ترکیب عمیق‌تری از همون مفاهیم پایه‌ان.

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

و البته بله، من خودم چندتا Course هم می‌فروشم؛ ولی حتی با وجود این، هنوز فکر می‌کنم چیزی که بیشتر از هر منبعی نتیجه می‌ده، Time + Consistency + Discipline هست.

#WindowsInternals
#Cybersecurity
#Programming
#Fundamentals
#Learning
#ReverseEngineering
#Infosec
#Security
#SoftwareEngineering
#Discipline

یکم درباره این AI آخرالزمانی آروم‌تر باشید عزیزان دلم.

چند تا نکته درباره اتفاقات اخیر:

۱. هک Hugging Face توسط Agentها
این‌طور نیست که یک مدل نشسته باشه و خودش تصمیم گرفته باشه بره یک سرویس رو هک کنه.

در ماجرای ExploitGym، دستورالعمل‌های مشخصی برای Agent وجود داشته که دقیقاً مسیر کار رو تعیین می‌کرده.

پس فعلاً خبری از Agentی که خودش بگه امروز بریم Hugging Face رو بزنیم نیست. 😅

۲. حل مسئله هزاره
اینکه AI تونسته در یک مسئله ریاضی بسیار سخت به نتیجه برسه، لزوماً به معنی این نیست که مدل به‌تنهایی یک مسئله هزاره رو حل کرده.

بخش بزرگی از کار بر پایه Research قبلی و Traceهای موجود بوده و بعد با تعداد زیادی Agent و Compute عظیم، فرضیه‌ها به‌صورت گسترده بررسی شدن.

یعنی بیشتر:

نکته رو توجه کنید : Research قبلی + Agentها + Brute Force در مقیاس بالا

تا یک مدل که از صفر نشسته و خودش یک نظریه جدید ساخته.

۳. و اما بخش بامزه ماجرا 😂

بعضی‌ها با دیدن این اتفاقات سریع می‌رن سراغ:

هوش مصنوعی قراره همه‌مون رو بکشه!

داداش، فعلاً آروم‌تر. 😂


#AI
#AIAgents
#AI
#HuggingFace
#OpenAI
#CyberSecurity

یه پدیده جالب با زیاد شدن ابزارهای AI به وجود اومده: آدم‌هایی که چند ماه با مدل‌های زبانی کار کرده‌اند و ناگهان خودشون رو متخصص AI معرفی می‌کنند.

مسئله این نیست که از AI استفاده می‌کنند. اتفاقاً استفاده از AI می‌تونه یک مهندس رو چند برابر سریع‌تر کنه.

مشکل از جایی شروع میشه که خروجی مدل رو بدون اینکه بفهمی، قبول کنی.

مدل کد می‌نویسه، تو اجراش می‌کنی و چون کار کرد، مستقیم می‌ره Production.

مدل یک تحلیل امنیتی تولید می‌کنه، تو همون رو داخل گزارش می‌ذاری.

مدل یک باگ پیدا می‌کنه، بدون اینکه بفهمی چرا آسیب‌پذیری وجود داره، اعلامش می‌کنی.

اینجا دیگه AI ابزار نیست؛ تبدیل شده به جایگزین دانش.

و این خطرناک‌ترین قسمت ماجراست.

چون LLM می‌تونه با اعتمادبه‌نفس کامل چیزی بگه که کاملاً اشتباهه. اگر ندونی چه چیزی درست و چه چیزی غلطه، عملاً هیچ راهی برای تشخیصش نداری.

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

در نهایت هم وقتی چیزی خراب بشه، کسی باید بیاد و بفهمه واقعاً چه اتفاقی افتاده.

اینجاست که تفاوت «AI User» و «Engineer» مشخص میشه.

مهندس از AI استفاده می‌کنه، ولی خروجی AI رو بررسی می‌کنه.

می‌تونه توضیح بده چرا این کد کار می‌کنه.

می‌تونه تشخیص بده کجا احتمال Hallucination وجود داره.

می‌تونه خروجی مدل رو تست و نقد کنه.

و مهم‌تر از همه، اگر AI اشتباه کرد، خودش متوجه میشه.

من کاملاً موافق استفاده از AI هستم و فکر می‌کنم کسی که امروز از ابزارهای AI استفاده نمی‌کنه، بخشی از بهره‌وری خودش رو از دست میده.

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

هوش مصنوعی می‌تونه سرعت کار یک مهندس رو بالا ببره؛ ولی نمی‌تونه مسئولیت فهمیدن کار رو از دوش مهندس برداره.

چکش، نجار نیست.

#هوش_مصنوعی
#مهندسی_نرم_افزار
#امنیت_سایبری

#AI
#SoftwareEngineering
#CyberSecurity

براتون 250+ Python One-Liners برای تقویت Problem Solving آوردم.

واقعا One-Linerها فقط ترفندهای عجیب برای کوتاه‌تر کردن کد نیستن.

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

این مجموعه با عنوان 250+ Killer Python One-Liners بیش از ۲۵۰ مثال کوتاه و کاربردی داره؛ از کار با String و List گرفته تا Date، Math، Validation و Random.

📌 موضوعاتش شامل:

• String و List manipulation

• کار با Arrayها
• Date & Time
• Math و Geometry
• Random Generatorها
• Validation برای Email، IP، URL و...
• Recursion
• Bitwise Operations
• Utility Functionهای کوچک

نکته جالب اینه که هدف صرفاً حفظ کردن One-Linerها نیست؛ ایده اصلی اینه که ببینین یک مسئله‌ی نسبتاً ساده رو چطور می‌شه با ابزارهای خود Python به شکل تمیز، کوتاه و Pythonic حل کرد.

البته کوتاه‌تر بودن همیشه به معنی بهتر بودن نیست؛ خوانایی همچنان مهم‌تره.

📚 برای تمرین Python و تقویت Problem Solving می‌تونه مجموعه جالبی باشه.

❤️ Share & Support

#Python
#Programming
#ProblemSolving
#PythonTips
#CyberSecurity
#Coding

🚨 ۶ باگ توی کرنل لینوکس؛ ادعای دسترسی روت در ۵ مورد.

هیون وو کیم جزئیات ۶ آسیب‌پذیری در بخش‌های مختلف کرنل لینوکس رو منتشر کرده؛ از مدیریت حافظه و سیگنال‌ها گرفته تا زمان‌بندی و SLUB.

🔹 طبق ادعای محقق، ۵ مورد می‌تونن به ارتقای دسترسی تا روت منجر بشن.

🔹 مورد ششم در PoC منتشرشده فقط باعث کرش کرنل می‌شه، نه دسترسی روت.

🔹 یکی از باگ‌ها روی Galaxy S26 Ultra هم بررسی شده؛ اما اکسپلویت اندروید هنوز عمومی نشده.

🔹 نکته مهم اینکه این باگ‌ها به دسترسی شبکه یا user namespace نیاز ندارن؛ البته بهره‌برداری از بعضی موارد به شرایط خاصی وابسته‌ست.

⚠️ یه نکته: این‌ها ادعاهای محقق بر اساس تحلیل‌ها و PoCها هستن و نباید بدون بررسی مستقل، همه جزئیات رو تأییدشده فرض کرد.

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

#Linux
#CyberSecurity