If observed WebDAV traffic to malicious sites in the past (in proxy logs), and recently I took some time to take a closer look.

TL;DR: when files are retrieved remotely with the file:// URI scheme on Windows, Windows will fallback to WebDAV when SMB connections can not be established.

I did my tests with 2 Windows 7 VMs on the same subnet, one Windows 7 machine with IIS/WebDAV, and the other Windows 7 machine with Word 2016 and a .docx document with a remote template (template.dotx) (using the file:// URI scheme). The Windows firewall on the IIS machine was configured to block ports 139 and 445.

When the .docx document is opened, Word will retrieve the template:

Here is the URI:

First we see attempts to connect on ports 445 and 139 on the IIS machine (SYN packets):

These come from the “System process”:

There are no packets coming back from the IIS machine (I blocked port 139 and 445), and after almost 30 seconds we see an HTTP request to port 80 on the IIS machine:

This is a WebDAV request, notice the User Agent string “DavClnt”:

This TCP connection originates from the Word process:

And about 3 seconds after this request, we get another WebDAV request:

For this request, the User Agent string is “Microsoft-WebDAV-MiniRedir/6.1.7601”.

This TCP connection originates from the WebClient service:

This service was not started:

The svchost service host process will load and start the WebClient service:

WebClient (WebClnt.dll) is the WebDAV service:

To summarize, when the file:// URI scheme is used in a Word document and SMB connections can not be established, we will see WebDAV requests from:

Word (DavClnt) WebClient service (Microsoft-WebDAV-MiniRedir/6.1.7601)

I’ve observed the same behavior with Windows 10 (with a different version number for the WebClient User Agent string).

When the document is opened a second time, there is no WebDAV request from Word (1), only requests from the WebClient service (2).

When I stop the WebClient service and reopen the document, there is first a WebDAV request from Word (1) followed by requests from the WebClient service (2).

When I disable the WebClient service and reopen the document, there are no more WebDAV requests at all.

 

Metasploit has a module to create Microsoft Word document with macros (.docm): office_word_macro.

Documents generated with this module are not that hard to analyze and detect, because they always use the same VBA code. As I explain in my workshops and trainings, although the “new” Office file format (OOXML) is a ZIP container for XML files, VBA code is still stored inside a binary file (vbaProject.bin) using the “old” file format (Compound File Binary Format, or ole file as I like to call it). This Metasploit module always uses the same vbaProject.bin file (inside the template file), and I explain how to analyze and detect it in this video:

I show YARA rules and ClamAV signatures in this video to detect documents created with this Metasploit module.

Here are the YARA rules:

/* Version 0.0.1 2017/08/20 Source code put in public domain by Didier Stevens, no Copyright https://DidierStevens.com Use at your own risk History: 2017/08/20: start */ import "hash" rule metasploit_office_word_macro_ID_GUID { meta: description = "Detect Metasploit's office_word_macro unique GUID" strings: $ID = "ID=\"{BB64F33D-3617-FA44-AFC9-63F65314A8A3}\"" condition: $ID } rule metasploit_office_word_macro_vbaproject_bin_zipped { meta: description = "Detect .docm files created with Metasploit's office_word_macro exploit" strings: $a = {776F72642F76626150726F6A6563742E62696EED3B0D7853D775E75D3D0959B6B1640C7120908B4CB04C2421C9B22D3B98EADF86D860B0032421C1FA79C222B2A44A4FD8E4A795B1D3928435AC5D33CAD20E42DAA62DEB489AB07EE9BA8976FB42F3B5DF48D3ED4BBA7531C99666FDBE0E4AB32F69B6C43BF7BD275BFE2350BA} condition: $a and hash.md5(@a + 19, 5962) == "e5995aba8551f30cc15c87ee49fb834a" }

The first rule (metasploit_office_word_macro_ID_GUID) detects the vbaProject.bin file used by this Metasploit module based on the unique ID ({BB64F33D-3617-FA44-AFC9-63F65314A8A3}) stored inside stream PROJECTwm of file vbaProject.bin. This rule must be used with a tool that can scan inside ZIP files, like zipdump.py or ClamAV.

If you can’t use such a tool, you can still use the second rule (metasploit_office_word_macro_vbaproject_bin_zipped) with the standard YARA scanner: this rule looks for the datastream of the compressed vbaProject.bin file inside Office files.

Here are the ClamAV signatures:

Signature to be put inside a .ndb file: metasploit_office_word_macro_ID_GUID:0:*:49443D227B42423634463333442D333631372D464134342D414643392D3633463635333134413841337D22 Signature to be put inside a .hdb file: 1788454ae206101fa6febf99005ce03b:15872:metasploit_office_word_macro_vbaproject_bin

The first signature (metasploit_office_word_macro_ID_GUID) detects the unique ID (just like the first YARA rule), and the second signature (metasploit_office_word_macro_vbaproject_bin) detects the vbaProject.bin file based on the MD5 hash (1788454ae206101fa6febf99005ce03b).

ClamAV is able to scan inside OOXML/ZIP files.