Jump to content

Recommended Posts

we are install eset antivirus is unable to stop virus in my computer all file corrected

Mess drop by virus is below

 

Your All Files Encrypted With High level Cryptography Algorithm
If You Need Your Files You Should Pay For Decryption
You Can Send 1MB File For Decryption Test To Make Sure Your Files Can Be Decrypted 
After 48 hour If You Dont contact us or use 3rd party applications or recovery tools   Decryption fee will Be Double
After Test You Will Get Decryption Tool 
Your ID For Decryption:V24ebEl6JQ
Contact Us: RDP700@protonmail.com

 

Screenshot is attached 

sample.jpg

Share this post


Link to post
Share on other sites

Files were encrypted by Filecoder.Ouroboros. If you have an ESET license purchased, please collect logs with ESET Log Collector and email the generated archive along with the following stuff to samples[at]eset.com:

- a pair of an encrypted an unencrypted file
- the ransomware note with payment instructions
- the ransomware itself

Share this post


Link to post
Share on other sites

we have eset node32 license product and this ransomware active in our system eset node32 is unable product computer system ??????  please resolve problem i already log in samles@eset.com i have very important document. i am trust on eset  but hope eset have solution

 

waitting for positive replay.

 

Thanks

 

Jignesh

Share this post


Link to post
Share on other sites

Ensure you have RDP access locked down on your network/devices. Most whom have been nailed by this ransomware variant were using RDP:

https://www.bleepingcomputer.com/forums/t/703888/lazarus-ransomware/

https://www.bleepingcomputer.com/forums/t/702015/zeropadypt-nextgen-ransomware-limbo-lazurus-support/

Edited by itman

Share this post


Link to post
Share on other sites

A result of analysis was sent to your email address with a request for additional files and logs. Obviously the ransomware has been recognized by ESET for a month at least, maybe even longer with all the protection features taken into account.

The logs revealed that real-time protection must have been disabled at the time when the ransomware was run. Further logs should show if an RDP attack has been performed recently.

Last but not least, there's a good chance that decryption will be possible.

Share this post


Link to post
Share on other sites

realtime protection is on at attack time check log file. 

 

how can decryption is possible ? 

 

 

Share this post


Link to post
Share on other sites

No, it was disabled. ESET had recognized the ransomware for at least one month when it was run on your machine which would not have been possible with real-time protection enabled.

Please provide the files and logs we requested from you at samples[at]eset.com and communicate with us primarily there please.

Share this post


Link to post
Share on other sites

We've received just one email that was replied about 20 minutes ago.

Share this post


Link to post
Share on other sites
1 hour ago, Marcos said:

ESET had recognized the ransomware for at least one month when it was run on your machine which would not have been possible with real-time protection enabled.

Care to elaborate on this?

It implies to me that the OP was being repeatedly infected and never reviewed his Eset detection log during that time period.

Scratch that. Appears you are stating that Eset had a sig. for the ransomware that was at least a month old.

Will be interesting to determine if this bugger bypassed real-time detection. Note that it was previously demonstrated that a malicous PowerShell script downloaded as a .txt file and renamed locally was able to bypass real-time scanning due to default Smart scanning option not re-initiating a re-scan at file rename time. In that instance, Eset AMSI on Win 10 was able to catch it. If this is a Win 7 installation, a bypass is possible. Also a Win 10 bypass is possible if this is a heavy obfuscated script, and Eset was unable to fully un-obfuscate it. 

Edited by itman

Share this post


Link to post
Share on other sites

Additionally if an attacker has remote access to a device, no stealthy methods need to be employed to bypass Eset's real-time protection.

Assuming Eset's GUI is not password protected, all the attacker has to do is add his executable, script, etc. to real-time's exception list. I usually do so by hash value for my test malwares. Using the above .txt file example, just add the .ps1 script to the exception list prior to renaming it. Eset doesn't check that the file actual exists when adding the exception. Or add the .exe exception first, and then download the file to the target device.

Which gets us to the fact that if Win RDP is installed on the device, Eset needs to make the Eset GUI password setting mandatory.

Share this post


Link to post
Share on other sites
9 hours ago, Marcos said:

We've received just one email that was replied about 20 minutes ago.

any update

Share this post


Link to post
Share on other sites

Hello Eset team,

 

it is very glad that you are protecting the company reputation. you are saying that eset protection was stopped but didn't say that how does it got stop?

Did client contact to Hacker and welcome them to mess the machine?

you are very well aware if you are aware about security infra that password can't be hacked or cracked without any automated script which break the security and give the access

Please don't try to protect eset reputation by telling that it happened due to opened RDP connection

if that the case NO CLOUD solution was supposed to be in place of IT. There are N number of datacenters in IT and there are not being used locally... All are being used by RDP ONLY

After having ESET if the computer is being compromised and after having root level access, it is really the place where eset has to improve their security or backup system where they keep their own backup technology as others are having(please don't tell that others don't do)

 

Share this post


Link to post
Share on other sites
6 hours ago, Techindia said:

any update

It's your turn now. We received an email from you (a.........m@gmail.com) yesterday at 19:26 CEST and replied at 19:36, ie. 10 minutes after. Got no further emails from your address since.

Share this post


Link to post
Share on other sites
15 hours ago, itman said:

Care to elaborate on this?

It implies to me that the OP was being repeatedly infected and never reviewed his Eset detection log during that time period.

Scratch that. Appears you are stating that Eset had a sig. for the ransomware that was at least a month old.

image.png

ECLS Command-line scanner, version 7.0.2097.0, (C) 1992-2018 ESET, spol. s r.o.
Module scanner, version 19940 (20190830), build 42596

Scan started at:   Wed Sep 11 12:46:06 2019
name="975f6d0b2b10f2e77fc9e98adf12e4c40946398b", threat="a variant of Win32/Filecoder.NXE trojan", action=""

Don't wonder about the difference in name; the Filecoder has been renamed just recently and it was given a more friendly name.
Still between Aug 30 when a detection was added for that particular variant (not taking into account Ransomware shield and other proactive protection techniques) and Sept 10 when the ransomware was executed there was plenty of time.

Checking the event logs revealed that update was failing with "unauthorized access" error (probably due to invalid license) since Aug 12 until Sept 10 and that appears to have been the main cause of the infection. The problem with license also caused LiveGrid not to work and Ransomware shield didn't work either because of missing data from LiveGrid.

I'm still waiting for logs to find out if there was also an RDP attack at that time.

Share this post


Link to post
Share on other sites
11 hours ago, Marcos said:

Still between Aug 30 when a detection was added for that particular variant (not taking into account Ransomware shield and other proactive protection techniques) and Sept 10 when the ransomware was executed there was plenty of time.

Your posted log entry clearly shows the situation during the noted time period. The attacker totally disabled Windows Defender by replacing its engine, msmpeng.exe, with a malware version. This could only happen if the attacker was able to modify its permissions since Trusted Installer is the only one that can modify it.

Another scenario is the attacker is injecting msmpeng.exe at system startup time. Upgrading to Win 10 1903 and enabling WD's self-protection and sandbox would have prevented this.

-EDIT- Actually what was happening was the Neshta.A virus appended its malicous code to msmpeng.exe. It also appears that WD is starting at boot time implying it is currently configured to perform "periodic scanning" activities.

I will also add that I discovered a "security quirk" on my on Win 10 Feature Upgraded 1903 version. This is WD's self-protection was disabled at first startup use of it. Once enabled it remained so upon subsequent startups of WD. As such and assuming OP was using 1903 version, malware could still disable WD when it activated upon Eset's license expiration.

Edited by itman

Share this post


Link to post
Share on other sites

I will also state that this incident is looking very suspicious to me.

It is inconceivable that the OP was not aware that Eset was not functioning properly for close to a month. Eset is quite "visual" in the display of status information that it is not functioning properly.

To the OP I state it's best you reformat and reinstall Windows. With the Windows Defender engine compromised, the attacker would have sufficient privileges to totally "trash" your device in regards to system modifications and malware installations.

Share this post


Link to post
Share on other sites

Notable from the Eset log screen shot is the presence of the Neshta.A virus. Sophos has an analysis of what that does here:  https://www.sophos.com/en-us/threat-center/threat-analyses/viruses-and-spyware/W32~Neshta-A/detailed-analysis.aspx . The most important point is the ability to connect to a remote C&C server on a continuous basis for spying purposes. Assume all passwords on this device entered in clear text have been compromised along with much more stored data.

Hybrid-Analysis has a 2017 detailed analysis of this virus here: https://www.hybrid-analysis.com/sample/2c2f87ce2d5f3f2e55272aa72b32fbdd30ef6886903266ae645ea9b1e08ab5f1?environmentId . Of note is this is a very old virus; over a decade. Of interest in this analysis is the following:

Reads terminal service related keys (often RDP related)

What that means is described in this analysis of a similar virus employing the technique: https://www.prodefence.org/rpd-remote-desktop-protocol-backdoor-malware-analysis/ .

Namely, it checks if the device has RDP capability. This then would confirm to the attacker that RDP could be utilized in a subsequent attack. Assume with virus installed that if the Eset GUI was password protected, the attacker would have already captured what that password is.

Edited by itman

Share this post


Link to post
Share on other sites

Hello infected parties,

 

I did recover my data which got impact on same day when you guys faced problem. Am the one poor person, who was using ESET and where all the protection including admin password got change.

 

At first attempt i did place request for ESET as they were the ONE who had admitted that there were approx. more then 5000 attempts(NOT SURE WHAT ESET as AN ANTIVIRUS WAS DOING AGAINST BRUTE FORCE ATTACK) to break the security. Still was looking forward to them to get my client's data back but unfortunately they were looking for impacted file and fresh file to check what is the mess. Still considered the demand and forwarded the demand of them to my client by being just as a mediator as i placed trust on ESET to keep my infra secure.

 

i did recover almost all data and decided to hand it over to my clients by making NO WORRY about the response from them for future business.

 

Have recovered the files with very minor change and OLD data as we had before without any wasting time in investigation and playing with victim and origin data(main stuff really client will believe you now for giving valued data AGAIN?). 

 

Seriously having question that if as ordinary business man, if i get the data back WHY ESET can't do as a security organisation and they need SAMPLES?

Share this post


Link to post
Share on other sites
18 minutes ago, JigneshC said:

At first attempt i did place request for ESET as they were the ONE who had admitted that there were approx. more then 5000 attempts(NOT SURE WHAT ESET as AN ANTIVIRUS WAS DOING AGAINST BRUTE FORCE ATTACK) to break the security.

Having an antivirus installed cannot ensure 100% protection. One must keep the OS up to date and install critical security updates not only for the OS but also for other installed applications with possible vulnerabilities that can be exploited. Also a security admin must harden and secure all possible infection vectors, such as RDP which is commonly enabled even on systems where not needed. A security admin should also care about the firewall to be set up properly to prevent attacks on machines in LAN and to setup policies for maximum protection (e.g. enforce strong passwords, account lockout policy, etc.).

Quote

Seriously having question that if as ordinary business man, if i get the data back WHY ESET can't do as a security organisation and they need SAMPLES?

I'm sorry but I don't understand this comment. Samples are needed in case that a particular malware is not recognized and detected which was not this case.

You can get the data back either from a backup or by paying the ransom (without warranty) which is something that nobody else can do.

Share this post


Link to post
Share on other sites
2 minutes ago, Marcos said:

Having an antivirus installed cannot ensure 100% protection. One must keep the OS up to date and install critical security updates not only for the OS but also for other installed applications with possible vulnerabilities that can be exploited. Also a security admin must secure all possible infection vectors, such as RDP which is commonly enabled even on systems where not needed.

I'm sorry but I don't understand this comment. Samples are needed in case that a particular malware is not recognized and detected which was not this case.

RDP does enabled in all cloud technology. Not sure why you guys are stick with RDP enabled stuff.

 

LAZARUS is not something new invented it is there since more time and there are documentations on this. This is very strange to hear that you as an ESET are not aware about this.

 

What eset was doing when some internal script was trying to break the password? Was that as a security application did try to NOTIFY to the contact details which you guys are taking while activating the product?

 

Please don't say that brute force is not something which can't be identified by ANY Antivirus.

Share this post


Link to post
Share on other sites
1 minute ago, JigneshC said:

RDP does enabled in all cloud technology. Not sure why you guys are stick with RDP enabled stuff.

Please elaborate more on this. Do you claim that RDP was disabled on the affected machines? If it was enabled, was it secured? How?

Quote

LAZARUS is not something new invented it is there since more time and there are documentations on this. This is very strange to hear that you as an ESET are not aware about this.

It's not something new for ESET, we didn't state that. Quite the contrary, ESET has recognized it long before the user got infected. Unfortunately, we haven't been provided requested logs for further analysis to confirm if an attacker logged on via RDP. What is a matter of fact is that ESET's protection was paused at the time when the attack was performed and files got encrypted.

Share this post


Link to post
Share on other sites
7 minutes ago, Marcos said:

Please elaborate more on this. Do you claim that RDP was disabled on the affected machines? If it was enabled, was it secured? How?

It's not something new for ESET, we didn't state that. Quite the contrary, ESET has recognized it long before the user got infected. Unfortunately, we haven't been provided requested logs for further analysis to confirm if an attacker logged on via RDP. What is a matter of fact is that ESET's protection was paused at the time when the attack was performed and files got encrypted.

          --- If it is not new WHY sample was needed for origin file and before making the request, need to think that who the vendor will give the origin file where all stuffs are impacted.

Hey Marcos,

For RDP

RDP is configured B/H firewall with port forwarding; WAF; AV; SSL all protections are in place.

There are limitation for browsing too. Only IT technology; Microsoft; ESET; GMAIL are allowed

 

For Logs,

Logs are handed over by your tech from my machine by downloading log collector and that the who said that brute force happened. Hoping that there are any logs remained to check for you guys.

Share this post


Link to post
Share on other sites
19 minutes ago, JigneshC said:

Hey Marcos,

For RDP

RDP is configured B/H firewall with port forwarding; WAF; AV; SSL all protections are in place.

There are limitation for browsing too. Only IT technology; Microsoft; ESET; GMAIL are allowed

 

For Logs,

Logs are handed over by your tech from my machine by downloading log collector and that the who said that brute force happened. Hoping that there are any logs remained to check for you guys.

Please tell me what logs are needed Marcos?

Tack#5D7883C6184D -  Opened on 10th SEP -- Last demand of ORIGIN file from ESET(How can that be given if all data is damaged)

Share this post


Link to post
Share on other sites

In that case it looks like both Filecoder.Phobos and Filecoder.Ouroboros encrypted files. There was one file which was encrypted by Phobos, however, the file name was changed by Ouroboros but it didn't encrypt it. Other encrypted files we received were encrypted by Ouroboros.

From logs it was obvious that real-time protection was disabled by an attacker.

Files encrypted by Ouroboros could be decrypted provided that we receive the files we asked for, including payment instructions dropped by Ouroboros (we received only Phobos instructions) as well as the Ouroboros ransomware itself from the machine. Now I understand what you mean by the sample, however, we need the exact ransomware sample that was run on the machine; any other even slightly modified variant could not be used to create a decryptor. Unfortunately since real-time protection was effectively disabled at the time of encryption, we don't have any metadata that we could use to find it ourselves.

Share this post


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...