Pivoting through a Sea of indicators to spot Turtles

December 27, 2023 by StrikeReady Labs10 minutes

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.

hashextracted indicator for pivotfilename from VT


71bbcd06a4a28f1f33a998928bfe6d78aa7a56fe068c61556f41e2586809a470xss[.]codes(potential test xlsm)


“hello martin”
d7d699f04463e86abc85ec029953ea7d558fd385a5e73ce0cc0d9cd0dbebd41ecMd.eXE, “hello hgroup”



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 2: obligatory IDA of d7d699f04463e86abc85ec029953ea7d558fd385a5e73ce0cc0d9cd0dbebd41e

Figure 3: b0307e523e5893f2a865b0abea91cb4fb2e9d86fc71e33adaf63c8878fac2748

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 4: PADNS coming to CARA in Q1 '24

old artifactpivot pointnewnotes
ai-connector.splendor[.]org161.35.32[.]185ai-connector.splendos[.]orgnote “splendor->splendos”
ai-connector.goldchekin[.]com168.100.10[.]187ono.technewsir[.]gqpossibly a “technews iran” spoof. however, like most pivoting these days, this is one hop away from a crypto cluster

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 Required
Date: Sat, 23 Dec 2023 22:09:37 GMT
Content-Type: application/json
Content-Length: 29
Connection: keep-alive
Server: 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 7: SSDEEP infrastructure scanning coming to CARA Q1 '24

old artifactpivot pointnew artifactnotes
Upgrade Required"192.153.57[.]31nuceciwan[.]news


“Nûçe Ciwan” is an oft-targeted Turkish news source

“Sol” is a Turkish newspaper. “haber” is Turkish for “news”
Upgrade Required"193.149.129[.]182solhaber[.]info“sol” is a Turkish newspaper
Upgrade Required"87.120.254[.]120caglayandergisi[.]net“Çağlayan Dergisi” is a Turkish blogger
Upgrade Required"93.123.12[.]151infohaber[.]net“haber” is Turkish for “news”
Upgrade Required"serverssl[.]net206.71.149[.]112146.70.157[.]28
Upgrade Required"168.100.9[.]203exp-al-marsad[.]co (PTR)not registered, although “Sl Marsad” is a human rights organization in the region

These domains were seen pointing to .232 only before the “upgrade behavior” started. Additional overlaps show lure domains with Iranian dissidents, such as Mahsa Aminiw, but will not be included in the high confidence indicator list

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 9: SSL cert scanning coming to CARA Q1 '24

old artifactpivot pointnew artifactnotes
206.166.251[.]163426 + certwww.alarabiyaa[.]onlineA spoof of Al Arabiya, an Arabic language news organization
206.71.149[.]112426 + certwww.pictture[.]online426 is the only link, provided for posterity. However, it was created a week apart from the above domain, both leveraging the ‘online’ tld
45.61.139[.]232426 + certyoutu[.]vc426 is the only firm link, so provided for posterity. However both this and the ’tiktok’ leverage the obscure tld ‘.vc’.
64.190.113[.]216426 + certtiktok[.]vc426 is the only link, provided for posterity
206.188.196[.]228426 + certtechdateweb[.]com426 is the only link, provided for posterity
206.71.149[.]218426 + certlibia[.]cc426 is the only link, provided for posterity
192.153.57[.]78426 + certamezon[.]pro426 is the only link, provided for posterity

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.

domaindomain creation timenot_beforenot_after
nuceciwan[.]news2022-11-26T11:23:562023-11-16 13:55:342024-02-14 13:55:33
solhaber[.]news2023-11-24T07:00:002023-11-24 07:57:352024-02-22 07:57:34
loading-website[.]net2023-01-19T07:00:002023-01-19 13:33:272023-04-19 13:33:26
solhaber[.]info2023-11-10T07:00:002023-11-14 07:47:072024-02-12 07:47:06
caglayandergisi[.]net2022-11-17T07:00:002023-08-24 12:52:022024-02-11 09:38:19
infohaber[.]net2023-03-24T07:35:382023-08-04 18:08:372023-11-02 18:08:36
alarabiyaa[.]online2023-11-13T21:52:212023-11-13 00:00:002024-02-11 23:59:59

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.
IPProviderFirst matching scan for 426 response426 codextechsupport cert
168.100.10[.]119BLNWX, US2023-12-15yesyes
168.100.10[.]204BLNWX, USnoyes
168.100.10[.]80BLNWX, US2023-09-24yesyes
168.100.11[.]127BLNWX, US2023-11-02yesyes
168.100.8[.]103BLNWX, USnoyes
168.100.8[.]24BLNWX, US2023-10-11yesno
168.100.8[.]245BLNWX, US2023-12-01yesno
168.100.9[.]203BLNWX, US2023-10-26yesno
192.153.57[.]204BLNWX, USnoyes
192.153.57[.]31BLNWX, US2023-11-05yesyes
192.153.57[.]78BLNWX, US2023-11-19yesno
193.149.129[.]128BLNWX, USnoyes
193.149.129[.]182BLNWX, US2023-11-19yesno
193.149.189[.]94BLNWX, US2023-12-20yesno
195.85.114[.]106BLNWX, US2023-11-03yesno
206.166.251[.]161BLNWX, USyesno
206.166.251[.]163BLNWX, US2023-12-03yesno
206.188.196[.]132BLNWX, US2023-12-19yesyes
206.188.196[.]228BLNWX, US2023-10-17yesno
206.188.196[.]90BLNWX, USnoyes
206.71.149[.]112BLNWX, US2023-12-03yesno
206.71.149[.]218BLNWX, US2023-12-23yesno
31.13.195[.]52NETERRA-AS, BG2023-11-10yesno
45.61.139[.]232BLNWX, US2023-10-05yesno
64.190.113[.]216BLNWX, US2023-12-06yesno
87.120.254[.]120NETERRA-AS, BG2023-12-07yesno
93.123.12[.]151NETERRA-AS, BG2023-09-21yesno
95.179.130[.]232AS-CHOOPA, US2023-10-27yesno

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.
initial artifactpivotnew artifactnotes
xtechsupport[.]orgwhere else have we seen this cert, that was not on a previous indicator list?168.100.10[.]204




Potentially interesting domains an additional hop away, but many at the same provider. Without stronger links, these artifacts have a lower confidence


infoviewdr[.]click, accepteddr[.]click




xtechsupport[.]org23be.xtechsupport[.]org45.61.137[.]131426 on 23be, but the domain only pointed to the IP on 12/14/23

Figure 13: Subsequent pivot from xtechsupport

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


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.