NoiseHound

डिटेक्शन-अवेयर Active Directory हमला-पथ स्कोरिंग। DreadHost Research | OffsetInspect (PowerShell) और OffsetScan (Rust) का साथी

BloodHound (और उसके ऊपर PlumHound) लक्ष्य तक एक पथ खोजता है। NoiseHound वही ग्राफ़ डेटा ग्रहण करता है और पथों को हॉप-काउंट के बजाय अपेक्षित डिटेक्शन लागत के आधार पर पुनः रैंक करता है, ताकि एक ऑपरेटर "डोमेन एडमिन तक पहुँचने का सबसे शांत तरीका क्या है" पूछ सके, न कि केवल "कोई एक तरीका क्या है"।

यहाँ नए हैं? Operator Walkthrough यह देखने का सबसे तेज़ तरीका है कि यह क्या करता है - इंस्टॉल से लेकर एक लाइव BloodHound CE प्रूफ़ ऑफ़ कॉन्सेप्ट (स्कोर UI में वापस लिखे गए), DeadAir इंजन, और ब्लू-टीम डिटेक्शन-गैप रिपोर्ट तक एक व्यावहारिक, स्क्रीनशॉट-आधारित यात्रा।

प्रोजेक्ट स्थिति (v1.2.0): स्थिर और कई डोमेन पर वास्तविक BloodHound डेटा पर परीक्षित। 77 कॉर्पस एजों में से 37 लैब-मापित हैं पाँच ऑन-प्रेम डिटेक्शन टियर (Windows audit, Defender for Endpoint, Elastic SIEM, Defender for Identity रनटाइम अलर्ट, और WDAC audit) के साथ-साथ एक मापित Azure/Entra टियर में - profiles/ में छह ड्रॉप-इन प्रोफ़ाइल के रूप में शिप किए गए, साथ में क्लोज़्ड-लूप प्रमाण कि वे पथ रैंकिंग बदलते हैं (docs/VALIDATION.md)। कॉर्पस में 13 Azure/Entra एजें हैं (docs/AZURE.md), जिन्हें सीधे AzureHound आउटपुट से ग्रहण किया जा सकता है। अमापित ऑन-प्रेम और सभी Azure एजों में विशेषज्ञ अनुमान हैं; कैलिब्रेशन हार्नेस (noisehound-calibrate) ही वह माध्यम है जिससे वे, और आपका अपना वातावरण, मापे जाते हैं। अकैलिब्रेटेड रैंकिंग को सुविचारित मार्गदर्शन मानें, न कि ग्राउंड ट्रुथ।

केवल अधिकृत एंगेजमेंट के लिए। यह टूल उन सिस्टमों के विरुद्ध OPSEC योजना के लिए हमला-पथों को स्कोर करता है जिन्हें परीक्षण करने की आपके पास लिखित अनुमति है।

NoiseHound एक स्वतंत्र सामुदायिक प्रोजेक्ट है। यह SpecterOps या BloodHound प्रोजेक्ट से संबद्ध, समर्थित या जुड़ा नहीं है; यह BloodHound के खुले डेटा फ़ॉर्मेट का उपभोग करता है।

---

यह कैसे काम करता है

1. Ingest करें BloodHound CE export (.zip), एक raw JSON फ़ाइल, या exports की एक directory को internal graph में। एक normalised {nodes, edges} JSON format भी offline analysis और tests के लिए स्वीकार किया जाता है। AD CS ESC1-8 escalation edges load time पर certificate-template और CA facts से synthesised होते हैं जो BloodHound collect करता है (नीचे देखें)।
2. edge-telemetry corpus से हर edge को Annotate करें, एक effective_noise_score (0-100) संलग्न करते हुए। जहाँ कई rights एक ही pair of nodes को जोड़ते हैं, वहाँ सबसे quietest चुना जाता है। corpus में अनुपस्थित edge types एक conservative score (60) पर default होते हैं ताकि gaps fail safe हों, under-reporting के बजाय। एक optional environment profile target के declared detection posture के लिए scores को adjust करता है (नीचे देखें)।
3. quietest paths के लिए Solve करें। चूँकि path score एक bottleneck plus mean है (साधारण sum नहीं), इसे Dijkstra द्वारा सीधे optimise नहीं किया जा सकता। solver एक threshold sweep (प्रत्येक distinct noise level के लिए, सबसे quietest route जो उसके नीचे रहता है) को bounded k-shortest-by-weight pass के साथ जोड़ता है, फिर union को real path score द्वारा re-rank करता है। threshold sweep correctness backstop है: यह एक long-but-uniformly-quiet path को सामने लाता है जिसे pure summed-weight search एक short-but-loud path से नीचे rank करेगा।
4. text, JSON (OffsetInspect result schema के साथ interoperable), या toolset से मेल खाने के लिए styled एक self-contained HTML report के रूप में Report करें।

Path scoring

Path noise जानबूझकर एक साधारण sum नहीं है। एक ही detection को दो बार trigger करना दोगुना loud नहीं होता (SOC triage, raw event count नहीं)। NoiseHound उपयोग करता है:

path_score = max(edge_scores) * 0.6 + mean(edge_scores) * 0.4

यह सबसे तेज़ एकल चरण की ओर झुकता है (एक खराब चरण अक्सर पूरे ऑपरेशन को बर्बाद कर देता है) जबकि संचयी जोखिम को भी ध्यान में रखता है। भार कॉन्फ़िगर करने योग्य हैं (--max-weight / --mean-weight) ताकि APT29/Caldera लैब से वास्तविक डिटेक्शन डेटा उपलब्ध होने पर उन्हें अनुभवजन्य रूप से ट्यून किया जा सके।

प्रत्येक पथ एक डिटेक्शन प्रायिकता भी रिपोर्ट करता है - किसी सहसंबद्ध अलर्ट को ट्रिगर करने की संभावना - जो सबसे तेज़ किनारे को सभी किनारों के संचयी noisy-OR के साथ मिलाती है (--correlation द्वारा ट्यून की गई)। यह शोर स्कोर से एक अलग प्रश्न का उत्तर देती है: एक छोटा लेकिन तेज़ पथ, एक लंबे लेकिन शांत पथ की तुलना में पकड़े जाने की कम समग्र प्रायिकता रख सकता है। इसे --rank-by probability के साथ रैंक करें।

दो-स्तरीय इंजन (DeadAir)

बड़े ग्राफ़ के लिए, समाधान DeadAir को सौंपा जाता है, जो एक साथी Rust इंजन है (OffsetScan-to-OffsetInspect स्तर)। NoiseHound सुविधा-संपन्न फ्रंटएंड बना रहता है - अंतर्ग्रहण, कॉर्पस, पर्यावरण/Sigma, बाधाएँ, रिपोर्टिंग - और तैयार ग्राफ़ को उस इंजन को सौंप देता है जो इसे हल करता है, इसलिए परिणाम दोनों तरह से समान होते हैं।

• --engine auto (डिफ़ॉल्ट): DeadAir जब इसकी बाइनरी मिलती है और ग्राफ़ बड़ा है (>= 5000 नोड्स); अन्यथा अंतर्निहित Python सॉल्वर।
• --engine python: अंतर्निहित सॉल्वर को बाध्य करें (किसी बाइनरी की आवश्यकता नहीं)।
• --engine rust: DeadAir को बाध्य करें (यदि बाइनरी अनुपस्थित है तो त्रुटि देता है)।

DeadAir $NOISEHOUND_DEADAIR, फिर PATH, फिर सहोदर ../deadair/target/{release,debug}/ बिल्ड के माध्यम से खोजा जाता है। यह बड़े ग्राफ़ पर 10-100x तेज़ है (250k-नोड ग्राफ़ ~2s में हल होता है बनाम Python में ~30s) जबकि बाइट-समान रैंकिंग उत्पन्न करता है। आउटपुट रिकॉर्ड करता है कि कौन सा इंजन चला।

बहु-उद्देश्यीय और बाधित पाथिंग

शोर, हॉप गणना, और डिटेक्शन प्रायिकता अलग-अलग दिशाओं में खींचते हैं, इसलिए --pareto Pareto फ्रंटियर लौटाता है - प्रत्येक वह पथ जिसे कोई अन्य तीनों पर एक साथ नहीं हराता - एकल विजेता को बाध्य करने के बजाय। और वास्तविक ऑपरेशनों में बाधाएँ होती हैं: --avoid NODE किसी पथ को एक विशिष्ट होस्ट (EDR-निगरानी वाला जंप बॉक्स, एक हनीपॉट) से दूर रखता है, और --avoid-edge TYPE किसी तकनीक को अस्वीकार करता है (जैसे --avoid-edge DCSync)। दोनों पुनरावर्तनीय हैं और तुरंत पुनः-हल करते हैं।

python -m noisehound -i export.zip -s jdoe -o "Domain Admins" --pareto
python -m noisehound -i export.zip -s jdoe -o "Domain Admins" --avoid FILESERVER01 --avoid-edge HasSession

NoiseHound की तुलना

भारित BloodHound पाथफाइंडिंग नई नहीं है, इसलिए यहाँ ईमानदार स्थिति प्रस्तुत है: