Closed ruslanbay closed 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.
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).
$ 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:
%SAMPLEPATH%\dd.exe
%SAMPLEPATH%\fc825633d2b831517253092a1e4a10b5b68452ba3a2af0b5f2a5a0d2c180a752.exe
C:\Windows\System32\wuapihost.exe
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.
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.
Well, dd.exe
does not access network libraries, so just by that we can tell that IP traffic doesn't comes from it (?)
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...
It is worse when you do stumble on something like this. 👀
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.
Setup
PortableGit-2.44.0-64-bit.7z.exe
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: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