I recently watched the recording of the interesting talk Windows Forensics: Event Trace Logs that Nicole Ibrahim gave at SANS DFIR Summit 2018. I then used the tool ETLParser to dump the contents of all the ETL files stored on my own workstation. I glanced through the giant CSV output file looking for anything of interest and accidentally noticed a string "ExternalIpAddress". As you can see, the string is followed by an IP address.
That IP address is my current public IP address. Why is it there?
The string "ExternalIpAddress" is located next to other interesting strings like "GEO: response", "CountryCode" and a precious timestamp. If this is a geolocation response, what triggered it? Since "ExternalIpAddress"appears several times in the log files, how many geolocation requests have been made so far and why?
DoSvc - Delivery Optimization
All the hits were found within some logs whose names begin with "dosvc". I searched on Google and found out that "dosvc" stands for Delivery Optimization which is the update delivery service for Windows 10 clients. In the online documentation Optimize Windows 10 update delivery, Microsoft explains what this service does:
Delivery Optimization is a new peer-to-peer distribution method in Windows 10. Windows 10 clients can source content from other devices on their local network that have already downloaded the updates or from peers over the internet.
Depending on the version of Windows 10, the various Event Trace Log (ETL) files created by the Delivery Optimization service (DoSvc) are stored here:
OS Version | Default path | Filename |
---|---|---|
Win10 (1507) | C:\Windows\Logs\dosvc | dosvc.\d*.\d.etl (e.g. dosvc.1377765.1.etl) |
Win10 (1709/1803) | C:\Windows\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\DeliveryOptimization\Logs | dosvc.yyyyMMdd_HHmmss_\d*.etl (e.g. dosvc.20181111_180339_399.etl) |
On my computer running Win10 (1803), which is always On and connected to the internet 24/7, the default DoSvc log path contains each day about 140 log files. Based on what I've observed, Win10 (1803) daily removes the ETL files older than 57/58 days. In such a scenario, there may be the chance of extracting several public/external IP addresses from the logs.
Even though the log files lead in the direction of "Delivery Optimization", I think something else might be responsible for the geolocation calls. On my computer, the "Delivery Optimization" service is off. Even the "Location" service is turned off.
|
|
How to parse the logs
After some trial and error trying to figure out what was the best way to extract the data I needed from the CSV output file created by ETLParser, I found out that Win10 has a built-in Powershell cmdlet named "Get-DeliveryOptimizationLog":
- Announcing Windows 10 Insider Preview Build 17074 for PC: https://blogs.windows.com/windowsexperience/2018/01/11/announcing-windows-10-insider-preview-build-17074-pc/
This cmdlet retrieves decoded logs for Delivery Optimization. If no parameter is given, the cmdlet parses the default DoSvc path. The parameter "-Path" is required to parse other locations:
Get-DeliveryOptimizationLog -Path C:\CustomPath\*
PS> Get-DeliveryOptimizationLog | Where-Object Message -Like "*ExternalIpAddress*"
(27/Nov/2018 11:05:47) |
I also spotted the IP that I was assigned to when using CyberGhost VPN.
(24/Nov/2018 23:26:39) |
What triggered the geolocation requests? Using the two examples shown above, I searched for "ProcessId" 13104 and 36192 and noticed that some events contain the message: "Create job name = WU Client Download".
TimeCreated : 27/11/2018 11:05:47 ProcessId : 13104 ThreadId : 9952 Level : 4 LevelName : Info Message : Create job name = WU Client Download, jobId = 4d66d186-68e2-4bfc-8d74-f40de415fc20, type = 0. hr = 0 Function : CDeliveryOptimizationManager::CreateJob LineNumber : 495 TimeCreated : 24/11/2018 23:26:43 ProcessId : 36192 ThreadId : 33560 Level : 4 LevelName : Info Message : Create job name = WU Client Download, jobId = bc698001-4916-4c93-b513-cdcfe325ae9d, type = 0. hr = 0 Function : CDeliveryOptimizationManager::CreateJob LineNumber : 495
What was downloaded and probably installed by the "Windows Update" (WU) client?
PS> Get-WuaHistory | Format-Table
Get-WuaHistory is a third party cmdlet.
This seems to be the answer:
Result Date Title ------ ---- ----- Succeeded 27/11/2018 11:04:59 Definition Update for Windows Defender Antivirus - KB2267602 (Definition 1.281.899.0) Succeeded 27/11/2018 11:04:59 Definition Update for Windows Defender Antivirus - KB2267602 (Definition 1.281.899.0) Succeeded 24/11/2018 23:25:54 Definition Update for Windows Defender Antivirus - KB2267602 (Definition 1.281.756.0) Succeeded 24/11/2018 23:25:54 Definition Update for Windows Defender Antivirus - KB2267602 (Definition 1.281.756.0)
I see from my Windows Update history that Windows Defender Antivirus is updated on a daily basis. Based on the log files, it seems that "WU Client" makes a geolocation call before downloading any available update. That could explain why I have at least one geolocation response per day in the logs. Additionally, the creation time (TimeCreated) of each "GEO: response" event message always matches or is very close to the installation date of each antivirus definition update.
A hive file named "dosvcState.dat" is also involved in the process, but I haven't had the time yet to check what it contains. The hive can be found here:
C:\WINDOWS\ServiceProfiles\NetworkService\AppData\Local\Microsoft\Windows\DeliveryOptimization\State\dosvcState.dat
Scripting
I wrote a Powershell script that adapts to my needs the output provided by the mentioned cmdlet. The script adds to the output the name of the log files from which the information was extracted and shows the contents of the "Message" object in a different way. The script will generate two output files in both CSV and JSON format:
- <timestamp>_dosvc_ExtIpAddress: contains the extraction of each IP found in the ETL files;
- <timestamp>_dosvc_ip2location: contains additional details about each unique IP found like the Internet service provider, latitude and longitude. The script uses an external API.
Filenames are prepended with the timestamp of when the script was executed. To use the script, just provide the path containing the ETL files to parse:
PS> .\Get-DoSvcExternalIP.ps1 C:\LogPath
From the logs of the computer I mentioned above (Win10 - 1803), I managed to extract 124 IP addresses whose dates range from October 10th 2018 to yesterday.
I also used the script against the DoSvc ETL files that I extracted from a laptop (Win10 - 1709) that I last used in May in Las Vegas during the Magnet User Summit 2018. I connected to the Wi-Fi network in the hotel a couple of times for a short moment, but that was long enough for Win10.
This is an example of what I could extract from the logs:
PS> (Get-Content 20181205_143620_dosvc_ExtIpAddress.json | ConvertFrom-Json) | Where-Object ExternalIpAddress -eq "xx.xxx.xx.x6"
LogName : C:\TEMP\ETL_Laptop2\dosvc.20180522_170803_773.etl
TimeCreated : 22/05/2018 17:09:04 ExternalIpAddress : xx.xxx.xx.x6 CountryCode : US ProcessId : 7840 ThreadId : 776 Level : 4 LevelName : Info KeyValue_EndpointFullUri : https://kv801-prod.do.dsp.mp.microsoft.com/all Version : <omissis> Function : CGeoInfoProvider::RefreshConfigs LineNumber : 58
These are the additional details provided by the script by using an external API:
C:\> type 20181205_143620_dosvc_ip2location.json | jq
{
"as": "ASxxxxx Cox Communications Inc.", "city": "Las Vegas", "country": "United States", "countryCode": "US", "isp": "Cox Communications Inc", "lat": xx.x892, "lon": -xxx.x63, "org": "HOSPITALITY NETWORK, LLC", "query": "xx.xxx.xx.x6", "region": "NV", "regionName": "Nevada", "status": "success", "timezone": "America/Los_Angeles", "zip": "89106" },
I hope you find this long blog post useful!
You can download the script from my GitHub repository here.
[UPDATE March 31, 2019]:
the peer-reviewed version of this article can be read at DFIR Review.
[UPDATE April 5, 2019]:
I improved the script and created a "Get-DoSvcExternalIP" module for KAPE.
Thank you for posting this. Very interesting!
ReplyDelete