search

git-for-windows / git

A fork of Git containing Windows-specific patches.
http://gitforwindows.org/
Other
8.26k stars 2.5k forks source link

dd.exe: suspicious IP traffic #4841

Closed ruslanbay closed 6 months ago

ruslanbay commented 6 months ago

Setup

Details

If you extract the PortableGit-2.44.0-64-bit.7z.exe\usr\bin\dd.exe file and check it in Virustotal, the "behavior" section shows connections to the following addresses:

192.229.211.108:80 (TCP)
20.69.140.28:443 (TCP)
20.99.133.109:443 (TCP)
20.99.185.48:443 (TCP)
23.216.147.76:443 (TCP)
23.35.98.25:443 (TCP)
a83f:8110:3048:400:a0:4904:0:104b:53 (UDP)

This is surprising for a command that is meant to work with local files. Is this expected behavior? https://www.virustotal.com/gui/file/fc825633d2b831517253092a1e4a10b5b68452ba3a2af0b5f2a5a0d2c180a752/behavior

dscho commented 6 months ago

I suspect a false positive, as is the case so often with VirusTotal. I appended a single LF character to the .exe file (which still lets it work identically) and uploaded it here: https://www.virustotal.com/gui/file/2aa1af813d52d36b3f4966c75b337a777116021d3911c97489d9e3a26a6874ab/behavior. As you can see, the list is now slightly different:

192.229.211.108:80 (TCP) 20.99.133.109:443 (TCP) 20.99.186.246:443 (TCP) 23.216.147.76:443 (TCP) a83f:8110:0:0:a800:0:0:0:53 (UDP)

The first IP seems to be consistent, the others not so much. According to https://www.whois.com/whois/192.229.211.108, the first one belongs to Edgecast, and according to https://www.whois.com/whois/20.99.133.109 the second one to Microsoft. I've seen a similar pattern before, in an unrelated project, and suspect concurrent processes to be caught in the fire by mistake.

To verify this even better, I uploaded the preceding dd.exe version (see https://github.com/git-for-windows/git-sdk-64/commits/HEAD/usr/bin/dd.exe): https://www.virustotal.com/gui/file/165f7a6772c2347005825feb66bc6f6de5e19465e7cf81edbb9f079e279b4a79/behavior shows no IP traffic. But I suspect that this is because someone uploaded the same file before me, and it was analyzed earlier. So I did the same thing here as with the newer dd.exe: append a single LF character and upload that. The result: https://www.virustotal.com/gui/file/c5a85f5cb7e66d6e21c4dc5eb839e84c67ff229b15185c33ee5503c200ff2d45/behavior. With that list:

IP Traffic 192.229.211.108:80 (TCP) 20.99.184.37:443 (TCP) 20.99.185.48:443 (TCP) 20.99.186.246:443 (TCP) 23.216.147.69:443 (TCP)

Spot the pattern? So how come that virtually the same executable has no issue a month ago, but now calls out to http/https servers? This sounds more like a problem with the test setup, and reinforces once again that every time I receive a report about a potential infection of the executables in Git for Windows, it costs me a lot of time only to find out that the report is based on a bogus analysis.

dscho commented 6 months ago

I appended a single LF character to the .exe file

FWIW I used that trick only to force VirusTotal to re-analyze the file (because the "Reanalyze" link only re-runs the test on the "Detection" tab, but not those on the "Behavior" tab).

exoosh commented 6 months ago 
$ for i in 20.69.140.28 20.99.133.109 23.216.147.76 23.35.98.25 192.229.211.108 20.99.184.37 20.99.185.48 20.99.186.246 23.216.147.69; do whois "$i"|grep ^OrgName:; done
OrgName:        Microsoft Corporation
OrgName:        Microsoft Corporation
OrgName:        Akamai Technologies, Inc.
OrgName:        Akamai Technologies, Inc.
OrgName:        Edgecast Inc.
OrgName:        Microsoft Corporation
OrgName:        Microsoft Corporation
OrgName:        Microsoft Corporation
OrgName:        Akamai Technologies, Inc.

It's not so clear from the output over on VirusTotal that the network communication was caused by this process. wuapihost.exe also got started and would have much more of a business causing this sort of traffic to Microsoft-related IP addresses. These would usually only show connections established by the overall sandbox.

It shows:

Processes created

PS: you can literally see that same behavior shown for the VT sandbox all over the web (example). And C:\Windows\System32\wuapihost.exe -Embedding is exactly what we're seeing here. wuapi as in Windows Update API.

ruslanbay commented 6 months ago

I noticed that IP traffic is only shown in the Microsoft Sysinternals sandbox results. I know that the listed IPv4 addresses are used in Windows to communicate with Microsoft services. These subnets are blocked by my firewall. My attention was drawn to a request for IPv6 a83f:8110:3048:400:a0:4904:0:104b:53 I could not find any information about it on the Internet. I use Virustotal to scan any files from the internet and this is the first time I've seen this behavior. Now I think this request probably has nothing to do with dd.exe. I have sent a request to Virustotal support and asked them to look into Microsoft sandbox reports.

I appreciate your support and I'will put more effort into diagnosis on my side next time. Thank you.

diegocr commented 6 months ago

Well, dd.exe does not access network libraries, so just by that we can tell that IP traffic doesn't comes from it (?)

240929142827

However, kernel32.dll though rpcrt4.dll does access ws2_32.dll, but given the list of imports (the first three entries) it doesn't seem to go that path...

240929144442

It is worse when you do stumble on something like this. 👀

dscho commented 6 months ago

My attention was drawn to a request for IPv6 a83f:8110:3048:400:a0:4904:0:104b:53 I could not find any information about it on the Internet.

Port 53 is DNS. That's probably the IPv6 of the DNS server used in the sandbox.