DecryptedTech

Wednesday06 July 2022

IAG Prophet Spider Targeting VMWare Horizon Servers Via Log4J Vulnerability


Reading time is around minutes.

A shell for me, a shell for you, a shell for everybody in the room. If you have not heard about Log4J and the associated vulnerabilities in versions between 2.0 and 2.16 you might have not been near a computer in quite a while. This Remote Code Execution vulnerability that has several CVEs (common vulnerabilities and exploits) associated with it is commonly lumped into the term Log4Shell. Log4J itself is a Java based Apache logging framework that is in widespread usage in many applications. The list of impacted applications is not, and may never be, known. Many vendors have release complex mitigation steps and patches, but many devices are not getting patched (nothing surprising here). This has allowed this vulnerability to become quickly weaponized and used in targeted attacks.

The first stage of the attack is to utilize exposed JNDI requests found in Log4J 2.0-2.16 to get the target system to execute a Base64 Encoded PowerShell script. The encoded portion contains the strings to download the payload. In most cases the attackers were observed to install crypto miners, although other malicious software/tools are possible including ransomware. The most common persistence mechanism was a scheduled task was created on the targeted system via a script. For more stealthy attacks attackers would leverage a webshell to maintain control over the system.

Although there have been a few groups targeting this attack one group, known as Prophet Spider. They are categorized as an Initial Access Group (IAG). An IAG will typically compromise hosts so that they can sell access later. Prophet Spider is known to sell access specifically for targeted ransomware attacks. Their attack patterns (TTPs) have been identified by the researchers at BlackBerry Research & Intelligence as well as their Incident Response (IR) teams.

The log4J/Log4Shell vulnerability with its ease of exploit and flexibility in payloads you can push is still a serious concern as many organizations are still not patching their known vulnerable systems. In top of this we are (still) seeing exposed VMWare Horizon servers as well as other hosts that are known to still be vulnerable to this exploit. This is despite massive efforts on the part of the security industry to respond to the original 0-Day. While there are next gen antimalware solutions that can stop the malicious pivot, patching ore disabling the exposed JNDI function is the only real way to ensure this vulnerability is not exploited in your environment.

Leave a comment

Make sure you enter all the required information, indicated by an asterisk (*). HTML code is not allowed.