InfoSec Handlers Diary Blog

Apache Tomcat is a java based web service that is used for different applications. While you may have it running in your environment, you may not be familiar with its workings to provide adequate incident response when the time come. This article will walk through an incident where Tomcat is used and what critical artifacts you should collect.

This articles assumes that you have already collected MACtimes (hxxps://digital-forensics.sans.org/blog/2011/12/07/digital-forensic-sifting-super-timeline-analysis-and-creation) and other volatile data.

Locating Install Directory

Tomcat can be installed in several different locations, but the most common are for Redhat: /usr/share/apache-tomcat-(version) and for Ubuntu: /usr/share/tomcat or /var/lib/tomcat. To be sure you have the right locations track down the Tomcat process and analyze it.

Here you can see that it is running from /usr/share/apache-tomcat-7.0.65. Depending on the install this will likely contain all the artifacts for tomcat that we need but we should still verify. If you are not getting an entire copy of the system, make sure that you get a backup of this directory along with the other critical ones.

Tomcat Logs

On the system I dealt with, the logs were in a subfolder called logs (e.g. /TOMCAT_HOME/logs). Check to make sure you have stuff in it, if not it is likely using syslog or the attacker cleared it out.

Catalina.out file is output from the tomcat console into this file. It is a multi-line log file, but has time and date stamps. This file shows if modules are added and other output that is useful for IR. Access_log is in common Apache format, but it is a simple format that does not have the user agent information. The manager.log and host-manager.log really did not have any useful information in my case.

For more information about Tomcat loging visit hxxps://tomcat.apache.org/tomcat-7.0-doc/logging.html

Web Applications Locations

Web applications are located on TOMCAT_HOME/webapps/. To deploy a web app, you must use the Tomcat web manager which you will see GETS and POSTS to /manager/ folder in the access logs.

For more info on Tomcat app deployment visit hxxps://tomcat.apache.org/tomcat-4.1-doc/appdev/deployment.html

Config File Locations

The Tomcat configurations are located in the TOMCAT_HOME/config directory. Server.xml is the main server config file. Tomcat-users.xml is a list of users and passwords for the system. The default admin password is:admin:password.

The Incident

Now that we know where to look, let’s go over the incident. A system was discovered to be compromised so I started our IR process. When looking at the processes running, a process was quickly changing its name and running as root. When looking at the list of open files for the process, I got a hint that tomcat might have something to do with the compromise.

Lets see if any files have changed in the Tomcat directory recently to get an idea of possible time of compromise. The file in /usr/bin/qymasclksx is being deleted and recreated every few seconds, so that will not be helpful for initial compromise time.

Here you can see that the attacker accessed the Tomcat management as the admin user and uploaded a file. Then the attacker access another page that accepts a command via a POST. Let’s see how the attacker was able to gain access as the admin user to the manager site. By viewing the tomcat-users.xml file, we can see that a very common username/password is being used.

/usr/share/apache-tomcat-7.0.65/conf/tomcat-users.xml

-->

The package that was installed was “jsp File browser 1.1a”. This allowed the attacker to install his backdoor/DDOS tool called Xorddos. Mandint did a write-up about this and mostly what I found was similar to their findings. (hxxps://www.fireeye.com/blog/threat-research/2015/02/anatomy_of_a_brutef.html)