Broad Scanners Scanning Broad Scanners

Try saying that five times fast. Well, in sticking with the trend of last week’s post, today we’re going to analyze another broad scanner scanning for broad scanner victims! 

Incident Overview

Ah, a request for “//jmx-console/HtmlAdaptor”. At first glance, it’s evident this scanner is looking for JBoss installations which are typically found on port 8080, and specifically those that are susceptible to the CVE-2010-0738 vulnerability. This is not an uncommon scan, and there are several known bot nets which continue to fight for the remaining vulnerable host’s ownership. However, the reconnaissance scans for this vulnerability often involve a simple HTTP ‘GET’, or ‘HEAD’ request for ‘/’, which then utilizes the response JBoss version header to determine susceptibility. These reconnaissance scans also typically happen, randomly, against either port 80 or 8080, whereas this one statically utilizes port 8080. Also uncommon is the 7 following events. A quick query reveals what they are.

//jmx-console/HtmlAdaptor
//manager/html/upload
//zecmd/zecmd.jsp?comment=whoami
//CluJaNuL/cmd.jsp?cmd=whoami
//wstats/wstats.jsp?comment=whoami
//idssvc/idssvc.jsp?comment=whoami
//iesvc/iesvc.jsp?comment=whoami
//bynazi/cmd.jsp?comment=whoami

The first requested URI is the one we determined was a CVE-2010-0738 reconnaissance scan. The next request appears to be reconnaissance for a known Apache Tomcat vulnerability, CVE-2009-3843.

The next six requests are for web shells which are commonly placed on machines which have succumbed to one of the many Bot Nets which often thrive on each CVE. Each of these URIs also contains the “comment” parameter, which is the command to be evaluated by the compromised system, within the context of the underlying process, either Apache Tomcat or JBoss. You'll also notice the attempted command is the operating system indiscriminate 'whoami', which will return the username running the underlying process.

The 2nd URI, //manager/html/upload, is an atypical reconnaissance string for the CVE-2009-3843 vulnerability. Seeing as it’s the 2nd most commonly requested URI, right behind ‘/’ and right before ‘http://www.google.com/’.

Remember, that a request for '/' is the standard URI we expect to see, and is widley utilized for reconnaissance scans. With that in mind, and verifying with other heuristics, CVE-2009-3843 is the most scanned vulnerability the Honey Net has observed.

As noted, the difference between the common CVE-2009-3843 reconnaissance and this one is the addition of the ‘/upload’ string, which is a more direct path to verifying the vulnerabilities existence. Once again, the request is only observed against port 8080, whereas numerous other ports, including port 80, are commonly targeted.

The succeeding six requests are what especially stands out. Not only is this scanner looking for evidence of susceptibility to both CVE-2010-0738, and CVE-2009-3843, but it’s looking for prior compromises against the 2010-0738 JBoss exploit.

Historical Activity

As seen in the database query above, this scanner has scanned us on four separate occasions, June 18th, June 21st, June 23rd, and June 25th. But this is notably only within the context of the HoneyNet. It’s important to enumerate information however possible. In this case, simple Google searches for each of the Web Shells provides insight into this scanners past. Particularly, Project Honey Net has this entry dating all the way back to November 28th, 2013.

https://www.projecthoneypot.org/ip_164.177.156.128 

We also find several Access Logs which have been graciously hosted by their admins.

Someone keeps trying to load /bynazi/cmd.jsp, only Google results are other logs of said requests.
— Ollie Read (@ollieread) November 24, 2013

Well, it’s evident this is nothing new. The first set of event logs which indicate the 202.104.254.245 address was previously infected even contains the same User-Agent String from the currently scans. User-Agent strings are often very good identifiers for linking actors between events, especially such a verbose one like this.

 http://www.useragentstring.com/

This User-Agent may blend in well with normal activity, however its presence with an automated scanner sticks out like a sore thumb. From the Google search we were able to trace this URI Request Pattern, and the User-Agent to the 202.104.254.245 host as far back as December 10th. The replication of this User-Agent heavily suggests it’s static to the specific scanner. The Google Chrome Release Calendar tells us this User-Agent was introduced as early as August 12^th, 2013, which suggests the script was assembled at a point in time later than that date. There’s also the log indicating the 184.22.46.91 host was infected and scanning from November 20^th, through December 1^st. There are numerous other logs found through simply Google searches which map this scanners activity even more thoroughly, but I'll leave that as an exercise to the reader.

Monkey See, Monkey Do

When dealing with broad scanning bot nets, there’s an important concept to remember. The vulnerability that this host is scanning you for, most often is the same it itself has succumbed to.

Running a quick request replay against the source host seems to verify that the source host is itself infected. It also suggests that our attacker is none the wiser to their own games. Remember, practice what you preach, especially if you’re going to randomly preach it to millions of random IPv4 addresses. Non-Intrusive Reconnaissance of the [previously] compromised hosts discovered by Google suggests they’ve been replaced and/or remediated since their involvement.

In Conclusion

It’s evident the attacker doesn’t fully understand what they’re exploiting. From the requests, it’s clear that the attacker is well capable of ascertaining the host’s susceptibility to either vulnerability within the first two requests. However, they then proceed to reveal their intent through the following six events. The attacker also doesn’t fully understand the behavior of their targeted botnets, which often scan more than just port 8080 which is statically chosen in these attacks.

Though the context of this campaign isn't yet known, it leaves significant forensic evidence behind to correlate its activity far into its origin. There's also significant evidence the attacker isn't cleaning up after themselves, suggesting more incriminating evidence has been left behind. The pattern introduced by the Request URIs is unique enough in itself, but the further correlation of such a verbose User-Agent helps to map the threat actor as they navigating from box to box. Furthermore, the centralized scanning suggests the attacker is not utilizing the ill-acquired hosts to directly replicate itself and expand in a Worm like fashion.

In closing, I’ll mention that I initially investigated this activity a few days ago. I attempted to contact the Web Server’s administrator (the Administrator of the FQDN currently points to the host address), and I of course am still waiting for their acknowledgement. Though, I suspect a language barrier may play a heavy role in this.