It never ceases to be true that the swiss cheese we call the Internet is one of the main reasons most of us in security have jobs. Case in point, earlier this week, researchers at FireEye (Muks Hirani, Sarah Jones, Ben Read) published a blog titled “Global DNS Hijacking Campaign: DNS Record Manipulation at Scale” which detailed an operation that harvests enterprise credentials through malicious manipulation of DNS records. Uncovering this activity in Awake is very simple, and our entire customer base was protected in a matter of hours.

The Threat Explained

A simplified explanation of the Techniques, Tactics, and Procedures (TTPs) is that the attacker redirects a particular subdomain of the enterprise (such as mail.victim.com, but not www.victim.com) to an attacker controlled server, which then captures credentials before transparently forwarding the user to the correct server (think ARP spoofing for the Internet age 😊). The original post contains more technical detail from observed breaches.

Awake in Action

The following screenshot shows how simple it is to uncover this activity with Awake.

This query highlights a small number of the powerful functions that enable playbook-style “forensic detection” techniques, as described below. We’ll examine the query in parts:


domain.name in domainFuzz "victim.com"

Awake’s advanced network traffic analysis (NTA) platform also operates as a passive DNS system. When using domain.name in a query, that translates to “show us all traffic, regardless of protocol (and even for unknown protocols), going to any IP address that has ever been associated with name X.” It’s worth noting that Awake’s passive DNS has visibility beyond the standard passive DNS systems, as names are extracted from not only DNS, but all protocols including TLS/SSL, HTTP, SMB, Kerberos, etc.

Additionally, this snippet has extra magic added with the domainFuzz function. This function will take a given name and look for many permutations of it, providing a powerful capability to find previously unknown names in use, in addition to discovering typo-squatting types of attacks.

In the example, “victim.com” would translate to several thousand permutations—think “victimsite.com”, “victimbenefits.com”, etc.—while also exposing typosquat domains like “vlctim.com.” From a security team’s perspective, this is practical since we’ve found that almost no one knows all of the legitimate domains tied to the organization. It also avoids the need to hardcode every potential domain name.

recipes.protocols.tls.free_certificate_providers

As the report highlighted, the attackers use many free TLS certificate providers. This snippet of the query shows a Query Definition being used. Because query defs are simple and easy-to-understand references to more complicated logic under the hood, we frequently refer to them as “investigative building blocks.” They are simple blocks of logic that can be chained together to find attacker TTPs that would be otherwise impossible to uncover with existing products. Many Query Definitions exist in the platform for a variety of noteworthy traffic characteristics, including encrypted traffic to servers using certificates from free providers like Let’s Encrypt, cPannel, etc. The other advantage of these query defs is that the end analyst doesn’t have to figure out the complex logic (unless they want to, hey we were taught to share our toys 😉). Instead, our research team keeps them updated.

activity.ip.autonomous_system.description != "Not Routed"

Activity in Awake can be filtered in or out based on destination information as well. For instance, in this case for Autonomous System Numbers (ASN) or descriptions. Here we are only including traffic that is leaving the enterprise and going somewhere external. (This part of the query uses a double-negative to catch all external traffic by saying “not not routed.”)

recipes.EAQL.outlier.ASN

This is another example of a simple investigative building block (think: detection based on playbooks), but this one is more complex behind the scenes since it uses a combination of logic across network activity, protocols, and time.

For example, assume you want to find when computerA connects to computerB using RDP, then within 90 minutes of that computerB connects to computerC. Awake allows you to express such logic, and therefore uncover types of lateral movement and data exfiltration activity that is impossible to find with other existing network traffic analysis technologies.

In this case, we are taking the results from the previous parts of the query (looking for traffic going externally to any destination that is somewhat similar to the company’s domain and using freely provided SSL certificates), and then automatically examining all the destination ASNs seen in the results and only returning traffic going to outlier networks for the given enterprise and traffic set. This helps narrow the detections and avoid false positives.

Conclusion

Every time we respond to a threat like this, it is always inspiring that Awake allows detection of the generic TTP rather than focusing on the specific indicators of compromise (IoC) that are currently in the news. As we know, attackers can and do easily change them often. We find the more robust TTP detection catches all future variants by focusing on the underlying attacker infrastructure and processes.

By Gary Golomb
Co-founder and Chief Research Officer
Awake Security
Breach Response
Security Analysis