Abstract image of numerous blue light dots extending vertically against a soft purple background, creating a digital or futuristic ambiance, reminiscent of a DomainTools Recipe Book.
Blog Use Cases

Introducing the DomainTools “Recipe Book” Project

Going back many years in the history of DomainTools, we have spent a lot of time learning about the various ways in which practitioners can put the data we provide into practical action in their environments. After all, while we might think that pivoting around adversary infrastructure is an interesting pastime in and of itself (yes, we’re those kinds of nerds), the reason companies become DomainTools customers is because the information they glean from our products and data make a real difference in their operations. However, for the most part, DomainTools supplies the “raw materials” in the form of the data and tools that practitioners then integrate into their ecosystem and workflows to bring the power of the data to life in securing their environments.

Many security teams are of sufficient maturity that all they really need from DomainTools is to understand what data we provide and how we deliver it. From there, they plug right into their tools and processes. But what works for one organization might not work for others, and even the very “lean-forward” shops may be unaware of some of the myriad ways in which the data can be put to practical use. Our objective with this project is to deliver a set of “recipes” that enable specific capabilities that many practitioners have found valuable. 

What We’ll Deliver

In each entry of this series, we describe one or more objectives and share some tools and procedures needed to accomplish that objective. Most of these involve automation technologies of one kind or another, and—of course—at least one DomainTools product. Each entry will contain links to resources you can use to try these recipes out in your own environment if you wish. And even if you don’t have the specific tool set illustrated in a given entry, the concepts may be very transferable to the tools that you do use. The recipes in general will be of three types:

  • Automated enrichment, pivoting, or enforcement SOAR-style playbooks, sometimes using a traditional SOAR platform, or other times using a low-code or no-code automation system
  • Streamlined (but not automated) interactive workflows using common productivity tools such as Slack
  • Pre-made Iris Investigate queries that address a specific use case

Each recipe will follow a specific structure:

  • Overview—what use case the recipe solves, often with some background information about the use case
  • Ingredients: what services, applications, etc. are required to execute the recipe
  • Procedure: a high-level description of how to set up and run the recipe
  • (Sometimes) Serving suggestions: ideas for modifying or augmenting the recipe

Important notes: 

  1. These recipes aren’t a complete technical manual for each item—in most of them, you will need to refer to additional documentation for DomainTools products, third-party applications, or both. The Procedure section is a summary to give you an overview of what is involved.
  2. Because third parties will evolve their products over time, some of these procedures may become obsolete at some point.

YouRE Welcome to Hack—and Reverse Engineer!

Even if you don’t wish to use the exact recipes we’re sharing, by reverse-engineering them, you may well come up with your own playbooks or recipes inspired by these. In Tines, for example, you can click into the various components of the stories to see how the data is being used, how the APIs are being called, etc.

And now…on to our first set of recipes. Bon appetit!


Recipe 1: Type a Domain, Get a Risk Score – in Slack

This recipe uses the Tines no-code automation platform, in concert with Slack, to enable a simple but powerful use case: type a domain into Slack, receive its DomainTools Risk Score. A growing number of security professionals are adopting various Slack integrations as part of their routines. This recipe lets an analyst quickly assess the risk of a domain of interest, without having to open a DomainTools UI (or other application, such as our App for Splunk). The very nature of “SlackOps” is continuous, quick operations. 

Screenshot of Slack running this recipe

Required Components 

  • A Tines tenant (Note: Tines offers a free Community Edition)
  • Slack, with Slack Chatbot (or “Slackbot”) configured
    • Note: you need to have admin privileges in the Slack workspace where you’ll install this (or any) app
  • DomainTools Risk Evidence API endpoint (and corresponding API username and key)


  1. Ensure that you have access to the DomainTools Risk Evidence API and that your API key is readily available (If you have purchased access to this API but need help with your key, contact us at [email protected]
  2. Slack actions
    1. Go to Apps -> Create new App
    2. Choose Slash Command
    3. Choose your command name and syntax (e.g. “dtriskscore” and “enter a domain”)
    4. Import Request URL from Tines (you can find this in the first Webhook block in the story)
    5. Install the App to your workspace
  1. Tines actions
    1. Instantiate a tenant (free)
    2. Navigate to this story
    3. Enter resource: DomainTools API username
    4. Enter credential: DomainTools API key
    5. Copy Webhook URL (to paste into Slack app)
  1. If the credentials/resources in Tines are correct, you should now be able to run your command from Slack!
Tines Story for DomainTools Risk Score in Slack

Recipe 2: Block Look-Alike Domains with a DNS Firewall

This recipe also uses Tines (yes, we spent some quality tines working on these recipes) but in a different way: in conjunction with DomainTools Iris Detect and a DNS firewall called NextDNS, the recipe allows you to set up a semi-automated way to block newly-created domains that spoof keywords of your choosing. It is “semi-automated” because it uses the Block function in Iris Detect, which is set interactively by the user. This is the case because not all domains matching your keywords in Detect are necessarily malicious—indeed, sometimes they may be of your own company’s making. But for those you deem malicious, simply selecting them for the Block action sets the stage for NextDNS to take care of the rest, mediated by a Tines story that calls the Iris Detect API.

While we don’t expect that most enterprises will use NextDNS at scale, the principles of this story can be applied and modified to create a blocking or alerting rule in many other security controls. 



This recipe uses the Iris Detect API (API guide) in conjunction with interactive use of the UI. As a user of Iris Detect, you will typically review the newly-discovered domains matching your keywords, and for those you deem malicious or suspicious enough to merit blocking, you designate them for that action in the UI. The instructions below assume that you have monitors configured and that you have an API key for Detect. 

Selecting the Block action in the Iris Detect UI
  1. DomainTools Iris Detect Actions
    1. Configure monitored terms
    2. Retrieve API username/key
    3. Triage domains in UI – select items to block
  2. NextDNS Actions
    1. Create (free) account
    2. Retrieve API username/key
    3. Select DNS enforcement method (via browser, via router, etc, but note that the story as written is for the browser method)
  3. Tines Actions
    1. Enter NextDNS, Tines, and DomainTools credentials (API keys)
    2. Enter NextDNS and DomainTools resources (usernames)
Tines screenshot: credential prerequisites needing to be filled in

Recipe 3: Find Likely Phishing Domains in Iris Investigate

This recipe is an example of the premade-search-hash category, and it makes good use of the First Seen field in Iris Investigate (introduced in mid-2023) as well as other operators you can use in the Advanced Search function of Investigate—in this case, to find domains that begin or end with terms associated with multifactor authentication spoofs. It also uses the query hash function of Investigate, which is a very handy way to manage, share, or automate queries into Investigate. The query hash function works in both the UI and the API of Iris Investigate.

Ingredient (just one!):

  • Iris Investigate


  1. Log in to Iris Investigate
  2. Create or open an investigation
  3. Enter the search hash below into the search box
  4. Run the query

Serving Suggestions:

With the query imported, open Advanced Search. Here you can see the way the query was built, so you can make adjustments as desired. In our example, the query finds domains matching the begins with/ends with criteria first seen within the last day. To see a wider scope of domains, you can adjust the First Seen value to a larger span, or you can designate a specific starting date. You can also adjust the syntax of the keywords to search for.

Conclusion: Season to Taste!

These recipes are examples of just a few ways in which you can apply DomainTools data to solve specific use cases in streamlined ways. They are just a starting point—for us, because we’ll be releasing more of them regularly—and for you, because we expect that folks who are interested in this kind of application will take the ideas in new and innovative directions. 

If you’d like to see these recipes, or any other application(s) of our data, drop us a line and sign up for a personalized session with us. Happy hunting!