Domain Monitoring, Fast and Cheap

by | Feb 12, 2020

If you’ve ever tried to visit a website and mistyped the URL, it’s possible you’ve encountered a typosquatting domain.  Typosquatting, formally defined, is a technique used by malicious actors where they register domain names that appear similar to legitimate domains.  The new domain is often used for the purpose of phishing the legitimate domain’s users or customers.  These domains may be one letter off from the original domain (think vs, or employ other techniques, such as the use of homoglyphs (, where the “t” is replaced with a full-width Latin small letter T, Unicode FF54).  Typosquatting is often used for email-based attacks, either as a sending domain for emails or for phishing links.

Registering a typosquatting domain, as noted in MITRE’s PRE-ATT&CK framework, is easy for an adversary, as domain registration is relatively cheap (or in some cases, free).  Recently, for example, digital risk protection company Digital Shadows detected more than 550 candidate-related and election-related domains for the 2020 United States presidential election.

In order to protect against typosquatting, cyber defenders need effective tools to monitor domain registration for potential abuse.  While commercial domain monitoring solutions assist in detecting these attacks, there are also open source projects with similar goals.  Marcin Ulikowski’s dnstwist, an existing open source tool, generates fuzzed variants of a domain name and checks whether they have DNS records. To monitor for and detect potential typosquatting of our clients’ domains, and in the SRA spirit of innovation, we have configured and operationalized this tool to run daily scans for potentially malicious domain doppelgangers.  dnstwist-monitor is a collection of AWS resources driven by a Lambda function that runs dnstwist and generates alerts based on new discoveries.


How It Works

dnstwist-monitor allows a security team to receive alerts on the discovery of typosquatting or other domains lexically similar to domains they’d like to monitor.  This allows the team to better protect the reputation of the organization and their brands.  The setup is light and it can integrate into an existing ticketing system like Atlassian Jira shown below.

Sample Jira Ticket Notification

Figure 1 – Sample Jira Ticket Notification

This ticket provides information for an analyst to start investigating the domain and a place to document their findings.  The analyst can use online lookup tools to establish the veracity of suspect domains, including, but not limited to, whois information or historical DNS records retrieved from a tool like SecurityTrails DNS History. If the analyst determines the domain poses a risk, they can escalate for further action.


AWS Architecture

Amazon Web Services (AWS) was chosen as the cloud-computing backbone for this project for its flexibility, scalability, and speed when provisioning resources.  We can adjust the code and services running on the fly, allowing for rapid development without the hassle of managing on-premise resources.  AWS Lambda also allows us to schedule the execution of this task any pay only for the time our code is running, as opposed to leaving a server or virtual machine running 24/7 only to be performing a job part of the time.


Lambda Function Workflow

Figure 2 - Workflow, from Resource Creation to Running

Figure 2 – Workflow, from Resource Creation to Running

Our dnstwist-monitor monitors for typosquatting domains and produce alerts.  After the infrastructure is created in AWS with Terraform, the dnstwist-monitor Lambda function is triggered by a CloudWatch rule.  The rule event data is passed into the Lambda function, containing the domain name and an identifying client code.

Figure 3 Test Event in the Lambda Console. This is the format for the JSON object passed in from the CloudWatch rule.

Figure 3 – Test Event in the Lambda Console. This is the format for the JSON object passed in from the CloudWatch rule.

When the Lambda function invokes, it runs dnstwist with the legitimate domain as input.  This generates many variations of the original target domain based on several fuzzers.  For example, might have a set of many variations including, but not limited to:,, or even ģ ( results are stored in a temporary file while a query is made to DynamoDB, AWS’s NoSQL database solution.  Because Lambda functions are stateless, there isn’t a way to save a history of observed domain permutations within the function itself; DynamoDB presents a solution to this state problem.  If a domain hasn’t been scanned by dnstwist-monitor before, the database is populated with all dnstwist findings.  However, if a domain has been denoted before (meaning this is not the first run for this legitimate domain), dnstwist-monitor checks to determine if there are newly found domains that aren’t already logged.  With this information, dnstwist-monitor proceeds with the logic for new detections and adds those domains to the database.

Figure 4 Selection of discoveries for stored in DynamoDB

Figure 4 – Selection of discoveries for stored in DynamoDB

Figure 5 CloudWatch debug logs for running scan of

Figure 5 – CloudWatch debug logs for running scan of

For each newly found domain, we opted to have the Lambda function create a Jira ticket for our tracking.  This way, we allow an analyst to assign the ticket to themselves and add relevant investigation notes.  If the analyst determines the domain is malicious, we can escalate this information.


Terraform Configuration

HashiCorp’s Terraform is used to define the infrastructure needed for dnstwist-monitor and standardize its deployment to AWS.  The configuration provided in dnstwist-monitor’s repository will create the following resources:

aws_dynamodb_tableused to store a history of seen domain names for the client
aws_cloudwatch_log_groupused to store logs produced while dnstwist is running
used to run dnstwist scans on a schedule, by default at randomly picked times near 3:30 AM and 7:30 PM Eastern
aws_iam_policyan AWS IAM policy document defining what resources with which the Lambda function may interact
aws_iam_rolethe AWS IAM role assigned to the Lambda function, containing the above defined policy
aws_lambda_functionPython code that runs dnstwist, saves found domains to the DynamoDB table, and creates tickets in Jira for any domains not previously seen in the DynamoDB table
aws_ssm_parameterthree Systems Manager parameters are created to store credentials used by the Lambda function to create Jira tickets

This Terraform configuration creates separate resources and IAM roles for every domain to be monitored so resources from one client cannot interact with those from another.

To deploy dnstwist-monitor, set up the AWS CLI on your machine configured with an access key from AWS IAM, install Terraform, and in the root of the dnstwist-monitor repository, run make build tf-init tf-apply.  Further details on deploying the resources can be found in the dnstwist-monitor repository.


Setup Process

Install Git and Prerequisites, Clone Repository, and Deploy

Install Git, if you do not already have it, and use this to pull down the repository.

Ensure you have Python and pip installed.  dnstwist-monitor has been tested on Python 3 (note that Python 2.7 will not be maintained as of January 1, 2020).

Follow Amazon’s guide on installing the AWS CLI; linked are the instructions for installing with Python’s PIP, but other methods are provided on the linked page’s navigation.

Follow the instructions on the linked guide to add your AWS access key.  Next, install the libraries required for dnstwist.

To deploy, be sure Terraform is installed on your host.

Enter the “tf/” directory to prepare the Terraform variables needed for deployment to AWS.  Copy “terraform.tfvars.example” to “terraform.tfvars” and fill in the appropriate values.

Once filled out, change back to the root directory for the dnstwist-monitor repository.  To initialize Terraform, build the function, and deploy the configuration to AWS, run “make clean tf-init build tf-apply”.

In a few minutes, the function and all associated resources are deployed!

Where Can I Find dnstwist-monitor?

Pat Heaney
CSOC Consultant, CySA+ | Archive

Pat focuses on developing and improving SOAR playbooks and running Purple Team Essentials engagements from both a blue and red team perspective. He is also a member of CSOC’s Security Engineering and Advanced Response (SEAR) team, where he provides architecture and engineering support and insight, maintains infrastructure and configuration automation, and contributes to research and innovation projects.

Pat is CompTIA Cybersecurity Analyst (CySA+) certified, an AWS Certified Cloud Practitioner, and a GIAC Python Coder (GPYC).

He has worked with companies across multiple industries, including pharmaceutical, healthcare, business services, and financial services.

Prior to joining SRA, Pat played roles in SOCs in the insurance and healthcare industries. He holds a degree in Security & Risk Analysis from The Pennsylvania State University.