{"lastseen": "2018-07-26T11:58:45", "references": [], "description": "Medium\n\nAlert ID: \n\n41910\n\nFirst Published:\n\n2015 November 3 20:21 GMT\n\nLast Updated:\n\n2015 November 4 20:34 GMT\n\nVersion: \n\n2\n\n## \n\nSummary \n\n * Cisco Security has detected significant activity related to spam email messages distributing malicious software. \n \nEmail messages that are related to this threat (RuleID19150) and (RuleID19150KVR) may contain the following files: \n \n**Name** | **Size in Bytes** | **MD5 Checksum** \n---|---|--- \npu.exe \n| 203,264 \n| 0xCD445E52EB7D2CA7359A8513157DD0A9 \n \nwa1.exe \n| 60,416 \n| 0xE8734DDB8A0E1E237D73249AE6737BB3 \n \nThe following text is a sample of the email message that is associated with this threat outbreak: \n\n\n> Subject: **E-Ticket Confirmation** \n \nMessage Body: \n \n**Ticket Issued: Nov 02, 2015** \n**Thank you for choosing American Airlines / American Eagle, a member of the oneworld Alliance.??Below are your itinerary and receipt for the ticket(s) purchased.??Please print and retain this document for use throughout your trip.** \n**For faster check-in??at the airport, scan the barcode below at any AA Self-Service machine.** \n**You must present a government-issued photo ID and either your boarding pass or a priority verification card at the security screening checkpoint.** \n**You can now Manage Your Reservation on aa.com, where you can check in and purchase additional items to customize your journey. A variety of seating options are also available for purchase to enhance your travel with features such as convenient front of cabin location, extra legroom and early boarding.** \n**Print your ticket from attach.** \n**As American and US Airways merge, many changes are taking place at our airport locations. Visit Find Your Way to assist with your journey.** \n\n\nOr \n\n\n> Subject:** Important - Internal Only** \n \nMessage Body: \n \n**File Validity: 03/11/2015** \n**File Format: Microsoft Word** \n**Name: Internal Only** \n**Original Filename: Internal_Only.doc** \n\n\nCisco security appliances can help protect customers during the critical period between the first exploit of a virus outbreak and the release of vendor antivirus signatures. Cisco Web Security Appliances help secure and control web and email traffic by offering layers of malware protection. Cisco security appliances are automatically updated to help prevent both spam email and hostile web URLs from being passed to the end user. \n \n**Related Links** \n[Cisco Security](<http://www.cisco.com/security>) \n[Cisco SenderBase Security Network](<http://www.senderbase.org/>)\n\n## \n\nRevision History \n\n * Version | Description | Section | Date \n---|---|---|--- \n2 | Cisco Security has detected significant activity on November 4, 2015. | | 2015-November-04 20:34 GMT \n1 | Cisco Security has detected significant activity on November 3, 2015. | | 2015-November-03 20:21 GMT \n1 | Initial Release | | 2015-November-03 20:21 GMT \nShow Less\n\n* * *\n\n## \n\nLegal Disclaimer \n\n * THIS DOCUMENT IS PROVIDED ON AN \"AS IS\" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE ALERTS AT ANY TIME. \n\nA standalone copy or paraphrase of the text of this document that omits the distribution URL is an uncontrolled copy and may lack important information or contain factual errors. The information in this document is intended for end users of Cisco products \n", "reporter": "Cisco", "published": "2015-11-03T20:21:14", "type": "ciscothreats", "title": "Threat Outbreak Alert RuleID19150: Email Messages Distributing Malicious Software on November 4, 2015", "enchantments": {"score": {"value": 0.1, "vector": "NONE", "modified": "2018-07-26T11:58:45", "rev": 2}, "dependencies": {"references": [{"type": "talosblog", "idList": ["TALOSBLOG:A09C50A444F2D7D6A5D4552C85316387", "TALOSBLOG:F2C2A5E8DB82E91E937128853BA79082"]}], "modified": "2018-07-26T11:58:45", "rev": 2}, "vulnersScore": 0.1}, "ciscoThreat": {"md5": "0xCD445E52EB7D2CA7359A8513157DD0A9", "subject": "E-Ticket Confirmation", "messageBody": "Ticket Issued: Nov 02, 2015\nThank you for choosing American Airlines / American Eagle, a member of the oneworld Alliance.??Below are your itinerary and receipt for the ticket(s) purchased.??Please print and retain this document for use throughout your trip.\nFor faster check-in??at the airport, scan the barcode below at any AA Self-Service machine.\nYou must present a government-issued photo ID and either your boarding pass or a priority verification card at the security screening checkpoint.\nYou can now Manage Your Reservation on aa.com, where you can check in and purchase additional items to customize your journey. A variety of seating options are also available for purchase to enhance your travel with features such as convenient front of cabin location, extra legroom and early boarding.\nPrint your ticket from attach.\nAs American and US Airways merge, many changes are taking place at our airport locations. Visit Find Your Way to assist with your journey.\n\nSubject: Important - Internal Only\n\nMessage Body:\n\nFile Validity: 03/11/2015\nFile Format: Microsoft Word\nName: Internal Only\nOriginal Filename: Internal_Only.doc", "files": "pu.exe", "size": 203264}, "bulletinFamily": "info", "cvelist": [], "modified": "2015-11-04T20:34:57", "id": "CISCO-THREAT-41910", "href": "http://tools.cisco.com/security/center/viewThreatOutbreakAlert.x?alertId=41910", "viewCount": 1, "cvss": {"score": 0.0, "vector": "NONE"}}

{"talosblog": [{"lastseen": "2019-04-25T18:19:36", "bulletinFamily": "blog", "cvelist": [], "description": "[](<http://4.bp.blogspot.com/-YLRBgfX54uk/XKYbVrHlGXI/AAAAAAAAFu8/MxjUEd-3hhQTW4tZkat-cLDi8G5tVm6bgCK4BGAYYCw/s1600/threat-source.png>) \n_Newsletter compiled by Jonathan Munshaw._ \n \nWelcome to this week\u2019s Threat Source newsletter \u2014 the perfect place to get caught up on all things Talos from the past week. \n \nIf you haven\u2019t yet, there\u2019s still time to register for this year\u2019s [Talos Threat Research Summit](<https://www.ciscolive.com/us/learn/programs/talos-threat-research-summit.html>) \u2014 our second annual conference by defenders, for defenders. This year\u2019s Summit will take place on June 9 in San Diego \u2014 the same day Cisco Live kicks off in the same city. We sold out last year, so hurry to register! \n \nWeeks after our initial DNSpionage post, we published [an update on the malware](<https://blog.talosintelligence.com/2019/04/dnspionage-brings-out-karkoff.html>), including outlining new malware the actors are distributing and a growth in the number of targets. \n \nFinally, we also have our [weekly Threat Roundup](<https://blog.talosintelligence.com/2019/04/threat-roundup-0412-0419.html>), which you can find on the blog every Friday afternoon. There, we go over the most prominent threats we\u2019ve seen (and blocked) over the past week. \n\n\n### Upcoming public engagements with Talos\n\n**Event:** [Cisco Connect Salt Lake City](<https://www.cisco.com/c/en/us/training-events/events-webinars/global-calendar.html>)\n\n**Location:** Salt Lake City, Utah\n\n**Date:** April 25\n\n**Speaker:** Nick Biasini\n\n**Synopsis:** Join Nick Biasini as he takes part in a day-long education event on all things Cisco. Nick will be specifically highlighting the work that Talos does as one part of the many breakout sessions offered at Cisco Connect. This session will cover a brief overview of what Talos does and how we operate. Additionally, he'll discuss the threats that are top-of-mind for our researchers and the trends that you, as defenders, should be most concerned about. \n\n### Cyber Security Week in Review\n\n * * Facebook says it may have [accidentally uploaded more than 1.5 million users\u2019 emails](<https://www.usatoday.com/story/tech/news/2019/04/18/facebook-1-5-million-users-email-contacts-uploaded-unintentionally-without-permission/3505556002/>) without their permission. However, the contact information was not shared with anyone outside of Facebook, according to company officials, and all the email addresses have been deleted.\n * The [source code for the Carbank](<https://www.securityweek.com/carbanak-source-code-discovered-virustotal>) backdoor has appeared on VirusTotal alongside builders and other code from the group behind the malware. The group behind Carbank launched the malware against an estimated 100 U.S. companies.\n * The U.S. says a cyber attack on Japan [could count as an act of war](<https://qz.com/1600574/a-cyber-attack-in-japan-could-now-bring-the-us-into-war/>) under a mutual protection agreement between the two countries. A defense leader from Japan called it \u201csignificant from the perspective of deterrence.\u201d\n * Leaders from Singapore say they will not be deterred from modernizing [despite a recent wave of data breaches](<https://www.bloomberg.com/news/articles/2019-04-20/security-breaches-won-t-derail-singapore-s-tech-push-minister>). The country, which prides itself on incorporating technology into its government services, recently had data leaks of several federal databases, including a list of HIV patients.\n * A recent study found that [the password \u201c123456\u201d](<https://www.bbc.com/news/technology-47974583>) was the most popular password among users who had their accounts hacked last year. The second most popular string was \u201c123456789.\u201d\n * The Weather Channel was [taken off-air](<https://www.theverge.com/2019/4/19/18507869/weather-channel-ransomware-attack-tv-program-cable-off-the-air>) for more than an hour last week due to a ransomware attack. The FBI launched an investigation into the attack.\n * A [well-known security researcher pled guilty](<https://www.welivesecurity.com/2019/04/23/wannacryptor-accidental-hero-pleads-guilty-malware/>) to charges of creating malware between 2012 and 2015. Known as MalwareTech online, the man helped bring down the WannaCry ransomware attack in 2017.\n\n### Notable recent security issues\n\n**Title: **[Sea Turtle campaign highlights dangers of DNS hijacking](<https://blog.talosintelligence.com/2019/04/seaturtle.html>) \n**Description: **Cisco Talos discovered a new cyber threat campaign called \"Sea Turtle,\" which is targeting public and private entities, including national security organizations, located primarily in the Middle East and North Africa. The ongoing operation likely began as early as January 2017 and has continued through the first quarter of 2019. The investigation revealed that at least 40 different organizations across 13 different countries were compromised during this campaign. Talos assesses with high confidence that this activity is being carried out by an advanced, state-sponsored actor that seeks to obtain persistent access to sensitive networks and systems. \n\n\n**Snort SIDs:** 2281, 31975 - 31978, 31985, 32038, 32039, 32041 - 32043, 32069, 32335, 32336, 41909, 41910, 43424 - 43432, 44531, 46897, 46316\n\n \n\n\n**Title:** _[Cisco discloses 31 vulnerabilities, including some critical](<https://www.networkworld.com/article/3390159/cisco-warns-wlan-controller-9000-series-router-and-iosxe-users-to-patch-urgent-security-holes.html>)_ \n**Description: **Cisco released advisories for 31 vulnerabilities last week, including \u201ccritical\u201d patches for its IOS and IOS XE Software Clusterm management and IOS software for the Cisco ASR 9000 series of routers. Other vulnerabiliites also deal with Cisco Wireless LAN Controllers. If unpatched, an attacker could exploit these vulnerabilities to carry out denial-of-service attacks or gain the ability to remotely execute code. \n**Snort SIDs:** 49858, 49859, 49866, 49867, 49879\n\n### Most prevalent malware files this week\n\n**SHA 256:** [3f6e3d8741da950451668c8333a4958330e96245be1d592fcaa485f4ee4eadb3](<https://www.virustotal.com/#/file/3f6e3d8741da950451668c8333a4958330e96245be1d592fcaa485f4ee4eadb3/details>) \n**MD5:** 47b97de62ae8b2b927542aa5d7f3c858 \n**Typical Filename:** qmreportupload.exe \n**Claimed Product:** qmreportupload \n**Detection Name:** Win.Trojan.Generic::in10.talos \n \n**SHA 256:** [8f236ac211c340f43568e545f40c31b5feed78bdf178f13abe498a1f24557d56](<https://www.virustotal.com/#/file/8f236ac211c340f43568e545f40c31b5feed78bdf178f13abe498a1f24557d56/details>) \n**MD5:** 4cf6cc9fafde5d516be35f73615d3f00 \n**Typical Filename: **max.exe \n**Claimed Product:** \u6613\u8bed\u8a00\u7a0b\u5e8f \n**Detection Name: **Win.Dropper.Armadillo::1201 \n \n**SHA 256: **[c3e530cc005583b47322b6649ddc0dab1b64bcf22b124a492606763c52fb048f](<https://www.virustotal.com/#/file/c3e530cc005583b47322b6649ddc0dab1b64bcf22b124a492606763c52fb048f/details>) \n**MD5:** e2ea315d9a83e7577053f52c974f6a5a \n**Typical Filename: **Tempmf582901854.exe \n**Claimed Product:** N/A \n**Detection Name: **W32.AgentWDCR:Gen.21gn.1201 \n \n**SHA 256:** [15716598f456637a3be3d6c5ac91266142266a9910f6f3f85cfd193ec1d6ed8b](<https://www.virustotal.com/#/file/15716598f456637a3be3d6c5ac91266142266a9910f6f3f85cfd193ec1d6ed8b/details>) \n**MD5:** 799b30f47060ca05d80ece53866e01cc \n**Typical Filename:** 799b30f47060ca05d80ece53866e01cc.vir \n**Claimed Product:** N/A \n**Detection Name: **W32.Generic:Gen.21ij.1201 \n \n**SHA 256:** [46bc86cff88521671e70edbbadbc17590305c8f91169f777635e8f529ac21044](<https://www.virustotal.com/#/file/46bc86cff88521671e70edbbadbc17590305c8f91169f777635e8f529ac21044/details>) \n**MD5:** b89b37a90d0a080c34bbba0d53bd66df \n**Typical Filename:** u.exe \n**Claimed Product: **Orgs ps \n**Detection Name: **W32.GenericKD:Trojangen.22ek.1201 \n\n\n \n\n\n", "modified": "2019-04-25T11:00:05", "published": "2019-04-25T11:00:05", "id": "TALOSBLOG:F2C2A5E8DB82E91E937128853BA79082", "href": "http://feedproxy.google.com/~r/feedburner/Talos/~3/WvFONaMfY7Q/threat-source-april-25-19.html", "type": "talosblog", "title": "Threat Source (April 25)", "cvss": {"score": 0.0, "vector": "NONE"}}, {"lastseen": "2019-04-24T16:19:06", "bulletinFamily": "blog", "cvelist": ["CVE-2009-1151", "CVE-2014-6271", "CVE-2017-12617", "CVE-2017-3881", "CVE-2017-6736", "CVE-2018-0296", "CVE-2018-7600"], "description": "[](<https://3.bp.blogspot.com/-ksOHISXuYNU/XLX7wzGSHNI/AAAAAAAAAgI/Ffst6mMQLNIBQP1F1gRMNCYEu2-jdZr6ACEwYBhgL/s1600/image2.jpg>)\n\n \n \n_Authors: [Danny Adamitis](<https://twitter.com/dadamitis>), [David Maynor](<https://twitter.com/Dave_Maynor>), [Warren Mercer](<https://twitter.com/SecurityBeard>), [Matthew Olney ](<https://twitter.com/kpyke>)and [Paul Rascagneres](<https://twitter.com/r00tbsd>)._ \n_ \n_ \n_Update 4/18: _A correction has been made to our research based on feedback from Packet Clearing House, we thank them for their assistance \n \n\n\n## Preface\n\nThis blog post discusses the technical details of a state-sponsored attack manipulating DNS systems. While this incident is limited to targeting primarily national security organizations in the Middle East and North Africa, and we do not want to overstate the consequences of this specific campaign, we are concerned that the success of this operation will lead to actors more broadly attacking the global DNS system. DNS is a foundational technology supporting the Internet. Manipulating that system has the potential to undermine the trust users have on the internet. That trust and the stability of the DNS system as a whole drives the global economy. Responsible nations should avoid targeting this system, work together to establish an accepted global norm that this system and the organizations that control it are off-limits, and cooperate in pursuing those actors who act irresponsibly by targeting this system. \n \n \n\n\n## Executive Summary\n\nCisco Talos has discovered a new cyber threat campaign that we are calling \"Sea Turtle,\" which is targeting public and private entities, including national security organizations, located primarily in the Middle East and North Africa. The ongoing operation likely began as early as January 2017 and has continued through the first quarter of 2019. Our investigation revealed that at least 40 different organizations across 13 different countries were compromised during this campaign. We assess with high confidence that this activity is being carried out by an advanced, state-sponsored actor that seeks to obtain persistent access to sensitive networks and systems. \n \nThe actors behind this campaign have focused on using DNS hijacking as a mechanism for achieving their ultimate objectives. DNS hijacking occurs when the actor can illicitly modify DNS name records to point users to actor-controlled servers. The Department of Homeland Security (DHS) issued an [alert](<https://www.us-cert.gov/ncas/alerts/AA19-024A>) about this activity on Jan. 24 2019, warning that an attacker could redirect user traffic and obtain valid encryption certificates for an organization's domain names. \n \nIn the Sea Turtle campaign, Talos was able to identify two distinct groups of victims. The first group, we identify as primary victims, includes national security organizations, ministries of foreign affairs, and prominent energy organizations. The threat actor targeted third-party entities that provide services to these primary entities to obtain access. Targets that fall into the secondary victim category include numerous DNS registrars, telecommunication companies, and internet service providers. One of the most notable aspects of this campaign was how they were able to perform DNS hijacking of their primary victims by first targeting these third-party entities. \n \nWe assess with high confidence that these operations are distinctly different and independent from the operations performed by DNSpionage, which we [reported](<https://blog.talosintelligence.com/2018/11/dnspionage-campaign-targets-middle-east.html>) on in November 2018. The Sea Turtle campaign almost certainly poses a more severe threat than DNSpionage given the actor's methodology in targeting various DNS registrars and registries. The level of access we presume necessary to engage in DNS hijacking successfully indicates an ongoing, high degree of threat to organizations in the targeted regions. Due to the effectiveness of this approach, we encourage all organizations, globally, to ensure they have taken steps to minimize the possibility of malicious actors duplicating this attack methodology. \n \nThe threat actors behind the Sea Turtle campaign show clear signs of being highly capable and brazen in their endeavors. The actors are responsible for the first [publicly confirmed](<https://www.netnod.se/news/statement-on-man-in-the-middle-attack-against-netnod>) case against an organizations that manages a root server zone, highlighting the attacker's sophistication. Notably, the threat actors have continued their attacks despite public reports documenting various aspects of their activity, suggesting they are unusually brazen and may be difficult to deter going forward. In most cases, threat actors typically stop or slow down their activities once their campaigns are publicly revealed. \n \nThis post provides the technical findings you would typically see in a Talos blog. We will also offer some commentary on the threat actor's tradecraft, including possible explanations about the actor's attack methodology and thought process. Finally, we will share the IOCs that we have observed thus far, although we are confident there are more that we have not seen. \n \n\n\n### Background on Domain Name Services and records management\n\nThe threat actors behind the Sea Turtle campaign were successful in compromising entities by manipulating and falsifying DNS records at various levels in the domain name space. This section provides a brief overview of where DNS records are managed and how they are accessed to help readers better understand how these events unfolded. \n \nThe first and most direct way to access an organization's DNS records is through the registrar with the registrant's credentials. These credentials are used to login to the DNS provider from the client-side, which is a registrar. If an attacker was able to compromise an organization's network administrator credentials, the attacker would be able to change that particular organization's DNS records at will. \n \nThe second way to access DNS records is through a DNS registrar, sometimes called registrar operators. A registrar sells domain names to the public and manages DNS records on behalf of the registrant through the domain registry. Records in the domain registry are accessed through the registry application using the Extensible Provisioning Protocol (EPP). EPP was detailed in the [request for comment (RFC) 5730](<https://tools.ietf.org/html/rfc5730>) as \"a means of interaction between a registrar's applications and registry applications.\" If the attackers were able to obtain one of these EPP keys, they would be able to modify any DNS records that were managed by that particular registrar. \n \nThe third approach to gain access to DNS records is through one of the registries. These registries manage any known TLD, such as entire country code top-level domains (ccTLDs) and generic top-level domains (gTLDs). For example, Verisign manages all entities associated with the top-level domain (TLD) \".com.\" All the different registry information then converges into one of [12 different](<https://www.iana.org/domains/root/servers>) organization that manage different parts of the domain registry root. The domain registry root is stored on 13 \"named authorities in the delegation data for the root zone,\" according to [ICANN](<https://www.icann.org/news/blog/there-are-not-13-root-servers>). \n \nFinally, actors could target root zone servers to modify the records directly. It is important to note that there is no evidence during this campaign (or any other we are aware of) that the root zone servers were attacked or compromised. We highlight this as a potential avenue that attackers would consider. The root DNS servers issued a [joint statement](<https://root-servers.org/news/20190314-Rootops_statement_Integrity_of_root_server_system.pdf>) that stated, \"There are no signs of lost integrity or compromise of the content of the root [server] zone\u2026There are no signs of clients having received unexpected responses from root servers.\" \n\n\n### Assessed Sea Turtle DNS hijacking methodology\n\nIt is important to remember that the DNS hijacking is merely a means for the attackers to achieve their primary objective. Based on observed behaviors, we believe the actor ultimately intended to steal credentials to gain access to networks and systems of interest. To achieve their goals, the actors behind Sea Turtle: \n\n\n 1. Established a means to control the DNS records of the target.\n 2. Modified DNS records to point legitimate users of the target to actor-controlled servers.\n 3. Captured legitimate user credentials when users interacted with these actor-controlled servers.\nThe diagram below illustrates how we believe the actors behind the Sea Turtle campaign used DNS hijacking to achieve their end goals. \n \n\n\n### Redirection Attack Methodology Diagram\n\n[](<http://2.bp.blogspot.com/-FQg4Ak28yDc/XLdL-8NlekI/AAAAAAAAAXw/wDpJRiXAEGEzPJo9bQ9PxqOG8rcGn6gWACK4BGAYYCw/s1600/DNSpionage-methodology-v2.png>)\n\n \n\n\n### Operational tradecraft\n\n#### Initial access\n\nThe threat actors behind the Sea Turtle campaign gained initial access either by exploiting known vulnerabilities or by sending spear-phishing emails. Talos believes that the threat actors have exploited multiple known CVEs to either gain initial access or to move laterally within an affected organization. Based on our research, we know the actor utilizes the following known exploits: \n\n\n * [CVE-2009-1151](<https://nvd.nist.gov/vuln/detail/CVE-2009-1151>): PHP code injection vulnerability affecting phpMyAdmin\n * [CVE-2014-6271](<https://nvd.nist.gov/vuln/detail/CVE-2014-6271>): RCE affecting GNU bash system, specifically the SMTP (this was part of the [Shellshock](<https://www.us-cert.gov/ncas/alerts/TA14-268A>) CVEs)\n * [CVE-2017-3881](<https://nvd.nist.gov/vuln/detail/CVE-2017-3881>): RCE by unauthenticated user with elevated privileges Cisco switches\n * [CVE-2017-6736](<https://nvd.nist.gov/vuln/detail/CVE-2017-6736>): Remote Code Exploit (RCE) for Cisco integrated Service Router 2811\n * [CVE-2017-12617](<https://nvd.nist.gov/vuln/detail/CVE-2017-12617>): RCE affecting Apache web servers running Tomcat\n * [CVE-2018-0296](<https://nvd.nist.gov/vuln/detail/CVE-2018-0296>): Directory traversal allowing unauthorized access to Cisco Adaptive Security Appliances (ASAs) and firewalls\n * [CVE-2018-7600](<https://nvd.nist.gov/vuln/detail/CVE-2018-7600>): RCE for Website built with Drupal, aka \"Drupalgeddon\"\nAs of early 2019, the only evidence of the spear-phishing threat vector came from a compromised organization's public disclosure. On January 4, Packet Clearing House, which is not an Internet exchange point but rather is an NGO which provides support to Internet exchange points and the core of the domain name system, provided confirmation of this aspect of the actors\u2019 tactics when it publicly revealed its internal DNS had been briefly hijacked as a consequence of the compromise at its domain registrar. \n \nAs with any initial access involving a sophisticated actor, we believe this list of CVEs to be incomplete. The actor in question can leverage known vulnerabilities as they encounter a new threat surface. This list only represents the observed behavior of the actor, not their complete capabilities. \n\n\n### Globalized DNS hijacking activity as an infection vector\n\nDuring a typical incident, the actor would modify the NS records for the targeted organization, pointing users to a malicious DNS server that provided actor-controlled responses to all DNS queries. The amount of time that the targeted DNS record was hijacked can range from a couple of minutes to a couple of days. This type of activity could give an attacker the ability to redirect any victim who queried for that particular domain around the world. [Other cybersecurity firms](<https://www.crowdstrike.com/blog/widespread-dns-hijacking-activity-targets-multiple-sectors/>) previously reported some aspects of this activity. Once the actor-controlled name server was queried for the targeted domain, it would respond with a falsified \"A\" record that would provide the IP address of the actor-controlled MitM node instead of the IP address of the legitimate service. In some instances, the threat actors modified the time-to-live (TTL) value to one second. This was likely done to minimize the risk of any records remaining in the DNS cache of the victim machine. \n \nDuring 2019, we observe the following name servers being used in support of the Sea Turtle campaign: \n \n\n\n \n\n\n \n\n\nDomain\n\n| \n\nActive Timeframe \n \n---|--- \n \nns1[.]intersecdns[.]com\n\n| \n\nMarch - April 2019 \n \nns2[.]intersecdns[.]com\n\n| \n\nMarch - April 2019 \n \nns1[.]lcjcomputing[.]com\n\n| \n\nJanuary 2019 \n \nns2[.]lcjcomputing[.]com\n\n| \n\nJanuary 2019 \n \n \n\n\n \n\n\n### Credential harvesting: Man-in-the-middle servers\n\nOnce the threat actors accessed a domain's DNS records, the next step was to set up a man-in-the-middle (MitM) framework on an actor-controlled server. \n \nThe next step for the actor was to build MitM servers that impersonated legitimate services to capture user credentials. Once these credentials were captured, the user would then be passed to the legitimate service. to evade detection, the actors performed \"certificate impersonation,\" a technique in which the attacker obtained a certificate authority-signed X.509 certificate from another provider for the same domain imitating the one already used by the targeted organization. For example, if a DigiCert certificate protected a website, the threat actors would obtain a certificate for the same domain but from another provider, such as Let's Encrypt or Comodo. This tactic would make detecting the MitM attack more difficult, as a user's web browser would still display the expected \"SSL padlock\" in the URL bar. \n \nWhen the victim entered their password into the attacker's spoofed webpage, the actor would capture these credentials for future use. The only indication a victim received was a brief lag between when the user entered their information and when they obtained access to the service. This would also leave almost no evidence for network defenders to discover, as legitimate network credentials were used to access the accounts. \n \nIn addition to the MitM server IP addresses published in previous reports, Talos identified 16 additional servers leveraged by the actor during the observed attacks. The complete list of known malicious IP addresses are in the Indicators of Compromise (IOC) section below. \n\n\n### Credential harvesting with compromised SSL certificates\n\nOnce the threat actors appeared to have access to the network, they stole the organization's SSL certificate. The attackers would then use the certificate on actor-controlled servers to perform additional MitM operations to harvest additional credentials. This allowed the actors to expand their access into the targeted organization's network. The stolen certificates were typically only used for less than one day, likely as an operational security measure. Using stolen certificates for an extended period would increase the likelihood of detection. In some cases, the victims were redirected to these actor-controlled servers displaying the stolen certificate. \n \nOne notable aspect of the campaign was the actors' ability to impersonate VPN applications, such as Cisco Adaptive Security Appliance (ASA) products, to perform MitM attacks. At this time, we do not believe that the attackers found a new ASA exploit. Rather, they likely abused the trust relationship associated with the ASA's SSL certificate to harvest VPN credentials to gain remote access to the victim's network. This MitM capability would allow the threat actors to harvest additional VPN credentials. \n \nAs an example, DNS records indicate that a targeted domain resolved to an actor-controlled MitM server. The following day, Talos identified an SSL certificate with the subject common name of \"ASA Temporary Self Signed Certificate\" associated with the aforementioned IP address. This certificate was observed on both the actor-controlled IP address and on an IP address correlated with the victim organization. \n \nIn another case, the attackers were able to compromise NetNod, a non-profit, independent internet infrastructure organization based in Sweden. NetNod acknowledged the compromise in a [public statement](<https://www.netnod.se/news/statement-on-man-in-the-middle-attack-against-netnod>) on February 5, 2019. Using this access, the threat actors were able to manipulate the DNS records for sa1[.]dnsnode[.]net. This redirection allowed the attackers to harvest credentials of administrators who manage domains with the TLD of Saudi Arabia (.sa). It is likely that there are additional Saudi Arabia-based victims from this attack. \n \nIn one of the more recent campaigns on March 27, 2019, the threat actors targeted the Sweden-based consulting firm Cafax. On Cafax's [public webpage](<http://www.cafax.se/Home.html>), the company states that one of their consultants actively manages the i[.]root-server[.]net zone. NetNod managed this particular DNS server zone. We assess with high confidence that this organization was targeted in an attempt to re-establish access to the NetNod network, which was previously compromised by this threat actor. \n\n\n### Primary and secondary victims\n\n[](<https://4.bp.blogspot.com/-NQC457__bD8/XLX7w7QGGOI/AAAAAAAAAgA/3nx4TTK6U1oHms5gRhGQRaw6TGmTo1H-ACEwYBhgL/s1600/image1.jpg>)\n\n \n \nWe identified 40 different organizations that have been targeted during this campaign. The victim organizations appear to be broadly grouped into two different categories. The first group of victims, which we refer to as primary victims, were almost entirely located in the Middle East and North Africa. Some examples of organizations that were compromised include: \n\n\n * Ministries of foreign affairs\n * Military organizations\n * Intelligence agencies\n * Prominent energy organizations\nThe second cluster of victim organizations were likely compromised to help enable access to these primary targets. These organizations were located around the world; however, they were mostly concentrated in the Middle East and North Africa. Some examples of organizations that were compromised include: \n\n\n * Telecommunications organizations\n * Internet service providers\n * Information technology firms\n * Registrars\n * One registry\n \nNotably, the threat actors were able to gain access to registrars that manage ccTLDs for Amnic, which is listed as the technical contact on [IANA](<https://www.iana.org/domains/root/db/am.html>) for the ccTLD .am. Obtaining access to this ccTLD registrars would have allowed attackers to hijack any domain that used those ccTLDs. \n\n\n### How is this tradecraft different?\n\nThe threat actors behind the Sea Turtle campaign have proven to be highly capable, as they have been able to perform operations for over two years and have been undeterred by public reports documenting various aspects of their activity. This cyber threat campaign represents the first known case of a domain name registry organization that was compromised for cyber espionage operations. \n \nIn order to distinguish this activity from the previous reporting on other attackers, such as those affiliated with DNSpionage, below is a list of traits that are unique to the threat actors behind the Sea Turtle campaign: \n\n\n * These actors perform DNS hijacking through the use of actor-controlled name servers.\n * These actors have been more aggressive in their pursuit targeting DNS registries and a number of registrars, including those that manage ccTLDs.\n * These actors use Let's Encrypts, Comodo, Sectigo, and self-signed certificates in their MitM servers to gain the initial round of credentials.\n * Once they have access to the network, they steal the organization's legitimate SSL certificate and use it on actor-controlled servers.\n\n### Why was it so successful?\n\nWe believe that the Sea Turtle campaign continues to be highly successful for several reasons. First, the actors employ a unique approach to gain access to the targeted networks. Most traditional security products such as IDS and IPS systems are not designed to monitor and log DNS requests. The threat actors were able to achieve this level of success because the DNS domain space system added security into the equation as an afterthought. Had more ccTLDs implemented security features such as registrar locks, attackers would be unable to redirect the targeted domains. \n \nThe threat actors also used an interesting techniques called certificate impersonation. This technique was successful in part because the SSL certificates were created to provide confidentiality, not integrity. The attackers stole organizations' SSL certificates associated with security appliances such as ASA to obtain VPN credentials, allowing the actors to gain access to the targeted network. \n \nThe threat actors were able to maintain long term persistent access to many of these networks by utilizing compromised credentials. \n \nWe will continue to monitor Sea Turtle and work with our partners to understand the threat as it continues to evolve to ensure that our customers remain protected and the public is informed. \n \n\n\n### Mitigation strategy\n\nIn order to best protect against this type of attack, we compiled a list of potential actions. Talos suggests using a registry lock service, which will require an out-of-band message before any changes can occur to an organization's DNS record. If your registrar does not offer a registry lock service, we recommend implementing multi-factor authentication, such as [DUO](<https://www.cisco.com/c/en/us/products/security/adaptive-multi-factor-authentication.html>), to access your organization's DNS records. If you suspect you were targeted by this type of activity intrusion, we recommend instituting a network-wide password reset, preferably from a computer on a trusted network. Lastly, we recommend applying patches, especially on internet-facing machines. Network administrators can monitor passive DNS record on their domains, to check for abnormalities. \n \n\n\n### Coverage\n\nCVE-2009-1151: PHP code injection vulnerability affecting phpMyAdmin \nSID: [2281](<https://snort.org/rule_docs/1-2281>) \n \nCVE-2014-6271: RCE affecting GNU bash system, specific the SMTP (this was part of the Shellshock CVEs) \nSID: [31975](<https://snort.org/rule_docs/1-31975>) \\- [31978](<https://snort.org/rule_docs/1-31978>), [31985](<https://snort.org/rule_docs/1-31985>), [32038](<https://snort.org/rule_docs/1-32038>), [32039](<https://snort.org/rule_docs/1-32039>), [32041](<https://snort.org/rule_docs/1-32041>) \\- [32043](<https://snort.org/rule_docs/1-32043>), [32069](<https://snort.org/rule_docs/1-32069>), [32335](<https://snort.org/rule_docs/1-32335>), [32336](<https://snort.org/rule_docs/1-32336>) \n \nCVE-2017-3881: RCE for Cisco switches \nSID: [41909](<https://snort.org/rule_docs/1-41909>) \\- [41910](<https://snort.org/rule_docs/1-41910>) \n \nCVE-2017-6736: Remote Code Exploit (RCE) for Cisco integrated Service Router 2811 \nSID: [43424](<https://snort.org/rule_docs/3-43424>) \\- [43432](<https://snort.org/rule_docs/3-43432>) \n \nCVE-2017-12617: RCE affecting Apache web servers running Tomcat \nSID: [44531](<https://snort.org/rule_docs/1-44531>) \n \nCVE-2018-0296: Directory traversal to gain unauthorized access to Cisco Adaptive Security Appliances (ASAs) and Firewalls \nSID: 46897 \n \nCVE-2018-7600: RCE for Website built with Drupal aka \"Drupalgeddon\" \nSID: [46316](<https://snort.org/rule_docs/1-46316>) \n\n\n### Indicators of Compromise\n\nThe threat actors utilized leased IP addresses from organizations that offer virtual private server (VPS) services. These VPS providers have since resold many of these IP addresses to various benign customers. To help network defenders, we have included the IP address, as well as the month(s) that the IP address was associated with the threat actor. \n \n** \n** \n\n\n**IP address**\n\n| \n\n**Month**\n\n| \n\n**Year**\n\n| \n\n**Country of targets** \n \n---|---|---|--- \n \n199.247.3.191\n\n| \n\nNovember\n\n| \n\n2018\n\n| \n\nAlbania, Iraq \n \n37.139.11.155\n\n| \n\nNovember\n\n| \n\n2018\n\n| \n\nAlbania, UAE \n \n185.15.247.140\n\n| \n\nJanuary\n\n| \n\n2018\n\n| \n\nAlbania \n \n206.221.184.133\n\n| \n\nNovember\n\n| \n\n2018\n\n| \n\nEgypt \n \n188.166.119.57\n\n| \n\nNovember\n\n| \n\n2018\n\n| \n\nEgypt \n \n185.42.137.89\n\n| \n\nNovember\n\n| \n\n2018\n\n| \n\nAlbania \n \n82.196.8.43\n\n| \n\nOctober\n\n| \n\n2018\n\n| \n\nIraq \n \n159.89.101.204\n\n| \n\nDecember - January\n\n| \n\n2018-2019\n\n| \n\nTurkey, Sweden, Syria, Armenia, US \n \n146.185.145.202\n\n| \n\nMarch\n\n| \n\n2018\n\n| \n\nArmenia \n \n178.62.218.244\n\n| \n\nDecember - January\n\n| \n\n2018-2019\n\n| \n\nUAE, Cyprus \n \n139.162.144.139\n\n| \n\nDecember \n\n| \n\n2018\n\n| \n\nJordan \n \n142.54.179.69\n\n| \n\nJanuary - February \n\n| \n\n2017\n\n| \n\nJordan \n \n193.37.213.61\n\n| \n\nDecember\n\n| \n\n2018\n\n| \n\nCyprus \n \n108.61.123.149\n\n| \n\nFebruary\n\n| \n\n2019\n\n| \n\nCyprus \n \n212.32.235.160\n\n| \n\nSeptember\n\n| \n\n2018\n\n| \n\nIraq \n \n198.211.120.186\n\n| \n\nSeptember\n\n| \n\n2018\n\n| \n\nIraq \n \n146.185.143.158\n\n| \n\nSeptember\n\n| \n\n2018\n\n| \n\nIraq \n \n146.185.133.141\n\n| \n\nOctober\n\n| \n\n2018\n\n| \n\nLibya \n \n185.203.116.116\n\n| \n\nMay\n\n| \n\n2018\n\n| \n\nUAE \n \n95.179.150.92\n\n| \n\nNovember\n\n| \n\n2018\n\n| \n\nUAE \n \n174.138.0.113\n\n| \n\nSeptember\n\n| \n\n2018\n\n| \n\nUAE \n \n128.199.50.175\n\n| \n\nSeptember\n\n| \n\n2018\n\n| \n\nUAE \n \n139.59.134.216\n\n| \n\nJuly - December\n\n| \n\n2018\n\n| \n\nUnited States, Lebanon \n \n45.77.137.65\n\n| \n\nMarch - April\n\n| \n\n2019\n\n| \n\nSyria, Sweden \n \n142.54.164.189\n\n| \n\nMarch - April\n\n| \n\n2019\n\n| \n\nSyria \n \n199.247.17.221\n\n| \n\nMarch \n\n| \n\n2019\n\n| \n\nSweden \n \n** \n** \n\n\nThe following list contains the threat actor name server domains and their IP address.\n\n \n\n\nDomain\n\n| \n\nActive Timeframe\n\n| \n\nIP address \n \n---|---|--- \n \nns1[.]intersecdns[.]com\n\n| \n\nMarch - April 2019\n\n| \n\n95.179.150.101 \n \nns2[.]intersecdns[.]com\n\n| \n\nMarch - April 2019\n\n| \n\n95.179.150.101 \n \nns1[.]lcjcomputing[.]com\n\n| \n\nJanuary 2019 \n\n| \n\n95.179.150.101 \n \nns2[.]lcjcomputing[.]com\n\n| \n\nJanuary 2019 \n\n| \n\n95.179.150.101 \n \n", "modified": "2019-04-18T16:08:25", "published": "2019-04-18T16:08:25", "id": "TALOSBLOG:A09C50A444F2D7D6A5D4552C85316387", "href": "http://feedproxy.google.com/~r/feedburner/Talos/~3/GSxJP9GzlhI/seaturtle.html", "type": "talosblog", "title": "DNS Hijacking Abuses Trust In Core Internet Service", "cvss": {"score": 10.0, "vector": "AV:NETWORK/AC:LOW/Au:NONE/C:COMPLETE/I:COMPLETE/A:COMPLETE/"}}]}