ransomware attack

[hamed_masoomi67 0]

Hello

some of my servers encrypted by a ransomware .it`s extension is banta.

are there any decryption tools ???

 

some infected files and the encrypt-or exe attached

eset logs attached too

 

pass :infected 

EsetLogs.rar

Edited August 3, 2019 by hamed_masoomi67

[Marcos 5,074]

Files were encrypted by FIlecoder.Phobos, decryption is not possible.

The detection was added on June 24. If you had ESET installed, it's possible that you have RDP enabled but not secured. If you have purchased a license for an ESET product, please email samples[at]eset.com and provide:
- logs from ESET Log Collector
- examples of encrypted files + ransomware note (those you have submitted here).

Please make sure to install all critical OS updates. Also set up an account lockout policy to prevent bruteforce attacks. We recommend using VPN for connections from outside and allowing RDP only within your local network.

[hamed_masoomi67 0]

thanks for your reply

[novice 20]

Just out of curiosity , how the dedicated "antiransomware module +HIPS" work, if we still rely on " The detection was added on June 24 "???

 

Shouldn't the computer be protected somehow even before "adding the detection" by those 2 modules (antiransomware module +HIPS)???

If we still rely on a signature to be added, what's the point of having the antiransomware module +HIPS?

 

[Marcos 5,074]

I didn't say that Ransomware shield wouldn't have protected the OP before that date. I was talking just about a specific detection of the sample the user had.

By the way, if everything was 100% then AVs wouldn't need any updates since they would detect 100% of malware without FPs already which is, of course, unreal.

Moreover, given that he's been hit by it recently no kind of protection would help since the attacker most likely logged in as an administrator and paused or uninstalled ESET. Hence I asked the OP to provide logs in order for us to investigate what actually happened.

[novice 20]

6 hours ago, Marcos said:

I didn't say ...

Thank you for your answer!

Seems like ".. the attacker most likely logged in as an administrator and paused or uninstalled ESET "  is the explanation of the day to justify ESET inability to protect against ransomware. At least several situations before were explained using the same (convenient) scenario.

The addition of "antiransomware shield" to ESET was advertised as a big achievement , yet I have never seen it "in action" and the number of people coming here and complaining about being infected by ransomware is higher than any other forum.

Despite all bells and whistles, it seems like ESET still relies 99.9% on signatures and Live Grid, while HIPS/behavior/heuristic has an insignificant contribution.

 

Edited August 3, 2019 by novice

[Marcos 5,074]

This is the last warning to Novice. Further to complaints from other users that we've received about your ranting, we kindly ask you to stop this. Either give us a proof that there is an antivirus that can detect 100% of threats without updates and without any false positives and at the same time it can protect users even if they unwittingly allow an attacker to do anything on their machines under an admin account or stop trolling and ranting. We are open to serious communication but trolling is not tolerated and will never be neither here nor in any other forums. Otherwise we will need to take the appropriate action.

[hamed_masoomi67 0]

hello Marcos

eset log and some encrypted files attached.

password for Esetlogs.rar : infected

Thanks

essp_logs.zip EsetLogs.rar

[notimportant 5]

On 8/3/2019 at 1:21 PM, novice said:

Seems like ".. the attacker most likely logged in as an administrator and paused or uninstalled ESET "  is the explanation of the day to justify ESET inability to protect against ransomware. 

 

This is not an excuse. I see this all the time in the customers logs when brute force attacks are performed against RDP.

[peteyt 393]

1 hour ago, notimportant said:

This is not an excuse. I see this all the time in the customers logs when brute force attacks are performed against RDP.

I have an idea that might not work but could possibly avoid issues like this.

Years ago I used to use a program called TuneUp Utilities that wasnt tol bad until AVG bought it. One interesting thing it did was to warn users of certain settings and offer to fix things e.g. this is enabled and could do this. 

Could something like this work with eset. E.g detect if certain stuff is enabled, possibly even unpatched. I know a lot of this is down to the users but at least if it worked eset wouldnt be blamed

[Marcos 5,074]

5 minutes ago, peteyt said:

Could something like this work with eset. E.g detect if certain stuff is enabled, possibly even unpatched. I know a lot of this is down to the users but at least if it worked eset wouldnt be blamed

We already change protection status to red, e.g. if HIPS is disabled, yet I come across cases when users intentionally disable it and set up application statuses so that they are not warned about that.

[peteyt 393]

5 minutes ago, Marcos said:

We already change protection status to red, e.g. if HIPS is disabled, yet I come across cases when users intentionally disable it and set up application statuses so that they are not warned about that.

Oh yeah there will always be people like that sadly. But if you could warn them about things they might not otherwise know it may avoid issues

[itman 1,659]

1 hour ago, peteyt said:

I have an idea that might not work but could possibly avoid issues like this.

I already posted in another thread a simple solution using Group Policy that will defeat almost all RDP brute force attacks. That is simply to restrict logon on attempts to 3 tries and locking out the account thereafter.

This isn't "rocket science." It has become increasingly apparent that a majority of SMB IT admins are not properly trained in basic Windows security fundamentals.

Edited August 6, 2019 by itman

[peteyt 393]

3 hours ago, itman said:

I already posted in another thread a simple solution using Group Policy that will defeat almost all RDP brute force attacks. That is simply to restrict logon on attempts to 3 tries and locking out the account thereafter.

This isn't "rocket science." It has become increasingly apparent that a majority of SMB IT admins are not properly trained in basic Windows security fundamentals.

Would there be any way eset could implent this e.g. flag up if the policy wasnt activated and then the user could click something in eset that would activate the policy?

Obviously I know this is above eset as its not their probelm but it could help avoid eset being blamed. Basically what im suggesting is eset offering something that can warn of unsafe settings and automatically fix these if the user clicked yes

[itman 1,659]

6 minutes ago, peteyt said:

Would there be any way eset could implent this e.g. flag up if the policy wasnt activated and then the user could click something in eset that would activate the policy?

Can't see how this would be possible. Things like Windows account policy/control and the like are strictly under OS control.

-EDIT- SMB's however should be deploying Pro+ versions of Windows as those are the only versions that include Group Policy capability.

Edited August 6, 2019 by itman

[itman 1,659]

Here's a recent article on RDP mitigations. Do note what I emphasized in bold text where Microsoft needs to get involved in this problem:

Quote

Microsoft RDP Attacks: Here’s What MSSPs Need to Know

Cybercriminals are using Microsoft Remote Desktop Protocol (RDP) attacks, and MSSPs must plan accordingly, security software company Sophos says.

by Dan Kobialka • Jul 21, 2019

Microsoft Remote Desktop Services provide remote users with access to a computer over a network and ensure they can control it using a Windows graphical user interface. Furthermore, Remote Desktop Protocol (RDP) allows end users to remotely connect to Windows systems, and cybercriminals are increasingly exploiting RDP to launch ransomware attacks, according to British security software company Sophos.

Cybercriminals are using BlueKeep, a “wormable” vulnerability that self-replicates malware to spread across the Internet rapidly, to launch RDP attacks. This allows cybercriminals to trigger ransomware outbreaks and compromise RDP servers to invade networks that often consist of millions of Internet-connected RDP servers, Sophos said.

In addition, cybercriminals frequently use password-guessing attacks to probe computers exposed by RDP, Sophos noted. They also select RDP attack targets based on their vulnerability to RDP brute forcing.

How to Combat RDP Attacks

System administrators, cloud computing vendors and Microsoft must work together to address RDP attacks, Sophos stated.

Sysadmins can require strong RDP passwords, as well as set RDP remote access restrictions and account lockout policies. With this approach, sysadmins can minimize the risk of RDP attacks.

Meanwhile, cloud computing vendors may need to modify the default configurations in their standard machine images, Sophos indicated. For example, updating remote administration configurations for cloud instances running Windows could help reduce the number of potential RDP attack targets.

Microsoft also could implement two-factor authentication or other authentication measures to help organizations combat RDP attacks, Sophos pointed out. In doing so, Microsoft could make it difficult for cybercriminals to use password-guessing to launch RDP attacks.

https://www.msspalert.com/cybersecurity-breaches-and-attacks/ransomware/microsoft-rdp-attacks-details/

Eset article on Bluekeep and like RDP mitigation recommendations: https://www.welivesecurity.com/2019/05/22/patch-now-bluekeep-vulnerability/

Edited August 6, 2019 by itman

[roga 0]

I have a small domain managed by ERA with up to date versions and definitions

@Marcos said: " The detection was added on June 24. "

However I had a win10 machine, which was not open to the internet, running win10 and ESET Endpoint Antivirus, which got infected on Monday 5th Aug.

So I'm not sure how that happened?

[itman 1,659]

4 hours ago, roga said:

However I had a win10 machine, which was not open to the internet, running win10 and ESET Endpoint Antivirus, which got infected on Monday 5th Aug.

So I'm not sure how that happened?

Although the device had no Internet connectivity it is assumed it had internal network connectivity. The attacker gained access to the network via RDP or other means; most likely the server. Access to the this device was gained from the compromised network device. As such, he could have disabled Eset's real-time and HIPS protection and forced a reboot for the device. At this point, Eset's ransomware protection is disabled and the ransomware could run the unimpeded.

Was Eset's GUI settings on this device password protected?

Also in theory, Windows Defender real-time protection should have been enabled when Eset's was disabled. So assume the attacker disabled it which is rather trivial to do unless you are running ver. 1903 and WD's tamper protection had been previously manually enabled. Of course, the only way that can be done is if WD's real-time protection had been previously enabled. Note that by default tamper protection is disabled. Finally even if tamper protection was enabled, it could be manually disabled. Unlike Eset, WD has no password protection for its settings.

If you are running either Windows Server 2008 R2 or Windows Server 2008, have you applied the OS patches against the BlueKeep worm?

Edited August 7, 2019 by itman

[itman 1,659]

Also of note:

Quote

Why Hackers Abuse Active Directory

From Ransomware to APT Attacks, AD Can Make Connecting to Systems Easy

Warning: Attackers are abusing poorly secured and managed implementations of Microsoft Active Directory.

Security experts say that Active Directory, built into most Windows Server operating systems, has become the dominant approach to managing Windows domain networks. But its ease of use can also be tapped by hackers. (For more information, see part two of this two-part series.)

Norway's Computer Emergency Response Team, NorCERT, for example, said that the attack earlier this year against aluminum giant Norsk Hydro involved LockerGoga ransomware "combined with an attack on Active Directory" (see: Hydro Hit by LockerGoga Ransomware via Active Directory).

In April, researchers Oleg Kolesnikov and Harshvardhan Parashar at Securonix reported other attacks that infected organizations with LockerGoga also tapped Active Directory. "In some incidents, the actors have also been using Active Directory management services to distribute the payload in the network," they wrote, referencing additional research conducted by Nozomi Networks.

https://www.inforisktoday.com/hackers-abuse-active-directory-a-12825

Edited August 7, 2019 by itman

[itman 1,659]

Quote

Report on Ransomware

Ransomware casts a wider net to ensnare the cloud, data center and enterprise

Cybercriminals target organizations that are most likely to pay larger ransoms to regain access to encrypted files. This can be particularly catastrophic for cloud service providers.

The fallout from ransomware attacks against cloud service providers is far more devastating when the business systems of every cloud-hosted customer are encrypted. It’s an efficient, premeditated criminal threat with a rapid close and no middleman.

The Spotlight Report on Ransomware also reveals:

• Attackers easily evade network perimeter security and perform internal reconnaissance to locate and encrypt shared network files.
• Encrypting files that are widely available on the network is faster and more efficient than encrypting files on every single host device.
• Cybercriminals target organizations that are most likely to pay larger ransoms to regain access to encrypted files.
• Recognizing ransomware behaviors early in the attack can prevent propagation and the malicious encryption of files.

The Spotlight Report on Ransomware is based on observations and data in the 2019 Black Hat Edition of the Attacker Behavior Industry Report from Vectra.

https://www.vectra.ai/download/2019-spotlight-report-on-ransomware

Edited August 7, 2019 by itman

[novice 20]

10 hours ago, itman said:

Although the device had no Internet connectivity it is assumed it had internal network connectivity. The attacker gained access to the network via RDP or other means; most likely the server. Access to the this device was gained from the compromised network device. As such, he could have disabled Eset's real-time and HIPS protection and forced a reboot for the device. At this point, Eset's ransomware protection is disabled and the ransomware could run the unimpeded.

Was Eset's GUI settings on this device password protected?

Also in theory, Windows Defender real-time protection should have been enabled when Eset's was disabled. So assume the attacker disabled it which is rather trivial to do unless you are running ver. 1903 and WD's tamper protection had been previously manually enabled. Of course, the only way that can be done is if WD's real-time protection had been previously enabled. Note that by default tamper protection is disabled. Finally even if tamper protection was enabled, it could be manually disabled. Unlike Eset, WD has no password protection for its settings.

If you are running either Windows Server 2008 R2 or Windows Server 2008, have you applied the OS patches against the BlueKeep worm?

So is either your sophisticated unproved theory OR much simpler one: ESET failed to protect against that specific ransomware ...

[itman 1,659]

2 minutes ago, novice said:

So is either your sophisticated unproved theory OR much simpler one: ESET failed to protect against that specific ransomware ...

Definitely trolling. Time for you to be banned.

[novice 20]

9 minutes ago, itman said:

Definitely trolling. Time for you to be banned.

What about proving me wrong rather than banning , ah?

 

 

[Marcos 5,074]

ESET didn't fail to protect the user. This is proved by the fact that ESET had recognized the ransomware for a long time before the user got infected which means that ESET must have been paused or otherwise deactivated by an attacker.

Because of continual trolling despite giving numerous warnings and complaints from other users, we'll ban Novice as of now.

[roga 0]

1 hour ago, Marcos said:

ESET didn't fail to protect the user. This is proved by the fact that ESET had recognized the ransomware for a long time before the user got infected which means that ESET must have been paused or otherwise deactivated by an attacker.

Hi @Marcos

Eset wasn't "deactivated by an attacker" as such in my case, EEA appears to have been deactivated by the malware, i.e. it is not as though a person paused protection and then the computer was attacked. BTW HIPS and " enable detection of potentially unsafe application" was on and everything else up to date.

So can I ask when you say "ESET had recognized the ransomware", in theory should ESET have recognised the malware attempting to disable EEA? (Perhaps my variant of the worm hadn't been recognised yet)

Edited August 8, 2019 by roga