The installation was very smooth, and the end result is neat. Don't try to run this with 4GB of memory, because is not gonna work. T-Pot requires at least 8GB (note to self: rtfm).
The number of attacks received always impresses me. Less than 45 minutes minutes after installation and the numbers are staggering.
👉🏿5,030 Dionaea attacks
👉🏿1,375 Cowrie attacks
Well, let's be honest, I didn't just run 1 T-Pot. 😂
Ah, my fellow country hackers 😅
Numbers going up nicely. Only 2 hours running. 🍿
The morning after deploying honeypots is like Christmas. Wake up early, way too excited to see what gifts are there for you!
For those interested, I installed a full version of T-Pot (@dtag_dev_sec). The server(s) were I've this installed has 8GB RAM/4CPU. T-Pot has around 20 different honeypots, an ELK suite, and pre-built Kibana dashboards. T-Pot GitHub repository is: github.com/telekom-securi…
Already having Kibana loading issues. It's incredible how much memory it requires. 8GB seemed enough, but now it's just struggling to load.
Alright, here we go. At least one dashboard loaded. An all time low around 1am, but got more active after that. This is after 14 hours since start time.
I was expecting numbers to be higher by now.
Interesting related paper that uses T-Pot data as their dataset: "Identifying Attack Propagation Patterns in Honeypots using Markov Chains Modeling and Complex Networks Analysis" (2016) cyber.bgu.ac.il/wp-content/upl…
Less than 48 hours after. Nice. And yes, I know. 🙏🏽
48 hs later, the Kibanas are completely unresponsive, the memory of the servers is completely depleted and I am almost unable to type commands via ssh because is super slow. Probably more than 8GB of memory are needed to run this for longer times.
It seems the real memory issue is due to log stash, not kibana. And that's a component you probably do not want to turn off. I see no real solution here except increasing memory, which is costly.
After a week, 3 out of 5 T-Pot installations crashed, and therefore stopped collecting data. Memory issues. The instances, all the same specs, had 8GB of RAM. The other two instances struggled but somehow survived. A quick walkthrough the observed attacks 👇🏿
Dionaea is, as usual, the most attacked. The majority of attacks coming from Vietnam, India, and Indonesia.
Cowrie, has a good 65,919 attacks. This seems a bit low for what we are used to see on SSH/Telnet ports. Surprisingly (?) most of the attacks are coming from Ireland, Russia, and Panama.
Adbhoney received 274 attacks. Again most attacking IPs are well known offenders. Most attacks coming from China, South Korea, and Russia.
The Ciscoasa honeypot received 131 attacks. Interestingly, most attacks coming from a single country: US.
Heralding honeypot received 7,137 attacks. The majority of attacks coming from Republic of Moldova and Seychelles. These two IPs attacking are well known offenders.
The top attacking country in this observation is Vietnam.
The end. EOM.
• • •
Missing some Tweet in this thread? You can try to
force a refresh
How does the traffic of Flexnet looks like? The sample shared below is available on @apklabio along with a nice pcap capture 👉🏿 apklab.io/apk.html?hash=…
From Wireshark Protocol Hierarchy Statistics we can see that most of the traffic is TCP on IPv4. Few UDP. A nice amount of packets.
Next step for me is always look at the conversations. I want to get a feeling of how many things do we need to check and verify. In this case there are only 12 IPs to check (1 IP is local). Easy to discard a few things here knowing this is an Android phone.
Now on the Green Room at #VB2019, @eldracote@anshirokova will present "Geost botnet. The discovery story of a new Android banking trojan from an OpSec error", a work also done with @MaryJo_E !
The Geost botnet was found by investigating the traffic of a different botnet: #htbot also known as proxyback. This htbot botnet offers a proxy service for users in the underground.
The Geost operators were using htbot to access the command and control servers from Geost (thinking they were hiding themselves).