unable stop virus

[itman 1,659]

1 hour ago, JigneshC said:

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

As far as I am aware of, none do. It is not their function to ensure a network is properly secured from unauthorized external access using a legitimate Windows feature to do so.

What they all do however is post multiple blog, security configuration articles, etc. on first, avoidance of RDP use, and second, on how to properly secure it if one still chooses to use it. The most basic of these security mitigations is to employ Windows Security Policy to control number of attempted logon attempts with subsequent account lockout as I have shown and repeatedly referenced in this posting: https://forum.eset.com/topic/20215-ransomeware-adage/?do=findComment&comment=98416

Edited September 13, 2019 by itman

[Marcos 5,070]

Quote

As far as I am aware of, none do.

Something is brewing here but until it's confirmed that it works without issues in real-world scenarios, I'd better not talk much about it. However, RDP is definitely an area that we'd like to have covered too. When there is some news to share publicly, we'll announce it.

[JigneshC 0]

31 minutes ago, Marcos said:

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.

Marcos,

 

that is what we are making you understand and putting the matter under your eyes that if the file has been downloaded for bruteforce, run script break the admin password, disable all protection.. what ESET was doing till the time.. after this what happened, we all are aware. We want to know what it was doing till it Real-Time protection was enabled.

 

Have given all full admin access with eset credential to your team and there is nothing after that as a result after 48Hrs and have to sit 4hrs to get solution along with folks of security(however i have eset the security organisation) which creates bad impression which was not in me. we have made him understood about the antivirus functions in market and their facility which are not well reputed as eset is, still they give facility to restore all the data withing 5-6Hrs. At other side we have given entire matching for approx. almost 2 days whenever they demanded with no time limit but no solution which is not good.

[JigneshC 0]

29 minutes ago, itman said:

As far as I am aware of, none do. It is not their function to ensure a network is properly secured from unauthorized external access using a legitimate Windows feature to do so.

What they all do however is post multiple blog, security configuration articles, etc. on first, avoidance of RDP use, and second, on how to properly secure it if one still chooses to use it. The most basic of these security mitigations is to employ Windows Security Policy to control number of attempted logon attempts with subsequent account lockout as I have shown and repeatedly referenced in this posting: https://forum.eset.com/topic/20215-ransomeware-adage/?do=findComment&comment=98416

PLEASE FIRST STOP YOURSELF FROM BLAMING ON RDP. RPD PASSWORD HAS NOT BEEN GIVEN BY CLIENT TO ATTACKER. WANT TO KNOW WHY ESET DIDN'T NOTIFY OF BRUTEFORCE

PLEASE FOCUS ON AVOIDING IN FUTURE INSTEAD OF KEEP BLAMING ON RDP SINCE LAST 48 HRS WITHOUT SOLUTION OF DATARECOVERY.

[Marcos 5,070]

If an attacker is able to log in via RDP with administrator rights, he or she can:
- pause protection if not protected with a password
- use legitimate tools to disable or uninstall AVs if detection of pot. unsafe applications is disabled.

Again, the primary issue was with the RDP breach so the user didn't have RDP secured. It's possible to harden ESET against further manipulation but hardly anyone protects settings with a password or enable detection of PUsA (which would not be needed if attackers couldn't gain remote access in the first place).

I have no clue what solution are you trying to find since files are irreversibly encrypted. The user can only:
1, restore files from a backup (which probably doesn't exist)
2, pay the ransom to get a decoder (without warranty and we don't recommend it either).

[Marcos 5,070]

2 minutes ago, JigneshC said:

PLEASE FIRST STOP YOURSELF FROM BLAMING ON RDP. RPD PASSWORD HAS NOT BEEN GIVEN BY CLIENT TO ATTACKER. WANT TO KNOW WHY ESET DIDN'T NOTIFY OF BRUTEFORCE

PLEASE FOCUS ON AVOIDING IN FUTURE INSTEAD OF KEEP BLAMING ON RDP SINCE LAST 48 HRS WITHOUT SOLUTION OF DATARECOVERY.

First of all, please stop using capitals which is generally considered as shouting in forums.

Secondly, as @itman stated:

Quote

As far as I am aware of, none do. It is not their function to ensure a network is properly secured from unauthorized external access using a legitimate Windows feature to do so.

It's the responsibility of IT admins to secure the system and prevent RDP breaches; it's not what antivirus software is supposed to do in the first place. Also according to @itman who is an advanced experienced user and who doesn't work for ESET, you should not blame ESET for this.

[JigneshC 0]

31 minutes ago, Marcos said:

If an attacker is able to log in via RDP with administrator rights, he or she can:
- pause protection if not protected with a password
- use legitimate tools to disable or uninstall AVs if detection of pot. unsafe applications is disabled.

Again, the primary issue was with the RDP breach so the user didn't have RDP secured. It's possible to harden ESET against further manipulation but hardly anyone protects settings with a password or enable detection of PUsA (which would not be needed if attackers couldn't gain remote access in the first place).

I have no clue what solution are you trying to find since files are irreversibly encrypted. The user can only:
1, restore files from a backup (which probably doesn't exist)
2, pay the ransom to get a decoder (without warranty and we don't recommend it either).

Marcos,

my focus was always there on data recovery by eset if it was not able to protect me against bruteforce or password has been compromised when eset protection was enabled.

Concern is after giving access of my infected machine and no solution after 3 days with my up and running live network which is in same network and not infected. we have to find the solution(however we did recover too without giving single bugs to attacker), that is PAINFUL as non security guys.

this is not for story but yeah NPAV did in past for one the telly machine(of one of client of NPAV's reseller) where telly server had ransom attack and they gave all data back as it was before as they are taking backup by their AV. Please check if you don't trust.

Edited September 13, 2019 by JigneshC

[JigneshC 0]

4 minutes ago, Marcos said:

First of all, please stop using capitals which is generally considered as shouting in forums.

Secondly, as @itman stated:

It's the responsibility of IT admins to secure the system and prevent RDP breaches; it's not what antivirus software is supposed to do in the first place. Also according to @itman who is an advanced experienced user and who doesn't work for ESET, you should not blame ESET for this.

it is very much secured marcos, that is why my all systems are not impacted.

 

systems were impacted where eset was. other systems where other antivirus was and without antivirus including my server where these servers are hosted, are UP and RUNNING.

[Marcos 5,070]

We do not provide data recovery services.

We would have protected the user provided that they had the system secured, preventing attackers from exploiting RDP. Our protection were not most likely password protected so the attacker could easily pause protection. Again, not ESET's fault.

I don't know what solution you were trying to find if the user had no backup created. The only solution is to pay the ransom and get a decoder with no warranty which we do not recommend.

[itman 1,659]

One example among many on how an attacker can use RDP maliciously:

Quote

Use Remote Port Forwarding to Slip Past Firewall Restrictions Unnoticed

In this article, we'll be using SSH to access the remote desktop on a host located behind a firewall in an internal network — all without modifying the port forwarding rules on the gateway!

The Situation

The shell is a Netcat connection running cmd.exe. The user "bob" is not a privileged user. Through prior information gathering, I know that the user "barrow" is a privileged user, and I also know that this machine has a remote desktop connection available.

It would be excellent to log into this machine via a remote desktop as an administrative user, but it is non-routable to my machine. Our compromised machine is behind a router, with an internal IP address, and I don't have access to the internal network, except via the internal host.

I can use the reverse shell to interact with the compromised host, but if I attempt to connect to a remote desktop, the IP address will be invalid. If I use the public-facing IP address, I will be connecting to a router which will just drop my packets. Since I don't have an SSH server on this network that I can pivot with, I'll have to use Plink to forward the remote desktop service to my attacking machine.

https://null-byte.wonderhowto.com/how-to/use-remote-port-forwarding-slip-past-firewall-restrictions-unnoticed-0179716/

BTW - plink.exe is a legitimate executable and will not be detected by Eset as malicious. Attacker drops his reverse shell - Netcat is a legit Windows process plus plink.exe and bingo - you're nailed.

Edited September 13, 2019 by itman

[JigneshC 0]

1 hour ago, Marcos said:

We do not provide data recovery services.

We would have protected the user provided that they had the system secured, preventing attackers from exploiting RDP. Our protection were not most likely password protected so the attacker could easily pause protection. Again, not ESET's fault.

I don't know what solution you were trying to find if the user had no backup created. The only solution is to pay the ransom and get a decoder with no warranty which we do not recommend.

That you say now to protect the reputation of ESET. Believe, then it will be useless to use ESET. Better to use NPAV / QH who atleast don't focus on blaming, they do recover the data if the mess happened in presence of their solution.

 

No more words for you guys and can't do more put matters under your eyes to make some good. 

[JigneshC 0]

32 minutes ago, itman said:

One example among many on how an attacker can use RDP maliciously:

https://null-byte.wonderhowto.com/how-to/use-remote-port-forwarding-slip-past-firewall-restrictions-unnoticed-0179716/

BTW - plink.exe is a legitimate executable and will not be detected by Eset as malicious. Attacker drops his reverse shell - Netcat is a legit Windows process plus plink.exe and bingo - you're nailed.

No man.. 

my focus was on eset to make proper for future business by accepting single lose. but no they dont want to accept the problem that they didn't do any till 48 hrs. can't do more for them after being a victim from attacker.

[JigneshC 0]

Did i say anywhere that it is not RDP attack? why are you not seeing that only 2 system with ESET got mess not others?

[Marcos 5,070]

2 hours ago, JigneshC said:

Did i say anywhere that it is not RDP attack? why are you not seeing that only 2 system with ESET got mess not others?

You've now admitted it was an RDP attack, ie. you didn't have RDP properly secured. Had it been secured, RDP attack attempts would have failed.

Real-time protection was disabled on the compromised machine, ie. recognized and known ransomware could run undetected. Again, this would not have been possible if ESET was secured and settings were protected with a password.

From the logs it's obvious that the ransomware was detected and blocked in the first place.

"@NAME=Win32/Filecoder.Phobos.C@TYPE=Trojan@SUSP=mod"    08.08.2019  

Note that Win32/Filecoder.Phobos.C was detected on the machine on Aug 8, 2019.

Taking the very same sample and scanning revealed that the ransomware sample has been recognized and detected by real-time protection and on-demand scanner (not taking into account other protection mechanisms, such as AMS, Ransomware shield, etc.) as of June 24, 2019.

 

ECLS Command-line scanner, version 7.0.2097.0, (C) 1992-2018 ESET, spol. s r.o.
Module scanner, version 19576 (20190624), build 41844

name="7954bba17a210ef1b17dfddbb4d38c15b0d013c6", threat="a variant of Win32/Filecoder.Phobos.C trojan", action="", info=""

 

That said, it's not true that ESET was unable to protect you and the above proof only confirms that unless you start to understand the issue, your system will get compromised again and again no matter what security solution you get unless you secure RDP and other possible vectors of infection. We all are trying to help you understand what the issue is and help you better protect your machines.

[JigneshC 0]

2 hours ago, Marcos said:

You've now admitted it was an RDP attack, ie. you didn't have RDP properly secured. Had it been secured, RDP attack attempts would have failed.

Real-time protection was disabled on the compromised machine, ie. recognized and known ransomware could run undetected. Again, this would not have been possible if ESET was secured and settings were protected with a password.

From the logs it's obvious that the ransomware was detected and blocked in the first place:

"@NAME=Win32/Filecoder.Phobos.C@TYPE=Trojan@SUSP=mod"    08.08.2019  

Note that Win32/Filecoder.Phobos.C was detected on the machine on Aug 8, 2019.

Taking the very same sample and scanning revealed that the ransomware sample has been recognized and detected by real-time protection and on-demand scanner (not taking into account other protection mechanisms, such as AMS, Ransomware shield, etc.) as of June 24, 2019.

 

ECLS Command-line scanner, version 7.0.2097.0, (C) 1992-2018 ESET, spol. s r.o.
Module scanner, version 19576 (20190624), build 41844

name="7954bba17a210ef1b17dfddbb4d38c15b0d013c6", threat="a variant of Win32/Filecoder.Phobos.C trojan", action="", info=""

 

That said, it's not true that ESET was unable to protect you and the above proof only confirms that unless you start to understand the issue, your system will get compromised again and again no matter what security solution you get unless you secure RDP and other possible vectors of infection. We all are trying to help you understand what the issue is and help you better protect your machines.

Marcos.. you play with ESET flag.. don't want to argue with you.. i know that you will not allow your flag down. let you play with flag on height and shout that it is not eset problem however am not here to convince that it is eset or rdp.. came to you for solution but as always vendors MNC is not there to understand. please reread what you found until you understand the problem.

"Kid doesn't understand what is balance until they fall"

 

Warn: "information and collected logs are not for to announce in public without written my permission, please don't do to make you correct"

[itman 1,659]

Appears there are two ongoing issues; a brute force RDP attack and a complaint about Eset's response to the incident. In regards to the later, one is better served resolving that matter off-line and removed from this forum.

Since it has been determined that a brute force RDP attack occurred, that fact alone is enough to determine the network was compromised. As such, any type of malicious activity could have occurred non-withstanding a least two known ransomware attacks. As @Marcos previously mentioned unless proper network security measures are employed by this installation to prevent not only brute force RDP attacks but all unauthorized network penetration, this installation will continue to be repeatedly attacked and its network compromised.

Edited September 13, 2019 by itman

[Marcos 5,070]

5 minutes ago, itman said:

a complaint about Eset's response to the incident. In regards to the later, one is better served resolving that matter off-line and removed from this forum.

I'd add that no confidential or private information from logs were disclosed. Since we were blamed in a public forum after responding in a private ticket at samples[at]eset.com, we had to defend and give proofs, of course, without disclosing any confidential information.

[peteyt 393]

4 hours ago, Marcos said:

Something is brewing here but until it's confirmed that it works without issues in real-world scenarios, I'd better not talk much about it. However, RDP is definitely an area that we'd like to have covered too. When there is some news to share publicly, we'll announce it.

I am curious - I don't know a lot about networking and RDP but have been wondering for a while if there would be a way an AV could warn users if RDP was not secure etc. I'm not sure if this is what you are hinting at and I know you can't say a lot at the moment but I do think if it is it could fix the issue that a lot of ransomware posts seem to be related to.

[peteyt 393]

4 hours ago, JigneshC said:

PLEASE FIRST STOP YOURSELF FROM BLAMING ON RDP. RPD PASSWORD HAS NOT BEEN GIVEN BY CLIENT TO ATTACKER. WANT TO KNOW WHY ESET DIDN'T NOTIFY OF BRUTEFORCE

PLEASE FOCUS ON AVOIDING IN FUTURE INSTEAD OF KEEP BLAMING ON RDP SINCE LAST 48 HRS WITHOUT SOLUTION OF DATARECOVERY.

It has probably been mentioned on here - but Itman and others have pointed out you can set RPD to get locked out after a set amount of failed logins - I'm just guessing but presume you do not have this set up as Brute force appears to have been used so adding this could avoid this in the future

[Marcos 5,070]

1 minute ago, peteyt said:

I am curious - I don't know a lot about networking and RDP but have been wondering for a while if there would be a way an AV could warn users if RDP was not secure etc. I'm not sure if this is what you are hinting at and I know you can't say a lot at the moment but I do think if it is it could fix the issue that a lot of ransomware posts seem to be related to.

It can prevent RDP bruteforce attacks which can be also accomplished by setting up an account lockout policy that has been supported by Windows for a long time.

[peteyt 393]

1 minute ago, Marcos said:

It can prevent RDP bruteforce attacks which can be also accomplished by setting up an account lockout policy that has been supported by Windows for a long time.

Ah I see - at least if it works it will stop people blaming eset - Would there be a way to set it up possibly to do a check - e.g. so users could see a warning that RDP is enabled, hasn't got a password etc. 

[JigneshC 0]

1 minute ago, peteyt said:

It has probably been mentioned on here - but Itman and others have pointed out you can set RPD to get locked out after a set amount of failed logins - I'm just guessing but presume you do not have this set up as Brute force appears to have been used so adding this could avoid this in the future

Yes Peteyt,

simply AV learns reads all logs of system. they just need to notify to the client on the contact details which they are taking at time of activation, so that time this could be prevented. no one is ready to take that catch here.

[peteyt 393]

8 minutes ago, JigneshC said:

Yes Peteyt,

simply AV learns reads all logs of system. they just need to notify to the client on the contact details which they are taking at time of activation, so that time this could be prevented. no one is ready to take that catch here.

As mentioned I'm not sure if any/many av's can do much about this right now. It relates to something I have been saying for years - too many people rely on their AV too much - for example I use Windows 10 because it's security is far better than previous versions and I think anyone using older unsupported OS's e.g. XP are just looking to put their systems at risk

[itman 1,659]

6 minutes ago, JigneshC said:

simply AV learns reads all logs of system. they just need to notify to the client on the contact details which they are taking at time of activation, so that time this could be prevented.

Pure unmitigated "rubbish."

As a primer, have the customer start here: https://docs.microsoft.com/en-us/windows-server/identity/software-restriction-policies/software-restriction-policies-technical-overview . Then enroll in the like Microsoft courses in the same subject matter. If they are unwilling to do so, then they need to contract out to a competent and certified source to perform those activities. 

[JigneshC 0]

4 minutes ago, itman said:

Pure unmitigated "rubbish."

As a primer, have the customer start here: https://docs.microsoft.com/en-us/windows-server/identity/software-restriction-policies/software-restriction-policies-technical-overview . Then enroll in the like Microsoft courses in the same subject matter. If they are unwilling to do so, then they need to contract out to a competent and certified source to perform those activities. 

Yes Itman,

 

you are spared to learn and making up the policy for individual 200 individual cloud machines of multiple clients. if all things needs to be managed by windows why AV is required. Forgot that client information while activation is being taken not for notification, it is just for making renewal business as per you then. say slowly that it has defender, no need  AV