{
	"id": "78a64996-f264-4eb8-82e4-fa2fd362a3a1",
	"created_at": "2026-04-06T00:14:41.001113Z",
	"updated_at": "2026-04-10T03:20:35.853528Z",
	"deleted_at": null,
	"sha1_hash": "9f79e69b351d0fa209872bb12464ec50c886d835",
	"title": "CFR Watering Hole Attack Details",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 148495,
	"plain_text": "CFR Watering Hole Attack Details\r\nBy by Darien Kindlund\r\nPublished: 2012-12-28 · Archived: 2026-04-05 20:20:16 UTC\r\nThreat Research\r\n[Updated on December 30, 2012] On December 27, we received reports that the Council on Foreign Relations\r\n(CFR) website was compromised and hosting malicious content on or around 2:00 PM EST on Wednesday,\r\nDecember 26. Through our Malware Protection Cloud, we can confirm that the website was compromised\r\nat that time, but we can also confirm that the CFR website was also hosting the malicious content as early as\r\nFriday, December 21—right before a major U.S. holiday.\r\nWe can also confirm that the malicious content hosted on the website does appear to use Adobe Flash to generate a\r\nheap spray attack against Internet Explorer version 8.0 (fully patched), which was the source of the zero-day\r\nvulnerability. We have chosen not to release the technical details of this exploit, as Microsoft is still investigating\r\nthe vulnerability at this time.\r\nIn the meantime, the initial JavaScript hosting the exploit has some interesting features. To start, it appears the\r\nJavaScript only served the exploit to browsers whose operating system language was either English (U.S.),\r\nChinese (China), Chinese (Taiwan), Japanese, Korean, or Russian:\r\nvar h=navigator.systemLanguage.toLowerCase();\r\nif(h!=\"zh-cn\" \u0026\u0026 h!=\"en-us\" \u0026\u0026 h!=\"zh-tw\" \u0026\u0026 h!=\"ja\" \u0026\u0026 h!=\"ru\" \u0026\u0026 h!=\"ko\")\r\n{\r\n  location.href=\"about:blank\";\r\n}\r\nAlso, the exploit used browser cookies to ensure that the exploit is only delivered once for every user:\r\nvar num=DisplayInfo();\r\nif(num \u003e1)\r\n{\r\n  location.href=\"about:blank\";\r\n}\r\nwhere DisplayInfo() essentially tracked when the page was last visited through browser cookies:\r\nfunction DisplayInfo()\r\n{\r\n    var expdate = new Date();\r\n    var visit;\r\nhttps://web.archive.org/web/20201024230407/https://www.fireeye.com/blog/threat-research/2012/12/council-foreign-relations-water-hole-attack-details.html\r\nPage 1 of 4\n\nexpdate.setTime(expdate.getTime() +  (24 * 60 * 60 * 1000*7 ));\r\n    if(!(visit = GetCookie(\"visit\")))\r\n    visit = 0;\r\n    visit++;\r\n    SetCookie(\"visit\", visit, expdate, \"/\", null, false);\r\n    return visit;\r\n}\r\nOnce those initial checks passed, the JavaScript proceeded to load a flash file \"today.swf\", which ultimately\r\ntriggered a heap spray in Internet Explorer in order to complete the compromise of the endpoint.\r\nOnce the browser is exploited, Prior to downloading the exploit, the browser appears to download “xsainfo.jpg”\r\ninto the browser cache (aka \"drive-by cache attack\"), which is the dropper encoded using single-byte XOR\r\n(key: 0x83, ignoring 0x00 and 0x83 bytes). Once the exploit succeeds, the JPG file is decoded as a DLL, which\r\nis written to the %TEMP% folder as \"flowertep.jpg\", the sample (MD5:\r\n1e90bd550fa8b288764dd3b9f90425f8) (MD5: 715e692ed2b48e455734f2d43b936ce1) appears to contain\r\ndebugging information in the metadata of the file:\r\nThe simplified Chinese \u003c文件说明\u003e translates to \u003cFile Description\u003e. It looks like the malware author included\r\nadditional metadata in the file, referencing \"test_gaga.dll\" as the internal name of this sample.\r\n[Update: December 30, 2012]\r\nAdditionally, another binary \"shiape.exe\" (MD5: a2e119106c38e09d2202e2a33e64adc9) is initially dropped to\r\nthe %TEMP% folder and executed, which appears to perform code injection activity against the standard IE\r\n\"iexplore.exe\" process and installs itself as \"%PROGRAMFILES%\\Common Files\\DirectDB.exe\", using the\r\nHKLM\\SOFTWARE\\STS\\\"nck\" registry key to maintain state information. We can also confirm Jamie Blasco's\r\n(AlienVault) findings, where the malware registers \"DirectDB.exe\" through the active setup registry key\r\nHKLM\\SOFTWARE\\Microsoft\\Active Setup\\Installed\r\nComponents\\, so that this executable starts once per user upon subsequent login. However, while AlienVault's IOC\r\nmentions a process handle name of \"\u0026!#@\u0026\", we have actually found the \"shiape.exe\" process generates a\r\nmutex of \\BaseNamedObjects\\\u0026!#@\u0026 upon execution, as well.\r\nAs of December 29, Microsoft released a security advisory (2794220), which provides initial details of the zero-day vulnerability. Additionally, CVE-2012-4792 has been assigned to track this vulnerability over time.\r\nhttps://web.archive.org/web/20201024230407/https://www.fireeye.com/blog/threat-research/2012/12/council-foreign-relations-water-hole-attack-details.html\r\nPage 2 of 4\n\nSimultaneously, Metasploit developers have analyzed the vulnerability and Eric Romang released details of the\r\nCDwnBindInfo Proof of Concept Vulnerability demonstration for independent verification.\r\nLastly, Cristian Craioveanu and Jonathan Ness with MSRC Engineering posted further technical details on MS\r\nTechnet about ways to mitigate CVE-2012-4792, in the meantime. \r\nOne interesting side-note that MSRC mentioned is:\r\nOn systems where the vulnerability is not present, this Javascript snippet will have the side effect of\r\ninitiating an HTTP GET request with the encoded heap spray address in it. A network log or proxy log\r\nwould reveal the following HTTP requests:\r\nGET /exploit.html HTTP/1.1\r\nGET /%E0%B4%8C%E1%82%ABhttps://www.example.com HTTP/1.1\r\nAs you can see, the value 0x10AB0C0D is encoded in UTF8 and sent as part of the HTTP request. The\r\nreal-world exploits do not use example.com and the heap spray address will vary depending on targeted\r\nOS platform and exploit mechanism but if you see encoded memory addresses in your proxy log, you\r\nshould investigate to determine whether your organization has been targeted.\r\nYet, in the wild, we have seen cases where a successfully compromised endpoint generates an equivalent\r\nencoded pattern:\r\n... and still beacons (via HTTP POST) to the initial command and control infrastructure at\r\n[REDACTED].yourtrap.com. Therefore, we encourage security operations analysts to fully investigate\r\nendpoints that generate the encoded heap spray network traffic, rather than simply assuming those systems\r\nare not compromised.\r\nhttps://web.archive.org/web/20201024230407/https://www.fireeye.com/blog/threat-research/2012/12/council-foreign-relations-water-hole-attack-details.html\r\nPage 3 of 4\n\nWe will continue to update this blog with further details, as we discover new information about this attack.\r\nSource: https://web.archive.org/web/20201024230407/https://www.fireeye.com/blog/threat-research/2012/12/council-foreign-relations-water-h\r\nole-attack-details.html\r\nhttps://web.archive.org/web/20201024230407/https://www.fireeye.com/blog/threat-research/2012/12/council-foreign-relations-water-hole-attack-details.html\r\nPage 4 of 4",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://web.archive.org/web/20201024230407/https://www.fireeye.com/blog/threat-research/2012/12/council-foreign-relations-water-hole-attack-details.html"
	],
	"report_names": [
		"council-foreign-relations-water-hole-attack-details.html"
	],
	"threat_actors": [],
	"ts_created_at": 1775434481,
	"ts_updated_at": 1775791235,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/9f79e69b351d0fa209872bb12464ec50c886d835.pdf",
		"text": "https://archive.orkl.eu/9f79e69b351d0fa209872bb12464ec50c886d835.txt",
		"img": "https://archive.orkl.eu/9f79e69b351d0fa209872bb12464ec50c886d835.jpg"
	}
}