Network Penetration and Security Report
Project 'Expanding trish'

2009 Team
Ted Stein
Jori Hardman
Kenneth Liu
Mike Chang

Original Team
Anda Bereczky 
Jeff Hentschel 
Greg McGlynn 
Isaac Wilson 

(T)iny (R)es(I)lient (SH)ell was developed last year to execute operations on an opposing machine 
after obtaining shell access. Trish was written to provide a remote shell that is hard to detect 
and even harder to destroy, allowing us to maintain our presence on the machine.  Although most of 
the codebase has been provided, there were several glaring bugs, and setup/installation was a 
chore.  Our purpose is to examine the current state of Trish's code, comment it, hunt for bugs, and 
enable its intended functionality.  The primary goal was not to provide new features, but to 
instead develop it further to provide a stable, well-documented, and easy-to-use resource.


Trish has the following original features: 
* execution of arbitrary commands on the opposing machine 
* upload files from the opposing machine 
* resilience: automatic stealth features to hide trish's presence on the opposing machine and fight 
against its removal:

    - Initially Trish spawns three identical processes.  When one of these are destroyed, it with 
spawn several more processes, ensuring Trish will always have a presence on the machine. 
    - When a Trish process spawns, its process name is copied from one of the currently running 
processes, making it hard to track down which running programs are Trish.

* a web interface to easily track and control the copies of trish present on all exploited 
machines, accessible from multiple computers 

Trish has been updated with the following features: 
* Originally the EXEC command only allowed the execution of one-argument commands.  This has been 
fiixed, so Trish can now run commands with an arbitrary number of arguments. 

* Added a simple malloc to randomize trish's process size, making it less obvious.

* Added many debug IFDEFs to the code so Trish can be compiled in debugging mode, allowing easier 
bug fixing.

* Originally the code was completely devoid of comments.  Most functions now have added comments to 
assist in debugging and modifications. 

* Originally, Trish came with a MYSQL database dump, requiring manual configuration of MySQL before 
installation.  This setup process has been replaced by a perl script which automatically compiles 
and installs Trish's command center.  It also changes several variables in the Trish binary to 
reflect the address of the new command center.  The entire process requires minimal user input, and 
as long as the dependencies are installed, it allows Trish to be completely set up in a couple of 

* When we first received the code, the web interface was missing many crucial javascript files 
rendering it useless.  We obtained the lost code, and fixed several minor bugs to get things 
working again.  We also added a page that allows the database to be cleared from one Trish use to 
the next.  

Trish Installation
1 - MySQL
2 - Apache
3 - GCC
4 - Perl

* To install the command center, simply run the perl script located in the trish 
directory.  The installer will prompt the user for the location of the www directory and the root 
MySQL password.  From there, installation is completely automated.  The Trish binary is provided as 
part of the command center at http://hostaddress/trish/trish.  Note that the binary will be 
compiled in the architecture of the command center computer.

Trish Deployment

Deploying trish is as simple as executing a few shell commands on the opposing computer.  Simply 
wget or curl the binary from the address given above.  The run the binary with ./trish &.

Trish Commands

The interface displays a list of all active trishes, including the host they run on and the 
username they run under. To command trish to execute an arbitrary 
shell command, you can send an EXEC command, either to all trishes or to all trishes who run under 
a certain username. The username that trish runs under 
will presumably correspond to the service that was originally exploited to deploy trish, so this 
allows you to run commands specific to a single exploited user. 

EXEC - lets you use trish to run arbitrary shell commands. 
As an example of what you might want to do, running the following command will search 
/example/directory and all subdirectories for flags and display any flags found: 
    ex: EXEC egrep '[[:xdigit:]]{8}-[[:xdigit:]]{4}-[[:xdigit:]]{4}-[[:xdigit:]]{4}-[[:x 
digit:]]{12}' -oR /example/directory 

GETFILE - allows you to retrieve the contents of any file from the host trish is running on. 
    ex: GETFILE /etc/passwd 

CHECKBACK - allows you to set how often Trish checks back (in seconds).
    ex: CHECKBACK 10

CRONTAB - Creates a cron job on the local machine.  The cronjob is specified by a url.
    ex: CRONTAB
*** This command was specified by the original team, but never implemented by either - this is in part
due to the fact that trish can already execute arbitrary commands.

Commands will not be executed immediately: trish periodically checks back with the command server 
to see if there are any new commands waiting for it, and only then are commands executed. Therefore 
it may take several seconds for your command to run. When it does, the results will be visible on 
the server. 

Viewing Trish on the Server
The trish web interface is located at http://hostaddress/trish. The following tabs are available: 
* add job - add a job to the queues of trishes given a username or ip 
* files - view contents of retrieved files

* output - view the output of completed commands 
* queue - view tasks in the queue given a username or ip 
* trishes - view information for all trishes

* clear server - clear the database

When entering a job, you filter out which trishes you want to send the command to by the username 
the trish is running under and/or the ip that the trish has reported. You will then see how many 
trishes your job was added to. Keep in mind though that not all of these trishes may be alive. 

Trish Performance
Based on lab testing, trish builds and runs very quickly.  The perl installation script completes 
in less than a minute.

Future Development
Enhanced stealth - As it is right now, all trish processes will spawn with different names, but 
have the same start time.  This makes it easier for defenders to discover.  In the future, it 
may be useful to add some morph functionality and delayed child creation. An entire project could 
be devoted to messing with the start time data in the kernel.

Versatile Metasploit module - deployment would be expediated if we had a custom payload designed to 
automate the download/run process on a target machine. Currently, we must get a shell on the target 
first, then manually download and run.  Future teams might look into turning this shellcode 
( into a metasploit payload.

Refined web interface - We added code that should allow the sorting of columns in the files, 
output, queue, and trishes pages, however we couldn't get it working.  This code most likely needs 
only a few minor modifications to get it working, which would make it much easier to find specific 
items in each page.

The purpose of this project was to develop Trish from its initial state to a point that it could be 
easily deployed and used in a competition setting.  Although the new competition rules basically 
ruled out using Trish, we have still achieved our goal.  Someone with zero knowledge of Trish can 
now set up the command center and get Trish running in a matter of minutes, instead of the hours it 
took us when we got the initial code base.  The debugging IFDEFs and commenting should make future 
development of Trish much easier, allowing the featureset to be expanded even more by future 
projects.  The expanded functionality of the EXEC command as well as numerous small bugfixes has 
made the program much more powerful and resilient, allowing it to completely replace a remote shell 
in a competition setting.