- Feb 25, 2017
- 2,504
Malware/PUA listed as clean (again)
- Thread starter Sandbox Breaker
- Start date
- Feb 7, 2023
- 1,737
But it is malicious.
- Jan 6, 2022
- 435
You learn something every day. Didn't know that.
- Sep 2, 2021
- 2,309
Yep, but since it does all this in 2/3sec, I don't have time to look with my little eyes xD
- Feb 7, 2023
- 1,737
Yep, but since it does all this in 2/3sec, I don't have time to look with my little eyes xD
There is InstallExtension.exe which adds the suspicious browser extension.
- Jan 6, 2022
- 435
- Feb 7, 2023
- 1,737
Because I’ve seen what people like @struppigel can do with files and in not extremely long time. There is no way analyst will not see the suspicious extension that is being added.
- Jan 6, 2022
- 435
Maybe they actually didn't. That's the sad state of affairs today. It's so unbelievable.
- Sep 2, 2021
- 2,309
- Feb 25, 2017
- 2,504
True. I love it so far. Fast static and dynamic analysis and a detailed but yet pretty compact report.
- Jan 6, 2022
- 435
And it's free. I remember them charging for it before.
- May 31, 2017
- 1,662
- Feb 25, 2017
- 2,504
- Feb 7, 2023
- 1,737
@danb might be a bit off-topic but it took me a minute to discover the “Get Second Opinion” link on the screenshot. Maybe having it underlined or blue or something might help
- Feb 25, 2017
- 2,504
Stumbled upon Yomi the other day and the sample got a 10 out of 10 malscore rating. Anybody heard of it?
A while ago, I assisted someone in removing something similar. Resetting the browser didn’t solve the issue, and removing the extension from the browser also proved ineffective. The problem persisted because there were some files in the C:\ProgramData folder (if I recall the location correctly) that kept reinfecting the browser, particularly a .bat file. The detection rate was quite low; I believe I used GData(detected by their engine, not the BD engine) + FRST.Surprisingly, Malwarebytes, Eset, BD, and others didn’t detect iT.After, I sent the entire folder to BD, a detection was added....
I've used Yomi before, nothing special really...
- Apr 9, 2020
- 656
Whatever this file is, it seems to be unfinished. It is an innosetup installer with an InstallExtension.exe inside and some JS code for the extension itself.
The extension pretends to be named Google docs, which in itself is reason enough to detect it as malicious because the intent is clear. This is the manifest:
However, it does not do much. This is service.js:
And this is web.js:
The InstallExtension.exe will schedule a task named "GoogleUpdate" (clear malicious intent) but the task's command is empty:
Anything else you see in the sandbox behavior, is also nothing malicious there. The processes for VC_redist.x64.exe are C++ redistributables. The Batch file does some preparation for the extension.
---------------------------
tl;dr Whatever this thing is meant to be---at current state it looks more like unfinished malware.
Nevertheless, it cannot be determined as clean. I would detect it as malware if that was my case.
---------------------------
I agree this sample is pretty obvious, but we sometimes also report and discuss files with other companies. It is my experience that those things also happen with human analysts, even if the file is obviously malware. This happens when there is a mixture of: lack of experience, lack of support in the work place, lack of quality checks and too much time pressure. Especially the last item has a bad effect on the analysis quality since analysis of one sample can range from 10 minutes to several months depending on how challenging the sample is.
So whenever analysts get pressured into, e.g., analysing 5 samples per day, they will have to resort to guessing for some samples if they do not make it in time. Forming a verdict based on guesses only is bound to fail.
I actually had the case where we sent in an FP to a company (not naming the company here), and the analyst stated the sample is malicious. We asked what malicious behavior they observed and they actually made up some behaviour, claiming it is a backdoor.
I had unpacked the sample and all it did was some innocent checks on a server. So we send the unpacked script to them including unpacking instructions and afterwards this company also said the file is clean. I assume the analyst was not able to unpack it in the given time frame and resorted to this verdict because other AV vendors had detections on the file.
This is not necessarily the analysts fault. If the situation does not permit investigating deeper, what are you gonna do? Or if you are new on the job do not feel you can ask anyone for help? It is one of the reasons we established a "Bring your sample" session at our workplace, where anyone can bring samples they have difficulties with or find challenging or where they learnt something that they want to show others.
The extension pretends to be named Google docs, which in itself is reason enough to detect it as malicious because the intent is clear. This is the manifest:
However, it does not do much. This is service.js:
And this is web.js:
The InstallExtension.exe will schedule a task named "GoogleUpdate" (clear malicious intent) but the task's command is empty:
Anything else you see in the sandbox behavior, is also nothing malicious there. The processes for VC_redist.x64.exe are C++ redistributables. The Batch file does some preparation for the extension.
---------------------------
tl;dr Whatever this thing is meant to be---at current state it looks more like unfinished malware.
Nevertheless, it cannot be determined as clean. I would detect it as malware if that was my case.
---------------------------
I agree this sample is pretty obvious, but we sometimes also report and discuss files with other companies. It is my experience that those things also happen with human analysts, even if the file is obviously malware. This happens when there is a mixture of: lack of experience, lack of support in the work place, lack of quality checks and too much time pressure. Especially the last item has a bad effect on the analysis quality since analysis of one sample can range from 10 minutes to several months depending on how challenging the sample is.
So whenever analysts get pressured into, e.g., analysing 5 samples per day, they will have to resort to guessing for some samples if they do not make it in time. Forming a verdict based on guesses only is bound to fail.
I actually had the case where we sent in an FP to a company (not naming the company here), and the analyst stated the sample is malicious. We asked what malicious behavior they observed and they actually made up some behaviour, claiming it is a backdoor.
I had unpacked the sample and all it did was some innocent checks on a server. So we send the unpacked script to them including unpacking instructions and afterwards this company also said the file is clean. I assume the analyst was not able to unpack it in the given time frame and resorted to this verdict because other AV vendors had detections on the file.
This is not necessarily the analysts fault. If the situation does not permit investigating deeper, what are you gonna do? Or if you are new on the job do not feel you can ask anyone for help? It is one of the reasons we established a "Bring your sample" session at our workplace, where anyone can bring samples they have difficulties with or find challenging or where they learnt something that they want to show others.
Last edited:
@Sandbox Breaker if you have more interesting samples, please share them with us
- Oct 16, 2022
- 110
Just to update everyone in this thread, I ran the file in question in a virtual machine with Comodo installed, and even though it did let it install, an executable named "InstallExtension" was called that right away was blocked by the real-time AV component
perhaps the file that was designed to drop a malicious executable after it installs, is not being classified by Comodo.. now there are ways to look at this; one may argue that the installation should have been blocked, although the installation per se is essentially harmless
another viewpoint would be that although the piece of code was executed, its malicious actions later were blocked if indeed, it was malicious but either way, at the end of the day, Comodo successfully did NOT let the system get infected
I have attached the relevant screenshots just in case, and the system is absolutely clean. Comodo did well in my view
perhaps the file that was designed to drop a malicious executable after it installs, is not being classified by Comodo.. now there are ways to look at this; one may argue that the installation should have been blocked, although the installation per se is essentially harmless
another viewpoint would be that although the piece of code was executed, its malicious actions later were blocked if indeed, it was malicious but either way, at the end of the day, Comodo successfully did NOT let the system get infected
I have attached the relevant screenshots just in case, and the system is absolutely clean. Comodo did well in my view
Attachments
Last edited:
Similar threads
