اخیرا محققان امنیتی از کمپینی هدفمند علیه سوئیچ‌های Cisco IOS خبر داده‌اند که در آن مهاجمان با سوءاستفاده از یک آسیب‌پذیری در پروتکل SNMP موفق به نصب Rootkit سطح پایین روی دستگاه‌های شبکه شده‌اند. این حمله به‌ویژه در محیط‌های سازمانی و زیرساختی، زنگ خطر جدی را برای مدیران شبکه به صدا درآورده است.
🔍 جزئیات فنی حمله
در این حمله، مهاجمان از نقصی در پیاده‌سازی SNMP (Simple Network Management Protocol) در برخی نسخه‌های سیستم‌عامل Cisco IOS استفاده کرده‌اند. این آسیب‌پذیری به آن‌ها اجازه می‌دهد تا بدون نیاز به احراز هویت کامل، دستورات مدیریتی از راه دور روی دستگاه اجرا کنند.
پس از دسترسی اولیه، مهاجمان با بهره‌گیری از اسکریپت‌های مخصوص و ابزارهای سفارشی، یک Rootkit مخفی در سطح firmware نصب می‌کنند که کنترل کامل بر ترافیک و تنظیمات دستگاه را به آن‌ها می‌دهد.
این Rootkit به‌گونه‌ای طراحی شده که:
- در ریبوت سیستم فعال باقی می‌ماند،
- دستورات CLI را پنهان می‌کند،
- لاگها را دست‌کاری می‌کند تا حضور مهاجم قابل شناسایی نباشد،
- و حتی می‌تواند پیکربندی SNMP را برای دسترسی مداوم تغییر دهد.
⚠️ تأثیر و دامنه تهدید
گزارش‌ها نشان می‌دهد این حملات بیشتر زیرساخت‌های حیاتی، ISPها و مراکز داده را هدف گرفته‌اند. از آنجا که Rootkit در سطح سیستم‌عامل شبکه فعالیت می‌کند، شناسایی آن توسط ابزارهای امنیتی سنتی (مانند IDS یا آنتی‌ویروس) تقریباً غیرممکن است.
در واقع، این نوع تهدید نشان می‌دهد که مرز بین امنیت شبکه و امنیت Firmware روزبه‌روز باریک‌تر می‌شود.
🛡️ راهکارهای پیشگیرانه برای مدیران شبکه
برای جلوگیری از آلودگی یا سوءاستفاده مشابه، کارشناسان توصیه می‌کنند:
- به‌روزرسانی فوری Cisco IOS و firmware به آخرین نسخه‌های منتشرشده.
- غیرفعال‌سازی SNMP نسخه 1 و 2c (که فاقد مکانیزم‌های امنیتی کافی هستند) و استفاده از SNMPv3 با احراز هویت قوی.
- محدود کردن دسترسی SNMP فقط به IPهای مدیریتی مطمئن.
- بررسی لاگ‌های شبکه برای فعالیت‌های غیرمعمول SNMP.
- اجرای دوره‌ای اسکن آسیب‌پذیری و تست نفوذ داخلی برای تجهیزات شبکه.
✅ کوئری‌های SIEM برای تشخیص سوء‌استفاده‌ی | SNMP نصبrootkit روی سوئیچ‌ها
نکته: لاگها و فیلدها در هر سازمان متفاوت‌اند. اگر لاگ سوئیچ‌ها از طریق syslog به SIEM می‌آید، از sourcetype یا syslog_facility مناسب استفاده کن و در کوئری‌ها فیلدهای محلی را جایگزین کن.
Splunk — جستجوی اولیه برای ترافیک SNMP غیرمعمول و پورت‌های UDP جدید
index=network OR index=syslog sourcetype="cisco:ios" OR sourcetype="syslog" ( (dest_port=161 OR dest_port=162) OR (message="*SNMP*" OR message="*snmp*") ) | stats count by src_ip, dest_ip, dest_port, host | where count > 50 | sort - count
توضیح: دنبال ترافیک SNMP زیاد (port 161/162) یا رخدادهای SNMP در لاگ سوئیچ‌ها بگرد. آستانه >50 برای یک بازهی پیش‌فرض (مثلاً 1 ساعت) را می‌توان سخت یا نرم کرد.
Splunk — شناسایی فراخوانی‌های مدیریتی غیرمعمول / تغییرات پیکربندی
index=syslog sourcetype="cisco:ios" ( message="*%SYS-5-CONFIG_I:*" OR message="*%SYS-5-LOG_SWITCHBASE:*" OR message="*%SNMP-5-*" OR message="*configuration change*" ) | rex field=message "from (?<user>\S+) by (?<method>\S+)" | stats count by host, user, method, _time | where count > 5
توضیح: پیام‌های مربوط به تغییر پیکربندی در IOS را جمع‌آوری کن. اگر یک کاربر یا متد (مثلاً SNMP) چند بار در بازه ی کوتاه تغییرات زده، مشکوک است.
Elastic / Kibana (KQL) — دفعه‌هایی که لاگ حذف یا لاگ پنهان شده احتمالی رخ داده
KQL (مثال برای شاخص cisco-*):
event.dataset:cisco.syslog and (message:*"deleted logs"* OR message:*"config file removed"* OR message:*"reload"* ) | sort @timestamp desc
توضیح: جستجوی الگوهای متنی که احتمالاً نشان‌دهنده‌ی دست‌کاری لاگ یا ریست شدن غیرعادی هستند. متن دقیق را با نمونه لاگ‌های خود تطبیق بده.
Elastic — ترافیک داخلی غیرعادی به پورت UDP listener (برای بررسی listenerهای جدید)
KQL / Lucene (مثال برای Netflow/Packetbeat):
destination.port:161 or destination.port:162 and network.direction: inbound | stats count() by source.ip, destination.ip, destination.port | where count > 20
توضیح: زمانی که سرویس SNMP روی دستگاه مدیریتی از بیرون یا از میزبان‌های غیرمنتظره درخواست زیادی دریافت می‌کند، هشدار بده.
QRadar AQL — شناسایی listenerهای UDP جدید یا تغییرات در پورت‌های باز
SELECT QIDNAME(logsourceid) AS eventName, LOGSOURCETYPENAME(logsourceid) AS srcType, COUNT(*) AS cnt, MIN(starttime) AS first, MAX(endtime) AS last FROM events WHERE (protocol = 'UDP' AND (destination_port = '161' OR destination_port = '162')) AND LOGSOURCETYPENAME(logsourceid) LIKE '%Cisco%' GROUP BY eventName, srcType HAVING cnt > 30
توضیح: آلارم وقتی تعداد رخدادهای UDP/SNMP از یک منبع بیش از حد شود.
Sigma rule — قاعده‌ی مستقل از پلتفرم (YAML)
title: Suspicious SNMP Activity and Possible Device Compromise id: e3e7f2a2-xxxx-xxxx-xxxx-xxxxxxxxxxxx status: experimental description: Detects unusual SNMP traffic or configuration changes that may indicate exploitation of SNMP vulnerabilities and post-exploitation activity on network devices. logsource: product: network service: syslog detection: selection: - message|contains: - "SNMP" - "%SYS-5-CONFIG_I" - "configuration change" condition: selection level: high tags: - attack.persistence - attack.privilege_escalation توضیح: Sigma را می‌توان به سازگار با SIEM مقصد (Splunk/ELK/QRadar) تبدیل و سپس پیاده‌سازی کرد.
📋 Playbook واکنش سریع وقتی آلارم زده شد
- تایید (Triage) : منابع لاگ را جمع‌آوری کنید. (syslog سوئیچ، NetFlow/PCAP اگر موجود است، EDR روی سرورهای متصل).
- ایزوله: در صورت دشواری در تشخیص، دستگاه مشکوک را از شبکه مدیریتی و از اینترنت ایزوله کنید.
- حفظ شواهد: تصویر حافظه/فایل پیکربندی، dump از firmware/ROM (در صورت امکان)، و ذخیره لاگها.
- تحلیل: جستجوی listenerهای UDP جدید، timestampهای تغییر پیکربندی، و هر نمونه‌ای از لاگ‌های حذف شده یا پاک‌سازی‌شده.
- پاک‌سازی/بازیابی: اگر آلودگی تأیید شد، پاک‌سازی firmware یا بازنویسی IOS/firmware از نسخهی تأیید شده و بازگردانی از پیکربندی سالم.
- ریست دسترسی‌ها: تغییر تمامی credentialهای مدیریتی و بازنگری ACLها / AAA .
- پیام‌رسانی: اطلاع به مدیریت و تیم‌های مربوطه و ثبت incident report.
- پایش بعدی: افزایش مانیتورینگ برای 30 روز و بررسی هر رفتار غیرعادی.
🧠 نتیجه‌گیری
این حادثه بار دیگر ثابت می‌کند که تهدیدات سایبری تنها از لایه نرم‌افزار آغاز نمی‌شوند. Firmware و پروتکل‌های مدیریتی مانند SNMP نیز می‌توانند دروازه‌ای برای نفوذهای عمیق‌تر باشند.
در محیط‌هایی که پایداری شبکه حیاتی است، هر مدیر سیستم باید نه‌تنها به‌روزرسانی‌های نرم‌افزاری را جدی بگیرد، بلکه کنترل دسترسی مدیریتی در سطح پروتکل‌های پایه را نیز با دقت تنظیم کند.
