In order to show just how much of a problem it can be to expose a public IP to the internet, Spitfire decided to setup a ‘Honeypot’ on a public IP and start collecting the number of attacks which can happen in just an hour at a random time in the middle of the day.

The idea is to make it look enticing to hackers or malicious software so they will try to attack it.

For our example we have set up our honeypot on a public IP using a virtual machine on the Azure platform.

Once the VM is set up and we’ve exposed the ports in question, we can then run our honeypot software and start listening to traffic and watching for IP addresses trying to gain entry.

What this diagram shows is that we’ve had 2,266 attacks come into our Azure public IP. And of these 2,226 attacks they have come from around 120 individual source IP’s . These attacks are then split into different types that attackers have used to try to gain entry to our honeypot device.

Examples:

‘Dionaea’ is used to capture SMB (server message block) exploits. SMB is a very common port to forward and is used for things like file shares.

‘Conpot’ is an ICS (Industrial control system) honeypot listening to common ports used in these systems.

To get more information we can then start to look at which countries the attackers have initiated their attack from. This is done by looking at the source IP of the attacker, which can be isolated to the country of origin as shown below:

In the window below we can see what username & passwords the dictionary attacks are using to try and gain entry. As expected, we can see lots of ‘default’ usernames and passwords which unfortunately are still commonly used within many businesses.

Once a CVE is released it is the software/hardware vendors responsibility to act on that and patch their software/hardware to make sure they are not exposed to the flaw, although there is no guarantee this will take place and would largely depend on that system having some sort of maintenance agreement.

If we look at the first few CVE’s being hit on our system, then we can get an idea of which exploits/vulnerabilities are being used:

CVE-2002-0013 = “Vulnerabilities in the SNMPv1 request handling of a large number of SNMP implementations allow remote attackers to cause a denial of service or gain privileges”

CVE-2020-11899 = “The Treck TCP/IP stack before 6.0.1.66 has an IPv6 Out-of-bounds Read. It is caused by improper input validation in the IPv6 component when handling a packet sent by an unauthorized network attacker. Potential Denial of Service.”

CVE-1999-0183 = “Linux implementations of TFTP would allow access to files outside the restricted directory.”

This offers a geographical layout of live ‘hits’ as they come into our honeypot, including the source country and the source IP where the attacker originates:

For those in the IT industry, seeing this level of attacks coming into our honeypot will be of no surprise.

It’s our job to make sure we are able to lock down these devices/services and make sure we are reducing exposure as much as possible while making sure our systems are also useable for staff.

It should be noted that in this example our Honeypot is on a UK IP address, and it was exposed to the internet in the middle of the day. If the same experiment was run during the evening, then we would expect a much larger number of attacks to hit our public IP.  Most attackers know that UK staff are likely to be out of the office by 6pm-8pm in the evening so they will wait until after these hours before they start looking for vulnerabilities, to avoid alerting anyone who may be looking out for them.

As can be seen if you wish to have any devices exposed to the internet via either simple port forwards or devices which sit directly on their own public IP address then making sure your device is locked down is of the upmost importance.

Having someone setup a simple port forward but forget to lock down that port forward can have a devastating effect on a business’s network. Once an attacker has access to a single device on a network they can use that to then hop onto other devices in that network.

In the worst cases they will make sure you are unaware of this vulnerability as long as possible before potentially launching something like a ransomware attack on your network.

A ransomware attacker can infect your network in just a few hours, but some attackers will stay on your network from days to weeks making sure as many systems as possible are infected before then locking all systems and files via encryption and then sending the ransom note to the unfortunate victim.