{
	"id": "3a3f3ffd-8c75-460c-8d46-ba2cc4d1e069",
	"created_at": "2026-04-06T00:21:04.528085Z",
	"updated_at": "2026-04-10T03:20:21.49312Z",
	"deleted_at": null,
	"sha1_hash": "af6f5ae1bdecd8622533a5f58307cac085c0186f",
	"title": "Tricks and COMfoolery: How Ursnif (Gozi) Evades Detection",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 428852,
	"plain_text": "Tricks and COMfoolery: How Ursnif (Gozi) Evades Detection\r\nBy Alex Holland\r\nPublished: 2019-03-07 · Archived: 2026-04-05 15:04:54 UTC\r\nUrsnif is one of the main threats that is effectively evading detection right now (at publication)\r\nThe dropper uses a COM technique to hide its process parentage\r\nWMI is used to bypass a Windows Defender attack surface reduction rule\r\nFast evolution of delivery servers means detection tools are left in the dark\r\nIn February we saw a resurgence of Ursnif (also known as Gozi), a credential-stealing Trojan that was first\r\nuncovered in 2007 and has been active ever since. Alongside Emotet, this threat is one of the most pervasive and\r\neffective malware families currently being delivered through malicious spam campaigns.\r\nThe recent campaign we observed used a standard multi-stage malware delivery mechanism, consisting of a\r\nphishing email delivering a Microsoft Word dropper containing a VBA AutoOpen macro inside a password-protected zip file. When opened, the document downloads the Ursnif executable from a remote server using\r\nPowerShell WebClient.DownloadFile, WebClient.DownloadString or WebClient.DownloadData methods. Unlike\r\nmany run-of-the-mill malicious spam campaigns, what’s interesting is how Ursnif’s operators link different\r\ntechniques together to effectively socially engineer targets, evade perimeter detection and bypass one of Windows\r\nDefender’s attack surface reduction rules.\r\nhttps://www.bromium.com/how-ursnif-evades-detection/\r\nPage 1 of 7\n\nUrsnif infection chain\r\nEffective Social Engineering\r\nUrsnif’s operators commonly tailor the phishing lure used against targets to make the email appear more\r\nauthentic. In this campaign, this was done by basing attachment names and the message body on businesses in the\r\nsame or related industries, or those that are geographically close to the target. In one of the samples we analysed,\r\nthe target was a manufacturer of a niche product. The zip attachment was named after a similar manufacturer in\r\nthe same industry and the Word dropper containing the malicious macro was named ‘Request4.doc’, presumably\r\nto trick the target into thinking that it was a legitimate purchase order.\r\nIn addition to targeted lures, Ursnif campaigns often rely on exploiting the existing trust relationship between a\r\ncompromised email account and the target. Instead of an unsolicited message, the target is commonly sent a\r\nphishing email from a compromised email account as a reply to an existing conversation between the sender and\r\nthe target. The curiosity of receiving an unexpected attachment from a sender that is already known to the target\r\nmight just be enough to entice a user into opening the attachment.\r\nAttack Infrastructure\r\nhttps://www.bromium.com/how-ursnif-evades-detection/\r\nPage 2 of 7\n\nUrsnif has a fast-changing delivery and command and control (C2) infrastructure. Our research found that the\r\naverage time from the registration of a domain used to host Ursnif executables to when a user first runs the\r\ncorresponding Word dropper is less than 12 hours. The speed at which Ursnif’s operators can change its\r\ninfrastructure gives web proxies and other perimeter security controls that rely on a traditional detection-based\r\ntechniques little time to block the download of the malware. In one example, only one domain reputation service\r\nhad classified the Ursnif delivery domain as malicious at the time when the Word dropper was run.\r\nBlacklist report of an Ursnif delivery domain\r\nEncrypted Zip Attachment\r\nThe dropper is delivered inside a password-protected zip file, with the password in the email message body. The\r\ndelivery of malware using this method is an old but effective technique for bypassing perimeter detection by\r\nmalware scanners at the target’s email gateway. While some organisations will block inbound email containing\r\npassword-protected zip files as a matter of policy, many will not do so because they are often used for legitimate\r\nreasons.\r\nBypassing an Attack Surface Reduction Rule\r\nThe dropper we identified in this campaign contains an obfuscated VBA AutoOpen macro, which runs each time\r\nthe document is opened. The document uses the common trick of requesting the user to enable macros, if they are\r\nnot already enabled.\r\nhttps://www.bromium.com/how-ursnif-evades-detection/\r\nPage 3 of 7\n\nObfuscated VBA macro, partially showing the AutoOpen function and PowerShell command\r\nThe macro runs a Base64 encoded PowerShell command using the Win32_Process and Win32_ProcessStartup\r\nWMI classes. The resulting PowerShell instance is run as a child process of WmiPrvSe.exe (WMI Provider Host).\r\nThis benefits the adversary by defeating detection techniques that rely on parent-child process relationships\r\nbecause the parent process ID of the Ursnif executable will be the process ID of WmiPrvSe.exe, instead of\r\nwinword.exe. In our testing on Windows 10 Enterprise 1809, we found that this technique is effective at bypassing\r\nthe Windows Defender attack surface reduction rule that blocks Office applications from creating child processes.\r\nIn some of the samples, this was used in conjunction with a COM technique that also spoofed the parent process\r\nID of the Ursnif process.\r\nIt is worth noting, however, that if the attack surface reduction rule ‘Block process creations originating from\r\nPSExec and WMI commands’ is enabled, the attack is successfully blocked.\r\nDeobfuscated macro that executes the PowerShell command via WMI\r\nWe identified two types of PowerShell commands in this campaign. The first type downloads the Ursnif\r\nexecutable to the target’s user profile folder, checks that the resulting file is greater than or equal to 40 KB, then\r\nruns it using the Invoke-Item cmdlet.\r\nhttps://www.bromium.com/how-ursnif-evades-detection/\r\nPage 4 of 7\n\nDeobfuscated PowerShell command\r\nCOMfoolery – Spoofing Ursnif’s Parent Process ID\r\nThe second type similarly downloads a string from a remote server and runs it in memory using the ‘iex’ alias of\r\nthe Invoke-Expression cmdlet. Additionally, it downloads a byte array from a second website and writes it to a file\r\nin the target’s ProgramData folder. It then instantiates a ShellBrowserWindow COM object by reference to its\r\nclass ID (C08AFD90-F2A1-11D1-8455-00A0C91F3880), which is finally used to run the Ursnif executable using\r\nthe ShellExecute method. The malware is run in a hidden window because the value of the final parameter is set to\r\nzero.\r\nThe reason for doing this is so that Ursnif is created as a child process of the current instance of explorer.exe. This\r\nadds another layer of difficulty for detection techniques that rely on parent-child process relationships because the\r\nparent process ID of the Ursnif executable will be the process ID of explorer.exe, instead of the more suspicious\r\nWmiPrvSe.exe.\r\nhttps://www.bromium.com/how-ursnif-evades-detection/\r\nPage 5 of 7\n\nDeobfuscated PowerShell command demonstrating COMfoolery\r\nMitigation\r\nBromium Controller’s graph view showing an Ursnif executable being dropped and executed\r\nEndpoints that are running Bromium Secure Platform are protected from this threat because each user task, such\r\nas opening an Office document, is run in its own isolated micro-virtual machine (called μVMs). When the user\r\ncloses a μVM, the virtual machine is destroyed along with the malware. All of the threat data associated with the\r\nattack is recorded and presented in the Bromium Controller, enabling SOC and incident response teams to quickly\r\ngain detailed insights into the threats facing their organisations. For machines that support Windows Defender’s\r\nAttack Surface Reduction (ASR) rules (Windows 10 version 1803 or later, Windows Server 2016 1804 or later, or\r\nWindows Server 2019), we recommend enabling the rule to block process creations originating from PSExec and\r\nWMI commands (D1E49AAC-8F56-4280-B9BA-993A6D77406C), which would block the PowerShell stage of\r\nthis attack.\r\nUpdate 04/06/2019 – Reader Maxim Guslyaev reported to us that ASR rule D1E49AAC-8F56-4280-B9BA-993A6D77406C was not being enforced on Windows 10 version 1709. We conducted additional testing and\r\nconfirmed that the minimum OS version to enforce this rule is Windows 10 version 1803. To verify that ASR rules\r\nare working correctly, we recommend testing your configuration using Microsoft’s test files. As of 4 June, there is\r\nan open issue on Microsoft’s Github page to clarify the minimum OS version required for each ASR rule. Thank\r\nyou, Maxim!\r\nIndicators of Compromise (IOCs)\r\nThe following IOCs were collected as part of this blog.\r\nDropper File\r\nName\r\nRequest[integer].doc\r\nhttps://www.bromium.com/how-ursnif-evades-detection/\r\nPage 6 of 7\n\nUrsnif File\r\nPath\r\n%UserProfile%\\[3 digits].exe\r\nUrsnif File\r\nPath\r\n%ProgramData%\\WlWdsDd.exe\r\nDelivery URL hxxp://176.32.35[.]16/704e.php\r\nDelivery URL hxxp://nge18oei[.]email/iwp01-2ksm/20918201.php?l=jsrxm10.sap\r\nDelivery URL hxxp://d49dv62iea39[.]email/puewpxmasl/suoepwxpamxapxlamslxdo.php?l=noos10.harz\r\nDelivery URL hxxp://fpetraardella[.]band/xap_102b-AZ1/704e.php?l=litten2.gas\r\nSHA256 148C998DECFD121DBB978CA5B16569CEA6F0DB2325FCE6FA2D825C09DE09FB1B\r\nSHA256 CA3FB0CD43A01FA492571A43C67CCA571A39B7291CE4BFF18D131A20D5092CCC\r\nSHA256 99439D1A41DE2568364693670826F6FBEC9A26315918E3A0FC93A12412842033\r\nSHA256 DF30584321560CFBE899B0221E62E9227839915D6C39CCFD14C7C3C72C934A84\r\nSource: https://www.bromium.com/how-ursnif-evades-detection/\r\nhttps://www.bromium.com/how-ursnif-evades-detection/\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://www.bromium.com/how-ursnif-evades-detection/"
	],
	"report_names": [
		"how-ursnif-evades-detection"
	],
	"threat_actors": [],
	"ts_created_at": 1775434864,
	"ts_updated_at": 1775791221,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/af6f5ae1bdecd8622533a5f58307cac085c0186f.pdf",
		"text": "https://archive.orkl.eu/af6f5ae1bdecd8622533a5f58307cac085c0186f.txt",
		"img": "https://archive.orkl.eu/af6f5ae1bdecd8622533a5f58307cac085c0186f.jpg"
	}
}