Sea Turtle is a threat group that tends to swim under the radar, but recently the Ministry of Justice in Greece, PWC, and others before them, published reports containing infrastructure currently in use. It was once believed that when an IP or domain was outed publicly, that an actor, especially a well-resourced one, would burn it down. In this blog we’ll pull on threads to show that isn’t always the case.

Sea Turtle, like most threat groups, leverages traditional malware for access, but also has used complex DNS hijacking techniques that were covered well in the above blogs. Many of the spoofed domains below would be of interest to those focused on domestic Turkish issues.

This analysis will focus on four major concepts in infrastructure pivoting.

1. Passive or Active DNS pivoting

• There is no perfect answer to the question “what domains are sitting on an IP?”. Data vendors try to answer this question for analysts in a variety of ways, the most common being passive or active DNS, where the vendor collects responses for DNS requests, either by sniffing resolver traffic, by reading resolver logs, or by actively doing forward record lookups of domains

2. SSL certificate tracking

• Observing SSL certificates can often broaden a set of suspect infra, either by direct movement (seeing a cert from server A move to server B), or by tracking specific attributes of certs over time.

• Additionally, it would not be uncommon to see domains in certs for which you don’t have a passive/active DNS record. An actor may prep their server and add a cert before making their campaign live.

3. Matching server response content to find similar infra

• For instance, a particular HTTP response header, the fuzzy hash of body content, or the way a server responds when you throw particular data at it. Many folks scan the internet with a 5 byte ASCII string “Gh0st”, in order to see if the server they’re talking to will respond like a Gh0st RAT server.

4. Discovering malware samples that are related to your original set, by looking for domain/ip overlaps, or by looking for static content with YARA that you don’t expect to be in many unrelated samples

When tracking a threat actor, an analyst develops a confidence for whether a particular indicator belongs in her dataset or not. This confidence is based on examining artifacts over time, and with an eye towards which technical links are of what quality. Servers often change ownership, ‘A’ records can be forged when a c2 isn’t operational, and supposed “uniqueness” may not be so unique upon further review. Sea Turtle leverages a multitude of these techniques which aggravate an investigation

Perhaps in an effort to provide a veil of legitimacy, or to improve a general “risk score” of their domain, this actor frequently points (or parks) their domain at large cloud providers, such as amazon/akamai/google. However, when the domain is used operationally, they typically leverage dedicated providers such as BLNWX, MVPS, Choopa, or the like.

Throughout their campaigns, they acquire domains (or leverage ddns) that look legitimate, such as systemctl.network, *.sslname.com, netssh.net, and serverssl.net. “serverssl” and “netssh” have nothing in common from a top level infrastructure perspective, but if you notice similar looking domains on a low density server, and see them move to IPs with the same provider, you can start to piece together lower quality sources of data.

In the first pivot, we can do simple network or yara based pivot to find samples that are similar to the PWC or Greek DOJ report. The high-fidelity IoCs are collated in a github link at the end of the post, but we provide our reasoning in each table.

Figure 1: Publicly available ST samples

Standalone string matches, after unpacking, remains an easy pivot to expand a dataset. Although these are not definitive pivot points, Sea Turtle does leverage a number of strange capitalizations and “shout-outs” to unknown persons, that can be combined to cast a net.

Figure 2: obligatory IDA of d7d699f04463e86abc85ec029953ea7d558fd385a5e73ce0cc0d9cd0dbebd41e

Figure 3: b0307e523e5893f2a865b0abea91cb4fb2e9d86fc71e33adaf63c8878fac2748

In our next pivot, we’ll examine Passive/Active DNS datasets, to try to find infrastructure “one hop” away.

Figure 4: PADNS coming to CARA in Q1 '24

Figure 5: PADNS pivots leads to more artifacts

Sea Turtle has been known to spoof news-related websites, and PWC highlighted three: alhurra[.]online, al-marsad[.]co, anfturkce[.]news. Examining their infra, some of the IPs or domains throw a 426 response seen below. A 426 error is “caused when a client is attempting to upgrade a connection to a newer version of a protocol, but the server is refusing to do so.” Despite this being a valid and common response code, when scanning the internet for that header/string, only ~25 results are returned with that exact context, and many appear to be interesting.

HTTP/1.1 426 Upgrade RequiredDate: Sat, 23 Dec 2023 22:09:37 GMTContent-Type: application/jsonContent-Length: 29Connection: keep-aliveServer: Apache
                {"detail":"Upgrade Required"}

Figure 6: Specific “426” server output from suspicious servers

Combining multiple artifacts such as the below can rule-in, or rule-out, indicators.

• Low global prevalence

• Timestamp overlaps, such as domain creation time or server ownership changes

• Historical scan non-overlaps (when was the first time this string appeared anywhere)

• Infrastructure similarly (registrars, hosting providers)

• Legitimate content or lack thereof, especially on domains with highly legitimate keywords where you would expect a domain to be actually used

In the case of our specific “Upgrade Required” string with the same headers, SilentPush reports the first time they saw it was 2023-09-21, and Censys reports a similarly narrow set of IPs.

Figure 7: SSDEEP infrastructure scanning coming to CARA Q1 '24

Figure 8: Additional discovered Turkish-themed domains

Another common pivot is to look at what SSL certs have lived on an IP address – in a specific timeframe – to understand what domains may have pointed there that your PADNS collection missed, or to find a campaign that is not fully live yet. An “indicator of (potential) future attack”. An example of this is alarabiyaa[.]online, where there is no record of a forward resolution, but we can see a cert with that domain on one of our “426” IPs, 206.166.251[.]163. The below table explores that technique.

Figure 9: SSL cert scanning coming to CARA Q1 '24

Figure 10: Additional potential infrastructure

It’s common for a domain to expire and point to an unrelated infra, but a well-formed certificate is an artifact that is generally intentionally created. For this reason, validity date ranges, along with domain creation timestamps, are useful data points when trying to timeline.

Figure 11: Certificates for lookalike/spoof domains

At one point, the ‘426’ artifact was a curiosity, but we observed other commonalities. Many of the ‘426’ servers also contained a certificate for xtechsupport[.]org, and lived on infrastructure from a very small number of providers. Unlike the other domains discovered, ‘xtechsupport’ was registered through IHS, a Turkish domain registrar. There is no content publicly available about this domain.

Figure 12: Servers currently responding with the specific ‘426’ error

At the end of an analysis exercise, it’s useful to do one last sweep through the collated indicator list, to look for commonalities that may have been missed. In the below table, armed with a higher confidence of “xtechsupport”, we’ll pivot once more.

Figure 13: Subsequent pivot from xtechsupport

For an easier to parse list of indicators, please visit our GitHub page.

Acknowledgements

The authors would like to thank the internal reviewers, as well as peer vendors, for their comments and corrections. Please get in touch if you have further corrections, or would like to collaborate on research in the future.

Additionally, we would like to thank Censys, Silent Push, and VirusTotal.