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

[Vince 0]

6 minutes ago, Nightowl said:

Upload it please to virustotal to see the results also you can try hybrid analysis web site and app anyrun

[Nightowl 206]

No still you need to proceed , select Windows 7 64

Also you can try with www.virustotal.com , it's faster and no queue.

[Nightowl 206]

This is probably the threat , upload it to VT/Hybrid Analysis and please post links to the results

And manually quarantine it with ESET , and proceed to scan with PUA and Unsafe applications enabled , a deep full system scan
Most probably your system is still safe , because most of the calls the trojan downloader or the script was doing were blocked by ESET , so attempts to do malicious things or downloads were prevented most likely

Edited June 7, 2020 by Nightowl

[Vince 0]

4 minutes ago, Nightowl said:

This is probably the threat , upload it to VT/Hybrid Analysis and please post links to the results

And manually quarantine it with ESET , and proceed to scan with PUA and Unsafe applications enabled , a deep full system scan

how to scan with PUA and Unsafe applications enabled ? i Scaned like that :

[Nightowl 206]

Up at right , you see the Settings Icon , you can switch to Deep Scan

And going to settings in ESET GUI , Real Time Scanning and On-demand scan settings , you can select ESET to detect unwanted apps and unsafe apps

explained more here : https://support.eset.com/en/kb6692-enable-or-disable-detection-of-potentially-unwantedunsafe-applications-on-an-individual-workstation-in-eset-endpoint-products-6x

You can also upload the malicious script to ESET maybe they could see it from their side and add it to the detection,

Manually add it to Quarantine and see if the blocks disappear.

[itman 1,720]

5 hours ago, Jozef76 said:

Hi!

I having problem with pop up hxxp://api.backend-app.com:8880

I created new HIPS rule!
Looks like the pop-ups has been stopped.

I found:
C:\Users\xxx\AppData\Roaming\Microsoft\Windows\Start Menu\Programs\Startup\updatewins.lnk

updatewins.lnk - >Target: C:\WINDOWS\system32\wscript.exe  /E:jscript "C:\Users\Joe\AppData\Roaming\updatewins" wscript.exe/e:key:przSlksUf6ucMA

Question.
Can updatewins.lnk file be deleted?

Thank you!

 

Have you downloaded and installed any cracked software? The presence of this indicates you are ;

wscript.exe/e:key:przSlksUf6ucMA.

Edited June 7, 2020 by itman

[Nightowl 206]

They were talking about Adobe cracked version in earlier posts , unsafe & unwanted options should help him find the crack.

[itman 1,720]

9 minutes ago, Nightowl said:

They were talking about Adobe cracked version in earlier posts

What's currently going on can apply to any cracked software where the crack author is using a backend api server.

[itman 1,720]

Here's my strong suspicion of what is going on. I swore to myself I wasn't going to post this because I believe anyone using cracked software deserves to be infected.

It appears the crackers are using a backend api server. They are also using port 8880. Eset appears to be detecting any connection to a backend api server via port 8880 as botnet activity. Or more specifically, the IP address used by this type of network connection is being detected by Eset as malicious.

There also appears to be a malicious JavaScript variant performing this same type of backend api connection via port 8880.

How to differentiate between the above activities is where;

wscript.exe/e:key:przSlksUf6ucMA

is specified as part or the Win Startup directory entry. The "key:" use is for passing the crack key to the backend api server used by the cracker.

Edited June 7, 2020 by itman

[itman 1,720]

I also suspect that perhaps "someone" has become fed up enough with the crackers activities that they might be purposely hosting malware on the backend api servers used by the crackers. In effect, using the AV's to block connections to those servers resulting in the shutdown of the cracked software use.

[Jozef76 0]

1 hour ago, itman said:

Have you downloaded and installed any cracked software? The presence of this indicates you are ;

wscript.exe/e:key:przSlksUf6ucMA.

Hi!

Thank you for reply!
Currently not installed cracked software!

Thanks!
 

[Jozef76 0]

5 hours ago, Marcos said:

Please do not delete any files without keeping a copy of them. Move the file to a new folder, reboot the machine and upload the file here along with logs collected with ESET Log Collector.

Hi!

Thank you for reply!
I moved the file, rebooted machine!
I sent the files to you!
Thanks!

[itman 1,720]

27 minutes ago, Jozef76 said:

Hi!

Thank you for reply!
Currently not installed cracked software!

Thanks!
 

Using Win Explore, scan the C:\Users\Joe\AppData\Roaming\ directory for any file beginning with "updatewins" less the quote marks. Ignore the Startup directory entry. Open the other file found using Notepad. Post a screen shot of what is shown in Notepad.

Edited June 7, 2020 by itman

[Jozef76 0]

3 hours ago, itman said:

Using Win Explore, scan the C:\Users\xxx\AppData\Roaming\ directory for any file beginning with "updatewins" less the quote marks. Ignore the Startup directory entry. Open the other file found using Notepad. Post a screen shot of what is shown in Notepad.

Thanks!
I didn't find it in the roomaing folder...
Good news, I turned off the rules, there was no pop-up. Nod32 is silent.

Thank you!

Edited June 7, 2020 by Jozef76

[GreekGuy 0]

 

I used Kaspersky Virus Removal Tool and  RogueKiller to get rid of a similar infection. I haven't had a warning pop up since.

 

[Nightowl 206]

4 hours ago, itman said:

I also suspect that perhaps "someone" has become fed up enough with the crackers activities that they might be purposely hosting malware on the backend api servers used by the crackers. In effect, using the AV's to block connections to those servers resulting in the shutdown of the cracked software use.

Most usually cracked software don't require an active internet connection to some place.

They usually reverse engineer the activation methods and bypass/remove the protections.

[itman 1,720]

3 hours ago, Jozef76 said:

Good news, I turned off the rules, there was no pop-up. Nod32 is silent.

Not really. The Eset alerts stopped because you removed the Startup directory entry that was source of the backend api connections.

[itman 1,720]

Let's again review what is known about the original malicious JavaScript variant.

1 A JavaScript file is dropped to the target device C:\ root directory. Method how this was done is currently unknown. Also this is not possible to do in Win 10 since it prohibits file entry creation in the C:\ root directory. However, the script could have been dropped to any directory the attacker had permission to write to. -EDIT- Correction the payload Javascript drops another JavaScript into the C:\ root directory. To see the degree of system modification done by payload JavaScript, you can view its modifications on this Hybrid-Analysis of it here: https://www.hybrid-analysis.com/sample/8d33d5c74a877dc2030ec36b79db8630e20dc476e3374d24b65dee6222d7d498?environmentId=100 .

2. Something, again unknown, executed the payload script in the root directory. This script when executed runs two PowerShell script child processes that create the Startup directory entry; copies the payload script or most likely an extract of it to %AppData% directory/sub-directory; and modifies system registry keys and other system settings.

Bottom line - removing the Startup directory entry only stops the Eset alerts to bankend API server. You are still infected since registry keys and system settings have been modified.

Assume that the hacker has modified the original payload JavaScript to avoid the existing Eset signature of it. Hence, a new payload variant is currently infecting devices.

To prevent malware infection from this current undetected payload JavaScript variant, it is necessary to monitor all wscript.exe program startup activity with an Eset user created "ask" mode HIPS rule. I have had a like HIPS rule in place for some time and have never received an alert from it. I have created no custom scripts that might trigger this rule. Additionally, it is highly unlikely any legit app software would be deploying wscript.exe. As previously posted, cracked software however appears to be deploying wscript.exe.

Finally, assume that any device where this malicious JavaScript payload is being dropped to is already compromised in some way.

Edited June 7, 2020 by itman

[itman 1,720]

Eset mitigations to this payload JavaScript issue.

First, "you can bet your booties" that the payload JavaScript is packed, highly obfuscated, and even encrypted. It might be even employing an AMSI bypass. Bypassing AMSI is for all practical purposes trivial.

Create an equivalent built-in HIPS rule similar to Windows Defender ASR mitigation that blocks highly obfuscated scripts. However, Eset will note the script might be legit. Hence they "get dinged on some AV lab test." To that I say the likelihood of such a script being legit is equal to that of two blue moons occurring in the same month.

Edited June 7, 2020 by itman

[SeriousHoax 85]

Maybe he should scan his system by Norton Power Eraser and Malwarebytes. These are very good at finding leftovers and potentially malicious registry modifications. 

Scan with this: 

https://support.norton.com/sp/static/external/tools/npe.html 

https://www.malwarebytes.com/ 

Make sure to disable the trial Pro version of Malwarebytes. Only use it as a scanner. 

[Vince 0]

no more popups alert for me with HIPS rules, or without HIPS rules.

After a Deep Scan  :

[Marcos 5,159]

28 minutes ago, itman said:

Eset mitigations to this payload JavaScript issue.

First, "you can bet your booties" that the payload JavaScript is packed, highly obfuscated, and even encrypted. It might be even employing an AMSI bypass. Bypassing AMSI is for all practical purposes trivial.

Create an equivalent built-in HIPS rule similar to Windows Defender ASR mitigation that blocks highly obfuscated scripts. However, Eset will note the script might be legit. Hence they "get dinged on some AV lab test." To that I say the likelihood of such a script being legit is equal to that of two blue moons occurring in the same month.

A recent detection on highly obfuscated javascripts that were often used for malicious purposes caused various FPs mainly in Japan among bigger customers. Using your words, we encountered 31 blue moons in the same month.

[itman 1,720]

1 minute ago, Marcos said:

A recent detection on highly obfuscated javascripts that were often used for malicious purposes caused various FPs mainly in Japan among bigger customers. Using your words, we encountered 31 blue moons in the same month.

I agree whole heartily. What I proposed should not be used on Eset Endpoint installations obviously. Corp. environments regrettably, use scripts for maintenance purposes, etc..   

[Marcos 5,159]

2 minutes ago, itman said:

I agree whole heartily. What I proposed should not be used on Eset Endpoint installations obviously. Corp. environments regrettably, use scripts for maintenance purposes, etc..   

The highly obfuscated script was not seen only on adware-related sites but surprisingly also on bank and government sites so it affected both consumer and business users.

[itman 1,720]

4 minutes ago, Marcos said:

The highly obfuscated script was not seen only on adware-related sites but surprisingly also on bank and government sites so it affected both consumer and business users.

OK. How about this. Allow exclusion capability to the built-in HIPS rule. Corps can then whitelist their obfuscated scripts.

Or, simply make it a suspicious detection and necessary HIPS allow rules created at that point.