TPot: A Study in Real-World threat Behavior

TPot: A Study in Real-World threat Behavior

TPot: A Study in Real-World threat Behavior

_________________

"To know your enemy, you must become your enemy."
— Sun Tzu

"To know your enemy, you must become your enemy."
— Sun Tzu

"To know your enemy, you must become your enemy."
— Sun Tzu

This project will hopefully provide valuable insights into real-world cyber threats, analyze attacker behaviors, and provide actionable security recommendations. By exposing a deliberately vulnerable machine to the internet, this project experiment aims to identify common attack patterns, malicious threat actors, and the TTPs used against the exposed machine.


Utilizing a honeypot grants us the significantly advantageous ability to gain insight into the most targeted services and ports, geographic distribution of attackers, and any time-based trends in malicious activity.


Additionally, we are able to better predict and provide actionable defense strategies and security recommendations that can be implemented in real-world environments, such as IDS/IPS tuning, firewall rules, and network segmentation practices.


This report presents the findings from a 30-day TPot deployment, providing an in-depth look into observed attacks and their implications for network safety.

This project will hopefully provide valuable insights into real-world cyber threats, analyze attacker behaviors, and provide actionable security recommendations. By exposing a deliberately vulnerable machine to the internet, this project experiment aims to identify common attack patterns, malicious threat actors, and the TTPs used against the exposed machine.


Utilizing a honeypot grants us the significantly advantageous ability to gain insight into the most targeted services and ports, geographic distribution of attackers, and any time-based trends in malicious activity.


Additionally, we are able to better predict and provide actionable defense strategies and security recommendations that can be implemented in real-world environments, such as IDS/IPS tuning, firewall rules, and network segmentation practices.


This report presents the findings from a 30-day TPot deployment, providing an in-depth look into observed attacks and their implications for network safety.

TOTAL ATTACKS

TOTAL ATTACKS

0
0
0

Why TPot?

For this project, TPot was chosen as the honeypot framework due to its multi-honeypot environment and advanced threat intelligence capabilities. Key reasons for selecting TPot include:


  • Multi-Honeypot Support – TPot integrates multiple honeypots (Cowrie, Dionaea, Conpot, etc.), allowing for diverse attack detection across different protocols.


  • Automated Logging & Analysis – Logs can be forwarded to Elasticsearch, Splunk, or TheHive for further correlation.


  • Low Maintenance & Easy Deployment – Compared to setting up individual honeypots manually, TPot offers a pre-configured, scalable solution.


Other honeypots, such as Cowrie (SSH/Telnet), Dionaea (Malware Collection), and MHN (Modern Honey Network), were considered but lacked the full-stack visibility and automation provided by TPot.

For this project, TPot was chosen as the honeypot framework due to its multi-honeypot environment and advanced threat intelligence capabilities. Key reasons for selecting TPot include:


  • Multi-Honeypot Support – TPot integrates multiple honeypots (Cowrie, Dionaea, Conpot, etc.), allowing for diverse attack detection across different protocols.


  • Automated Logging & Analysis – Logs can be forwarded to Elasticsearch, Splunk, or TheHive for further correlation.


  • Low Maintenance & Easy Deployment – Compared to setting up individual honeypots manually, TPot offers a pre-configured, scalable solution.


Other honeypots, such as Cowrie (SSH/Telnet), Dionaea (Malware Collection), and MHN (Modern Honey Network), were considered but lacked the full-stack visibility and automation provided by TPot.

Why Vultr?

  1. Simplicity and Speed

    • Compared to AWS or Azure, Vultr has a clean, beginner-friendly interface with fast provisioning (boot times in seconds).

    • We can be up and running in minutes, which is great for fast iteration


  1. Affordability and Flexibility

    • Hourly billing and low-cost plans mean we can spin up a box, run it for 30 days, and tear it down without a long-term commitment.

    • Great for budget-conscious, short-term research projects like this one


  1. Public Internet Exposure Without Complexity

    • Vultr allows direct exposure to the internet with no restrictive default firewalls, unlike platforms like AWS or Azure which require security group configuration.

    • This makes it ideal for honeypots, which must be easily discoverable by attackers to collect meaningful traffic.


This matters as our TPot deployment needs to like a real, vulnerable system on the open web. Vultr makes that simple.

  1. Simplicity and Speed

    • Compared to AWS or Azure, Vultr has a clean, beginner-friendly interface with fast provisioning (boot times in seconds).

    • We can be up and running in minutes, which is great for fast iteration


  1. Affordability and Flexibility

    • Hourly billing and low-cost plans mean we can spin up a box, run it for 30 days, and tear it down without a long-term commitment.

    • Great for budget-conscious, short-term research projects like this one


  1. Public Internet Exposure Without Complexity

    • Vultr allows direct exposure to the internet with no restrictive default firewalls, unlike platforms like AWS or Azure which require security group configuration.

    • This makes it ideal for honeypots, which must be easily discoverable by attackers to collect meaningful traffic.


This matters as our TPot deployment needs to like a real, vulnerable system on the open web. Vultr makes that simple.

  1. TPot Deployment

We'll be collecting real threat data over a 30-day sample. We'll create an account at Vultr, and select Deploy -> Deploy a Server to get started

We'll be collecting real threat data over a 30-day sample. We'll create an account at Vultr, and select Deploy -> Deploy a Server to get started

From our list of deployable options, we'll select Shared CPU with 4 vCPUs, 8GB of memory, adn 160GB of NVMe storage

From our list of deployable options, we'll select Shared CPU with 4 vCPUs, 8GB of memory, adn 160GB of NVMe storage

We'll select Ubuntu 24.04 as the OS

We'll select Ubuntu 24.04 as the OS

Next we'll name our server and enter a label, then finalize our configurations by selecting Deploy Now, and we can see our VM begin the provisioning process by installing Ubuntu

Next we'll name our server and enter a label, then finalize our configurations by selecting Deploy Now, and we can see our VM begin the provisioning process by installing Ubuntu

After Ubuntu is finished provisioning, we can finally see our machine in the products dashboard

After Ubuntu is finished provisioning, we can finally see our machine in the products dashboard

Once the VM has finished the provisioning process, we can access the virtual console and setup SSH access temporarily while we provision TPot on the Ubuntu system by defining the 64295 port for access

Once the VM has finished the provisioning process, we can access the virtual console and setup SSH access temporarily while we provision TPot on the Ubuntu system by defining the 64295 port for access

While Tpot is setting up, we'll want to create a new firewall group. The reason for this is to prevent access to our IP address only. We'll navigate to Firewall section in the left-hand pane under Settings and name the group Honeypot

While Tpot is setting up, we'll want to create a new firewall group. The reason for this is to prevent access to our IP address only. We'll navigate to Firewall section in the left-hand pane under Settings and name the group Honeypot

Within this created Firewall group we'll create an explicit deny rule for all IP addresses on all available network interfaces and an explicit allow rule for every port from our public IPv4 address

Within this created Firewall group we'll create an explicit deny rule for all IP addresses on all available network interfaces and an explicit allow rule for every port from our public IPv4 address

After creating and configuring our Firewall group, we'll then apply it to the VM by selecting Update Firewall Group

Next we'll access our VM from the virtual console and begin the process of installing TPot by cloning the GitHub repository

We can then take our VM's public IP address and access TPot's web interface from our browser over port 64297

And success! We can access the front page for the TPot web interface. We'll allow our deployment to stay active and online for 30 days and return to analyze the threat data collected

After thirty days, we'll return to our TPot deployment and access the Kibana dashboard to find the consolidated threat data from the 10 deployed honeypots on our system

DATA REPORT

Top 10 Attacker Locations

The geographic breakdown of attacks collected by the honeypot highlights the global scale and distribution of malicious activity, with notable concentrations in Europe, North America, and Asia.

Countries

Cities

  1. France


  2. United States


  3. The Netherlands


  4. China


  5. Brazil


  6. Canada


  7. Ukraine


  8. Bulgaria


  9. Panama


  10. Romania

  1. France


  2. United States


  3. The Netherlands


  4. China


  5. Brazil


  6. Canada


  7. Ukraine


  8. Bulgaria


  9. Panama


  10. Romania

  1. Shaoxing


  2. Baltimore


  3. Kiev


  4. Paris


  5. Amsterdam


  6. Salvador


  7. Sofia


  8. Bucharest


  9. Singapore


  10. Chengdu

  1. Shaoxing


  2. Baltimore


  3. Kiev


  4. Paris


  5. Amsterdam


  6. Salvador


  7. Sofia


  8. Bucharest


  9. Singapore


  10. Chengdu

Highest Volume of Attacks by IP Address

  1. 189.28.184.88

    1. Country: Brazil

    2. Number of Attacks: 323,902

    3. Type & Port: TCP/22 SSH Bruteforce Attack

    4. ISP: ENGEPLUS INFO

    5. Honeypot:



  1. 148.113.207.170

    1. Country: Canada

    2. Number of Attacks: 313,147

    3. Type & Port: TCP/22 SSH Bruteforce Attack

    4. ISP: OVH SAS

    5. Honeypot:



  1. 133.242.149.220

    1. Country: Japan

    2. Number of Attacks: 125,740

    3. Type & Port: TCP/22 SSH Bruteforce Attack

    4. ISP: SAKURA Internet

    5. Honeypot:



  2. 62.149.25.72

    1. Country: Ukraine

    2. Number of Attacks: 87138

    3. Type & Port: TCP/22 SSH Brutefroce Attack

    4. ISP:1 Cloud Lab (75,228 attacks)

    7heaven LLC (11,910 attacks)



  1. 61.16.120.186

    1. Country: Singapore

    2. Number of Attacks: 86,727

    3. Type & port: 445

    4. Honeypot: Dionaea

    5. ISP: SPTEL PTE.LTD.



  2. 2.57.121.207

    1. Country: Romaina

    2. Number of Attacks: 83,749

    3. Type & Port: 5060

    4. Honeypot: SentryPeer

    5. ISP:Unmanaged Ltd.



  3. 45.249.8.86

    1. Country: Pakistan

    2. Number of Attacks: 82,408

    3. Type & Port TCP/22 SSH Bruteforce Attack

    4. Honeypot: Cowrie

    5. ISP: Trans World Enterprise (Private) Limited



  4. 103.116.202.218

    1. Country: Indonesia

    2. Number of Attacks: 78,375

    3. Type & Port: TCP/22 SSH Bruteforce Attack

    4. Honeypot: Cowrie

    5. ISP: PT Parsaoran Global Datatrans


  5. 193.37.69.157

    1. Country: Netherlands

    2. Number of Attacks: 68,377

    3. Type & Port: 5900

    4. Honeypot: Heralding

    5. ISP: Nechaev Dmitry


  6. 79.124.49.154

    1. Country: Bulgaria

    2. Number of Attacks: 46,550

    3. Type & Port: 5900

    4. Honeypot: Heralding

    5. ISP: Tamatiya EOOD


Key Observations


  • 8 out of 10 attackers are using TCP/22 for brute force SSH attacks. This reflects a pervasive targeting for open SSH hosts, most likely though automated botnets


  • The top 2 addresses alone account for 637,000 attacks, nearly half of recorded traffic, indicating certain IP Ranges may be heavily misused or neglected in abuse handling


  • While SSH is the most common target, ports 445, 5060, and 5900 (SMB, VoIP, and VNC respectively) also appear, signifying the importance of hardening services beyond just SSH


Actionable Mitigation


  • Most frequent attackers should be the easiest, and most pertinent to utilize firewall rules against, blocking top offending IPs or CIDR blocks. Also considering blocking at the country level if these IPs fall within known regional ranges that aren't a part of our active user base.


  • Reporting repeat offenders to their respective ISPs/Abuse DBs. This helps broaden the communication regarding attackers in the current threat landscape to other analysts.


  • Integrating TPot log output into a SIEM or alerting system for better visibility.


Attacks by (Known) Attacker Source Reputation

  1. Known Attacker: 1,185,127

  2. Bot, Crawler: 60,682

  3. Form Crawler: 9,321

  4. Mass Scanner: 4,241

  5. Tor Exit Node: 191

  6. Anonymizer: 39

  7. Bitcoin Node: 2

  1. Known Attacker: 1,185,127


  2. Bot, Crawler: 60,682


  3. Form Crawler: 9,321


  4. Mass Scanner: 4,241


  5. Tor Exit Node: 191


  6. Anonymizer: 39


  7. Bitcoin Node: 2

Key Observations


  • The vast majority of attackers come from known sources making up over 230k of the attacks. This suggests that as an attacker you may be more likely to be flagged or draw attention by using a Tor node or Anonymizers.


  • Mass scanners make up a small, but significant portion of attacks. These are most often opportunistic attackers, looking for open ports or vulnerable services utilizing specialized tools such as Shodan, Masscan, or ZMap.

Top ASNs

  1. ASN #: 401116

    • Hosting Company: NYBULA

    • Location: United States

    • Count: 453,862


  2. ASN #: 16276

    • Hosting Company: OVH SAS

    • Location: France

    • Count: 405,913


  3. ASN #: 28292

    • Hosting Company: ENGEPLUS INFORMATICA LTDA

    • Location: Brazil

    • Count: 323,902


  4. ASN #: 211632

    • Hosting Company: Internet Solutions & Innovations LTD.

    • Location: Seychelles

    • Count: 244,344


  5. ASN # 44477

    • Hosting Company: Stark Industries Solutions Ltd

    • Location: United Kingdom

    • Count: 182,746


  6. ASN #: 14061

    • Hosting Company: DIGITALOCEAN-ASN

    • Location: United States

    • Count: 182,148


  7. ASN #: 213194

    • Hosting Company: Nechaev Dmitry Sergeevich

    • Location: Russia

    • Count: 166,597


  8. ASN #: 47890

    • Hosting Company: Unamanged LTD.

    • Location: United Kingdom

    • Count: 142,795


  9. ASN #: 43350

    • Hosting Company: NForce Entertainment B.V.

    • Location: Netherlands

    • Count: 94,855


  10. ASN #: 59425

    • Hosting Comapny: Chang Way Technologies Co. Limited

    • Location: Hong Kong

    • Count: 84,451

Top Commands

  1. echo -e \x46\x49\x4e - 11,373 attempts


  2. shell - 4,780 attempts


  3. system - 4,794 attempts


  4. cd ~; chattr -ia .ssh; lockr -ia .ssh - 3,767 attempts


  5. lockr -ia .ssh - 3,767 attempts


  6. uname -a - 3,729 attempts


  7. cat /proc/cpuinfo | grep name | wc -l - 3,439 attempts

Key Observations


  • echo -e \x46\x49\\x4e

    contains obfuscated hex output. The use of echo -e is common in malware stagers or obfuscated commands that download or initialize a second-stage payload.


  • shell and system commands reflect efforts to gain shell access on the honeypot or execute system-level commands. This suggesting attackers are seeking to elevate privileges.


  • uname -a

    Attempted frequently, this is a reconnaissance technique that collects kernel and OS info.

Actionable Mitigation


  • We can setup detection rules for specific keywords used in commonly attempted commands. So for example, we could make a detection rule to alert based on the use of echo -e with \x values. This would be considered a high-confidence indicator of staging/obfuscated malicious activity


  • In the event of unauthorized shell access, the results could be catastrophic on our internal network. Therefore, we may want to add non-admin users to restricted shells (rbash, nologin, etc.)

Attempted Script Execution & Malware Downloads

  1. IP Address: 196.251.70.219

    • Location: Netherlands

    • Filename: clean.sh

    • No. of Attacks: 32


  1. IP Address: 196.251.70.219

    • Location: Netherlands

    • Filename: redtail.arm7

    • No. of Attacks: 20


  1. IP Address: 196.251.70.219

    • Location: Netherlands

    • Filename: redtail.arm8

    • No. of Attacks: 20


  1. IP Address: 196.251.70.219

    • Location: Netherlands

    • Filename: redtail.armi686

    • No. of Attacks: 20


  1. IP Address: 141.98.10.122

    • Location: Lithuania

    • Filename: telnet (Trojan Downloader)

    • No. of Attacks: 11


  1. IP Address: 196.251.71.100

    • Location: Seychelles

    • Filename: no.sh (Trojan Downloader)

    • No. of Attacks: 8


  1. IP Address: 37.44.238.92

    • Location: France

    • Filename: bins.sh (Trojan Downloader)

    • No. of Attacks: 8


  1. IP Address: 64.182.209.151

    • Location: United States

    • Filename: jack5tr.sh

    • No. of Attacks: 4

  1. IP Address: 196.251.70.219

    • Location: Netherlands

    • Filename: clean.sh

    • No. of Attacks: 32


  2. IP Address: 196.251.70.219

    • Location: Netherlands

    • Filename: redtail.arm7

    • No. of Attacks: 20


  3. IP Address: 196.251.70.219

    • Location: Netherlands

    • Filename: redtail.arm8

    • No. of Attacks: 20


  4. IP Address: 196.251.70.219

    • Location: Netherlands

    • Filename: redtail.armi686

    • No. of Attacks: 20


  5. IP Address: 141.98.10.122

    • Location: Lithuania

    • Filename: telnet (Trojan Downloader)

    • No. of Attacks: 11


  1. IP Address: 196.251.71.100

    • Location: Seychelles

    • Filename: no.sh (Trojan Downloader)

    • No. of Attacks: 8


  2. IP Address: 37.44.238.92

    • Location: France

    • Filename: bins.sh (Trojan Downloader)

    • No. of Attacks: 8


  3. IP Address: 64.182.209.151

    • Location: United States

    • Filename: jack5tr.sh

    • No. of Attacks: 4


  1. IP Address: 196.251.70.219

    • Location: Netherlands

    • Filename: clean.sh

    • No. of Attacks: 32


  1. IP Address: 196.251.70.219

    • Location: Netherlands

    • Filename: redtail.arm7

    • No. of Attacks: 20


  1. IP Address: 196.251.70.219

    • Location: Netherlands

    • Filename: redtail.arm8

    • No. of Attacks: 20


  1. IP Address: 196.251.70.219

    • Location: Netherlands

    • Filename: redtail.armi686

    • No. of Attacks: 20


  1. IP Address: 141.98.10.122

    • Location: Lithuania

    • Filename: telnet (Trojan Downloader)

    • No. of Attacks: 11


  1. IP Address: 196.251.71.100

    • Location: Seychelles

    • Filename: no.sh (Trojan Downloader)

    • No. of Attacks: 8


  1. IP Address: 37.44.238.92

    • Location: France

    • Filename: bins.sh (Trojan Downloader)

    • No. of Attacks: 8


  1. IP Address: 64.182.209.151

    • Location: United States

    • Filename: jack5tr.sh

    • No. of Attacks: 4

Actionable Mitigation


  • If I was operating this machine from an on-premises location, these would be immediate indications to add offending IPs to denylists. Similarly, if I was hosting this machine on cloud-infrastructure, I would immediately want to move to configure network security groups, or ACLs to restrict connections from known-malicious geographies.


  • Capturing any of these payloads invites analysis via a Sandbox such as Cuckoo AnyRun, or VirusTotal.

Indicators of Compromise

TPot detected targeted exploitation attempts of multiple high-profile CVEs, including over 600 attempts to exploit CVE-2020-11910 and nearly 600 additional attempts against CVE-2020-11899—both vulnerabilities that impact widely used FTP and embedded networking stacks.


This activity reflects opportunistic and possibly automated scanning by actors targeting known vulnerabilities in legacy or misconfigured systems.

Additional activity involving a bundle of Ripple20-related CVEs underscores the importance of asset inventory and patch validation, particularly for embedded or IoT systems. Security teams should implement CVE-based alerting and network segmentation to reduce the attack surface of such vulnerable components.

Conclusion

This project successfully demonstrated how honeypots, paired with structured threat analysis, can uncover actionable intelligence and support real-time defensive decision-making. This type of telemetry is critical in informing SOC operations, guiding incident response playbooks, and validating detections within SIEM platforms.


Going forward, these insights can be expanded by integrating threat feeds, enriching honeypot telemetry with automated classification, and feeding indicators into detection pipelines to create a feedback loop between deception, detection, and response.


Several key findings stood out:


  • SSH brute force attacks remain the most dominant attack vector, often sourced from known malicious IPs and automated botnets.



  • Multiple malicious scripts and architecture-specific malware variants were deployed, indicating the use of modular payloads and target-aware delivery mechanisms.



  • Behavioral patterns such as .ssh directory tampering, privilege escalation attempts, and hardware reconnaissance (e.g., CPU checks) reinforce the need for endpoint hardening and behavioral-based alerting.

Conclusion

This project successfully demonstrated how honeypots, paired with structured threat analysis, can uncover actionable intelligence and support real-time defensive decision-making. This type of telemetry is critical in informing SOC operations, guiding incident response playbooks, and validating detections within SIEM platforms.


Going forward, these insights can be expanded by integrating threat feeds, enriching honeypot telemetry with automated classification, and feeding indicators into detection pipelines to create a feedback loop between deception, detection, and response.


Several key findings stood out:


  • SSH brute force attacks remain the most dominant attack vector, often sourced from known malicious IPs and automated botnets.



  • Multiple malicious scripts and architecture-specific malware variants were deployed, indicating the use of modular payloads and target-aware delivery mechanisms.



  • Behavioral patterns such as .ssh directory tampering, privilege escalation attempts, and hardware reconnaissance (e.g., CPU checks) reinforce the need for endpoint hardening and behavioral-based alerting.