Snakes in the Satellites: On-going Turla Infrastructure

A couple months ago, we posted an entry outlining one of our newer datasets, SSL certificates. In that post, we focused on the cyber espionage group, turla, which is said to be associated with Russian government operations. Using self-signed SSL certificate fingerprints, we were able to correlate a number of IP addresses belonging to various satellite providers and unearth an extensive network of command and control domains.

Before releasing the post publicly, we did one critical item within the PassiveTotal platform - we monitored all the IP addresses. If any new domains or certificates showed up, we would get an alert through email and inside the platform. Our primary motivation behind the alerts was largely to see if the public posting changed any behaviors. While we can never be completely sure how public postings influence actor operations, it seems in this case that it was a mixed bag.

Changing Certificates

In original reporting from Kaspersky, we were able to make infrastructure connections across 42 Turla IP address based on common usage of a single self-signed SSL certificate.


Shortly after the release of our follow-on posting, we noticed a shift in certificate usage from the above self-signed Ubuntu certificate, to the new self-signed certificate seen below.

Both the original certificate and the current one being used by this actor group overlap on previously known bad IP addresses.

Using the known bad IP addresses from both of these certificates, PassiveTotal data, and our monitoring infrastructure, we were able to automatically observe new Turla infrastructure as it came online. While the actor group changed the certificate they used to secure their communications, our reporting did not seem to cause them to walk away from this infrastructure entirely, leading us to believe it is still of value to them.

In order to conduct our analysis, we used two different techniques. The first approach was manual effort to visit each IP address inside of the PassiveTotal platform. New domains that had yet to be associated with public reporting appeared white. Using this color-coding pattern, we quickly identified new domains for each IP address and classified them accordingly.

Following the Trail

By analyzing the hits from the monitor alerts, we were able to identify 42 new fully qualified domains across 11 IP addresses (detailed below) that were previously unmentioned in public reporting. It’s difficult to know whether or not these domains are truly associated with the actors, but the use of dynamic DNS (both the service and specific providers) and presence of the self-signed certificate leads us to believe these domains should be considered suspect.

Maltego for Rapid Discovery

The second technique was using our custom Maltego machines we outlined in previous posts. Leveraging the machines allowed us to perform the following logic in a matter of minutes, with no analyst intervention:

  1. Get IP address and passive DNS associations for all known Turla SSL certificates
  2. Enrich these associations with PassiveTotal tags and open source intelligence (OSINT) for all values to identify previously unknown
  3. Run a second-order passive DNS and SSL certificate history on the newly discovered domains to identify any additional infrastructure

The Maltego chart above demonstrates that with a few queries or a single machine, you can quickly identify infrastructure outliers, or those domains and IP addresses that were not previously identified through open source reporting. The red circles indicate new clusters of domain activity and pruning the chart up to only include that data provides a clean look at the new dynamic DNS domains.


From what we can tell, Turla does still seem to be active on this infrastructure, but it’s not likely to be their primary command and control any longer. A drop in domain activity and new certificates suggests that this infrastructure may be used for less valuable targets or more general operations. If you are curious to explore the current infrastructure for yourself, use this SSL certificate as a starting point. For a complete starting point, add in this older self-signed certificate that was used in previously documented attacks.