After an initial recognition phase, we decided to monitor threats transiting through RDP. Now it’s time to describe our methods, prerequisites, what tools do we use, and how to store the data to produce the best of it.
This serie of articles try to demystify honeypots and provide some ideas that can maybe help you in your projects.

After a quick overview of our methods, we will present a first phase of full-scale tests ran over a short period.

RDP (Remote Desktop Protocol) is a remote control protocol for Windows.
This one is very used for remote maintenance.
RDP is highly prized by the attackers, because:

  • RDP is mostly used by companies, not by individuals (rare)
  • A RDP access allow you to be in LAN
  • A RDP access is easier to use than a shell or a backdoor
  • Today, a lot of small shops uses a computer to process the point of sales. Since these small shops are often unfamiliar with IT, maintenance of these PoS are done by service providers who, for costs’ reasons, prefer to do remote maintenance… through RDP. And unfortunately, many IT services companies do not have computer security basics and have bad practices such as low passwords and lack of 2FA etc. These kind of remote access are very targeted.


The main goal is to make a robust and automated as possible Honeypot, so our infrastructure required some prerequisites :

  • It should be able to enable network tapping
  • It should be able to retrieve and stores malwares automatically
  • It must be able to restore itself automatically
  • It must be able to collect and store the datas acquired
  • It must be robust and strong to prevent any uncontrolled compromise


This kind of honeypot could be divided into 4 parts :

  • Network
  • Endpoints
  • Data Capture
  • Data Storage

A. The network

A standard network scheme is used (192.168.0.x / 24), VM honeypots must be able to communicate with each other (to allow us to observe lateral propagation to VMs not exposed directly on the Internet) and have total Internet access which is provided to them by their gateway. This gateway is set up on a homemade bastion, which is the unique element allowing the communication between the attackers and the vulnerable machines.
The main purpose of the bastion is to be a secure router that will redirect the whole traffic coming from the VMs to outside. This traffic is redirected to a tunnel to one of our FeedFarm public IP.

B. The endpoints

  • Operating systems
    Our honeypots are virtual machines running under Windows 7 and Windows 2008 R2 that mimics usage in a professional context : by renaming them, providing them a new wallpaper and some browser activities can increase the realism of these honeypots, and so attracts and keeps the attacker on the machine as long as possible.
    The passwords and accounts used are very low, and easy to bruteforce. They even are sometimes in public lists, so the bruteforcer can easily gain an access on machine.
    However we try not to be in the bruteforce lists of worms like Morto, to avoid “well-known” infections which are already tracked (on http://benkow.cc/morto/ for example)


  • Saves and backups
    The main goal of these honeypots is obviously to be compromised. It’ a good way to train our collaborators on real forensics cases.
    So, we regularly backup the virtual machines, to allows training, but also the retention of evidence when an attacker uses our honeypot for malicious purposes.


C. Captures

  • Tshark and IPTables
    The other goal of this bastion is to capture the traffic issued from these honeypots.
    We use Tshark for this, which allows the extraction of pcap in csv format.
    However, due to stability problems, we also turned on the iptables logs to be able to exploit the light lig like “source, dest, port, etc…”


  • SplunkForwarder
    Once the logs are acquired, they are forwarded directly to Splunk via a splunkforwarder installed on the server. This allows us to quickly have logs already matching a specific index for our searches.


  • Keystrokes, screenshots RDP, clipboard
    The main goal is to capture the keystrokes, clipboard content, RDP session screenshots …., while remaining invisible by the attacker.
    Unfortunately, none of the tools we had would fit fully our needs.
    For example, none were able to retrieve a file executed from a mounted share like \\tsclient, exported logs were bad quality or like the majority of malwares, their stability was not really good…
    We had to take some time to develop a monitoring tools that suited our needs, that is modular, and where the logs output was highly customizable.
  • Network
    The network capture is only done on the bastion, which can intercept all the inbound and outbound flows, and also the flows from the machines not directly connected to Internet but accessible through the LAN network of the Honeypot, in order to detect every kind of lateral movements.


D. Storage and displaying

Logs on our Splunk are organized in several parts :

1. Honeypots traffic :

This allows us to have stats on which ports were used, destination IPs, bandwidth used. With that, we can quickly see when an attackers was caught.

2. Traffic received from outside :
The second part contains graphics we use to display stats on IP “scanning” or attacking us, as well as ports used, which as we said in our first article, are not necessarily the standard port 3389.


A. What was caught

For the moment, we have collected several kind of logs :

  • Logs for every packets (network stats)
  • Logs with every screenshots for every clicks or change of focus for the primary application…
  • Logs for every keystrokes
  • Logs for the clipboard changes
  • Logs for the machines :
    Periodically, we would dump the host machine, in case we need it to do a post-mortem forensic analysis.


B. What we want to catch in the next versions

In the future, we want to go beyond data capture and analysis. Currently, the data we get are limited to a specific scope.
We want to add the followings features to our futures captures :

  • Full packet capture (so that we can reconstruct downloaded malware in case it gets deleted from the hard disk)
  • Retrieving the Windows events (like executed command lines)
  • Get the executable from every process launched by the attacker on the host machine.


From the implementation of our honeypots, we saw two major phases :

A. Fingerprinting phase :

We can identify a growth in the number of packets received toward our RDP, but we also have a change in the type of connection.

Fingerprinting happens in 3 steps :
1 – Scans searching open RDPs
2 – Brute forces of found RDP
3 – Malicious use of the honeypot

During three weeks, we have recorded more than 1200 unique malicious IPs, with many packets of connections attempts, like bruteforce using dictionaries.
If an attacker succeeded to connects to our honeypots he follows the same process :

1 – Verification of the honeypot’s public IP using google (whatsmip, whoer.net, …)
2 – Verification of the local variables (french keyboard, computer in french)
3 – Reading the documents present on the host (meaning that the attacker is possibly not a bot)
4 – Logging off.


B. Exploitation :

With the previous step, where we had some real connections without malwares or malicious actions, our honeypot seems to finally be in the hacker’s lists and we could then see malicious actions in a frequent pace, with averaging 2 attacks per day.

a. Observing the different operating modes

We had a lot Bitcoin, ethereum and other crypto-currencies miners.
Two different operating modes have been identified :

1. The “one-click” script which install and configure the miner. While mostly uncommon, the attacker come back periodically to verify or reinstall the malware.

2. The script-kiddie, who will even dare to read the documentation of malwares or miners using the host’s computer and then set it up. This second operating mode is a lot more frequent than the first.


The honeypot is also targeted by all kind of Ransomwares.
We can see frequently two of them :

1. Nemesis

2. Blackout Ransomware.
This ransomware has been seen on Internet around the 13th of the July, 2017. We could watch it in our honeypots ten days later.

A lof of vectors of infections has been detected :

1. Some by downloading the payload from a malicious website containing several kind of different payloads, like ransomwares, keyloggers, info stealers, etc…

– For example, Nemesis Ransomware, dropped from hxxp://3501.\ru/l.zip

2. The second vector is executing the malware through a RDP share, the tsclient.

The problem in this case is that it is impossible for us to retrieve the malware executed by the tsclient, even using usual methods of forensics, unless we could directly retrieve the payload in memory. In this case, it is imperative that we react quickly to this kind of infection.

We could not retrieve some sample because of this vector. Infected by this method, we could not get the Blackout Ransomware’s payload because we did not expect the use of tsclient.

Bouncing to other RDP and being added to lists

The clipboard, which we retrieved while someone connected using RDP, is the most important source of informations. We could see several attackers sharing their clipboard between host and client.
This clipboard was sometimes filled with a lot of datas like lists of vulnerables RDP.
These lists are sold on some websites, specialized in selling/buying “vulnerables” RDP (most of them using weak passwords).

These lists are used by attackers to see which machines are best related to their goal, by looking at informations like the country where the host is, the version and other things.
This allows them to target machines more easily for their use(mining things, get money with ransomwares…).
For example, on a Windows 2008 machine, the probability of having a better CPU than a machine using Windows 7 is quite big. Knowing this, the attacker will be more interested in putting a miner, who will run more efficiently on it. This information can also indicate that the machine can be a company’s server, and so it become an interesting target for other reasons.
Below, we can see an example of this kind of list, containing lines like : IP:PORT@domains\user:password

We are not surprised by the weak strength of the passwords. This also confirms what we saw : bruteforce done on our honeypots are relatively brief. Moreover, we think that the lists containing the pair of user/password are short. In fact, we only had one single real iterative brute force in 1 month of logs.

Mules (Money laundering through buying and sending things)

RDPs seem to be often used to do money laundering using stolen credit card number and paypal accounts. Attackers use open RDP to buy things on Internet.
There are a lot of ways to collect the money from stolen CBs, like shipping the bought products in another country, rauds using Paypal…(cf screenshot) .

The attacker seems to use commercial websites which are located close to the IP of the RDP used (in France, the attackers will use website like bonprix.fr, but other websites more “world-wide” such as wish.com or sarenza.com).
However, contrary to what we thought, shipping in Russia doesn’t seem to be a problem in the payment process because of the few checks done by the banks or the commercial websites themselves.

The first step is to verify if the PayPal account is valid (by checking if there is a credit card on it mostly).

To do that, the attacker will try to transfer small amounts of money, by donating to http://chrispederick.com/ to test if the payments are allowed.
It seems to be a questionable joke, referring to the hack of the Web Developer plugin of Chris Pederick, who admitted having his account compromised which allowed hackers to uploaded a hacked version of it.

Finally, the purchases are done using these PayPal account, mostly in the same country of the person who got his credentials stolen.

During this kind of operation, the attackers will not hesitate to modify the host machine, by changing passwords, installing tools useful for their wrongdoing or installing custom web browser like Epic Privacy Browser, MX5 or Opera. The hackers will also reconnect on the same RDP again and again, using the same tools installed previously. It is not a one shot attack on the RDP because they will use it several times.

Missed things

Finally, we saw a lot of scripts executed automatically. Those were configured to use qwerty keyboards, but they obviously failed on our honeypots because they were using azerty.

The choice of language is one of the most important thing on our kind of honeypot, because we chose to focus on french related things. We will sometimes miss some attacks because of this choice.


While doing a RDP connection, it is possible to share folders and files between host and guest. This is called tsclient.
This feature is also used a lot by attackers dropping payloads. This is a problem to us because they can execute the payload from a remote folder, without copying it on the host.
The payload being on the attacker’s computer, we can only hope to retrieve it in the Honeypot’s memory.
But, some payloads, when they properly end, can’t be found in the memory anymore.

We are working on a workaround, with various possibilities opening to us, like an API hook on the creation of processus.


This kind of project can give you quickly a lot of results, and it is cheap to deploy in term of time and material.
This project is also a good training platform: developing dedicated tools, network and system’s building, malware analysis and forensic investigations. This can also be a platform of self-learning for the Blue-Teams.
If you are interested by our data, or have any suggestions or feedbacks, don’t hesitate to contact us so that we can improve our project and our data analysis.