Threat Hunting: यह क्या है और यह कैसे काम करता है

Threat hunting नेटवर्क और endpoints के through proactively search करने की practice है जहाँ attackers पहले से ही आपके existing detections को पार कर चुके हैं। यह एक सरल, असहज assumption से शुरू होता है: कुछ बुरा पहले से ही अंदर हो सकता है, और कोई alert नहीं चली। SIEM rule के trigger होने का इंतजार करने की बजाय, एक hunter एक hypothesis बनाता है और इसे confirm या kill करने के लिए evidence ढूंढने जाता है।

Why detection alone isn't enough

Signature-based और rule-based detection known patterns को catch करता है। Attackers जो living-off-the-land binaries (LOLBins), valid credentials, या slow, low-volume techniques use करते हैं, वे इन thresholds के तहत हफ्तों तक रह सकते हैं। Threat hunting इस gap को भरता है क्योंकि एक human actively data को question करता है: क्या finance workstation से 2 a.m. पर यह PowerShell invocation sense बनाता है? svchost.exe reverse DNS के बिना एक IP को outbound connection क्यों बना रहा है?

यह incident response नहीं है। IR तब शुरू होता है जब आप जानते हैं कि कुछ हुआ है। Hunting तब शुरू होता है जब आप अभी नहीं जानते, और लक्ष्य यह पता लगाना है कि एक बड़ी घटना सवाल को force करने से पहले।

The three common starting points

अधिकांश hunts तीन angles में से एक से शुरू होते हैं:

• Intelligence-driven: एक नई threat report एक TTP को describe करती है (कहें, persistence के लिए एक scheduled task का abuse), और आप check करते हैं कि यह आपके environment में present है या नहीं।
• Situational awareness: आप देखते हैं कि आपके organization के लिए क्या वास्तव में unusual है — एक service account जो एक ऐसे country से authenticate कर रहा है जहाँ वह कभी नहीं था, या workstations के बीच SMB traffic में spike जो normally केवल servers से बात करते हैं।
• Analytics-driven: आप normal behavior का एक baseline build करते हैं (process trees, login times, DNS query volume) और इसके खिलाफ statistical outliers के लिए hunt करते हैं।

MITRE ATT&CK वह reference है जिसे अधिकांश teams hypotheses को structure करने के लिए use करती हैं। "malware के लिए look करो" की बजाय, आप एक technique जैसे T1053 (Scheduled Task/Job) pick करते हैं और पूछते हैं: यह हमारे Windows Event Logs या EDR telemetry में कैसा दिखेगा, और क्या मैं इसके लिए अभी query कर सकता हूँ?

What the actual workflow looks like

एक hunt आमतौर पर इस loop को follow करता है:

1. एक specific, testable hypothesis form करें ("intrusions के लिए check करो" नहीं बल्कि "patch windows के बाहर created last 30 days में नए scheduled tasks के लिए check करो")।
2. आवश्यक data sources को identify करें — 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. Results को triage करें — अधिकांश false positives या benign admin activity होंगे, और काम उस noise को genuinely anomalous तक narrow करना है।
5. Findings को document करें, चाहे वह एक confirmed compromise हो, एक detection gap हो, या बस एक