Opinion on rouge Chrome Updater

[Piholasimam]

I've been studying this sample on and off for a couple months now.

It was originally part of a software bundler.

I have a ton of Screenshots, .logs , and also the files themselves.

Was wondering if anyone would be able to assist me with analysis.
I will link a VirusTotal Result for a preview.

Respectfully,
Pi


VirusTotal

 

[Chimaira]

I don't think there is much to analyze. It is detected by a lot of engines on VTotal. Chromium doesn't have any installers for it like this, so this isn't official.

I wouldn't trust this.

 

[frogboy]

I think I would just get rid of it, it sure does not look safe to me.

 

[AtlBo]

What better way to pipe malware into a PC than through an "updater"? This seems like building malware writers a freeway into the system. I wouldn't keep it installed based on what you have posted and attached.

Did you want specifics on the installation registry key changes and so on? That kind of information has been hard to find for me in the past. I guess the registry is still partly the great unknown. Maybe you could make a short list of activity you have noticed from the app. I would be interested to see what it actually does...

 

[tim one]

I've quickly given a look at the VT report, and according to User32.dll import this sample also uses GetKeyState, GetKeyboardState, and SetWindowsHookEx.

Well, the GetKeyState function is the weak ring of each keylogger because this function (with GetAsyncKeyState and other) is one of the most detected by a good antivirus.
Also, GetKeyboardState and GetKeyState can only do a check on the pressure of a specific key.

That's why, in order to capture the keyboard input on system global level, it uses SetWindowsHookEx:

SetWindowsHookEx function (Windows)

In particular, see the hook WH_KEYBOARD and WH_KEYBOARD_LL.

If a WH_KEYBOARD hook is set as global, then the procedure has to be implemented in a dll.
While for WH_KEYBOARD_LL the procedures can also be implemented within a normal executable, because a context-switch is made to send the notification, but the thread that registered the hook must have its own "message loop".

 

[AtlBo]

Thanks for the post @tim one. What do you think of this comment?

"A .dll is not an executable, it's a storehouse for script or for other referenceable data"

I have been mulling this over for years, and I haven't been able to find a good discussion on how this kind of thinking might apply to interesting security concepts. My knowledge of .dlls is admittedly limited, so maybe that's why I haven't been able to resolve the thinking into something deeper.

Just have a nagging feeling that there could be an interesting way to monitor .dlls if they are considered storehouses or potentially dangerous code or script rather than an executable. Maybe an example would be to track executable associations with a .dll for patterns and then use the information in signature development or potentially even use the information for leaner monitoring...

 

[tim one]

Thanks for the post @tim one. What do you think of this comment?

"A .dll is not an executable, it's a storehouse for script or for other referenceable data"

I have been mulling this over for years, and I haven't been able to find a good discussion on how this kind of thinking might apply to interesting security concepts. My knowledge of .dlls is admittedly limited, so maybe that's why I haven't been able to resolve the thinking into something deeper.

Just have a nagging feeling that there could be an interesting way to monitor .dlls if they are considered storehouses or potentially dangerous code or script rather than an executable. Maybe an example would be to track executable associations with a .dll for patterns and then use the information in signature development or potentially even use the information for leaner monitoring...

Briefly, the main differences are:

EXE

An EXE always runs in its own address space, then it is a separate process.
The purpose of an EXE is to launch its own separate application.

DLL

A DLL always needs a host exe to run, it can never be run in its own address space.
The purpose of a DLL is to have a collection of methods / classes that can be reused by some other application.

Let's say the file format of DLL and EXE is essentially the same but Windows recognizes the difference between DLL and EXE through the PE Header in the file.

 

[AtlBo]

So a .dll contains reference data. Glad I got that part right. The code resulting from the reference is able to achieve the rights of whatever is able to reference the .dll for the data...hmmm...

I'd like to be part of a project that looked at creating a new classification of files->reference and individually broke them down into subclasses based on what might be present and so on. Kind of see where that goes. I'm sure this is part of what's done with some security programs, but it would be something I think I would like to get into at some point...

 

[tim one]

So a .dll contains reference data. Glad I got that part right. The code resulting from the reference is able to achieve the rights of whatever is able to reference the .dll for the data...hmmm...

I'd like to be part of a project that looked at creating a new classification of files->reference and individually broke them down into subclasses based on what might be present and so on. Kind of see where that goes. I'm sure this is part of what's done with some security programs, but it would be something I think I would like to get into at some point...

Every executable (EXE or DLL) that has an entry point, relied upon by the operating system immediately after loading. For a DLL, the entry point is mapped on the DllMain function (and depending, however, of the compiler).

The DllMain function is invoked, in addition to the loading (or unloading) of the DLL and when a thread is created or destroyed in the process in which the DLL resides.

Unlike an EXE file, the DLL must exit from the entry point as soon as it has finished the necessary initializations.

 

[AtlBo]

The DllMain function is invoked, in addition to the loading (or unloading) of the DLL and when a thread is created or destroyed in the process in which the DLL resides.

So would the code in a .dll running standalone as a .dll be executed via dllhost.exe or via the process (or both) or would that depend on the dll? By this I mean how is this type of .dll associated activity explained in terms of parent/child, dllhost.exe is the parent (or something else Windows) or the process that requested the .dll run is the parent? In the case of the process, I don't mean that it actually becomes the parent of a .dll (only figuratively), although I am guessing this could be true in some cases. This is if Microsoft allows .dlls to be executed as an executable->as your statements seem to indicate to me.

Really appreciate the assistance with this. Trying to sort through the details once and for all...

 

[AtlBo]

Thanks @tim one. Found what I am looking for here at Wikipedia:

Features of DLL[edit]

1. Since DLLs are essentially the same as EXEs, the choice of which to produce as part of the linking process is for clarity, since it is possible to export functions and data from either.
2. It is not possible to directly execute a DLL, since it requires an EXE for the operating system to load it through an entry point, hence the existence of utilities like RUNDLL.EXE or RUNDLL32.EXE which provide the entry point and minimal framework for DLLs that contain enough functionality to execute without much support.
3. DLLs provide a mechanism for shared code and data, allowing a developer of shared code/data to upgrade functionality without requiring applications to be re-linked or re-compiled. From the application development point of view Windows and OS/2 can be thought of as a collection of DLLs that are upgraded, allowing applications for one version of the OS to work in a later one, provided that the OS vendor has ensured that the interfaces and functionality are compatible.
4. DLLs execute in the memory space of the calling process and with the same access permissions which means there is little overhead in their use but also that there is no protection for the calling EXE if the DLL has any sort of bug.

Dynamic-link library - Wikipedia

 

[tim one]

So would the code in a .dll running standalone as a .dll be executed via dllhost.exe or via the process (or both) or would that depend on the dll? By this I mean how is this type of .dll associated activity explained in terms of parent/child, dllhost.exe is the parent (or something else Windows) or the process that requested the .dll run is the parent? In the case of the process, I don't mean that it actually becomes the parent of a .dll (only figuratively), although I am guessing this could be true in some cases. This is if Microsoft allows .dlls to be executed as an executable->as your statements seem to indicate to me.

Really appreciate the assistance with this. Trying to sort through the details once and for all...

In the end, a dll is like an exe, it contains the code, data, routines; with a small difference: the exe is designed so that its code has a beginning and a running end; the dll is not executed directly, it is just a file that contains pieces of code (functions) that other exe can "withdraw" and run.

If you consider Win32 API reference, a process has several objects: address space, execution modules , and anything that the running modules open or create. Then a process must be established by a running module, an private address space and a thread. Each process must have at least one thread. What is a thread? A thread is in reality a "run queue". When Windows creates for the first time a process, it creates only one thread per process. This thread usually begins to be executed from the first statement in the module. If the process subsequently needs more threads, it can explicitly create them. When Windows receives a command to create a process, it creates the private memory address space for that process, and then map the executable file in this space. After that, it creates the primary thread for the process.

 

[Marko :)]

The GUI of this program looks so, so familiar.

 

[tim one]

The GUI of this program looks so, so familiar.

Eh...eh..yeah!!

 

[Piholasimam]

I will add some additional information. The "adware" and i use that term loosely here because I have reason to believe it was doing much more than adding shady extensions and forcing my default browser to chromium. I can get into that later if need be.

I'd like to understand why this program was so difficult to remove. I was interesting the way it operated, going to great lengths to conceal itself. Only manifesting in the form of the update window, and leaving very little trace of itself. Its admittedly a long story, but ultimately I was able to isolate and extract it to a flash drive for analysis on a virtual machine.

I actually was the first one to submit it to Virustotal on 2017-12-22.

I will leave some more interesting screenshots if anyone is interested about anything particular, I would be happy to provide more info.

 

[Deleted member 65228]

[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\div_child.dll
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting Begin path C:\Program Files (x86)\html\div\Application\1.0.0.0\div_elf.dll
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\d3dcompiler_43.dll
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\d3dcompiler_46.dll
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\default_apps
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\delegate_execute.exe
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\Extensions
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\ffmpegsumo.dll
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\icudtl.dat
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\libegl.dll
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\libexif.dll
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\libglesv2.dll
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\libpeerconnection.dll
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\Locales
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\metro_driver.dll
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\mksnapshot.ia32.exe.assert.manifest
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\nacl64.exe
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\nacl_irt_x86_32.nexe
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\nacl_irt_x86_64.nexe
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\pdf.dll
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\PepperFlash
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\pphtmlnaclplugindiv.dll
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\resources.pak
[0607/195454:WARNING:uninstall_class.cpp(568)] Deleting install path C:\Program Files (x86)\html\div\Application\1.0.0.0\widevinecdmadapter.dll

If it's any consolation, I do recognise some of the file-names in the above log. For example: d3dcompiler_43.dll, d3dcompiler_46.dll, icudtl.dat, libegl.dll, libglesv2.dll, resources.pak. It doesn't mean any of the file-names I recognise are actually the same components I am thinking of, people can lie on file-names.

d3dcompiler_43.dll and d3dcompiler_46 file-names -> Direct3D API.

libegl.dll and libglesv2.dll is either Direct3D or Angle.

There's links between the log report you shared and other Adware from the past, see here: BingAdwareHelpMe - Pastebin.com

resources.pak likely stores content packed inside of it, I only know of *.pak usage since I've had to do it before when dealing with web-based UI frameworks like the Chrome Embedded Framework. It is indeed possible that this rogue Chrome updater is relying on a web-based UI, but without further investigation you won't know.

I don't think any of us here can download samples directly from VirusTotal so providing us the VirusTotal link and not the actual sample won't get you anywhere asking for help on analysis.

However, as others have already said, the VirusTotal results speak for themselves. It's quite clear most vendors believe it to be adware - you also mentioned it is from a software bundler. There's likely not much point progressing further, I doubt all of those detection's are FPs and given the initial screenshots you attached, the likelihood of the detection's being FPs are like 0.0000001%/100000000000000000000000000000000000000.

In regards to SetWindowsHookExA/W imported by user32.dll, it doesn't necessarily mean the sample has a keylogger component embedded within it. The routine is used by Windows itself for functionality such as the shake effect when you drag a window's Win32 title-bar quickly and other windows automatically become minimised. The same applies to other Win32 API routines from User32.dll and other modules. The imports of a binary can provide insight sometimes but it won't be accurate alone most of the time. You'll need to check the actual binary statically/dynamically. Try checking the references to the routine in a disassembler like IDA and you'll be given more information regarding how it is used and if it is actually used for malicious intent for activity like a keylogger; it's very well possible it is, but you'll need to dig a tad deeper say on case it isn't.