| CERT

INTRODUCTION

Understanding how attackers work is a real advantage if you want to setup relevant defensive tools.
Today, it is easy to access many data feeds and IOCs to feed up security tools.

The problem is the difficulty to contextualize these IOC feeds. Lists of hashes and IPs are often not sufficient to understand certain attack types and it becomes simple for attackers to bypass security solutions.

One of the simplest solutions, in terms of approach and speed of implementation, and that allows us to monitor attackers behaviour are Honeypots.

Through a series of blogposts, we will attempt to describe OPMD CERT methods in use to monitor the level of the threat and the behavior of the attackers.

HONEYPOTS

The concept is simple, we need to expose vulnerable services on Internet and study the attackers’ behaviors toward them.

  • What type of exploits do they use ?
  • What are they trying to do ?
  • How do they work ?

 

However, honeypots have their pros and cons :

  • Honeypots advantage is that they allow you to easily study the surrounding “noise”

– We can catch attacks used by automated tools scanning Internet all the days.
– We can more easily map the most attacked services, the most used methods, etc… and understand how to avoid these kinds of attacks.

  • The major inconvenient is that you can only catch attacks done on a massive scale (such as scans) and so few advanced attacks.

– However, honeypots allow us to reduce the number of massive scale attacks and thus deploy sophisticated tools to catch more advanced attacks.

Delimitation of the perimeter

To make more contextualized and relevant data, one of the first key step is to delimit the perimeter.
As such, it is not easy to monitor “the Internet” because countries around the globe are not targeted in a same way, with the same intensity, and by the same kind of people.
For example, some countries, which don’t use smartcards as payment cards, are more targeted by malware targeting point of sales. (https://www.symantec.com/content/dam/symantec/docs/white-papers/attacks-on-point-of-sale-systems-en.pdf).
The OPMD-CERT being young and having a majorly french customer base, we are trying to use servers only located in France.

Step 1 - Overview of the situation

Before making honeypots, it is important to understand :

  • The current threats
  • What are the most attacked services
  • How are they attacked

Answering these questions allows us to adjust the honeypots to get results more quickly.

  • First phase : recon and as such, we need servers located in our perimeter (France in our case).
    We can choose between IP from hosting providers (e.g OVH, 1&1, Gandi …) or ISPs.
    As our goal is to monitor the threat to exposed services on Internet, we chose an IP from OVH.
  • We capture network :
    Using tcpdump
    Traffic is being captured on every TCP/UDP ports
    The capture will last for 4 days

 

This will allow us to study which services are the most attacked and to predict deployment of the vulnerable services.

Step 2 - Overview of a 4 days PCAP

Let us start by some numbers from the generated 4 days pcap.

Particularity of the PCAP :

  • First packet : 2017-06-07 18:46:32
  • Last packet 2017-06-12 09:34:46
  • 1 212 759 captured packets
  • Average of 3 pps
  • PCAP file is about 255Mo
  • 6172 unique IPs have scanned us

These 4 days of monitoring taught us an interesting first fact : on the 6172 IPs that scanned us, servers 61.177.172.10 61.177.172.52 and 61.177.172.53

were responsibles of 50% of the total traffic.

These 3 IPs, located in China, were used for SSH brute forcing.

For the rest of this article, we chose to exclude these 3 IPs. These servers represents half the traffic and can distort the stats made on the rest of the network capture.

TCP

TCP traffic accounts for 99% of the total traffic..
Our goal is to determine the services that we will audit with the honeypot. Therefore, we will focus on targeted ports in the PCAP, which we will detail below.
(If we didn’t catch your favorite service on these 4 days, don’t worry, we will do these steps again later and you might find it there).

Our server was scanned on:

  • 700 different ports (from 11 to 62222),
  • 174 ports have been scanned 3 times or more.

The top 10 most targeted ports isn’t a surprise.

  • SSH (port 22) is at the top of the ranking:
    This service is heavily brute forced (https://blog.sucuri.net/2013/07/ssh-brute-force-the-10-year-old-attack-that-still-persists.html) to install DDoS bots, mostly by those who we can call team “China-Z” and smaller crews from malwares GayFgt et Kaiten.
  • Telnet (port 23/2323) is also heavily brute forced,
    Mostly by Mirai botnets but also usually by anyone who wants to attack connected objects.
  • SMB (port 445) comes in third position:
    It is targeted by the latest vulnerabilities Eternal Blue/Eternal Red and Wannacry.
    It is also targeted because of worms such as Conficker, which use vulnerability MS06-068.
  • Database services are also targeted by brute force attacks
    MSSQL (1433)
    MySQL (3306)
    rMongoDB (27017).
  • RDP protocol (3389).
    Once brute forced, attacked RDP servers are used for many purposes : Bitcoin mining, Ransomware, Scans, …
    RDP is used a lot by IT companies for their clients. As such, numerous Point of Sales and other applications like SCADA are accessible from Internet and are targeted (https://www.symantec.com/connect/blogs/demystifying-point-sale-malware-and-attacks)
  • HTTP (80, 81) is also attacked
    Web servers are a powerful vector of attacks because they are mostly badly configured and used by a lot of web applications (CMS, Intranet, PhpMyAdmin, CPanel, Tomcat and other business tools).
    It is also attacked by low level attackers (skids) because it’s more accessible for them.
    We will look into the attacks targeting web servers, because it would take an article on its own.

The case of port 9000
Port 9000 is listed at the top of the scanned ports (8th position). A lot of people have begun (https://twitter.com/xme/status/869521041026158593) to notice this behavior.
Again, our goal is to try to quickly understand if there is an interest to monitor this port with a Honeypot emulating this service.
By opening a TCP socket on port 9000, (and by doing the three-way handshake) we will be able to capture the first request sent to port 9000 by the attacker.
We used the following python script :
https://pastebin.com/LEPEK4TS

After a few hours, the first requests are :

This is a scan trying to find a vulnerable DVR to exploit, probably to install a malware.
This subject being already done, we will not focus on the analysis of this one for now.

What about other ports ?

There is also in the PCAP 690 other ports that we didn’t speak about. We will separate them in the following way :

  • The known services, not listed in our top 10 like:
    FTP (21)
    ADSL management port (7547)
    Proxy (3128,8080)
    VNC/rAdmin (5900,4899)
  • Alternatives ports to known services, with mostly:
    RDP (33389 or 33899) or other random ports
    HTTP
  • Scanned ports by automated scanning tools:
    “Predictables” ports (4444, 5555, 6666…)
    Alternatives RDP ports, …
  • Scanned ports for specific vulnerabilities:
    Redis (6379) for a 2015 vulnerability
    Elasticsearch (9200) for CVE-2015-1427

 

Fun Fact :
We noticed that Shodan scanned Internet looking for NJRAT C&C.

On top of this TCP analysis, we noticed there are several kind of automated scans :

  • those with the IP searching one service on several ports
  • those with the IP searching every kind of services on the same port

This was very frequent for RDP and HTTP.
You can found the TOP 50 of scanned ports at: https://pastebin.com/xVn2cfvU

After this brief TCP port analysis, we will study the <1% last packets : UDP.

UDP
In the same way as TCP, let’s have a look on some statistics:

  • 381 uniq IPs have scanned our server
  • On 148 differents ports from 7 to 64738

The majority of the attacks is done for launching DDoS attacks.
– Port 1900 (UPnP SSDP).
– Port 53 (DNS).

  • We’ve received many DNS resolution requests like:
    1×1.cz
    ppal-kundenservice.gdn
    leth.cc
    hoffmeister.be
    activum.nu
    c.afekv.com
    cpsc.gov
    lywy.995eaca3.wc.syssec.rub.de
  • Open DNS resolvers are targeted by people looking for DDoS amplification.
    Port 161 (SNMP)
    Port 19 (Chargen).

 

Port 5060 is also often targeted:
– This is the SIP (VOIP) port.
– SIP is a seriously underestimated attack vector : there is a lot of good reason for attacking SIP:

  • Stealing money via premium number
  • Using compromised SIP for mass call spams
  • Using compromised SIP for installing malware…

It should be noted that the huge majority of all the SIP request are done by the tools SIPVicious.

  • The port 53413
    This port is targeted due to a backdoor on Netis routers.

 

  • Finally, the remaining entries of this TOP10 are mainly ports/traffic requests done by old worms:
    Port 1434 (MSSQL)
    Port 137 (SMB)
    Port 111 (RPC/NFS)

What about other ports ?

The huge majority of the other ports are some alternative SIP ports.

  • We can also found some vulnerability check like on port 9999 (ASUS router backdoor)

 

  • LDAP services are also researched .
  • Finally, we have found different curious things like some DHT P2P requests, or Garry’s Mod video game requests.

Which port to choose?

This analysis shows 2 types of attack:

  • Automated attacks(SSH, Telnet, Mysql, ELK…)
    – Services are scanned and brute forced
    – A malware is automatically installed
  • Semi-automated attacks:
    – Services are scanned and brute forced
    – The attacker connects manually to the service and interacts with the victim’s computer

Automated attacks are currently well monitored with honeypots like Cowrie or ElasticHoney.
Installing a new instance of Cowrie will not bring anything new.
So, we’ll try to catch semi-automated attacks to understand how the attackers work.

RDP protocol looks perfect for that:

  • It is very high in the most attacked TCP ports
  • Attackers does many different things when they use hacked RDP.
  • Attackers try to found RDP servers on many differents ports. It allows us to have a big exposition on the Internet.
  • Once the system is setup to monitor RDP, it is simple to add other similar protocols, such as VNC or SMB, for example.
  • RDP is an interesting protocol to study.

Our first monitored service will be RDP.

First recommendations

As shown by these first statistics, it is mandatory to be careful with what you expose on the Internet.

SSH and Telnet are the most attacked services:

  • In 4 days we receive 29765 scans on SSH port (22).
    – It is around 5 scans by minutes
    – It’s the same thing with Telnet

You can be compromised in just a few minutes simply exposing SSH service using tests credentials.

First of all, by changing the default port of SSH and Telnet, you strongly reduce the number of brute force attacks.
Because the main attack vector of SSH attack is Bruteforcing, you can avoid these attacks by using certificate authentication.

Another solution is to use tools like fail2ban. It allow you to ban any IP that make more that X fail attempt

Remote access tools (VNC, RDP, rAdmin…) are also very attacked. You can enhance security of these service by configuring 2FA with OTP or SMS and by using strong password.
This is an example of password used by attacker against VNC services: https://pastebin.com/aKy2W0Gc

It’s the same for database services:

  • Use strong passwords
  • If it’s not necessary, don’t expose your database services on the Internet
  • Be careful with user rights
  • If you need to expose database services on the Internet: use IP white listing

These few elementary rules are enough for avoiding automatic attacks. For some years, it became usual to mass scan the entire Internet. Some time for legits reasons, some time for malicious reasons. It is important to regularly listen the network for understanding security trends and apply security countermeasures.

Next step

We’re getting at the end of this first part. We tried to have a big picture on which services we have to actively monitor first.
The next step of this adventure is to introduce the architecture used to deploy our RDP honeypot and explain our first results.