Analysts identified several infected servers hosting phishing sites. These phishing sites, imitating, for example, a Microsoft office login page, were hosted on compromised servers in the form of PHP scripts.
Web servers with different content management systems (CMS) were compromised.
Most often WordPress in various versions, including the latest one or Joomla, were affected.
Since the compromised web servers have nothing in common, analysts assume the attackers took advantage of poorly secured servers, with weak login credentials, to gain admin access to the servers, but analysts do not have enough information to confirm this theory.
The proxied version communicates with the TDS infrastructure via a malicious PHP script, usually located on the same web server, and executes the response content.
The code performs basic user filtering based on the User-Agent string, cookies and referrer. Briefly said, this code contacts the TDS only once for each user who visits the infected page. This type of filtering prevents multiple repeating requests and possible server overload.
The aforementioned PHP script serves two purposes. The first is to extract client information like the IP address, referrer and cookies, forward the request from the victim to the Parrot TDS C2 server and send the response in the other direction.
The second functionality allows an attacker to perform arbitrary code execution on the web server by sending a specifically crafted request, effectively creating a backdoor. The PHP script uses different names and is located in different locations, but usually, its name corresponds to the name of the folder it is in (hence the name of the TDS, since it parrots the names of folders).
In several cases, analysts also identified a traditional web shell on the infected web servers, which was located in various locations under different names but still following the same “parroting” pattern. This web shell likely allowed the attacker more comfortable access to the server, while the backdoor in the PHP script mentioned above was used as a backup option.
The direct version is almost identical to the previous one. This version utilises the same filtering technique. However, it sends the request directly to the TDS C2 server and, unlike the previous version, omits the malicious backdoor PHP script.
It executes the content of the response the same way as the previous version.
The Parrot TDS response is JavaScript code that is executed on the client.
In general, this code can be arbitrary and exposes clients to further danger.
However, in practice, analysts have seen only two types of responses. The first, shown below, is simply setting the __utma cookie on the client.
This happens when the client should not be redirected to the landing page. Due to the cookie-based user filtering mentioned above, this step effectively prevents repeated requests on Parrot TDS C2 servers in the future.
The user receives JavaScript that changes the appearance of the page and tries to force the user to download malicious code.
This JavaScript also contains a Base64 encoded ZIP file with one malicious JavaScript file inside. Once the user downloads the ZIP file and executes the JavaScript it contains, the code starts fingerprinting the client in several stages and then delivers the final payload.
The entire infection chain is set up so that it is complicated to replicate and, therefore, to investigate it. Parrot TDS provides the first layer of defence, which filters users based on IP address, User-Agent and referrer.
The FakeUpdate campaign provides the second layer of defence, using several mechanisms. The first is using unique URLs that deliver malicious content to only one specific user.
The last defence mechanism is scanning the user’s PC. This scan is performed by several JavaScript codes sent by the FakeUpdate C2 server to the user. This scan harvests the following information.
– Name of the PC
– User name
– Domain name
– Manufacturer
– Model
– BIOS version
– Antivirus and antispyware products
– MAC address
– List of processes
– OS version
The final payload is then delivered in two phases. In the first phase, a PowerShell script is dropped and run by the malicious JavaScript code. This PowerShell script is downloaded to a temporary folder under a random eight character name (e.g. %Temp%1c017f89.ps1). However, the name of this PowerShell is hardcoded in the JavaScript code. The content of this script is usually a simple whoami /all command. The result is sent back to the C2 server.
In the second phase, the final payload is delivered. This payload is downloaded to the AppDataRoaming folder. Here, a folder with a random name containing several files is dropped. The payloads analysts have observed so far are part of the NetSupport Client remote access tool and allow the attacker to gain easy access to the compromised machines.
The RAT is commonly named ctfmon.exe (mimicking the name of a legitimate program). It is also automatically started when the computer is switched on by setting an HKCUSOFTWAREMicrosoftWindowsCurrentVersionRun registry key.
The installed NetSupport Manager tool is configured so that the user has very little chance of noticing it and, at the same time, gives the attacker maximum opportunities.
The tool basically gives the attacker full access to the victim’s machine. To run unnoticed, chat functions are disabled, and the silent option is set on the tool, for example.
A gateway is also set up that allows the attacker to connect to the client from anywhere in the world.