Honeypot Report - T-pot: ADBHoney
Please note that this post is a continuation of My Honeypot Report series. For the main post and background information, please refer to this following link: https://pillothecat-hacks.tumblr.com/post/675760067780460544/honeypot-report-t-pot-cowrie
OVERVIEW OF ADBHONEY
ADBHoney is a low interaction honeypot for Android Debug Bridge over TCP/IP. An Android Debug Bridge (ADB) is a protocol to keep track of emulated and real phones/TVs,DVRs connected to a given host. Though this protocol is intentionally for developers to debug or push content to the devices, malicious attackers can run shell commands and execute binaries. ***reference: “https://github.com/huuck/ADBHoney”
ADBHoney ATTACK OVERVIEW
Compared to the Cowrie honeypot, ADBHoney had far fewer attacks. I’ve narrowed the scope of my search to a 12 hour window, on Thursday, Feb 10, from 12am -12pm.
Down below is a table of the two command input attacks; like from the previous post, we’ll break down and understand what each command line is doing.
** image will be more clear and visible in each section when we break down the commands!
ADBHoney ATTACKER ANALYSIS
Runtime-information-gathering (RIG) Attack – Ridgewood, USA (1) - 74.73.96.249
A RIG attack exploits apps to obtain sensitive user data that can range from simple phone conversations to the user’s health records. With the emergence of Android based Internet of Things (IoT) systems, attackers have been using this method of attack to gain access into devices with shared communication channels, such as Bluetooth. The attacker uses a malicious app and runs it along with another target application, and then abuses the connected service’s permissions. We’ll notice that the attacker uploads and APK or Android Package Kit, a file format used by the Android OS for distribution and installation of mobile apps and middleware. We can also see that the attacker installed the APK file after finding the path for Google TV, a popular app to jump between movies, TV channels, and other apps by combining all services in one convenient place.
Look familiar?
To give some extra context, here is another example of a RIG attack. An attacker might first abuse the IP of a camera’s motion detection capabilities; with a malicious app that does not require any permissions, the attacker then attacks the victim’s phone that is connected to the motion detector and turns off an alert that is sent to the phone. Maybe the attacker even steals information of the victim’s address from which the motion detector is set up. The connections between IoT devices might be a convenience to centralize our access to different apps, but it may also lead to security concerns.
When we examine the command inputs of this RIG attack down below, we’ll notice one of the commands runs “nohup”. This makes sense in the context of a RIG attack since nohup, short for “No Hangups” is a supplemental command that tells Linux systems not to stop a command once it has started; the attacker might be using this command to establish persistence and possibly to hide the attack.
**pm = package manager and am = activity manager
Trinity Miner – Quebec, Canada (2) 135.19.132.144
Before we talk about the Trinity Miner, let’s take a step back and re-explain what the Android Debug Bridge (ADB) is. As mentioned before, the ADB is a protocol to keep track of both emulated and real phones, TVs, or DVRs connected to a given host.
With an ADB, developers can both debug and push content to connected devices over port 5555. Hence the Trinity Miner’s initial attack is also very similar to a RIG attack, in that the attacker abuses the lax permissions settings of a shell to push and upload binaries to IoT connected Android devices. The process can give an attacker control over the device and have the device ready to be harvested by a botnet maker.
OSINT ON ATTACKERS
Open Source Intelligence is the process of gathering information of a target through open and public information. For our analysis, we’ll be mainly using Spiderfoot (which is built into the ELK stack) – with Shodan, Virus Total, and AlienVault OTX modules.
(Refer to Part 1 for setup -- https://pillothecat-hacks.tumblr.com/post/675760067780460544/honeypot-report-t-pot-cowrie)
We’ll start off with performing OSINT on IP address 135.19.132.144 (Machine 2) and then on 74.73.96.249 (Machine 1)
OSINT Machine 2 – Quebec, Canada – 135.19.132.144
First, let’s identify the domain name of this IP. By searching the attacker’s IP address: 135.19.132.144 on Talos Intelligence (whois tab), we’ll see that the domain is from videotron.com.
The address: 150 Beaubien West, Montreal Canada returned from Talos (in image above) is also helpful for me to identify the address I want to learn more about, especially since there are multiple addresses listed with the attacker from my Spiderfoot scan.
Upon google searching Videotron Ltee and the 150 Beaebien West address, we’ll find out that Videotron is and ISP (Internet Service Provider) headquartered in the stated address.
Much like the Cowrie attacks, we might notice another pattern in how the source of the attack point to another telecommunications company. While last time we examined KT and Chungwa Telecommunications, this time it’s a Canadian, Internet Service Provider in Quebec.
With this information I am led to believe that the command was executed by an infected host with a botnet. We can see this visually when we click on the “graph” section of our Spiderfoot results and see the outgoing connections of the attacks, and it’s spread to other networks. The red dot represents the source IP of the attacker, Videotron; seeing that most of connections are rallying to the IP 135.19.132.144, (even though the connections are a lot less compared to the attacker from Ridgewood,USA) I reasonably associate the source as the C&C of this Trinity Miner.
OSINT Machine 1 – Ridgewood, USA - 74.73.96.249
Speaking of Ridgewood, I deliberately started out with Quebec’s attack first to contrast the volume of connections for this RIG attack.
Look at these connections:
As we’ve learned, the nature of a RIG attack gains access to an ADB device and can pivot to all other IoT devices in the network. This might be one explanation for why there are a lot more centralized connection points, with subdomains associated with it.
There are also a lot more addresses linked to this attacker, so we’ll lookup Talos again to specify the attacker’s domain name and location.
It’s important to note here that our result distinguishes that the attacker is from Ridgewood in Queens, New York (and NOT the Ridgewood in New Jersey). *** I was confused at first because I’m not familiar with the area!!
But we’ll also see that the network owner is using Spectrum services and is flagged for it’s high spam level.
The whois tab on Talos points us to Charter Communications Inc (ANOTHER telecommunications service), but notice how when we google search Charter Communications Inc, the HQ address is in Stamford, Connecticut.
I’m interested in the address given from Talos’ whois search, and I looked up 6175 S. Willow Dr, Greenwood Village since that is in Colorado. But we’ll see another organization instead called CSG.
We might be particularly interested in the fact that CSG offers “support systems software and services, primarily to the telecommunications industry.
It is likely that that this attack is also connected by a botnet, by which the infected host has multiple applications also infected through a single ADB device!
CONCLUDING THOUGHTS AND DEFENSSIVE MEASURES
After conducting this analysis, normally we should turn our attention to best practices for defending ourselves against such attacks. Granted that for this project we’ve deliberately set our AWS security group’s inbound rule to be vulnerable, we can still see how open inbound rules should normally be restricted to trusted users or for those in the LAN. We can also consider closing any unused ports, especially by setting inbound rules for port 5555 – port for ADB protocol. As we saw many ADB attackers gain their initial foothold through port 5555, and then possibly pivot to any other devices in the network using the same port.
Also, specifically for RIG attacks, we can implement defensive applications, such as App Guardian. App Guardian “thwarts a malicious app’s runtime monitoring attempt by pausing all suspicious background processes when the target app (called principal) is running in the foreground, and resuming them after the app stops and its runtime environment is cleaned up.” Additionally, we can think about a multiple layers of IPS/IDS on the various devices connected over ADB in a network and block any malicious domains.
I hope you’ve been enjoying these articles as much as I have been enjoying analyzing my honeypot. Unfortunately, the honeypot is racking up my costs with the AWS instance that I’m using to host this honeypot, so it looks like this will be the end of this series (for now at least)! Still, to preserve the log files I was able to tar zip the honeypot data from the AWS instance, and then secure copy (scp) the data into my Kali Linux in to JSON files. In a later post we’ll try uploading the data into Splunk and analyze some results from there!
Until then, stay safe and protected in your network~