تا چند سال پیش وقتی اسم 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