ESET I.S. Agressively blocking URL, can't find app

[itman 1,659]

3 minutes ago, Marcos said:

This is something different which is detected by ESET as JS/Agent.AG

Note I stated the "original JavaScript variant." First, note the naming conventions used by the original:

• C:\Users\admin\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\update-win.js.lnk
• C:\Users\admin\AppData\Roaming\update-win.js

The techniques employed in the second Javascript variant are identical to the first. Only file names used in the second variant have been slightly altered.

Bottom line - this is the same malware developer. He didn't stop after the original variant was detected via signature and I don't expect him to stop now that the second variant has likewise been detected by signature.

 

[Namoh 0]

21 minutes ago, Nightowl said:

Crack/hacktools/keygens and etc are all detected as HACKTOOL by ESET , as if UNSAFE apps detection isn't enabled then ESET won't touch them , or warn about them , because they are not malicious to the user.

 

Maybe a stupid question, but where's this UNSAFE apps detection option located?
Would like to check if I have it enabled or disabled.

[Nightowl 202]

1 minute ago, Namoh said:

Maybe a stupid question, but where's this UNSAFE apps detection option located?
Would like to check if I have it enabled or disabled.

It's completely normal

It's available here : https://support.eset.com/en/kb3204-configure-eset-products-to-detect-or-ignore-unwanted-unsafe-and-suspicious-applications

For example a software called CheatEngine which is used to make trainers/modify memory while in-game , enabling the option of UNSAFE apps will trigger CheatEngine as a HACKTOOL , while it's completely normal and non-malicious software , but the detection has it's name for the software , it is a HACKTOOL

Edited June 9, 2020 by Nightowl

[Vince 0]

6 hours ago, Nightowl said:

I am sorry but unfortunately I don't have it , but @Vince should , it got uploaded to VT

and probably he manually quarantined it to ESET.

ESET deleted it yesterday :

[Nightowl 202]

ESET has added the detection earlier for the shortcut link , same as the other file which was in the Roaming Folder , it wasn't detected because it was missing the .ext , but as far as I understood it should be detected by now even without the .JS

[Namoh 0]

Ok, so I found it, but what's the best setting?

All on Aggressive for as well Reporting as Security...?

All these settings are there for a reason I assume, but you still can be infected if some of these settings are incorrect, while you think you're safe.

I'll keep them on Agressive (changed this few days ago because of this threads) for Reporting, but not for Security.

[Nightowl 202]

This can explain better than I do :

 

[Nightowl 202]

For my personal use , I run all at Aggressive , if I have a trouble somewhere , I will just make some adjustments and continue on.

[Namoh 0]

6 minutes ago, Nightowl said:

For my personal use , I run all at Aggressive , if I have a trouble somewhere , I will just make some adjustments and continue on.

I assume you mean Aggressive for Reporting not for Security

[Nightowl 202]

6 minutes ago, Namoh said:

I assume you mean Aggressive for Reporting not for Security

For both, but if you normally use hacktools , it will drive you crazy with detection triggers.(If you enable UNSAFE Applications)

Enabling PUA is also helpful as it could help you get rid of possible junk from your PC.

Edited June 9, 2020 by Nightowl

[itman 1,659]

For those that insist on still downloading cracked software after all that has been posted in this thread, I have been doing my own recent research in that area.

Don't be surprised if you can't download the cracked software anymore. Appears Eset is blacklisting a number of servers hosting these cracked downloads. Kudos to Eset in this regard.

For example;

Time;URL;Status;Application;User;IP address;SHA1
6/8/2020 3:24:54 PM;https://d5qkj7n97c2ot.cloudfront.net;Blocked by internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxx\xxxxx;52.85.90.143;6A7CC00B6CED44FA2843D1AD1F635C7527FF7A61

[Nightowl 202]

9 minutes ago, itman said:

For those that insist on still downloading cracked software after all that has been posted in this thread, I have been doing my own recent research in that area.

Don't be surprised if you can't download the cracked software anymore. Appears Eset is blacklisting a number of servers hosting these cracked downloads. Kudos to Eset in this regard.

For example;

Time;URL;Status;Application;User;IP address;SHA1
6/8/2020 3:24:54 PM;https://d5qkj7n97c2ot.cloudfront.net;Blocked by internal blacklist;C:\Program Files\Mozilla Firefox\firefox.exe;xxxxx\xxxxx;52.85.90.143;6A7CC00B6CED44FA2843D1AD1F635C7527FF7A61

But yet these people have been bluffed , they were given a false download , it's normally done through download websites or dodgy websites , or some popular torrent websites , bots would just upload torrents with fake seeders count so it could reach a good ranking and infect lot of people

As I've said , never was Games and Software cracks requesting/reporting data to somekind of a server unless it's fake or injected with a virus and re-uploaded to the internet.

Usually people who crack software/games don't put crazy things , the SCENE(It's called like this) never do that , and they never want their releases out to the public , so it's never from crackers , P2P solutions is different story and can be modified and changed to whatever and re-released

And fake torrents/downloads are another story because there are bots/people who work all the time to do that.

To infect , to deny you from finding the right download , etc...

It's due to the user inability to distinguish between what is good and what is wrong.

[itman 1,659]

1 minute ago, Nightowl said:

It's due to the user inability to distinguish between what is good and what is wrong.

Reminds me of the truism, "If you play with fire, you will eventually get burnt."

[Nightowl 202]

1 minute ago, itman said:

Reminds me of the truism, "If you play with fire, you will eventually get burnt."

Indeed that is true , like everything in life.

[itman 1,659]

In regards to what this malware JavaScript malware does, a few observations.

In addition to other system modifications, it creates a new network service. It also creates a copy of wscript.exe in the C:\Users\Public directory. Assumed it is using that copy to execute any additional scripts the malware deploys. So if one is indeed using Eset HIPS to monitor wscript.exe startup, you would have made target application in the rule C:\Windows\System32\wscript.exe. As such, this rule will not detect wscript.exe startup from any other directory location.

This gets us to Eset's "stone age" HIPS capability. I for one have "been harping" for some time about the lack of global wildcard capability. That is a specification such as *\wscript.exe that would detect wscript.exe PE use regardless of where it is located. -EDIT- How this would be deployed is one "ask" HIPS rule for C:\Windows\System32\wscript.exe. Then one "block" HIPS rule for *\wscript.exe. This would also enable blocking of abused legit "living of the land" utilities such as those included in the SysInternals suite; e,g. PsExec, that can be maliciously deployed from any directory.

BTW- the dropping of executable's into the C:\Users\Public directory is a technique used by North Korean hackers. One possible source where the malware is originating from.

Edited June 9, 2020 by itman

[Nightowl 202]

15 hours ago, itman said:

In regards to what this malware JavaScript malware does, a few observations.

In addition to other system modifications, it creates a new network service. It also creates a copy of wscript.exe in the C:\Users\Public directory. Assumed it is using that copy to execute any additional scripts the malware deploys. So if one is indeed using Eset HIPS to monitor wscript.exe startup, you would have made target application in the rule C:\Windows\System32\wscript.exe. As such, this rule will not detect wscript.exe startup from any other directory location.

This gets us to Eset's "stone age" HIPS capability. I for one have "been harping" for some time about the lack of global wildcard capability. That is a specification such as *\wscript.exe that would detect wscript.exe PE use regardless of where it is located. -EDIT- How this would be deployed is one "ask" HIPS rule for C:\Windows\System32\wscript.exe. Then one "block" HIPS rule for *\wscript.exe. This would also enable blocking of abused legit "living of the land" utilities such as those included in the SysInternals suite; e,g. PsExec, that can be maliciously deployed from any directory.

BTW- the dropping of executable's into the C:\Users\Public directory is a technique used by North Korean hackers. One possible source where the malware is originating from.

So what if we change the executable name from wscript.exe to w.exe , will it be denied the same by HIPS ? or it will bypass the block?

[itman 1,659]

4 hours ago, Nightowl said:

So what if we change the executable name from wscript.exe to w.exe , will it be denied the same by HIPS ? or it will bypass the block?

It will bypass the block.

However as a rule, .exe file name changes from what the internal PE header shows aren't done. Many AV's will flag that as suspicious per se.

Also copying Win system .exes to another directory is unusual. Some AV's would detect running one from other than its default directory as suspicious.

[Nightowl 202]

2 minutes ago, itman said:

It will bypass the block.

However as a rule, .exe file name changes from what the internal PE header shows aren't done. Many AV's will flag that as suspicious per se.

Also copying Win system .exes to another directory is unusual. Some AV's would detect running one from other than its default directory as suspicious.

So it all goes back to the same root , Behavior Control / Application Control

[itman 1,659]

Actually, a whitelisting approach is quite effective. The problem is there is no way to practically do so using the Eset HIPS. Its learning mode just doesn't create a rule to allow app startup, but creates rules for every activity the app does. The result is a rule set that is unreadable and unmanageable.

[itman 1,659]

I also don't understand "what is the big deal" with modifying the HIPS to allow for a global wildcard specification for the program startup parameter, e.g. *\wscript.exe. When the HIPS parses the path and sees it begins with "*\", it ignores the default full path directory lookup and instead examines the PE header of the process attempting to load for a match to the string value following "*\".

Many of security products have this capability. Additionally, Win 10 OS itself has this capability. For example, in Window Security Center -> App & browser control -> Exploit Protection -> Program Settings. Here you can just enter wscript.exe versus the full path name.