Netlas CookBook: a recipe index for querying an internet-wide asset index

A guide to a hosted index, not a tool you run yourself

The netlas-cookbook repository is a guide, and understanding that shapes everything about it.

The stated goal is very simple: to teach anyone interested in cybersecurity, regardless of their knowledge level, how to make the most of Netlas.io. The README says it is a long read, and that as many simple use cases as possible have been collected and demonstrated, with the emphasis on how to automate them.

The service underneath is described as a search engine designed to find and analyse information about all IP addresses and domains available on the Internet. The guide notes that Netlas has some attack surface management features, but says it focuses mostly on the Netlas Search Tools and on how to use them in automations.

So the subject matter is a hosted internet-wide index of hosts and domains, and the guide's job is to show you how to drive it programmatically. That distinction matters for a reader deciding what to take away. There is no binary here to install and no index to download. The repository's top level is only a LICENSE, a README.md, an images/ directory and a scripts/ directory, so the deliverable is prose, screenshots and a handful of helper scripts.

The licence is CC0-1.0, which is a public domain dedication rather than a software licence. That is an unusual and deliberate choice for a repository attached to a commercial service: the written guide is placed beyond copyright, so anyone can copy, translate or republish the recipes, while the service and its API remain subject to the service's own terms. This review does not interpret those terms, and the practical point for a reader is that the guide is free to reuse but the data it returns is not automatically free to use.

The repository carries a contributions-welcome badge, so it is maintained as a community document rather than as a sealed reference.

The query syntax, from filters to regular expressions

The largest part of the guide is the search query syntax, and it is organised as a reference rather than a narrative.

The first block is filters, the fields you can restrict on, followed by logical operators, which is how you combine those conditions, ranges, wildcards, fuzziness and regular expressions. That is the core of the guide and it is where the practical value sits. Anyone who has used a search interface for internet-wide data knows the friction: the syntax is not documented where you are using it, so you end up guessing field names and operators. A reference that names them in one place is worth more than a hundred screenshots.

Regular expressions deserve particular mention because they are the feature that changes what is possible. Combined with a body or title field, a regular expression turns the index from a lookup service into something you can ask precise questions of, such as finding pages whose content matches a pattern rather than pages containing a literal word.

Fuzziness is the opposite idea and is equally practical. It is how you find hosts that look almost right, which is what you want when a domain name is a near miss of a brand name or when a banner string has been slightly altered.

The guide separates this syntax section from the simple usage examples that come before it, and that ordering is a deliberate choice. The simple examples cover getting information about a single IP or domain, searching for non-Latin domains, and looking for websites containing a certain word in their title. Those three are the on-ramp, and the syntax reference is what you come back to when the simple query is not enough.

The README's table of contents also lists a section on other Netlas.io search features, which suggests the syntax reference does not claim to cover the entire query surface.

The API, its key, and the difference between search, download and host

The API section is where the guide turns into something you can script, and it is the most detailed part of the table of contents.

The first question any reader has is where the key comes from, and the guide has a section for that. The rest of the section is a working reference: the structure of the Netlas API JSON response, and then a set of subsections that read like a manual for using that response. There is a section on tools for debugging API requests, a section on tools for working with data in JSON format, a section on the Netlas Python library, and one on the Netlas CLI tools. There is a separate section for examples of response keys for getting useful data, and another on Netlas Python response datatypes.

One subsection name carries a distinction that matters more than it looks. Search, Download and Host are described as different methods, not as parameters of one method. A search endpoint returns matches. A download endpoint returns the underlying records. A host method returns everything known about a single host. Choosing between them is a decision about how much data you are pulling for a given question, and collapsing them into one interface would be a design mistake, because the data volumes differ by orders of magnitude.

The guide also covers additional request parameters, and then the practical end: making requests with Python without the Netlas Python library, which is what you would do if you are working in a different language or do not want the dependency, and examples for other programming languages. There is a section on the jq utility for working with JSON on the command line, and one on AI tools for writing code, and a section on code checkers.

That last group is worth noting for what it reveals about the audience. A guide for security practitioners that covers jq, that shows how to call the API from any language, and that includes tooling advice for generating code, is written for people who will adapt the recipes to their own environment rather than copy one script.

OSINT recipes that reach past the search box

The OSINT section is the largest group of recipes in the guide, and it is where the interesting techniques live.

Several recipes look for a person rather than a host. There is a section on searching a person's nickname or email in WHOIS contacts, and another on searching for the same in the title and body of a web page. Both work by treating identifying strings as an index query, which turns a name into a list of infrastructure.

Other recipes look for specific classes of exposed file. There is a section on searching for juicy info files on the subdomains of a company's website, a section on file mentions that looks for content that may be infringing on copyrights, and a section on phone number mentions.

A cluster of recipes reads structured metadata rather than page text. There is a section on domain WHOIS information gathering, one on searching for a location in an address tag, one on searching for an author name in meta tags, and a broader question about what else can be found in the meta tags of an HTML document. The meta tag section is the most general of these, because meta tags are where pages leak things they did not intend to publish.

Three recipes work against infrastructure rather than content. There is a section on searching by FTP server banner text, one on searching for contact information in SSL certificates, and one on using Netlas as an alternative to the WayBack Machine, which is a direct substitution of the index for an archival service.

The guide closes the OSINT section with a section offering nine ways to search related websites, which is the pivot from looking for a specific thing to exploring around an asset you already have.

A caveat applies to all of these. The index reports what its crawlers saw, so results describe a past state of the internet, and a record that a host once exposed a file does not mean it does now.

From mining farms to Tor exit nodes: the investigative recipes

Three further sections cover domains of use that are less about a single asset and more about a category of infrastructure.

The crypto section has three recipes. One is for searching mining farms, another for finding websites infected with cryptominers, and the third for finding vulnerable Bitcoin nodes. These are the kind of queries that have no counterpart in a general web search, because the subject is a server configuration rather than a page, and an index that records ports, banners and TLS data is the only way to answer them at scale.

The pentest section is the longest of the three in the table of contents, and its recipes are reconnaissance rather than exploitation. There is a subdomain search recipe, a section on searching for sites with specific vulnerabilities, and a more specific one on searching for sites with vulnerabilities whose descriptions contain a certain word, which is a way of narrowing a known issue to the deployments that look like yours. There is a section on searching by server HTTP header, one on searching for vulnerable servers by favicon hash, and one on searching by tag name.

The favicon hash recipe deserves a note because it is a technique that a newcomer would not arrive at independently. A favicon is a small image every site requests, and many are default or shared, so a hash of it becomes a fingerprint of the software behind the site. It is a way of identifying a product without a version banner, which is useful precisely when the banner is absent or misleading.

The section also has a recipe for searching for vulnerable servers and devices near you or any other location, one for login and admin panels, one for vulnerable database admin panels, and one for sites vulnerable to SQL injection. The last of those returns indicators rather than instructions, and the guide's framing throughout is that the results are the input to a human decision.

The IoT section lists nine basic search routes: by title, inside the body, by port number, by banner, by favicon, by server headers, by cookies, by tag, and additional search filters. This is the section that best illustrates the index's distinctive value, since consumer devices rarely serve pages that a web search can find, but they do expose banners and headers.

The darknet section covers Tor exit node search and collecting links to .onion sites, which is a different kind of collection problem since those addresses are not resolvable or indexable by ordinary crawlers.

Scraping, scripts and the shape of a maintained guide

The scraping section closes the loop with the API sections, because once the index has told you which hosts to look at, you still need to fetch the pages themselves.

Three approaches are given. The first uses the Beautifulsoup package, the second uses the re package for regular expression extraction, and the third points at other Python packages for scraping. The choice of re alongside BeautifulSoup is deliberate and slightly old-fashioned: a regular expression against a raw response is fast and dependency-free, and for pulling a single value out of a page it beats parsing the whole document. The guide is not advocating a full HTML parser as the default.

The scripts/ directory at the repository root presumably holds the code that accompanies the recipes, and the images/ directory holds the screenshots, which is the usual split for a guide of this kind.

On maintenance, the repository is not archived and the last push was on 2026-09-18, on the main branch. The repository has no GitHub releases, so the guide is versioned only by its commits. That is normal for a document, and it has one consequence worth naming: a recipe that worked against the API a year ago may not match the current response shape, and there is no tag to compare against.

The projects that a reader would bring to this guide are the ones it points at rather than the ones it contains. The scraping section names Beautifulsoup and re, the API section names jq, the Python library is used for its own requests, and the code-checkers and AI tool sections are about producing working request code in the first place. The guide is best read as a worked example of how to structure a query, then reimplemented against the tool set you already have.

The topics attached to the repository, osint, pentest, bugbounty and cybersecurity, together with the awesome and awesome-list tags, place it in the family of curated link and recipe collections rather than in the family of maintained software.

Editorial conclusion

netlas-cookbook is worth bookmarking for anyone who has to automate asset discovery rather than browse a web interface, because it collects the filter syntax, the API request shape and the response keys in one place, and the recipes are written as automations rather than screenshots. It is the wrong thing to adopt if you need offline data, since the guide is entirely about querying a live hosted index, and it is the wrong thing to expect from a tool, because this repository is documentation for someone else's service and carries no code of its own beyond a scripts/ directory. Before you rely on a recipe, check the licence field on the repository, which says CC0-1.0, and confirm the API key and account terms on the service side, because the guide documents a hosted product whose pricing and access rules it does not control.

Frequently asked questions

Official sources

1. Issues
2. License: CC0-1.0
3. netlas-io/netlas-cookbook on GitHub
4. README