پوشیدہ Unicode حروف phishing filter سے نکلے—لفظ دکھا، مگر کوڈ بدل گیا

Microsoft Security Research نے 3 ستمبر 2026 کو بتایا کہ ایک بلند حجم مالیاتی phishing مہم نے پوشیدہ Unicode Tags حروف کو “funding” جیسے الفاظ کے اندر رکھ کر literal keyword filtering سے بچنے کی کوشش کی۔ Microsoft کی تکنیکی تحقیق کے مطابق یہ حروف عام interface میں نظر نہیں آتے، مگر email کے اصل متن میں موجود رہ کر لفظ کا code sequence بدل دیتے ہیں۔

یہ ہر security layer کو عبور کرنے والا مکمل bypass نہیں تھا۔ 6 ستمبر کی BleepingComputer کی رپورٹ کے مطابق Microsoft Defender نے 99 فیصد سے زیادہ متعلقہ پیغامات کو sender، IP، domain اور reputation سمیت دوسرے signals سے پکڑا؛ وسیع phishing آپریشن جاری تھا، اگرچہ Unicode Tags والے بلند حجم کا مرحلہ 15 مئی کے بعد تیزی سے گھٹ گیا تھا۔

دکھائی دینے والا لفظ، مختلف code sequence

ASCII smuggling ایسے Unicode code points کے استعمال کو کہا جاتا ہے جو متن میں محفوظ رہتے ہیں لیکن عام fonts اور interfaces انہیں render نہیں کرتے۔ اس واقعے میں متعلقہ Unicode Tags block کی حد U+E0000 سے U+E007F تھی، جس میں printable ASCII حروف کے tag equivalents بھی شامل ہیں۔

مہم نے مکمل پوشیدہ پیغام encode نہیں کیا۔ Microsoft کے دیکھے گئے نمونوں میں ایک پوشیدہ U+E0020 TAG SPACE مالیاتی lure word کے درمیان separator کے طور پر داخل کیا گیا: وصول کنندہ کو “funding” دکھائی دے سکتا تھا، جبکہ اصل ترتیب fun[U+E0020]ding تھی۔ مسلسل “funding” تلاش کرنے والا literal rule یا ایسا tokenizer جو پہلے tag character نہ ہٹائے، اسے ایک مکمل مانوس لفظ کے بجائے الگ حصوں اور غیر متوقع code point کے طور پر پڑھ سکتا ہے۔

اسی لیے اس نمونے کی زیادہ درست فنی تشریح invisible-character insertion ہے۔ اگر کوئی processing layer پہلے tag character کو strip یا normalize کر دے تو صاف لفظ دوبارہ مل جاتا ہے؛ ایسا نہ ہو تو keyword matching، regex، indexing اور tokenization کا نتیجہ بدل سکتا ہے۔ اثر ہر filter میں یکساں نہیں، کیونکہ parsing اور normalization کی ترتیب مختلف ہوتی ہے۔

اصل خطرہ پوری mail-processing chain میں اختلاف ہے

ایک ہی email کو انسان، gateway، quarantine preview، archive، search index، SIEM اور AI-connected mailbox الگ representations میں دیکھ سکتے ہیں۔ Raw MIME میں tag code point محفوظ رہ سکتا ہے، جبکہ کسی downstream نظام کا extracted text اسے ہٹا سکتا ہے؛ user interface دونوں صورتوں میں ایک ہی مکمل لفظ دکھا سکتا ہے۔ اس فرق سے analyst کی search، alert میں محفوظ متن اور صارف کے screenshot کا باہمی موازنہ مشکل ہو جاتا ہے۔

4 ستمبر کی Security.io کی عملی assessment gateway، archive، SIEM، e-discovery اور AI-connected inbox میں canonical text کا تقابل کرنے اور اصل و normalized دونوں forms محفوظ رکھنے کی سفارش کرتی ہے۔ پاکستانی Microsoft 365 اداروں کے لیے یہ خاص طور پر اہم ہے اگر mailbox کا مواد summarisation، ticket creation یا کسی action-taking AI workflow کو دیا جاتا ہو۔

Normalization، authorization کا متبادل نہیں۔ صاف کیا ہوا email بھی غیر معتبر خارجی input رہتا ہے؛ ایسا mailbox agent جو پیغام بھیج سکتا ہو، حساس data حاصل کر سکتا ہو یا business tool چلا سکتا ہو، اس کے لیے الگ permission boundaries اور نتیجہ خیز کارروائی سے پہلے تصدیق ضروری ہے۔ دستیاب رپورٹوں میں کسی AI agent کے ان حروف پر عمل کرنے کا ثبوت نہیں دیا گیا۔

ایک محدود test سے ہر layer کا نتیجہ ملائیں

دفاعی ٹیم منظور شدہ test tenant یا محدود test mailboxes میں benign نمونہ استعمال کر کے معلوم کر سکتی ہے کہ ہر مرحلہ کس متن پر فیصلہ کرتا ہے۔ مقصد production users کو مشتبہ lure بھیجنا نہیں، بلکہ صاف اور obfuscated نمونوں کے درمیان processing کا قابلِ ریکارڈ فرق تلاش کرنا ہے۔

1. ایک control email میں صاف مالیاتی لفظ رکھیں اور دوسری benign نقل میں اسی لفظ کے درمیان دستاویزی U+E0020 شامل کریں۔ Subject، plain-text body اور HTML body کو الگ test cases سمجھیں۔
2. Gateway پر raw MIME، message identifier، verdict، applied policy اور extracted text محفوظ کریں۔ اصل message کا hash بھی درج کریں تاکہ بعد کی archive یا e-discovery export اسی evidence سے ملائی جا سکے۔
3. دونوں نمونوں کو user view، quarantine preview، Microsoft 365 search، archive export، e-discovery اور SIEM event میں تلاش کریں۔ ہر مرحلے پر درج کریں کہ code point برقرار رہا، حذف ہوا یا کسی دوسری value میں بدلا۔
4. اگر mailbox content کسی AI summary یا triage workflow تک جاتا ہے تو صرف محدود test account سے دیکھیں کہ workflow کو raw متن ملا یا normalized متن۔ Test کے دوران external sending، data retrieval اور tool execution کے اختیارات محدود رہیں۔
5. صاف اور obfuscated نمونوں پر gateway، downstream rules اور SOC alerts کے نتائج ملائیں۔ Gateway کا alert پوری chain کی یکسانیت ثابت نہیں کرتا؛ archive یا search میں مختلف representation بھی قابلِ اصلاح control gap ہے۔

Unicode rule اکیلا کافی کیوں نہیں

پورے U+E0000–U+E007F block کو بلاشرط malicious قرار دینا false positives پیدا کر سکتا ہے۔ England، Scotland اور Wales کے subdivision flag emoji sequences بھی Tags block استعمال کرتے ہیں؛ Microsoft کی ابتدائی broad hunting signature نے انہی جائز sequences کو match کیا تھا۔ اس لیے Unicode anomaly کو context اور دوسرے campaign signals کے ساتھ پرکھنا ضروری ہے۔

• Keyword، regex اور content classification سے پہلے subject اور body سے غیر مرئی code points کو normalize یا strip کریں، مگر forensic copy میں raw متن برقرار رکھیں۔
• Tags block کی غیر متوقع موجودگی کو anomaly signal بنائیں اور جائز flag sequences کے لیے محدود، audit ہونے والا استثنا رکھیں۔
• Sender اور envelope domains، IP اور URL reputation، authentication، bulk-mail pattern اور brand impersonation کو Unicode signal کے ساتھ ملا کر verdict بنائیں۔
• دیکھیں کہ rendered-text یا OCR analysis وہ visible لفظ حاصل کرتی ہے یا نہیں جسے raw tokenizer نے توڑا تھا، اور دونوں representations alert evidence میں دستیاب رکھیں۔
• Archive، DLP، e-discovery، SIEM اور AI ingestion کے لیے واضح canonicalisation policy مقرر کریں؛ مختلف products کے default رویے کو یکساں نہ سمجھیں۔

تحقیق نے کیا ثابت کیا، اور کیا نہیں

Microsoft telemetry میں signature hits 9 فروری 2026 کو تیزی سے بڑھے، تقریباً تین ماہ بلند رہے اور 15 مئی کے بعد اس مخصوص technique کا بلند حجم تیزی سے کم ہوا۔ یہ تاریخیں صرف Unicode Tags کے مشاہدہ شدہ استعمال کی حد بتاتی ہیں؛ وسیع مہم پہلے شروع ہوئی تھی اور اس technique کے کم ہونے کے بعد بھی جاری رہی۔

Microsoft نے کسی مخصوص threat actor کو ذمہ دار نہیں ٹھہرایا۔ دستیاب شواہد یہ بھی ثابت نہیں کرتے کہ پوشیدہ حروف نے ہر email filter کو عبور کیا یا کسی mailbox-connected AI نے ان پر کارروائی کی۔ ثابت شدہ مسئلہ یہ ہے کہ لفظ انسان کو معمول کے مطابق دکھائی دے سکتا ہے جبکہ code-aware systems مختلف sequence حاصل کریں—اور دفاعی نتیجہ اس بات پر منحصر ہے کہ ہر layer normalization اور دوسرے signals کو کیسے استعمال کرتی ہے۔

یہ بھی پڑھیں:

• AI bubble ایک ہی منڈی نہیں، تحقیق نے کمپنیوں کے درمیان فرق دکھا دیا
• Claude کا پوشیدہ watermark ثبوت نہیں: ترجمہ اسے کمزور کر سکتا ہے
• Google AI Mode میں ہوٹل بکنگ آ گئی، مگر پاکستان ابھی فہرست سے باہر