Vibehacking L+1 — tajribali red-team uchun subagent orkestratsiyasi Вайбхакинг L+1 — оркестрация субагентов для опытного red-team инженера Vibehacking L+1 — subagent orchestration for experienced red teamers

1. Subagent orkestratsiyasi — fan-out / fan-in / DAG

Asosiy wave shabloni (Wave 1 → 2 → 3) — bu narvon. Real engagement esa DAG, unda yarim tugunlar bir-biriga bog'liq.

                  planner
                     │
        ┌────────────┼────────────┐
        ▼            ▼            ▼
   recon-dns    recon-ct    recon-asn      (Wave 1, fan-out)
        └────────────┼────────────┘
                     ▼
              merge-targets               (Wave 1.5, fan-in barrier)
                     │
        ┌────────────┼────────────┐
        ▼            ▼            ▼
   web-fp      tls-audit    headers       (Wave 2)
        └────────────┼────────────┘
                     ▼
              service-classifier          (Wave 2.5, inson aralashuvi)
                     │
   ┌────────┬────────┼────────┬────────┐
   ▼        ▼        ▼        ▼        ▼
 graphql  swagger  actuator  portainer  minio   (Wave 3, parallel guruhlar)

Graf qoidalari:

• blocked_by qat'iy. web-fp merge-targets targets.json ni qaytarmaguncha boshlanmaydi. Bloksiz agentlar ishni dublikat qiladi yoki eski target listda ishlaydi.
• Fan-in barrierlari majburiy. Har wavedan keyin — merge-* agent orqali sinxronizatsiya. Barriersiz dispetcher to'liq bo'lmagan dataga qarab "yarim qaror" qabul qilishni boshlaydi.
• Har bir tugun idempotent. Qayta ishga tushirish hech narsani buzmasligi kerak. Ya'ni: har subagent loot/<wave>/<host>/<agent>.json ga to'liq overwrite bilan yozadi, append emas.
• Parallelizm = 4–6, undan ko'p emas. Asosiy agentning kontekst oynasi cheklangan: bir vaqtda 12+ subagent — bu fan-in da 12+ summary, asosiy agent aggregatsiyada bo'g'iladi. 5 tadan ikki wave 10 dan bitta wavedan yaxshi.

Subagent turlarini qachon ishlatish:

2. Prompt engineering — security promptning anatomiyasi

Dev-vazifalardan farqli, security prompt erkinlikni kechirmaydi. Har "o'zing o'ylab top" — bu targetning logiga qo'shimcha trace va sizning kontekstingizga +5K token.

Kanonik anatomiyasi:

[CONTEXT]    — kim sen, target, scope, nima allaqachon ma'lum
[COMMANDS]   — verbatim komandalar yoki curl/dig ekvivalenti
[CONSTRAINTS]— rps, timeout, max bytes, retry policy
[OPSEC]      — tripwirelar, stop conditions, NIMA qilmaslik kerak
[OUTPUT]     — format, uzunlik, fayl yo'li, JSON schema

# yomon — middle uslubi
"app.example.tld da recon qil, qiziq narsa bormi ko'r"

# yaxshi — L+1
[CONTEXT] target: app.example.tld, scope: *.example.tld, auth ref: TKT-1234
[COMMANDS]
  1) dig +short A,AAAA,MX,NS,TXT app.example.tld
  2) for s in $(cat loot/wave1/subs.txt); do
       dig +short A "$s"
     done
  3) curl -s "https://crt.sh/?q=%25.example.tld&output=json" | jq -r '.[].name_value' | sort -u
[CONSTRAINTS] sleep 0.3 so'rovlar orasida; max wallclock 4 daqiqa
[OPSEC] faqat passiv; *.example.tld ga HTTP yo'q; avval VPN check: curl -s ifconfig.me
[OUTPUT] loot/wave1/recon-dns.json — schema: {subs: [...], a_records: {...}, anomalies: [...]}, ≤ 350 so'z prose

Conditional probelar — promptdagi shoxlanish

L+1 ning eng kam baholangan usuli. "N ta so'rov qil" o'rniga — "1 ta so'rov qil, javobga qarab keyingi qadamni tanla". Ham kontekst, ham shovqinni tejaydi.

[COMMANDS]
  1) curl -s -o /dev/null -w "%{http_code}" "https://${T}/.git/HEAD" --max-time 6
  2) IF status == 200 AND body "ref: " bilan boshlansa:
       → curl -s "https://${T}/.git/config" --max-time 6 → loot/wave4/${T}/config
       → STOP. .env, .DS_Store ni urinib ko'rma. PoC ni yozib qo'y, dispetcherga xabar ber.
     ELIF status == 403:
       → "blocked but exists?" deb belgila, davom etma.
     ELSE:
       → ro'yxatdagi keyingi probe

Asosiy g'oya: agent o'zi davom etish kerakligini hal qiladi. Promptga o'rnatilgan PoC sentinel. Bu bo'lmasa, agent .git/ topgandan keyin ham butun wordlist ni yondiradi.

Output cheklashlar — kontekst nazorati

• ≤ 400 so'z qat'iy, aks holda agent essay yozadi.
• JSON schema aniq, aks holda reporter keyinroq parse qila olmaydi.
• fayl yo'li majburiy, aks holda output asosiy agent oynasiga oqib ketadi.
• final outputda chain-of-thought yo'q — alohida qator. Aks holda reasoning parent contextga oqib ketadi.

Inline PII masking

Maskingni reporterga qoldirmang — kech bo'ladi. Sizib chiqishi mumkin bo'lgan dataga tegishli har bir promptda:

[OPSEC] Outputda email/phone/passport/INN uchrasa — faylga yozishdan OLDIN mask qil:
  email: u***@d***.tld (birinchi harf + tld)
  phone: +998 XX *** ** XX (birinchi 2, oxirgi 2)
  passport: AA*******
loot/ ga unmasked saqlama.

3. Toolchain integratsiyasi

Agentlar — bu toollarning o'rnini bosmaydi, ular ustidan orkestrator. Nimani va qanday ulash kerak.

Burp Collaborator

OOB (out-of-band) kanallar — blind zaifliklarda. Collaborator URL ni promptda aniq bering, agent o'zi Burp UI ga kirib chiqadi deb kutmang.

[CONTEXT] OOB channel: xyz123.oastify.com (Burp Collaborator, vakolatli)
[COMMANDS]
  1) curl -s "https://${T}/api/import" -d '{"url":"http://xyz123.oastify.com/ssrf-probe-01"}'
  2) sleep 8
  3) Collaboratorni so'rash men o'zim qilaman, sen faqat probe-id ni yoz.
[OUTPUT] {probe_id: "ssrf-probe-01", target_endpoint: "...", payload_used: "..."}

Collaborator polling agentga bermang — bu interaktiv XML auth, agent buzilib qoladi. Probe-id ni yozib oling, o'zingiz polling qiling.

Nuclei — "ikkinchi miya"

Nuclei discovery uchun emas, verifikatsiya uchun. Qo'lda bir narsa topdingiz → tor tag filtri bilan nuclei ni yugurtirdingiz → mustaqil tasdiq oldingiz.

[COMMANDS]
  nuclei -u "https://${T}" -tags exposure,misconfig -severity high,critical \
    -rate-limit 5 -timeout 8 -no-color -j -o loot/wave3/${T}/nuclei.jsonl
[CONSTRAINTS] -rate-limit 5 majburiy, aks holda CF /24 ni banlaydi
[OUTPUT] jsonl ni parse qil, faqat matched entriesni final hisobotga, ≤ 10 finding

Filtersiz nuclei -t cves/ ni ishga tushirmang — bu 8000+ template va bir soatlik run.

ffuf — wordlist aniq yo'l orqali

[COMMANDS]
  ffuf -w /Users/you/infosec/wordlists/quickhits.txt:FUZZ \
       -u "https://${T}/FUZZ" \
       -mc 200,401,403 -fs 0 -t 10 -p 0.2 -o loot/wave3/${T}/ffuf.json

"Wordlist olib kel" emas — to'liq yo'l. Aks holda agent /usr/share/wordlists/... ga boradi, sizda yo'q, qulaydi, retrylarni yondiradi. Va -t 10, default 40 emas — aks holda har qanday rate-limiter sizni darhol payqaydi.

NIMA agent orqali, NIMA qo'lda

Qoida: agar tool real vaqt rejimida watch-and-tweak talab qilsa — bu qo'l. Agent fire-and-forget vazifalarda toza exit code bilan zo'r.

RTK hook va /usr/bin/curl

RTK muhitida curl hook tomonidan tutib qolinadi. Bitta so'rovda bu normal, lekin tight loopda (for i in $(seq 1 200); do curl ...) hook ba'zan bo'g'iladi va butun loop ECONNRESETga osilib qoladi. Yechim — aniq yo'l:

/usr/bin/curl --max-time 8 -sS "$url"

4. Concurrency limitlar va failure modellari

Asosiy agentning kontekst oynasi

Har subagent 200–400 so'zlik summary qaytaradi ≈ 500–1000 token. 12 ta subagent = parent contextda 12 ta parallel quyruq. tool_use/tool_result obvyazka bilan x2. Jami 24K token faqat aggregatsiya fazasi uchun. 2–3 wavedan keyin oyna yonib ketadi.

Limit: 6 ta parallel, ideal — 4. Ko'proq kerak bo'lsa — ketma-ket ikki waveiga bo'ling. Vaqtni deyarli yo'qotmaysiz (har subagent ~5–10 minut), lekin asosiy agent toza qoladi.

Uzoq fonli vazifalarda ECONNRESET

• Watchdog 600s no-progress — asosiy agent har subagent task uchun deadline qo'yadi. 10 minutda qaytmasa → kill, yangi prompt bilan retry.
• Hammasini backgroundga qo'ymang. Backgroundga faqat haqiqatan uzoq ishlar (to'liq nuclei template set). Oddiy probelar foregroundda, tezroq tugaydi.

Agent "qotib" qolganda

Belgilar: TaskCreate running da, oxirgi tool_use 5+ daqiqa oldin, logda yangi narsa yo'q. Sabablari:

1. ECONNRESET, subagent xabar bermagan
2. RTK ostidagi tight curl loop
3. nuclei egilgan repodan 5 MB template tortib turibdi

Retry strategiyasi

5. PTT-driven engagementlar (Pentest Task Tree)

PTT — bu pentest uchun TodoList, lekin kontrakt bilan: har tugunda status, owner (subagent type), evidence path, severity bor.

PTT (Wave 3, target: app.example.tld)
[x] graphql-introspection      → ad-hoc subagent → loot/w3/graphql.json    [info]
[x] swagger-discovery          → web subagent    → loot/w3/swagger.json    [info]
[ ] actuator-heapdump          → ad-hoc subagent → blocked_by: swagger     [pending]
[!] portainer-noauth           → web subagent    → loot/w3/portainer.md    [HIGH, tripwire]
[ ] minio-anonymous-list       → ad-hoc subagent →                         [pending]

Qachon yangilash:

• Har wavedan keyin — fan-in barrier statuslarni yangilaydi.
• Tripwire ishga tushganda — eskalatsiya uchun [!] tugunlar qo'shing.
• Scope kengayganda — faqat tegishli sub-tree ni qayta yig'ing, butun PTT ni emas.

Live PTT vs review-end PTT:

• Live PTT — asosiy agent uni har promptda ko'radi (context block sifatida uzatamiz). Wavelar 5+ bo'lsa va joyni yo'qotish oson bo'lsa foydali.
• Review-end PTT — oxirida yig'iladi, internal.md ga tushadi. Audit trail.

Men ikkalasini ham yuritaman, lekin live versiyasini joriy wave + oldingi wavega kesib qo'yaman. Butun tarixni har promptga uzatish — bu bekorga +3K token.

6. Wave architecture (chuqur)

Wave 1: faqat passiv — nol footprint

Faqat ochiq manbalar, targetga bironta so'rov yo'q:

recon-dns      → ochiq resolverlarga dig (8.8.8.8, 1.1.1.1)
recon-ct       → crt.sh, certspotter
recon-asn      → bgp.he.net, hackertarget aslookup
recon-osint    → GitHub dorks, wayback machine, archive.org
recon-leaks    → DeHashed-style presence check, credential lookupsiz

Target sizning mavjudligingizni umuman bilmasligi kerak. Agar Wave 1 dan qiziq narsa chiqmasa — scope tor, mijoz bilan gaplashing, ko'r-ko'rona Wave 2 ga o'tmang.

Wave 2: yengil aktiv — fingerprint

web-headers    → topilgan barcha sublarga curl -I, Server/X-Powered-By/Set-Cookie ni parse qil
web-tls        → testssl.sh --quick (to'liq EMAS)
web-fp         → whatweb yoki ekvivalent, lite-mode
web-robots     → robots.txt + sitemap.xml + /.well-known/security.txt

Shovqin — host boshiga bitta GET, googlebotdan farqlanmaydi. Wordlistlar yo'q, ?id=1' yo'q.

Wave 3+: service turi bo'yicha targetlangan

Wave 2 dan keyin sizda hostlar klassifikatsiyasi bor. Endi xizmat guruhlari bo'yicha parallellaymiz, hostlar bo'yicha emas:

group-orchestration: portainer, k8s-dashboard, rancher, docker-api
group-monitoring:    grafana, prometheus, kibana, alertmanager
group-api:           graphql, swagger, openapi, actuator
group-cms:           wp-login, drupal, joomla, ghost
group-storage:       minio, s3-public, ftp, smb

Har guruh = bitta ad-hoc subagent, 4–6 guruh parallel. Har agent faqat o'z guruhini biladi, chalg'imaydi.

Wavelar orasida — sync + reassess

Middlening eng tez-tez xatosi: "wavelar konveyer kabi ketadi". Yo'q. Har wavedan keyin:

1. fan-in: hamma subagentlar tugadi
2. asosiy agent summarylarni o'qiydi
3. PTT ni yangilaydi — nima topildi, nima tushib qoldi, nima qo'shildi
4. scope ni qayta baholaydi — sister-domain topildimi? STOP, kelishuv
5. faqat shundan keyin — keyingi wave

3–4 qadamlarsiz siz scope tashqarisidagi hostlarda Wave 5 olasiz.

7. Adversarial scenariolar

Reflective WAF (Cloudflare, Cloudbric, Imperva)

Belgi: har "g'alati" queryga 403, normalga 200. Yondashuvlar:

• WAFga urmang, originga uring. Originni topish: censys/shodan favicon hash, unikal header, certificate SAN orqali.
• Sekinlashtirish — -rate-limit 1, sleep 1.5. WAF reactive smoothing window-based detectionda ishlaydi, sekin fuzz ko'pincha o'tadi.
• Headers rotatsiyasi — nuclei -H orqali har xil User-Agent, qonuniy Accept-Language. Panacea emas, lekin score kamayadi.

Aggressive rate-limit (hammaga 429)

• Eksponensial backoff promptda: if 429: sleep $((2**retry)), max retry 3
• Sublar boyicha taqsimlash — agar limit per-host bo'lsa, 5 ta sub aylanasida bittadan so'rov.
• 429 ko'pincha "target bizni ko'rayapti" signali. 30 daqiqa pauza, keyin yengilroq yondashuv.

GeoIP block (mas. UZ-egress kerak)

Mahalliy xizmatlar ko'pincha xorijiy IPlarni bloklaydi. Mahalliy exit-node bilan VPN. Wave 1 dagi tekshiruv:

curl -s ifconfig.io/country_code  # kutilgan davlat bo'lishi kerak
curl -s -o /dev/null -w "%{http_code}" "https://${T}"  # 200 bo'lishi kerak, 451 emas

Agar maxsus geo-egress kerak bo'lsa va VPN provayderda yo'q bo'lsa — vakolatli broker orqali residential proxy, "forumdan sotib olgan" emas. Bu yuridik savol, texnik emas.

Engagement o'rtasida legal scope

Senariy: Wave 2 da api.sister-company.tld topdingiz — target bilan bog'langan, lekin scopeda yo'q. Harakat:

8. Reporting workflow

Reporter — alohida subagent, qo'shimcha ehtiyotkorlik bilan.

CRITICAL ga 3x verifikatsiya

Har CRITICAL finding 3 ta mustaqil tasdiqdan o'tadi:

1. Findingni topgan subagentdan asl PoC.
2. Reporter tomonidan reproduce — boshqa subagent, boshqa prompt, o'sha kutilgan output.
3. Manual replay — siz shaxsan hisobotdagi komandani bajarasiz, solishtirasiz.

Agar 3-qadam mos kelmasa — finding olib tashlanadi aniqlangunga qadar. Real CRITICAL ni o'tkazib yuborgan yaxshi, yolg'onini chiqarib yuborgandan ko'ra.

Pandoc + pdf_style.css

pandoc tech.md -o tech.pdf \
  --css=/Users/you/infosec/pdf_style.css \
  --pdf-engine=weasyprint \
  --metadata title="Texnik hisobot"

Reporter shu pipeline uchun markdown yozadi, o'zi PDF chizishga urinmaydi. Agentning "LaTeX da chiroyli PDF qilaman" urinishlari — bug-zavodi.

Majburiy 0-bandlik "Ish xarakteri haqida"

exec.pdf va tech.pdf da bir xil. Reporter bu bandlik uchun tayyor shablonni oladi (~/infosec/REPORT_STANDARD.md dan), substitutsiya qiladi: sanalar, scope, ticket-id, hujumchi profili.

Faqat aniq L-profil:

Reporter promptda: "faqat L1–L4 ishlat, profilni finding kontekstidan tanla, 1 jumla bilan asosla".

PII masking avtomatlashtirish

Reporter ikkita sed skript oladi:

s/[a-zA-Z0-9._%+-]\+@\([a-zA-Z0-9.-]\+\)\.\([a-z]\{2,\}\)/u***@\1.\2/g
s/+998 \([0-9]\{2\}\) [0-9]\{3\} [0-9]\{2\} \([0-9]\{2\}\)/+998 \1 *** ** \2/g

tech.md va exec.md yozishdan oldin run. Outputda PII qoldig'i bo'lsa — reporterga qaytarish, aniq qatorga ko'rsatkich bilan.

9. Cost / token byudjeti

Vibe-hacking dagi asosiy token yutuvchilar:

Ishlaydigan mikro-optimizatsiyalar:

• loot/ fayllarni promptga inline qo'ymang — yo'lni bering, agentlar o'zi o'qiydi.
• JSON output, prose emas — JSON axborot birligiga 2–3x zichroq token bo'yicha, plyus deterministik parsing.
• Done-tasklarni yoping — PTT dagi [x] status keyingi promptlarga evidence blokini sudramasin.

Byudjet: tipik 1-soatlik engagementga ~150–200K parent token, ~500K subagentlar bo'yicha jami sarflanadi. Bundan oshsak — qayerdadir promptlar juda umumiy.

10. Failure case study (anonimlashtirilgan)

Topilganlar:

• 4× CRITICAL: ochiq .git/, ochiq Django debug page SECRET_KEY bilan, anonymous list+download bilan MinIO, authsiz Portainer.
• 7× HIGH: hamma joyda yo'q security headerlar, GraphQL introspection ochiq, write operatsiyalar bilan authsiz Swagger, JS bundleda hardcoded credlar, oldindan aytsa bo'ladigan ID orqali API IDOR, weak JWT secret (offline crackable), admin segmentda ochiq registratsiya.
• ~20 MEDIUM/LOW.

Texnik saboqlar:

1. DAG > chiziqli wavelar, lekin fan-in barrierlari majburiy.
2. Conditional probelar shovqinni katta darajaga kamaytiradi.
3. Watchdog "yangi signal yo'q" ga, "output yo'q" ga emas.
4. Reporter har doim 3x verify bilan, aks holda CRITICAL inflyatsiyasi.
5. Scope drift faqat plannerda explicit auto-flag bilan tutiladi.

11. Senior daraja uchun TL;DR

• Graf, narvon emas. blocked_by — sizning do'stingiz.
• 4–6 parallel, hech qachon 12+ emas.
• Conditional probelar > chiziqli wordlistlar.
• Prompt = CONTEXT/COMMANDS/CONSTRAINTS/OPSEC/OUTPUT. Erkinlik yo'q.
• Batch looplari uchun /usr/bin/curl.
• Nuclei verifikatsiyaga, discoveryga emas.
• SQLMap/hashcat/Burp — qo'lda, agentsiz.
• CRITICAL ga reporter 3x verifikatsiya bilan, aks holda exec.pdf da yolg'on alarm va obro' qarzi.
• Sister-domain → STOP → eskalatsiya. Compliance > findings.
• Watchdog 600s no-meaningful-progress, boshqa prompt bilan retry.

L+1 vibe-hacking — bu "ko'proq agent" emas. Bu kamroq agent, o'tkirroq promptlar, qattiqroq barrierlar. Tezlik aniqlikdan keladi, parallelizmdan emas.