VPN লগইনের পর র্যানসমওয়্যার: প্রমাণ কী সমর্থন করে
02:14-এ একটি লগইন এবং 03:02-এ এনক্রিপ্ট করা ফাইল — এটি তদন্তের যোগ্য একটি ক্রম, প্রবেশপথ নয়। প্রমাণীকরণ, সেশন ও হোস্টের প্রমাণ আলাদা রাখুন।
নিচের সবকিছু একটি অনুমানভিত্তিক রেকর্ড ব্যবহার করে, যা বাস্তব কোনো ঘটনা বর্ণনা করার বদলে একটি আকৃতি দেখানোর জন্য সাজানো। এটি একটি শৃঙ্খলের মতো পড়া যায়: 02:14-এ একটি গেটওয়ে প্রমাণীকরণ, 02:19-এ একটি ডেস্কটপ সেশন, 02:41-এ একটি বিশেষাধিকারপ্রাপ্ত অ্যাকাউন্ট পরিবর্তন, এবং 03:02-এ পাওয়া এনক্রিপ্ট করা ফাইল। প্রথম লাইনটি উত্তর বলে মনে হয়, আর প্রতিবেদনটি প্রায়ই এমনভাবে লেখা হয় যেন সেটিই উত্তর। একটি লগইন হলো গেটওয়ে যে ঘটনা রেকর্ড করেছে, কেউ কীভাবে ঢুকল তার সিদ্ধান্ত নয়, এবং এই পার্থক্যই ঠিক করে আপনি পরে কী করবেন।
লক্ষণ: একটি লগইন যা উত্তর বলে মনে হয়
প্রমাণীকরণের রেকর্ড হলো সবচেয়ে সহজে পাওয়া প্রমাণ এবং সবচেয়ে সহজে অতিরিক্ত ব্যাখ্যা করার প্রমাণ। এগুলো দেখায় যে সেবাটি একটি নির্দিষ্ট সময়ে, একটি নির্দিষ্ট ঠিকানা থেকে, একটি নির্দিষ্ট অ্যাকাউন্টের জন্য একটি পরিচয়পত্র গ্রহণ করেছে। এগুলো দেখায় না কে পরিচয়পত্রটি নিয়ন্ত্রণ করছিল, গেটওয়েটি শোষিত হয়েছিল কি না, বা অ্যাকাউন্ট মালিকের ডিভাইস আগেই ক্ষতিগ্রস্ত হয়েছিল কি না।
তিনটি ব্যাখ্যা একই লগইন লাইনে খাপ খায়। কেউ একটি চুরি করা পাসওয়ার্ড ব্যবহার করেছে, এবং গেটওয়ে ঠিক যা করার জন্য তৈরি তা-ই করেছে। আগে ক্ষতিগ্রস্ত একটি ল্যাপটপ স্বাভাবিকভাবেই লগইন করেছে। একটি অসম্পর্কিত উন্মুক্ত সেবা আসল প্রবেশপথ দিয়েছে, আর VPN সেশন হলো একই অভিনেতার পরবর্তী, আলাদা কাজ।
প্রতিটি ব্যাখ্যা পরিবেশের অন্য জায়গায় ভিন্ন প্রমাণ পূর্বাভাস দেয়, তাই তদন্তকে সেই পূর্বাভাসগুলো খুঁজতে হবে, যে প্রথম ব্যাখ্যাটি মিলে যায় তার নিশ্চিতকরণ নয়। চুরি করা পাসওয়ার্ড অস্বাভাবিক প্রমাণীকরণ ভূগোল বা সময়ের পূর্বাভাস দেয়। ক্ষতিগ্রস্ত ল্যাপটপ লগইনের আগে হোস্টের নিদর্শনের পূর্বাভাস দেয়। অসম্পর্কিত প্রবেশপথ গেটওয়ের সঙ্গে কোনো সম্পর্কহীন কার্যকলাপের পূর্বাভাস দেয়।
বর্ণনা করার আগে ঘটনাগুলো আলাদা রাখুন
কোনো বর্ণনা তৈরি হওয়ার আগেই ঘটনাগুলো আলাদাভাবে লিখে রাখুন, কারণ বর্ণনা সময়রেখাকে একজন সন্দেহভাজনের চারপাশে সাজানোর আমন্ত্রণ জানায়। প্রতিটি লাইন বলবে সেই রেকর্ডটি কী প্রতিষ্ঠা করে এবং আলাদাভাবে, একা কী প্রতিষ্ঠা করতে পারে না। যেই মুহূর্তে দুটি লাইন একটি বাক্যে মিলে যায়, তখনই একটি ব্যাখ্যা জিতে গেছে।
লক্ষ করুন, শেষ ঘটনাটি আক্রমণকারীর নয়, সনাক্তকরণের বিষয়ে। আবিষ্কারের সময় ও ক্ষতির সময় সাধারণত ঘণ্টা বা সপ্তাহের ব্যবধানে থাকে, আর যে প্রতিবেদন এদের সমান করে দেয় তা আপনার পরে আসা প্রত্যেক পাঠককে বিভ্রান্ত করবে।
প্রতিটি সময়চিহ্ন কোথা থেকে এসেছে তা লিখুন, শুধু কী বলে তা নয়। সংগ্রাহকের প্রাপ্তির সময়, ঘটনার সময় এবং সনাক্তকরণের সময় তিনটি আলাদা সংখ্যা, এবং এগুলোকে নীরবে এক কলামে স্বাভাবিক করাই হলো সময়রেখার এমন আকৃতি পাওয়ার উপায় যা প্রমাণের কখনোই ছিল না।
শনাক্তকারীরা মিলে গেলেই কেবল রেকর্ড একত্র করুন
রেকর্ড একত্র করা একটি অনুমান, বিন্যাসের ধাপ নয়। অ্যাকাউন্টের নাম, নির্ধারিত VPN ঠিকানা, লক্ষ্য হোস্ট এবং সেশন শনাক্তকারীকে অবশ্যই মিলতে হবে, তার আগে দুটি সারি এক গল্প হবে না। একটি সাধারণ পাবলিক ঠিকানা যথেষ্ট নয়, কারণ এটি নকশা অনুযায়ীই সাধারণ।
| Record source | Join key that must match | What breaks when the key is missing |
|---|---|---|
| File-share or backup record | file path and modification time | impact cannot be ordered against any session |
| Host process record, EDR or audit log | host name and process start time | the process cannot be placed inside a session |
| Session broker or remote-desktop log | session identifier and target host | the session cannot be traced back to a gateway login |
| Gateway authentication log | account name and assigned VPN address | the session cannot be followed past the gateway |
প্রবেশপথ অনুসরণ করার সময় টেবিলটি নিচ থেকে উপরে পড়ুন, আর প্রভাবের পরিধি নির্ধারণের সময় উপর থেকে নিচে, কারণ দুটি প্রশ্নের বিপরীত দিক দরকার। যেখানে শনাক্তকারীরা সত্যিই মেলে, তা বলুন এবং দুটি রেকর্ডই উদ্ধৃত করুন। যেখানে মেলে না, ফাঁকটি অনুমান দিয়ে বন্ধ না করে দৃশ্যমান রাখুন।
এখানেই পরিচিত ব্যবহারকারীনাম বিভ্রান্ত করে। একই অ্যাকাউন্ট সকালে ব্যবহার করতে পারেন বৈধ মালিক এবং রাতে অন্য কেউ, আর কেবল অ্যাকাউন্টের নাম তাদের আলাদা করতে পারে না। অ্যাকাউন্টকে আরোপ করুন, তারপর ব্যক্তিকে আলাদাভাবে আরোপ করুন, এবং কেবল যখন কিছু তা সমর্থন করে। পর্যালোচনায় ভেঙে পড়া বেশিরভাগ সময়রেখা ঠিক এই ধাপটি খুব দ্রুত করেছে।
অনুপস্থিত লগ একটি ফাঁক, নেতিবাচক প্রমাণ নয়
ব্যর্থ পাসওয়ার্ডের ঘটনা না থাকা প্রমাণ করে না যে সফল লগইনটি বৈধ ছিল। বৈধ চুরি করা পরিচয়পত্র একটি সফল প্রমাণীকরণ রেকর্ড তৈরি করে এবং একটিও ব্যর্থতা নয়, আর ঠিক এটাই পরিচয়পত্র চুরি-কে আকর্ষণীয় করে তোলে।
একইভাবে, আজ বন্ধ থাকা একটি পোর্ট আজকের বিষয়ে কিছু বলে। তখন সেই সেবাটি উন্মুক্ত ছিল কি না, তখন তা দুর্বল ছিল কি না, বা তা আক্রমণ বহন করেছিল কি না, সে সম্পর্কে এটি কিছুই বলে না। ঐতিহাসিক কনফিগারেশন ও সেবার প্রমাণই এই ফাঁক বন্ধ করার একমাত্র উপায়।
প্রতিবেদনে ফাঁকটি স্পষ্টভাবে উল্লেখ করুন। “সেই সময়ের জন্য আমাদের কোনো রেকর্ড নেই” একটি রক্ষণাযোগ্য বাক্য; “আর কিছু ঘটেনি” নয়, এবং তা আপনাকে উদ্ধৃত করে ফিরিয়ে দেওয়া হবে। ফাঁকেরও মালিক থাকে: যে সিস্টেমের রেকর্ডটি তৈরি করার কথা ছিল তার নাম বলুন এবং কেন করেনি। সেই লাইনই একটি বাদকে সংশোধনের কাজে পরিণত করে।
প্রমাণ যে স্তর সমর্থন করে সেই স্তরেই ফলাফল লিখুন
সংরক্ষণ, নিয়ন্ত্রণ ও পুনরুদ্ধারকে ঘটনার মালিকের মাধ্যমে সমন্বয় করুন, তার পাশ কাটিয়ে নয়। CISA-র কারিগরি নির্দেশনা পুনরুদ্ধার যা কিছু পাওয়া যাবে তা বদলে দেওয়ার আগেই প্রাসঙ্গিক নিদর্শন ও লগ সংগ্রহ করার উপর জোর দেয়, এবং এই ক্রমটি যেকোনো একক সরঞ্জামের চেয়ে বেশি গুরুত্বপূর্ণ।
ফাঁক বন্ধ করতে লাইভ সরঞ্জামে সন্দেহভাজন শোষণ আবার চালানো যে ঝুঁকি যোগ করে তার মূল্য নয়। যে পরীক্ষা দেখায় আক্রমণ কাজ করতে পারত, তা প্রমাণ নয় যে কাজ করেছিল, আর এই দুটি বাক্যের পার্থক্যই এই অনুশীলনের সম্পূর্ণ শৃঙ্খলা।
চারটি তালিকা দিয়ে শেষ করুন: কী পর্যবেক্ষণ করা হয়েছে, রেকর্ডগুলো কোন সম্পর্ক সমর্থন করে, কী অনুমান হিসেবে থাকে, এবং কোন রেকর্ড পাওয়া যায় না। “ঘটনার সময় একটি VPN অ্যাকাউন্ট ব্যবহার করা হয়েছিল” দ্বিতীয় তালিকায় পড়ে, যখন রেকর্ডগুলো তা সমর্থন করে। “VPN-ই র্যানসমওয়্যার ঘটিয়েছে” কোথাও পড়ে না, যতক্ষণ না কিছু কার্যকারণ প্রতিষ্ঠা করে।