# Honeypot
The moment a system is exposed to the internet, it begins attracting attention. Most of that attention isn’t targeted, rather it’s automated scanning, credential stuffing, and opportunistic probing performed at massive scale.
To observe this behavior firsthand, I deployed [T-Pot](https://github.com/telekom-security/tpotce), an open-source, multi-honeypot platform that simulates vulnerable services and aggregates attack data into a centralized dashboard. By intentionally exposing emulated services in AWS, I was able to capture and analyze real-world attack traffic, providing a clear view into the constant background noise of the internet.
#### Launch Instance
1. Log into AWS console and Launch an EC2 Instance
I chose a t3.xlarge to ensure sufficient CPU and memory for:
* Elastic Stack (ELK)
* Cowrie (SSH/Telnet honeypot)
* Dionaea (malware capture)
* Suricata (IDS)
* Other T-Pot integrated sensors
2. Select AMI (I selected Debian)
2. Configure storage
I only configured my storage for 40GB since I planned to only let it run for a short time. You can choose more if you want to keep it running for a longer duration. T-Pot recommends 128GB.
3. Security Group Configuration
We will allow inbound connections for ports 64294, 64295, and 64297 only from our IP, these ports will later used as T-Pot management ports. For the ports between 1 to 64000, we will allow inbound access from anywhere for both IPV4 and IPV6, these will used to lure the attackers in.
4. Create a Key Pair
Generate an SSH key pair to connect to the EC2 instance.
5. Allocate Elastic IP Address
Create an elastic IP for the instance so that the IP remains the same even if the instance is restarted.
6. Confirm that the EC2 instance is running
Connect to Instance
1. Select your instance and naviage to the SSH Client tab. This tab will provide the Public DNS used to connect to the instance.
2. Go to your terminal and SSH into the instance
3. Run the following commands to update the packages and install git.
```
sudo apt update -y
sudo apt install git -yome code
```
4. Clone the T-Pot repo from Github
```
git clone https://github.com/telekom-security/tpotce
```
5. Navigate to the installer
```
cd tpotce/iso/installer/
```
6. Run the T-Pot installation script
```
sudo ./install.sh --type=user
```
7. Select STANDARD install
8. Next, you will be prompted to create a username and password
9. The installation process will complete after a few minutes. You will notice that port 22 is not longer available. We will need to SSH from port 64295 (previously set up in the SG). Notice the note at the bottom says: "Please reboot and re-connect via SSH on tcp/64295.
10. Reboot the instance
11. Log back into the instance
12. You can check the status of the T-Pot service by using:
```
sudo systemctl status tpot
```
13. Navigate to the UI
14. Login to the console using the username and password created earlier.
15. After successful login, you will be greeted by the T-Pot homepage
#### Scanning T-Pot
1. Just for fun, let's scan our T-Pot instance and see what we find. We can see that there are numerous ports open.
2. Let's try and connect to the instance using telnet. We successfully connect and prompted for a username and password. In reality, it is presenting a fake login shell using Crowie and records the attempts.
#### T-Pot
Here's a screenshot of the Attack Map.
I let T-Pot run for a 24 hours and here's what I saw:
Within a 24-hour period, the environment recorded over 13,500 attack interactions across multiple services and protocols.
| Sensor | Attack Count | What It Monitors |
| -------------- | ------------ | -------------------------- |
| Honeyptrap | 6,025 | Generic port/service traps |
| Dionaea | 5,402 | Malware & exploit attempts |
| Cowrie | 1,067 | SSH/Telnet brute force |
| SentryPeer | 313 | SIP/VoIP attacks |
| Tanner | 277 | HTTP interaction logging |
| ConPot | 128 | ICS/SCADA emulation |
| Redishoneypot | 86 | Redis attacks |
| Mailoney | 69 | SMTP traps |
| Adbhoney | 47 | Android Debug Bridge |
| CitrixHoneypot | 43 | Citrix exploit emulation |
The dashboard revealed:
* Continuous automated scanning activity
* Thousands of credential brute-force attempts
* High targeting of ports
* 445 (SMB)
* 23 (Telnet)
* 22 (SSH)
* 80 (HTTP)
* 5060 (SIP)
* Globally distributed source IPs
* Highest concentration
* United States
* Philippines
* China
* France
* Egypt
Attempted usernames and passwords that were captures
* The most commonly attempted usernames were admin and root, indicating automated brute-force activity targeting default administrative accounts.
* Other usernames such as guest, pi, sa, and anonymous suggest attacks against common IoT, database, and Linux device defaults.
* Password attempts were dominated by weak credentials like admin, 1234, 123456, and 12345678, reflecting credential stuffing and dictionary attacks.
* Variations such as Admin123, password, qwerty, and numeric-only passwords confirm use of standard brute-force wordlists. Picture 2 contains some NSFW passwords.
* Some attempts included device-specific credentials like raspberry, pointing to scanning for exposed Raspberry Pi systems.
* The repetition and clustering of common credentials strongly suggest automated botnet-driven attacks rather than manual intrusion attempts.
**Cowrie (SSH and Telnet honeypot)**
* 1,069 total SSH/Telnet authentication attempts were recorded within the selected time window.
* 303 unique source IPs attempted to authenticate, indicating broad distributed scanning activity.
* Only 4 unique password hashes were observed, reinforcing repetitive use of common credential lists.
* Geographic distribution of source IPs was global, with concentration across North America, Europe, and Asia.
* The ratio of attempts to unique IPs suggests coordinated bot-driven credential stuffing rather than manual intrusion attempts.
**Redis Honeypot (Redis database server)**
* 86 total Redis interaction attempts were recorded from 27 unique source IPs.
* All source IPs were classified as known attackers or mass scanners.
* Top attacking ASNs included Alibaba Cloud, Tencent, Amazon, Microsoft, and other major hosting providers.
* Geographic distribution was concentrated in China and the United States, with smaller volumes from South Korea and Belize.
* Most observed actions were connection attempts (NewConnect) followed by immediate closure, suggesting reconnaissance rather than successful exploitation.
* A small number of commands such as PING and INFO were issued, consistent with automated Redis probing scripts.
* The traffic pattern reflects opportunistic scanning for exposed or misconfigured Redis instances.
**Ciscoasa (emulates Cisco Adaptive Security Appliance (ASA) firewall)**
* Cisco ASA honeypot recorded 19 total attack attempts from 8 unique source IP addresses.
* Activity levels were relatively low compared to other honeypots, suggesting targeted probing rather than mass scanning.
* Geolocation data indicates traffic originating from multiple international regions, including Europe and North America.
**Adbhoney (Android Debug Bridge honeypot)**
* 47 total Android Debug Bridge (ADB) interaction attempts were recorded from 7 unique source IPs.
* The majority of activity originated from infrastructure associated with China Telecom and other large hosting providers.
* All source IPs were classified as known attackers, indicating scanning infrastructure rather than random traffic.
* Observed command inputs included attempts to download and execute files from `/data/local/tmp/`, consistent with automated Android malware deployment scripts.
* Commands such as `chmod 0755`, `nohup`, and references to `trinity` suggest attempts to install or run crypto mining malware.
* Sample artifacts were captured, demonstrating successful emulation of file transfer attempts within the honeypot environment.
* The traffic pattern reflects opportunistic scanning for exposed ADB services, commonly targeted in IoT and misconfigured Android-based devices.
**ConPot (ICS/SCADA honeypot)**
* 128 total industrial protocol interaction attempts were recorded from 15 unique source IPs.
* All source IPs were classified as known attackers or automated scanners.
* Attack activity showed brief spikes rather than sustained interaction, consistent with reconnaissance scanning.
* Most traffic originated from the United States, with smaller volumes from Vietnam, China, Australia, and the United Kingdom.
* Observed protocols included ICS-related services such as IEC104 and other simulated industrial control interfaces.
* Event types were primarily new connection attempts followed by connection loss, suggesting probing rather than full exploitation.
* The activity reflects opportunistic scanning for exposed ICS/SCADA systems rather than targeted operational technology attacks.
**HoneyTrap (low-interaction network honeypot)**
* Honeytrap recorded 5,812 total connection attempts from 1,467 unique source IPs, indicating continuous internet-wide scanning activity.
* The majority of source IP reputation classifications were identified as known attackers or mass scanners, reinforcing the automated nature of the traffic.
* Most activity originated from large cloud and hosting providers including Google Cloud Platform, Akamai, DigitalOcean, Alibaba, Microsoft, and Amazon, which are commonly abused for large-scale scanning operations.
* Destination port analysis shows concentration on common service ports such as SSH (22), HTTP/HTTPS (80/443), and other high-value exposed services, indicating reconnaissance behavior.
* Geographic distribution highlights activity primarily from the United States, France, United Kingdom, Netherlands, India, and China, reflecting globally distributed scanning infrastructure.
* The heatmap visualization demonstrates persistent probing across time intervals, with no prolonged quiet periods.
**Tanner (HTTP interaction honeypot)**
* 275 total HTTP interaction attempts were recorded from 41 unique source IPs.
* The majority of source IPs were classified as known attackers or mass scanners.
* Traffic originated globally, with notable activity from Indonesia, China, and parts of Europe.
* Most HTTP requests targeted generic paths such as `/` or `/index`, with some references to `wp-content`, suggesting WordPress-focused scanning.
* Attack patterns showed brief spikes followed by low sustained activity, typical of automated web crawler behavior.
* The majority of HTTP requests used the GET method, consistent with automated reconnaissance and directory enumeration.
* User-Agent strings were largely generic browser identifiers, indicating simple scripted scanning rather than specialized tooling.
* Top requested URIs included `/`, `/env`, `/favicon.ico`, and `/.git/HEAD`, suggesting probing for exposed configuration files and source repositories.
* Requests for `.env` and `.git` paths indicate attempts to locate sensitive application configuration data or version control artifacts.
* Additional probes targeted common administrative paths such as `phpmyadmin` and `MyAdmin`, reflecting automated database management interface scanning.
* Top attacking ASNs were primarily large telecom and hosting providers, reinforcing use of VPS/cloud infrastructure for scanning.
* A small number of high-volume source IPs accounted for a disproportionate share of traffic, consistent with automated scanning nodes.
* The overall pattern reflects broad web enumeration rather than application-specific exploitation.
**\*\*\*NOTE: I left the instance on longer than 24 hours for the data below here\*\*\***
**Suricata IDS**
* 106,272 Suricata events were recorded within the selected time window.
* Activity originated from 5,298 unique source IPs and 712 unique JA3 TLS fingerprints.
* Event volume significantly exceeded individual honeypot interaction counts, reflecting broader network-layer visibility.
* Traffic patterns showed sustained background scanning with periodic spikes consistent with automated campaigns.
* Geographic distribution of source IPs was global, with concentrated activity across North America, Europe, and Asia.
* The diversity of JA3 fingerprints indicates multiple scanning toolsets rather than a single coordinated actor.
* Suricata detections captured malformed packets, protocol anomalies, and exploit signature matches beyond direct honeypot interactions.
* The data demonstrates the value of combining deception telemetry with network intrusion detection for layered visibility.
* The majority of alerts were categorized as generic protocol communication, miscellaneous attacks, and attempted administrative access.
* High-volume destination ports included 445 (SMB), 21 (FTP), 23 (Telnet), and several high-numbered ephemeral ports.
* Most source IPs were classified as mass scanners or known attacker infrastructure.
* HTTP analysis showed heavy use of GET requests with common browser-style User-Agent strings, indicating automated enumeration.
* Probing activity targeted common web paths and administrative endpoints.
* SSH client fingerprinting revealed scanning tools such as ZGrab and other automated reconnaissance utilities.
* File type and content analysis reflected simple probing rather than complex payload delivery.
* Top alert signatures included malformed TCP stream behavior, Nmap scanning detection, and exploit framework indicators such as DoublePulsar.
* Geographic distribution remained globally dispersed, with concentrated activity from major internet infrastructure regions.
* The highest volume of traffic originated from major cloud providers, including Google Cloud, Amazon, Alibaba Cloud, and Akamai.
* Several individual source IPs generated thousands of events, indicating high-frequency automated scanning.
* Activity clustered around hosting and telecom infrastructure rather than residential networks.
* Suricata mapped traffic to multiple known CVEs, including recent and legacy vulnerabilities.
* CVE references spanned web application, protocol, and service-level weaknesses, suggesting broad exploit probing.
* The mix of older and newer CVEs possibly indicates automated exploit kits scanning indiscriminately rather than targeted vulnerability exploitation.
**Fatt (fingerprinting/HTTP enumeration)**
* 8,683 total interactions were recorded from 184 unique source IPs.
* Activity included 30 unique HTTP client fingerprints and 12 unique JA3 TLS fingerprints.
* No RDP fingerprinting activity was observed during the selected time window.
* The majority of source IPs were classified as mass scanners.
* Traffic originated primarily from hosting providers such as OVH, DigitalOcean, Microsoft, and Google Cloud.
* Requested paths included `/`, `/.env`, `/.git/config`, and `/favicon.ico`, indicating attempts to locate exposed configuration and repository files.
* Destination port activity was dominated by HTTPS (443), with additional probing on HTTP (80) and other service ports.
* Traffic volume remained steady throughout the observation period, consistent with automated scanning behavior.
* The majority of source IPs were classified as mass scanners, with a smaller portion identified as known attacker infrastructure.
* Geographic distribution showed concentrated activity from Germany and the United States, with smaller volumes from Indonesia, China, and Portugal.
* Protocol distribution was heavily weighted toward TLS, indicating encrypted service probing and fingerprinting.
* SSH client fingerprinting identified common automated tools such as ZGrab and generic SSH libraries.
* HTTP request methods were overwhelmingly GET, consistent with automated enumeration and content discovery.
* User-Agent strings were largely generic browser identifiers and common scanning libraries, indicating scripted reconnaissance.
* HTTP client header hashes show repeated patterns, suggesting reuse of automated scanning toolsets.
* Port distribution remained heavily concentrated on HTTPS (443), with minimal interaction on alternate service ports.
* The highest-volume traffic originated from large cloud and hosting providers, including Google Cloud, Amazon, DigitalOcean, Akamai, and Cloudflare.
* T-Systems International GmbH generated the largest single ASN count in this view, indicating concentrated scanning from specific infrastructure.
* A small number of source IPs accounted for a disproportionate share of total events, consistent with automated scanning nodes.
* One internal IP (172.31.0.40) appears in the top list, reflecting local or internal system activity rather than external threat traffic.
* Most activity originated from data center or telecom networks rather than residential IP space.
* The concentration of traffic within major cloud ASNs reinforces the use of VPS and hosted infrastructure for large-scale reconnaissance.
**Mailoney (SMTP honeypot)**
* 69 total SMTP interactions observed from 26 unique source IPs.
* Activity shows steady low-volume probing with occasional small spikes.
* Majority of source IPs classified as known attackers or mass scanners.
* Traffic primarily originated from the United States, with additional activity from France, Hong Kong, and Japan.
* Top autonomous systems included Akamai Connected Cloud and Google Cloud Platform, indicating cloud-hosted scanning infrastructure.
* Most active individual source IPs generated 5–6 connection attempts each.
* Captured email activity included common spam-related sender and receiver addresses (e.g., scanner and spam accounts).
* Geographic visualization highlights concentrated activity from cloud-hosted infrastructure rather than residential networks.
#### Reflecting on T-Pot
Deploying T-Pot in AWS quickly demonstrated a fundamental reality of the modern internet: the moment a system becomes publicly accessible, it is discovered and probed. Within hours, the honeypot began receiving automated scans, credential stuffing attempts, protocol probing, and exploit traffic originating from cloud providers and globally distributed infrastructure.
What stood out most was not sophistication, but persistence and scale. The overwhelming majority of activity was automated. Services like SSH, Redis, HTTP, and industrial protocols were continuously targeted. Weak usernames and passwords dominated attempts, reinforcing how much of today’s internet-wide activity is driven by botnets cycling through known credential lists and exposed services.
Each honeypot component provided a different lens into attacker behavior. Cowrie showed brute-force login attempts and post-authentication command execution. Honeytrap revealed broad network reconnaissance. Suricata surfaced exploit signatures and protocol anomalies. Redis, ADB, Mail, and other service emulations highlighted how attackers hunt for misconfigurations at scale. Together, the data paints a picture that most attacks are opportunistic, automated, and indiscriminate.
This experiment reinforces a critical security principle where exposure equals attention. Any publicly reachable service will be scanned, any weak credential will eventually be tested, and any misconfiguration will likely be discovered.
Honeypots like T-Pot do more than collect logs, they provide visibility into the constant background noise of the internet. This information provides shows how security risks can turn into into measurable, observable behavior.
