Setting the Scene
During this past week Zepko Analysts decided to try to track down ransomware threat actors using a different approach.
Zepko were recently approached by a company who were hit with ransomware which was identified by Zepko Analysts as a variant of CrySiS ransomware using file extensions .dharma, .wallet or .zzzzz.
Analysts have had previous experience dealing with CrySiS ransomware and discovered that the Threat Actors often use RDP brute force attacks to login, kill the antivirus and monitoring processes, then execute the ransomware payload. To find out more regarding ransomware over RDP attacks visit https://news.zepko.com/ransomware-over-rdp/
Leading on from this, as we know, most ransomware types leave a contact email address in the ransom note or in the file extension, which is used as a direct point of contact with the Threat Actor. This is the email address to directly talk about the payment methods, usually in return for a decryption tool for the encrypted files. In this correspondence Threat Actors also sometimes offer to decrypt one or two files to prove they are able to decrypt files as promised.
Using the email address in the ransom note, Analysts attempted to see if it was possible to somehow use this direct contact with the Threat Actor as a way of tracking them down.
To do this they decided to use a method utilising the STUN protocol, otherwise known as Simple Traversal of User Datagram Protocol (UDP) through Network Address Translators (NAT’s)). Quite a mouthful.
The protocol has a number of different uses but simply put, STUN is a tool which can be used to detect and traverse NATs that are located between two endpoints. When a blinding request is sent over UDP from a client operating from a private network, the STUN server responds with the IP and port number of the client. A full, (and much better) explanation of the STUN Protocol can be found on Wikipedia at https://en.wikipedia.org/wiki/STUN.
To perform a stun request on a ransomware Threat Actor, Analysts used a hidden PHP script in an image to perform the STUN request once a link is clicked by the Threat Actor.
To do this, Analysts created a website with a webpage that displayed an image. This image contained the hidden PHP script that when the image is visited in a web browser it loads the PHP script and would initiate the STUN request which the response was logged containing the IP address of the person who clicked the link. This IP address would be that of the threat actor.
Because this was being sent in the form of a suspicious looking link it was highly unlikely that the threat actor would click it. To entice the Threat Actor to click the link, Analysts posed as a finance company who had been hit with the ransomware who were ready to pay the ransom.
Emailing the Threat Actor
Below is the email chain between Analysts and the Threat Actors. The email address contacted was email@example.com. Spelling mistakes and typos were purposely made throughout the email correspondence to make it appear as if the message had been sent by someone who is not especially familiar with using computers.
The response email can be seen below stating how to make a payment. It also reads that it is possible to test the decryption process using “small size” files including .jpg file types.
Our response was sent back to the Threat Actor asking if we could “test” the decryption process using a jpg file. This was “uploaded” to our webserver with a tempting title “finance_report_december_2016.jpg” which we hoped would lead the Threat Actor to click the link.
After the email was sent, Analysts waited to see if the link would be clicked and if the log file would be populated with the attackers IP address.
After around 60 seconds *click* the attacker had clicked the link and the log file now contained the Threat Actors IP.
Shortly after another email was received:
Investigating the IP
Using the IP address Analysts conducted further research to see if any other information could be discovered. The IP address was found to be managed by Talia.net, a UK Internet Service Provider.
Checking the IP on Shodan it was found that a number of ports were open, including 3389. As port 3389 was open this immediately raised suspicion that this could be another device compromised through RDP brute forcing. We immediately contacted the ISP to investigate the matter further, however, at the time of writing we had still received no reply from them.
This process was used to see if this technique would work, and as can be seen, Analysts did have some success and in the future the same process could be improved upon in the hope to track ransomware Threat Actors down with greater success.
- https://news.zepko.com/ransomware-over-rdp/ – Zepko – Ransomware over RDP
- https://en.wikipedia.org/wiki/STUN – Wikipedia