What is hitting our honeypots?

In recent months, we’ve been sharing information collected by APNIC honeypots with our community at several conferences, seminars, and workshops. ‘Information’ here basically means observations from the logs/traffic, as well as artefacts collected (such as scripts and binaries). For those who are not familiar with APNIC’s Community Honeynet Project, you can check out some of the previous posts on this topic.

So, what is hitting our honeypots?

Cryptominers and DDoS agents — pick your poison

On our Cowrie honeypots that simulate Telnet and SSH services, we generally see two types of activities. Upon a ‘successful’ entry (such as guessing the correct credentials) the attack source will then download either precompiled binaries or a script to be executed.

Earlier this year, we had the privilege of Mohamad Yazid A Wahab helping to analyse a few things in our datasets. His work was part of his Cybersecurity Masters degree program at Griffith University.

One observation he made was how quickly malware can spread if it is not mitigated. For instance, we saw a particular URL for the first time on 13 March 2021. On that day, there were only two IP addresses associated with the URL, from Brazil and Romania. However, by the end of April there were about 900 unique IP addresses from 16 economies in the Asia Pacific region. So, what started out as an activity seen on only one honeypot sensor spread rapidly to 33 other sensors.

There’s no secret sauce in the spreading technique here. Threat actors scan for SSH service on port 22 and guess their way in:

timestamp, source_ip, protocol, username, password, ssh_agent
2021-03-13T09:40:34.094071,a.b.c.d,ssh, root,root,SSH-2.0-libssh_0.9.5

Secure your systems too!

Of course, there are other factors that help malware spread, such as using an easily guessed username/password combination and/or unnecessarily exposing your SSH service to the rest of the world. Unfortunately, at the time of this writing, the host serving the malicious script is still up and running, and we keep seeing new IP addresses from different places all trying to hit our honeypots with the same payload.

The SSH brute force activity in the log below is from a different bot/malware. While it may look harmless, it generates a lot of noise.

timestamp, source ip, username, password 

2021-08-03T03:32:55.693372,a.b.c.d,MikroTik,admin1
2021-08-03T03:32:05.122073,a.b.c.d,MikroTik,qwerty
2021-08-03T03:32:00.652876,a.b.c.d,MikroTik,test
2021-08-03T03:31:56.197063,a.b.c.d,MikroTik,passw0rd
2021-08-03T03:31:51.600284,a.b.c.d,MikroTik,88888888
2021-08-03T03:31:47.069584,a.b.c.d,MikroTik,password
2021-08-03T03:31:42.600393,a.b.c.d,MikroTik,admin123
2021-08-03T03:31:38.003806,a.b.c.d,MikroTik,11
2021-08-03T03:31:33.449066,a.b.c.d,MikroTik,1122
2021-08-03T03:31:28.829793,a.b.c.d,MikroTik,1
2021-08-03T03:30:35.719893,a.b.c.d,MikroTik,password
2021-08-03T03:30:30.080113,a.b.c.d,MikroTik,123456789
2021-08-03T03:30:24.606929,a.b.c.d,MikroTik,12345678
2021-08-03T03:30:20.228537,a.b.c.d,MikroTik,1234567
2021-08-03T03:30:15.089569,a.b.c.d,MikroTik,123456
2021-08-03T03:30:10.729907,a.b.c.d,MikroTik,12345
2021-08-03T03:30:06.381968,a.b.c.d,MikroTik,1234
2021-08-03T03:30:01.894832,a.b.c.d,MikroTik,123
2021-08-03T04:03:16.928385,a.b.c.d,telecomadmin,admin123
2021-08-03T04:03:12.504951,a.b.c.d,telecomadmin,11
2021-08-03T04:03:08.012282,a.b.c.d,telecomadmin,1122
2021-08-03T04:03:01.991040,a.b.c.d,telecomadmin,1
2021-08-03T04:02:57.441684,a.b.c.d,telecomadmin,password
2021-08-03T04:02:52.868634,a.b.c.d,telecomadmin,123456789
2021-08-03T04:02:46.606662,a.b.c.d,telecomadmin,12345678
2021-08-03T04:02:42.184402,a.b.c.d,telecomadmin,1234567
2021-08-03T04:02:37.635923,a.b.c.d,telecomadmin,123456
2021-08-03T04:02:33.158513,a.b.c.d,telecomadmin,12345
2021-08-03T04:02:28.633456,a.b.c.d,telecomadmin,1234
2021-08-03T04:02:24.056157,a.b.c.d,telecomadmin,123
2021-08-03T04:02:19.651843,a.b.c.d,telecomadmin,admin

This log activity can be useful for detection but the prerequisite is that you must be monitoring (popularly known as ‘threat hunting’). In other words, if you see several outbound SSH activities to multiple hosts on the Internet, then you probably have an infected system or bot in the house.

Here’s another example but this time it’s a Mirai infected system that is trying to spread by bruteforcing Telnet. The Wireshark screenshot below shows the infected host sending SYN packets to the destination port 23 at multiple IP addresses. In this case, we actually loaded one of the pre-compiled ELF binaries captured in one of the Linux Sandbox (LiSA).

More analysis, tools, and discovery

Speaking of Sandbox, other than using something like the LiSA, we also occasionally try to ‘execute’ the binaries in our own testing environment. In a nutshell, this involves setting up a Linux system that the binary was compiled for and setting up additional tools to capture memory and traffic (PCAP). Then we use Volatility to do the analysis on the memory dump. We actually did this in the workshop with Bhutan CERT recently.

Going back to the observation made by Yazid earlier, we use Volatility’s Yara plugin to tell us if there’s anything in the memory dump that matches one of the malware signatures.

The short answer is yes! As we can see in Figure 2, Linux Tsunami is found in the Yara result and if you look closely at the matching strings you can tell the purpose of this particular botnet is DDoS.

Additionally, the Suricata alerts showed some Internet Relay Chat (IRC) activities over port 8080.

05/25/2021-11:14:51.304265  [**] [1:2019240:14] ET POLICY Executable and linking format (ELF) file download Over HTTP [**] [Classification: Potential Corporate Privacy Violation] [Priority: 1] {TCP} a.b.c.d:80 -> 10.0.2.15:39526


05/25/2021-11:14:53.336178  [**] [1:2000345:16] ET MALWARE IRC Nick change on non-standard port [**] [Classification: A Network Trojan was detected] [Priority: 1] {TCP} 10.0.2.15:54206 -> w.x.y.z:8080

05/25/2021-11:14:53.514247  [**] [1:2000345:16] ET MALWARE IRC Nick change on non-standard port [**] [Classification: A Network Trojan was detected] [Priority: 1] {TCP} 10.0.2.15:54206 -> w.c.y.z:8080

It turns out that an IRC server was set up on a university server in APNIC’s region and used as a ‘command and control’ for the botnet. Basically, the infected systems get instructions from the bot operator using IRC.

Now, if we think about this for a moment, we have uncovered another component in the threat actor’s infrastructure. In this case, it’s a compromised server. Normally, when I’m giving a presentation, this is the moment where I’d point out to everyone that if you don’t make an effort to secure your assets, they could be part of malicious or criminal activities. I’d also mention the robustness of the IRC protocol — long live IRC!

Seriously, though, to see this old tactic still being used in 2021 is quite concerning, especially given this is just one example from the many hits we see daily on our honeypots. These are not the advanced persistent attacks (APTs) everyone is talking about, but they are prevalent.

Takeaways

1. Do you know what your systems are exposing to the Internet? If not, scan your own network or use something like Shodan.
2. If you have services that need to be exposed (like SSH), harden the service and create an access control list for those who need to access those services. Also in 2021, you shouldn’t be using Telnet over the insecure Internet.
3. Are any of your resources part of a botnet or participating in activities that are considered malicious? If you’re a network operator, consider getting free feeds from Shadowserver. If you’re an APNIC Member, check out DASH. These feeds may cover only a subset of bad things, but they are very useful.
4. Is any host or system in your network serving malware? URLhaus offers AS number and Top Level Domain feeds for network operators and ISPs.
5. Once you have the daily feeds and reports you can plan to remediate any future problems. This may be very straightforward, or not, but if you don’t do anything the problem won’t go away.

As this post emphasizes, if there’s no action taken on both the infected system and the infrastructure used by threat actors, you can only expect more infection.

No mitigation = more bots.

Rate this article

---

The views expressed by the authors of this blog are their own and do not necessarily reflect the views of APNIC. Please note a Code of Conduct applies to this blog.