We have written a number of blogs about vulnerabilities within and attacks on sites built with WordPress. And, when you consider that 34 percent of all websites in the world are built with WordPress, it’s understandable that cybercriminals will continue to focus their attention on this popular platform.
One of the most common attack vectors employed by these bad actors is to launch an XML-RPC attack. XML-RPC on WordPress, which is enabled by default, is actually an API that provides third-party applications and services the ability to interact with WordPress sites, rather than through a browser. Attackers use this channel to establish a remote connection to a WordPress site and make modifications without being directly logged in to your WordPress system. However, if a WordPress site didn’t disable XML-RPC, there is no limit to the number of login attempts that can be made by a hacker, meaning it is just a matter of time before a cybercriminal can gain access.
Recently, the Zscaler ThreatLabZ team came across a scheme to attack WordPress sites where a malicious program gets a list of WordPress sites from a C&C server which then are attacked leveraging the XML-RPC pingback method to fingerprint the existing vulnerabilities on the listed WordPress sites.
Even though we saw a payload used in this attack in our Zscaler cloud and also found a campaign of similar files on VirusTotal, we haven’t found any specific spam templates used for this campaign. Additionally, the payloads appear to be new and had no specific attribution, so we have given a new name to this program based on its activity—Win32.Backdoor.WPbrutebot.
In our research, we found several samples pertaining to this campaign but we analyzed one sample here for brevity and as an example.
In the sample set we worked on, we found that almost all samples used Microsoft-version information, but all of them lack a legitimate Windows Digital Signature and left the company name as TODO, which implies that these files are being generated through a script and this section is still a work in progress.
Figure 1: The common metadata used in most files in this campaign.
Another feature we found was that InternalName was always a sequence of 2s. Unfortunately, we weren’t able to conclude if this was intentional or not.
The initial layer of the malware is for decoding the URIs used to make initial contact with the C&C server.
The first section is unpacked as shown in Figure 2:
Figure 2: The decryption loop of this program.
This decryption loop is a simple XOR decryption that sequentially runs from B5 to C7, which gives us /lk4238fh317/update.php.
Figure 3 shows the debugger dump.
Figure 3: The decrypted string of this program.
Next, the domain is generated using another XOR-based decryption where the key goes from B5 to C0.
Figure 4: The decryption loop for this program.
The domain generated is k6239847[.]lib. This URL is then used with blockchain DNS.
Figure 5: The DNS query.
The blockchain DNS URI is decrypted using a similar XOR loop as shown in Figure 6. The value compared depends on the size of the blockchain DNS URI.
Figure 6: The decryption loop.
These are first assembled in heap using RtlAllocateHeap.
Figure 7: The decrypted strings.
The code shown in Figure 8 is called several times to allocate heap to save decrypted strings that are used later to perform network activity or for creating files.
Figure 8: The API call details.
This same code is reused to assemble user-agent strings, which are later used for making internet connections.
Figure 9: The user-agents employed in this attack.
This is then used to create a DNS request for the blockchain DNS server.
Figure 10: The concatenated URL.
The DNS request generated produces a C&C IP of 217.8.117[.]48, which can be confirmed online at explorer.emercoin[.]com/nvs/dns.
Figure 11: The domains found at emercoin.com.
The segment of a URL created during the first decryption loop (as shown above) is then used with the IP address to contact the C&C. The URL created is 217.8.117[.]48/lk4238fh317/update.
The C&C then replies back with 217.8.117[.]48/j537djjlhg763/svchst.exe, which is the downloaded payload. The payload is downloaded at C:\Users\User-Name\AppData\Roaming\svchst.exe.
Figure 12: The program downloading an updated version of itself.
The downloaded sample (MD5:86374F27C1A915D970BE3103D22512B9) is an updated version of the parent sample, which downloads itself to ensure that the latest version of the malicious program is running on the system. This sample also performs a DNS query on k6239847[.]lib. The string is obfuscated by breaking the string in two parts—k623 and 9847.lib, which are concatenated in memory.
This time, a command is run using cmd.exe /C ping 126.96.36.199 -n 1 -w., where -n means the number of echo requests to send and -w is the timeout in milliseconds to wait for each reply. 188.8.131.52 is popular DNS service by Cloudflare.
The full command is cmd.exe /C ping 184.108.40.206 -n 1 -w -n 1 -w3000 > Nul & Del /f /q \"%s.
The program then enumerates system information including information such as user name, processor architecture, and more.
Figure 13: The algorithm to initiate the /xmlrpc.php attack.
Figure 14: The attack vectors found in the file.
Here, the malicious program is using <methodName>wp.getUsersBlogs</methodName> to execute a brute force attack via the “wp.getUsersBlogs” method of xmlrpc.php where an attacker is actually doing a reverse IP lookup for the IPs fetched from the C&C and is looking for all the available methods on the corresponding DNS. Once found, it attempts to gain the login via cookie-based authentication by logging into WordPress using cURL, authenticating the server (which ran the cURL script) and providing the username/password to the login page of the desired WordPress site.
Here is a redacted list of a few WordPress sites the attacker is trying to attack leveraging this malware payload:
Figure 15: The list of WordPress sites targeted for a brute force attack.
We then went on hunting for similar samples. We were able to unearth more samples connecting to the same domains (k6239847.lib) and IP address (220.127.116.11). The samples we found had similar activity but used a .space TLD domain as one of its C&C.
Cloud Sandbox detection
The malware payload was successfully detected and blocked by the Zscaler Cloud Sandbox as seen in the Figure 16.
Figure 16: The Zscaler Cloud Sandbox successfully detected the malware.
Advanced Threat Signature name:
Due to its popularity, WordPress is a common target for cyberattacks. As such, WordPress admins need to be on alert to reports of newly found vulnerabilities and attacks. In addition, WordPress admin should keep the XML-RPC option disabled and refrain from using logins from third-party applications.
Zscaler continues to protect our customers from such attacks and detects these malicious programs in our Cloud Sandbox in real time.
MITRE ATT&CK TTP Mapping
Modify Authentication Process
OS Credential Dumping