Blog Post

Security Analysis: LogMeIn


In the introductory post, I set the stage for why remote access tools should be analyzed more carefully. In a nutshell, I commonly discover these tools in many environments, often unbeknownst to the teams monitoring the networks. This is no fault of their own, as the techniques used to cross the network perimeter are quite hard to attribute without thorough analysis. These tools do make the network perimeter more permeable than security teams might like and so it is important to know who is initiating the connection, and where the communicating devices reside—especially if this isn’t the approved remote access solution. We now dive into the first of these with details on a well-known remote access tool called LogMeIn.

Initial Observation

By observing the DNS names, we’re able to see that LogMeIn uses at least two CDNs (Akamai and INAP), has very easily-identifiable domains and subdomains, and includes several IP address ranges.

Fig 1. Identifying LogMeIn Behaviors

Observation of the TLS traffic to several of these and other related IP addresses shows that there is a 16 byte hex string prefixed to the webservice subdomain on the controlling device’s communication and that both devices participating in the LogMeIn session utilize the latest version of TLS.

Fig 2. Identifying the Controller Device

Fig 3. Identifying the Controlled Device

The 16 byte hex string preceding seems to be an identifier associated with the LogMeIn client application used by the controller device. We see this communication with the infrastructure several times during a session (whether connected to anything else or not), and the 16 byte value seems to be consistent across time for the system running the application.

Therefore, we can identify unique systems with the application installed and open in this way. Also, note that this can show up both in DNS responses and in TLS Client Hello Server Name Indication extension.

Fig 4. Identifier Value Consistency (1)

Fig 5. Identifier Value Consistency (2)

In Figure 1, you may have noticed queries with the pattern app[0-9]{1,}-[0-9]{1,} We see this particular pattern again within TLS Client Hello messages’ Server Name Indication extension values when both the controller and controlled devices communicate with the LogMeIn infrastructure devices associated with control functionality.

Fig 6. TLS Server Name Identification (1)

Fig 7. TLS Server Name Identification (2)

While most of the time this pattern is prefixed by “console-” followed by 10 alphabetical characters, in some cases a string similar to the controlled system’s name (though not precisely its name, it seems) can be discovered.

Fig 8. TLS Server Name Sometimes Provides Naming

This information provides us with some insight about the infrastructure and related service providers used for LogMeIn, as well as some potential aliases for the device being connected to, but we can’t actually learn its precise name or its IP address from this information. This is unsatisfying at best.

Detailed Observation

Near the beginning of the connection to the to-be-controlled device, there are a lot of UDP flows to the same IP addresses found in our initial analysis.

Fig 9. UDP Flows Near TLS (experiment 1)

Fig 10. UDP Flows Near TLS (experiment 2)

Within those flows there are some exceptionally large UDP packets, whereas most of the remaining UDP packets are quite small. Looking into some of these shows data that is human-readable, and seems to resemble information one might find in an SSL certificate.

Fig 11. Large UDP Packets

Odd, especially considering that we’re communicating via UDP. Looking for answers, I spent a couple of minutes ruling out TLS-over-UDP solutions such as QUIC and DTLS, which led me back to studying the structure of the packets.

After more careful analysis, I was able to identify that there is another IPv4 header in the data portion of the UDP packet! Additionally, the destination IP address in the tunneled IPv4 header is the actual IP address of the other side of the communication–be it the controller or the controlled!

We’ll discuss how to determine which device in the communication you’ve captured–as well as additional details–a bit later.

Fig 12. Complete IPv4 Header in Tunneled Data

With further analysis, it becomes clear that a TCP session is actually being tunneled within the UDP session. To continue decoding, we can select the bytes of the beginning of the embedded IPv4 header (0x4500…), right-click, and choose “Decode As → IPv4.” Now we have IPv4 encapsulated data!

Fig 13. Attempting First Decode

Unfortunately, Wireshark is still unable to recognize the TCP header that comes next (or the TLS data on top of it), so more work must be done. The main reason for this stems from the fact that the encapsulated IPv4 header has set its fragmentation offset bytes to 0x0080, which means that the offset is supposed to be 1024. However, this is not true, as there is no data that comes before, and because each packet has the same value set.

Fig 14. Decode Issues

To enable Wireshark to recognize this as legitimate TCP data, a hex editor is required. By searching the PCAP for the bytes 0x008040 (offset of 1024) and replacing them with 0x000040 (no offset), we are able to clear the fragmentation bytes! Returning to Wireshark, we now see one of two things: your UDP streams have turned into TCP streams of [PSH,ACK] packets (older versions of Wireshark), or your UDP streams have turned into valid TLSv1.2 traffic. If the former, right-click on one of the packets and select “Decode As → SSL” to achieve the desired result.

Fig 15. Decoding to TLS Packets

What We Know

The only place where we can learn the proper name of the system being connected to in the session from the TLS certificate tunneled within the UDP session (as shown in the previous section).

The information contained within the tunneled TLS traffic to one of the two machines provides the following information:

  • public or private IP address of the sender (in both the outer and tunneled IPv4 headers)
  • the receiver’s private IP address (in the outer IPv4 header)
  • the receiver’s public or private IP address (in the tunneled IPv4 header)

Fig 16. Tunneled Header of a Physically Separate Device

Additionally, if both the outside and tunneled IP headers’ IP addresses match, you have learned that the devices are both on the same network (because there are no public IP addresses used, there is no way for the traffic to reach the intended recipient unless it is also local). This information can be hashed for a quicker check.

Fig 17. Tunneled Header of a Physically Local Device

How are the IP Addresses Communicated?

UDP destination ports 1152 (and sometimes also 1153) were used for communication to certain LogMeIn servers immediately preceding the sessions that contained the tunneled TLS. While the secondary server IP address associated with destination port 1153 is never returned via DNS, it is passed as what looks like a backup option in the communication with the primary control server.

Fig 18. Communication of Infrastructure IP Addresses

Additionally, port 1152 is where both the to-be-controlled device and the to-be-controller device provide the LogMeIn servers with their private IP addresses and source ports. The LogMeIn servers then provide the controlled device and controller with the other’s public (if applicable, else private local) IP address and destination port. Since the LogMeIn server learns both devices’ public and private IP addresses through this communication mechanism, it is able to determine whether the public or private local IP address should be used in the tunneled TLS traffic (because devices on the same local network configured in the most common way would have the same public IP address).

Fig 19. Physically Separated Devices

Fig 20. Physically Local Devices

The communications between the two devices immediately follows this exchange. Interestingly, the source port used to communicate with these LogMeIn servers is the port that will also be used as the source port for the tunneled communications. This is both a useful (but easy-to-modify) signature, as well as an unexpected behavior.

Determining Controller vs. Controlled

However, we still haven’t directly addressed a burning question–which side of the communication is being controlled? To answer this question, there are a few distinctions that can be made.

Only the controller has:

  • DNS requests for the names andconsole-[a-zA-Z]{10}.app[0-9]{1,}-[0-9]{1,}
  • TLS communications with the server named and the server named console-[a-zA-Z]{10}.app[0-9]{1,}-[0-9]{1,}

LogMeIn Controller Device

Fig 22. Controlled Device

Only the controlled has:

  • a DNS TXT query (specifically, for list.[0-9]{1,}

Fig 23. Controller Device

Fig 24. Controlled Device

Unfortunately, the above signatures can be changed very simply to avoid even relatively complex regular expression matches.

To distinguish the two devices in a harder-to-change way, the tunneled TLS communication should be decoded successfully. Interestingly, this tells us that the server is actually the device being controlled!

Fig 25. Distinguishing Controller from Controlled


Without knowing that this traffic is part of the LogMeIn application, it is likely that the communications occurring would have been dismissed as background noise unrelated to the more easy-to-identify behaviors. It is only with dedicated time to hunt that we uncover the true relationships between these and other seemingly unrelated sessions crossing the enterprise perimeter. Shining a light on this and other hard-to-attribute behavior–and providing actionable intelligence on portions of the exchange that are harder to modify than domains, ports, and IPs–is essential in defense of today’s networks. Be sure to check back soon for the next installment, focusing on TeamViewer!

David Pearson
David Pearson

Principal Threat Researcher