{
	"id": "946102ae-635d-4ade-8f23-5dee232271d4",
	"created_at": "2026-04-06T00:07:23.150199Z",
	"updated_at": "2026-04-10T03:35:48.489234Z",
	"deleted_at": null,
	"sha1_hash": "fe38ca9e8664e774e9783b3db2315f1a94afa094",
	"title": "What Talos Incident Response learned from a recent Qakbot attack hijacking old email threads",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 610081,
	"plain_text": "What Talos Incident Response learned from a recent Qakbot\r\nattack hijacking old email threads\r\nBy Jonathan Munshaw\r\nPublished: 2022-07-27 · Archived: 2026-04-05 23:22:59 UTC\r\nWhat Talos Incident Response learned from a recent Qakbot attack hijacking old\r\nemail threads\r\nWednesday, July 27, 2022 08:00\r\nBy Nate Pors and Terryn Valikodath.\r\nExecutive summary\r\nIn a recent malspam campaign delivering the Qakbot banking trojan, Cisco Talos Incident Response\r\n(CTIR) observed the adversary using aggregated, old email threads from multiple organizations that we\r\nassess were likely harvested during the 2021 ProxyLogon-related compromises targeting vulnerable\r\nMicrosoft Exchange servers.\r\nThis campaign relies on external thread hijacking, whereby the adversary is likely using a bulk aggregation\r\nof multiple organizations’ harvested emails to launch focused phishing campaigns against previously\r\nuncompromised organizations. This differs from the more common approach to thread hijacking, in which\r\nattackers use a single compromised organization’s emails to deliver their threat.\r\nThis many-to-one approach is unique from what we have generally observed in the past and is likely an\r\nindirect effect of the widespread compromises and exfiltration of large volumes of email from 2020 and\r\n2021.\r\nhttps://blog.talosintelligence.com/2022/07/what-talos-incident-response-learned.html\r\nPage 1 of 5\n\nUnderstanding the difference between external and single-victim thread hijacking is essential for detecting\r\nthese threats. Below, we have several tips for defenders on how to identify key indicators of this activity.\r\nExternal thread hijacking\r\nCisco Talos has observed threat actors using external thread hijacking, a method by which attackers weaponize\r\nemails previously harvested from other organizations. This differs from the more common approach to thread\r\nhijacking, in which adversaries compromise the victim organization’s Exchange server to obtain email threads that\r\nare then weaponized. We recently observed this in June 2022 as part of a broader campaign that delivered the\r\nQakbot banking trojan. In this threat activity, the attackers used old emails harvested months to years ago during\r\nthe 2021 ProxyLogon campaign, tracked as CVE-2021-26855, targeting vulnerable Exchange servers.\r\nExternal thread hijacking is not dependent on the threat actor gaining initial access to the victim environment. This\r\nis notable from a digital forensics and incident response (DFIR) perspective because the target organization only\r\nsaw inbound phishing emails with its own legitimate emails as the source material, with multiple external\r\norganizations represented in the email threads. Our assessment of the adversary’s use of emails obtained from the\r\nProxyLogon compromises is based on a number of observations, including the timing of the emails and research\r\ninto publicly acknowledged ProxyLogon compromises. The attackers selectively used these emails to target\r\nsenders or recipients from the target organization.\r\nIn the external thread hijacking attack observed by CTIR, the adversary likely took the following steps:\r\n1. The attacker took control of multiple third-party organizations’ Exchange servers or individual inboxes and\r\nexported emails for later use. The adversary selected the emails relevant to the target organization from the\r\nemail dumps. This could have been accomplished with a regex search for “[@]company[.]com” in the “To”\r\nor “From” fields, although we did not directly observe the adversary’s selection process.\r\n2. With the emails selected, the adversary ran a script to format the text of each legitimate thread into a\r\nphishing email by adding malicious content.\r\n3. The attacker then sent the phishing emails to the original “[@]company[.]com” address in each legitimate\r\nthread from many adversary-controlled external mailboxes, completing the phishing attack.\r\nSee the graphic below for a visual depiction of those steps. Note that the graphic shows only one third-party\r\norganization for simplicity, but emails harvested from multiple external organizations were involved in the attack\r\nobserved by Cisco Talos.\r\nhttps://blog.talosintelligence.com/2022/07/what-talos-incident-response-learned.html\r\nPage 2 of 5\n\nVictim thread hijacking\r\nTo help showcase the unusual nature of the external thread hijacking, a brief breakdown of the more common\r\nvictim thread hijacking is instructive. In 2021 and early 2022, adversary methods for thread-hijacking primarily\r\ndepended on access to a victim’s Exchange server or individual email account. Most recently, this was seen in an\r\nIcedID campaign in early 2022 where the adversary compromised a victim’s Exchange server and used it as a base\r\nof operations to craft and send malicious emails based on recent legitimate email threads.\r\nIn the past, in a standard malspam campaign delivering IcedID, an attacker would have taken control of the target\r\norganization’s Exchange server, then hijacked threads between internal users and/or their external partners. The\r\nkey point is that the victim’s Exchange server served as both the source for the legitimate email thread and the\r\nsender for the malicious reply. These attacks were usually conducted immediately post-compromise, or shortly\r\nafter.\r\nIn a victim thread hijacking attack, the adversary would take the following steps:\r\n1. Take control of the target organization’s Exchange server via ProxyLogon or another Exchange\r\nvulnerability.\r\n2. The adversary would then use a legitimate email to craft a reply, inserting malicious content. Next, the\r\nadversary would send a malicious reply to the target user via the target organization’s Exchange server.\r\nThis step of the attack would work equally well for internal-to-internal and internal-to-external phishing.\r\n3. The target user, seeing the legitimate sender, source and thread history of the email, would be reasonably\r\nlikely to click the link, thereby executing the IcedID payload on the system.\r\nhttps://blog.talosintelligence.com/2022/07/what-talos-incident-response-learned.html\r\nPage 3 of 5\n\nRegarding the malware delivered in this campaign, there are numerous Snort rules and ClamAV signatures users\r\ncan deploy to detect the deployment of Qakbot. While the primary focus of this post covers the process of how an\r\nattacker delivered this attack, if a user were to be infected with this particular campaign, Qakbot can steal financial\r\ndata and login information from targeted systems. It also loads additional malware from its C2 servers, which\r\nSnort rules can detect and prevent.\r\nWith a clear understanding of the difference between external thread hijacking versus victim thread hijacking, the\r\nnext question is how to detect external thread hijacking, particularly in the current campaign using emails\r\nharvested through ProxyLogon attacks. This is a very relevant topic for DFIR professionals because accurate\r\nidentification of this attack method might lower the priority of in-depth forensic examination of internal Exchange\r\nservers.\r\nTips for Defenders\r\nLook for the following indicators as key signs of the external thread hijacking method:\r\nSpoofed senders. Since the adversary did not have access to the victim’s Exchange server, all emails\r\noriginate from spoofed, external addresses.\r\nOld email threads, primarily from 2020 and 2021. However, Cisco Talos has observed at least one email\r\nthread as recent as May 2022, indicating that the adversary in question is actively using newly harvested\r\nemails.\r\nNo or very limited internal-to-internal threads. Since the emails were harvested from external sources,\r\nthere should be very few internal-to-internal threads seen in the legitimate content.\r\nMalformed replies. The adversary concatenated the old, legitimate content with the new, malicious\r\ncontent within the email body. This created a malformed appearance, as seen in the example below.\r\nhttps://blog.talosintelligence.com/2022/07/what-talos-incident-response-learned.html\r\nPage 4 of 5\n\nPartially scrubbed email addresses. The adversary’s script removed some email addresses from the\r\nbodies of the legitimate emails during the construction of the malicious emails, as noted in the example\r\nbelow.\r\nRepetitive use of the same harvested legitimate email threads in multiple phishing waves. The example\r\nbelow was created by Cisco Talos to avoid displaying identifying information but is highly similar in all\r\naspects to the external thread hijacking emails observed in the wild.\r\nConclusion\r\nBy early 2022, the direct effects of ProxyLogon, most famously exploited by the HAFNIUM group, largely\r\nquieted down. The external approach to thread hijacking, not necessarily specific to one adversary, appears to be\r\none of the many indirect effects of the widespread compromises that resulted in exfiltration of large volumes of\r\nemail from 2020 and 2021. Although those emails are relatively old by now, we will likely continue to observe\r\nadversaries leveraging bulk email aggregations from multiple organizations to launch focused phishing\r\ncampaigns. Accurately recognizing the difference between external thread hijacking and victim thread hijacking\r\ncan potentially avoid incorrect assessment of an incident and save dozens of hours of hunting for an internal\r\nbreach that does not exist.\r\nSource: https://blog.talosintelligence.com/2022/07/what-talos-incident-response-learned.html\r\nhttps://blog.talosintelligence.com/2022/07/what-talos-incident-response-learned.html\r\nPage 5 of 5",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"ETDA"
	],
	"references": [
		"https://blog.talosintelligence.com/2022/07/what-talos-incident-response-learned.html"
	],
	"report_names": [
		"what-talos-incident-response-learned.html"
	],
	"threat_actors": [
		{
			"id": "7c969685-459b-4c93-a788-74108eab6f47",
			"created_at": "2023-01-06T13:46:39.189751Z",
			"updated_at": "2026-04-10T02:00:03.241102Z",
			"deleted_at": null,
			"main_name": "HAFNIUM",
			"aliases": [
				"Red Dev 13",
				"Silk Typhoon",
				"MURKY PANDA",
				"ATK233",
				"G0125",
				"Operation Exchange Marauder"
			],
			"source_name": "MISPGALAXY:HAFNIUM",
			"tools": [],
			"source_id": "MISPGALAXY",
			"reports": null
		},
		{
			"id": "2704d770-43b4-4bc4-8a5a-05df87416848",
			"created_at": "2022-10-25T15:50:23.306305Z",
			"updated_at": "2026-04-10T02:00:05.296581Z",
			"deleted_at": null,
			"main_name": "HAFNIUM",
			"aliases": [
				"HAFNIUM",
				"Operation Exchange Marauder",
				"Silk Typhoon"
			],
			"source_name": "MITRE:HAFNIUM",
			"tools": [
				"Tarrask",
				"ASPXSpy",
				"Impacket",
				"PsExec",
				"China Chopper"
			],
			"source_id": "MITRE",
			"reports": null
		},
		{
			"id": "529c1ae9-4579-4245-86a6-20f4563a695d",
			"created_at": "2022-10-25T16:07:23.702006Z",
			"updated_at": "2026-04-10T02:00:04.71708Z",
			"deleted_at": null,
			"main_name": "Hafnium",
			"aliases": [
				"G0125",
				"Murky Panda",
				"Red Dev 13",
				"Silk Typhoon"
			],
			"source_name": "ETDA:Hafnium",
			"tools": [],
			"source_id": "ETDA",
			"reports": null
		}
	],
	"ts_created_at": 1775434043,
	"ts_updated_at": 1775792148,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/fe38ca9e8664e774e9783b3db2315f1a94afa094.pdf",
		"text": "https://archive.orkl.eu/fe38ca9e8664e774e9783b3db2315f1a94afa094.txt",
		"img": "https://archive.orkl.eu/fe38ca9e8664e774e9783b3db2315f1a94afa094.jpg"
	}
}