False Positive? settings-win.data.microsoft.com resolving to Microsoft Blackhole IP

Published: 2015-05-19
Last Updated: 2015-05-19 20:36:01 UTC
by Johannes Ullrich (Version: 1)
4 comment(s)

Thanks to Xavier for bringing this to our attention. It looks a couple of days ago, a legitimate Microsoft host name, settings-win.data.microsoft.com started to resolve to a Microsoft IP that is commonly used for blackholes that Microsoft operates:

$ host settings-win.data.microsoft.com
settings-win.data.microsoft.com is an alias for settings.data.glbdns2.microsoft.com.
settings.data.glbdns2.microsoft.com is an alias for blackhole6.glbdns2.microsoft.com.
blackhole6.glbdns2.microsoft.com has address 131.253.18.253

Connecting to a blackhole IP like this is often an indicator of compromise, and many IDS's will flag it. For example:

[**] [1:2016101:2] ET TROJAN DNS Reply Sinkhole - Microsoft - 131.253.18.0/24 [**] [Classification: A Network Trojan was detected] [Priority: 1] ...

It is not yet clear what process causes the connect to this IP on port 443. But a number of other users are reporting similar issues. For example, see here:

https://social.technet.microsoft.com/Forums/windowsserver/en-US/37aecee6-0df9-4234-8159-c632070478ad/strange-dns-requests-blocked-by-ips?forum=winserversecurity

At this point, I am assuming that this is some kind of configuration error at Microsoft.

---
Johannes B. Ullrich, Ph.D.
STI|Twitter|LinkedIn

Keywords:
4 comment(s)

Comments

I have also seen the same type of detection and according to the analysis, it was DiagTrack service which is trying to communicate to this IP range (131.253.18.0). Recently released MS patch KB: 3022345 is associated with this, doubt it might be reason for this false positive.

KB detail: This update enables the Diagnostics Tracking Service in Windows 8.1, Windows Server 2012 R2, Windows 7 Service Pack 1 (SP1), and Windows Server 2008 R2 SP1. This tracking service collects data about functional issues in Windows.

But some confirmation from Microsoft is still pending.
Emerging threads rule has been updated a few hours ago!

old: alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"ET TROJAN DNS Reply Sinkhole - Microsoft - 131.253.18.0/24"; content:"|00 01 00 01|"; content:"|00 04 83 fd 12|"; distance:4; within:5; classtype:trojan-activity; sid:2016101; rev:2;)
new: alert udp $EXTERNAL_NET 53 -> $HOME_NET any (msg:"ET TROJAN DNS Reply Sinkhole - Microsoft - 131.253.18.11-12"; content:"|00 01 00 01|"; content:"|00 04 83 fd 12|"; distance:4; within:5; byte_test:1,>,10,0,relative; byte_test:1,<,13,0,relative; threshold: type limit, count 1, seconds 120, track by_src; classtype:trojan-activity; sid:2016101; rev:6;)

Xavier
I haven't seen any new hits after updating my rules. I had 20+ hosts hitting the sink hole yesterday, ranging from Server 2012, Windows 7, Windows CE. None of them had Skype for Business, and only a few had Office 2010.
This is initiated by the process dmclient.exe.

From the MS website "https://msdn.microsoft.com/en-us/library/dn904951(v=vs.85).aspx": "The DMClient configuration service provider is used to specify additional enterprise-specific mobile device management configuration settings for identifying the device in the enterprise domain, security mitigation for certificate renewal, and server-triggered enterprise unenrollment."

I see this on a regular basis on Windows 8.1 and Windows 10 machines that are not on a domain.

Diary Archives