Eset keep warning detected and cleaned the malware

[3D Joe Ng 0]

efsw_logs.zip

Dear Team,

I have 1 server window 2019 standard happen Eset alert this few days. I think this server infected malware. I delete Task Scheduler also. But keep happen at night Eset will detected and deleted again. Would you mind help to check and teach me delete which task scheduler. Thank you.

Edited December 12, 2022 by 3D Joe Ng

[Marcos 5,451]

This one will be tough to remove since it's likely stored directly in a database.

[itman 1,801]

What is notable based on the posted screen shots is the hash for each PowerShell malware detected by Eset is unique.

Next you stated:

12 hours ago, 3D Joe Ng said:

I delete Task Scheduler also. But keep happen at night Eset will detected and deleted again.

Do you mean you disabled task scheduler not to run during non-business evening hours? If that is the case and the malware attacks continue at night, then the attack source is not a scheduled task.

More likely, you are being subjected to a remote network attack during the evening hours with the attacker assuming it will be less likely to be detected.

Have you applied all the latest Win updates to your Win server 2019 OS installation? Especially, any related to SQL Server vulnerabilities? Also, Microsoft has a tool that will check for SQL Server configuration vulnerabilities here: https://learn.microsoft.com/en-us/sql/relational-databases/security/sql-vulnerability-assessment?view=sql-server-ver16 .

Edited December 12, 2022 by itman

[JamesR 58]

@3D Joe Ng I will be sending you a direct message shortly with some steps to help you move closer to a clean environment.  What you have looks to be an MS SQL persistent threat.  These are not simple clean up.  These occur when MS SQL management ports (1433-1434) are exposed to the internet, and administrative credentials are successfully guessed and used.

The way MS SQL persistence works, is that it can execute commands and/or scripts using an assortment of Stored Procedures which will either execute at certain time intervals or when certain actions occur on a SQL server.  This can make them feel like they are scheduled tasks.

What leads me to believe this is an SQL persistent threat?  Its because one of your screenshots shows the main SQL process is involved in causing the detection (.\sqlservr.exe).

[itman 1,801]

Here's a couple of articles on properly securing SQLServer installations:

https://www.netwrix.com/sql_server_security_best_practices.html

https://blog.quest.com/13-sql-server-security-best-practices/

Of note:

Quote

4. Configure a server to listen on a different port

Microsoft SQL Server uses the default port 1433 for all database connections. It is a common security risk in many database environments because database professionals typically do not change the default port. It is a well-known port, and intruders can utilize this opportunity to access SQL Server. Therefore, you should use a non-default port to harden your SQL Server security.

 

Edited December 13, 2022 by itman

[JamesR 58]

I do not recommend simply changing the port any service uses.  It is to simple to run a port scan on all ports to identify the service which is running on them and does not stop an attack on any service which is exposed to the internet.

It would be better to close easily brute forced ports/services off from any inbound public IPs.  If you do need to have the port open to the internet, it should be restricted only to allow specific public IP addresses, otherwise, you will end up having password guessing attacks occur.  This holds true for SQL, RDP, SMB, SSH, and many many other services.

If you change the default port, and expose it to the internet, you have opened the door to being attacked.

[itman 1,801]

2 hours ago, JamesR said:

It is to simple to run a port scan on all ports to identify the service which is running on them and does not stop an attack on any service which is exposed to the internet.

Commercial and some home gateways/routers have IDS capability to prevent port scanning, Also, Eset is supposed to have like IDS protection.

Edited December 13, 2022 by itman

[3D Joe Ng 0]

Dear itman,

I have been changed SA password and try to disable SA account to testing.

[JamesR 58]

@3D Joe Ng

While hardening your SQL Server is a very good idea, there is a good chance that persistence was already added to the SQL server and that detections by ESET will continue until the persistence is removed.  In my last DM to you, I provided a simple way to log SQL persistence.

Where you able to run the final batch file I provided?  If yes, can you please supply the zip file generated?

There are many types of SQL Persistence, and if your MS SQL is hosting more than one instance, each instance will need to be checked.  There are the following types of MS SQL persistence:

• Stored Procedures
  • At start of MS SQL service, a procedure will start and execute ever certain amount of seconds/minutes/hours
  • A stored procedure can be "encrypted" to hide its definition from being easily seen
  • More info on Stored Procedures here: https://blog.netspi.com/sql-server-persistence-part-1-startup-stored-procedures/
• Triggers
  • DDL Triggers - Data Definition Language Triggers
    • Server based triggers which can be set to execute when specific queries like CREATE, ALTER, or DROP are used
    • These triggers can be "encrypted" to hide the definition from being easily seen
  • DML Triggers - Data Manipulation Language Triggers
    • Database based triggers which can be set to execute on specific queries like INSERT, UPDATE, or DELETE
    • Untested if these can be "encrypted" but it should be assumed that they can be encrypted as well
  • Logon Triggers
    • As their name implies, these are triggers which execute queries whenever a user logs in to MS SQL. And can theoretically, prevent a user from logging in.
    • Untested if these can be "encrypted" but it should be assumed that they can be encrypted as well
  • More info on Triggers here: https://blog.netspi.com/maintaining-persistence-via-sql-server-part-2-triggers/
• Other notes
  • In order to allow MS SQL to execute external applications, the use of advanced options is needed.  You will want to check and disable these settings (Ensure you make not of what you changed, and monitor your SQL server for any issues afterwards.  Your SQL server may have legitimately been using these settings)
    • "show advanced options" - Allows the following settings to be used
    • "xp_cmdshell" - Allows MS SQL to directly execute external applications like Ping.exe or any other executables on disk.
    • "Ole Automation Procedures" - Allows MS SQL to execute Windows Script Host and VBScript macros, which allows wscript.shell to execute other executables on the computer's disk, without the use of xp_cmdshell.
    • "clr enabled" - Allow you to store .net code inside of SQL which can be executed by a stored procedure. This is one of the more powerful ways of providing code execution to SQL. But these should easily be spotted when reviewing all stored procedures on a server.

[3D Joe Ng 0]

Dear JamesR,

When i run the .bat has been blocked by TRAPS Antivirus software. I still waiting security team reply.

Thanks your follow.

[itman 1,801]

39 minutes ago, 3D Joe Ng said:

When i run the .bat has been blocked by TRAPS Antivirus software.

Are you aware that TRAPS ESM is both end-of-life and an unsupported product: https://docs.paloaltonetworks.com/traps ?

Do you have it installed on your Win server installation?

Also, the same applies to TRAPS endpoint solution: https://www.paloguard.com/Endpoint-Protection.asp

Edited December 14, 2022 by itman

[3D Joe Ng 0]

Dear itman,

Yes,it's end point product and installed on window server longtime ago.

[itman 1,801]

3 hours ago, 3D Joe Ng said:

Yes,it's end point product and installed on window server longtime ago.

Note  that TRAPS never supported Win Server 2019. I advise you uninstall it.