{
	"id": "e0b843e4-e6e3-46e4-9293-a2013075ba3b",
	"created_at": "2026-04-06T00:11:39.708435Z",
	"updated_at": "2026-04-10T13:11:51.895934Z",
	"deleted_at": null,
	"sha1_hash": "41adf7bdd7b276e0fa5dd161811c6e6ab71aadc8",
	"title": "Emotet vs. Windows Attack Surface Reduction - SANS ISC",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 165607,
	"plain_text": "Emotet vs. Windows Attack Surface Reduction - SANS ISC\r\nBy SANS Internet Storm Center\r\nArchived: 2026-04-05 15:36:45 UTC\r\nEmotet malware in the form of malicious Word documents continued to make the rounds over the past weeks, and\r\nthe samples initially often had pretty poor anti-virus coverage (Virustotal) .The encoding used by the maldoc is\r\nvery similar to what Didier Stevens analyzed in his recent diary, and the same method can be used to extract the\r\nmal-code from the current Emotet docs.\r\nWith the de-obfuscation reasonably straight forward, I proceeded to look into how the malware crooks accomplish\r\nexecution from within the Word doc, and in particular, why Microsoft's \"Attack Surface Reduction Rules\" do\r\nnot seem to help much.\r\nBut first, let's take a quick detour into what Attack Surface Reduction (ASR) promises to do on modern Windows\r\ndevices. ASR is a somewhat clunky set of additional protections in Microsoft Defender Antivirus that can be\r\nturned on to log or intercept (block) some common attack scenarios. Microsoft's web site offers meager\r\ndocumentation, including a marginally helpful list of GUIDs that can be used to activate the feature.\r\nOne rule, \"Block all Office Applications from creating child processes\" (GUID D4F940AB-401B-4EFC-AADC-AD5F3C50688A) is supposed to prevent a Word document from launching any other task. Therefore, when this\r\nrule is configured, we would expect that the current Emotet and its execution chain of Word-Doc -\u003e cmd.exe -\u003e\r\nPowershell should not be successful. But it is.\r\nCloser inspection of the Defender Event Log gives a hint \"why\": \r\nhttps://isc.sans.edu/diary/rss/27036\r\nPage 1 of 2\n\nThe only ASR rule that we see firing when the Emotet Doc is being opened is the one with ID d1e49aac-8f56-\r\n4280-b9ba-993a6d77406c, corresponding to \"Block process creations originating from PSExec and WMI\r\ncommands\". Yes, the Emotet VBA Macro is using a WMI (windows management instrumentation) call to launch\r\nthe subsequent attack code. For such WMI invocation via the Win32 Process class, the parent process of \"cmd\"\r\nends up being WmiPrvSe.exe, which in turn is launched from \"svchost\". Therefore, \"cmd\" is not a child process of\r\nWord, and the ASR block rule to prevent child processes of Word consequently doesn't trigger. Bah!\r\nIn corporate environments, remote management of user devices often uses tools like SCCM or Endpoint Manager,\r\nwhich in turn rely on WMI to function. Therefore, setting the ASR Rule for WMI/PSExec to \"block\" will likely\r\nbreak device management, and cause a huge mess. Chances are, the Emotet crooks were fully aware of this, and\r\nthat's exactly why they chose this particular execution method for their attack code.\r\nIf you have Microsoft ATP, you can also use a hunting rule like this to search for WMI process creation\r\nDeviceEvents\r\n| where ActionType == \"ProcessCreatedUsingWmiQuery\"\r\n| project Timestamp, DeviceName, ActionType, FileName, SHA1, FolderPath, InitiatingProcessCommandLine,\r\nProcessCommandLine\r\n| sort by Timestamp desc\r\nYou might have to add a couple of exclusions to cover your management instrumentation or software distribution\r\ntools, but with a bit of tuning, you should see any current Emotet-like WMI attempts in your environment. The\r\nProcessCommandLine in these cases will be long (\u003e600chars) and contain Base64 encoded Powershell, and the\r\nInitiatingProcess is Winword.\r\nIn the meantime, the probably best bet to protect your Windows users against Emotet and similar malware remains\r\nto quarantine password protected zips or Office documents with macros on your email gateway, or to disable\r\nmacros within Office outright if you can get away with it.\r\nMaybe, in a decade or three, Microsoft will get to the point where malware introduced via Office documents really\r\nno longer is a concern and prevalent problem. Until then, I guess we have to kinda hope that today's international\r\nraid by law enforcement against the Emotet gang really got the right guys, and got them good.\r\nSource: https://isc.sans.edu/diary/rss/27036\r\nhttps://isc.sans.edu/diary/rss/27036\r\nPage 2 of 2",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"Malpedia"
	],
	"origins": [
		"web"
	],
	"references": [
		"https://isc.sans.edu/diary/rss/27036"
	],
	"report_names": [
		"27036"
	],
	"threat_actors": [],
	"ts_created_at": 1775434299,
	"ts_updated_at": 1775826711,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/41adf7bdd7b276e0fa5dd161811c6e6ab71aadc8.pdf",
		"text": "https://archive.orkl.eu/41adf7bdd7b276e0fa5dd161811c6e6ab71aadc8.txt",
		"img": "https://archive.orkl.eu/41adf7bdd7b276e0fa5dd161811c6e6ab71aadc8.jpg"
	}
}