[{"data":1,"prerenderedAt":-1},["ShallowReactive",2],{"$fddxxtciy8mnl":3},{"success":4,"posts":5,"pagination":56,"availableLocales":59},true,[6],{"_id":7,"slug":8,"title":9,"excerpt":10,"content":11,"coverImage":12,"authorName":13,"authorType":14,"publicationKind":15,"category":16,"tags":17,"metaDescription":22,"metaKeywords":23,"isFeatured":28,"publishedAt":29,"createdAt":30,"updatedAt":29,"readTime":31,"viewCount":32,"contentLocale":33,"availableLocales":34,"hasEnglishTranslation":4,"translations":44},"ca1ba9756e09172be1d6dc5a","why-password-change-may-not-end-infostealer-access","পাসওয়ার্ড বদলালেও ইনফোস্টিলারের প্রবেশাধিকার কেন থেকে যেতে পারে","পাসওয়ার্ড বদলানোর পরও চুরি হওয়া সেশন ব্যবহারযোগ্য থাকতে পারে। এন্ডপয়েন্ট বিচ্ছিন্ন করা, টোকেন অকার্যকর করা, অ্যাপ্লিকেশনের সেশন নিয়ন্ত্রণ ও অ্যাকাউন্ট পুনরুদ্ধার কীভাবে একসঙ্গে কাজ করে, তা জানুন।","\u003Cp>অ্যাকাউন্টের পাসওয়ার্ড বদলানোর পরও একটি ওয়েব অ্যাপ্লিকেশনের সেশন সক্রিয় থাকতে পারে। নিজের সক্ষমতা অনুযায়ী একটি ইনফোস্টিলার সংরক্ষিত পাসওয়ার্ডের পাশাপাশি সেশন কুকি, প্রমাণীকরণ টোকেন, API কী এবং ডিভাইসে থাকা অন্যান্য তথ্য সংগ্রহ করতে পারে। সেই তথ্য ডিভাইসের বাইরে চলে গেলে ম্যালওয়্যার সরিয়ে ফেললেও তা অকার্যকর হয় না।\u003C\u002Fp>\u003Cp>পাসওয়ার্ড হলো প্রমাণীকরণের সময় দেওয়া একটি গোপন তথ্য। অ্যাক্সেস টোকেন কোনো অ্যাপ্লিকেশনকে নির্দিষ্ট রিসোর্সে প্রবেশের অনুমতি দেয়। আর প্রোটোকল অনুমতি দিলে রিফ্রেশ টোকেন দিয়ে নতুন অ্যাক্সেস টোকেন নেওয়া যায়। সাধারণত প্রমাণীকরণের পর ইস্যু করা আলাদা কুকি বা সেশনের গোপন তথ্যের মাধ্যমে অ্যাপ্লিকেশনের সেশন চলতে থাকে। এই ব্যবস্থাগুলো একই অ্যাকাউন্টের সঙ্গে যুক্ত হতে পারে, তবে সেগুলোর মেয়াদ বা বাতিল করার নিয়ন্ত্রণ এক হবে, এমন নয়।\u003C\u002Fp>\u003Ch2>পাসওয়ার্ড বদলানোর পরও কোন প্রবেশাধিকার বহাল থাকতে পারে?\u003C\u002Fh2>\u003Cp>পাসওয়ার্ড পরিবর্তন পুরোনো পাসওয়ার্ডের ওপর নির্ভরশীল নতুন সাইন-ইন বন্ধ করে। তবে এর ফলে বৈধ থাকা সব টোকেন বা অ্যাপ্লিকেশন সেশন শেষ হয়ে যাবে বলে ধরে নেওয়া যায় না। \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fentra\u002Fidentity\u002Fusers\u002Fusers-revoke-access\">Entra-তে জরুরি পরিস্থিতিতে প্রবেশাধিকার নিয়ন্ত্রণের জন্য Microsoft-এর নির্দেশনা\u003C\u002Fa> অনুযায়ী, নতুন সাইন-ইন বন্ধ করা এবং রিফ্রেশ টোকেন বাতিল করা হলে ব্যবহারকারী নতুন Entra টোকেন নিতে পারেন না। তবে বিদ্যমান অ্যাক্সেস টোকেনের ডিফল্ট এক ঘণ্টার মেয়াদ শেষ না হওয়া পর্যন্ত সেটি কাজ করতে পারে। সমর্থিত Microsoft 365 পরিস্থিতিতে Continuous Access Evaluation এই সময় কমাতে পারে; তবে এটি সব টোকেন তাৎক্ষণিকভাবে অকার্যকর করার নিশ্চয়তা নয়।\u003C\u002Fp>\u003Cp>অ্যাপ্লিকেশন থেকে ইস্যু করা সেশন কুকির জন্য আলাদা ব্যবস্থা নিতে হয়। অ্যাপ্লিকেশন নিজে যে সেশন টোকেন ইস্যু করেছে, Entra সরাসরি সেটি বাতিল করতে পারে না। \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fpages.nist.gov\u002F800-63-4\u002Fsp800-63b\u002Fsession\u002F\">NIST SP 800-63B-4\u003C\u002Fa>-এ ফেডারেটেড সিস্টেমেও একই পৃথক ব্যবস্থার কথা বলা হয়েছে: পরিচয় প্রদানকারী (IdP) ও নির্ভরকারী পক্ষ (RP) স্বাধীনভাবে নিজেদের সেশন তৈরি ও শেষ করে। শুধু পরিচয় প্রদানকারীর সেশন শেষ করলেই সংযুক্ত প্রতিটি অ্যাপ্লিকেশনের সেশন শেষ হয় না।\u003C\u002Fp>\u003Cp>এই পার্থক্য আক্রমণকারীর কাজে লাগে। \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fattack.mitre.org\u002Ftechniques\u002FT1550\u002F004\u002F\">MITRE ATT&CK-এর নথিতে\u003C\u002Fa> ব্যাখ্যা করা হয়েছে, চুরি হওয়া ওয়েব সেশন কুকি বৈধ ও পুনর্ব্যবহারযোগ্য থাকলে কীভাবে সেটি আক্রমণকারীর নিয়ন্ত্রণে থাকা ব্রাউজারে আমদানি করা যেতে পারে। সেশনটি আগেই প্রমাণীকৃত হওয়ায় কিছু প্রমাণীকরণ প্রক্রিয়ায় নতুন করে MFA ধাপের প্রয়োজন নাও হতে পারে। এটি একটি সক্ষমতার বর্ণনা; কোনো নির্দিষ্ট অ্যাকাউন্ট দখল হয়েছে, তার প্রমাণ নয়।\u003C\u002Fp>\u003Ch2>ডিভাইস বিচ্ছিন্ন করা ও অ্যাকাউন্টের নিয়ন্ত্রণ\u003C\u002Fh2>\u003Cp>প্রাসঙ্গিক প্রমাণ সংরক্ষণের প্রয়োজন মূল্যায়ন করার সময় প্রতিষ্ঠানের ঘটনা মোকাবিলার পরিকল্পনা অনুযায়ী সন্দেহভাজন এন্ডপয়েন্টটি বিচ্ছিন্ন করা হয়। অ্যাকাউন্টের বিশেষাধিকার থাকলে বা সেটি দিয়ে সংবেদনশীল তথ্যে প্রবেশ করা গেলে, এন্ডপয়েন্টের পূর্ণাঙ্গ বিশ্লেষণ শেষ হওয়ার আগেই নতুন সাইন-ইন বন্ধ করা ও বর্তমান প্রবেশপথগুলো বন্ধ করার কাজ শুরু হতে পারে। পাসওয়ার্ড পরিবর্তন, অ্যাকাউন্ট পুনরুদ্ধার ও প্রশাসনিক কাজ বিশ্বস্ত ডিভাইস ও মাধ্যম ব্যবহার করে করা হয়, যাতে নতুন পরিচয়-প্রমাণক তথ্য সন্দেহভাজন সিস্টেমে উন্মুক্ত না হয়।\u003C\u002Fp>\u003Ch3>ডিভাইসে সংরক্ষিত প্রবেশাধিকারের তথ্য\u003C\u002Fh3>\u003Cp>পর্যালোচনা শুধু সন্দেহভাজন সংক্রমণকাল শুরু হওয়ার পর সংরক্ষিত পাসওয়ার্ডে সীমাবদ্ধ থাকে না। সংক্রমণ কখন শুরু হয়েছে তা অনিশ্চিত হতে পারে, আর ইনফোস্টিলার ডিভাইসে আগে থেকেই সংরক্ষিত পরিচয়-প্রমাণক তথ্যও সংগ্রহ করতে পারে। ঘটনার প্রমাণের ভিত্তিতে ব্রাউজার প্রোফাইল, ডিভাইসে ব্যবহৃত বা সংরক্ষিত অ্যাকাউন্ট, সেশন কুকি, টোকেন ও API কী পর্যালোচনার আওতায় আসে। এন্ডপয়েন্ট পরিষ্কার করা বা নতুন করে প্রস্তুত করলেও আগে নিয়ে নেওয়া হয়ে থাকতে পারে এমন পাসওয়ার্ড, টোকেন বা কী অকার্যকর হয় না।\u003C\u002Fp>\u003Ch3>টোকেন ও সেশনের নিয়ন্ত্রণ\u003C\u002Fh3>\u003Cp>নতুন সাইন-ইন বন্ধ করতে, সমর্থিত ক্ষেত্রে রিফ্রেশ টোকেন অকার্যকর করতে এবং IdP সেশন শেষ করতে পরিচয় প্রদানকারীর নথিভুক্ত নিয়ন্ত্রণগুলো ব্যবহার করা হয়। এরপর গুরুত্বপূর্ণ অ্যাপ্লিকেশনগুলো আলাদাভাবে পরীক্ষা করা হয় এবং অ্যাপ্লিকেশন-স্তরের নিয়ন্ত্রণের মাধ্যমে সেগুলোর নিজস্ব সেশন শেষ করা হয়। প্রশাসনিক স্ক্রিনে “সফল” বার্তা দেখালেই সব প্রবেশাধিকার শেষ হয়েছে বলে নিশ্চিত হওয়া যায় না। টোকেনের ধরন, কোন শর্তে সেটির মেয়াদ শেষ হওয়ার কথা এবং প্রতিটি অ্যাপ্লিকেশন কখন আবার প্রমাণীকরণ চাইবে—এসব তখনও গুরুত্বপূর্ণ।\u003C\u002Fp>\u003Cp>ঘটনার আওতায় থাকা পাসওয়ার্ড ও প্রবেশাধিকারের অন্যান্য তথ্য বিশ্বস্ত ডিভাইস থেকে বদলানো বা অকার্যকর করা হয়। এর মধ্যে API কী, ডেভেলপার টোকেন বা ডিভাইসে সংরক্ষিত অন্য কোনো পরিচয়-প্রমাণক তথ্য অন্তর্ভুক্ত হবে কি না, তা নির্ভর করে ঘটনার প্রমাণ ও ক্ষতিগ্রস্ত সিস্টেমের আচরণের ওপর। লক্ষ্য নির্বিচারে প্রতিটি অ্যাকাউন্ট রিসেট করা নয়; বরং কোন পাসওয়ার্ড, টোকেন, কী বা সেশন কুকি ডিভাইসের বাইরে চলে গিয়ে এখনও ব্যবহারযোগ্য থাকতে পারে, তা নির্ধারণ করা।\u003C\u002Fp>\u003Ch3>প্রবেশাধিকার টিকিয়ে রাখার জন্য করা পরিবর্তন\u003C\u002Fh3>\u003Cp>অনুপ্রবেশকারী শুধু বর্তমান সেশনের ওপর নির্ভর না করে অ্যাকাউন্টে ফিরে আসার নতুন পথ যোগ করতে পারে। \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fdefender-office-365\u002Fresponding-to-a-compromised-email-account\">অননুমোদিত নিয়ন্ত্রণে চলে যাওয়া Microsoft 365 মেইল অ্যাকাউন্টের জন্য Microsoft-এর প্রতিকার নির্দেশনা\u003C\u002Fa>-তে অপরিচিত MFA পদ্ধতি ও ডিভাইস, অ্যাপ্লিকেশনকে দেওয়া অনাকাঙ্ক্ষিত অনুমতি, অননুমোদিত প্রশাসনিক ভূমিকা, মেইল ফরওয়ার্ডিং এবং লুকানো ইনবক্স নিয়ম পর্যালোচনা করতে বলা হয়েছে। এই তালিকা Microsoft 365-এর জন্য নির্দিষ্ট; অন্যান্য প্রদানকারীর সমতুল্য নিয়ন্ত্রণ ও সেগুলোর প্রভাব ভিন্ন হয়।\u003C\u002Fp>\u003Cp>অপরিচিত বা সন্দেহজনক MFA পদ্ধতি সরিয়ে ফেলা বা অকার্যকর করা হয়। বৈধ ব্যবহারকারীর পদ্ধতি আবার নিবন্ধন করার প্রয়োজন হলে প্রথমে বিশ্বস্ত পুনরুদ্ধার মাধ্যম দিয়ে মালিকানা যাচাই করা হয়। এরপর কেবল সেই ব্যবহারকারীর নিয়ন্ত্রণে থাকা নতুন পদ্ধতিই নিবন্ধন করা হয়। আক্রমণকারীর যোগ করা পদ্ধতি আবার নিবন্ধন করলে প্রবেশপথ বন্ধ হওয়ার বদলে বহাল থাকবে।\u003C\u002Fp>\u003Ch2>MFA সক্রিয় সেশন বাতিল করে না\u003C\u002Fh2>\u003Cp>চুরি হওয়া পাসওয়ার্ড দিয়ে নতুন সেশন শুরু করার পথে MFA আরেকটি বাধা তৈরি করে। তবে এটি নিজে থেকে আগে প্রমাণীকৃত, পুনর্ব্যবহারযোগ্য কুকি অকার্যকর করে না। MFA পদ্ধতিগুলোর সুরক্ষাও এক নয়। NIST-এর \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fpages.nist.gov\u002F800-63-4\u002Fsp800-63b\u002Fauthenticators\u002F\">প্রমাণীকরণ উপায়ের প্রয়োজনীয়তা\u003C\u002Fa>-তে হাতে লিখে দেওয়া একবার ব্যবহারযোগ্য কোডকে ফিশিং-প্রতিরোধী হিসেবে গণ্য করা হয় না এবং ফিশিং-প্রতিরোধী প্রমাণীকরণের উদাহরণ হিসেবে WebAuthn\u002FFIDO2 উল্লেখ করা হয়েছে। শক্তিশালী প্রমাণীকরণ ভবিষ্যতের সাইন-ইন সুরক্ষিত রাখে; বৈধ থাকা চুরি হওয়া সেশন এখনও আলাদাভাবে শেষ করতে হয়।\u003C\u002Fp>\u003Ch2>লগ থেকে কী নিশ্চিত করা যায়—আর কী যায় না\u003C\u002Fh2>\u003Cp>যেখানে রেকর্ড পাওয়া যায়, সেখানে ঘটনাকালের সাইন-ইন ও সংবেদনশীল কাজের রেকর্ড অস্বাভাবিক অবস্থান, সময়, অ্যাপ্লিকেশনকে দেওয়া অনুমতি এবং অ্যাকাউন্টের পরিবর্তন প্রকাশ করতে পারে। Microsoft 365-এর ক্ষেত্রে প্রদানকারী প্রাথমিক অডিট অনুসন্ধানের পরিসর খুব তাড়াতাড়ি সংকুচিত না করার পরামর্শ দেয় এবং সন্দেহজনক কার্যকলাপের শুরু থেকে প্রতিকার পর্যন্ত সময়ের রেকর্ড পর্যালোচনা করতে বলে। সন্দেহজনক ঘটনা না পাওয়া অ্যাকাউন্ট নিরাপদ থাকার প্রমাণ নয়। ফলাফলের তাৎপর্য কেবল উপলব্ধ টেলিমেট্রি, রেকর্ড সংরক্ষণের মেয়াদ, অনুসন্ধান করা উৎস ও সময়সীমার মধ্যেই সীমাবদ্ধ।\u003C\u002Fp>\u003Cp>একইভাবে, কোনো পরিচয়-প্রমাণক তথ্য বা কুকি উন্মুক্ত হওয়ার প্রমাণ নিজে থেকে অননুমোদিত ব্যবহার সফল হওয়া বা অ্যাকাউন্ট দখলের প্রমাণ নয়। তথ্য উন্মুক্ত হওয়া, ব্যবহারের চেষ্টা দেখা যাওয়া এবং নিশ্চিত অ্যাকাউন্ট দখল—এগুলো আলাদা বিষয়। সম্ভাব্য বৈধ প্রবেশপথগুলোর জন্য এখনও ঝুঁকির অনুপাতে ব্যবস্থা নেওয়া দরকার। সেই ব্যবস্থার পরিসর নির্ধারিত হবে অ্যাকাউন্টের বিশেষাধিকার, তথ্যের সংবেদনশীলতা ও উপলব্ধ প্রমাণের ভিত্তিতে। LeakData-এর \u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fleakdata.io\u002Fen\u002Fblog\u002Fwhat-is-a-data-breach-what-to-do-if-your-email-was-leaked\">তথ্য ফাঁসের পর মূল্যায়নের নির্দেশিকা\u003C\u002Fa>-তে তথ্য উন্মুক্ত হওয়া ও নিশ্চিত অপব্যবহারের মধ্যকার এই বৃহত্তর পার্থক্য আলোচনা করা হয়েছে।\u003C\u002Fp>\u003Cp>ঘটনার নথিতে পরিচয় প্রদানকারী ও অ্যাপ্লিকেশনগুলোর মধ্যে কোন সেশন শেষ করা হয়েছে, কোন শর্তে টোকেনগুলোর মেয়াদ শেষ হওয়ার কথা, কোন অননুমোদিত পরিবর্তন সরানো হয়েছে এবং লগ পর্যালোচনায় কোথায় ঘাটতি রয়েছে—এসব তালিকাভুক্ত করা হয়। এতে স্পষ্ট হয় কোন প্রবেশপথের জন্য ব্যবস্থা নেওয়া হয়েছে এবং কোন অনিশ্চয়তা এখনও রয়ে গেছে।\u003C\u002Fp>\u003Ch2>তথ্যসূত্র\u003C\u002Fh2>\u003Cul>\u003Cli>\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fentra\u002Fidentity\u002Fusers\u002Fusers-revoke-access\">Microsoft Learn — জরুরি পরিস্থিতিতে Microsoft Entra ID-তে ব্যবহারকারীর প্রবেশাধিকার বাতিল করা\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Flearn.microsoft.com\u002Fen-us\u002Fdefender-office-365\u002Fresponding-to-a-compromised-email-account\">Microsoft Learn — Microsoft 365-এ অননুমোদিত নিয়ন্ত্রণে চলে যাওয়া ইমেইল অ্যাকাউন্টের জন্য প্রতিকার\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fpages.nist.gov\u002F800-63-4\u002Fsp800-63b\u002Fsession\u002F\">NIST SP 800-63B-4 — সেশন ব্যবস্থাপনা\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fpages.nist.gov\u002F800-63-4\u002Fsp800-63b\u002Fauthenticators\u002F\">NIST SP 800-63B-4 — প্রমাণীকরণ উপায়ের প্রয়োজনীয়তা\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fattack.mitre.org\u002Ftechniques\u002FT1550\u002F004\u002F\">MITRE ATT&CK T1550.004 — ওয়েব সেশন কুকি\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003Cli>\u003Cp>\u003Ca target=\"_blank\" rel=\"noopener noreferrer\" href=\"https:\u002F\u002Fspecopssoft.com\u002Fblog\u002Finside-infostealer-attacks\u002F\">Specops Software — ইনফোস্টিলার আক্রমণের ভেতরের কার্যক্রম\u003C\u002Fa>\u003C\u002Fp>\u003C\u002Fli>\u003C\u002Ful>","\u002Fuploads\u002Fblog\u002Finfostealer-sonrasi-parola-degisikligi-neden-yetmeyebilir-dfdf6bda3fb759147214.webp","LeakData নিরাপত্তা দল","Organization","blog","güvenlik",[18,19,20,21],"ইনফোস্টিলার","নিরাপত্তা-ঘটনা মোকাবিলা","সেশনের নিরাপত্তা","পরিচয় ও প্রবেশাধিকার","পাসওয়ার্ড বদলালেও ইনফোস্টিলারের প্রবেশাধিকার কেন থাকতে পারে; এন্ডপয়েন্ট, টোকেন, সেশন ও স্থায়ী প্রবেশপথের নিয়ন্ত্রণ কীভাবে একসঙ্গে কাজ করে।",[24,25,26,27],"ইনফোস্টিলার মোকাবিলা","টোকেন অকার্যকর করা","চুরি হওয়া সেশন কুকি","পাসওয়ার্ড পরিবর্তন",false,"2026-10-09T16:49:52.841Z","2026-09-16T23:36:22.537Z",6,0,"bn",[35,36,37,38,39,40,41,33,42,43],"en","tr","zh","hi","es","ar","fr","pt","ru",{"en":45,"tr":46,"zh":48,"hi":49,"es":50,"ar":51,"fr":52,"bn":53,"pt":54,"ru":55},{"slug":8},{"slug":47},"infostealer-sonrasi-parola-degisikligi-neden-yetmeyebilir",{"slug":8},{"slug":8},{"slug":8},{"slug":8},{"slug":8},{"slug":8},{"slug":8},{"slug":8},{"page":57,"limit":58,"total":57,"pages":57},1,12,[35,36,37,38,39,40,41,33,42,43]]