ٹیکنالوجی اور جدت

HAProxy خامی نہیں، binary بدل دی گئی—Ted backdoor logs سے بھی چھپتا ہے

|مصنف: QUASA ادارتی ٹیم|6 منٹ مطالعہ| 1
HAProxy خامی نہیں، binary بدل دی گئی—Ted backdoor logs سے بھی چھپتا ہے

4 ستمبر 2026 کو شائع ہونے والی آزاد تکنیکی رپورٹ کے مطابق، جنوبی کوریا کے automotive اور media شعبوں سے تعلق رکھنے والے دو اداروں میں Ted نامی implant ان کی HAProxy 2.8.12 binaries کے اندر compile ملا۔ حملہ آوروں کے چھوڑے ہوئے debug strings میں اس کا نام ted تھا، جبکہ load balancing کا معمول کا کام بظاہر جاری رہتا تھا۔

اس 4 ستمبر کے انکشاف کا مرکزی نکتہ یہ ہے کہ Ted کسی نئی HAProxy vulnerability یا CVE کا نام نہیں۔ اسے نصب کرنے کے لیے حملہ آور کو پہلے host پر code execution اور چلنے والی binary بدلنے کی صلاحیت درکار تھی؛ اس کے بعد implant منتخب web traffic دیکھ سکتا تھا اور اپنی C2 درخواستوں کو backend logs اور HAProxy statistics سے چھپا سکتا تھا۔

HAProxy چل رہا تھا، مگر executable معتبر نہیں رہا

چلتی ہوئی HAProxy 2.8.12 سروس کی deployed binary معتبر package copy سے مختلف نکلتی ہے

Ted کسی الگ اور آسانی سے پہچانے جانے والے process کے طور پر نہیں چلتا تھا۔ حملہ آور نے HAProxy source میں ted_plugin شامل کرکے build دوبارہ تیار کی؛ plugin نے native filter API، HTTP parser، memory structures اور scheduler استعمال کیے، اس لیے جائز traffic معمول کے مطابق backend تک جاتا رہا۔

درست version string یا صحت مند service status binary integrity کی ضمانت نہیں۔ Trojanized build وہی متوقع ورژن ظاہر کر سکتی ہے، جبکہ اس کے اندر اضافی code موجود ہو۔ اسی وجہ سے صرف HAProxy patch نصب کرنا کافی incident response نہیں: deployed executable کو distribution package، تنظیم کے signed artifact یا کسی دوسرے قابلِ اعتماد build reference سے ملانا ضروری ہے۔

C2 درخواست backend log بننے سے پہلے رک جاتی ہے

Ted کی C2 درخواست HAProxy host پر رک جاتی ہے اور backend log و connection counters میں ظاہر نہیں ہوتی

Ted ایک مخصوص HTTP path ملنے پر command mode میں داخل ہوتا تھا۔ وہ command body کو /tmp میں بنائی گئی named pipe تک پہنچاتا، پھر request channel کے forward pointers اور buffer lengths صفر کر دیتا؛ یوں HAProxy کے پاس backend کو بھیجنے کے لیے کوئی data باقی نہیں رہتا تھا۔

IntelFusions کے تکنیکی تجزیے کے مطابق implant hard-coded HAProxy 2.8.12 offsets کے ذریعے active، cumulative، request اور byte counters بھی کم کرتا تھا۔ نتیجہ یہ تھا کہ operator کی درخواست backend application تک نہیں پہنچتی، backend access log میں درج نہیں ہوتی اور load balancer کے اپنے اعداد بھی اس traffic کو ظاہر نہیں کرتے۔

اسی پوشیدہ channel سے operator beacon حاصل کر سکتا، file upload یا download کر سکتا، shell command چلا سکتا اور implant کی configuration بدل سکتا تھا۔ جواب raw socket پر عام HTTP/1.0 200 OK header کے ساتھ واپس آتا، اس لیے سطحی network inspection میں exchange جائز web response جیسا دکھائی دے سکتا تھا۔

دوسرے Linux daemons بھی toolkit کا حصہ تھے

Ted اکیلا component نہیں تھا۔ دریافت شدہ toolkit میں curlRAT، ایک stager، SSH credentials پکڑنے والا جزو اور crond، sshd، agetty، atd اور polkitd کی trojanized شکلیں شامل تھیں۔ Stager root privileges چیک کرتا اور HAProxy یا cron کی موجودگی میں payload تعینات کر سکتا تھا۔

تحقیق میں legitimate crond کو malicious build سے overwrite کرنے، service دوبارہ شروع کرنے اور نئی file کا timestamp /usr/bin/ssh سے نقل کرنے کا طریقہ بھی ملا۔ صفائی کے مرحلے میں tmp، wget، cron اور crond جیسے منتخب الفاظ root shell history اور متعدد system logs سے نکالے جاتے تھے؛ اس لیے معمول کا timestamp یا بظاہر صاف log compromise کو خارج نہیں کرتا۔

curlRAT کا default polling interval 43,200 seconds، یعنی 12 گھنٹے تھا، جسے operator flag کے ذریعے 30 seconds تک کم کیا جا سکتا تھا۔ اس RAT میں command execution، staged payload، reverse shell، system beacon اور interactive terminal جیسی صلاحیتیں تھیں، جبکہ ایک الگ thread HAProxy process کی حالت C2 کو بتاتا تھا۔

شمالی کوریائی نسبت ابھی medium confidence ہے

Rapid7 Labs کی اصل تحقیق نے toolkit کو شمالی کوریا سے وابستہ APT سرگرمی سے medium confidence کے ساتھ منسوب کیا۔ اس جائزے کی بنیاد جنوبی کوریائی media اور automotive اہداف، toolkit میں بار بار استعمال ہونے والی سادہ XOR اور substitution encryption، watering-hole طرز اور ایسے C2 domains تھے جنہیں بیرونی trackers نے APT37 infrastructure کے طور پر درج کیا تھا۔

یہ شواہد شمالی کوریائی تعلق کو قابلِ غور بناتے ہیں، مگر کسی ایک operator یا cluster کی قطعی شناخت ثابت نہیں کرتے۔ APT37 infrastructure، Lazarus سے مشابہ delivery model اور Kimsuky سے وابستہ سابقہ mail یا groupware targeting الگ نوعیت کے اشارے ہیں؛ انہیں ایک ہی threat actor کی براہِ راست تصدیق سمجھنا دستیاب evidence سے آگے ہوگا۔

ابتدائی رسائی بھی غیر حل شدہ ہے۔ دونوں متاثرہ edge servers پر groupware login portal اور mail service موجود تھے، لیکن forensic مواد کسی مخصوص vulnerability، CVE یا entry point کو ثابت نہیں کرتا۔ رپورٹ میں دکھائی گئی ممکنہ attack chain ایک reconstruction ہے، مشاہدہ شدہ ابتدائی exploit نہیں۔

تحقیق binary provenance اور پرانے IOCs سے شروع ہوگی

Linux تحقیق میں HAProxy اور system daemons کی package verification سے متعدد تبدیل شدہ binaries سامنے آتی ہیں

دفاعی تحقیق کا پہلا سوال یہ نہیں کہ کون سا HAProxy patch رہ گیا، بلکہ یہ ہے کہ executable کس نے بنایا اور host پر کیسے پہنچا۔ Running process کی memory اور disk پر موجود binary دونوں کو trusted package records یا signed build artifacts سے ملانا چاہیے؛ یہی verification crond، sshd، agetty، atd اور polkitd پر بھی لاگو ہوتی ہے۔

  • Deployed binaries کے hashes، package ownership اور build provenance کو clean reference سے ملایا جائے۔
  • HAProxy host سے باہر محفوظ flow، firewall یا packet telemetry کو backend access logs اور load-balancer statistics کے ساتھ correlate کیا جائے۔
  • haproxy-1000.cache سے haproxy-1002.cache تک files، /tmp میں t*_w.pipe طرز کی named pipes، /tmp/jasper-log اور مخصوص C2 request path کو historical records میں تلاش کیا جائے۔
  • ایک binary mismatch ملنے پر credentials، persistence، administrator access، lateral movement اور build pipeline کو بھی incident scope میں شامل کیا جائے۔

شائع شدہ چھ C2 domains 4 ستمبر کو A اور NS دونوں DNS queries میں NXDOMAIN دے رہے تھے۔ اس لیے وہ live blocking سے زیادہ historical DNS، proxy، TLS اور connection records کی تلاش میں مفید ہیں؛ موجودہ عدم resolution یہ ثابت نہیں کرتی کہ کسی host نے پہلے ان سے رابطہ نہیں کیا تھا۔

اب تک دو جنوبی کوریائی اداروں میں trojanized HAProxy 2.8.12 builds، پوشیدہ C2 mechanics اور دوسرے تبدیل شدہ Linux daemons کی موجودگی ثابت ہوئی ہے۔ تمام HAProxy 2.8.12 installations کے متاثر ہونے، کسی عمومی HAProxy flaw، ابتدائی entry point، campaign کے مکمل دورانیے یا قطعی operator کے بارے میں ثبوت موجود نہیں؛ نئی forensic معلومات آنے تک attribution کو medium confidence اور binary replacement کو privileged host compromise سمجھنا مناسب حد ہے۔

یہ بھی پڑھیں:

شیئر کریں:

ہمارا نیوز لیٹر سبسکرائب کریں

ویب 3، AI اور کرپٹو کی تازہ خبریں براہ راست اپنے اِن باکس میں پائیں۔

0