{
	"id": "6e48c193-dc3d-4751-ac0e-433a03b53807",
	"created_at": "2026-04-06T00:11:32.134656Z",
	"updated_at": "2026-04-10T03:19:58.075505Z",
	"deleted_at": null,
	"sha1_hash": "6ca7695b1b01bbbedecb22e7b5a997eaf33ab6b8",
	"title": "Finding More Indicators via Passive DNS in DomainTools Iris",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 562507,
	"plain_text": "Finding More Indicators via Passive DNS in DomainTools Iris\r\nBy Chad Anderson\r\nArchived: 2026-04-05 14:42:25 UTC\r\nFinding Additional Indicators With a SeaTurtle Deep Dive in Passive DNS Within\r\nDomainTools Iris\r\nIntroduction\r\nAs SeaTurtle keeps on swimming with its DNS hijacking campaign—originally reported by Talos—it becomes\r\nincreasingly important to monitor and examine your domains for indications of name server compromise. While\r\nsecurity measures such as two-factor authentication, DNSSEC, and locking of your domains may be great steps,\r\nthe actors behind SeaTurtle have shown that they can overcome all of those by moving laterally from tertiary\r\nvendors to exfiltrate signing certificates and credentials to DNS management services. Active monitoring is key,\r\nbut additional research through passive DNS can reveal past attacks or suspicious activity on endpoints you may\r\nnot normally be paying attention to in your infrastructure.\r\nAt DomainTools we’ve done extensive testing across passive DNS providers to come up with what we feel\r\ncomprises the top providers, which includes our partner Farsight Security, for comprehensive breadth and timely\r\ncoverage. Using this spread of vendors coupled with access to all of the other data sets in our Iris Investigate\r\nPlatform, you can quickly pivot and expand to find new artifacts. In this paper we’ll take a look at the SeaTurtle\r\nIoCs reported by Talos in DomainTools Iris with further examination through passive DNS and show how we can\r\nuncover new IoCs in DomainTools data sets.\r\nSeaTurtle Recap\r\nEssentially the SeaTurtle campaign comes down to an initial compromise via a spearphishing email or a well-known exploit on an unpatched server. Often times the attackers leveraged an outside vendor used by the end\r\norganization. The attackers then move laterally to eventually reach their primary target —sometimes through\r\nmultiple organizations—and steal credentials for issuing certificates and modifying DNS records. They then issue\r\ncertificates spoofing target domains and flip the victim nameservers to point to their own nameservers that then\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 1 of 24\n\nreturn man-in-the-middle servers for email and other services. Attackers then harvest more credentials and\r\nexfiltrate data while continuing to cement their position with these new credential sets.\r\nThese techniques give you a couple of artifacts to look for in passive DNS. First would be the man-in-the-middle\r\nservers used to siphon credentials, their IP addresses and where they were hosted. Second, the nameservers that\r\nwere swapped—both the original and the attacker-controlled nameservers. And finally, the IP addresses those\r\nnameservers pointed to and where they would be hosted. With this information you can tell from Passive DNS the\r\nduration of a man-in-the-middle attack when investigating a breach.\r\nAdditionally, you can monitor your DNS record sets for any anomalous responses falling outside your expected\r\nASN. If the victims of SeaTurtle had been monitoring for responses that contained known ephemeral cloud\r\nhosting providers—or even just IPs outside their own range—they would have been immediately aware of the\r\nbreach. This is why DNS monitoring is essential; however this core fabric of network infrastructure is often\r\noverlooked by security teams.\r\nLooking at the Indicators\r\nIn a post-GDPR world, attribution has obviously become much more difficult. Some would say it’s been relegated\r\nto its correct place—never putting much stock in attribution to begin with—and that now we should concentrate\r\non identifying and stopping attacks by fingerprinting infrastructure instead of relying on leaked registration details\r\nor other poor OpSec from an attacker. Regardless of your stance, identifying the infrastructure and techniques of\r\nattackers is the only way to generate a clear fingerprint of an actor or group so we will go through each of these\r\nindividually to suss out key points.\r\nServer Used\r\nThe actors behind SeaTurtle used all commodity VPS providers to host their nameservers and man-in-the-middle\r\nmachines on. While that isn’t anything new or particularly interesting, the spread of providers that they used\r\ncertainly is. Looking at the IoCs Talos provided we see the following spread if we look at them in Iris IP Profile\r\ntool:\r\nIP ASN\r\nGeoIP/VPS\r\nRegion\r\nProvider Target(s) Attack Time\r\n199.247.3.191 20473 Frankfurt, DE Vultr Albania, Iraq Nov 2018\r\n37.139.11.155 14061\r\nAmsterdam,\r\nNL\r\nDigitalOcean Albania, UAE Nov 2018\r\n185.15.247.140 24961\r\nDusseldorf,\r\nDE\r\nMyloc Albania Jan 2018\r\n206.221.184.133 23470\r\nPiscataway,\r\nNJ, US\r\nReliableSite Egypt Nov 2018\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 2 of 24\n\nIP ASN\r\nGeoIP/VPS\r\nRegion\r\nProvider Target(s) Attack Time\r\n188.166.119.57 14061\r\nAmsterdam,\r\nNL\r\nDigitalOcean Egypt Nov 2018\r\n185.42.137.89 8674 Stockholm, SE Netnod IX Albania Nov 2018\r\n82.196.8.43 14061\r\nAmsterdam,\r\nNL\r\nDigitalOcean Iraq Oct 2018\r\n159.89.101.204 14061 Frankfurt, DE DigitalOcean\r\nTurkey, Sweden,\r\nSyria, Armenia, USA\r\nDec 2018 –\r\nJan 2019\r\n146.185.145.202 14061\r\nAmsterdam,\r\nNL\r\nDigitalOcean Armenia Mar 2018\r\n178.62.218.244 14061\r\nAmsterdam,\r\nNL\r\nDigitalOcean UAE, Cyprus\r\nDec 2018 –\r\nJan 2019\r\n139.162.144.139 63949 Frankfurt, DE Linode Jordan Dec 2018\r\n142.54.179.69 33386\r\nKansas City,\r\nMO, US\r\nDataShack Jordan\r\nJan 2017 – Feb\r\n2017\r\n193.37.213.61 44901 Sofia, BG\r\nRedCluster\r\n(VPSag)\r\nCyprus Dec 2018\r\n108.61.123.149 20473 Roubaix, FR Vultr Cyprus Feb 2019\r\n212.32.235.160 60781\r\nAmsterdam,\r\nNL\r\nLeaseweb Iraq Sep 2018\r\n198.211.120.186 14061\r\nAmsterdam,\r\nNL\r\nDigitalOcean Iraq Sep 2018\r\n146.185.143.158 14061\r\nAmsterdam,\r\nNL\r\nDigitalOcean Iraq Sep 2018\r\n146.185.133.141 14061\r\nAmsterdam,\r\nNL\r\nDigitalOcean Libya Oct 2018\r\n185.203.116.116 44901 Sofia, BG\r\nRedCluster\r\n(VPSag)\r\nUAE May 2018\r\n95.179.150.92 20473\r\nMonroe, LA,\r\nUS\r\nVultr UAE Nov 2018\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 3 of 24\n\nIP ASN\r\nGeoIP/VPS\r\nRegion\r\nProvider Target(s) Attack Time\r\n174.138.0.113 14061\r\nAmsterdam,\r\nNL\r\nDigitalOcean UAE Sep 2018\r\n128.199.50.175 14061\r\nAmsterdam,\r\nNL\r\nDigitalOcean UAE Sep 2018\r\n139.59.134.216 14061 Frankfurt, DE DigitalOcean USA, Lebanon\r\nJul 2018 – Dec\r\n2018\r\n45.77.137.65 20473\r\nHoofddorp,\r\nNL\r\nVultr Syria, Sweden\r\nMar 2019 –\r\nApr 2019\r\n142.54.164.189 33387\r\nKansas City,\r\nMO, US\r\nDataShack Syria\r\nMar 2019 –\r\nApr 2019\r\n199.247.17.221 20473 Frankfurt, DE Vultr Sweden Mar 2019\r\n95.179.150.101 20473\r\nMonroe, LA,\r\nUS\r\nVultr\r\n(Attacker\r\nNameservers,\r\nMultiple Victims)\r\nJan 2019 –\r\nStill Resolving\r\nYou can see below that those behind SeaTurtle overwhelmingly preferred DigitalOcean and Vultr as providers\r\nusing mostly instances across all providers in the Netherlands and Germany—almost all in the EU. There are\r\nmany explanations for this choice. For example, many bad actors choose those regions for legal reasons, but it’s\r\npossible that those were just where they found compromisable servers they could use for free. Either purchased or\r\nplundered, the location is an interesting indicator to stay aware of when fingerprinting these attackers.\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 4 of 24\n\nTaking a look at campaign time or target to location used and campaign time or target to provider doesn’t reveal\r\nany additional information about these attackers and therefore limits the opportunity to fingerprint them. To get\r\nfurther we’re going to have to dig into more data sets than what is freely available from OSINT sources and that is\r\nwhere Passive DNS comes into play.\r\nHostnames and IP Addresses\r\nOnce DNS had been compromised the actors behind SeaTurtle would either change the A records to point to man-in-the-middle servers to harvest credentials or would entirely change over their victim’s NS records to point to\r\ntheir controlled nameservers then serve up new A records to man-in-the-middle servers for harvesting. In some\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 5 of 24\n\ncases, they even compromised the root nameservers. The reason for each of these different techniques with the\r\nsame end goal depends on the domain’s various security features such as DNSSEC or their third-party DNS\r\nvendor MFA.\r\nOne method to unearth more information is to take the time period of the attack, look up the IoCs from the Talos\r\nreport, then work backward to determine what matching query/response pairs can be found in the Passive DNS\r\ndata set and to see if any additional indicators would make themselves apparent. The following shows each of the\r\nIoCs provided by Talos and the domains that appeared in our Passive DNS data sets in Iris to resolve to that IP\r\naddress during the given time period. A summary of the additional analysis is given along with any additional\r\nindicators found. At the bottom will be a table of just additional IoCs if you wish to skip the details.\r\nExecutive Summary\r\nThe following is a detailed look at parsing through various bits of passive DNS data to discover or otherwise infer\r\nnew indicators. In total through our research we were able to find an additional:\r\n15 Actor Controlled Nameservers\r\n8 IP Addresses\r\n4 Man-in-the-Middle Domains\r\nFrom this information, continued monitoring and pivoting can be used to find even more indicators of\r\ncompromise related to the SeaTurtle attack. Due to the in-depth nature and time necessary to complete and verify\r\nfurther work only the following have been provided.\r\n199.247.3.191 – Albania, Iraq\r\nPassive DNS Domains\r\n*.inc-vrdl[.]iq—appeared this is a test to be globally responding for all subdomains requested includ\r\nmail[.]asp[.]gov[.]al\r\nwebvpn[.]shish[.]gov[.]al\r\nreserve435432[.]drproxy[.]website\r\nSummary of Findings\r\nThe .iq domains included here seem to be the malicious nameserver responding for all subdomains requested—\r\nalmost as if someone was enumerating subdomains. Labels included firewall, git, exchange, dev and more\r\ncommon services.\r\nFor the .al domains the first mail domain belongs to the Albanian State Police normally on an IP of 185.71.180.6.\r\nIt is worth mentioning after the attack the mail domain was pointed back at this IP. The second VPN domain\r\nbelonging to the Agjencia Kombetare Shoqerise se Informacionit— roughly translated by Google as the National\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 6 of 24\n\nAgency for Information Society which sits directly under the Albanian Prime Minister’s Office and coordinates\r\nthe development of the state’s information systems and guiding Albania’s state decisions in the digital age. One of\r\ntheir main goals is keeping up the e-Albania portal which is the electronic gateway for Albanian citizens to the\r\ngovernment.\r\nIf you look at the NS records for these domains you begin to see many points at which—both during the listed\r\nattacks and at other times—the NS records were flipped to servers running on VPS hosting infrastructure from\r\nmyLoc or DigitalOcean. Some of these switches correspond with other indicators that are listed in the original\r\nTalos report, but others are new. Four additional nameserver domains and two additional IP addresses can be\r\ngleaned from examining these swaps in passive DNS. For example, see the ns4[.]mmfasi[.]com nameserver below\r\nwhich is used by both the .iq and .al domains at one point when they were switched off of their normal\r\nnameservers. These nameservers crop up elsewhere in later indicators reviewed as well tying them to the same\r\nactors.\r\nAdditional Indicators\r\ndns[.]cloudipnameserver[.]com\r\nresolve[.]cloudipnameserver[.]com\r\nns3[.]mmfasi[.]com\r\nns4[.]mmfasi[.]com\r\n82.196.11.127\r\n198.211.125.184\r\n37.139.11.155 – Albania, UAE\r\nPassive DNS Domains\r\nmail[.]shish[.]gov[.]al\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 7 of 24\n\nSummary of Findings\r\nThe single domain in passive DNS for this host during this time period matches the mmfasi[.]com nameservers\r\nseen before. In addition to that, some odd nameservers— ns2[.]emailmarketer[.]ro and ns2[.]oink[.]ro—appear to\r\nspread on this IP during the campaign. Since they cannot be tied to any of the other indicators it’s possible these\r\nwere compromised machines redirected here. One other domain crops up spanning the time of the attacks:\r\ndemo[.]localhost[.]hu. It also cannot be tied to any of the other indicators via nameserver lookups or previous IP\r\nassignments.\r\nAdditional Indicators\r\nNone\r\n185.15.247.140 – Albania\r\nPassive DNS Domains\r\nns1[.]shish[.]gov[.]al\r\nmail[.]shish[.]gov[.]al\r\nws1[.]shish[.]gov[.]al\r\ndns[.]cloudipnameserver[.]com\r\nresolve[.]cloudipnameserver[.]com\r\nowa[.]e-albania[.]al\r\nfs[.]dgca[.]gov[.]kw\r\nedge1[.]dgca[.]gov[.]kw\r\nmail[.]dgca[.]gov[.]kw\r\nSummary of Findings\r\nThis IP address contains domains that continue to attack the mail of the shish[.]gov[.]al domain as well as\r\nexplicitly going after the OWA (Outlook Web Access) portal of e-albania[.]al domain. In addition to those\r\ndomains are the dgca[.]gov[.]kw domains that did not appear in the original report. These appear just a few days\r\nprior and fit the pattern of attacking the mail servers. Since these domains normally lie within the Kuwaiti\r\nagency’s network or Gulfnet International networks it is odd that they end up on this IP that ties to a myLoc VPS.\r\nWe feel that is enough to conclude that this IP at some point was DNS hijacking Kuwaiti domains as well. For\r\ncontext, the DGCA is the civilian aviation department that handles licenses for pilots, crew members, and\r\nengineers.\r\nLooking further into these domains we see no evidence of a swap in their NS records so it must have been a\r\nsimple switch of the A record from a compromised nameserver. There are no additional IP addresses to add, but\r\nwe can identify the recurring theme where domains point to actor controlled nameservers. This will start to build a\r\nweb throughout which all of these indicators are connected.\r\nAdditional Indicators\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 8 of 24\n\nfs[.]dgca[.]gov[.]kw\r\nedge1[.]dgca[.]gov[.]kw\r\nmail[.]dgca[.]gov[.]kw\r\n206.221.184.133 – Egypt\r\nPassive DNS Domains\r\nmail[.]petroleum[.]gov[.]eg\r\nSummary of Findings\r\nAt first it looks like this IP only points to the ReliableSite VPS that this Egypt IP sits on, but looking through\r\nrecords from a month before we can see another time that this domain was caught sending users to RedCluster—\r\nanother VPS provider used by SeaTurtle in other attacks—at 185.205.210.23. This differs from the usual IP of\r\n213.212.238.4 that this domain has had since 2010 and continued to respond to queries after the attacks.\r\nLooking up other domains tied to that IP address we do see a lot of mail-related domains in a similar time period,\r\nbut there is not enough to tie them to the rest of the SeaTurtle attacks. Included in that list though is\r\npetroamazonas[.]gob[.]ec mail domains which is interesting that they also are related to the oil industry, but\r\nlooking further into NS records for those domains have no evidence of nameserver hijacking so are hard to tie in\r\nfor sure.\r\nFinally, this is the first indicator where we see use of the mentioned ns1[.]lcjcomputing[.]com and\r\nns2[.]lcjcomputing[.]com nameservers that are actor controlled and still in use at the time of this report’s writing\r\nin December 2019. They have gone through multiple changes, but most notably they were turned “off” for almost\r\na month while being pointed to Google’s 8.8.8.8 DNS service from March to April of 2019.\r\nAdditional Indicators\r\n185.205.210.23\r\n188.166.119.57 – Egypt\r\nPassive DNS Domains\r\nsm2[.]mod[.]gov[.]eg\r\nmail[.]mod[.]gov[.]eg\r\nmail[.]nmi[.]gov[.]eg\r\nmail[.]mfa[.]gov[.]eg\r\nSummary of Findings\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 9 of 24\n\nThis follows the pattern of using the lcjcomputing[.]com nameservers to redirect mail servers. Here the MOD is\r\nthe Egyptian Ministry of Defense, NMI is the National Management Institute and MFA is the Ministry of Foreign\r\nAffairs. All are government entities.\r\nAdditional Indicators\r\nNone\r\n185.42.137.89 – Albania\r\nPassive DNS Domains\r\ndnsnode[.]netnod[.]se\r\nSummary of Findings\r\nThis domain does not fit the profile in the initial SeaTurtle report, but Cisco Talos may have access to a different\r\ndata set. This included dnsnode[.]netnod[.]se, which does tie to another IP address in passive DNS during a time\r\nperiod outside of this indicator: 159.89.101.204. At a minimum this ties this domain to the attacks. Additionally of\r\ninterest is the fact that at no point did dnsnode[.]netnode[.]se actually become a nameserver—according to passive\r\nDNS—for the netnod[.]se domain. In fact, what we do see is it switching to the additional actor controlled\r\nnameserver we have already found at ns3[.]mmfasi[.]com and ns4[.]mmfasi[.]com. It is possible that this\r\ndnsnode[.]netnod[.]se nameserver was never actually activated as well due to the low number of hits in passive\r\nDNS that we see for it.\r\nAdditionally, you’ll notice that netnod[.]se was once pointed to the ns1[.]frobbit[.]se nameserver, which is\r\nconsistent with Cisco Talos’ report. During the time of attacks on Sweden we can see the A record for this domain\r\nswitch to a Linode server at 45.56.92.19. Since the attackers only used Linode one other time during their attacks\r\nthis may mean the DNS services company coincidentally uses Linode as a backup for server migrations or during\r\nupgrades.\r\nAdditional Indicators\r\ndnsnode[.]netnod[.]se\r\n45.56.92.19\r\n82.196.8.43 – Iraq\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 10 of 24\n\nPassive DNS Domains\r\nnsa[.]gov[.]iq\r\nSummary of Findings\r\nMatching the report this attack looks to be targeting the National Security Agency of Iraq and again does so by\r\nswapping to the ns3[.]mmfasi[.]com and ns4[.]mmfasi[.]com nameservers during the attack.\r\nAdditional Indicators\r\nNone\r\n159.89.101.204 – Turkey, Sweden, Syria, Armenia and USA\r\nPassive DNS Domains\r\nns1[.]yorunge[.]com[.]tr\r\nns2[.]yorunge[.]com[.]tr\r\ndnsnode[.]netnod[.]se\r\nmail[.]pch[.]net\r\nkeriomail[.]pch[.]net\r\nSummary of Findings\r\nThis seems to fall outside of the typical tactics of those behind SeaTurtle. They seem to be redirecting private\r\ncompanies’ DNS servers here to their own DigitalOcean server. In prior attacks they would use these tertiary\r\nvendors providing DNS services to government organizations as an initial hop into those organizations. That\r\nmakes this indicator a little more interesting.\r\nIn any case, it appears that these vendors were eventually compromised. While the yorunge[.]com[.]tr domain\r\ndoes not have any evidence outside of its nameserver’s A records switching to the attacker controlled server, the\r\npch[.]net domain does at one point have its NS record point to the usual ns4[.]mmfasi[.]com and\r\nns3[.]mmfasi[.]com domains, but also has the newly appeared ns1[.]mmfasi[.]com and ns2[.]mmfasi[.]com NS\r\nrecords.\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 11 of 24\n\nConsidering that these were only ever on one IP—one later shared by ns3[.]mmfasi[.]com and ns4[.]mmfasi[.]com\r\nit looks like these may have been a test server before the other mmfasi[.]com NS record switches happened on\r\nother victim domains.\r\nAdditional Indicators\r\nns1[.]mmfasi[.]com\r\nns2[.]mmfasi[.]com\r\n146.185.145.202 – Armenia\r\nPassive DNS Domains\r\nNone Matching the report.\r\nSummary of Findings\r\nWe were unable to find any information in passive DNS that matched what the report mentioned. This could be\r\ndue either to poor coverage of passive DNS sensors from providers in Armenia or perhaps this was just used as an\r\nexfiltration server or another purpose in the campaign.\r\nAdditional Indicators\r\nNone\r\n178.62.218.244 – UAE, Cyprus\r\nPassive DNS Domains\r\n*[.]cyta[.]com[.]cy\r\nowa[.]gov[.]cy\r\nwebmail[.]gov[.]cy\r\ngovcloud[.]gov[.]cy\r\ntest[.]govcloud[.]gov[.]cy\r\nm[.]govcloud[.]gov[.]cy\r\nportal[.]ucg[.]ae\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 12 of 24\n\nSummary of Findings\r\nThe cyta[.]com[.]cy domain has dozens of responses relating to mail and admin panels and meets the usual tactic\r\nof switching to the ns1[.]lcjcomputing[.]com and ns2[.]lcjcomputing[.]com NS records for the domain before the\r\nattack then swapping in a man-in-the-middle server to presumably collect credentials.\r\nThe owa[.]gov[.]cy domain follows the same tactic, but has an additional IP address not mentioned in the report\r\nthat it gets routed to later that lasts until March. This IP address—142.54.164.189—belongs to DataShack which\r\nis another VPS provider that the attackers used with other targets, but on a later attack against Syrian domains\r\nyou’ll see later. This firmly ties them to that attack and deepens the web there.\r\nThe remaining domains follow the same pattern except for portal[.]ucg[.]ae which points to this same IP at one\r\npoint, but then switches to two actor spun up nameservers at ns30[.]ucg[.]ae and ns31[.]ucg[.]ae which both point\r\nto the DigitalOcean address of 167.99.40.72 during the attack. This shows that they had compromised the\r\nnameservers of ucg[.]ae, then leveraged that to put in A records to new nameservers that were close to the ucg[.]ae\r\nnaming convention of ns10[.]ucg-core[.]com, then redirected all traffic through there. A different set of steps for\r\nthe same result.\r\nPassive DNS Domains\r\nns30[.]ucg[.]ae\r\nns31[.]ucg[.]ae\r\n167.99.40.72\r\n139.162.144.139 – Jordan\r\nPassive DNS Domains\r\ngid[.]gov[.]jo\r\ntajneed[.]gid[.]gov[.]jo\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 13 of 24\n\nli1411-139[.]members[.]linode.com\r\nSummary of Findings\r\nThis is the one Linode address mentioned in the report although Linode was used in other parts of the hijacking\r\nprocess. GID here stands for Jordan’s General Intelligence Directorate. The method follows the same here where\r\nthe NS records are changed over to the actor controlled lcjcomputing[.]com nameservers.\r\nLooking closer at these we can see that the GID has used Cloudflare for DNS since 2016. Although this attack\r\nhappened at the end of 2018 there is another odd switch of their NS records in 2017 to ns1[.]cloudnamedns[.]com\r\nand ns2[.]cloudnamedns[.]com. Both of these addresses point to the same IP address (89.163.206.26) on a myLoc\r\nserver—another VPS provider used by SeaTurtle. This shows us that they were compromised at least one time\r\nbefore the attack reported in the Cisco report.\r\nAdditional Indicators\r\nns1[.]cloudnamedns[.]com\r\nns2[.]cloudnamedns[.]com\r\n89.163.206.26\r\n142.54.179.69 – Jordan\r\nPassive DNS Domains\r\nsts-dns[.]sts[.]com[.]jo\r\nmail[.]sts[.]com[.]jo\r\ndns[.]interland[.]com\r\nresolve[.]interland[.]com\r\ndns[.]cloudnameservice[.]com\r\nresolve[.]cloudnameservice[.]com\r\nSummary of Findings\r\nThe STS here is the IT division in Jordan known as Specialized Technical Services. They handle cybersecurity and\r\nnetworking for the state. This follows the typical of hijacking a nameserver and redirecting to man-in-the-middle\r\nmail servers. What is interesting about this IP and what passive DNS surfaces is that we have two other sets of\r\nactor controlled nameservers that crop up following one of their naming conventions on both interland[.]com and\r\ncloudnameservice[.]com. The cloudnameservice[.]com nameservers—along with being hosted on this IP address\r\n—are also earlier hosted on 82.102.14.218 which is a IOMart (UK hosting provider) VPS address.\r\nIf we look into where those nameservers were used you can see that in 2017 primus[.]com[.]jo was also pointed to\r\nthe dns[.]cloudnameservice[.]com nameserver along with sts[.]com[.]jo—likely using this initial hijacking to\r\nmove to hijacking customers that use them as vendors.\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 14 of 24\n\nAdditional Indicators\r\ndns[.]interland[.]com\r\nresolve[.]interland[.]com\r\ndns[.]cloudnameservice[.]com\r\nresolve[.]cloudnameservice[.]com\r\n82.102.14.218\r\n193.37.213.61 – Cyprus\r\nSummary of Findings\r\nNo Passive DNS data could be found for the time frame mentioned for this attack in the report, but there was a\r\nowa[.]gov[.]cy query and response pair later in 2019.\r\nAdditional Indicators\r\nNone\r\n108.61.123.149 – Cyprus\r\nPassive DNS Domains\r\nmail[.]defa[.]com[.]cy\r\nwww[.]owa[.]gov[.]cy\r\nSummary of Findings\r\nThese follow the usual tactic of hijacking to the intersecdns[.]com nameservers and using this IP for a man-in-the-middle server. Nothing else of import about this batch.\r\nAdditional Indicators\r\nNone\r\n212.32.235.160 – Iraq\r\nSummary of Findings\r\nNo passive DNS data could be found for the time frame mentioned for this attack in the report, but there are a\r\nnumber of Iraq domains during 2019 that fit the profile—all domains on the nsa[.]gov[.]iq network. These have\r\nalready been mentioned earlier in this report so it will not be repeated here.\r\nAdditional Indicators\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 15 of 24\n\nNone\r\n198.211.120.186 – Iraq\r\nPassive DNS Domains\r\nns3[.]mmfasi[.]com\r\nns4[.]mmfasi[.]com\r\nSummary of Findings\r\nNo passive DNS data could be found for the time frame mentioned for this attack in the report, but there are query\r\nand response pairs for the mmfasi[.]com attacker-controlled nameservers. Outside of that nothing new exists\r\nbehind this IP address.\r\nAdditional Indicators\r\nNone\r\n146.185.143.158 – Iraq\r\nSummary of Findings\r\nNo passive DNS data could be found for the time frame mentioned for this attack in the report.\r\nAdditional Indicators\r\nNone\r\n146.185.133.141 – Libya\r\nPassive DNS Domains\r\nns3[.]mmfasi[.]com\r\nns4[.]mmfasi[.]com\r\nSummary of Findings\r\nNo passive DNS data could be found for the time frame mentioned for this attack in the report. This was however\r\nanother hosting point for the actor controlled mmfasi[.]com nameservers.\r\nAdditional Indicators\r\nNone\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 16 of 24\n\n212.32.235.160 – Iraq\r\nSummary of Findings\r\nNo passive DNS data could be found for the time frame mentioned for this attack in the report, but there are a\r\nnumber of Iraq domains during 2019 that fit the profile—all domains on the nsa[.]gov[.]iq network. These have\r\nalready been mentioned earlier in this report so it will not be repeated here.\r\nAdditional Indicators\r\nNone\r\n185.203.116.116 – UAE\r\nPassive DNS Domains\r\nwebmail[.]mofa[.]gov[.]ae\r\njcont[.]ae\r\nSummary of Findings\r\nThe webmail[.]mofa[.]gov[.]ae domain stands out initially as just another man-in-the-middle domain for hijacking\r\nwebmail credentials for the UAE’s Ministry of Foreign Affairs, but digging into passive DNS will reveal\r\nsomething a little different. First off, this domain differs in that it never gets redirected to another nameserver that\r\nis actor controlled. Instead, we can see what looks like data exfiltration or some kind of C2 signalling through\r\nDNS. Finding out what was going on here without more network data is near impossible, but an example of the\r\nthousands of records in passive DNS during the reported time frame follows below.\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 17 of 24\n\nThe jcont[.]ae domain also shirks the usual pattern of those behind SeaTurtle attacks in that there is no NS\r\nhijacking outside of the domain’s A record itself being repointed to the RedCluster VPS IP address during the time\r\nframe of the attacks.\r\nAdditional Indicators\r\nNone\r\n95.179.150.92 – UAE\r\nPassive DNS Domains\r\nwebmail[.]mofa[.]gov[.]ae\r\nSummary of Findings\r\nThis matches the above and just seems to be one of the other IP addresses that the Ministry of Foreign Affairs’\r\nwebmail login was redirected to at one point or another.\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 18 of 24\n\nAdditional Indicators\r\nNone\r\n174.138.0.113 – UAE\r\nPassive DNS Domains\r\nnsd[.]ae\r\nmail[.]nsd[.]ae\r\nSummary of Findings\r\nThis nsd[.]ae domain’s registration lapsed in 2019 and the attack at the end of 2018. This one stands out as odd\r\nsince during the domains existence from 2013 to 2019 the only passive DNS records—or active DNS lookups we\r\ncan find on A records for this domain—point to the IP address mentioned. We are unable to tie this into the rest of\r\nthe SeaTurtle attacks as NSD is also not a government agency or current corporation that is registered in the\r\nEmirates.\r\nAdditional Indicators\r\nNone\r\n128.199.50.17 – UAE\r\nPassive DNS Domains\r\neft[.]efr[.]ae\r\nSummary of Findings\r\nThis domain also lies outside the norm for other IPs mentioned in the SeaTurtle report. The domain mentioned\r\nbelongs to a high end car services company. We are unable to tie this into the rest of the SeaTurtle attacks from\r\npassive DNS alone.\r\nAdditional Indicators\r\nNone\r\n139.59.134.21 – USA, Lebanon\r\nPassive DNS Domains\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 19 of 24\n\nns0[.]idm[.]net[.]lb\r\nns1[.]isu[.]net[.]sa\r\nfork[.]sth[.]dnsnode[.]net\r\nsa1[.]dnsnode[.]net\r\nSummary of Findings\r\nAlthough we were unable to find evidence in passive DNS on an attack on domains in the US, there was an\r\ninteresting shift of the Lebanese nameserver here at ns0[.]idm[.]net[.]lb. This nameserver was swapped to the\r\nDigitalOcean address listed and is interesting because it manages the DNS for 1,975 domains. If we assume that\r\nSeaTurtle’s target was a government organization, than of those domains, 62 are gov[.]lb domains. Going through\r\neach of those domains in passive DNS we can find some oddities such as a domain w1[.]state-security[.]gov[.]lb\r\nwhich during the attack time frame pointed to a Linode address at 45.33.91.165, bdl[.]gov[.]lb pointing to a\r\nRedCluster IP address at 185.205.210.23 (which also holds an earlier gov[.]eg domain hijacking) or cdr[.]gov[.]lb\r\npointing to a Rackspace IP address of 23.253.148.68. e believe this indicates that a number of those domains were\r\nhijacked and sent to man-in-the-middle servers for a time. Those we could find we have included as additional\r\nindicators.\r\nAs for the sa1[.]dnsnode[.]net nameserver we can see that also being directed to the same DigitalOcean server\r\nwhich is the authority for all .sa domains in the Saudi Arabian ccTLD. The fork[.]sth[.]dnsnode[.]net server which\r\nalso gets hijacked manages all of the .tz Tanzanian ccTLD domains. In addition, it is also the nameserver for\r\nlinux[.]org—the London Internet Exchange. The sheer number of domains that trust these root nameservers makes\r\nit a herculean effort to go through and find exactly which domains were targeted for man-in-the-middle attacks,\r\nbut it does show that these SeaTurtle attackers were able to take over these authoritative servers for at least a short\r\ntime during 2018. This is by far— from the evidence we have—their most impressive takeover and most\r\ndangerous.\r\nLastly, we can see that during that same time frame the ns[.]sth[.]dnsnode[.]net server was pointed to another\r\nDigitalOcean address of 82.196.11.127. This is the exact same IP address which earlier had hosted the\r\nmmfasi[.]com nameservers controlled by those behind SeaTurtle.\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 20 of 24\n\nAdditional Indicators\r\n45.33.91.165\r\n185.205.210.23\r\n23.253.148.68\r\n45.77.137.65 – Syria, Sweden\r\nPassive DNS Domains\r\nemail[.]syriatel[.]sy\r\nmail[.]syriatel[.]sy\r\nSummary of Findings\r\nSyriaTel is a mobile network provider in Syria. These email domains follow the usual pattern of hijacking the\r\nnameserver to deliver man-in-the-middle domains. The attacker controlled nameservers used are the\r\nintersecdns[.]com servers mentioned earlier.\r\nAdditional Indicators\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 21 of 24\n\nNone\r\n142.54.164.18 – Syria\r\nSummary of Findings\r\nWe were unable to find any domains in Passive DNS that confirmed this attack or use of this IP address.\r\nAdditional Indicators\r\nNone\r\n199.247.17.221 – Sweden\r\nPassive DNS Domains\r\nnsd[.]cafax[.]se\r\nSummary of Findings\r\nThis domain belongs to Cafax—a company that specializes in managing DNS and particularly DNSSEC. Those\r\nbehind SeaTurtle likely leveraged this nameserver to attack other groups like the Talos report mentioned by\r\ngetting into tertiary vendors and disabling DNSSEC. Looking in passive DNS we can see that this nsd[.]cafax[.]se\r\ndomain points to a Vultr VPS. Peering at the NS records for the cafax[.]se domain we can see that on March 27,\r\n2019 passive DNS first recorded the switch of the primary nameserver from ns[.]cafax[.]se to nsd[.]cafax[.]se. The\r\nactors must have been able to add the A record for nsd[.]cafax[.]se due to a compromise—likely at Cafax or\r\nanother DNS provider—then three days later (as recorded in passive DNS) they switched to using their controlled\r\nnameservers on the intersecdns[.]com domain.\r\nIn addition to the added nsd[.]cafax[.]se domain it looks like Cafax may have previously used another DNS\r\ncompany to manage their DNS records named Frobbit. Looking at older NS records we see an ns1[.]frobbit[.]se\r\nand looking at NS records for cafax[.]se again we see a time when the Cafax domain’s NS was again pointed to\r\nns1[.]frobbit[.]se. Looking further on that subdomain in passive DNS we can see that for a time in 2019—during\r\nthe attack—it was also pointed at a Linode server (45.56.92.19). As this matches the tactics for the actors behind\r\nSeaTurtle we can add this IP address as an additional indicator during the 2019 attacks and as of the time of this\r\nwriting it still resolves to that Linode address. This is possibly a coincidence as the attackers only used Linode one\r\nother time during the campaign.\r\nAdditional Indicators\r\n45.56.92.19\r\nns1[.]frobbit[.]se\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 22 of 24\n\nSeaTurtle Map\r\nSummary of Additional Indicators\r\nAdditional Actor Controlled Nameservers\r\ndns[.]cloudipnameserver[.]com\r\nresolve[.]cloudipnameserver[.]com\r\nns1[.]mmfasi[.]com\r\nns2[.]mmfasi[.]com\r\nns3[.]mmfasi[.]com\r\nns4[.]mmfasi[.]com\r\nns30[.]ucg[.]ae\r\nns31[.]ucg[.]ae\r\nns1[.]frobbit[.]se\r\nns1[.]cloudnamedns[.]com\r\nns2[.]cloudnamedns[.]com\r\ndns[.]interland[.]com\r\nresolve[.]interland[.]com\r\ndns[.]cloudnameservice[.]com\r\nresolve[.]cloudnameservice[.]com\r\nAdditional Man-in-the-Middle Domains\r\nfs[.]dgca[.]gov[.]kw\r\nedge1[.]dgca[.]gov[.]kw\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 23 of 24\n\nmail[.]dgca[.]gov[.]kw\r\ndnsnode[.]netnod[.]se\r\nAdditional IP Addresses\r\n142.53.169.189\r\n167.99.40.72\r\n82.196.11.127\r\n198.211.125.184\r\n185.205.210.23\r\n45.56.92.19\r\n89.163.206.26\r\n82.102.14.218\r\nConclusion\r\nAs of the time of this paper, SeaTurtle continues to effectively use these techniques to compromise various\r\norganizations and government groups. This will continue to happen as this technique remains viable and that’s\r\nwhy it is important to learn how to take these indicators and map them to produce more data points. From what we\r\nhave done here we can see that there are many more potential actor controlled nameservers to be found and will be\r\nmore in the future as those behind SeaTurtle keep using this technique. With its effectiveness will come other\r\nimitators following suit.\r\nWe at DomainTools highly recommend introducing MFA, DNSSEC and other protections for your domains\r\nalongside monitoring your DNS for any anomalies—particularly for changes in NS records.\r\nSource: https://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nhttps://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris\r\nPage 24 of 24",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MISPGALAXY",
		"Malpedia"
	],
	"references": [
		"https://www.domaintools.com/resources/blog/finding-additional-indicators-with-passive-dns-within-domaintools-iris"
	],
	"report_names": [
		"finding-additional-indicators-with-passive-dns-within-domaintools-iris"
	],
	"threat_actors": [],
	"ts_created_at": 1775434292,
	"ts_updated_at": 1775791198,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/6ca7695b1b01bbbedecb22e7b5a997eaf33ab6b8.pdf",
		"text": "https://archive.orkl.eu/6ca7695b1b01bbbedecb22e7b5a997eaf33ab6b8.txt",
		"img": "https://archive.orkl.eu/6ca7695b1b01bbbedecb22e7b5a997eaf33ab6b8.jpg"
	}
}