Jump to content

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


Recommended Posts

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

hybrid.jpg.9cf817dea0df5278649443029d98173b.jpg

Link to post
Share on other sites
  • Replies 169
  • Created
  • Last Reply

Top Posters In This Topic

Top Posters In This Topic

Popular Posts

Got it from VT. In fact, it's not detected because of the extension but with a correct extension it would be detected: updatewins.js - JS/Kryptik.BPU trojan. The detection was created between Feb 17

The script uploaded to VT is the initiator script that will run the payload script that has been previously dropped here: C:\updatewins.js . As such, this JavaScript itself is not malicious; the scrip

The script is malicious and has been detected by ESET since Feb. As of the last update it's also detected without an extension

Posted Images

  • Most Valued Members

No still you need to proceed , select Windows 7 64

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

Link to post
Share on other sites
  • Most Valued Members
Posted (edited)

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 by Nightowl
Link to post
Share on other sites
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 :

virustotal.jpg

hybrid.jpg

scan Eset.jpg

Link to post
Share on other sites
  • Most Valued Members

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.

Link to post
Share on other sites
Posted (edited)
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 by itman
Link to post
Share on other sites
  • Most Valued Members

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

Link to post
Share on other sites
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.

Link to post
Share on other sites
Posted (edited)

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 by itman
Link to post
Share on other sites

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.

Link to post
Share on other sites
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!
 

Link to post
Share on other sites
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!

Link to post
Share on other sites
Posted (edited)
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 by itman
Link to post
Share on other sites
Posted (edited)
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 by Jozef76
Link to post
Share on other sites

 

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

 

image.thumb.png.ce6120d00838f0abb6b49c06e3908797.png

Link to post
Share on other sites
  • Most Valued Members
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.

Link to post
Share on other sites
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.

Link to post
Share on other sites
Posted (edited)

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 by itman
Link to post
Share on other sites
Posted (edited)

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 by itman
Link to post
Share on other sites

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. 

Link to post
Share on other sites
  • Administrators
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.

Link to post
Share on other sites
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..   

Link to post
Share on other sites
  • Administrators
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.

Link to post
Share on other sites
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. 

Link to post
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.
Note: Your post will require moderator approval before it will be visible.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

  • Recently Browsing   0 members

    No registered users viewing this page.


×
×
  • Create New...