mob
mob copied to clipboard
remotemobprogramming
Virusdetection on mob.exe
Today, my Windows BitDefender detected the trojan Script/Wacatac.H!ml in mob.exe version 4.1.2. Using the current mob.exe from https://github.com/remotemobprogramming/mob/releases/download/v4.1.2/mob_v4.1.2_windows_amd64.tar.gz and feeding the included mob.exe into www.virustotal.com leads to:
Any ideas on that?
I assume its a false positive. Did more checks
4.1.1:
3.2.0:
2.0.0:
1.12.0:
Initial Release:
However, you might want to scan your system for further "Script/Wacatac.H!ml". Since your system detected it on your mob.exe, but VirusTotal which also uses BitDefender did not.
I made a false positive report on the BitDefender Site with the Link to this Archive: https://github.com/remotemobprogramming/mob/releases/download/v4.1.2/mob_v4.1.2_windows_amd64.tar.gz Hoping it will resolve.
Tried reporting Kaspersky, but they found nothing https://opentip.kaspersky.com/5E1BC52F7811C3C95A5D8872A6868F975FFC8F81B00B6DFBF3A8B5449110FE44/results?tab=upload
Now, virustotal reports 14/71.
I can see how, given the nature of mob, heuristics fail. However, not having to "allowlist" tools within AV solution, avoids a lot of discussion. I hope AV vendors quickly adjust their databases.
I released v4.2.0 and its flagged by 5 Vendors including Kaspersky
Again I submitted a false positive report on Kaspersky, but their Threat Intelligence Portal analyzed the File for 3 minutes and says its clean ... I'm confused. https://support.kaspersky.com/common/error/other/1870#:~:text=If%20you%20suspect%20a%20false,reanalyze%20on%20the%20results%20page.
Bitdefender Total Security just flagged mob.sh as a trojan
I installed the latest mob.sh just in case. Same issue.
Thoughts?
Thank you @soulpatch I don't know why. I think there must be some signature in the exe that is marked as trojanic. However, I don't know of any trojanic code in our codebase. I also don't see a way how our pipeline could inject such code. So I believe that it is a false positive. I did report the archive as false positive on the Bitdefender Homepage.
The actual version of mob looks better again. Just three less used scanners flagged it. https://www.virustotal.com/gui/file/a38b60335beeace00264405589321adb9666148c2a18c44bb90aca0625dc7ef7
I reached out to cylance and told them about the false positive. Waiting for response now.
One thing we could do is to add a virus total build step to our release and use the vt monitor to announce our executables to virustotal. This could prevent false positives.
Any update on this @hollesse? More vendors are classifying mob as malicious (note note that the following hash pertains to the Windows v4.4.2 executable):
I think I've identified some of the suspicious components of the executable. Please get in touch over email if you'd like to discuss this.
Hi @hollesse, so sorry that I missed this in October! I have responded to you via email. I think I've managed to identify a couple of big problems with the build.
So I had a lot to do the last days, but I got the email from @jakewilliami and also spoke to an security and go expert in my company. To be transparent I just will share the email from @jakewilliami here.
Hi Joshua, I’m so sorry I missed your email from October!
I have access to a sandbox through an AV product and have run the Windows executable of mob.exe through it.
Static analysis of the file does not identify much suspicious, which indicates that it’s the behaviour of the executable that is being classified as malicious.
I don’t know if you’ve heard of the MITRE ATT&CK framework but it is a classification framework to identify malicious digital behaviours. From dynamic analysis of the executable (enriched with attributes from the static parser) we can glean what behaviours are being classed as malicious.
The structure of the framework is hierarchical: tactic, technique, subtechnique. We have the following tactics, techniques, possible subtechniques, and a brief explanation of why they might be identified as such: Execution Native API Import suspicious APIs (relevance: 1/10): GetSystemInfo, LoadLibraryW, LoadLibraryA, GetProcAddress, GetThreadContext, CreateThread, WriteFile, GetSystemDirectoryA, CreateFileA, VirtualAlloc Defense Evasion Obfuscated Files or Information Subtechnique: Software Packing PE file contains unusual section name (relevance: 10/10): mob.exe has sections named “/4”, “/19”, “/32”, “/46”, “/65”, “/78”, “/90”, and “.symtab”. This might be seen as obfuscation PE file has unusual entropy sections (relevance: 3/10): sections “/19”, “/32”, “/65”, “/78”, and “/90” have unusual entropies (higher entropy can indicate packed data) Discovery Process Discovery Queries process information (relevance: 4/10): queries SystemProcessInformation Query Registry Monitors specific registry key for changes (relevance: 4/10): the executable monitors HKLM\SOFTWARE\Microsoft\Ole, REGISTRY\USERS<SID>\Local Settings\Software\Microsoft, and HKLM\SYSTEM\ControlSet001\Services\WinSoc2\Parameters\NameSpace_Catalog5 System Information Discovery Found system commands related strings (relevance: 3/10): found string “Hostname” (related to system command “hostname”) Another behavioural threat indicator that was not classified within the ATT&CK framework is that Wine emulator-related strings (“wine_get_version”). This attribute is classed as malicious, yet it only has a 2/10 rating in terms of relevance.
Finally, the other HUGE red flag when looking at malware is the creation time. The PE header has a creation time of the start of Epoch time, which is very common for ransomware!
This is a lot so let me help you to focus on the attributes that are most relevant to the suspicious outcome: PE file contains unusual section names (relevance: 10/10) Time stamp in PE header is very old (relevance: 10/10) Wine emulator strings in data (2/10) Perhaps addressing these three (especially the former) might change the outcome of AV systems. If you make some changes, let me know and I can run it through the sandbox again.
It seems like the main cause for concern is that the format of the executable for Windows is packed in a way that might be indicative of obfuscation, as well as a few other odd PE attributes. Can you explain to me how this executable is built, and if this is non-standard? I would expect to see more alerts for Go applications if it was a Go problem, so it might be the way that mob is being built. It is very non-standard for the PE header creation time to be at 0 Epoch. It might also be worth looking into the Wine emulator related string, and reviewing why this is needed. Can you use a Wine API instead?
Unfortunately I don’t know much about how to fix these issues, but let me know if you have any other questions and I can certainly try to assist. Often it’s difficult to translate these lower level attributes into higher level changes, but let me know how you get on. But in short, first thing you should do is review the build system and fix that system time problem. Let me know once that’s done and we can review again.
Let me know also if this is an issue on other operating systems. Hope this helps.
Best as ever, Jake
Now let me just answer it here right away. What I think an found out. First of all I got the recommendation from one of our security experts in the company to just pack the exe with UPX Packer, as even a hello world in Go sometimes is identified as malware by some anti virus detection applications. Thats something we should try and which could maybe help with the creation time of the exe and also with the software packing issues and the PE file.
Some other things that come to my mind is the feature that the mob timer gets stopped when doing mob done. Which is done by killing the process. I think this is also something we should stop doing, as this looks like malicious behavior.
The string hostname is used for timer.mob.sh maybe it makes sense to adjust it to a better name, if hostname is supisious.
Where the wine emulator string come from is not clear to me. Here is futher investigation needed.
I will create some Issues for the steps and link them here.
Just found this thread. My security colleage also told me that even just a hello world in GO gets flagged by some scanners. One thing which is written in the comments is that it should have gotten worse with newer version than GO 1.16. I did update the go version from 1.15 to 1.20 on 26th may 2023. But the first hints we where getting where already before this. But at least the process killing was already done in the end of 2022 maybe this was the first hit and then the new go version adds more hits...
I found one more thing we should change. I introduced the test package. This package is not just test code and therefore is bundled into the app. Even if it is not used. This package uses system APIs to write files etc which could also be suspicious. We should make this package test only. This small adjustment can also have an impact on the virus detection.