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

[SeriousHoax 87]

21 minutes ago, itman said:

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.

It would've been easier to deny CertUtil.exe execution all together if Eset had support for wildcards in HIPS. I know you asked for it many times but not gonna happen sadly.

[SeriousHoax 87]

6 minutes ago, itman said:

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

New Wiper Malware impersonates security researchers as prank

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

And these will most definitely bork your OS installation:

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

Hmm tested ESET against this malware. ESET failed, whole system lockdown.

[itman 1,801]

8 minutes ago, SeriousHoax said:

It would've been easier to deny CertUtil.exe execution all together if Eset had support for wildcards in HIPS.

No, because it is used legitimately by the OS and apps. Additionally if you want to verify a cert. chaining path, the OS will dial-out to the cert. originator web site for verification. This is because not all certs. reside in the Window CA store.

Edited April 13, 2020 by itman

[Marcos 5,450]

5 minutes ago, SeriousHoax said:

Hmm tested ESET against this malware. ESET failed, whole system lockdown.

It would be interesting to know where you got the sample from since even Lawrence could not get hold of it:

If you have been infected and know where you downloaded the file, please submit a sample here or contact us on Twitter with the site you downloaded the file.

Please provide SHA1 of the sample and submit it to samples[at]eset.com. You can share it with Lawrence as well.

[SeriousHoax 87]

6 minutes ago, Marcos said:

It would be interesting to know where you got the sample from since even Lawrence could not get hold of it:

If you have been infected and know where you downloaded the file, please submit a sample here or contact us on Twitter with the site you downloaded the file.

Please provide SHA1 of the sample and submit it to samples[at]eset.com. You can share it with Lawrence as well.

I shared the sample to Eset's sample submit email few hours ago. Just now submitted to Lawrence also.

Here's the SHA1: CAA76AE5CA56541DF4776A4E0667AD3948048757

[SeriousHoax 87]

8 minutes ago, itman said:

No, because it is used legitimately by the OS and apps. Additionally if you want to verify a cert. chaining path, the OS will dial-out to the cert. originator web site for verification. This is because not all certs. reside in the Window CA store.

Ohh didn't know that. I created rules to block it in OSA. Let's see when I get a block.

[itman 1,801]

As far as MBR modification by malware, it's time Eset takes a look at incorporating  Cisco's MBRFilter code which is open source at Github.

An alternative is to backup the MBR at Eset installation time. Then provide a Tools option to restore it when needed.

[itman 1,801]

33 minutes ago, SeriousHoax said:

Here's the SHA1: CAA76AE5CA56541DF4776A4E0667AD3948048757

Here's the Hybrid-Analysis detail on it: https://www.hybrid-analysis.com/sample/4cd23a989a8f196b1f49e5e66c6ecfa0cebf63f04950ae4d64127aaedda9e89c?environmentId=120 .

It's writing the following to the startup directory, %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\sentinelone.scr. Suspect this trashes the MBR at boot after forced shutdown.

Also there's an an outbound connection. So assume a remote download payload. -EDIT- Yes, sentinelone.scr performing outbound connection: https://www.virustotal.com/gui/file/4cd23a989a8f196b1f49e5e66c6ecfa0cebf63f04950ae4d64127aaedda9e89c/behavior/VenusEye Sandbox

Edited April 13, 2020 by itman

[itman 1,801]

Personally, I am tired with what I am seeing here.

Sometime ago, I performed my own testing in regards to Eset's monitoring of %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup. I created a .lnk reference to an .exe which BTW is the oldest trick "known to malware mankind" that ran w/o issue. I subsequently had a long PM conversation with Eset about this to apparently no avail.

Now I do monitor write activity to this directory via Eset HIPS rules. But in some convoluted fashion since the "stone age" HIPS won't allow me to do so properly by wildcard specification; e.g. *.lnk, etc..  

[SeriousHoax 87]

17 minutes ago, itman said:

Personally, I am tired with what I am seeing here.

Sometime ago, I performed my own testing in regards to Eset's monitoring of %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup. I created a .lnk reference to an .exe which BTW is the oldest trick "known to malware mankind" that ran w/o issue. I subsequently had a long PM conversation with Eset about this to apparently no avail.

Now I do monitor write activity to this directory via Eset HIPS rules. But in some convoluted fashion since the "stone age" HIPS won't allow me to do so properly by wildcard specification; e.g. *.lnk, etc..  

With * rule if a new file is created eg: a notpad file then the HIPS rule works but .lnk doesn't created by apps doesn't work 😒

[itman 1,801]

So how did this malware pull this off?

Quote

Writes a file to the start menu

details

"4cd23a989a8f196b1f49e5e66c6ecfa0cebf63f04950ae4d64127aaedda9e89c.exe" wrote to file "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\sentinelone.scr"
"<Input Sample>.exe" wrote to file "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\sentinelone.scr"
"<Input Sample>.exe" wrote to file "%APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\sentinelone.scr:Zone.Identifier"

Ref.: https://fileinfo.com/extension/zone.identifier

 

 

 

Edited April 13, 2020 by itman

[itman 1,801]

10 minutes ago, SeriousHoax said:

With * rule if a new file is created eg: a notpad file then the HIPS rule works but .lnk doesn't created by apps doesn't work 😒

We discussed this previously via PM.

First, you can't create a HIPS rule blocking for example, %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\*.* because there are legit hidden files in that directory that the OS constantly updates.

[SeriousHoax 87]

1 hour ago, itman said:

We discussed this previously via PM.

First, you can't create a HIPS rule blocking for example, %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\*.* because there are legit hidden files in that directory that the OS constantly updates.

Hmm I tested it after you told me that .lnk doesn't work. I still have a rule created but got no alert yet.

[itman 1,801]

39 minutes ago, SeriousHoax said:

Hmm I tested it after you told me that .lnk doesn't work. I still have a rule created but got no alert yet.

Are you monitoring write activity to %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\*.*? If you're monitoring program startup activity, none be detected for a .lnk file since it is just a shortcut to the actual .exe location.

Also if your monitoring write activity to %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\*.*, you have to allow write activity to hidden OS .ini files there. Finally, you just can absolutely block anything written to %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\*.* since legit apps and even the OS may do so although I have yet to find anything that does other than the .ini files mentioned.

 

Edited April 13, 2020 by itman

[SeriousHoax 87]

6 minutes ago, itman said:

Are you monitoring write activity to %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\*.*? If you're monitoring program startup activity, none be detected for a .lnk file since it is just a shortcut to the actual .exe location.

Also if your monitoring write activity to %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\*.*, you have to allow write activity to hidden OS .ini files there. Finally, you just can absolutely block anything written to %APPDATA%\Microsoft\Windows\Start Menu\Programs\Startup\*.* since legit apps and even the OS may do so although I have yet to find anything that does.

 

My rule is "*" instead of "*.*". Aren't they the same? I'm yet to notice anything either.

[itman 1,801]

Works for me:

If you have coded this, %APPDATA%, in the rule, replace it with, C:\Users\XXXXX\AppData\Roaming\..............

Edited April 13, 2020 by itman

[SeriousHoax 87]

33 minutes ago, itman said:

Works for me:

If you have coded this, %APPDATA%, in the rule, replace it with, C:\Users\XXXXX\AppData\Roaming\..............

Ok thanks.

[itman 1,801]

BTW - %AppData% is not the only startup location malware can write to but also, C:\ProgramData\Microsoft\Windows\Start Menu\Programs\StartUp\ . However, this directory takes a bit more work due to permissions issues. But a UAC bypass should do the trick.

Then there are the multiple of registry run keys ..................................