Abstract

This post describes the high level overview, technical approach and proposed mitigation of a new red teaming lateral movement technique namely "LAME”, which is based on establishing encrypted communication channels within internal networks by using trusted SSL Certificates. The “LAME” technique was identified and presented in Deloitte's annual Hacking Community of Practice (CoP) summit in Dublin in August 2018 by Evangelos Mourikis and Nikos Karouzos, members of Deloitte Greece ethical hacking team.

TLDR - The "LAME" technique: Lateral movement using trusted SSL Certificates in internal networks

Introduction

During data breach simulations and penetration testing engagements, red teamers endeavor to obtain remote access to the target internal network and elevate their privileges within the in-scope environment. Following, they establish persistent communication channels in order to continuously monitor and extract data from a specific host, pivot within the internal network and achieve the scenario objectives.

In order to establish persistent communication channels in a covert way, red teamers use a number of lateral movement techniques, usually relying on well-known TCP/IP communication protocols, trying to emulate expected network traffic and user behavior and thus remaining unnoticed. DNS, SMB and HTTP connections are commonly used for that purpose. Most of these protocols are using unencrypted communication that can be easily identified by network monitoring tools, NIDS/HIDS etc. Furthermore, the use of an encrypted channel (e.g. HTTPS) with self-signed certificates will also trigger alerts on intrusion detection / monitoring systems since it is a very common attack vector for Man In The Middle (MiTM) attacks.

Updated Antivirus software can easily identify these techniques and using the latest heuristic engines, they are able to correlate and block these type of communication channels.

Picture 1 - Unencrypted communication channel (HTTP):

Picture 2 - Trying to execute a payload with a self-signed SSL Certificate creates a number of error messages and leaves a lot of trace for the intrusion detection / monitoring tools:

The "LAME" technique

What if we could use trusted SSL Certificates for lateral movement within the internal networks?

Facts

1. Domain Name System (DNS)

Domain Implementation and Specification RFC 1035 (November 1987)[1] states that "The RDATA section of an A line in a master file is an Internet address expressed as four decimal numbers separated by dots without any imbedded spaces (e.g., "10.2.0.52" or "192.0.5.6")."

Private IP Address allocation was introduced later on (RFC 1918 - Address Allocation for Private Internets, February 1996[2]), without specifying any security considerations related to the assignment of public DNS records to private IP addresses.

Although a number of publications suggest otherwise[3][4], it is still possible to assign A records of public domain names to private (internal) IP addresses.

2. SSL Certificates

Validation and signing of SSL Certificates performed by Certificate Authorities (RFC 6125)[5] is heavily relying on checks of the respective DNS name. For efficiency purposes, the signed certificate is not bound to the corresponding IP address, so that changes in the underlying infrastructure will not affect the validity of the certificate. As a result, it is possible to issue a trusted SSL Certificate for a public DNS name resolving to a private (internal) IP address.

The "LAME" technique breakdown

Preparation

Note: A number of commercial and / or free tools can be used for preparing the required setup. For Proof-of-Concept (PoC) purposes, we used free services such as Cloudflare and LetsEncrypt.

In order to execute the LAME technique, the following preparations steps should be executed:

  • Issue an SSL certificate for internal.dotelite.gr by using the DNS verification method of LetsEncrypt[6].
  • Assign DNS A record internal.dotelite.gr to the internal IP address: 192.168.72.141 using CloudFlare.

Picture 3 - Trusted SSL certificate for public DNS name, resolving to internal IP address:

Execution

Picture 4 - The below diagram provides an overview of the "LAME" technique:

The Red Team has deployed a Command and Control (CNC) Server on IP address 192.168.72.141 and configured an HTTPS server with the signed SSL Certificate for internal.dotelite.gr.

After obtaining remote code execution on the victim's workstation (192.168.72.140), the Red Team establishes an encrypted communication channel towards the CNC. Using a PowerShell oneliner, the victim will connect to internal.dotelite.gr via the following process:

  1. Victim requests the DNS record of internal.dotelite.gr on internal DNS server.
  2. Internal DNS server forwards the DNS record request to its root DNS server on the Internet.
  3. Public DNS server (e.g. CloudFlare) responds with the DNS record pointing to the internal IP 192.168.72.141.
  4. Internal DNS server receives the above DNS record.
  5. The DNS record is stored in cache of the internal DNS server and can serve multiple similar future requests within the internal network.
  6. The DNS record is forwarded to the victim.
  7. The victim will establish an encrypted communication channel to the attacker's internal IP 192.168.72.141, using a trusted SSL Certificate.

Picture 5 - PowerShell oneliner initiating the "LAME" technique (Step 0):

Picture 6 - DNS resolution traffic for resolving the internal.dotelite.gr subdomain to the 192.168.72.141 IP address (Steps 1-6):

Picture 7 - The TLS Initiation communication (Step 7):

Picture 8 - Fully functional encrypted communication channel within the internal network (Step 7):

Picture 9 - Network traffic of the above commands execution (Step 7):

Conclusion

It is possible to obtain a trusted SSL Certificate for a public DNS name resolving to internal IP address and use it for establishing encrypted communication channels within internal networks. This can be used as a covert lateral movement technique, which bypasses intrusion detection / monitoring tools.

Furthermore, the LAME technique could be used as an APT method from the Internet in more sophisticated red teaming scenarios. In conjunction with port forwarding and proxying methods, the red teamers could create multiple covert pivoting points within the target environment, after obtaining initial foothold in the internal network. As a result, the red teaming activities could be controlled by an external CNC server over the Internet.

Mitigation

Due to the encrypted nature of communication and the validity of the exchanged SSL Certificate, detection of this lateral movement technique seems quite elaborate. Blocking HTTPS traffic between hosts within the internal network might cause availability issues for legitimate services and therefore does not seem a feasible solution. Instead, we recommend enforcing the use of centralized DNS servers within the internal network and creation of specific monitoring use cases for all requested DNS entries. Resolved DNS records should be analyzed and potential suspicious entries assigned to internal IP addresses should be further investigated. Furthermore, we recommend enhancing the monitoring capabilities on host-level, in order to timely identify alternative attack paths which could have the same result (e.g. monitor changes of local "etc/hosts" files).

Update (04/09/2018): In addition to the above suggestions, enabling anti-rebinding protections in the centralized internal DNS server (where supported) could add one more mitigation layer against the LAME technique (e.g. --stop-dns-rebind, --rebind-domain-ok options in dnsmasq[7]). Credits to Florent Daignere.

Basic Terminology

Red team

When used in a hacking context, a red team is a group of white-hat hackers that attack an organization's digital infrastructure as an attacker would in order to test the organization's defenses. The use of cyber red teams provides "real-world" attack simulations designed to assess and significantly improve the effectiveness of an entire information security program.

Lateral movement

Lateral movement refers to techniques that cyber attackers, "threat actors" or professional red teamers use to progressively move through a network as they search for the key data and assets that are ultimately the target of their attack campaigns.

Advanced persistent threat (APT)

An advanced persistent threat (APT) is a set of stealthy and continuous computer hacking processes, often orchestrated by a person or persons targeting a specific entity. An APT usually targets either private organizations, states or both for business or political motives. APT processes require a high degree of covertness over a long period of time. The "advanced" process signifies sophisticated techniques using malware to exploit vulnerabilities in systems. The "persistent" process suggests that an external command and control system is continuously monitoring and extracting data from a specific target. The "threat" process indicates human involvement in orchestrating the attack.

Disclaimer: The authors of this article are not responsible for any misuse of the information. This information shall only be used to expand knowledge and not for causing malicious or damaging attacks. You may try all of these techniques on your own computer at your own risk. Performing any hacking attempts / tests without written permission from the owner of the computer system is illegal.

  1. RFC1035 - Domain Names Implementation and Specification ↩︎

  2. RFC1918 - Address Allocation for Private Internets ↩︎

  3. RFC6752 - Issues with Private IP Addressing in the Internet ↩︎

  4. IP Addresses that should never appear in the public DNS ↩︎

  5. RFC6125 - Representation and Verification of Domain-Based Application Service Identity within Internet PKIX Certificates in the Context of TLS ↩︎

  6. LetsEncrypt DNS verification using CertBot ↩︎

  7. DNSMASQ man page ↩︎