{
	"id": "5dc781b8-5c0d-43d0-bd23-aead9808ee03",
	"created_at": "2026-04-06T00:16:44.292002Z",
	"updated_at": "2026-04-10T03:21:03.341952Z",
	"deleted_at": null,
	"sha1_hash": "46e511b8438266866b8baa20ea39337bcf9ccaec",
	"title": "Spoofed SEC Emails Distribute Evolved DNSMessenger",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 2047462,
	"plain_text": "Spoofed SEC Emails Distribute Evolved DNSMessenger\r\nBy Edmund Brumaghin\r\nPublished: 2017-10-11 · Archived: 2026-04-05 20:46:47 UTC\r\nWednesday, October 11, 2017 12:11\r\nThis post was authored by Edmund Brumaghin, Colin Grady, with contributions from Dave Maynor and\r\n@Simpo13.\r\nExecutive Summary\r\nCisco Talos previously published research into a targeted attack that leveraged an interesting infection process\r\nusing DNS TXT records to create a bidirectional command and control (C2) channel. Using this channel, the\r\nattackers were able to directly interact with the Windows Command Processor using the contents of DNS TXT\r\nrecord queries and the associated responses generated on the attacker-controlled DNS server.\r\nWe have since observed additional attacks leveraging this type of malware attempting to infect several target\r\norganizations. These attacks began with a targeted spear phishing email to initiate the malware infections and also\r\nleveraged compromised U.S. state government servers to host malicious code used in later stages of the malware\r\ninfection chain. The spear phishing emails were spoofed to make them appear as if they were sent by the\r\nSecurities and Exchange Commission (SEC) in an attempt to add a level of legitimacy and convince users to open\r\nthem. The organizations targeted in this latest malware campaign were similar to those targeted during previous\r\nDNSMessenger campaigns. These attacks were highly targeted in nature, the use of obfuscation as well as the\r\npresence of a complex multi-stage infection process indicates that this is a sophisticated and highly motivated\r\nthreat actor that is continuing to operate.\r\nhttps://blog.talosintelligence.com/2017/10/dnsmessenger-sec-campaign.html\r\nPage 1 of 8\n\nTechnical Details\r\nThe emails associated with this malware campaign were spoofed to make them appear as if they had originated\r\nfrom the Securities and Exchange Commission (SEC) Electronic Data Gathering, Analysis, and Retrieval\r\n(EDGAR) system. For those not familiar with this system, EDGAR is an automated filing platform that\r\norganizations can use to submit filings which are legally required to be performed by publicly traded companies.\r\nThis was likely done to increase the perceived legitimacy of the emails and increase the chances that the recipient\r\nwould open the email and associated attachments.\r\nThe emails themselves contained a malicious attachment that when opened would initiate a sophisticated multi-stage infection process leading to infection with DNSMessenger malware. The malicious attachments were\r\nMicrosoft Word documents. Rather than leveraging macros or OLE objects, which are some of the most common\r\nways that Microsoft Word documents are leveraged to execute code, these attachments leveraged Dynamic Data\r\nExchange (DDE) to perform code execution. A description of this technique has been published here. This\r\ntechnique has recently been publicized following a Microsoft decision that this functionality is a feature by design\r\nand will not be removed. We are now seeing it actively being used by attackers in the wild, as demonstrated in this\r\nattack.\r\nSimilar to the emails described above, the malicious attachments were made to appear as if they had originated\r\nfrom the SEC and include logos and branding as well as information that would be expected from any documents\r\nreceived from the SEC. When opened, victims would be greeted with a message informing them that the\r\ndocument contains links to external files, and asking them to allow/deny the content to be retrieved and displayed.\r\nhttps://blog.talosintelligence.com/2017/10/dnsmessenger-sec-campaign.html\r\nPage 2 of 8\n\nIn the case of this attack, if the user allows the external content to be retrieved, the malicious document will reach\r\nout to attacker hosted content to retrieve code that will be executed to initiate the malware infection. Interestingly,\r\nthe DDEAUTO field used by this malicious document retrieved code that the attacker had initially hosted on a\r\nLouisiana state government website, which was seemingly compromised and used for this purpose. The\r\nDDEAUTO command that is executed is below:\r\nThe aforementioned command results in the code hosted at the referenced URL to be downloaded and executed\r\ndirectly using Powershell. The contents of the code that is retrieved from the server is Powershell code and\r\nincludes a code blob that is both Base64 encoded and gzipped. The code is retrieved, deobfuscated, then passed to\r\nthe Invoke-Expression (IEX) cmdlet and executed by Powershell.\r\nThe deobfuscated code is responsible for staging and kicking off subsequent stages of the infection process. It is\r\nalso responsible for achieving persistence on systems. The code features a number of ways that persistence may be\r\nachieved depending on the operating environment of the malware. It determines the version of Powershell on the\r\ninfected system as well as the access privileges of the user to determine how to proceed with achieving this\r\npersistence.\r\nFirst, a blob of code called $ServiceCode, which is also both base64 encoded and compressed using gzip, is\r\nwritten to the Windows registry using the following Powershell command:\r\nhttps://blog.talosintelligence.com/2017/10/dnsmessenger-sec-campaign.html\r\nPage 3 of 8\n\nA second block of code present in the Powershell is called $stagerCode and is responsible for extracting and\r\ndecoding the code that was previously stored in the registry, then executing this code, first checking for the\r\npresence of the mutex '1823821749'. If this mutex does not exist, execution continues.\r\nThe malware then attempts to write the contents of $stagerCode along with the appropriate PowerShell command\r\nto execute it to the following registry locations, creating a new registry key called \"IE\"\r\nHKLM:\\SOFTWARE\\Microsoft\\Windows\\CurrentVersion\\Run\r\nHKLM:\\Software\\Microsoft\\Windows\\CurrentVersion\\RunOnce\r\nHKLM:\\Software\\Microsoft\\Windows\\CurrentVersion\\RunServices\r\nHKCU:\\Software\\Microsoft\\Windows\\CurrentVersion\r\nHKEY_USERS\\.Default\\Software\\Microsoft\\Windows\\CurrentVersion\\Run\r\nHKLM:\\Software\\Microsoft\\Windows NT\\CurrentVersion\\Winlogon\r\nHKLM:\\System\\CurrentControlSet\\Services\\VxD\r\nHKCR:\\vbsfile\\shell\\open\\command\r\nThe malware also creates a new scheduled task called \"IE\" that is responsible for executing $stagerCode each time\r\nthe system boots, using a random startup delay period.\r\nhttps://blog.talosintelligence.com/2017/10/dnsmessenger-sec-campaign.html\r\nPage 4 of 8\n\nThe malware then queries the system to determine the characteristics of the environment in which it is operating to\r\ndetermine how to proceed. It specifically checks the version of Powershell that is installed on the system. If the\r\nsystem is running a Powershell version later than Powershell 2.0, the malware will write the contents of\r\n$ServiceCode to an Alternate Data Stream (ADS) of the the following file location:\r\n%PROGRAMDATA%\\Windows:kernel32.dll\r\nThe malware then checks to determine the privilege level of the user that was infected. If the user has\r\nadministrative privileges on the infected system, it will set up a WMI event consumer and filter as an additional\r\nWMI-based persistence mechanism. The filter name is \"kernel32_filter\" and the consumer name is\r\n\"kernel32_consumer\". The Powershell code used for the performance of these tasks is below:\r\nOnce all of these tasks have completed, the malware then enters the next stage of the infection process by\r\nexecuting $stagerCode directly using the IEX Powershell cmdlet.\r\nThis next stage of the malware infection was heavily obfuscated with both variables and function names obscured.\r\nMost of the strings within this code were also base64 encoded. The code associated with this stage starts by\r\ndefining an array containing a list of domains that will be used for subsequent Command and Control (C2)\r\ncommunications. A list of the domains in this array is included in the Indicators of Compromise section of this\r\nblog.\r\nhttps://blog.talosintelligence.com/2017/10/dnsmessenger-sec-campaign.html\r\nPage 5 of 8\n\nThe malware also obtains the serial number of the system from the BIOS. It calculates the MD5 hash of the serial\r\nnumber and returns the first ten bytes.\r\nExample S/N: VMware-56 4d 64 66 d0 7d f4 26-2c ad a5 8b f8 51 26 f8\r\nResulting Value: EFA29DD310\r\nThe malware then sets a counter value to zero. The aforementioned hash value, the hardcoded string\r\n\"stage\", the value of the counter, and a randomly selected domain from the array are then combined to\r\ncreate the initial hostname that will be used by the malware to start making DNS requests.\r\nExample Hostname: EFA29DD310.stage.0.ns0.pw\r\nAt this point the malware enters a loop which will continue until it receives an A record lookup result of\r\n0.0.0.0 or any lookup fails entirely. The A record result represents a checksum value, which will be\r\nexplained below. The IPv4 value returned by the DNS server in response to the A record request is then\r\nconverted to an integer, then a binary number.\r\nExample IP: 107.50.99.116\r\nInteger Value: 1798464372\r\nBinary: 1101011001100100110001101110100\r\nThe same generated hostname is then used by the malware to make a TXT record request. The result of the\r\nTXT record query is then used to calculate an MD5 hash and the first eight bytes of the MD5 hash are then\r\nrun through a checksum algorithm that returns an integer value which is converted into a binary number.\r\nExample TXT Query Result:\r\nH4sIAIia3VkC/909a1fbSJafyTn5DxXhbkvYEpg8pgcjpnnkwXQgLNCTnnG8HdkqQGBLjiRDCPE5+x/2H+4v2XvrpdLLmE7m9J6lZ8BWVd133br\r\nMD5: 432B4077F72EE96CA70B57F10B68F35E\r\nSelected Bytes: 432B4077\r\nChecksum: 1126908023\r\nBinary: 1000011001010110100000001110111\r\nOnce the malware has both the binary values from the A record response and the above checksum\r\ncalculation, they are compared. If the A record response and the TXT record response match, the result of\r\nthe TXT record query response is appended to the end of a final resulting string, a new domain is then\r\nrandomly selected from the array and the counter value previously mentioned, and included in the\r\nhostname used for queries, is incremented by one. If they don't match, the queries continue in kind until\r\nthey do.\r\nThis process continues until the result of the A record lookup is 0.0.0.0, which indicates a completion of the code\r\ncollection via DNS, at which time the resulting string is returned for further processing. This result string is then\r\ndecoded using Base64 and decompressed using gzip. It is then passed to the Powershell IEX cmdlet to execute the\r\ncode that was retrieved using DNS.\r\nDuring analysis of this specific attack, we were unable to obtain this next stage of Powershell code from the C2\r\nservers. Given the targeted nature of this attack it is likely that the attacker is restricting these communications in\r\nan attempt to evade analysis by information security companies and researchers. It's been reported that the stage 4\r\npayload is documented here.\r\nhttps://blog.talosintelligence.com/2017/10/dnsmessenger-sec-campaign.html\r\nPage 6 of 8\n\nConclusion\r\nThis attack shows the level of sophistication that is associated with threats facing organizations today. Attackers\r\noften employ multiple layers of obfuscation in an attempt to make analysis more difficult, evade detection and\r\nprevention capabilities, and continue to operate under the radar by limiting their attacks to only the organizations\r\nthat they are targeting. It is also important for organizations to be aware of some of the more interesting\r\ntechniques that malware is using to execute malicious code on systems and gain persistence on systems once they\r\nare infected. In this particular case, the malware featured the capability to leverage WMI, ADS, scheduled tasks,\r\nas well as registry keys to obtain persistence. The use of DNS as a conveyance for later stage code and C2\r\ncommunications is also becoming more and more commonplace. Talos continues to monitor the threat landscape\r\nfor unique and targeted attacks such as this one so that customers remain protected as attackers change the\r\ntechniques they use to perform their malicious activities.\r\nCoverage\r\nAdditional ways our customers can detect and block this threat are listed below.\r\nAdvanced Malware Protection (AMP) is ideally suited to prevent the execution of the malware used by these\r\nthreat actors.\r\nCWS or WSA web scanning prevents access to malicious websites and detects malware used in these attacks.\r\nEmail Security can block malicious emails sent by threat actors as part of their campaign.\r\nNetwork Security appliances such asNGFW,NGIPS, andMeraki MX can detect malicious activity associated with\r\nthis threat.\r\nAMP Threat Grid helps identify malicious binaries and build protection into all Cisco Security products.\r\nUmbrella, our secure internet gateway (SIG), blocks users from connecting to malicious domains, IPs, and URLs,\r\nwhether users are on or off the corporate network.\r\nhttps://blog.talosintelligence.com/2017/10/dnsmessenger-sec-campaign.html\r\nPage 7 of 8\n\nOpen Source Snort Subscriber Rule Set customers can stay up to date by downloading the latest rule pack\r\navailable for purchase on Snort.org.\r\nIndicators of Compromise (IOCs)\r\nThe following Indicators of Compromise (IOCs) are associated with the attack described in this blog post.\r\nMalicious Word Documents:\r\n1a1294fce91af3f7e7691f8307d07aebd4636402e4e6a244faac5ac9b36f8428\r\nbf38288956449bb120bae525b6632f0294d25593da8938bbe79849d6defed5cb\r\nStage 2 PowerShell\r\n8c5209671c9d4f0928f1ae253c40ce7515d220186bb4a97cbaf6c25bd3be53cf\r\nec3aee4e579e0d1db922252f9a15f1208c4f9ac03bd996af4884725a96a3fdf6\r\nDomains:\r\ntrt[.]doe[.]louisiana[.]gov\r\nns0[.]pw\r\nns0[.]site\r\nns0[.]space\r\nns0[.]website\r\nns1[.]press\r\nns1[.]website\r\nns2[.]press\r\nns3[.]site\r\nns3[.]space\r\nns4[.]site\r\nns4[.]space\r\nns5[.]biz\r\nns5[.]online\r\nns5[.]pw\r\nIP Addresses:\r\n206[.]218[.]181[.]46\r\nSource: https://blog.talosintelligence.com/2017/10/dnsmessenger-sec-campaign.html\r\nhttps://blog.talosintelligence.com/2017/10/dnsmessenger-sec-campaign.html\r\nPage 8 of 8",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia",
		"ETDA"
	],
	"references": [
		"https://blog.talosintelligence.com/2017/10/dnsmessenger-sec-campaign.html"
	],
	"report_names": [
		"dnsmessenger-sec-campaign.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434604,
	"ts_updated_at": 1775791263,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/46e511b8438266866b8baa20ea39337bcf9ccaec.pdf",
		"text": "https://archive.orkl.eu/46e511b8438266866b8baa20ea39337bcf9ccaec.txt",
		"img": "https://archive.orkl.eu/46e511b8438266866b8baa20ea39337bcf9ccaec.jpg"
	}
}