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/’.
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/’.
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.
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
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 12th,
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 20th, through December 1st. 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.
