রাতে phone-এ “Approve sign-in?” prompt এল। আপনি login করেননি, তাই Deny করলেন। কয়েক মিনিট পরে আবার, তারপর আরও কয়েকবার। বিরক্ত হয়ে Approve চাপিয়ে prompt থামানোই attacker-এর লক্ষ্য হতে পারে। একে MFA fatigue বা push bombing বলা হয়: repeated approval request দিয়ে user-কে ভুল করানো। Unexpected prompt-কে nuisance নয়, সম্ভাব্য account attack হিসেবে নিন। নিচের workflow personal ও workplace account-এ তাৎক্ষণিক response, account review এবং team reporting গুছিয়ে করতে সাহায্য করবে।

নিজে login শুরু না করলে approve নয়

MFA prompt আসার সময় থেমে context দেখুন। কোন account, app, device এবং approximate location দেখাচ্ছে? আপনি ঠিক সেই মুহূর্তে trusted browser-এ sign-in শুরু করেছিলেন কি? না হলে Approve দেবেন না। Number matching থাকলে screen-এর number অন্ধভাবে type করবেন না; numberটি আপনার নিজের শুরু করা login page-এ দেখা দরকার। Prompt-এর support link বা caller-এর বলা link ব্যবহার না করে account provider-এর known app বা manually typed official URL খুলুন।

Deny করে suspicious হিসেবে report করুন

App-এ Deny, “No, it’s not me” বা report suspicious option থাকলে ব্যবহার করুন। শুধু notification dismiss করলে provider attempt-এর nature বুঝতে নাও পারে। Screenshot প্রয়োজন হলে account name বা private details share করার আগে mask করুন। Prompt কখন, কতবার এবং কোন account-এ এসেছে note করুন। Workplace account হলে organisation-এর security/helpdesk channel-এ দ্রুত জানান। Random phone number বা incoming “IT support” caller-কে code দেবেন না; attacker prompt-এর পরে call করে চাপ সৃষ্টি করতে পারে।

Repeated prompt কেন serious signal

Microsoft Entra identity protection guidance MFA fatigue-তে attacker repeated push request পাঠিয়ে accidental approval পাওয়ার চেষ্টা করে বলে ব্যাখ্যা করে। Prompt আসা মানে password নিশ্চিতভাবে চুরি হয়েছে—এমন প্রমাণ সবসময় নয়; misconfigured app বা stale session-ও cause হতে পারে। তবে repeated unsolicited request credential exposure-এর সম্ভাবনা ধরে investigate করা নিরাপদ। Evidence ছাড়া “false alarm” বলে বন্ধ করবেন না।

Trusted device থেকে account activity দেখুন

Known clean device ও bookmarked official account page ব্যবহার করুন। Recent sign-in, device, session, recovery email এবং security alert দেখুন। অচেনা session sign out বা revoke করার provider-supported option নিন। Location approximate হতে পারে, mobile network বা VPN-এর কারণে ভিন্নও দেখাতে পারে; location একা decision নয়। Time, browser, device এবং successful/failed status একসঙ্গে দেখুন। Workplace account-এ admin logs বেশি evidence দিতে পারে, তাই নিজে সব session delete করে forensic trail নষ্ট না করে security team-এর নির্দেশ মানুন।

Password action কখন নেবেন

আপনার জানা password reuse হয়েছে, phishing page-এ type করেছেন, unknown successful sign-in আছে বা security team compromise সন্দেহ করছে—এমন হলে trusted device থেকে password বদলান। অন্য account-এ একই password থাকলে প্রত্যেকটিতে unique password দিন। Password manager দিয়ে strong unique value রাখা সুবিধাজনক। Email account আগে secure করুন, কারণ সেটি recovery control করতে পারে। শুধু password বদলালেই existing stolen session সবসময় শেষ নাও হতে পারে; provider-এর sign-out-all বা session revoke option দেখুন। Recovery method-এ attacker-এর detail যোগ হয়েছে কি না পরীক্ষা করুন।

একটি workplace scenario

ধরুন সন্ধ্যা ৮টায় employee পাঁচটি approval prompt পেলেন। তিনি login করেননি, তাই Deny ও report করলেন, prompt-এর time note করে security desk-কে ফোন করলেন known directory number দিয়ে। Admin দেখলেন অচেনা country থেকে password attempt হয়েছে, session revoke ও password reset করালেন। পরদিন team phishing email খুঁজল এবং affected account scope review করল। Employee approve না করলেও incident review দরকার ছিল। এই example response sequence বোঝায়; আপনার organisation-এর incident plan অগ্রাধিকার পাবে।

Highlighted response checklist

  • Stop: নিজের শুরু করা login না হলে কোনো prompt approve বা number enter করা হয়নি।
  • Deny: app-এর deny/report suspicious action ব্যবহার করা হয়েছে।
  • Record: সময়, account, prompt count ও displayed context নিরাপদভাবে note করা হয়েছে।
  • Open safely: notification link নয়, known app বা typed official URL ব্যবহার হয়েছে।
  • Review: recent sign-in, session, device ও recovery method দেখা হয়েছে।
  • Contain: প্রয়োজনমতো password change, session revoke ও unique credentials করা হয়েছে।
  • Report: workplace account security team বা provider support-কে জানানো হয়েছে।

Number matching ও phishing-resistant option

CISA number matching guidance push bombing কমাতে number matching-এর ব্যবহার ব্যাখ্যা করে। এটি plain Approve button-এর চেয়ে context যোগ করে, কিন্তু user phishing page-এর number follow করলে ভুল হতে পারে। Provider ও organisation support করলে passkey বা FIDO2 security key-এর মতো phishing-resistant method বিবেচনা করুন। Enrollment-এর আগে recovery path, spare key এবং lost-device process ঠিক করুন। কোনো factor একা careless approval বা compromised recovery channel-এর সব ঝুঁকি মুছে দেয় না।

Prompt থামার পরে incident close করবেন না

Attacker চেষ্টা বন্ধ করলেই password exposure বা session risk শেষ হয়েছে এমন নয়। পরের ২৪–৪৮ ঘণ্টায় provider alert, forwarding rule, mailbox sent item এবং security setting পরিবর্তন দেখুন। Financial বা admin account হলে transaction ও privileged action আলাদাভাবে review করুন। Team root cause লিখুক: phishing, password reuse, leaked credential, legacy app না configuration error। তারপর targeted change করুন—user training, password reset, risky protocol block, number matching বা stronger authentication। Scoring বা alert rule বদলে symptom লুকাবেন না; evidence দিয়ে control উন্নত করুন।