Berserko - Burp Suite के लिए Kerberos प्रमाणीकरण

NCC Group Plc द्वारा ओपन सोर्स के रूप में जारी - http://www.nccgroup.trust/

Richard Turnbull द्वारा विकसित, richard [dot] turnbull [at] nccgroup [dot] com

http://www.github.com/nccgroup/Berserko

AGPL के अंतर्गत जारी, अधिक जानकारी के लिए LICENSE देखें

❗ महत्वपूर्ण नोट ❗

Berserko का आगे का विकास https://github.com/rteatea/Berserko पर होगा

परिचय

Berserko एक Burp एक्सटेंशन है जो Kerberos प्रमाणीकरण करने के लिए समर्थन जोड़ता है। यह Windows डोमेन में परीक्षण के लिए उपयोगी है जब NTLM प्रमाणीकरण समर्थित नहीं होता है (Burp पहले से ही NTLM को संभालता है)। Berserko के लिए यह आवश्यक नहीं है कि Burp चलाने वाली मशीन डोमेन से जुड़ी हो (या यहाँ तक कि वह Windows चला रही हो)।

Burp का उपयोग करके Kerberos अनुप्रयोगों के परीक्षण के लिए वर्तमान में हमें ज्ञात एकमात्र मौजूदा समाधान Fiddler के माध्यम से श्रृंखला बनाना है, जिसमें इन निर्देशों के अनुसार प्रमाणीकरण सेट किया गया हो। लेकिन Fiddler केवल Windows के लिए है, और प्रॉक्सी की श्रृंखला बनाने से जटिलता बढ़ती है और प्रदर्शन बाधित होता है, इसलिए Burp के भीतर ही Kerberos क्षमता होना अच्छा है।

सिस्टम आवश्यकताएँ

• Burp Suite
• Windows और Linux (Kali) पर परीक्षण किया गया

स्थापना

Releases टैब से, या berserko\releases फ़ोल्डर से नवीनतम Berserko jar फ़ाइल प्राप्त करें

Burp में Extender टैब पर जाएँ, Add चुनें, सुनिश्चित करें कि Extension type के रूप में Java चुना गया है, और फिर इसे jar फ़ाइल की ओर इंगित करें। सब ठीक रहने पर, Berserko टैब Burp UI में जुड़ जाना चाहिए।

त्वरित आरंभ

• Berserko टैब पर जाएँ और Do Kerberos authentication चेकबॉक्स को चिह्नित करें।
• Domain Settings पैनल में Change बटन पर क्लिक करें और डोमेन का DNS नाम (NETBIOS नाम नहीं) तथा किसी KDC (डोमेन कंट्रोलर) का होस्टनाम (या IP पता) प्रदान करें।
• Test domain settings बटन दबाएँ और जाँचें कि आपको Successfully contacted Kerberos service प्रतिक्रिया मिलती है।
• Domain Credentials पैनल में Change बटन पर क्लिक करें और एक डोमेन खाते के लिए उपयोगकर्ता नाम और पासवर्ड प्रदान करें (केवल सादा उपयोगकर्ता नाम, न कि MYDOMAIN\user या [email protected] या ऐसा कुछ भी)।
• Berserko को आपके लिए krb5.conf फ़ाइल बनाने देकर Kerberos प्रतिनिधिमंडल सक्षम करें। Delegation पैनल में Create krb5.conf file बटन पर क्लिक करें और एक उपयुक्त स्थान चुनें जहाँ फ़ाइल बनाई जा सके। कोई भी स्थान चलेगा। आप किसी भी मौजूदा सिस्टम-स्तरीय krb5.conf फ़ाइल को ओवरराइट नहीं करना चाहेंगे। जब Berserko पूछे कि क्या आप इसे krb5.conf फ़ाइल के रूप में सेट करना चाहते हैं, तो हाँ कहें। यह बुरा है कि हमें ऐसा करना पड़ता है (एक फ़ाइल बनाना) लेकिन यह Berserko की गलती नहीं है और न ही Burp की गलती है - यह Java Kerberos APIs की एक सीमा है। अधिक जानकारी के लिए नीचे Delegation पर दिए गए नोट देखें।
• Test credentials बटन दबाएँ और जाँचें कि आपको "TGT successfully acquired" प्रतिक्रिया मिलती है। उम्मीद है कि इसमें यह भी कहेगा कि "TGT is forwardable so delegation should work"।
• Kerberos प्रमाणीकरण अब निर्दिष्ट डोमेन में होस्टों के लिए कार्यशील हो जाना चाहिए।

सेटिंग्स

Burp में Berserko टैब पर विभिन्न नियंत्रण हैं।

Do Kerberos authentication चेकबॉक्स एक मास्टर स्विच है। जब तक इसे सक्षम नहीं किया जाता, Berserko कुछ भी नहीं करेगा।

Restore defaults बटन Berserko को डिफ़ॉल्ट कॉन्फ़िगरेशन पर लौटा देगा (जिसमें कोई डोमेन विवरण या उपयोगकर्ता क्रेडेंशियल मौजूद नहीं हैं)।

Clear Kerberos state बटन क्लाइंट पर सभी Kerberos टिकट और अन्य स्थिति को साफ़ कर देगा। आपको इसका उपयोग करने की आवश्यकता केवल तभी पड़ सकती है यदि सर्वर पक्ष पर Kerberos कॉन्फ़िगरेशन में परिवर्तन किए गए हों और आप एक नई स्थिति से शुरू करना चाहते हों।

Write tickets to log बटन आपके वर्तमान Kerberos टिकटों के बारे में जानकारी Berserko की लॉग स्ट्रीम में लिखेगा - यह डिबगिंग/समस्या निवारण के लिए उपयोगी हो सकता है। लॉग देखने के लिए Burp के Extender टैब पर जाएँ, Berserko चुनें और नीचे Output टैब देखें। यहाँ Save to file विकल्प का उपयोग करना समझदारी हो सकती है, क्योंकि टिकट डेटा GUI में लॉग बफर को आसानी से भर सकता है।

कुछ नियंत्रणों में एक सहायता बटन होता है जो अधिक जानकारी पॉप अप करेगा।

डोमेन सेटिंग्स

इस अनुभाग में नियंत्रणों का उपयोग करके Domain DNS Name और KDC Host निर्दिष्ट करें। टेक्स्टबॉक्स को सीधे संपादित नहीं किया जा सकता; उन्हें संशोधित करने के लिए आपको 'Change' बटन का उपयोग करना होगा।

Domain DNS Name उस डोमेन का DNS नाम होना चाहिए जिसके विरुद्ध आप प्रमाणीकरण करना चाहते हैं (सटीक कहें तो, यह वास्तव में Kerberos रियल्म है)। यह कुछ ऐसा होना चाहिए जैसे mydomain.acme.local। यह डोमेन का NETBIOS नाम नहीं होना चाहिए (जो कुछ ऐसा होगा जैसे MYDOMAIN)।

KDC Host एक Kerberos KDC (Key Distribution Center) का होस्टनाम (या IP पता) होना चाहिए। Windows डोमेन में, KDC बस एक डोमेन कंट्रोलर होता है।

Domain DNS Name प्रदान करने के बाद, आप स्वचालित रूप से KDC का पता लगाने के प्रयास के लिए Auto बटन का उपयोग कर सकते हैं। यह Kerberos सेवा के लिए DNS SRV क्वेरी भेजकर ऐसा करता है। यदि आपके DNS सर्वरों में से एक सही डोमेन के लिए डोमेन कंट्रोलर है, तो यह काम करना चाहिए। यदि नहीं, तो यह काम नहीं करेगा। ❗यह कार्यक्षमता Burp के हाल के संस्करणों में काम नहीं करेगी, क्योंकि आवश्यक DNS लाइब्रेरी बंडल किए गए JRE के भाग के रूप में शामिल नहीं की जा रही हैं। आप इस README के शीर्ष पर वर्णित अनुसार पूर्ण JRE के अंतर्गत लॉन्च करके इससे बच सकते हैं।❗

जब Domain DNS Name और KDC Host दर्ज कर लिए गए हों, तो कनेक्टिविटी का परीक्षण करने के लिए Test domain settings बटन का उपयोग करें। सब ठीक रहने पर, आपको Successfully contacted Kerberos service प्रतिक्रिया मिलेगी।

इन Domain Settings के लिए सही मान प्राप्त करने के बारे में अधिक जानकारी के लिए यह फ़ाइल देखें।

डोमेन क्रेडेंशियल्स

इस अनुभाग में नियंत्रणों का उपयोग करके डोमेन खाते के लिए Username और Password निर्दिष्ट करें। टेक्स्टबॉक्स को सीधे संपादित नहीं किया जा सकता; उन्हें संशोधित करने के लिए आपको 'Change' बटन का उपयोग करना होगा।

Username केवल सादा उपयोगकर्ता नाम होना चाहिए। यह कुछ ऐसा होना चाहिए जैसे bob। यह MYDOMAIN\bob या [email protected] या समान नहीं होना चाहिए।

क्रेडेंशियल प्रदान करने के बाद, आप Test credentials बटन का उपयोग कर सकते हैं। यह निर्दिष्ट उपयोगकर्ता के लिए Kerberos टिकट-ग्रांटिंग टिकट प्राप्त करने का प्रयास करेगा। सफल होने पर, आपको TGT successfully acquired प्रतिक्रिया मिलेगी। यदि सफल नहीं होता है, तो ध्यान दें कि यह एक डोमेन प्रमाणीकरण प्रयास है, इसलिए सावधान रहें कि आपका खाता लॉक न हो।

पासवर्ड अगली बार के लिए Berserko कॉन्फ़िग में सहेजा नहीं जाएगा जब तक कि Save password in Burp config? चेकबॉक्स चिह्नित न किया गया हो। हालाँकि, अन्य सभी सेटिंग्स सहेजी जाएँगी।

प्रतिनिधिमंडल (Delegation)

कुछ अनुप्रयोग क्लाइंट की पहचान को अन्य सर्वरों तक अग्रेषित करने के लिए सर्वर पक्ष पर Kerberos प्रतिनिधिमंडल का उपयोग करते हैं (लेकिन क्लाइंट पक्ष से यह निर्धारित करने का कोई आसान तरीका नहीं है कि यह उपयोग में है या नहीं)।

Berserko इसका समर्थन करता है, लेकिन एक समस्या है। प्रतिनिधिमंडल तभी काम करता है जब उपयोगकर्ता के पास एक forwardable TGT (टिकट-ग्रांटिंग टिकट) हो। Kerberos का Java कार्यान्वयन दुर्भाग्य से प्रोग्रामेटिक रूप से यह निर्दिष्ट करने का कोई तरीका प्रदान नहीं करता है कि एक forwardable टिकट प्राप्त किया जाना चाहिए। यह केवल krb5.conf कॉन्फ़िगरेशन फ़ाइल में एक उपयुक्त प्रविष्टि जोड़कर किया जा सकता है।

इसलिए, प्रतिनिधिमंडल के काम करने के लिए, Berserko को एक उपयुक्त krb5.conf फ़ाइल की ओर इंगित किया जाना चाहिए, और यहाँ दो संभावित दृष्टिकोण हैं।

सबसे आसान काम, और अनुशंसित दृष्टिकोण, Create krb5.conf file बटन का उपयोग करना है। यह आपकी पसंद के स्थान पर आपके लिए एक उपयुक्त फ़ाइल बनाएगा। आप इसे अस्थायी निर्देशिका में, या अपनी प्रोजेक्ट निर्देशिका में, या कहीं भी रख सकते हैं। लेकिन उसी फ़ाइल का अनिश्चित काल तक पुन: उपयोग किया जा सकता है, इसलिए इसे किसी अधिक स्थायी स्थान पर रखना समझदारी हो सकती है। Change बटन आपको उपयोग की जाने वाली एक अलग फ़ाइल चुनने देता है।

यदि आपकी रुचि है, तो जो krb5.conf फ़ाइल बनाई जाती है वह बहुत सरल है, और उसमें निम्नलिखित सामग्री होगी:

[libdefaults]
    forwardable = true

वैकल्पिक रूप से, आप सिस्टम पर मौजूदा krb5.conf फ़ाइल की ओर इंगित करने के लिए Change बटन का उपयोग कर सकते हैं। आप ऐसा केवल तभी करना चाहेंगे यदि इस फ़ाइल में अन्य महत्वपूर्ण Kerberos सेटिंग्स हों जिन्हें Berserko द्वारा ग्रहण किया जाना चाहिए (जो सिद्धांत रूप में ठीक काम करना चाहिए, लेकिन व्यवहार में परीक्षण नहीं किया गया है)। ध्यान दें कि Linux पर इस फ़ाइल का डिफ़ॉल्ट स्थान /etc/krb5.conf है - अन्य ऑपरेटिंग सिस्टम में इसके होने की संभावना कम है। यदि आप किसी मौजूदा krb5.conf फ़ाइल की ओर इंगित कर रहे हैं, तो सुनिश्चित करें कि आप फ़ॉरवर्डिंग सक्षम करने के लिए इसे संपादित करें - [libdefaults] अनुभाग में forwardable = true जोड़ें (या प्रत्येक रियल्म के लिए अलग से)। लेकिन सावधान रहें। Berserko से आपके लिए फ़ाइल बनवाना 99% समय बेहतर विकल्प होगा।

यदि आप जानना चाहते हैं कि आपका प्रतिनिधिमंडल कॉन्फ़िगरेशन सफल है या नहीं, तो Check current config बटन का उपयोग करें। यह आपको बताएगा कि krb5.conf फ़ाइल का पता लगाया गया है या नहीं, और forwardable सेटिंग सही है या नहीं। यह भी ध्यान दें कि जब आप Test credentials बटन का उपयोग करेंगे तो Berserko आपको बताएगा कि उसने सफलतापूर्वक एक forwardable TGT प्राप्त किया या नहीं।

किसी अनुप्रयोग का उपयोग शुरू करने से पहले यह सुनिश्चित करना एक अच्छा विचार है कि आपके पास एक forwardable टिकट है। ऐसा प्रतीत होता है कि IIS सर्वर पक्ष पर उपयोगकर्ता की प्रमाणीकरण स्थिति को इस तरह कैश कर सकता है कि गैर-फ़ॉरवर्डेबल टिकट से फ़ॉरवर्डेबल टिकट पर स्विच करना काम नहीं करेगा।

प्रमाणीकरण रणनीति

इस अनुभाग में सेटिंग्स नियंत्रित करती हैं कि Berserko Kerberos प्रमाणीकरण 'प्रतिक्रियात्मक रूप से' (reactively) करता है (यानी सर्वर से 401 प्रतिक्रिया मिलने की प्रतीक्षा करें और फिर Kerberos प्रमाणीकरण हेडर जोड़कर अनुरोध को पुनः भेजें) या 'सक्रिय रूप से' (proactively) (यानी बाहर जाने वाले अनुरोध में Kerberos प्रमाणीकरण हेडर जोड़ें)।

सक्रिय प्रमाणीकरण का लाभ यह है कि इसमें केवल एक HTTP राउंड ट्रिप की आवश्यकता होती है, जबकि प्रतिक्रियात्मक प्रमाणीकरण में दो की आवश्यकता होती है। सक्रिय प्रमाणीकरण का नुकसान यह है कि यह संभव है कि Kerberos प्रमाणीकरण हेडर उन होस्टों को भेजे जाएँ जो उनकी उम्मीद नहीं कर रहे हैं। प्रतिक्रियात्मक रणनीति का उपयोग करते समय Berserko प्रमाणीकरण त्रुटियों का निदान करने में भी बेहतर सक्षम है।

Proactive Kerberos authentication, only after initial 401 received विकल्प इन दोनों दृष्टिकोणों का एक संकर है, जहाँ Berserko किसी होस्ट के लिए पहले अनुरोध पर प्रतिक्रियात्मक रूप से प्रमाणीकरण करेगा, लेकिन उसके बाद सक्रिय रहेगा।

कार्यक्षेत्र (Scope)

इस अनुभाग में, आप परिभाषित कर सकते हैं कि Kerberos प्रमाणीकरण के लिए कौन से होस्ट कार्यक्षेत्र में माने जाते हैं।

डिफ़ॉल्ट रूप से, All hosts in this Kerberos domain in scope for Kerberos बॉक्स चिह्नित होगा। इसका मतलब है कि Berserko केवल उन वेब सर्वरों के लिए Kerberos प्रमाणीकरण का प्रयास करेगा जिनका होस्टनाम डोमेन DNS नाम के साथ समाप्त होता है। कई स्थितियों में यह पर्याप्त होगा। हालाँकि, ऐसे Kerberos-सक्षम वेब अनुप्रयोग होना संभव है जिनका होस्टनाम इस रूप का नहीं है (यह मानते हुए कि व्यवस्थापक ने एक उपयुक्त Service Principal Name सेट किया है)। इसे ध्यान में रखने के लिए, आप दाईं ओर की सूची बॉक्स का उपयोग करके कार्यक्षेत्र में माने जाने वाले अतिरिक्त होस्ट जोड़ सकते हैं। ध्यान दें कि वाइल्डकार्ड का उपयोग किया जा सकता है (* शून्य या अधिक वर्णों से मेल खाता है, ? डॉट को छोड़कर किसी भी वर्ण से मेल खाता है)।

वैकल्पिक रूप से, आप All hosts in scope for Kerberos authentication बॉक्स को चिह्नित कर सकते हैं। जाहिर है इसका लाभ यह है कि आपको कार्यक्षेत्र को मैन्युअल रूप से निर्दिष्ट करने की आवश्यकता नहीं है। इस कॉन्फ़िगरेशन का संभावित नुकसान यह है कि यह Berserko को उन होस्टों के लिए सेवा टिकट प्राप्त करने हेतु KDC को Kerberos अनुरोध भेजने के लिए प्रेरित कर सकता है जो डोमेन में नहीं हैं। इससे प्रदर्शन संबंधी समस्याएँ हो सकती हैं, और गोपनीयता संबंधी समस्याएँ भी हो सकती हैं (यदि आप नहीं चाहते कि यह जानकारी KDC को लीक हो)। यह विशेष रूप से Proactive Kerberos authentication रणनीति के साथ एक समस्या होने की संभावना है, ऐसी स्थिति में Berserko Burp से गुजरने वाले हर अनुरोध में Kerberos प्रमाणीकरण हेडर जोड़ने का प्रयास करेगा। विकल्पों का यह संयोजन अनुशंसित नहीं है, और यदि इसे चुना जाता है तो Berserko आपको चेतावनी देगा (लेकिन वास्तव में इसे रोकेगा नहीं)।

यदि न तो All hosts in this Kerberos domain in scope for Kerberos और न ही All hosts in scope for Kerberos authentication चुने गए हैं, तो कार्यक्षेत्र में केवल वही होस्ट होंगे जो सूची बॉक्स में जोड़े गए हैं।

Plain hostnames considered part of domain विकल्प, यदि चुना जाता है, तो इसका मतलब है कि 'प्लेन होस्टनाम' (यानी वे होस्टनाम जिनमें केवल एक घटक होता है) को डोमेन का हिस्सा माना जाएगा (और इसलिए यदि All hosts in this Kerberos domain in scope for Kerberos चुना गया है तो स्वचालित रूप से कार्यक्षेत्र में)। आप इसे अक्षम करना चाहेंगे इसका मुख्य कारण यह होगा कि आपकी मशीन उस डोमेन से भिन्न डोमेन से जुड़ी हुई थी जिसके विरुद्ध Berserko का उपयोग करके प्रमाणीकरण किया जा रहा है (ऐसी स्थिति में, प्लेन होस्टनाम संभवतः उस डोमेन के होस्टों को संदर्भित करते हैं जिससे आप जुड़े हुए हैं)।

यदि चुना जाता है, तो Do not perform Kerberos authentication to servers which support NTLM विकल्प Berserko को उन होस्टों के विरुद्ध Kerberos प्रमाणीकरण का प्रयास न करने का निर्देश देगा जो Kerberos के अतिरिक्त NTLM का भी समर्थन करते हैं (यानी वे होस्ट जो WWW-Authenticate: NTLM और WWW-Authenticate: Negotiate दोनों हेडर लौटाते हैं)।

लॉगिंग

Alert Level और Logging Level को यहाँ कॉन्फ़िगर किया जा सकता है, या तो NONE, NORMAL या VERBOSE।

Alert Level Burp के Alerts टैब पर भेजी गई जानकारी की मात्रा को नियंत्रित करता है।

Logging Level Berserko के मानक आउटपुट पर भेजी गई जानकारी की मात्रा को नियंत्रित करता है (इसे Extender टैब पर देखा जा सकता है)। ध्यान दें कि Logging Level को VERBOSE तक बढ़ाने से किसी भी त्रुटि या अपवाद के बारे में अधिक जानकारी प्रदान की जाएगी।

डोमेन ट्रस्ट

यदि आपके वातावरण में Kerberos डोमेन ट्रस्ट उपयोग में हैं, तो आप यहाँ कुछ मार्गदर्शन पा सकते हैं।

पोर्ट फ़ॉरवर्डिंग / TCP पर Kerberos

डिफ़ॉल्ट रूप से, Berserko KDC के साथ सभी Kerberos इंटरैक्शन UDP (पोर्ट 88) पर करता है। यदि आप इसके बजाय TCP का उपयोग करना चाहते हैं, तो यह संभव है। ऐसा करने का सबसे आम कारण संभवतः वह स्थिति है जहाँ TCP पोर्ट 88 के लिए SSH पोर्ट फ़ॉरवर्ड उपयोग में है। बस अपनी krb5.conf फ़ाइल में udp_preference_limit = 1 जोड़ें, ताकि यह ऐसा दिखे:

[libdefaults]
    forwardable = true
    udp_preference_limit = 1
	

उन्नत कॉन्फ़िगरेशन

किसी विशेष होस्ट के लिए उपयोग किए जाने वाले SPN को कॉन्फ़िगर करना संभव है, krb5.conf फ़ाइल में [berserko_spn_hints] अनुभाग शामिल करके (ऊपर देखें)। सिंटैक्स नीचे दिखाया गया है।

[berserko_spn_hints]
    [email protected]
	server2.bar.org=app.domain2.local
	

लक्ष्य सर्वर बराबर चिह्न के बाईं ओर है, और उपयोग किया जाने वाला SPN दाईं ओर है। SPN के लिए रियल्म वैकल्पिक रूप से निर्दिष्ट किया जा सकता है (यदि नहीं, तो Berserko सामान्य रूप से सही रियल्म निर्धारित करने का प्रयास करेगा)। SPN का HTTP/ भाग यहाँ शामिल न करें।

बग्स

• यदि Berserko टैब का UI ठीक से प्रदर्शित नहीं होता है, तो Burp की Metal थीम का उपयोग करने का प्रयास करें।

सीमाएँ

• Berserko Burp की अपनी Platform Authentication सुविधा के साथ विशेष रूप से अच्छी तरह से काम नहीं करेगा। Platform Authentication को सक्षम रखना ठीक है, लेकिन इसे उन होस्टों के लिए कॉन्फ़िगर न करें जिन्हें Kerberos (NTLM के बजाय) प्रमाणीकरण की आवश्यकता होती है।
• Berserko KDC होस्टनाम को हल करते समय Burp की Hostname Resolution सुविधा का उपयोग करके परिभाषित किसी भी कस्टम होस्ट मैपिंग का उपयोग नहीं कर सकता। यदि यह एक समस्या है, तो KDC host बॉक्स में KDC का IP पता निर्दिष्ट करें। ध्यान दें कि यह Burp से भेजे जा रहे वास्तविक अनुरोधों के लिए कोई समस्या नहीं है, केवल Berserko के KDC के साथ स्वयं के संचार के लिए है।

(संभावित) भविष्य की योजनाएँ

• डोमेन-जुड़ी मशीनों पर पहले से प्राप्त Kerberos टिकटों का उपयोग (निश्चित नहीं कि यह संभव है या नहीं)
• एक ही समय में कई डोमेनों में प्रमाणीकरण करने की क्षमता (यह ठीक काम करना चाहिए)
• forwardable टिकटों और प्रतिनिधिमंडल पर बेहतर नियंत्रण

❗ महत्वपूर्ण नोट ❗

Berserko v2020.5.1 से पहले के Burp v2 के साथ संगत नहीं है। Burp v1 के साथ कोई समस्या नहीं है।

यह पुराने Burp 2 संस्करणों के साथ भेजे जा रहे OpenJDK के संस्करण के कारण होता है, जिसमें Berserko द्वारा उपयोग की जाने वाली कुछ Kerberos कार्यक्षमता शामिल नहीं है। इससे Berserko का उपयोग करने का प्रयास करते समय java.lang.ClassNotFoundException: com.sun.security.jgss.ExtendedGSSContext त्रुटि उत्पन्न होगी।

स्पष्ट समाधान v2020.5.1 या बाद के संस्करण में अपग्रेड करना है। वैकल्पिक रूप से, यदि आप Java रनटाइम एनवायरनमेंट के पूर्ण संस्करण (यानी Burp के साथ बंडल किया गया नहीं) का उपयोग करके लॉन्च करते हैं तो Berserko किसी भी Burp v2 संस्करण के साथ काम करना चाहिए।

यह मानते हुए कि java आपके path में उपलब्ध है:

java -jar burpsuite_pro.jar

कमांड लाइन से लॉन्च करने के बारे में Burp प्रलेखन देखें।