February 12, 2020 | Posted in Blue Teams by Pat Heaney
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 legitimate-companyy.com vs legitimate-company.com), or employ other techniques, such as the use of homoglyphs (legitimaｔe-company.com, 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.
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.
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
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.
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, Google.com might have a set of many variations including, but not limited to: g00gle.com, googl.com, or even ģoogle.com (xn--oogle-71a.com).The 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.
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.
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_table||used to store a history of seen domain names for the client|
|aws_cloudwatch_log_group||used 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_policy||an AWS IAM policy document defining what resources with which the Lambda function may interact|
|aws_iam_role||the AWS IAM role assigned to the Lambda function, containing the above defined policy|
|aws_lambda_function||Python 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_parameter||three 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.
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!