Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.

Partner Perspectives  Connecting marketers to our tech communities.
SPONSORED BY
12/21/2016
11:00 AM
Malwarebytes Labs
Malwarebytes Labs
Partner Perspectives
50%
50%

Explained: Domain-Generating Algorithms

Cybercriminals use domain-generating algorithms to prevent their servers from being blacklisted or taken down.

A domain-generating algorithm (DGA) is a program or subroutine that provides malware with new domains on demand or on the fly. Kraken was the first malware family to use a DGA (in 2008) that we could find. Later that year, Conficker made DGA a lot more famous.

The DGA technique is in use because malware that depends on a fixed domain or IP address is quickly blocked, which then hinders operations. So rather than bringing out a new version of the malware or setting everything up again at a new server, the malware switches to a new domain at regular intervals.

An example of DGA in practice is C&C servers for botnets and ransomware. If we were able to block these or take them down, we would cut the link between the victims and the threat actor. Bots would no longer be able to fetch new instructions, and machines infected with ransomware would be unable to request encryption keys and send user data.

The constant changing of the domain for the C&C server is also sometimes called “domain fluxing” or “fast fluxing,” which actually is a reference to an older technique based on abusing the DNS load balancing system.

How It Works

To better understand how these algorithms work, let’s look at the requirements they have to fulfill:

  • The routines have to generate domains that are predictable to both sides of the communication chain.
  • The routines have to be as unpredictable for security researchers as possible.
  • The domain registration fee has to be low, given the huge amounts of domains that will be used.
  • The need for speed can be enormous.
  • The registration process has to be anonymous or at least untraceable.

To achieve predictability, yet remain hard to research, DGA routines use a few building blocks:

  • The seed (base element)
  • An element that changes with time
  • Top level domains (TLDs)

 

Image courtesy of Cisco Blog

The seed can be a phrase or a number -- practically anything that the threat actor can change at will and that can be used in an algorithm. The seed and the time-based element are combined in an algorithm to create the domain name, and this “body” will be combined with one of the available TLDs.

Note that a time-based element need not be the date and time. It can be something else that varies with time -- for example, the trending topic on Twitter in a certain country at the moment of the connection. Actually, something that is difficult to predict is preferred, as this makes it harder for researchers to register certain domains ahead of time and intercept traffic or do a takeover.

Another trick to throw off countermeasures is to not use all the domains that the algorithm produces, but only certain ones. This will drastically increase the number of domains necessary to register by researchers if they plan to intercept the traffic.

When it comes to TLDs, .xyz.top, and .bid are popular at the moment. This is due to the low costs and quick availability because the registrars allow automated and anonymous domain registrations.

Cybercriminals use domain-generating algorithms to prevent their servers from being blacklisted or taken down. The algorithms produce random-looking domain names. The idea is that two machines using the same algorithm will contact the same domain at a given time, so they will be able to exchange information or fetch instructions.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/6/2020
Ripple20 Threatens Increasingly Connected Medical Devices
Kelly Sheridan, Staff Editor, Dark Reading,  6/30/2020
DDoS Attacks Jump 542% from Q4 2019 to Q1 2020
Dark Reading Staff 6/30/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-15505
PUBLISHED: 2020-07-07
MobileIron Core and Connector before 10.3.0.4, 10.4.x before 10.4.0.4, 10.5.x before 10.5.1.1, 10.5.2.x before 10.5.2.1, and 10.6.x before 10.6.0.1, and Sentry before 9.7.3 and 9.8.x before 9.8.1, allow remote attackers to execute arbitrary code via unspecified vectors.
CVE-2020-15506
PUBLISHED: 2020-07-07
MobileIron Core and Connector before 10.3.0.4, 10.4.x before 10.4.0.4, 10.5.x before 10.5.1.1, 10.5.2.x before 10.5.2.1, and 10.6.x before 10.6.0.1 allow remote attackers to bypass authentication mechanisms via unspecified vectors.
CVE-2020-15507
PUBLISHED: 2020-07-07
MobileIron Core and Connector before 10.3.0.4, 10.4.x before 10.4.0.4, 10.5.x before 10.5.1.1, 10.5.2.x before 10.5.2.1, and 10.6.x before 10.6.0.1 allow remote attackers to read files on the system via unspecified vectors.
CVE-2020-15096
PUBLISHED: 2020-07-07
In Electron before versions 6.1.1, 7.2.4, 8.2.4, and 9.0.0-beta21, there is a context isolation bypass, meaning that code running in the main world context in the renderer can reach into the isolated Electron context and perform privileged actions. Apps using "contextIsolation" are affecte...
CVE-2020-4075
PUBLISHED: 2020-07-07
In Electron before versions 7.2.4, 8.2.4, and 9.0.0-beta21, arbitrary local file read is possible by defining unsafe window options on a child window opened via window.open. As a workaround, ensure you are calling `event.preventDefault()` on all new-window events where the `url` or `options` is not ...