ইমেইলে অদৃশ্য Unicode: filter পেরোনো phishing ধরতে normalization জরুরি

Microsoft Security Research ৩ সেপ্টেম্বর ২০২৬-এ এমন একটি phishing campaign-এর বিশ্লেষণ প্রকাশ করেছে, যেখানে আর্থিক প্রলোভনের দৃশ্যমান শব্দের মাঝখানে অদৃশ্য Unicode tag character ঢুকিয়ে keyword-নির্ভর পরীক্ষা এড়ানোর চেষ্টা হয়েছে। Microsoft-এর campaign analysis অনুযায়ী, Defender for Office 365 telemetry-তে সংশ্লিষ্ট hunting signature-এর hit ৯ ফেব্রুয়ারি দ্রুত বাড়ে এবং ১১ ফেব্রুয়ারি দৈনিক ২৩ লাখ ছাড়ায়।

প্রতিরক্ষার সরাসরি উত্তর হলো: মূল বার্তা evidence হিসেবে অপরিবর্তিত রেখে অদৃশ্য tag শনাক্ত করতে হবে, আর subject ও body-এর পরিষ্কার সংস্করণে keyword, URL ও phishing model চালাতে হবে। ৭ সেপ্টেম্বর প্রকাশিত ITPro-এর প্রতিবেদন একই কৌশল ও detection-এর আগে text normalization-এর প্রয়োজন তুলে ধরেছে; তবে সেপ্টেম্বরের ঘটনাটি নতুন গবেষণা প্রকাশের, সেপ্টেম্বরে নতুন করে ২৩ লাখ বার্তা পাঠানোর দাবি নয়।

দৃশ্যমান শব্দটি filter-এর কাছে কেন ভাঙা থাকে

এই ঘটনায় “ASCII smuggling” নামটি কিছুটা বিস্তৃত অর্থে ব্যবহৃত হয়েছে। Unicode-এর Tags block, U+E0000 থেকে U+E007F, printable ASCII character-এর সঙ্গে সম্পর্কিত অদৃশ্য code point বহন করতে পারে। সাধারণ font ও user interface সেগুলো দেখায় না, কিন্তু raw message বা decoded text-এ character-গুলো থেকে যেতে পারে।

Campaign-টিতে সম্পূর্ণ গোপন নির্দেশনা encode করার বদলে একটি tag character আর্থিক শব্দের মাঝখানে separator হিসেবে ঢোকানো হয়েছিল। উদাহরণস্বরূপ, প্রাপকের পর্দায় “funding” স্বাভাবিক দেখালেও decoded text-এ “fun”, অদৃশ্য U+E0020, তারপর “ding” থাকতে পারে। Literal keyword, অনমনীয় regular expression বা normalization-বিহীন tokenizer তখন একটানা শব্দটি নাও পেতে পারে।

Microsoft-এর পর্যবেক্ষিত বার্তাগুলো business loan, line of credit ও advance funding ধরনের প্রলোভন ব্যবহার করেছে। Traffic বৈধ ActiveCampaign infrastructure দিয়ে এসেছিল; Microsoft-এর প্রতিবেদনে উদ্ধৃত ActiveCampaign-এর বক্তব্য অনুযায়ী, তাদের moderation system অদৃশ্য character-যুক্ত বার্তাকে unobfuscated সংস্করণের সমান verdict দেয় এবং এমন character-এর অতিরিক্ত ব্যবহারকে সন্দেহজনক signal হিসেবে বিবেচনা করে।

Normalization-এর আগে raw evidence, পরে content detection

শুধু NFC বা NFKC প্রয়োগকে Tags block অপসারণের সমার্থক ধরে নেওয়া ঠিক নয়। কার্যকর ক্রম হলো MIME ও HTML decode করা, raw ও decoded রূপে tag anomaly শনাক্ত করা, মূল নমুনা সংরক্ষণ করা, নীতিমাফিক tag বাদ দিয়ে sanitized copy তৈরি করা এবং তারপর সেই copy-তে content detection চালানো।

1. Mail gateway: subject, display name, plain-text অংশ এবং HTML থেকে তোলা text-এ U+E0000–U+E007F খুঁজুন। মূল message অপরিবর্তিত রেখে sanitized copy-তে keyword, regex, URL analysis ও phishing model চালান।
2. SIEM ও SOC: “tag পাওয়া গেছে” event-এর সঙ্গে sender domain, sending IP, envelope path, URL reputation, authentication result, volume ও সময়ের pattern পাঠান। Raw-message hash ও normalized-text hash আলাদা রাখলে analyst দৃশ্যমান লেখা এবং detector-এর পরীক্ষিত লেখার সম্পর্ক মিলিয়ে দেখতে পারবেন।
3. AI-ingestion pipeline: summarizer, retrieval index বা mail-reading agent-এ content দেওয়ার আগে tag payload শনাক্ত করে quarantine বা strip করুন। ব্যবহারকারীর rendered text ও model-এর raw input আলাদা হলে মানুষ এবং automation ভিন্ন content প্রক্রিয়া করতে পারে।

Sanitized copy-তে detection চালানোর পাশাপাশি raw copy-তেও anomaly rule রাখা দরকার। Character বাদ দিলে ভাঙা keyword জোড়া লাগবে, কিন্তু ইচ্ছাকৃত অস্বাভাবিক code point থাকার signal হারিয়ে যেতে পারে। তাই sanitation এবং alerting একই প্রক্রিয়ার পৃথক output হওয়া উচিত।

বৈধ flag sequence-এর জন্য সংকীর্ণ ব্যতিক্রম

Tags block পাওয়া মাত্র সব mail block করলে false positive হবে। Microsoft-এর প্রথম broad signature ইংল্যান্ড, স্কটল্যান্ড ও ওয়েলসের subdivision flag emoji থাকা বৈধ বার্তাতেও hit করেছিল। এসব emoji black-flag base character, নির্দিষ্ট tag sequence এবং terminating tag দিয়ে গঠিত হতে পারে।

তাই কেবল স্বীকৃত ও সম্পূর্ণ flag sequence allowlist করা নিরাপদতর। আর্থিক শব্দের মাঝখানে একক tag, base flag ছাড়া tag run, অসম্পূর্ণ sequence কিংবা terminating tag-বিহীন গঠন একই ছাড় পাবে না। অন্য zero-width ও format character-এর ক্ষেত্রে ভাষা ও অবস্থান বিবেচনায় আলাদা নীতি দরকার; সব অদৃশ্য character নির্বিচারে বাদ দেওয়া এই campaign-এর জন্য প্রয়োজনীয় নিয়ন্ত্রণের চেয়ে বিস্তৃত।

Validation corpus-এ স্বাভাবিক বাংলা ও ইংরেজি mail, বৈধ subdivision flag, দৃশ্যমান শব্দের মাঝখানে একক tag এবং tag-এ encode করা দীর্ঘ hidden string রাখা যায়। প্রতিটি নমুনার raw alert, sanitized text, rendered output ও final verdict আলাদাভাবে মিলিয়ে দেখলে allowlist bypass এবং over-blocking—দুটিই ধরা পড়বে।

Layered detection-এ normalization-এর ভূমিকা যাচাই

Normalization এই evasion ঠেকানোর গুরুত্বপূর্ণ নিয়ন্ত্রণ, কিন্তু এটি একা phishing verdict নয়। BleepingComputer-এর ৬ সেপ্টেম্বরের প্রতিবেদনে Microsoft-এর তথ্য উদ্ধৃত করে বলা হয়েছে, sender, IP, domain ও reputation-সহ অন্য signal মিলিয়ে Defender পর্যবেক্ষিত বার্তার ৯৯ শতাংশের বেশি শনাক্ত করেছিল; ৯ ফেব্রুয়ারিতে দেখা ১৪৮টি finance-themed sender domain signature-এ ধরা traffic-এর প্রায় ৯৬ শতাংশের সঙ্গে যুক্ত ছিল।

• একই corpus-এর raw ও sanitized সংস্করণে keyword, regex এবং machine-learning verdict তুলনা করুন।
• tag anomaly-র সঙ্গে sender domain, bulk volume, URL reputation ও authentication result মিলিয়ে দেখুন।
• Plain-text MIME অংশ এবং HTML-extracted text আলাদা পরীক্ষা করে rendered content-এর সঙ্গে তুলনা করুন; image-based lure থাকলে OCR path-ও পৃথকভাবে যাচাই করুন।
• Gateway-এর sanitized text যেন SIEM, archive, e-discovery বা AI assistant-এ গিয়ে অনিচ্ছাকৃতভাবে raw সংস্করণে প্রতিস্থাপিত না হয়, সেই data lineage পরীক্ষা করুন।
• বৈধ flag allowlist version-controlled রাখুন এবং malicious ও benign sample দিয়ে regression test চালান।

Microsoft-এর মাপা নির্দিষ্ট Unicode-tag activity-র উচ্চ-volume পর্যায় ৯ ফেব্রুয়ারির পর প্রায় তিন মাস স্থায়ী হয়, ১৫ মে থেকে দ্রুত কমে যায় এবং ১৮ জুন পর্যন্ত অল্প residual activity দেখা যায়। বিস্তৃত phishing campaign ওই কৌশল ব্যবহারের আগেই শুরু হয়েছিল এবং পরে অন্য আচরণে চলেছে। অন্য mail platform-এ এই কৌশলের prevalence বা বিভিন্ন normalization policy-এর তুলনামূলক ফল এখনো প্রকাশিত হয়নি; তাই যাচাইযোগ্য প্রতিরক্ষার ভিত্তি হলো raw anomaly সংরক্ষণ, sanitized content-এ detection এবং rendered output-এর সঙ্গে তুলনা।