LLM-आधारित हैकिंग exploit generation का औद्योगीकरण करीब आ रहा है

• Opus 4.5 और GPT-5.2 आधारित एजेंट्स ने QuickJS zero-day vulnerability का उपयोग करके 6 परिदृश्यों में 40 से अधिक exploits तैयार किए
• GPT-5.2 ने सभी कार्य हल किए, और Opus 4.5 ने दो को छोड़कर सभी कार्य हल किए, जिससे स्वायत्त code analysis, debugging, और exploit chain निर्माण क्षमता दिखाई दी
• प्रयोग के नतीजे बताते हैं कि exploit development मानव हैकरों की संख्या नहीं, बल्कि token throughput से सीमित हो सकता है
• vulnerability detection और exploit generation पहले ही उस चरण में पहुंच चुके हैं जहां token input के अनुपात में प्रदर्शन बढ़ता है
• आगे चलकर cyber attack automation और security evaluation framework के पुनर्गठन की आवश्यकता पर जोर दिया गया है

---

प्रयोग का अवलोकन

• Opus 4.5 और GPT-5.2 का उपयोग करके QuickJS JavaScript interpreter की zero-day vulnerability को लक्ष्य बनाकर exploit generation प्रयोग किया गया
  • विभिन्न exploit mitigation techniques (ASLR, NX, RELRO, CFI, shadow stack, seccomp आदि) लागू की गईं
  • एजेंट्स ने shell generation, file write, C2 connection जैसे कई लक्ष्यों को हासिल किया
• GPT-5.2 ने सभी परिदृश्य हल किए, जबकि Opus 4.5 ने दो को छोड़कर सभी कार्य हल किए
  • प्रत्येक रन पर अधिकतम 3 करोड़ tokens की सीमा थी, लागत लगभग 30 डॉलर
  • सबसे कठिन कार्य में 5 करोड़ tokens, लगभग 3 घंटे, और 50 डॉलर की लागत से समाधान मिला
• GPT-5.2 ने seccomp sandbox और shadow stack सक्षम वातावरण में glibc की exit handler chain का उपयोग करते हुए 7-स्टेप function call से file write exploit पूरा किया

प्रयोग की सीमाएं

• QuickJS का आकार और जटिलता वास्तविक browser engines की तुलना में बहुत कम है, इसलिए परिणामों के सामान्यीकरण की सीमाएं हैं
• तैयार किए गए exploits ने protection mechanisms की नई कमजोरियां नहीं खोजीं, बल्कि पहले से ज्ञात deployment-level weak points का उपयोग किया
• QuickJS vulnerability स्वयं नई खोजी गई थी, और GPT-5.2 का समाधान तरीका पहले से प्रलेखित न की गई नई chain construction के रूप में आंका गया

intrusion का औद्योगीकरण

• ‘औद्योगीकरण’ से मतलब ऐसी स्थिति से है जहां किसी संगठन की attack capability मानव संसाधन की संख्या नहीं, बल्कि token throughput से तय होती है
• इसके लिए दो शर्तें जरूरी हैं
  • LLM-आधारित एजेंट्स को पर्यावरण के भीतर स्वायत्त रूप से exploration करने में सक्षम होना चाहिए
  • सटीक और तेज verification system मौजूद होना चाहिए
• exploit development इन शर्तों को पूरा करने वाला आदर्श उदाहरण है
  • environment setup आसान है, और verification प्रक्रिया स्पष्ट है
  • उदाहरण: shell-generating exploit के मामले में, port listener के जरिए connection success से सत्यापन संभव है
• इसके विपरीत, real-time interaction की आवश्यकता वाले intrusion, privilege escalation, persistent access maintenance, और data exfiltration का औद्योगीकरण अधिक कठिन है
  • क्योंकि वास्तविक वातावरण में गलत कार्रवाई detection का कारण बन सकती है

मौजूदा चरण

• vulnerability detection और exploit development में पहले ही token input के अनुपात में प्रदर्शन बढ़ रहा है
  • OpenAI के Aardvark project में भी यही प्रवृत्ति देखी गई
  • प्रयोग में भी सीमा बजट की थी, मॉडल की क्षमता की नहीं
• वास्तविक network के भीतर hacking automation अभी भी अनिश्चित है
  • Anthropic की रिपोर्ट के अनुसार चीनी hacking teams द्वारा API-आधारित attack attempts के उदाहरण मौजूद हैं
  • हालांकि पूरी तरह स्वचालित SRE (Site Reliability Engineering) एजेंट्स के व्यावसायिक उपयोग का कोई उदाहरण नहीं है
• यदि SRE automation सफल होता है, तो hostile network के भीतर automated hacking भी संभव होने की संभावना अधिक है

निष्कर्ष और सुझाव

• इस प्रयोग ने cyber domain में automation की सीमा और समयसीमा को लेकर धारणा बदल दी है
• मौजूदा model evaluation methods (CTF, पुरानी vulnerabilities, synthetic data) वास्तविक zero-day attack capability को मापने के लिए उपयुक्त नहीं हैं
• frontier labs और AI security institutions को वास्तविक zero-day targets (जैसे Linux kernel, Firefox) पर evaluation करना चाहिए
  • “X अरब tokens का उपयोग करके Y exploits बनाए गए” जैसे प्रारूप में सार्वजनिक रिपोर्टिंग की जरूरत है
• IoT firmware जैसे वास्तविक उपकरणों को लक्ष्य बनाकर मूल्यांकन की भी आवश्यकता है
  • Opus 4.5 या GPT-5.2 आधारित एजेंट्स के साथ एक सप्ताह के भीतर वास्तविक exploit generation की संभावना प्रस्तुत की गई
• शोधकर्ताओं और इंजीनियरों को स्वयं प्रयोग करने और परिणाम सार्वजनिक करने की सिफारिश की गई
  • प्रयोग का code और data GitHub repository में सार्वजनिक किया गया है

[GN⁺]

Hacker News की राय

• GPT‑5.2 को सबसे कठिन काम के रूप में डिस्क के किसी खास path पर एक string लिखने का तरीका खोजने को कहा गया
  यह QuickJS environment था, जिसमें ASLR, non-executable memory, full RELRO, fine-grained CFI, hardware shadow-stack, seccomp sandbox जैसी सभी protections चालू थीं
  GPT‑5.2 ने glibc की exit handler chain का इस्तेमाल करके 7-स्टेप function call के जरिए समस्या हल की। यह सचमुच चौंकाने वाला नतीजा था

  • ऐसा लगता है कि क्या इन mitigations को ही पूरी तरह हटा देना चाहिए
    असली exploit आम तौर पर “vulnerability ढूँढना (मुश्किल)” और फिर “बेकार की कई-layer mitigations को पार करना (झंझट वाला, लेकिन संभव)” के क्रम में आगे बढ़ता है
    probabilistic mitigation probabilistic attack पर तो काम करती है, लेकिन हमलावर जानबूझकर कमजोरियाँ खोजते हैं
  • आखिरकार machine-code stack के निचले हिस्से में बहुत ज़्यादा छेद हैं
    भविष्य में शायद हमें अफसोस होगा कि हमने पहले ही WASM पर स्विच क्यों नहीं किया
    तब तक हम hardware mitigations पर mitigations जोड़ते रहेंगे और पुराने stack overwrite की समस्या से जूझते रहेंगे
  • “glibc का exit handler”... सिहरन पैदा करने वाली बात है
  • आजकल kill chain का बड़ा हिस्सा कई bugs को जोड़कर इस्तेमाल करता है
    यह मेरा काम है, इसलिए मैं अच्छे से जानता हूँ, और धीरे-धीरे लाचारी की भावना बढ़ रही है
  • यह मामला दिखाता है कि C में बना QuickJS LLM के सामने कितना कमजोर है
    जैसे Use‑After‑Free से libc pointer leak करना
    Rust में यह काफ़ी मुश्किल होता, लेकिन अगर libc calls ज़्यादा हों तो पूरी सुरक्षा फिर भी कठिन है

• GPT‑5.2 का exploit mitigations को नए तरीके से नहीं तोड़ता, बल्कि पहले से ज्ञात implementation gaps का इस्तेमाल करता है
  इंसानी hackers भी आम तौर पर mitigation को नया तोड़ते नहीं हैं
  लेकिन CTF क्षेत्र में अब LLM के one-shot में pwn problem solve करने के मामले बढ़ रहे हैं
  ऐसी प्रगति की वजह से अधूरी mitigation implementations टूटेंगी, और शायद formal exploit modeling पर रिसर्च तेज़ होगी

  • अगर “formal exploit modeling” अभी अपरिपक्व क्षेत्र है, तो पढ़ने लायक materials जानना अच्छा रहेगा

• एक security researcher के नज़रिए से देखें तो, LLM द्वारा बनाया गया read/write primitive API मौजूदा APIs का सिर्फ़ साधारण recombination है
  यह किसी नई technique से ज़्यादा CTF toy binary जैसा लगता है
  लेकिन हाल के OpenAI models आम तौर पर असली exploit code generate करने से बचते हैं, इसलिए यह जानना दिलचस्प है कि क्या इसमें prompt bypass इस्तेमाल हुआ था

• लेखक ने दिलचस्प point उठाया है, लेकिन मैं बहुत ज़्यादा चिंतित नहीं हूँ
  ऐसे tools को defenders भी symmetric तरीके से इस्तेमाल कर सकते हैं
  जैसे CI चरण में “LLM Red Team” चलाकर automated security testing जोड़ना

  • गणितीय रूप से देखें तो यह symmetry नहीं है
    attacker को सिर्फ़ एक बार सफल होना होता है, जबकि defender को हर बार सफल होना पड़ता है
    मौजूदा models में pass@x performance, maj@x से 20~30% बेहतर है
    फिर भी Red vs Blue loop चलाने से सुरक्षा स्तर बेहतर होगा
  • complex systems में यह symmetry टूट जाती है
    attacker को सिर्फ़ एक failure point चाहिए, जबकि defender को सब कुछ रोकना पड़ता है
  • इसका defensive इस्तेमाल पहले से हो रहा है
    उदाहरण: Google Project Zero का Big Sleep project
    संबंधित vulnerabilities की सूची यहाँ देखी जा सकती है
  • यह symmetric हो ही नहीं सकता
    attacker सिर्फ़ एक bug ढूँढकर उसे weaponize कर सकता है, लेकिन defender को हर bug ढूँढना पड़ता है
    यह “any vs all” का asymmetry है
  • maintenance के बिना पड़े software बहुत ज़्यादा हैं
    आखिर में LLM कंपनियाँ ही असली विजेता बनेंगी, जो दोनों पक्षों को tokens बेचेंगी

• यह दिलचस्प है that Codex 5.2 ने सबसे complex exploit ढूँढा
  मैं भी मुख्य रूप से Opus 4.5 इस्तेमाल करता हूँ, लेकिन Codex 5.2 का Extra High thinking mode वाकई ताकतवर है
  मुझे यह बात भरोसेमंद नहीं लगती कि LLM की प्रगति धीमी पड़ गई है। बल्कि tasks इतने कठिन हो गए हैं कि प्रगति कम महसूस होती है

  • असल में इसने exploit “ढूँढा” नहीं, बल्कि पहले से दिए गए vulnerability को exploit करने वाला code लिखा
    logs इस repository में देखे जा सकते हैं
  • Anthropic models tool-user type, OpenAI Codex High reviewer/fixer type, और Gemini creative artist type है
    सबकी style अलग है
  • “काफी कठिन tasks” ज़्यादातर company internal IP के रूप में बँधे रहते हैं
    जब तक उनका commercial value खत्म नहीं होता, वे public नहीं होते

• QuickJS मूल रूप से एक toy project है, जिसमें unpatched vulnerabilities बहुत हैं
  curl जैसे real-world target पर exploit ज़्यादा दिलचस्प होगा

• एक तरफ़ यह दावा है कि LLM बेहतरीन exploit लिखते हैं, और दूसरी तरफ़ यह कि वे बेकार bug reports देते हैं
  क्या दोनों बातें एक साथ सच हो सकती हैं?

  • दोनों पूरी तरह संभव हैं
    LLM की quality user prompts और interpretation skill पर निर्भर करती है
    अगर expert चुनकर इस्तेमाल करे, तो शानदार नतीजे मिल सकते हैं
  • exploit को “क्या यह काम करता है” से साफ़ तौर पर evaluate किया जा सकता है, लेकिन CVE reports की verification कहीं ज़्यादा कठिन है
    auto-generated reports maintainers पर बड़ा बोझ डालती हैं
  • वास्तव में quality का फ़र्क usage pattern पर बहुत निर्भर करता है
    अगर बस “इस program की vulnerabilities ढूँढो” कहा जाए, तो काफ़ी बकवास मिलेगी, लेकिन
    test loop और environment देने पर यह बार-बार सुधार करके सचमुच काम करने वाला output देता है
  • exploit का success criterion स्पष्ट होता है, और यह LLM की लगातार दोहराव करने की क्षमता से अच्छी तरह मेल खाता है
    वहीं bug reports अस्पष्ट होती हैं और उनका evaluation कठिन होता है
  • budget structure भी अलग है
    उदाहरण के लिए, अगर $100 में $50 की एक असली issue और $0.01 की 5000 fake reports मिली हों, तो
    असली हीरा ढूँढना बहुत मुश्किल हो जाता है

• sandbox का वर्णन अस्पष्ट था, इसलिए शुरुआत में यह संदिग्ध लगा
  लेखक की repository देखने पर पता चला कि लक्ष्य “/tmp/pwned में ‘PWNED’ string लिखना” था
  यानी, यह sandbox escape नहीं बल्कि सिर्फ़ file write restriction का मामला था

  • पूरी repository और लेख की रचना कुछ हद तक गलतफ़हमी पैदा करने वाली है
    OOB R/W primitive API बनवाना भी, आखिरकार, पहले से GitHub पर मौजूद हज़ारों examples को reuse करने जैसा ही था

• यह बात असरदार लगी कि “आगे चलकर किसी देश या संगठन की hacking capability, hackers की संख्या से नहीं बल्कि token throughput से तय होगी”

  • असल में संभवतः ऐसे संगठन LLM के ढीले-ढाले code patterns का analysis करके, इंसानों से सीधे general-purpose exploit लिखवा रहे होंगे

• software development की entry barrier और hacking की entry barrier का एक साथ कम होना विस्फोटक संयोजन है
  अब हमें security guardrails और verifiability वाले नए platforms की ज़रूरत है
  non-experts द्वारा लिखे गए code पर निर्भर रहना खतरनाक है

  • मूल तीसरे paragraph में “एक exploit बनाम पूरे system की defense” वाले imbalance का ज़िक्र था; सोच रहा हूँ कि उसे क्यों हटा दिया गया