Avigdor CyberTech is a Bengaluru-based cyber security and ethical hacking training institute offering CEH, CompTIA, Cisco and SOC certifications with 100% placement assistance.

  • img
  • img
  • img
  • img
  • img
  • img

2nd Floor, Trinity Square Building, 385/1, ITPL Main Rd, Lakshminarayana Pura, AECS Layout, Munnekollal, Bengaluru, Karnataka 560037

AI-Powered Bug Bounty Practitioner Course

Become a Bug Bounty Hunter.

Agents do the recon. You find the bug.

Master AI-powered reconnaissance, manual validation, and professional bug reporting on live authorised programs.

AI Workflows Live Authorised Programs Trusted by 1,000+ cybersecurity learners 4.9 Google Rating* →

Next batch starts soon · Online + Bangalore classroom

HackerOne Bugcrowd Intigriti YesWeHack Burp Suite ProjectDiscovery opencode Ollama
33modules, all on live targets
6phases, start to finish
11vulnerability-class modules
$0spend on AI tooling
0practice labs. none.
LIVEauthorised programs only
The difference that matters

Agent-led recon.
Human exploitation.

Every course in this space now calls itself “AI-assisted”. That phrase describes a tool you happen to have open. It says nothing about who decides — and deciding is the entire job. So we name the division of labour instead, because the division of labour is the method.
Agent · breadth

Runs wide, cheap, and confidently wrong

A very fast intern with no accountability.

  • Enumerate, then normalise the messone JSON shape out of nine tools
  • Read the 4,000-line JS bundleendpoints and params you would skim past
  • Write the throwaway parserthe jq you would have spent an hour on
  • Draft the nuclei templatefrom a bug you already found by hand
  • Diff yesterday against todayand say only what changed
You · judgement

Runs narrow, slow, and accountable

The one with a platform reputation to lose.

  • Decide whether it is actually realreproduce it in Repeater, by hand
  • Two accounts, one diffno model holds the app's authorization model
  • Judge the business impactwhat breaks, for whom, worth how much
  • Build the chainopen redirect + OAuth = account takeover
  • Decide not to submitthe skill that protects your signal
The verification gate

An agent may never be the last thing to touch a finding before submission.

Live targets only

We hunt real targets.
There are no practice targets.

There is no deliberately vulnerable application anywhere in the syllabus — no seeded demo app, no scored lab track, no container with exactly one bug in exactly one place. From the agent phase onward every exercise runs against a live programme you selected and are authorised to test, and so does every exercise the instructors run.

kali@hunter:~$
$ httpx -l targets.txt -silent
https://app.acme-corp.com[200]
https://api.acme-corp.com[200]
https://auth.acme-corp.com[200]
https://admin.acme-corp.com[200]
https://uploads.acme-corp.com[200]
 
$ nuclei -l targets.txt -severity high,critical
[HIGH]CVE-2026-XXXX — app.acme-corp.com
[CRITICAL]CVE-2026-YYYY — api.acme-corp.com
Taught live

Your target, on screen

Agent output, triage decisions and Repeater sessions worked through on the real programme you selected — including the endpoints that turn out to be correctly secured, because those teach you the application's authorization model.

DashboardTargetProxyIntruderRepeater
InterceptHTTP historyWebSocketsOptions
Request to https://app.acme-corp.com:443  [34.120.45.67]
ForwardDropIntercept is onAction
1GET /api/user/profile HTTP/1.1
2Host:app.acme-corp.com
3Authorization:Bearer eyJhbGci…
4User-Agent:Mozilla/5.0 (X11; Linux)
5Accept:application/json
6{"id":101,"role":"admin"}
Alongside you

We hunt it too

Instructors work live targets in parallel with the class. You see the false starts, the dead ends and the agent runs that returned nothing usable — not a cleaned-up final payload with the failures edited out.

Submissions
DashboardProgramsSubmissionsHacktivity
IDTitleProgramStatusReward
#1337IDOR in Account ID parameterAcme CorpAccepted$1,800
#1336Privilege escalation via APIAcme CorpResolved$750
#1335Stored XSS in feedback moduleFinTech Inc.Duplicate$0
#1334Open redirect in logoutRetail Ltd.Informational$0
Reviewed

Real submissions

Findings are written up as actual reports, reviewed line by line before they are sent, and followed all the way through triage — including the ones that come back duplicate or informational.

Real programsLive, in-scope targets you are authorised to test.
Real vulnerabilitiesNo seeded labs. No rehearsal.
Real impactReal reports. Real rewards.
$45K+Total bounties earned by our students.
A seeded lab teaches you that a bug class exists and that someone put one there for you. Neither fact is true on a live programme, and the second one is the habit that has to go. Real targets teach the thing labs cannot: most of what you test is correctly secured, and reading that correctly is the skill.
Which means the rules are real

Every live session runs inside a published programme policy with a written ROE, and scope is confirmed before the first packet leaves the machine — including the programme's clause on AI tooling, which is now a standard part of policy review rather than an afterthought. Students who test outside scope are removed from the programme. This is the one rule we do not bend.

The money is real

What live programs actually pay

These are published reward ranges from real programs on the major platforms — the kind of scope you will be hunting during the course. Nobody gets the top number for a low-impact finding: the range is set by the program, and where you land in it is set by the impact you can prove.

Bug bounty platform program directory showing eight live programs with published minimum and maximum reward ranges: Nubank Brasil $50 to $4,000; LaunchDarkly $150 to $7,500; MATLAB Online $200 to $7,000; Rapyd $100 to $7,500; OpenAI Safety Bug Bounty $250 to $7,500; eToro $100 to $15,000; Optus $150 to $5,000; Moovit $100 to $7,000.
ProgramIndustryReward range
eToroSocial investment platform Finance $100$15,000
LaunchDarklyFeature management Computer Software $150$7,500
RapydPayments APIs Finance $100$7,500
OpenAI SafetySafety bug bounty Computer Software $250$7,500
MathWorksMATLAB Online Computer Software $200$7,000
MoovitMobility as a service Utilities $100$7,000
OptusSingTel Optus Technology $150$5,000
Nubank BrasilDigital banking Finance $50$4,000

Minimum and maximum rewards as published by each program on a public bug bounty platform. Programs revise these regularly — verify current figures before relying on them. Listed here as market context, not as a prediction of individual earnings.

This is why Phase 3 is the biggest phase in the course. Automated scanning — and now agent scanning — finds what everyone else's automation finds, and those pay at the bottom of these ranges. The findings at the top are access control, logic and chained bugs: the ones a human has to reason their way into.
Real hunters. Real results.

Reports our students got paid for

Findings submitted by students on live authorised programs during and after the course. Program names are withheld under disclosure policy.

Live program
$ httpx -l targets.txt -silent
https://app.example.com[200]
https://api.example.com[200]
https://admin.example.com[200]
https://uploads.example.com[200]
 
$ nuclei -l targets.txt -severity high,critical
$350
Bounty awarded
I used to spend hours doing reconnaissance manually. The AI workflow cut that time dramatically, so I could focus on testing and finding real vulnerabilities. I landed my first valid bounty within weeks.
Neeraj B.Batch 12/2026
Verified
Live program
GET/api/profile HTTP/1.1
Host:app.example.com
Authorization:Bearer eyJhbGciOiJIUzI1Ni…
Accept:application/json
 
HTTP/1.1 200 OK
{
  "id": 101,
  "role": "admin"
}
$850
Bounty awarded
Most courses teach tools. This one taught me a repeatable workflow. Learning how to combine AI agents with manual validation completely changed how I approach bug hunting.
Priya M.Bug Bounty Cohort 2026
Verified
Live program
IDTitleSeverityStatusReward
#10583IDOR in Account ID parameterHighAccepted$1,800
#10571Privilege escalation via APIHighResolved$750
#10432Stored XSS in feedback moduleMediumDuplicate$0
#10321Open redirect in logoutLowInformational$0
$1,800
Bounty awarded
The biggest difference was working on live authorised programs instead of practice labs. By the end of the course, I was writing professional reports with confidence.
Arjun K.Bug Bounty Cohort 2026
Verified
Live program
POST/api/v1/reports HTTP/1.1
Host:portal.example.com
Authorization:Bearer eyJhbGciOiJIUzI1Ni…
Accept:application/json
 
HTTP/1.1 200 OK
{
  "impact": "confirmed",
  "state": "triaged"
}
$400
Bounty awarded
Finding the vulnerability was only half the problem. I struggled to explain the impact clearly. The report-review process taught me how to reproduce the issue, demonstrate the business impact and write reports that a security team could actually act on.
Swapna M.Bug Bounty Cohort 2026
Verified
Live program
$ subfinder -d example.com -all -silent | anew subs.txt
api-staging.example.com[200]
legacy.example.com[403]
dev-portal.example.com[200]
files.example.com[401]
 
$ httpx -json | jq -r 'select(.status_code==403)'
[INFO]4 hosts worth a closer look
$250
Bounty awarded
Recon was always the part where I got lost. I was collecting hundreds of endpoints without knowing what mattered. Learning how to reduce the attack surface and prioritise targets completely changed how I approached a program.
Clinton M.Bug Bounty Cohort 2026
Verified
Live program
GET/api/orders/8842 HTTP/1.1
Host:shop.example.com
Authorization:Bearer eyJhbGciOiJIUzI1Ni…
Accept:application/json
 
HTTP/1.1 200 OK
account A ──▸ 200 OK
account B ──▸ 200 OK ← same order
 
[!] reproduced by hand
$175
Bounty awarded
I had spent months watching bug bounty videos but never knew what to actually test. The structured hunting process helped me stop guessing and start testing systematically. My first valid finding came from a workflow I had already practised during the course.
Irfan KhanBug Bounty Cohort 2026
Verified
Live program
$ cat workflow.sh
recon ──▸ enumerate + normalise[ok]
triage ──▸ rank by evidence[ok]
test ──▸ by hand, two accounts[ok]
report ──▸ reviewed, then sent[ok]
 
$ ./run.sh --target example.com
[INFO]same loop, next programme
$50
Bounty awarded
My first bounty felt like luck. The bigger change was learning how to repeat the process across different targets. I now have a workflow for recon, testing, validation and reporting instead of randomly trying payloads and hoping something works.
DeekshithBug Bounty Cohort 2026
Verified
Auto-scrolling — drag, scroll or use the arrows to take over
100+Student reports paid for
$45K+Total bounties earned
Live ProgramsReal targets. Real impact.
100% EthicalAuthorised testing. Responsible disclosure.
What we will not tell you

That you will earn a bounty by a fixed date. Bounty outcomes over any short window are mostly luck — method is not, and method is what we can actually teach. Anyone selling you a guaranteed payout is selling you something else.

Honest expectations

The milestones,
in the order they actually arrive

Progress here is not linear, and it helps to know the sequence rather than guessing. We set expectations against this from day one, so nobody quietly assumes they have failed.
04

It repeats

Consistent findings across two or three programs. Now you know it was method, not luck.

Focus: Compounding
Said plainly

If you move through this sequence slowly, nothing is wrong. Almost every hunter spends a long stretch on zero before something clicks, and the ones who quit are usually the ones nobody told. Assessment here is on process.

⚡ What you walk away with

Cumulative, and none of it expires when the course ends — the pipeline is still running the week after you graduate.

Phase 0

A rebuildable box

A working Kali environment plus a personal setup.sh that reconstructs it end to end, and a fully keyed config set.

Yours. Reproducible. Portable.
Phase A

A zero-cost agent stack

Four agent CLIs behind one routing config with a local model as the floor, so no vendor's pricing decision can interrupt your work again.

Local-first. Private. Reliable.
Phase A

A hardened agent box

A written threat model, a permission config that enforces it, and your own measured true-positive rate for agent output.

Secure by design. Measured by you.
Phase 1

A Burp project template

Scope rules, the full extension set and match/replace rules preconfigured for every future engagement.

Consistent. Clean. Engagement-ready.
Phase 2

An unattended recon pipeline

Running against multiple programs with tuned alerting, still working long after the course ends.

Set it once. Let it run.
Phase 3

A personal IDOR checklist

Built from your own testing matrix against a real application — not copied from a blog post.

Custom. Practical. Yours.

Everything builds on everything.
You keep the tools, the configs, the templates — and the results.

The pipeline doesn't stop
when the course ends.

Honest fit check

Who this is for — and who it isn't

We would rather you skip this course than sit through it frustrated. We will tell you the same thing in the demo call, before you pay anything.

This is for you if…

  • The self-taught plateau — a few labs done, a lot of AI hunting videos watched, some tools run, nothing submitted
  • Certified but untested — you hold a cert and have never touched a live program. This inverts that: process first, paper never.
  • Working in defence — SOC, appsec or dev, and you want to understand the offensive side well enough to argue with a pentest report
  • You can use a Linux shell and know roughly what an HTTP request is
  • You will do the field work between live sessions

Bottom line: You'll show up, ship work, get feedback, and improve.

This is not for you if…

  • You want a payload list and a promise of quick income — we will say so in the first conversation, not partway through
  • You expect an agent to hunt for you. It will produce confident, well-formatted, wrong reports, and your platform signal will pay for it.
  • You expect a guaranteed bounty by a fixed date. Nobody can honestly sell you that.
  • You want to learn unauthorised hacking. Everything here runs inside a published program policy.
  • You only want a certificate to hang on a wall

Our promise: We only want committed learners who are ready to put in the work.

Who teaches you

A practitioner, not a lecturer

The person teaching this course hunts the same programs you will — live, in the same sessions.

ParthaSarathi

Lead instructor · Bug bounty & web application security

Designed and leads the 33-module curriculum built around an agent-led recon stack and the RECON//CONSOLE toolchain. Works live authorised programs alongside the class — including the false starts, the dead ends and the agent runs that returned nothing usable, because a cleaned-up demo teaches nobody how hunting actually goes.

View LinkedIn profile →
Full curriculum

33 modules across 6 phases

Expand any phase for every module, its tools and its field work. Phase A sits between the box build and the fundamentals because the agent layer is infrastructure — it has to exist, and be bounded, before it is pointed at anything. Phase 3 is ordered by expected return for a hunter with this toolchain, not by textbook convention: access control comes first because it is consistently the highest-volume paid class, and neither a scanner nor an agent can find it.

Ground rules and the lab box3 modules · legality, tooling, workspace
Phase 0
Module 0.1

Legal ground, program selection, and scope

  • Authorization models: public programs, private invites, VDPs, self-hosted programs via /.well-known/security.txt
  • Reading a program policy like a contract — in-scope vs out-of-scope assets, prohibited testing, safe harbour, disclosure terms
  • Reading the AI clause: disclosure requirements, prohibitions on fully autonomous submission, and what a given programme counts as validation
  • Wildcard scope and what it actually covers: third-party SaaS on a CNAME'd subdomain is usually out of scope even though it resolves inside the wildcard
  • Out-of-scope vulnerability lists and why they exist — self-XSS, missing headers, CSV injection, rate limiting, clickjacking on non-sensitive pages
  • Testing accounts, rate-limit etiquette, and identifying your traffic with a custom header
  • Platform mechanics across HackerOne, Bugcrowd, Intigriti, YesWeHack and Synack — and how a bad report costs you more than it earns
Field workCompare five program policies on scope breadth, payout range, out-of-scope classes, AI terms and response time; find three self-hosted programs via security.txt
DeliverableAn ROE template you reuse for every target for the rest of the course
Module 0.2

Building the box

  • Toolchain layering — why Go, pipx and cargo each exist in this stack, and why Kali's apt Go is too old for current ProjectDiscovery source
  • PATH construction, and why half of all "command not found" issues are exactly this
  • pipx vs pip vs --break-system-packages: PEP 668 and why Kali now refuses a bare pip install
  • pdtm as the ProjectDiscovery package manager, and when to fall back to individual go install
  • libpcap and the SYN-scan capability requirement for naabu
  • Version discipline: pinning the tools that break your pipeline vs updating on a cadence
DeliverableA working box plus a personal setup.sh that rebuilds it end to end
Module 0.3

API keys, data discipline, and the workspace

  • Sources worth configuring and the config file locations for each
  • Environment tokens: GITHUB_TOKEN for the subfinder GitHub source and trufflehog org scans, PDCP_API_KEY for Chaos
  • Key hygiene — separate keys per machine, never in a repo, read-only PAT scopes, rotation
  • The one-folder-per-target model: ~/recon/$TARGET/{subs,dns,ports,http,urls,js,params,fuzz,vulns,loot}
  • anew as the backbone of the entire system — dedupe on append, print only what is new
Field workRegister every free tier, populate the configs, then measure the keyless vs keyed vs recursive subdomain delta
DeliverableFully keyed config set, encrypted backup, and the before/after counts as proof it works
The agent layer4 modules · routing, permissions, injection, the gate
Phase A
Module A.1

Model routing, and why you will never learn a vendor

  • The three-variable contract — OPENAI_BASE_URL, OPENAI_API_KEY, OPENAI_MODEL — honoured by opencode, Aider and Qwen Code alike, which is what makes vendors swappable
  • Free hosted paths as they stand at your intake, and the discipline of verifying rather than trusting a syllabus: OpenCode Zen's rotating free tier, OpenRouter's free pool, Google AI Studio's tier
  • The local floor — Ollama as an OpenAI-compatible endpoint on 127.0.0.1:11434, with honest hardware requirements at 7B, 14B and above
  • Model selection for security work: a large context window beats a leaderboard rank when the input is a 4,000-line minified bundle
  • Designing for quota exhaustion — a pipeline that degrades to the local model at 3am instead of dying at 3am
  • Provider data policy as a selection criterion rather than a footnote, and which of your material may never leave the box
Toolsopencode, Aider, Qwen Code, Ollama, curl, jq
Field workWire three backends behind one config and run the same real input — your authorised target's JS corpus — through each. Then kill every backend in turn and confirm the pipeline fails over rather than falling over.
DeliverableA models.env you switch in one line, plus written quality notes per backend measured on the same real input
Module A.2

Agent CLIs, the permission model, and the workspace

  • Running one identical task through all four CLIs, because the differences only surface when the task is held constant
  • opencode's permission block in depth: edit, webfetch, and bash pattern matching down to individual commands
  • Aider's git-native design — auto-commit as a real undo, /read-only versus /add, and forcing whole-file edits when a small model fumbles diffs
  • AGENTS.md as the agent's rules of engagement: scope, directories it may never touch, commands it may never run, and the programme's own AI clause restated where the agent will actually read it
  • The skills pack — loading a curated bug-hunting knowledge base into the agent's context so it reasons in your methodology instead of the internet's average one
  • Containment: unprivileged user, container, no egress, and no platform tokens or cloud credentials anywhere in the inherited environment
  • One workspace per target, and why pointing an agent at ~/recon root is the mistake that ends badly
  • MCP servers — what they add, and why every one you connect widens the same blast radius
Toolsopencode, Aider, Qwen Code, Antigravity, Docker, git
Field workInstall all four, run the same task against your authorised target's corpus through each, and record precisely what each one got wrong. Then harden the configs until the task is still possible and the dangerous paths are not.
DeliverableA hardened opencode.json and AGENTS.md pair you clone for every new target
Module A.3

Your agent is attack surface

  • Indirect prompt injection — attacker-controlled instructions hidden inside ordinary data, later read by the agent as instructions rather than as content
  • Why a recon corpus is close to an ideal delivery vehicle: you assembled it out of material the target controls, deliberately, and then handed it to a model
  • The escalation chain from "summarise these endpoints" to shell execution, and the structural reason the model cannot separate your instruction from the target's
  • Documented attacks against autonomous offensive-security tooling, including variants establishing control that persists across sessions
  • The defence stack in practice: role separation, default-deny bash, denied webfetch, a credential-free environment, a container without egress, one workspace per target
  • Detection — goal drift, tool calls you never asked for, and output referencing things that were never in your prompt
  • The same class pointed outward: LLM features shipping on live programmes, how to recognise the pattern, and reading the policy before you touch them
Toolsopencode permission config, Docker, your own corpus, Burp
Field workPlant a benign, clearly-marked injection string in a file inside your own corpus, run all four agents over it, and document which ones obeyed it and which control stopped the rest. On your own material — never by planting anything on a target.
DeliverableA written threat model for your own hunting box, and the configuration that enforces it
Module A.4

Where the agent stops

  • What agents are good at here: reading bundles nobody would read, collapsing nine tool outputs into one shape, writing throwaway parsers, drafting nuclei templates from a bug you already found, explaining an unfamiliar stack
  • What they are consistently bad at: deciding whether a finding is real, judging business impact, and anything that needs two authenticated accounts and a careful diff
  • The rule this course is built on — an agent may never be the last thing to touch a finding before submission
  • The economics behind the rule: the 2026 slop crisis, the programmes that paused or closed, and the platform scoring systems that now hold you responsible for what you file
  • The verification gate in practice: every agent-derived claim reproduced by hand in Repeater before it is allowed anywhere near a report
  • Calibration — measuring your own true-positive rate rather than assuming it, and re-measuring when you change models
ToolsBurp Repeater, your agent stack, the programme policy
Field workTake ten agent-produced candidate findings on your authorised target and verify every one by hand. Record the true-positive rate. That number is your calibration for the rest of the course, and it is usually humbling.
DeliverableYour agent-to-human handoff checklist, plus your own measured true-positive rate written down where you will see it
Fundamentals you cannot skip3 modules · HTTP, DNS/TLS, Burp
Phase 1
Module 1

HTTP and the browser security model

  • Request and response anatomy, methods and their real handling, method-override headers such as X-HTTP-Method-Override
  • Status codes as signal — what 403 vs 401 vs 404 vs 302 tells you about backend logic
  • Cookies in depth: Domain vs Path scoping, HttpOnly, Secure, SameSite semantics, cookie tossing between subdomains
  • Same-Origin Policy — SOP does not stop the request being sent; it stops the response being read. Half of all CSRF confusion comes from missing this.
  • CORS preflight triggers, origin reflection, Allow-Credentials, and why the null origin matters
  • CSP semantics, nonce and strict-dynamic, and bypasses via JSONP and permissive CDN allowlists
  • Encoding layers — URL, double-URL, HTML entity, unicode normalisation, base64, JSON escaping — and how parser mismatches between layers become bugs
Field workIntercept and annotate a full login flow on your authorised target, header by header. For every cookie attribute, CORS header and CSP directive, write down what it is defending against before you decide whether it holds.
Module 2

DNS, TLS, and how modern infrastructure is shaped

  • Record types you will actually use, resolution paths, TTLs, negative caching, and why a stale resolver ruins a brute-force run
  • Wildcard DNS detection — an undetected wildcard will hand you 40,000 fake subdomains
  • Resolver quality: why a curated list beats 8.8.8.8, rate limits, and poisoned public resolvers
  • Certificate Transparency logs as an asset source; SAN fields leak internal hostnames constantly
  • CDN and WAF identification and what it means for scanning — hence naabu -exclude-cdn
  • Cloud infrastructure shapes: origin IP exposure, bucket naming, ASN and IP range attribution
  • Virtual hosting and Host header routing — the basis for vhost fuzzing and host header attacks
Field workMap one large org root domain → ASN → IP ranges → cert SANs → subdomains, four ways, then diff and identify which subdomains sit on third-party SaaS
Module 3

Burp Suite as your primary instrument

  • Proxy setup, CA installation, browser profile isolation
  • Target scope configuration and scope regex — everything downstream depends on this being right
  • Repeater workflow and tab discipline; Intruder attack types, payload processing, grep-match and grep-extract
  • Match & Replace rules, session handling rules, and macros for token refresh
  • Logger++ for cross-tool visibility, filtered so it stays usable
  • Routing CLI tools through Burp — katana -proxy, ffuf -replay-proxy, nuclei -proxy — so automation lands in the sitemap and manual testing picks up where the scanner stopped
Field workConfigure the full extension set, run a katana crawl through the proxy, confirm the sitemap populates
DeliverableA saved Burp project template with scope rules, extensions and match/replace rules preconfigured
Recon: building the attack surface9 modules · the pipeline you keep
Phase 2
Module 4

Organization mapping and scope expansion

  • Corporate structure as attack surface: acquisitions, subsidiaries, regional entities, rebrands
  • ASN discovery and IP range attribution; reverse WHOIS and registrant pivoting
  • Certificate pivoting on subject and organization fields, not just CN
  • Favicon hashing, copyright strings, analytics and ad-network IDs as fingerprints across properties
  • GitHub org discovery, mobile apps and their backend hosts
  • Confirming every discovered asset against program scope before touching it
Toolsamass intel, shodan CLI, tlsx, urlfinder, crt.sh, whois
Field workProduce a list of root domains and IP ranges plausibly owned by a target, each with linking evidence, classified in-scope / out-of-scope / ask-the-program
Deliverablescope.md for one real program, with reasoning
Module 5

Passive subdomain enumeration

  • Passive sources and their differing coverage — and why running six tools beats running one
  • subfinder -all -recursive semantics and what recursive actually does
  • crt.sh JSON parsing, wildcard stripping and dedupe
  • Merging and normalising: sort -u vs anew, lowercasing, stripping ports and trailing dots
  • Measuring per-source contribution so you know which keys are earning their keep
Toolssubfinder, assetfinder, amass, urlfinder, unfurl, anew, jq, curl
Field workRun four passive sources, keep per-source files, compute unique contribution — then permanently drop the sources that contributed zero
Module 6

Active DNS: brute-force, permutation, resolution

  • Brute-force strategy: wordlist size vs time, and when the huge list is worth it
  • massdns and puredns internals — concurrency, resolver rotation, retry logic
  • Wildcard detection and filtering: the difference between a clean run and 40k garbage hosts
  • Permutation generation with dnsgen — producing dev-, -staging, api2, uat. variants no dataset contains
  • Iterative loops: brute → permute known-good → resolve → feed results back
  • Resolving to records with dnsx -a -aaaa -cname -resp, and why CNAMEs are where takeovers live
Toolspuredns, massdns, dnsgen, dnsx, amass, trickest resolvers, n0kovo wordlist
Field workFull active run on an authorised target; compare passive-only vs passive+active counts and manually verify ten new hosts
Module 7

Ports, services, and TLS

  • Fast sweep then deep scan — naabu or rustscan to find open ports, nmap -sVC only on what is open
  • Top-ports vs full range, and when 65535 is justified
  • -exclude-cdn, and why scanning Cloudflare edge IPs burns scan time and produces nothing
  • Rate limiting, --ulimit, and not getting your VPS null-routed
  • Non-web services as targets: exposed Redis, Elasticsearch, MongoDB, Docker API, Kubernetes API, RDP, SMB, database ports
  • TLS inspection with tlsx — cert SANs for more hostnames, weak configs, JARM fingerprints
Toolsnaabu, rustscan, nmap, tlsx
Field workScan an authorised target's resolved IPs; for every non-80/443 port, identify the service and decide in writing whether it warrants manual investigation
Module 8

HTTP probing and attack-surface triage

  • The pivot point of the whole pipeline: hostnames become testable web targets
  • httpx full fingerprint in one JSON pass — status, title, length, tech, server, location, IP, CNAME, ASN
  • Reading that JSON as a triage document and parsing it with jq into a prioritised list — the first place an agent genuinely earns its keep
  • Multi-port probing and what each conventional port implies; screenshotting at scale
  • Status filtering strategy — treat 401 and 403 as interesting, not dead. Those are the endpoints someone thought worth protecting.
  • Prioritisation heuristics: non-standard ports, dev/staging/uat hostnames, unusual titles, no-CDN hosts, admin naming, old stacks
Toolshttpx, jq, your agent stack
Field workTurn a 500+ host list into a ranked top-20 with written justification for each — then defend the ranking against the agent's ranking and explain every disagreement
DeliverableA reusable jq one-liner set for slicing httpx JSON
Module 9

URL harvesting and crawling

  • Archive mining with waybackurls, gau and waymore — a parameter that existed in 2019 often still works on the backend
  • Active crawling with katana: depth, JS crawling, known-files, automatic form fill, scope control
  • Headless vs non-headless crawling for single-page applications
  • Normalisation with uro — without this step your fuzzing lists are 90% redundant
  • unfurl for slicing domains, paths, keys and values; building and maintaining the master URL corpus
Toolswaybackurls, gau, waymore, katana, gospider, uro, unfurl, anew
Field workBuild a full corpus, report raw / post-uro / parameterised counts, then find one endpoint that exists only in archive data and check whether it still responds
Module 10

JavaScript mining and secret hunting

  • JS files are the most under-mined surface on most targets: endpoints, parameter names, feature flags, internal hostnames, sometimes credentials
  • Source map recovery (.js.map) and reconstructing original source — including the comments developers thought nobody would read
  • Webpack bundle analysis, chunk enumeration, lazy-loaded route discovery — the single highest-value use of an agent in the whole pipeline
  • Secret detection and the critical --only-verified distinction between a string that looks like a key and a key that works
  • Key triage: cloud credentials and payment secrets matter; Maps keys, Sentry DSNs and Firebase configs are public by design, and reporting them burns your signal
Toolskatana, SecretFinder, mantra, trufflehog, gf, grep, your agent stack
Field workMine JS from one target; produce endpoints your crawl missed plus every candidate secret with a written verdict on exploitability. Every endpoint the agent claims to have found is confirmed in the bundle by hand.
Module 11

Content discovery, API routes, and parameters

  • Directory and file brute-force with ffuf, feroxbuster and gobuster — what each is best at
  • Wordlist selection as a skill, including building custom lists from the target's own content
  • Filtering and calibration, soft 404 handling, and knowing when you have been shadow-banned rather than when nothing exists
  • API route discovery with kiterunner — REST APIs do not respond to directory brute-force the way sites do
  • Hidden parameter discovery with arjun and Param Miner across GET, POST, JSON body and headers
  • gf pattern sorting to bucket the corpus into xss, sqli, ssrf, lfi and redirect — so you fuzz with intent
Toolsffuf, feroxbuster, gobuster, kiterunner, arjun, gf, Param Miner, SecLists
Field workFull content-discovery pass, then rebuild the wordlist from the target's own JS and sitemap and measure what the custom list found that raft-large missed
Module 12

Automation, monitoring, and being first

  • The anew diff trick — a complete change-detection system in one pipe
  • notify configuration for Discord, Telegram or Slack
  • The monitor loop: new subs → probe only the new ones → nuclei only the new live ones → alert at each stage
  • The agent's overnight job: read the diff, rank what changed, and hand you a short list instead of a log file
  • cron scheduling, staggered jobs, log rotation, and not DoSing yourself
  • Alert fatigue — tuning severity thresholds so you actually read the notifications
  • An honest assessment of when frameworks like Osmedeus and reNgine help, and when they add opacity you cannot debug
Toolsanew, notify, subfinder, httpx, nuclei, cron, your agent stack
Field workDeploy monitor.sh on a VPS against three authorised programs, build a real alert history, classify every alert as actionable or noise, then tune
DeliverableA running monitoring stack you keep for the rest of the course
Vulnerability classes11 modules · the core of the course
Phase 3
Module 13

Broken access control: IDOR, BOLA, BFLA

  • Why first: the server must decide, for every request, whether this user may touch this object. That decision is application-specific, so no template and no model catches it.
  • Object-level vs function-level vs property-level authorization
  • Identifier types and their tells — sequential integers, UUIDs, hashes, base64-wrapped IDs, composite keys, slugs
  • Where IDs hide: path segments, query strings, JSON bodies, headers, cookies, WebSocket frames, GraphQL variables, multipart fields
  • The two-account methodology — capture every authenticated request from account A, replay with B's session and A's object IDs, diff the responses
  • Autorize configuration and how to read its three-state output correctly
  • Method-based bypasses, response-shape analysis, mass assignment, and blind IDOR where the state change is real but invisible in the response
ToolsBurp Repeater, Autorize, Logger++, arjun, ffuf, Turbo Intruder
Field workA full two-account matrix against your authorised programme. Document the correctly protected endpoints too — the negative results are how you learn the application's authorization model, and no agent can hold that model for you.
DeliverableA personal IDOR checklist you run against every new endpoint for the rest of your career
Module 14

Authentication and session management

  • Session handling: fixation, invalidation on logout and password change, concurrent sessions, token entropy
  • JWT attacks — alg:none, RS256→HS256 confusion, weak HMAC secrets, kid injection, jku/x5u abuse
  • OAuth 2.0 and OIDC: redirect_uri validation flaws, missing or predictable state, implicit-flow token leakage via Referer, account-linking abuse
  • SAML signature wrapping and comment injection in NameID
  • Password reset flows — consistently productive: token predictability, Referer leakage, host-header poisoning of the reset link, reuse after use, token bound to the wrong account
  • MFA bypass: missing enforcement on the verification endpoint, response manipulation, backup-code weaknesses, race conditions, OTP brute-force with no lockout
  • Pre-account takeover and unicode/case normalisation collisions in email handling
ToolsBurp Repeater, JWT Editor, Turbo Intruder, Collaborator, hashcat (offline only)
Field workMap every auth-adjacent flow on your authorised target — registration, login, reset, MFA enrolment, session invalidation, OAuth callback, account linking — and test each against the failure list. Start with reset flows; they pay most often.
Module 15

Business logic and race conditions

  • What a logic bug actually is: the app enforces the rule the developer stated, but not the rule they meant
  • Numeric manipulation, price and total tampering, discount stacking, coupon reuse, cart manipulation between add and checkout
  • Workflow bypass — skipping steps, replaying a completed step, forcing a state transition out of order
  • Race conditions in depth: the limit-overrun pattern, TOCTOU on balance checks, the single-packet attack via Turbo Intruder, HTTP/2 multiplexing
  • Where races hide: coupon redemption, withdrawal and transfer, vote counters, invite acceptance, MFA verification, upload deduplication
  • Impact framing — logic bugs need a clear financial or trust narrative because there is no CVE to point at
ToolsBurp Repeater, Turbo Intruder, Intruder, Logger++
Field workWrite out the app's intended rules in plain English first, then design one test per rule that violates it. Hunting logic bugs by poking randomly does not work.
Module 16

SSRF

  • Where SSRF lives: URL parameters, webhook config, PDF and thumbnail generators, import-from-URL, link preview, SSO metadata fetch, XML parsers
  • Cloud metadata endpoints as the primary escalation path, and why IMDSv2 blunts most of these
  • Internal network access — localhost services, admin panels on internal interfaces, Redis/Elasticsearch/Docker/Kubernetes APIs
  • Filter bypasses: alternate IP encodings, IPv6 forms, DNS names resolving to private ranges, redirect-based bypass, DNS rebinding for TOCTOU on the allowlist check
  • Protocol smuggling with gopher://, dict:// and file:// where the fetch library allows
  • Distinguishing DNS-only interactions from full HTTP — DNS-only often means a resolver saw it, not that a request was made
  • Reporting responsibly: demonstrate access, do not exfiltrate real customer data or pivot further than needed
Toolsinteractsh-client, Burp Collaborator, Collaborator Everywhere, qsreplace, gf ssrf, httpx, nuclei
Field workRun the gf ssrf bucket through qsreplace with an interactsh URL against your authorised target, then explain in writing why each non-hit is a non-hit
Module 17

Server-side injection

  • SQL injection — error-based, UNION, boolean-blind, time-blind, second-order, and where it survives now: internal APIs, legacy reporting endpoints, ORM raw-query escapes, sort and order-by parameters
  • sqlmap operated properly — and never reporting a sqlmap result you have not reproduced by hand
  • NoSQL injection — operator injection, auth bypass, blind extraction via regex
  • Command injection — metacharacters, blind detection via time delay and OOB DNS, and argument injection as the subtler variant
  • SSTI — engine identification via polyglot probes; SSTI in an email- or invoice-template feature is one of the most common real-world instances
  • XXE — classic file read, blind XXE with external DTD, XInclude, and XXE via file upload because SVG, DOCX and XLSX are secretly zips of XML
  • Deserialization — recognising serialized formats and why this class is high-severity but high-effort
Toolssqlmap, Burp Repeater/Intruder, ActiveScan++, Backslash Powered Scanner, interactsh, gf sqli
Field workTest the gf sqli bucket by hand first and sqlmap second, then compare what each approach found and what each cost you in traffic. Any sqlmap result you cannot reproduce manually does not exist.
Module 18

Client-side vulnerabilities

  • Reflected, stored and DOM XSS — sources, sinks, and context-aware payload construction
  • DOM XSS hunting with DOM Invader; sink tracing through minified bundles
  • Sanitizer bypass and mutation XSS, and knowing when a sanitizer bypass belongs to the sanitizer's maintainers instead
  • CSP bypass via JSONP on allowlisted origins, strict-dynamic gadget chains, base-uri omission, dangling markup exfiltration
  • Escalation is the module. Session theft, forced state change via the victim's session, CSRF token theft, chaining to account takeover — the difference between a $50 XSS and a $5,000 one
  • Prototype pollution, postMessage flaws, CORS misconfiguration, client-side path traversal, open redirect as a chain component, DOM clobbering
Toolsdalfox, DOM Invader, Param Miner, qsreplace, gf xss, katana, Hackvertor
Field workRun the one-liner chain against an authorised target, manually verify every hit, and write down why dalfox was wrong on each false positive. Then take one low-impact XSS and practise deciding not to report it.
Module 19

File upload, traversal, and file-handling bugs

  • Upload validation bypasses: content-type spoofing, magic-byte prefixing, double extensions, null bytes, case variation, allowlist vs denylist
  • Path traversal in the filename field — overwriting application files, writing outside the upload directory
  • Where uploaded files land and whether they execute: same-origin storage vs CDN vs S3 changes severity completely
  • SVG uploads as a triple threat — XSS, XXE and SSRF from a file type routinely allowlisted as "an image"
  • Polyglot files, image processing library exploitation, zip slip and symlink extraction
  • LFI and RFI: traversal to sensitive files, log poisoning, PHP wrappers, filter chains, and LFI-to-RCE paths
ToolsBurp Repeater, ffuf, feroxbuster, Content-Type Converter, gf lfi
Field workFind every upload feature on your authorised target and document each one's validation model: what it checks, in what order, where the file lands, and whether that location executes. Then test the model you wrote down, not a generic checklist.
Module 20

API and GraphQL testing

  • Why APIs are the best surface available right now — broad, fast-changing, under-tested, and documented in ways that hand you the map
  • Finding API surface: /api/, /v1/, swagger and OpenAPI specs, .well-known, mobile traffic, JS bundles
  • OWASP API Security Top 10 mapped to concrete test cases
  • Versioning as attack surface — /v1/ still live and unpatched with weaker authorization after /v2/ shipped
  • Mass assignment and excessive data exposure, where the API returns the whole user object and the frontend hides half of it
  • GraphQL: introspection, schema reconstruction via field suggestions when introspection is off, query batching for auth brute-force, aliasing to bypass rate limits, mutation authorization gaps
ToolsInQL, kiterunner, arjun, Burp Repeater, Autorize, ffuf, Logger++
Field workEnumerate every live API version on your authorised target and compare their authorization behaviour on the same object. Then reconstruct the GraphQL schema: by introspection where it is open, by field suggestion where it is not.
Module 21

Request smuggling, cache attacks, and header abuse

  • Harder class, less competition, and the payouts reflect that — attempted only after Modules 13–20 are solid
  • HTTP/1.1 smuggling: CL.TE, TE.CL, TE.TE, and detection via timing; HTTP/2 downgrade smuggling
  • Impact: bypassing front-end access controls, capturing other users' requests, response queue poisoning
  • Web cache poisoning — unkeyed input discovery, cache key analysis, fat GET requests, parameter cloaking, turning a self-XSS into a stored one via the cache
  • Web cache deception and host header attacks including password-reset poisoning and routing-based SSRF
  • Testing safely: cache poisoning can affect real users, so unique cache-busters on every probe and never leave a poisoned entry behind
ToolsBurp Repeater (HTTP/2 tab), Turbo Intruder, Param Miner, Collaborator
Field workSafety protocol first, signed off before any probe leaves the machine. Rehearsed against infrastructure you own, then run on the programme only once the protocol has held for a full session. This is the one class where a mistake reaches real users, so it is the one class we gate.
Module 22

Infrastructure, cloud, and the automation payoff

  • Subdomain takeover: dangling CNAMEs, fingerprint databases and their false-positive rate, service-specific claim processes, safe proof-of-concept
  • Second-order takeover via dangling NS records and expired domains in JS src attributes
  • Cloud storage discovery and permission testing — a writable bucket serving JS to the main site is critical, not medium
  • CI/CD exposure: public build logs, .git directories, .env files, exposed artifacts
  • Known-CVE hunting with nuclei, with every hit verified manually
  • Writing custom nuclei templates — the real force multiplier, and the one drafting job an agent does well. A novel bug found on one host becomes a check across every host you have ever collected.
Toolsnuclei and custom templates, httpx, dnsx, trufflehog, shodan, your agent stack
Field workWrite three nuclei templates — a technology fingerprint, an exposure check, and one reproducing a bug you found manually — then run a takeover sweep across your entire subdomain history and verify every hit by hand
Module 23

Chaining and severity escalation

  • Turning findings into chains: open redirect + OAuth redirect_uri → account takeover; self-XSS + cache poisoning → stored XSS; IDOR + email change → takeover; SSRF + metadata → cloud credentials
  • CVSS 3.1 vector construction, where CVSS misrepresents web bugs, and the platform-specific severity guidance that actually determines payment
  • Demonstrating impact without causing harm — minimum viable proof, no real user data, cleaning up test artifacts
  • Knowing when a chain is worth building versus when to report the components separately
Field workTake three low-severity findings from earlier work and attempt to build one chain from them. Even a failed attempt is the point of the exercise.
Getting paid and staying in the game3 modules · reports, strategy, capstone
Phase 4
Module 24

Report writing

  • A bug that cannot be reproduced from your report does not exist. This module has a bigger effect on income than any tool in Phase 2.
  • Report anatomy: title, summary, affected asset, prerequisites, numbered reproduction steps, proof, impact, remediation suggestion
  • Writing steps a tired triager can follow at the end of a long shift, with no context on your target
  • Evidence: screenshots with visible URLs and timestamps, short video for races and multi-step bugs, standalone curl commands
  • Impact sections argued in the program's terms — data exposed, users affected, money movable, trust broken — rather than restating the vulnerability class
  • What gets reports closed as informational, and why duplicates happen: novel surface reduces them, novel payloads do not
  • Triage interaction — pushing back on a wrong severity with evidence rather than frustration, and when to request mediation
Field workWrite three full reports — one high, one medium, and one you decide not to submit with the reasoning documented — then have someone else attempt to reproduce from your text alone
DeliverableA personal report template and a pre-submission checklist
Module 25

Program strategy and sustainability

  • Target selection: new programs vs mature ones, wide vs deep scope, payout tables vs response times
  • Why a mature program with a huge scope often beats a fresh program with a small one — the fresh program is picked clean almost immediately
  • Specialisation: picking one or two bug classes or one technology stack and going deeper than the crowd
  • Time allocation — most hunters over-invest in recon and under-invest in manual testing and reporting, and an agent makes that trap easier to fall into
  • Note-taking and knowledge management: your notes on a target compound
  • Burnout, duplicate streaks and long stretches with no income. Set a process goal, not an outcome goal.
  • Income reality — it is lumpy and unpredictable. Understand your tax obligations on foreign platform payouts before the first payment arrives, not after.
Field workBuild a forward plan: three programs, how you will split your time, the bug classes you will go deeper on, and what you will measure
Module 26

Capstone

  • One authorised program, the full cycle end to end
  • Written ROE and scope analysis before any traffic
  • Complete recon: org mapping → passive → active DNS → ports → HTTP probe → URL corpus → JS mining → params → content discovery
  • Documented triage with a ranked target list and the reasoning behind it, plus an automated pass
  • Sustained manual testing across at least four bug classes, with notes on every endpoint tested including the secure ones
  • At least one submitted report, or a written analysis of why nothing met the bar — a legitimate outcome, and more common than course marketing admits
  • A retrospective: what your recon found that you never tested, and why
DeliverableAssessment is on process, not on whether a bounty landed.
The zero-cost agent stack — four CLIs, one swappable backend

Every AI tool in this course is free, and none of the free ones are stable. That second fact is what the syllabus is built around. Learn a vendor and you relearn everything the month that vendor changes its mind. Learn the routing layer and you change three environment variables and carry on.

ToolShapeWhy it earns a placeWhat will bite you
opencodeMIT · terminal75+ providers, MCP support, and a permission block that denies bash patterns outright — the only one of the four with a security control you would call a controlRoute it away from providers that have blocked it
AiderApache-2.0 · git-nativeEvery edit lands as a real commit, so /undo is an undo rather than a promise; /read-only keeps reference files out of the edit setSmall local models fumble partial diffs — force whole-file edits when output goes strange
Qwen CodeOpen source · terminalGemini CLI ancestry with Qwen3-Coder tuning, and it reads the same OPENAI_* trio as everything else in the stackThe CLI is free; the hosted tier behind it is not. Bring a key or an endpoint.
AntigravityGoogle · IDE-shapedAn agent-manager surface that suits long recon-review sessions better than a TUI doesThe most volatile free tier of the four — treat it as a bonus, never as your pipeline
# the entire switching layer is three variables — every CLI above reads them export OPENAI_BASE_URL="http://127.0.0.1:11434/v1" # local: no quota, no egress export OPENAI_API_KEY="ollama" export OPENAI_MODEL="qwen2.5-coder:14b" # a hosted free tier closes overnight? you change line one, not your workflow
Operational security, not paranoia

Hosted free tiers are frequently free because your inputs have value. Assume anything you send may be retained. That rules out response bodies containing real customer data, platform tokens, session cookies for programme-issued accounts, and unredacted findings before submission. Sensitive context goes to the local model — which is exactly why Ollama is taught as the floor of the stack rather than a curiosity.

The recon pipeline you will build — 12 stages

Stages 01–09 are where the agent layer earns its place. Stage 10 is yours alone, and the highlight marks it for a reason.

01

Org mapping

ASN · WHOIS · certs

02

Passive subs

CT logs · datasets

03

Active DNS

brute · permute

04

Ports & TLS

naabu · nmap · tlsx

05

HTTP probe

httpx · triage

06

URL corpus

archives · katana

07

JS mining

endpoints · secrets

08

Content discovery

ffuf · kiterunner

09

gf bucketing

xss · sqli · ssrf

10

Manual testing

where the money is

11

Report

impact · evidence

12

Monitor

anew · notify

New assets re-enter the pipeline · continuously
The toolchain — 40+ tools, installed and explained
GroupTools
Agent layeropencode, Aider, Qwen Code, Antigravity, Ollama, jq
ProjectDiscoverysubfinder, httpx, katana, nuclei, dnsx, naabu, urlfinder, notify, interactsh-client, tlsx
Subdomain / DNSassetfinder, amass, puredns, massdns, dnsgen
URL corpuswaybackurls, gau, waymore, gospider, uro, anew, qsreplace, unfurl, gf
Portsnmap, rustscan, naabu
Fuzzingffuf, feroxbuster, gobuster, kiterunner
Secrets / exploitationtrufflehog, SecretFinder, mantra, dalfox, sqlmap
Burp extensionsAutorize, Param Miner, Turbo Intruder, Collaborator Everywhere, InQL, JWT Editor, Logger++, Hackvertor, DOM Invader
OSINT & wordlistsshodan CLI, SecLists, n0kovo DNS list, trickest resolvers
The endpoint checklist students keep printing
  • Replay with no session — what happens?
  • Replay with a second, lower-privileged account's session
  • Swap every ID for an object owned by the other account
  • Change the HTTP method; try method-override headers
  • Add unexpected fields (role, isAdmin, userId, price)
  • Remove required fields; send nulls, empty strings, wrong types
  • Look for hidden parameters with arjun and Param Miner
  • Test every reflected value for injection in its actual context
  • Test every URL-ish value for SSRF with an out-of-band payload
  • Test every file-ish value for traversal
  • Send it twice in parallel — is there a race?
  • Check the response for data the UI never displays
  • Check for the same endpoint on an older API version
  • Read the JS that calls it for validation done client-side only
  • Have the agent summarise the calling code — then verify every claim it makes against the actual request
Anti-patterns we actively train out

Most of what keeps a hunter at zero is not missing knowledge. It is a habit. The first four are new since 2026 and are currently the fastest ways to end a hunting career before it starts.

  • Submitting anything an agent drafted that you have not reproduced by hand — the quickest route to a ruined platform signal, and increasingly to a ban
  • Treating agent confidence as evidence. These models are trained to be agreeable; they will describe a non-finding fluently, at length, and with a severity rating.
  • Rebuilding the entire agent stack every time a free tier changes, instead of editing three environment variables
  • Handing one agent a shell, your recon corpus and your credentials in the same session, then being surprised when attacker-controlled text in the corpus turns out to matter
  • Running the whole pipeline on twenty targets and manually testing none of them
  • Chasing XSS exclusively because it is the easiest class to automate, and therefore the most duplicated
  • Testing out of scope because "it's probably fine"
  • Ignoring 403s and 401s during triage — those are the endpoints someone thought worth protecting
  • Submitting the moment something looks odd, before confirming impact
  • Comparing yourself to leaderboard hunters who have been doing this far longer than you have
Prerequisites and hardware
  • Comfort with a Linux shell — navigating, piping, editing files. You do not need to be fluent.
  • A working idea of what an HTTP request is. Everything past that is taught in Phase 1.
  • A Kali VM, 4 vCPU and 8 GB RAM minimum.
  • For the local model floor: ~16 GB RAM for a 7B model, ~32 GB for 14B. Hosted free tiers cover you otherwise.
  • Burp Suite Community is enough early on; Professional is strongly recommended by Phase 3.
Student stories

What Avigdor students have to say

Reviews from students across our programmes — freshers, switchers and working professionals.

Khazi Junaid
Khazi JunaidPlatform Security
Avigdor is the best place to gain the knowledge about cybersecurity, you get good learning and you will have the knowledge and get trained on what you need for cybersecurity, also you will have good Mentoring too!!
Ashwathi
AshwathiStudent
I had an exceptional learning experience at Avigdor CyberTech as part of my CPENT-based cybersecurity training. I gained practical exposure to OSINT tools, Active Directory pentesting, and various real-world cybersecurity scenarios.
Bharath Raju
Bharath RajuPlatform Operations
I have enrolled for the cyber security professional training at Avigdor. Highly recommended to people interested in career switch to cyber security and also for freshers looking to enter this field, as there is Placement Assistance.
Anirudh
AnirudhStudent
Best institute to learn cyber security. The courses cover a wide range of topics, from penetration testing to incident response, delivered through a blend of instructor-led live classes and hands-on practical exercises.
Manoj C
Manoj CVAPT Analyst
Avigdor CyberTech's VAPT training is hands-on and realistic. The focus on real attack scenarios, tools, and methodology makes it genuinely useful for anyone aiming for a VAPT role.
Ganesh
GaneshSOC Analyst
As a fresher, Avigdor CyberTech helped me understand how a SOC actually works. The training covered SIEM basics, alerts, and real incident scenarios in a way that was easy to follow and practical.
Jerald
JeraldSOC Analyst
Avigdor CyberTech's SOC training is practical and industry-focused. Real SIEM use cases, log analysis, and incident handling — not just theory. If you're serious about becoming a SOC analyst, this training gives you the right foundation.
Auto-scrolling — drag, scroll or use the arrows to take over
FAQ

The questions people actually ask

Do I have to pay for AI tools or API credits?
No. Every AI tool in this course is free — four open-source agent CLIs, free hosted tiers, and a local model on your own hardware as the floor. You learn the routing layer rather than a vendor, so when a free tier closes overnight you change three environment variables instead of rebuilding your workflow. That is a module, not a footnote.
Isn't AI going to replace bug hunters anyway?
Not the ones doing the part that pays. 2026 made this measurable: submission volume rose sharply, the valid-report rate did not move, and several programmes paused or closed under the load. What collapsed in price was plausible-looking findings. What did not was verified ones. Agents are now in most hunters' workflows, so they are no longer an edge — knowing exactly where to stop them is.
Will I earn a bounty by the end of the course?
We will not promise that, and you should be sceptical of anyone who does. Bounty outcomes over any short window are mostly luck; method is not. What we commit to is that you finish with a running recon pipeline, a hardened agent stack, a written method per bug class, live testing experience on authorised programs, and reports reviewed line by line. The capstone is assessed on process.
What are the fees?
Transparent fees with instalment options and no hidden charges. We go through the fee structure in the free demo class, or you can ask on WhatsApp and we will send it across.
Really no practice labs at all?
Really. A seeded lab guarantees a bug exists and that someone graded the path to it, and that guarantee trains the wrong search behaviour — keep looking, because finding is certain. On a live programme the base rate runs the other way. You meet each new bug class by finding it on the target's own surface with an instructor on the call, including the very common outcome where the application handles it correctly and what you have learned is the defence.
Do I need programming experience?
No. Programming is not a prerequisite. You will be writing bash and reading minified JavaScript by the vulnerability-class phase — that is a promise rather than a warning, and it is taught, not assumed. What you do need is comfort with a Linux shell and a working idea of what an HTTP request is.
Do I need Burp Suite Professional?
Community is enough for the early phases. By Phase 3 the absence of active scan, saved project files and most BApp extensions becomes a genuine ceiling, so Professional is strongly recommended from that point. We will tell you exactly when you need it rather than requiring it on day one.
Is testing live programs actually legal?
Yes — within a published program policy that grants authorisation, which is precisely what Module 0.1 teaches you to read like a contract, AI clause included. Scope is confirmed in writing before any traffic leaves the machine. Students who test outside scope are removed from the programme. This is the one rule we do not bend.
How is this different from the CEH v13 course?
CEH v13 is a broad, certification-led program covering 20 modules across offence and defence, and it is the recognised entry credential for pentesting roles. This course is narrower and deeper: web and API bug hunting only, no exam, 33 modules across 6 phases, and the practical outcome is a working hunting method on live programs rather than a certificate. Plenty of students do CEH first.
Online or classroom? And what if I miss a session?
Both run live with the same instructor and the same field work. Classroom sessions are at our Marathahalli / AECS Layout centre in Bengaluru; online students get identical exercises. Every session is recorded and yours to rewatch, and batch size is capped so field work and report reviews stay individual.

More questions? Ask us directly →

The market, in 2026

Why that gate is the whole course

Discovery got cheap in 2026 and triage did not. The gap became a crisis, and it is the reason a course can no longer teach AI tooling without also teaching where to stop it.
+76%year-on-year jump in submissions recorded by HackerOne
~25%share of valid reports — flat, while volume quadrupled
+334%rise in Bugcrowd queues over three weeks, excluding traditional submissions
~82%of hackers now use AI somewhere in the workflow
Programs closed doors — and they closed them on hunters

curl ended its bug bounty programme after drowning in hallucinated reports. Google stopped accepting AI-generated reports. HackerOne paused the Internet Bug Bounty, Node.js suspended rewards, Nextcloud shut its programme down. YesWeHack now names the violation directly, listing programme spamming and AI slop together and enforcing them through an ethical score that can end in a permanent ban.

Read that as a market signal rather than a moral one. The supply of plausible-looking findings collapsed in price. The supply of verified findings did not.

The most-cited proof that agents can genuinely hunt is XBOW — the first documented case of an autonomous agent topping a HackerOne leaderboard. The detail that rarely survives the retelling is the lesson: its own team still put a human between the agent and the submit button. You are not going to out-engineer that decision. You are going to copy it.
The honest limit of this approach

Agent-led recon widens what you see. It does not make you better at reading an authorization model, and it will not invent the two-account test that finds the IDOR. The agent phase exists to buy you time for the manual work, not to replace it — which is exactly why Phase 3 is the biggest phase in the course.

Free demo class

Sit in on a live hunt. Free.

Meet the instructor, watch a real target get worked, and ask whatever you want. No payment details asked, no commitment — and if we think you are a poor fit, we will tell you.

4.9 on Google* → 1,000+ trained “The quality of the course content and the teaching is top notch.” — Bharath Raju

✓ Opening WhatsApp — hit send on the pre-filled message and we'll confirm your demo slot there.

Booking happens on WhatsApp — your details go straight to our team. No spam, ever.

* Google rating is sample data for design review.