{"id":39189,"date":"2014-11-12T17:31:27","date_gmt":"2014-11-13T01:31:27","guid":{"rendered":"http:\/\/blogs.mcafee.com\/?p=39189"},"modified":"2025-08-17T20:17:43","modified_gmt":"2025-08-18T03:17:43","slug":"bypassing-microsofts-patch-for-the-sandworm-zero-day-even-editing-can-cause-harm","status":"publish","type":"post","link":"https:\/\/www.mcafee.com\/blogs\/internet-security\/bypassing-microsofts-patch-for-the-sandworm-zero-day-even-editing-can-cause-harm\/","title":{"rendered":"Bypassing Microsoft\u2019s Patch for the Sandworm Zero Day"},"content":{"rendered":"

This is the\u00a0second part of our analysis of the Sandworm OLE zero-day vulnerability and the MS14-060<\/a> patch bypass. Check out the first part here.<\/a><\/em><\/p>\n

Microsoft’s Patch<\/strong><\/h2>\n

From our previous analysis we\u2019ve learned that the core of this threat is its ability to effectively right-click a file. Now, let’s see what Microsoft did in its patch MS14-060.<\/p>\n

With a little bit of help from patch diffing, we can easily spot that the function MarkFileUnsafe()<\/em> is called right after the malicious file is dropped into the temp folder. The following image shows the call:<\/p>\n

\"\"<\/a>MarkFileUnsafe() is called right after dropping the file into the temp folder.<\/em><\/p>\n

There are two ways that an attacker can drop a file into the temp folder. Researchers have seen real in-the-wild samples of both. The first way is to copy from a UNC location, such as in this sample<\/a> (SHA1: 22fbbcfa5646497e57ee238a180d1b367789984a).<\/em> The second is to drop it directly from the embedded OLE stream, as in this sample<\/a> (SHA1: cb2aadbfcfac3c5802ff23ae6971791549b120b8)<\/em>. Our research also shows that the two ways are represented by several code flows. Thus, there have to be (and we have seen them in the updated packager.dll) several places calling the MarkFileUnsafe() <\/em>function.<\/p>\n

Now, let’s take a look at what MarkFileUnsafe()<\/em> does. The function calls the IZoneIdentifier<\/a> APIs to mark the dropped file as coming from the Internet zone (“URLZONE_INTERNET”). At a low level, the function leverages a feature in NTFS. (If you’d like more details on how this works, refer to these links 1<\/a>, 2.<\/a>) We call this feature Internet marked.<\/p>\n

After a file is Internet marked, users will receive a warning dialog whenever they try to “execute” the file. This blocks automatic code execution. For example, installing an Internet-marked .inf file will bring up the following dialog, which is exactly what we saw when testing the original zero-day sample with Microsoft\u2019s patch MS14-060:<\/p>\n

\"\"<\/a>Warning dialog when a user tries to \u201cexecute\u201d the Internet-marked .inf file.<\/em><\/p>\n

Problem with the patch<\/strong><\/h2>\n

An “execute” action will be blocked by the Internet-marked feature because the Windows Shell routines will check the Security Zone when performing an\u00a0\u201cexecute\u201d action. However, a\u00a0“non-execute” action will go through directly. This is the same reason that we can’t directly run an executable downloaded through Internet Explorer, but we can open a downloaded Word document with Office.<\/p>\n

Let\u2019s consider the potential problems:<\/p>\n