03.05.2023
3 min
4953
Network intelligence (OSINT) is a key tool for bug hunters hunting for vulnerabilities in web services and corporate infrastructure. Using Google Dorks, Shodan, GitHub search, and leak monitoring, you can find subdomains, open APIs, test instances, and sensitive data before active testing. Thanks to OSINT, a specialist creates a map of the infrastructure, identifies old passwords, tokens, and vulnerable services that can be used as a login to the system. The right approach to information collection increases the chances of successful bug hunting and increases the efficiency of finding critical errors.
A bughunter is a specialist in finding vulnerabilities in digital systems. His task is to find technical holes that can be exploited and report them to the system owners before someone else does. This is paid for under bug bounty programs or private contracts. The better a bughunter collects information about the target, the faster he finds an entry point. If you don’t know what services the company has, you won’t find an error or a bug. But if you have OSINT in your arsenal? Open source intelligence? You get an advantage.
OSINT is the search and analysis of information from public sources: websites, forums, social networks, local registries, even search engine caches. Advanced open source intelligence is not just collecting website addresses. This is systematic work: first, infrastructure analysis, then searching for vulnerabilities, then clarifying what can actually be used in an attack.
OSINT tools allow a bughunter to:
скласти карту доменів та піддоменів компанії;
знайти відкриті API, адмінки, панелі моніторингу та тестові інстанси;
отримати інформацію про внутрішні системи – слідами розробників у GitHub, Jira, DockerHub;
побачити витоку конфігурацій, паролів, ключів
зрозуміти, які технології використовує ціль і які вони відомі вразливості.
A simple example: a bughunter runs a scan of subdomains, finds dev.oldcorp.com, Jenkins on it without authorization. Then it executes a command through the console, gets a reverse shell. It all started with OSINT.
Let’s analyze each of the OSINT methods in parts and on real cases: from Google Dorks to leak analysis.
The first step is to understand what the target has on the Internet, i.e. what domains it controls, what technologies it uses, what services are running online. All of this can be gathered without touching any server directly. For example, a bughunter uses Amass to gather all the company’s subdomains, among which he finds the third-level domain vpn.oldcorp.com. Through Shodan, he learns that the server uses outdated OpenVPN. Through nmap, he sees that port 943 is open. This means that it is possible to knock on the web interface of the admin with the version. According to CVE, in this way we found an RCE exploit, and therefore OSINT gave us not just a map of the infrastructure, but a specific target that is being exploited without any unnecessary noise.
Developers often post keys, configs, and passwords in open repositories themselves. Usually, this happens accidentally or out of ignorance. All of this becomes part of the open internet if it gets into a search engine index, repository, or cloud storage without access. For example, a bughunter can use Google Dork site:github.com “aws_access_key_id” “oldcorp” – and find the commit in which the engineer uploaded .env with AWS keys. The check showed that the key is active. Through the AWS CLI, the bughunter gets a list of buckets, one of which may be open and contain dumps of internal databases. What could be done with this information? If access were real, this is a critical vulnerability with serious consequences.
Tools and approaches:
Google Dorks: intitle:index.of, filetype:env, intext:”password”
GitHub search + GitLeaks: looking for API keys, tokens, configs
hunter.io, theHarvester: collecting email addresses and profiles
waybackurls, gau: indexing old URLs and resources
A leaked password is not just a string from the database, it is a potential login to internal systems. Many companies have corporate emails that have already surfaced in old leaks and are still working. If two-factor is not implemented and passwords have not been changed for years, then the attack becomes trivial.
For example, a bughunter checks the company domain through Have I Been Pwned and sees several matches by email. One of them is [email protected]. Using DeHashed and Scylla.sh, he finds the old password. Then, using this data, he enters the Jenkins instance, available at ci.target.com. Jenkins can be configured without SSO and authorization will be successful. With this obzoz, you can gain access to pipelines, environment variables, tokens.
Another real-life case is the Slack token leak. In 2023, a developer accidentally committed .env from SLACK_API_TOKEN to a public GitHub repository. The repository was deleted a day later, but the token remained active. A bughunter used the GitHub archive via the wayback machine, extracted .env, obtained the token, decrypted the workspace, and then found a list of participants and internal channel messages. Among them was a discussion of a production incident and a key to the staging environment.
Also in 2024, a database leak occurred from the Exploit.in forum, which again updated the vulnerability through old corporate emails. One of the bughunters found the login and password of an IT employee in this database. After trying to authorize on the company’s GitLab, he gained access. Uploading projects showed that one of the repositories had a deploy.sh with a private SSH key. The key was active and was used to connect to the staging server.
This is an important lesson about not ignoring old leaks. What leaked in 2016 could work in 2025 if there are no processes for monitoring and rotation. A bughunter who watches for leaks is several steps ahead of any scanner check.
Unfortunately, corporate mistakes are repeated, especially within the same industry — fintech, edtech, SaaS, etc. By analyzing competitors’ vulnerabilities, a bughunter can get a map of typical bugs, architectural miscalculations, and bad practices.
For example, a bughunter studies public reports on HackerOne for companies in the same industry as the target. He sees a series of bugs related to poor validation of JWT tokens: no alg check, token replacement with none, or no refresh token rotation. He checks the implementation on his target’s side and finds a similar construction, then generates a token with alg: none, signs it, and thus gains access to someone else’s account.
Another case: studying competitors’ subdomains via Shodan. A bughunter notices that one of the competitors’ vendors has deployed a monitoring system on a public IP without authorization. He checks the same scheme near the target and finds grafana.oldcorp.com, accessible without a login. Next, he receives a visualization of requests to the backend, database schemas, and API keys.
It should be understood that the tool itself is just a program that has only theoretical utility. The effect is given only by the correct chain: target → assumption → tool → result → attack.
This is a visual analysis tool that is launched to enrich and clarify the connections between domains, IP, email, companies and any other entities. For example, enter example.com, build a graph and find related email addresses, one of which is highlighted in Have I Been Pwned. Next, it is logical to perform a password check for attempts to log in to internal panels.
Maltego is useful for investigating and mapping related structures. Especially if the target is divided into many legal entities or the infrastructure is spread out by contractors.
This is an infrastructure search engine. In practical implementation it might look like this: we request org: “OldCorp” port:9200, we see that the company has opened Elasticsearch without authorization. Then we make a transition by IP, curl request and see the data. You can report a critical vulnerability.
Shodan can also be used to search for Open Jenkins, GitLab, Prometheus, Zabbix and other services with known vulnerabilities. In addition, you can search by signatures: product:Jenkins, http.title:”GitLab”.
This is a basic tool for refining search queries. For example, the query site:corp.com filetype:env can return .env with product keys. And intitle:”index of” admin can highlight a folder with dumps. Despite its simplicity, this is a fairly effective tool: administrators still upload such files to the root of the site or forget to close the indexing.
However, this scheme does not work for fresh files. You should only count on what has already been indexed. In this case, it is better to combine Google Dorks with waybackurls and filesystem search.
Searching repositories can be very useful. When we query org:corp “api_key”, we can find a committed config.js with the Stripe key. Using git clone and gitleaks detect, you can automate the search at the level of the entire GitHub or specific repos. This is useful both in the reconnaissance phase and for monitoring your own leaks if you are on the company side.
OSINT is not hacking, but its consequences can be comparable. It all depends on where you are hacking and for what purpose. The line is drawn where publicity ends and unauthorized access begins.
What is permissible:
analysis of domains, IP, public metadata;
study of open repositories, forums, social networks;
verification of leaks using public databases;
scanning through passive sources (Shodan, Censys, Archives);
search on Google Dorks and cache.
What requires permission:
phishing (even if it’s just an email with a link);
attempting to log in using the data found;
working with vulnerable services, even if access is open;
scanning or searching on combat instances.
Example: you found an open Jenkins. If you just entered the interface, it is OSINT. If you launched a build, it is already an active action. Without permission, it is a criminal article.
Thus, OSINT is not just a stage of reconnaissance, but the foundation of successful bughunting. Every found subdomain, leaked password, or forgotten API is a potential door into the system. A bughunter without OSINT is like a treasure hunter without a map. He can dig at random, but the real finds await those who know how to analyze, compare, and find weaknesses before the first attack.
