Malware Analysis Malware/PUA listed as clean (again)


Level 36
Top Poster
Feb 25, 2017
It starts an installation and closes
I think it does more than that:

Screenshot 2023-06-28 182752.png


Level 8
Mar 24, 2016
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....


Staff Member
Apr 9, 2020
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.


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.

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:


Level 3
Oct 16, 2022
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


  • 1.png
    219.1 KB · Views: 91
  • 2.png
    151.3 KB · Views: 82
Last edited:

About us

  • MalwareTips is a community-driven platform providing the latest information and resources on malware and cyber threats. Our team of experienced professionals and passionate volunteers work to keep the internet safe and secure. We provide accurate, up-to-date information and strive to build a strong and supportive community dedicated to cybersecurity.

User Menu

Follow us

Follow us on Facebook or Twitter to know first about the latest cybersecurity incidents and malware threats.