arrow_backفیلڈ نوٹس پر واپس جائیں
BLUE TEAM شائع شدہ 28 Jul 2026

Threat Hunting: اس کا مطلب اور یہ کیسے کام کرتا ہے

Threat hunting کی عملی glossary تفصیل: اس کا مطلب، alert triage سے کیسے مختلف ہے، اور hunters اصل میں کون سے طریقے استعمال کرتے ہیں۔

Threat hunting نیٹ ورک اور endpoints میں سے گزر کر ان حملہ آوروں کو فعال طریقے سے تلاش کرنے کی عمل ہے جو پہلے ہی آپ کی موجودہ detections سے نکل چکے ہیں۔ یہ ایک سادہ، غیر آرام دہ فرض سے شروع ہوتا ہے: کچھ بُرا شاید پہلے سے اندر ہو سکتا ہے، اور اس کے لیے کوئی alert آگ نہیں لگی۔ SIEM rule کے trigger ہونے کا انتظار کرنے کی بجائے، ایک hunter ایک مفروضہ بناتا ہے اور اسے تصدیق یا مسترد کرنے کے لیے شواہد تلاش کرتا ہے۔

صرف detection کافی کیوں نہیں ہے

Signature-based اور rule-based detection معلوم پیٹرن کو پکڑتا ہے۔ Living-off-the-land binaries (LOLBins)، درست credentials، یا سست، کم حجم والی تکنیکیں استعمال کرنے والے حملہ آور ان تھریشولڈ سے کئی ہفتوں تک نیچے رہ سکتے ہیں۔ Threat hunting ایک انسان کو فعال طریقے سے ڈیٹا پر سوال اٹھانے کی اجازت دے کر اس خلا کو بھرتا ہے: کیا ایک finance workstation سے صبح 2 بجے یہ PowerShell invocation منطقی ہے؟ svchost.exe reverse DNS کے بغیر ایک IP پر آؤٹ باؤنڈ connection کیوں بنا رہا ہے؟

یہ incident response نہیں ہے۔ IR اس کے بعد شروع ہوتا ہے جب آپ کو معلوم ہو کہ کچھ ہوا ہے۔ Hunting اس وقت شروع ہوتا ہے جب آپ ابھی نہیں جانتے، اور مقصد یہ معلوم کرنا ہے کہ بڑے واقعے سے پہلے سوال کو مجبور کرے۔

تین عام نقطہ آغاز

زیادہ تر hunts تینوں میں سے کسی ایک زاویے سے شروع ہوتے ہیں:

  • Intelligence-driven: ایک نیا threat report ایک TTP (کہہ دیں، persistence کے لیے scheduled task کا غلط استعمال) بیان کرتا ہے، اور آپ یہ چیک کرتے ہیں کہ آیا یہ آپ کے ماحول میں موجود ہے۔
  • Situational awareness: آپ دیکھتے ہیں کہ آپ کی تنظیم کے لیے کیا واقعی غیر معمولی ہے — ایک service account کسی ایسے ملک سے authenticate ہو رہا ہے جہاں یہ کبھی نہیں ہوا، یا workstations کے درمیان SMB traffic میں اضافہ جو عام طور پر صرف servers سے بات کرتے ہیں۔
  • Analytics-driven: آپ عام رویے کی ایک baseline بناتے ہیں (process trees، login times، DNS query volume) اور اس کے مقابلے اعدادوشمار کی異常تلاش کرتے ہیں۔

MITRE ATT&CK وہ reference ہے جو اکثر teams مفروضوں کو ڈھانچہ دینے کے لیے استعمال کرتے ہیں۔ "malware کو تلاش کریں" کی بجائے، آپ ایک تکنیک جیسے T1053 (Scheduled Task/Job) منتخب کرتے ہیں اور پوچھتے ہیں: یہ ہماری Windows Event Logs یا EDR telemetry میں کیسا نظر آئے گا، اور کیا میں اسے ابھی query کر سکتا ہوں؟

حقیقی workflow کیسا نظر آتا ہے

ہنٹ عام طور پر اس loop کی پیروی کرتا ہے:

  1. ایک مخصوص، قابل تجربہ مفروضہ بنائیں ("intrusions کے لیے چیک کریں" نہیں بلکہ "patch windows کے باہر بنائے گئے نئے scheduled tasks کے لیے پچھلے 30 دنوں میں چیک کریں")۔
  2. درکار ڈیٹا سورسز کی شناخت کریں — process creation کے لیے Sysmon Event ID 1، scheduled task creation کے لیے Windows Security Event ID 4698، EDR process trees، یا network context کے لیے Zeek conn logs۔
  3. Query اور pivot کریں۔ عملی طور پر اس کا مطلب Microsoft Sentinel میں KQL، Splunk میں SPL، یا Elastic index کے خلاف raw queries لکھنا ہے۔
  4. Triage کریں — اکثریت false positives یا benign admin activity ہوں گی، اور کام یہ ہے کہ اس شور کو اس چیز تک محدود کریں جو واقعی anomalous ہے۔
  5. Findings کو document کریں، چاہے یہ ایک تصدیق شدہ compromise، ایک detection gap، یا صرف ایک

AI کی مدد سے لکھا گیا، Michal Pilch (CISSP)، Korra Studio کے ذریعے جائزہ لیا گیا اور شائع کیا گیا۔

آگے بڑھنے کے لیے تیار ہیں؟

یہ Korra Studio کے علم کے ذخیرے کا ایک نوٹ ہے — یہ پلیٹ فارم ہر موضوع کو ایک سے ایک رہنمائی کے ساتھ جوڑتا ہے۔

مفت شروع کریںarrow_forward