بررسی روش کارکرد ویروس Stuxnet

استاکس‌نت (Stuxnet) - تحلیل کامل معماری، تاریخچه و نگاشت کد

هشدار و مسئولیت: این سند صرفاً برای مقاصد آموزشی و پژوهشی درباره یکی از مهم‌ترین رویدادهای تاریخ امنیت سایبری نوشته شده است. کدهای این مخزن یک بازسازی پژوهشی (reconstruction) بر اساس گزارش‌های عمومی شرکت‌های امنیتی (Symantec، ESET، Kaspersky) و تحلیل‌گرانی مانند Amr Thabet هستند، نه سورس اصلی نشت‌شده. استفاده از این مطالب برای اجرای هرگونه حمله واقعی روی سیستم‌های صنعتی، غیرقانونی و خطرناک است.

فهرست مطالب

• استاکس‌نت (Stuxnet) - تحلیل کامل معماری، تاریخچه و نگاشت کد
  • فهرست مطالب
  • سورس
  • ۱. مقدمه و اهمیت تاریخی
  • ۲. هدف حمله: نطنز و برنامه غنی‌سازی اورانیوم
  • ۳. نقشه کلی معماری Stuxnet
  • ۴. مرحله اول: ورود اولیه (Initial Infection)
  • ۵. مرحله دوم: افزایش سطح دسترسی (Privilege Escalation)
  • ۶. مرحله سوم: نصب Rootkit و پنهان‌سازی
  • ۷. مرحله چهارم: انتشار در شبکه (Propagation)
  • ۸. مرحله پنجم: ارتباطات فرمان و کنترل (C\&C)
  • ۹. مرحله ششم: نفوذ به Siemens Step 7 و WinCC
  • ۱۰. مرحله هفتم: خرابکاری فیزیکی روی PLC
  • ۱۱. نگاشت کامل فایل‌های مخزن به عملکرد واقعی
  • ۱۲. چرا این حمله بی‌سابقه بود
  • ۱۳. روش کشف
    • کشف تصادفی توسط یک شرکت کوچک
    • شناسایی هدف واقعی - ماه‌ها تحلیل
    • اقدامات مهار (Mitigation)
    • واکنش ایران
    • نتیجه نهایی حمله

---

سورس

سورس موارد گفته شده در لینک زیر دردسترس است:
Stuxnet

۱. مقدمه و اهمیت تاریخی

استاکس‌نت (Stuxnet) در ژوئن ۲۰۱۰ توسط شرکت امنیتی بلاروسی VirusBlokAda کشف شد، اما تحلیل‌های بعدی Symantec نشان داد که این کرم از حداقل سال ۲۰۰۹ در حال فعالیت بوده است. اهمیت استاکس‌نت در این است که اولین سلاح سایبری شناخته‌شده در تاریخ است که هدف نهایی‌اش نه سرقت اطلاعات، بلکه آسیب فیزیکی مستقیم به تجهیزات صنعتی بود. طبق تحلیل دانشگاه استنفورد (Stanford, cs356)، این بدافزار به‌طور خاص برای دستکاری کنترل‌کننده‌های منطقی برنامه‌پذیر (PLC) طراحی شده بود که در خطوط تولید صنعتی از جمله خطوط لوله گاز و نیروگاه‌ها استفاده می‌شوند.

پیچیدگی این حمله (استفاده از چهار آسیب‌پذیری Zero-Day به‌طور همزمان، دو گواهی دیجیتال سرقتی، و دانش عمیق مهندسی از تجهیزات Siemens) به‌طور گسترده به‌عنوان مدرکی از دخالت یک یا چند نهاد دولتی (state-sponsored) تفسیر شده است.

۲. هدف حمله: نطنز و برنامه غنی‌سازی اورانیوم

طبق تحلیل‌های منتشرشده (از جمله گزارش Falco - ccdcoe.org)، مسیر منطقی زنجیره حمله به این صورت بازسازی شده است:

• هدف نهایی، سانتریفیوژهای گازی IR-1 در تسهیلات غنی‌سازی اورانیوم نطنز در ایران بود.
• این سانتریفیوژها توسط درایورهای فرکانس متغیر (Variable Frequency Drives - VFD) ساخت شرکت‌های Fararo Paya (ایران) و Vacon (فینلاند) کنترل می‌شدند.
• کنترل این VFDها توسط PLCهای Siemens مدل S7-315 و S7-417 انجام می‌شد که از طریق نرم‌افزار مهندسی Step 7 و پایش SIMATIC WinCC مدیریت می‌شدند.
• چون شبکه کنترل صنعتی نطنز به اینترنت متصل نبود (Air-Gapped)، طراحان مجبور بودند بردار آلودگی را از طریق فیزیکی (USB) و انتشار محلی طراحی کنند.

۳. نقشه کلی معماری Stuxnet

معماری این بدافزار را می‌توان در ۴ لایه هم‌پوشان دید:

لایه	وظیفه	فایل‌های مرتبط در این مخزن
Dropper / Loader	ورود اولیه، تزریق کد، افزایش دسترسی	Dropper/Stub.c, Dropper/Stub - Handlers.c, Dropper/Winsta.exe.c, Dropper/Xutils.c
Rootkit (Kernel-mode)	پنهان‌سازی فایل، پروسه و رجیستری	Rootkit/mrxcls.sys.c, Rootkit/mrxnet.sys.c, Rootkit/FastIo.c, Rootkit/jmidebs.sys.c
ارتباطات و انتشار	C&C، RPC، P2P، فشرده‌سازی داده	CONN/agentsb.dll.c, CONN/datacprs.dll.c, CONN/inetpsp.dll.c, CONN/netsimp32.d.c, Complnd/Complnd.dll.c, Complnd/Complnd - RPC.dll.c, Complnd/Complnd - Proxy.dll.c
Payload صنعتی (ICS)	حمله به PLC و پنهان‌سازی نتیجه	s7otbxdx/s7otbxdx.dll.c, s7otbxdx/s7otbxsx, s7otbxdx/s7cntlD.scr, Main/Stuxnet.dll.c, Main/homSave7.DBF.c, Main/stuxydbs.MDX.c, Main/perfnws.PNF.c

فایل‌های xor/checksum, xor/xor.txt, xor/paper, xor/Hex-Rays مربوط به الگوریتم رمزنگاری XOR سبک‌وزنی هستند که Stuxnet برای مبهم‌سازی (obfuscation) رشته‌ها و بلوک‌های داده در تمام لایه‌های بالا استفاده می‌کرد؛ همین ساده‌بودن الگوریتم (نه رمزنگاری قوی) یکی از دلایلی بود که تحلیل‌گران توانستند نسبتاً سریع باینری را دیکامپایل کنند.

۴. مرحله اول: ورود اولیه (Initial Infection)

مهم‌ترین ابزار ورود، سوءاستفاده از یک آسیب‌پذیری Zero-Day در نحوه رندر کردن آیکون فایل‌های میانبر ویندوز (LNK) بود؛ شناسه رسمی آن CVE-2010-2568 است. طبق مستندات ESET (Stuxnet Under the Microscope)، این باگ به‌گونه‌ای بود که صرفاً با نمایش یک پوشه حاوی فایل LNK آلوده در Windows Explorer (بدون حتی یک بار کلیک کاربر)، کد مخرب به اجرا می‌رسید.

در نگاشت این مخزن، منطق مربوط به مرحله‌ی اجرای اولیه و ثبت خودش به‌عنوان سرویس در فایل‌های Dropper/Stub.c و Dropper/Winsta.exe.c قرار دارد؛ Stub.c نقطه ورود (entry point) دراپر است که مسئول استخراج بسته اصلی و اجرای فایل باینری اصلی است، درحالی‌که Winsta.exe.c (برگرفته از نام واقعی فایل مشاهده‌شده در نمونه‌های اصلی، winsta.exe) نقش لانچر سطح-کاربر را ایفا می‌کند. تابع‌های کمکی رمزگشایی و بازکردن بسته‌های تعبیه‌شده (embedded resource) در Dropper/Xutils.c قرار دارند.

۵. مرحله دوم: افزایش سطح دسترسی (Privilege Escalation)

برای نصب یک درایور کرنلی، فرآیند دراپر نیاز به دسترسی SYSTEM دارد. طبق گزارش‌های ESET و ccdcoe، Stuxnet از دو مسیر Zero-Day دیگر بسته به نسخه ویندوز استفاده می‌کرد:

• CVE-2010-2743: آسیب‌پذیری در win32k.sys مرتبط با پردازش Keyboard Layout، مؤثر روی Windows XP.
• CVE-2010-3888 / Task Scheduler: سوءاستفاده از یک فایل XML ناقص در Task Scheduler که به کد اجازه اجرا با دسترسی بالاتر می‌داد.

فایل Dropper/Stub - Handlers.c در این مخزن، هندلرهایی را پیاده‌سازی می‌کند که مسئول تشخیص نسخه سیستم‌عامل (XP در برابر 7) و انتخاب مسیر افزایش دسترسی متناظر هستند - دقیقاً همان منطق «شاخه‌ای بر اساس نسخه OS» که در دیسمبل باینری واقعی مشاهده شده است.

۶. مرحله سوم: نصب Rootkit و پنهان‌سازی

بعد از رسیدن به دسترسی SYSTEM، دو درایور کرنلی نصب می‌شدند که هر دو با گواهی دیجیتال سرقت‌شده از شرکت‌های Realtek و JMicron امضا شده بودند تا از دید آنتی‌ویروس‌ها به‌عنوان درایور معتبر عبور کنند (طبق تحلیل ESET):

• Rootkit/mrxcls.sys.c: معادل درایور واقعی mrxcls.sys، به‌عنوان سرویس Boot-Start ثبت می‌شود (یعنی همراه با اولین لحظات بوت ویندوز بارگذاری می‌شود) و وظیفه اصلی‌اش تزریق کد (DLL injection) به فضای آدرس پروسه‌های هدف مانند s7tgtopx.exe و ccProjectMgr.exe است.
• Rootkit/mrxnet.sys.c: معادل mrxnet.sys، یک فیلتر درایور سیستم‌فایل (File System Filter Driver) است که با هوک‌کردن IRPهای مربوط به Enumeration، فایل‌های .lnk و .tmp مخرب روی درایوهای USB را از دید Explorer و اسکنرهای امنیتی مخفی می‌کند.
• Rootkit/FastIo.c: پیاده‌سازی توابع Fast I/O مربوط به مینی‌فیلتر درایور بالا؛ در معماری واقعی ویندوز، توابع FastIo برای عملیات پرتکرار (مثل خوانده‌شدن ویژگی‌های فایل) مسیر سریع‌تری از IRP معمولی فراهم می‌کنند و اینجا هم برای شفاف‌سازی همان مسیر سریع پنهان‌سازی استفاده شده‌اند.
• Rootkit/jmidebs.sys.c: بازسازی درایور جعلی دومی که با گواهی JMicron امضا شده بود (نسخه‌های بعدی Stuxnet این گواهی را جایگزین گواهی Realtek کردند وقتی گواهی اول باطل شد).

۷. مرحله چهارم: انتشار در شبکه (Propagation)

پس از آلوده‌شدن یک میزبان، Stuxnet چند مسیر مستقل برای گسترش به ماشین‌های دیگر داشت (طبق UMIACS Dossier و ccdcoe):

• آسیب‌پذیری Print Spooler (MS10-061 / CVE-2010-2729): هر ماشینی که به یک پرینتر اشتراکی مشترک دسترسی داشت، آلوده می‌شد.
• آسیب‌پذیری RPC (MS08-067): مسیر قدیمی‌تری که پیش‌تر توسط Conficker هم استفاده شده بود.
• فایل‌های پروژه Step 7: با آلوده‌کردن فایل‌های پروژه به اشتراک‌گذاشته‌شده بین مهندسان.
• P2P (همتا‌به‌همتا) از طریق RPC: به این ترتیب نسخه‌های آلوده می‌توانستند بدون سرور مرکزی، مستقیماً بین خودشان به‌روزرسانی مبادله کنند - ویژگی حیاتی برای محیط بدون اینترنت.

منطق ارتباطات RPC و مکانیزم P2P در این مخزن در فایل‌های Complnd/Complnd - RPC.dll.c و Main/stuxydbs.MDX.c بازسازی شده‌اند؛ نام stuxydbs اشاره به نام واقعی فایل پایگاه‌داده موقتی است که Stuxnet برای رهگیری نسخه‌های همتا و زمان آخرین به‌روزرسانی استفاده می‌کرد.

۸. مرحله پنجم: ارتباطات فرمان و کنترل (C&C)

اگرچه هدف اصلی (نطنز) به اینترنت متصل نبود، اما بسیاری از میزبان‌های آلوده‌شده در مسیر انتشار به اینترنت دسترسی داشتند. این میزبان‌ها تلاش می‌کردند به دو دامنه فرمان-و-کنترل (www.mypremierfutbol.com و www.todaysfutbol.com) متصل شوند تا نسخه‌های جدید را دانلود کرده یا اطلاعات محدودی درباره سیستم آلوده ارسال کنند.

در این مخزن، منطق رمزگذاری/فشرده‌سازی بسته‌های ارتباطی در CONN/datacprs.dll.c (Data Compress) و کتابخانه واسط شبکه در CONN/netsimp32.d.c بازسازی شده است. فایل CONN/inetpsp.dll.c معادل ماژول شبکه‌ای اینترنتی (Internet Proxy/SSP) است که مسیر HTTP خروجی به سمت دامنه‌های C&C را مدیریت می‌کرد، و CONN/agentsb.dll.c نقش عامل واسط (Agent Stub) بین ماژول اصلی و لایه شبکه را دارد.

۹. مرحله ششم: نفوذ به Siemens Step 7 و WinCC

این بخش تکنیک اصلی و متمایزکننده حمله است. نرم‌افزار Step 7 هرگز مستقیم با PLC صحبت نمی‌کند، بلکه از کتابخانه واسط s7otbxdx.dll استفاده می‌کند (طبق UMIACS Dossier، بخش «Looking at how access to the PLC works»).

روش کار به این صورت بود:

1. فایل اصلی و قانونی s7otbxdx.dll به نام s7otbxsx.dll تغییر نام داده می‌شد (تفاوت تنها در یک حرف: d به s). این دقیقاً منطبق با فایل s7otbxdx/s7otbxsx در این مخزن است که نسخه Renamed اصلی را نشان می‌دهد.
2. نسخه مخرب جدید، با همان نام اصلی s7otbxdx.dll جایگزین می‌شد؛ این فایل در مخزن معادل s7otbxdx/s7otbxdx.dll.c است.
3. این DLL جدید تمام توابع Export شده نسخه اصلی (مانند s7ag_read_szl, s7blk_write, s7db_open) را نیز داشت و به‌سادگی هر Call را اول از فیلتر خودش رد می‌کرد و سپس (در صورت نیاز) به نسخه اصلی (s7otbxsx.dll) هدایت می‌کرد؛ به این ترتیب Step 7 هیچ خطا یا کندی محسوسی حس نمی‌کرد.

فایل کمکی s7otbxdx/s7cntlD.scr در این مخزن معادل یک اسکریپت کنترلی کوچک برای هماهنگ‌سازی زمان‌بندی این جایگزینی در زمان بوت است. فایل‌های Main/homSave7.DBF.c و Main/stuxydbs.MDX.c نیز به فرمت‌های فایل واقعی Step 7 (پایگاه‌داده پروژه با پسوندهای DBF/MDX) اشاره دارند و مسئول ذخیره وضعیت آلودگی درون خود فایل پروژه پی‌ال‌سی بودند - به این ترتیب حتی اگر یک نسخه پروژه به مهندس دیگری در سایت دیگر منتقل می‌شد، آلودگی همراه آن سفر می‌کرد.

۱۰. مرحله هفتم: خرابکاری فیزیکی روی PLC

با استقرار DLL آلوده، فایل اصلی حمله - Main/Stuxnet.dll.c - هر ۱۵ دقیقه یک روتین بررسی محیط را اجرا می‌کرد (طبق تحلیل UMIACS Dossier):

1. با تابع s7ag_read_szl نوع دقیق CPU متصل خوانده می‌شد؛ فقط مدل‌های Siemens 6ES7-315-2 یا 6ES7-417 پذیرفته می‌شدند.
2. بلوک‌های System Data Block (SDB) پی‌ال‌سی بررسی می‌شدند تا مشخص شود پیکربندی از نوع «Sequence A» یا «Sequence B» است - دو الگوی متفاوت که Symantec معتقد است متناظر با دو خوشه سانتریفیوژ متفاوت در نطنز بودند.
3. اگر شرایط برقرار نبود، DLL کاملاً بی‌اثر (dormant) باقی می‌ماند.
4. در صورت تطابق، بلوک اصلی DP_RECV (که داده‌های ورودی/خروجی حلقه کنترلی را می‌خواند) کپی و به بلوک جدید FC1869 منتقل می‌شد و بلوک‌های سازمانی OB1 و OB35 (که به‌طور دوره‌ای اجرا می‌شوند) با منطق مخرب جایگزین می‌شدند.
5. منطق تزریق‌شده، فرمان‌های ارسالی به درایورهای فرکانس متغیر (VFD) را دستکاری می‌کرد؛ سرعت چرخش موتور سانتریفیوژ گاهی به بالای ۱۴۰۰ هرتز و گاهی به زیر ۲ هرتز می‌رفت، در چرخه‌های زمانی نامنظم و طولانی که تشخیص آن را برای مهندسان دشوار می‌کرد.

فایل Main/perfnws.PNF.c در این مخزن معادل ماژول اندازه‌گیری کارایی (Performance) است که زمان‌بندی این چرخه‌های ۱۵ دقیقه‌ای و تایمر مانیتورینگ داخلی را مدیریت می‌کند.

مهم‌ترین بخش فریب اینجا اتفاق می‌افتد: همان DLL آلوده که فرمان‌های مخرب را به PLC می‌فرستد، وقتی اپراتور روی مانیتور SCADA وضعیت را می‌خوانَد، مقادیر از‌پیش‌ضبط‌شده و طبیعی را نشان می‌دهد (طبق Broadcom/Symantec، «Exploring Stuxnet’s PLC Infection Process»). یعنی اپراتور در اتاق کنترل عملاً یک بازپخش ضبط‌شده از وضعیت سالم را می‌بیند درحالی‌که تجهیزات واقعی تخریب می‌شوند.

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

فایل در مخزن	نام واقعی متناظر (طبق تحلیل‌های عمومی)	نقش
Dropper/Stub.c	Dropper اصلی	نقطه ورود، استخراج بسته‌ها
Dropper/Stub - Handlers.c	هندلرهای Dropper	تشخیص OS، مسیر Exploit مناسب
Dropper/Winsta.exe.c	winsta.exe	لانچر سطح-کاربر
Dropper/Xutils.c	توابع کمکی	رمزگشایی و باز‌کردن بسته‌های تعبیه‌شده
Dropper/sysnullevnt.MOF.c	sysnullevnt.mof	فایل تعریف WMI برای اجرای خودکار
Rootkit/mrxcls.sys.c	mrxcls.sys	تزریق کد به پروسه‌ها
Rootkit/mrxnet.sys.c	mrxnet.sys	پنهان‌سازی فایل روی USB
Rootkit/FastIo.c	بخشی از mrxnet.sys	مسیر سریع I/O مینی‌فیلتر
Rootkit/jmidebs.sys.c	درایور با گواهی JMicron	نسخه دوم rootkit
CONN/agentsb.dll.c	Agent Stub	واسط بین Core و شبکه
CONN/datacprs.dll.c	Data Compression Module	فشرده‌سازی بسته‌های C&C
CONN/inetpsp.dll.c	Internet Proxy/SSP	ارتباط HTTP با C&C
CONN/netsimp32.d.c	Network Simple Module	لایه شبکه ساده‌شده
Complnd/Complnd.dll.c	Command Module	پردازش فرمان‌های دریافتی
Complnd/Complnd - RPC.dll.c	RPC Command Interface	ارتباط RPC بین همتاها
Complnd/Complnd - Proxy.dll.c	Proxy Command Module	مسیر Proxy برای فرمان‌ها
s7otbxdx/s7otbxdx.dll.c	s7otbxdx.dll (مخرب)	جایگزین کتابخانه واسط PLC
s7otbxdx/s7otbxsx	s7otbxsx.dll (اصلی، تغییرنام‌یافته)	نسخه اصلی و قانونی
s7otbxdx/s7cntlD.scr	اسکریپت کنترلی	زمان‌بندی جایگزینی DLL
Main/Stuxnet.dll.c	Payload اصلی	منطق تشخیص هدف و تزریق به PLC
Main/homSave7.DBF.c	فایل پروژه Step 7 (DBF)	ذخیره وضعیت آلودگی در پروژه
Main/stuxydbs.MDX.c	پایگاه‌داده P2P	رهگیری نسخه‌های همتا
Main/perfnws.PNF.c	ماژول Performance	زمان‌بندی چرخه بررسی ۱۵ دقیقه‌ای
xor/*	الگوریتم XOR obfuscation	مبهم‌سازی رشته‌ها و داده‌ها
Desktop/desktop.ini	فایل سیستمی جعلی	کمک به پنهان‌سازی روی پوشه‌های به‌اشتراک‌گذاشته

۱۲. چرا این حمله بی‌سابقه بود

سه ویژگی، Stuxnet را از تمام بدافزارهای پیش از خود متمایز کرد:

• استفاده همزمان از چهار آسیب‌پذیری Zero-Day در یک بدافزار، هزینه توسعه‌ای که به میلیون‌ها دلار می‌رسید و نشانه‌ای قوی از حمایت یک نهاد دولتی بود.
• استفاده از دو گواهی دیجیتال سرقتی (Realtek و JMicron) برای دورزدن سیستم‌های تشخیص مبتنی بر اعتماد به امضای دیجیتال.
• طراحی هدفمند برای آسیب فیزیکی تدریجی به‌جای تخریب فوری، که هم تشخیص را دشوار می‌کرد و هم زمان کافی برای انتشار گسترده قبل از کشف فراهم می‌آورد.

۱۳. روش کشف

استاکس‌نت در ژوئن ۲۰۱۰ کشف شد، اما این کشف کاملاً تصادفی و از سر ناتوانی خود بدافزار در پنهان‌ماندن کامل اتفاق افتاد؛ سپس چند نهاد مستقل به‌مرور آن را خلع‌سلاح کردند.

کشف تصادفی توسط یک شرکت کوچک

ماجرا از یک باگ در خود Stuxnet شروع شد، نه از یک هشدار امنیتی. یک مشتری ایرانی متوجه شد کامپیوترهایش که سرور SIMATIC WinCC روی آن‌ها نصب بود، بی‌وقفه ری‌استارت می‌شوند و با شرکت امنیتی کوچک بلاروسی VirusBlokAda تماس گرفت. محقق این شرکت، سرگئی اولاسِن (Sergey Ulasen)، در ۱۷ ژوئن ۲۰۱۰ فایل‌های مخربی را پیدا کرد که از یک آسیب‌پذیری ناشناخته (Zero-Day) در فایل‌های LNK ویندوز استفاده می‌کردند. او این یافته را به مایکروسافت اطلاع داد و همین موضوع، زنجیره‌ای از تحلیل‌های جهانی را به راه انداخت.

شناسایی هدف واقعی - ماه‌ها تحلیل

بعد از کشف اولیه، Symantec، Kaspersky و محقق مستقل آلمانی رالف لانگنر (Ralph Langner) روی دیکامپایل کردن کد کار کردند. تا سپتامبر ۲۰۱۰ (حدود سه ماه بعد از کشف)، لانگنر توانست ثابت کند این بدافزار دقیقاً هدف‌گذاری‌شده روی PLCهای Siemens S7-315 و S7-417 است. او با تحلیل آرایه‌های داده، متوجه شد این کد دقیقاً منطبق با آبشارهای ۱۶۴-سانتریفیوژی نطنز است - مدرکی که عملاً هدف را قطعی کرد.

اقدامات مهار (Mitigation)

هیچ سازمان واحدی «جلوی» Stuxnet را به یک‌باره نگرفت؛ بلکه چند اقدام موازی آن را خلع‌سلاح کرد:

• مایکروسافت طی چند ماه، وصله‌های امنیتی (patch) برای هر چهار آسیب‌پذیری Zero-Day منتشر کرد؛ از جمله باگ LNK در اوت ۲۰۱۰.
• زیمنس یک ابزار تشخیص و حذف اختصاصی منتشر کرد و به مشتریانش توصیه کرد از فلش‌های USB غیرمجاز استفاده نکنند و رمزهای عبور پیش‌فرض WinCC را فوراً تغییر دهند.
• شرکت‌های آنتی‌ویروس (Symantec، Kaspersky و غیره) امضاهای (signature) تشخیص Stuxnet را به پایگاه‌داده‌های خود اضافه کردند، که عملاً گسترش آن را روی رایانه‌های عادی متوقف کرد.
• خودِ Stuxnet یک تاریخ خودتخریبی (Kill Date) داشت: طبق تحلیل Kaspersky (Securelist)، در یکی از بلوک‌های پیکربندی، مقداری معادل ۲۴ ژوئن ۲۰۱۲ کدگذاری شده بود که از آن تاریخ به بعد، زیرروتین‌های انتشار از طریق فایل LNK به‌طور خودکار غیرفعال می‌شدند.

واکنش ایران

ایران در ابتدا آلودگی را رسماً تأیید نکرد، اما بعداً احمدی‌نژاد اعلام کرد که «کارشناسان ایرانی این حمله سایبری را کشف کردند و برای جلوگیری از تأثیر یا تکرار آن اقدام کردند». طبق گزارش نهاد نظارتی ISIS، ایران در اواخر ۲۰۰۹ و اوایل ۲۰۱۰ حدود ۱۰۰۰ سانتریفیوژ IR-1 را در تسهیلات نطنز از کار انداخت و جایگزین کرد - که نشان می‌داد این تعداد در اثر Stuxnet آسیب دیده بودند. این رقم حدود ۱۰ درصد از ظرفیت وقت نطنز بود.

نتیجه نهایی حمله

با این حال باید دقیق بود: Stuxnet «کاملاً» غنی‌سازی ایران را متوقف نکرد. طبق تحلیل ICRC Casebook، اگر هدف Stuxnet نابودی کامل سانتریفیوژهای FEP بود، این هدف محقق نشد؛ برنامه غنی‌سازی ایران تنها با تأخیر و کاهش موقت کارایی (حدود ۳۰ درصد) ادامه یافت. یعنی این حمله بیشتر یک عقب‌انداختن استراتژیک بود تا نابودی کامل برنامه هسته‌ای.

---

این سند بخشی از تلاش آموزشی این مخزن برای درک عمیق یکی از پیچیده‌ترین سلاح‌های سایبری تاریخ است. لطفاً محتوای این پروژه را صرفاً برای پژوهش، آموزش امنیت سایبری و دفاع صنعتی (ICS/SCADA Security) استفاده کنید.