আসল software-এর নকল installer: download-এর আগেই পাঁচটি সংকেত মিলিয়ে নিন
Microsoft-এর ১ সেপ্টেম্বরের গবেষণা একটি সক্রিয় malware campaign নথিবদ্ধ করেছে, যেখানে পরিচিত software vendor-এর মতো দেখতে download page থেকে Windows ব্যবহারকারীদের ক্ষতিকর installer দেওয়া হচ্ছিল। একই নামের archive-এর content ও hash বদলেছে; installer চালানোর পর malware স্থায়ী প্রবেশ তৈরি, নিরাপত্তাব্যবস্থা দুর্বল এবং attacker-controlled infrastructure-এর সঙ্গে যোগাযোগের চেষ্টা করেছে।
TechRadar-এর ২ সেপ্টেম্বরের প্রতিবেদন Microsoft Edge, Razer, Kaspersky, Calibre-সহ একাধিক brand-এর ছদ্মবেশ, scheduled-task persistence, বৈধ process-এ injection, Defender ও Windows Update দুর্বল করা এবং backup মুছে ফেলার আচরণ পুনরায় তুলে ধরেছে। প্রকাশিত তথ্য মূলত China-based operations ও Chinese-speaking ব্যবহারকারীদের ঘিরে; বাংলাদেশ বা ভারতে আক্রান্ত প্রতিষ্ঠানের নিশ্চিত তথ্য নেই। তবু নকল page চেনার সরাসরি উত্তর একই: logo বা filename নয়, পাঁচটি আলাদা সংকেত মিলিয়ে installer-এর provenance যাচাই করতে হবে।
Download-এর আগে পাঁচটি সংকেত
- Publisher domain: search result, বিজ্ঞাপন, forum বা message-এর download button-কে official উৎস ধরে নেবেন না। vendor-এর পরিচিত domain নিজে লিখে, প্রতিষ্ঠানের approved catalogue থেকে অথবা আগে যাচাই করা bookmark দিয়ে page খুলুন। brand-এর নাম থাকলেও ভুল বানান, বাড়তি hyphen, অপ্রত্যাশিত subdomain বা অন্য প্রতিষ্ঠানের মূল domain দেখা গেলে download থামান।
- Redirect chain: button চাপার পর browser কোন final hostname থেকে file নিচ্ছে, সেটি দেখুন। official site থেকে vendor-এর নথিভুক্ত CDN-এ যাওয়া স্বাভাবিক হতে পারে; অচেনা shortener, অপ্রাসঙ্গিক mirror কিংবা brand page ও delivery host-এর ব্যাখ্যাহীন বিচ্ছেদ provenance দুর্বল করে।
- Package ও archive: প্রত্যাশিত product, edition, version, filename, extension এবং packaging মিলিয়ে নিন। পরিচিত নাম, ZIP icon বা “setup” লেখা পরিচয়ের প্রমাণ নয়—সাম্প্রতিক campaign-এ একই filename রেখেও archive-এর content ও hash বদলেছে।
- File hash: vendor যদি official page-এ SHA-256 checksum প্রকাশ করে, downloaded file-এর hash তার সঙ্গে অক্ষরে অক্ষরে মেলান; Windows PowerShell-এর Get-FileHash দিয়ে local value বের করা যায়। independently published reference না থাকলে একটি hash শুধু নির্দিষ্ট file-কে শনাক্ত করে, সেটি নিরাপদ বা আসল—এ কথা প্রমাণ করে না।
- Signature ও endpoint telemetry: signer-এর নাম, certificate chain এবং expected publisher মিলিয়ে দেখুন; পাশাপাশি SmartScreen, antivirus বা EDR-এর reputation ও behavioral warning বিবেচনা করুন। অপ্রত্যাশিত child process, C:\Users\Public বা C:\ProgramData-এর এলোমেলো executable, নতুন scheduled task, Defender exclusion অথবা অচেনা outbound connection দেখা গেলে execution বা deployment বন্ধ রাখুন।
Signature কেন একা যথেষ্ট নয়
Digital signature জানায় কোন certificate দিয়ে file sign করা হয়েছে এবং signing-এর পরে file বদলেছে কি না। কিন্তু download page-টির নিয়ন্ত্রণ প্রকৃত vendor-এর হাতে কি না, certificate অপব্যবহৃত হয়েছে কি না বা signed program নিরাপদ আচরণ করবে কি না—শুধু signature থেকে সেসব জানা যায় না। signer প্রত্যাশিত publisher-এর সঙ্গে না মিললে কিংবা chain validation ব্যর্থ হলে file চালানো উচিত নয়।
Campaign-টির একটি execution path বৈধ ও signed Windows component msiexec.exe ব্যবহার করেছিল। installer তার প্রত্যাশিত কাজও সম্পন্ন করেছে, কিন্তু একই সঙ্গে randomized path-এ payload লিখে চালিয়েছে। অন্য payload-এ পরিচিত প্রতিষ্ঠানের version metadata থাকলেও অসম্পূর্ণ template field পাওয়া গেছে; ফলে বিশ্বাসযোগ্য metadata, বৈধ system process এবং signed-looking presentation—কোনোটিই source ও behavior যাচাইয়ের বিকল্প নয়।
প্রতিষ্ঠানে installer সংগ্রহের নিয়ন্ত্রিত পথ
ব্যক্তিগত ব্যবহারে সংক্ষিপ্ত workflow হলো official domain থেকে সঠিক edition বেছে নেওয়া, final host পরীক্ষা করা, vendor প্রকাশিত checksum ও signer মেলানো এবং endpoint protection সক্রিয় রেখেই file চালানো। “Pre-activated”, অপ্রকাশিত build বা official page-এর বাইরে পাওয়া দ্রুত download provenance যাচাই অসম্ভব করে তোলে।
প্রতিষ্ঠানের approved software catalogue-এ vendor URL, অনুমোদিত version, expected signer, SHA-256, সংগ্রহের সময় এবং যাচাইকারীর পরিচয় রাখা যায়। production deployment-এর আগে staging endpoint বা sandbox-এ child process, scheduled task, service, registry persistence, outbound destination, Defender configuration ও Windows Update setting পর্যবেক্ষণ করলে page থেকে endpoint পর্যন্ত evidence এক জায়গায় থাকে।
Filename বা একবার দেখা archive hash-কে স্থায়ী indicator ধরে নেওয়া এই campaign-এ বিশেষভাবে দুর্বল পদ্ধতি। IT team-এর hunting record-এ original URL, redirect path, file hash ও endpoint alert একসঙ্গে থাকলে delivery host বা filename বদলালেও একই আচরণ অন্য যন্ত্রে খোঁজা যায়।
Installer চললে প্রথম ১৫ মিনিটের অগ্রাধিকার
প্রথম অগ্রাধিকার containment: সন্দেহভাজন endpoint-কে network থেকে isolate করে প্রতিষ্ঠানের security বা IT team-কে জানান। Managed EDR থাকলে তার isolation feature ব্যবহার করলে তদন্তের প্রয়োজনীয় telemetry ধরে রাখা সম্ভব হতে পারে; নিজে থেকে তড়িঘড়ি power off করলে volatile process ও connection evidence হারাতে পারে। download URL, সময়, file path, hash এবং দেখা alert নথিবদ্ধ করুন।
এরপর compromised account-এর নিয়ন্ত্রণ ফেরাতে হবে। Microsoft-এর incident-response নির্দেশিকা client endpoint isolate ও reinstall করার পাশাপাশি জানা compromised account disable করা, password reset, authentication token expire এবং MFA enrollment যাচাই করার কথা বলে। Password পরিবর্তন ও session revoke সন্দেহভাজন যন্ত্রে নয়, পরিচ্ছন্ন আলাদা যন্ত্র থেকে করুন; administrator বা service account জড়িত হলে পরিবর্তনটি incident-response team-এর সঙ্গে সমন্বয় করা দরকার।
তারপর একই download origin, hash, randomized executable path, scheduled task, Defender exclusion এবং outbound destination অন্য endpoint-এ খুঁজুন। protection setting বদলানো বা shadow copy মুছে ফেলার evidence থাকলে শুধু installer delete করে যন্ত্রটি ফের ব্যবহার করা যথেষ্ট নয়; তদন্তের ফল অনুযায়ী known-good image থেকে rebuild এবং যাচাইকৃত backup থেকে restore প্রয়োজন হতে পারে।
Campaign সম্পর্কে যা এখনো অজানা
এটি শুধু নকল landing page-এর ঘটনা নয়: পর্যবেক্ষিত attack chain spoofed site থেকে archive delivery, payload execution, persistence, privilege escalation, defense evasion ও command-and-control পর্যন্ত গেছে। কার্যকলাপটি Silver Fox বা Yinhu নামে প্রকাশ্যে আলোচিত fake-software campaign-এর সঙ্গে সামঞ্জস্যপূর্ণ বলে moderate confidence-এ মূল্যায়ন করা হয়েছে, কিন্তু কোনো nation-state actor-কে দায়ী করা হয়নি।
Spoofed domain-এর সম্পূর্ণ বর্তমান তালিকা, আক্রান্ত যন্ত্রের মোট সংখ্যা এবং প্রতিটি download একই payload দিয়েছে কি না—এসব প্রকাশিত হয়নি। তাই পাঁচটি সংকেতের কোনো একটিতে অমিল পেলেই file চালানো বা deployment থামানো যুক্তিসংগত: official publisher domain, ব্যাখ্যাযোগ্য redirect path, প্রত্যাশিত package, vendor-প্রকাশিত hash এবং সঠিক signature ও endpoint behavior। installer ইতিমধ্যে চললে isolation ও clean-device credential containment আগে আসবে।
আরও পড়ুন:
আমাদের নিউজলেটার নিন
সর্বশেষ Web3, AI ও ক্রিপ্টো সংবাদ সরাসরি আপনার ইনবক্সে পান।