{
	"id": "850c114e-3b7d-46f9-9ec4-1249871833de",
	"created_at": "2026-04-06T00:18:38.664505Z",
	"updated_at": "2026-04-10T03:21:40.410141Z",
	"deleted_at": null,
	"sha1_hash": "efe65596dddb99e882d0b550114231087f4dfc8f",
	"title": "WebDAV Traffic To Malicious Sites",
	"llm_title": "",
	"authors": "",
	"file_creation_date": "0001-01-01T00:00:00Z",
	"file_modification_date": "0001-01-01T00:00:00Z",
	"file_size": 1406900,
	"plain_text": "WebDAV Traffic To Malicious Sites\r\nPublished: 2017-11-13 · Archived: 2026-04-05 20:28:42 UTC\r\nI observed WebDAV traffic to malicious sites in the past (in proxy logs), and recently I took some time to take a\r\ncloser look.\r\nTL;DR: when files are retrieved remotely with the file:// URI scheme on Windows, Windows will fallback to\r\nWebDAV when SMB connections can not be established.\r\nI did my tests with 2 Windows 7 VMs on the same subnet, one Windows 7 machine with IIS/WebDAV, and the\r\nother Windows 7 machine with Word 2016 and a .docx document with a remote template (template.dotx) (using\r\nthe file:// URI scheme). The Windows firewall on the IIS machine was configured to block ports 139 and 445.\r\nWhen the .docx document is opened, Word will retrieve the template:\r\nHere is the URI:\r\nFirst we see attempts to connect on ports 445 and 139 on the IIS machine (SYN packets):\r\nhttps://blog.didierstevens.com/2017/11/13/webdav-traffic-to-malicious-sites/\r\nPage 1 of 7\n\nThese come from the “System process”:\r\nThere are no packets coming back from the IIS machine (I blocked port 139 and 445), and after almost 30 seconds\r\nwe see an HTTP request to port 80 on the IIS machine:\r\nThis is a WebDAV request, notice the User Agent string “DavClnt”:\r\nThis TCP connection originates from the Word process:\r\nAnd about 3 seconds after this request, we get another WebDAV request:\r\nFor this request, the User Agent string is “Microsoft-WebDAV-MiniRedir/6.1.7601”.\r\nThis TCP connection originates from the WebClient service:\r\nhttps://blog.didierstevens.com/2017/11/13/webdav-traffic-to-malicious-sites/\r\nPage 2 of 7\n\nThis service was not started:\r\nThe svchost service host process will load and start the WebClient service:\r\nhttps://blog.didierstevens.com/2017/11/13/webdav-traffic-to-malicious-sites/\r\nPage 3 of 7\n\nhttps://blog.didierstevens.com/2017/11/13/webdav-traffic-to-malicious-sites/\r\nPage 4 of 7\n\nhttps://blog.didierstevens.com/2017/11/13/webdav-traffic-to-malicious-sites/\r\nPage 5 of 7\n\nWebClient (WebClnt.dll) is the WebDAV service:\r\nhttps://blog.didierstevens.com/2017/11/13/webdav-traffic-to-malicious-sites/\r\nPage 6 of 7\n\nTo summarize, when the file:// URI scheme is used in a Word document and SMB connections can not be\r\nestablished, we will see WebDAV requests from:\r\n1. Word (DavClnt)\r\n2. WebClient service (Microsoft-WebDAV-MiniRedir/6.1.7601)\r\nI’ve observed the same behavior with Windows 10 (with a different version number for the WebClient User Agent\r\nstring).\r\nWhen the document is opened a second time, there is no WebDAV request from Word (1), only requests from the\r\nWebClient service (2).\r\nWhen I stop the WebClient service and reopen the document, there is first a WebDAV request from Word (1)\r\nfollowed by requests from the WebClient service (2).\r\nWhen I disable the WebClient service and reopen the document, there are no more WebDAV requests at all.\r\nSource: https://blog.didierstevens.com/2017/11/13/webdav-traffic-to-malicious-sites/\r\nhttps://blog.didierstevens.com/2017/11/13/webdav-traffic-to-malicious-sites/\r\nPage 7 of 7",
	"extraction_quality": 1,
	"language": "EN",
	"sources": [
		"MITRE"
	],
	"references": [
		"https://blog.didierstevens.com/2017/11/13/webdav-traffic-to-malicious-sites/"
	],
	"report_names": [
		"webdav-traffic-to-malicious-sites"
	],
	"threat_actors": [],
	"ts_created_at": 1775434718,
	"ts_updated_at": 1775791300,
	"ts_creation_date": 0,
	"ts_modification_date": 0,
	"files": {
		"pdf": "https://archive.orkl.eu/efe65596dddb99e882d0b550114231087f4dfc8f.pdf",
		"text": "https://archive.orkl.eu/efe65596dddb99e882d0b550114231087f4dfc8f.txt",
		"img": "https://archive.orkl.eu/efe65596dddb99e882d0b550114231087f4dfc8f.jpg"
	}
}