It’s understood that the threat landscape is growing and evolving, though certain trends may be quickening relative to earlier times. With adoption of large language models (LLMs) like ChatGPT, more convincing phishing lures, Business Email Compromise (BEC), and more, there are many opportunities for bad actors to craft new ways to bypass detection. While many sectors are appealing to cybercriminals, the Government sector can be particularly appealing. 

In this Best Practices Guide, we offer insights into the cyber threats facing the Government sector, what the landscape looks like for defenders, and how security teams are making effective use of adversary infrastructure analysis to gain an edge.

In this guide, readers will learn about: 

• The current threat landscape
• Successes and limitations of common defensive strategies
• The value of DNS and DNS-adjacent data in Zero Trust initiatives and in adversary analysis, and why DomainTools is a leader in this space
• How government-sector security teams are solving important security problems with DomainTools

The post Best Practices Guide Federal Government appeared first on DomainTools | Start Here. Know Now..

Earlier this year we introduced the concept of the DomainTools “Recipe Book,” a series of instructions for using DomainTools data in specific applications to meet various use cases. In each entry of this series, we’ll 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 (as did two of the three we shared last time), 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. 

Important notes (which we also included in our first entry): 

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.

And now…on to this installment!

Investigate All the Things – in Slack

Like our Slack Domain Risk Score recipe (published in the first blog in this series), this one also uses the Tines no-code automation platform, in concert with Slack, to enable a simple but powerful use case: given a domain as a starting point, get quick summary info about the domain, and pivot on shared data points to find connected domains. This recipe lets an analyst quickly develop a sense of how a given domain may fit into a larger campaign, without having to open a DomainTools UI (or other application, such as our App for Splunk). But—if you want to, you can also use the link that Slack offers to open up the actual Iris Investigate UI. You can see the blue link for that in the screenshot below.

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 Iris Investigate API endpoint (and corresponding API username and key)

Procedure 

1. Ensure that you have access to the DomainTools Iris Investigate 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 enterprisesupport@domaintools.com). Optionally, for the passive DNS (pDNS) component, you will also need a DNSDB API key.
2. Slack actions
   1. Go to Apps -> Create new App
   2. Choose Slash Command
   3. Choose your command name and syntax (e.g. “dtirisinvestigate” 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

3. Tines actions
   1. Instantiate a tenant (free)
   2. Navigate to this story
   3. Enter resource: DomainTools API username
   4. Enter resource: Domain Monitor List and associated Resource ID (optional; this is populated by another story in Tines and uses the Iris Enrich API)
   5. Enter credential: DomainTools Iris Investigate API key
   6. Enter credential: DNSDB API key (optional; for the pDNS action)
   7. Enter credential: Tines API key (obtain this from Tines)
   8. Copy Webhook URL (to paste into Slack app)

4. If the credentials/resources in Tines are correct, you should now be able to run your command from Slack! If you use the optional Monitor List component, that part will be available as soon as you have any monitored domains populated into the list.

This recipe lets you do the following things, all from Slack:

• See the component and overall Domain Risk Scores for the domain
• Open an investigation in the Iris Investigate UI (this opens a browser window)
• Explore Guided Pivots, if there are any for the domain (more on this below)
• See a list of subdomains associated with the domain
• Get a .csv output of passive DNS (pDNS) observations for the domain if you have DNSDB access
• Monitor the domain for future changes to its Risk Score (these changes will be sent as Slack messages when there is a change to the Risk Score) NOTE: this feature chains together a separate Tines story with this one.

About Guided Pivots

This is a feature in the Iris Investigate UI that’s designed to draw the analyst’s attention to the pivots that are most likely to be helpful to an investigation. While you might wonder “what sorcery is this?,” the principle is in fact very simple. For a data point (such as an IP address, name server, registrant email, etc) to be a Guided Pivot, it has to have a count of connected domains between 2 and 500. Having a connected-domains count in this range is useful because a) it’s a manageable number of other domains to examine, and b) it is more likely that the domains may be under the control of the same entity, rather than being arbitrarily lumped together (say by a hosting provider on a generic IP address). 

Using this Slack integration, if the domain you’re querying has any Guided Pivots associated with it, you will be able to select them from a dropdown list, all in the Slack UI. You can see the dropdown in the first screenshot above.

Subdomains, pDNS, and Risk Score monitoring

Each of these actions has a button in the Slack UI once it has returned the summary info for the domain you queried. The button labeled Subdomains looks at our pDNS database to surface any subdomains that have been observed for the domain (e.g. subdomain.example.com). pDNS, which is optional and uses the DNSDB API, provides more detail on resolutions that have been observed for the domain, including timestamps of those resolutions, and a variety of record types. Risk Score monitoring (which leverages another Tines story, linked above) allows you to designate the domain so that if its score changes in the future, you’ll receive a Slack notification with the new score. 

Taken together, the actions illustrated here allow analysts to carry out a lot of the tasks they often do when unknown or suspicious domains are surfaced in their environments—and from within a tool that many organizations use throughout the workday. Of course, there are many other ways to carry out these workflows, such as in our native applications or in other integrations; the best choice is the one that most directly suits your work habits.

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!

The post Investigate All the Things - in Slack appeared first on DomainTools | Start Here. Know Now..

• Identify and/or block connections to newly-created domains
• Build context around adversary-controlled infrastructure
• Identify clusters of malicious activity based infrastructure patterns
• Monitor emerging attack campaigns as the adversary develops them

Read this white paper to learn more about how DomainTools fits into your Zero Trust initiative.

The post Zero Trust and DomainTools appeared first on DomainTools | Start Here. Know Now..

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. 

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)

Procedure 

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 enterprisesupport@domaintools.com) 
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

3. 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)

4. If the credentials/resources in Tines are correct, you should now be able to run your command from 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. 

Ingredients:

• Iris Detect, with monitored keywords configured (User Guide)
• A Tines tenant
• NextDNS (there is a free version available)

Procedure:

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. 

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)

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

Procedure:

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

U2FsdGVkX18nllP6a1KEkoLbyYAkpK4vyB/7N8HBz6t+HG/exErw1eyeUomDLtJMH+3i4tUUtSWNro6djk4ss1dlvdj6sIl2ZTO3UiahXWRX1My0OO+YzTcX60yCEjT9e48nk20mgJL4AxdqWfDZJN24ijb26QFs2UJmQtxvowlu6UJMDlCLUSYVp055J6A0Bm63fCXgiHJgEzNXqluOTPEv7cKA5L4TCBXNfbU2kNV0Ahn6+bAgkaK6RbXPED4/Ut3gmCSipAh+ACtW5WSJlqLS4utr7N6nZ9Lb/YAJvAFMqApKzo9RlKjMwhmY9zgd8IVLz2RzoNEYCo8/mZ99bHg9GXakxzAEctNScLqREa2gSSdMS5WoIieWCBZkKYY4h1lrnGWQ/FH0Na4k2J+7nydoBfSnUGYB/e83GCb4hylmJynXnovk/suND8DAxNr/fn6pDjZk8S2CUOkTLoBCc6qbb7XWpbjsfopDR1GqFHRwfhqY25if5ZoKDAtrQPPnvmrga1Gqe8CsscBvP+ZEKQD+626bT30xEKgRHAe/n41W64yleO19gVLs3kHuKuzaM08RwgcVHY5LoLMiODJsAIy5ZmUBwNPAY6T31jTW1zrHu3u7XtuT8SjWsK7fHHXzS7AlxfYxrOk6uDzhP0DRMwblP8sVdNFaa2jKRu9qWw2eZGHO1WlMwjPHDEL+qLJrnYZNIig/AlSnFn9/kWfC1uHZMy136ekqlupVIYqPri8UuRIdtpU6cuI0+yNUYDeTpmPbltVoZ6xHrDWphKmpL2AWhGMttIgHwZ8PdeCllLreph0R4oL9nktEgpV9WqHTxDXk7TlohMus2QFkrYiQ9bB5uLzHJOJTBVPTFD0EKRPgDARmrS5aO9lozatFRxywHP6/aXRP+skBTR8k9upf3CMra2qmwDWLIkx8sJiRsc+wmKWCQINS4IWdMwmJVcJbSeAyfxonOfxcroYOr+sFPnWL+VUC1O1MeDVuQhSMs6bCssKfKZlZUpd4c2wx6bduAbtmOTrIU2G8QMsQ1/g2Z0ItBCE1/F+ROLWsH2pUh76nW3X6LcEGU6zxF/UFHV/bZypWOw1FMgxst9fCwnJMkAa40dnzRktVk8lyhpgbvv1zrC2+gjJ/r7/i80CprYSj2VgYI8B5uTdZZp4NExOSjXYE02tEo+Q3O0Iaj0x2FyoxOdEY3yfW4AlNtO87N7SIei5evdiNck+sNw4b1/sBZJj/nlKwEHxw7c1KfWDyaeR4R/qQVa/gjGjvonUMfH4VKwAGm4+D4SxdcOJZMUK3kYiW588Yvkzy/uxIpE4AaYYylzYevcPJVRgsTUuWZWE49UX2l93huHWznav+ruR7OeKUdohk3JvYzSlXwq58P1OHFmllDVZ/FJhDMmb/PaY1YzZ9DlBb8r8fsUnpZGnmaz5uGvdxg91uCQJDLTmpnmC/oItVki3j+fZSKpedhilvFGICWY+LVirHMZfYKHz73h4dlcTYLyjetnfLFErcwV+Pw+zHcS6R7p3sg9u/Kri3fhUdXhRzOjCe4YJ7RFfN0qwxiwfjCW0iT34UzZsq5fyG9rDIKbGuKDucC6QxeTbRmdC++pPNp6ifRYQdie/ojyZs5+AKqK7Z3WRaHkpbeOPpbBMA7A46KHX3egsXspw+jQfQP3FaRX3Pe0LZVgYZ1qbadS6rPtCPCkWdp9otIhUgFR8Bxh2AeVZskpiYJQq+bUW9G0UfEt7eKY2c9ii/U+4nnCadaLlJ700BtLgWquoyJRByqd5n1EMBdfodmPf8pc35t0Gi3MRd0vf11RrgeUJAvxXtZSAuq1xTermPkeJOAw/utJi3i5+GUnStxmsPHW2xovYaBRk54/XoBv8/Kv7k6PXgRyqOA5J/6YW6PtUU3a0Mir02IO5ohxwqg8jv+OTUz77S94KWLTNQkI2bTxpTnP9CXLSJbbYByKWbWGHx3fbgtiwKI2yJwSz4uyeqcWpvpbxBLj9hcFjMIKH1S3VySCyumLsJE75YDWEmDYuv0NHgCQKsa/eXofM4l9AoQXZN1asv+spek3+DYdtadf2vS21gyASFZ25swSyW/TlwFooEiXBBbkN+4ovqlhzSwlcMeH1AkdehulgcmsjvtZVNrarJ9wUVR6jps/Yezq4Q1/vWuShfYKzyOc31yuq+ou+klg2KpO4+Y5swA8Yfq+Zc8H8vrp+6TBycCKU9wmIsABR4MjbXLCUnXU+luKmJYgRPqZ968YepC0/mVcYaww==

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!

The post Introducing the DomainTools “Recipe Book” Project appeared first on DomainTools | Start Here. Know Now..

A contingent from DomainTools decided to tackle a more down-to-earth competition. When we saw the Recon-Aacharya Challenge to find subdomains, we couldn’t resist—this is the stuff we eat, sleep, and breathe around here! This contest was part of Recon Village (“An Open Space with Talks, Live Demos, Workshops, Discussions, and CTFs with a common focus on Reconnaissance.”) which makes sense, since enumerating infrastructure such as subdomains is a common form of both red and blue team reconnaissance. Other Recon Village items of note this year included a Jeopardy-style open source intelligence (OSINT) CTF with challenges around harvesting information and credentials from target organizations, finding password dumps, etc; and there were also a variety of fascinating talks and live demos. 

A quick aside for readers less familiar with the objective of the subdomain challenge: the subdomains (e.g. subdomain.example.com) associated with registered domains represent an important component of infrastructure for both legitimate and malicious enterprises. In fact, they are a space where malicious and legitimate sometimes cross over, since many malicious actors have stood up rogue subdomains under legitimate victim domains. Once you own (or pwn) a registered domain’s DNS server(s), there’s no real limit on the number or variety of subdomains you can populate it with. Red teams and malicious actors use subdomain enumeration to explore and possibly exploit areas of an enterprise’s holdings that may be obscure or less well-protected. Defenders use the technique to map their own attack surface, and to enumerate malicious infrastructure in order to defend against it or to gain intelligence about threat actors. So this CTF was definitely rooted in an activity that has value for hackers of any color of hat.

We didn’t go into it cocky. There are a lot of outstanding hackers out there and, while we are genuine believers in DomainTools data as the best there is, we also know that this is a big world with a lot of resources in it—not to mention the fact that some of the competing teams could also be using DomainTools data, for all we knew! And while no one on our team had stats at our fingertips to help us guesstimate how many subdomains might exist for the list of registered domains in the contest, we knew the number would not be small. We planned on having tough competition and knew it would take a good, well-planned effort to make a strong showing. We had high hopes but kept our expectations in check.

Methodology

The rules were essentially this: all teams were given the same list of about 15,000 registered domains. The challenge was to identify all currently-resolving (as of judging time) subdomains on those domains. Teams would receive one point for each valid subdomain, and lose one point for each invalid one (unless they submitted more than 5,000 invalid subdomains, which would disqualify the team). Wildcard subdomains were not allowed. Teams had a little under two days to complete their work and upload text files of their subdomains to a repository provided by the contest sponsor.

This was the first or second DEF CON for most of our team, which was composed of DomainTools employees Dan Nunes, Sean McNee, Steven Hallman, Daniel Schwalbe, and your correspondent, as well as DomainTools alumnus Dan Fernandez. We wanted to use our data the same way any of our customers would, so we excluded our insider corporate resources as well as third-party sources of data we have access to internally. Armed only with personal public cloud accounts, an unlimited DNSDB API key, and the “burner”-quality hardware we brought to DEF CON, we set out to complete the challenge.

While most of our team members are quite technical, none of us is a developer, so we relied on third-party libraries to help us out. The subfinder open source tool was key—it took care of the heavy lifting of querying DNSDB and checking for wildcard subdomains. That said, we did have to make a few modifications to meet our needs: we time-fenced the passive DNS results to the past 365 days for performance. (We’ll be submitting a PR for the subfinder team to add some DNSDB-related enhancements as soon as one of our developers has taken a pass at it). Since the contest objective requires active DNS resolution, subfinder conveniently took care of that, but it was clear that our local network capabilities would not have been sufficient to complete the challenge in time. (If you haven’t been to DEF CON before, take it from us: even at Vegas scale, putting some 30,000 tech-curious folks in a relatively small area is going to cause some network congestion). As tempting as it was to use our corporate DNS collection capabilities, we resisted that urge and stuck with personal AWS accounts. We sharded the data and leveraged terraform to complete a run of the given domains in about 2 hours, using a network with much better bandwidth than at the village itself. 

Since DNS isn’t guaranteed (remember: UDP!), and we did occasionally run into rate limits, we performed several runs of our scripts and de-duplicated the aggregated data. All in all, we identified 4.1 million active subdomains across the 14,917 registered domains, and submitted our results with fingers crossed.

How’d we do?

Once we made our submission, we weren’t sure what to expect. Was 4.1 million a good number? A good enough number to win or at least place strongly? We felt that our methodology was sound, but what if there was something we hadn’t thought of that could have put us at a disadvantage? And, of course, we knew nothing about our competitors. Per the contest rules, we were allowed to make a partial submission to see if we were on the right track, and the results looked good. But as Yogi Berra said, “it ain’t over ‘til it’s over.” 

On Sunday (closing day of DEF CON), we found out: we won! While the prize—a PlayStation 5—will have a place of honor in the DomainTools office, for us the real win was in working together on an interesting project whose larger implications are deeply meaningful to us: providing defenders with resources they need to help them fight bad actors. We are grateful to the organizers of the contest for sponsoring an activity that helped participants hone a valuable set of skills. And we’re energized for DEF CON 32!

The post Hunting Subdomains at DEF CON 31 appeared first on DomainTools | Start Here. Know Now..

But since it is still a prevalent threat, I thought it might be interesting to look into the infrastructure it’s been using (including some very recently created), to see what else we could learn about it and, ideally, to be able to stay ahead of it.

By way of background, in case you’re not familiar with it, Check Point describes Ramnit this way:

Ramnit is a banking trojan, meaning that it is primarily intended to steal account credentials for online banking. However, like many banking trojans, Ramnit is designed to be highly modular, enabling it to collect additional types of credentials such as those for social media, email, and other accounts or to download and deploy other malware.

Ramnit is often spread via phishing campaigns that may deploy multi-stage malware. Once the target falls for the initial phishing campaign and runs the malware, it downloads and executes additional malware that eventually launches the Ramnit trojan. Ramnit will then attempt to collect banking credentials and may download additional Ramnit modules or other malware to achieve the attacker’s goals.

One of the distinguishing features of the Ramnit malware is the use of both hardcoded domains and a domain generation algorithm (DGA) for command and control. Malware using a DGA generates a sequence of random-looking domains to which it sends command and control traffic. The attacker’s command and control server runs the same DGA and registers these domains, directing the traffic to the attacker-controlled system. By using a DGA, the malware can avoid DNS blocklists because it is constantly using new, unblocked domains for its traffic.

We’ll see shortly how a bit of infrastructure analysis in Iris Investigate demonstrates that set of characteristics in the last paragraph.

If you’ve attended recent DomainTools webinars, you may have heard me discuss three analytical roles of domain infrastructure features. These features can serve as characterizers, connectors, or identifiers (and in many cases are more than one of these things at once). This may seem self-evident, but it’s worth considering as we go through some Ramnit infrastructure to see how it plays out.

Our starting point is the domain zahlung[.]name. For those who aren’t German speakers, “Zahlung” means “payment.” This domain is one of the indicators that has been tied to Ramnit in some IOC lists (though it doesn’t happen to appear in the Talos blog cited earlier). Here’s what the Iris database has to say about it:

The DomainTools Risk Score doesn’t like this domain very much. As an aside, the reason that the three Threat Profile boxes say “N/A” is that this domain is pretty old by malware infrastructure standards. We stop the Threat Profile scores after a domain reaches an age of 30 months, because as a general rule, malicious infrastructure does not remain active that long.

One of the first things we tend to do after looking up a domain in Iris Investigate is to look for useful pivots that might connect that domain to others. We do this because 

1. Seeing the “company it keeps” can inform us about the nature of the original domain, and 
2. Because if we’re threatened by a given domain, we should make the effort to protect ourselves against other domains that are under the control of the same actor.

In the Iris Investigate Pivot Engine, we can see a couple of Guided Pivots. These are data points highlighted in blue; the highlight means that they have more than one, but fewer than 500 (by default) domains that share the feature. Such pivots are typically valued by analysts because they can signal correlation in a way that pivots with thousands or millions of shared domains do not. Put differently, the blue highlight means that the feature is a useful connector. For zahlung[.]name, there are guided pivots on the IP address 72[.]26.218.70 and on two fields from the SSL/TLS certificate section—the certificate’s hash, and the subject CN. 

As of this writing, that IP address is shared by 140 other domains. But are those domains actually under the control of the same actor as zahlung[.]name, or are they simply all thrown together by a hosting provider? There are a couple of ways to cross-check this. 

First, we can look at the domain names. The Pivot Preview in Investigate gives us a look at the domain names sharing this IP address (and their risk scores).

(A partial view of the Pivot Preview for this IP address)

Notice that a lot of the domain names don’t seem to represent actual words. Recall that the Check Point description of Ramnit says that some of their domains are generated by domain generation algorithms (DGAs). While it’s not proof, the high entropy (randomness) of many of the domain names sharing that IP makes them look sketchy. Moreover, the risk scores of 100 mean that these domains have already been “convicted” by well-known blocklist providers. So we’re looking at malicious infrastructure, and there’s a good chance that it’s tied to Ramnit.

But let’s not rely only on the shared hosting. Might there be other ways to solidify our assertion that these domains are related? Indeed…and one such way is by looking at passive DNS, which has the valuable benefit (among many) of showing the subdomains that have been observed with the registered (second-level) domain. Here are some passive DNS entries for zahlung[.]name:

There are some unusual subdomains there. They are not necessarily damning, (or Ramning?) but they are something to note. We tend to see subdomains that would make sense to a human—things such as mail.<domain>.com or cpanel.<domain>.com. These three-character ones are a little less usual. So now, let’s do some spot-checking of some of the other domains tied to the IP address. To keep things as relevant as possible, first we will narrow our search to just domains that are newer—within the last three months. 

This narrows us down to 9 domains. Now let’s pick the newest one, which as of this writing is boeyrhmrd[.]com, (first seen on July 15) and check its passive DNS entries. 

We can see that this domain also has some odd-looking subdomain patterns. Now that we know that these two domains have unusual subdomain patterns, we can consider those subdomain values as characterizers—they tell us that there’s something a bit different about these domains. If we combine the factors of the shared hosting, the high risk scores, and the unusual subdomain patterns, we can now have fairly high confidence that we are looking at the work of a single actor—at least for boeyrhmrd[.]com and zahlung[,]name. If the stakes were high, we could look at the subdomain structures of more or even all of the other domains on that IP. But for many defenders, this would be enough to make the determination to block the IP, or at least to block the domain names (since they could flux IPs—more on which below).

But do we know that we’ve found all of the relevant Ramnit infrastructure at this point? Not at all. We have a chunk of it, and it’s a bigger number than what’s on many IOC lists for this malware, but it’s not necessarily the whole enchilada. 

Returning to the initial view of zahlung[.]name, we had some connecting data in the SSL/TLS arena as well. Let’s see a Pivot Preview of the certificate hash:

Here we can see a mix of sensical and nonsensical domain names, with a variety of risk scores (but overall pretty high). At the bottom of the preview window, we can also see that 18 of these domains are not among the 140 we already have. So we can bring those in too, and now we’re up to 158 domains in total.

Each time we bring in more domains, it’s a good idea to do some spot-checking to see whether the ones that we’ve added look like they are relevant—in this case, whether they look like they share the Ramnit patterns we’ve seen so far. Certainly the DGA-ish domain names look that way. What about some of the domains with names that do seem to be made of real words?

This is an interesting example. We can see a couple of nonsensical subdomains, a couple of standard ones (mail, smtp), and several (apparent) name server subdomains (ns2, ns8, etc.). Not the same pattern of short non-word subdomains, but there is something this domain has in common with several of the others—large numbers of ns* subdomains. This image is only a small portion of the observed records from this domain, and there are dozens of these ns records. This might indicate fast-flux activity. Although I didn’t mention it earlier, the boeyrhmrd[.]com domain similarly shows large numbers of ns* subdomains. The combination of the shared hosting and this set of subdomain patterns is enough that if your correspondent were making recommendations to the firewall team, I’d go ahead and throw all of these 158 domains on the blocklist. We could block the IP address too, but passive DNS shows a variety of IP address A records for these domains, and all those ns subdomains suggest that these don’t hang around on the same IP address for very long. 

In fact, in a sense I’ve buried the lede here, in that another look at the Pivot Engine, without even going into passive DNS, would have shown these unusual name server patterns.

The screenshot above is a random chunk of domains out of our set. Notice that in the name server column, each domain has several name servers, and importantly, the domain of the name servers is the same as the registered domain itself. This is not a common pattern, except for large and well-known domains (e.g. Apple uses *.apple.com name servers). For newly-created domains, or domains that aren’t among the largest on the web, this pattern tends to correlate fairly strongly with high risk scores. Name server records of this kind are a characterizer, within the context of looking at potentially malicious infrastructure. 

And in this we see an example of how we can use DNS-based OSINT data to stay ahead of, or at least even with, attackers. If we enrich all of the unique domain names seen in the environment with DNS and domain data, we could create scripts for alerting or blocking that work something like “if domain age < n days AND name server domain = registered domain, alert/block.” Some clever scripting in a local DNS resolver could perhaps prevent even the first attempt to connect to such domains from succeeding. Such a script would, of course, have to have an affordance for a set of well-known legit domains that follow that pattern, so as to avoid help desk calls.

Conclusion

No two adversary investigations are the same. You might not ever observe Ramnit-related infrastructure in your environment. But the same principles from this analysis can apply to any domain-based investigation you carry out. Connecting one domain to others that share characteristics allows you to both increase your chances of flagging or blocking the larger campaign that the first domain was tied to, and increase your contextual understanding of the original domain itself. If you don’t have access to Iris Investigate but are curious, hop on over to https://domaintools.com/demo and we’ll be happy to set up a personalized demo for you. 

The post Ramnit, Jim, I’m a threat hunter, not a doctor! appeared first on DomainTools | Start Here. Know Now..

One or more confirmed and successfully-repelled attacks of a sophisticated nature can make the value of the security spend much more apparent. But any security pro would be hard-pressed to wish for such occasions because they are high-stress events that seem to occur with depressing regularity late on Friday afternoons. But even when such events do occur, and the security controls and procedures save the day, is this truly a “return on investment,” or is it better categorized as an appropriate value for the expenditure?

It’s not likely that the whole world will ever come to a consensus on which way to put it, but the good news is that there are, in fact, meaningful ways to quantify the wins associated with various security implementations. And so we introduce a study that we commissioned with Enterprise Strategy Group (ESG), an IT analysis and market research firm with extensive experience in the field. We at DomainTools take pride, of course, when we hear success stories from our customers. But these anecdotes don’t really tell us much about the actual business or monetary wins connected to the investments; they are qualitative, not quantitative. This is where ESG came in: we asked them to speak to DomainTools customers and employ a proven methodology to model net gains. Their analysis was endorsed by the customers and is what you’ll find in the pages of the study.

We asked ESG to look at two categories of DomainTools customers: end users (SOC personnel, and other practitioners on the front lines of infosec and brand protection), and OEMs (original equipment manufacturers)—firms who have embedded DomainTools technologies in their own offerings to strengthen and differentiate them in a crowded marketplace. 

We won’t recapitulate the whole study here, but a couple of spotlights are worth examining—one from the end-user perspective and one from the world of the OEM. 

Finding More Badness, Faster

It’s not controversial to say that when it comes to detecting emerging threats, time is of the essence. ESG asked survey respondents a few questions about how they spent their time and how their use of DomainTools affected that. One of the questions had to do with the rapidity of detection, and what these practitioners reported jibes with our perspective on the Internet—namely that quick detection matters, and that detecting malicious domains before they do harm (which is what lands them on those blocklists) is valuable for SOC teams.

Standing Out From the Crowd

A growing number of security products in the market today use DomainTools data as important inputs into their rules engines and other technologies. The utility of DNS, Whois, and related data points, as well as risk scoring, is evident; but when a company is looking to incorporate those kinds of data into their own products, it is often tempting to consider building the functionality in-house. After all, these are primarily OSINT (open source intelligence) data. But once engineers start to more fully understand the complexities involved in developing these capabilities, many of them opt to OEM the data from DomainTools rather than attempting to build it themselves. This lets them get compelling products to market much faster, and differentiate themselves from competitors.

Conclusion

We hope the analysis is helpful to you, especially if, like many in the field, you face constraints and appropriately incisive questions about your expenditures. The models provided by ESG may be helpful to you in quantifying your own wins (with DomainTools, and/or with other security products and services you consume). We invite you to read the study, and if you have feedback or questions, don’t hesitate to reach out! 

The post The Economic Benefits of Using DomainTools appeared first on DomainTools | Start Here. Know Now..

In this edition, we again focus on concentrations of malicious activity by the same six features we studied in the last edition in the Fall of 2021:

• Top Level Domain (TLD); for example, .com or .net
• IP Autonomous System Number (ASN); these represent an aspect of the domain’s hosting
• Nameserver ASN; these represent the hosting of the nameserver associated with a domain 
• IP Geolocation: the country code associated with the location of the domain’s IP address
• Registrar: the entity through which the domain was registered
• SSL Certificate Authority (CA): the CA for certificate(s) associated with domains

We chose these features because they’re often used by defenders and security researchers as part of a process of building out a better understanding of a domain. In many cases, the data seen at scale tend to support those intuitions. Certain TLDs, for example, have reputations among security analysts as being dangerous “neighborhoods” of the Internet, and as this and previous DomainTools Reports show, there are indeed some TLDs that have high concentrations of malicious domains. Other criteria are more ambiguous; for example, we will see that when it comes to SSL certificate issuers, some readers may be surprised by what this large-scale analysis shows—and does not show—about where the danger lies. (We first saw these surprises in our Fall 2021 edition.)

Report Methodology

Candidate Domains

The DomainTools Iris database includes around 350 million currently-registered domains. How did we  determine which of the candidate domains represent threats? There were two components to this. We identified domains that were known-bad by checking the domain names against several well-known industry blocklists which give indications of malware, phishing, or spam activity.

Secondly, we focused on those domains that were active (as of the report data snapshot), and therefore capable of packing a punch. Thus, we excluded domains that appear to be dormant. We did this by cross-checking the domains against our passive DNS sources; only those domains that have recently shown up in passive DNS are candidates for signal strength calculations. 

Signal Strength

The tables in this report are populated and sorted based on the strongest signals for phishing, malware, or spam activity associated with the populations of known-bad domains sharing the characteristic (such as TLD, IP ASN, etc). The larger the proportion of malicious domains in a given population (an IP address, a nameserver, a registrar, etc) the higher our confidence that any unknown domain from that population may be involved in the threat in question. And in actual practice, many defenders treat these signals in exactly this way: many characteristics of a domain (such as certain TLDs or certificate authorities) are viewed as caution signs. Signal strengths closer to 1.00 indicate a neutral signal, and if the signal strength is below 1.00, the item in question is actually more associated with neutral/good domains than with malicious ones. There were some cases in which, for a given threat type, our Top 10 lists had fewer than ten entities with signals above 1.00 – in other words, there were some items in some of these lists that actually signal more goodness than badness—a phenomenon we first noted in the Fall 2021 edition of the Report. For this report, we took a snapshot of the domains in existence and active as of late March, 2023. 

What Changed? What Didn’t?

In some categories, the findings this time around are remarkably similar to those in the previous report; the domain feature of SSL certificate issuer stands out in this respect, because for each of the three threat types, many of the top 10 issuers were the same as in the Q4 2021 report. In other categories, the lineup changes quite a bit. 

We’re going to give you a small teaser of some of the interesting data from this edition of the report, but of course we invite you to take a deep dive and read the report itself. For the teaser, we’re looking at two of the Top Ten lists — one with results that probably won’t surprise most readers, and one that might!

A Tale of Two Top-Ten Lists: TLD and SSL Cert Issuer

When defenders say that they automatically distrust certain TLDs, they have plenty of reason for doing so, as the following Top Ten list will show. 

A development that preceded this report (but not by long enough to make much of a difference in the statistics) may have an impact on the next edition: Freenom, the domain registrar behind some of the TLDs in these lists including .ga, .gq, .tk, .ml, and .cf, shut down its registrations after being sued by Meta. Stay tuned for the next edition to find out what the impact might be on these numbers.

This table shows the top ten TLDs ranked by signal strength for phishing. The TLDs .buzz, .rest, .cyou, .top, .monster, and .live were all in the previous Top 10 list for phishing. More notable, perhaps, compared to the last edition, is that we observed a large uptick in the absolute numbers of phishing domains in .cyou, with over 35,000 domains this time versus just under 10,000 in the previous report. In fact, even though our new thresholding rule would have eliminated only one contender from the previous Top 10 (.rest, with a total of 426 phishing domains), the absolute numbers were substantially higher this time around across many of the TLDs.

SSL Cert Issuers: Malware 

This is where some of the more surprising data turned up: our “Top Ten” list of certificate issuers did not have ten entries—the issuers in green were actually more strongly correlated with neutral domains than with malicious ones. And among the issuers with a positive correlation (signal strength) with malware, the signal strengths themselves are very mild. 

This may run at odds with some practitioners’ expectations—for example, we have heard many practitioners and researchers say that Let’s Encrypt certificates are a sign of sketchy domains. The data says otherwise—but the context is the key. A domain imitating a major brand, but with a Let’s Encrypt certificate (for example), is much more likely to be risky than a vanity site or a small-business eCommerce site with the same certificate issuer. 

Conclusion

This is the second iteration of the DomainTools Report in what we plan going forward to be a rhythm of semiannual snapshots. Over time, we intend to glean trending information about the evolving nature of concentrations of malicious activity across the Internet. At the same time, as our change in thresholding methodology demonstrates, we may continue to make small adjustments in order to give what we judge to be the most useful insights.

We hope that this and future editions will be useful to others who, like the DomainTools team, are passionate about making the Internet a safer place for everyone! Drop us a line and let us know what you think.

The post The DomainTools Report, Spring 2023 appeared first on DomainTools | Start Here. Know Now..

What happens when you add world-class passive DNS and domain registration data to one of the leading SIEM platforms?  Interesting incident response (IR) and hunting use cases are unlocked! Today, we are happy to announce the integration of the DomainTools Iris Investigate and Farsight DNSDB data sets in Microsoft’s Sentinel SIEM product. Microsoft Sentinel is a popular platform, so it’s a natural fit. This integration will afford Sentinel users new capabilities for enrichment of events raised in Sentinel.

Iris Platform Workflows and Playbooks

There are several playbooks that make use of Iris data in Microsoft Sentinel Incidents. When an Iris Enrich Domain playbook is invoked, it retrieves all the Domain objects in the Incident, and then iterates through the Domain objects and fetches the results from DomainTools Iris Enrich for each domain. From this, all the details about the domain are added as comments in a tabular format. Iris Enrich is designed for high-volume, machine-scale enrichment.  At the human-scale end of things, the Iris Investigate Domain playbook (and similar URL playbook) is comparable in data output, but in addition to the enriching datapoints themselves, the response includes attributes that have an analytically-useful number of connected domains (between 200 and 400), and  link to the DomainTools Iris Investigate UI, so you can carry out further investigation. 

But wait—you’d like the system to do some of that for you? No problem! The Iris Investigate Guided Pivots playbook does the same actions described above, but it also returns all of the domains (with risk scores) identified as first-order connections to the domain(s) originally identified in the Incident. The below screenshot gives a sense of what this looks like: the playbook has returned all of the domains connected to a specific SSL certificate hash, while the hash itself was connected to a domain raised in an Incident.

Here’s a list of additional Iris Investigate-based playbooks:

• Domain Risk Score Playbook – Given a domain or set of domains associated with an incident, return the risk scores and adjust the severity of the incident if a high risk domain is observed. Add the risk scoring details in the comments of the incident.
• Malicious Tags Playbook – Track the activities of malicious actors using the Iris Investigate UI, tagging domains of interest. Given a domain or set of domains associated with an incident, query Iris Investigate for information on those domains, and if a specified set of tags is observed, mark the incident as “severe” in Sentinel and add a comment.
• URL Playbook – Given a URL or set of URLs associated with an incident, return all DomainTools Iris Investigate data for the extracted domains from the URL as comments in the incident.
• Iris Investigate With Farsight pDNS Playbook – Given a domain or set of domains associated with an incident, enrich the domain using the DomainTools Iris Investigate API, returning whois and infrastructure details. Subsequently retrieve associated subdomains from passive DNS information seen in Farsight’s DNSDB. Farsight DNSDB API subscription required

These playbooks are only suggested workflows, and can be easily modified within Microsoft Sentinel’s logic app editor to suit your needs. 

Farsight DNSDB playbooks

That last item above referred to Farsight DNSDB—but it’s not the only way to leverage this dataset. With the Microsoft Sentinel App for Farsight DNSDB’s playbooks, an investigator can answer questions such as “where did this domain previously resolve,” or “what other domains share hosting with this domain?” Such information can be extremely valuable when trying to correlate events that may otherwise show no relationship to each other. For example, a traffic flow to an IP address that is not currently associated with a malicious domain, but where that domain did previously reside, could be an indication of harmful activity such as command and control callbacks, malware downloader traffic, or other threats. You can see this by running the DNSDB_Historical_Address playbook. Likewise, if your DNS logs contain lookups for other domains that you know to be co-hosted with a known-bad domain, then you may have threat traffic to investigate. The DNSDB_Co_Located_Hosts playbook enables this.

The various actions supported in the DNSDB integration enable you to probe the industry’s leading passive DNS database to develop insights around additional adversary assets beyond those that might have been observed in previous traffic flows to or from your protected environment. This can help uncover dormant infrastructure that could be activated by adversaries for future campaigns, or future stages of campaigns in progress.

Give them a try!

If you are a user of Microsoft Sentinel, we hope you’ll take a look at these integrations. Developing deeper context around adversary assets is essential to many network defense, incident response, and threat hunting workflows. 

DomainTools Iris Investigate and Farsight DNSDB on the Microsoft Marketplace

If you don’t already have access to the Iris Investigate, Iris Enrich (optional, enables higher-volume lookups), or Farsight DNSDB APIs, please contact your account manager and we’ll help you get connected!

The post The Perfect Pair: Integrating DomainTools Data Sets in Microsoft’s Sentinel SIEM Product appeared first on DomainTools | Start Here. Know Now..

News of the information security skills gap is no news at all; anyone in the industry at best is aware of it, and at worst is suffering because of it, whether by being overworked, being stressed to the gills, or (likely in addition to the first two) struggling to maintain the security posture they strive for. We don’t have enough smart, motivated folks in this fight.

At the same time, you also don’t have to look too deeply into infosec Twitter or other gathering places to see would-be new practitioners screened out of the game by unrealistic requirements in job descriptions for entry-level positions in the industry. As long as both of these things are true—the skills gap, and the unrealistic entry requirements—we’re going to be on the back foot security-wise.

It was encouraging, therefore, to see SANS and Jen Easterly, head of CISA, addressing this directly in a Twitter thread earlier this year:

Tale of an On-Ramp

My own entry into infosec was one that I encourage anyone interested in joining the field to consider: technical support for a security vendor. Tech support can certainly be a thankless job, but, maybe because of that, it’s often open to relatively green job-seekers. A major key to success for a technical support representative is found in the “soft skills” that sometimes get short shrift in technical fields: communication, empathy, grit, curiosity, a “can-do” attitude, etc. (a sense of humor sure helps, too.) Tech support reps in infosec, or infosec-adjacent fields such as networking, gain exposure not just to the products they are supporting, but also to the customer environments in which these products sit, the customers themselves and their roles and functions, the technology stack with which the product interoperates, the (ab)uses the customer subjects the product to, protocols and standards (such as RFCs), and much more.

Moreover, tech support folks are often sought out within a company for their insights on customers, the product itself, bugs and feature requests, and more. This means that teams such as QA, product management, marketing, technical writing, sales, and others are potential conduits to further career progress for someone in technical support. A lot of doors can open to support personnel who seek out those intra-company relationships.

I write from direct experience: this was my own avenue into what has become a very rewarding career of over two decades in the industry. I did not have a technical background when I applied for that first Level 1 technical support position, but I did have some technical aptitude, some book-smarts on TCP/IP and firewalling, and a variety of those other soft skills that do tend to get at least some emphasis in tech support roles. I also happened to be good at dealing with angry, frustrated customers, which helped a lot; but the key was that the job provided an environment where, by learning what I needed to learn to excel in supporting a complicated set of technologies, I gained a lot of crucial background knowledge to help me advance through the technical support ranks and then into other roles such as product management, product marketing, and general security evangelism.

A Well-Rounded Candidate

I also like to emphasize that skills learned in other professions or backgrounds can be incredibly valuable in technology, even if they seem unrelated. How did I get good at handling fuming customers on the phone? My first job out of college, teaching inner-city middle school students, gave me both experience and perspective in dealing with humans going through difficult things. How did I get comfortable speaking publicly to large audiences, or the media, about security issues? Perhaps my decades on stage as a professional musician had something to do with that. It’s so easy for these kinds of skills to be deemed irrelevant in technical roles, but to dismiss them is to potentially dismiss very strong candidates who can contribute to world-class security teams.

A major challenge to entering this field is an old logic trap that we, as a society, need to change: in order to get a job you need experience, but in order to get experience you need a job. Opening roles such as first-level technical support to candidates who have the right non-technical ingredients and just need a chance to put their talents to work is a step toward making the Internet more secure for everyone.

The post We Need More Roads Into Infosec appeared first on DomainTools | Start Here. Know Now..