NotPetya: تاریخ کا سب سے مہنگا سائبر حملہ

25 فروری، 2026 • 12 min read

جون 2017 کے آخر میں یوکرین میں ایک ایسی چیز شروع ہوئی جو پہلی نظر میں “ہمیشہ والا ransomware” لگتی تھی: کمپیوٹر ریبوٹ ہونے لگتے ہیں، فائلیں اچانک دستیاب نہیں رہتیں، اور اسکرین پر تاوان کا مطالبہ آ جاتا ہے۔

چند ہی گھنٹوں بعد یہ واضح ہو جاتا ہے: یہ کوئی لوکل واقعہ نہیں تھا۔ یہ ایک آگ تھی جو پھیل رہی تھی۔

جس نام نے جگہ بنائی وہ NotPetya ہے۔ آج بھی یہ اس بات کی علامت ہے کہ “بظاہر سادہ مالویئر ویو” کیسے دنیا بھر میں کمپنیوں کو روک سکتی ہے اور اربوں کے نقصان میں بدل سکتی ہے۔

اس پوسٹ میں میں دو چیزیں جوڑنا چاہتا ہوں:

NotPetya کی کہانی: اُس وقت کیا ہوا اور یہ اتنا مہنگا کیوں پڑا؟
عملی زاویہ: آج “نارمل” کمپنیوں کے لیے اس کا کیا مطلب ہے، صرف Fortune 500 کے لیے نہیں؟

NotPetya کی پریشان کن بات یہ نہیں کہ وہ “بہت پیچیدہ” تھا۔ پریشان کن بات یہ ہے کہ یہ خوفناک حد تک حقیقت پسندانہ ہے۔

میں یہ 2026 میں کیوں لکھ رہا ہوں؟ کیونکہ آج ہم AI سے چلنے والے deepfake phishing پر بات کرتے ہیں، لیکن بحران میں ہم اب بھی 2017 جیسی بنیادی چیزوں پر پھسلتے ہیں: segmentation کی کمی اور backups جو پروڈکشن کے ساتھ اسی “لائف لائن” پر لٹکے ہوئے ہوں۔

NotPetya پانچ منٹ میں: کیا ہوا؟

سمجھنے کے لیے ہمیں واقعات ترتیب دینا ہوں گے۔

27 جون 2017 کو NotPetya پہلے یوکرین میں نظر آیا اور پھر بہت تیزی سے عالمی سطح پر پھیل گیا۔ ایک مرکزی عنصر یوکرین میں عام طور پر استعمال ہونے والے اکاؤنٹنگ سافٹ ویئر (M.E.Doc) کا compromised update تھا۔ یہ “ایک غلط کلک” سے نہیں آیا، بلکہ ایک ایسے میکانزم سے آیا جسے کمپنیاں روزانہ استعمال کرتی ہیں: updates۔

اور یہ وہ نکتہ ہے جسے اکثر نظر انداز کیا جاتا ہے: یہ بنیادی طور پر Supply Chain Attack تھا۔ M.E.Doc اتفاقی ہدف نہیں تھا؛ updates پر قدرتی طور پر اعتماد کیا جاتا ہے، اسی لیے یہ بہترین لیور تھا۔

آج کا سبق کڑوا مگر ضروری ہے: آپ اندرونی IT کو جتنا بھی “ٹھیک” کر لیں، اگر اکاؤنٹنگ، vendor، ERP connector یا کسی third-party tool کی software supply chain compromise ہو جائے تو آپ پھر بھی متاثر ہوں گے۔ supply chain risk کوئی “cloud والی بات” نہیں؛ یہ بہت سیدھی طرح updates والی بات ہے۔

جب NotPetya ایک بار نیٹ ورک میں آ گیا تو پھر بات single endpoints کی نہیں رہی، بلکہ Lateral Movement کی ہو گئی:

SMB اور معروف کمزوریوں کے ذریعے (جس میں EternalBlue / MS17-010 بھی شامل ہے، جو NSA کے toolset سے لیک ہونے والا exploit سمجھا جاتا ہے) NotPetya بغیر user interaction کے دیگر Windows سسٹمز تک پھیل سکتا تھا۔
ساتھ ہی، credential dumping (Mimikatz/LSASS) کے ذریعے RAM سے passwords/hashes نکال کر وہ حقیقی admin credentials کے ساتھ آگے بڑھتا تھا۔
remote execution کے لیے اس نے “نارمل” admin tools (مثلاً PsExec/WMI) بھی استعمال کیے۔ یہی مکس خطرناک ہے کیونکہ ابتدا میں logs میں یہ “آپریشن” جیسا لگ سکتا ہے۔

یہی “خفیہ نسخہ” تھا: exploit کے ساتھ تیزی سے نئی مشینوں تک پہنچنا، memory سے credentials لے کر حقیقی privileges حاصل کرنا، پھر built-in tools سے اسکیل کرنا۔

اہم بات: صرف patching کافی نہیں تھا۔ اگر کوئی سسٹم EternalBlue کے خلاف patched بھی تھا تو وہ تب بھی گر سکتا تھا جب مالویئر نے نیٹ ورک میں کہیں سے valid admin credentials/hashes حاصل کر لیے ہوں۔

NotPetya نے وقت کے ساتھ بھی کھیل کھیلا: اس میں delay تھا اور “بڑا دھماکا” (reboot/wipe) فوراً نہیں ہوتا تھا بلکہ کچھ دیر بعد ہوتا تھا۔ اس سے detection مشکل ہوتی ہے اور یہ sandboxing کے خلاف بھی کلاسک پیٹرن ہے: مالویئر فوری “detonate” نہیں کرتا، جبکہ پس منظر میں پھیل چکا ہوتا ہے۔

نتیجہ وہی ہے جو ہمیشہ نظر آتا ہے:

پہلے چند سسٹمز “عجیب” لگتے ہیں۔
پھر اچانک پورا site گر جاتا ہے۔
اور اگر آپ بہت تیزی سے ردعمل نہ دیں (نیٹ ورک کاٹنا، اکاؤنٹس lock کرنا، segment boundaries بند کرنا) تو یہ بین السائٹ پھیل سکتا ہے۔

“Ransomware” صرف پردہ کیوں تھا؟

NotPetya کو بہت جگہ ransomware سمجھا گیا کیونکہ اس نے تاوان کا پیغام دکھایا۔ لیکن تکنیکی اور عملی طور پر یہ کچھ اور تھا۔

اصل نکتہ: NotPetya حقیقت میں wiper تھا۔ اس کا مقصد “پیسہ کمانا” نہیں بلکہ سسٹمز کو مستقل نقصان پہنچانا اور آپریشن روکنا تھا۔

یہ بات شاید لفظی لگے، مگر incident میں فرق بہت بڑا ہے:

کلاسک ransomware میں (کبھی کبھار) keys یا negotiation کے ذریعے واپسی کا امکان ہوتا ہے۔
wiper میں مقصد “توڑنا” ہوتا ہے۔ Bitcoin ٹرانسفر مدد نہیں کرتا۔

NotPetya میں ایک تکنیکی تفصیل اس بات کو مزید واضح کرتی ہے: اس نے MBR (Master Boot Record) overwrite کیا اور MFT (Master File Table) encrypt کی۔ اور “ransomware” میکانزم کی implementation بھی خراب تھی: دکھائی جانے والی installation ID رینڈم ہوتی تھی اور usable decryption key کے ساتھ ٹھیک طرح link نہیں تھی۔ یعنی تقنیکی طور پر واپسی کا راستہ تقریباً موجود نہیں تھا۔

اسی لیے NotPetya اتنا خطرناک تھا: اس نے شروع میں کمپنیوں کو غلط playbook کی طرف دھکیل دیا۔ آپ “ransomware playbook” سوچتے ہیں، جبکہ آپ کو “disaster recovery playbook” چاہیے ہوتا ہے۔

یہ بھی اسی کہانی سے میل کھاتا ہے کہ اسے بعد میں کئی حکومتوں نے روسی state actors سے منسوب کیا۔

10 ارب ڈالر: یہ اتنا مہنگا کیوں پڑا؟

اگر آپ صرف “ransomware” لیبل دیکھیں تو نقصان سمجھ میں نہیں آتا: “backup سے restore کر لیں”۔

حقیقت میں NotPetya اتنا مہنگا اس لیے پڑا کیونکہ اس نے وہاں ضرب لگائی جہاں بجٹس میں ہمیشہ کمی رہتی ہے: availability۔

سب سے بڑا خرچ مالویئر نہیں، بلکہ downtime تھا:

پروڈکشن لائنیں رک جاتی ہیں۔
لاجسٹکس کاغذ پر آ جاتی ہے۔
identities اور domains دوبارہ بنانے پڑتے ہیں۔
ایپس، integrations اور dependencies ایک کے بعد ایک گرتی ہیں۔
اور یہ سب ایک ساتھ کئی جگہ ہوتا ہے۔

اسی لیے NotPetya کو اکثر “تاریخ کا سب سے مہنگا سائبر حملہ” کہا جاتا ہے اور مجموعی نقصان تقریباً 10 ارب امریکی ڈالر بتایا جاتا ہے۔

اور یہ کمپنیوں کے اپنے اعداد میں بھی نظر آتا ہے: Merck، FedEx (TNT Express سمیت) اور Mondelez نے بتایا کہ یہ صرف IT مسئلہ نہیں تھا بلکہ بزنس پر براہ راست اثر تھا۔

NotPetya کا ایک بڑا قانونی پہلو بھی تھا: کمپنیوں اور insurers کے درمیان جھگڑے۔ کچھ insurers نے اسے “Act of War” کہہ کر ادائیگی سے بچنے کی کوشش کی (یعنی ریاستی حملہ)۔ Mondelez کا کیس کافی معروف ہے۔ آج بھی سبق یہی ہے: کیا آپ کی cyber insurance ریاستی حملوں کو کور کرتی ہے، یا war exclusion لگ جائے گی؟

Pro-readers کے لیے اپ ڈیٹ: Mondelez کیس 2023 میں فائنل ہو گیا۔ اس کے بعد (اور مجموعی طور پر NotPetya کے بعد) انشورنس انڈسٹری نے کئی جگہ clauses سخت کر دیں: “state-motivated” حملوں کو اب زیادہ تنگ انداز میں define کیا جاتا ہے یا واضح طور پر exclude کر دیا جاتا ہے۔ اس سے cyber insurance ایک حقیقی مالی خطرہ بن جاتی ہے اگر آپ wording نہیں سمجھتے۔

ایک اور بات: چاہے آپ “صرف IT restore” ہی کر رہے ہوں، حقیقت میں dependencies آپ کو روکتی ہیں۔

Maersk کی مثال اکثر دی جاتی ہے: یہ چند فائلوں کا معاملہ نہیں تھا، بلکہ core systems، identities اور operational IT دوبارہ بنانا تھا تاکہ ports اور logistics چل سکیں۔

اور اس کے پیچھے ایک مشہور کہانی ہے: Maersk نے تقریباً پورا global Active Directory کھو دیا تھا — سوائے Ghana میں ایک Domain Controller کے جو بجلی کی بندش کے باعث حملے کے وقت offline تھا۔ یہ “Lucky Punch” ایک accidental offline backup بن گیا: اسی ایک فزیکل سرور سے وہ عالمی AD دوبارہ کھڑا کر سکے۔

آخر میں، یہ صرف “IT” نہیں بلکہ بزنس پر سیدھا اثر ڈالتا ہے:

فوڈ میں: پروڈکشن، پلاننگ اور سپلائی چین رک جاتی ہے۔
شپنگ میں: کنٹینرز کھڑے رہ جاتے ہیں۔
فارما میں: مینوفیکچرنگ، کوالٹی اور سپلائی پر دباؤ آتا ہے۔

اسی لیے یہ اتنا مہنگا ہے: ransom اسکرین علامت ہے، اصل نقصان downtime ہے۔

عملی مثال: ایک “نارمل” کمپنی میں کیا ہو سکتا ہے؟

میں جان بوجھ کر ایک ایسا سیناریو بیان کرنا چاہتا ہوں جو ہالی ووڈ نہ لگے۔ “State actor vs big tech” نہیں، بلکہ مڈ سائز کمپنی کے لیے حقیقت پسندانہ۔

ایک مڈ سائز کمپنی تصور کریں:

ایک مین سائٹ اور ایک چھوٹی دوسری سائٹ۔
کلاسک Windows setup: AD، فائل سرور، چند VMs، ERP۔
کچھ سسٹمز جنہیں کوئی چھیڑتا نہیں: مشین کنٹرولرز، پرانا اسپیشل سافٹ ویئر، “Windows Server 2008 کچھ”۔
backups: روزانہ NAS پر، ہفتہ وار ایک دوسرے سسٹم پر بھی۔

اور یہاں وہ بات ہے جو اکثر مس ہوتی ہے:

یہ کمپنی “کم سکیورٹی” اس لیے نہیں رکھتی کہ سب ناکام ہیں۔ بلکہ اس لیے کہ آپریشن اور وقت ہمیشہ جیتتے ہیں۔

پچنگ ٹلتی ہے کیونکہ پروڈکشن ٹائٹ ہے۔ segmentation “بعد میں” کیونکہ VLANs محنت ہیں۔ لوکل ایڈمن پاس ورڈز تاریخی بوجھ ہیں۔ اور NAS آن لائن ہے کیونکہ ورنہ restore مشکل ہے۔

ٹائم لائن (حقیقت پسندانہ)

منگل کی صبح ایک update آتا ہے۔ vendor، سروس پرووائیڈر ٹول، connector—کوئی بھی auto-update والی چیز۔ یا VPN کے ذریعے کسی پارٹنر کا compromised سسٹم۔

08:10: پہلے کلائنٹس unstable۔
08:25: پہلا فائل سرور slow۔
08:40: “ڈومین عجیب”۔ لاگ اِن سست، گروپ پالیسی خراب۔
09:00: ایک admin “جلدی سے دیکھنے” کے لیے لاگ اِن کرتا ہے—اکثر یہیں lateral movement تیز ہوتا ہے۔
09:20: ایک پورا site عملی طور پر offline۔

اور پھر وہ حصہ آتا ہے جو بعد میں سمجھ آتا ہے:

اگر اس لمحے آپ hard cut نہیں کرتے تو نقصان linear نہیں، exponential ہوتا ہے۔

اور پھر وہ سوال آتا ہے جو ہمیشہ آتا ہے:

“کیا ہمیں pay کرنا چاہیے؟”

NotPetya میں تلخ حقیقت یہ تھی: pay کرنے سے بھی شاید کچھ نہ ہوتا۔ آپ کو فوراً “rebuild” موڈ میں جانا ہوتا ہے، “decrypt” میں نہیں۔

جتنا دیر کریں گے، اتنے زیادہ سسٹمز دوبارہ بنانے پڑیں گے۔ جتنے زیادہ سسٹمز، اتنا ہی زیادہ وقت ایمرجنسی موڈ میں۔ اور جتنا زیادہ وقت ایمرجنسی موڈ میں، اتنا ہی زیادہ خرچ۔

اصل درد کہاں ہوتا ہے؟

کچھ گھنٹوں بعد واضح ہو جاتا ہے: یہ “چند فائلیں restore” نہیں۔ یہ “Active Directory اور core systems دوبارہ بنانا” ہے۔

اور پھر پتہ چلتا ہے:

backups آن لائن تھے اور متاثر ہو گئے۔
ڈاکیومنٹیشن اپ ٹو ڈیٹ نہیں۔
“golden images” کم ہیں۔
admin credentials ہر جگہ تھے۔
کسی نے کبھی 30 منٹ میں site کو clean segment کرنے کی مشق نہیں کی۔

یہ وہ لمحہ ہے جب IT incident کمپنی بحران بن جاتا ہے۔

آج SOC کیا مختلف کرتا ہے (اور AI کہاں مدد کرتا ہے)

ایک بڑے SOC میں روزانہ اربوں events آتے ہیں۔ یہ “ایک admin لاگ دیکھ رہا ہے” نہیں، بلکہ صنعتی عمل ہے: sensors، correlation، automation اور انسانی تجزیہ۔

رولز کی تقسیم دلچسپ ہے:

AI/automation بطور پہلی لائن: چھانٹتی ہے، correlates کرتی ہے، patterns نکالتی ہے، واضح چیزیں فلٹر کرتی ہے۔
انسان بطور دوسری/تیسری لائن: جب کیس critical یا unclear ہو تو analysts فیصلہ اور response coordinate کرتے ہیں۔

یہ “صرف بڑی کمپنیوں” جیسا لگتا ہے، مگر سبق چھوٹی کمپنیوں کے لیے بھی ہے:

آپ کو SOC خود نہیں بنانا۔ مگر ذہنیت وہی چاہیے:

signals جمع کریں (EDR، firewall، auth logs)۔
“normal” define کریں۔
اور ایسا process رکھیں جو منٹوں میں react کرے، دنوں میں نہیں۔

NotPetya 2017 میں ہی اتنا تیز تھا کہ انسان “کافی تیزی” سے react نہیں کر سکتا تھا جب پھیلاؤ شروع ہو جائے۔ AI کا اصل فائدہ “اور تیز” ہونا نہیں، بلکہ noise میں anomaly جلدی ڈھونڈنا ہے (مثلاً رات 03:00 پر اچانک 500 مشینیں SMB پر بات کرنا چاہیں)۔ وہی منٹ فیصلہ کرتے ہیں: جلدی دیکھیں، جلدی محدود کریں، جلدی isolate کریں۔

اور پھر ایک mindset ہے جو اب default بنتا جا رہا ہے:

Assume breach.

یعنی پلان ایسے کریں جیسے attacker پہلے سے اندر ہے۔ یہ paranoia نہیں، pragmatism ہے۔

آج کم از کم کیا ہونا چاہیے (بغیر enterprise بجٹ کے)

اگر NotPetya سے ایک چیز لینی ہو تو وہ یہ ہے:

NotPetya “ایک vulnerability” نہیں تھا۔ یہ کمزوریوں کی ایک چین تھی جو ایک دوسرے کو amplify کرتی رہی۔

اچھی بات یہ ہے کہ اسی لیے چند basics سے بڑا رسک کم ہو سکتا ہے۔

1) Patch اور exposure management (سنجیدگی سے)

Windows کے critical updates (خاص طور پر SMB) “کبھی نہ کبھی” نہیں چلتے۔
جو چیز باہر سے reachable ہے وہ priority ہے۔
legacy چاہیے تو کم از کم segmented اور واضح rules کے ساتھ۔

2) Lateral Movement کو مشکل بنائیں

admin accounts الگ کریں (روزمرہ vs admin)۔
ہر ڈیوائس پر unique local admin passwords (LAPS)۔
WMI/PsExec کو ہر جگہ کھلا نہ چھوڑیں۔
SMB کو صرف جہاں واقعی ضرورت ہو وہاں رکھیں۔

3) Segmenting، مگر pragmatically

آپ کو کل سے “perfect Zero Trust” نہیں چاہیے۔ مگر:

clients، servers، backups اور OT/production ایک فلیٹ نیٹ میں نہیں ہونے چاہییں۔
Domain Controllers tier 0 ہیں۔
east‑west traffic پر بھی ویسی توجہ چاہیے جیسے internet traffic پر۔

4) Backups: offline، immutable، tested

میں وہی کہوں گا جو اکثر پروجیکٹس میں نظر آتا ہے:

جو backup ہمیشہ writable اور ہمیشہ online ہو، وہ incident میں اکثر backup نہیں رہتا۔

3-2-1 اچھا آغاز ہے۔
immutable storage (یا offline media) game changer ہے۔
restore tests لازمی ہیں۔

5) Incident runbooks اور سائٹس کے لیے “kill switch”

80 صفحوں کا handbook نہیں چاہیے۔ مگر clarity چاہیے:

کون فیصلہ کرتا ہے کہ site کٹے؟
accounts جلدی کیسے lock ہوں؟
پہلے کون سے سسٹمز واپس آئیں (AD، DNS، DHCP، VPN، ERP)؟

اور یہ practice کرنا ضروری ہے۔

Reality-check: NotPetya میں اکثر سب سے مؤثر اقدام “ایک اور tool” نہیں تھا، بلکہ فزیکلی کاٹ دینا تھا۔ Maersk کے بارے میں ایسے بیانات ملتے ہیں کہ لوگ دفاتر میں دوڑ کر switches سے پاور/نیٹ ورک کیبلز نکال رہے تھے تاکہ پھیلاؤ روکا جا سکے۔ سننے میں سادہ ہے، مگر کبھی یہی بہترین “High-Tech Security” ہوتی ہے۔

نتیجہ

NotPetya آج بھی اس بات کی بہترین مثال ہے کہ IT security “antivirus ہے تو بس” نہیں۔

یہ اس لیے تباہ کن نہیں تھا کہ یہ جادو تھا۔ بلکہ اس لیے کہ یہ عام کمزوریوں پر لگا:

updates پر اندھا اعتماد
lateral movement بہت آسان
کم segmentation
backups پروڈکشن نیٹ کے بہت قریب

اسی لیے یہ “نارمل” کمپنیوں کے لیے بھی اتنا relevant ہے۔

اگر آج آپ سرمایہ کاری کرتے ہیں تو صرف tools میں نہیں، resilience میں کریں: visibility، تیز response، اور clean restore کی صلاحیت۔ یہ فرق ہے “ایک بہت برا دن” اور “ایک ایسا quarter جسے آپ کبھی نہیں پکڑ پائیں گے” کے درمیان۔

ذرائع اور مزید پڑھیں

اگلی بار تک، Joe