{ "id": "cc4a34a9-0249-408e-9d99-17d094d3fae7", "created_at": "2026-04-06T00:22:33.9292Z", "updated_at": "2026-04-10T03:24:24.74414Z", "deleted_at": null, "sha1_hash": "4f8e3c9f5e14e777a628b6b0cafee37ab5b44228", "title": "Evil Clippy: MS Office maldoc assistant | Outflank", "llm_title": "", "authors": "", "file_creation_date": "0001-01-01T00:00:00Z", "file_modification_date": "0001-01-01T00:00:00Z", "file_size": 86613, "plain_text": "Evil Clippy: MS Office maldoc assistant | Outflank\r\nBy Stan\r\nPublished: 2019-05-05 · Archived: 2026-04-05 15:05:58 UTC\r\nAt BlackHat Asia we released Evil Clippy, a tool which assists red teamers and security testers in creating\r\nmalicious MS Office documents. Amongst others, Evil Clippy can hide VBA macros, stomp VBA code (via p-code) and confuse popular macro analysis tools. It runs on Linux, OSX and Windows.\r\nIn this blog post we will explore the features of Evil Clippy and the technology behind it. The latest source code of\r\nthe tool can be found here:\r\nhttps://github.com/outflanknl/EvilClippy\r\nLatest binary releases are available at:\r\nhttps://github.com/outflanknl/EvilClippy/releases\r\nUse cases\r\nAt the time of writing, this tool is capable of getting malicious macros to bypass all major antivirus products and\r\nmost maldoc analysis tools. It achieves this by manipulating MS Office files on a file format level.\r\nhttps://outflank.nl/blog/2019/05/05/evil-clippy-ms-office-maldoc-assistant/\r\nPage 1 of 8\n\nThe following screenshot shows detection rates of a default Cobalt Strike VBA macro before Evil Clippy is\r\napplied. This is a basic process injection macro which is obviously malicious and is detected by practically all\r\nmajor antivirus vendors.\r\nAfter applying Evil Clippy to this document (EvilClippy.exe -s fake.vbs -g -r cobaltstrike.doc), all major antivirus\r\nengines fail to detect this macro.\r\nNote that Evil Clippy only focuses on evasion of static analysis. A combination which can be particularly effective\r\nfor initial compromise during red teaming operations is to deliver malicious documents generated with Evil\r\nhttps://outflank.nl/blog/2019/05/05/evil-clippy-ms-office-maldoc-assistant/\r\nPage 2 of 8\n\nClippy via HTML smuggling (which helps you bypass perimeter defenses). If you need to evade dynamic analysis\r\nof macros, then read our blog on bypassing AMSI for VBA.\r\nEvil Clippy is written in C#. The code compiles perfectly fine with the Mono C# compiler and has been tested on\r\nLinux, OSX and Windows. Compilation and usage instructions can be found in the readme.\r\nTechnology\r\nIn order to understand how Evil Clippy works, we need to dive into the Compound File Binary Format (CFBF).\r\nThis file format is used abundantly in MS Office. Evil Clippy supports the following two MS Office file types:\r\n97 – 2003 format (.doc and .xls), these files are entirely in the CFBF file format.\r\n2007+ format (.docm and .xlsm), these files are actually ZIP containers. If you unzip the file, you will find\r\na file named “vbaProject.bin” in the “word” (.docm) or “xl” (.xlsm) directories. This file is a CFBF file\r\nwhich contains the macro information for the document.\r\nEvil Clippy uses the OpenMCDF library to manipulate CFBF files. If you want to manipulate CFBF files\r\nmanually, then FlexHEX is one of the best editors for this.\r\nThe pane on the bottom left shows the structure of this particular CFBF file. A CFBF file is like a file system in a\r\nsingle file: there are streams (think of them as “files”) which can be stored in containers (think of them as\r\n“directories”).\r\nThe “macros” container contains all subcontainers and streams related to VBA macros in a MS Word document. In\r\nMS Excel files this container is called “_VBA_PROJECT_CUR”. The structure and contents of this container are\r\nexplained by Microsoft in a lengthy and complex specification called MS-OVBA.\r\nhttps://outflank.nl/blog/2019/05/05/evil-clippy-ms-office-maldoc-assistant/\r\nPage 3 of 8\n\nThe most important streams in the macros container are:\r\nPROJECT: a stream with text data specifying project information. It can be regarded as a configuration file\r\nwith CRLF separated lines which instruct the VBA editor GUI (amongst others).\r\n_VBA_PROJECT: a stream with binary data which instructs the VBA engine. There is no official\r\ndocumentation on the contents of this stream, but it is crucial in how macros are interpreted (which we will\r\nsee later in this post).\r\nDir: a stream which contains the VBA project layout. This stream is compressed and its format is rather\r\nwell documented.\r\nModule streams: in the screenshot above there are two module streams named “ThisDocument” and\r\n“Module1”. These contain the actual code that is going to run. Each module stream consist of two parts: a\r\nPerformanceCache, which is undocumented, and CompressedSourceCode, which contains the VBA macro\r\nsource code in a compressed format.\r\nNote that some streams contain compressed data (most notably the dir and module streams), using a custom\r\ncompression algorithm. Evil Clippy reuses code from Kavod.VBA.Compression to implement the compression\r\nalgorithm.\r\nFor more information on this file format, watch our TROOPERS19 presentation titled MS Office File Format\r\nSorcery. If you dive deeper into the MS-OVBA specifications, you will soon note the following issues:\r\nThere are many features which are not documented (for example, the PerformanceCache mentioned\r\nabove). It turns out however that many of these functions are critical for how VBA macros are actually\r\nprocessed and interpreted. More on this in the “VBA stomping” section below.\r\nThe specifications lead to ambiguity. For example, module names are stored in multiple places. The\r\nsection “Confusing analysis tools” later in this blog post will deal with this aspect.\r\nThe specifications are very long and complex. What happens when you slightly deviate from the specs?\r\nWe found that MS Office is much more robust and forgiving to such deviations than most analysis tools\r\n(example).\r\nEvil Clippy exploits these issues to evade static analysis by antivirus engines as well as manual VBA macro\r\nanalysis tools.\r\nVBA stomping (via p-code)\r\nThe most powerful technique of Evil Clippy is “VBA stomping”. VBA stomping abuses a feature which is not\r\nofficially documented: the undocumented PerformanceCache part of each module stream contains compiled\r\npseudo-code (p-code) for the VBA engine. If the MS Office version specified in the _VBA_PROJECT stream\r\nmatches the MS Office version of the host program (Word or Excel) then the VBA source code in the module\r\nstream is ignored and the p-code is executed instead.\r\nIn summary: if we know the version of MS Office of a target system (e.g. Office 2016, 32 bit), we can replace our\r\nmalicious VBA source code with fake code, while the malicious code will still get executed via p-code. In the\r\nmeantime, any tool analyzing the VBA source code (such as antivirus) is completely fooled.\r\nhttps://outflank.nl/blog/2019/05/05/evil-clippy-ms-office-maldoc-assistant/\r\nPage 4 of 8\n\nVesselin Bontchev was the first to publicly document this technique (samples here). The security team from\r\nWalmart has gathered great resources on this topic here. We briefly discussed this technique in our talk “The MS\r\nOffice Magic Show” at DerbyCon. Evil Clippy is the first tool to fully weaponize this technique for red teamers\r\nand security testers.\r\nFor example, in order to replace the VBA source code in your malicious document with fake code and to have the\r\nmalicious p-code run on 32 bit installs of Office 2016, run Evil Clippy with the following command line:\r\nEvilClippy.exe -s fakecode.vba -t 2016x86 macrofile.doc\r\nAfter executing this command, a file named “macrofile_EvilClippy.doc” will be created. Any common VBA\r\nanalysis tools such as OleVBA, OleDump or VirusTotal will tell you that this file contains the fake code.\r\nHowever, if the file is opened on a 32 bit install of Office 2016 (our target version), the malicious p-code is\r\nexecuted instead.\r\nSo in order to make this attack work, we need to know the MS Office version of our target. Achieving this is not\r\nas difficult as it sounds. A common trick is to send the victim an email that contains a tracking pixel. If the pixel is\r\nretrieved by MS Outlook (which is usually part of the same MS Office install), the headers of this HTTP request\r\nwill disclose the MS Office version number and whether it is a 32 or 64 bit install.\r\nEvil Clippy can also automate the target version identification for you using a templating trick. The process hereto\r\nis as follows:\r\nYou create a MS Word template (.dot / .dotm) that includes a malicious macro.\r\nRun the Evil Clippy tool with the –webserver option and point it to the malicious template file. It will then\r\nspin up a web server that listens for incoming connections on the port you specified.\r\nYou subsequently create another document that points to this template document via a URL by referencing\r\nit as a template from the developer toolbar in Word (you can use an arbitrary extension, .dot extension is\r\nnot required!).\r\nIf this document is opened, MS Office will reach out to the web server to fetch the template. Evil Clippy\r\nwill identify the target MS Office version from the HTTP header and will patch the version bytes in the\r\n_VBA_PROJECT stream of the malicious template before serving it.\r\nMake sure to read the caveats in the readme before you use this option! The following screenshots shows this\r\nfeature in action:\r\nhttps://outflank.nl/blog/2019/05/05/evil-clippy-ms-office-maldoc-assistant/\r\nPage 5 of 8\n\nHiding macros\r\nNote that after running a macro using p-code in MS Office, the VBA engine will reconstruct the VBA source code\r\nfrom p-code and display it in the VBA editor GUI when opened. Hence, we need an additional trick to hide our\r\nmalicious code from prying eyes.\r\nOne technique to achieve this is to modify the PROJECT stream. As mentioned above, this stream can be regarded\r\nas a configuration file for the VBA editor GUI. By simply removing a line such as “Module=Module1” we can\r\nmake the module named “Module1” disappear in the VBA editor. Note that this does not work with the default\r\n“ThisDocument” or “ThisWorkbook” modules, so you have to place your malicious code in a separate module in\r\norder to make this trick work.\r\nhttps://outflank.nl/blog/2019/05/05/evil-clippy-ms-office-maldoc-assistant/\r\nPage 6 of 8\n\nEvil Clippy can automatically hide all modules with the -g flag:\r\nEvilClippy.exe -g macrofile.doc\r\nAnother trick to make macro code unaccessible is to mark the project as locked and unviewable. This feature has\r\nbeen added to Evil Clippy by Carrie Robberts from Walmart and can be used with the -u flag. Carrie has written a\r\ndetailed blog on this topic.\r\nConfusing analysis tools\r\nAlthough the -g and -u flags can hide our malicious code from human eyes, they do not protect against security\r\ntools which analyse our file on a file format level. For example, pcodedmp can be used by an analyst to extract p-code from a document. However, we can use the ambiguity and complexity of the MS-OVBA specification to\r\nconfuse various analysis tools, including pcodedmp.\r\nEvil Clippy can confuse pcodedmp and many other analysis tools with the -r flag.\r\nEvilClippy.exe -r macrofile.doc\r\nAfter running pcodedmp on this file, it crashes with a “file not found” error and empty list of module names:\r\nhttps://outflank.nl/blog/2019/05/05/evil-clippy-ms-office-maldoc-assistant/\r\nPage 7 of 8\n\nHow does it achieve this? With the -r flag Evil Clippy sets random ASCII module names in the Dir stream. Most\r\nanalyst tools use the module names specified here, while MS Office parses module names from the undocumented\r\n_VBA_PROJECT stream. By setting a random ASCII module name most P-code and VBA analysis tools crash,\r\nwhile the actual P-code and VBA still runs fine in Word and Excel. More information about the root cause of this\r\nissue can be read in this Twitter thread by Vesselin Bontchev, the author of pcodedmp.\r\nDetection and mitigation\r\nEvil Clippy only scratches the surface of issues resulting from the gap between official Microsoft specifications on\r\nVBA macros (MS-OVBA) and its actual implementation in MS Office. Since malicious macros are one of the\r\nmost common methods for initial compromise by threat actors, proper defense against such macros is crucial. We\r\nbelieve that the lack of adequate specifications of how macros actually work in MS Office severely hinders the\r\nwork of antivirus vendors and security analysts. This blog post serves as a call to Microsoft to change this for the\r\nbetter.\r\nIn the meantime there are several things that you can do to make the life of a malicious macro much harder:\r\nFor users and teams in your organisation that do not use macros, turn them off.\r\nFor users that do require working with macros, consider disabling macros in documents that are\r\ndownloaded from the internet. Note that this feature is available in MS Office 2013 and 2016, and can be\r\ncontrolled via GPO.\r\nUse Attack Surface Reduction rules to limit the impact of malicious macros. Note that the most important\r\nrules can already be turned on with an E3 license. If you fear the impact of these rules in blocking mode,\r\nthen consider enabling them in audit mode for monitoring.\r\nDeploy an antivirus product that hooks into the AMSI for VBA engine. Although this implementation of\r\nAMSI is far from perfect, it will raise the bar for malicious macros.\r\nMonitor the execution of macros via our Sysmon trick, which can help you in hunting evil macros.\r\nAuthors and contributions\r\nEvil Clippy is maintained by Stan Hegt (@StanHacked).\r\nAfter its initial release, the project has received significant code contributions from the security team at Walmart,\r\nespecially from Carrie Robberts (@OrOneEqualsOne). If you want to contribute to Evil Clippy, we are happy to\r\nreceive your pull request.\r\nSpecial thanks to Nick Landers from Silent Break Security (@monoxgas) for pointing us towards OpenMCDF.\r\nSource: https://outflank.nl/blog/2019/05/05/evil-clippy-ms-office-maldoc-assistant/\r\nhttps://outflank.nl/blog/2019/05/05/evil-clippy-ms-office-maldoc-assistant/\r\nPage 8 of 8", "extraction_quality": 1, "language": "EN", "sources": [ "MITRE" ], "references": [ "https://outflank.nl/blog/2019/05/05/evil-clippy-ms-office-maldoc-assistant/" ], "report_names": [ "evil-clippy-ms-office-maldoc-assistant" ], "threat_actors": [ { "id": "610a7295-3139-4f34-8cec-b3da40add480", "created_at": "2023-01-06T13:46:38.608142Z", "updated_at": "2026-04-10T02:00:03.03764Z", "deleted_at": null, "main_name": "Cobalt", "aliases": [ "Cobalt Group", "Cobalt Gang", "GOLD KINGSWOOD", "COBALT SPIDER", "G0080", "Mule Libra" ], "source_name": "MISPGALAXY:Cobalt", "tools": [], "source_id": "MISPGALAXY", "reports": null } ], "ts_created_at": 1775434953, "ts_updated_at": 1775791464, "ts_creation_date": 0, "ts_modification_date": 0, "files": { "pdf": "https://archive.orkl.eu/4f8e3c9f5e14e777a628b6b0cafee37ab5b44228.pdf", "text": "https://archive.orkl.eu/4f8e3c9f5e14e777a628b6b0cafee37ab5b44228.txt", "img": "https://archive.orkl.eu/4f8e3c9f5e14e777a628b6b0cafee37ab5b44228.jpg" } }