- Critical Thinking - Bug Bounty Podcast
- Posts
- [HackerNotes Ep. 63] JHaddix Returns
[HackerNotes Ep. 63] JHaddix Returns
Jhaddix returns on the pod covering: The Bug Hunters Methodology, target hunts, recon techniques, going deep on apps and more.
Hacker TLDR;
JHaddix - The Bug Hunters Methodology: A two-day live course launched covering all things recon, application analysis, JS analysis, and more. Prior talks from Cons on previous versions of the methodology can be here and here.
FIS Hunt: Some tips to bypass Akamai-based WAFs learnt from hitting the FIS target on BugCrowd:
Residential IPs don’t get blocked as much, or aren’t blacklisted (risky scanning from your residential IP as you could get your home banned, however)
Rotate user agents with every request.
Limit to 15 threads in the content discovery process.
Using IPs in countries which the site resides can help get past geofencing.
Going Deep on Apps: The premise is to get access to extra functionality on the app by asking:
What do I have an advantage on that somebody else doesn’t have?
Can I pay for paid versions of the application?
Is functionality geofenced, can I route through or am I in a location which isn’t geofenced?
Can I join a developer program on the target?
Can I join a reseller program on the target?
Recon techniques:
Reverse DNS: You can ask a nameserver what domains are associated with this IP, and if there are PTR (pointer records, basically reverse records) they will respond with the domain name
SecurityTrails, Shodan, Netlist: These companies sell recon data all have different methods of building their recon data
Reverse DMARC: A few providers spider the internet for DMARC records and store them in a database. You can look at a company and its DMARC record to see what other domains it's applied to. Use dmarc.live
Reverse CSP: You can also do this with CSPs - reverse lookup a CSP policy to see if it matches and potentially find more targets if they match your target. A nice tool to do this: https://github.com/edoardottt/csprecon
JHaddix - The Bug Hunters Methodology
If you haven’t already seen it, JHaddix’s Bug Hunters Methodology is one of the long-standing pillars of bug bounty resources that has been around forever. It’s a very well-respected talk, or now a series of talks, that JHaddix started back when and regularly updates. You can find the app analysis talk from last year here and from NahamCon2020 here
The Bug Hunters Methodology has progressed into a live 2-day course you can sign up for, which is constantly updated between cohorts (one a quarter) covering topics like JavaScript analysis, recon, app analysis and much more.
There’s a value-added section on red teaming techniques which is equally as good at the end of the class, but due to the amount of content, it has officially split into another talk entirely.
I did attend one in November/December when I was getting ready to jump into bug bounty. In my opinion, it's well worth it and you’ll 9/10 times walk away with a bunch of tools or techniques you didn’t know before.
The Discord channel is lively, with collaborations on live hunts for different targets every month too. Be sure to check it out if it's your sort of thing.
FIS Hunt
JHaddix, as part of his Discord, launches hunts where he uses his speciality of recon to gather a whole bunch of targets to hunt every month. As part of the recon, he uses all the worthwhile paid-for services as data sources in the process, using all of the techniques you’ll find in the bug hunters methodology.
Throughout this process of recon, on targets, you’ll encounter various WAFs, firewalls, rate limits and everything else. For one of the targets, FIS, the WAFs were unforgiving - any payload in a request would get you blocked, and most VPS provider's IPs were blacklisted - Digital Ocean, AWS etc.
Some WAF bypass tips from this process:
Residential IPs don’t get blocked as much, or aren’t blacklisted (risky scanning from your residential IP as you could get your home banned, however)
Rotate user agents with every request
Limit to 15 threads when in the content discovery process
Using IPs in countries in the site resides can help get past geofencing
Now, something cool I learned from this episode that JHaddix is going to use going forward to avoid hassle with scanning are IP rotation services that specialise in mobile and home network IP ranges. You can pay for a proxy which rotates through various IPs hosted in different areas such as mobile networks, residential ISPs, and data centres to name a few to route your traffic through.
The supplier JHaddix is going for is called Brightdata, but looking around there are a few companies which offer this service. Most of them charge $ per GB, so only using it for recon or a POC might be a good idea.
Going Deep on Apps
If you’re a regular Critical Thinking listener you’ll know how much we talk about going deep on applications. JHaddix follows this approach, and breaks down some tips on how to do so:
The premise is to get access to extra functionality on the app. What do I have an advantage on that somebody else doesn’t have?
Can I pay for paid versions of the application?
Is functionality geofenced, can I route through or am I in a location which isn’t geofenced?
Can I join a developer program on the target?
Can I join a reseller program on the target?
Application Heat Mapping
Application heat mapping is a process of mapping out an application functionality and identifying functionality where things commonly go wrong; things as output encoding, SSRF, and file upload facilities to name a few.
Identifying these areas can be instrumental in uncovering bugs. In some cases, developers may encounter limitations with default framework functions, such as output encoding, particularly in certain sections of an application.
Say you’re building a webhook across apps, they need special characters to some extent to work properly as part of the URI schema, so more often than not devs will not implement the protections properly, or at all.
JHaddix uses the concept of 'heat mapping' an application to pinpoint potentially risky behaviours, thereby prioritizing efforts on high-risk areas. This approach targets the most vulnerable areas first, uncovering common points of failure to identify bugs efficiently.
Recon techniques
A few high-yield recon techniques for finding subdomains and expanding the attack surface on a wider-scoped target:
Reverse DNS
You can ask a nameserver what domains are associated with this IP, and if there are PTR (pointer records, basically reverse records) they will respond with the domain name
Hakrevdns does this in a tool
SecurityTrails, Shodan, Netlist
These companies sell recon data all have different methods of building their recon data
Can do a reverse name server lookup. FIS was using Akamai as a name server fronting. Through whoisxml API you can do a query that basically says ‘What other servers use this server as a name server’
Massive amounts of hosts come back, 6-8k servers. You can grep through the list for the target.
Reverse DMARC
A few providers spider the internet for DMARC records and store them in a database. You can look at a company and its DMARC record to see what other domains it's applied to. Use dmarc.live
Reverse CSP
You can also do this with CSPs - reverse lookup a CSP policy to see if it matches and potentially find more targets if they match your target. A nice tool to do this: https://github.com/edoardottt/csprecon
JHaddix’s recon philosophy is to do these sorts of recon tasks manually instead of trying to automate them. Spending time to manually understand the target and ‘eyeball’ naming conventions can give you a deeper understanding of the target, and gives you an edge on grabbing context and targets which automation could miss.
AI for Bug Bounty & LLM-Based Bounties
Platforms and programs are appearing that host models to hunt on, with the aim of the model to perform X task. They need to confirm that the bot isn’t going to subject them to any legal trouble - ie ensuring it doesn’t give sexist or racist results or suggest things which could cause harm for example.
To try and combat this, prompt-based firewalls are often created to try and filter out prompts which could illicit those sorts of behaviours.
This has bred something called ‘biased bounties’, which are bug bounties but from the result of using prompts to bypass and illicit this type of unwanted behaviour.
Equally, spending time to craft very specific prompts and using the chatGPT API to adjust some of the configurations around prompts can be used to massively improve productivity with bounties and hacking in general. JHaddix took this a step further and released a bot on the OpenAIs GPT marketplace here.
Red Teaming
JHaddix does a lot of red teaming with equally as valuable takeaways for bug bounty. In red teaming, there’s a concept of implants which are essentially used for command and control from host to c2 server - think of these as a means of establishing persistence on a target.
In this process, you have different types of implants for different stages. The reason for this is that some implants lend themselves more towards initial access but don’t offer a tonne of functionality, so you may use it as a stage 0 implant and later upgrade to a more functionality-rich implant once you’ve found an appropriate means of dropping one on a host.
The reasoning behind this is to usually avoid detection against defences such as EDRs which reside locally on hosts. JHaddix uses nimplant as a stage 0 implant as EDRs struggle to detect nim-based implants as it currently stands, but then upgrades to a stage 1/stage 2 implant for better usability.
Implants can typically be broken down into categories based on their functionality and roles:
Stage 0/1 - Initial Access, persistent remote access and initial data gathering
Stage 2 - Modern framework, offers functionality like a web GUI to manage C2s and gather data and files
Stage 3 - Offers the capability to upload data to c2 and exfil from host
Red Team + Bug Bounty
Now there is some overlap with red teaming and bug bounty. Although not common, threat intel-based findings can be reported to programs. Threat intel-based findings is when you find working domain creds, or VPN creds on the dark web for example and then submit them as a bug bounty report.
As you can imagine it can be a bit of a grey area depending on the program, and often ends up being 50/50 in terms of if a program accepts these or not; sometimes they are welcomed, other times they aren’t.
Checking the program's scope and policy section can help determine if these sort of findings are explicitly out of scope, but equally, these usually fall into the category of ‘not out of scope, but not in scope either’.
The way this works is people sell credentials on the dark web, Telegram and Discord channels which operate like its own ecosystem. The sellers on these channels are often cred stealer operators, so they usually don’t actively target specific companies but rather groups of people in campaigns.
To prove these campaigns are fresh and contain good data, they provide a stealer log sample which you can parse to look for your company or bug bounty target - if their domain or related domain shows up, you can buy the creds for that domain.
This malware also steals your cookies straight from the browser to avoid 2FA prompts - instead of using creds, just use the cookie!
A good paid threat intel source JHaddix uses as part of this process in his red team is https://flare.io/.
Again, this is a grey area for bounty programs and can vary massively depending on the program you report it on.
JHaddix always has a tonne of cool sh** to share. If you don’t already follow him, you can find him on Twitter here.
As always, keep hacking!