NotPetya: इतिहास का सबसे महंगा साइबर हमला

जून 2017 के आखिर में यूक्रेन में कुछ ऐसा शुरू हुआ जो पहली नजर में “हमेशा वाला ransomware” लगता है: मशीनें reboot होती हैं, फाइलें अचानक उपलब्ध नहीं रहतीं, और स्क्रीन पर फिरौती की मांग दिखती है।

कुछ ही घंटों बाद साफ हो जाता है: यह कोई local incident नहीं है। यह एक wildfire है।

जिस नाम ने इतिहास में जगह बनाई, वह है NotPetya। आज भी यह इस बात का बेहतरीन उदाहरण है कि कैसे एक “साधारण malware wave” जैसा दिखने वाला हमला दुनिया भर की कंपनियों को रोक सकता है और नुकसान को अरबों तक पहुंचा सकता है।

इस पोस्ट में मैं दो चीजें जोड़ना चाहता हूं:

1. NotPetya की कहानी: तब क्या हुआ और यह इतना महंगा क्यों पड़ा?
2. Practical perspective: आज “नॉर्मल” कंपनियों के लिए इसका क्या मतलब है — सिर्फ Fortune 500 के लिए नहीं?

NotPetya की uncomfortable बात यह नहीं है कि यह “बहुत complex” था। Uncomfortable बात यह है: यह डरावनी तरह से realistic है।

मैं यह 2026 में क्यों लिख रहा हूं? क्योंकि आज हम AI‑driven deepfake phishing की बातें करते हैं, लेकिन crisis में हम अब भी 2017 जैसी ही basic बातों पर फेल होते हैं: segmentation की कमी और ऐसे backups जो production के साथ उसी “lifeline” पर लटके होते हैं।

5 मिनट में NotPetya: क्या हुआ?

Context सेट करने के लिए हमें घटनाओं को क्रम में रखना होगा।

27 जून 2017 को NotPetya पहले यूक्रेन में दिखा और फिर बहुत तेजी से global फैल गया। इसमें एक compromised update का बड़ा रोल था — यूक्रेन में widely used accounting software (M.E.Doc) का। यानी यह “एक बेवकूफ click” से नहीं आया, बल्कि ऐसे mechanism से आया जिसे कंपनियां रोज इस्तेमाल करती हैं: updates।

और यह वह चीज है जिसे लोग hindsight में अक्सर underestimate करते हैं: यह core में एक Supply Chain Attack था। M.E.Doc random target नहीं था; updates पर organizations by design भरोसा करती हैं, इसलिए यह perfect lever था।

आज के लिए lesson uncomfortable है, लेकिन जरूरी है: आप internal IT को जितना भी “perfect” कर लें, अगर आपके accountant/vendor/ERP connector या किसी third‑party tool की supply chain corrupt हो गई, तो आप फिर भी प्रभावित होंगे। Supply chain risk कोई “cloud वाला” मुद्दा नहीं है — यह बहुत सीधे updates का मुद्दा है।

एक बार NotPetya नेटवर्क में आ गया, तो यह single endpoints की बात नहीं रहती, बल्कि Lateral Movement की बात बन जाती है:

• SMB और known vulnerabilities (जिसमें EternalBlue / MS17-010 भी शामिल है — NSA toolset से leaked exploit) के जरिए NotPetya बिना user interaction के दूसरे Windows systems तक फैल सकता था।
• साथ ही, उसने credential dumping (Mimikatz/LSASS) का इस्तेमाल करके RAM से passwords/hashes निकाले और real admin credentials के साथ आगे बढ़ा।
• Remote execution के लिए उसने “normal” admin tools (जैसे PsExec/WMI) इस्तेमाल किए। यह combo खतरनाक है, क्योंकि शुरुआती logs में यह “business as usual” जैसा लग सकता है।

यही “secret recipe” था: exploit से तेजी से नए systems तक पहुंचना, memory से credentials लेकर असली privileges पाना, और फिर built‑in tools से scale करना।

Important: सिर्फ patching यहां पर्याप्त नहीं था। यदि कोई सिस्टम EternalBlue के खिलाफ patched भी था, तब भी वह गिर सकता था अगर malware ने network में कहीं से valid admin credentials/hashes हासिल कर लिए हों।

NotPetya ने time factor भी इस्तेमाल किया: इसमें delay था और “big bang” (reboot/wipe) तुरंत नहीं होता था, बल्कि कुछ समय बाद force होता था। यह detection के लिए nasty है — और sandboxes के खिलाफ भी classic, क्योंकि malware तुरंत “detonate” नहीं करता जबकि background में फैल चुका होता है।

Result वही है जो ऐसे incidents में हमेशा दिखता है:

• पहले कुछ systems “अजीब” लगते हैं।
• फिर अचानक पूरा एक site down हो जाता है।
• और अगर आप बहुत जल्दी react नहीं करते (network cut, accounts lock, segment boundaries बंद), तो यह multi‑site बन सकता है।

“Ransomware” सिर्फ camouflage क्यों था

NotPetya को कई जगह ransomware समझा गया क्योंकि उसने ransom note दिखाया। लेकिन technically और practically यह कुछ और था।

Key point: NotPetya असल में wiper था। इसका goal “पैसा कमाना” नहीं, बल्कि systems को destroy करना और operations को रोकना था।

यह बात semantics लग सकती है, लेकिन incident में इससे बहुत फर्क पड़ता है:

• Classic ransomware में (कभी‑कभी) keys या negotiation से data वापस आने की संभावना होती है।
• Wiper में goal “तोड़ना” होता है। Bitcoin भेजना मदद नहीं करता।

NotPetya में एक technical detail इसे और स्पष्ट करती है: इसने MBR (Master Boot Record) overwrite किया और MFT (Master File Table) encrypt की। और “ransomware” का हिस्सा भी गलत implement हुआ था: दिखने वाली installation ID random थी और usable decryption key से सही तरह linked नहीं थी। यानी technically वापसी का रास्ता लगभग नहीं था।

इसीलिए NotPetya इतना pernicious था: इसने शुरुआत में बहुत‑सी कंपनियों को गलत playbook पर धकेल दिया। आप “ransomware playbook” सोचते हैं, जबकि आपको “disaster recovery playbook” चाहिए होता है।

यह भी उसी तस्वीर में फिट होता है कि कई सरकारों ने बाद में NotPetya को publicly रूसी state actors से जोड़ा।

10 बिलियन डॉलर: इतना महंगा क्यों पड़ा?

अगर आप सिर्फ “ransomware” label देखें, तो नुकसान समझना मुश्किल लगता है: “backup से restore कर लो, बस।”

Reality में NotPetya इतना महंगा इसलिए पड़ा क्योंकि उसने एक ऐसे हिस्से पर चोट की जिसे budget discussions में अक्सर underestimate किया जाता है: availability।

सबसे बड़ा cost malware नहीं था, बल्कि downtime था:

• Production lines रुक जाती हैं।
• Logistics कागज पर वापस चली जाती है।
• Identities और domains दोबारा बनते हैं।
• Apps, integrations और dependencies cascade में गिरती हैं।
• और यह सब एक साथ कई systems में होता है।

इसीलिए NotPetya को अक्सर “सबसे महंगा साइबर हमला” कहा जाता है। कई reports total damage को करीब 10 बिलियन US डॉलर के आसपास बताती हैं।

Company-level numbers भी यही कहानी दिखाते हैं: Merck, FedEx (TNT Express सहित), और Mondelez ने बताया कि यह सिर्फ IT issue नहीं था, बल्कि revenue/costs/delivery capability पर direct business impact था।

NotPetya के बाद एक बड़ा legal angle भी आया: कंपनियों और insurers के बीच विवाद। कुछ insurers ने भुगतान से बचने के लिए इसे “Act of War” (यानी state-directed attack) कहा। Mondelez का dispute खास तौर पर चर्चा में रहा। Lesson learned आज भी यही है: क्या आपकी cyber insurance state-backed attacks को cover करती है, या war exclusion लागू हो जाएगी?

Pro-readers के लिए अपडेट: Mondelez वाला केस 2023 में settle हुआ। इसके बाद (और overall NotPetya के बाद) कई policies में language काफ़ी tight हो गई: “state-motivated” attacks को अब कई जगह narrow define किया जाता है या explicitly exclude किया जाता है। मतलब: अगर clauses समझ में नहीं हैं, तो cyber insurance अपने आप में एक बड़ा financial risk बन जाती है।

और एक और बात: आप “सिर्फ IT restore” कर रहे हों, तब भी dependencies आपको रोकती हैं।

Maersk का example अक्सर दिया जाता है: यह कुछ files की बात नहीं थी, बल्कि core systems, identities और operational IT को rebuild करना था ताकि ports और logistics फिर से चल सकें।

इसके पीछे एक legendary story भी है: Maersk ने practically पूरा global Active Directory खो दिया — बस Ghana में एक Domain Controller बचा रहा जो power outage की वजह से attack के वक्त offline था। यह “Lucky Punch” accidental offline backup बन गया: उसी एक physical server से वे global AD reconstruct कर पाए और recovery तेज हुई।

अंत में असर सिर्फ “IT” पर नहीं, सीधे business पर पड़ता है:

• Food में: production, planning और supply chain ठप।
• Shipping में: containers अटक जाते हैं।
• Pharma में: manufacturing, quality processes और delivery capability दबाव में।

इसीलिए यह इतना महंगा है: ransom screen सिर्फ symptom है। असली नुकसान downtime है।

Practical scenario: “नॉर्मल” कंपनी में यह कैसे दिखेगा

मैं जानबूझकर एक ऐसा scenario लिख रहा हूं जो Hollywood जैसा न लगे। “State actor vs big tech” नहीं, बल्कि mid-sized companies के लिए plausible।

कल्पना कीजिए एक मध्यम आकार की कंपनी:

• एक मुख्य site, एक छोटा दूसरा site।
• Classic Windows setup: AD, file server, कुछ VMs, ERP।
• और कुछ systems जिन्हें छुआ नहीं जाता: machine controllers, legacy software, “Windows Server 2008 कुछ”।
• Backups: daily NAS पर, weekly एक दूसरे system पर भी।

और फिर वह point आता है जिसे लोग underestimate करते हैं:

यह कंपनी “कम security” इसलिए नहीं रखती क्योंकि लोग incompetent हैं। बल्कि इसलिए कि operations और time हमेशा जीतते हैं।

Patching टलती है क्योंकि production tight है। Segmentation “बाद में” क्योंकि VLANs work हैं। Local admin passwords historical हैं। और NAS online है क्योंकि वरना restore बहुत असुविधाजनक है।

Timeline (realistic, not dramatic)

मंगलवार सुबह एक update आता है। Supplier, service-provider tool, connector — कुछ भी जो auto-update करता है। या VPN के जरिए किसी partner का compromised system।

• 08:10: first clients unstable।
• 08:25: first file server slow, helpdesk tickets बढ़ते हैं।
• 08:40: “domain weird” — login slow, GPO issues।
• 09:00: admin “जल्दी देखने” के लिए login करता है — अक्सर यहीं lateral movement तेज होता है।
• 09:20: पूरा site practically offline।

और फिर वह हिस्सा आता है जो बाद में समझ आता है:

अगर उस पल आप hard cut नहीं करते, तो नुकसान linear नहीं, exponential होता है।

और फिर वही सवाल आता है:

“क्या हमें pay करना चाहिए?”

NotPetya में bitter truth यह था: pay करने से भी शायद कुछ नहीं होता। आपको mentally तुरंत “rebuild” पर जाना पड़ता है, “decrypt” पर नहीं।

जितना देर करेंगे, उतने systems दोबारा बनाने पड़ेंगे। जितने systems, उतना ज्यादा emergency mode। और जितना ज्यादा emergency mode, उतना ज्यादा खर्च।

असल में दर्द कहां होता है

कुछ घंटों में साफ हो जाता है: यह “कुछ files restore” नहीं है। यह “Active Directory और core systems rebuild” है।

और फिर पता चलता है:

• Backups online थे और hit हो गए।
• Documentation up to date नहीं।
• Fast reimage के लिए “golden images” कम।
• Admin credentials हर जगह।
• किसी ने 30 मिनट में site segment करने की drill नहीं की।

यहीं IT incident एक company crisis बन जाता है।

आज SOC क्या अलग करता है (और AI का रोल क्या है)

एक बड़े SOC में रोज़ बहुत‑से sources से अरबों events आते हैं। यह “admin firewall log देख रहा है” नहीं, बल्कि sensors, correlation, automation और human analysis का industrial process है।

Role split आमतौर पर ऐसा होता है:

• AI/automation first line: sort, correlate, patterns detect, obvious चीजें filter।
• Humans second/third line: critical या unclear मामलों में analysts decisions लेते हैं और response coordinate करते हैं।

यह “sirf enterprise” जैसा लग सकता है, लेकिन सीख छोटी कंपनियों के लिए भी है:

आपको खुद SOC नहीं बनाना। पर mindset वही चाहिए:

• Signals collect करें (EDR, firewall, auth logs)।
• “Normal” define करें।
• और ऐसा process रखें जो minutes में react करे, days में नहीं।

NotPetya 2017 में ही इतना fast था कि एक बार spread चल पड़ा तो इंसान “जल्दी enough” react नहीं कर सकता था। AI का फायदा “और तेज” नहीं, बल्कि noise में anomaly जल्दी पकड़ना है (जैसे रात 03:00 पर अचानक 500 machines SMB पर एक‑दूसरे से बात करना चाहें)। वही minutes decide करते हैं: जल्दी देखना, जल्दी contain करना, जल्दी isolate करना।

और फिर एक mindset है जो अब default बन रहा है:

Assume breach.

यानी plan ऐसे करें जैसे attacker पहले से अंदर है। यह paranoia नहीं, pragmatism है।

आज minimum क्या होना चाहिए (बिना enterprise-budget के)

अगर NotPetya से एक चीज लेनी हो तो यह:

NotPetya “एक vulnerability” नहीं था। यह weaknesses की chain थी जो एक‑दूसरे को amplify करती थीं।

अच्छी खबर: यही वजह है कि कुछ basics से risk बहुत कम हो सकता है।

1) Patch और exposure management (seriously)

• Critical Windows updates (खासकर SMB) “कभी” नहीं चलतीं।
• जो भी बाहर से reachable है, priority।
• Legacy चाहिए तो कम से कम segmented, clear rules के साथ।

2) Lateral Movement को painful बनाएं

• Admin accounts अलग (daily vs admin)।
• Per-device unique local admin passwords (LAPS)।
• WMI/PsExec को हर जगह खुला न छोड़ें।
• SMB सीमित करें जहाँ जरूरी नहीं।

3) Segmentation, but pragmatic

आपको कल से “perfect Zero Trust” नहीं चाहिए। लेकिन:

• Clients, servers, backups, OT/production को flat network में न रखें।
• Domain Controllers tier 0 हैं।
• East‑west traffic पर भी उतनी ही नजर जितनी internet traffic पर।

4) Backups: offline, immutable, tested

मैं वही कहूंगा जो projects में बार‑बार दिखता है:

जो backup हमेशा writable और हमेशा online हो, वह incident में अक्सर backup नहीं रहता।

• 3-2-1 अच्छा start है।
• Immutable storage (या offline media) game changer है।
• Restore tests जरूरी हैं।

5) Incident runbooks और sites के लिए “kill switch”

80 पेज का handbook नहीं चाहिए। पर clarity चाहिए:

• Site cut करने का फैसला कौन करेगा?
• Accounts जल्दी lock कैसे होंगे?
• कौन‑से systems पहले वापस आएं (AD, DNS, DHCP, VPN, ERP)?

और हां: इसे practice करना होगा।

Reality-check: NotPetya में कई बार सबसे effective कदम “एक और tool” नहीं था, बल्कि physically cut करना था। Maersk के बारे में reports हैं कि लोग offices में दौड़कर switches से power/network cables निकाल रहे थे ताकि spread रुके। सुनने में basic है, मगर seconds में decision हो तो यही best “high-tech” बन जाता है।

निष्कर्ष

मेरे लिए NotPetya आज भी सबसे अच्छे examples में से एक है कि security “हमारे पास antivirus है” पर खत्म नहीं होती।

यह इसलिए devastating नहीं था कि यह magical था। बल्कि इसलिए कि यह बहुत normal weak points पर लगा:

• updates पर भरोसा
• lateral movement बहुत आसान
• segmentation कम
• backups production network के बहुत पास

और इसी वजह से यह “नॉर्मल” कंपनियों के लिए भी relevant है।

अगर आप आज निवेश करें, तो tools के साथ resilience में निवेश करें: visibility, fast response, और clean restore की क्षमता। यह फर्क है “एक बहुत बुरा दिन” और “एक ऐसा quarter जिसे आप कभी recover नहीं कर पाएंगे” के बीच।

Sources और आगे पढ़ें

• CISA: Petya Ransomware (incl. NotPetya) (TA17-181A)
• U.S. DHS Blog (Archive): The NotPetya Ransomware Attack
• WIRED: The Untold Story of NotPetya, the Most Devastating Cyberattack in History
• UK Government: Foreign Office Minister condemns Russian govt cyber attack (NotPetya)
• U.S. DOJ: Six Russian intelligence officers charged (GRU) incl. NotPetya
• Merck: Form 10-K (2017) (SEC EDGAR)
• FedEx: Quarterly results (2017) mentioning TNT/NotPetya impacts
• Mondelez International: 2017 Fourth Quarter and Full Year Results (NotPetya impact)

अगली बार तक जो