For the last couple of days I've let three T-Pot honeypots in different parts of the world run with the goal of identifying and analyzing any possible patterns regarding what kind of Internet-based attacks and reconnaissance is happening, based on the geographical location of the target.
The three honeypots are set up in Amazon Web Services in different datacenters around the world:
- Oregon - US-West-2
- London - EU-West-2
- Seoul - AP-Northwest-2
We have one honeypot in the US, one in the EU and one in Asia. This will hopefully give us a basic understanding of what kinds of attacks are occurring based on the geographical location.
This is the third and possibly last part of this short series. I might write a conclusion later, but for now It's just been fun to dig through the data and getting it on paper.
This report as well as the London report have been running for longer than the Oregon honeypot, so the results may be a little bit skewed, but hopefully we will still be able to see patterns over all three honeypots.
So let's get started and finish of in Seoul!
Seoul - AP-Northwest-2
There are a few interesting things right out of the bat: Russia is still Nr.1 in number of events, but United States and China have switched places:
Russia - 96728 Events
United States - 94336 Events
China - 60728 Events
There are also a bigger percentage of events against VNC and SMB, although TELNET/SSH attacks still are the largest area to attack.
- Cowrie - 153708 Events
- Honeytrap - 107231 Events
- Vnclowpot - 49947 Events
- Dionaea - 13296 Events
For Cowrie in Seoul, China is actually in the lead in number of events with 54.260 (40.58%) events versus Russia's 52.803 (39.49%).
Other than that there really is not that much different to read from Cowrie; SSH/TELNET is still the most targeted protocols on the internet with the most events originating from Russia and China.
There are no spikes in traffic that sticks out, so we will proceed with usernames and passwords used against the honeypot:
As in the previous honeypots, no real surprises here; common passwords and passwords for IoT-devices reign supreme.
Let's take a look at what the attackers try to run when they identify a 'successful attack':
Previously we have only seen commands used to gather more information about the target (uname -a, ps, cpuinfo, etc.), but here we have a command that actually tries to download a file! According to URLhaus Database this IP has previously been used to distribute malware, and that's exactly what it tries to do this time.
do3309 is a Windows based trojan/bot which previously has been identified and uploaded to virustotal.com multiple times before. The malware is detected and stopped by the majority of AV-products out there, so it is not exactly the most effective or advanced malware out there.
For more detailed information on the virus itself you can read an analysis report from the automated sandbox tool: Joesandbox.
There is one IP-adress that almost all attacks are originating from:
This IP-adress is very close to the IP-adress that had the most attacks originating from it all together: 18.104.22.168.
This might be exit-nodes for a VPNs commonly used by attackers, or Internet Scanners placed in an IP-span.
With Honeytrap we get similar data to what we did in London, but not as many events originating from Russia. Instead the United States generated more events (43.793 or 42.56%) versus Russia (42.393 or 41.19%). This is probably because of the spike on ports 9022, 2280 and 122 that we also saw on the London Honeypot.
What's kind of interesting is that we did see the other spike from France on port 2313, but did not receive the spike on the 12th of October against port 3333 (Monero miners) that London did. I wonder why that is? The IP that was used during the spike (22.214.171.124) originates from India. Was the traffic blocked on the way, or did they just not target Korea?
With VNClowpot we get a very different event-curve than in London. Instead of a few spikes we get a long and continuous stream of attacks Originating in the United States (45.669 Events or 91.43%). Also in this case, there is a single IP-adress responsible for almost all attacks: 126.96.36.199, originating in Atlanta, USA. The AS/ASN (46261/QuickPacket, LLC) indicate that this IP is used for PVS-services, so it was probably used for a shorter reconnaissance mission.
And here are the VNC handshakes for Seoul:$vnc$*00000000000000000000000000000000*FF97502E9422F089FF97502E9422F089 $vnc$*00000000000000000000000000000000*DB6C002A7CCA479FDB6C002A7CCA479F $vnc$*00000000000000000000000000000000*7B98C4424077D6047B98C4424077D604 $vnc$*00000000000000000000000000000000*D29F6E7F0456F8DED29F6E7F0456F8DE $vnc$*00000000000000000000000000000000*D94BB74798A107C7D94BB74798A107C7 $vnc$*00000000000000000000000000000000*46661F5F1713169A46661F5F1713169A $vnc$*00000000000000000000000000000000*C899CEF7E6E7DAC7C899CEF7E6E7DAC7 $vnc$*00000000000000000000000000000000*CAB6C66B0E17D737CAB6C66B0E17D737 $vnc$*00000000000000000000000000000000*ECF87B7A5D68C77FECF87B7A5D68C77F $vnc$*00000000000000000000000000000000*37D5DA0FD47CDC4937D5DA0FD47CDC49
And lastly, let's take a look at Dionaea!
We get a very similiar dashboard as we got in Oregon. China is leading the charge against SMB-services with the intent of using EternalBlue or DoublePulsar.
No huge spikes in traffic of note, and over 90% of all traffic is against port 445.
Well, this honeypot wasn't as interesting as the previous, but we did get some interesting information to consolidate our data:
- Some of the spikes from Honeytrap occurred in both London and Seoul, but not all of them. After a second check, Oregon did also receive the spikes from United States and France, but not the last spike against 3333, which only London received.
- The Honeypot in Seoul was the only one where we could actually see someone try to infect it with a malware. We would probably see a lot more if we dug into the Cowrie data, but fun none the less!
- The honeypots collected the following number of events during last week:
Oregon - 348006
Seoul - 331670
London - 342697
This has been a fun small project in both AWS configuration, data analytics and just writing a technical report. I hope this has been somewhat eye-opening to some of you, and I hope to write something more soon!