While installing/testing neovim in a Windows 11 sandbox environment for security testing purposes before deploying in a commercial environment, the bundled tee.exe binary was classified as Trojan.M...
The tee utility and its expected behavior is fairly well-documented and known. I cannot find any justifiable explanation for this behavior.
The commit history shows that this binary was committed to the neovim/deps repo ~2 years ago via neovim/deps@21c5e8b and that's where it's being sourced from when building neovim. Given this behavior, I'm inclined to suggest a root cause analysis should be performed and insist that this binary along with the others in the deps repo should be built from source.
Read the original article
Comments
By mike_d 2025-02-148:04 I forced a refresh of the VirusTotal results. It is only being flagged by a single engine: MaxSecure, an Indian anti-virus vendor that has gone out of business.
https://www.virustotal.com/gui/file/950eea4e17fa3a7e89fa2c55...
By likeabatterycar 2025-02-147:132 reply Probably Windows checking certificate revocation on a signed binary (or linked library).
Yeah, I'm inclined to agree. The binaries were probably built by mingw and I've seen "hello world" get flagged by virus total when built by mingw.
If it is the binary itself making those calls (and not the OS), then anyone with a little bit of reverse engineering experience should be able to prove it and post the assembly.
Edit: I was wrong about the build toolchain, they were built by visual studio, see comment below.
By retsl 2025-02-148:10 the virustotal report shows the output from detectiteasy in "Details" -> "Basic properties": DetectItEasy PE64 Compiler: Microsoft Visual C/C++ (19.14.26715) [C++] Linker: Microsoft Linker (14.00.24241) Tool: Visual Studio (2015)
this is not meant to imply anything about whether the binary is malicious or not.
By likeabatterycar 2025-02-147:231 reply > It is absolutely not that. To suggest this, considering the evidence posted, goes beyond idiocy into potential maliciousness
The scary IPs are part of DigiCert's CDN for OCSP responder (probably depending where you are and their anycast):
https://github.com/hoshsadiq/adblock-nocoin-list/issues/452
The "evidence" is the system made some network calls and DNS lookups. Which you know, you would do when validating a certificate. He also lists some SMB calls to the localnet which are clearly unrelated. tee.c source contains no network code so this would be truly easy to audit. So tell me again what is the damning evidence?
Also, are we to believe malware gangs are hosting on Akamai now? They must be in the major leagues.
And you call me an idiot?
Have a nice day.
By j16sdiz 2025-02-1411:08 Thanks for your research.
Random googling shows lots of people have similar question, and most of time the tread just die out without answer.
phicdn.net as a privacy-protected domain from godaddy sure make the case more suspicious.
DigiCert (or whatever the owner piecdn is) could have save us lots of time just publishing that information on their website.
By readthenotes1 2025-02-146:551 reply The potentially malicious IP is owned by akamai. Not sure why tee would want to talk out
By likeabatterycar 2025-02-148:01 It's not.
This is almost certainly Windows performing certificate validation.
The "evidence" was just copy pasted from VirusTotal. In fact he forgot to copy from below the cut, which would have shown it also called out to www.microsoft.com - depending who you ask, definitely a malicious address!
VirusTotal just notes all network traffic during the time the binary executed in the sandbox. It doesn't mean it emanated from the binary.
