{
	"id": "2855e6f4-09f6-45ed-adbe-1c7b59b5876b",
	"created_at": "2026-04-06T00:21:05.494844Z",
	"updated_at": "2026-04-10T03:21:49.581842Z",
	"deleted_at": null,
	"sha1_hash": "320a7e4a9ea4342714019222c85f4d034bf46e79",
	"title": "Global DNS Hijacking Campaign: DNS Record Manipulation at Scale | Mandiant",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 557059,
	"plain_text": "Global DNS Hijacking Campaign: DNS Record Manipulation at\r\nScale | Mandiant\r\nBy Mandiant\r\nPublished: 2019-01-09 · Archived: 2026-04-02 11:09:52 UTC\r\nWritten by: Muks Hirani, Sarah Jones, Ben Read\r\nIntroduction\r\nFireEye’s Mandiant Incident Response and Intelligence teams have identified a wave of DNS hijacking that has\r\naffected dozens of domains belonging to government, telecommunications and internet infrastructure entities\r\nacross the Middle East and North Africa, Europe and North America. While we do not currently link this activity\r\nto any tracked group, initial research suggests the actor or actors responsible have a nexus to Iran. This campaign\r\nhas targeted victims across the globe on an almost unprecedented scale, with a high degree of success. We have\r\nbeen tracking this activity for several months, mapping and understanding the innovative tactics, techniques and\r\nprocedures (TTPs) deployed by the attacker. We have also worked closely with victims, security organizations,\r\nand law enforcement agencies where possible to reduce the impact of the attacks and/or prevent further\r\ncompromises.\r\nWhile this campaign employs some traditional tactics, it is differentiated from other Iranian activity we have seen\r\nby leveraging DNS hijacking at scale. The attacker uses this technique for their initial foothold, which can then be\r\nexploited in a variety of ways. In this blog post, we detail the three different ways we have seen DNS records be\r\nmanipulated to enable victim compromises. Technique 1, involving the creation of a Let's Encrypt certificate and\r\nchanging the A record, was previously documented by Cisco’s TALOS team. The activity described in their blog\r\npost is a subset of the activity we have observed.\r\nInitial Research Suggests Iranian Sponsorship\r\nAttribution analysis for this activity is ongoing. While the DNS record manipulations described in this post are\r\nnoteworthy and sophisticated, they may not be exclusive to a single threat actor as the activity spans disparate\r\ntimeframes, infrastructure, and service providers.\r\nMultiple clusters of this activity have been active from January 2017 to January 2019.\r\nThere are multiple, nonoverlapping clusters of actor-controlled domains and IPs used in this activity.\r\nA wide range of providers were chosen for encryption certificates and VPS hosts.\r\nPreliminary technical evidence allows us to assess with moderate confidence that this activity is conducted by\r\npersons based in Iran and that the activity aligns with Iranian government interests.\r\nhttps://www.fireeye.com/blog/threat-research/2019/01/global-dns-hijacking-campaign-dns-record-manipulation-at-scale.html\r\nPage 1 of 5\n\nFireEye Intelligence identified access from Iranian IPs to machines used to intercept, record and forward\r\nnetwork traffic. While geolocation of an IP address is a weak indicator, these IP addresses were previously\r\nobserved during the response to an intrusion attributed to Iranian cyber espionage actors.\r\nThe entities targeted by this group include Middle Eastern governments whose confidential information\r\nwould be of interest to the Iranian government and have relatively little financial value.\r\nDetails\r\nThe following examples use victim[.]com to stand in for the victim domain, and private IP addresses to stand in\r\nfor the actor controlled IP addresses.\r\nTechnique 1 – DNS A Records\r\nThe first method exploited by the attacker is altering DNS A Records, as seen in Figure 1.\r\n1. The attacker logs into PXY1, a Proxy box used to conduct non-attributed browsing and as a jumpbox to\r\nother infrastructure.\r\n2. The attacker logs into the DNS provider’s administration panel, utilising previously compromised\r\ncredentials.\r\n3. The A record (e.g. mail[.]victim[.]com) is currently pointing to 192.168.100.100.\r\n4. The attacker changes the A record and points it to 10.20.30.40 (OP1).\r\n5. The attacker logs in from PXY1 to OP1.\r\nA proxy is implemented to listen on all open ports, mirroring mail[.]victim[.]com.\r\nA load balancer points to 192.168.100.100 [mail[.]victim[.]com] to pass through user traffic.\r\n6. certbot is used to create a Let’s Encrypt certificate for mail[.]victim[.]com\r\nWe have observed multiple Domain Control Validation providers being utilised as part of this\r\ncampaign.\r\n7. A user now visits mail[.]victim[.]com and is directed to OP1. The Let’s Encrypt certificate allows the\r\nbrowsers to establish a connection without any certificate errors as Let's Encrypt Authority X3 is trusted.\r\nhttps://www.fireeye.com/blog/threat-research/2019/01/global-dns-hijacking-campaign-dns-record-manipulation-at-scale.html\r\nPage 2 of 5\n\nThe connection is forwarded to the load balancer which establishes the connection with the real\r\nmail[.]victim[.]com. The user is not aware of any changes and may only notice a slight delay.\r\n8. The username, password and domain credentials are harvested and stored.\r\nTechnique 2 – DNS NS Records\r\nThe second method exploited by the attacker involved altering DNS NS Records, as seen in Figure 2.\r\n1. The attacker again logs into PXY1.\r\n2. This time, however, the attacker exploits a previously compromised registrar or ccTLD.\r\n3. The nameserver record ns1[.]victim[.]com is currently set to 192.168.100.200. The attacker changes the NS\r\nrecord and points it to ns1[.]baddomain[.]com [10.1.2.3]. That nameserver will respond with the IP\r\n10.20.30.40 (OP1) when mail[.]victim[.]com is requested, but with the original IP 192.168.100.100 if it is\r\nwww[.]victim[.]com.\r\n4. The attacker logs in from PXY1 to OP1.\r\nA proxy is implemented to listen on all open ports, mirroring mail[.]victim[.]com.\r\nA load balancer points to 192.168.100.100 [mail[.]victim[.]com] to pass through user traffic.\r\n5. certbot is used to create a Let’s Encrypt certificate for mail[.]victim[.]com.\r\nWe have observed multiple Domain Control Validation providers being utilised during this\r\ncampaign.\r\n6. A user visits mail[.]victim[.]com and is directed to OP1. The Let’s Encrypt certificate allows browsers to\r\nestablish a connection without any certificate errors as Let's Encrypt Authority X3 is trusted. The\r\nconnection is forwarded to the load balancer which establishes the connection with the real\r\nmail[.]victim[.]com. The user is not aware of any changes and may only notice a slight delay.\r\n7. The username, password and domain credentials are harvested and stored.\r\nTechnique 3 – DNS Redirector\r\nhttps://www.fireeye.com/blog/threat-research/2019/01/global-dns-hijacking-campaign-dns-record-manipulation-at-scale.html\r\nPage 3 of 5\n\nThe attacker has also been observed using a third technique in conjunction with either Figure 1 or Figure 2 above.\r\nThis involves a DNS Redirector, as seen in Figure 3.\r\nFigure 3: DNS Operational box\r\nThe DNS Redirector is an attacker operations box which responds to DNS requests.\r\n1. A DNS request for mail[.]victim[.]com is sent to OP2 (based on previously altered A Record or NS\r\nRecord).\r\n2. If the domain is part of victim[.]com zone, OP2 responds with an attacker-controlled IP address, and the\r\nuser is re-directed to the attacker-controlled infrastructure.\r\n3. If the domain is not part of the victim.com zone (e.g. google[.]com), OP2 makes a DNS request to a\r\nlegitimate DNS to get the IP address and the legitimate IP address is returned to the user.\r\nTargets\r\nA large number of organizations have been affected by this pattern of DNS record manipulation and fraudulent\r\nSSL certificates. They include telecoms and ISP providers, internet infrastructure providers, government and\r\nsensitive commercial entities.\r\nRoot Cause Still Under Investigation\r\nIt is difficult to identify a single intrusion vector for each record change, and it is possible that the actor, or actors\r\nare using multiple techniques to gain an initial foothold into each of the targets described above. FireEye\r\nintelligence customers have received previous reports describing sophisticated phishing attacks used by one actor\r\nthat also conducts DNS record manipulation. Additionally, while the precise mechanism by which the DNS\r\nrecords were changed is unknown, we believe that at least some records were changed by compromising a\r\nvictim’s domain registrar account.\r\nPrevention Tactics\r\nThis type of attack is difficult to defend against, because valuable information can be stolen, even if an attacker is\r\nnever able to get direct access to your organization’s network. Some steps to harden your organization include:\r\n1. Implement multi-factor authentication on your domain’s administration portal.\r\n2. Validate A and NS record changes.\r\nhttps://www.fireeye.com/blog/threat-research/2019/01/global-dns-hijacking-campaign-dns-record-manipulation-at-scale.html\r\nPage 4 of 5\n\n3. Search for SSL certificates related to your domain and revoke any malicious certificates.\r\n4. Validate the source IPs in OWA/Exchange logs.\r\n5. Conduct an internal investigation to assess if attackers gained access to your environment.\r\nConclusion\r\nThis DNS hijacking, and the scale at which it has been exploited, showcases the continuing evolution in tactics\r\nfrom Iran-based actors. This is an overview of one set of TTPs that we recently observed affecting multiple\r\nentities. We are highlighting it now so that potential targets can take appropriate defensive action.\r\nPosted in\r\nThreat Intelligence\r\nSecurity \u0026 Identity\r\nSource: https://www.fireeye.com/blog/threat-research/2019/01/global-dns-hijacking-campaign-dns-record-manipulation-at-scale.html\r\nhttps://www.fireeye.com/blog/threat-research/2019/01/global-dns-hijacking-campaign-dns-record-manipulation-at-scale.html\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE",
		"Malpedia",
		"MISPGALAXY",
		"ETDA"
	],
	"references": [
		"https://www.fireeye.com/blog/threat-research/2019/01/global-dns-hijacking-campaign-dns-record-manipulation-at-scale.html"
	],
	"report_names": [
		"global-dns-hijacking-campaign-dns-record-manipulation-at-scale.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434865,
	"ts_updated_at": 1775791309,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/320a7e4a9ea4342714019222c85f4d034bf46e79.pdf",
		"text": "https://archive.orkl.eu/320a7e4a9ea4342714019222c85f4d034bf46e79.txt",
		"img": "https://archive.orkl.eu/320a7e4a9ea4342714019222c85f4d034bf46e79.jpg"
	}
}