All Shellz Breaking Loose

By Dan Kottmann ·

Working in the Security Assessments team at FishNet Security, we perform a variety of engagements aimed at identifying risk among our clients. By far, the most common engagement my team performs is a typical network penetration test. Although I won’t delve into the details of our methodology, exploitation is certainly the most discussed portion of the process. The outcome of an attempted exploit is generally synchronous and near real-time:  submit request and receive a response indicating success/failure.

Unfortunately, not all tests operate in such a pristine fashion. For example, consider a spear phishing campaign. After an email is sent, exploitation may occur periodically over the course of a few days at no predictable interval. What if the campaign is geared toward capturing credentials and the credentials are one-time use and/or time-limited passwords such as those commonly used for two-factor authentication? Do we manually watch for new credentials around the clock over the course of seven days to ensure we don’t miss our opportunity?

Also consider tests where feedback is not readily accessible. For example, onsite physical assessments often include plugging a device (e.g. Sheeva Plug, PwnPlug) into the target network. The device provides backdoor access to the network. If we’re onsite then how do we know if connectivity was established? Maybe an authenticated proxy is preventing the outbound connection from that particular source port? There’s nothing worse than assuming connectivity only to later find out that it failed.

So what do we do? We can’t be in two places at once, and our time is too valuable to watch for new credentials and shells around the clock.

Recently while executing multiple breach assessments, my colleague Chris Patten and I experienced a number of challenges similar to those described above. Additionally, due to network latency issues we had limited windows to interact with Meterpreter shells before we lost connectivity. The success of our tests was in jeopardy unless we could figure out a method to do the following:

  • Alert us when new credentials were captured.
  • Alert us when a new Meterpreter shell was received in our lab.
  • Alert us when our Sheeva Plug connected/disconnected.

This would allow us to respond to certain time-sensitive events without constant, manual monitoring and would allow us to confirm device connectivity without assumptions.

Born from these requirements was a small Python application named SeeShells. Created by Chris and I, the application simply watches for significant events and sends an SMS text message to our phones within 10 seconds of the event. The application is highly configurable and allows us to maintain constant visibility on our environment and take almost immediate action if necessary. It contains functionality to monitor the following:

  • Connected/disconnected OpenVPN connection from a device
  • Startup/shutdown of a local listening port
  • New Meterpreter shell
  • New credential captured from a login portal

Filters can be defined to limit the alerts to only those items that are of interest to the tester. Optionally, a Powershell feature allows you to automatically run a Powershell script against any new Meterpreter shell (e.g. a Veil payload utilized in a persistence script).

SeeShells is an open source project released under MIT license. Download or contribute at:

https://bitbucket.org/dkottmann/seeshells

For a complete demo, view the following video: