Infection Chain

This infection chain began with me making a GET request for usde.php at serene.rushpcb.co.uk. Inspection of the file shows that the domain it is acting as a gate. However, due to lack of resources (i.e. no packets and logs), I don’t know how the user was redirected to this page. It could’ve been from malvertising, from a malicious link (in an email or otherwise), or it could have been from a compromised website. At this point I’m really not sure.

Viewing the source shows the following injected script:

Some people might have noticed that the injected script returned by usde.php is identical to those used by previous Good Man gates as well as compromised websites that had been redirecting users to Good Man gates. For example, below is an image taken from a Good Man gate, which was documented by Brad at malware-traffic-analysis.net.

The script is designed to redirect traffic to exploit kit landing pages. The landing page will then determine if your host is exploitable. Successful exploits will result in the malware payload being sent to your host.

During my investigation I did two runs, back to back, so RIG dropped d0x936yo.exe (1st run) and 3efgsu69.exe (2nd run) in %Temp%. Both files were 223 KB in size and produced the same hash value, making them identical payloads. The malware payload delivered by RIG EK is Pony (thanks to @Antelox for the ID).

Post-Infection Traffic

Immediately following the initial RIG EK payloads being dropped and executed in %Temp% the host checked-in via an HTTP POST requests to the CnC at 89.45.67.99/ppp/gate.php.

Below is an image of the Pony login panel:

Those POST requests were followed by GET requests for de.exe, aka “103900378.exe” (1st run) and “103899520.exe” (2nd run) located at 86.106.93.17/degate/. De.exe is 1,073 KB in size and was the Philadelphia ransomware payload. To read more about Philadelphia ransomware check out this article from BleepingComputer.com:

Follow up post-infection traffic shows information about my host being sent back to the CnC:

The server’s initial response returns the victim ID (13 characters, alphanumeric), followed by a BTC wallet address and then by the ransom amount (0.3). You will also notice the continuous status updates throughout the encryption process. For example:

Once completed the host will check-in with the status update “Ransom+window”:

Note:
If you’re looking at Figure 1 you will likely notice that there were duplicate POST and GET requests. This is due to the fact that I had received two identical payloads from RIG EK. Normally a user would only receive one, which would have resulted in only one GET and POST request.

File System

Below is an image of my %Temp% folder after the infection:

Apart from the malware payloads being dropped in %Temp% you will notice various other files being created during the infection. The website zeta-two.com recently published a detailed write-up on reversing Philadelphia ransomware. That analysis describes the contents of many of these same files. To read more about that click HERE.

Another thing to note is that executables dropped in %Temp% were appended with .locked, even though they weren’t actually encrypted.

We also find that the malware is copied to %AppData% and runs under the name winword.exe: