 Hello, Didier Stevens here, Senior Handler at the Internet Storm Center. My dire entry about YARA and Cybershift was an example showing how you can use a YARA rule to detect office macros in a Word document with Cybershift. It was an OLE file, so the binary format .doc. I got a question if it also works for the new file format, the XML format, OO XML, Office Open XML, so doc.m when it comes for macros. It doesn't. You cannot use it like that, but there are some changes that you can make and then it will work. Let me show you. So I copy the recipe here, so I have my YARA rule here and now here I have a Word document, a doc.m file with macros, the new file format and as you can see here there is no detection. The reason is there is indeed an OLE file inside here, but this is a zip container and I showed you that zip container. You can also work with the zip container, but then you have to unzip it. So let's take this unzip command here and as you can see, still no detection. The reason why that is is because of the following. Then you provide a zip container like this Office document here, doc.m and you unzip it. Then YARA, sorry, Cybershift here will concatenate all the output as one single stream and so your YARA rule here will operate on all the different files considered as a single file. This YARA rule is not very suited for that because it searches for a string, that's okay, but then it also does a check. Is the beginning of the file, is there an unsigned 32-bit integer that when you look at its big-end representation equals to D0CF11E0 and that is not the case. So that is the start of an OLE file, but the very first files that we have in here are not OLE files, but XML files. So if I disable this here, you can see the XML files. And this here, VBAproject.bin file, that one contains the macros. So this is an OLE file, but it's not first. This will not work. One way to make this work is the following, is by not making the rule that strict that it has to be at the beginning, but that you just need to, that it needs to be present. And let me change the rule here, $B equals and then we will input some hexadecimal. So D0CF11E0 and that's the kind of lead speak for DOC file. And here we just say NB and now we have a match because it finds both strings. You can see here, it finds both strings. And as you can see here, the B string, so DOC file, it's not found at position 0, but at position 5,640. Now you can see here, there are four files in front of the VBAproject.bin file. So I opened the calculator here. Let's add these things together. 1, 4, 5, 3, plus 5, 9, 0, plus 2, 6, 5, 8, plus 9, 3, 9 equals 5,640. And if we re-enable this, you can see here position 5,640. So this illustrates that the different files are concatenated together. So you need to change your YARA rule. So also something I can illustrate in another way by disabling this, doing away with this file and taking another example file here, three text files. So this is a zip file that just contains three text files, 15 bytes each. This is line 1, this is line 2, this is line 3. If I now, for example, do a ASCII xdump, let's try this. Then you can see here that those three files are actually concatenated into a single file. This is line 1, new line, this is line 2, new line, this is line 3, new line. So you can do this here with YARA, unzipping the .m file. Then you're running your YARA rules on it. But you need to have YARA rules that will work. And also you can get false positives because it might find string A in one file and string B inside another file. And then the YARA rule will not trigger on those individual files, but here on the on the Recype with the zip file it will trigger. So it's not an ideal situation. If you can, then you need to unzip the files locally and then load them one by one here. For example, opening a folder with Cyberchef.