Sea Turtle Threat Actor Profile: DNS Hijacking, Credential Capture and Defences

Sea Turtle does not need to break into its final target first: by taking over the registrars, DNS providers and hosting accounts that a target relies on, it can redirect logins to its own servers and collect valid credentials. This profile covers the group MITRE ATT&CK tracks as G1041 Sea Turtle, also known as Marbled Dust (Microsoft), Teal Kurma, Cosmic Wolf and SILICON. ATT&CK describes it as a Türkiye-linked actor active since at least 2017 that conducts espionage and service provider compromise. The page draws on ATT&CK v20 and primary research from Cisco Talos, Hunt & Hackett and Microsoft Threat Intelligence, using each source's own attribution wording. It is written for DNS and domain owners, telecoms, ISP and hosting providers, identity teams and SOC analysts. For the DNS side in depth, see the DNS Security Guide.

Key takeaways

• DNS is an identity control. Talos documented name server records changed at registrars and a registry so that users reached attacker servers, which captured their credentials while presenting valid-looking certificates.
• The supply chain is the target list. Registrars, ccTLD operators, telecoms, ISPs and IT providers were compromised to reach national security, foreign affairs and energy bodies (Talos).
• Hosting panel accounts are a front door. Hunt & Hackett saw compromised cPanel accounts used to reach environments over SSH in the Netherlands between 2021 and 2023.
• Stolen credentials feed exploits. Microsoft assessed in May 2025 that Marbled Dust likely used DNS hijacking or typosquatted domains to obtain credentials, then used them to exploit an authenticated flaw in a messaging server.
• Logs get erased. The group cleared shell and database history and overwrote Linux system logs, so off-host logging decides whether there is any evidence.

Who they are (names and aliases)

ATT&CK calls Sea Turtle Türkiye-linked and notes its targeting of registrars managing country code top-level domains. Talos (2019) assessed with high confidence that a state-sponsored actor was responsible and did not name a country. Hunt & Hackett (2024) describes an actor operating in alignment with Turkish interests. Microsoft (2025) assesses Marbled Dust as a Türkiye-affiliated espionage threat actor whose activity overlaps with what others track as Sea Turtle and UNC1326.

This page names no individuals. ATT&CK associates one software entry with the group: SnappyTCP (S1163), a Linux reverse shell that Hunt & Hackett describes as having basic command and control capability and that ATT&CK also records as a web shell.

Targeting and motivation

• Motivation: espionage. Hunt & Hackett judges the stolen data was likely used for surveillance of specific groups and individuals, including minority groups and political dissidents.
• 2017 to 2019: at least 40 organisations in 13 countries, chiefly national security bodies, foreign ministries, military, intelligence and energy organisations in the Middle East and North Africa, reached through registrars, a registry, telecoms, ISPs and IT firms (Talos).
• 2021 to 2023: telecoms, ISPs, media, IT service providers and Kurdish websites in the Netherlands (Hunt & Hackett).
• 2025: targets that Microsoft assesses with high confidence are associated with the Kurdish military operating in Iraq, alongside government, telecoms and IT organisations in Europe and the Middle East.
• Who should care: registrars, registries, DNS and hosting providers, telecoms, and any organisation whose domains, webmail or VPN portals serve people of interest to the group. See the Telecoms Threat Actors Guide.

Tactics and techniques (MITRE ATT&CK)

All IDs below are ATT&CK v20 techniques recorded against G1041, grouped by tactic. This is a selection of the most defensively useful relationships.

For the core techniques, see MITRE ATT&CK T1557 Adversary-in-the-Middle and the MITRE ATT&CK T1199 Trusted Relationship Guide.

How they abuse identities and credentials

• Registrar and DNS management accounts: Talos describes control of DNS records gained through compromised registrar credentials, stolen EPP keys or registry access. These accounts are often shared logins held by an agency or a single administrator, and they control every login page on the domain. See the Corporate Domain Registrar guide.
• User passwords captured in transit: once DNS points to an attacker server, password and one-time code logins can be relayed. FIDO2 passkeys and security keys bind authentication to the real origin and defeat this pattern. See the AiTM Phishing Guide.
• TLS certificates as credentials: Talos saw legitimate certificates, including VPN certificates, stolen and reused on attacker servers. Private keys for public services are non-human credentials and need inventory, protection and revocation plans.
• Hosting panel and SSH access: cPanel accounts and exposed SSH gave direct server access. Hunt & Hackett recommends strong passwords, secrets held in a secrets manager, two-factor authentication on exposed accounts and less internet-facing SSH. See the OpenSSH Server Hardening Guide.
• Application accounts reused for exploitation: Microsoft assessed that Marbled Dust used captured Output Messenger credentials to exploit CVE-2025-27920, an authenticated directory traversal flaw that the vendor has fixed. Stolen credentials widen the set of vulnerabilities that matter.

Notable activity

Detection and defence

What to monitor

For DNS telemetry, see the DNS Logging and Detection Guide and the Certificate Transparency Monitoring Guide for Web Teams.

Phased response plan

1. Lock the domain layer: enable registry lock (out-of-band confirmation for changes) on critical domains where the registry offers it, and enforce MFA on every registrar and DNS provider account. Document who can approve changes and test the unlock process before you need it.
2. Watch the domain layer: monitor DNS records and Certificate Transparency logs for your domains and alert on any change outside a ticket. Publish CAA records to limit which CAs may issue.
3. Move to origin-bound authentication: roll out FIDO2 security keys or passkeys for webmail, VPN and admin portals, starting with the staff most likely to be targeted. Pilot with one group, keep a fallback method for the pilot period, then remove weaker factors.
4. Shrink server access paths: put hosting panels and SSH behind VPN or allowlists, use key-based SSH with MFA, and remove compilers and database admin tools from production servers.
5. Keep evidence off the host: forward system, auth and application logs in real time to a central store the server cannot modify.
6. Respond as a credential incident: if a hijack is found, revert records, revoke certificates issued for the hijacked names, and reset passwords network-wide from a trusted network, as Talos recommends. See the DNS Hijack Playbook and the Domain Registrar Compromise Playbook.

Decision guidance

• Small organisations: MFA on the registrar account, registrar lock, CAA records, a free Certificate Transparency monitor and passkeys on email cover most of the documented chain.
• Large organisations and government: use a corporate registrar with registry lock, separate approval for DNS changes, external DNS monitoring and phishing-resistant MFA everywhere a hijack could capture a login.
• Registrars, hosting and telecoms providers: you are the trusted relationship. Enforce MFA for customer and staff panel access, protect EPP credentials, and alert customers on delegation changes.

Metrics

• Percentage of critical domains with registry lock and MFA on the registrar account.
• Time from an unexpected DNS or certificate change to alert.
• Percentage of webmail, VPN and admin logins using phishing-resistant authenticators.
• Number of internet-exposed SSH and hosting panel endpoints (trend down).
• Percentage of servers forwarding logs off-host with no gaps longer than an agreed threshold.

Framework mapping

Common failure patterns

• Registrar accounts outside the identity programme: a password-only login held by an agency or former employee controls every service on the domain.
• Trusting the padlock: Talos showed that attacker servers presented certificates browsers accepted.
• One-time codes as the strongest factor: codes typed into a hijacked page can be relayed; origin-bound authenticators cannot.
• Logs only on the server: the group overwrote local logs and history.
• Exposed panels and SSH with password logins: the documented 2021 to 2023 entry point.

Practitioner checklist

• Enable registry lock and MFA on registrar and DNS provider accounts.
• Monitor DNS records and Certificate Transparency for your domains.
• Publish CAA records for every production domain.
• Deploy phishing-resistant MFA on webmail, VPN and admin portals.
• Restrict hosting panels and SSH to allowlisted sources with key-based MFA.
• Forward Linux logs off-host in real time and watch for gaps.
• Remove compilers and database admin tools from production servers.
• Patch internet-facing applications, including messaging servers, promptly.

Standards and references

• MITRE ATT&CK: Sea Turtle (G1041)
• Cisco Talos: DNS hijacking abuses trust in core internet service
• Hunt & Hackett: Turkish espionage campaigns in the Netherlands
• Microsoft Threat Intelligence: Marbled Dust leverages zero-day in Output Messenger for regional espionage
• NIST: SP 800-53 Rev. 5
• NIST: Cybersecurity Framework 2.0

Related NHI Mgmt Group resources: DNS Security Guide · DNS Hijack Playbook · DNSSEC Deployment Guide · Salt Typhoon Threat Actor Profile · AiTM Phishing Guide