NotPetya: ইতিহাসের সবচেয়ে ব্যয়বহুল সাইবার আক্রমণ

জুন 2017-এর শেষদিকে ইউক্রেনে এমন কিছু শুরু হয়, যা প্রথম দেখায় “চিরচেনা ransomware” মনে হয়: মেশিন রিবুট হয়, ফাইল হঠাৎ অপ্রাপ্য হয়ে যায়, আর স্ক্রিনে মুক্তিপণের দাবি দেখায়।

কয়েক ঘণ্টার মধ্যেই পরিষ্কার হয়ে যায়: এটা কোনো লোকাল ইনসিডেন্ট নয়। এটা একটা আগুনের মতো ছড়িয়ে পড়া ঘটনা।

যে নামটা আজও মনে থাকে, সেটা হলো NotPetya। এটি এখনো দেখায় কীভাবে দেখতে “সাধারণ malware wave” হলেও তা বিশ্বজুড়ে কোম্পানিগুলোকে থামিয়ে দিতে পারে এবং ক্ষতিকে বিলিয়ন‑ডলারে নিয়ে যেতে পারে।

এই পোস্টে আমি দুইটা বিষয় যুক্ত করতে চাই:

1. NotPetya-এর স্টোরি: তখন কী ঘটেছিল এবং কেন এটা এত ব্যয়বহুল হলো?
2. প্র্যাক্টিক্যাল পার্সপেক্টিভ: আজ “নরমাল” কোম্পানির জন্য এর মানে কী—শুধু Fortune 500 নয়?

NotPetya-এর অস্বস্তিকর দিকটা এই নয় যে এটা “খুব কমপ্লেক্স” ছিল। অস্বস্তিকর দিকটা হলো: এটা ভয়ংকরভাবে বাস্তবসম্মত।

আমি 2026 সালে এটা কেন লিখছি? কারণ আজ আমরা AI‑চালিত deepfake phishing নিয়ে কথা বলি, কিন্তু বাস্তব সংকটে আমরা এখনও 2017‑এর মতোই বেসিক জায়গায় ব্যর্থ হই: segmentation নেই এবং backups প্রোডাকশনের সাথে একই “লাইফলাইন”-এ ঝুলে থাকে।

৫ মিনিটে NotPetya: কী হয়েছিল?

কনটেক্সট বোঝার জন্য ঘটনাগুলো সাজাতে হবে।

27 জুন 2017‑তে NotPetya প্রথমে ইউক্রেনে দেখা যায় এবং খুব দ্রুত গ্লোবালি ছড়িয়ে পড়ে। এখানে বড় ভূমিকা ছিল ইউক্রেনে বহুল ব্যবহৃত একটি অ্যাকাউন্টিং সফটওয়্যার (M.E.Doc)‑এর compromised update। অর্থাৎ এটা “একটা বোকা ক্লিক” দিয়ে আসেনি, বরং এমন এক মেকানিজম দিয়ে এসেছে যা কোম্পানিগুলো প্রতিদিন ব্যবহার করে: updates।

আর এটা অনেকেই hindsight‑এ underestimate করে: এটা মূলত একটি Supply Chain Attack। M.E.Doc কোনো র‌্যান্ডম টার্গেট ছিল না; updates সাধারণত বাই‑ডিজাইন ট্রাস্টেড, তাই এটি পারফেক্ট লিভার ছিল।

আজকের জন্য লেসনটা অস্বস্তিকর হলেও জরুরি: আপনি ইনটার্নাল IT যত ভালোই ম্যানেজ করুন, যদি আপনার অ্যাকাউন্ট্যান্ট/vendor/ERP connector বা কোনো third‑party tool‑এর supply chain করাপ্ট হয়, তবুও আপনি আক্রান্ত হবেন। supply chain risk কোনো “cloud‑এর সমস্যা” নয়; এটা খুব সরাসরি update‑এর সমস্যা।

একবার NotPetya নেটওয়ার্কে ঢুকলে বিষয়টা আর একেকটা endpoint নয়, বরং Lateral Movement:

• SMB এবং পরিচিত দুর্বলতার (যার মধ্যে EternalBlue / MS17-010 আছে—NSA toolset থেকে লিক হওয়া exploit) মাধ্যমে NotPetya user interaction ছাড়াই অন্য Windows সিস্টেমে ছড়িয়ে যেতে পারত।
• একই সাথে credential dumping (Mimikatz/LSASS) ব্যবহার করে RAM থেকে passwords/hashes তুলে নিয়ে real admin credentials দিয়ে এগোত।
• Remote execution‑এর জন্য “নরমাল” admin tools (যেমন PsExec/WMI) ব্যবহার করা হতো। এই মিক্সটা বিপজ্জনক কারণ শুরুতে logs‑এ এটা “স্বাভাবিক অপারেশন” মনে হতে পারে।

এটাই ছিল “secret recipe”: exploit দিয়ে দ্রুত নতুন সিস্টেমে যাওয়া, মেমরি থেকে credentials নিয়ে আসল privileges পাওয়া, তারপর built‑in tools দিয়ে scale করা।

গুরুত্বপূর্ণ: শুধু patching যথেষ্ট ছিল না। কোনো সিস্টেম EternalBlue‑এর বিরুদ্ধে patched থাকলেও তা পড়ে যেতে পারত যদি malware নেটওয়ার্কের কোথাও থেকে valid admin credentials/hashes পেয়ে যায়।

NotPetya সময়ের সাথে খেলেছে: এতে delay ছিল এবং “বড় ধাক্কা” (reboot/wipe) সাথে সাথে না হয়ে কিছু সময় পরে forced হতো। এটা detection‑কে কঠিন করে—এবং sandboxing‑এর বিরুদ্ধেও ক্লাসিক, কারণ malware সঙ্গে সঙ্গে “detonate” না করেও ব্যাকগ্রাউন্ডে ছড়িয়ে পড়ে।

ফলাফলটা সেই চেনা প্যাটার্ন:

• প্রথমে কিছু সিস্টেম “অদ্ভুত” লাগে।
• তারপর হঠাৎ করে পুরো একটা সাইট পড়ে যায়।
• আর আপনি যদি খুব দ্রুত react না করেন (নেটওয়ার্ক কাট, accounts lock, segment boundaries বন্ধ), তাহলে এটা multi‑site হয়ে যায়।

“Ransomware” কেন শুধু ক্যামোফ্লাজ ছিল

NotPetya‑কে অনেক জায়গায় ransomware মনে হয়েছিল কারণ এটা ransom note দেখাত। কিন্তু টেকনিক্যালি ও প্র্যাক্টিক্যালি এটা অন্য কিছু।

কী পয়েন্ট: NotPetya বাস্তবে ছিল wiper। উদ্দেশ্য “পয়সা কামানো” নয়, বরং সিস্টেম নষ্ট করা এবং অপারেশন থামানো।

এটা শব্দের খেলা মনে হতে পারে, কিন্তু incident‑এ পার্থক্য বিশাল:

• ক্লাসিক ransomware‑এ (কখনও কখনও) keys বা negotiation দিয়ে ফিরে আসার সুযোগ থাকে।
• wiper‑এ লক্ষ্য “ধ্বংস”। Bitcoin পাঠালেও কাজ হবে না।

NotPetya‑তে একটি টেকনিক্যাল ডিটেইল এটাকে আরও স্পষ্ট করে: এটি MBR (Master Boot Record) overwrite করত এবং MFT (Master File Table) encrypt করত। উপরন্তু “ransomware” অংশের ইমপ্লিমেন্টেশনও ত্রুটিপূর্ণ ছিল: দেখানো installation ID র‌্যান্ডম ছিল এবং usable decryption key‑এর সাথে ঠিকমতো link ছিল না। অর্থাৎ টেকনিক্যালি ফিরে আসার পথ প্রায় ছিল না।

এটাই NotPetya‑কে এত ভয়ংকর করেছে: শুরুতে অনেক কোম্পানি ভুল playbook ধরেছিল। আপনি ভাববেন “ransomware playbook”, কিন্তু আপনার দরকার “disaster recovery playbook”।

এটা পরবর্তী attribution‑এর সাথেও মেলে: একাধিক সরকার NotPetya‑কে রাশিয়ান state actors‑এর সাথে যুক্ত করেছে।

১০ বিলিয়ন ডলার: এত ব্যয়বহুল কেন?

আপনি যদি শুধু “ransomware” লেবেল দেখেন, ক্ষতি বোঝা কঠিন: “backup থেকে restore করে দিলেই তো হয়”।

রিয়েল ওয়ার্ল্ডে NotPetya এত ব্যয়বহুল হয়েছিল কারণ এটি এমন জায়গায় আঘাত করেছিল যেটা বাজেট আলোচনায় প্রায়ই অবহেলিত: availability।

সবচেয়ে বড় খরচ malware নয়, downtime:

• প্রোডাকশন লাইন থেমে যায়।
• লজিস্টিকস কাগজে ফিরে যায়।
• identities ও domains নতুন করে বানাতে হয়।
• apps, integrations ও dependencies একের পর এক পড়ে যায়।
• আর এগুলো অনেক সিস্টেমে একসাথে ঘটে।

এ কারণেই NotPetya‑কে অনেক সময় “সবচেয়ে ব্যয়বহুল সাইবার আক্রমণ” বলা হয় এবং মোট ক্ষতি প্রায় ১০ বিলিয়ন US ডলার বলা হয়।

কোম্পানির ফাইলিংস‑এও এটা দেখা যায়: Merck, FedEx (TNT Express সহ) এবং Mondelez বলেছিল এটা শুধু IT ইস্যু নয়, বরং revenue, cost এবং delivery capability‑এর ওপর সরাসরি business impact।

NotPetya‑র পরে বড় একটি legal aftermathও ছিল: কোম্পানি বনাম ইনসুরেন্স। কিছু ইনসুরার পেমেন্ট এড়াতে এটাকে “Act of War” (state‑directed attack) হিসেবে ব্যাখ্যা করেছিল। Mondelez‑এর কেস বিশেষভাবে পরিচিত। আজও লেসন একই: আপনার cyber insurance কি রাষ্ট্রীয় আক্রমণ কভার করে, নাকি war exclusion কাজ করবে?

Pro‑readers‑দের জন্য আপডেট: Mondelez কেস 2023‑এ ফাইনাল হয়। এরপর (এবং সামগ্রিকভাবে NotPetya‑র পর) অনেক policy‑র ভাষা কঠোর হয়েছে: “state‑motivated” আক্রমণগুলো এখন অনেক জায়গায় আরও সংকীর্ণভাবে define করা হয় বা explicitly exclude করা হয়। ফলে clauses না বুঝলে cyber insurance নিজেই একটা বড় financial risk হয়ে দাঁড়ায়।

আরেকটা জিনিস: আপনি “শুধু IT restore” করলেও বাস্তবে dependencies নিয়ে যুদ্ধ করতে হয়।

Maersk‑এর উদাহরণ এখানে খুব শক্তিশালী: এটি কয়েকটা ফাইল এনক্রিপ্ট হওয়ার বিষয় ছিল না, বরং core systems, identities এবং operational IT নতুন করে দাঁড় করানো—যাতে ports ও logistics আবার চলতে পারে।

এর পেছনে একটি কিংবদন্তি স্টোরিও আছে: Maersk প্রায় পুরো global Active Directory হারিয়েছিল—শুধু Ghana‑তে একটি Domain Controller বেঁচে গিয়েছিল, কারণ বিদ্যুৎ চলে যাওয়ায় আক্রমণের সময় সেটি offline ছিল। এই “Lucky Punch” এক ধরনের accidental offline backup হয়ে যায়: ওই এক physical server দিয়েই তারা global AD reconstruct করতে পেরেছিল।

শেষ পর্যন্ত আঘাতটা শুধু “IT” নয়, business‑এ সরাসরি:

• Food কোম্পানিতে: production, planning ও supply chain থেমে যায়।
• Shipping‑এ: containers আটকে থাকে।
• Pharma‑তে: manufacturing, quality processes ও delivery capability চাপের মধ্যে পড়ে।

এ কারণেই সংখ্যাটা এত বড়: ransom screen শুধু symptom। আসল ক্ষতি downtime।

Practical scenario: “নরমাল” কোম্পানিতে এটা কেমন দেখাবে?

আমি ইচ্ছা করে Hollywood‑like নয় এমন একটা scenario লিখছি। “State actor vs big tech” নয়, বরং mid‑sized কোম্পানির জন্য plausible।

ধরে নিন একটি মাঝারি কোম্পানি:

• একটি main site, একটি ছোট second site।
• Classic Windows setup: AD, file server, কিছু VMs, ERP।
• কিছু সিস্টেম যেগুলো কেউ ছুঁতে চায় না: machine controllers, পুরনো স্পেশাল সফটওয়্যার, “Windows Server 2008 কিছু”।
• Backups: প্রতিদিন NAS‑এ, সপ্তাহে একবার আরও একটা সিস্টেমে।

এবং এখানেই সেই point:

এই কোম্পানি “কম সিকিউরিটি” রাখে বলে সবাই অদক্ষ নয়। বরং operations আর time সবসময় জিতে যায়।

Patching পিছিয়ে যায় কারণ প্রোডাকশন টাইট। Segmentation “পরে” কারণ VLANs কাজ। Local admin passwords ঐতিহাসিকভাবে গড়ে ওঠে। NAS অনলাইনই থাকে কারণ না হলে restore ঝামেলা।

Timeline (realistic)

মঙ্গলবার সকালে একটি update আসে। Supplier, service-provider tool, connector—যে কোনো auto‑update হওয়া জিনিস। অথবা VPN‑অ্যাক্সেস থাকা কোনো partner‑এর compromised সিস্টেম।

• 08:10: প্রথম ক্লায়েন্টগুলো unstable।
• 08:25: প্রথম file server slow, helpdesk tickets বাড়ে।
• 08:40: “domain weird”—login slow, GPO সমস্যা।
• 09:00: admin “দ্রুত দেখে” login করে—অনেক সময় এখানেই lateral movement গতি পায়।
• 09:20: একটি পুরো site কার্যত offline।

আর এটা পরে বোঝা যায়:

আপনি তখন hard cut না করলে ক্ষতি linear নয়, exponential।

তারপর আসে সেই প্রশ্ন:

“পেমেন্ট করব?”

NotPetya‑তে bitter truth ছিল: পেমেন্ট করলেও সম্ভবত কাজ হতো না। মানসিকভাবে আপনাকে সাথে সাথে “rebuild” মোডে যেতে হয়, “decrypt” নয়।

যত দেরি করবেন, তত বেশি সিস্টেম rebuild। যত বেশি সিস্টেম, তত বেশি সময় emergency mode। আর যত বেশি সময় emergency mode, তত বেশি খরচ।

আসল ব্যথা

কয়েক ঘণ্টার মধ্যে পরিষ্কার: এটা “কিছু ফাইল restore” নয়। এটা “Active Directory ও core systems rebuild”।

তারপর বোঝা যায়:

• Backups অনলাইন ছিল এবং আক্রান্ত হয়েছে।
• ডকুমেন্টেশন আপ‑টু‑ডেট নয়।
• দ্রুত reimage‑এর জন্য “golden images” কম।
• Admin credentials সর্বত্র।
• 30 মিনিটে site segment করার drill করা হয়নি।

এখানেই IT incident কোম্পানি‑ক্রাইসিস হয়ে যায়।

আজ SOC কী আলাদা করে (এবং AI এখানে কোথায় কাজে লাগে)

বড় SOC‑এ প্রতিদিন অনেক সোর্স থেকে বিলিয়ন‑পর্যায়ের ইভেন্ট আসে। এটা “একজন admin firewall log দেখছে” নয়; এটি সেন্সর, correlation, automation ও human analysis‑এর industrial process।

রোল ডিভিশন সাধারণত:

• AI/automation first line: sort, correlate, pattern detect, obvious ফিল্টার।
• Humans second/third line: critical/unclear হলে analysts সিদ্ধান্ত নেয় এবং response coordinate করে।

এটা “শুধু বড় কোম্পানি” মনে হতে পারে, কিন্তু learning ছোটদের জন্যও:

আপনাকে নিজে SOC বানাতে হবে না। কিন্তু mindset একই:

• Signals সংগ্রহ করুন (EDR, firewall, auth logs)।
• “Normal” define করুন।
• Minutes‑এ react করার process রাখুন।

NotPetya 2017‑এ এমনিতেই এত দ্রুত ছিল যে spread শুরু হলে মানুষ “দ্রুত enough” react করতে পারত না। AI‑এর আসল কাজ “আরও দ্রুত” নয়, বরং noise‑এর মধ্যে anomaly আগেই ধরা (যেমন রাত 03:00‑তে হঠাৎ 500 মেশিন SMB‑এ কথা বলতে চাইছে)। ওই মিনিটগুলোই নির্ধারণ করে: আগে দেখা, আগে সীমাবদ্ধ করা, আগে isolate করা।

এবং একটি mindset আছে যা এখন ডিফল্ট হচ্ছে:

Assume breach.

অর্থাৎ ধরে নিন attacker ইতিমধ্যেই ভেতরে। Paranoia নয়, pragmatism।

আজ কমপক্ষে যা থাকা উচিত (enterprise budget ছাড়াই)

NotPetya থেকে একটি জিনিস নিতে হলে:

NotPetya “একটা vulnerability” নয়। এটা weaknesses‑এর chain যা একে অপরকে amplify করেছে।

ভালো খবর: কিছু basics‑এ অনেক risk কমে।

1) Patch ও exposure management (সিরিয়াসলি)

• Critical Windows updates (বিশেষ করে SMB) “কখনো” নয়।
• বাইরে থেকে reachable জিনিসগুলো priority।
• Legacy দরকার হলে অন্তত segmented ও clear rules।

2) Lateral Movement কঠিন করুন

• Admin accounts আলাদা (daily vs admin)।
• Per-device unique local admin passwords (LAPS)।
• WMI/PsExec সব জায়গায় খোলা নয়।
• SMB সীমিত করুন যেখানে দরকার নেই।

3) Segmentation, কিন্তু pragmatic

কাল থেকেই “perfect Zero Trust” দরকার নেই। কিন্তু:

• clients, servers, backups, OT/production ফ্ল্যাট নেটওয়ার্কে নয়।
• Domain Controllers tier 0।
• east‑west 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 এবং sites‑এর জন্য “kill switch”

80 পেজের handbook লাগবে না। কিন্তু clarity লাগবে:

• কে সিদ্ধান্ত নেবে site কাটবে?
• accounts দ্রুত lock হবে কীভাবে?
• কোন সিস্টেম আগে উঠবে (AD, DNS, DHCP, VPN, ERP)?

এবং এগুলো practise করতে হবে।

Reality-check: NotPetya‑তে অনেক সময় সবচেয়ে effective ছিল “আরেকটা টুল” নয়, বরং physical cut। Maersk‑এ এমন গল্প আছে যে লোকজন অফিসে দৌড়ে switches থেকে power/network cables খুলে দিয়েছিল যাতে ছড়ানো থামে। শুনতে সিম্পল, কিন্তু seconds matter করলে এটা-ই best “high‑tech” হয়ে যায়।

উপসংহার

NotPetya আজও দেখায় কেন security “antivirus আছে তো হলো” নয়।

এটা devastating ছিল না কারণ এটা magical ছিল। বরং কারণ এটা খুব সাধারণ দুর্বল জায়গায় আঘাত করেছিল:

• updates‑এর ওপর অতিরিক্ত ভরসা
• lateral movement সহজ
• segmentation কম
• backups প্রোড নেটওয়ার্কের খুব কাছে

এ কারণেই এটি “নরমাল” কোম্পানির জন্যও relevant।

আজ বিনিয়োগ করলে tools‑এ নয়, resilience‑এ বিনিয়োগ করুন: visibility, দ্রুত response, এবং clean restore করার সক্ষমতা। এটাই পার্থক্য “একটা খুব খারাপ দিন” আর “একটা quarter যা আর ফেরত পাবেন না”‑এর মধ্যে।

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)

পরবর্তীবার পর্যন্ত, Joe