یک آسیب‌پذیری مهم در TDengine TSDB با شناسه CVE-2026-42542 کشف شده که می‌تواند باعث ایجاد اختلال از راه دور در سرویس شود. TDengine یک پایگاه‌داده توزیع‌شده سری زمانی است که در حوزه‌هایی مثل Industrial IoT، انرژی، تله‌متری صنعتی و سیستم‌های مانیتورینگ برای دریافت، ذخیره و پردازش داده‌های تجهیزات استفاده می‌شود.

این آسیب‌پذیری با امتیاز CVSS 7.5 و شناسه CWE-191 مربوط به یک Integer Overflow در تابع "uvConnMayGetUserInfo()" از کامپوننت "taosd" است. مشکل هنگام پردازش پروتکل RPC اختصاصی TDengine و قبل از مرحله احراز هویت رخ می‌دهد؛ یعنی مهاجم بدون داشتن نام کاربری، رمز عبور یا Session فعال، تنها با ارسال یک Packet RPC دستکاری‌شده می‌تواند باعث Crash شدن پردازش "taosd" و در نتیجه ایجاد Denial of Service شود.

نسخه‌های 3.4.0.0 تا 3.4.1.5 تحت تأثیر این آسیب‌پذیری هستند و این مشکل در نسخه 3.4.1.6 برطرف شده است. طبق گزارش Ridge Security، تاکنون شواهدی از سوءاستفاده واقعی از این آسیب‌پذیری وجود ندارد، اما یک نمونه PoC برای اثبات امکان حمله توسعه داده شده است.

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

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

منابع:
TDengine Security Advisory:
https://docs.tdengine.com/security-guide/security-advisories/

Ridge Security Technical Analysis:
https://ridgesecurity.ai/blog/one-packet-can-take-down-the-database-behind-industrial-operations-ridge-security-discovers-cve-2026-42542/

سیستم تشخیص نفوذ (IDS) برای اینترنت صنعتی اشیاء (IIoT) بر روی خانواده‌های جدیدی از حملات مورد آزمایش قرار گرفت.

محققان یک سیستم تشخیص نفوذ (IDS) برای اینترنت صنعتی اشیاء (IIoT) ارائه دادند که دو مکانیسم تشخیص حمله را با هم ترکیب می‌کند. مکانیسم اول، انواع شناخته‌شده از حملات را طبقه‌بندی می‌کند، در حالی که مکانیسم دوم تلاش می‌کند تا ترافیکی را شناسایی کند که شبیه داده‌های موجود در مجموعه آموزشی نباشد. این سیستم بر اساس یک طرح آزمایش شد که در آن یک کل خانواده از حملات از مجموعه آموزشی حذف شده و فقط در مرحله تست ظاهر می‌شد.

آزمایش اصلی بر روی X-IIoTID انجام شد. این یک مجموعه داده‌ی باز برای تحقیق در مورد حملات در محیط IIoT است که شامل 820,834 رکورد از فعالیت‌های عادی و مخرب است. این مجموعه داده شامل داده‌های ترافیک شبکه، گزارش‌های سیستم و برنامه‌ها، استفاده از منابع دستگاه‌ها و رویدادهای IDS است. این مجموعه داده شامل فعالیت‌هایی مانند شناسایی، بهره‌برداری از آسیب‌پذیری‌ها، حرکت جانبی، خواندن رجیستر‌های Modbus، دستکاری داده‌ها، باج‌افزار و سایر سناریوها است.

مدل ترکیبی، نتایجی بهتر از هر یک از آشکارسازها به صورت جداگانه و همچنین دو روش رایج برای شناسایی ناهنجاری‌ها، یعنی Isolation Forest (که با جداسازی آماری رکوردهای غیرعادی از مجموعه‌ی اصلی داده‌ها، آن‌ها را شناسایی می‌کند) و One-Class SVM (که بر روی یک کلاس، معمولاً ترافیک عادی، آموزش داده می‌شود و اشیاء بسیار متفاوت را به عنوان ناهنجاری علامت‌گذاری می‌کند)، به دست آورد. این تفاوت‌ها از نظر آماری معنادار بودند (p <0.001). حجم مدل کمتر از 2 مگابایت بود و پردازش یک رکورد کمتر از 1 میلی‌ثانیه طول می‌کشید.

به طور جداگانه، مدل بر روی ToN-IoT، مجموعه‌ی داده UNSW Canberra که شامل ترافیک شبکه، داده‌های تله‌متری دستگاه‌های IoT/IIoT و رویدادهای Windows و Linux است، آموزش داده شد و سپس بدون آموزش اضافی، بر روی X-IIoTID آزمایش شد. در این آزمایش، کارایی کلی تقریباً تصادفی بود و روش ترکیب آشکارسازها بین دو مجموعه داده، قابل انتقال نبود. آزمایش‌ها بر روی مجموعه‌های داده انجام شد، نه در یک سیستم کنترل صنعتی واقعی.

منبع: Zhimin Ren, Yi Bao, Adaptive Fusion of Closed-World and Open-Set Detectors for Zero-Day Attack Generalization in Industrial IoT Intrusion Detection
https://doi.org/10.1007/s10586-026-06631-7

🛡️ CVE-2026-8065 | BDU:2026-15878

یکی از آسیب‌پذیری‌های مهم اخیر در حوزه OT/ICS مربوط به کنترل‌کننده‌های Hitachi Energy RTU500 سری CMU منتشر شده؛ جایی که یک ضعف در احراز هویت برای عملکرد حیاتی باعث میشه مهاجم از راه دور، بدون نیاز به احراز هویت، به قابلیت Firmware Update دسترسی پیدا کنه.

در سناریوی سوءاستفاده، امکان ارسال درخواست مخرب و بارگذاری Firmware دلخواه روی تجهیز وجود داره؛ موضوعی که می‌تونه یکپارچگی و در دسترس بودن RTU رو تحت تأثیر قرار بده و در محیط‌های صنعتی و زیرساخت‌های انرژی، اهمیت خیلی بالایی داره. شدت این آسیب‌پذیری Critical و CVSS 9.1 اعلام شده.

نسخه‌های قدیمی RTU500 CMU که در محدوده 11.x و قبل‌تر قرار دارن تحت تأثیر گزارش‌های سازنده هستن و Hitachi Energy توصیه کرده به نسخه‌های پشتیبانی‌شده ارتقا داده بشن؛ از جمله 12.7.8 یا 13.9.1 یا آخرین نسخه موجود.

نکته مهم برای محیط‌های OT اینه که اینجا فقط بحث یک Web Vulnerability معمولی نیست؛ وقتی یک RTU در زنجیره کنترل و اتوماسیون زیرساخت قرار داره، دستکاری Firmware می‌تونه مستقیماً روی Availability و Integrity تجهیز اثر بذاره. 🔴⚙️

📌 CVE: CVE-2026-8065
📌 BDU: BDU:2026-15878
📌 CWE: CWE-306 — Missing Authentication for Critical Function
📌 Severity: Critical | CVSS 9.1

🔗 توصیه رسمی Hitachi Energy: "Security Advisory – RTU500" (https://publisher.hitachienergy.com/preview?DocumentID=8DBD000251&LanguageCode=en&DocumentPartId=&Action=Launch&utm_source=chatgpt.com)

🔻 وقتی شبکه برق فقط یک مسئله الکتریکی نیست؛ پای امنیت سایبری هم وسط است
این تصویر مربوط به شبکه استاندارد IEEE 39-Bus هست؛ مدلی که برای بررسی و شبیه‌سازی رفتار شبکه‌های قدرت استفاده می‌شه. در نگاه اول، چیزی که می‌بینیم مجموعه‌ای از شینه‌ها، خطوط انتقال و ژنراتورهاست؛ اما وقتی همین شبکه رو از دید امنیت سیستم‌های کنترل صنعتی بررسی کنیم، موضوع کمی متفاوت می‌شه.
در زیرساخت‌های حیاتی، شبکه برق فقط از تجهیزات الکتریکی تشکیل نشده. بخش مهمی از عملکرد اون به سامانه‌های کنترل، تجهیزات اندازه‌گیری، ارتباطات صنعتی و سیستم‌های نظارتی مثل SCADA وابسته است. اطلاعاتی که از سطح میدان جمع‌آوری می‌شن، به مرکز کنترل می‌رسن و مبنای تصمیم‌گیری اپراتور یا الگوریتم‌های کنترلی قرار می‌گیرن.

حالا فرض کنید بخشی از این اطلاعات دست‌کاری بشه یا داده‌ای نادرست به سامانه کنترل برسه. مسئله دیگه صرفاً یک خطای نرم‌افزاری یا اختلال در ارتباطات نیست؛ باید بررسی کرد که این اتفاق چه اثری روی وضعیت واقعی شبکه، تصمیم‌های کنترلی و در نهایت پایداری سیستم می‌ذاره.
اینجاست که مفهوم Cyber-Physical Security اهمیت پیدا می‌کنه؛ جایی که امنیت سایبری رو نمی‌شه جدا از رفتار فیزیکی فرایند بررسی کرد. برای مثال، مدل IEEE 39-Bus می‌تونه بستری برای مطالعه اثر حملات تزریق داده جعلی، ارزیابی روش‌های تشخیص ناهنجاری و بررسی ارتباط بین داده‌های اندازه‌گیری و وضعیت واقعی شبکه باشه.
البته خود این نمودار یک مدل الکتریکیه، نه نقشه شبکه ارتباطی یا سامانه SCADA. برای تحلیل کامل امنیتی، باید مدل شبکه قدرت رو با معماری کنترل و ارتباطات صنعتی ترکیب کرد تا بشه اثر یک سناریوی سایبری رو در کنار پیامدهای فیزیکی اون ارزیابی کرد.
به نظرم یکی از نکات مهم در امنیت زیرساخت‌های حیاتی همین‌جاست؛ اینکه صرفاً امن بودن تجهیزات یا شبکه ارتباطی کافی نیست. باید بدونیم اگر داده‌ای تغییر کرد، ارتباطی مختل شد یا یک فرمان غیرمنتظره صادر شد، فرایند صنعتی چه واکنشی نشون می‌ده.
در امنیت OT، هدف فقط شناسایی حمله نیست؛ مهم اینه که بفهمیم حمله چه اثری روی فرایند واقعی می‌ذاره.
#ICS_Security #OT_Security #SCADA #PowerGrid #CyberPhysicalSecurity

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

یکی از سناریوهای مهم توی امنیت سایبری شبکه‌های برق، حملاتیه که هدفشون لزوماً از کار انداختن تجهیزات نیست، بلکه دست‌کاری داده‌هایی هست که سیستم بر اساسشون وضعیت شبکه رو تحلیل می‌کنه. این تصویر دو راهبرد TSDA و BLIA رو در چند مرحله نشون می‌ده که طی اون‌ها خطوط انتقال، نقاط تولید و مسیرهای مختلف شبکه بررسی می‌شن تا اثر حمله و شرایط نهایی شبکه مشخص بشه. بخش مهم ماجرا، حملات FDI یا تزریق داده جعلیه؛ جایی که مهاجم می‌تونه داده‌های اندازه‌گیری رو طوری دست‌کاری کنه که سامانه کنترل و پایش، وضعیت شبکه رو متفاوت از واقعیت ببینه. اصطلاح Targeted Line هم به خط انتقال هدف‌گذاری‌شده در این سناریو اشاره داره. حالا اهمیت این موضوع برای امنیت ICS/SCADA چیه؟ اینکه توی زیرساخت‌های حیاتی، صرفاً سالم بودن تجهیزات و برقرار بودن ارتباطات به معنی امن بودن سیستم نیست. اگه داده‌های ورودی قابل اعتماد نباشن، حتی یک سامانه کنترل سالم هم ممکنه بر اساس اطلاعات اشتباه تصمیم بگیره. به همین دلیل، امنیت شبکه‌های صنعتی فقط محدود به فایروال، تفکیک شبکه و کنترل دسترسی نیست

اعتبارسنجی داده‌ها، تحلیل رفتار فرایند فیزیکی، تشخیص ناهنجاری و مقایسه وضعیت محاسبه‌شده با وضعیت واقعی شبکه هم اهمیت اساسی دارن. البته برای تفسیر دقیق جزئیات دو راهبرد TSDA و BLIA و معنای همه مراحل، باید به مقاله اصلی مراجعه کرد؛ چون خود تصویر به‌تنهایی تمام فرضیات و سازوکارهای روش‌ها رو مشخص نمی‌کنه. در نهایت، توی امنیت زیرساخت‌های حیاتی، گاهی خطر واقعی از جایی شروع می‌شه که همه‌چیز روی مانیتور عادی به نظر می‌رسه، اما داده‌هایی که این تصویر رو ساخته‌ان، دیگه قابل اعتماد نیستن. 🔐⚡

🔥 خارجیا واقعاً با کلاس‌ن! (خدایی حق دارن)

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

حالا بیاید انصاف بدیم... ما خودمون هرجا رفتیم چی دیدیم؟ 😂
یا یه بشکه نفت گذاشتن، یا یه جعبه نوشابه (یا کولا) رو کردن میز کار! 😅 مهندس بیچاره باید لپ‌تاپش رو بذاره روی جعبه، خم بشه و ساعت‌ها کد PLC رو دیباگ کنه.

اما چرا اونا این‌طورین و ما نه؟ چند تا دلیل ساده:

✅ ارگونومی (راحتی): مهندس باید ساعت‌ها کار کنه. اگه ارتفاع میز استاندارد نباشه، خسته میشه و خطا می‌کنه. اون میز تاشو دقیقاً برای همینه.
✅ مدیریت کابل: تو عکس ببینید، کابل‌ها مرتب از مسیر خودشون رد شدن. تو سیستم ما گاهی کابل‌ها مثل رشته ماکارونی دور تابلو پیچیدن! 🍝
✅ ایمنی و HSE: بشکه نفت یا جعبه نوشابه، هم کثیفن، هم ممکنه بشکنن و لپ‌تاپ بیفته. تو استاندارد جهانی، محل کار باید تمیز و ایمن باشه.
✅ طراحی ماژولار: تجهیزات (مثل ماژول‌های زیمنس که تو عکس هست) روی ریل نصب شدن. هر قطعه خراب شد، ۵ دقیقه‌ای عوض میشه. تو ایران گاهی باید کل تابلو رو جراحی کنی! 🏥

چرا تو ایران این‌طوری نیست؟
متأسفانه ریشه‌ش برمی‌گرده به فرهنگ پیمانکاری. هدف فقط «راه‌اندازی»ه، نه «راحتی بهره‌بردار». هزینه برای یه میز تاشو تو بودجه نیست. از اون طرف، تو کارگاه‌های ما هنوز فکر می‌کنن «کار کردن با سختی» یه نوع افتخاره! 😅 در حالی که تو دنیا، مهندسی یعنی ساده‌تر، ایمن‌تر و سریع‌تر کردن کار.

البته خداروشکر تو بعضی پروژه‌های بزرگ (پتروشیمی، نیروگاه و...) داریم به این استانداردها نزدیک میشیم، ولی خب... راه درازی در پیشه! 🚶‍♂️

شما تو محل کارتون از چی به عنوان میز استفاده می‌کنید؟ بشکه؟ جعبه؟ کارتن؟ تو کامنتا بگید تا بخندیم! 👇😂

#مهندسی #تابلو_برق #PLC #استاندارد #HSE #طنز_مهندسی@pythonwithmedev

🛡️ OT Sentinel | ICS/OT Security

🔎 پورت 502 بازه؛ آیا یعنی شبکه صنعتی آسیب‌پذیره؟

نه لزوماً!

پورت TCP/502 به‌طور معمول برای پروتکل Modbus TCP استفاده می‌شه؛ پروتکلی که در برخی شبکه‌های صنعتی برای تبادل داده بین تجهیزات کنترلی و سامانه‌های نظارتی به کار می‌ره.

اما یک نکته مهم وجود داره: مشاهده این پورت در وضعیت LISTENING یا شناسایی اون در اسکن شبکه، به‌تنهایی اثبات نمی‌کنه که سیستم آسیب‌پذیره یا در معرض حمله قرار داره.

برای ارزیابی درست باید چند مورد رو بررسی کنیم:

▪️ آیا سرویس واقعاً Modbus TCP هست؟

▪️ آیا ارتباط از شبکه‌های غیرمجاز امکان‌پذیره؟

▪️ آیا تجهیزات و معماری شبکه با سیاست‌های امنیتی تعریف‌شده مطابقت دارن؟

▪️ آیا ارتباطات مشاهده‌شده با خط مبنای عملیاتی شبکه سازگارن؟

▪️ آیا کنترل‌های دسترسی و تفکیک شبکه به‌درستی پیاده‌سازی شدن؟

در محیط OT، مسئله فقط باز یا بسته بودن یک پورت نیست؛ مسئله اینه که چه کسی، از کجا، با چه مجوزی و برای چه هدفی می‌تونه با یک تجهیز صنعتی ارتباط برقرار کنه.

📚 منابع:

• IANA — Service Name and Port Number Registry
https://www.iana.org/assignments/service-names-port-numbers/

• NIST SP 800-82 Rev. 3 — Guide to Operational Technology Security
https://csrc.nist.gov/pubs/sp/800/82/r3/final

OT Sentinel | Understand. Analyze. Protect.

⚡ از طراحی یک PCB تا ساخت یک گره هوشمند برای صنعت؛ شروع یک پروژه در دنیای ICS/OT
مدتیه دارم روی ایده‌ای کار می‌کنم که برای من صرفاً طراحی یک برد الکترونیکی نیست؛ هدفم توسعه‌ی یک تجهیز سخت‌افزاریه که بتونه بین دنیای برق صنعتی، تجهیزات اندازه‌گیری، سیستم‌های مانیتورینگ و شبکه‌های کنترل صنعتی ارتباط برقرار کنه.
اسمش رو می‌شه یک Industrial Energy Monitoring & Control Node گذاشت؛ یک گره سخت‌افزاری برای پایش انرژی و اجرای فرمان‌های کنترلی که قراره از مرحله‌ی طراحی شماتیک و PCB شروع بشه و به‌تدریج به یک نمونه‌ی اولیه‌ی قابل آزمایش و توسعه برسه.
🔧 اما این تجهیز دقیقاً قراره چه کاری انجام بده؟
هسته‌ی اصلی طراحی بر پایه‌ی ماژول صنعتی ESP32-POE-ISO-IND از Olimex در نظر گرفته شده. ایده اینه که تجهیز بتونه از طریق رابط RS-485 به پاورمترهای صنعتی متصل بشه، داده‌ها رو با پروتکل Modbus RTU دریافت کنه و از طریق Ethernet در اختیار سیستم مانیتورینگ یا SCADA قرار بده.

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

⚙️ بخش دوم پروژه؛ پایش در کنار کنترل

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

بخش تغذیه هم اهمیت زیادی داره. ورودی ۲۴ ولت DC در نظر گرفته شده و طراحی باید بتونه ولتاژهای موردنیاز مدار رو تأمین کنه. حفاظت در برابر اضافه‌ولتاژ، اتصال معکوس، نویزهای محیط صنعتی، حفاظت خطوط ارتباطی و ایزولاسیون مناسب، از جمله مواردی هستن که در طراحی این بخش باید جدی گرفته بشن.

چون در محیط صنعتی، روشن شدن مدار فقط نقطه‌ی شروعه؛ مسئله‌ی اصلی اینه که تجهیز در شرایط واقعی، رفتار قابل پیش‌بینی و ارتباط پایدار داشته باشه

🏭 این پروژه کجا می‌تونه کاربرد داشته باشه؟

از تابلوهای برق و سامانه‌های پایش مصرف انرژی گرفته تا سیستم‌های مدیریت انرژی (EMS)، میکروگریدها، شبکه‌های هوشمند و زیرساخت‌های صنعتی مجهز به SCADA، چنین معماری‌ای می‌تونه نقطه‌ی شروعی برای توسعه‌ی راهکارهای کاربردی باشه.

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

اینجاست که موضوع امنیت OT وارد ماجرا می‌شه.

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

🧠 چرا تصمیم گرفتم این پروژه رو دنبال کنم؟

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

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

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

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


#OTSecurity #ICS #SCADA #PCBDesign #EmbeddedSystems #Modbus #IndustrialAutomation #EnergyMonitoring #HardwareSecurity@pythonwithmedev

🛡🎯 دعوت به همکاری در چالش امنیت سایبری TryHackMe
سلام به همه دوستان! 👋
من در رویداد امنیت سایبری TryHackMe – It’s Downtime شرکت کردم و دوست دارم چند نفر از دوستان علاقه‌مند به امنیت سایبری هم به تیممون اضافه بشن تا با هم چالش‌ها رو حل کنیم و از این فرصت استفاده کنیم. 🚀
🎁 جوایز رویداد شامل:
🏆 اشتراک یک‌ساله TryHackMe
🎓 گواهی‌نامه‌های رایگان
🎧 هدفون و جوایز سخت‌افزاری
🎟 و جوایز جذاب دیگه
💻 اگر به هک اخلاقی، تحلیل بدافزار، تحلیل لاگ و امنیت شبکه علاقه داری، خوشحال می‌شم به تیممون بپیوندی.
🔗 لینک عضویت در تیم:
https://tryhackme.com/downtime?joinTeam=17fa0b3b53
بیاید کنار هم یاد بگیریم، تجربه کسب کنیم و شانس‌مون رو برای برنده‌شدن امتحان کنیم! 💪🔥
#TryHackMe #CyberSecurity #InfoSec #CTF

📢 یه درخواست کوچیک از دوستانی که به تیم ملحق می‌شن ❤️
اگر از طریق لینک دعوت، عضو تیم TryHackMe ما شدید، لطفاً بهم پیام بدید و اطلاع بدید تا اکانت رو بررسی کنم و مطمئن بشم عضویتتون به‌درستی ثبت شده. ✅
ممنون از همراهی و حمایتتون 🙏💙