Honeypot systems have been around for more than a decade. There have been a number of initiatives such as The Honeynet Project or Project Honeypot that have had a great impact on development and adaption of honeypot systems.
However, within enterprises, honeypot systems have not been widely adapted or used. This could be due to difficulty in setting up and managing a honeypot system as well as not knowing their invaluable benefits. The focus of this article is to highlight 5 effective use-cases of a honeypot system for any enterprise.
The experiment highlights the correlation among sources and types of attacks across Amazon EC2 geographic zones (or regions) by using Smart Honeypots. The purpose is to identify whether choice of EC2 geographic region has an impact on risk profile of a Cloud-based host.
- With only 6% correlation on source of intrusions, 94% of intruders were unique to each zone.
- The attack profile between zones were completely different. Tokyo zone received significant number of NTP amplification intrusions, where Ireland suffered the most from SNMP scanning and N.Virginia from SSH brute-force attempts.
- Intruders targeting N.Virginia were mainly sourced from Russia and China, whereas Sydney zone received most intrusions from Netherlands.
- Except for DNS amplification intrusions that widely observed on all zones, intruders were only targeted a single zone.
- DNS amplification, SSH brute-forcing, VoIP, SNMP and UPNP scanning had the highest correlation across all zones.
- Ecatel and Firering (NL), OVH (France), Redstation (UK) and VolumeDrive (US) were top non-Chinese providers that allowed for their environment to be used for launching attacks.
- Read our recommendation (on the last page) on how to improve the security of your cloud instance by getting access to our cloud-based custom blacklist service.
The research study investigates Secure Shell (SSH) attacks on Amazon EC2 cloud instances across different AWS zones by means of deploying Smart Honeypot (SH). It provides an in-depth analysis of SSH attacks, SSH intruders profile, and attempts to identify their tactics and purposes.
Key observations for this research experiment are as following:
- Without disclosure of SH’s IP addresses, in less than 10 hours, first brute-force attempt was detected.
- Over 89% of intruders only targeted one SH in one zone;
- Three threat actors (attacker’s profile) were detected – brute-forcer, infector and commander – by which their source IP addresses were completely different;
- Typically, blacklists are limited to prevent the first threat actor i.e. brute-forcer and not the other two;
- Top three (3) origin country of attacks (based on whois information) were China, Russia and Egypt;
- Some password lists used for brute-forcing SSH service were limited to few passwords and targeted toward compromising other malicious groups infected hosts;
- VoIP services, network appliances and development tools account names were constantly targeted by intruders;
- Upon a successful password guess, a new actor (Infector) appeared to upload malicious files to SH and a connection were made to an external Command and Control server;
- A number of tactics were used to hide malicious executable, replace legitimate executable with infected ones and disable audit functionalities of the operating system;
- A third actor (Commander) employed the infected SH to conduct denial-of-service (DoS) attacks;
- On average intruders’ source IP address was observed for a day and there was no further connection to check the status of the infected host or re-deploy the malicious files.
Different variance of ‘old’ php-cgi remote code execution vulnerability (i.e. CVE-2012-1823) was observed across EC2 Smart Honeypot instances. The interesting piece was differences in the attack drop-by files::
- Hosting a IRC bot (DDoS, RCE etc.) – as always!
- Hosting a Linux.Darlloz worm – observed again.
- Hosting a Crypto Currency miner – interesting piece!
- Hosting a port scanner – not very well scripted!
It is a jungle out there! If you happen to run a honeypot, you will be amazed by number of intrusions your receive in matter of a few minutes. The issue is even bigger when it comes to servers hosted on cloud. They are constantly being targeted by online adversaries and cyber criminals. The public IP addresses assigned to every cloud instance is from a predefined IP address pool. Therefore, from adversaries perspective it is trivial to identify and target these cloud instances.
We started a journey of experiments and called it Project Amazon EC2 to find out what attacks are received by cloud hosts on a major cloud provider specifically Amazon Web Services (AWS).
We have deployed a number of Smart Honeypots across AWS geographic zone. We make each cloud host to mimic a typical cloud hosted server often used by online business to server a public website.